On 05/18/16 16:09, El-Haj-Mahmoud, Samer wrote: > 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)?
Probably on the closed USWG mailing list, and/or attached to (similarly closed) Mantis tickets, as ECR documents. According to the Mantis changelog at the beginning of the UEFI spec v2.6, the relevant tickets are: 1268 RAM Disk UEFI Device Path Node 1466 UEFI Ram disk protocol https://mantis.uefi.org/mantis/view.php?id=1268 https://mantis.uefi.org/mantis/view.php?id=1466 ... Yep, I can see some docs attached to those. Log in to Mantis and peruse them. :) Thanks Laszlo > 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
