Hi Vasili, On 4 May 2015 at 10:21, Vasili Galka <vvv...@gmail.com> wrote: > > Hi Simon, > > On Thu, Apr 30, 2015 at 3:38 AM, Simon Glass <s...@chromium.org> wrote: >> >> Hi Vasili, >> >> On 29 April 2015 at 10:57, Vasili Galka <vvv...@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.
From memory I think I did test it locally but did not send patches to enable it. You will need to enable DEBUG_UART_NS16550, and supply suitable values for DEBUG_UART_BASE and DEBUG_UART_CLOCK. But the debug UART code (in ns16550.c) is really simple so it should not be possible to debug it. I think it would be good to have the DEBUG_UART_... options in the board's defconfig file, even though CONFIG_DEBUG_UART itself is disabled. Then people can enable it easily when they want to use the debug UART. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
