Patchwork Adding board support

login
register
mail settings
Submitter Stephen Warren
Date Oct. 14, 2011, 7:20 p.m.
Message ID <74CDBE0F657A3D45AFBB94109FB122FF173BE1A33E@HQMAIL01.nvidia.com>
Download mbox | patch
Permalink /patch/119909/
State New, archived
Headers show

Comments

Stephen Warren - Oct. 14, 2011, 7:20 p.m.
Thierry Reding wrote at Friday, October 14, 2011 12:59 PM:
> * Stephen Warren wrote:
> > Thierry Reding wrote at Thursday, October 13, 2011 11:50 PM:
...
> > > Another question concerns testing. So far I've always booted a modified
> > > U-Boot (from Vibrante 1.1) to allow booting with an initial ramdisk (loaded
> > > from SD/MMC) as payload for fastboot/quickboot. What are other people using?
> >
> > Personally, I've recently switched to using mainline U-Boot on almost all my
> > boards (Harmony, Seaboard, Ventana). Maybe I'll add TrimSlice support there
> > too. Note that this relies on a number of patches that have been posted to
> > the U-Boot mailing list, but not yet checked into their repos. This completely
> > bypasses fastboot; Tegra's boot ROM runs U-Boot directly instead of fastboot.
> 
> I was hoping that somebody had gotten this to work. Would you mind sharing
> the script that you use? All the scripts I've seen so far create some boot
> image (using a tool named mkbootimg) that contains U-Boot.
> 
> U-Boot mainline support is another point on my TODO list. Getting the latest
> mainline code with the patches you mention (I assume you are referring to the
> patch series by Simon Glass and Tom Warren) to work would be a good step in
> that direction.

I branched from: git://git.denx.de/u-boot.git master at commit
0841ca90f22d73b0ea4642ef1ce33d879bb2f3ff.

I applied the following:

http://patchwork.ozlabs.org/patch/115862/
http://patchwork.ozlabs.org/patch/115864/
http://patchwork.ozlabs.org/patch/115865/
http://patchwork.ozlabs.org/patch/115860/
http://patchwork.ozlabs.org/patch/115863/
http://patchwork.ozlabs.org/patch/115861/

http://patchwork.ozlabs.org/patch/119321/
http://patchwork.ozlabs.org/patch/119322/
http://patchwork.ozlabs.org/patch/119323/
http://patchwork.ozlabs.org/patch/119324/
http://patchwork.ozlabs.org/patch/119325/

http://patchwork.ozlabs.org/patch/118184/

I applied the following to hack the default environment so I could boot from
SD cards layed out how mine are; you'll probably need to tweak this a bunch:


In order to actually use the resultant u-boot.bin, it's pretty simple if you
already have nvflash working with burn fastboot.

1) Edit flash.cfg (or whatever config file you pass to nvflash to define
The partitions and their content) and replace the filename entry in the
EBT partition with u-boot.bin.

2) I personally remove all the partition entries in flash.cfg except for
BCT, PT, EBT. This will avoid nvflash flashing your Android/... filesystem.
If you want your filesystem in the same flash, don't do this.

Then, run nvflash just like you would normally.

> Have you done any testing with the NVIDIA binary blobs when booting this way?
> The latest information I have from our NVIDIA contacts is that fastboot or
> quickboot are required, for some reason, to make HW accelerated video
> decoding and 3D rendering work.

It's possible the binary drivers accidentally rely on the bootloader
having configured some piece of HW.

However, in general, the bootloader product you use shouldn't affect
whether the binary drivers work.

In particular, the binary drivers certainly work after the ChromeOS
U-Boot boots a board.

Coincidentally, right before seeing your email, I just tried mainline
U-Boot on Seaboard with our Linux4Tegra alpha 1 release, and while X
started, I couldn't see anything on screen. This did previously work
with some old version of ChromeOS's U-Boot. So, there's certainly some
missing HW initialization somewhere.

BTW, you might also want to take a look at NVIDIA's web forums:

http://developer.nvidia.com/beta-forum

While I'm personally happy to answer your questions here, (I work for
a group dedicated to making general Linux support on Tegra) you may find
more people aimed at this kind of support on those forums. I'm not
active on those forums though.

I hope this all helps!
Thierry Reding - Oct. 14, 2011, 11:24 p.m.
* Stephen Warren wrote:
> Thierry Reding wrote at Friday, October 14, 2011 12:59 PM:
> > * Stephen Warren wrote:
[...]
> > U-Boot mainline support is another point on my TODO list. Getting the latest
> > mainline code with the patches you mention (I assume you are referring to the
> > patch series by Simon Glass and Tom Warren) to work would be a good step in
> > that direction.
> 
> I branched from: git://git.denx.de/u-boot.git master at commit
> 0841ca90f22d73b0ea4642ef1ce33d879bb2f3ff.
> 
> I applied the following:
> 
> http://patchwork.ozlabs.org/patch/115862/
> http://patchwork.ozlabs.org/patch/115864/
> http://patchwork.ozlabs.org/patch/115865/
> http://patchwork.ozlabs.org/patch/115860/
> http://patchwork.ozlabs.org/patch/115863/
> http://patchwork.ozlabs.org/patch/115861/
> 
> http://patchwork.ozlabs.org/patch/119321/
> http://patchwork.ozlabs.org/patch/119322/
> http://patchwork.ozlabs.org/patch/119323/
> http://patchwork.ozlabs.org/patch/119324/
> http://patchwork.ozlabs.org/patch/119325/
> 
> http://patchwork.ozlabs.org/patch/118184/
> 
> I applied the following to hack the default environment so I could boot from
> SD cards layed out how mine are; you'll probably need to tweak this a bunch:
> 
> diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h
> index 07546a4..f30f569 100644
> --- a/include/configs/tegra2-common.h
> +++ b/include/configs/tegra2-common.h
> @@ -104,9 +104,19 @@
>  
>  /* Environment information */
>  #define CONFIG_EXTRA_ENV_SETTINGS \
> -       "console=ttyS0,115200n8\0" \
> -       "mem=" TEGRA2_SYSMEM "\0" \
> -       "smpflag=smp\0" \
> +       "bootcmd=run usb0_boot ; run usb1_boot ; run mmc1_boot ; run mmc0_boot\0" \
> +       "bootdelay=2\0" \
> +       "loadaddr=0x00500000\0" \
> +       "scriptaddr=0x408000\0" \
> +       "script_img=/u-boot/boot.scr.uimg\0" \
> +       "mmc0_boot=setenv devnum 0; run mmc_boot;\0" \
> +       "mmc1_boot=setenv devnum 1; run mmc_boot;\0" \
> +       "usb0_boot=usb start 0; run usb_boot;\0" \
> +       "usb1_boot=usb start 1; run usb_boot;\0" \
> +       "scr_boot=fatload ${devtype} ${devnum}:c ${scriptaddr} ${script_img};source ${scriptaddr};read ${devtype} ${devnum}:${kernelpart} ${scriptaddr} 0 10;source ${scriptaddr};\0" \
> +       "mmc_boot=mmc dev ${devnum};setenv devtype mmc;setenv devname mmcblk${devnum}p;run scr_boot;\0" \
> +       "usb_boot=setenv devtype usb;setenv devnum 0;setenv devname sda;run scr_boot;\0" \
> +       "platform_extras=lp0_vec=0x2000@0x1C406000 kcrashmem=0x100000@0x02000000 mem=384M@0M nvmem=128M@384M mem=511M@512M\0" \
>  
>  #define CONFIG_LOADADDR                0x408000        /* def. location for kernel */
>  #define CONFIG_BOOTDELAY       2               /* -1 to disable auto boot */
> 
> In order to actually use the resultant u-boot.bin, it's pretty simple if you
> already have nvflash working with burn fastboot.
> 
> 1) Edit flash.cfg (or whatever config file you pass to nvflash to define
> The partitions and their content) and replace the filename entry in the
> EBT partition with u-boot.bin.
> 
> 2) I personally remove all the partition entries in flash.cfg except for
> BCT, PT, EBT. This will avoid nvflash flashing your Android/... filesystem.
> If you want your filesystem in the same flash, don't do this.
> 
> Then, run nvflash just like you would normally.

Okay, I've been able to build U-Boot and setup some scripts that should
automate the nvflash procedure according to your instructions. I'll have to
wait until I get back to work on Monday to see whether it actually works,
though.

> > Have you done any testing with the NVIDIA binary blobs when booting this way?
> > The latest information I have from our NVIDIA contacts is that fastboot or
> > quickboot are required, for some reason, to make HW accelerated video
> > decoding and 3D rendering work.
> 
> It's possible the binary drivers accidentally rely on the bootloader
> having configured some piece of HW.
> 
> However, in general, the bootloader product you use shouldn't affect
> whether the binary drivers work.
> 
> In particular, the binary drivers certainly work after the ChromeOS
> U-Boot boots a board.
> 
> Coincidentally, right before seeing your email, I just tried mainline
> U-Boot on Seaboard with our Linux4Tegra alpha 1 release, and while X
> started, I couldn't see anything on screen. This did previously work
> with some old version of ChromeOS's U-Boot. So, there's certainly some
> missing HW initialization somewhere.

Right, I'll probably run into the same problems then. But if it can actually
make the system boot, it's enough to prepare some patches on top for mainline
support.

I've just caught up with most of my email backlog and I'm looking forward to
testing the device-tree support in U-Boot that's recently been posted.

> BTW, you might also want to take a look at NVIDIA's web forums:
> 
> http://developer.nvidia.com/beta-forum
> 
> While I'm personally happy to answer your questions here, (I work for
> a group dedicated to making general Linux support on Tegra) you may find
> more people aimed at this kind of support on those forums. I'm not
> active on those forums though.

I'm not a big fan of forums, but I guess I should check it out. A co-worker
has actually done more work with the binary drivers and I don't know how much
I will be involved there either, but I will make sure to pass the information
on.

> I hope this all helps!

Yes, very helpful indeed! Thanks again.

Thierry
Thierry Reding - Oct. 17, 2011, 10:26 a.m.
* Thierry Reding wrote:
> * Stephen Warren wrote:
> > Thierry Reding wrote at Friday, October 14, 2011 12:59 PM:
> > > * Stephen Warren wrote:
> [...]
> > > U-Boot mainline support is another point on my TODO list. Getting the latest
> > > mainline code with the patches you mention (I assume you are referring to the
> > > patch series by Simon Glass and Tom Warren) to work would be a good step in
> > > that direction.
> > 
> > I branched from: git://git.denx.de/u-boot.git master at commit
> > 0841ca90f22d73b0ea4642ef1ce33d879bb2f3ff.
> > 
> > I applied the following:
> > 
> > http://patchwork.ozlabs.org/patch/115862/
> > http://patchwork.ozlabs.org/patch/115864/
> > http://patchwork.ozlabs.org/patch/115865/
> > http://patchwork.ozlabs.org/patch/115860/
> > http://patchwork.ozlabs.org/patch/115863/
> > http://patchwork.ozlabs.org/patch/115861/
> > 
> > http://patchwork.ozlabs.org/patch/119321/
> > http://patchwork.ozlabs.org/patch/119322/
> > http://patchwork.ozlabs.org/patch/119323/
> > http://patchwork.ozlabs.org/patch/119324/
> > http://patchwork.ozlabs.org/patch/119325/
> > 
> > http://patchwork.ozlabs.org/patch/118184/
> > 
> > I applied the following to hack the default environment so I could boot from
> > SD cards layed out how mine are; you'll probably need to tweak this a bunch:
> > 
> > diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h
> > index 07546a4..f30f569 100644
> > --- a/include/configs/tegra2-common.h
> > +++ b/include/configs/tegra2-common.h
> > @@ -104,9 +104,19 @@
> >  
> >  /* Environment information */
> >  #define CONFIG_EXTRA_ENV_SETTINGS \
> > -       "console=ttyS0,115200n8\0" \
> > -       "mem=" TEGRA2_SYSMEM "\0" \
> > -       "smpflag=smp\0" \
> > +       "bootcmd=run usb0_boot ; run usb1_boot ; run mmc1_boot ; run mmc0_boot\0" \
> > +       "bootdelay=2\0" \
> > +       "loadaddr=0x00500000\0" \
> > +       "scriptaddr=0x408000\0" \
> > +       "script_img=/u-boot/boot.scr.uimg\0" \
> > +       "mmc0_boot=setenv devnum 0; run mmc_boot;\0" \
> > +       "mmc1_boot=setenv devnum 1; run mmc_boot;\0" \
> > +       "usb0_boot=usb start 0; run usb_boot;\0" \
> > +       "usb1_boot=usb start 1; run usb_boot;\0" \
> > +       "scr_boot=fatload ${devtype} ${devnum}:c ${scriptaddr} ${script_img};source ${scriptaddr};read ${devtype} ${devnum}:${kernelpart} ${scriptaddr} 0 10;source ${scriptaddr};\0" \
> > +       "mmc_boot=mmc dev ${devnum};setenv devtype mmc;setenv devname mmcblk${devnum}p;run scr_boot;\0" \
> > +       "usb_boot=setenv devtype usb;setenv devnum 0;setenv devname sda;run scr_boot;\0" \
> > +       "platform_extras=lp0_vec=0x2000@0x1C406000 kcrashmem=0x100000@0x02000000 mem=384M@0M nvmem=128M@384M mem=511M@512M\0" \
> >  
> >  #define CONFIG_LOADADDR                0x408000        /* def. location for kernel */
> >  #define CONFIG_BOOTDELAY       2               /* -1 to disable auto boot */
> > 
> > In order to actually use the resultant u-boot.bin, it's pretty simple if you
> > already have nvflash working with burn fastboot.
> > 
> > 1) Edit flash.cfg (or whatever config file you pass to nvflash to define
> > The partitions and their content) and replace the filename entry in the
> > EBT partition with u-boot.bin.
> > 
> > 2) I personally remove all the partition entries in flash.cfg except for
> > BCT, PT, EBT. This will avoid nvflash flashing your Android/... filesystem.
> > If you want your filesystem in the same flash, don't do this.
> > 
> > Then, run nvflash just like you would normally.
> 
> Okay, I've been able to build U-Boot and setup some scripts that should
> automate the nvflash procedure according to your instructions. I'll have to
> wait until I get back to work on Monday to see whether it actually works,
> though.

I'm unable to make this work. I've done as you said, branched from the commit
you mentioned and applied the patches you listed. Then ran:

	$ make CROSS_COMPILE=... O=build/harmony harmony_config
	$ make CROSS_COMPILE=... O=build/harmony -j8

And flashed the resulting u-boot.bin like you described, by replacing the
fastboot.bin in the configuration with u-boot.bin. When rebooting the device
(I used a Harmony for this testing obviously) there's nothing. No output on
the serial line. Flashing fastboot.bin I can at least see some debugging
output.

I also tried to update the TEXT_BASE, which seems to be 0x00108000 for
fastboot, and 0x00E08000 for U-Boot, but that didn't make a difference. Any
ideas on what could be the problem?

I'm not quite sure where these values come from. Are they hard-coded in the
boot ROM? And how does it know from which NAND partition to load the
bootloader?

Thanks,
Thierry
Stephen Warren - Oct. 17, 2011, 4:15 p.m.
Thierry Reding wrote at Monday, October 17, 2011 4:27 AM:
> * Thierry Reding wrote:
> > * Stephen Warren wrote:
> > > ... [U-Boot patch/build instructions]
> > > Then, run nvflash just like you would normally.
> >
> > Okay, I've been able to build U-Boot and setup some scripts that should
> > automate the nvflash procedure according to your instructions. I'll have to
> > wait until I get back to work on Monday to see whether it actually works,
> > though.
> 
> I'm unable to make this work. I've done as you said, branched from the commit
> you mentioned and applied the patches you listed. Then ran:
> 
> 	$ make CROSS_COMPILE=... O=build/harmony harmony_config
> 	$ make CROSS_COMPILE=... O=build/harmony -j8
> 
> And flashed the resulting u-boot.bin like you described, by replacing the
> fastboot.bin in the configuration with u-boot.bin. When rebooting the device
> (I used a Harmony for this testing obviously) there's nothing. No output on
> the serial line. Flashing fastboot.bin I can at least see some debugging
> output.
> 
> I also tried to update the TEXT_BASE, which seems to be 0x00108000 for
> fastboot, and 0x00E08000 for U-Boot, but that didn't make a difference. Any
> ideas on what could be the problem?

Ah yes, sorry, I'd forgotten about that.

The default load address for fastboot and U-Boot is different. I don't
know why, but apparently U-Boot doesn't work when built with a load
address that matches fastboot. I believe we have a bug filed to investigate
why, but I don't know any more details.

> I'm not quite sure where these values come from. Are they hard-coded in the
> boot ROM? And how does it know from which NAND partition to load the
> bootloader?

These addresses exist in a couple places:

* In the BCT, which tells the boot ROM the SDRAM address where the boot-
loader should be copied to, and what the entry point is.

* Hard-coded into nvflash, and the fastboot.bin used during the flashing
process.

Hence, internally, I believe we use nvflash/fastboot.bin that have been
specifically recompiled to support U-Boot's load address.

Thinking about this some more, I think we have shipped those rebuilt
versions outside NVIDIA in a publically accessible place. I'll follow
up internally and see if we have, or what we can do about it. Sorry for
sending you on a wild goose chase.
Thierry Reding - Oct. 20, 2011, 8:08 a.m.
* Stephen Warren wrote:
> Thierry Reding wrote at Monday, October 17, 2011 4:27 AM:
> > * Thierry Reding wrote:
> > > * Stephen Warren wrote:
> > > > ... [U-Boot patch/build instructions]
> > > > Then, run nvflash just like you would normally.
> > >
> > > Okay, I've been able to build U-Boot and setup some scripts that should
> > > automate the nvflash procedure according to your instructions. I'll have to
> > > wait until I get back to work on Monday to see whether it actually works,
> > > though.
> > 
> > I'm unable to make this work. I've done as you said, branched from the commit
> > you mentioned and applied the patches you listed. Then ran:
> > 
> > 	$ make CROSS_COMPILE=... O=build/harmony harmony_config
> > 	$ make CROSS_COMPILE=... O=build/harmony -j8
> > 
> > And flashed the resulting u-boot.bin like you described, by replacing the
> > fastboot.bin in the configuration with u-boot.bin. When rebooting the device
> > (I used a Harmony for this testing obviously) there's nothing. No output on
> > the serial line. Flashing fastboot.bin I can at least see some debugging
> > output.
> > 
> > I also tried to update the TEXT_BASE, which seems to be 0x00108000 for
> > fastboot, and 0x00E08000 for U-Boot, but that didn't make a difference. Any
> > ideas on what could be the problem?
> 
> Ah yes, sorry, I'd forgotten about that.
> 
> The default load address for fastboot and U-Boot is different. I don't
> know why, but apparently U-Boot doesn't work when built with a load
> address that matches fastboot. I believe we have a bug filed to investigate
> why, but I don't know any more details.
> 
> > I'm not quite sure where these values come from. Are they hard-coded in the
> > boot ROM? And how does it know from which NAND partition to load the
> > bootloader?
> 
> These addresses exist in a couple places:
> 
> * In the BCT, which tells the boot ROM the SDRAM address where the boot-
> loader should be copied to, and what the entry point is.
> 
> * Hard-coded into nvflash, and the fastboot.bin used during the flashing
> process.
> 
> Hence, internally, I believe we use nvflash/fastboot.bin that have been
> specifically recompiled to support U-Boot's load address.
> 
> Thinking about this some more, I think we have shipped those rebuilt
> versions outside NVIDIA in a publically accessible place. I'll follow
> up internally and see if we have, or what we can do about it. Sorry for
> sending you on a wild goose chase.

I've been working some on getting our boards to boot from a device tree.
Unfortunately, the U-Boot issue seems to be more of a problem than I
anticipated. Since the mainline U-Boot doesn't run properly, I was going to
use the one shipped with Vibrante. As it turns out, that version is rather
old and doesn't have proper DT support for ARM yet. So I tried to switch to
the Chromium tree in the meantime but I cannot get it to work either. Not
standalone and not with quickboot as stage1.

So I'm running a little out of options. I'm reluctant to backport complete DT
support to the Vibrante version and I'm a short on time anyway, so figuring
out why the Chromium tree won't boot is not really an option either.

Are there any news on these rebuilt versions of nvflash that you mentioned?

Thierry
Stephen Warren - Oct. 20, 2011, 4:01 p.m.
Thierry Reding wrote at Thursday, October 20, 2011 2:08 AM:
...
> I've been working some on getting our boards to boot from a device tree.
> Unfortunately, the U-Boot issue seems to be more of a problem than I
> anticipated. Since the mainline U-Boot doesn't run properly,

----------==========----------==========----------==========----------==========
What issues are you having? I assume you're referring to something more
than just getting stuff flashed with nvflash.

> Are there any news on these rebuilt versions of nvflash that you mentioned?

Sorry, not yet.
Thierry Reding - Oct. 20, 2011, 7:08 p.m.
* Stephen Warren wrote:
> Thierry Reding wrote at Thursday, October 20, 2011 2:08 AM:
> ...
> > I've been working some on getting our boards to boot from a device tree.
> > Unfortunately, the U-Boot issue seems to be more of a problem than I
> > anticipated. Since the mainline U-Boot doesn't run properly,
> 
> ----------==========----------==========----------==========----------==========
> What issues are you having? I assume you're referring to something more
> than just getting stuff flashed with nvflash.

Flashing U-Boot is not the problem, but when booting the device, there's no
output whatsoever on the debug port. That's what I meant in one of the
previous mails. nvflash says it's loading fastboot.bin at address 0x00108000,
and quickboot seems to use the same load address. However, U-Boot is built
with CONFIG_SYS_TEXT_BASE set to 0x00E08000. If it is loaded to the same
address as fastboot/quickboot it obviously cannot run. So I went ahead and
built U-Boot (both mainline and the one from the Chromium repo) with a load
address of 0x00108000 - to no avail.

I'm starting to think that perhaps I'm completely overlooking something
obvious. When I use the Vibrante U-Boot, I get normal U-Boot output on the
debug port when I flash it as stage 2 for quickboot. The other versions of
U-Boot don't work in that setup. None of the three versions boot when flashed
standalone (substituting u-boot.bin for fastboot.bin in the nvflash
configuration file). I would guess that at least with quickboot as stage 1 I
should be able to get serial output from the mainline U-Boot.

Would it be helpful to move the discussion to the U-Boot mailing list
instead? It's sort of off-topic here.

Thierry
Stephen Warren - Oct. 21, 2011, 8:13 p.m.
Thierry Reding wrote at Thursday, October 20, 2011 1:08 PM:
> * Stephen Warren wrote:
> > Thierry Reding wrote at Thursday, October 20, 2011 2:08 AM:
> > ...
> > > I've been working some on getting our boards to boot from a device tree.
> > > Unfortunately, the U-Boot issue seems to be more of a problem than I
> > > anticipated. Since the mainline U-Boot doesn't run properly,
> >
> > What issues are you having? I assume you're referring to something more
> > than just getting stuff flashed with nvflash.
> 
> Flashing U-Boot is not the problem, but when booting the device, there's no
> output whatsoever on the debug port. That's what I meant in one of the
> previous mails. nvflash says it's loading fastboot.bin at address 0x00108000,
> and quickboot seems to use the same load address. However, U-Boot is built
> with CONFIG_SYS_TEXT_BASE set to 0x00E08000. If it is loaded to the same
> address as fastboot/quickboot it obviously cannot run. So I went ahead and
> built U-Boot (both mainline and the one from the Chromium repo) with a load
> address of 0x00108000 - to no avail.

OK, I built U-Boot with load address 0x00108000 and also see nothing at boot.
So, I've reproduced at least one of your problems.

(This is with an Android-style nvflash that configures the BCT to tell the CPU
to load/boot the bootloader at address 0x00108000, so this should work.)

So, I've added this observation into the bug I filed. I'll let you know once
we've had a chance to investigate and/or solve this.

Sorry this isn't working yet; it's pretty early days for U-Boot on Tegra
outside of ChromeOS, which uses the modified nvflash and hence doesn't hit
these issues.
Thierry Reding - Oct. 25, 2011, 5:57 a.m.
* Stephen Warren wrote:
> Thierry Reding wrote at Thursday, October 20, 2011 1:08 PM:
> > * Stephen Warren wrote:
> > > Thierry Reding wrote at Thursday, October 20, 2011 2:08 AM:
> > > ...
> > > > I've been working some on getting our boards to boot from a device tree.
> > > > Unfortunately, the U-Boot issue seems to be more of a problem than I
> > > > anticipated. Since the mainline U-Boot doesn't run properly,
> > >
> > > What issues are you having? I assume you're referring to something more
> > > than just getting stuff flashed with nvflash.
> > 
> > Flashing U-Boot is not the problem, but when booting the device, there's no
> > output whatsoever on the debug port. That's what I meant in one of the
> > previous mails. nvflash says it's loading fastboot.bin at address 0x00108000,
> > and quickboot seems to use the same load address. However, U-Boot is built
> > with CONFIG_SYS_TEXT_BASE set to 0x00E08000. If it is loaded to the same
> > address as fastboot/quickboot it obviously cannot run. So I went ahead and
> > built U-Boot (both mainline and the one from the Chromium repo) with a load
> > address of 0x00108000 - to no avail.
> 
> OK, I built U-Boot with load address 0x00108000 and also see nothing at boot.
> So, I've reproduced at least one of your problems.
> 
> (This is with an Android-style nvflash that configures the BCT to tell the CPU
> to load/boot the bootloader at address 0x00108000, so this should work.)
> 
> So, I've added this observation into the bug I filed. I'll let you know once
> we've had a chance to investigate and/or solve this.
> 
> Sorry this isn't working yet; it's pretty early days for U-Boot on Tegra
> outside of ChromeOS, which uses the modified nvflash and hence doesn't hit
> these issues.

I was able to get my hands on the nvflash source code, so I may be able to
get this to work myself. Any hints as to what exactly was changed? Was it
only the load/entry address. You mention that nvflash configures the BCT; in
what way. A quick glimpse at the source code doesn't show any modifications
being done to the loaded BCT file.

On the other hand, since obviously the paperwork is okay to get the nvflash
sources, perhaps I could ask my NVIDIA contacts to provide the ChromeOS
variant of nvflash. Does it have a special name internally that I should
refer to?

Thierry
Thierry Reding - Oct. 27, 2011, 10:29 a.m.
* Stephen Warren wrote:
> Thierry Reding wrote at Thursday, October 20, 2011 1:08 PM:
> > * Stephen Warren wrote:
> > > Thierry Reding wrote at Thursday, October 20, 2011 2:08 AM:
> > > ...
> > > > I've been working some on getting our boards to boot from a device tree.
> > > > Unfortunately, the U-Boot issue seems to be more of a problem than I
> > > > anticipated. Since the mainline U-Boot doesn't run properly,
> > >
> > > What issues are you having? I assume you're referring to something more
> > > than just getting stuff flashed with nvflash.
> > 
> > Flashing U-Boot is not the problem, but when booting the device, there's no
> > output whatsoever on the debug port. That's what I meant in one of the
> > previous mails. nvflash says it's loading fastboot.bin at address 0x00108000,
> > and quickboot seems to use the same load address. However, U-Boot is built
> > with CONFIG_SYS_TEXT_BASE set to 0x00E08000. If it is loaded to the same
> > address as fastboot/quickboot it obviously cannot run. So I went ahead and
> > built U-Boot (both mainline and the one from the Chromium repo) with a load
> > address of 0x00108000 - to no avail.
> 
> OK, I built U-Boot with load address 0x00108000 and also see nothing at boot.
> So, I've reproduced at least one of your problems.
> 
> (This is with an Android-style nvflash that configures the BCT to tell the CPU
> to load/boot the bootloader at address 0x00108000, so this should work.)
> 
> So, I've added this observation into the bug I filed. I'll let you know once
> we've had a chance to investigate and/or solve this.
> 
> Sorry this isn't working yet; it's pretty early days for U-Boot on Tegra
> outside of ChromeOS, which uses the modified nvflash and hence doesn't hit
> these issues.

I've been able to make limited progress on this. I've been able to
successfully run a mainline U-Boot (c30a15e) with the patches you mentioned
previously applied on top. However, this currently only works as quickboot
payload. Standalone is not working yet. However this allows booting a
mainline kernel with device tree support. So while the nvflash issues are
sorted out, I have something I can get work done with.

Thierry
Stephen Warren - Oct. 27, 2011, 3:47 p.m.
Thierry Reding wrote at Monday, October 24, 2011 11:58 PM:
...
> I was able to get my hands on the nvflash source code, so I may be able to
> get this to work myself. Any hints as to what exactly was changed? Was it
> only the load/entry address. You mention that nvflash configures the BCT; in
> what way. A quick glimpse at the source code doesn't show any modifications
> being done to the loaded BCT file.
> 
> On the other hand, since obviously the paperwork is okay to get the nvflash
> sources, perhaps I could ask my NVIDIA contacts to provide the ChromeOS
> variant of nvflash. Does it have a special name internally that I should
> refer to?

FYI, I'm going to follow up with Thierry off-list, since any support for
nvflash source code isn't going to be useful to list users.
Stephen Warren - Nov. 9, 2011, 7:41 p.m.
Thierry Reding wrote at Thursday, October 20, 2011 1:08 PM:
> * Stephen Warren wrote:
> > Thierry Reding wrote at Thursday, October 20, 2011 2:08 AM:
> > ...
> > > I've been working some on getting our boards to boot from a device tree.
> > > Unfortunately, the U-Boot issue seems to be more of a problem than I
> > > anticipated. Since the mainline U-Boot doesn't run properly,
> >
> > What issues are you having? I assume you're referring to something more
> > than just getting stuff flashed with nvflash.
> 
> Flashing U-Boot is not the problem, but when booting the device, there's no
> output whatsoever on the debug port.

Just to close the loop on this in the mailing list archives, the issue is
now solved. The specific fix was to add "USE_PRIVATE_LIBGCC=yes" to the
make command used to build U-Boot. And just for the record (Thierry was
already trying this), CONFIG_SYS_TEXT_BASE must match those nvflash and
fastboot.bin expect, which is 0x00108000 for the binaries shipped with our
Linux4Tegra alpha 1 release.

Patch

diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h
index 07546a4..f30f569 100644
--- a/include/configs/tegra2-common.h
+++ b/include/configs/tegra2-common.h
@@ -104,9 +104,19 @@ 
 
 /* Environment information */
 #define CONFIG_EXTRA_ENV_SETTINGS \
-       "console=ttyS0,115200n8\0" \
-       "mem=" TEGRA2_SYSMEM "\0" \
-       "smpflag=smp\0" \
+       "bootcmd=run usb0_boot ; run usb1_boot ; run mmc1_boot ; run mmc0_boot\0" \
+       "bootdelay=2\0" \
+       "loadaddr=0x00500000\0" \
+       "scriptaddr=0x408000\0" \
+       "script_img=/u-boot/boot.scr.uimg\0" \
+       "mmc0_boot=setenv devnum 0; run mmc_boot;\0" \
+       "mmc1_boot=setenv devnum 1; run mmc_boot;\0" \
+       "usb0_boot=usb start 0; run usb_boot;\0" \
+       "usb1_boot=usb start 1; run usb_boot;\0" \
+       "scr_boot=fatload ${devtype} ${devnum}:c ${scriptaddr} ${script_img};source ${scriptaddr};read ${devtype} ${devnum}:${kernelpart} ${scriptaddr} 0 10;source ${scriptaddr};\0" \
+       "mmc_boot=mmc dev ${devnum};setenv devtype mmc;setenv devname mmcblk${devnum}p;run scr_boot;\0" \
+       "usb_boot=setenv devtype usb;setenv devnum 0;setenv devname sda;run scr_boot;\0" \
+       "platform_extras=lp0_vec=0x2000@0x1C406000 kcrashmem=0x100000@0x02000000 mem=384M@0M nvmem=128M@384M mem=511M@512M\0" \
 
 #define CONFIG_LOADADDR                0x408000        /* def. location for kernel */
 #define CONFIG_BOOTDELAY       2               /* -1 to disable auto boot */