[Qemu-devel] [PATCH] Add support to sparc for loading a real bios image.

2007-10-05 Thread Robert Reif

Add support to sparc for loading a real bios image.

Index: hw/sun4m.c
===
RCS file: /sources/qemu/qemu/hw/sun4m.c,v
retrieving revision 1.52
diff -p -u -r1.52 sun4m.c
--- hw/sun4m.c  5 Oct 2007 13:08:35 -   1.52
+++ hw/sun4m.c  6 Oct 2007 00:05:16 -
@@ -49,7 +49,7 @@
 #define KERNEL_LOAD_ADDR 0x4000
 #define CMDLINE_ADDR 0x007ff000
 #define INITRD_LOAD_ADDR 0x0080
-#define PROM_SIZE_MAX(256 * 1024)
+#define PROM_SIZE_MAX(512 * 1024)
 #define PROM_PADDR   0xff000ULL
 #define PROM_VADDR   0xffd0
 #define PROM_FILENAME   "openbios-sparc32"
@@ -435,9 +435,12 @@ static void sun4m_load_kernel(long vram_
 snprintf(buf, sizeof(buf), "%s/%s", bios_dir, bios_name);
 ret = load_elf(buf, PROM_PADDR - PROM_VADDR, NULL, NULL, NULL);
 if (ret < 0) {
-   fprintf(stderr, "qemu: could not load prom '%s'\n",
+ret = load_image(buf, phys_ram_base + prom_offset);
+   if (ret < 0) {
+   fprintf(stderr, "qemu: could not load prom '%s'\n",
buf);
-   exit(1);
+   exit(1);
+   }
 }
 
 kernel_size = 0;


[Qemu-devel] qemu/target-ppc cpu.h helper.c op.c translate.c...

2007-10-05 Thread Jocelyn Mayer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/05 22:06:02

Modified files:
target-ppc : cpu.h helper.c op.c translate.c 
 translate_init.c 

Log message:
Full implementation of PowerPC 64 MMU, just missing support for 1 TB
  memory segments.
Remove the PowerPC 64 "bridge" MMU model and implement segment registers
  emulation using SLB entries instead.
Make SLB area size implementation dependant.
Improve TLB & SLB search debug traces.
Temporary hack to make PowerPC 970 boot from ROM instead of RAM.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemu&r1=1.72&r2=1.73
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemu&r1=1.68&r2=1.69
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemu&r1=1.53&r2=1.54
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemu&r1=1.85&r2=1.86
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemu&r1=1.42&r2=1.43




Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

2007-10-05 Thread Natalia Portillo

Hi all,

Just to resume,
I'm in position with Fabrice, Thiemo and Jocelyn.

And, to note.

Current BIOS are very bloated assembler hacks that everytime I use them make 
me think "miracle, it POSTs!"


No way, in a far far away galaxy, there was a simple BIOS, that WONT RUN 
UNDER QEMU.


Why?
Timing?
Doesn't matter to it.

Strange hardware bugs?
Too early for ever knowing they were there.

Source available?
Yes, it is, I don't know the license, but Compaq used it to make the cloned 
BIOS, so we should be able to use it to make QEMU able to POST-It (trademark 
lol)


And if any firmware wants to be an alternative open-source firmware it 
should meet the following requirements:

1.- Be able to boot, unmodified, in real hardware (REAL!)
2.- Be able to boot the same operating systems a closed-source firmware for 
that platform will be. (in REAL hardware)


It is desiderable for QEMU,
no way,
IT IS A MUST FOR QEMU,
to be able to boot real firmware that boots in the real hardware QEMU is 
emulating.


(That is, if QEMU emulates a PIIX4 with Pentium II, it must support booting 
a BIOS for P2+PIIX4, but must not support booting a BIOS for a 
Athlon+nForce)


And, extrapolate what I say to PowerPC, MIPS, ARM, Alpha, Sparc, so on!

Regards,
Natalia Portillo

- Original Message - 
From: "Thiemo Seufer" <[EMAIL PROTECTED]>

To: "Blue Swirl" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; 
Sent: Monday, October 01, 2007 10:57 PM
Subject: Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin



Blue Swirl wrote:
[snip]

> > Qemu is not also aimed for 100% accurate emulation of the hardware.
> > There are no caches or cycle counters and hardware devices run
> > unrealistically fast from CPU standpoint. Emulating performance
> > counters or the errata the most CPUs have would be extremely
> > difficult. I doubt Qemu CPU emulation can ever pass POST of real
> > BIOSes.
>
> I am working on making the Malta emulation boot a unaltered YAMON
> image. I don't see why a PC BIOS would be harder to accomodate.

Emulating microcode, or firmware blobs loaded to misc devices. Think
writing a BIOS for Transmeta,


Writing the emulation for a transmeta is IMHO more challenging than
writing the "BIOS". Btw, if you are interested in the x86 mode, you can
handle the transmeta just as a x86 variant (with a much more standard 
BIOS).



Alpha or a SoC.


Writing "Firmware for a SoC" is part of my dayjob.


> > Real BIOSes are also closed source, proprietary binary blobs.
>
> At least YAMON, CFE and PMON are not closed source. YAMON has a funny
> license which - I hope - will change.
>
> > Making open source BIOSes a viable alternative is in my opinion a 
> > much

> > more important goal.
>
> The one doesn't exclude the other. That said, I regard the ability to
> boot unaltered real-world firmare as an important test of the quality
> of a system emulation.

Maybe. The CPU probes for cacheline size, checks for errata #42 vs
#45, reads debug registers, attempts to identify the bus speed by
comparing I/O access times, tries to verify the system using a TPM and
fails all cases. What can you do?


Improve the emulation to handle at least one probing path.


Thiemo










[Qemu-devel] qemu/linux-user main.c qemu.h signal.c

2007-10-05 Thread Blue Swirl
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl   07/10/05 17:01:51

Modified files:
linux-user : main.c qemu.h signal.c 

Log message:
 Implement sparc64_[gs]et_context

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemu&r1=1.127&r2=1.128
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/qemu.h?cvsroot=qemu&r1=1.37&r2=1.38
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/signal.c?cvsroot=qemu&r1=1.44&r2=1.45




[Qemu-devel] qemu/target-ppc cpu.h translate_init.c

2007-10-05 Thread Jocelyn Mayer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/05 13:11:25

Modified files:
target-ppc : cpu.h translate_init.c 

Log message:
Rename PowerPC MMUCSR0 and MMUCFG SPRs: those are not BookE specific.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemu&r1=1.71&r2=1.72
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemu&r1=1.41&r2=1.42




[Qemu-devel] qemu/target-ppc helper.c translate_init.c

2007-10-05 Thread Jocelyn Mayer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/05 13:09:55

Modified files:
target-ppc : helper.c translate_init.c 

Log message:
PowerPC hardware reset vector is now considered as part of the 
exception model.
Use it at CPU initialisation time.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemu&r1=1.67&r2=1.68
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemu&r1=1.40&r2=1.41




[Qemu-devel] qemu vl.c vl.h hw/mips_malta.c hw/mips_pica61.c...

2007-10-05 Thread Jocelyn Mayer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/05 13:08:35

Modified files:
.  : vl.c vl.h 
hw : mips_malta.c mips_pica61.c mips_r4k.c pc.c 
 ppc405_boards.c ppc_chrp.c ppc_prep.c shix.c 
 sun4m.c sun4u.c 

Log message:
New '-bios' option, used to select an alternate BIOS image from 
bios_dir.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.345&r2=1.346
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.273&r2=1.274
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_malta.c?cvsroot=qemu&r1=1.44&r2=1.45
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_pica61.c?cvsroot=qemu&r1=1.8&r2=1.9
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemu&r1=1.47&r2=1.48
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pc.c?cvsroot=qemu&r1=1.85&r2=1.86
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc405_boards.c?cvsroot=qemu&r1=1.6&r2=1.7
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_chrp.c?cvsroot=qemu&r1=1.43&r2=1.44
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_prep.c?cvsroot=qemu&r1=1.43&r2=1.44
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/shix.c?cvsroot=qemu&r1=1.4&r2=1.5
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemu&r1=1.51&r2=1.52
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4u.c?cvsroot=qemu&r1=1.20&r2=1.21




Re: [Qemu-devel] RFC: cleanups in ELF loader

2007-10-05 Thread J. Mayer
On Thu, 2007-10-04 at 12:20 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> [snip]
> > The thing I see is different is that the n32 ABI redefines elf_greg_t
> > and elf_caddr_t as 32 bits. Maybe I missed something but those types
> > seem not to be used by the ELF loader (or maybe I should look in a more
> > recent kernel ;-) ).
> > Then, I have seen no apparent issue with the patch and I'm quite sure
> > that, even if it's not correct for some specific ABI, it would bring no
> > regression.
> 
> Agreed.

I'd really like to have the though of ARM developpers about it
But if no one seem to report potential issues, I'll commit it.

-- 
J. Mayer <[EMAIL PROTECTED]>
Never organized





Re: [Qemu-devel] RFC: BIOS filename option

2007-10-05 Thread J. Mayer
On Thu, 2007-10-04 at 12:38 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> > Hi,
> > 
> > This is a proposal to allow the user to select a BIOS file name on the
> > command line. The goal is mainly to ease debug, for example when I want
> > to try to run a firmware comming from a real machine instead of the
> > default one.
> > The only change is to add a -bios  option, use the given file
> > if any or use the default if none were given.
> > Maybe the options would be better named as -biosfile Or it maybe a
> > good idea to give a full path, not to concatenate the given name with
> > the bios_dir prefix...
> > Some may find this option is not so useful, as one can specify a
> > directory to find the target BIOS. But I feel more confortable keeping
> > all BIOS images together at the same place.
> 
> I welcome this, especially since the various mips machine emulations
> may have several alternative BIOS implementations soon.

Hi,

OK, I will apply this soon.

-- 
J. Mayer <[EMAIL PROTECTED]>
Never organized