[Qemu-devel] [PATCH 0/4] ppc: Fix PReP emulation

[Qemu-devel] [PATCH 0/4] ppc: Fix PReP emulation

[Andreas Färber]

Hello,

Based on an earlier attempt of mine to make OpenBIOS work with -M prep,
with kind support from Hervé Poussineau here's an initial stab at
fixing the long-broken PReP emulation and preparing migration from
abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware.

In particular a number of hw_error()s are resolved, so that the BIOS
can be entered at all. It is not yet working in terms of serial and
VGA support etc.

This series is also available from:

git://repo.or.cz/qemu/afaerber.git prep-queue

Some more work-in-progress for the curious is on my prep branch [2].
The corresponding work-in-progress OpenBIOS changes are at [3].

Unfortunately the prep machine is lacking documentation what exactly it
tries to emulate. The plan thus is to merge emulation of a second, real
IBM 40p machine based on Hervé's work at [1], for use with original
binary firmware.

Also upcoming are new ppc_chrp machines, forked from ppc_newworld,
emulating the 970-based IBM JS20 (using Apple U3) [4] and possibly the
POWER5-based IntelliStation 285. These depend on the ongoing ppc64 port
of OpenBIOS to be completed though. This relates to PReP in that the
machine IDs will need to be coordinated.

Have fun,
Andreas

[1] git://repo.or.cz/qemu/hpoussin.git ppc
    http://repo.or.cz/w/qemu/hpoussin.git/shortlog/refs/heads/ppc
[2] http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/prep
[3] http://repo.or.cz/w/openbios/afaerber.git/shortlog/refs/heads/prep
[4] http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/aix

Andreas Färber (4):
  prep: Remove bogus BIOS size check
  prep: Add ELF support
  prep: Fix duplicate ISA IDE IRQ
  prep: Quickfix for ioport

 hw/ppc_prep.c |   31 ++++++++++++++++++-------------
 1 files changed, 18 insertions(+), 13 deletions(-)

-- 
1.7.3

[Qemu-devel] [PATCH 1/4] prep: Remove bogus BIOS size check

[Andreas Färber]

r3480 added this check to account for the entry vector 0xfff00100 to be
available for CPUs that need it. Today however, the NIP is not yet
initialized at this point (zero), so the check always triggers.

Cc: Hervé Poussineau <hpoussin@reactos.org>
Cc: Alexander Graf <agraf@suse.de>
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
---
 hw/ppc_prep.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
index 1492266..6b22122 100644
--- a/hw/ppc_prep.c
+++ b/hw/ppc_prep.c
@@ -600,9 +600,6 @@ static void ppc_prep_init (ram_addr_t ram_size,
     if (filename) {
         qemu_free(filename);
     }
-    if (env->nip < 0xFFF80000 && bios_size < 0x00100000) {
-        hw_error("PowerPC 601 / 620 / 970 need a 1MB BIOS\n");
-    }
 
     if (linux_boot) {
         kernel_base = KERNEL_LOAD_ADDR;
-- 
1.7.3

[Qemu-devel] [PATCH 2/4] prep: Add ELF support

[Andreas Färber]

In order to switch from abondoned OpenHack'Ware to OpenBIOS firmware,
the PReP machine needs to be able to load an ELF BIOS.

ELF loading is adapted from ppc_newworld, the fallback mechanism from sun4m.

Note that since we must register the maximum amount of ROM before attempting
to load an ELF BIOS and since there is no cpu_unregister_physical_memory(),
raw BIOS files such as OHW may now be preceded by unused ROM memory.

Cc: Alexander Graf <agraf@suse.de>
Cc: Hervé Poussineau <hpoussin@reactos.org>
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
---
 hw/ppc_prep.c |   24 +++++++++++++++---------
 1 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
index 6b22122..3575dee 100644
--- a/hw/ppc_prep.c
+++ b/hw/ppc_prep.c
@@ -36,6 +36,7 @@
 #include "qemu-log.h"
 #include "ide.h"
 #include "loader.h"
+#include "elf.h"
 #include "mc146818rtc.h"
 #include "blockdev.h"
 
@@ -582,18 +583,23 @@ static void ppc_prep_init (ram_addr_t ram_size,
         bios_name = BIOS_FILENAME;
     filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
     if (filename) {
-        bios_size = get_image_size(filename);
+        cpu_register_physical_memory(0xfff00000, BIOS_SIZE,
+                                     bios_offset | IO_MEM_ROM);
+        bios_size = load_elf(filename, NULL, NULL, NULL,
+                             NULL, NULL, 1, ELF_MACHINE, 0);
+        if (bios_size < 0 || bios_size > BIOS_SIZE) {
+            bios_size = get_image_size(filename);
+            if (bios_size > 0 && bios_size <= BIOS_SIZE) {
+                target_phys_addr_t bios_addr;
+                bios_size = (bios_size + 0xfff) & ~0xfff;
+                bios_addr = (uint32_t)(-bios_size);
+                bios_size = load_image_targphys(filename, bios_addr,
+                                                bios_size);
+            }
+        }
     } else {
         bios_size = -1;
     }
-    if (bios_size > 0 && bios_size <= BIOS_SIZE) {
-        target_phys_addr_t bios_addr;
-        bios_size = (bios_size + 0xfff) & ~0xfff;
-        bios_addr = (uint32_t)(-bios_size);
-        cpu_register_physical_memory(bios_addr, bios_size,
-                                     bios_offset | IO_MEM_ROM);
-        bios_size = load_image_targphys(filename, bios_addr, bios_size);
-    }
     if (bios_size < 0 || bios_size > BIOS_SIZE) {
         hw_error("qemu: could not load PPC PREP bios '%s'\n", bios_name);
     }
-- 
1.7.3

[Qemu-devel] [PATCH, RFC 3/4] prep: Fix duplicate ISA IDE IRQ

[Andreas Färber]

Calling isa_ide_init() twice with the same IRQ 13 fails:

qemu: hardware error: isa irq 13 already assigned

Use a different IRQ (14) for the second one to avoid this.

Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Cc: Alexander Graf <agraf@suse.de>
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
---
 hw/ppc_prep.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
index 3575dee..3073870 100644
--- a/hw/ppc_prep.c
+++ b/hw/ppc_prep.c
@@ -76,7 +76,7 @@ qemu_log_mask(CPU_LOG_IOPORT, fmt, ## __VA_ARGS__)
 /* Constants for devices init */
 static const int ide_iobase[2] = { 0x1f0, 0x170 };
 static const int ide_iobase2[2] = { 0x3f6, 0x376 };
-static const int ide_irq[2] = { 13, 13 };
+static const int ide_irq[2] = { 13, 14 };
 
 #define NE2000_NB_MAX 6
 
-- 
1.7.3

[Qemu-devel] [FYI 4/4] prep: Quickfix for ioport

[Andreas Färber]

Workaround the following error:

qemu: hardware error: register_ioport_read: invalid opaque

Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
---
 hw/ppc_prep.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
index 3073870..0c9183e 100644
--- a/hw/ppc_prep.c
+++ b/hw/ppc_prep.c
@@ -721,8 +721,10 @@ static void ppc_prep_init (ram_addr_t ram_size,
     register_ioport_read(0x398, 2, 1, &PREP_io_read, sysctrl);
     register_ioport_write(0x398, 2, 1, &PREP_io_write, sysctrl);
     /* System control ports */
+#if 0
     register_ioport_read(0x0092, 0x01, 1, &PREP_io_800_readb, sysctrl);
     register_ioport_write(0x0092, 0x01, 1, &PREP_io_800_writeb, sysctrl);
+#endif
     register_ioport_read(0x0800, 0x52, 1, &PREP_io_800_readb, sysctrl);
     register_ioport_write(0x0800, 0x52, 1, &PREP_io_800_writeb, sysctrl);
     /* PCI intack location */
-- 
1.7.3

Re: [Qemu-devel] [FYI 4/4] prep: Quickfix for ioport

[Andreas Färber]

Am 14.12.2010 um 01:49 schrieb Andreas Färber:

> Workaround the following error:
>
> qemu: hardware error: register_ioport_read: invalid opaque

I found out that this is a conflict with i8042 registering I/O port  
0x0092 in pckbd.c, too.
Not sure what the proper fix should look like - add some qdev property  
to ISAKBDState to disable the port?

Andreas

> Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
> Signed-off-by: Andreas Färber <andreas.faerber@web.de>
> ---
> hw/ppc_prep.c |    2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
> index 3073870..0c9183e 100644
> --- a/hw/ppc_prep.c
> +++ b/hw/ppc_prep.c
> @@ -721,8 +721,10 @@ static void ppc_prep_init (ram_addr_t ram_size,
>   register_ioport_read(0x398, 2, 1, &PREP_io_read, sysctrl);
>   register_ioport_write(0x398, 2, 1, &PREP_io_write, sysctrl);
>   /* System control ports */
> +#if 0
>   register_ioport_read(0x0092, 0x01, 1, &PREP_io_800_readb, sysctrl);
>   register_ioport_write(0x0092, 0x01, 1, &PREP_io_800_writeb,  
> sysctrl);
> +#endif
>   register_ioport_read(0x0800, 0x52, 1, &PREP_io_800_readb, sysctrl);
>   register_ioport_write(0x0800, 0x52, 1, &PREP_io_800_writeb,  
> sysctrl);
>   /* PCI intack location */
> -- 
> 1.7.3
>
>

Re: [Qemu-devel] [FYI 4/4] prep: Quickfix for ioport

[Alexander Graf]

Am 27.12.2010 um 00:28 schrieb Andreas Färber <andreas.faerber@web.de>:

> Am 14.12.2010 um 01:49 schrieb Andreas Färber:
> 
>> Workaround the following error:
>> 
>> qemu: hardware error: register_ioport_read: invalid opaque
> 
> I found out that this is a conflict with i8042 registering I/O port 0x0092 in pckbd.c, too.
> Not sure what the proper fix should look like - add some qdev property to ISAKBDState to disable the port?

Well, why does the PREP board have its own mapping there in the first place? It should be the same as a PC from a port pov, no?

Alex


> 
> Andreas
> 
>> Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
>> Signed-off-by: Andreas Färber <andreas.faerber@web.de>
>> ---
>> hw/ppc_prep.c |    2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>> 
>> diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
>> index 3073870..0c9183e 100644
>> --- a/hw/ppc_prep.c
>> +++ b/hw/ppc_prep.c
>> @@ -721,8 +721,10 @@ static void ppc_prep_init (ram_addr_t ram_size,
>>  register_ioport_read(0x398, 2, 1, &PREP_io_read, sysctrl);
>>  register_ioport_write(0x398, 2, 1, &PREP_io_write, sysctrl);
>>  /* System control ports */
>> +#if 0
>>  register_ioport_read(0x0092, 0x01, 1, &PREP_io_800_readb, sysctrl);
>>  register_ioport_write(0x0092, 0x01, 1, &PREP_io_800_writeb, sysctrl);
>> +#endif
>>  register_ioport_read(0x0800, 0x52, 1, &PREP_io_800_readb, sysctrl);
>>  register_ioport_write(0x0800, 0x52, 1, &PREP_io_800_writeb, sysctrl);
>>  /* PCI intack location */
>> -- 
>> 1.7.3
>> 
>> 
> 

Re: [Qemu-devel] [FYI 4/4] prep: Quickfix for ioport

[Andreas Färber]

Am 27.12.2010 um 01:11 schrieb Alexander Graf:

> Am 27.12.2010 um 00:28 schrieb Andreas Färber  
> <andreas.faerber@web.de>:
>
>> Am 14.12.2010 um 01:49 schrieb Andreas Färber:
>>
>>> Workaround the following error:
>>>
>>> qemu: hardware error: register_ioport_read: invalid opaque
>>
>> I found out that this is a conflict with i8042 registering I/O port  
>> 0x0092 in pckbd.c, too.
>> Not sure what the proper fix should look like - add some qdev  
>> property to ISAKBDState to disable the port?
>
> Well, why does the PREP board have its own mapping there in the  
> first place? It should be the same as a PC from a port pov, no?

Why does the i8042 controller have a System Control Port in the first  
place rather than the 'pc' machine? :)

The PReP spec v1.1 has a Special Port 0x0092 that includes two bits of  
significence - softreset and endian mode. So wherever the port is  
registered, the latter behavior is board-specific and does not match  
pckbd.c (A20 gate or HDD activity depending on bit numbering).

A similar issue arises between PReP machines: The ioport currently  
does not allow using a different opaque for reads and writes to the  
same address. So either we need to change ioport or create some  
inheritence/override mechanism for port behavior.

Andreas

Re: [Qemu-devel] [FYI 4/4] prep: Quickfix for ioport

[Alexander Graf]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 27.12.2010, at 01:25, Andreas Färber wrote:

> Am 27.12.2010 um 01:11 schrieb Alexander Graf:
> 
>> Am 27.12.2010 um 00:28 schrieb Andreas Färber <andreas.faerber@web.de>:
>> 
>>> Am 14.12.2010 um 01:49 schrieb Andreas Färber:
>>> 
>>>> Workaround the following error:
>>>> 
>>>> qemu: hardware error: register_ioport_read: invalid opaque
>>> 
>>> I found out that this is a conflict with i8042 registering I/O port 0x0092 in pckbd.c, too.
>>> Not sure what the proper fix should look like - add some qdev property to ISAKBDState to disable the port?
>> 
>> Well, why does the PREP board have its own mapping there in the first place? It should be the same as a PC from a port pov, no?
> 
> Why does the i8042 controller have a System Control Port in the first place rather than the 'pc' machine? :)
> 
> The PReP spec v1.1 has a Special Port 0x0092 that includes two bits of significence - softreset and endian mode. So wherever the port is registered, the latter behavior is board-specific and does not match pckbd.c (A20 gate or HDD activity depending on bit numbering).
> 
> A similar issue arises between PReP machines: The ioport currently does not allow using a different opaque for reads and writes to the same address. So either we need to change ioport or create some inheritence/override mechanism for port behavior.

Hmm - sounds to me like that register simply doesn't belong there then, so a split would be the correct solution. The alternative would be to have the keyboard controller create a bus that those bits send signals to. An x86 system could then implement its A20 gate in x86 specific code while PREP could do its specific stuff.


Alex

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)

iEYEARECAAYFAk0jibgACgkQq7Wi27wfN1PtUACfdx6L4Sk/aR5/sC3QEg1Hciyy
Zm0AnAxaD2jguRq+RcaI8TLsaWGE1gN7
=VioX
-----END PGP SIGNATURE-----

Re: [Qemu-devel] [FYI 4/4] prep: Quickfix for ioport

[Andreas Färber]

Am 04.01.2011 um 21:57 schrieb Alexander Graf:

> On 27.12.2010, at 01:25, Andreas Färber wrote:
>
>> Am 27.12.2010 um 01:11 schrieb Alexander Graf:
>>
>>> Am 27.12.2010 um 00:28 schrieb Andreas Färber <andreas.faerber@web.de 
>>> >:
>>>
>>>> Am 14.12.2010 um 01:49 schrieb Andreas Färber:
>>>>
>>>>> Workaround the following error:
>>>>>
>>>>> qemu: hardware error: register_ioport_read: invalid opaque
>>>>
>>>> I found out that this is a conflict with i8042 registering I/O  
>>>> port 0x0092 in pckbd.c, too.
>>>> Not sure what the proper fix should look like - add some qdev  
>>>> property to ISAKBDState to disable the port?
>>>
>>> Well, why does the PREP board have its own mapping there in the  
>>> first place? It should be the same as a PC from a port pov, no?
>>
>> Why does the i8042 controller have a System Control Port in the  
>> first place rather than the 'pc' machine? :)
>>
>> The PReP spec v1.1 has a Special Port 0x0092 that includes two bits  
>> of significence - softreset and endian mode. So wherever the port  
>> is registered, the latter behavior is board-specific and does not  
>> match pckbd.c (A20 gate or HDD activity depending on bit numbering).
>>
>> A similar issue arises between PReP machines: The ioport currently  
>> does not allow using a different opaque for reads and writes to the  
>> same address. So either we need to change ioport or create some  
>> inheritence/override mechanism for port behavior.
>
> Hmm - sounds to me like that register simply doesn't belong there  
> then, so a split would be the correct solution. The alternative  
> would be to have the keyboard controller create a bus that those  
> bits send signals to. An x86 system could then implement its A20  
> gate in x86 specific code while PREP could do its specific stuff.

Coincidentally there's a recent pckbd patch from Blue that resolves  
the conflict. Feel free to review. :)

Any thoughts on the read vs. write port issue? Do we need to register  
both ports in the base device and add hooks to the device state?  
Sounds problematic VMState-wise, just like some of the qemu_irq  
constructs in the ppc devices. (My prep_pci changes are still far from  
perfect, UniNorth has similar issues I noticed.)

Andreas

Re: [Qemu-devel] [FYI 4/4] prep: Quickfix for ioport

[Alexander Graf]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 04.01.2011, at 22:36, Andreas Färber wrote:

> Am 04.01.2011 um 21:57 schrieb Alexander Graf:
> 
>> On 27.12.2010, at 01:25, Andreas Färber wrote:
>> 
>>> Am 27.12.2010 um 01:11 schrieb Alexander Graf:
>>> 
>>>> Am 27.12.2010 um 00:28 schrieb Andreas Färber <andreas.faerber@web.de>:
>>>> 
>>>>> Am 14.12.2010 um 01:49 schrieb Andreas Färber:
>>>>> 
>>>>>> Workaround the following error:
>>>>>> 
>>>>>> qemu: hardware error: register_ioport_read: invalid opaque
>>>>> 
>>>>> I found out that this is a conflict with i8042 registering I/O port 0x0092 in pckbd.c, too.
>>>>> Not sure what the proper fix should look like - add some qdev property to ISAKBDState to disable the port?
>>>> 
>>>> Well, why does the PREP board have its own mapping there in the first place? It should be the same as a PC from a port pov, no?
>>> 
>>> Why does the i8042 controller have a System Control Port in the first place rather than the 'pc' machine? :)
>>> 
>>> The PReP spec v1.1 has a Special Port 0x0092 that includes two bits of significence - softreset and endian mode. So wherever the port is registered, the latter behavior is board-specific and does not match pckbd.c (A20 gate or HDD activity depending on bit numbering).
>>> 
>>> A similar issue arises between PReP machines: The ioport currently does not allow using a different opaque for reads and writes to the same address. So either we need to change ioport or create some inheritence/override mechanism for port behavior.
>> 
>> Hmm - sounds to me like that register simply doesn't belong there then, so a split would be the correct solution. The alternative would be to have the keyboard controller create a bus that those bits send signals to. An x86 system could then implement its A20 gate in x86 specific code while PREP could do its specific stuff.
> 
> Coincidentally there's a recent pckbd patch from Blue that resolves the conflict. Feel free to review. :)

Ah, sorry :). Still catching up. Just now finished to watch news of the last 1 1/2 weeks :).

> Any thoughts on the read vs. write port issue? Do we need to register both ports in the base device and add hooks to the device state? Sounds problematic VMState-wise, just like some of the qemu_irq constructs in the ppc devices. (My prep_pci changes are still far from perfect, UniNorth has similar issues I noticed.)

Well, the general idea is that a single IO always gets routed to the same device. I don't fully understand why you need separate handlers there tbh. Mind to explain this?


Alex

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)

iEYEARECAAYFAk0jlJcACgkQq7Wi27wfN1N/agCeL6hOC6c+DHjLQ7Q3uXsp1Clo
x94An0lSzs/kvXGynRy1y2UMmLwpltp1
=NkaJ
-----END PGP SIGNATURE-----

Re: [Qemu-devel] [FYI 4/4] prep: Quickfix for ioport

[Andreas Färber]

Am 04.01.2011 um 22:43 schrieb Alexander Graf:

> On 04.01.2011, at 22:36, Andreas Färber wrote:
>
>> Am 04.01.2011 um 21:57 schrieb Alexander Graf:
>>
>>> On 27.12.2010, at 01:25, Andreas Färber wrote:
>>>
>>>> Am 27.12.2010 um 01:11 schrieb Alexander Graf:
>>>>
>>>>> Am 27.12.2010 um 00:28 schrieb Andreas Färber <andreas.faerber@web.de 
>>>>> >:
>>>>>
>>>>>> Am 14.12.2010 um 01:49 schrieb Andreas Färber:
>>>>>>
>>>>>>> Workaround the following error:
>>>>>>>
>>>>>>> qemu: hardware error: register_ioport_read: invalid opaque
>>>>>>
>>>>>> I found out that this is a conflict with i8042 registering I/O  
>>>>>> port 0x0092 in pckbd.c, too.
>>>>>> Not sure what the proper fix should look like - add some qdev  
>>>>>> property to ISAKBDState to disable the port?
>>>>>
>>>>> Well, why does the PREP board have its own mapping there in the  
>>>>> first place? It should be the same as a PC from a port pov, no?
>>>>
>>>> Why does the i8042 controller have a System Control Port in the  
>>>> first place rather than the 'pc' machine? :)
>>>>
>>>> The PReP spec v1.1 has a Special Port 0x0092 that includes two  
>>>> bits of significence - softreset and endian mode. So wherever the  
>>>> port is registered, the latter behavior is board-specific and  
>>>> does not match pckbd.c (A20 gate or HDD activity depending on bit  
>>>> numbering).
>>>>
>>>> A similar issue arises between PReP machines: The ioport  
>>>> currently does not allow using a different opaque for reads and  
>>>> writes to the same address. So either we need to change ioport or  
>>>> create some inheritence/override mechanism for port behavior.
>>>
>>> Hmm - sounds to me like that register simply doesn't belong there  
>>> then, so a split would be the correct solution. The alternative  
>>> would be to have the keyboard controller create a bus that those  
>>> bits send signals to. An x86 system could then implement its A20  
>>> gate in x86 specific code while PREP could do its specific stuff.
>>
>> Coincidentally there's a recent pckbd patch from Blue that resolves  
>> the conflict. Feel free to review. :)
>
> Ah, sorry :). Still catching up. Just now finished to watch news of  
> the last 1 1/2 weeks :).

Welcome back. Did they have to pay much? ;)

>> Any thoughts on the read vs. write port issue? Do we need to  
>> register both ports in the base device and add hooks to the device  
>> state? Sounds problematic VMState-wise, just like some of the  
>> qemu_irq constructs in the ppc devices. (My prep_pci changes are  
>> still far from perfect, UniNorth has similar issues I noticed.)
>
> Well, the general idea is that a single IO always gets routed to the  
> same device. I don't fully understand why you need separate handlers  
> there tbh. Mind to explain this?

In short: Inheritance.

The actual issue appears to be snip'ed above, it's about apparent  
subtle machine differences concerning non-standard register uses  
(here, "Motorola ... register" in -M prep vs. nothing in PReP 1.1 spec).

Andreas

Re: [Qemu-devel] [FYI 4/4] prep: Quickfix for ioport

[Alexander Graf]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 04.01.2011, at 22:59, Andreas Färber wrote:

> Am 04.01.2011 um 22:43 schrieb Alexander Graf:
> 
>> On 04.01.2011, at 22:36, Andreas Färber wrote:
>> 
>>> Am 04.01.2011 um 21:57 schrieb Alexander Graf:
>>> 
>>>> On 27.12.2010, at 01:25, Andreas Färber wrote:
>>>> 
>>>>> Am 27.12.2010 um 01:11 schrieb Alexander Graf:
>>>>> 
>>>>>> Am 27.12.2010 um 00:28 schrieb Andreas Färber <andreas.faerber@web.de>:
>>>>>> 
>>>>>>> Am 14.12.2010 um 01:49 schrieb Andreas Färber:
>>>>>>> 
>>>>>>>> Workaround the following error:
>>>>>>>> 
>>>>>>>> qemu: hardware error: register_ioport_read: invalid opaque
>>>>>>> 
>>>>>>> I found out that this is a conflict with i8042 registering I/O port 0x0092 in pckbd.c, too.
>>>>>>> Not sure what the proper fix should look like - add some qdev property to ISAKBDState to disable the port?
>>>>>> 
>>>>>> Well, why does the PREP board have its own mapping there in the first place? It should be the same as a PC from a port pov, no?
>>>>> 
>>>>> Why does the i8042 controller have a System Control Port in the first place rather than the 'pc' machine? :)
>>>>> 
>>>>> The PReP spec v1.1 has a Special Port 0x0092 that includes two bits of significence - softreset and endian mode. So wherever the port is registered, the latter behavior is board-specific and does not match pckbd.c (A20 gate or HDD activity depending on bit numbering).
>>>>> 
>>>>> A similar issue arises between PReP machines: The ioport currently does not allow using a different opaque for reads and writes to the same address. So either we need to change ioport or create some inheritence/override mechanism for port behavior.
>>>> 
>>>> Hmm - sounds to me like that register simply doesn't belong there then, so a split would be the correct solution. The alternative would be to have the keyboard controller create a bus that those bits send signals to. An x86 system could then implement its A20 gate in x86 specific code while PREP could do its specific stuff.
>>> 
>>> Coincidentally there's a recent pckbd patch from Blue that resolves the conflict. Feel free to review. :)
>> 
>> Ah, sorry :). Still catching up. Just now finished to watch news of the last 1 1/2 weeks :).
> 
> Welcome back. Did they have to pay much? ;)

The only one ending up paying was me to get in for the 27c3 ;).

>>> Any thoughts on the read vs. write port issue? Do we need to register both ports in the base device and add hooks to the device state? Sounds problematic VMState-wise, just like some of the qemu_irq constructs in the ppc devices. (My prep_pci changes are still far from perfect, UniNorth has similar issues I noticed.)
>> 
>> Well, the general idea is that a single IO always gets routed to the same device. I don't fully understand why you need separate handlers there tbh. Mind to explain this?
> 
> In short: Inheritance.
> 
> The actual issue appears to be snip'ed above, it's about apparent subtle machine differences concerning non-standard register uses (here, "Motorola ... register" in -M prep vs. nothing in PReP 1.1 spec).

Hrm. So the port belongs to machine specific code then and should only call helper functions for other generic bits, no?


Alex

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)

iEYEARECAAYFAk0jmOYACgkQq7Wi27wfN1Pp2ACdFf7aa8y/tNC7fx9Z4zFheNnU
1RQAnjGNJqAGhYNvEOKuNihLVJKsVeG9
=QdiF
-----END PGP SIGNATURE-----

Re: [Qemu-devel] [PATCH, RFC 3/4] prep: Fix duplicate ISA IDE IRQ

[Andreas Färber]

Am 14.12.2010 um 01:49 schrieb Andreas Färber:

> Calling isa_ide_init() twice with the same IRQ 13 fails:
>
> qemu: hardware error: isa irq 13 already assigned
>
> Use a different IRQ (14) for the second one to avoid this.
>
> Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
> Cc: Alexander Graf <agraf@suse.de>
> Signed-off-by: Andreas Färber <andreas.faerber@web.de>

The implied question behind "RFC" is, has this been a dormant bug in  
ppc_prep.c or would this need to be fixed at ISA level (allowing two  
devices to share the same IRQ) in isa-bus.c where the above error  
message is raised?

Andreas

> ---
> hw/ppc_prep.c |    2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
> index 3575dee..3073870 100644
> --- a/hw/ppc_prep.c
> +++ b/hw/ppc_prep.c
> @@ -76,7 +76,7 @@ qemu_log_mask(CPU_LOG_IOPORT, fmt, ## __VA_ARGS__)
> /* Constants for devices init */
> static const int ide_iobase[2] = { 0x1f0, 0x170 };
> static const int ide_iobase2[2] = { 0x3f6, 0x376 };
> -static const int ide_irq[2] = { 13, 13 };
> +static const int ide_irq[2] = { 13, 14 };

Re: [Qemu-devel] [PATCH, RFC 3/4] prep: Fix duplicate ISA IDE IRQ

[Alexander Graf]

On 20.12.2010, at 07:37, Andreas Färber wrote:

> Am 14.12.2010 um 01:49 schrieb Andreas Färber:
> 
>> Calling isa_ide_init() twice with the same IRQ 13 fails:
>> 
>> qemu: hardware error: isa irq 13 already assigned
>> 
>> Use a different IRQ (14) for the second one to avoid this.
>> 
>> Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
>> Cc: Alexander Graf <agraf@suse.de>
>> Signed-off-by: Andreas Färber <andreas.faerber@web.de>
> 
> The implied question behind "RFC" is, has this been a dormant bug in ppc_prep.c or would this need to be fixed at ISA level (allowing two devices to share the same IRQ) in isa-bus.c where the above error message is raised?

That depends on the hardware. Usually ISA can't share IRQs. There are some exceptions though, where ISA controllers have some built in magic to enable sharing along identical devices. Not sure which case we're looking at here, but having them separate is certainly the safe choice.


Alex

Re: [Qemu-devel] [PATCH, RFC 3/4] prep: Fix duplicate ISA IDE IRQ

[Aurelien Jarno]

On Tue, Dec 14, 2010 at 01:49:17AM +0100, Andreas Färber wrote:
> Calling isa_ide_init() twice with the same IRQ 13 fails:
> 
> qemu: hardware error: isa irq 13 already assigned
> 
> Use a different IRQ (14) for the second one to avoid this.

I am not sure it is actually a good idea. While it fixes the QEMU error,
it breaks the kernel boot which waits for both IDE channels on IRQ 13.
This causes an endless boot, so the machine never finishes to boot:

| ide0 at 0x1f0-0x1f7,0x3f6 on irq 13
| ide1 at 0x170-0x177,0x376 on irq 13 (shared with ide0)
| hda: max request size: 512KiB
| hda: 20971520 sectors (10737 MB) w/256KiB Cache, CHS=16383/255/63
| hda: cache flushes supported
| hda: hda1 hda2
| ide-cd: cmd 0x5a timed out
| hdc: lost interrupt
| ide-cd: cmd 0x5a timed out
| hdc: lost interrupt
| hdc: ATAPI 4X CD-ROM drive, 512kB Cache
| Uniform CD-ROM driver Revision: 3.20
| hdc: lost interrupt
| ide-cd: cmd 0x3 timed out
| hdc: lost interrupt
| ide-cd: cmd 0x3 timed out
| hdc: lost interrupt
| hdc: lost interrupt
| ...

As a temporary workaround it seems better to disable the second IDE
channel, this solution works. 

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

[Qemu-devel] Re: [PATCH 1/4] prep: Remove bogus BIOS size check

[Alexander Graf]

On 14.12.2010, at 01:49, Andreas Färber wrote:

> r3480 added this check to account for the entry vector 0xfff00100 to be
> available for CPUs that need it. Today however, the NIP is not yet
> initialized at this point (zero), so the check always triggers.
> 
> Cc: Hervé Poussineau <hpoussin@reactos.org>
> Cc: Alexander Graf <agraf@suse.de>
> Signed-off-by: Andreas Färber <andreas.faerber@web.de>
> ---
> hw/ppc_prep.c |    3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
> index 1492266..6b22122 100644
> --- a/hw/ppc_prep.c
> +++ b/hw/ppc_prep.c
> @@ -600,9 +600,6 @@ static void ppc_prep_init (ram_addr_t ram_size,
>     if (filename) {
>         qemu_free(filename);
>     }
> -    if (env->nip < 0xFFF80000 && bios_size < 0x00100000) {
> -        hw_error("PowerPC 601 / 620 / 970 need a 1MB BIOS\n");
> -    }
> 

The bios gets mapped to 0xfff00000, so it can at most be 0x100000 bytes long which is 1MB. The bogus part of the check is the first, the nip part.

Alex

[Qemu-devel] Re: [PATCH 1/4] prep: Remove bogus BIOS size check

[Andreas Färber]

Am 19.12.2010 um 10:52 schrieb Alexander Graf:

> On 14.12.2010, at 01:49, Andreas Färber wrote:
>
>> r3480 added this check to account for the entry vector 0xfff00100  
>> to be
>> available for CPUs that need it. Today however, the NIP is not yet
>> initialized at this point (zero), so the check always triggers.
>>
>> Cc: Hervé Poussineau <hpoussin@reactos.org>
>> Cc: Alexander Graf <agraf@suse.de>
>> Signed-off-by: Andreas Färber <andreas.faerber@web.de>
>> ---
>> hw/ppc_prep.c |    3 ---
>> 1 files changed, 0 insertions(+), 3 deletions(-)
>>
>> diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
>> index 1492266..6b22122 100644
>> --- a/hw/ppc_prep.c
>> +++ b/hw/ppc_prep.c
>> @@ -600,9 +600,6 @@ static void ppc_prep_init (ram_addr_t ram_size,
>>    if (filename) {
>>        qemu_free(filename);
>>    }
>> -    if (env->nip < 0xFFF80000 && bios_size < 0x00100000) {
>> -        hw_error("PowerPC 601 / 620 / 970 need a 1MB BIOS\n");
>> -    }
>>
>
> The bios gets mapped to 0xfff00000, so it can at most be 0x100000  
> bytes long which is 1MB. The bogus part of the check is the first,  
> the nip part.

If you look at 2/4, it is checked using BIOS_SIZE define (1024 * 1024)  
further down in the more correct place. :)

At this time - 1/4 - the BIOS gets mapped to 0xffffffff minus BIOS  
size. If the entry is at 0xfffffffc, the BIOS is allowed to be smaller  
than 1 MB. So marking BIOS sizes smaller as 1 MB as error would break  
both the OHW ppc_rom.bin and the IBM 40p BIOS. Therefore it must  
simply go away.

Unless you happen to know a better place for this NIP-dependent check,  
that is. I believe the reset handling was changed at some point?

Andreas

[Qemu-devel] Re: [PATCH 1/4] prep: Remove bogus BIOS size check

[Alexander Graf]

On 19.12.2010, at 13:26, Andreas Färber wrote:

> Am 19.12.2010 um 10:52 schrieb Alexander Graf:
> 
>> On 14.12.2010, at 01:49, Andreas Färber wrote:
>> 
>>> r3480 added this check to account for the entry vector 0xfff00100 to be
>>> available for CPUs that need it. Today however, the NIP is not yet
>>> initialized at this point (zero), so the check always triggers.
>>> 
>>> Cc: Hervé Poussineau <hpoussin@reactos.org>
>>> Cc: Alexander Graf <agraf@suse.de>
>>> Signed-off-by: Andreas Färber <andreas.faerber@web.de>
>>> ---
>>> hw/ppc_prep.c |    3 ---
>>> 1 files changed, 0 insertions(+), 3 deletions(-)
>>> 
>>> diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
>>> index 1492266..6b22122 100644
>>> --- a/hw/ppc_prep.c
>>> +++ b/hw/ppc_prep.c
>>> @@ -600,9 +600,6 @@ static void ppc_prep_init (ram_addr_t ram_size,
>>>   if (filename) {
>>>       qemu_free(filename);
>>>   }
>>> -    if (env->nip < 0xFFF80000 && bios_size < 0x00100000) {
>>> -        hw_error("PowerPC 601 / 620 / 970 need a 1MB BIOS\n");
>>> -    }
>>> 
>> 
>> The bios gets mapped to 0xfff00000, so it can at most be 0x100000 bytes long which is 1MB. The bogus part of the check is the first, the nip part.
> 
> If you look at 2/4, it is checked using BIOS_SIZE define (1024 * 1024) further down in the more correct place. :)
> 
> At this time - 1/4 - the BIOS gets mapped to 0xffffffff minus BIOS size. If the entry is at 0xfffffffc, the BIOS is allowed to be smaller than 1 MB. So marking BIOS sizes smaller as 1 MB as error would break both the OHW ppc_rom.bin and the IBM 40p BIOS. Therefore it must simply go away.
> 
> Unless you happen to know a better place for this NIP-dependent check, that is. I believe the reset handling was changed at some point?

Hrm, maybe. The reset vector is board dependent and different CPU typed recommend different default values. So I agree - just get rid of this check.


Alex

[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Alexander Graf]

On 14.12.2010, at 01:49, Andreas Färber wrote:

> Hello,
> 
> Based on an earlier attempt of mine to make OpenBIOS work with -M prep,
> with kind support from Hervé Poussineau here's an initial stab at
> fixing the long-broken PReP emulation and preparing migration from
> abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware.
> 
> In particular a number of hw_error()s are resolved, so that the BIOS
> can be entered at all. It is not yet working in terms of serial and
> VGA support etc.
> 
> This series is also available from:
> 
> git://repo.or.cz/qemu/afaerber.git prep-queue
> 
> Some more work-in-progress for the curious is on my prep branch [2].
> The corresponding work-in-progress OpenBIOS changes are at [3].
> 
> Unfortunately the prep machine is lacking documentation what exactly it
> tries to emulate. The plan thus is to merge emulation of a second, real
> IBM 40p machine based on Hervé's work at [1], for use with original
> binary firmware.
> 
> Also upcoming are new ppc_chrp machines, forked from ppc_newworld,
> emulating the 970-based IBM JS20 (using Apple U3) [4] and possibly the
> POWER5-based IntelliStation 285. These depend on the ongoing ppc64 port
> of OpenBIOS to be completed though. This relates to PReP in that the
> machine IDs will need to be coordinated.

Does this series actually make anything work, or is it just a first step set to get your development rolling? IOW, would users benefit from having the patches upstream yet?


Alex

[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Andreas Färber]

Am 19.12.2010 um 10:54 schrieb Alexander Graf:

> On 14.12.2010, at 01:49, Andreas Färber wrote:
>
>> Hello,
>>
>> Based on an earlier attempt of mine to make OpenBIOS work with -M  
>> prep,
>> with kind support from Hervé Poussineau here's an initial stab at
>> fixing the long-broken PReP emulation and preparing migration from
>> abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware.
>>
>> In particular a number of hw_error()s are resolved, so that the BIOS
>> can be entered at all. It is not yet working in terms of serial and
>> VGA support etc.
>>
>> This series is also available from:
>>
>> git://repo.or.cz/qemu/afaerber.git prep-queue
>>
>> Some more work-in-progress for the curious is on my prep branch [2].
>> The corresponding work-in-progress OpenBIOS changes are at [3].
>>
>> Unfortunately the prep machine is lacking documentation what  
>> exactly it
>> tries to emulate. The plan thus is to merge emulation of a second,  
>> real
>> IBM 40p machine based on Hervé's work at [1], for use with original
>> binary firmware.
>>
>> Also upcoming are new ppc_chrp machines, forked from ppc_newworld,
>> emulating the 970-based IBM JS20 (using Apple U3) [4] and possibly  
>> the
>> POWER5-based IntelliStation 285. These depend on the ongoing ppc64  
>> port
>> of OpenBIOS to be completed though. This relates to PReP in that the
>> machine IDs will need to be coordinated.
>
> Does this series actually make anything work, or is it just a first  
> step set to get your development rolling? IOW, would users benefit  
> from having the patches upstream yet?

As indicated above, it lets you enter a BIOS, which is a user-visible  
improvement. User-supplied binary firmware works with 1 + 3-4, ELF  
firmware with 1-4. Patch 3 depends on review comments. Patch 4 was  
just an FYI for testing the preceding patches and still needs  
investigation.

For OpenBIOS to work, we need fw_cfg in ppc_prep.c and, independently,  
patches to OpenBIOS. Unless of course we want to use another firmware  
like OFW from the start. The main interest in PReP nowadays will be  
proprietary firmware anyway. I thought Rob (cc'ed) had PReP Linux  
kernel patches for QEMU at some point but I couldn't locate them in  
the Aboriginal Linux tree.

I am planning to queue reviewed patches for upstream on a new branch.  
Then we can either pull them into your ppc queue or directly into  
master.

Andreas

[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Alexander Graf]

On 19.12.2010, at 16:04, Andreas Färber wrote:

> Am 19.12.2010 um 10:54 schrieb Alexander Graf:
> 
>> On 14.12.2010, at 01:49, Andreas Färber wrote:
>> 
>>> Hello,
>>> 
>>> Based on an earlier attempt of mine to make OpenBIOS work with -M prep,
>>> with kind support from Hervé Poussineau here's an initial stab at
>>> fixing the long-broken PReP emulation and preparing migration from
>>> abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware.
>>> 
>>> In particular a number of hw_error()s are resolved, so that the BIOS
>>> can be entered at all. It is not yet working in terms of serial and
>>> VGA support etc.
>>> 
>>> This series is also available from:
>>> 
>>> git://repo.or.cz/qemu/afaerber.git prep-queue
>>> 
>>> Some more work-in-progress for the curious is on my prep branch [2].
>>> The corresponding work-in-progress OpenBIOS changes are at [3].
>>> 
>>> Unfortunately the prep machine is lacking documentation what exactly it
>>> tries to emulate. The plan thus is to merge emulation of a second, real
>>> IBM 40p machine based on Hervé's work at [1], for use with original
>>> binary firmware.
>>> 
>>> Also upcoming are new ppc_chrp machines, forked from ppc_newworld,
>>> emulating the 970-based IBM JS20 (using Apple U3) [4] and possibly the
>>> POWER5-based IntelliStation 285. These depend on the ongoing ppc64 port
>>> of OpenBIOS to be completed though. This relates to PReP in that the
>>> machine IDs will need to be coordinated.
>> 
>> Does this series actually make anything work, or is it just a first step set to get your development rolling? IOW, would users benefit from having the patches upstream yet?
> 
> As indicated above, it lets you enter a BIOS, which is a user-visible improvement. User-supplied binary firmware works with 1 + 3-4, ELF firmware with 1-4. Patch 3 depends on review comments. Patch 4 was just an FYI for testing the preceding patches and still needs investigation.
> 
> For OpenBIOS to work, we need fw_cfg in ppc_prep.c and, independently, patches to OpenBIOS. Unless of course we want to use another firmware like OFW from the start. The main interest in PReP nowadays will be proprietary firmware anyway. I thought Rob (cc'ed) had PReP Linux kernel patches for QEMU at some point but I couldn't locate them in the Aboriginal Linux tree.

I'm not sure on the copyright problems we might run into when delivering binary firmware. So we certainly do need some open source firmware solution for prep to at least have Linux running. For other guests, I don't see a reason why users shouldn't try to fetch a real firmware blob separately :).

> 
> I am planning to queue reviewed patches for upstream on a new branch. Then we can either pull them into your ppc queue or directly into master.

I'd say let's wait until we get to a point where we can boot any (really, any) guest. As soon as we're there, let's pull the whole thing in to qemu. Until then, I'm sure little enough code changes upstream that it's fine to keep it in a separate tree.

If it gets too cumbersome to keep it separate, just nag me and I'll reconsider :).


Alex

[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Andreas Färber]

Am 19.12.2010 um 16:34 schrieb Alexander Graf:

> On 19.12.2010, at 16:04, Andreas Färber wrote:
>
>> Am 19.12.2010 um 10:54 schrieb Alexander Graf:
>>
>>> On 14.12.2010, at 01:49, Andreas Färber wrote:
>>>
>>>> Hello,
>>>>
>>>> Based on an earlier attempt of mine to make OpenBIOS work with -M  
>>>> prep,
>>>> with kind support from Hervé Poussineau here's an initial stab at
>>>> fixing the long-broken PReP emulation and preparing migration from
>>>> abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware.
>>>>
>>>> In particular a number of hw_error()s are resolved, so that the  
>>>> BIOS
>>>> can be entered at all. It is not yet working in terms of serial and
>>>> VGA support etc.
>>>>
>>>> This series is also available from:
>>>>
>>>> git://repo.or.cz/qemu/afaerber.git prep-queue
>>>>
>>>> Some more work-in-progress for the curious is on my prep branch  
>>>> [2].
>>>> The corresponding work-in-progress OpenBIOS changes are at [3].
>>>>
>>>> Unfortunately the prep machine is lacking documentation what  
>>>> exactly it
>>>> tries to emulate. The plan thus is to merge emulation of a  
>>>> second, real
>>>> IBM 40p machine based on Hervé's work at [1], for use with original
>>>> binary firmware.
>>>>
>>>> Also upcoming are new ppc_chrp machines, forked from ppc_newworld,
>>>> emulating the 970-based IBM JS20 (using Apple U3) [4] and  
>>>> possibly the
>>>> POWER5-based IntelliStation 285. These depend on the ongoing  
>>>> ppc64 port
>>>> of OpenBIOS to be completed though. This relates to PReP in that  
>>>> the
>>>> machine IDs will need to be coordinated.
>>>
>>> Does this series actually make anything work, or is it just a  
>>> first step set to get your development rolling? IOW, would users  
>>> benefit from having the patches upstream yet?
>>
>> As indicated above, it lets you enter a BIOS, which is a user- 
>> visible improvement. User-supplied binary firmware works with 1 +  
>> 3-4, ELF firmware with 1-4. Patch 3 depends on review comments.  
>> Patch 4 was just an FYI for testing the preceding patches and still  
>> needs investigation.
>>
>> For OpenBIOS to work, we need fw_cfg in ppc_prep.c and,  
>> independently, patches to OpenBIOS. Unless of course we want to use  
>> another firmware like OFW from the start. The main interest in PReP  
>> nowadays will be proprietary firmware anyway. I thought Rob (cc'ed)  
>> had PReP Linux kernel patches for QEMU at some point but I couldn't  
>> locate them in the Aboriginal Linux tree.
>
> I'm not sure on the copyright problems we might run into when  
> delivering binary firmware.

No one suggested shipping proprietary firmware.

I was advocating enabling users to use the available firmware rather  
than holding fixes back just because there is no fully-working FOSS  
alternative firmware yet.

> So we certainly do need some open source firmware solution for prep  
> to at least have Linux running. For other guests, I don't see a  
> reason why users shouldn't try to fetch a real firmware blob  
> separately :).

We're not shipping any firmware for ppcemb either, so that argument  
seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently.  
Feel free to supply additional blobs for U-Boot etc.

Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do  
you want to run using open source firmware?
I certainly do not intend to write firmware for the upcoming 40p  
machine. If Linux runs on real 40p hardware then it should run with  
real firmware under emulation, too. QEMU is an emulation project, not  
a Linux testing framework.

Andreas

[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Alexander Graf]

On 19.12.2010, at 20:12, Andreas Färber wrote:

> Am 19.12.2010 um 16:34 schrieb Alexander Graf:
> 
>> On 19.12.2010, at 16:04, Andreas Färber wrote:
>> 
>>> Am 19.12.2010 um 10:54 schrieb Alexander Graf:
>>> 
>>>> On 14.12.2010, at 01:49, Andreas Färber wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> Based on an earlier attempt of mine to make OpenBIOS work with -M prep,
>>>>> with kind support from Hervé Poussineau here's an initial stab at
>>>>> fixing the long-broken PReP emulation and preparing migration from
>>>>> abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware.
>>>>> 
>>>>> In particular a number of hw_error()s are resolved, so that the BIOS
>>>>> can be entered at all. It is not yet working in terms of serial and
>>>>> VGA support etc.
>>>>> 
>>>>> This series is also available from:
>>>>> 
>>>>> git://repo.or.cz/qemu/afaerber.git prep-queue
>>>>> 
>>>>> Some more work-in-progress for the curious is on my prep branch [2].
>>>>> The corresponding work-in-progress OpenBIOS changes are at [3].
>>>>> 
>>>>> Unfortunately the prep machine is lacking documentation what exactly it
>>>>> tries to emulate. The plan thus is to merge emulation of a second, real
>>>>> IBM 40p machine based on Hervé's work at [1], for use with original
>>>>> binary firmware.
>>>>> 
>>>>> Also upcoming are new ppc_chrp machines, forked from ppc_newworld,
>>>>> emulating the 970-based IBM JS20 (using Apple U3) [4] and possibly the
>>>>> POWER5-based IntelliStation 285. These depend on the ongoing ppc64 port
>>>>> of OpenBIOS to be completed though. This relates to PReP in that the
>>>>> machine IDs will need to be coordinated.
>>>> 
>>>> Does this series actually make anything work, or is it just a first step set to get your development rolling? IOW, would users benefit from having the patches upstream yet?
>>> 
>>> As indicated above, it lets you enter a BIOS, which is a user-visible improvement. User-supplied binary firmware works with 1 + 3-4, ELF firmware with 1-4. Patch 3 depends on review comments. Patch 4 was just an FYI for testing the preceding patches and still needs investigation.
>>> 
>>> For OpenBIOS to work, we need fw_cfg in ppc_prep.c and, independently, patches to OpenBIOS. Unless of course we want to use another firmware like OFW from the start. The main interest in PReP nowadays will be proprietary firmware anyway. I thought Rob (cc'ed) had PReP Linux kernel patches for QEMU at some point but I couldn't locate them in the Aboriginal Linux tree.
>> 
>> I'm not sure on the copyright problems we might run into when delivering binary firmware.
> 
> No one suggested shipping proprietary firmware.
> 
> I was advocating enabling users to use the available firmware rather than holding fixes back just because there is no fully-working FOSS alternative firmware yet.

Hrm, I only partially agree. If you ship a target in qemu that people can't test out of the box, it won't receive testing from contributers. I doubt that RH people will go in and download proprietary firmware just to check that prep didn't break. I do hope however, that they test targets that "just work".

I have this very issue with s390. The only host to run (and compile) this on is an s390. And few people have those. So it breaks from time to time.

Since prep would at least get built for everyone, there's less of an issue, yes.

> 
>> So we certainly do need some open source firmware solution for prep to at least have Linux running. For other guests, I don't see a reason why users shouldn't try to fetch a real firmware blob separately :).
> 
> We're not shipping any firmware for ppcemb either, so that argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to supply additional blobs for U-Boot etc.

IIUC you don't need u-boot for the embedded targets. You just pass in a kernel and the rest is magic.

> Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want to run using open source firmware?
> I certainly do not intend to write firmware for the upcoming 40p machine. If Linux runs on real 40p hardware then it should run with real firmware under emulation, too. QEMU is an emulation project, not a Linux testing framework.

I completely agree. Linux is usually easy because it's fully open source and supports a lot of targets. If you feel like running NetBSD or Haiku instead, feel free to do so.

I'd even be willing to say that running any OS with a proprietary firmware blob is enough to pull stuff in. And really, I mean _any_ OS. I just really want to see some value for users, so in case the whole system just doesn't work at all, we can rather apply a big bunch of removal commits instead of fixes that won't end up in anything working either.

Having said that, I have faith in your skills to get this working. So I assume you'll have something that meets the "something runs" criteria in at most a couple of weeks. Shouldn't be too bad, no? :)


Alex

Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Andreas Färber]

Am 20.12.2010 um 10:04 schrieb Alexander Graf:

> On 19.12.2010, at 20:12, Andreas Färber wrote:
>
>> Am 19.12.2010 um 16:34 schrieb Alexander Graf:
>>
>>> On 19.12.2010, at 16:04, Andreas Färber wrote:
>>>
>>>> Am 19.12.2010 um 10:54 schrieb Alexander Graf:
>>>>
>>>>> On 14.12.2010, at 01:49, Andreas Färber wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Based on an earlier attempt of mine to make OpenBIOS work with - 
>>>>>> M prep,
>>>>>> with kind support from Hervé Poussineau here's an initial stab at
>>>>>> fixing the long-broken PReP emulation and preparing migration  
>>>>>> from
>>>>>> abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware.
>>>>>>
>>>>>> In particular a number of hw_error()s are resolved, so that the  
>>>>>> BIOS
>>>>>> can be entered at all. It is not yet working in terms of serial  
>>>>>> and
>>>>>> VGA support etc.
>>>>>>
>>>>>> This series is also available from:
>>>>>>
>>>>>> git://repo.or.cz/qemu/afaerber.git prep-queue
>>>>>>
>>>>>> Some more work-in-progress for the curious is on my prep branch  
>>>>>> [2].
>>>>>> The corresponding work-in-progress OpenBIOS changes are at [3].
>>>>>>
>>>>>> Unfortunately the prep machine is lacking documentation what  
>>>>>> exactly it
>>>>>> tries to emulate. The plan thus is to merge emulation of a  
>>>>>> second, real
>>>>>> IBM 40p machine based on Hervé's work at [1], for use with  
>>>>>> original
>>>>>> binary firmware.
>>>>>>
>>>>>> Also upcoming are new ppc_chrp machines, forked from  
>>>>>> ppc_newworld,
>>>>>> emulating the 970-based IBM JS20 (using Apple U3) [4] and  
>>>>>> possibly the
>>>>>> POWER5-based IntelliStation 285. These depend on the ongoing  
>>>>>> ppc64 port
>>>>>> of OpenBIOS to be completed though. This relates to PReP in  
>>>>>> that the
>>>>>> machine IDs will need to be coordinated.
>>>>>
>>>>> Does this series actually make anything work, or is it just a  
>>>>> first step set to get your development rolling? IOW, would users  
>>>>> benefit from having the patches upstream yet?
>>>>
>>>> As indicated above, it lets you enter a BIOS, which is a user- 
>>>> visible improvement. User-supplied binary firmware works with 1 +  
>>>> 3-4, ELF firmware with 1-4. Patch 3 depends on review comments.  
>>>> Patch 4 was just an FYI for testing the preceding patches and  
>>>> still needs investigation.
>>>>
>>>> For OpenBIOS to work, we need fw_cfg in ppc_prep.c and,  
>>>> independently, patches to OpenBIOS. Unless of course we want to  
>>>> use another firmware like OFW from the start. The main interest  
>>>> in PReP nowadays will be proprietary firmware anyway. I thought  
>>>> Rob (cc'ed) had PReP Linux kernel patches for QEMU at some point  
>>>> but I couldn't locate them in the Aboriginal Linux tree.
>>>
>>> I'm not sure on the copyright problems we might run into when  
>>> delivering binary firmware.
>>
>> No one suggested shipping proprietary firmware.
>>
>> I was advocating enabling users to use the available firmware  
>> rather than holding fixes back just because there is no fully- 
>> working FOSS alternative firmware yet.
>
> Hrm, I only partially agree. If you ship a target in qemu that  
> people can't test out of the box, it won't receive testing from  
> contributers. I doubt that RH people will go in and download  
> proprietary firmware just to check that prep didn't break. I do hope  
> however, that they test targets that "just work".
>
> I have this very issue with s390. The only host to run (and compile)  
> this on is an s390. And few people have those. So it breaks from  
> time to time.
>
> Since prep would at least get built for everyone, there's less of an  
> issue, yes.
>
>>
>>> So we certainly do need some open source firmware solution for  
>>> prep to at least have Linux running. For other guests, I don't see  
>>> a reason why users shouldn't try to fetch a real firmware blob  
>>> separately :).
>>
>> We're not shipping any firmware for ppcemb either, so that argument  
>> seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently.  
>> Feel free to supply additional blobs for U-Boot etc.
>
> IIUC you don't need u-boot for the embedded targets. You just pass  
> in a kernel and the rest is magic.
>
>> Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do  
>> you want to run using open source firmware?
>> I certainly do not intend to write firmware for the upcoming 40p  
>> machine. If Linux runs on real 40p hardware then it should run with  
>> real firmware under emulation, too. QEMU is an emulation project,  
>> not a Linux testing framework.
>
> I completely agree. Linux is usually easy because it's fully open  
> source and supports a lot of targets. If you feel like running  
> NetBSD or Haiku instead, feel free to do so.
>
> I'd even be willing to say that running any OS with a proprietary  
> firmware blob is enough to pull stuff in. And really, I mean _any_  
> OS. I just really want to see some value for users, so in case the  
> whole system just doesn't work at all, we can rather apply a big  
> bunch of removal commits instead of fixes that won't end up in  
> anything working either.
>
> Having said that, I have faith in your skills to get this working.  
> So I assume you'll have something that meets the "something runs"  
> criteria in at most a couple of weeks. Shouldn't be too bad, no? :)

Listen, I won't spend a couple of weeks on a firmware that I don't  
need just because you want me to.
I can't work on QEMU all day nor am I getting paid for it, so I'd  
rather spend my time on getting ppc/ppc64 Mac emulation working for my  
needs! :)

My interest in PReP is of historical nature only - it would be 'cool'  
to see BeOS/ppc emulated (and - if feasible - extend Haiku/ppc to run  
on it, too).

The three QEMU PReP projects we're talking about here - 'prep', '40p'  
and BeBox share a common core like some memory-mapped registers but  
use different devices and different firmware. The IBM 40p works with a  
binary firmware - got it to show some graphics on OpenSolaris/amd64  
host yesterday (hinting towards endianness issues on Darwin/ppc64  
host). The BeBox BootROM however uses a custom format with Be-specific  
headers and some PE stuff as it seems [1]. Writing firmware for the  
'prep' machine buys us nothing there... Fixing it is not even strictly  
needed, but it seems a good deed while we're at it.

Andreas

[1] http://www.bebox.nu/tech.php?s=tech/bootROM

Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Alexander Graf]

On 21.12.2010, at 00:00, Andreas Färber wrote:

> Am 20.12.2010 um 10:04 schrieb Alexander Graf:
> 
>> On 19.12.2010, at 20:12, Andreas Färber wrote:
>> 
>>> Am 19.12.2010 um 16:34 schrieb Alexander Graf:
>>> 
>>>> On 19.12.2010, at 16:04, Andreas Färber wrote:
>>>> 
>>>>> Am 19.12.2010 um 10:54 schrieb Alexander Graf:
>>>>> 
>>>>>> On 14.12.2010, at 01:49, Andreas Färber wrote:
>>>>>> 
>>>>>>> Hello,
>>>>>>> 
>>>>>>> Based on an earlier attempt of mine to make OpenBIOS work with -M prep,
>>>>>>> with kind support from Hervé Poussineau here's an initial stab at
>>>>>>> fixing the long-broken PReP emulation and preparing migration from
>>>>>>> abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware.
>>>>>>> 
>>>>>>> In particular a number of hw_error()s are resolved, so that the BIOS
>>>>>>> can be entered at all. It is not yet working in terms of serial and
>>>>>>> VGA support etc.
>>>>>>> 
>>>>>>> This series is also available from:
>>>>>>> 
>>>>>>> git://repo.or.cz/qemu/afaerber.git prep-queue
>>>>>>> 
>>>>>>> Some more work-in-progress for the curious is on my prep branch [2].
>>>>>>> The corresponding work-in-progress OpenBIOS changes are at [3].
>>>>>>> 
>>>>>>> Unfortunately the prep machine is lacking documentation what exactly it
>>>>>>> tries to emulate. The plan thus is to merge emulation of a second, real
>>>>>>> IBM 40p machine based on Hervé's work at [1], for use with original
>>>>>>> binary firmware.
>>>>>>> 
>>>>>>> Also upcoming are new ppc_chrp machines, forked from ppc_newworld,
>>>>>>> emulating the 970-based IBM JS20 (using Apple U3) [4] and possibly the
>>>>>>> POWER5-based IntelliStation 285. These depend on the ongoing ppc64 port
>>>>>>> of OpenBIOS to be completed though. This relates to PReP in that the
>>>>>>> machine IDs will need to be coordinated.
>>>>>> 
>>>>>> Does this series actually make anything work, or is it just a first step set to get your development rolling? IOW, would users benefit from having the patches upstream yet?
>>>>> 
>>>>> As indicated above, it lets you enter a BIOS, which is a user-visible improvement. User-supplied binary firmware works with 1 + 3-4, ELF firmware with 1-4. Patch 3 depends on review comments. Patch 4 was just an FYI for testing the preceding patches and still needs investigation.
>>>>> 
>>>>> For OpenBIOS to work, we need fw_cfg in ppc_prep.c and, independently, patches to OpenBIOS. Unless of course we want to use another firmware like OFW from the start. The main interest in PReP nowadays will be proprietary firmware anyway. I thought Rob (cc'ed) had PReP Linux kernel patches for QEMU at some point but I couldn't locate them in the Aboriginal Linux tree.
>>>> 
>>>> I'm not sure on the copyright problems we might run into when delivering binary firmware.
>>> 
>>> No one suggested shipping proprietary firmware.
>>> 
>>> I was advocating enabling users to use the available firmware rather than holding fixes back just because there is no fully-working FOSS alternative firmware yet.
>> 
>> Hrm, I only partially agree. If you ship a target in qemu that people can't test out of the box, it won't receive testing from contributers. I doubt that RH people will go in and download proprietary firmware just to check that prep didn't break. I do hope however, that they test targets that "just work".
>> 
>> I have this very issue with s390. The only host to run (and compile) this on is an s390. And few people have those. So it breaks from time to time.
>> 
>> Since prep would at least get built for everyone, there's less of an issue, yes.
>> 
>>> 
>>>> So we certainly do need some open source firmware solution for prep to at least have Linux running. For other guests, I don't see a reason why users shouldn't try to fetch a real firmware blob separately :).
>>> 
>>> We're not shipping any firmware for ppcemb either, so that argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to supply additional blobs for U-Boot etc.
>> 
>> IIUC you don't need u-boot for the embedded targets. You just pass in a kernel and the rest is magic.
>> 
>>> Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want to run using open source firmware?
>>> I certainly do not intend to write firmware for the upcoming 40p machine. If Linux runs on real 40p hardware then it should run with real firmware under emulation, too. QEMU is an emulation project, not a Linux testing framework.
>> 
>> I completely agree. Linux is usually easy because it's fully open source and supports a lot of targets. If you feel like running NetBSD or Haiku instead, feel free to do so.
>> 
>> I'd even be willing to say that running any OS with a proprietary firmware blob is enough to pull stuff in. And really, I mean _any_ OS. I just really want to see some value for users, so in case the whole system just doesn't work at all, we can rather apply a big bunch of removal commits instead of fixes that won't end up in anything working either.
>> 
>> Having said that, I have faith in your skills to get this working. So I assume you'll have something that meets the "something runs" criteria in at most a couple of weeks. Shouldn't be too bad, no? :)
> 
> Listen, I won't spend a couple of weeks on a firmware that I don't need just because you want me to.
> I can't work on QEMU all day nor am I getting paid for it, so I'd rather spend my time on getting ppc/ppc64 Mac emulation working for my needs! :)

Yup. I thought you were the incredible Hulk and would manage to get everything working nevertheless :). No, seriously - is it really too much work left to do? The target did work at one point in time already, right?

> 
> My interest in PReP is of historical nature only - it would be 'cool' to see BeOS/ppc emulated (and - if feasible - extend Haiku/ppc to run on it, too).

I fully agree!

> 
> The three QEMU PReP projects we're talking about here - 'prep', '40p' and BeBox share a common core like some memory-mapped registers but use different devices and different firmware. The IBM 40p works with a binary firmware - got it to show some graphics on OpenSolaris/amd64 host yesterday (hinting towards endianness issues on Darwin/ppc64 host). The BeBox BootROM however uses a custom format with Be-specific headers and some PE stuff as it seems [1]. Writing firmware for the 'prep' machine buys us nothing there... Fixing it is not even strictly needed, but it seems a good deed while we're at it.

I see. Well, don't do it then. Just get something proprietary running and be good. I merely wanted to save you from the troubles I go through with S/390 where people simply don't test that target since they can't run it...


Alex

Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Andreas Färber]

Am 21.12.2010 um 00:07 schrieb Alexander Graf:

> On 21.12.2010, at 00:00, Andreas Färber wrote:
>
>> Am 20.12.2010 um 10:04 schrieb Alexander Graf:
>>
>>> On 19.12.2010, at 20:12, Andreas Färber wrote:
>>>
>>>> Am 19.12.2010 um 16:34 schrieb Alexander Graf:
>>>>
>>>>> On 19.12.2010, at 16:04, Andreas Färber wrote:
>>>>>
>>>>>> Am 19.12.2010 um 10:54 schrieb Alexander Graf:
>>>>>>
>>>>>>> On 14.12.2010, at 01:49, Andreas Färber wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Based on an earlier attempt of mine to make OpenBIOS work  
>>>>>>>> with -M prep,
>>>>>>>> with kind support from Hervé Poussineau here's an initial  
>>>>>>>> stab at
>>>>>>>> fixing the long-broken PReP emulation and preparing migration  
>>>>>>>> from
>>>>>>>> abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware.
>>>>>>>>
>>>>>>>> In particular a number of hw_error()s are resolved, so that  
>>>>>>>> the BIOS
>>>>>>>> can be entered at all. It is not yet working in terms of  
>>>>>>>> serial and
>>>>>>>> VGA support etc.
>>>>>>>>
>>>>>>>> This series is also available from:
>>>>>>>>
>>>>>>>> git://repo.or.cz/qemu/afaerber.git prep-queue
>>>>>>>>
>>>>>>>> Some more work-in-progress for the curious is on my prep  
>>>>>>>> branch [2].
>>>>>>>> The corresponding work-in-progress OpenBIOS changes are at [3].
>>>>>>>>
>>>>>>>> Unfortunately the prep machine is lacking documentation what  
>>>>>>>> exactly it
>>>>>>>> tries to emulate. The plan thus is to merge emulation of a  
>>>>>>>> second, real
>>>>>>>> IBM 40p machine based on Hervé's work at [1], for use with  
>>>>>>>> original
>>>>>>>> binary firmware.
>>>>>>>>
>>>>>>>> Also upcoming are new ppc_chrp machines, forked from  
>>>>>>>> ppc_newworld,
>>>>>>>> emulating the 970-based IBM JS20 (using Apple U3) [4] and  
>>>>>>>> possibly the
>>>>>>>> POWER5-based IntelliStation 285. These depend on the ongoing  
>>>>>>>> ppc64 port
>>>>>>>> of OpenBIOS to be completed though. This relates to PReP in  
>>>>>>>> that the
>>>>>>>> machine IDs will need to be coordinated.
>>>>>>>
>>>>>>> Does this series actually make anything work, or is it just a  
>>>>>>> first step set to get your development rolling? IOW, would  
>>>>>>> users benefit from having the patches upstream yet?
>>>>>>
>>>>>> As indicated above, it lets you enter a BIOS, which is a user- 
>>>>>> visible improvement. User-supplied binary firmware works with 1  
>>>>>> + 3-4, ELF firmware with 1-4. Patch 3 depends on review  
>>>>>> comments. Patch 4 was just an FYI for testing the preceding  
>>>>>> patches and still needs investigation.
>>>>>>
>>>>>> For OpenBIOS to work, we need fw_cfg in ppc_prep.c and,  
>>>>>> independently, patches to OpenBIOS. Unless of course we want to  
>>>>>> use another firmware like OFW from the start. The main interest  
>>>>>> in PReP nowadays will be proprietary firmware anyway. I thought  
>>>>>> Rob (cc'ed) had PReP Linux kernel patches for QEMU at some  
>>>>>> point but I couldn't locate them in the Aboriginal Linux tree.
>>>>>
>>>>> I'm not sure on the copyright problems we might run into when  
>>>>> delivering binary firmware.
>>>>
>>>> No one suggested shipping proprietary firmware.
>>>>
>>>> I was advocating enabling users to use the available firmware  
>>>> rather than holding fixes back just because there is no fully- 
>>>> working FOSS alternative firmware yet.
>>>
>>> Hrm, I only partially agree. If you ship a target in qemu that  
>>> people can't test out of the box, it won't receive testing from  
>>> contributers. I doubt that RH people will go in and download  
>>> proprietary firmware just to check that prep didn't break. I do  
>>> hope however, that they test targets that "just work".
>>>
>>> I have this very issue with s390. The only host to run (and  
>>> compile) this on is an s390. And few people have those. So it  
>>> breaks from time to time.
>>>
>>> Since prep would at least get built for everyone, there's less of  
>>> an issue, yes.
>>>
>>>>
>>>>> So we certainly do need some open source firmware solution for  
>>>>> prep to at least have Linux running. For other guests, I don't  
>>>>> see a reason why users shouldn't try to fetch a real firmware  
>>>>> blob separately :).
>>>>
>>>> We're not shipping any firmware for ppcemb either, so that  
>>>> argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones  
>>>> currently. Feel free to supply additional blobs for U-Boot etc.
>>>
>>> IIUC you don't need u-boot for the embedded targets. You just pass  
>>> in a kernel and the rest is magic.
>>>
>>>> Recent vanilla Linux kernels wouldn't run on PReP. So what Linux  
>>>> do you want to run using open source firmware?
>>>> I certainly do not intend to write firmware for the upcoming 40p  
>>>> machine. If Linux runs on real 40p hardware then it should run  
>>>> with real firmware under emulation, too. QEMU is an emulation  
>>>> project, not a Linux testing framework.
>>>
>>> I completely agree. Linux is usually easy because it's fully open  
>>> source and supports a lot of targets. If you feel like running  
>>> NetBSD or Haiku instead, feel free to do so.
>>>
>>> I'd even be willing to say that running any OS with a proprietary  
>>> firmware blob is enough to pull stuff in. And really, I mean _any_  
>>> OS. I just really want to see some value for users, so in case the  
>>> whole system just doesn't work at all, we can rather apply a big  
>>> bunch of removal commits instead of fixes that won't end up in  
>>> anything working either.
>>>
>>> Having said that, I have faith in your skills to get this working.  
>>> So I assume you'll have something that meets the "something runs"  
>>> criteria in at most a couple of weeks. Shouldn't be too bad, no? :)
>>
>> Listen, I won't spend a couple of weeks on a firmware that I don't  
>> need just because you want me to.
>> I can't work on QEMU all day nor am I getting paid for it, so I'd  
>> rather spend my time on getting ppc/ppc64 Mac emulation working for  
>> my needs! :)
>
> [...] seriously - is it really too much work left to do? The target  
> did work at one point in time already, right?

Not with OpenBIOS, no. It's a nightmare, since we don't even get  
serial output because PReP doesn't use ESCC or not in the locations it  
expects. This is hardcoded in the config file and thus not fw_cfg- 
dependent.

The switch to OpenBIOS really marked the beginning of my being able to  
use qemu-system-ppc. OpenHack'Ware never worked for me before.  
Supposedly patched Linux kernels loaded via -kernel, still searching  
for a working one though...

$ qemu-system-ppc -M prep -nographic
ERROR: BUG caught...
BIOS execution exception
nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000
Stopping execution

$ qemu-system-ppc -M prep -kernel .../vmlinuz-2.4.25 -nographic # http://www.olifantasia.com/qemu/
ERROR: BUG caught...
BIOS execution exception
nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000
Stopping execution

$ qemu-system-ppc -M prep -kernel .../vmlinuz-2.4.25 -append  
'ide0=0x1f0,0x3f6,13 ide1=0x170,0x376,13 netdev=9,0x300,eth0  
console=ttyS0 console=tty0 root=/dev/hda' -nographic
ERROR: BUG caught...
BIOS execution exception
nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000
Stopping execution

Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Alexander Graf]

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


On 21.12.2010, at 01:33, Andreas Färber wrote:

> Am 21.12.2010 um 00:07 schrieb Alexander Graf:
> 
>> On 21.12.2010, at 00:00, Andreas Färber wrote:
>> 
>>> Am 20.12.2010 um 10:04 schrieb Alexander Graf:
>>> 
>>>> On 19.12.2010, at 20:12, Andreas Färber wrote:
>>>> 
>>>>> Am 19.12.2010 um 16:34 schrieb Alexander Graf:
>>>>> 
>>>>>> On 19.12.2010, at 16:04, Andreas Färber wrote:
>>>>>> 
>>>>>>> Am 19.12.2010 um 10:54 schrieb Alexander Graf:
>>>>>>> 
>>>>>>>> On 14.12.2010, at 01:49, Andreas Färber wrote:
>>>>>>>> 
>>>>>>>>> Hello,
>>>>>>>>> 
>>>>>>>>> Based on an earlier attempt of mine to make OpenBIOS work with -M prep,
>>>>>>>>> with kind support from Hervé Poussineau here's an initial stab at
>>>>>>>>> fixing the long-broken PReP emulation and preparing migration from
>>>>>>>>> abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware.
>>>>>>>>> 
>>>>>>>>> In particular a number of hw_error()s are resolved, so that the BIOS
>>>>>>>>> can be entered at all. It is not yet working in terms of serial and
>>>>>>>>> VGA support etc.
>>>>>>>>> 
>>>>>>>>> This series is also available from:
>>>>>>>>> 
>>>>>>>>> git://repo.or.cz/qemu/afaerber.git prep-queue
>>>>>>>>> 
>>>>>>>>> Some more work-in-progress for the curious is on my prep branch [2].
>>>>>>>>> The corresponding work-in-progress OpenBIOS changes are at [3].
>>>>>>>>> 
>>>>>>>>> Unfortunately the prep machine is lacking documentation what exactly it
>>>>>>>>> tries to emulate. The plan thus is to merge emulation of a second, real
>>>>>>>>> IBM 40p machine based on Hervé's work at [1], for use with original
>>>>>>>>> binary firmware.
>>>>>>>>> 
>>>>>>>>> Also upcoming are new ppc_chrp machines, forked from ppc_newworld,
>>>>>>>>> emulating the 970-based IBM JS20 (using Apple U3) [4] and possibly the
>>>>>>>>> POWER5-based IntelliStation 285. These depend on the ongoing ppc64 port
>>>>>>>>> of OpenBIOS to be completed though. This relates to PReP in that the
>>>>>>>>> machine IDs will need to be coordinated.
>>>>>>>> 
>>>>>>>> Does this series actually make anything work, or is it just a first step set to get your development rolling? IOW, would users benefit from having the patches upstream yet?
>>>>>>> 
>>>>>>> As indicated above, it lets you enter a BIOS, which is a user-visible improvement. User-supplied binary firmware works with 1 + 3-4, ELF firmware with 1-4. Patch 3 depends on review comments. Patch 4 was just an FYI for testing the preceding patches and still needs investigation.
>>>>>>> 
>>>>>>> For OpenBIOS to work, we need fw_cfg in ppc_prep.c and, independently, patches to OpenBIOS. Unless of course we want to use another firmware like OFW from the start. The main interest in PReP nowadays will be proprietary firmware anyway. I thought Rob (cc'ed) had PReP Linux kernel patches for QEMU at some point but I couldn't locate them in the Aboriginal Linux tree.
>>>>>> 
>>>>>> I'm not sure on the copyright problems we might run into when delivering binary firmware.
>>>>> 
>>>>> No one suggested shipping proprietary firmware.
>>>>> 
>>>>> I was advocating enabling users to use the available firmware rather than holding fixes back just because there is no fully-working FOSS alternative firmware yet.
>>>> 
>>>> Hrm, I only partially agree. If you ship a target in qemu that people can't test out of the box, it won't receive testing from contributers. I doubt that RH people will go in and download proprietary firmware just to check that prep didn't break. I do hope however, that they test targets that "just work".
>>>> 
>>>> I have this very issue with s390. The only host to run (and compile) this on is an s390. And few people have those. So it breaks from time to time.
>>>> 
>>>> Since prep would at least get built for everyone, there's less of an issue, yes.
>>>> 
>>>>> 
>>>>>> So we certainly do need some open source firmware solution for prep to at least have Linux running. For other guests, I don't see a reason why users shouldn't try to fetch a real firmware blob separately :).
>>>>> 
>>>>> We're not shipping any firmware for ppcemb either, so that argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to supply additional blobs for U-Boot etc.
>>>> 
>>>> IIUC you don't need u-boot for the embedded targets. You just pass in a kernel and the rest is magic.
>>>> 
>>>>> Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want to run using open source firmware?
>>>>> I certainly do not intend to write firmware for the upcoming 40p machine. If Linux runs on real 40p hardware then it should run with real firmware under emulation, too. QEMU is an emulation project, not a Linux testing framework.
>>>> 
>>>> I completely agree. Linux is usually easy because it's fully open source and supports a lot of targets. If you feel like running NetBSD or Haiku instead, feel free to do so.
>>>> 
>>>> I'd even be willing to say that running any OS with a proprietary firmware blob is enough to pull stuff in. And really, I mean _any_ OS. I just really want to see some value for users, so in case the whole system just doesn't work at all, we can rather apply a big bunch of removal commits instead of fixes that won't end up in anything working either.
>>>> 
>>>> Having said that, I have faith in your skills to get this working. So I assume you'll have something that meets the "something runs" criteria in at most a couple of weeks. Shouldn't be too bad, no? :)
>>> 
>>> Listen, I won't spend a couple of weeks on a firmware that I don't need just because you want me to.
>>> I can't work on QEMU all day nor am I getting paid for it, so I'd rather spend my time on getting ppc/ppc64 Mac emulation working for my needs! :)
>> 
>> [...] seriously - is it really too much work left to do? The target did work at one point in time already, right?
> 
> Not with OpenBIOS, no. It's a nightmare, since we don't even get serial output because PReP doesn't use ESCC or not in the locations it expects. This is hardcoded in the config file and thus not fw_cfg-dependent.
> 
> The switch to OpenBIOS really marked the beginning of my being able to use qemu-system-ppc. OpenHack'Ware never worked for me before. Supposedly patched Linux kernels loaded via -kernel, still searching for a working one though...
> 
> $ qemu-system-ppc -M prep -nographic
> ERROR: BUG caught...
> BIOS execution exception
> nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000
> Stopping execution
> 
> $ qemu-system-ppc -M prep -kernel .../vmlinuz-2.4.25 -nographic # http://www.olifantasia.com/qemu/
> ERROR: BUG caught...
> BIOS execution exception
> nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000
> Stopping execution
> 
> $ qemu-system-ppc -M prep -kernel .../vmlinuz-2.4.25 -append 'ide0=0x1f0,0x3f6,13 ide1=0x170,0x376,13 netdev=9,0x300,eth0 console=ttyS0 console=tty0 root=/dev/hda' -nographic
> ERROR: BUG caught...
> BIOS execution exception
> nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000
> Stopping execution
> 

This one boots for me on qemu from SLES10SP3 (0.8.2):

http://www.oszoo.org/wiki/index.php/Debian_Etch_ppc_(PowerPC)_-_Qemu_Ready


Alex


[-- Attachment #2: Type: text/html, Size: 23086 bytes --]

Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Andreas Färber]

Am 21.12.2010 um 01:46 schrieb Alexander Graf:

> On 21.12.2010, at 01:33, Andreas Färber wrote:
>
>> OpenHack'Ware never worked for me before. Supposedly patched Linux  
>> kernels loaded via -kernel, still searching for a working one  
>> though...
>>
>> $ qemu-system-ppc -M prep -nographic
>> ERROR: BUG caught...
>> BIOS execution exception
>> nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000
>> Stopping execution
>>
>> $ qemu-system-ppc -M prep -kernel .../vmlinuz-2.4.25 -nographic # http://www.olifantasia.com/qemu/
>> ERROR: BUG caught...
>> BIOS execution exception
>> nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000
>> Stopping execution
>>
>> $ qemu-system-ppc -M prep -kernel .../vmlinuz-2.4.25 -append  
>> 'ide0=0x1f0,0x3f6,13 ide1=0x170,0x376,13 netdev=9,0x300,eth0  
>> console=ttyS0 console=tty0 root=/dev/hda' -nographic
>> ERROR: BUG caught...
>> BIOS execution exception
>> nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000
>> Stopping execution
>>
>
> This one boots for me on qemu from SLES10SP3 (0.8.2):
>
> http://www.oszoo.org/wiki/index.php/Debian_Etch_ppc_(PowerPC)_-_Qemu_Ready

$ qemu-system-ppc -m 256 -M prep -kernel .../zImage.prep -hda .../ 
debian-ppc-qemu.qcow -nographic

shows same error as above.

Could this be due to the IRQ issue? The older kernel did expect IRQ 13  
twice.
I would expect it to get a little further before running into such an  
error...

Andreas

Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Alexander Graf]

On 22.12.2010, at 00:51, Andreas Färber <andreas.faerber@web.de> wrote:

> Am 21.12.2010 um 01:46 schrieb Alexander Graf:
> 
>> On 21.12.2010, at 01:33, Andreas Färber wrote:
>> 
>>> OpenHack'Ware never worked for me before. Supposedly patched Linux kernels loaded via -kernel, still searching for a working one though...
>>> 
>>> $ qemu-system-ppc -M prep -nographic
>>> ERROR: BUG caught...
>>> BIOS execution exception
>>> nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000
>>> Stopping execution
>>> 
>>> $ qemu-system-ppc -M prep -kernel .../vmlinuz-2.4.25 -nographic # http://www.olifantasia.com/qemu/
>>> ERROR: BUG caught...
>>> BIOS execution exception
>>> nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000
>>> Stopping execution
>>> 
>>> $ qemu-system-ppc -M prep -kernel .../vmlinuz-2.4.25 -append 'ide0=0x1f0,0x3f6,13 ide1=0x170,0x376,13 netdev=9,0x300,eth0 console=ttyS0 console=tty0 root=/dev/hda' -nographic
>>> ERROR: BUG caught...
>>> BIOS execution exception
>>> nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000
>>> Stopping execution
>>> 
>> 
>> This one boots for me on qemu from SLES10SP3 (0.8.2):
>> 
>> http://www.oszoo.org/wiki/index.php/Debian_Etch_ppc_(PowerPC)_-_Qemu_Ready
> 
> $ qemu-system-ppc -m 256 -M prep -kernel .../zImage.prep -hda .../debian-ppc-qemu.qcow -nographic
> 
> shows same error as above.
> 
> Could this be due to the IRQ issue? The older kernel did expect IRQ 13 twice.
> I would expect it to get a little further before running into such an error...

Phew - I doubt it too. There have been quite some changes since it last worked I guess ;). First thing that sounds reasonable now would be to find a known good version and check when the interpreted code paths start to differ.

Alex

> 

[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Rob Landley]

On Monday 20 December 2010 03:04:38 Alexander Graf wrote:
> On 19.12.2010, at 20:12, Andreas Färber wrote:
> > Am 19.12.2010 um 16:34 schrieb Alexander Graf:
> >> On 19.12.2010, at 16:04, Andreas Färber wrote:
> >>> Am 19.12.2010 um 10:54 schrieb Alexander Graf:
> >>>> On 14.12.2010, at 01:49, Andreas Färber wrote:
> >>>>> Hello,
> >>>>>
> >>>>> Based on an earlier attempt of mine to make OpenBIOS work with -M
> >>>>> prep, with kind support from Hervé Poussineau here's an initial stab
> >>>>> at fixing the long-broken PReP emulation and preparing migration from
> >>>>> abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware.
> >>>>>
> >>>>> In particular a number of hw_error()s are resolved, so that the BIOS
> >>>>> can be entered at all. It is not yet working in terms of serial and
> >>>>> VGA support etc.
> >>>>>
> >>>>> This series is also available from:
> >>>>>
> >>>>> git://repo.or.cz/qemu/afaerber.git prep-queue
> >>>>>
> >>>>> Some more work-in-progress for the curious is on my prep branch [2].
> >>>>> The corresponding work-in-progress OpenBIOS changes are at [3].
> >>>>>
> >>>>> Unfortunately the prep machine is lacking documentation what exactly
> >>>>> it tries to emulate. The plan thus is to merge emulation of a second,
> >>>>> real IBM 40p machine based on Hervé's work at [1], for use with
> >>>>> original binary firmware.
> >>>>>
> >>>>> Also upcoming are new ppc_chrp machines, forked from ppc_newworld,
> >>>>> emulating the 970-based IBM JS20 (using Apple U3) [4] and possibly
> >>>>> the POWER5-based IntelliStation 285. These depend on the ongoing
> >>>>> ppc64 port of OpenBIOS to be completed though. This relates to PReP
> >>>>> in that the machine IDs will need to be coordinated.
> >>>>
> >>>> Does this series actually make anything work, or is it just a first
> >>>> step set to get your development rolling? IOW, would users benefit
> >>>> from having the patches upstream yet?
> >>>
> >>> As indicated above, it lets you enter a BIOS, which is a user-visible
> >>> improvement. User-supplied binary firmware works with 1 + 3-4, ELF
> >>> firmware with 1-4. Patch 3 depends on review comments. Patch 4 was just
> >>> an FYI for testing the preceding patches and still needs investigation.
> >>>
> >>> For OpenBIOS to work, we need fw_cfg in ppc_prep.c and, independently,
> >>> patches to OpenBIOS. Unless of course we want to use another firmware
> >>> like OFW from the start. The main interest in PReP nowadays will be
> >>> proprietary firmware anyway. I thought Rob (cc'ed) had PReP Linux
> >>> kernel patches for QEMU at some point but I couldn't locate them in the
> >>> Aboriginal Linux tree.
> >>
> >> I'm not sure on the copyright problems we might run into when delivering
> >> binary firmware.
> >
> > No one suggested shipping proprietary firmware.
> >
> > I was advocating enabling users to use the available firmware rather than
> > holding fixes back just because there is no fully-working FOSS
> > alternative firmware yet.
>
> Hrm, I only partially agree. If you ship a target in qemu that people can't
> test out of the box, it won't receive testing from contributers. I doubt
> that RH people will go in and download proprietary firmware just to check
> that prep didn't break. I do hope however, that they test targets that
> "just work".

I have prebuilt binaries for a bunch of different targets at 
http://landley.net/aboriginal/downloads/binaries (grab the system-image 
tarballs and run the "run-emulator.sh" or "dev-environment.sh" scripts out of 
them).  (I'm actually working on a new release now, should be out by new 
year's.)

However, my goal is to provide native development environments (optionally 
calling out to the cross compiler on the host via distcc), so I switched from 
prep to mac99 a few years back because it was better supported and the 
architecture (compiler config) and userspace were identical.  I can dig up prep 
again, but last I checked qemu -kernel didn't work and I was using a custom 
boot sector from Milton Miller to make it boot.

> I have this very issue with s390. The only host to run (and compile) this
> on is an s390. And few people have those. So it breaks from time to time.

I have some pages bookmarked hinting how to get S390 Linux to boot under 
hercules, the same way I have instructions for running m68k under Aranym.  But 
in general, if QEMU doesn't support it I have a hard time making myself 
care...

I have been know to test out of tree architecture patches, though.  I only 
ever got sh4 to work by patching qemu, for example.

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.

[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Alexander Graf]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 27.12.2010, at 02:01, Rob Landley wrote:

> On Monday 20 December 2010 03:04:38 Alexander Graf wrote:
>> On 19.12.2010, at 20:12, Andreas Färber wrote:
>>> Am 19.12.2010 um 16:34 schrieb Alexander Graf:
>>>> On 19.12.2010, at 16:04, Andreas Färber wrote:
>>>>> Am 19.12.2010 um 10:54 schrieb Alexander Graf:
>>>>>> On 14.12.2010, at 01:49, Andreas Färber wrote:
>>>>>>> Hello,
>>>>>>> 
>>>>>>> Based on an earlier attempt of mine to make OpenBIOS work with -M
>>>>>>> prep, with kind support from Hervé Poussineau here's an initial stab
>>>>>>> at fixing the long-broken PReP emulation and preparing migration from
>>>>>>> abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware.
>>>>>>> 
>>>>>>> In particular a number of hw_error()s are resolved, so that the BIOS
>>>>>>> can be entered at all. It is not yet working in terms of serial and
>>>>>>> VGA support etc.
>>>>>>> 
>>>>>>> This series is also available from:
>>>>>>> 
>>>>>>> git://repo.or.cz/qemu/afaerber.git prep-queue
>>>>>>> 
>>>>>>> Some more work-in-progress for the curious is on my prep branch [2].
>>>>>>> The corresponding work-in-progress OpenBIOS changes are at [3].
>>>>>>> 
>>>>>>> Unfortunately the prep machine is lacking documentation what exactly
>>>>>>> it tries to emulate. The plan thus is to merge emulation of a second,
>>>>>>> real IBM 40p machine based on Hervé's work at [1], for use with
>>>>>>> original binary firmware.
>>>>>>> 
>>>>>>> Also upcoming are new ppc_chrp machines, forked from ppc_newworld,
>>>>>>> emulating the 970-based IBM JS20 (using Apple U3) [4] and possibly
>>>>>>> the POWER5-based IntelliStation 285. These depend on the ongoing
>>>>>>> ppc64 port of OpenBIOS to be completed though. This relates to PReP
>>>>>>> in that the machine IDs will need to be coordinated.
>>>>>> 
>>>>>> Does this series actually make anything work, or is it just a first
>>>>>> step set to get your development rolling? IOW, would users benefit
>>>>>> from having the patches upstream yet?
>>>>> 
>>>>> As indicated above, it lets you enter a BIOS, which is a user-visible
>>>>> improvement. User-supplied binary firmware works with 1 + 3-4, ELF
>>>>> firmware with 1-4. Patch 3 depends on review comments. Patch 4 was just
>>>>> an FYI for testing the preceding patches and still needs investigation.
>>>>> 
>>>>> For OpenBIOS to work, we need fw_cfg in ppc_prep.c and, independently,
>>>>> patches to OpenBIOS. Unless of course we want to use another firmware
>>>>> like OFW from the start. The main interest in PReP nowadays will be
>>>>> proprietary firmware anyway. I thought Rob (cc'ed) had PReP Linux
>>>>> kernel patches for QEMU at some point but I couldn't locate them in the
>>>>> Aboriginal Linux tree.
>>>> 
>>>> I'm not sure on the copyright problems we might run into when delivering
>>>> binary firmware.
>>> 
>>> No one suggested shipping proprietary firmware.
>>> 
>>> I was advocating enabling users to use the available firmware rather than
>>> holding fixes back just because there is no fully-working FOSS
>>> alternative firmware yet.
>> 
>> Hrm, I only partially agree. If you ship a target in qemu that people can't
>> test out of the box, it won't receive testing from contributers. I doubt
>> that RH people will go in and download proprietary firmware just to check
>> that prep didn't break. I do hope however, that they test targets that
>> "just work".
> 
> I have prebuilt binaries for a bunch of different targets at 
> http://landley.net/aboriginal/downloads/binaries (grab the system-image 
> tarballs and run the "run-emulator.sh" or "dev-environment.sh" scripts out of 
> them).  (I'm actually working on a new release now, should be out by new 
> year's.)
> 
> However, my goal is to provide native development environments (optionally 
> calling out to the cross compiler on the host via distcc), so I switched from 
> prep to mac99 a few years back because it was better supported and the 
> architecture (compiler config) and userspace were identical.  I can dig up prep 
> again, but last I checked qemu -kernel didn't work and I was using a custom 
> boot sector from Milton Miller to make it boot.
> 
>> I have this very issue with s390. The only host to run (and compile) this
>> on is an s390. And few people have those. So it breaks from time to time.
> 
> I have some pages bookmarked hinting how to get S390 Linux to boot under 
> hercules, the same way I have instructions for running m68k under Aranym.  But 
> in general, if QEMU doesn't support it I have a hard time making myself 
> care...

Few people jump through the hoops to run an emulator to compile and run qemu inside then when they only want to verify if their patches break something. The general philosophy I've seen is that the best we can expect is a "does ./configure && make break on your x86_64 box?".

> I have been know to test out of tree architecture patches, though.  I only 
> ever got sh4 to work by patching qemu, for example.

I really dislike out-of-tree. As soon as an architecture runs publicly available code, it should get upstream, so others can benefit from it.


Alex

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)

iEUEARECAAYFAk0jilwACgkQq7Wi27wfN1P+ggCWKSPiYeZJnEEaSoFWsroBx7rL
5ACfVxQlUZAY+jZSRTvHRF+EKQh9W84=
=1JOQ
-----END PGP SIGNATURE-----

[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Rob Landley]

On Tuesday 04 January 2011 15:00:12 Alexander Graf wrote:
> >> I have this very issue with s390. The only host to run (and compile)
> >> this on is an s390. And few people have those. So it breaks from time to
> >> time.
> >
> > I have some pages bookmarked hinting how to get S390 Linux to boot under
> > hercules, the same way I have instructions for running m68k under Aranym.
> >  But in general, if QEMU doesn't support it I have a hard time making
> > myself care...
>
> Few people jump through the hoops to run an emulator to compile and run
> qemu inside then when they only want to verify if their patches break
> something. The general philosophy I've seen is that the best we can expect
> is a "does ./configure && make break on your x86_64 box?".

If you're talking about running qemu on a non-x86 host, I don't do that.  But 
if you're talking about running non-x86 code on qemu, my project's motto is 
"we cross compile so you don't have to".  The thing is designed so you grab a 
tarball and go "./run-emulator.sh" to get a shell prompt in your emulated 
environment, with full development tools.  If you go "./dev-environment.sh" 
instead you get a 2 gigabyte pesistent ext2 image mounted on /home so you can 
wget and build fairly large packages.

I've built the whole of Linux From Scratch 6.7 inside this this, on a couple 
different platforms.  (Still debugging powerpc and mips, probably uClibc 
issues.  Less spare time than I used to have...)

In theory I could do the same with qemu itself, just like any other software 
package.  If you feed it just one architecture in a --target-list it shouldn't 
take _too_ long to build.  But in practice running the result would be too 
slow to do more than boot to a shell prompt and demonstrate that it worked.

> > I have been know to test out of tree architecture patches, though.  I
> > only ever got sh4 to work by patching qemu, for example.
>
> I really dislike out-of-tree.

I can't stand 'em, but I don't control what gets merged into most projects.

> As soon as an architecture runs publicly
> available code, it should get upstream, so others can benefit from it.

Entirely agreed.  I've been waiting for any of the m68k improvements to QEMU 
(to run more than just coldfire) work to get merged for a long time.  And I 
have a todo item to look at https://github.com/uli/qemu-s390 also...

> Alex

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.

[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Alexander Graf]

On 05.01.2011, at 13:07, Rob Landley wrote:

> On Tuesday 04 January 2011 15:00:12 Alexander Graf wrote:
>>>> I have this very issue with s390. The only host to run (and compile)
>>>> this on is an s390. And few people have those. So it breaks from time to
>>>> time.
>>> 
>>> I have some pages bookmarked hinting how to get S390 Linux to boot under
>>> hercules, the same way I have instructions for running m68k under Aranym.
>>> But in general, if QEMU doesn't support it I have a hard time making
>>> myself care...
>> 
>> Few people jump through the hoops to run an emulator to compile and run
>> qemu inside then when they only want to verify if their patches break
>> something. The general philosophy I've seen is that the best we can expect
>> is a "does ./configure && make break on your x86_64 box?".
> 
> If you're talking about running qemu on a non-x86 host, I don't do that.  But 
> if you're talking about running non-x86 code on qemu, my project's motto is 
> "we cross compile so you don't have to".  The thing is designed so you grab a 
> tarball and go "./run-emulator.sh" to get a shell prompt in your emulated 
> environment, with full development tools.  If you go "./dev-environment.sh" 
> instead you get a 2 gigabyte pesistent ext2 image mounted on /home so you can 
> wget and build fairly large packages.
> 
> I've built the whole of Linux From Scratch 6.7 inside this this, on a couple 
> different platforms.  (Still debugging powerpc and mips, probably uClibc 
> issues.  Less spare time than I used to have...)
> 
> In theory I could do the same with qemu itself, just like any other software 
> package.  If you feed it just one architecture in a --target-list it shouldn't 
> take _too_ long to build.  But in practice running the result would be too 
> slow to do more than boot to a shell prompt and demonstrate that it worked.

Yeah, don't worry. My point was that anything that doesn't build and run on x86 hosts has little chance of getting test coverage.

> 
>>> I have been know to test out of tree architecture patches, though.  I
>>> only ever got sh4 to work by patching qemu, for example.
>> 
>> I really dislike out-of-tree.
> 
> I can't stand 'em, but I don't control what gets merged into most projects.

The main issue is that it takes time and effort to get stuff upstream - and it's good that way. There are people out there who are great programmers, but unfortunately don't have the patience to go through an upstream merging cleanup process.

> 
>> As soon as an architecture runs publicly
>> available code, it should get upstream, so others can benefit from it.
> 
> Entirely agreed.  I've been waiting for any of the m68k improvements to QEMU 
> (to run more than just coldfire) work to get merged for a long time.  And I 
> have a todo item to look at https://github.com/uli/qemu-s390 also...

I'm currently working on the s390 parts, so no worries. I have a cleaned up tree and partially working system emulation already.


Alex

[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Rob Landley]

On Wednesday 05 January 2011 06:31:01 Alexander Graf wrote:
> On 05.01.2011, at 13:07, Rob Landley wrote:
> > On Tuesday 04 January 2011 15:00:12 Alexander Graf wrote:
> >>>> I have this very issue with s390. The only host to run (and compile)
> >>>> this on is an s390. And few people have those. So it breaks from time
> >>>> to time.
> >>>
> >>> I have some pages bookmarked hinting how to get S390 Linux to boot
> >>> under hercules, the same way I have instructions for running m68k under
> >>> Aranym. But in general, if QEMU doesn't support it I have a hard time
> >>> making myself care...
> >>
> >> Few people jump through the hoops to run an emulator to compile and run
> >> qemu inside then when they only want to verify if their patches break
> >> something. The general philosophy I've seen is that the best we can
> >> expect is a "does ./configure && make break on your x86_64 box?".
> >
> > If you're talking about running qemu on a non-x86 host, I don't do that. 
> > But if you're talking about running non-x86 code on qemu, my project's
> > motto is "we cross compile so you don't have to".  The thing is designed
> > so you grab a tarball and go "./run-emulator.sh" to get a shell prompt in
> > your emulated environment, with full development tools.  If you go
> > "./dev-environment.sh" instead you get a 2 gigabyte pesistent ext2 image
> > mounted on /home so you can wget and build fairly large packages.
> >
> > I've built the whole of Linux From Scratch 6.7 inside this this, on a
> > couple different platforms.  (Still debugging powerpc and mips, probably
> > uClibc issues.  Less spare time than I used to have...)
> >
> > In theory I could do the same with qemu itself, just like any other
> > software package.  If you feed it just one architecture in a
> > --target-list it shouldn't take _too_ long to build.  But in practice
> > running the result would be too slow to do more than boot to a shell
> > prompt and demonstrate that it worked.
>
> Yeah, don't worry. My point was that anything that doesn't build and run on
> x86 hosts has little chance of getting test coverage.

Which is half the reason I did Aboriginal Linux.

Download one of the prebuilt system images, use ./dev-environment.sh to get a 
shell prompt in the emulator with full development tools, wget your source 
code, ./configure, make, run test suite.

That means people who don't own this hardware can still test it on their 
laptop, or from a cron job.  It means you can package up a test environment 
with your bug report so a package maintainer (who hasn't got the hardware 
either) can reproduce your non-x86 bug and test their fixes.

I did a giant evil presentation on this once upon a time, over 200 slides.  
(An 8 hour, day-long course to actually cover all that, but everybody kept 
wanting 1 hour summaries...  Oh well.)

  http://landley.net/aboriginal/downloads/presentation.pdf

> >>> I have been know to test out of tree architecture patches, though.  I
> >>> only ever got sh4 to work by patching qemu, for example.
> >>
> >> I really dislike out-of-tree.
> >
> > I can't stand 'em, but I don't control what gets merged into most
> > projects.
>
> The main issue is that it takes time and effort to get stuff upstream - and
> it's good that way. There are people out there who are great programmers,
> but unfortunately don't have the patience to go through an upstream merging
> cleanup process.

Sometimes it's not a question of cleanup, sometimes it's a question of the 
upstream developers simply not wanting to do something you want to do.  It's 
possible to disagree on _goals_.

If the then-kconfig maintainer thinks miniconfig is simply a bad idea, you can't 
exactly work around him by rewriting the implementation.

I've been submitting perl removal patches to the linux kernel build on and off 
since Peter Anvin went crazy and simultaneously introduced perl as a build 
prerequisite to the 2.6.25 kernel (and every other project he contributed to, 
ala klibc and syslinux and such, all at the same time).  He resists the 
removal on principle because he thinks it's GOOD that the kernel depends on 
perl to build.  I have no idea why.

Is sysfs an ABI the kernel exports to userspace that should be stable and 
documented, or is it a private channel that Greg KH and Kay Sievers made for 
their userspace udev package that nobody else should ever use?  When Linus 
believes one thing and Greg and Kay clearly believe another but won't _admit_ 
it, you can get some (hilarious or frustrating, depending on your point of 
view) squirming out of them:

  http://lkml.org/lkml/2007/7/20/487

Technical issues I'll engage with ad nauseam, but irreconcilable differences of 
_opinion_ you can't always work around.

The squashfs maintainer's efforts to get his patch merged upstream were 
positively _heroic_, but really: by the time EVERY SINGLE DISTRO is shipping 
an out of tree patch, the vanilla kernel not including it is a problem with 
the vanilla kernel.  (And yes a year or so before it was merged I checked, and 
couldn't find a non-toy distro (I.E. one with a package management system and a 
reasonably current kernel) that _didn't_ include squashfs.  Which didn't get 
merged for another 4 releases after that, and when it _did_ the file format was 
incompatible with what was already out there.)

I'm not sure the _twelve_year_ saga of union mounts (at least since I first saw 
an out of tree implementation) is really a "patience and cleanup" issue 
either.  Yes it's a hard problem to get right, but so is virtual memory.  The 
linux kernel has spent its entire history with a series of sucky VM it's 
ripped out and replaced at least twice (anybody remember 2.4.10?), and that's 
not counting token based thrashing control and /proc/sys/vm/swappiness and the 
OOM killer and so on.  But it worked all that out in-tree, and union mounts 
are still out of tree.  But NFS is in-tree.  Sometimes, it seems a bit 
arbitrary to me.  Oh well.

> >> As soon as an architecture runs publicly
> >> available code, it should get upstream, so others can benefit from it.
> >
> > Entirely agreed.  I've been waiting for any of the m68k improvements to
> > QEMU (to run more than just coldfire) work to get merged for a long time.
> >  And I have a todo item to look at https://github.com/uli/qemu-s390
> > also...
>
> I'm currently working on the s390 parts, so no worries. I have a cleaned up
> tree and partially working system emulation already.

Ooh, I'm very interested in adding support for this to aboriginal linux.  
Please keep me posted...

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.

[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Rob Landley]

On Sunday 19 December 2010 09:34:24 Alexander Graf wrote:
> On 19.12.2010, at 16:04, Andreas Färber wrote:
> > Am 19.12.2010 um 10:54 schrieb Alexander Graf:
> >> On 14.12.2010, at 01:49, Andreas Färber wrote:
> >>> Hello,
> >>>
> >>> Based on an earlier attempt of mine to make OpenBIOS work with -M prep,
> >>> with kind support from Hervé Poussineau here's an initial stab at
> >>> fixing the long-broken PReP emulation and preparing migration from
> >>> abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware.
> >>>
> >>> In particular a number of hw_error()s are resolved, so that the BIOS
> >>> can be entered at all. It is not yet working in terms of serial and
> >>> VGA support etc.
> >>>
> >>> This series is also available from:
> >>>
> >>> git://repo.or.cz/qemu/afaerber.git prep-queue
> >>>
> >>> Some more work-in-progress for the curious is on my prep branch [2].
> >>> The corresponding work-in-progress OpenBIOS changes are at [3].
> >>>
> >>> Unfortunately the prep machine is lacking documentation what exactly it
> >>> tries to emulate. The plan thus is to merge emulation of a second, real
> >>> IBM 40p machine based on Hervé's work at [1], for use with original
> >>> binary firmware.
> >>>
> >>> Also upcoming are new ppc_chrp machines, forked from ppc_newworld,
> >>> emulating the 970-based IBM JS20 (using Apple U3) [4] and possibly the
> >>> POWER5-based IntelliStation 285. These depend on the ongoing ppc64 port
> >>> of OpenBIOS to be completed though. This relates to PReP in that the
> >>> machine IDs will need to be coordinated.
> >>
> >> Does this series actually make anything work, or is it just a first step
> >> set to get your development rolling? IOW, would users benefit from
> >> having the patches upstream yet?
> >
> > As indicated above, it lets you enter a BIOS, which is a user-visible
> > improvement. User-supplied binary firmware works with 1 + 3-4, ELF
> > firmware with 1-4. Patch 3 depends on review comments. Patch 4 was just
> > an FYI for testing the preceding patches and still needs investigation.
> >
> > For OpenBIOS to work, we need fw_cfg in ppc_prep.c and, independently,
> > patches to OpenBIOS. Unless of course we want to use another firmware
> > like OFW from the start. The main interest in PReP nowadays will be
> > proprietary firmware anyway. I thought Rob (cc'ed) had PReP Linux kernel
> > patches for QEMU at some point but I couldn't locate them in the
> > Aboriginal Linux tree.
>
> I'm not sure on the copyright problems we might run into when delivering
> binary firmware. So we certainly do need some open source firmware solution
> for prep to at least have Linux running. For other guests, I don't see a
> reason why users shouldn't try to fetch a real firmware blob separately :).

Milton Miller wrote the ppc_bin in the last message from scratch, and made it 
available to me under GPLv2.  The tarball is the source (which includes a 
snapshot of dtc, which these days you can suck out of the linux kernel) and 
the .bin file is the output.  I used my own powerpc toolchain (built by the 
build scripts in the same source tree) to compile it.

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.

[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Rob Landley]

On Sunday 19 December 2010 09:04:00 Andreas Färber wrote:
> For OpenBIOS to work, we need fw_cfg in ppc_prep.c and, independently,
> patches to OpenBIOS. Unless of course we want to use another firmware
> like OFW from the start. The main interest in PReP nowadays will be
> proprietary firmware anyway. I thought Rob (cc'ed) had PReP Linux
> kernel patches for QEMU at some point but I couldn't locate them in
> the Aboriginal Linux tree.

I switched from prep to c99 over a year ago, but the old file is still buried 
in the archives circa 2008 or so:

http://landley.net/hg/hgwebdir.cgi/aboriginal/file/ad65353ad01c/sources/toys

Look for ppc_rom.bin and make-ppc_rom.tar.bz2 both more or less from Milton 
Miller.  The corresponding ppc configuration is in sources/targets/powerpc and 
it worked at the time.  (I just switched to something I could do a normal
-kernel with like all the other targets.)

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.

[Qemu-devel] Re: Re: [PATCH 0/4] ppc: Fix PReP emulation

[François Revol]

>>> So we certainly do need some open source firmware solution for prep to at least have Linux running. For other guests, I don't see a reason why users shouldn't try to fetch a real firmware blob separately :).
>> 
>> We're not shipping any firmware for ppcemb either, so that argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to supply additional blobs for U-Boot etc.
> 
> IIUC you don't need u-boot for the embedded targets. You just pass in a kernel and the rest is magic.

This holds only for Linux which imposes its own startup API to bootloaders and go with kernel drivers directly.

Other OS like Haiku use a 2nd stage bootloader which assumes a working callable BIOS (OF on ppc), and getting it to run on U-Boot is already tricky on its own.

>> Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want to run using open source firmware?
>> I certainly do not intend to write firmware for the upcoming 40p machine. If Linux runs on real 40p hardware then it should run with real firmware under emulation, too. QEMU is an emulation project, not a Linux testing framework.
> 
> I completely agree. Linux is usually easy because it's fully open source and supports a lot of targets. If you feel like running NetBSD or Haiku instead, feel free to do so.

Thanks for thinking about Haiku ;)

Btw there are other existing targets, like AROS, MorphOS, or AmigaOS which uses a modified U-Boot with a 'boota' command that passes their 2nd stage Parthenope bootloader a list of BIOS-like callbacks into U-Boot, cf. :
http://www.acube-systems.biz/index.php?page=hardware&pid=2
http://www.acube-systems.biz/download/u-boot-1.3.1c_20101206_prod.tar.gz

Though they probably won't run on PReP, and PReP support in Haiku might come only for the sake of supporting the BeBox, which had its own dumb firmware (MAME seems to have some emulation support for BeBox).

OTOH, I've been thinking about adding a Sam440 target, but it'd still require the custom U-Boot to start AmigaOS for example.

François.

[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Alexander Graf]

On 20.12.2010, at 13:19, François Revol wrote:

>>>> So we certainly do need some open source firmware solution for prep to at least have Linux running. For other guests, I don't see a reason why users shouldn't try to fetch a real firmware blob separately :).
>>> 
>>> We're not shipping any firmware for ppcemb either, so that argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to supply additional blobs for U-Boot etc.
>> 
>> IIUC you don't need u-boot for the embedded targets. You just pass in a kernel and the rest is magic.
> 
> This holds only for Linux which imposes its own startup API to bootloaders and go with kernel drivers directly.
> 
> Other OS like Haiku use a 2nd stage bootloader which assumes a working callable BIOS (OF on ppc), and getting it to run on U-Boot is already tricky on its own.

That was my point :). I'm not aware of us supporting firmware on ppcemb, so it's capable of running an OS all by itself already.

> 
>>> Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want to run using open source firmware?
>>> I certainly do not intend to write firmware for the upcoming 40p machine. If Linux runs on real 40p hardware then it should run with real firmware under emulation, too. QEMU is an emulation project, not a Linux testing framework.
>> 
>> I completely agree. Linux is usually easy because it's fully open source and supports a lot of targets. If you feel like running NetBSD or Haiku instead, feel free to do so.
> 
> Thanks for thinking about Haiku ;)
> 
> Btw there are other existing targets, like AROS, MorphOS, or AmigaOS which uses a modified U-Boot with a 'boota' command that passes their 2nd stage Parthenope bootloader a list of BIOS-like callbacks into U-Boot, cf. :
> http://www.acube-systems.biz/index.php?page=hardware&pid=2
> http://www.acube-systems.biz/download/u-boot-1.3.1c_20101206_prod.tar.gz
> 
> Though they probably won't run on PReP, and PReP support in Haiku might come only for the sake of supporting the BeBox, which had its own dumb firmware (MAME seems to have some emulation support for BeBox).
> 
> OTOH, I've been thinking about adding a Sam440 target, but it'd still require the custom U-Boot to start AmigaOS for example.

I'd call U-Boot the firmware that we can ship with Qemu then because it's open source :). I'm not advocate for openBIOS. If it works, great. If something else works better, let's take that.

The only thing I really want to see is a target that does something useful. That's it :). A target that loads proprietary firmware halfway through is not valuable to users IMHO. A target that loads proprietary firmware and boots an OS is valuable. A target that doesn't need firmware and loads an OS is valuable. Maybe a target that doesn't boot an OS quite yet, but loads open source firmware pretty well is valuable too.


Alex

Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Andreas Färber]

Am 20.12.2010 um 13:30 schrieb Alexander Graf:

> On 20.12.2010, at 13:19, François Revol wrote:
>
>>>>> So we certainly do need some open source firmware solution for  
>>>>> prep to at least have Linux running. For other guests, I don't  
>>>>> see a reason why users shouldn't try to fetch a real firmware  
>>>>> blob separately :).
>>>>
>>>> We're not shipping any firmware for ppcemb either, so that  
>>>> argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones  
>>>> currently. Feel free to supply additional blobs for U-Boot etc.
>>>
>>> IIUC you don't need u-boot for the embedded targets. You just pass  
>>> in a kernel and the rest is magic.
>>
>> This holds only for Linux which imposes its own startup API to  
>> bootloaders and go with kernel drivers directly.
>>
>> Other OS like Haiku use a 2nd stage bootloader which assumes a  
>> working callable BIOS (OF on ppc), and getting it to run on U-Boot  
>> is already tricky on its own.
>
> That was my point :). I'm not aware of us supporting firmware on  
> ppcemb, so it's capable of running an OS all by itself already.

No, you rather mean: It's capable of running The OS so you don't care  
about proper firmware there.
By the same argument we could just load a Linux kernel directly on  
PReP and be good with it. Any pointers appreciated.

>>>>
>>>> Recent vanilla Linux kernels wouldn't run on PReP. So what Linux  
>>>> do you want to run using open source firmware?
>>>> I certainly do not intend to write firmware for the upcoming 40p  
>>>> machine. If Linux runs on real 40p hardware then it should run  
>>>> with real firmware under emulation, too. QEMU is an emulation  
>>>> project, not a Linux testing framework.
>>>
>>> I completely agree. Linux is usually easy because it's fully open  
>>> source and supports a lot of targets. If you feel like running  
>>> NetBSD or Haiku instead, feel free to do so.
>>
>> Thanks for thinking about Haiku ;)
>>
>> Btw there are other existing targets, like AROS, MorphOS, or  
>> AmigaOS which uses a modified U-Boot with a 'boota' command that  
>> passes their 2nd stage Parthenope bootloader a list of BIOS-like  
>> callbacks into U-Boot, cf. :
>> http://www.acube-systems.biz/index.php?page=hardware&pid=2
>> http://www.acube-systems.biz/download/u-boot-1.3.1c_20101206_prod.tar.gz
>>
>> Though they probably won't run on PReP, and PReP support in Haiku  
>> might come only for the sake of supporting the BeBox, which had its  
>> own dumb firmware (MAME seems to have some emulation support for  
>> BeBox).
>>
>> OTOH, I've been thinking about adding a Sam440 target, but it'd  
>> still require the custom U-Boot to start AmigaOS for example.
>
> I'd call U-Boot the firmware that we can ship with Qemu then because  
> it's open source :). I'm not advocate for openBIOS. If it works,  
> great. If something else works better, let's take that.
>
> The only thing I really want to see is a target that does something  
> useful. That's it :). A target that loads proprietary firmware  
> halfway through is not valuable to users IMHO. A target that loads  
> proprietary firmware and boots an OS is valuable. A target that  
> doesn't need firmware and loads an OS is valuable. Maybe a target  
> that doesn't boot an OS quite yet, but loads open source firmware  
> pretty well is valuable too.

Then we agree, a target that doesn't load any firmware or kernel is  
not really valuable.

If you look around then you'll find all kinds of starved QEMU  
branches, e.g., alpha es40, avr32 and z80. They're collecting virtual  
dust while QEMU grows things like qdev. That's why I'm trying to fix  
(note: fix) things in upstream, not create another fork to bitrot.

Andreas

Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Alexander Graf]

On 20.12.2010, at 23:24, Andreas Färber wrote:

> Am 20.12.2010 um 13:30 schrieb Alexander Graf:
> 
>> On 20.12.2010, at 13:19, François Revol wrote:
>> 
>>>>>> So we certainly do need some open source firmware solution for prep to at least have Linux running. For other guests, I don't see a reason why users shouldn't try to fetch a real firmware blob separately :).
>>>>> 
>>>>> We're not shipping any firmware for ppcemb either, so that argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to supply additional blobs for U-Boot etc.
>>>> 
>>>> IIUC you don't need u-boot for the embedded targets. You just pass in a kernel and the rest is magic.
>>> 
>>> This holds only for Linux which imposes its own startup API to bootloaders and go with kernel drivers directly.
>>> 
>>> Other OS like Haiku use a 2nd stage bootloader which assumes a working callable BIOS (OF on ppc), and getting it to run on U-Boot is already tricky on its own.
>> 
>> That was my point :). I'm not aware of us supporting firmware on ppcemb, so it's capable of running an OS all by itself already.
> 
> No, you rather mean: It's capable of running The OS so you don't care about proper firmware there.
> By the same argument we could just load a Linux kernel directly on PReP and be good with it. Any pointers appreciated.

if that works, yes. If instead loading netbsd or haiku is easier, go for those. Anything that actually runs is good :).

> 
>>>>> 
>>>>> Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want to run using open source firmware?
>>>>> I certainly do not intend to write firmware for the upcoming 40p machine. If Linux runs on real 40p hardware then it should run with real firmware under emulation, too. QEMU is an emulation project, not a Linux testing framework.
>>>> 
>>>> I completely agree. Linux is usually easy because it's fully open source and supports a lot of targets. If you feel like running NetBSD or Haiku instead, feel free to do so.
>>> 
>>> Thanks for thinking about Haiku ;)
>>> 
>>> Btw there are other existing targets, like AROS, MorphOS, or AmigaOS which uses a modified U-Boot with a 'boota' command that passes their 2nd stage Parthenope bootloader a list of BIOS-like callbacks into U-Boot, cf. :
>>> http://www.acube-systems.biz/index.php?page=hardware&pid=2
>>> http://www.acube-systems.biz/download/u-boot-1.3.1c_20101206_prod.tar.gz
>>> 
>>> Though they probably won't run on PReP, and PReP support in Haiku might come only for the sake of supporting the BeBox, which had its own dumb firmware (MAME seems to have some emulation support for BeBox).
>>> 
>>> OTOH, I've been thinking about adding a Sam440 target, but it'd still require the custom U-Boot to start AmigaOS for example.
>> 
>> I'd call U-Boot the firmware that we can ship with Qemu then because it's open source :). I'm not advocate for openBIOS. If it works, great. If something else works better, let's take that.
>> 
>> The only thing I really want to see is a target that does something useful. That's it :). A target that loads proprietary firmware halfway through is not valuable to users IMHO. A target that loads proprietary firmware and boots an OS is valuable. A target that doesn't need firmware and loads an OS is valuable. Maybe a target that doesn't boot an OS quite yet, but loads open source firmware pretty well is valuable too.
> 
> Then we agree, a target that doesn't load any firmware or kernel is not really valuable.
> 
> If you look around then you'll find all kinds of starved QEMU branches, e.g., alpha es40, avr32 and z80. They're collecting virtual dust while QEMU grows things like qdev. That's why I'm trying to fix (note: fix) things in upstream, not create another fork to bitrot.

And I very much appreciate that! In fact, I think we're thinking along the same line here. The only difference is that I'd like to see a full patch set in 2 weeks from now that makes prep do something useful, while you wouldn't mind getting those 2 early patches in upstream right now.

Either way, you have my full support on this. If you want to stop working on prep after those patches, let's merge them in now - it's an improvement either way. If instead you're keen on improving it, let's let them mature for a while while you continue to work on them. I'm sure you'll spot even more stuff and maybe even find out that you need to go a completely different route in the end :).

Whatever happens, I'm very happy to see you work on this!


Alex

Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Alexander Graf]

On 20.12.2010, at 23:24, Andreas Färber wrote:

> Am 20.12.2010 um 13:30 schrieb Alexander Graf:
> 
>> On 20.12.2010, at 13:19, François Revol wrote:
>> 
>>>>>> So we certainly do need some open source firmware solution for prep to at least have Linux running. For other guests, I don't see a reason why users shouldn't try to fetch a real firmware blob separately :).
>>>>> 
>>>>> We're not shipping any firmware for ppcemb either, so that argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to supply additional blobs for U-Boot etc.
>>>> 
>>>> IIUC you don't need u-boot for the embedded targets. You just pass in a kernel and the rest is magic.
>>> 
>>> This holds only for Linux which imposes its own startup API to bootloaders and go with kernel drivers directly.
>>> 
>>> Other OS like Haiku use a 2nd stage bootloader which assumes a working callable BIOS (OF on ppc), and getting it to run on U-Boot is already tricky on its own.
>> 
>> That was my point :). I'm not aware of us supporting firmware on ppcemb, so it's capable of running an OS all by itself already.
> 
> No, you rather mean: It's capable of running The OS so you don't care about proper firmware there.
> By the same argument we could just load a Linux kernel directly on PReP and be good with it. Any pointers appreciated.
> 
>>>>> 
>>>>> Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want to run using open source firmware?
>>>>> I certainly do not intend to write firmware for the upcoming 40p machine. If Linux runs on real 40p hardware then it should run with real firmware under emulation, too. QEMU is an emulation project, not a Linux testing framework.
>>>> 
>>>> I completely agree. Linux is usually easy because it's fully open source and supports a lot of targets. If you feel like running NetBSD or Haiku instead, feel free to do so.
>>> 
>>> Thanks for thinking about Haiku ;)
>>> 
>>> Btw there are other existing targets, like AROS, MorphOS, or AmigaOS which uses a modified U-Boot with a 'boota' command that passes their 2nd stage Parthenope bootloader a list of BIOS-like callbacks into U-Boot, cf. :
>>> http://www.acube-systems.biz/index.php?page=hardware&pid=2
>>> http://www.acube-systems.biz/download/u-boot-1.3.1c_20101206_prod.tar.gz
>>> 
>>> Though they probably won't run on PReP, and PReP support in Haiku might come only for the sake of supporting the BeBox, which had its own dumb firmware (MAME seems to have some emulation support for BeBox).
>>> 
>>> OTOH, I've been thinking about adding a Sam440 target, but it'd still require the custom U-Boot to start AmigaOS for example.
>> 
>> I'd call U-Boot the firmware that we can ship with Qemu then because it's open source :). I'm not advocate for openBIOS. If it works, great. If something else works better, let's take that.
>> 
>> The only thing I really want to see is a target that does something useful. That's it :). A target that loads proprietary firmware halfway through is not valuable to users IMHO. A target that loads proprietary firmware and boots an OS is valuable. A target that doesn't need firmware and loads an OS is valuable. Maybe a target that doesn't boot an OS quite yet, but loads open source firmware pretty well is valuable too.
> 
> Then we agree, a target that doesn't load any firmware or kernel is not really valuable.
> 
> If you look around then you'll find all kinds of starved QEMU branches, e.g., alpha es40, avr32 and z80. They're collecting virtual dust while QEMU grows things like qdev. That's why I'm trying to fix (note: fix) things in upstream, not create another fork to bitrot.

Also on the other forks. I'm not sure what happened with the Alpha port, but for AVR32 and z80 I have not seen any upstream submissions since I joined qemu. I know that the AVR32 people were eager in learning things, but I haven't seen any code submitted upstream.

I don't believe this is what will happen with you. You're well aware of how open source works and will hopefully pester at least me - preferably others too - until stuff gets in :).


Alex