Bezüglich Toomas Soome's Nachricht vom 29.06.2017 10:39 (localtime): > >> On 29. juuni 2017, at 11:24, Harry Schmalzbauer <free...@omnilan.de >> <mailto:free...@omnilan.de>> wrote: >> >> 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) ;-) >>>
… > There has not been too much activities about this topic, except some > discussions. But it is quite clear that this change has to be handled by > the loader in first place - as we need to get the data in safe location; > now of course there is secondary part as well - it may be that kernel > would need some work as well, depending on how the md image(s) are to be > handled in relation to memory maps. Hello Toomas, unfortunately my skills don't allow me to make this happen myself :-( But since almost every production system here is MFS_ROOT based, I'm awfully missing the UEFI boot feature, especially on those where I have to do work via vt(4) from time to time, which would be a lot easier if vt_efi was usable instead of vt_vga :-) Can you estimate if someone has intentions/interest/time to implement the missing extensions in boot and kernel resp. the timeframe? Thanks, -harry _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
