qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 03/10] raven: move BIOS loading from board co


From: Hervé Poussineau
Subject: Re: [Qemu-devel] [PATCH v3 03/10] raven: move BIOS loading from board code to PCI host
Date: Mon, 23 Dec 2013 20:16:13 +0100
User-agent: Thunderbird 2.0.0.23 (Windows/20090812)

Peter Maydell a écrit :
On 23 December 2013 06:48, Hervé Poussineau <address@hidden> wrote:
So, this patch is a small functional change, as it adds a copy of the
firmware in a new range 0xfff00000-0xfff7ffff, but I think we can live with
it.

We'll be able to remove it once we switch to another firmware which uses the
right reset instruction pointer or whose size is 1MB.

+    /* Open Hack'Ware hack: bios size is 512K and is loaded at
0xfff00000.
+     * However, reset address is 0xfffffffc. Mirror the bios from
+     * 0xfff00000 to 0xfff80000.
+     */
+    memory_region_init_alias(bios, NULL, "bios-alias", sysmem,
0xfff00000,
+                             0x00080000);
+    memory_region_add_subregion_overlap(sysmem, 0xfff80000, bios, 1);

This code creates the mirrored region regardless of the size of the
firmware blob, right? I think that means that if we do supply a
1MB blob it'll do the wrong thing. You probably want to have some
"mirror this object as many times as necessary to fill the space"
logic.

We could probably do with having a generic MemoryRegion
API for that, actually -- it's not uncommon behaviour for devices
to be accessible every N bytes because they simply don't
decode the full set of address lines.

memory_region_add_subregion_tiled(MemoryRegion *mr,
                                 hwaddr offset, hwaddr tilelen,
                                 MemoryRegion *subregion)

to add copies of subregion to container mr starting at offset
for tilelen bytes, maybe? (we assume subregion to be created
at the length that each 'tile' should be, so don't need to pass
that too).

This hack is meant to exist only as long as OHW has not been replaced by something else. That's a hack which has to be used only for *current OHW firmware* (ie 512KB) and only for *a short time*. I've already patches to replace OHW by OpenBIOS, but some details need some more polish.

So, I don't want to invest too much time to polish this hack. Choose whatever you want, but I don't want to take more time to push this patchset.

If you really don't like it, I can provide a OHW image which is 1MB, so this hack becomes moot. It will be created by concatenating 2 512KB OHW images in a 1MB image.

Regards,

Hervé




reply via email to

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