Bad Magic Number

Bad magic number means that when U-Boot tried to boot the UImage kernel image it found that the kernel image was not valid, i.e. the magic number it expected at the beginning of the image was not there or otherwise corrupted.

This normally means that your UImage is missing or your UImage is corrupted, or it is not a UImage. Most commonly this stems from some problem in your U-Boot arguments, if you could post your U-Boot arguments from 'printenv' we can probably locate the issue.

Bad Magic Number means that u-boot was not able to find a valid Linux Kernel (uImage) where it is looking for it.  This could be because

1) The Linux Kernel (uImage) is not at the memory location where u-boot is being configured (via u-boot environment variables) to look (80700000 ), or

2) The Linux Kernel at the location is corrupt.  Sometimes putting a new copy of the same uImage in the correct location fixes the problem.  If you want to use the original uImage, it is included as part of DVSDK software.  For example, for DM6446 you would find this under

.../dvsdk_1_30_00_41/PSP_XX_XX_XX_XX/bin

Let me know if this helps.

Hi,

Thanks for the response.  I tried just moving the uImage in that directory and tried booting from that, but it gives the same error. 

What could I be doing wrong?

Thanks

Could you post your U-Boot arguments from 'printenv' as well as a log of the output from your failed boot? I would guess that something is wrong in there such that you are not TFTPing the proper file or that the TFTP is failing, either way we should be able to give you some further insight if you can provide the output from your terminal program when the failure happens along with your U-Boot arguments.

DM355 EVM # printenv
bootdelay=3
baudrate=115200
filesize=248448
fileaddr=82000000
stdin=serial
stdout=serial
stderr=serial
videostd=ntsc
bootcmd=dhcp;bootm
serverip=192.168.0.64
bootfile=uImage
nfshost=192.168.0.64
rootpath=/localhome/administrator/workdir/filesys
bootargs=console=ttyS0,115200n8 noinitrd rw ip=dhcp root=/dev/nfs nfsroot=192.168.0.64:/localhome/administrator/workdir/filesys,nolock mem=116M video=davincc

Environment size: 540/16380 bytes
DM355 EVM #

and then I type bootm and I get the following:

DM355 EVM # bootm
## Booting image at 80700000 ...
Bad Magic Number
DM355 EVM #

Hope this helps.  Thanks for the help!

NeeravPatel said:

Thanks for the response.  I tried just moving the uImage in that directory and tried booting from that, but it gives the same error. 

What could I be doing wrong?

Thanks

Are you using TFTP to load the Linux Kernel (I assume so since you mention 'directory')?  If copying fresh version of uImage into host "/tftpboot" directory (default in RHEL4 OS), and it still does not fix the problem, then you may need a clean copy of uImage.  As I mentioned in my previous post, if you use the original uImage that comes with DVSDK which is found under

.../dvsdk_1_30_00_41/PSP_01_20_00_014/bin

that should be guaranteed to work.

Edit:  Apologies, I was midway typing this response when I got a visitor; therefore I did not realize that more posts had occurred since I read the one quoted above.

NeeravPatel said:

DM355 EVM # printenv
bootdelay=3
baudrate=115200
filesize=248448
fileaddr=82000000
stdin=serial
stdout=serial
stderr=serial
videostd=ntsc
bootcmd=dhcp;bootm
serverip=192.168.0.64
bootfile=uImage
nfshost=192.168.0.64
rootpath=/localhome/administrator/workdir/filesys
bootargs=console=ttyS0,115200n8 noinitrd rw ip=dhcp root=/dev/nfs nfsroot=192.168.0.64:/localhome/administrator/workdir/filesys,nolock mem=116M video=davincc

Environment size: 540/16380 bytes
DM355 EVM #

 

 

and then I type bootm and I get the following:

DM355 EVM # bootm
## Booting image at 80700000 ...
Bad Magic Number
DM355 EVM #

 

Hope this helps.  Thanks for the help!

 

try typing

> boot

at the u-boot prompt.  FYI, 'bootm' command implies that it will look for uImage at location specified by fileaddr.  If you execute before running 'dhcp' command, there will be no TFTP file transfer to put uImage onto DDR2 where bootm will look for it.  This is why "bootcmd" environment variable is set to

bootcmd=dhcp;bootm

Try running 'boot' instead of bootm, bootm will try to execute an image in DDR that may not exist yet, particularly if you did not run 'dhcp' yet. This is why your bootcmd is set to dhcp;bootm, so when your board boots it runs dhcp to load the uImage and than executes it with bootm.

This should have worked if you just power cycled the board and let u-boot expire instead of typing bootm.

EDIT: Juan is 4 minutes faster today :)

Ah I see, awesome thanks.  Boot has always worked, I was just a bit confused as to why bootm wasnt working, but now it makes sense.  There was no dhcp server at the time it tried to call boot.  I did however follow the instructions in the Getting Started manual so I am still unsure as to why it didnt work, but for now I will just do the boot if I want to recompile the kernel.

Thanks for all the help.

NeeravPatel said:

I did however follow the instructions in the Getting Started manual so I am still unsure as to why it didnt work

I am not sure which part did not work? EDIT: perhaps you mean your board host were not on a DHCP network? if so I understand

Just to be clear running bootm will only work if there was some prior command run to load a uImage into DDR, such as running dhcp or performing a copy out of flash.

Yeah the DHCP Server hasnt assigned an IP to the board yet, and therefore if I understood you correctly, the board doesnt know where to look for the file.  By calling boot it actuall assigns the ip first and then downloads the code cause it knows where the ftp server is.

Exactly, if the network is not usable than the DHCP command will fail and you will not be able to get a uImage file, the DHCP command actually does both obtain an IP address and attempt to load a uImage via TFTP so the loading step is kind of hidden there. Your understanding of boot is also correct, it essentially runs the two commands dhcp and bootm in sequence to obtain the desired boot effect.