From owner-freebsd-hackers Wed Mar 1 14:22:57 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA01648 for hackers-outgoing; Wed, 1 Mar 1995 14:22:57 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id OAA01642 for ; Wed, 1 Mar 1995 14:22:52 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id JAA12258; Thu, 2 Mar 1995 09:13:04 +1100 Date: Thu, 2 Mar 1995 09:13:04 +1100 From: Bruce Evans Message-Id: <199503012213.JAA12258@godzilla.zeta.org.au> To: Remy.Card@masi.ibp.fr, hasty@netcom.com Subject: Re: Since lites-1.0 is out... Cc: bakul@netcom.com, freebsd-hackers@FreeBSD.org Sender: hackers-owner@FreeBSD.org Precedence: bulk > Mach.all bombs out because it is linked as a QMAGIC binary. It seems >that the current boot blocks are not able to boot a QMAGIC kernel. I have not >looked into it: I have simply modified the mkbootimage script in Mach4 to make >it generate a ZMAGIC binary (simply add -Z to the call to ld). BTW, I noticed >that everything under FreeBSD is linked as a QMAGIC binary except the kernel >so I suspect that the boot blocks bug is already known. The original Mach bootblocks probably would have worked, but the mask for munging head.a_entry to get startaddr was changed from 0x00F00000 to 0x00FFFFFF because the former arbitrarily restricts the load address to a 1MB boundary and QMAGIC wasn't supported at all when the change was made. I think the bootblock shouldn't know anything about executable magics. It should simply load a file wherever it wants and jump to the load address. Startup code in the file can relocate and expand the bss, etc. This would be easier if the jmp instruction at the start of the file worked on more machines that PDP-11's :-). Bruce