Hi all,
As it still seems there are some memory issues with SPARC32 (even with the new patches), I've just tried increasing the memory for the Forth machine from 128K to 256K by making the following change in arch/sparc32/openbios.c:
--- arch/sparc32/openbios.c (revision 918) +++ arch/sparc32/openbios.c (working copy) @@ -26,7 +26,7 @@ #define NO_QEMU_PROTOS #include "arch/common/fw_cfg.h"
-#define MEMORY_SIZE (128*1024) /* 16K ram for hosted system */ +#define MEMORY_SIZE (256*1024) /* 16K ram for hosted system */ #define DICTIONARY_SIZE (256*1024) /* 256K for the dictionary */ #define UUID_FMT "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x" #define FW_CFG_SUN4M_DEPTH (FW_CFG_ARCH_LOCAL + 0x00)
However, with this change in place OpenBIOS just freezes on boot after emitting "Configuration device id QEMU version 1 machine id 32". Does anyone know anything about the SPARC32 memory code to know why changing this constant doesn't just work?
ATB,
Mark.
Hi,
Am 25.10.2010 um 11:02 schrieb Mark Cave-Ayland:
I've just tried increasing the memory for the Forth machine from 128K to 256K by making the following change in arch/sparc32/ openbios.c:
--- arch/sparc32/openbios.c (revision 918) +++ arch/sparc32/openbios.c (working copy) @@ -26,7 +26,7 @@ #define NO_QEMU_PROTOS #include "arch/common/fw_cfg.h"
-#define MEMORY_SIZE (128*1024) /* 16K ram for hosted system */ +#define MEMORY_SIZE (256*1024) /* 16K ram for hosted system */ #define DICTIONARY_SIZE (256*1024) /* 256K for the dictionary */ #define UUID_FMT "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x %02x%02x%02x%02x%02x" #define FW_CFG_SUN4M_DEPTH (FW_CFG_ARCH_LOCAL + 0x00)
However, with this change in place OpenBIOS just freezes on boot after emitting "Configuration device id QEMU version 1 machine id 32".
I think you need to adjust VMEM_SIZE in arch/sparc32/ldscript accordingly...
Andreas
Andreas Färber wrote:
I think you need to adjust VMEM_SIZE in arch/sparc32/ldscript accordingly...
Andreas
I've just tried that, and still no dice starting qemu with the new ROM:
./qemu-system-sparc -cdrom /home/build/src/qemu/sparcimage/sol8-cd1.iso -boot d -nographic rom: requested regions overlap (rom /home/build/rel-qemu-git/share/qemu/openbios-sparc32. free=0x0000000070107000, addr=0x0000000070000000) rom loading failed
Does this error mean that the ROMs are larger than the memory space allocated to them? Given that the SPARC32 ROM appears to load at 0xffd00000, surely that means the ROM can be a couple of MB without any problem? Currently the size on disk of the unstripped ROM is around 540KB which should be fine.
ATB,
Mark.
On Tue, Oct 26, 2010 at 10:46 AM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Andreas Färber wrote:
I think you need to adjust VMEM_SIZE in arch/sparc32/ldscript accordingly...
Andreas
I've just tried that, and still no dice starting qemu with the new ROM:
./qemu-system-sparc -cdrom /home/build/src/qemu/sparcimage/sol8-cd1.iso -boot d -nographic rom: requested regions overlap (rom /home/build/rel-qemu-git/share/qemu/openbios-sparc32. free=0x0000000070107000, addr=0x0000000070000000) rom loading failed
Does this error mean that the ROMs are larger than the memory space allocated to them? Given that the SPARC32 ROM appears to load at 0xffd00000, surely that means the ROM can be a couple of MB without any problem?
Currently not a couple. hw/sun4m.c:
#define PROM_SIZE_MAX (1024 * 1024)
Currently the size on disk of the unstripped ROM is around 540KB which should be fine.
Yes, should be fine. But looks like you are hitting 512KiB limit somewhere...
Artyom Tarasenko wrote:
Does this error mean that the ROMs are larger than the memory space allocated to them? Given that the SPARC32 ROM appears to load at 0xffd00000, surely that means the ROM can be a couple of MB without any problem?
Currently not a couple. hw/sun4m.c:
#define PROM_SIZE_MAX (1024 * 1024)
Right - but we should still be well under this limit.
Currently the size on disk of the unstripped ROM is around 540KB which should be fine.
Yes, should be fine. But looks like you are hitting 512KiB limit somewhere...
Actually, not even that. If I copy across the unstripped version (which is 220K on my system) then I get exactly the same error message. I think that the error message here is likely misleading, and it's maybe something to do with one of the section sizes in the output binary image rather than the entire binary image size.
ATB,
Mark.