OK, I got a little progress. I managed to build a problem with its own head. I linked it with the compressed vmlinux image and then put it in an ELF format. The entry address I set is 0x10000. When I tried to start, I got this screen output: "Attached TCP/IP interface to emac0. Warning: no netmask specified. Attaching network interface lo0... done. Loading... 668152 Starting at 0x10000..."
Then nothing happened after that. The linux didn't come up. I think the entry of the file has been correctly located but somehow it couldn't decompress the linux file and put it in a correct address. What could happen here and how should I debug it? Can I get some print out information on the screen to monitor what is going on?
Thanks! Frank
I am a little puzzled... Can vxworks boot loader load binary kernel?
> Should it be a ELF format? As I remembered, the vxworks kernel image
> is stored as an ELF format...
>
> I followed your instruction and get a zImage.bin by objcopy. But the
> file size is even smaller than the vmlinux. Vmlinux is about 1.7M
> while zImage.bin is about 1.3M. When I tried to load the zImage.bin
> with vxworks boot loader, I got same error message:
> ==================
> Attached TCP/IP interface to emac0.
> Warning: no netmask specified.
> Attaching network interface lo0... done.
> Loading... Erroneous header read
>
> Error loading file: errno = 0x610001.
> Can't load boot file!!
> .
> ==================
>
>
> When I tried to make the kernel, I notice the last few commands are as
> below:
> =====================================
> ppc_405-objcopy -O elf32-powerpc \
> --add-section=.image=../images/vmlinux.gz \
> --set-section-flags=.image=contents,alloc,load,readonly,data \
> ../common/dummy.o image.o
> ppc_405-ld -T ../ld.script -Ttext 0x00400000 -Bstatic -o zvmlinux
> head.o ../common/relocate.o misc-embedded.o ../common/misc-common.o
> ../common/string.o ../common/util.o embed_config.o ../common/ns16550.o
> image.o ../lib/zlib.a
> ppc_405-objcopy -O elf32-powerpc zvmlinux zvmlinux -R .comment -R
> .stab -R .stabstr \
> -R .ramdisk -R .sysmap
> ../utils/mktree zvmlinux ../images/zImage.treeboot
> rm -f zvmlinux
> make[2]: Leaving directory
> `/home/yang/work/linux-2.4.18_mvl30/arch/ppc/boot/simple'
> make[1]: Leaving directory
> `/home/yang/work/linux-2.4.18_mvl30/arch/ppc/boot'
> =========================================
>
> What does "-Ttext 0x00400000" means? Is 0x00400000 an entry address?
> But if I use readelf to read vmlinux, the entry address is still
> 0xc0000000. What happened here?
>
> BTW, I am using PPC405. Is the the chip that always turns MMU on?
>
> Thanks!
> Frank
>
>
> > You may also try just
> >
> > objcopy -O binary vmlinux zImage.bin
> >
> > You don't want to change the addresses that vmlinux uses,
> > you only want to make it into a binary since vxWorks doesn't
> > handle elf.
> >
> > But this will be a large file and the zImage.bin uses a compressed
> > image that is much smaller and quicker to load.
> >
> > Just to let you know what is happening.
> >
> > The zImage.bin is a binary file created from an exec that
> > is not the kernel. This program has its own head.S and has
> > the compressed kernel linked into it as a data object. The
> > zImage program is made to run with out the MMU on, so it runs
> > in a flat memory space just like vxWorks. Now vxWorks boot
> > loader will copy it somewhere and then jump to it. The first
> > thing that zImage does is to find out where it is (bl then
> > mflr r3), and with that it relocates itself somewhere, (I
> > think at the 8 meg part) out of the way from where it will
> > place the kernel, but in some location that it can start
> > running C code that needs to know where it is. Then
> > it uncompresses the kernel down into physical address 0x00000000.
> > And finally it jumps to the kernel, and the kernel takes over.
> >
> >
> > And yes, PPC expects the kernel virtual address to be at
> > 0xC0000000, but when the code jumps to the kernel, the kernel
> > will know that the MMU is off, or it will turn it off, and
> > the kernel will map itself where it should be. There's even
> > code in the kernel to map itself to the right physical place
> > too, and that is why the objcopy above should also work,
> > but with a long transfer time.
> >
> > Now this may not be the case for all PPC architectures. For
> > instance, the 440 IIRC or one of the other IBM chips, has
> > the MMU always on and you can't turn it off. What a pain in
> > the ass that was!
> >
> > -- Steve