Re: kernel 2.2 and d-i
V Út, 10. 08. 2004 v 10:00, Geert Uytterhoeven píše:
> > Real disappointed by the kernel 2.4.26 that allocates the videoram
> > randomly and often completely out of 24-bit VIDEL range I have given
> > last try with the 2.2.x kernel. And what a surprise - at the moment
> > where kernel 2.4.x turned font colors to red and got stuck the 2.2.x
> > cleared the screen and offered language selection!
>
> 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.
> But (looking at the code in 2.2.10) atafb does call atari_stram_alloc() to
> alloc memory? And atari_stram_alloc() returns memory that's not ST-RAM?
I have posted the numbers yesterday, IIRC. It was like f80000 virtual
which was 1b80000 physical and that is way behind the end of ST-RAM
(400000) or even behind the 24-bit VIDEL address boundary (1000000).
Please see the comments in stram.c:
first: "get_dma_pages() shouldn't be used on Atari anyway anymore
(better use atari_stram_alloc()"
second: "If mem_init() already has been called, and ST-RAM swapping is
not enabled, the only possibility is to try with __get_dma_pages(). This
has the disadvantage that it's very hard to get more than 1 page, and it
is likely to fail :-("
Please note that I haven't traced the __get_dma_pages yet but from the
comments in stram.c it seems that it can fail and that I shouldn't be
surprised when it does. Note that for VIDEL videoram I might easily need
up to 870 kB of contiguous ST-RAM memory (that would be for 896x640 in
256 colors)... But it failed when I asked for about 300 kB of RAM only.
How to fix this? Do we need to fix the ST-RAM swap space? Or should the
kernel allocate ALL remaining ST-RAM as a static pool before the
mem_init and later use this pool for atari_stram_alloc?
Petr
Reply to: