Re: aranym vs atafb
Hi,
> I've been trying to get d-i initrds to work with aranym without
> trashing the screen [0]. I noticed something interesting in my testing
> today.
>
> [0] <http://people.debian.org/~smarenka/d-i/aranym/>
>
> With the same kernel (2.6.18-4) and args ...
>
> Args = root=/dev/ram load_ramdisk=1 ramdisk_size=20000 debug=par
> video=atafb:vga16 stram_swap=0 console=tty
> debian-installer/framebuffer=false init=/bin/sh
>
> The result is a trashed screen when atafb loads.
>
> | atafb: screen_base 01700000 real_screen_base 01700000 screen_len 311296
> | Determined 640x480, depth 4
> | virtual 640x972
> | Console: switching to colour frame buffer device 80x30
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).
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?
> If I drop the Ramdisk = parameter from the aranym config, atafb loads as
> follows, and works just fine.
>
> | atafb: screen_base 00c80000 real_screen_base 00c80000 screen_len 311296
> | Determined 640x480, depth 4
> | virtual 640x972
> | Console: switching to colour frame buffer device 80x30
That screen base address is fine to use for atafb.
> I tried all the atafb configurations listed, but I couldn't get a
> working result and have a ramdisk. The Floppy setting doesn't trash
> the screen but we don't have any initrd's small enough.
We need to load them somewhere else, FWIS. Meaning in TT-RAM.
> I don't suppose we can build a bootable cdrom for atari?
Uh, nope. CD-ROM drivers are a bad can of worms as it were, no idea what
would even be supported by the CT60 (and it's all closed source). Unless
you count booting from MiNT (assuming that can even be done).
Michael
Reply to: