[U-Boot] putting U-boot in Nand flash for Tms320dm6467

Andrew Dyer amdyer at gmail.com
Sat Feb 27 16:38:19 CET 2010


On Sat, Feb 27, 2010 at 5:40 AM, Balaji Sivakumar, ERS, HCLTech
<balajisk at hcl.in> wrote:
> Hi,
> We have developed new board with TMS320DM6467, My question here is can I use same the U-boot.bin that came with DM6467 EVM.
> We are using the RBL supported Nand Device and no change in the memory map. The only I change we are using Nand Flash from different manufacturer Micron.

No, the u-boot that comes with the EVM expects to have the RAM setup
and other stuff already done by the user boot loader which is normally
loaded from SPI EEPROM on the EVM.  For the purpose of testing, you
can use a GEL file with an emulator to do the setup and load u-boot
into RAM at the normal load address.

The handling of NAND ECC is kind of a mess on this hardware - I didn't
work on that part of our project, but I believe there is a particular
format the RBL expects to see and the SPI UBL code may do something
different, so you have to be careful with how that gets written.

> I have got u-boot 1.2.0 folder, but it contains different folders, could anyone explain if I need to change the configurations for my board what are the files I need to look.

this is covered in the u-boot readme, but start with
./include/configs/davinci-dm646x.h (in the TI distribution).

>
> If I build the code, whether it will generate the binary file or different format.

Normally the build generates ELF (u-boot), binary (u-boot.bin), and
s-records (u-boot.srec).  If you are debugging with CCS, you can load
in the elf file to CCS and get symbols and debug info.  The optimized
code jumps around alot.

If you have a chance to start from recent u-boot code, I would do
that.  We had to use the u-boot as distributed by TI because of client
requirements, but the base code TI distributes with the EVM is very
old and hacked up.


More information about the U-Boot mailing list