Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Jun 2017 10:24:28 +0200
From:      Harry Schmalzbauer <freebsd@omnilan.de>
To:        Toomas Soome <tsoome@me.com>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: EFI loader doesn't handle md_preload (md_image) correct?
Message-ID:  <5954B93C.8060101@omnilan.de>
In-Reply-To: <591B284B.6070204@omnilan.de>
References:  <591B12C6.4040301@omnilan.de> <DD0FE9CA-48C9-4A77-81FD-8CA139D95543@me.com> <591B1A8B.6070803@omnilan.de> <591B1EA4.600@omnilan.de> <FEF74507-4A04-49DD-A763-6733E18CCE66@me.com> <591B2523.6040101@omnilan.de> <7CF3AC8F-A778-40AE-B457-9B96AE5B4719@me.com> <591B284B.6070204@omnilan.de>

next in thread | previous in thread | raw e-mail | index | archive | help
 Bezüglich Harry Schmalzbauer's Nachricht vom 16.05.2017 18:26 (localtime):
> B
…
>>>> The issue is, that current UEFI implementation is using 64MB staging
>>>> memory for loading the kernel and modules and files. When the boot is
>>>> called, the relocation code will put the bits from staging area into the
>>>> final places. The BIOS version does not need such staging area, and that
>>>> will explain the difference.
>>>>
>>>> I actually have different implementation to address the same problem,
>>>> but thats for illumos case, and will need some work to make it usable
>>>> for freebsd; the idea is actually simple - allocate staging area per
>>>> loaded file and relocate the bits into the place by component, not as
>>>> continuous large chunk (this would also allow to avoid the mines like
>>>> planted by hyperv;), but right now there is no very quick real solution
>>>> other than just build efi loader with larger staging size.
>>> Ic, thanks for the explanation.
>>> While not aware about the purpose of the staging area nor the
>>> consequences of enlarging it, do you think it's feasable increasing it
>>> to 768Mib?
>>>
>>> At least now I have an idea baout the issue and an explanation why
>>> reducing md_imgae to 100MB hasn't helped – still more than 64...
>>>
>>> Any quick hint where to define the staging area size highly appreciated,
>>> fi there are no hard objections against a 768MB size.
>>>
>>> -harry
>> The problem is that before UEFI Boot Services are not switched off, the memory is managed (and owned) by the firmware,
> Hmm, I've been expecting something like that (owend by firmware) ;-)
>
> So I'll stay with CSM for now, and will happily be an early adopter if
> you need someone to try anything (-stable mergable).

Toomas, thanks for your help so far! I'm just curious if there's news on
this.
Was there a decision made whether kernel should be utilized to relocate
the MD image modules or the loader should be extended to handle
(x-)large staging areas?

I'd like to switch back to UEFI booting for various reasons (most
priority has consistency), but can't since it breaks md-rootfs with that
machine (the other run ESXi still).

If there's anything to test, please let me know.

Thanks,

-harry




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5954B93C.8060101>