Re: aranym vs atafb
> > > 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 ....
After consulting the source, I found the hidden bit of information in the
log:
Linux version 2.6.18-4-atari (Debian 2.6.18.dfsg.1-11) (waldi@debian.org)
(gcc version 3.3.6 (Debian 1:3.3.6-15)) #1 Thu Feb 22 23:37:58 CET 2007
Atari hardware found: VIDEL STDMA-SCSI ST_MFP STND_DMA YM2149 PCM CODEC
DSP56K ANALOG_JOY Blitter tried to read byte from register ff8a00 at
0072ca
BLITTER IDE TT_CLK FDC_SPEED
initrd: 01000000 - 017e9000
(found in arch/m68k/kernel/setup.c)
That address is a virtual address, but (at least on my setup) the kernel
virtual addresses are identity mapped to physical. So the ramdisk
(compressed) resides in TT RAM or FastRAM. The shit hits the fan right
here, I presume:
checking if image is initramfs...it isn't (bad gzip magic numbers); looks
like an initrd
Freeing initrd memory: 2025k freed
(happens in init/initramfs.c:populate_rootfs() as it were)
That does probably steal our precious ST-RAM space.
The good news: the ramdisk data is already where I suggested it should be,
so no changes to the bootstrap needed. The bad news: populate_rootfs()
just dumps the data to the buffer cache by generic sys_open()
and sys_write() - we cannot mess with those. So no easy workaround that I
can see.
I guess I'll have to just allocate the required ST-RAM for atafb early, or
make the stram_swap allocator work again, at least as DMA memory allocator
(swapping just won't work anymore without me learning more about VFS that
I can currently spend time on). I'll think about it some more ...
Michael
Reply to: