I set the env varialbes according to section A.4.1 DVEVM 2.0 Getting Started Guide (sprue66f.pdf) to boot from Flash and I'm getting an error:
DaVinci EVM # boot Unknown command 'nboot' - try 'help' ## Booting image at 80700000 ... Bad Magic Number
Here are my env settings
bootdelay=3filesize=5fd2fileaddr=80700000baudrate=115200dns=10.8.104.3gateway=10.8.104.100netmask=255.255.254.0stdin=serialstdout=serialstderr=serialethaddr=00:0e:99:02:5e:18videostd=ntscserverip=10.8.104.79bootfile=uImagerootpath=/home/mikeiz/workdir/filesysnfshost=10.8.104.79ipaddr=10.8.104.78:10.8.104.79:10.8.104.100:255.255.254.0:10.8.100.3:::offbootargs=console=ttyS0,115200n8 noinitrd rw ip=10.8.104.78:10.8.104.79:10.8.104.100:255.255.254.0:10.8.100.3:::off root=/dev/hda1 mem=118Mbootcmd=nboot 0x80700000 0 0x200000; bootmEnvironment size: 551/131068 bytes
Are you using the full software stack from DVSDK 2.0, in particular the U-Boot?
MRI: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?
Its better to be a fool for a minute rather than being foolish and ignorant for rest of the career!
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: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: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.
ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". TI AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY TI. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM TI.
Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.