atafb allocates non-STRAM (was Re: kernel 2.2 and d-i)
V Út, 10. 08. 2004 v 11:50, Geert Uytterhoeven píše:
> > > Probably frame buffer devices are initialised later in 2.4 than in 2.2.
> >
> > Why do you think so? I'd say the frame buffer is active since beginning,
> > the penguin is there since first moment.
>
> Because it used to get ST-RAM from atari_stram_alloc(), while you get
> non-ST-RAM?
> When is ST-RAM swap enabled? Before atafb is initialized?
Well. I don't know about atafb initialization much but I do know the
kernel 2.4 changes the screen base address in the middle of the boot,
after all those initializations. As for ST-RAM swap, it would of course
be enabled as the first thing but I have it disabled now.
First, when the kernel starts it prints the following stuff:
Kernel command line: root=/dev/ram video=atafb:vga16 load_ramdisk=1
stram_swap=0 debug=par BOOT_IMAGE=vmlinux
Console: colour dummy device 80x25
Calibrating delay loop... 40.24 BogoMIPS
Memory: 70260k/79872k available (1288k kernel code, 8252k data, 72k
init)
This (80x25) is the original resolution I started the bootstrap with, I
guess, so it didn't have to touch the screen_base. A simple prove is
that ramdisk loaded to the end of ST-RAM (by default) collides with this
active videoram and so the initial kernel messages basically destroy the
ramdisk contents long time before kernel had a chance to unpack it.
Then, a while later (after devfs) it prints:
Console: switching to colour frame buffer device 80x30
Determined 640x480, depth 4
virtual 640x972
fb0: Atari Builtin vga16 frame buffer device, using 304K of video memory
And there, in the "switching to colour frame buffer device" it allocated
the wrong memory and changed the screen_base to point to nowhere.
Petr
Reply to: