which kernel image did you download into the target via tftp?
vmlinux.gz is just gzip version of vmlinux Here i downloaded
zImage.embedded, which has the following features: ELF 32-bit MSB
executable, PowerPC or cisco 4500, version 1 (SYSV), staticlly linked,
not stripped. then, with the offset 0x10000 from loadaddr, the kernel
is up.
What is the difference between vmlinux and zImage.embedded ?
Bob
quoted
I am a linux-newbie working on a parallel track on the MPC 860, on
a ADS board. I am facing difficulty in getting the kernel to load.
This is what I have done so far:
- built a cross-toolchain using Dan Kegel's crosstool.
- built u-boot-1.0.1 and flashed it to the board using BDI2000
- built linus-2.4.22, (with the below mentioned patch on last attempt).
The compilation goes through fine, I get "vmlinux" on the top-dir,
and also a vmlinux.gz in the arch/ppc/boot/images if I do a "make
zImage".
When I configure bootp, and bootup the board, u-boot comes up fine,
the tftp download of the kernel image goes through fine too. Then I
am stuck with a "Bad Magic Number". Some initial digup led me to a
mismatched image header magic number.
Could anyone please help me with how to go ahead? Am I missing
something?
Also thanks to everyone whose postings on this and other lists
helped me get started!
-----Original Message-----
From: Xavier Miville [mailto:xmiville@oerlikon.ca]
Sent: Thursday, February 26, 2004 9:58 PM
Subject: RE: PCI daughter card with USB on a 405GP
You will need to apply the corresponding linuxppc patch
(/pub/linux/kernel/ports/ppc/2.4) to 2.4.22. The zvmlinux doesn't seem
to be built with only 2.4.22.
On Sat, 2004-02-28 at 06:32, Marius Groeger wrote:
On Thu, 27 Feb 2004, Bob Beck wrote:
quoted
What is the difference between vmlinux and zImage.embedded ?
vmlinux is the plain kernel ELF image. You can use it to analyse the kernel
code or symbols, but you cannot boot it as-is.
zImage.embedded is the compressed kernel image plus some glue code used as a
bridge between the firmware and the kernel.
On my proprietary board (PPC 603). I do not have access to flash
so I am loading vmlinux into RAM and jumping to 0x10000. It is
running into problems in mmu_off.
Should I be loading zImage.embedded instead ?
Bob
I can see
On Sat, 2004-02-28 at 07:29, Marius Groeger wrote:
On Thu, 27 Feb 2004, Bob Beck wrote:
quoted
On Sat, 2004-02-28 at 06:32, Marius Groeger wrote:
quoted
On Thu, 27 Feb 2004, Bob Beck wrote:
quoted
What is the difference between vmlinux and zImage.embedded ?
vmlinux is the plain kernel ELF image. You can use it to analyse the kernel
code or symbols, but you cannot boot it as-is.
zImage.embedded is the compressed kernel image plus some glue code used as a
bridge between the firmware and the kernel.
On my proprietary board (PPC 603). I do not have access to flash
so I am loading vmlinux into RAM and jumping to 0x10000. It is
running into problems in mmu_off.
Should I be loading zImage.embedded instead ?
Yes you can try that, but then you will have to modify the code in
arch/ppc/boot/... to match the specifics of your board.
Another popular way to go is to port u-boot to your platform first.
U-boot accepts kernel pImages which you get by doing a "make pImage"
in the kernel source dir.
You will have to know your tools and hardware quite well either way,
be prepared to learn a lot.
Good Luck,
Marius
Thanks. What is the difference between zImage.embedded and vmlinux.gz
generated by the kernel build ?
This is the file used by U-Boot's mkImage command to produce a
vmlinux.img file.
Bob
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Thanks. What is the difference between zImage.embedded and vmlinux.gz
generated by the kernel build ?
Huge. The vmlinux.gz is just the gzipped kernel. The zImage contains
the 'bootloader' code that can perform some processor initialization,
uncompresses the vmlinux.gz, locates it properly in memory, sets initial
registers, then jumps to the start of the kernel.
Does this mean I should put zImage.embedded into 1 place in memory,
vmlinux.gz into a different place in memory and jump to the start of
zImage.embedded ?
Currently, we are not using U-Boot. We load the binaries into RAM
using a hand rolled program and jump to 0x10000.
Bob
quoted
This is the file used by U-Boot's mkImage command to produce a
vmlinux.img file.
If you are building for u-boot, you should 'make uImage' and use
the uImage that is created.
-- Dan
From: Marius Groeger <hidden> Date: 2004-02-27 16:32:03
On Thu, 27 Feb 2004, Bob Beck wrote:
What is the difference between vmlinux and zImage.embedded ?
vmlinux is the plain kernel ELF image. You can use it to analyse the kernel
code or symbols, but you cannot boot it as-is.
zImage.embedded is the compressed kernel image plus some glue code used as a
bridge between the firmware and the kernel.
Regards,
Marius
--
Marius Groeger [off-list ref]
Project Manager
SYSGO Real-Time Solutions AG | Embedded and Real-Time Software
Am Pfaffenstein 14
55270 Klein-Winternheim, Germany
Voice: +49-6136-9948-0 | FAX: +49-6136-9948-10
www.sysgo.com | www.elinos.com | www.osek.de
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Marius Groeger <hidden> Date: 2004-02-27 17:29:27
On Thu, 27 Feb 2004, Bob Beck wrote:
On Sat, 2004-02-28 at 06:32, Marius Groeger wrote:
quoted
On Thu, 27 Feb 2004, Bob Beck wrote:
quoted
What is the difference between vmlinux and zImage.embedded ?
vmlinux is the plain kernel ELF image. You can use it to analyse the kernel
code or symbols, but you cannot boot it as-is.
zImage.embedded is the compressed kernel image plus some glue code used as a
bridge between the firmware and the kernel.
On my proprietary board (PPC 603). I do not have access to flash
so I am loading vmlinux into RAM and jumping to 0x10000. It is
running into problems in mmu_off.
Should I be loading zImage.embedded instead ?
Yes you can try that, but then you will have to modify the code in
arch/ppc/boot/... to match the specifics of your board.
Another popular way to go is to port u-boot to your platform first.
U-boot accepts kernel pImages which you get by doing a "make pImage"
in the kernel source dir.
You will have to know your tools and hardware quite well either way,
be prepared to learn a lot.
Good Luck,
Marius
--
Marius Groeger [off-list ref]
Project Manager
SYSGO Real-Time Solutions AG | Embedded and Real-Time Software
Am Pfaffenstein 14
55270 Klein-Winternheim, Germany
Voice: +49-6136-9948-0 | FAX: +49-6136-9948-10
www.sysgo.com | www.elinos.com | www.osek.de
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2004-02-27 19:32:44
Bob Beck wrote:
Thanks. What is the difference between zImage.embedded and vmlinux.gz
generated by the kernel build ?
Huge. The vmlinux.gz is just the gzipped kernel. The zImage contains
the 'bootloader' code that can perform some processor initialization,
uncompresses the vmlinux.gz, locates it properly in memory, sets initial
registers, then jumps to the start of the kernel.
This is the file used by U-Boot's mkImage command to produce a
vmlinux.img file.
If you are building for u-boot, you should 'make uImage' and use
the uImage that is created.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2004-02-27 21:05:22
Bob Beck wrote:
Does this mean I should put zImage.embedded into 1 place in memory,
vmlinux.gz into a different place in memory and jump to the start of
zImage.embedded ?
No. zImage.embedded contains everything.
objcopy -O binary zImage.embedded zImage.bin
load zImage.bin at a high address like 4MB or above.
Jump to the first location.
You will have to update some of the files in arch/ppc/boot/simple
to create a configuration descriptor for your board. There are
plenty of examples to copy.
Currently, we are not using U-Boot. We load the binaries into RAM
using a hand rolled program and jump to 0x10000.
That's guaranteed not to work. Something has to initialize the
environment before the Linux kernel starts running. This is
accomplished by the boot roms (u-boot is good for this), or the
bootloader wrappers in the arch/ppc/boot directories.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
I am booting Linux on a custom board and having many
problems. The board contains a PPC603E, flash, an
ethernet controller, and a serial chip.
Here is what I have done so far.
o Configured the kernel to support 6xx/7xx boards
o Introduced a new defined named "CONFIG_ATCNVMS"
o Modified kernel/setup.c so that early_init() would
skip the last 3 things it does that do not make
sense for my board.
o Added a new embed_config() function in arch/ppc/boot/simple
that populates a bd_t structure (from ppcboot.h)
o Added code to save registers r3-r7 at the beginning
of start_ in simple/head.S. Restored these registers
in relocate.S before the jump to 0.
o Updated the makefiles so that the zImage.embedded
would be created in the arch/ppc/boot/images directory.
We are writing our own boot loader code for a couple of reasons.
o U-Boot does not support our ethernet chip or serial chip.
o VxWorks is in flash and we cannot change that in the near future.
o The VxWorks boot loader initializes the hardware and
we run our custom boot loader from its shell.
Here are the steps taken by our custom boot loader.
o Malloc a piece of memory and copy the ram disk from a file
to the malloc'd memory.
o Malloc a piece of memory and copy the zImage.bin contents from
a file to memory.
powerpc-linux-objcopy -O binary zImage.embedded zImage.bin
o Prepare the registers
r3 = ptr to bd_t
r4 = ptr to initial ram disk bin in memory
r5 = ptr to end of initial ram disk
r6 = ptr to start of command line string
r7 = ptr to end of command line string
o Jump to the start address where the zImage.bin has been loaded
into memory.
In arch/ppc/boot/simple/head.S, I call a routine that blinks a light
(start_), but this light never blinks. I also call this routine
at __start in arch/ppc/kernel/head.S but the light never blinks.
I don't understand what to do at this point. In the past I
loaded the ram disk and vmlinux into memory and jumped to 0x10000.
Somebody on this list said that was guaranteed not to work.
However, the light did blink before the code had problems in
mmu initialization.
Regards,
Bob Beck
beck@assurtech.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/