> On May 17, 2016, at 4:08 PM, Foster, Matthew I <matthew.i.fos...@intel.com> 
> wrote:
> 
> Thanks Ersek, 
> 

Laszlo... 

> I did change my code to match what you have here as far as the allocation. I 
> did some more debugging and registered up a callback in exit boot services, 
> and did an integrity check of the memory I previously allocated and put the 
> ramdisk in. I checked the memory right before I call loadimage (to launch the 
> kernel), and then again I check in the callback during exit boot services. So 
> some point between the memory actually does get changed. So it might be 
> something happening during exit boot services. 
> 
> Just a question, after allocating that memory as you mentioned below, other 
> code should not be able to allocate and use that same address range right?

The EFI Memory Map is well defined and you can read about it in Section 6.2 
Memory Allocation Services. 

> Even during exit boot services?
> 

I assume you mean after ExitBootServices() as it is not good form to allocate 
memory in an EFI ExitBootServices Event. 

EFI_BOOT_SERVICES.AllocatePool(), as well as blocks that the firmware is using 
for its own purposes. The memory map is only used to describe memory that is 
present in the system. The firmware does not return a range description for 
address space regions that are not backed by physical hardware. Regions that 
are backed by physical hardware, but are not supposed to be accessed by the OS, 
must be returned as EfiReservedMemoryType. The OS may use addresses of memory 
ranges that are not described in the memory map at its own discretion.

Thanks,

Andrew Fish


> 
> 
> -----Original Message-----
> From: Laszlo Ersek [mailto:ler...@redhat.com] 
> Sent: Tuesday, May 17, 2016 11:41 AM
> To: Foster, Matthew I <matthew.i.fos...@intel.com>
> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>
> Subject: Re: [edk2] Using the Shell to launch a kernel using a RAMDISK
> 
> On 05/17/16 19:13, Foster, Matthew I 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?
> 
> Please see the following messages in the list archive:
> 
> http://thread.gmane.org/gmane.comp.bios.edk2.devel/10766
> http://thread.gmane.org/gmane.comp.bios.edk2.devel/9885/focus=9923
> 
> In a nutshell (basically just summarizing what others have described):
> - Reserved memory is needed only if you want to boot off of a RAM disk
>  (as opposed to just playing with the filesystem on it while in the
>  UEFI shell or similar).
> - If you want to boot off of a RAM disk, then reserved memory *is*
>  necessary.
> - The RAM disks created with the firmware setup forms (HII) are not
>  meant for booting off of.
> 
> So, you should do something like this:
> 
>  EFI_STATUS           Status;
>  EFI_PHYSICAL_ADDRESS KernelRootFsAddress;
> 
>  Status = gBS->AllocatePages (
>                  AllocateAnyPages,
>                  EfiReservedMemoryType,
>                  EFI_SIZE_TO_PAGES ((UINTN)KernelFsSize),
>                  &KernelRootFsAddress
>                  );
>  if (!EFI_ERROR (Status)) {
>    VOID *KernelRootFs;
> 
>    KernelRootFs = (VOID *)(UINTN)KernelRootFsAddress;
>    /* ... */
>  }
> 
> Thanks,
> Laszlo
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to