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
