RE: Questions about 8xxrom

RE: Questions about 8xxrom

[Brown, David (dbrown03)]

This thread has become interesting, but I think that my original message was
maybe not understood.  Here are the highlights:

a) I originally got 8xxrom-0.3.0 working by adding a GO command:  GO
0xFF810000 will jump to location 0xFF810000 where zImage.initrd's code
starts.  That works fine for me and I'm happy with it.  But 8xxrom was
intended to work with disk in addition to flash, so I started exploring why
ELF-loading didn't work.

b) I found several problems in 8xxrom-0.3.0 regarding loading an ELF image
from the beginning of a disk.  I was hoping some past/present/future 8xxrom
developer was lurking on this list and I could start a conversation (off of
the list probably) about this.

c) The problem with initrd decompression was that the board descriptor data
was copied explicitly to 0x200000 which happened to be in the middle of
initrd.  This happens in arch/ppc/mbxboot/misc.c:
	cmd_line = (char *)(0x200000);
For me at least, this change worked wonders:
	if ((load_addr >= 0x10000) && (load_addr <= 0x210000))
		cmd_line = (char *)(load_addr - 0x10000);
	else
		cmd_line = (char *)(0x200000);
This assumes that the 64K directly under the load address is RAM that is
unused.  That assumption may not be valid for everyone.

Regarding the questions about the load sequence, I think this has been
covered many times on this list and elsewhere.  The load sequence is
something like this:

1) The original boot loader initializes the hardware and locates the Linux
image.  If the Linux image is on a disk, the boot loader copies the Linux
image to RAM.  Otherwise, if the Linux image is in flash, the boot loader
can just jump to the flash address, probably saving a bit of time and
definitely needing less RAM.

2) Linux's loader (the code in arch/ppc/mbxboot) initializes a serial port
and the board descriptor.  It finds RAM for the command line, the board
descriptor, the zImage, and the initrd.  If necessary, it copies zImage and
initrd into RAM.

3) Linux's loader uncompresses zImage into RAM and jumps to it.

4) The actual Linux kernel boots.  It finds an initrd in RAM and
uncompresses it to create a RAMdisk.  The original initrd RAM is freed.
Here also, the arch/ppc/8xx_io/uart.c takes over the serial port handling
and many other things happen.

We shouldn't dabble with the uncompressing of initrd.. that's standard
Linux.
We don't have much room to improve the linux loader in arch/ppc/mbxboot.  It
does a good job juggling various memory requirements for an ever-growing
assortment of target boards which have different memory layouts.  The code
in arch/ppx/mbxboot shouldn't be specialized for each board.  That is the
job of the original boot loader such as 8xxrom.  In that light, I have been
looking at 8xxrom to try to improve it beyond what I require.


> -----Original Message-----
> From: Dan Malek [mailto:dan@netx4.com]
> Sent: Monday, May 29, 2000 5:48 PM
> To: Graham Stoney
> Cc: Brown, David (dbrown03); linuxppc-embedded@lists.linuxppc.org
> Subject: Re: Questions about 8xxrom
>
>
>
> Graham Stoney wrote:
>
> > > After all that, it still fails, while decompressing initrd.
>
> I must have missed this.....what is the error?  Post the few lines
> that show the actual/relocated debug messages for the zImage portions.
>
> > I suspect Dan's comments last week explain that this
> doesn't currently work:
>
> The word "currently" is quite correct.  It was never designed to
> decompress directly from Flash.
>
> > Dan, any chance you could clarify what would need to be
> done in order to
> > decompress the initrd directly from flash?  We also want to do this
> > eventually, and would like to avoid the wasted copy to RAM.
>
> Nothing needs to be done.  The code in arch/ppc/mbxboot/misc.c will
> allocate a RAM area and copy the initrd from Flash to RAM.
> The address
> and size of this is given to the kernel when it is started.
>
> The functions for uncompressing and using initrd are part of
> the kernel
> and common to all architectures.  It assumes the initrd is in RAM,
> which is also common to all architectures.  I don't intend to change
> this, and I don't see any real reason either.  The product dependent
> boot will place a copy of initrd in RAM, which could be from
> a network,
> CDROM, Floppy, Flash ROM, PCMCIA disk, etc.  The kernel isn't
> responsible
> for placing it there, only for using it.  It is a common feature for
> all systems, and thankfully someone made it real easy for us
> to use it.
>
>
> 	-- Dan
>

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

Re: Questions about 8xxrom

[Dan Malek]

"Brown, David (dbrown03)" wrote:

> .....  But 8xxrom was
> intended to work with disk in addition to flash, so I started exploring why
> ELF-loading didn't work.

There have been lots of changes since I originally wrote the code.  I
didn't have the disk loading, but I can speculate on the trouble.

If you are trying to load zImage, it simply isn't going to work.  I
am exhausted at explaining why, but one more time.......

The zImage is simple.  It is not an ELF image.  Strip the 64k header
from the image.  Load the bits at or above 0x00200000.  Jump to the
first instruction.

If you are loading from a disk, which I presume has a file system, you
know the size of the file.  Just load it.  I know originally the loader
knew it had to load at or above 0x00200000.......It also knew it was
loading a zImage, and if the ELF header was found knew what it could
believe or not and how to start a zImage.  I don't know what the code
looks like today, as I am still using the old stuff from years ago.


> c) The problem with initrd decompression was that the board descriptor data
> was copied explicitly to 0x200000 which happened to be in the middle of
> initrd.

It shouldn't be.  You didn't follow the instructions.....Load the zImage
at or above 0x00200000, jump to the first instruction.  FYI, 8260 is
load at or above 0x00480000.



	-- Dan

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

Re: Questions about 8xxrom

[Duncan Palmer]

>
> "Brown, David (dbrown03)" wrote:
>
> > .....  But 8xxrom was
> > intended to work with disk in addition to flash, so I started exploring why
> > ELF-loading didn't work.

Dan Malek wrote:
>
>
> The zImage is simple.  It is not an ELF image.  Strip the 64k header
> from the image.  Load the bits at or above 0x00200000.  Jump to the
> first instruction.
>
> If you are loading from a disk, which I presume has a file system, you
> know the size of the file.  Just load it.  I know originally the loader
> knew it had to load at or above 0x00200000.......It also knew it was
> loading a zImage, and if the ELF header was found knew what it could
> believe or not and how to start a zImage.  I don't know what the code
> looks like today, as I am still using the old stuff from years ago.

I posted a couple of patches to Raphael Bossek (the guy who maintains
8xxrom now) a couple of months back which are really worth applying
(they add support for RPX classic boards, clean some things up
considerably, and make it cleaner to add support for new boards). These
live on raphaels site at www.s4l.de, or mine at www.zip.com.au/~dunk

These patches include little chunks of code to load images from flash
(safely ignoring all elf headers ;)). From memory, the code which loads
elf images from disk expects what is in the elf header to be correct
(which is obviously a broken assumption a lot of the time).

Dunk

PS. Please cc: any replies to me as I'm on holidays at the moment, and
so am not subscribed to the list.

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

Questions about 8xxrom

[Brown, David (dbrown03)]

I've been using 8xxrom-0.3.0 to start up my board.
Since I couldn't get the ELF reading to work,
I added a "go" command..
"go 0xff810000" is what I use to start Linux.

Now, I've gone back to try the ELF method.  My flash starts at FF800000, and
the zImage.initrd is stored at the beginning of flash.  I found three things
that had been in my way:
1) rom_bread() second parameter was edited sometime to be 0-based, but elf.c
still wants it to be 1-based.  I don't know the proper fix, but I edited
rom_bread() to be 1-based again.

2) After elf.c reads the image into RAM, it sets eh = bp; but bp was
modified during the read loop.  Better to set eh = zstart.

3) 500000 bytes is not enough for zImage.initrd.  I made it 2000000 (elf.c).

After all that, it still fails, while decompressing initrd.
I think the problem is that the board information overwrites part of initrd,
as shown in the boot text:

rom:0:/> bootz
No filesystem found

entry 0x100000, phoff 0x34, shoff 0x1e9064
phnum 0x1, shnum 0xa
p_offset 0x10000, p_vaddr 0x100000, p_paddr 0x100000
p_filesz 0x6318, p_memsz 0xc318
Loading at 0x10d000
Starting 0x11d000
loaded at:     0011D000 00129318
relocated to:  00100000 0010C318
board data at: 00FFF000 00FFF138
relocated to:  00200100 00200238	<= oops, why here?
zimage at:     00124000 00184034
initrd at:     00184034 002F6023	<<
avail ram:     002F7000 01000000

I'm continuing to look at the code to see why the initrd gets overwritten.
I'm using the arch/ppc/mbxboot loader.

I see that 8xxrom is supposed to be on sourceforge as ppcboot, but nothing
is on the website yet, so I'm asking here.

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

Re: Questions about 8xxrom

[Dan Malek]

"Brown, David (dbrown03)" wrote:

>
> Now, I've gone back to try the ELF method.  My flash starts at FF800000, and
> the zImage.initrd is stored at the beginning of flash.


As I have said many times, and as recently as yesterday, the zImage
(especially with initrd) was never intended to be a proper ELF image.
It is the most compressed set of bits possible to minimize storage
in a device.  The ELF header is an artifact of the tools used to create
zImage, and should simply be stripped.  The zImage is a "self extracting"
image that is loaded into ram or flash rom.  When you are loading this
from a file system or via TFTP, you know the size to load into memory.
If you are loading from some medium, like a raw flash card, you have
to make some assumptions about the size or tack a few bytes on the front
that indicate the length.  Most systems have some custom boot loader
that requires a special, very small header, or they just jump to the
start of the image in flash rom.


	-- Dan

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

Re: Questions about 8xxrom

[Graham Stoney]

Hi David,

"Brown, David (dbrown03)" writes:
> My flash starts at FF800000, and the zImage.initrd is stored at the
> beginning of flash.
...
> After all that, it still fails, while decompressing initrd.

I suspect Dan's comments last week explain that this doesn't currently work:

Dan Malek wrote:
> A very important note.....Because of the initrd logic in the Linux
> kernel, you can't uncompress a ram disk from Flash rom, it must be
> in RAM (pages are discarded when this is done).  The "magic" functions
> assume if loaded above 16 Mbytes, and a ram disk is attached, the
> ram disk portion of the image must be copied to ram.  If loading in
> ram above 16 Mbytes this will result in an unnecessary copying of
> the ram disk image, so it is probably best to load the image somewhere
> below 16 Mbytes if in memory.  There are lots of other assumptions
> and "special" memory locations used within these functions to support
> a variety of loading options on various boards and products.  It is
> best you realize this is a bunch of bits for production use and don't
> try to modify it for something else.  Lots of people depend on this
> image as it is.

Dan, any chance you could clarify what would need to be done in order to
decompress the initrd directly from flash?  We also want to do this
eventually, and would like to avoid the wasted copy to RAM.

Thanks,
Graham
--
Graham Stoney
Principal Hardware/Software Engineer
Canon Information Systems Research Australia
Ph: +61 2 9805 2909  Fax: +61 2 9805 2929

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

Re: Questions about 8xxrom

[Dan Malek]

Graham Stoney wrote:

> > After all that, it still fails, while decompressing initrd.

I must have missed this.....what is the error?  Post the few lines
that show the actual/relocated debug messages for the zImage portions.

> I suspect Dan's comments last week explain that this doesn't currently work:

The word "currently" is quite correct.  It was never designed to
decompress directly from Flash.

> Dan, any chance you could clarify what would need to be done in order to
> decompress the initrd directly from flash?  We also want to do this
> eventually, and would like to avoid the wasted copy to RAM.

Nothing needs to be done.  The code in arch/ppc/mbxboot/misc.c will
allocate a RAM area and copy the initrd from Flash to RAM.  The address
and size of this is given to the kernel when it is started.

The functions for uncompressing and using initrd are part of the kernel
and common to all architectures.  It assumes the initrd is in RAM,
which is also common to all architectures.  I don't intend to change
this, and I don't see any real reason either.  The product dependent
boot will place a copy of initrd in RAM, which could be from a network,
CDROM, Floppy, Flash ROM, PCMCIA disk, etc.  The kernel isn't responsible
for placing it there, only for using it.  It is a common feature for
all systems, and thankfully someone made it real easy for us to use it.


	-- Dan

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