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

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

[Anthony Liguori]

Revision: 5765
          http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=5765
Author:   aliguori
Date:     2008-11-20 22:15:46 +0000 (Thu, 20 Nov 2008)

Log Message:
-----------
uImage: only try to load 'kernel' images (Hollis Blanchard)

Loading other image types (e.g. IH_TYPE_MULTI, IH_TYPE_FLATDT) is not
implemented.

IH_TYPE_STANDALONE images could be loaded, but would unexpectedly fail if they
tried to use any uboot services.

Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Modified Paths:
--------------
    trunk/loader.c

Modified: trunk/loader.c
===================================================================
--- trunk/loader.c	2008-11-20 22:14:40 UTC (rev 5764)
+++ trunk/loader.c	2008-11-20 22:15:46 UTC (rev 5765)
@@ -479,9 +479,9 @@
     if (hdr->ih_magic != IH_MAGIC)
         goto out;
 
-    /* TODO: Implement Multi-File images.  */
-    if (hdr->ih_type == IH_TYPE_MULTI) {
-        fprintf(stderr, "Unable to load multi-file u-boot images\n");
+    /* TODO: Implement other image types.  */
+    if (hdr->ih_type != IH_TYPE_KERNEL) {
+        fprintf(stderr, "Can only load u-boot image type \"kernel\"\n");
         goto out;
     }
 
@@ -498,7 +498,7 @@
 
     /* TODO: Check CPU type.  */
     if (is_linux) {
-        if (hdr->ih_type == IH_TYPE_KERNEL && hdr->ih_os == IH_OS_LINUX)
+        if (hdr->ih_os == IH_OS_LINUX)
             *is_linux = 1;
         else
             *is_linux = 0;

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

[François Revol]

> 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.
We would still have an u-boot rom around anyway, wouldn't we?

François.

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

[Hollis Blanchard]

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.)

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.

-- 
Hollis Blanchard
IBM Linux Technology Center

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

[Jean-Christophe PLAGNIOL-VILLARD]

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.