OpenBIOS

openbios@openbios.org

4289 discussions

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

[PATCH 0/2] escc: add missing port reset
by Mark Cave-Ayland 08 Sep '21

08 Sep '21

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 3

Move to github workflow?
by Mark Cave-Ayland 19 Aug '21

19 Aug '21

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.

4 5

[PATCH v3] pci: Rename pci_xbox_blacklisted() as pci_xbox_ignore_device()
by Philippe Mathieu-Daudé 16 Feb '21

16 Feb '21

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

3 8

[PATCH v2] pci: Rename pci_xbox_blacklisted() as pci_xbox_skip_device()
by Philippe Mathieu-Daudé 11 Feb '21

11 Feb '21

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

2 2

[PATCH] pci: Rename pci_xbox_blacklisted() as pci_xbox_denylisted()
by Philippe Mathieu-Daudé 07 Feb '21

07 Feb '21

In order to use inclusive terminology, rename pci_xbox_blacklisted() as pci_xbox_denylisted(). Signed-off-by: Philippe Mathieu-Daudé <philmd(a)redhat.com> --- drivers/pci.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/pci.c b/drivers/pci.c index 34ae69a..19b9027 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_denylisted (int bus, int devnum, int fn) { /* * The Xbox MCPX chipset is a derivative of the nForce 1 @@ -1388,7 +1388,7 @@ static char pci_xbox_blacklisted (int bus, int devnum, int fn) return 1; /* - * The device is not blacklisted. + * The device is not denylisted. */ return 0; } @@ -1708,7 +1708,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_denylisted (bus, devnum, fn)) return; #endif addr = PCI_ADDR(bus, devnum, fn); -- 2.26.2

3 2

[PATCH 0/3] 40p: Match QEMU Raven IRQ swizzling change
by Philippe Mathieu-Daudé 07 Feb '21

07 Feb '21

As requested by Mark on qemu-devel list, update OpenBIOS to be consistent with QEMU change: https://lists.gnu.org/archive/html/qemu-devel/2020-10/msg03079.html Philippe Mathieu-Daudé (3): 40p: Allow Raven controller to handle all IRQs 40p: use is_apple() macro 40p: simplify IRQ swizzling drivers/pci.c | 27 +++++++-------------------- 1 file changed, 7 insertions(+), 20 deletions(-) -- 2.26.2

3 6

[PATCH] PPC: mark first 4 pages of physical and virtual memory as unavailable
by Mark Cave-Ayland 25 Jul '20

25 Jul '20

The Debian ports images have now switched from using yaboot to grub as their bootloader. Recent versions of these images will hang rather than boot under QEMU despite there being no obvious changes to the boot process. Further investigation reveals that the second stage grub bootloader appears to use low memory whilst loading the kernel/initrd from disk: unfortunately the OpenBIOS vector table lives within the first few pages of physical RAM and so grub writes over the vector table (in particular overwriting the MMU fault handlers) causing them to fail next time they are executed which causes the hang. Fortunately just before this stage of the bootloader executes, it uses the CIF to request the contents of the /memory node "available" property. It seems that the low memory locations used by grub are taken from the start of the available range, so we can simply increase the number of RAM pages reserved at the bottom of RAM to ensure that the area chosen by the bootloader doesn't conflict with the vector table. This patch raises the start of available memory from 0x1000 to 0x4000 which allows grub to boot successfully in my tests. According to dumps of device trees taken from real PPC Macs there are already several examples where the start of available memory is set to 0x3000 or 0x4000, so as this is already present on real hardware it should not cause any regressions. Finally it is worth noting that even in the earlier grub images I could see write accesses to low memory that would overwrite the vector table: I think that until recently we were lucky that they happened to avoid anything that was critical to allow the kernel to load and boot. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- arch/ppc/qemu/ofmem.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/ppc/qemu/ofmem.c b/arch/ppc/qemu/ofmem.c index 7a78a1e..4ff0803 100644 --- a/arch/ppc/qemu/ofmem.c +++ b/arch/ppc/qemu/ofmem.c @@ -571,9 +571,9 @@ ofmem_init(void) { ofmem_t *ofmem = ofmem_arch_get_private(); - /* Mark the first page as non-free */ - ofmem_claim_phys(0, PAGE_SIZE, 0); - ofmem_claim_virt(0, PAGE_SIZE, 0); + /* Mark the first 4 pages as non-free */ + ofmem_claim_phys(0, 4 * PAGE_SIZE, 0); + ofmem_claim_virt(0, 4 * PAGE_SIZE, 0); /* Map everything at the top of physical RAM 1:1, minus the OpenBIOS ROM in RAM copy */ ofmem_claim_phys(get_ram_top(), get_hash_base() + HASH_SIZE - get_ram_top(), 0); -- 2.20.1

1 0

[PATCH] SPARC: add implementation of addr word
by Mark Cave-Ayland 07 Jul '20

07 Jul '20

OpenBSD uses the addr word to retrieve the address of several framebuffer variables during initialisation. Provide an implementation of addr which allows OpenBSD to initialise the framebuffer correctly on SPARC32 and SPARC64. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- forth/util/util.fs | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/forth/util/util.fs b/forth/util/util.fs index 8247c7d..54dbf91 100644 --- a/forth/util/util.fs +++ b/forth/util/util.fs @@ -102,3 +102,18 @@ 2dup " tell" is-relay 2drop ; + +\ ------------------------------------------------------------------------- +\ Miscellaneous +\ ------------------------------------------------------------------------- + +[IFDEF] CONFIG_SPARC32 1 [ELSE] [IFDEF] CONFIG_SPARC64 1 [ELSE] 0 [THEN] [THEN] [IF] + +\ Return the address of a named constant or value +: addr ( <word> -- addr ) + parse-word $find if + cell + + then +; + +[THEN] -- 2.20.1

3 5

[PATCH] virtio: limit ring size to a maximum of 128 descriptor entries
by Mark Cave-Ayland 21 May '20

21 May '20

QEMU commit c9b7d9ec21 "virtio: increase virtqueue size for virtio-scsi and virtio-blk" increased the number of queue descriptors from 128 to 256 which caused OpenBIOS to fail when booting from a virtio-blk device under qemu-system-ppc due to a memory overflow. Update the virtio-blk driver so that it uses a maximum of 128 descriptor entries (the previous value) to fix the issue, and also ensure that any further increases in virtqueue size will not cause the same failure. Note that this commit also fixes the vring_area size calculation which was incorrectly based upon the number of virtqueues, and not the number of descriptor entries. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- drivers/virtio.c | 7 ++++++- drivers/virtio.h | 5 +++-- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/virtio.c b/drivers/virtio.c index ff7ed6f..7808d94 100644 --- a/drivers/virtio.c +++ b/drivers/virtio.c @@ -303,7 +303,12 @@ ob_virtio_configure_device(VDev *vdev) }; virtio_cfg_write16(vdev->common_cfg, VIRTIO_PCI_COMMON_Q_SELECT, i); + info.num = virtio_cfg_read16(vdev->common_cfg, VIRTIO_PCI_COMMON_Q_SIZE); + if (info.num > VIRTIO_MAX_RING_ENTRIES) { + info.num = VIRTIO_MAX_RING_ENTRIES; + virtio_cfg_write16(vdev->common_cfg, VIRTIO_PCI_COMMON_Q_SIZE, info.num); + } vring_init(&vdev->vrings[i], &info); @@ -503,7 +508,7 @@ void ob_virtio_init(const char *path, const char *dev_name, uint64_t common_cfg, addr = POP(); vdev->vrings = cell2pointer(addr); - PUSH(VIRTIO_RING_SIZE * VIRTIO_MAX_VQS); + PUSH((VIRTIO_RING_SIZE * 2 + VIRTIO_PCI_VRING_ALIGN) * VIRTIO_MAX_VQS); feval("dma-alloc"); addr = POP(); vdev->ring_area = cell2pointer(addr); diff --git a/drivers/virtio.h b/drivers/virtio.h index 64b49e7..36cb205 100644 --- a/drivers/virtio.h +++ b/drivers/virtio.h @@ -147,8 +147,9 @@ struct VirtioDev { }; typedef struct VirtioDev VirtioDev; -#define VIRTIO_RING_SIZE (PAGE_SIZE * 8) -#define VIRTIO_MAX_VQS 3 +#define VIRTIO_MAX_RING_ENTRIES 128 +#define VIRTIO_RING_SIZE (sizeof(VRingDesc) * VIRTIO_MAX_RING_ENTRIES) +#define VIRTIO_MAX_VQS 1 #define KVM_S390_VIRTIO_RING_ALIGN 4096 #define VRING_USED_F_NO_NOTIFY 1 -- 2.20.1

1 1

← Newer
1
2
3
4
5
6
7
8
9
...
429
Older →

Jump to page: