Dear Simon,
In message CAPnjgZ1TBN+Ro8f0nDubAYRi54UAV0LxjrdFz-AW5qBgue1+Fw@mail.gmail.com you wrote:
Please make up your mind: either you CAN initialize the console, then you can use it to output messages in a regular way, or you CANNOT initialize it, in which case you cannot print anything. There is no third option.
Well that is very clear - we cannot. We hit panic() before console_ready() is called.
OK - but this means that no output to a serial console port can be done, no matter what you try.
If you have "available UARTs", you could use this as console, right?
Yes, if we knew which it was.
This is a design issue. If there are several similar boards that shall be handled with the same binary, then you must agree on some common sub-set of features, like on UART port that is available on all of these, and use this as (early) console port.
We know we won't get to console init in this case - there is a panic() that happens first. So the existing pre-console putc() becomes our route to displaying a message. The problem with that is only that the
No. When you cannot initialize the console, you cannot output anything to the console. Period.
If there is a way to do some initialization and output charatcers, than make this your regular console init code, and use it always, without any special warts.
board init hasn't happened yet, so either the pre-console putc() must init the UARTs or we need a separate init function.
This makes no sense to me.
So the existing pre-console putc() can be used, if we can sort out how to make UART init work. Graeme suggested an approach here - I will see if I can make that work.
I don't think I will accept any "pre-console putc()". This is such a dirty hack. Either you can initialize and use putc, then use the normal console mechanism for it, or you cannot. And "cannot" means "cannot" here.
Best regards,
Wolfgang Denk