I like the idea of passing in the flash address of the initrd rather than
the DRAM address of a copy. No reason to copy the data an extra time.
However, there are three places in the kernel that need to be fixed to make
this work. If the initrd is in flash, then the kernel should not
reserve_mem or free_mem the initrd area. I worked around them with ifdefs,
but we need a more general fix. (What we really need is a compressed, rw
flash filesystem, but that's another story.)
find_bootmap_pfn (in arch/arm/kernel/setup.c) turns off initrd if it's not
in physical dram.
setup_bootmem calls reserve_mem, which fails with a data abort if the initrd
is not in dram.
rd_release calls free_page on the initrd.
If we augment the meminfo field with the addresses of flash, then we can fix
the first two problems. rd_release could be fixed by having it unreserve
and free the memory if PageReserved() is true.
-Jamey Hicks
-----Original Message-----
From: Nicolas Pitre [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 11, 2000 11:07 PM
To: Gaixia Zhang
Cc: ByungGi Baek; [EMAIL PROTECTED]
Subject: Re: Adress of rd_start/initrd_start on EBSA285
On Tue, 11 Apr 2000, Gaixia Zhang wrote:
> This works, but it isn't very clever in the way it enough RAM for the
> compressed ramdisk is available at a fixed address and wont be overwritten
> by the initialising kernel.
>
> I don't know how best to improve this. I'd like to add a routine to
> arch/arm/kernel/setup.c to copy the ramdisk image from FLASH to RAM if
> initrd_start is a FLASH address, but I don't know if that would be the
> right thing to do.
I don't think so.
Probably the best is to set initrd_start so it points directly to your
initrd in flash. Of course the flash must be mapped. Then prevent
free_initrd_mem() from freeing memory that isn't actually RAM pages.
Nicolas
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++ Please use [EMAIL PROTECTED] for
++
++ kernel-related discussions.
++
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++ Please use [EMAIL PROTECTED] for ++
++ kernel-related discussions. ++
