[U-Boot] AM335x configurations - console output at early stages lost

[Vasili Galka]

Hi Simon,

On Thu, Apr 30, 2015 at 3:38 AM, Simon Glass <sjg at chromium.org> wrote:

> Hi Vasili,
>
> On 29 April 2015 at 10:57, Vasili Galka <vvv444 at gmail.com> wrote:
> > Hi Tom,
> >
> > I’m working on rebasing an old U-Boot branch for our company’s AM335x
> > based board upon the current U-Boot release (v2015.04). Our branch was
> > initially based on the v2013.10 release (the ti/am335x/ board was
> > taken as reference).
> >
> > After making all the code compile, I discovered there was a change in
> > the U-Boot initialization sequence, introduced by commit
> > a6b541b09022acb6f7c2754100ae26bd44eed1d9, that prevents our code from
> > working:
> >
> > Prior to the above mentioned commit, the console serial port was
> > initialized at a very early stage in the armv7/am335x/board.c:s_init()
> > function (calling preloader_console_init()). Roughly saying, it was
> > the first thing done by the SPL code. This made quite much sense, as
> > it enabled all the code afterwards to output status/debugging info to
> > the console.
> > Moving the preloader_console_init() call to spl_board_init() caused it
> > to be run at a very "late" stage (as part of the board_init_r()
> > function). AFAIU, now all the code that runs till then has no ability
> > for any console output.
> > For example, in our particular case, the DDR configuration code (in
> > sdram_init()) reads the DDR type from an I2C EEPROM. Obviously, if
> > something goes wrong in this process, we would like to report it to
> > the console.
> >
> > I understand there was a good reason for the mentioned commit (the
> > GD), however, as you see, we have also lost some important
> > functionality with it. I would appreciate your advice on how to solve
> > it.
>
> It would certainly be very useful and it would be great if we could
> printf() from as soon as we have a stack (and perhaps printch() even
> earlier). I think it can be done, but I have not put in the time to
> figure it out.
>
> You could take a look at CONFIG_DEBUG_UART which at least allows
> primitive UART access before gd is set up. I wonder if we could do
> something like change printf() /purchatr() to use this when gd is
> NULL?
>
> Regards,
> Simon
>

Thanks for the suggestion! I'm attempting to make it work.
Was the "Debug UART" code (added in
21d004368fc8a4da07147c58dfe9a4e16d4ab761) ever tested on AM335x? It does
not seem to work for me, I'm currently debugging in attempt to understand
the cause.

Regards,
Vasili