> On Jul 30, 2017, at 11:25 AM, Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> wrote:
>
> On 28/07/17 02:27, Programmingkid wrote:
>
>>> On Jul 27, 2017, at 12:36 PM, Răzvan Corneliu C.R. VILT <razvan.vilt(a)gmail.com> wrote:
>>>
>>> Andrei Warkentin managed to get as far as booting veneer.exe but it crashes at the NT Kernel using his prephv build (https://github.com/andreiw/prephv/).
>>>
>>> OpenBIOS cannot load PE Images and I believe that even if PE loading was added to it, it wouldn't help since you also have some special >> requirements for little endian booting and some for the load-base.
>
> I'd be very interested to discuss some of this over on the OpenBIOS
> mailing list - writing a PE driver should be fairly simple these days.
>
>>> Veneer.exe is basically an emulator for the ARC Firmware needed by the NT OSLoader.exe on top of the openfirmware environment.
>>>
>>> About one year ago I did some digging into this documented on Artyom's blog.
>>> http://tyom.blogspot.ro/2014/09/open-firmware-for-qemu-system-ppc-m-prep.ht…
>>>
>>> If you want, you can write a minimal MZ-PE Loader in Forth and we'll take it from there.
>
> All of the other OpenBIOS loaders are written in C, so I don't see why
> the same couldn't be done for MZ-PE, especially as most people find that
> considerably easier than Forth.
>
>
> ATB,
>
> Mark.
Hi Mark. I was just thinking about asking you about this. It would be fun to make Windows NT 4.0 PowerPC work in QEMU. For anyone who is interested I found this page on the PE format. It might be helpful: https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).…
Hello,
Is there a way to add a new device in the middle of the device tree
(before or after an existing node) from Forth? If I try:
dev / new-device " newdev" device-name finish-device show-devs
/newdev appears at the end of the device-tree but that's not what I want.
I need this device to go at a specific place in the middle but I could not
find out how to achieve that. Any ideas?
Thank you,
BALATON Zoltan
This is the final set of changes required to switch SPARC64 over to use the QEMU
machine configuration with Simba bridges. Note that this is currently pending
approval of pre-requisite patches for the corresponding sun4u patchset.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Mark Cave-Ayland (2):
SPARC64: switch to simba PCI bridge machine configuration
pci: set cmd646 name and device_type properties to "ide"
arch/sparc64/openbios.c | 2 +-
drivers/pci.c | 22 ++++++++++++++--------
drivers/pci_database.c | 2 +-
3 files changed, 16 insertions(+), 10 deletions(-)
--
1.7.10.4
This patchset prepares the way for changing the QEMU sun4u machine to be much
closer to a real Ultra 5.
The main change we are aiming for is to replicate the PCI bus topology so that
onboard devices are attached behind simba A and simba B is an empty PCI bus
(although devices can be added via QEMU's -device syntax).
Note that this patch does all of the preparation work but doesn't actually
implement the changes required by the switch. This is because the QEMU patches
are still awaiting upstream approval and change to the sun4u machine must
be synchronised between QEMU and OpenBIOS.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Mark Cave-Ayland (13):
SPARC64: increase size of PCI memory space
SPARC64: increase size of PCI IO space
SPARC64: fix PCI memory base in host ranges
SPARC64: fix PCI configuration space size
SPARC64: implement custom PCI bus scan for sabre
SPARC64: add custom sabre reg property to sabre_config_cb()
pci: implement simba_config_cb() for programming device ranges
pci: update interrupt-map-mask to include the bus during interrupt
comparisons
pci: don't set interrupt-map and interrupt-map-mask properties if
empty
pci: rename SUN4U_INTERRUPT to SUN4U_PCIAINTERRUPT
pci: alter ob_configure_pci_device() to return its device phandle
pci: use ob_pci_bus_set_interrupt_map() to configure interrupts for
Simba PCI bus B
pci: map Simba PCI bus A on-board devices to fixed interrupts
arch/sparc64/openbios.c | 12 ++--
drivers/pci.c | 175 ++++++++++++++++++++++++++++++++++++++++++-----
drivers/pci_database.c | 2 +-
drivers/pci_database.h | 1 +
4 files changed, 167 insertions(+), 23 deletions(-)
--
1.7.10.4
Whilst debugging some SPARC64 issues relating to PCI bridges, it became apparent
that the logic for generating the ranges property for the PCI host bridge isn't
flexible enough to allow generation of the correct values across all architectures.
In order to allow per-architecture customisation of PCI host bridge properties, split
them out into a separate struct within pci_arch_t and migrate all PCI architectures
over to use them. As a side effect we can now remove the rbase and rlen members from
pci_arch_t since they are no longer required.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Mark Cave-Ayland (5):
pci: define pci_range_t typedef and add it to pci_arch_t struct
pci: move memory type enum from drivers/pci.c to
include/drivers/pci.h
arch: update pci_host_t host_ranges with values for each architecture
pci: update pci_set_host_ranges() to use the new pci_arch_t
host_ranges
arch: remove rbase and rlen from pci_arch_t for all PCI architectures
arch/ppc/qemu/init.c | 29 +++++++++++++++++-------
arch/sparc64/openbios.c | 6 +++++
arch/x86/openbios.c | 4 ++++
drivers/pci.c | 56 ++++++++++++++---------------------------------
include/drivers/pci.h | 19 ++++++++++++++--
5 files changed, 64 insertions(+), 50 deletions(-)
--
1.7.10.4
Compared with real SPARC/PReP device trees, an 8042 controller should be modelled as a
separate device with keyboard (and optionally mouse) devices beneath it.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Mark Cave-Ayland (2):
pc_kbd: place keyboard device under 8042 controller device
pc_kbd: add optional mouse device support for 8042 devices
drivers/pc_kbd.c | 112 ++++++++++++++++++++++++++++++++++++++-------
drivers/pci.c | 4 +-
include/drivers/drivers.h | 4 +-
3 files changed, 100 insertions(+), 20 deletions(-)
--
1.7.10.4
This is a small set of fixes that came out of my current queue of
SPARC64 patches.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Mark Cave-Ayland (3):
vga.fs: do not attempt to map MMIO registers more than once
pci: always use devfn 0 for PCI host bridge ranges
SPARC64: fix up PCI-EBus interrupt map and ino for PS/2 keyboard
device
drivers/pci.c | 21 +++++++++++++++------
drivers/vga.fs | 4 +++-
2 files changed, 18 insertions(+), 7 deletions(-)
--
1.7.10.4
Commit c80a58b added a workaround to allow ioport access through the first PCI
bridge found until its base and limits were programmed, so that on-board devices
not directly attached to the PCI host bus could be used during OpenBIOS
initialisation.
Unfortunately the logic was broken, and in fact the reset should only occur if
we're the first PCI bridge that isn't the host bridge - otherwise we end up
resetting io_base for the PCI host bus causing its devices to be mapped over
existing in-built ioports causing strange behaviour.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
---
drivers/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci.c b/drivers/pci.c
index db92683..92938a4 100644
--- a/drivers/pci.c
+++ b/drivers/pci.c
@@ -1426,7 +1426,7 @@ static void ob_configure_pci_bridge(pci_addr addr,
/* Always expose the legacy ioports on the first PCI bridge. If we
must have legacy devices behind a PCI bridge then they must be
on the first one discovered to ensure that the ioports will work. */
- if (*io_base < 0x1000) {
+ if (primary_bus > 0 && *io_base < 0x1000) {
*io_base = 0x0;
}
--
1.7.10.4