Hi Allen,
On Mon, Jun 11, 2012 at 12:22 PM, Allen Martin amartin@nvidia.com wrote:
On Sat, Jun 09, 2012 at 12:12:09PM -0700, Simon Glass wrote:
Hi Allen,
On Fri, Jun 8, 2012 at 2:16 PM, Allen Martin <amartin@nvidia.com<mailto:
amartin@nvidia.com>> wrote:
Add target for tegra20 u-boot image. This is a concatenation of tegra spl and normal u-boot binaries.
Signed-off-by: Allen Martin <amartin@nvidia.com<mailto:
amartin@nvidia.com>>
.gitignore | 1 + Makefile | 11 +++++++++++ board/nvidia/seaboard/config.mkhttp://config.mk | 1 + 3 files changed, 13 insertions(+) create mode 100644 board/nvidia/seaboard/config.mkhttp://config.mk
diff --git a/.gitignore b/.gitignore index 0f32fd8..b9192bf 100644 --- a/.gitignore +++ b/.gitignore @@ -39,6 +39,7 @@ /u-boot.ais /u-boot.dtb /u-boot.sbhttp://u-boot.sb +/u-boot.t2
What does t2 mean? If it is a binary file of some sort perhaps
u-boot-t2.bin would be better?
It's just means "tegra2". I was following the convention that other SPL builds use. I don't have a strong opinion on the name though.
OK, still would prefer a .bin on the end, but up to you.
+ifeq ($(CONFIG_OF_SEPARATE),y) +T2_UBOOT=$(obj)u-boot-dtb.bin +else +T2_UBOOT=$(obj)u-boot.bin +endif
What is this logic for? The dtb file is separate but that doesn't necessarily mean that it must be immediately after the U-Boot image. We provide other options for packaging it, like getenv(). Maybe if you want to create this composite binary you should change its name (u-boot-dtb-t2.bin or u-boot-t2.bin) to indicate what it contains?
This just picks up the name of the u-boot binary so it glues the SPL to the right thing depending if devicetree is in use or not.
OK, to avoid confusion I think you should change the name to include the -dtb or not, rather than having a filename without the -dtb part which does in fact include a dtb.
+$(obj)u-boot.t2: $(obj)spl/u-boot-spl.bin $(T2_UBOOT)
$(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary$(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
cat $(obj)spl/u-boot-spl-pad.bin $(T2_UBOOT) >$(obj)u-boot.t2
rm $(obj)spl/u-boot-spl-pad.binI echo Stephen's comments. But also SPL is supposed to load U-Boot, so shouldn't this t2 binary do that?
The t2 binary is the SPL and u-boot concatenated together into one binary. The whole thing will get loaded into memory by the tegra BootROM. The SPL knows the address of the real u-boot at compile time and uses that as the address for the Cortex A9 to jump to when it comes out of reset.
OK I see, makes sense. I am interested in your comments as to whether we might move to a 'true SPL' later, where U-Boot is actually loaded by SPL.
-Allen
nvpublic
Regards, Simon