[U-Boot] booting os 'Unknown OS' (1) is not supported

[Wolfgang Denk]

Dear Alexander,

In message <CABtOAfzG3B-eis0nDOiYtdq2rig_wP6SF2_jz=NLWw7Gp+PE2A at mail.gmail.com> you wrote:
>
> link to my u-boot https://github.com/fedya/u-boot-yse5250

Sorry, but I do not really care about out of tree code.

> Changed to this
> bootcmd=md 40800000 10;imi 40800000;bootm 40800000

OK, lets's go through this step by step.

Note that
> [YSE5250 at omv]# boot
> 40800000: 56190527 ba6b0d61 9850d952 08484800    '..Va.k.R.P..HH.
> 40800010: 00800040 00800040 8a221c4c 00020205    @... at ...L.".....
> 40800020: 756e694c 2e332d78 302e3331 3863722d    Linux-3.13.0-rc8
> 40800030: 00000000 00000000 00000000 00000000    ................

The header (struct image_header) is defined in "include/image.h".  we
have:

237 typedef struct image_header {
238         __be32          ih_magic;       /* Image Header Magic Number    */
	56190527 => 0x27051956 OK
239         __be32          ih_hcrc;        /* Image Header CRC Checksum    */
	ba6b0d61
240         __be32          ih_time;        /* Image Creation Timestamp     */
	9850d952 => 0x52d95098 = 1389973656 = Fri Jan 17 16:47:36 2014
241         __be32          ih_size;        /* Image Data Size              */
	08484800 => 0x00484808 = 4737032
242         __be32          ih_load;        /* Data  Load  Address          */
	00800040 = 0x40008000 OK
243         __be32          ih_ep;          /* Entry Point Address          */
	00800040 = 0x40008000 OK
244         __be32          ih_dcrc;        /* Image Data CRC Checksum      */
	8a221c4c
245         uint8_t         ih_os;          /* Operating System             */
	05 = IH_OS_LINUX OK
246         uint8_t         ih_arch;        /* CPU architecture             */
	02 = IH_ARCH_ARM OK
247         uint8_t         ih_type;        /* Image Type                   */
	02 = IH_TYPE_KERNEL OK
248         uint8_t         ih_comp;        /* Compression Type             */
	00 = IH_COMP_NONE OK
249         uint8_t         ih_name[IH_NMLEN];      /* Image Name           */
	Linux-3.13.0-rc8
250 } image_header_t;

This all looks perfectly OK to me.

> ## Checking Image at 40800000 ...
>    Legacy image found
>    Image Name:   Linux-3.13.0-rc8
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    4737032 Bytes = 4626 KiB
>    Load Address: 40008000
>    Entry Point:  40008000
>    Verifying Checksum ... OK

This is the "iminfo" output. All looks perfectly fine. Note
especially that the image gets correctly decoded as "ARM Linux Kernel
Image (uncompressed)".

> ## Booting kernel from Legacy Image at 40800000 ...
>    Image Name:   Linux-3.13.0-rc8
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    4737032 Bytes = 4626 KiB
>    Load Address: 40008000
>    Entry Point:  40008000
>    Verifying Checksum ... OK

This is the regular "bootm" image output. So far it looks perfectly
fine.

>    kernel data at 0x40800040, len = 0x00484808 (4737032)
> ## No init Ramdisk
>    ramdisk start = 0x00000000, ramdisk end = 0x00000000
>    Loading Kernel Image ... OK
> OK
>    kernel loaded at 0x40008000, end = 0x4048c808

0x40008000 + 0x00484808 (size) = 0x4048c808 ==> looks perfectly fine,
too, and is far enough away from your load address at 40800000

> ERROR: booting os 'Unknown OS' (1) is not supported

This code comes from "common/cmd_bootm.c":

 691         if (boot_fn == NULL && need_boot_fn) {
 692                 if (iflag)
 693                         enable_interrupts();
 694                 printf("ERROR: booting os '%s' (%d) is not supported\n",
 695                        genimg_get_os_name(images->os.os), images->os.os);
...

images->os.os has the value 1 here, not the expected 5 (IH_OS_LINUX)
we had before.  Somenting must have overwritten the header
information / parts of your RAM.

> >movi
> string from help
> 
> movi    - movi  - sd/mmc r/w sub system for SMDK board
> 
> and same command for o-droid
> http://lists.denx.de/pipermail/u-boot/2013-February/146047.html

I have not the lightest idea why they would invent something new
instead of what is being used in mainline.


I have no idea where your memory gets corrupted, or why, and with
out-of-tree code it's difficult to even guess.  But there is a good
chance that parts of your code base are simply broken.

If I were you, I would run this code under control of GDB (with a
JTAG debugger attached).  Then set a watchpoint on the images.os.os
address and check where it gets corrupted.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I must follow the people.  Am I not their leader? - Benjamin Disraeli