OpenBIOS

openbios@openbios.org

4289 discussions

[PATCH] libopenbios: fix build for platforms without fw_cfg interface
by Mark Cave-Ayland 18 Jun '17

18 Jun '17

Commit 7130437 "fw_cfg: implement fw-cfg-read-file Forth word" added a binding for the Forth version of fw_cfg_read_file() into libopenbios/init.c but forgot to only include the binding when CONFIG_DRIVER_FW_CFG was defined. This broke the build for platforms which don't have the fw_cfg interface enabled by default such as x86. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- libopenbios/init.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libopenbios/init.c b/libopenbios/init.c index aa99608..e08df19 100644 --- a/libopenbios/init.c +++ b/libopenbios/init.c @@ -28,8 +28,10 @@ openbios_init( void ) PUSH(pointer2cell((void *)&__context)); feval("['] __context cell+ !"); +#if defined(CONFIG_DRIVER_FW_CFG) // Bind the Forth fw_cfg file interface bind_func("fw-cfg-read-file", forth_fw_cfg_read_file); +#endif // Bind the C implementation of (init-program) into Forth bind_func("(init-program)", init_program); -- 1.7.10.4

1 1

Curious as to current status
by Jonathan C Day 10 Jun '17

10 Jun '17

Hi, The git repository seems alive, so there's someone out there, but the main website hasn't been updated in a while and the list is... quiet. I'm looking to find out where OpenBIOS is, if it handles large devices (or if I need TianoCore for that, which I'd really not like) and whether the project is still in serious development (good) or is more maintenance mode (proprietary vendors have won). I'm also curious as to what will boot cleanly. Coreboot only seems to give results for direct payloads and SeaBIOS, and I don't see a list on OpenBIOS' site (but may have missed it), so it's not obvious what works well, what's YMMV and what's in the paperweight category. If things are semi-active to active, and if I can find a way to program the flash chip when things fail, I'd be happy to do testing. Jonathan Day

2 1

[PATCH] vga.fs: install MacOS VGA PPC driver from QEMU fw_cfg interface if available
by Mark Cave-Ayland 01 May '17

01 May '17

If the fw_cfg interface provides a MacOS VGA PPC NDRV binary driver then install it into the "driver,AAPL,MacOS,PowerPC" property of the QEMU VGA package. The installation of the binary is configured via the NVRAM configuration variable "vga-ndrv?" (which is set to true by default for PPC) and also the presence of the NDRV binary driver file within the QEMU fw_cfg interface itself. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- drivers/vga.fs | 14 ++++++++++++++ forth/admin/nvram.fs | 1 + 2 files changed, 15 insertions(+) diff --git a/drivers/vga.fs b/drivers/vga.fs index 29a043a..cbfa46c 100644 --- a/drivers/vga.fs +++ b/drivers/vga.fs @@ -34,6 +34,9 @@ fcode-version3 " fb8-fillrect" (find-xt) value fb8-fillrect-xt : fb8-fillrect fb8-fillrect-xt execute ; +" fw-cfg-read-file" (find-xt) value fw-cfg-read-file-xt +: fw-cfg-read-file fw-cfg-read-file-xt execute ; + \ \ IO port words \ @@ -197,6 +200,17 @@ headerless depth-bits encode-int " depth" property line-bytes encode-int " linebytes" property + \ Is the VGA NDRV driver enabled? (PPC only) + " /options" find-package drop s" vga-ndrv?" rot get-package-property not if + decode-string 2swap 2drop \ ( addr len ) + s" true" drop -rot comp 0= if + \ Embed NDRV driver via fw-cfg if it exists + " ndrv/qemu_vga.ndrv" fw-cfg-read-file if + encode-string " driver,AAPL,MacOS,PowerPC" property + then + then + then + ['] qemu-vga-driver-install is-install ; diff --git a/forth/admin/nvram.fs b/forth/admin/nvram.fs index 20f6462..3fbd935 100644 --- a/forth/admin/nvram.fs +++ b/forth/admin/nvram.fs @@ -336,6 +336,7 @@ s" -1" s" real-size" int-config s" 4000000" s" load-base" int-config s" -1" s" virt-base" int-config s" -1" s" virt-size" int-config +s" true" s" vga-ndrv?" bool-config [THEN] [IFDEF] CONFIG_X86 -- 1.7.10.4

1 0

[PATCH v2 0/2] Display color fixes
by Mark Cave-Ayland 21 Apr '17

21 Apr '17

Here are a couple of fixes that correct the display colors in the Solaris console login screen. It seems that the Solaris drivers assume the foreground and background colors are in different palette entries to those currently used by OpenBIOS causing the console to appear invisible as white text on a white background. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> v2: - Reword commit message for first patch as suggested by Tarl Mark Cave-Ayland (2): display.fs: fix off-by-one errors in color palette initialisation display.fs: fix palette entries for foreground and background colors forth/device/display.fs | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) -- 1.7.10.4

1 3

[PATCH] SPARC32: fix up obp_dumb_mmap() and obp_dumb_munmap()
by Mark Cave-Ayland 21 Apr '17

21 Apr '17

obp_dumb_mmap() needs to call ofmem_map() rather than the low-level ofmem_arch_map_pages() function otherwise the specified area is mapped directly on the CPU without being recorded in the relevant memory node properties. This fixes Solaris 2.6 which uses obp_dumb_mmap() to map the kernel msgbuf and would otherwise trap on boot as the mapping was lost once the kernel had taken over memory management from OpenBIOS. While we're here, add a missing DPRINTF() to obp_dumb_mmap() and provide the corresponding obp_dumb_munmap() implementation. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- arch/sparc32/lib.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/arch/sparc32/lib.c b/arch/sparc32/lib.c index d27b604..a53a396 100644 --- a/arch/sparc32/lib.c +++ b/arch/sparc32/lib.c @@ -196,15 +196,25 @@ char *obp_dumb_mmap(char *va, int which_io, unsigned int pa, unsigned int size) { uint64_t mpa = ((uint64_t)which_io << 32) | (uint64_t)pa; + ucell virt; + + DPRINTF("obp_dumb_mmap: virta 0x%x, phys 0x%x, size %d\n", (unsigned int)va, pa, size); + + /* Claim virtual memory */ + virt = ofmem_claim_virt(pointer2cell(va), size, 0); - ofmem_arch_map_pages(mpa, (unsigned long)va, size, ofmem_arch_default_translation_mode(mpa)); - return va; + /* Map memory */ + ofmem_map(mpa, virt, size, ofmem_arch_default_translation_mode(mpa)); + + return cell2pointer(virt); } -void obp_dumb_munmap(__attribute__((unused)) char *va, - __attribute__((unused)) unsigned int size) +void obp_dumb_munmap(char *va, unsigned int size) { DPRINTF("obp_dumb_munmap: virta 0x%x, sz %d\n", (unsigned int)va, size); + + ofmem_unmap(pointer2cell(va), size); + ofmem_release_virt(pointer2cell(va), size); } char *obp_memalloc(char *va, unsigned int size, unsigned int align) -- 1.7.10.4

1 1

[PATCH] pci: don't add simple open/close words to all PCI devices
by Mark Cave-Ayland 21 Apr '17

21 Apr '17

Currently all PCI devices except display devices are initialised with simple open and close words that are effectively a no-op, but enable the device to be accessed. Unfortunately this means that if devices have custom open and close words then the existing ones are overwritten causing OpenBIOS to emit warnings such as "open isn't unique" on the console. Resolve this by defaulting all PCI devices to the empty PCI node template ob_pci_empty_node and then adding the simple open and close words after the device has been initialised if they do not already exist. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- drivers/pci.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/pci.c b/drivers/pci.c index d698364..c7b2bd2 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -49,7 +49,7 @@ /* DECLARE data structures for the nodes. */ DECLARE_UNNAMED_NODE( ob_pci_bus_node, INSTALL_OPEN, 2*sizeof(int) ); -DECLARE_UNNAMED_NODE( ob_pci_simple_node, INSTALL_OPEN, 2*sizeof(int) ); +DECLARE_UNNAMED_NODE( ob_pci_simple_node, 0, 2*sizeof(int) ); DECLARE_UNNAMED_NODE( ob_pci_empty_node, 0, 2*sizeof(int) ); const pci_arch_t *arch; @@ -399,7 +399,6 @@ NODE_METHODS(ob_pci_bus_node) = { }; NODE_METHODS(ob_pci_simple_node) = { - { NULL, ob_pci_initialize }, { "open", ob_pci_open }, { "close", ob_pci_close }, }; @@ -1418,11 +1417,8 @@ static void ob_configure_pci_device(const char* parent_path, REGISTER_NAMED_NODE_PHANDLE(ob_pci_bus_node, config.path, phandle); } break; - case PCI_CLASS_DISPLAY: - REGISTER_NAMED_NODE_PHANDLE(ob_pci_empty_node, config.path, phandle); - break; default: - REGISTER_NAMED_NODE_PHANDLE(ob_pci_simple_node, config.path, phandle); + REGISTER_NAMED_NODE_PHANDLE(ob_pci_empty_node, config.path, phandle); break; } @@ -1460,6 +1456,11 @@ static void ob_configure_pci_device(const char* parent_path, pci_dev->config_cb(&config); } + /* if devices haven't supplied open/close words then supply them with simple defaults */ + if (!find_package_method("open", phandle) && !find_package_method("close", phandle)) { + REGISTER_NODE_METHODS(ob_pci_simple_node, config.path); + } + /* device is configured so we may move it out of scope */ device_end(); -- 1.7.10.4

1 1

[PATCH v2 0/3] fw_cfg: add support for files
by Mark Cave-Ayland 21 Apr '17

21 Apr '17

This patchset is part of the ongoing work to add virtio support to OpenBIOS, yet self-contained enough to be spun out as a separate patchset. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> v2: - Add comment explaining BE access for file API - Add mising byte swap macros to fw_cfg_find_file() Mark Cave-Ayland (3): fw_cfg: split fw_cfg_read() into fw_cfg_read() and fw_cfg_read_bytes() fw_cfg: add fw_cfg_find_file() and fw_cfg_read_file() functions fw_cfg: implement fw-cfg-read-file Forth word drivers/fw_cfg.c | 89 +++++++++++++++++++++++++++++++++++++++--- include/arch/common/fw_cfg.h | 16 ++++++++ libopenbios/init.c | 7 +++- 3 files changed, 105 insertions(+), 7 deletions(-) -- 1.7.10.4

1 4

[PATCH 0/2] Display color fixes
by Mark Cave-Ayland 20 Apr '17

20 Apr '17

Here are a couple of fixes that correct the display colors in the Solaris console login screen. It seems that the Solaris drivers assume the foreground and background colors are in different palette entries to those currently used by OpenBIOS causing the console to appear invisible as white text on a white background. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (2): display.fs: fix off-by-one errors in color palette initialisation display.fs: fix palette entries for foreground and background colors forth/device/display.fs | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) -- 1.7.10.4

2 4

[PATCH 0/3] fw_cfg: add support for files
by Mark Cave-Ayland 20 Mar '17

20 Mar '17

This patchset is part of the ongoing work to add virtio support to OpenBIOS, yet self-contained enough to be spun out as a separate patchset. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (3): fw_cfg: split fw_cfg_read() into fw_cfg_read() and fw_cfg_read_bytes() fw_cfg: add fw_cfg_find_file() and fw_cfg_read_file() functions fw_cfg: implement fw-cfg-read-file Forth word drivers/fw_cfg.c | 88 +++++++++++++++++++++++++++++++++++++++--- include/arch/common/fw_cfg.h | 16 ++++++++ libopenbios/init.c | 7 +++- 3 files changed, 104 insertions(+), 7 deletions(-) -- 1.7.10.4

2 7

[PATCH] pci: fix setup of 64-bit BARs
by Mark Cave-Ayland 14 Mar '17

14 Mar '17

The current PCI implementation is designed for a 32-bit PCI bus. When a 64-bit BAR is encountered during PCI bus enumeration, currently we treat the MSB BAR the same as a standard 32-bit BAR, attempting to guess its size by setting to 0xffffffff and reading back the response which returns back an invalid size of 0 and fails. This has the effect of setting the MSB BAR to 0xffffffff meaning that 64-bit BARs are mapped at the top of PCI memory in the wrong location. Handle this case by ignoring the MSB BAR when we detect a 64-bit BAR leaving it at its default value of zero. This solves the issue by ensuring that all 64-bit BARs are mapped within 32-bit PCI space which is fine for the PPC/SPARC64 machines we care about. Most noticeably this solves the issue of virtio modern devices (which use 64-bit BARs under QEMU) causing a kernel panic upon startup on qemu-system-sparc64 because they are mapped at the wrong address by OpenBIOS. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- drivers/pci.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/pci.c b/drivers/pci.c index c998280..2e09d0a 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1202,9 +1202,9 @@ ob_pci_configure(pci_addr addr, pci_config_t *config, int num_regs, int rom_bar, unsigned long *mem_base, unsigned long *io_base) { - uint32_t omask; + uint32_t omask, mask; uint16_t cmd; - int reg; + int reg, flags, space_code; pci_addr config_addr; ob_pci_configure_irq(addr, config); @@ -1216,6 +1216,14 @@ ob_pci_configure(pci_addr addr, pci_config_t *config, int num_regs, int rom_bar, ob_pci_configure_bar(addr, config, reg, config_addr, &omask, mem_base, io_base); + + /* Ignore 64-bit BAR MSBs (always map in 32-bit space) */ + pci_decode_pci_addr(config->assigned[reg], + &flags, &space_code, &mask); + + if (space_code == MEMORY_SPACE_64) { + reg++; + } } if (rom_bar) { -- 1.7.10.4

1 1

Jump to page: