Re: Booting Sandpoint 8240??

On Thu, Feb 22, 2001 at 01:26:06PM -0500, tsombakos, mark wrote:

  Well, I got the thing to boot, though now I don't quite understand it.
  I ended up changing the address used in zsrec and the "go" address
  to "0x90000" instead of "0x900000".  I saw the memory map in the
  DINK32 manual that the "Start of user memory" is at 0x90000.  I figured
  it was a typo in the HHL CDK manual. So, life was good.  Until
  I realized the bootloader relocates to 0x80000. Now I'm confused again.

DINK32 loads the linear array of bits that comprise the zImage at 0x90000
(576KB).  The standard bootloader always relocates to 0x800000 (8MB) and
continues running.  The bootloader then uncompresses the included
vmlinux.gz and places it at the start of RAM (0MB).

DINK32_MAX >>go 90000
loaded at:     00090000 000A4E20
relocated to:  00800000 00814E20
zimage at:     0009B000 0011B486
relocated to:  00815000 00895486

avail ram:     00400000 00800000


Since "avail ram" is 400000-800000, should I run srec -s (something <
800000)?
I know I read that it should be higher than the relocated image ...

You don't need to do a thing, all is well. :)

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

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

Matt Porter wrote:

You don't need to do a thing, all is well. :)

Ummmm....I think this should work, but those addresses weren't my
original intention.  The original "design" was to use 0x00800000
as the link address, and 0x00900000 as the load address.  The code
will copy itself down to the 8 Meg location, then uncompress as you
describe.  I don't know if this is still the case, but the uncompress
code used to make some assumptions (take some liberties) about using
the space between the load address and execute address for temporary
storage.  If you load below the execute address, this address
arithmetic is screwed up and I'm not sure what would happen.

With the 2.4 kernel you have to allow almost 1.5 Mbytes of space
from the start of RAM for the kernel to do its work, and not write
over some boot information (command line or initrd info) that the
initial bootloader may have dropped into magical memory locations.
Trying to run a bootloader under the 2M boundary is risky, and it
won't run in under the 1.5 M boundary.


	-- Dan

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