From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3 7/8] zynq: Move SPL console init out of board_init_f()
Date: Mon, 19 Oct 2015 07:15:19 +0200 [thread overview]
Message-ID: <20151019071519.2aa26c7c@lilith> (raw)
In-Reply-To: <CAPnjgZ2fY3c3hsTQexuN2Q5nyC8TM9rHpo=VSdWapUC=S3L6Dw@mail.gmail.com>
Hello Simon,
On Sun, 18 Oct 2015 14:37:03 -0600, Simon Glass <sjg@chromium.org>
wrote:
> Hi Albert,
>
> On 18 October 2015 at 10:36, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote:
> > Hello Simon,
> >
> > On Sat, 17 Oct 2015 15:07:00 -0600, Simon Glass <sjg@chromium.org>
> > wrote:
> >> We should not init the console this early and there is no need to. If we want
> >> to do early init it can be done in spl_board_init(). Move the
> >> preloader_console_init() call from board_init_f() to board_init_r().
> >>
> >> Signed-off-by: Simon Glass <sjg@chromium.org>
> >> Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> >> Tested-by: Michal Simek <michal.simek@xilinx.com>
> >
> > I personally think that we should, almost must in fact, initialize the
> > console as early as possible.
> >
> > What exactly is the drawaback of initializing the console here?
>
> This is described in the README now for SPL. The console is not
> available until driver model is ready, which cannot be before
> global_data is ready.
Makes sense now.
Maybe the commit message could explicitly mention that the cause of the
"should not" is the driver model? This commit might be viewed in
isolation and the reader may need a clue on how to relate that commit
to the driver model or the README.
> My second zynq series removes the next few lines from board_init_f(),
> so in effect there is very little difference in timing - the console
> still is set up very early. It is just that we must not set it up
> before driver model is running.
>
> There is also a debug UART which can be used to make printf() work
> before global_data is available. But I'm trying to remove the
> global_data hacks that exist in early board code.
Then my initial concern is address (and again, maybe a small note in
the commit message could remind the reader about the debug UART not
being affected by the commit). Thanks!
> Regards,
> Simon
Amicalement,
--
Albert.
next prev parent reply other threads:[~2015-10-19 5:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-17 21:06 [U-Boot] [PATCH v3 0/8] arm: Tidy up early init Simon Glass
2015-10-17 21:06 ` [U-Boot] [PATCH v3 1/8] Move board_init_f_mem() into a common location Simon Glass
2015-10-17 21:06 ` [U-Boot] [PATCH v3 2/8] board_init_f_mem(): Don't require memset() Simon Glass
2015-10-18 16:28 ` Albert ARIBAUD
2015-10-18 20:38 ` Simon Glass
2015-10-19 5:21 ` Albert ARIBAUD
2015-10-17 21:06 ` [U-Boot] [PATCH v3 3/8] board_init_f_mem(): Don't create an unused early malloc() area Simon Glass
2015-10-17 21:06 ` [U-Boot] [PATCH v3 4/8] arm: Switch aarch64 to using generic global_data setup Simon Glass
2015-10-17 21:06 ` [U-Boot] [PATCH v3 5/8] arm: Switch 32-bit ARM " Simon Glass
2015-10-17 21:06 ` [U-Boot] [PATCH v3 6/8] microblaze: Add a TODO to call board_init_f_mem() Simon Glass
2015-10-17 21:07 ` [U-Boot] [PATCH v3 7/8] zynq: Move SPL console init out of board_init_f() Simon Glass
2015-10-18 16:36 ` Albert ARIBAUD
2015-10-18 20:37 ` Simon Glass
2015-10-19 5:15 ` Albert ARIBAUD [this message]
2015-10-17 21:07 ` [U-Boot] [PATCH v3 8/8] Revert "ARM: zynq: disable CONFIG_SYS_MALLOC_F to fix MMC boot" Simon Glass
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151019071519.2aa26c7c@lilith \
--to=albert.u.boot@aribaud.net \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox