Patchwork [U-Boot,v2,08/10] tegra20: add u-boot.t2 target

login
register
mail settings
Submitter Allen Martin
Date June 5, 2012, 9:20 p.m.
Message ID <1338931225-12246-9-git-send-email-amartin@nvidia.com>
Download mbox | patch
Permalink /patch/163165/
State Superseded
Headers show

Comments

Allen Martin - June 5, 2012, 9:20 p.m.
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
Stephen Warren - June 6, 2012, 4:48 p.m.
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.
Allen Martin - June 6, 2012, 7:37 p.m.
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
Stephen Warren - June 6, 2012, 7:57 p.m.
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?
Allen Martin - June 6, 2012, 10 p.m.
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
Stephen Warren - June 7, 2012, 2:02 a.m.
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?
Allen Martin - June 7, 2012, 5:06 p.m.
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

Patch

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