Shouldn't passing the address and size to the kernel command line be enough for the kernel not to walk over it? Is there best known method for setting up a ramdisk in the BIOS and allowing the kernel to use it?
console=ttyS0,115200n8 loglevel=8 rootwait root=/dev/mtdblock0 mtdparts=RAM0:0x00F42000@0x00000000(RootFileSystem-RAM) phram.phram=RAM0,0x0C235000,0x00F42000 memmap=0x00F42000$0x0C235000 -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Tuesday, May 17, 2016 10:24 AM To: Foster, Matthew I <[email protected]> Cc: [email protected] Subject: Re: [edk2] Using the Shell to launch a kernel using a RAMDISK > On May 17, 2016, at 10:13 AM, Foster, Matthew I <[email protected]> > wrote: > > I am trying to boot a linux kernel from within the shell that is using a > ramdisk filesystem. I allocate memory in the shell for a ramdisk. I read the > filesystem out of flash memory after allocating memory in the shell: > > KernelRootFS = AllocatePages(((KernelFSSize/FOUR_KB_ALIGNED) +1)); > > I then use that address (KernelRootFS) to pass it to the kernel command line > to tell there kernel where the filesystem is in memory. When it goes to use > the ramdisk at some in the kernel boot, the ramdisk appears to be corrupted > and I get SQUASHFS errors. > > If I do that exact procedure in BdsBoot, I do not see the corruption. Which > leads me to believe the shell might be somehow trampling over the memory. > Does anyone have any ideas on what I might do, or what could be going on here? > The Shell is likely not trampling the memory. It is more likely the OS is trampling the memory. Your library call is allocating EfiBootServicesData. When the OS Boots it calls ExitBootServices() to take over managing the system resources from EFI and at this point EfiBootServicesData is basically freed back for use by the OS. The Shell vs. BDS probably just change the address that gets allocated and moves it a range that shows the conflict. Thanks, Andrew Fish _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
