On 05/18/16 16:31, El-Haj-Mahmoud, Samer wrote: > Thanks Laszlo. I am familiar with those documents, and did review > them in USWG when the feature was introduced.
Ah, great, then you know much more about the background and use cases than I do :) > 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. That sounds promising. If the HII checkbox for the memory type is not counter-design, then I guess it shouldn't be too hard to reach consensus, and add it. (Famous last words? :)) Not that I'm volunteering! :) Thanks Laszlo > > > > > -----Original Message----- From: Laszlo Ersek > [mailto:[email protected]] Sent: Wednesday, May 18, 2016 9:28 AM To: > El-Haj-Mahmoud, Samer <[email protected]>; Andrew Fish > <[email protected]>; Foster, Matthew I <[email protected]>; > [email protected] Cc: [email protected] > <[email protected]> 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:[email protected]] On Behalf Of Laszlo Ersek >> Sent: Wednesday, May 18, 2016 9:04 AM To: El-Haj-Mahmoud, Samer >> <[email protected]>; Andrew Fish <[email protected]>; >> Foster, Matthew I <[email protected]> Cc: >> [email protected] <[email protected]> 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:[email protected]] On Behalf Of Laszlo >>> Ersek Sent: Wednesday, May 18, 2016 4:39 AM To: Andrew Fish >>> <[email protected]>; Foster, Matthew I >>> <[email protected]> Cc: [email protected] >>> <[email protected]> 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 >>>>> <[email protected]> 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 [email protected] >>> https://lists.01.org/mailman/listinfo/edk2-devel >>> >> >> _______________________________________________ edk2-devel mailing >> list [email protected] >> https://lists.01.org/mailman/listinfo/edk2-devel >> > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
