Re: Linux on Motorola Sandpoint/PPMC7400

On Wed, Aug 30, 2000 at 10:02:10PM +0300, Alex Shnitman wrote:

Hi again,

I'm trying to load a kernel with an initrd image. I have two questions.

First, I'm locating the kernel (via the s-records) at 400000. It then
relocates to 800000. I'm refering to this output:

DINK32_MAX >>go 400000
loaded at:     00400000 00414E20
relocated to:  00800000 00814E20
zimage at:     0040B000 00489577
relocated to:  00815000 00893577
initrd at:     00489577 00533299
relocated to:  00893577 0093D299
avail ram:     00400000 00800000

After that it boots fine.

If I try to locate it at 800000 to begin with, it fails like this:

DINK32_MAX >>go 800000
loaded at:     00800000 00814E20
zimage at:     0080B000 00889577
initrd at:     00889577 00933299
avail ram:     00400000 00800000

Linux/PPC load: root=/dev/ram
Uncompressing Linux...bad gzipped data
exit

Does that make sense to anyone? Not that it disturbs me, but I'm just
curious.

The bootloader relocation algorithm doesn't work when loaded at
0x800000.  Anything else will work.

Second, I'm trying to load an initrd image. I put the compressed
filesystem image in arch/ppc/boot/ramdisk.image.gz and then did "make
zImage.initrd", which created zvmlinux.initrd which I'm loading.
However during bootup it says this:

No clue here.

--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Matt Porter wrote:

The bootloader relocation algorithm doesn't work when loaded at
0x800000.  Anything else will work.

Well, not exactly :-).  The code is actually written with some
assumptions because I couldn't make it do _everything_.  The download
should be located above the address where it is linked to execute.
For example, I download to 0x900000, the code relocates to 0x800000,
then uncompresses the kernel into the base of memory.

This follows the MPC8xx boot model with a larger memory window.
The MPC8xx had more constraints (smaller main memory 8 Mbyte start
up translation), so the load/execution addresses were lower in
memory.  Since the kernel is constantly growing and the 82xx had
a 16 MByte window, I just decided to move everything further up
in the address space.

Anything below the linked execution address (0x800000 in this case)
is considered fair game for allocation by the code, so it could
write over itself or other necessary information (like zImage or the
ramdisk).

No clue here.

I am not sure the ramdisk stuff was ever tested.  I was just happy to
get the serial download of the kernel working and let NFS do the rest.
I am itching to fire up my 8240/Sandpoint (among other things :-), so
I may be able to help after the weekend.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Wed, 30 Aug 2000, Dan Malek wrote:

Well, not exactly :-).  The code is actually written with some
assumptions because I couldn't make it do _everything_.  The download
should be located above the address where it is linked to execute.
For example, I download to 0x900000, the code relocates to 0x800000,
then uncompresses the kernel into the base of memory.

This follows the MPC8xx boot model with a larger memory window.
The MPC8xx had more constraints (smaller main memory 8 Mbyte start
up translation), so the load/execution addresses were lower in
memory.  Since the kernel is constantly growing and the 82xx had
a 16 MByte window, I just decided to move everything further up
in the address space.

Anything below the linked execution address (0x800000 in this case)
is considered fair game for allocation by the code, so it could
write over itself or other necessary information (like zImage or the
ramdisk).

Well, if you have a look at PrePboot, it solves all these kind of
problems. On my MVME2600:

- when booting from network, the zImage is loaded very low in memory,
- when booting from disk, it finds itself at top of memory (~15Mb),

what the code does is first to relocate itself where it is originally
loaded (compiled with -mrelocatable) so that it can perform a basic
analyzis of the current memory layout.

Then it moves itself up or down to the top of memory (yes it can have to
move itself down to the top, as contradictory as it seems, it actually
happens quite often), sometimes with partial overlaps, clears its bss,
relocates itself once again (until this point your have to be very careful
with what the code does), and setup a basic memory management system
taking into account firmware needs to avoid stepping on firmware's toes.

At this point, reading OF device tree, decompressing the kernel,
emulating VGA ROM bioses, etc... becomes almost trivial.

	Regards,
	Gabriel.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Using the Abatron BDI2000 and bdiGDB, have you figured out a way to
implement loadable device drivers for hardware using a PowerPC device?

Thanks for your help in advance.

Peter Tympanick
Sales Engineer
Ultimate Solutions, Inc.
===============================
Development Tools for Embedded Systems
Ph: 978-455-3383
Fx: 978-926-3091
Email: ptymps@ultsol.com
WWW: http://www.ultsol.com


----- Original Message -----
From: Gabriel Paubert <redacted>
To: Dan Malek <redacted>
Cc: Matt Porter <redacted>; <redacted>
Sent: Thursday, August 31, 2000 4:13 AM
Subject: Re: Linux on Motorola Sandpoint/PPMC7400



On Wed, 30 Aug 2000, Dan Malek wrote:

Well, not exactly :-).  The code is actually written with some
assumptions because I couldn't make it do _everything_.  The download
should be located above the address where it is linked to execute.
For example, I download to 0x900000, the code relocates to 0x800000,
then uncompresses the kernel into the base of memory.

This follows the MPC8xx boot model with a larger memory window.
The MPC8xx had more constraints (smaller main memory 8 Mbyte start
up translation), so the load/execution addresses were lower in
memory.  Since the kernel is constantly growing and the 82xx had
a 16 MByte window, I just decided to move everything further up
in the address space.

Anything below the linked execution address (0x800000 in this case)
is considered fair game for allocation by the code, so it could
write over itself or other necessary information (like zImage or the
ramdisk).

Well, if you have a look at PrePboot, it solves all these kind of
problems. On my MVME2600:

- when booting from network, the zImage is loaded very low in memory,
- when booting from disk, it finds itself at top of memory (~15Mb),

what the code does is first to relocate itself where it is originally
loaded (compiled with -mrelocatable) so that it can perform a basic
analyzis of the current memory layout.

Then it moves itself up or down to the top of memory (yes it can have to
move itself down to the top, as contradictory as it seems, it actually
happens quite often), sometimes with partial overlaps, clears its bss,
relocates itself once again (until this point your have to be very careful
with what the code does), and setup a basic memory management system
taking into account firmware needs to avoid stepping on firmware's toes.

At this point, reading OF device tree, decompressing the kernel,
emulating VGA ROM bioses, etc... becomes almost trivial.

Regards,
Gabriel.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/