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.

bootm error - Wrong Image format, Can't get kernel image - Custom Board

Other Parts Discussed in Thread: OMAP-L137

Hello All

I am working on bringing up linux on a custom OMAP - L138 board and have come across certain obstacles.

BACKGROUND:

Network is not available on the custom board. Hence we have copied a single file to the flash by changing the code for flash utility (sft). This seems to be the best option as of now.

This file contains the following at the given addresses in flash

1) U-Boot -> Universal Boot Loader

2) U-Image -> Kernel Image

3) Filesystem

The kernel image and the filesytem are at an offset of 0x10000.

So kernel base address -> 0x90000 

Filesystem base address -> 0x310000

ENVIRONMENTAL VARIABLES:

Kernel                                                                   File System

K: 0xc90000 (Kernelbase)                             B: 0x310000 (File system base)

ks: 0x210000 (Kernel Size)                            S: 0x500000 (File system size)

L: 0xc0000000 (Load Address)                     A: 0x1180000 (Load address)

I have verified that files have been copied to these addresses by reading them in RAM and comparing the files.

sf read 0xc2000000 $B $S

cmp.b 0xc2000000 $A

 

sf read 0xc2000000 $K $ks

cmp.b 0xc2000000 $L

CURRENT:

I am trying to run the flashboot command do boot the images but not able to do so.

setenv flashboot ‘setenv bootargs console=ttyS2,115200n8 root =/dev/ram0 rw initrd $A; sf probe 0;; sf read $A $B $S; sf read $L $K $ks; bootm $L’

which is just

Sf probe 0;

Sf read $A $B $S   -> Read filesytem at $A

Sf read $L $K $ks   -> Read kernel image at $L

bootm $L -> Boot from $L

U-BOOT ERROR:

I get a bad CRC warning and Ethernet init failure as network is not up.

I read somewhere that it is because of unsaved environment variables.

ARM clock: 300000000 Hz

DDR clock: 132000000 Hz

FLASHBOOT ERROR

U-Boot: run F

SF: Detected M25P128 with page size 256, total 16MiB

16384 KiB M25P128 at 0:0 is now current device

Wrong Image Format for bootm command

ERROR: can't get kernel image!

I would be really grateful if anyone could come with some suggestions/procedures or request for additional info. 

  • Not sure I can help but I think there are some inconsistencies in your post. Kernel flash address is noted as 0x90000 and 0xc90000. The ramdisk image RAM address is 0x01180000. Shouldn't that be 0xC1180000? I assume that you are using uimage and not image or zimage.

    The kernel RAM address of 0xC0000000 is the beginning of DDR. Typically 0xC0700000 is used (from TI Wiki). Might be that U-boot is using that memory.

  • Hi Norman

    Thanks for the reply. My apologies. The addresses are

    kernelbase - 0x90000

    ramdisk image address - 0xc1180000.

    I am using a uimage in this case. Also I tried to load the kernel at 0xc0700000 (and other addresses). But I am still getting the same error.

     

    Kindly let me know your view.

  • I think "Wrong Image Format" just means the header is unexpected or not there. I don't think it has read past the header yet. Try looking the first few bytes of the uimage in memory and the first few bytes of the uimage file on the host. The uboot utility "mkimage" adds the header. Maybe you are using a mkimage that incompatible with your u-boot version. If you have a u-boot build, there should be a mkimage within it.

  • Hi Norman

    Thanks for the quick reply. I think that may be the case.

    However when I run the same u-boot on EVM, copy the kernel file (uImage) to flash and run it I am able to do so. In this case my u-boot and kernel build are the same as that for custom card.

    Also I am not getting any error such as "mkimage not found".

    Does that mean the error is with the single bin file I am flashing.

  • Well...if the same u-boot and uimage runs in the EVM, I would guess on custom board that the image in SPI flash is bad or the image in RAM is bad. On the target, dump out header to check.

  • Hi Norman

    Sorry but could you tell me how to do that inside of u-boot. I will try to dump the initial contents then.

  • I think you can use the memory display (md) command after copying uimage from flash to RAM. Something like:

    sf read $L $K $ks

    md $L

    This assumes that the "sf read" command is accessing flash correctly.

    On the linux host, I think you can use "hexdump uimage".

  • Hi Norman

    Thanks a lot for your help!!! 
    The memory display command was indeed very useful. I compared the memory on the EVM card with the custom board and there seemed to be an offset for the entry point of the kernel image and filesystem.

    Maybe it might have been due to the header wrapped around it.

    But anyways after reading the file to RAM at 0xc3000000, I specified the address plus the offset at 0xc3000014 for the bootm command

    Thus 

    sf read 0xc3000000 $K $ks

    bootm 0xc3000014

    This forum has been indeed very helpful.

  • I'd guess that sft is adding the header. The header is used between the first and second stage bootloaders.

    Another way to program the kernel and file system is ymodem. Download via your terminal program over the console. The u-boot ymodem command is "loady". Hopefully it's included in your u-boot build.

  • Hi Norman

    Thanks for the alternative. But I wanted to know if this program could be used from linux.

    Even  if it can be accessed only inside U-Boot, we can transfer our additional files through ymodem without the flashing procedure and then access it once we are inside linux. 

    If yes then it could be really fruitful as network is not up on our card.

  • Hi Norman

    I figured out the ymodem protocol. I think the best way forward is to copy the file to RAM, then to Flash during U-boot and then access from Linux.

  • That's good news. I did much the same on my OMAP-L137 custom board with no network.
    1) Use UART boot and sft to program u-boot and optional armubl. I used emulation boot, JTAG and spi flash writer.
    2) Boot into u-boot, use ymodem to download uimage and ramdisk. Program both into flash. See "loady" and "sf write".
    3) Boot into linux, use zmodem to download u-boot, uimage and ramdisk onto the file system. Program into flash. See "rzsz" and "MTD-Utils". Your board.c file must have the flash partitions defined the same way that u-boot and the RBL use them.

  • seems like this has been answered. thanks for all the help. i have this problem before. in order to get kernel image, i have tried so many image formats. just couldn't figure out which one to use.


    tag: image format, .net image sdk

  • Hi,

    kernel image -> uImage (kernel image with u-boot header)

    If you have further questions, Please create new thread.

    Thank you.