Yes this works, A simple checkbox in the HII form before starting File Explorer
-----Original Message----- From: edk2-devel [mailto:[email protected]] On Behalf Of Laszlo Ersek Sent: Thursday, May 19, 2016 2:49 AM To: Tian, Feng <[email protected]>; El-Haj-Mahmoud, Samer <[email protected]>; Andrew Fish <[email protected]>; Foster, Matthew I <[email protected]> Cc: Wu, Hao A <[email protected]>; [email protected] <[email protected]> Subject: Re: [edk2] Using the Shell to launch a kernel using a RAMDISK On 05/19/16 04:41, Tian, Feng wrote: > 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:) * I think on the first form that lists > Create raw > Create from file There could be a persistent checkbox above these options, called Make next created RAM disk bootable [ ] * Alternatively, given that there aren't too many options yet, it shouldn't be a problem duplicating them: > Create raw (boot time only use) > Create raw (usable at runtime, bootable) > Create from file (boot time only use) > Create from file (usable at runtime, bootable) * Whichever of the above two is chosen, it would be nice (if possible) to display under Created RAM disk list: which RAM disks live in reserved memory and which don't. (This should really be optional though.) Just some ideas, of course. Thanks! Laszlo > -----Original Message----- > From: El-Haj-Mahmoud, Samer [mailto:[email protected]] > Sent: Wednesday, May 18, 2016 10:10 PM > To: Laszlo Ersek <[email protected]>; Andrew Fish <[email protected]>; > Foster, Matthew I <[email protected]>; Tian, Feng > <[email protected]> > Cc: [email protected] <[email protected]>; El-Haj-Mahmoud, > Samer <[email protected]> > 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:[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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
