Date: Tue, 16 May 2017 19:20:34 +0300 From: Toomas Soome <tsoome@me.com> To: Harry Schmalzbauer <freebsd@omnilan.de> Cc: freebsd-stable@freebsd.org Subject: Re: EFI loader doesn't handle md_preload (md_image) correct? Message-ID: <7CF3AC8F-A778-40AE-B457-9B96AE5B4719@me.com> In-Reply-To: <591B2523.6040101@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>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 16. mai 2017, at 19:13, Harry Schmalzbauer <freebsd@omnilan.de> = wrote: >=20 > Bez=C3=BCglich Toomas Soome's Nachricht vom 16.05.2017 18:00 = (localtime): >>=20 >>> On 16. mai 2017, at 18:45, Harry Schmalzbauer <freebsd@omnilan.de >>> <mailto:freebsd@omnilan.de>> wrote: >>>=20 >>> Bez=C3=BCglich Harry Schmalzbauer's Nachricht vom 16.05.2017 17:28 = (localtime): >>>> Bez=C3=BCglich Toomas Soome's Nachricht vom 16.05.2017 16:57 = (localtime): >>>>>> On 16. mai 2017, at 17:55, Harry Schmalzbauer <freebsd@omnilan.de >>>>>> <mailto:freebsd@omnilan.de>> wrote: >>>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> unfortunately I had some trouble with my preferred MFS-root = setups. >>>>>> It seems EFI loader doesn't handle type md_image correctly. >>>>>>=20 >>>>>> If I load any md_image with loader invoked by gptboot or = gptzfsboot, >>>>>> 'lsmod' >>>>>> shows "elf kernel", "elf obj module(s)" and "md_image". >>>>>>=20 >>>>>> Using the same loader.conf, but EFI loader, the md_image-file is >>>>>> prompted and sems to be loaded, but not registered. There's no >>>>>> md_image >>>>>> with 'lsmod', hence it's not astonsihing that kernel doesn't = attach md0 >>>>>> so booting fails since there's no rootfs. >>>>>>=20 >>>>>> Any help highly appreciated, hope Toomas doesn't mind beeing >>>>>> initially CC'd. >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> -harry >>>>>=20 >>>>> The first question is, how large is the md_image and what other >>>>> modules are loaded? >>>> Thanks for your quick response. >>>>=20 >>>> The images are 50-500MB uncompressed (provided by gzip compressed = file). >>>> Small ammount of elf modules, 5, each ~50kB. >>>=20 >>> On the real HW, there's vmm and some more: >>> Id Refs Address Size Name >>> 1 46 0xffffffff80200000 16M kernel >>> 2 1 0xffffffff8121d000 86K unionfs.ko >>> 3 1 0xffffffff81233000 3.1M zfs.ko >>> 4 2 0xffffffff81545000 51K opensolaris.ko >>> 5 7 0xffffffff81552000 279K usb.ko >>> 6 1 0xffffffff81598000 67K ukbd.ko >>> 7 1 0xffffffff815a9000 51K umass.ko >>> 8 1 0xffffffff815b6000 46K aesni.ko >>> 9 1 0xffffffff815c3000 54K uhci.ko >>> 10 1 0xffffffff815d1000 65K ehci.ko >>> 11 1 0xffffffff815e2000 15K cc_htcp.ko >>> 12 1 0xffffffff815e6000 3.4M vmm.ko >>> 13 1 0xffffffffa3a21000 12K ums.ko >>> 14 1 0xffffffffa3a24000 9.1K uhid.ko >>>=20 >>> Providing md_image uncompressed doesn't change anything. >>>=20 >>> Will deploy a /usr separated rootfs, which is only ~100MB = uncompressed >>> and see if that changes anything. >>> That's all I can provide, code is far beyond my knowledge... >>>=20 >>> -harry >>=20 >>=20 >> 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. >>=20 >> 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. >=20 > 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? >=20 > At least now I have an idea baout the issue and an explanation why > reducing md_imgae to 100MB hasn't helped =E2=80=93 still more than = 64... >=20 > Any quick hint where to define the staging area size highly = appreciated, > fi there are no hard objections against a 768MB size. >=20 > -harry The problem is that before UEFI Boot Services are not switched off, the = memory is managed (and owned) by the firmware, and you can not write = into the random places. So you need to allocate the staging area, read = data there, switch BS off, move data into final location and start the = kernel. Alternatively, you move only the kernel into place, and let the kernel = to relocate and manage the modules and MD image. rgds, toomas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7CF3AC8F-A778-40AE-B457-9B96AE5B4719>