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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot