Samer, I am ok to add an item/option to allow user choose ramdisk memory type. But I don't know how to organize the form to show that straightforwardly, for example, how to add an item for those chosen by File Explorer. Look forward to see your patch:)
Thanks Feng -----Original Message----- From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hpe.com] Sent: Wednesday, May 18, 2016 10:10 PM To: Laszlo Ersek <ler...@redhat.com>; Andrew Fish <af...@apple.com>; Foster, Matthew I <matthew.i.fos...@intel.com>; Tian, Feng <feng.t...@intel.com> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com> Subject: RE: [edk2] Using the Shell to launch a kernel using a RAMDISK Thanks Laszlo! I missed that thread. I did not participate in the original design either (where is the original design anyway? Is it public on the EDK2 list)? Feng, Do you mind if I submit a patch to update the HII to support allocating Reserved memory RAM Disks? This will help a lot in troubleshooting. Thanks, --Samer -----Original Message----- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo Ersek Sent: Wednesday, May 18, 2016 9:04 AM To: El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>; Andrew Fish <af...@apple.com>; 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/18/16 15:48, El-Haj-Mahmoud, Samer wrote: > Does it make sense to update the RAM Disk HII (at > \MdeModulePkg\Universal\Disk\RamDiskDxe) to allow creating a RAM Disk > of Type Reserved, for this kind of testing? That's exactly what I suggested in http://thread.gmane.org/gmane.comp.bios.edk2.devel/10766/focus=10770 Namely, > [...] I think this question should be exposed with a checkbox on the > form: "will you want to boot from this RAM disk?" And then the answer > to that question should determine the type of memory the RAM disk is > allocated from. but it was not approved; Feng said later in the thread, > [...] For those ramdisk created from Ramdisk HII, the original design > intention is only for boot time use. I had not participated in the design, so I didn't question it. Thanks Laszlo > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Laszlo Ersek > Sent: Wednesday, May 18, 2016 4:39 AM > To: Andrew Fish <af...@apple.com>; 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/18/16 01:16, Andrew Fish wrote: >> >>> On May 17, 2016, at 4:08 PM, Foster, Matthew I <matthew.i.fos...@intel.com> >>> wrote: >>> >>> Thanks Ersek, >>> >> >> Laszlo... > > That's right, thanks Andrew :) > >>> 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. > > Yeah, once allocated (and not freed), those pages should never be handed out > to any other agent calling gBS->AllocatePool() or gBS->AllocatePages(). > > The memory corruption issue is very interesting. I have faced similar > earlier, several times. I've developed methods for trying to dealing > with it ("develop methods" is a fancy expression for just a few basic > ideas, of course :)) > > - The integrity check you mention. Since we are not talking about a > malicious attacker, just (likely) a genuine bug somewhere, the > CalculateCrc32() boot service is usually helpful in pointing out corruption. > > - CRC32 can also be computed on a set of smaller blocks, not just the entire > image. I usually don't try to keep the CRCs in an array (for later > comparison) -- instead I dump the CRCs to the debug log, and compare the > values (before vs. after) with text processing utilities. > > - Once you managed to narrow down the location of the corruption a little > bit, you can hexdump the entire block, and compare its before / after > contents. > > - Occasionally it can help to look at the ASCII representation of the > differring blocks. For example, many structures in edk2 start with a 32-bit > or 64-bit signature (see the SIGNATURE_32 and SIGNATURE_64 macros), and the > signature is usually an abbreviation of English words in ASCII. If you find > some signatures, you might be able to deduce where they come from (IOW, the > nature of the data discloses the origin of the data). > > [snip] > > 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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
