[Top][All Lists]
[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.