From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1clIbd-00005a-LA for mharc-grub-devel@gnu.org; Tue, 07 Mar 2017 12:09:01 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47567) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clIbV-0008W8-Ti for grub-devel@gnu.org; Tue, 07 Mar 2017 12:08:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1clIbU-0008Nr-K9 for grub-devel@gnu.org; Tue, 07 Mar 2017 12:08:53 -0500 Received: from mail-wm0-x241.google.com ([2a00:1450:400c:c09::241]:35828) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1clIbU-0008Nh-9b for grub-devel@gnu.org; Tue, 07 Mar 2017 12:08:52 -0500 Received: by mail-wm0-x241.google.com with SMTP id z63so2037991wmg.2 for ; Tue, 07 Mar 2017 09:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FfH0m1hmnc56D5JrYKOJ4DMIVJ3Jn9adEQy4nI1G6HE=; b=fLiY3pBZq7pJwlgMk7mOMupramxts2XPOOqeAFOGtol6iwc2Hfz7tY/oBR/OhrCAzW 1bhvMEk8jXICdx0N6IhFy9Xxb1oRTpv2CQ7ZtrUp0mM3rtB6YxNh8V7/zZs1X5+ErHrz yurZGk6hhdxKY2mirfBV90PmMSwzLxQ14H15XtnVilNEh9dujbMVGlvQ+cuc7bpVk23U CwxkFvJeDVmW+iVgbgKwL/ymdwXwMOo0N8RyYxCLiHiuqD5UX/Q5wqiK/VNTKoDw0VDk RroGeZhH4jtWCqYnhN8xn7XxGdaqgnuvLQ+4uqDWryOGIka44Xrea6Cweau0P/8aW6dh 2C7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FfH0m1hmnc56D5JrYKOJ4DMIVJ3Jn9adEQy4nI1G6HE=; b=jmVnK3d9QzhoMrpQjZ2EDmmO0hvGrSOZ5boqvOf2S8cP4T8g2GFfCAyADwGlbMsbfC BceCa2B3njEhPkJtEojxgcMO3SkPchLhuCDC8P5VjRUzDXoyugFpnTmr2+v5mZNO3hga friYyg+ywNQTvFb9UzLX9c5tT7JbH6Esr62WRMCC2QVTc+DnTVrAK3zHc3/V3GxIpbpe TrYrLfQEIqDY+oaehqox1tTRcKJqhqsr34oSFZg2FOhib2hgD6eWuT8gOn3D5MZENMnu mOM82wBEJqgScxcsw1Eod+VLqmkQ7rekALabbPhUQw67oXtNMRwDbTa1TP1he23iL3Bi NP3A== X-Gm-Message-State: AMke39nz2GwlH5Axd3g3ehaigSMHZG9dKklDMxb0QqdKNyu9UUIiLnYa5dEB1sUzMuHBidORPz9VjnbOqANWuw== X-Received: by 10.28.96.130 with SMTP id u124mr20715905wmb.81.1488906529503; Tue, 07 Mar 2017 09:08:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.174.226 with HTTP; Tue, 7 Mar 2017 09:08:48 -0800 (PST) Received: by 10.223.174.226 with HTTP; Tue, 7 Mar 2017 09:08:48 -0800 (PST) In-Reply-To: References: <0F096E795C1FFC47A7AE6BB0F7A9C1764BDD05B1@nkgeml513-mbs.china.huawei.com> <20170307155811.GM16034@bivouac.eciton.net> From: Michel Hermier Date: Tue, 7 Mar 2017 18:08:48 +0100 Message-ID: Subject: Re: Grub2: add UEFI support for accessing memory address above 4GB. To: The development of GNU GRUB Cc: yanjianlong Content-Type: multipart/alternative; boundary=001a1148f03acb7f27054a2710b0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::241 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 17:09:00 -0000 --001a1148f03acb7f27054a2710b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le 7 mars 2017 17:24, "Vladimir 'phcoder' Serbinenko" a =C3=A9crit : On Tue, Mar 7, 2017, 08:15 Leif Lindholm 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 --001a1148f03acb7f27054a2710b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Le=C2=A07 mars 2017 17:24, "Vladimir 'phcoder' Serbi= nenko" <phcoder@gmail.com&= gt; a =C3=A9crit=C2=A0:


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 t= oo large files in bootloader. I.a. TFTP protocol has problems with files ov= er about 100MIB. Generally you should download only kernel + initrd and res= t 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 h= ave 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&= #39;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 co= uld redefine a value of any kind.


> The feature should support UEFI BIOS boot mode.

I do not understand this statement.

/
=C2=A0 =C2=A0 Leif

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://li= sts.gnu.org/mailman/listinfo/grub-devel

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-de= vel


--001a1148f03acb7f27054a2710b0--