Re: aranym vs atafb
> > IIRC any addresses in that range (i.e. above 0xffffff) are aliased down to
> > fit in 24 bit (ST-RAM on the Falcon only decodes 24 bit, and the VIDEL
> > needs to use ST-RAM). Basically, you used up all available ST-RAM with the
> > ramdisk and now force the framebuffer to use an invalid address (one which
> > you can perfectly well write to, but the VIDEL cannot read from there).
> >
> > What you see on the screen is whatever is located at address 0x00700000
> > and thereabouts (may be kernel memory, may be data/buffer cache).
>
> That totally makes sense.
Well, no - that totally is borked hardware design. The Falcon is an
especially sick beast but the TT had the same limitation, only a
different video chipdet.
OTOH, borked hardware design may well have been a hallmark of m68k
personal computers (look at the Mac for the real weird stuff). Whatever.
> > The ramdisk load code needs to make sure a ramdisk is not loaded where it
> > might interfere with other uses of ST-RAM (i.e. frame buffer or DMA bounce
> > buffers for SCSI). Where does the ramdisk get loaded at, anyway? Is the
> > kernel loaded in ST-RAM also?
>
> How do I find out?
That's a parameter to ataboot (or the equivalent boot code in ARAnyM. IIRC
-s loads the kernel in ST-RAM. If there is no code to load the ramdisk in
TT-RAM we'd better add code to move it around after the kernel started to
initialize ....
On second thought, that would be a sick hack deserving of m68k hardware
designers. We did already have a provision to reserve a chunk of ST-RAM
for special purposes like framebuffer, you just have to disable that with
2.6 kernels (explicitly, by adding stram_swap=0 to the kernel parameters).
That code needs to be reactivated, it seems. Plus the bootstrap needs to
take the size of reserved ST-RAM into account when loading the initrd
image, I guess. At least we can then figure out that there is not enough
ST-RAM free to run Linux, and bail out. Or kick the ramdisk out of the way
instead :->
> I put all the relevant parts including the boot log at
> <http://people.debian.org/~smarenka/d-i/aranym/>.
Thanks, all I see from that is the ramdisk driver is initialized after the
framebuffer, but the ramdisk (non-compressed??) was already present prior
to that. I'll grab your kernel and ramdisk and play with it for a bit on
my Powerbook - incidentially, how much FastRAM have you specified for
ARAnyM?
> > We need to load them somewhere else, FWIS. Meaning in TT-RAM.
>
> Is that kernel hacking or a parameter?
A bootstrap parameter, rather. Might be easy enough to add in ARAnyM. If
that works (i.e. loading the ramdisk where it won't interfere with the
kernel drivers' needs) we could think about adding some code to relocate
the ramdisk. At the time when the framebuffer loads, the kernel memory
management has already been initialized so it's going to be more than just
moving stuff around and adjusting a few pointers.
Might be best to detect this situation early (in the early arch init) and
fix it before it really hurts. I'll look what I can come up with - for
anything memory management related I'd need RomanZ's help anyway.
Michael
Reply to: