Le 7 mars 2017 18:22, "Vladimir 'phcoder' Serbinenko" <[email protected]> a écrit :
On Tue, Mar 7, 2017, 09:09 Michel Hermier <[email protected]> wrote: > > > Le 7 mars 2017 17:24, "Vladimir 'phcoder' Serbinenko" <[email protected]> > a écrit : > > > > On Tue, Mar 7, 2017, 08:15 Leif Lindholm <[email protected]> wrote: > > On Tue, Mar 07, 2017 at 01:55:01AM +0000, Yufuping wrote: > > Who can add the new feature for grub2: > > Add UEFI support for accessing memory address above 4GB. > > Presumably you mean for x86_64? > Since GRUB supports all 5 architectures currently supported by the > UEFI specification, 3 of which are 64-bit, it is useful to be a bit > more precise. > > > When using grub2 as PXE downloading engine, grub2 can get initrd > > file from network and put it to memory above 4GB. > > I'd like to know more about the usecase. Generally you should avoid > downloading or loading too large files in bootloader. I.a. TFTP protocol > has problems with files over about 100MIB. Generally you should download > only kernel + initrd and rest of the system should be on iSCSI or NFS. > > > I can think of nothing particularly related to PXE here. > The x86_64 port currently sets GRUB_EFI_MAX_USABLE_ADDRESS to > 0xffffffff or 0x7fffffff, depending on toolchain configuration. > > ARM64 sets it to 0xffffffffffffULL, and that works fine. > > I seem to recall that the x86_64 port was being restricted due to > known bad firmware encountered in the past. It could be that it would > be worth adding an option to configure for enabling access to higher > addresses, alternatively for retaining compatibility with the broken > systems. > > I'm opposed to a config option for this. We don't want to have several > variants of grub binaries for the same platform. If we want to support > >4GiB memory we should detect the buggy firmware on runtime. It's pretty > easy: buggy firmware didn't map memory above 4GiB. We can then either avoid > memory above 4GiB or map it ourselves. > > > What about a dynamic variable instead or at least accessible from script? > So a user could redefine a value of any kind. > What if advantage compared to automatic detection. And still, I want to know about usecase Because I don't trust automatic detection. Even if one say it is 200% safe, there is allways that machine that nobody heard of that will fail. So having user being able to force some values is usually a good idea. > > > The feature should support UEFI BIOS boot mode. > > I do not understand this statement. > > / > Leif > > _______________________________________________ > Grub-devel mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/grub-devel > > > _______________________________________________ > Grub-devel mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/grub-devel > > > _______________________________________________ > Grub-devel mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/grub-devel > _______________________________________________ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
_______________________________________________ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
