From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1FIBaL-0002Ta-4A
	for qemu-devel@nongnu.org; Sat, 11 Mar 2006 16:25:13 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1FIBaH-0002Rn-5X
	for qemu-devel@nongnu.org; Sat, 11 Mar 2006 16:25:12 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1FIBaG-0002Rk-Ux
	for qemu-devel@nongnu.org; Sat, 11 Mar 2006 16:25:08 -0500
Received: from [65.74.133.6] (helo=mail.codesourcery.com)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FIBdr-0000wB-GO
	for qemu-devel@nongnu.org; Sat, 11 Mar 2006 16:28:52 -0500
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH] Add more devices for MIPS system emulation
Date: Sat, 11 Mar 2006 21:25:04 +0000
References: <20060221191118.GA4110@networkno.de>
	<200602232144.21423.paul@codesourcery.com>
	<20060306145044.GB27785@networkno.de>
In-Reply-To: <20060306145044.GB27785@networkno.de>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200603112125.05107.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

> I updated the patch to allow for that again, and added an ELF loader on
> top to avoid hardcoded kernel load addresses/entry points. This is also
> useful for stand-alone programs. The ramdisk and command line addresses
> are still hardcoded.

Except now you can't load raw kernel images.

I'm still not convinced the boot sector hacks can do anything useful How 
exactly are you using these? You say the DECstation bios uses offsets stored 
in the boot sector to locate the second stage bootloader, but:
a) We aren't using a DECstation bios. I'm guessing we're not emulating 
DECstation hardware, so it wouldn't work even if we did have one.
b) You haven't modified the boot sector to provide those offsets.
c) You're only replacing the boot sector itself. Even if you did insert the 
correct offsets they'd still be pointing to random bits of user data, not the 
kernel you want to boot.

Paul