| Message ID | 1338931225-12246-9-git-send-email-amartin@nvidia.com |
|---|---|
| State | Superseded |
| Headers | show |
On 06/05/2012 03:20 PM, Allen Martin wrote: > Add target for tegra20 u-boot image. This is a concatenation of tegra > spl and normal u-boot binaries. > diff --git a/board/nvidia/seaboard/config.mk b/board/nvidia/seaboard/config.mk > +PAD_TO=0x00108000 Oh crap, does this mean that we have to start flashing the combined u-boot.t2 at 0x8000 (IIRC the start address of the SPL in an earlier patch) instead of 0x108000? That would cause all kinds of problems. If that is the case, can we move the SPL to the existing 0x108000, and bump the regular U-Boot up a bit to make space? If that isn't the case, could you please explain exactly how the SPL memory layout etc. works for me? Thanks.
On Wed, Jun 06, 2012 at 09:48:23AM -0700, Stephen Warren wrote: > On 06/05/2012 03:20 PM, Allen Martin wrote: > > Add target for tegra20 u-boot image. This is a concatenation of tegra > > spl and normal u-boot binaries. > > > diff --git a/board/nvidia/seaboard/config.mk b/board/nvidia/seaboard/config.mk > > > +PAD_TO=0x00108000 > > Oh crap, does this mean that we have to start flashing the combined > u-boot.t2 at 0x8000 (IIRC the start address of the SPL in an earlier > patch) instead of 0x108000? That would cause all kinds of problems. If > that is the case, can we move the SPL to the existing 0x108000, and bump > the regular U-Boot up a bit to make space? If that isn't the case, could > you please explain exactly how the SPL memory layout etc. works for me? > Thanks. The addresses are arbitrary, I picked 0x8000 for the SPL to preserve the existing 0x108000 for the normal u-boot but it doesn't have to be that way. The only requirement is that the SPL needs to know the address of the normal u-boot at compile time because it doesn't have any smarts to look for it. I'll move the SPL to 0x108000 and the normal u-boot to 0x208000 if that sounds more acceptable. -Allen
On 06/06/2012 01:53 PM, Tom Warren wrote: > Allen, > >> -----Original Message----- >> From: Allen Martin [mailto:amartin@nvidia.com] >> Sent: Wednesday, June 06, 2012 12:37 PM >> To: Stephen Warren >> Cc: Tom Warren; sjg@chromium.org; u-boot@lists.denx.de >> Subject: Re: [PATCH v2 08/10] tegra20: add u-boot.t2 target >> >> On Wed, Jun 06, 2012 at 09:48:23AM -0700, Stephen Warren wrote: >>> On 06/05/2012 03:20 PM, Allen Martin wrote: >>>> Add target for tegra20 u-boot image. This is a concatenation of >>>> tegra spl and normal u-boot binaries. >>> >>>> diff --git a/board/nvidia/seaboard/config.mk >>>> b/board/nvidia/seaboard/config.mk >>> >>>> +PAD_TO=0x00108000 >>> >>> Oh crap, does this mean that we have to start flashing the combined >>> u-boot.t2 at 0x8000 (IIRC the start address of the SPL in an earlier >>> patch) instead of 0x108000? That would cause all kinds of problems. If >>> that is the case, can we move the SPL to the existing 0x108000, and >>> bump the regular U-Boot up a bit to make space? If that isn't the >>> case, could you please explain exactly how the SPL memory layout etc. >> works for me? >>> Thanks. >> >> The addresses are arbitrary, I picked 0x8000 for the SPL to preserve the >> existing 0x108000 for the normal u-boot but it doesn't have to be that way. >> The only requirement is that the SPL needs to know the address of the normal >> u-boot at compile time because it doesn't have any smarts to look for it. >> >> I'll move the SPL to 0x108000 and the normal u-boot to 0x208000 if that >> sounds more acceptable. > The current flash tools everyone is using expect to flash U-Boot to 0x0108000 (on T20). This works with the non-SPL (current) upstream U-Boot for Tegra, and should continue to work for any new SPL Tegra U-Boot, so that people can use the same flash tools for either build. > > Note that the above statement assumes we'll still be able to build either a 'normal' non-SPL build of Tegra U-Boot and a SPL build with your patchset, at least in the interim while we're testing/reviewing these major changes. I assume that once a board is converted to SPL, you always use a matched/concatenated pair of SPL+non-SPL, i.e. never SPL on its own or non-SPL on its own? But that does bring up one point - boards which haven't yet converted to SPL need to still build/link for the original 00108000 address, so the addresses need to depend on config data. Either that, or just convert all boards at once?
On Wed, Jun 06, 2012 at 12:57:05PM -0700, Stephen Warren wrote: > On 06/06/2012 01:53 PM, Tom Warren wrote: > >> > >> I'll move the SPL to 0x108000 and the normal u-boot to 0x208000 if that > >> sounds more acceptable. > > The current flash tools everyone is using expect to flash U-Boot to 0x0108000 (on T20). This works with the non-SPL (current) upstream U-Boot for Tegra, and should continue to work for any new SPL Tegra U-Boot, so that people can use the same flash tools for either build. > > > > Note that the above statement assumes we'll still be able to build either a 'normal' non-SPL build of Tegra U-Boot and a SPL build with your patchset, at least in the interim while we're testing/reviewing these major changes. > > I assume that once a board is converted to SPL, you always use a > matched/concatenated pair of SPL+non-SPL, i.e. never SPL on its own or > non-SPL on its own? Yes, that's the intention. Although I do have plans down the road for adding memory initialization to the SPL so I can use it for boot/flashing when in recovery mode and there's no BCT. In the normal case they have to be used together. > > But that does bring up one point - boards which haven't yet converted to > SPL need to still build/link for the original 00108000 address, so the > addresses need to depend on config data. > > Either that, or just convert all boards at once? I'll need to convert all the boards. Since I removed the Cortex A9 init from the normal u-boot it will no longer work for non SPL boot. I think that's what we want anyway, I just may need some help testing some of the boards I don't have. -Allen
On 06/06/2012 04:00 PM, Allen Martin wrote: > On Wed, Jun 06, 2012 at 12:57:05PM -0700, Stephen Warren wrote: >> On 06/06/2012 01:53 PM, Tom Warren wrote: >>>> >>>> I'll move the SPL to 0x108000 and the normal u-boot to 0x208000 if that >>>> sounds more acceptable. >>> The current flash tools everyone is using expect to flash U-Boot to 0x0108000 (on T20). This works with the non-SPL (current) upstream U-Boot for Tegra, and should continue to work for any new SPL Tegra U-Boot, so that people can use the same flash tools for either build. >>> >>> Note that the above statement assumes we'll still be able to build either a 'normal' non-SPL build of Tegra U-Boot and a SPL build with your patchset, at least in the interim while we're testing/reviewing these major changes. >> >> I assume that once a board is converted to SPL, you always use a >> matched/concatenated pair of SPL+non-SPL, i.e. never SPL on its own or >> non-SPL on its own? > > Yes, that's the intention. Although I do have plans down the road for > adding memory initialization to the SPL so I can use it for > boot/flashing when in recovery mode and there's no BCT. In the normal > case they have to be used together. How would that work; in the regular boot process, SPL would be linked to e.g. 00108000 since the boot ROM will put it into SDRAM. However, in recovery mode, code will be downloaded to the IRAM, so would have to be linked to a different address, and hence the same SPL binary couldn't be used. At that point, aren't we looking at: * Regular boot SPL, which just sets up a few PLLs and jump-starts the A9s. * Regular boot full-blown U-Boot to run on the A9s. * Some third build t run from IRAM. Or am I missing something?
On Wed, Jun 06, 2012 at 07:02:45PM -0700, Stephen Warren wrote: > On 06/06/2012 04:00 PM, Allen Martin wrote: > > Yes, that's the intention. Although I do have plans down the road for > > adding memory initialization to the SPL so I can use it for > > boot/flashing when in recovery mode and there's no BCT. In the normal > > case they have to be used together. > > How would that work; in the regular boot process, SPL would be linked to > e.g. 00108000 since the boot ROM will put it into SDRAM. However, in > recovery mode, code will be downloaded to the IRAM, so would have to be > linked to a different address, and hence the same SPL binary couldn't be > used. At that point, aren't we looking at: > > * Regular boot SPL, which just sets up a few PLLs and jump-starts the A9s. > * Regular boot full-blown U-Boot to run on the A9s. > * Some third build t run from IRAM. > > Or am I missing something? No, that's spot on, it's just that #3 and #1 above are very similar, only a few build/config tweaks should separate them. I've already hacked up an SPL to boot from IRAM as proof of concept and loaded it in recovery mode. But you're right, it has to be a separate build. -Allen
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.sb +/u-boot.t2 # # Generated files diff --git a/Makefile b/Makefile index b2275ed..6f4abc6 100644 --- a/Makefile +++ b/Makefile @@ -456,6 +456,16 @@ $(obj)u-boot.sb: $(obj)u-boot.bin $(obj)spl/u-boot-spl.bin elftosb -zdf imx28 -c $(TOPDIR)/board/$(BOARDDIR)/u-boot.bd \ -o $(obj)u-boot.sb +ifeq ($(CONFIG_OF_SEPARATE),y) +T2_UBOOT=$(obj)u-boot-dtb.bin +else +T2_UBOOT=$(obj)u-boot.bin +endif +$(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.bin + ifeq ($(CONFIG_SANDBOX),y) GEN_UBOOT = \ cd $(LNDIR) && $(CC) $(SYMS) -T $(obj)u-boot.lds \ @@ -775,6 +785,7 @@ clobber: tidy @rm -f $(obj)u-boot.ais @rm -f $(obj)u-boot.dtb @rm -f $(obj)u-boot.sb + @rm -f $(obj)u-boot.t2 @rm -f $(obj)tools/inca-swap-bytes @rm -f $(obj)arch/powerpc/cpu/mpc824x/bedbug_603e.c @rm -f $(obj)arch/powerpc/cpu/mpc83xx/ddr-gen?.c diff --git a/board/nvidia/seaboard/config.mk b/board/nvidia/seaboard/config.mk new file mode 100644 index 0000000..1d6e878 --- /dev/null +++ b/board/nvidia/seaboard/config.mk @@ -0,0 +1 @@ +PAD_TO=0x00108000
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> --- .gitignore | 1 + Makefile | 11 +++++++++++ board/nvidia/seaboard/config.mk | 1 + 3 files changed, 13 insertions(+) create mode 100644 board/nvidia/seaboard/config.mk