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...

[Toomas Soome]

> On 23. aug 2016, at 15:36, Slawa Olhovchenkov <slw at zxy.spb.ru> wrote:
> 
> On Tue, Aug 23, 2016 at 03:26:04PM +0300, Toomas Soome wrote:
> 
>>> 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?
>> 
>> 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?
> 
> 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.
> 
> How to resolve this:
> 
> 1) start entirely; boot2 in protected mode and read all boot2 to
> extended memory
> 
> 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… 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