NVFlash hangs when flashing U-Boot on Tegra2 board

NVFlash hangs when flashing U-Boot on Tegra2 board

[Nuno Santos]

Hi

I have a Tegra2 based board (Harmony) running Linux. It is currently booting 
using the fastboot.bin bootloader shipped with NVIDIA's SDK Developer Kit, but 
I need to replace it for U-Boot, because U-Boot is open source.

So far I've been able to successfully deploy U-Boot on the device using nvflash 
and U-Boot actually runs. However, nvflash hangs waiting for the bootloader to 
finish initializing and therefore flashing won't happen. Apparently nvflash is 
expecting the bootloader to follow some protocol, which U-Boot apparently
is not aware of.

I'd really appreciate any help on this and I'm sorry in advance if this is not
the right forum to publish this question. It has been really hard to find 
information on the web about this. Furthermore, I haven't been able to find
nvflash source code anywhere, which could help tremendously to investigate
what's going on; if at least someone could point me to where I can download
I'd be deeply grateful.

So, this is what I'm using to flash the bootloader:

sudo ./nvflash --bct flash.bct --setbct --configfile flash.cfg --create 
    --bl u-boot-dtb.bin --go

(I've updated the file name of the bootloader in flash.cfg, but apparently it 
doen't affect the outcome)

The output is this:

----------------------------------------
Nvflash v1.1.54599 started
rcm version 0X20001
System Information:
   chip name: t20
   chip id: 0x20 major: 1 minor: 2
   chip sku: 0x8
   chip uid: 0x161c10c541006317
   macrovision: disabled
   hdcp: enabled
   sbk burned: false
   dk burned: false
   boot device: nand
   operating mode: 3
   device config strap: 0
   device config fuse: 0
   sdram config strap: 0

sending file: flash.bct
- 4080/4080 bytes sent
flash.bct sent successfully
odm data: 0x300d8011
downloading bootloader -- load address: 0x108000 entry point: 0x108000
sending file: u-boot-dtb.bin
/ 244122/244122 bytes sent
fastboot.bin sent successfully
waiting for bootloader to initialize
----------------------------------------

And it hangs while U-Boot has actually started executing in the device. If I
reset the board, nvflash  unblocks and prints out the following output:

----------------------------------------
usb read error (71): Protocol error
bootloader failed NvError 0x0
command failure: bootloader download failed 
----------------------------------------


Many thanks in advance!
--Nuno

Re: NVFlash hangs when flashing U-Boot on Tegra2 board

[Alex Courbot]

Hi Nuno,

On Mon 23 Jul 2012 05:45:09 PM JST, Nuno Santos wrote:
> Hi
>
> I have a Tegra2 based board (Harmony) running Linux. It is currently booting
> using the fastboot.bin bootloader shipped with NVIDIA's SDK Developer Kit, but
> I need to replace it for U-Boot, because U-Boot is open source.
>
> So far I've been able to successfully deploy U-Boot on the device using nvflash
> and U-Boot actually runs. However, nvflash hangs waiting for the bootloader to
> finish initializing and therefore flashing won't happen. Apparently nvflash is
> expecting the bootloader to follow some protocol, which U-Boot apparently
> is not aware of.
>
> I'd really appreciate any help on this and I'm sorry in advance if this is not
> the right forum to publish this question. It has been really hard to find
> information on the web about this. Furthermore, I haven't been able to find
> nvflash source code anywhere, which could help tremendously to investigate
> what's going on; if at least someone could point me to where I can download
> I'd be deeply grateful.
>
> So, this is what I'm using to flash the bootloader:
>
> sudo ./nvflash --bct flash.bct --setbct --configfile flash.cfg --create
>      --bl u-boot-dtb.bin --go

If I understand correctly, you are giving the wrong parameter to --bl. 
--bl is the bootloader that is used to interpret the commands sent by 
nvflash and create the layout described in flash.cfg. Therefore you want 
to use the bootloader that is provided in your BSP as argument to --bl, 
and modify flash.cfg to write u-boot to the right partition of your 
flash memory. Then I guess you will have the expected result.

With your current command you are indeed running U-boot from nvflash, 
but it is never written to flash memory and cannot understand the 
commands that nvflash tries to send it.

Hope this helps,
Alex.

Re: NVFlash hangs when flashing U-Boot on Tegra2 board

[Nuno Santos]

Hi Alex

Thank you so much for your prompt response! It really help me understand 
what's going on! Based on your clarification, I was already able to 
flash u-boot on its own partition and have the device booting u-boot 
directly from flash.

Just one more thing. The next step is now to boot linux from u-boot. 
Ideally, I'd like to load the kernel from the Harmony board's nand flash 
using the "nboot" command. This command, however, is not available when 
I compile U-boot for Harmony and looking at U-boot's source code, there 
apparently no nand support for Tegra 2 based boards (at least I couldn't 
find any specific driver code). Do you know if this is actually the case?

Thank you again in advance!

Kind regards,
--Nuno

Re: NVFlash hangs when flashing U-Boot on Tegra2 board

[Stephen Warren]

On 07/23/2012 09:11 AM, Nuno Santos wrote:
> Hi Alex
> 
> Thank you so much for your prompt response! It really help me understand
> what's going on! Based on your clarification, I was already able to
> flash u-boot on its own partition and have the device booting u-boot
> directly from flash.
> 
> Just one more thing. The next step is now to boot linux from u-boot.
> Ideally, I'd like to load the kernel from the Harmony board's nand flash
> using the "nboot" command. This command, however, is not available when
> I compile U-boot for Harmony and looking at U-boot's source code, there
> apparently no nand support for Tegra 2 based boards (at least I couldn't
> find any specific driver code). Do you know if this is actually the case?
> 
> Thank you again in advance!

(Mainline) U-Boot doesn't currently contain a driver for Tegra's NAND
controller. A driver does exist, and is in the process of being
upstreamed, it's just not there just yet.