Re: Relocating an amigappc kernel by the boot loader

[Frank Wille <frank%phoenix.owl.de@localhost>]

On Tue, 16 Feb 2010 16:46:02 +0100
Ignatios Souvatzis <is%netbsd.org@localhost> wrote:

> > [...] Programs which are accessing the kernel's
> > nlists through the kvm(3) interface fail miserably, because the
> > file /netbsd is not relocated to the same address space as the
> > current kernel in RAM.
> 
> I don't think this is a really bad problem. After all, some of
> NetBSD's install media don't have any valid kernel on / at all;
> same for some netboot setups. Only a few commands fail; normal use
> and setup (including networking etc.) is proven to work, because
> install works that way.

Agreed. But some of those commands make my installation drop into ddb now
(I have to check if it's a real panic or a Debugger() call). That's not
nice to watch.


> Now, for the added comfort - can we do the following?
> 
> 1. make your kernel relocate for it's compile-time starting address;
> this is just a constant to add (and it will be relocated for you,
> too), so you can execute 2. repeatedly.

And the prefered compile-time starting address would be? Maybe 0x8000000,
to make at least CSPPC systems work immediately without patching the kernel?

Ok, I enhanced my boot loader yesterday, so it can relocate a kernel with
any compile-time start address (which was a bit more complex than relying
on zero).


> 2. provide a tool (hm, would a wrapper around objcopy be enough?) to 
> relocate the kernel to the address actually used.

I can easily extract such a tool out of my boot loader, so we don't have
to rely on any GPL tools.

I guess the relocation tool should work under NetBSD, not AmigaOS (or
both?). Maybe we could even check the kernel automatically during multi-
user boot and relocate it, when its VMA doesn't match the loaded kernel?


> (Actually - if BlizzardPPC had a fixed address, I wouldn't bother with
> 2., but provide fora method to build the kernel for a starting
> address as a kernel option. But as I understand there are several
> possibilities depending on memory configuration?)

Lots. A RAM module in bank 1 will be mapped downwards from 0x?8000000 and
a module in bank 2 will be mapped upwards from 0x?8000000. The '?' can be
any of 4, 5, 6, 7, depending on the size of RAM (I think).

At least all the RAM will always be in a single 256MB segment, so I can
BAT-map it.


> > - Turning on the MMU early to translate all addresses doesn't work
> > either, as exception handling and pmap may disable the MMU.
> 
> It has been suggested to me to "fix the pmap so nothing bad happens 
> then." I don't remember whether we'd need additional cache/tlb
> flushing, in which case this woul be too expensive...

I would rather not touch pmap and risk harm for any other PPC port, just
for two or three amigappc users. :)

-- 
Frank Wille