Hi Graeme,
On Sun, Dec 4, 2011 at 7:40 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon,
On Mon, Dec 5, 2011 at 2:34 PM, Simon Glass sjg@chromium.org wrote:
Hi Stefan,
On Sun, Dec 4, 2011 at 10:56 AM, Stefano Babic sbabic@denx.de wrote:
On 02/12/2011 19:16, Simon Glass wrote:
It actually started as a last-ditch panic message printer. It morphed into the general pre-console putc after discussions on the list (with Graeme).
It can happen that your early board code does not know what clocks to use, or can't find a console, or some other critical error. It then calls panic() which silently dies or maybe reboots if you are lucky. This problem mostly comes about with device trees, where we must have certain info in the device tree before we can even get to relocation.
The idea is that boards provide a way of outputting characters which tries to work on all types of boards with that SOC. For example, they output the characters on all UARTs with various clock options, etc.
We use it on Tegra to print a friendly panic message when something is horribly wrong. In this case we will never make it to relocation so the pre-console buffer will not be displayed. So we can't rely on that.
I do not know if this mechanism can be used on other SOCs, but IMHO it does not hurt and it helps at least on Tegra, as you explained me.
Applied to u-boot-staging, sbabic@denx.de branch
Thanks. I think it can be used on any SOC with internal UARTs and a reasonably small list of permitted clock speeds. I suspect I will be trying it out on a few before long.
Can it be used in conjuction with PRE_CONSOLE_BUFFER? i.e. panic() prints the contents of the PRE_CONSOLE_BUFFER before the panic message? I think that would be invaluable in determining what was happening leading up to the panic
It could have been when it was still a pre-console panic. But now that it has morphed into a general putc(), I suppose the only option is to somehow detect the first call and send the pre-console text first?
Regards, Simon
Regards,
Graeme