From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Kc85W-00043n-8E for mharc-grub-devel@gnu.org; Sat, 06 Sep 2008 20:25:10 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kc85V-00043F-9V for grub-devel@gnu.org; Sat, 06 Sep 2008 20:25:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kc85U-000432-KO for grub-devel@gnu.org; Sat, 06 Sep 2008 20:25:08 -0400 Received: from [199.232.76.173] (port=51694 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kc85U-00042w-HJ for grub-devel@gnu.org; Sat, 06 Sep 2008 20:25:08 -0400 Received: from fg-out-1718.google.com ([72.14.220.155]:46767) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kc85U-0005lS-1y for grub-devel@gnu.org; Sat, 06 Sep 2008 20:25:08 -0400 Received: by fg-out-1718.google.com with SMTP id l26so1102460fgb.30 for ; Sat, 06 Sep 2008 17:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=yYbv7GFtIjC5j0w+abBgtWuRVO5NoE2mh/HQ5rhVEOU=; b=IuUsZfQNRCv1xps8A44JOrrlHThEHCEnsPrTfHSnNLNcbn8O6Vs4lECqPO0EWk7Uwk 1BdYMFETjS8bWjQRAqOhF7SP/1eV3Ryqt/7NPpQCeE0GiBijeSqhn+budL23zFXhqmRC 007HSdMh5OEYDPHs4QvnE7hAzx8LFbcldmS0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=WROetZvl+x5NHYsEz7NyDMSbkk6TGQ8A/O+CiTOki2UuNLL/omZlZpjosl1pDLyh+Q RpeAyloYnK3vBEkp8VumMVx4VBUAP2R8x5vusmBcjOrdiEal2iqaRbniPNfhgwCAmBwZ yGeLVuqFRPIgOjZRAd8jXwyiReO+VXIETw3Ow= Received: by 10.86.96.18 with SMTP id t18mr10053093fgb.1.1220747107363; Sat, 06 Sep 2008 17:25:07 -0700 (PDT) Received: from ?192.168.1.15? ( [85.1.148.39]) by mx.google.com with ESMTPS id 3sm2715228fge.3.2008.09.06.17.25.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 06 Sep 2008 17:25:06 -0700 (PDT) Message-ID: <48C31F5F.6060808@gmail.com> Date: Sun, 07 Sep 2008 02:25:03 +0200 From: phcoder User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: The development of GRUB 2 References: <48C16C17.2000803@gmail.com> <20080906112003.GA14991@thorin> In-Reply-To: <20080906112003.GA14991@thorin> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) Subject: Re: [RFC] general-usage real-mode loader X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2008 00:25:09 -0000 I checked the archive found the thread "Idea: Move kernel to upper memory". But what is discussed there is much more general about general memory layout. Here I wanted to speak about just one function. Vladimir 'phcoder' Serbinenko Robert Millan wrote: > On Fri, Sep 05, 2008 at 07:27:51PM +0200, phcoder wrote: >> Hello. A long time ago I written a C+asm code which loads any given code >> at any real-mode location, then puts machine in correct state and then >> launches the kernel. I can modify this code to suit GRUB2. Then loading >> realmode kernel would work like this: >> 1) copy helper asm to last kb of lower memory >> 2) jump to the helper >> 3) helper copies from upper memory the kernel >> 4) turn A10 bug back on if necessary >> 5) go to RM >> 6) prepare registers >> 7) jump to the kernel >> >> This protocol is very flexible and as such could be used by all loaders >> which load kernel in realmode or even in PM (skip step 5, do steps 6-7 >> in 32-bit mode) except for changing page tables. Such a helper can be >> easily implemented as module and so help us removing asm-parts of >> loaders from the kernel. If I recieve greenlight for it, I implement it. > > Maybe I'm confusing this with something else, but isn't this what both Bean > and Vesa implemented separately, and are currently discussing in another > thread? > > (the goal there was to move BIOS wrappers out of kern/i386/pc/startup.S) >