Hi Stephen,
On Fri, Dec 14, 2012 at 2:03 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 12/14/2012 02:14 PM, Simon Glass wrote:
Hi Tom,
On Fri, Dec 14, 2012 at 12:40 PM, Tom Rini trini@ti.com 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.
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.
Yes there is a general problem to be solved here. Assuming that the problem is solved in U-Boot itself with device tree, then:
- It would be nice to keep a single source for this information
so that SPL and U-Boot are consistent. Where we invent a new mechanism for efficiency reasons it would be best if there was a 1-1 mapping from device tree to this new mechanism.
Many (most, I assume) U-Boot builds don't use device tree at all (yet?). I'm not sure we should tie any new mechanism for low-level boot information into device tree, since that severely limits where it can be used.
Perhaps I can make the point another way. Assuming that the SOC in question is ARM-based and has Linux support it either supports FDT now or presumably will fairly soon. We found that some of the things we want to know about at the low level are hardware properties that are already sit in a node in the FDT. For example the memory controller may have information about the memory type attached to it.
Given this, my suggestion is that this hardware information be kept in one place (FDT) where possible, even if it unfortunately temporarily needs to be translated into some simpler format as part of the SPL build for efficiency reasons.
As to platforms that support FDT, that is true, only a few. Adding basic support for a new board is very easy though.
But looking at your comments below, I worry that this might be a sledgehammer to crack a nut. As I understand it, you really just have a 32-word which selects the console UART and a few other things. It seems like you solved that problem a few emails back.
- It would be nice if we could write a simple tool which is
generic across architectures and configures an SPL given a device tree file. I'm not sure if that is a problem worth solving or not.
I'm not sure the information is generic enough to even represent in device tree, or that it even makes sense to do so.
After all, what the Tegra ODMDATA2 fields are representing is pinmux setup. Every piece of hardware does pinmux differently; at the very least, the pin IDs and available mux selection options are different. Some SoCs mux pins individually, some in groups. Sometimes more than just mux options must be selected. Some SoCs don't need pinmux. Some SoCs would allow the data to be embedded into some boot flash in a SoC-defined manner, whereas other SoCs' boards might require reading GPIOs, I2C EEPROMs, ... to get the information, etc. All this means that the information required, and the format needed to represent it, really is different in every case. The only way to avoid this would be to retro-actively redesign every SoC and board to always have the same requirements for what data needs to represent the UART selection process, and implement in the same way. That's obviously impossible to do, and so having any kind of remotely generic tool to handle the representation of this data also seems quite impossible.
- From the SPL point of view, the less code required to get at
the information, the better.
For one possible solution, see:
arch/arm/include/asm/arch-exynos/spl.h
A certain amount of that information duplicates what's in the Tegra BCT, which is essentially part of the HW itself, since it's handled by the non-modifiable boot ROM code. I really don't think U-Boot should be mandating some data structure that requires duplication of information that's already present.
No certainly not. But I think Tom is concerned that each SOC will do it differently and we might end up with a mess. SPL configuration is a slightly different problem to what you talk about here, but in a sense the BCT is an SOC-specific binary config blob attached to SPL. Other SOCs might do a similar thing but in their own format and in their own tools. Is it possible to unify these at all? Perhaps not?
Regards, Simon