From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LszaB-0000aj-FB for mharc-grub-devel@gnu.org; Sun, 12 Apr 2009 09:18:47 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lsza9-0000Zk-U6 for grub-devel@gnu.org; Sun, 12 Apr 2009 09:18:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lsza4-0000ZU-EW for grub-devel@gnu.org; Sun, 12 Apr 2009 09:18:44 -0400 Received: from [199.232.76.173] (port=47963 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lsza4-0000ZR-9P for grub-devel@gnu.org; Sun, 12 Apr 2009 09:18:40 -0400 Received: from fg-out-1718.google.com ([72.14.220.153]:5324) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lsza3-0006tv-RG for grub-devel@gnu.org; Sun, 12 Apr 2009 09:18:40 -0400 Received: by fg-out-1718.google.com with SMTP id 19so511450fgg.7 for ; Sun, 12 Apr 2009 06:18:39 -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 :content-type:content-transfer-encoding; bh=fdEPzdBSvOUA+/8eUucenMb3M6/+S8FBQehc/5WVqdU=; b=uvMfru0TcMth5QlqKHbHLc42PLEx7WetqkVrR2CgYq6ghLtLTK1jdugPen2G0mWtYa te0Z8gf0F3IbVhnhBfywgi/CvcE33ONqNcKyCWpdYdBW8CX5ClHCdixnfH/o1kIpHOOn U5NCQwsfUz/+XsFJ0LRALf8N5a2MsfTIlIUjo= 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:content-type:content-transfer-encoding; b=R5ka+b7UrmtpRF4USKIfyP9PKNOsEkE2Pr4BiBRnWnDsndRZ5ZHACI8LSOeTk4ydb0 0+pLtna1r9DMnsTZR1rTjKGBkwnFLNZ/VhlscyUpbdicUPtrT1Qtvj/jL+geYaS1X6nf SvhactSnU/Zqt/vmKjdTm+hdG7XHGG6t7JXts= Received: by 10.86.95.20 with SMTP id s20mr4015423fgb.43.1239542318970; Sun, 12 Apr 2009 06:18:38 -0700 (PDT) Received: from ?192.168.1.25? (116-145.62-81.cust.bluewin.ch [81.62.145.116]) by mx.google.com with ESMTPS id d4sm5023526fga.28.2009.04.12.06.18.37 (version=SSLv3 cipher=RC4-MD5); Sun, 12 Apr 2009 06:18:38 -0700 (PDT) Message-ID: <49E1EA32.1020004@gmail.com> Date: Sun, 12 Apr 2009 15:18:42 +0200 From: phcoder User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: The development of GRUB 2 References: <49E08411.70306@gmail.com> In-Reply-To: <49E08411.70306@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: GRUB2 - Please add support for 64-bit FreeBSD 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, 12 Apr 2009 13:18:46 -0000 I have looked in it and isolated the files which changes are needed: 1) switching to x86_64 mode and setting the paging up 2) elf64 parser 3) different boot parameters I'm quite optimistic and think I should have working freebsd64 soon. Another good piece of news is that it seems that in freebsd64 all BIOS calls are moved to bootloader. It's a very wise decision which also allows FreeBSD64 to boot on EFI or coreboot phcoder wrote: > I haven't looked in depth yet, but it's a bit more. the loader switches > to amd64 and sets preliminary page translation > Bean wrote: >> On Sat, Apr 11, 2009 at 5:54 AM, Daniel Nebdal wrote: >>> Bean wrote: >>>> Hi, >>>> >>>> Please try the btx loader in /boot/loader, which I believe to be >>>> 32-bit even in amd64 freebsd. The btx loader is an a.out executable, >>>> grurb2 has supported for it already. >>> Ah, just noticed I replied to this before subscribing, so the copy to >>> the list bounced. >>> Let's try again. >>> >>> The BTX loader starts, yes - but the reason I'm using GRUB2 in the >>> first place is to skip it, >>> since it doesn't seem to support logical partitions. >> >> Hi, >> >> Oh, thanks for the information. The 32-bit bsd kernel is basically an >> elf image that needs a little address translation: >> >> physical address = virtual address & 0xFFFFFF >> >> I think the principle can be applied to 64-bit kernel as well, it >> shouldn't be difficult to add support for it. >> > > -- Regards Vladimir 'phcoder' Serbinenko