From owner-svn-src-all@freebsd.org Tue Aug 23 13:44:06 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF912BC3B2E; Tue, 23 Aug 2016 13:44:06 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp003.me.com (st13p35im-asmtp003.me.com [17.164.199.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B13EE1230; Tue, 23 Aug 2016 13:44:06 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp003.me.com by st13p35im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OCD00D007H1KI00@st13p35im-asmtp003.me.com>; Tue, 23 Aug 2016 13:44:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1471959845; bh=bt00acq9frRgCDol9VDhWXuFAHcwtWpPDSwjT8/E+r4=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=S33lyaYnNx0Yte0Dfp8N7KagTnv0l2lYDmwaBMhSitAGPOiKT8/Eryi+J+upXnbQR M9QCvt73saUzTA/a8t8NPp8pKckJnxxZl34zFsUtXZDNuDFdgPz1G4BszTOtlxQmkY CU+qPgsUV2YtC2p2g9fzR8kTvL+nL+P4xBY0gHHKBRlF5ItoYntxFu1afTDbw9xvkO 3wz9fwITFHueOHg5n7svkOB2ENpx9B3gU0jmCxp+NZ52TYL5UD6qCXJyCWMUV4OYG9 9lGpOmYecrT1aBx71MgCnKkZhavO3wGwDfK3GTsVnTOQdguLKyo9MnGlhG/hRDHDI0 xHYLaYIFtNW5Q== Received: from [88.196.10.91] (91-10-196-88.dyn.estpak.ee [88.196.10.91]) by st13p35im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OCD00JBI7HD5840@st13p35im-asmtp003.me.com>; Tue, 23 Aug 2016 13:44:05 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-08-23_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=18 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1608230138 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 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... From: Toomas Soome In-reply-to: <20160823123621.GB88122@zxy.spb.ru> Date: Tue, 23 Aug 2016 16:44:01 +0300 Cc: Warner Losh , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , src-committers , Toomas Soome , Andriy Gapon Content-transfer-encoding: quoted-printable Message-id: <70353DFD-06E4-4D18-9D01-187C402BC302@me.com> References: <7bdb0cf5-e139-375b-8be6-c1280e39da25@FreeBSD.org> <4c76efd6-146a-e70b-c065-729d223e3398@FreeBSD.org> <1C479C8A-9F58-425C-8AC2-0A6809F39ACA@me.com> <20160823112940.GW22212@zxy.spb.ru> <20160823121629.GA88122@zxy.spb.ru> <151A63A8-6444-4E84-80B8-B773C8F661EF@me.com> <20160823123621.GB88122@zxy.spb.ru> To: Slawa Olhovchenkov X-Mailer: Apple Mail (2.3124) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 13:44:07 -0000 > On 23. aug 2016, at 15:36, Slawa Olhovchenkov 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=