Dear Simon Glass,
In message CAPnjgZ0jYpHSNG354=f4mDVJ0TT5-6jDCxpEG1Y70v5dwbYxkQ@mail.gmail.com you wrote:
I agree - The board designer should specify a 'default' debug port which is used for all character output prior to the 'configured' console port being initialised.
We can provide that, but if it is wrong for the board we are using,
Then your board configuration is wrong and needs to be fixed.
We cannot select the UART via CONFIG - remember that all of these boards have the same U-Boot binary. Please read that again :-) The device tree is the only thing that distinguishes them. All of the CONFIG options are identical for all boards.
This is conceptually broken.
If you cannot define a common UART port as debug console, and if there is no other way to find out what the console port should be (*), you must either use static board-specific configuration, or you must accept the fact that there is no console output in certain error situations.
The longer I read about this the less I feel willing to accept warts in the code trying to handle this.
This Tegra code is starting to annoy me.
We have standard ways of telling the Linux kernel what the console port is - the "console=" boot argument has been working fine for many, many years and many, many boards and systems. But Tegra needs to invent it's own hackinsh implementation of putting special data in some special registers. What a crap.
We have a pretty clean concept of dealing with console output for more a decade. Everybody uses it, without any significant problems. The Tegra comes and submits more and more obscure code to fix it's home-made problems.
I don't want to have that. I got better things to do than reading these patches again and again. I don't even see that we are converging on some acceptable solution.
To bring this to a constructive end:
It appears that all you are trying here is an annoying, but somewhat unlikely error situation. As marked above (see *), it might make sense to think of alternative ways to find out what the console port might be. One possibility to do this is to use the environment. You need access to the environment anyway to initialize the console port (for reading the "baudrate" setting). So why not encoding the console UART port for example as part of a "hwconfig" setting? This setting could be auto-initialized when you load a DT on this board (eventually after verifying that it works).
OK, there is still a chance that the environment settings are missing or incorrect _and_ the DT cannot be loaded, but the probability for such a double-fault is much, much smaller.
Could this be an acceptable solution for you?
Best regards,
Wolfgang Denk