[prev in list] [next in list] [prev in thread] [next in thread]
List: grub-devel
Subject: Re: Grub2: add UEFI support for accessing memory address above 4GB.
From: Michel Hermier <michel.hermier () gmail ! com>
Date: 2017-03-07 17:08:48
Message-ID: CAAZ5spBiKUPXq1nQRW4nXi8AK-vVdE7fvpr0HethfGRm2ByeCg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Le 7 mars 2017 17:24, "Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com> a
=C3=A9crit :
On Tue, Mar 7, 2017, 08:15 Leif Lindholm <leif.lindholm@linaro.org> 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.
> > The feature should support UEFI BIOS boot mode.
>
> I do not understand this statement.
>
> /
> Leif
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[Attachment #5 (text/html)]
<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">Le 7 \
mars 2017 17:24, "Vladimir 'phcoder' Serbinenko" <<a \
href="mailto:phcoder@gmail.com">phcoder@gmail.com</a>> a écrit :<br \
type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div class="quoted-text"><br><br><div \
class="gmail_quote"><div dir="ltr">On Tue, Mar 7, 2017, 08:15 Leif Lindholm <<a \
href="mailto:leif.lindholm@linaro.org" \
target="_blank">leif.lindholm@linaro.org</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">On Tue, Mar 07, 2017 at 01:55:01AM +0000, Yufuping wrote:<br \
class="m_3116463110773228278gmail_msg"> > Who can add the new feature for \
grub2:<br class="m_3116463110773228278gmail_msg"> > Add UEFI support for accessing \
memory address above 4GB.<br class="m_3116463110773228278gmail_msg"> <br \
class="m_3116463110773228278gmail_msg"> Presumably you mean for x86_64?<br \
class="m_3116463110773228278gmail_msg"> Since GRUB supports all 5 architectures \
currently supported by the<br class="m_3116463110773228278gmail_msg"> UEFI \
specification, 3 of which are 64-bit, it is useful to be a bit<br \
class="m_3116463110773228278gmail_msg"> more precise.<br \
class="m_3116463110773228278gmail_msg"> <br class="m_3116463110773228278gmail_msg">
> When using grub2 as PXE downloading engine, grub2 can get initrd<br \
class="m_3116463110773228278gmail_msg"> > file from network and put it to memory \
above 4GB.<br class="m_3116463110773228278gmail_msg"></blockquote></div></div><div>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.</div><div class="quoted-text"><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <br \
class="m_3116463110773228278gmail_msg"> I can think of nothing particularly related \
to PXE here.<br class="m_3116463110773228278gmail_msg"> The x86_64 port currently \
sets GRUB_EFI_MAX_USABLE_ADDRESS to<br class="m_3116463110773228278gmail_msg"> \
0xffffffff or 0x7fffffff, depending on toolchain configuration.<br \
class="m_3116463110773228278gmail_msg"> <br class="m_3116463110773228278gmail_msg">
ARM64 sets it to 0xffffffffffffULL, and that works fine.<br \
class="m_3116463110773228278gmail_msg"> <br class="m_3116463110773228278gmail_msg">
I seem to recall that the x86_64 port was being restricted due to<br \
class="m_3116463110773228278gmail_msg"> known bad firmware encountered in the past. \
It could be that it would<br class="m_3116463110773228278gmail_msg"> be worth adding \
an option to configure for enabling access to higher<br \
class="m_3116463110773228278gmail_msg"> addresses, alternatively for retaining \
compatibility with the broken<br class="m_3116463110773228278gmail_msg"> systems.<br \
class="m_3116463110773228278gmail_msg"></blockquote></div></div><div>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.</div></blockquote></div></div></div><div dir="auto"><br></div><div \
dir="auto">What about a dynamic variable instead or at least accessible from script? \
So a user could redefine a value of any kind.</div><div dir="auto"><br></div><div \
dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote \
class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="elided-text"><div class="gmail_quote"><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br class="m_3116463110773228278gmail_msg">
> The feature should support UEFI BIOS boot mode.<br \
class="m_3116463110773228278gmail_msg"> <br class="m_3116463110773228278gmail_msg">
I do not understand this statement.<br class="m_3116463110773228278gmail_msg">
<br class="m_3116463110773228278gmail_msg">
/<br class="m_3116463110773228278gmail_msg">
Leif<br class="m_3116463110773228278gmail_msg">
<br class="m_3116463110773228278gmail_msg">
______________________________<wbr>_________________<br \
class="m_3116463110773228278gmail_msg"> Grub-devel mailing list<br \
class="m_3116463110773228278gmail_msg"> <a href="mailto:Grub-devel@gnu.org" \
class="m_3116463110773228278gmail_msg" target="_blank">Grub-devel@gnu.org</a><br \
class="m_3116463110773228278gmail_msg"> <a \
href="https://lists.gnu.org/mailman/listinfo/grub-devel" rel="noreferrer" \
class="m_3116463110773228278gmail_msg" \
target="_blank">https://lists.gnu.org/mailman/<wbr>listinfo/grub-devel</a><br \
class="m_3116463110773228278gmail_msg"> </blockquote></div>
</div><br>______________________________<wbr>_________________<br>
Grub-devel mailing list<br>
<a href="mailto:Grub-devel@gnu.org">Grub-devel@gnu.org</a><br>
<a href="https://lists.gnu.org/mailman/listinfo/grub-devel" rel="noreferrer" \
target="_blank">https://lists.gnu.org/mailman/<wbr>listinfo/grub-devel</a><br> \
<br></blockquote></div><br></div></div></div>
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic