qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [5765] uImage: only try to load 'kernel' images (Hollis


From: Jean-Christophe PLAGNIOL-VILLARD
Subject: Re: [Qemu-devel] [5765] uImage: only try to load 'kernel' images (Hollis Blanchard)
Date: Fri, 21 Nov 2008 01:30:44 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On 17:37 Thu 20 Nov     , Hollis Blanchard wrote:
> On Thu, 2008-11-20 at 23:29 +0100, François Revol wrote:
> > > IH_TYPE_STANDALONE images could be loaded, but would unexpectedly 
> > > fail if they
> > > tried to use any uboot services.
> > 
> > Hmm how is it planned to support the external API that is being 
> > developped ?
> > It's being added for NetBSD IIRC, and I'll probably need that for Haiku 
> > as well, or use the boot loader as a standalone image.
> 
> I don't know anything about it, but assuming you mean a runtime API
> u-boot offers to applications it's loaded, I don't see that qemu needs
> to be involved at all.
> 
> > We would still have an u-boot rom around anyway, wouldn't we?
> 
> It's possible to implement the API in qemu itself (using a magic
> "call-out" instruction), but running u-boot itself inside the VM is the
> best option. (At one point Jocelyn claimed that this already works with
> qemu's 405 emulation, but I could never get it to work.)

I'm interested too it he can send info about it

> 
> The code that I've posted is specifically to load uImages, so it
> wouldn't be used to load u-boot itself. In the Bamboo patches I'm
> working on, I just replicate the post-load environment u-boot leaves
> behind (register state, device tree, kernel load address, TLB entries,
> etc). This bypasses the need for a u-boot ROM.
IMHO I'll prefer to boot qemu with u-boot also to be the nearest of the
reallity

Best Regards,
J.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]