OpenBIOS

openbios@openbios.org

4297 discussions

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

[PATCH] pci: Enable bus-master on virtio_blk
by bdragon＠FreeBSD.org 16 May '20

16 May '20

From: Brandon Bergren <git(a)bdragon.rtk0.net> In qemu 9d7bd0826f2d19f88631ad7078662668148f7b5f, the behavior of vring processing was changed to not run whenever bus-mastering is disabled. Since we were never enabling it in the first place, OpenBIOS was no longer able to access virtio disks on qemu. Fix this by enabling bus-mastering before initializing. Signed-off-by: Brandon Bergren <git(a)bdragon.rtk0.net> --- drivers/pci.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci.c b/drivers/pci.c index 9d501d3..34ae69a 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -816,6 +816,9 @@ int virtio_blk_config_cb(const pci_config_t *config) return 0; } + /* Enable bus mastering to ensure vring processing will run. */ + ob_pci_enable_bus_master(config); + ob_virtio_init(config->path, "virtio-blk", common_cfg, device_cfg, notify_base, notify_mult, idx); #endif -- 2.25.1

2 1

[PATCH v2 0/2] SPARC64/SPARC32 fix kernel and initrd mapping
by Mark Cave-Ayland 04 May '20

04 May '20

Unfortunately it looks as if my original fix for this was wrong, and in particular causes one of the SPARC64 QEMU advent calendar images which uses a preloaded kernel to panic on boot. The SILO memory allocators search through the physical memory "available" property but then don't actually allocate the result: instead hardcoded virtual addresses are only mapped to the physical addresses that are determined to be free. These patches remove the physical and virtual allocations introduced as part of the original fix and map these memory areas in exactly the same way that SILO does. This also solves the issue the original patches were trying to fix, which was that clients could still claim the memory in-use by the kernel via the CIF - the virtual addresses used by SILO are higher up in memory, making a clash extremely unlikely (and indeed, if it did happen, would mean the kernel/initrd combination would also fail to boot under SILO). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> v2: - Fix typo and cut/paste error patch 2 Mark Cave-Ayland (2): SPARC64: fix kernel and initrd mapping to match SILO SPARC32: fix kernel and initrd mapping to match SILO arch/sparc32/boot.h | 3 +++ arch/sparc32/openbios.c | 31 ++++++++++++++++--------------- arch/sparc64/boot.c | 2 +- arch/sparc64/boot.h | 3 +++ arch/sparc64/openbios.c | 16 +++++++--------- 5 files changed, 30 insertions(+), 25 deletions(-) -- 2.20.1

1 3

← Newer
1
...
4
5
6
7
8
9
10
...
430
Older →

Jump to page: