OpenBIOS May 2012

openbios@openbios.org

10 participants
42 discussions

Re: [OpenBIOS] [PATCH 0/2] Sparc64: virtio-block and interrupt support
by Artyom Tarasenko 12 May '12

12 May '12

On Sat, May 12, 2012 at 3:54 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Sat, May 12, 2012 at 1:34 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: >> On Sat, May 12, 2012 at 1:42 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>> Based on Artyom's Sparc64 work (thanks a lot!), I added some minimal >>> support for virtio-block and interrupt nodes. >> >> Hey, that was fast! Does it mean your patches also allow booting from >> a virtio device? > > No, only a warning for the unknown device is avoided and Linux can use > the interrupts. > > Making a simple driver does not look very difficult, here are some examples: > http://fxr.watson.org/fxr/source/dev/virtio/block/virtio_blk.c > http://fxr.watson.org/fxr/source/drivers/block/virtio_blk.c?v=linux-2.6 > http://git.qemu.org/?p=seabios.git;a=blob;f=src/virtio-blk.c;h=194deaf98b41… > Fair enough. On the other hand, if we implement it too soon, there will be less motivation in fixing the cmd646 emulation in qemu... ;-) >>> With these patches and QEMU HEAD, Linux can boot like Artyom describes in >>> http://tyom.blogspot.de/2012_05_01_archive.html >>> but without any manual OpenBIOS setup. >>> >>> Blue Swirl (2): >>> pci: identify virtio-scsi devices >>> Sparc64: fix interrupt properties >>> >>> drivers/ide.c | 2 ++ >>> drivers/pc_serial.c | 3 +++ >>> drivers/pci.c | 23 +++++++++++++++++++++++ >>> drivers/pci_database.c | 19 ++++++++++++++++++- >>> drivers/pci_database.h | 1 + >>> include/drivers/pci.h | 3 +++ >>> 6 files changed, 50 insertions(+), 1 deletion(-) >>> >>> -- >>> 1.7.10 -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] [PATCH 0/2] Sparc64: virtio-block and interrupt support
by Blue Swirl 12 May '12

12 May '12

On Sat, May 12, 2012 at 1:34 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > On Sat, May 12, 2012 at 1:42 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >> Based on Artyom's Sparc64 work (thanks a lot!), I added some minimal >> support for virtio-block and interrupt nodes. > > Hey, that was fast! Does it mean your patches also allow booting from > a virtio device? No, only a warning for the unknown device is avoided and Linux can use the interrupts. Making a simple driver does not look very difficult, here are some examples: http://fxr.watson.org/fxr/source/dev/virtio/block/virtio_blk.c http://fxr.watson.org/fxr/source/drivers/block/virtio_blk.c?v=linux-2.6 http://git.qemu.org/?p=seabios.git;a=blob;f=src/virtio-blk.c;h=194deaf98b41… >> With these patches and QEMU HEAD, Linux can boot like Artyom describes in >> http://tyom.blogspot.de/2012_05_01_archive.html >> but without any manual OpenBIOS setup. >> >> Blue Swirl (2): >> pci: identify virtio-scsi devices >> Sparc64: fix interrupt properties >> >> drivers/ide.c | 2 ++ >> drivers/pc_serial.c | 3 +++ >> drivers/pci.c | 23 +++++++++++++++++++++++ >> drivers/pci_database.c | 19 ++++++++++++++++++- >> drivers/pci_database.h | 1 + >> include/drivers/pci.h | 3 +++ >> 6 files changed, 50 insertions(+), 1 deletion(-) >> >> -- >> 1.7.10 > > > > -- > Regards, > Artyom Tarasenko > > solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] sun4u interrupt-map
by Artyom Tarasenko 12 May '12

12 May '12

On Mon, Apr 9, 2012 at 6:08 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > On Thu, Apr 5, 2012 at 11:54 PM, Tarl Neustaedter <tarl-b2(a)tarl.net> wrote: >> The interrupt mask property should probably be 00ff.ffff, ff . > > Should it matter, if the used one matches the target "reg"? > Btw, thanks Tarl for pointing in the right direction. The problem was that the combination of the interrupt map and mask properties matched _more than one_ "reg". That was confusing the Linux OF tree parser. Out of curiosity: should this mappings be really unique? -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] [PATCH 0/2] Sparc64: virtio-block and interrupt support
by Artyom Tarasenko 12 May '12

12 May '12

On Sat, May 12, 2012 at 1:42 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > Based on Artyom's Sparc64 work (thanks a lot!), I added some minimal > support for virtio-block and interrupt nodes. Hey, that was fast! Does it mean your patches also allow booting from a virtio device? > With these patches and QEMU HEAD, Linux can boot like Artyom describes in > http://tyom.blogspot.de/2012_05_01_archive.html > but without any manual OpenBIOS setup. > > Blue Swirl (2): > pci: identify virtio-scsi devices > Sparc64: fix interrupt properties > > drivers/ide.c | 2 ++ > drivers/pc_serial.c | 3 +++ > drivers/pci.c | 23 +++++++++++++++++++++++ > drivers/pci_database.c | 19 ++++++++++++++++++- > drivers/pci_database.h | 1 + > include/drivers/pci.h | 3 +++ > 6 files changed, 50 insertions(+), 1 deletion(-) > > -- > 1.7.10 -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

[commit] r1057 - trunk/openbios-devel/arch/sparc32
by repository service 12 May '12

12 May '12

Author: blueswirl Date: Sat May 12 13:43:57 2012 New Revision: 1057 URL: http://tracker.coreboot.org/trac/openbios/changeset/1057 Log: Sparc32: avoid problems with SMP table Check CPU ID if we're running on boot CPU. If so, don't use SMP table information since it may contain uninitialized or garbage values. Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Modified: trunk/openbios-devel/arch/sparc32/entry.S Modified: trunk/openbios-devel/arch/sparc32/entry.S ============================================================================== --- trunk/openbios-devel/arch/sparc32/entry.S Sat Apr 28 15:35:06 2012 (r1056) +++ trunk/openbios-devel/arch/sparc32/entry.S Sat May 12 13:43:57 2012 (r1057) @@ -126,12 +126,23 @@ set 0x2000, %g3 sub %g1, %g3, %g6 + ! Check if this is the boot CPU and skip SMP table check if yes + ! XXX: not all CPUs should have MXCC + set 0x1c00f00, %g2 + ldda [%g2] ASI_CONTROL, %g2 + srl %g3, 24, %g7 + sub %g7, 8, %g7 + tst %g7 + bz skip_table + nop + ! Calculate SMP table location set 0x1f0c, %g2 add %g6, %g2, %g2 ! valid? lda [%g2] ASI_M_BYPASS, %g7 sta %g0, [%g2] ASI_M_BYPASS +skip_table: ! Get machine ID from configuration device mov FW_CFG_MACHINE_ID, %g2 sub %g5, 2, %g5

1 0

[PATCH 2/2] Sparc64: fix interrupt properties
by Blue Swirl 12 May '12

12 May '12

Add interrupt-map and interrupt-mask properties to host bridge and sprinkle interrupt properties to various devices. Based on hack by Artyom Tarasenko. Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> --- drivers/ide.c | 2 ++ drivers/pc_serial.c | 3 +++ drivers/pci.c | 23 +++++++++++++++++++++++ drivers/pci_database.c | 2 +- drivers/pci_database.h | 1 + 5 files changed, 30 insertions(+), 1 deletion(-) diff --git a/drivers/ide.c b/drivers/ide.c index 0d09bcd..90138ff 100644 --- a/drivers/ide.c +++ b/drivers/ide.c @@ -1432,6 +1432,8 @@ int ob_ide_init(const char *path, uint32_t io_port0, uint32_t ctl_port0, props[0]=14; props[1]=0; set_property(dnode, "interrupts", (char *)&props, 2*sizeof(props[0])); +#elif defined(CONFIG_SPARC64) + set_int_property(get_cur_dev(), "interrupts", 0); #endif props[0] = __cpu_to_be32(chan->io_regs[0]); diff --git a/drivers/pc_serial.c b/drivers/pc_serial.c index 583d1c0..5882a05 100644 --- a/drivers/pc_serial.c +++ b/drivers/pc_serial.c @@ -190,6 +190,9 @@ ob_pc_serial_init(const char *path, const char *dev_name, uint64_t base, fword("encode+"); push_str("reg"); fword("property"); +#if defined(CONFIG_SPARC64) + set_int_property(get_cur_dev(), "interrupts", 1); +#endif aliases = find_dev("/aliases"); set_property(aliases, "ttya", nodebuff, strlen(nodebuff) + 1); diff --git a/drivers/pci.c b/drivers/pci.c index e270a73..1e68000 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -401,6 +401,21 @@ static void pci_host_set_interrupt_map(const pci_config_t *config) props[PCI_INT_MAP_PCI_INT] = 0x7; set_property(dev, "interrupt-map-mask", (char *)props, 4 * sizeof(props[0])); +#elif defined(CONFIG_SPARC64) + phandle_t dev = get_cur_dev(); + uint32_t props[5]; + + props[0] = 0x000001fe; + props[1] = 0x020003f8; + props[2] = 1; + props[3] = find_dev("/"); + props[4] = 0x2b; + set_property(dev, "interrupt-map", (char *)props, 5 * sizeof(props[0])); + + props[0] = 0x000001ff; + props[1] = 0xffffffff; + props[2] = 3; + set_property(dev, "interrupt-map-mask", (char *)props, 3 * sizeof(props[0])); #endif } @@ -522,6 +537,14 @@ int bridge_config_cb(const pci_config_t *config) return 0; } +int virtio_config_cb(const pci_config_t *config) +{ +#if defined(CONFIG_SPARC64) + set_int_property(get_cur_dev(), "interrupts", 0); +#endif + return 0; +} + int ide_config_cb2 (const pci_config_t *config) { ob_ide_init(config->path, diff --git a/drivers/pci_database.c b/drivers/pci_database.c index 7d420c3..1d2958c 100644 --- a/drivers/pci_database.c +++ b/drivers/pci_database.c @@ -52,7 +52,7 @@ static const pci_dev_t scsi_devices[] = { NULL, "virtio-scsi", NULL, "pci1af4,1001\0pci1af4,1001\0pciclass,01018f\0", 0, 0, 0, - NULL, NULL, + virtio_config_cb, NULL, }, { 0xFFFF, 0xFFFF, diff --git a/drivers/pci_database.h b/drivers/pci_database.h index 5ddbb20..5459032 100644 --- a/drivers/pci_database.h +++ b/drivers/pci_database.h @@ -28,6 +28,7 @@ struct pci_dev_t { const void *private; }; +extern int virtio_config_cb(const pci_config_t *config); extern int ide_config_cb2(const pci_config_t *config); extern int eth_config_cb(const pci_config_t *config); extern int macio_heathrow_config_cb(const pci_config_t *config); -- 1.7.10

1 0

[PATCH 1/2] pci: identify virtio-scsi devices
by Blue Swirl 12 May '12

12 May '12

Identify virtio SCSI device in PCI probe. Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> --- drivers/pci_database.c | 19 ++++++++++++++++++- include/drivers/pci.h | 3 +++ 2 files changed, 21 insertions(+), 1 deletion(-) diff --git a/drivers/pci_database.c b/drivers/pci_database.c index ac47621..7d420c3 100644 --- a/drivers/pci_database.c +++ b/drivers/pci_database.c @@ -45,6 +45,23 @@ static const pci_subclass_t undef_subclass[] = { }, }; +static const pci_dev_t scsi_devices[] = { + { + /* Virtio-block controller */ + PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_DEVICE_ID_VIRTIO_BLOCK, + NULL, "virtio-scsi", NULL, + "pci1af4,1001\0pci1af4,1001\0pciclass,01018f\0", + 0, 0, 0, + NULL, NULL, + }, + { + 0xFFFF, 0xFFFF, + NULL, NULL, NULL, NULL, + -1, -1, -1, + NULL, NULL, + }, +}; + static const pci_dev_t ide_devices[] = { { PCI_VENDOR_ID_CMD, PCI_DEVICE_ID_CMD_646, /* CMD646 IDE controller */ @@ -64,7 +81,7 @@ static const pci_dev_t ide_devices[] = { static const pci_subclass_t mass_subclass[] = { { PCI_SUBCLASS_STORAGE_SCSI, "SCSI bus controller", - NULL, NULL, NULL, + "scsi", scsi_devices, NULL, NULL, NULL, }, { diff --git a/include/drivers/pci.h b/include/drivers/pci.h index 562a43e..4c996c0 100644 --- a/include/drivers/pci.h +++ b/include/drivers/pci.h @@ -205,6 +205,9 @@ extern const pci_arch_t *arch; #define PCI_VENDOR_ID_QEMU 0x1234 #define PCI_DEVICE_ID_QEMU_VGA 0x1111 +#define PCI_VENDOR_ID_REDHAT_QUMRANET 0x1af4 +#define PCI_DEVICE_ID_VIRTIO_BLOCK 0x1001 + #define PCI_VENDOR_ID_INTEL 0x8086 #define PCI_DEVICE_ID_INTEL_82441 0x1237 -- 1.7.10

1 0

[PATCH 0/2] Sparc64: virtio-block and interrupt support
by Blue Swirl 12 May '12

12 May '12

Based on Artyom's Sparc64 work (thanks a lot!), I added some minimal support for virtio-block and interrupt nodes. With these patches and QEMU HEAD, Linux can boot like Artyom describes in http://tyom.blogspot.de/2012_05_01_archive.html but without any manual OpenBIOS setup. Blue Swirl (2): pci: identify virtio-scsi devices Sparc64: fix interrupt properties drivers/ide.c | 2 ++ drivers/pc_serial.c | 3 +++ drivers/pci.c | 23 +++++++++++++++++++++++ drivers/pci_database.c | 19 ++++++++++++++++++- drivers/pci_database.h | 1 + include/drivers/pci.h | 3 +++ 6 files changed, 50 insertions(+), 1 deletion(-) -- 1.7.10

1 0

Re: [OpenBIOS] [PATCH] pci: fix BAR setup
by Jakub Jermar 12 May '12

12 May '12

Hi Artyom, all, On 04/19/2012 10:29 PM, Artyom Tarasenko wrote: > On Thu, Apr 19, 2012 at 10:04 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >> On Thu, Apr 19, 2012 at 19:06, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: >>> On Sun, Mar 11, 2012 at 11:59 AM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>>> A change in QEMU on how PCI bridges are setup revealed >>>> a bug in OpenBIOS PCI setup. On Sparc64, the BARs just >>>> happened to get somewhat correct values by accident before >>>> the commit but not after the change. >>>> >>>> Don't use arch->io_base for PCI I/O port BARs. >>>> >>>> Fix Sparc64 PCI memory base. >>> >>> Could it be that the ranges property needs to be adjusted to look as >>> it did before the patch? >>> >>> This patch breaks HelenOS-0.4.3/sparc boot. But if I modify the ranges >>> property to the old value, HelenOS boots. >>> >>> 0 > cd /pci@1fe,0 ok >>> 0 > .properties >>> [...] >>> ranges -- 54 : 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 01 fe 01 00 00 00 00 00 00 00 02 00 00 00 01 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 01 fe 02 00 00 00 00 00 00 00 00 01 00 00 02 00 >>> 00 00 00 00 00 00 00 10 00 00 00 00 01 ff 00 00 00 00 00 00 00 00 10 >>> 00 00 00 >>> >>> Not sure about the best formatting. If I reformat it like this: >>> >>> 00000000 00000000 00000000 000001fe 01000000 00000000 02000000 >>> 01000000 00000000 00000000 000001fe 02000000 00000000 00010000 >>> 02000000 00000000 00100000 000001ff 00000000 00000000 10000000 >>> ^^^^ this one (the third) used to be 0 >>> >> >> On an Ultra-5 this should be >> 00000000.00000000.00000000.000001fe.01000000.00000000.01000000. >> 01000000.00000000.00000000.000001fe.02000000.00000000.01000000. >> 02000000.00000000.00000000.000001ff.00000000.00000001.00000000. >> 03000000.00000000.00000000.000001ff.00000000.00000001.00000000 >> >> http://git.kernel.org/?p=linux/kernel/git/davem/prtconfs.git;a=blob;f=ultra… >> >> I guess the problem is that the properties are added by finding the >> host bridge in the PCI bus (which btw isn't so nice), so we use the >> pci_mem_base. Using pci_mem_base = 0 would probably fix the BAR, but >> then VGA would get in the way. Probably something more complex is >> needed. > > Hmm. Complicated. What is actually the meaning of this property? Don't > we need the values ourselves? > If these are just BARs, can't we pass the configuration from qemu? I am now looking into this from the HelenOS point of view. The problem is that HelenOS miscomputes the framebuffer physical address. I think I found the culprit in the ranges property of the PCI node. The mechanism of the bug seems to be as follows. HelenOS reads the parent-relative address of the VGA node from the reg property. The address is 0x008000000. It then wants to apply it on the parent node's (PCI) ranges property. Using a packed C structure, a range is defined as follows: typedef struct { uint32_t space; uint64_t child_base; uint64_t parent_base; uint64_t size; }; Note that in our case, the matching range is: 02000000 00000000 00100000 000001ff 00000000 00000000 10000000 child_base is 0x00100000 parent_base is 0x1ff00000000 reg_addr is 0x00800000 HelenOS then computes the resulting physical address using this formula: pa = parent_base + (reg_addr - child_base); The result is thus 0x1ff00700000 instead of the correct value 0x1ff00800000. So it looks like either the child base should be 0, or reg_addr must be 0x00900000, or parent_base must be 0x1ff00100000. From the way this works e.g. on Sun E6500, the last option seems to be the correct one. What do you think of it? Jakub

3 2

Re: [OpenBIOS] sparc-softmmu uninitialized memory read?
by Andreas Färber 06 May '12

06 May '12

Am 06.05.2012 18:44, schrieb Blue Swirl: > On Sun, May 6, 2012 at 2:02 PM, Andreas Färber <afaerber(a)suse.de> wrote: >> Am 06.05.2012 13:32, schrieb Blue Swirl: >>> On Sat, May 5, 2012 at 3:37 PM, Andreas Färber <afaerber(a)suse.de> wrote: >>>> Hello Blue, >>>> >>>> Testing a potential AREG0 fix for ppc host by malc I got an error >>>> running `./sparc-softmmu/sparc-softmmu` (same with CD/kernel): >>>> >>>> qemu: fatal: Trap 0x07 while interrupts disabled, Error state >>>> pc: 00005e0c npc: 00005e10 >>>> General Registers: >>>> %g0-7: 00000000 00000001 babababa 00000000 00000020 07ffff08 07ffe000 >>>> babababa >>>> >>>> Current Register Window: >>>> %o0-7: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >>>> 00000000 >>>> %l0-7: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >>>> 00000000 >>>> %i0-7: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >>>> 00000000 >>>> >>>> Floating Point Registers: >>>> %f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >>>> %f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >>>> %f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >>>> %f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >>>> psr: 048000c0 (icc: N--- SPE: SP-) wim: 00000001 >>>> fsr: 00000000 y: 00000020 >>>> Abgebrochen >>>> >>>> The 0xbabababa in %g2 and %g7 is a signature I've seen in uninitialized >>>> memory on openSUSE 12.1 Betas. So I ran valgrind, and the following >>>> caught my eye on both ppc and x86_64: >>>> >>>> ==18801== Command: ./sparc-softmmu/qemu-system-sparc >>>> ==18801== >>>> ==18801== Thread 2: >>>> ==18801== Conditional jump or move depends on uninitialised value(s) >>>> ==18801== at 0x25C5AF: compute_all_logic (cc_helper.c:37) >>>> ==18801== by 0x25C648: helper_compute_psr (cc_helper.c:470) >>>> ==18801== by 0x8CD0981: ??? >>>> ==18801== Uninitialised value was created by a heap allocation >>>> ==18801== at 0x4C27CE8: memalign (in >>>> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) >>>> ==18801== by 0x4C27D97: posix_memalign (in >>>> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) >>>> ==18801== by 0x1F2101: qemu_memalign (oslib-posix.c:93) >>>> ==18801== by 0x1F21A9: qemu_vmalloc (oslib-posix.c:126) >>>> ==18801== by 0x2665F6: qemu_ram_alloc_from_ptr (exec.c:2647) >>>> ==18801== by 0x286D76: memory_region_init_ram (memory.c:954) >>>> ==18801== by 0x297FFD: ram_init1 (sun4m.c:757) >>>> ==18801== by 0x204DAE: qdev_init (qdev.c:151) >>>> ==18801== by 0x204EEC: qdev_init_nofail (qdev.c:258) >>>> ==18801== by 0x298845: ram_init.constprop.7 (sun4m.c:783) >>>> ==18801== by 0x298980: sun4m_hw_init (sun4m.c:862) >>>> ==18801== by 0x2994A2: ss5_init (sun4m.c:1289) >>>> >>>> This is at 8f473dd104f0937ce98523fa6f9de0bd845aebbe, and cc_helper.c:37 >>>> is int32_t dst argument of get_NZ_icc(), which is always called with >>>> CC_DST, i.e. env->cc_dst. >>>> >>>> This seems to indicate that a read from uninitialized memory occurred, >>>> from which cc_dst is being initialized? >>> >>> This should happen in target-sparc/cpu.c:45 >>> memset(env, 0, offsetof(CPUSPARCState, breakpoints)); >>> >>> cc_dst is between structure start and CPU_COMMON. >>> >>> 89aaf60dedbe0e6415acfe816e02b538e5c54e68 fixed a bug relating to reset recently. >> >> The still-current master commit above includes that fix though, and >> that's no explanation for the uninitialized memory stemming from sun4m >> RAM as opposed to QOM object_new(). Somewhere a read is happening, >> possibly in OpenBIOS, from uninitialized memory that is then stored into >> the CPUSPARCState after that has been zero-initialized, IIUC. > > Ok, I see it now. OpenBIOS assumes that the Sparc32 SMP table is valid > when the valid field is nonzero, indicating secondary processor setup > so OpenBIOS jumps to the location indicated with the SMP table. With > 0xbabababa in memory, this fragile logic fails and there is the early > crash. > https://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel/arc… > https://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel/arc… Great! I have tested the following workaround: diff --git a/hw/sun4m.c b/hw/sun4m.c index 34088ad..55d5bdc 100644 --- a/hw/sun4m.c +++ b/hw/sun4m.c @@ -755,6 +755,7 @@ static int ram_init1(SysBusDevice *dev) RamDevice *d = FROM_SYSBUS(RamDevice, dev); memory_region_init_ram(&d->ram, "sun4m.ram", d->size); + memset(memory_region_get_ram_ptr(&d->ram), 0, d->size); vmstate_register_ram_global(&d->ram); sysbus_init_mmio(dev, &d->ram); return 0; This makes sparc32 work on ppc with malc's attached patch (and doesn't break on x86_64). Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

2 1