On Mon, Jul 15, 2013 at 04:52:51PM +0200, Koen Kooi wrote:
Op 15 jul. 2013, om 16:49 heeft Tom Rini trini@ti.com het volgende geschreven:
On Mon, Jul 15, 2013 at 02:16:50PM +0200, Koen Kooi wrote:
Op 15 jul. 2013, om 14:11 heeft Nishanth Menon nm@ti.com het volgende geschreven:
For folks not using concatenated device tree with uImage, having an handy function to find and load device tree is very handy.
So introduce findfdt and loadfdt and run findfdt by default to make it easier on user scripts.
Signed-off-by: Nishanth Menon nm@ti.com
V3: Fixes typo mistake reported in http://marc.info/?t=137358212300006&r=1&w=2
include/configs/omap3_beagle.h | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index bdeee17..5ec8ade 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -210,6 +210,8 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ "loadaddr=0x80200000\0" \ "rdaddr=0x81000000\0" \
- "fdt_high=0xffffffff\0" \
- "fdtaddr=0x80f80000\0" \ "usbtty=cdc_acm\0" \ "bootfile=uImage\0" \ "ramdisk=ramdisk.gz\0" \
@@ -250,6 +252,17 @@ "omapdss.def_disp=${defaultdisplay} " \ "root=${nandroot} " \ "rootfstype=${nandrootfstype}\0" \
- "findfdt=" \
"if test $beaglerev = AxBx; then " \"setenv fdtfile omap3-beagle.dtb; fi; " \"if test $beaglerev = Cx; then " \"setenv fdtfile omap3-beagle.dtb; fi; " \"if test $beaglerev = xMAB; then " \"setenv fdtfile omap3-beagle-xm.dtb; fi; " \"if test $beaglerev = xMC; then " \"setenv fdtfile omap3-beagle-xm.dtb; fi; " \"if test $fdtfile = undefined; then " \"echo WARNING: Could not determine device tree to use; fi; \0" \With the remote chance of a future xM rev D, can you make the fallthrough be 'omap3-beagle-xm.dtb' intead of 'undefined'?
I don't like that idea. On am335x_evm configs we have undefined and then say "hey, it's undefined!" so it's clear that we don't know what to do. That in theory future xM rev D might need a different device tree for example.
And that's patched out on the build that actually ships with the beaglebone and beaglebone black so it will fall back to BBB when it can't ID the board. You'll see that the u-boot bits that need the ID for the xM also fallback to the latest rev. I don't see why the boardfile and script need to have different behaviour.
Yes, I'm not terribly happy with what gets done for the shipping U-Boot on BBB, but I understand you're trying to not have too special of a binary used in programming versus distribution of the board. If the vendor wants to ship software that says "when in doubt, it's likely this board", that's OK for the vendor to do.