> > 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
