Adding board support

Adding board support

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]

Hi,

I have two Tegra2 based boards that I would like to add mainline support to.
Currently they run on a modified NVIDIA kernel (Vibrante 1.1 for those who
know it), but I would very much like to have them eventually boot from a
mainline kernel. Both boards are rather similar to Harmony.

I have a couple of questions, though. From what I can tell, the only
functionality missing from mainline is nvmap/nvhost. While this is required
for our boards, I was looking for some remote that includes support. The only
source I came across was at git.chromium.org (kernel.git and
kernel-next.git). I suppose those are kernels that are recommended to run on
Tegra2 boards if HW-accelerated video decoding and 3D rendering is required,
right?

I guess for the time being, the best plan would be to work on two branches,
one based on the code from chromium and one based on the mainline code which
doesn't contain nvmap/nvhost and used to prepare patches for mainline. Which
branch or repository should I base such work on? Olof's for-3.2 branches?

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?
What tools should I be using to update the firmware? Unfortunately nvflash is
not available in source code, and I haven't found any documentation about the
early boot process, so it is kind of hard to figure out how all this is
supposed to work and consequently find ways to automate these things for
production boards.

I realize that some of these questions may be slightly off-topic here. If so,
would someone be so kind as to point me to the correct mailing list?

Thanks,
Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

RE: Adding board support

[Stephen Warren]

Thierry Reding wrote at Thursday, October 13, 2011 11:50 PM:
...
> I have a couple of questions, though. From what I can tell, the only
> functionality missing from mainline is nvmap/nvhost. While this is required
> for our boards, I was looking for some remote that includes support. The only
> source I came across was at git.chromium.org (kernel.git and
> kernel-next.git). I suppose those are kernels that are recommended to run on
> Tegra2 boards if HW-accelerated video decoding and 3D rendering is required,
> right?

There are also some NVIDIA kernel repos that contain this support; see:
http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=summary

I think our current Linux4Tegra releases do use the kernel from ChromeOS, but
future releases may move to our internal kernels.

> I guess for the time being, the best plan would be to work on two branches,
> one based on the code from chromium and one based on the mainline code which
> doesn't contain nvmap/nvhost and used to prepare patches for mainline. Which
> branch or repository should I base such work on? Olof's for-3.2 branches?

Just as an FYI, upstreaming nvmap/nvhost isn't a near-term goal. In the longer
term, we're starting to think about a solution here.

For practical purposes, you'll probably want to base any product kernels off
one of NVIDIA's various downstream branches. Given your Vibrante usage, it'd
probably be best to ask your existing NVIDIA contacts some of these questions.

However, please don't let that stop you upstreaming basic board support; you
should be able to upstream anything that doesn't depend on nvhost/nvmap etc.
You'll probably want to use device-tree exclusively for any new board support
in mainline.

> 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.

> What tools should I be using to update the firmware? Unfortunately nvflash is
> not available in source code, and I haven't found any documentation about the
> early boot process, so it is kind of hard to figure out how all this is
> supposed to work and consequently find ways to automate these things for
> production boards.

Try grabbing the Linux4Tegra packages from:
http://developer.nvidia.com/content/linux-tegra-release-12-alpha-1-released

at least that has a publically obtainable/usable nvflash for a few boards.
You should be able to adjust the flash.cfg files there for other boards.

It's a little early to say much, but there are some early movements towards
replacing nvflash with something more open for general Linux usage. You may
also want to look at the "cbootimage" tool here:

https://gitorious.org/cbootimage

-- 
nvpublic

Re: Adding board support

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 5139 bytes --]

Hi,

Thanks for taking the time to reply. This is *exactly* the kind of
information I'm looking for.

* Stephen Warren wrote:
> Thierry Reding wrote at Thursday, October 13, 2011 11:50 PM:
> ...
> > I have a couple of questions, though. From what I can tell, the only
> > functionality missing from mainline is nvmap/nvhost. While this is required
> > for our boards, I was looking for some remote that includes support. The only
> > source I came across was at git.chromium.org (kernel.git and
> > kernel-next.git). I suppose those are kernels that are recommended to run on
> > Tegra2 boards if HW-accelerated video decoding and 3D rendering is required,
> > right?
> 
> There are also some NVIDIA kernel repos that contain this support; see:
> http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=summary
> 
> I think our current Linux4Tegra releases do use the kernel from ChromeOS, but
> future releases may move to our internal kernels.

The kernel at the NVIDIA website seems to be close to what Vibrante ships
with. I'll have a closer look at it.

> > I guess for the time being, the best plan would be to work on two branches,
> > one based on the code from chromium and one based on the mainline code which
> > doesn't contain nvmap/nvhost and used to prepare patches for mainline. Which
> > branch or repository should I base such work on? Olof's for-3.2 branches?
> 
> Just as an FYI, upstreaming nvmap/nvhost isn't a near-term goal. In the longer
> term, we're starting to think about a solution here.

That's good news. :-)

> For practical purposes, you'll probably want to base any product kernels off
> one of NVIDIA's various downstream branches. Given your Vibrante usage, it'd
> probably be best to ask your existing NVIDIA contacts some of these questions.
> 
> However, please don't let that stop you upstreaming basic board support; you
> should be able to upstream anything that doesn't depend on nvhost/nvmap etc.
> You'll probably want to use device-tree exclusively for any new board support
> in mainline.

We'll have to stick to the Vibrante kernel while some issues are still being
worked out and I don't want to risk any differences in the kernel to
interfere.

However, in the meantime I would like to prepare some board support patches
for inclusion in the mainline kernel. My intention was indeed to use the
device-tree exclusively. Since both boards are rather similar to Harmony, it
will probably be easy to derive them from Harmony. I've been meaning to read
up on device-trees for a while and this looks to be the perfect opportunity.

> > 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.

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.

> > What tools should I be using to update the firmware? Unfortunately nvflash is
> > not available in source code, and I haven't found any documentation about the
> > early boot process, so it is kind of hard to figure out how all this is
> > supposed to work and consequently find ways to automate these things for
> > production boards.
> 
> Try grabbing the Linux4Tegra packages from:
> http://developer.nvidia.com/content/linux-tegra-release-12-alpha-1-released
> 
> at least that has a publically obtainable/usable nvflash for a few boards.
> You should be able to adjust the flash.cfg files there for other boards.
> 
> It's a little early to say much, but there are some early movements towards
> replacing nvflash with something more open for general Linux usage.

More good news.

> You may also want to look at the "cbootimage" tool here:
> 
> https://gitorious.org/cbootimage

That's great. Another missing piece of the puzzle. This seems to be the
open-source equivalent of another tool from Vibrante that allows to create
BCT files from "source" files (I've forgotten the name).

Thanks,
Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

RE: Adding board support

[Stephen Warren]

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:

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.

> 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!

-- 
nvpublic

Re: Adding board support

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 5622 bytes --]

* 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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: Adding board support

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 4779 bytes --]

* 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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

RE: Adding board support

[Stephen Warren]

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.

-- 
nvpublic

Re: Adding board support

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3324 bytes --]

* 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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

RE: Adding board support

[Stephen Warren]

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.

-- 
nvpublic

Re: Adding board support

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]

* 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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

RE: Adding board support

[Stephen Warren]

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.

-- 
nvpublic

Re: Adding board support

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]

* 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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: Adding board support

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]

* 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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

RE: Adding board support

[Stephen Warren]

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.

-- 
nvpublic

RE: Adding board support

[Stephen Warren]

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.

-- 
nvpublic