[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: aranym vs atafb

On Fri, Dec 28, 2007 at 04:09:21AM +0100, Michael Schmitz wrote:

> (found in arch/m68k/kernel/setup.c)
> That address is a virtual address, but (at least on my setup) the kernel
> virtual addresses are identity mapped to physical. So the ramdisk
> (compressed) resides in TT RAM or FastRAM. The shit hits the fan right
> here, I presume:
> checking if image is initramfs...it isn't (bad gzip magic numbers); looks
> like an initrd
> Freeing initrd memory: 2025k freed
> (happens in init/initramfs.c:populate_rootfs() as it were)
> That does probably steal our precious ST-RAM space.

Would using an initramfs help? I can certainly build an initrd that way
(how well tested that all is on m68k is a different beast!).

> The good news: the ramdisk data is already where I suggested it should be,
> so no changes to the bootstrap needed. The bad news: populate_rootfs()
> just dumps the data to the buffer cache by generic sys_open()
> and sys_write() - we cannot mess with those. So no easy workaround that I
> can see.
> I guess I'll have to just allocate the required ST-RAM for atafb early, or
> make the stram_swap allocator work again, at least as DMA memory allocator
> (swapping just won't work anymore without me learning more about VFS that
> I can currently spend time on). I'll think about it some more ...

I guess I stepped in it good!



Stephen R. Marenka     If life's not fun, you're not doing it right!

Attachment: signature.asc
Description: Digital signature

Reply to: