Hi Tom,
On Fri, Dec 14, 2012 at 12:40 PM, Tom Rini trini@ti.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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:
1. 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.
2. 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.
3. 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
Basically it works (for a small number of parameters) by giving each a letter, and listing the required parameters in the structure. An external tool can then fairly easily fill in the values it needs from the device tree, without worrying about the format being wrong, etc.
I'm not sure that it scales to all SOCs though.
Personally I would like to see the simplest option possible and avoid inventing a new infrastructure just for SPL.
Regards, Simon
Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQy47RAAoJENk4IS6UOR1W/wIP/1CyXg8ShiITZAS6/R52Aj89 X7mhTHWUg3m+BtEN8TGkI8foznHjpv5JK7Exlf8XgKuoH6idBYd/5eF6nRXGfePY rQAad+hHeBYSBfvaP6GIaSTMm5x6KDMILExDkxue0mNcdkRL568ac0oR/HsVPM/N d75PVHsK77dAIzm9DbT3m2zilHC6balbplG1LtnKx0+sKb/PGpfXT5GYCZUUc9es R2Uzkyx+f25ZTlVRzdrh+h8SDhNzuACszJtqY11SxhLUZevvkja0jm6LykBsyJGH wh1wydRRPN6LKWRVQgUAHBJBEebf6Olck+PPBBA3+LypN5kSuj+bKixoyNxTQHIf E8qJb59rB7bnXLVb43AudcbUWe/PqdwZ8Yha3dmMrT/r8k0eXfNLBXlIP8BDXPis 4ssoH/DZXqv0+QvsmX+NPoF/3pBSy/Uc1g13w20xbdy12ovGEVgOWwioOPKgWgCR b34CvOT7MR+8zMixCHP287ITyTrpY/K7gxo2rF8EQ+o6QW1JCphTJFpVqlTVWEAT 5vPMnt7y7w9WtImCxUpa7itMfeVOgnbv+2bB2Ipxj6VjOZcIvdqB405wN39bGYux fzatCFurtbdaSQ7aFR1ZFRp51rjl/rC7QxODD0H84Ip7AbVO2qLPOTri2wwYfaPN EXPCI+T8YtDbI2/RW92B =DR6s -----END PGP SIGNATURE-----