Hi,
Slightly less hackish implementation of that hack attached. This (on top of my max_dma_address patch before) does solve the ramdisk related atafb problems without resorting to artificial RAM limits. Stephen, please try this patch.I finally tried this patch and it seems to work fine. I know you said it's not ready to be merged, but it fixes a major d-i problem I'm having.
My major problem with that patch is that it introduces a memory leak because memory allocated from the ST-RAM reserve pool cannot be freed. For the intended purpose (i.e. framebuffer) this does not matter. If it gets to be a problem, ST-RAM memory with the BLOCK_POOL flag set could be put back on the corresponding free list. (On alloc, a suitable chunk is looked for on the free list, but there's no code to actually put something back on the free list. I'd be kind of embarassed to ask for such code to be merged...)
BTW: The same 'memory leak' is present for memory allocated before mem_init was run, so that's really not too serious.
The latest d-i images seem to require aranym FastRAM to be 48M which invokes low memory mode. I'd rather not have to go there. :)
Well, that kind of rules out installing on a TT ever again...Did you try whether this patch actually does require the maxdma patch as well? I'm unsure about that right now.
Anyway, the patch seems to be required for ramdisk use, so I better clean it up one way or the other. Geert - do we need to be able to free allocated ST-RAM? Otherwise, I'd just remove the dead freelist stuff and submit that.
Cheers, Michael