Re: Adding board support

[Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>]

[-- 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 --]