OpenBIOS October 2021

openbios@openbios.org

4 participants
6 discussions

[PATCH v8] arch/ppc/qemu: Add a node for the empty first PCI bus to the device tree
by BALATON Zoltan 20 Nov '21

20 Nov '21

QEMU mac99 emulates two of the three PCI buses found on real PowerMac3,1 but OpenBIOS currently only handles a single PCI bus and inits and puts info in the device tree of the second PCI bus only (which is where devices are connected). However, some clients (e.g. MorphOS) may have hardcoded assumptions and erroneously use the address of the first bus to access PCI config registers for devices on the second bus if the first bus is missing from the device tree, which silently fails as these requests will go to the other empty bus emulated and return invalid values as the device they address are not present there. As a result devices mapped via MMIO still appear to work but they may not be correctly initialised and some cards are not detected because of this. One such case might be enabling bus master bit for network cards which the OS should do but OpenBIOS has workaround for it now. Once both PCI buses appear in device tree those workarounds may not be needed any more. Until proper support for multiple PCI buses is implemented add an empty node in the device tree for the first bus on QEMU mac99 to let OSes know about it. This fixes detecting PCI devices (such as USB) under MorphOS and allows it to boot. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- arch/ppc/qemu/init.c | 55 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 45cd77e..b1c2197 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -716,6 +716,59 @@ static void kvm_of_init(void) fword("finish-device"); } +static void encode_int_plus(int n, ...) +{ + int i; + ucell v; + va_list ap; + + va_start(ap, n); + for (i = 0; i < n; i++) { + v = va_arg(ap, ucell); + PUSH(v); + fword("encode-int"); + if (i > 0) { + fword("encode+"); + } + } + va_end(ap); +} + +static void empty_pci_bus_init(void) +{ + if (machine_id == ARCH_MAC99) { + fword("new-device"); + push_str("pci"); + fword("device-name"); + push_str("pci"); + fword("device-type"); + encode_int_plus(2, 0xf0000000, 0x02000000); + push_str("reg"); + fword("property"); + PUSH(3); + fword("encode-int"); + push_str("#address-cells"); + fword("property"); + PUSH(2); + fword("encode-int"); + push_str("#size-cells"); + fword("property"); + PUSH(1); + fword("encode-int"); + push_str("#interrupt-cells"); + fword("property"); + encode_int_plus(12, + 0x01000000, 0, 0, 0xf0000000, 0, 0x00800000, + 0x02000000, 0, 0x90000000, 0x90000000, 0, 0x10000000); + push_str("ranges"); + fword("property"); + encode_int_plus(2, 0, 0); + push_str("bus-range"); + fword("property"); + fword("finish-device"); + } +} + /* * filll ( addr bytes quad -- ) */ @@ -868,6 +921,8 @@ arch_of_init(void) case ARCH_MAC99_U3: /* The NewWorld NVRAM is not located in the MacIO device */ macio_nvram_init("/", 0); + /* We only handle 1 PCI bus but MorphOS needs info for both to boot */ + empty_pci_bus_init(); ob_pci_init(); ob_unin_init(); break; -- 2.21.4

3 24

[PATCH] cuda: fix reset-all and power-off words
by Mark Cave-Ayland 30 Oct '21

30 Oct '21

There is a long-standing bug in the CUDA implementation of the reset-all and power-off words whereby an extra byte is written after the CUDA_RESET_SYSTEM and CUDA_POWERDOWN commands. This extra byte used to be ignored in QEMU until commits 017da0b568 ("cuda: port POWERDOWN command to new framework") and 54e894442e ("cuda: port RESET_SYSTEM command to new framework") added a check which rejects the command if the command length is incorrect. Fix the outgoing command length to remove the extra byte which allows the reset-all and power-off words to work in QEMU once again. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Fixes: https://gitlab.com/qemu-project/qemu/-/issues/624 --- drivers/cuda.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/cuda.c b/drivers/cuda.c index 56d73e1..c89b174 100644 --- a/drivers/cuda.c +++ b/drivers/cuda.c @@ -177,7 +177,7 @@ static cuda_t *main_cuda; static void ppc32_reset_all(void) { - uint8_t cmdbuf[2], obuf[64]; + uint8_t cmdbuf[1], obuf[64]; cmdbuf[0] = CUDA_RESET_SYSTEM; cuda_request(main_cuda, CUDA_PACKET, cmdbuf, sizeof(cmdbuf), obuf); @@ -186,7 +186,7 @@ ppc32_reset_all(void) static void ppc32_poweroff(void) { - uint8_t cmdbuf[2], obuf[64]; + uint8_t cmdbuf[1], obuf[64]; cmdbuf[0] = CUDA_POWERDOWN; cuda_request(main_cuda, CUDA_PACKET, cmdbuf, sizeof(cmdbuf), obuf); -- 2.20.1

2 2

[PATCH 0/2] escc: reset fixes for sun keyboard/mouse
by Mark Cave-Ayland 30 Oct '21

30 Oct '21

The sun4m machine uses 2 ESCC devices: one for use as normal serial ports and another for use with a Sun keyboard/mouse. The previous ESCC fixes added new code to send the ESCC soft reset sequence for the normal serial ports but failed to do so for the keyboard/mouse serial ports. This worked fine for OpenBIOS and all of my SPARC32 test images except for my OpenBSD test image which hangs on boot: whilst the OS sends the reset sequence to the normal serial port, it tries to access the Sun keyboard/mouse serial ports without sending the reset sequence first causing it to get stuck in a polling loop waiting for the status register bits to be set correctly. This patchset updates the kbd_init() function which initialises the ESCC used by the Sun keyboard/mouse so that it now sends the ESCC soft reset sequence to both ports. This ensures that the status register bits are set to their expected reset defaults which allows OpenBSD SPARC32 to boot successfully once again. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (2): escc: add speed parameter to kbd_init() for sun keyboard/mouse serial ports escc: initialise sun keyboard/mouse serial ports in kbd_init() arch/sparc32/openbios.c | 2 +- drivers/escc.c | 4 +++- include/drivers/drivers.h | 2 +- 3 files changed, 5 insertions(+), 3 deletions(-) -- 2.20.1

1 3

[PATCH] arch/ppc/qemu: Add a dummy device tree node for the first PCI bus
by BALATON Zoltan 24 Oct '21

24 Oct '21

Real PowerMac3,1 has two PCI and one AGP buses that are emulated in QEMU but OpenBIOS currently only handles a single PCI bus and inits and puts info in the device tree of the second PCI bus only (which is where devices are connected). MorphOS is confused by this and erroneously uses the address of the first bus to access PCI config registers for devices on the second bus if the first pci node is missing from the device tree, This results in either not booting at all or devices mapped via MMIO may still appear to work but they may not be correctly initialised and some cards are not detected because of this. However, adding the other /pci node causes problems with other guests such as NetBSD. Fortunately MorphOS is happy as long as any node of pci device-type comes before the actual /pci entry. Until proper support for multiple PCI buses is implemented, add such a dummy node in the device tree for QEMU mac99 to avoid this problem which fixes detecting PCI devices (such as USB) under MorphOS and allows it to boot. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- arch/ppc/qemu/init.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 45cd77e..ef8b27a 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -865,6 +865,16 @@ arch_of_init(void) switch (machine_id) { case ARCH_MAC99: + /* This adds a dummy node of pci device-type before the actual /pci + * node which is needed for MorphOS to find devices on PCI bus. + * (Real machine has 3 /pci nodes but we only have one.) */ + fword("new-device"); + push_str("dummy-pci"); + fword("device-name"); + push_str("pci"); + fword("device-type"); + fword("finish-device"); + /* fall through */ case ARCH_MAC99_U3: /* The NewWorld NVRAM is not located in the MacIO device */ macio_nvram_init("/", 0); -- 2.21.4

1 0

[PATCH v7] arch/ppc/qemu: Add a node for the empty first PCI bus to the device tree
by BALATON Zoltan 23 Oct '21

23 Oct '21

QEMU mac99 emulates two of the three PCI buses found on real PowerMac3,1 but OpenBIOS currently only handles a single PCI bus and inits and puts info in the device tree of the second PCI bus only (which is where devices are connected). However, some clients (e.g. MorphOS) may have hardcoded assumptions and erroneously use the address of the first bus to access PCI config registers for devices on the second bus if the first bus is missing from the device tree, which silently fails as these requests will go to the other empty bus emulated and return invalid values as the device they address are not present there. As a result devices mapped via MMIO still appear to work but they may not be correctly initialised and some cards are not detected because of this. One such case might be enabling bus master bit for network cards which the OS should do but OpenBIOS has workaround for it now. Once both PCI buses appear in device tree those workarounds may not be needed any more. Until proper support for multiple PCI buses is implemented add an empty node in the device tree for the first bus on QEMU mac99 to let OSes know about it. This fixes detecting PCI devices (such as USB) under MorphOS and allows it to boot. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- arch/ppc/qemu/init.c | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 45cd77e..5e3959e 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -716,6 +716,44 @@ static void kvm_of_init(void) fword("finish-device"); } +static void empty_pci_bus_init(void) +{ + if (machine_id == ARCH_MAC99) { + fword("new-device"); + push_str("pci"); + fword("device-name"); + push_str("pci"); + fword("device-type"); + PUSH(0xf0000000); + fword("encode-int"); + PUSH(0x02000000); + fword("encode-int"); + fword("encode+"); + push_str("reg"); + fword("property"); + PUSH(3); + fword("encode-int"); + push_str("#address-cells"); + fword("property"); + PUSH(2); + fword("encode-int"); + push_str("#size-cells"); + fword("property"); + PUSH(1); + fword("encode-int"); + push_str("#interrupt-cells"); + fword("property"); + PUSH(0); + fword("encode-int"); + PUSH(0); + fword("encode-int"); + fword("encode+"); + push_str("bus-range"); + fword("property"); + fword("finish-device"); + } +} + /* * filll ( addr bytes quad -- ) */ @@ -868,6 +906,8 @@ arch_of_init(void) case ARCH_MAC99_U3: /* The NewWorld NVRAM is not located in the MacIO device */ macio_nvram_init("/", 0); + /* We only handle 1 PCI bus but MorphOS needs info for both to boot */ + empty_pci_bus_init(); ob_pci_init(); ob_unin_init(); break; -- 2.21.4

2 11

Installing OpenBIOS
by bernd1-1＠web.de 23 Oct '21

23 Oct '21

Hi. I've watched a television broadcast where a hacker or security expert suspected that the BIOS of ThinkPads has a backdoor and therefore he installed OpenBIOS. I read https://www.openfirmware.info/OpenBIOS. 1. Please tell me whether a user without knowledge in programming or Linux command lines in Terminal is able to install OpenBIOS. 2. Would you provide step by step instructions (especially for my case) how to install OpenBIOS on my system? Regards,

2 1