On 12/14/2012 01:40 PM, Tom Rini wrote:
On 12/13/12 16:51, Simon Glass wrote:
[snip]
And from there we can move on and say "On ${SoC} we get a device tree (that we can't quite parse as we don't have enough resources) AND $some-data (OMDATA or an abbreviated device tree or $whatever), lets translate that into something we can make use of very early rather than a hard-coded initial console location"
It seems like you're saying that once we have dynamic serial port assignment working based on DT, you'll be fine using ODMDATA to initialize the early console, but not before then? If so, I'm having a hard time understanding why enabling the DT-based support blocks using ODMDATA, since the code would be pretty orthogonal.
Yes well dynamic console selection sounds find to me, ODMDATA or otherwise. To me it is a Tegra feature that should be supported as such. Perhaps we can allow the FDT console alias to specify "odmdata" to mean that, and/or (as you suggest I think) set the console to USE_ODMDATA, which then selects CONFIG_SYS_NS16550_COMx accordingly.
There's two parts to it. One part is that sure, Tegra and only Tegra has ODMDATA. But on am33xx if we poke the i2c eeprom (on platforms that do the eeprom) we can then know ... And I bet other SoCs have other tricks for this or that. So it's not just tegra that can tell us the initial console is $here or $there if we just ...something.
That's certainly true.
I personally view the method of retrieving this kind of information as part of an SoC's boot architecture, or as part of a board's design. As you have mentioned above, different SoCs/boards already have mechanisms to represent/determine this information. These mechanisms are already in-place and defined by the SoC or board designers.
The other part is, take a look at the Allwinner thread from a week or so ago. We really need to define how we want early board specific data to come in because if we start saying we'll accept per-SoC solutions we'll be drowning in them in short time. We want to say here's our preferred way to pass this information in.
I don't understand why you think U-Boot is in a position to mandate that the existing solutions that are already in place are incorrect, and must be replaced with some alternative.