Date: Tue, 23 Aug 2016 16:44:01 +0300 From: Toomas Soome <tsoome@me.com> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: Warner Losh <imp@bsdimp.com>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, src-committers <src-committers@freebsd.org>, Toomas Soome <tsoome@freebsd.org>, Andriy Gapon <avg@freebsd.org> Subject: Re: svn commit: r304321 - in head/sys: boot/efi/boot1 boot/efi/loader boot/i386/boot2 boot/i386/gptboot boot/i386/gptzfsboot boot/i386/zfsboot boot/userboot/ficl boot/userboot/userboot boot/userboot/zf... Message-ID: <70353DFD-06E4-4D18-9D01-187C402BC302@me.com> In-Reply-To: <20160823123621.GB88122@zxy.spb.ru> References: <7bdb0cf5-e139-375b-8be6-c1280e39da25@FreeBSD.org> <4c76efd6-146a-e70b-c065-729d223e3398@FreeBSD.org> <AE24A37C-51F5-4CEC-9399-D7FDEBC93972@me.com> <CANCZdfo0P7CPPf4khzj_JnSjWQ4gVqK9wSEqW=LCdZKQwGh6Sw@mail.gmail.com> <AE896F50-D053-4C30-BB43-286E1CCDE4B8@me.com> <1C479C8A-9F58-425C-8AC2-0A6809F39ACA@me.com> <20160823112940.GW22212@zxy.spb.ru> <C8A2C3A1-C35A-4993-AC0F-66F6B0AD51A6@me.com> <20160823121629.GA88122@zxy.spb.ru> <151A63A8-6444-4E84-80B8-B773C8F661EF@me.com> <20160823123621.GB88122@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 23. aug 2016, at 15:36, Slawa Olhovchenkov <slw@zxy.spb.ru> wrote: >=20 > On Tue, Aug 23, 2016 at 03:26:04PM +0300, Toomas Soome wrote: >=20 >>> Main trouble (by kib@) is 640KB real mode limit. >>> Separated heap don't soled this. >>> May be solution is early switch to protected mode, boot2? >>=20 >> hm, but boot2 is already btx client and btx is setting up the >> protected mode. Only zfsboot/gpt[zfs]boot memory copy (boot2 >> relocator) is working in segmented real mode, so the gptldr.S and >> zfsldr.S has to deal with memory segments to set boot2 up. Or did >> got you wrong? >=20 > Mat be I am wrong. > May be I am not very clean. > As I understund kib@ restriction caused by 640KB realmode limit. > In case of boot2 start in real mode and read enterly by boot1 -- we > also touch this trouble. >=20 > How to resolve this: >=20 > 1) start entirely; boot2 in protected mode and read all boot2 to > extended memory >=20 > 2) read only part of boot2 (boot2 relocator) by boot1 and switch to > protected mode before reading rest of boot2 by boot2 code. Ah, well, the boot2 by itself is not an issue - it is much smaller and = the only related problem was that real mode relocator was using segment = size (64k) for copy, but this limit is removed (was pre-requisite for = geli support in gptboot and I did port that change to zfsboot as well). = The size issue with loader (stage3) is due to fact that loader memory = image is located in low memory, base 0xa000 and the upper limit is EBDA = and video memory area. Since boot2 is running in protected mode, it can = load loader (or kernel) were needed, just that placing loader must be = careful=E2=80=A6 in that sense the current location is almost perfect = (with exception about the size limit;) and I would avoid moving it = without the very good reason. rgds, toomas=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?70353DFD-06E4-4D18-9D01-187C402BC302>