OpenBIOS

openbios@openbios.org

4 participants
4244 discussions

[PATCH 0/2] escc: reset fixes for sun keyboard/mouse

by Mark Cave-Ayland

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

23 hours, 32 minutes

[PATCH v8] arch/ppc/qemu: Add a node for the empty first PCI bus to the device tree

by BALATON Zoltan

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

2 days, 9 hours

[PATCH] arch/ppc/qemu: Add a dummy device tree node for the first PCI bus

by BALATON Zoltan

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

3 days, 22 hours

[PATCH v7] arch/ppc/qemu: Add a node for the empty first PCI bus to the device tree

by BALATON Zoltan

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

5 days, 4 hours

Installing OpenBIOS

by bernd1-1＠web.de

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,

5 days, 6 hours

[PATCH] cuda: fix reset-all and power-off words

by Mark Cave-Ayland

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 weeks, 5 days

[PATCH 0/2] escc: add missing port reset

by Mark Cave-Ayland

An upcoming change to QEMU's ESCC device reset mechanism exposed a bug that OpenBIOS's ESCC driver doesn't actually reset the port before attempting to configure it. Whilst this has no effect for now, once the QEMU ESCC changes have been merged (which implement the reset as documented in the datasheet), this port reset must be sent so that the registers are set to their default values after power-on. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (2): escc: add port index to uart_init_line() escc: send software reset command before configuring the port drivers/escc.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) -- 2.20.1

1 month, 2 weeks

Move to github workflow?

by Mark Cave-Ayland

Hi all, Since the coreboot team moved the OpenBIOS project onto Github, there have been a number of steadily increasing pull requests and issues raised there and so I'm wondering if now is the time to start thinking about moving to a more Github-based workflow. The nice thing about Github is that we can start to put together some CI to allow build testing of PRs and open potential review to people outside of the OpenBIOS mailing list. However there are a number of very knowledgeable people on this mailing list who have helped with the project over the years and I am really keen to maintain the benefit of their expertise. On this basis I would like to propose the following changes: 1) Move to a merge request workflow and start accepting PRs from Github 2) Add the openbios(a)openbios.org mailing list automatically to Github PRs and Issues so people on the mailing can take part in the discussions. Note: this is currently VERY low volume. 3) Implement a basic Github workflow using the QEMU project cross-compiler docker images to enable build testing and artifact generation without requiring a cross-compiler to be built manually. (I've already tried a few experiments and made some progress here). Any further thoughts/ideas/suggestions? ATB, Mark.

2 months, 1 week

[PATCH v3] pci: Rename pci_xbox_blacklisted() as pci_xbox_ignore_device()

by Philippe Mathieu-Daudé

In order to use inclusive terminology, rename pci_xbox_blacklisted() as pci_xbox_ignore_device(), and remove an obvious comment. Suggested-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd(a)redhat.com> --- drivers/pci.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/pci.c b/drivers/pci.c index 34ae69a..0e12dc7 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1356,7 +1356,7 @@ static void ob_pci_add_properties(phandle_t phandle, } #ifdef CONFIG_XBOX -static char pci_xbox_blacklisted (int bus, int devnum, int fn) +static char pci_xbox_ignore_device (int bus, int devnum, int fn) { /* * The Xbox MCPX chipset is a derivative of the nForce 1 @@ -1387,9 +1387,6 @@ static char pci_xbox_blacklisted (int bus, int devnum, int fn) if (bus >= 2) return 1; - /* - * The device is not blacklisted. - */ return 0; } #endif @@ -1708,7 +1705,7 @@ static int ob_pci_read_identification(int bus, int devnum, int fn, pci_addr addr; #ifdef CONFIG_XBOX - if (pci_xbox_blacklisted (bus, devnum, fn)) + if (pci_xbox_ignore_device (bus, devnum, fn)) return; #endif addr = PCI_ADDR(bus, devnum, fn); -- 2.26.2

8 months, 2 weeks

[PATCH v2] pci: Rename pci_xbox_blacklisted() as pci_xbox_skip_device()

by Philippe Mathieu-Daudé

In order to use inclusive terminology, rename pci_xbox_blacklisted() as pci_xbox_skip_device(), and remove an obvious comment. Suggested-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd(a)redhat.com> --- drivers/pci.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/pci.c b/drivers/pci.c index 34ae69a..461e0fe 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1356,7 +1356,7 @@ static void ob_pci_add_properties(phandle_t phandle, } #ifdef CONFIG_XBOX -static char pci_xbox_blacklisted (int bus, int devnum, int fn) +static char pci_xbox_skip_device (int bus, int devnum, int fn) { /* * The Xbox MCPX chipset is a derivative of the nForce 1 @@ -1387,9 +1387,6 @@ static char pci_xbox_blacklisted (int bus, int devnum, int fn) if (bus >= 2) return 1; - /* - * The device is not blacklisted. - */ return 0; } #endif @@ -1708,7 +1705,7 @@ static int ob_pci_read_identification(int bus, int devnum, int fn, pci_addr addr; #ifdef CONFIG_XBOX - if (pci_xbox_blacklisted (bus, devnum, fn)) + if (pci_xbox_skip_device (bus, devnum, fn)) return; #endif addr = PCI_ADDR(bus, devnum, fn); -- 2.26.2

8 months, 2 weeks

Jump to page: