Hi Stephen, On Thu, Dec 13, 2012 at 1:07 PM, Stephen Warren <swar...@wwwdotorg.org> wrote: > On 12/13/2012 01:53 PM, Tom Rini wrote: >> On 12/13/12 15:45, Stephen Warren wrote: >>> On 12/13/2012 01:36 PM, Wolfgang Denk wrote: >>>> Dear Stephen Warren, >>>> >>>> In message <50ca1bb8.4000...@wwwdotorg.org> you wrote: >>>>> >>>>>> Arghh... Do we really, really have to invent yet another >>>>>> way to pass hardware configuration information? Especially >>>>>> one totally incompatible to any other system? >>>>> >>>>> This is a special case for the console UART. The idea is to >>>>> get that up and running well before device tree is parsed in >>>>> any way. For example, Tegra's SPL doesn't touch the device >>>>> tree in any way (or even know one exists) but does want to >>>>> print (possibly error) messages in a generic fashion. >>>>> Similarly, many problems could occur before the device tree >>>>> is parsed (e.g. the user forgets to provide one...), and >>>>> having specifically the console UART set up before that >>>>> allows those errors to be reported, rather than requiring a >>>>> JTAG or similar debugger. >>>>> >>>>> My intent is that ODMDATA will definitely only be used for >>>>> the console UART, and will NOT be used for anything else like >>>>> LCD, RTC, ... Those other devices will certainly be >>>>> configured via device tree. >>>> >>>> We've been there before, you know. >> >>> I'm not quite sure what the implication is here. >> >>>> OK - what is the scope of visibility of such code? Will it be >>>> strictly board specific only? Or SoC specific? Arch? Global? >> >>> It's partially SoC-specific, partially global. >> >> Right. I see what Wolfgang was saying before, and I get it now. >> This is not how we want to open the can of worms for "lets do >> dynamic locations of stuff". We should start with being able to >> parse (some form of the normal) device tree, and be able to say "I >> now know I have a UART $HERE and $THERE". > > So if Tegra were to statically define the location of all 5 on-SoC > UARTs, by defining CONFIG_SYS_NS16550_COM*, and then use the ODMDATA > to select which UART to use for the console, rather than using the > ODMDATA to dynamically change the value that CONFIG_SYS_NS16550_COM1 > sets up, would that remove the objection? I haven't look into coding > that up, but I imagine it could be made to work...
Seems good to me. > >> And yes, that's too late for initial console being in the right >> spot, at first, probably. But now we've moved in the direction of >> being able to dynamically assign things. > > I'm not sure about "at first"; on Tegra, I don't imagine the SPL would > ever use device tree. The only HW- (board-) specific thing that's > relevant to it is the UART and UART-pinmux, since the SPL only exists > to boot the main A9 cores, and doesn't ever access any kind of storage > device. On Tegra, yes. On some chips, SPL accesses devices to read U-Boot. In extremis we could use a very simple table (a C structure with a couple of members) which is filled in by a tool from the device tree as part of image creation, just to avoid the FDT overhead. However, given that many of the SOCs I seem to be using have >100KB of SRAM, it's not clear that we shouldn't just use FDT eventually. > >> 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. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot