• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 751 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Bad Magic Number 0x200000

Aditya Gaddam
Intellectual 850 points


Hi,

I've seen this error message being posted in some previous threads, but they seem to get resolved when they use the stock uImage from the dvsdk. In my case, even the stock uImage (found in the PSP directory under dvsdk..) is giving me this error.

 

I stuck the uImage file in my tftproot and followed the steps here: https://community.ti.com/forums/t/10466.aspx

The following is my printenv output:

 

bootdelay=3

baudrate=115200

bootfile=uImage

filesize=1ec844

fileaddr=80700000

gatewayip=10.1.172.1

netmask=255.255.254.0

ipaddr=10.1.172.191

serverip=10.1.172.190

dnsip=10.1.173.205

dnsip2=10.2.173.24

bootcmd=nboot 0x80700000 0 0x200000; bootm

bootargs=video=davincifb:vid0=0,2500K:vid1=0,2500K:osd0=720x576x16,2025K davinci_enc_mngr.ch0_output=COMPOSITE davinci_enc_mngr.ch0_mode=$(videostd) console=ttyS0,115200n8 noinitrd rw ip=dhcp root=/dev/hda1 mem=118M

stdin=serial

stdout=serial

stderr=serial

ethaddr=00:0e:99:02:5e:ce

videostd=ntsc

Environment size: 534/16380 bytes

My U-boot version is 1.2.0.

Any help would be greatly appreciated. 

Thanks,

Aditya

 

  • 0
    TI__Mastermind 37340 points

    what platform are you working with (DM6446, DM6467...)?

    The name of the binary in your log above is "bootfile=uImage"; is this the same binary name in hos tftp directory (I am pretty sure is not the name given in PSP folder which you copied it from)?

    Also, I assume you are running dhcp command (not shown in log above) to copy binary over; otherwise, the bootcmd you have above (bootcmd=nboot 0x80700000 0 0x200000; bootm) will try to load uImage from NAND flash and not via TFTP.

  • 0
    Intellectual 850 points

    Sorry about that.

    I am working with the DM6446 evaluation board. Yes, I renamed the uImage file. If load the same uImage file from tftp (using dhcp) then the kernel boots fine. But if I try the instructions in that link I posted using the nand writing tools to flash the uImage file into nand and boot from nand, then the board doesn't boot and I get the error I posted.

    In the post, they are making me do:

    nand erase 0x2060000 0x1ece00

    which leads me to believe that the kernel lies at 0x2060000 in nand, but the board seems to be trying to boot from 0x80700000. Are their instructions wrong? Or does the board automagically load the kernel from 0x2060000 first before booting from 0x80700000?

    Thanks,

    Aditya

  • 0 in reply to Aditya Gaddam
    TI__Mastermind 37340 points

    please note that in the post you cited, 0x2060000 is the address in NAND and 0x80700000 is the address in SDRAM. 

    during dhcp process, kernel is tranferred into SDRAM, then you use nand write command to copy kernel from SDRAM to NAND (at address 0x2060000).  During normal boot, your system looks at u-boots bootcmd variable to tell it where to find the kernel (TFTP, FLASH...).  Your bootcmd per your first post appears to be

       bootcmd=nboot 0x80700000 0 0x200000; bootm

    which tells the system that the kernel is in NAND Flash (not execute in place -XIP type memory), hence you need to copy it to SDRAM before kernel can execute; the rest of the bootcmd tells it copy datat from 0x200000 NAND address (but wait, you copied it into 0x2060000), and copy it into SDRAM address 0x80700000 at offset 0. 

    Hopefully this helps clear up the process for you.  The problem appears to be a mismatch in the NAND address being used for copying (0x2060000) and booting (0x2000000).

     

  • 0 in reply to Juan Gonzales
    Intellectual 850 points

    I have no idea why that was set to 0x200000, and why I kept thinking it should be. After I set it to 2060000 it found it fine. It had a bad CRC though. But when I did dhcp again, it gave me a different size than  it was giving me on friday. Somewhat strange. But either way, this seems like another case of an error between keyboard and chair :)

     

    Thanks a lot for your patience and help.

    - Aditya