Ok, I have figured out that when I build a kernel, by default, it won't be ready for U-boot. I need to run mkimage on it first. Has anyone done this? I found a Windows version, but it gives the error "mkimage: Bad Magic Number: "Image" is no valid image".

Ok, I worked my way past that. It turns out that for this version, I needed to gzip the vmlinux in the main directory, like this:

gzip --best -c vmlinux > vmlinux.gz

and use this vmlinux.gz for mkimage.

Now I have a binary file that Uboot can uncompress. However, it stops at this point:

"Uncompressing Kernel Image..."

Does anyone know why it won't finish uncompressing?

Normally if you do a linux build, there will already be a g-zipped image in the boot directory after compilation. When running makeimage you should remember to specify the Load Address and Entry point.

mkimage -A arm -O linux -C none -T kernel -a 20008000 -e 20008000 -n linux-2.6 -d arch/arm/boot/zImage uImage

mkimage options
-A ==> set architecture to 'arch'
-O ==> set operating system to 'os'
-T ==> set image type to 'type'
-C ==> set compression type 'comp'
-a ==> set load address to 'addr' (hex)
-e ==> set entry point to 'ep' (hex)
-n ==> set image name to 'name'
-d ==> use image data from 'datafile'

In order to create an u-boot suitable image at build time you have to build your kernel with the following command:

$ make uImage

BTW you need to have mkimage in your path.

[quote="incognito"]When running makeimage you should remember to specify the Load Address and Entry point.

mkimage -A arm -O linux -C none -T kernel -a 20008000 -e 20008000 -n linux-2.6 -d arch/arm/boot/zImage uImage[/quote]

How do I know what values to use for -a and -e options? I used a pre-built kernel from this website and that worked fine on the board. Is there a way to know what -a and -e options were used for that? I put the kernel image at 0xa0000 in Nandflash.

[quote="koan"]In order to create an u-boot suitable image at build time you have to build your kernel with the following command:

$ make uImage
[/quote]

Yes, I believe I ran mkimage successfully enough to at least have the kernel image be recognized by U-boot. Before I knew about mkimage I would get this error:

Wrong Image Format for bootm command
ERROR: can't get kernel image!

But now after I have used mkimage, I get the problem:

"Uncompressing Kernel Image..."

and the board seems to stop there. Like, with the pre-built binary, I would see lots of "........." and then the kernel would come up. But now I only see 3 dots and then it doesn't do anything.

1) Do I need more parameters to mkimage?
2) Do I need another parameter when building the kernel?

These addresses are those in SDRAM where the image is load from NAND/Data Flash. They are addresses which do not conflict with where uBoot has been loaded. They will be reflected in the uBoot commands to load/exec the image. My kernel is being loaded from 0x200000 in NAND, but that will clearly depend on how you've mapped things out, and the specific part you're using. It gets staged at 0x22000000 in SDRAM, but then goes to 0x20008000

What information is uBoot providing about the image before it starts the decompression?

If the memory addresses are wrong, or the SDRAM hardware is not configured correctly will cause the process to fail. Things like timing/refresh issues will typically show up as "checksum" type failures. Consider also how large your kernel is, and if it fits in the constraints the system is assuming (less than 2MB).

If you're sufficiently adept with a JTAG debugger, it's possible to traverse ROMBoot, AT91BootStrap, uBoot, and the initial kernal load/decompress. It's also possible to step beyond the transition into virtual memory.


NAND read: device 0 offset 0x200000, size 0x200000
2097152 bytes read: OK
## Booting kernel from Legacy Image at 22000000 ...
Image Name: Linux-2.6.38.7
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1806964 Bytes = 1.7 MiB
Load Address: 20008000
Entry Point: 20008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Linux version 2.6.38.7 (ct@linux-1234) (gcc version 4.3.5 (Buildroot 2011.05) )
#1 Fri Nov 11 11:11:11 CDT 2011
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Atmel AT91SAM9G20-EK

[quote="CptTitanic"]

What information is uBoot providing about the image before it starts the decompression?

[/quote]



This is what U-boot tells me:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
U-Boot 1.3.4 (Mar 9 2010 - 19:35:35)

DRAM: 64 MB
NAND: 256 MiB
In: serial
Out: serial
Err: serial
Net: macb0
macb0: Starting autonegotiation...
macb0: Autonegotiation complete
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
Hit any key to stop autoboot: 0

NAND read: device 0 offset 0xa0000, size 0x200000
2097152 bytes read: OK
## Booting kernel from Legacy Image at 22000000 ...
Image Name: built_kernel.bin
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 2039184 Bytes = 1.9 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ...

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

So from the message "Booting kernel from Legacy Image at 22000000" do I assume that "22000000" is the value for the -a parameter? What would I then set for a value for -e?

The SDRAM itself should be ok because I was able to load a pre-built kernel on here and it executed fine and I could run programs in Linux and such.

I checked the kernel size. It is 2,039,248 bytes. So this is too large? Can I change a setting, or do I have to delete some stuff from the kernel? If so, I wouldn't know where to begin looking for what is "deletable". Any hints?

0x22000000 is a staging address, ie data placed here before moving it.

The addresses inside your kernel are 0/0, but should be 0x20008000/0x20008000. As Incognito suggested these should be the parameters. This is where the SDRAM is in most SAM9xxx implementations (except 9G45 has two banks of DDR, the primary at 0x70000000)

While uBoot can load bigger kernel images, you'd need to play with it's environment variables, and ensure your mapping within the NAND can accommodate this.

2MB = 2,097,152 bytes, at 1.9MB you are under this limit. The invalid load/exec addresses certainly could explain why this isn't working as it is.

buildroot manages to get this done with significantly less bother. Even if you'd prefer to do it manually, it might behoove you to see how buildroot achieves it.

[quote="CptTitanic"]The addresses inside your kernel are 0/0, but should be 0x20008000/0x20008000. As Incognito suggested these should be the parameters.

buildroot manages to get this done with significantly less bother. Even if you'd prefer to do it manually, it might behoove you to see how buildroot achieves it.[/quote]

It looks like the addresses were definitely a problem. I thought they were board-specific, not ARM-specific, which is why I didn't try Incognito's values. But 0x20008000 for both -a and -e has gotten me past the issue. Of course, now a new one.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Uncompressing Kernel Image ... OK

Starting kernel ...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

So before setting -a and -e properly, it never got the "OK" for uncompressing the image. Now it hangs at "Starting kernel..."

As for buildroot, I started to look into that, but I got the impression the learning curve would be a lot higher than this. Maybe I was wrong? I saw a long list of software I'd need to install just to get it going. Also, the final goal is to be able to recompile the kernel again with some other software program. That software program needs to be built as part of the kernel. So my feeling now is that if I can compile the basic kernel and see it run, then I can compile the kernel with this other software package included and see that run. Would buildroot even allow for this? But since I am so close, I think, with the current approach, I'd appreciate comments on that too.

> Uncompressing Kernel Image ... OK
>
> Starting kernel ...

If you compare the console output you're seeing versus what CptTitanic posted for a typical ARM Linux kernel booted by U-Boot, you'll notice that your kernel is uncompressed before it's started, whereas the proper sequence starts the kernel and then it's uncompressed. This reversal indicates that you are building the kernel incorrectly and/or misusing mkimage.

U-Boot itself contains code to uncompress the (kernel) image that has been loaded into RAM. However the ARM boot sequence for the Linux kernel should not invoke any of this U-Boot code. Instead U-Boot should simply load the ARM Linux kernel image and start execution of the "wrapper code" that mkimage attaches to the kernel image.

It's this "wrapper code" that uncompresses the Linux kernel (in the ARM boot scheme which uses a uImage binary). U-Boot actually considers the uImage it just loaded as an "uncompressed" image (which does *not* need to be decompressed by U-Boot). That's why the "Uncompressing Linux.." output should appear after U-Boot declares that it is "Starting kernel ...".

You need to go back to your kernel build, and build a proper uImage binary of the kernel. gzip'ing the kernel before you give it to mkimage is incorrect. mkimage will perform its own compression, and then add its wrapper code. The resulting uImage file is essentially a self-extracting binary image.

Regards

[quote="blue_z"]If you compare the console output you're seeing versus what CptTitanic posted for a typical ARM Linux kernel booted by U-Boot, you'll notice that your kernel is uncompressed before it's started, whereas the proper sequence starts the kernel and then it's uncompressed. This reversal indicates that you are building the kernel incorrectly and/or misusing mkimage.

You need to go back to your kernel build, and build a proper uImage binary of the kernel. gzip'ing the kernel before you give it to mkimage is incorrect. mkimage will perform its own compression, and then add its wrapper code. The resulting uImage file is essentially a self-extracting binary image.
[/quote]

Thanks. I can't see how I could be building the image wrong, but I bet that's it. I have a compiler from CodeSourcery, G++ Lite. Anyone used this?

Could it be an issue with 'make menuconfig'? I really didn't know what to set in there, so I just kind of left it alone. Or is that not part of the problem?

Also, which image should I be using? After I build, I am left with:
vmlinux (size 4656277 bytes)
arch/arm/boot/compressed/vmlinux (size 1745308 bytes)
arch/arm/boot/Image (size 3392384 bytes)
arch/arm/boot/zImage (size 1701112 bytes)

Out of these 4, which is the proper one to pass to mkimage?

As koan indicates you need uImage for a uBoot strapped system.

http://www.at91.com/linux4sam/bin/view/ ... inux_image

This Linux4SAM stuff is a prerequisite.

Why can't you connect your linux build machine to the internet, indirectly or whatever, and why can't you install all the tools you need on it? You seem to be making this way more difficult than necessary. Without a debugger, you're not going to be able to figure out why it crashes by looking at the serial output, at this point you're stabbing around in the dark. The basic answer is it is attempting to execute code that is incompatible with the platform. There may be a problem with mkimage, or something further upstream, not sure you're currently equipped to make such a determination, or fix it. So let's step back and try a method that's workable.

Most people are building the AT91SAM9 kernels with openembedded or buildroot. A SuSE system installed directly off the DVD requires about 7 additional packages, which can be installed via a single command line. The entire build process can be invoked in an equivalent number of lines. It then fetches and builds the pieces it needs.

# Install additional package required on a raw system, this should cover most
sudo zypper install gcc-c++ bison flex subversion make patch texinfo
wget http://buildroot.uclibc.org/downloads/b ... 05.tar.bz2
tar -xjvf buildroot-2011.05.tar.bz2
cd buildroot-2011.05
make at91sam9g20dfc_defconfig
# To customize, make menuconfig
make

Poof, a fraction of a parsec later a kernel is emitted

Looking at the progress it generates the kernel/images
..
LD arch/arm/boot/compressed/vmlinux
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
UIMAGE arch/arm/boot/uImage
Image Name: Linux-2.6.38.7
Created: Mon Nov 14 12:16:58 2011
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1806964 Bytes = 1764.61 kB = 1.72 MB
Load Address: 20008000
Entry Point: 20008000
Image arch/arm/boot/uImage is ready

[quote="CptTitanic"]
# Install additional package required on a raw system, this should cover most
sudo zypper install gcc-c++ bison flex subversion make patch texinfo
wget http://buildroot.uclibc.org/downloads/b ... 05.tar.bz2
tar -xjvf buildroot-2011.05.tar.bz2
cd buildroot-2011.05
make at91sam9g20dfc_defconfig
# To customize, make menuconfig
make

Poof, a fraction of a parsec later a kernel is emitted

Looking at the progress it generates the kernel/images
..
LD arch/arm/boot/compressed/vmlinux
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
UIMAGE arch/arm/boot/uImage
Image Name: Linux-2.6.38.7
Created: Mon Nov 14 12:16:58 2011
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1806964 Bytes = 1764.61 kB = 1.72 MB
Load Address: 20008000
Entry Point: 20008000
Image arch/arm/boot/uImage is ready[/quote]

Ok, I did all the steps as you wrote them. First, thank you for clearing explaining things. Second, when I did 'make' it took about an hour. When it was done, there was a file

buildroot-2011.05/output/images/uImage

I assume that is the one I should use. The output I saw did not match what you wrote: here is the tail end of the make command:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
----------------------------------------------------------------------
Libraries have been installed in:
/home/user1/buildroot-2011.05/output/host/usr/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,-rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
test -z "/home/user1/buildroot-2011.05/output/host/usr/bin" || /bin/mkdir -p "/home/user1/buildroot-2011.05/output/host/usr/bin"
/bin/sh ./libtool --mode=install /usr/bin/install -c 'faked' '/home/user1/buildroot-2011.05/output/host/usr/bin/faked'
libtool: install: /usr/bin/install -c faked /home/user1/buildroot-2011.05/output/host/usr/bin/faked
make[3]: Leaving directory `/home/user1/buildroot-2011.05/output/build/host-fakeroot-1.9.5'
make[2]: Leaving directory `/home/user1/buildroot-2011.05/output/build/host-fakeroot-1.9.5'
make[1]: Leaving directory `/home/user1/buildroot-2011.05/output/build/host-fakeroot-1.9.5'
>>> host-makedevs undefined Extracting
>>> host-makedevs undefined Patching package/host-makedevs
>>> host-makedevs undefined Configuring
>>> host-makedevs undefined Building
/usr/bin/gcc -O2 -I/home/user1/buildroot-2011.05/output/host/include -I/home/user1/buildroot-2011.05/output/host/usr/include -L/home/user1/buildroot-2011.05/output/host/lib -L/home/user1/buildroot-2011.05/output/host/usr/lib -Wl,-rpath,/home/user1/buildroot-2011.05/output/host/usr/lib package/makedevs/makedevs.c -o /home/user1/buildroot-2011.05/output/build/host-makedevs-undefined/makedevs
>>> host-makedevs undefined 'Installing to host directory'
install -D -m 755 /home/user1/buildroot-2011.05/output/build/host-makedevs-undefined/makedevs /home/user1/buildroot-2011.05/output/host/usr/bin/makedevs
>>> Generating root filesystem image rootfs.tar
rm -f /home/user1/buildroot-2011.05/output/build/_fakeroot.fs
touch /home/user1/buildroot-2011.05/output/build/.fakeroot.00000
cat /home/user1/buildroot-2011.05/output/build/.fakeroot* > /home/user1/buildroot-2011.05/output/build/_fakeroot.fs
echo "chown -R 0:0 /home/user1/buildroot-2011.05/output/target" >> /home/user1/buildroot-2011.05/output/build/_fakeroot.fs
cat target/generic/device_table.txt target/generic/device_table_dev.txt > /home/user1/buildroot-2011.05/output/build/_device_table.txt
echo "/home/user1/buildroot-2011.05/output/host/usr/bin/makedevs -d /home/user1/buildroot-2011.05/output/build/_device_table.txt /home/user1/buildroot-2011.05/output/target" >> /home/user1/buildroot-2011.05/output/build/_fakeroot.fs
echo " tar -c""f /home/user1/buildroot-2011.05/output/images/rootfs.tar -C /home/user1/buildroot-2011.05/output/target ." >> /home/user1/buildroot-2011.05/output/build/_fakeroot.fs
chmod a+x /home/user1/buildroot-2011.05/output/build/_fakeroot.fs
/home/user1/buildroot-2011.05/output/host/usr/bin/fakeroot -- /home/user1/buildroot-2011.05/output/build/_fakeroot.fs
rootdir=/home/user1/buildroot-2011.05/output/target
table='/home/user1/buildroot-2011.05/output/build/_device_table.txt'
rm -f /home/user1/buildroot-2011.05/output/build/.fakeroot*
user1@linux-0mmn:~/buildroot-2011.05>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

U-boot appears to recognize this image. It gets much farther than it used to. This is pretty much what appears in the serial output now:

INIT: version 2.86 booting
Starting udevKernel panic - not syncing: Attempted to kill init!
[<c002d5dc>] (unwind_backtrace+0x0/0xdc) from [<c02588a4>] (panic+0x34/0x120)
[<c02588a4>] (panic+0x34/0x120) from [<c0040d8c>] (do_exit+0x64/0x5b4)
[<c0040d8c>] (do_exit+0x64/0x5b4) from [<c0041364>] (do_group_exit+0x88/0xbc)
[<c0041364>] (do_group_exit+0x88/0xbc) from [<c004b1fc>] (get_signal_to_deliver+
0x2f8/0x334)
[<c004b1fc>] (get_signal_to_deliver+0x2f8/0x334) from [<c002a510>] (do_notify_re
sume+0x70/0x5ac)
[<c002a510>] (do_notify_resume+0x70/0x5ac) from [<c0027e88>] (work_pending+0x1c/
0x20)
INFO: RCU detected CPU 0 stall (t=1000 jiffies)
INFO: RCU detected CPU 0 stall (t=4000 jiffies)
INFO: RCU detected CPU 0 stall (t=7000 jiffies)
INFO: RCU detected CPU 0 stall (t=10000 jiffies)

Is it a problem with the filesystem? I didn't change that - I am using the same one I had used when I used the pre-built kernel image. It is Angstrom-console-at91sam9-image-glibc-ipk-2009.X-stable-at91sam9g20ek.rootfs.jffs2.

As far as I remember the pre-built images for Angstrom use another partitioning of the NAND flash.
So you probably have your Angstrom jffs Image copied to 0x2000000 in NAND.
Most newer Kernels use another partitioning scheme in NAND.
0x0 to 0x20000 Bootstrap (/dev/mtdblock0)
0x20000 to 0x60000 U-Boot (/dev/mtdblock1)
0x60000 to 0x80000 U-Boot Env 1 (/dev/mtdblock2)
0x80000 to 0xA0000 U-Boot Env 2 (/dev/mtdblock3)
0xA0000 to 0x2A0000 Linux Kernel (/dev/mtdblock4)
From 0x2A0000 Root file system. (/dev/mtdblock5)
This is the one you also use now specified by the bootargs parameter of U-Boot discussed in another thread.

Take your time and read through www.linux4sam.com, it is worth it.