Thanks Laszlo. I am familiar with those documents, and did review them in USWG when the feature was introduced. And most of the content of those ECRs is now publically available in the UEFI Spec. None of them discuss or hint to an HII menu or its design.
-----Original Message----- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Wednesday, May 18, 2016 9:28 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>; feng.t...@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 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
