[Qemu-devel] [Patch] Ali Chipset support for PC [+ questions about alpha-softmmu target]

[Qemu-devel] [Patch] Ali Chipset support for PC [+ questions about alpha-softmmu target]

[Brian Wheeler]

Hello!

Long time listener, first time caller...

Since the ES40 Alpha Emulation project seems to have stalled, I've been
looking at what it would take to get QEmu to a state where it could
emulate an alpha machine.  

The es40 is basically a PC with an alpha chip instead of an x86 and it
uses the Ali1543C south bridge.   This basically is a copy of piix_pci.c
so the chipset reports the ALI vendor and device codes to qemu when the
"alipc" machine type is selected.

I've booted Knoppix and it seems to work ok...which is no surpise
considering how minor the changes are.  

So, now to the questions:
* Is anyone else working on a softmmu target for the alpha?

* What state is the alpha cpu emulation in, and what's the best way to
test it?

* What's the most simple -softmmu target that could be used as a
starting point?

* Where is the virtual->physical address translation code?  I peeked
around and couldn't find it very easily. 

* Looking over some of the softmmu targets, it looks like the bulk of
target work (after the cpu emulation, of course) is just attaching all
of the devices in the right places.   

Thanks!
Brian




Index: Makefile.target
===================================================================
--- Makefile.target	(revision 5182)
+++ Makefile.target	(working copy)
@@ -538,7 +538,7 @@
 # Hardware support
 OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
 OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
-OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
+OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o ali.o
 OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o
 CPPFLAGS += -DHAS_AUDIO -DHAS_AUDIO_CHOICE
 endif
Index: target-i386/machine.c
===================================================================
--- target-i386/machine.c	(revision 5182)
+++ target-i386/machine.c	(working copy)
@@ -9,6 +9,8 @@
 {
     qemu_register_machine(&pc_machine);
     qemu_register_machine(&isapc_machine);
+    qemu_register_machine(&alipc_machine);
+
 }
 
 static void cpu_put_seg(QEMUFile *f, SegmentCache *dt)
Index: hw/usb-uhci.c
===================================================================
--- hw/usb-uhci.c	(revision 5182)
+++ hw/usb-uhci.c	(working copy)
@@ -1143,3 +1143,40 @@
 
     register_savevm("uhci", 0, 1, uhci_save, uhci_load, s);
 }
+
+
+void usb_uhci_alisb_init(PCIBus *bus, int devfn)
+{
+    UHCIState *s;
+    uint8_t *pci_conf;
+    int i;
+
+    s = (UHCIState *)pci_register_device(bus,
+                                        "USB-UHCI", sizeof(UHCIState),
+                                        devfn, NULL, NULL);
+    pci_conf = s->dev.config;
+    pci_conf[0x00] = 0xb9;
+    pci_conf[0x01] = 0x10;
+    pci_conf[0x02] = 0x37;
+    pci_conf[0x03] = 0x52;
+    pci_conf[0x08] = 0x03; // revision number
+    pci_conf[0x09] = 0x10;
+    pci_conf[0x0a] = 0x03;
+    pci_conf[0x0b] = 0x0c;
+    pci_conf[0x0e] = 0x00; // header_type
+    pci_conf[0x3d] = 1; 
+
+    for(i = 0; i < NB_PORTS; i++) {
+        qemu_register_usb_port(&s->ports[i].port, s, i, uhci_attach);
+    }
+    s->frame_timer = qemu_new_timer(vm_clock, uhci_frame_timer, s);
+
+    uhci_reset(s);
+
+    /* Use region 4 for consistency with real hardware.  BSD guests seem
+       to rely on this.  */
+    pci_register_io_region(&s->dev, 4, 0x20,
+                           PCI_ADDRESS_SPACE_IO, uhci_map);
+
+    register_savevm("uhci", 0, 1, uhci_save, uhci_load, s);
+}
Index: hw/ide.c
===================================================================
--- hw/ide.c	(revision 5182)
+++ hw/ide.c	(working copy)
@@ -461,6 +461,7 @@
 #define IDE_TYPE_PIIX3   0
 #define IDE_TYPE_CMD646  1
 #define IDE_TYPE_PIIX4   2
+#define IDE_TYPE_ALISB   3
 
 /* CMD646 specific */
 #define MRDMODE		0x71
@@ -3314,6 +3315,61 @@
 }
 
 /***********************************************************/
+/* ALI SB IDE */
+static void alisb_reset(void *opaque)
+{
+    PCIIDEState *d = opaque;
+    uint8_t *pci_conf = d->dev.config;
+    int i;
+
+    for (i = 0; i < 2; i++)
+        ide_dma_cancel(&d->bmdma[i]);
+
+    pci_conf[0x04] = 0x00;
+    pci_conf[0x05] = 0x00;
+    pci_conf[0x06] = 0x80; /* FBC */
+    pci_conf[0x07] = 0x02; // PCI_status_devsel_medium
+    pci_conf[0x20] = 0x01; /* BMIBA: 20-23h */
+}
+
+void pci_alisb_ide_init(PCIBus *bus, BlockDriverState **hd_table, int devfn,
+                        qemu_irq *pic)
+{
+    PCIIDEState *d;
+    uint8_t *pci_conf;
+
+    d = (PCIIDEState *)pci_register_device(bus, "ALISB IDE",
+                                           sizeof(PCIIDEState),
+                                           devfn,
+                                           NULL, NULL);
+    d->type = IDE_TYPE_ALISB;
+
+    pci_conf = d->dev.config;
+    pci_conf[0x00] = 0xb9; // Intel
+    pci_conf[0x01] = 0x10;
+    pci_conf[0x02] = 0x29;
+    pci_conf[0x03] = 0x52;
+    pci_conf[0x09] = 0xFA; 
+    pci_conf[0x0a] = 0x01; // class_sub = PCI_IDE
+    pci_conf[0x0b] = 0x01; // class_base = PCI_mass_storage
+    pci_conf[0x0e] = 0x00; // header_type
+
+    qemu_register_reset(alisb_reset, d);
+    alisb_reset(d);
+
+    pci_register_io_region((PCIDevice *)d, 4, 0x10,
+                           PCI_ADDRESS_SPACE_IO, bmdma_map);
+
+    ide_init2(&d->ide_if[0], hd_table[0], hd_table[1], pic[14]);
+    ide_init2(&d->ide_if[2], hd_table[2], hd_table[3], pic[15]);
+    ide_init_ioport(&d->ide_if[0], 0x1f0, 0x3f6);
+    ide_init_ioport(&d->ide_if[2], 0x170, 0x376);
+
+    register_savevm("ide", 0, 1, pci_ide_save, pci_ide_load, d);
+}
+
+
+/***********************************************************/
 /* MacIO based PowerPC IDE */
 
 /* PowerMac IDE memory IO */
Index: hw/pci.h
===================================================================
--- hw/pci.h	(revision 5182)
+++ hw/pci.h	(working copy)
@@ -108,6 +108,7 @@
 /* usb-uhci.c */
 void usb_uhci_piix3_init(PCIBus *bus, int devfn);
 void usb_uhci_piix4_init(PCIBus *bus, int devfn);
+void usb_uhci_alisb_init(PCIBus *bus, int devfn);
 
 /* usb-ohci.c */
 void usb_ohci_init_pci(struct PCIBus *bus, int num_ports, int devfn);
Index: hw/boards.h
===================================================================
--- hw/boards.h	(revision 5182)
+++ hw/boards.h	(working copy)
@@ -29,6 +29,7 @@
 /* pc.c */
 extern QEMUMachine pc_machine;
 extern QEMUMachine isapc_machine;
+extern QEMUMachine alipc_machine;
 
 /* ppc.c */
 extern QEMUMachine prep_machine;
Index: hw/pc.c
===================================================================
--- hw/pc.c	(revision 5182)
+++ hw/pc.c	(working copy)
@@ -52,6 +52,7 @@
 static PITState *pit;
 static IOAPICState *ioapic;
 static PCIDevice *i440fx_state;
+static PCIDevice *ali_state;
 
 static void ioport80_write(void *opaque, uint32_t addr, uint32_t data)
 {
@@ -730,6 +731,7 @@
     int bios_size, isa_bios_size, vga_bios_size;
     PCIBus *pci_bus;
     int piix3_devfn = -1;
+    int alisb_devfn = -1;
     CPUState *env;
     NICInfo *nd;
     qemu_irq *cpu_irq;
@@ -880,9 +882,12 @@
     i8259 = i8259_init(cpu_irq[0]);
     ferr_irq = i8259[13];
 
-    if (pci_enabled) {
+    if (pci_enabled==1) {
         pci_bus = i440fx_init(&i440fx_state, i8259);
         piix3_devfn = piix3_init(pci_bus, -1);
+    } else if(pci_enabled==2) {
+      pci_bus = ali_init(&ali_state, i8259);
+      alisb_devfn = alisb_init(pci_bus, -1);
     } else {
         pci_bus = NULL;
     }
@@ -984,8 +989,10 @@
 	    hd[i] = NULL;
     }
 
-    if (pci_enabled) {
+    if (pci_enabled==1) {
         pci_piix3_ide_init(pci_bus, hd, piix3_devfn + 1, i8259);
+    } else if(pci_enabled==2) {
+      pci_alisb_ide_init(pci_bus, hd, alisb_devfn + 1, i8259);
     } else {
         for(i = 0; i < MAX_IDE_BUS; i++) {
             isa_ide_init(ide_iobase[i], ide_iobase2[i], i8259[ide_irq[i]],
@@ -1011,7 +1018,10 @@
     cmos_init(below_4g_mem_size, above_4g_mem_size, boot_device, hd);
 
     if (pci_enabled && usb_enabled) {
+      if(pci_enabled==1)
         usb_uhci_piix3_init(pci_bus, piix3_devfn + 2);
+      else
+	usb_uhci_alisb_init(pci_bus, alisb_devfn + 2);
     }
 
     if (pci_enabled && acpi_enabled) {
@@ -1029,6 +1039,10 @@
         i440fx_init_memory_mappings(i440fx_state);
     }
 
+    if (ali_state) {
+      ali_init_memory_mappings(ali_state);
+    }
+
     if (pci_enabled) {
 	int max_bus;
         int bus, unit;
@@ -1060,6 +1074,19 @@
              initrd_filename, 1, cpu_model);
 }
 
+
+static void pc_init_pci_ali(ram_addr_t ram_size, int vga_ram_size,
+                        const char *boot_device, DisplayState *ds,
+                        const char *kernel_filename,
+                        const char *kernel_cmdline,
+                        const char *initrd_filename,
+                        const char *cpu_model)
+{
+    pc_init1(ram_size, vga_ram_size, boot_device, ds,
+             kernel_filename, kernel_cmdline,
+             initrd_filename, 2, cpu_model);
+}
+
 static void pc_init_isa(ram_addr_t ram_size, int vga_ram_size,
                         const char *boot_device, DisplayState *ds,
                         const char *kernel_filename,
@@ -1085,3 +1112,10 @@
     .init = pc_init_isa,
     .ram_require = VGA_RAM_SIZE + PC_MAX_BIOS_SIZE,
 };
+
+QEMUMachine alipc_machine = {
+    .name = "alipc",
+    .desc = "PC with ALI Chipset",
+    .init = pc_init_pci_ali,
+    .ram_require = VGA_RAM_SIZE + PC_MAX_BIOS_SIZE,
+};
Index: hw/pc.h
===================================================================
--- hw/pc.h	(revision 5182)
+++ hw/pc.h	(working copy)
@@ -140,9 +140,18 @@
                         qemu_irq *pic);
 void pci_piix4_ide_init(PCIBus *bus, BlockDriverState **hd_table, int devfn,
                         qemu_irq *pic);
+void pci_alisb_ide_init(PCIBus *bus, BlockDriverState **hd_table, int devfn,
+                        qemu_irq *pic);
 
 /* ne2000.c */
 
 void isa_ne2000_init(int base, qemu_irq irq, NICInfo *nd);
 
+
+/* ali.c */
+PCIBus *ali_init(PCIDevice **ali_state, qemu_irq *pic);
+int alisb_init(PCIBus *bus, int devfn);
+void ali_init_memory_mappings(PCIDevice *d);
+
+
 #endif

Re: [Qemu-devel] [Patch] Ali Chipset support for PC [+ questions about alpha-softmmu target]

[Blue Swirl]

On 9/9/08, Brian Wheeler <bdwheele@indiana.edu> wrote:
> Hello!
>
>  Long time listener, first time caller...
>
>  Since the ES40 Alpha Emulation project seems to have stalled, I've been
>  looking at what it would take to get QEmu to a state where it could
>  emulate an alpha machine.
>
>  The es40 is basically a PC with an alpha chip instead of an x86 and it
>  uses the Ali1543C south bridge.   This basically is a copy of piix_pci.c
>  so the chipset reports the ALI vendor and device codes to qemu when the
>  "alipc" machine type is selected.

IMHO pc.c would support more machines more cleanly if hardware
definition structures like Sparc ones were used.  Otherwise the patch
looks fine to me.

>  I've booted Knoppix and it seems to work ok...which is no surpise
>  considering how minor the changes are.
>
>  So, now to the questions:
>  * Is anyone else working on a softmmu target for the alpha?
>
>  * What state is the alpha cpu emulation in, and what's the best way to
>  test it?
>
>  * What's the most simple -softmmu target that could be used as a
>  starting point?

Depends on what you know, x86 is quite baroque but everyone knows the
basic architecture. Sparc32 is pretty simple.

>  * Where is the virtual->physical address translation code?  I peeked
>  around and couldn't find it very easily.

cpu_*_handle_mmu_fault(), usually in target-*/helper.c.

>  * Looking over some of the softmmu targets, it looks like the bulk of
>  target work (after the cpu emulation, of course) is just attaching all
>  of the devices in the right places.

True. Also it's not hard to create new devices.

Re: [Qemu-devel] [Patch] Ali Chipset support for PC [+ questions about alpha-softmmu target]

[Tristan Gingold]

On Sep 9, 2008, at 5:53 PM, Brian Wheeler wrote:

> Hello!
>
> Long time listener, first time caller...
>
> Since the ES40 Alpha Emulation project seems to have stalled, I've  
> been
> looking at what it would take to get QEmu to a state where it could
> emulate an alpha machine.

Hi,

I had the same idea too.  Qemu should be much faster than es40 emulator.

> The es40 is basically a PC with an alpha chip instead of an x86 and it
> uses the Ali1543C south bridge.   This basically is a copy of  
> piix_pci.c
> so the chipset reports the ALI vendor and device codes to qemu when  
> the
> "alipc" machine type is selected.
>
> I've booted Knoppix and it seems to work ok...which is no surpise
> considering how minor the changes are.
>
> So, now to the questions:
> * Is anyone else working on a softmmu target for the alpha?

I plan to work on it.  But first I have to finish the TCG conversion  
of target-alpha.

> * What state is the alpha cpu emulation in, and what's the best way to
> test it?

Still beta.  It was not maintained nor tested for a while.  And bugs  
were recently found.

> * Looking over some of the softmmu targets, it looks like the bulk of
> target work (after the cpu emulation, of course) is just attaching all
> of the devices in the right places.

Booting might be an issue too as alpha boots from icache.
It looks like es40 has an IO-TLB which is not present in standard  
PC.  I suppose Sparc64 has also
an IO-TLB but I didn't look further.

Tristan.

Re: [Qemu-devel] [Patch] Ali Chipset support for PC [+ questions about alpha-softmmu target]

[Brian Wheeler]

On Wed, 2008-09-10 at 09:30 +0200, Tristan Gingold wrote:
> On Sep 9, 2008, at 5:53 PM, Brian Wheeler wrote:
> 
> > Hello!
> >
> > Long time listener, first time caller...
> >
> > Since the ES40 Alpha Emulation project seems to have stalled, I've  
> > been
> > looking at what it would take to get QEmu to a state where it could
> > emulate an alpha machine.
> 
> Hi,
> 
> I had the same idea too.  Qemu should be much faster than es40 emulator.
> 

That was my thought.  Plus the devices are more fully tested.  I wrote
the IDE stuff (and misc other devices) for es40 and it was really hit or
miss on timing.


> > The es40 is basically a PC with an alpha chip instead of an x86 and it
> > uses the Ali1543C south bridge.   This basically is a copy of  
> > piix_pci.c
> > so the chipset reports the ALI vendor and device codes to qemu when  
> > the
> > "alipc" machine type is selected.
> >
> > I've booted Knoppix and it seems to work ok...which is no surpise
> > considering how minor the changes are.
> >
> > So, now to the questions:
> > * Is anyone else working on a softmmu target for the alpha?
> 
> I plan to work on it.  But first I have to finish the TCG conversion  
> of target-alpha.
> 

Cool.

> > * What state is the alpha cpu emulation in, and what's the best way to
> > test it?
> 
> Still beta.  It was not maintained nor tested for a while.  And bugs  
> were recently found.
> 

Anything that I can do to help?  I worked on es40 (mostly pc-style
hardware stuff) so if I can help I'd like to.

> > * Looking over some of the softmmu targets, it looks like the bulk of
> > target work (after the cpu emulation, of course) is just attaching all
> > of the devices in the right places.
> 
> Booting might be an issue too as alpha boots from icache.
> It looks like es40 has an IO-TLB which is not present in standard  
> PC.  I suppose Sparc64 has also
> an IO-TLB but I didn't look further.

Yeah, the icache thing will be interesting.  Looking at es40, the icache
looks like its only used during the rom decompression stage.  es40
creates a decompressed rom file on the first run and it looks like the
first uint64 is the PC, and the second uint64 is the PAL_BASE.  That
should be enough to get the system up and running (after a software-only
call_pal instruction is implemented)...and it doesn't seem to mess with
the icache in that case.

I may look at a standalone rom extractor, so you can give it the
cl67srmrom.exe file and drop out a ready-to-run rom file.

Brian

> Tristan.
> 
> 
> 

Re: [Qemu-devel] [Patch] Ali Chipset support for PC [+ questions about alpha-softmmu target]

[Tristan Gingold]

>>> * What state is the alpha cpu emulation in, and what's the best  
>>> way to
>>> test it?
>>
>> Still beta.  It was not maintained nor tested for a while.  And bugs
>> were recently found.
>>
>
> Anything that I can do to help?  I worked on es40 (mostly pc-style
> hardware stuff) so if I can help I'd like to.

A simple printf("Hello world\n") program compiled on linux now works  
on qemu (patches
pending).  So the cpu emulation is not that bad.  There are still a  
lot to check (FPU,
overflow) but they are less frequently used.

>
>>> * Looking over some of the softmmu targets, it looks like the  
>>> bulk of
>>> target work (after the cpu emulation, of course) is just  
>>> attaching all
>>> of the devices in the right places.
>>
>> Booting might be an issue too as alpha boots from icache.
>> It looks like es40 has an IO-TLB which is not present in standard
>> PC.  I suppose Sparc64 has also
>> an IO-TLB but I didn't look further.
>
> Yeah, the icache thing will be interesting.  Looking at es40, the  
> icache
> looks like its only used during the rom decompression stage.  es40
> creates a decompressed rom file on the first run and it looks like the
> first uint64 is the PC, and the second uint64 is the PAL_BASE.  That
> should be enough to get the system up and running (after a software- 
> only
> call_pal instruction is implemented)...and it doesn't seem to mess  
> with
> the icache in that case.
>
> I may look at a standalone rom extractor, so you can give it the
> cl67srmrom.exe file and drop out a ready-to-run rom file.

So if you get the SRM decompressed from es40, you can start to work  
on the softmmu
emulation.

Tristan.

Re: [Qemu-devel] [Patch] Ali Chipset support for PC [+ questions about alpha-softmmu target]

[Paul Brook]

> So if you get the SRM decompressed from es40, you can start to work
> on the softmmu emulation.

Does linux actually use the bios at all once it's loaded[1]?
If not the simplest solution may be to load the kernel directly, and ignore 
the machine firmware.

[1] On Open Firmware based systems the kernel tends to use the firmware 
interface for doing initial machine setup and hardware probing.  On most 
other systems there's no real interaction between the bootloader and the 
kernel.  You just load the kernel into ram and set it going..

Paul

Re: [Qemu-devel] [Patch] Ali Chipset support for PC [+ questions about alpha-softmmu target]

[Brian Wheeler]

On Wed, 2008-09-10 at 16:17 +0200, Tristan Gingold wrote:
> >>> * What state is the alpha cpu emulation in, and what's the best  
> >>> way to
> >>> test it?
> >>
> >> Still beta.  It was not maintained nor tested for a while.  And bugs
> >> were recently found.
> >>
> >
> > Anything that I can do to help?  I worked on es40 (mostly pc-style
> > hardware stuff) so if I can help I'd like to.
> 
> A simple printf("Hello world\n") program compiled on linux now works  
> on qemu (patches
> pending).  So the cpu emulation is not that bad.  There are still a  
> lot to check (FPU,
> overflow) but they are less frequently used.
> 
> >
> >>> * Looking over some of the softmmu targets, it looks like the  
> >>> bulk of
> >>> target work (after the cpu emulation, of course) is just  
> >>> attaching all
> >>> of the devices in the right places.
> >>
> >> Booting might be an issue too as alpha boots from icache.
> >> It looks like es40 has an IO-TLB which is not present in standard
> >> PC.  I suppose Sparc64 has also
> >> an IO-TLB but I didn't look further.
> >
> > Yeah, the icache thing will be interesting.  Looking at es40, the  
> > icache
> > looks like its only used during the rom decompression stage.  es40
> > creates a decompressed rom file on the first run and it looks like the
> > first uint64 is the PC, and the second uint64 is the PAL_BASE.  That
> > should be enough to get the system up and running (after a software- 
> > only
> > call_pal instruction is implemented)...and it doesn't seem to mess  
> > with
> > the icache in that case.
> >
> > I may look at a standalone rom extractor, so you can give it the
> > cl67srmrom.exe file and drop out a ready-to-run rom file.
> 
> So if you get the SRM decompressed from es40, you can start to work  
> on the softmmu
> emulation.
> 

I'll start looking at the 21072 (Typhoon) chipset. 

Where does the physical address -> {IO Port, PCI Memory, RAM} routing
take place in QEmu.  I'm seeing lots of registration functions, but I
can't seem to find where the call takes place based upon a physical
address...


Brian


> Tristan.
> 
> 
> 

Re: [Qemu-devel] [Patch] Ali Chipset support for PC [+ questions about alpha-softmmu target]

[Tristan Gingold]

On Sep 10, 2008, at 4:46 PM, Paul Brook wrote:

>> So if you get the SRM decompressed from es40, you can start to work
>> on the softmmu emulation.
>
> Does linux actually use the bios at all once it's loaded[1]?
> If not the simplest solution may be to load the kernel directly,  
> and ignore
> the machine firmware.

The SRM contains the PALcode and any OS depends on PALcode.
MILO is an open-source firmware for Alpha.  Maybe we could start from  
it too.

Re: [Qemu-devel] [Patch] Ali Chipset support for PC [+ questions about alpha-softmmu target]

[Avi Kivity]

Paul Brook wrote:
>> So if you get the SRM decompressed from es40, you can start to work
>> on the softmmu emulation.
>>     
>
> Does linux actually use the bios at all once it's loaded[1]?
>   

On x86, yes (for the e820 map, etc.)

ACPI is in the BIOS, there are 32-bit suspend/resume entry points, etc.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [Patch] Ali Chipset support for PC [+ questions about alpha-softmmu target]

[Paul Brook]

On Wednesday 10 September 2008, Tristan Gingold wrote:
> On Sep 10, 2008, at 4:46 PM, Paul Brook wrote:
> >> So if you get the SRM decompressed from es40, you can start to work
> >> on the softmmu emulation.
> >
> > Does linux actually use the bios at all once it's loaded[1]?
> > If not the simplest solution may be to load the kernel directly,
> > and ignore
> > the machine firmware.
>
> The SRM contains the PALcode and any OS depends on PALcode.
> MILO is an open-source firmware for Alpha.  Maybe we could start from
> it too.

Using an open source bootloader is almost certainly going to make your job a 
lot easier. It's much easier to get things up and running when you can hack 
the bootloader to workaround deficiencies in the emulation, and debug things 
from both ends (instrumentation the bootloader to tell you what it thinks is 
going on).  The final goal may be to run unmodified images from real 
machines, but there are a lot of very useful intermediate steps before you 
get there.

Paul

Re: [Qemu-devel] [Patch] Ali Chipset support for PC [+ questions about alpha-softmmu target]

[Hervé Poussineau]

[-- Attachment #1: Type: text/plain, Size: 418 bytes --]

Hi,

Brian Wheeler a écrit :
> Since the ES40 Alpha Emulation project seems to have stalled, I've been
> looking at what it would take to get QEmu to a state where it could
> emulate an alpha machine.  

I tried some time ago to add an alpha-softmmu target to Qemu.
Unfortunately, it doesn't even try to decode the first instruction, for 
some unknown reason...

Attached patch gives what I have.

Hervé

[-- Attachment #2: es40.diff --]
[-- Type: plain/text, Size: 9591 bytes --]

Re: [Qemu-devel] [Patch] Ali Chipset support for PC [+ questions about alpha-softmmu target]

[Laurent Desnogues]

On Wed, Sep 10, 2008 at 5:19 PM, Tristan Gingold <gingold@adacore.com> wrote:
>
> The SRM contains the PALcode and any OS depends on PALcode.
> MILO is an open-source firmware for Alpha.  Maybe we could start from it
> too.

My understanding is that SRM is required anyway to boot
"modern" Alpha systems.  MILO is used on older systems.

cf: http://www.alphalinux.org/faq/SRM-HOWTO


Laurent

Re: [Qemu-devel] [Patch] Ali Chipset support for PC [+ questions about alpha-softmmu target]

[Brian Wheeler]

I believe Milo was needed for systems with the AlphaBIOS and/or ARC
consoles.  Systems with SRM are unix friendly, so Linux didn't need a
special console for them (and BSD only supported SRM).  As near as I can
tell from the es40 rom, it looks like there are a bunch of diagnostics
in it if you turn them on...

Brian

On Thu, 2008-09-11 at 16:08 +0200, Laurent Desnogues wrote:
> On Wed, Sep 10, 2008 at 5:19 PM, Tristan Gingold <gingold@adacore.com> wrote:
> >
> > The SRM contains the PALcode and any OS depends on PALcode.
> > MILO is an open-source firmware for Alpha.  Maybe we could start from it
> > too.
> 
> My understanding is that SRM is required anyway to boot
> "modern" Alpha systems.  MILO is used on older systems.
> 
> cf: http://www.alphalinux.org/faq/SRM-HOWTO
> 
> 
> Laurent
> 
>