Booting DM6446 from Flash using the EVM's Hard Drvie

Are you using the full software stack from DVSDK 2.0, in particular the U-Boot?

MRI said:

Unknown command 'nboot' - try 'help'

This makes me think that your U-Boot version is not the same version that the GSG you are reading from is meant for. I suspect the failure to run nboot is leading to the bad magic number since the image is not being copied from flash to DDR.

Hi...

Can we suspect on file in flash corrupted as it  is giving "bad magic" number ?

I so, re-burning the flash may b a solution.

Regards,

Onkar

'bad magic number' normally means uImage is corrupt or cannor be found at the specified location, so you are correct to a large extent and the solution would be re-flash the kernel; In this case though, the 'Unknown command 'nboot' ' seems to come before the bad magic number, which would suggest that maybe u-boot was not upgraded with the rest of the DVSDK software (previous versions of GSG corresponding to DVSDK releases suggested use bootm instead of nboot)

Hi Juan and Bernie,

              I have recently started playing with DVEVM6446. I have same problem as the first poster. However I can successfully boot and run programs with 'DHCP + NFS (system) +TFTP (kernel protocol)'. I am wondering once my examples are tested and ready I need to have them as a stand alone system and not interact with host via TFTP and NFS file system. I followed default mode and I have a feeling that my uImage shouldn't be corrupt as it works for other methods. It may be the location or path. Any takes on this? Any suggestions?

Typically bad magic number means your image is not where you are trying to boot it from, either not in the right place in flash or not being copied into RAM properly before trying to boot it, basically the first word of the image is not what was expected, so anything that could prevent you from reading the first word of your uImage could cause the error. In the original post there was also an error about nboot not being recognized which indicates that the uImage was never copied from flash to RAM leading to the error, do you have any other suspicious output around the bad magic number error?

You normally want to make sure all three main pieces of software (u-boot, uImage, and Linux file-system) come from the same DVSDK software release.  This is very easy to overlook specially as you are in the development phase mostly working via TFTP and NFS.  When you are all done developing and want to run stand-alone, you not only have to flash uImage on EVM, but also upgrade the file-system on HDD to match uImage.  Finally, you may need to upgrade u-boot to match the other two components; this last step is not always required but can be depending on which version of u-boot you have and which version of DVSDK your other components come from.

My output is as follows

                                                                               
U-Boot 1.1.4 (Sep 13 2007 - 11:00:43)                                          
                                                                               
U-Boot code: 81080000 -> 81097950  BSS: -> 810A0340                            
RAM Configuration:                                                             
Bank #0: 80000000 256 MB                                                       
INTEL Flash: 16 MB                                                             
In:    serial                                                                  
Out:   serial                                                                  
Err:   serial                                                                  
ARM Clock :- 297MHz                                                            
DDR Clock :- 162MHz                                                            
MSP430 Firmware supports AM/PM Feature                                         
Hit any key to stop autoboot:  0                                               
Unknown command 'nboot' - try 'help'                                           
## Booting image at 80700000 ...                                               
Bad Magic Number                                                               
DaVinci EVM #

My bootloader U-boot is 1.1.4 while rest of the tools are version 2+ e.g. dvsdk2_00_00_22 (I downloaded them recently from TI account). Also have confusion about NAND and NOR memories!!! Which is better for person in a development stage like mine. Also if I proceed to finalize my application as stand alone and then realize I need to go back to DHCP +TFTP + NFS procedure to change code...develop, test it and then download stuff back again to HDD what precautions I need to follow?

U boot is ver 1.1.4 while dvsdk and LSP, monta vista setup, etc  ver 2+ (I recently downloaded from TI account). If I need to redevelop and switch back between 'DHCP+NFS+TFTP' and 'HDD+FLASH' modes of booting , what precautions/ steps do I need to take? Also how are NAND and NOR memories to be used for a person in a development stage like mine?

virgoptrex said:

If I need to redevelop and switch back between 'DHCP+NFS+TFTP' and 'HDD+FLASH' modes of booting , what precautions/ steps do I need to take?

All you need to do to switch a board between stand alone and network based booting is change the U-Boot arguments, assuming you still have the host PC configured for NFS and TFTP, these configurations are described in the getting started guide. In general in regard to precautions I would just save your known good U-Boot arguments in a text file somewhere that you can use to copy them back to the board when you need to switch around boot modes, booting from the network should have no impact on your HDD or flash contents aside from U-Boot arguments unless you explicitly modify them.

virgoptrex said:

Also how are NAND and NOR memories to be used for a person in a development stage like mine?

The NAND or NOR will contain your UBL and U-Boot boot loaders as well as a uImage kernel image in a stand alone system, additionally in systems without a HDD you could use the flash to hold a filesystem as well. However for development generally the flash will only hold the UBL and U-Boot boot loaders, with the uImage kernel and filesystem loading over the network for ease of development.