OpenBIOS

openbios@openbios.org

4289 discussions

[PATCH] SPARC64: fix up dma-* words
by Mark Cave-Ayland 26 Aug '18

26 Aug '18

Commit 8584d42 "SPARC64: implement dma-* words" introduced the dma-* words for SPARC64 but accidentally introduced an older prototype implementation (probably introduced during a rebase) rather than using the correct defer words. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- arch/sparc64/tree.fs | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/arch/sparc64/tree.fs b/arch/sparc64/tree.fs index a1d5620..af8948d 100644 --- a/arch/sparc64/tree.fs +++ b/arch/sparc64/tree.fs @@ -52,26 +52,23 @@ include config.fs : decode-unit decode-unit-upa ; : dma-sync ( virt devaddr size -- ) - s" (dma-sync)" $find if execute then + (dma-sync) ; : dma-alloc ( size -- virt ) - \ OpenBIOS doesn't enable the sun4u IOMMU so we can fall back to using - \ alloc-mem - h# 2000 + alloc-mem dup - h# 2000 1 - and - \ align to 8K page size + (dma-alloc) ; : dma-free ( virt size -- ) - 2drop + (dma-free) ; : dma-map-in ( virt size cacheable? -- devaddr ) - 2drop + (dma-map-in) ; : dma-map-out ( virt devaddr size -- ) - dma-sync + (dma-map-out) ; new-device -- 2.11.0

1 1

[PATCH] ppc: move init-program client stack to 1:1 virt to phys mapped memory
by Mark Cave-Ayland 26 Aug '18

26 Aug '18

The default context used by init-program is allocated from the OpenBIOS heap which uses a different virt to phys mapping to avoid having to physically relocate the PROM on startup for PPC machines. It seems that the OpenBSD bootloader isn't happy with this change introduced by the context rework, most likely because there is an assumption that the client stack is mapped 1:1 virt to phys. Fix this by overriding the default context stack during init-program to a location just under the MMU hash table (SDR1) which was its previous hard-coded location in 1:1 virt to phys mapped memory, and allow OpenBSD to boot. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- arch/ppc/qemu/context.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/arch/ppc/qemu/context.c b/arch/ppc/qemu/context.c index 03ca173..06e0122 100644 --- a/arch/ppc/qemu/context.c +++ b/arch/ppc/qemu/context.c @@ -16,6 +16,7 @@ #include "libopenbios/ofmem.h" #include "libopenbios/initprogram.h" #include "libopenbios/sys_info.h" +#include "arch/ppc/processor.h" #define MAIN_STACK_SIZE 16384 #define IMAGE_STACK_SIZE 4096*2 @@ -232,6 +233,14 @@ arch_init_program(void) ctx->regs[REG_R6] = 0; ctx->regs[REG_R7] = 0; + /* Override the stack in the default context: the OpenBSD bootloader + fails soon after setting up virt to phys mappings with the default + stack. My best guess is that this is because the malloc() heap + doesn't have a 1:1 virt to phys mapping. So for the moment we use + the original (pre-context) location just under the MMU hash table + (SDR1) which is mapped 1:1 and makes the bootloader happy. */ + ctx->sp = mfsdr1() - 32768 - 65536; + /* Set param */ feval("load-state >ls.param @"); param = POP(); -- 2.11.0

1 1

[PATCH v2 0/4] Add virtio-blk driver support
by Mark Cave-Ayland 19 Aug '18

19 Aug '18

These patches add support for booting from virtio-blk (PCI) devices as used by QEMU. Patches 1 and 2 add bootindex support which is the new way for passing boot order information from QEMU to OpenBIOS. Note that there are also corresponding patches for QEMU required, without which the generated device paths will be incorrect and cause virtio boot to fail. Patch 3 adds the legacy virtio-blk driver (it follows the 0.9 rather than the 1.0 specification). Patch 4 enables the new driver for both PPC and SPARC64 architectures so that virtio-blk devices will be usable out-of-the-box with QEMU. Once these patches have been applied to OpenBIOS (along with the corresponding fw path fixes for QEMU) it is possible to boot from virtio-blk devices like this: PPC: ./qemu-system-ppc -drive file=debian-9.0-powerpc-NETINST.iso,if=none,index=0,id=cd,media=cdrom \ -device virtio-blk-pci,drive=cd,bootindex=0 -m 256 -boot d SPARC: ./qemu-system-sparc64 -drive debian-9.0-sparc64-NETINST.iso,if=none,index=0,id=cd,media=cdrom \ -device virtio-blk-pci,bus=pciB,drive=cd,bootindex=0 -m 256 -boot d -nographic Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> v2: - Switch over to using dma-* words to allocate rings and descriptors - Fix up some minor whitespace issues Mark Cave-Ayland (4): ppc: add bootindex support SPARC64: add bootindex support drivers: add legacy virtio-blk driver config: enable virtio-blk driver for default PPC and SPARC64 builds arch/ppc/qemu/init.c | 55 +++- arch/sparc64/boot.c | 2 +- arch/sparc64/boot.h | 2 +- arch/sparc64/openbios.c | 38 ++- config/examples/ppc_config.xml | 1 + config/examples/sparc64_config.xml | 1 + drivers/build.xml | 1 + drivers/pci.c | 18 ++ drivers/pci_database.c | 4 +- drivers/pci_database.h | 1 + drivers/virtio.c | 516 +++++++++++++++++++++++++++++++++++++ drivers/virtio.h | 330 ++++++++++++++++++++++++ include/drivers/drivers.h | 4 + 13 files changed, 953 insertions(+), 20 deletions(-) create mode 100644 drivers/virtio.c create mode 100644 drivers/virtio.h -- 2.11.0

1 4

[PATCH 0/3] Miscellaneous fixes
by Mark Cave-Ayland 18 Aug '18

18 Aug '18

Here is a set of fixes discovered during my work on adding virtio-blk support to OpenBIOS. Patch 1 changes the way in which the IDE controller DT nodes are generated so that they use the controller index as the address, and not the value programmed in the PCI BAR. Otherwise it is impossible for QEMU to determine the fw path for IDE boot devices, since the PCI BARs are programmed after the machine has been initialised. Patches 2 and 3 contain fixes for bugs that were discovered whilst trying to initialise the virtio-blk device for both PPC and SPARC64 architectures. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (3): ide: don't use ioports as part of the controller node address libopenbios: don't allow find_package_method() to push a NULL for empty strings pci: use absolute PCI IO addresses when programming bridge IO limits config/examples/ppc64_config.xml | 2 +- config/examples/ppc_config.xml | 2 +- drivers/ide.c | 18 ++++++++---------- drivers/pci.c | 2 +- libopenbios/bindings.c | 7 ++++++- 5 files changed, 17 insertions(+), 14 deletions(-) -- 2.11.0

2 6

Re: [OpenBIOS] Back at it again( PCI Passthrough )
by Joe van Tunen 14 Jul '18

14 Jul '18

I finally got around to updating my fcode to forth conversion scripts (see attached zip, also at https://www.dropbox.com/s/u2lojlc6vtuphbs/joevtOpen_Firmware_and_Forth.zip?… ). It's a Unix bash shell script which converts a PCI rom (containing fcode) to a forth source file that can be edited and tokenized to a new rom file. The bash script deals with extracting the PCI header and uses detok to extract the fcode. It then calls a perl script to convert the output from detok. It takes a couple minutes to do about 25000 lines. The version of toke and detok are based on older versions with enhancements and bug fixes to correctly handle the roms I've tested them with. The conversion process depends on the formatting (indenting) produced by detok. The generated forth source file has tokenizer commands (used by toke) to more faithfully reproduce the PCI header. These may be specific to my version of toke. To verify the output, do the following: DumpPCIRom the original rom. toke the result to create a new rom. DumpPCIRom the new rom and compare the result with the original. See example commands in joevtNewOFCommands.worksheet {.txt if you don't have BBEdit}). You'll notice the new rom is smaller because toke uses the more compact words for values {-1, 0, 1, 2, 3} instead of just b(lit). You may want to comment out the line "tokenizer[ xxxxx ]tokenizer rom-size" so that the rom size is set automatically (unless you want the size to be the same as the original). I didn't include a preprocessor. I had made one for MPW where you can embed shell commands to modify the forth source file to make it more compact/readable. For example, sections of duplicated code could be replaced by a loop. Large binary properties could be replaced by a command to encode-bytes from a binary file (e.g. for the macOS driver property). Defines and conditional compilation could be used to easily create roms for different purposes (debug or release, different hardware or settings). > On May 6, 2018, at 8:12 PM, Joe van Tunen <joevt(a)shaw.ca> wrote: > > Once I get my fcode token to forth converter updated (so it can be used with Unix/macOS instead of MPW) then you can make your own nvidia open firmware driver with added debugging code. > > > On 5/6/18, 8:11 AM, "Jd Lyons" <lyons_dj(a)yahoo.com> wrote: > > Seems to be tripping over the second b(>resolve), tho I’m not sure what this fcode is trying to do? > > Joe, see if you can have a look at it, when you have time, and see if you have any ideas what is causing the exception.

1 0

[PATCH v4] arch/ppc/qemu: Add a node for the other (empty) PCI bus to the device tree
by BALATON Zoltan 30 Jun '18

30 Jun '18

QEMU emulates two of the three PCI buses found on real hardware because some clients seem to need both and fail with only one present, but OpenBIOS only handles a single PCI bus and initialises and puts in the device tree only one of these: the second one which is where devices are connected and also marks it bus 0. However, clients getting info from the device tree may not know about this and thinking there is only one PCI bus they erroneously use the address of the first bus to access PCI config registers for devices on the second bus which silently fails as these requests will go to the other empty bus emulated and return invalid values. Devices mapped via MMIO still appear to work but they may not be correctly initialised and some cards are not detected because of this. Until support for multiple PCI buses is implemented add an empty node in the device tree for the uninitialised bus to let clients know about it. This is still not entirely correct as bus-range property does not match real hardware but this fixes detecting PCI devices (such as USB) under MorphOS and may also fix enabling the bus master bit needed with some network cards and allow the workarund for this to be reverted. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- v4: Rebased to latest master v3: See: https://mail.coreboot.org/pipermail/openbios/2017-January/009867.html arch/ppc/qemu/init.c | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index af15682..d362b0e 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -716,6 +716,48 @@ static void kvm_of_init(void) fword("finish-device"); } +static void empty_pci_bus_init(void) +{ + if (machine_id == ARCH_MAC99) { + /* Add empty node for first pci bus */ + /* Remove this when pci driver is fixed to handle multiple buses */ + activate_device("/"); + 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"); + device_end(); + } +} + /* * filll ( addr bytes quad -- ) */ @@ -857,6 +899,7 @@ arch_of_init(void) feval("['] ppc-dma-sync to (dma-sync)"); #ifdef CONFIG_DRIVER_PCI + empty_pci_bus_init(); ob_pci_init(); #endif -- 2.7.6

2 4

[PATCH 0/5] mac99 PMU patches
by Mark Cave-Ayland 17 Jun '18

17 Jun '18

Here is a reworked version of Ben's mac99 PMU patches for OpenBIOS along with a minor fix for the keyboard alias. The main difference between Ben's version and this version are that instead of defining a new mac99p machine, the aim is to keep using the existing mac99 machine and then switch it over to use PMU by default once the remaining issues with USB and timers have been fixed. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (5): ppc: add fw_cfg interface for passing VIA/ADB configuration from QEMU ppc: add GPIO devices to the device tree when PMU hardware detected adb: set compatible property differently if PMU is present ppc: add PMU driver usbhid: fix up keyboard alias for USB keyboards arch/ppc/qemu/init.c | 28 +- drivers/adb_bus.c | 8 +- drivers/adb_bus.h | 5 + drivers/build.xml | 1 + drivers/macio.c | 80 +++++- drivers/pci.c | 18 ++ drivers/pmu.c | 625 +++++++++++++++++++++++++++++++++++++++++++ drivers/pmu.h | 17 ++ drivers/usbhid.c | 2 +- include/arch/common/fw_cfg.h | 1 + include/drivers/drivers.h | 10 + 11 files changed, 785 insertions(+), 10 deletions(-) create mode 100644 drivers/pmu.c create mode 100644 drivers/pmu.h -- 2.11.0

2 8

[PATCH 00/11] PReP support for QEMU 40p machine
by Mark Cave-Ayland 08 Jun '18

08 Jun '18

The current PReP firmware provided with OpenBIOS is OpenHackWare which provides a basic set of OpenFirmware interfaces but does this without providing any kind of Forth implementation which limits its usefulness and compatibility. Whilst the project has allowed QEMU PReP development to continue to date, it is sadly now abandonware with no patches for over 4 years, and with no-one willing to take on maintenance it is now time for a different approach. This patchset adds PReP support for the QEMU 40p machine allowing it to start booting NetBSD and the sandalfoot Linux zImage. The main features required for this are support for the LSI SCSI controller, resdidual data and PReP boot partitions. In order to test these patches you'll need a recent QEMU with the following patches applied: https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg05480.html https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg05964.html Next you'll need an updated openbios-ppc binary, and for those without access to a cross-compiler setup I've uploaded the resulting binary to https://www.ilande.co.uk/tmp/qemu/openbios-ppc.prep. To boot the sandalfoot zImage from http://www.juneau-lug.org/zImage.initrd.sandalfoot you can do: qemu-system-ppc -M 40p -bios openbios-ppc.prep -cdrom zImage.initrd.sandalfoot -boot d Note that it seems to get stuck trying to initialise the LSI SCSI controller, presumably due to a bug in the existing QEMU emulation. NetBSD works much better and in fact boots all the way to userspace: qemu-system-pcc -M 40p -bios openbios-ppc.prep -cdrom NetBSD-7.1.2-prep.iso -boot d -nographic In terms of functionality I think this patchset is just about there: there are a few questions around device names but hopefully someone with real PReP experience can point me in the right direction. Finally I've added various people on CC who have expressed interest in PReP and/or OpenHackWare in the past: if this is no longer of any interest to you, do let me know and I'll drop your email address from future versions. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (11): pc_kbd: ensure that we properly reset the 8042 controller and keyboard device pci: rename i82378 keyboard device from 8042 to keyboard pci: add AMD PCNET information to PCI database bootcode_load: ensure LOADER_NOT_SUPPORT is returned if no bootcode is present ppc: add PReP support to dma-map-in pci: add driver for LSI 53C810 SCSI controller ppc: add PReP residual data block ppc: use proper context when pre-loading kernels pc-parts: allow successful detection of PReP boot partitions libopenbios: add PReP boot partition loader for PPC prep: disable VBE extensions when executing client program arch/ppc/qemu/context.c | 129 ++++++- arch/ppc/qemu/context.h | 1 + arch/ppc/qemu/init.c | 34 ++ arch/ppc/qemu/kernel.h | 1 - arch/ppc/qemu/main.c | 11 +- arch/ppc/qemu/switch.S | 43 --- arch/ppc/qemu/tree.fs | 5 - config/examples/ppc_config.xml | 2 + drivers/build.xml | 1 + drivers/lsi.c | 770 ++++++++++++++++++++++++++++++++++++++++ drivers/pc_kbd.c | 22 +- drivers/pci.c | 21 +- drivers/pci_database.c | 14 + drivers/pci_database.h | 1 + drivers/vga.fs | 11 + forth/debugging/client.fs | 1 + include/arch/ppc/residual.h | 116 ++++++ include/drivers/drivers.h | 4 + include/drivers/pci.h | 6 + include/libopenbios/prep_load.h | 24 ++ libopenbios/bootcode_load.c | 2 + libopenbios/build.xml | 1 + libopenbios/initprogram.c | 8 + libopenbios/load.c | 11 + libopenbios/prep_load.c | 106 ++++++ packages/pc-parts.c | 10 + 26 files changed, 1300 insertions(+), 55 deletions(-) create mode 100644 drivers/lsi.c create mode 100644 include/arch/ppc/residual.h create mode 100644 include/libopenbios/prep_load.h create mode 100644 libopenbios/prep_load.c -- 2.11.0

2 14

[PATCH 00/15] Implement dma-* words
by Mark Cave-Ayland 26 May '18

26 May '18

This patchset is something I've been working on for a while and started off with the aim of getting rid of the "dma-alloc" console warnings whilst booting *BSD images on PPC, but ended up as a full implementation for SPARC32/SPARC64 and PPC. The patchset is fairly straightfoward: the first few patches rework the SPARC32 DVMA functions to make them usable from Forth, whilst patch 8 adds a missing D-cache flush for PPC which could certainly do with another set of eyes. The remainder of the patches add PPC and SPARC64 support before adding in the complete "dma-*" $call-parent chains to enable devices to call the DMA functions as indicated in the IEEE-1275 specification and various FCode examples found around the net. Finally the last 2 patches switch the esp SCSI driver over to use the IEEE-1275 Forth words instead of calling the low-level C functions directly. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (15): dma: add defers for the dma-* words SPARC32: rename dvma_alloc()'s ba variable to iova SPARC32: allocate contiguous physical memory for DVMA SPARC32: implement dvma_map_in() for DMA IOVA to phys translation SPARC32: move pgtsrmmu.h from arch/sparc32 to include/arch/sparc32 SPARC32: implement dvma_sync() function for synchronising DMA memory SPARC32: implement dma-* words PPC: add flush_dcache_range() to start.S PPC: implement dma-* words SPARC64: implement dma-* words macio: add missing REGISTER_NODE for New World macio devices pci: add dma-* call-parent chain to all PCI devices and bridges sbus: add dma-* call-parent chain to all PCI devices and bridges esp: switch creation of esp device over to use new-device esp: switch over to using dma-alloc/dma-map-in arch/ppc/qemu/init.c | 35 +++++++ arch/ppc/qemu/kernel.h | 1 + arch/ppc/qemu/start.S | 21 ++++ arch/ppc/qemu/tree.fs | 40 ++++++++ arch/sparc32/lib.c | 2 +- arch/sparc32/ofmem_sparc32.c | 2 +- arch/sparc32/openbios.c | 47 ++++++++- arch/sparc32/tree.fs | 56 +++++++++++ arch/sparc64/openbios.c | 40 ++++++++ arch/sparc64/tree.fs | 47 +++++++++ drivers/esp.c | 159 ++++++++++++++++++++---------- drivers/ide.c | 40 ++++++++ drivers/iommu.c | 95 +++++++++++++++--- drivers/macio.c | 36 +++++++ drivers/pci.c | 40 ++++++++ forth/device/other.fs | 8 +- forth/device/table.fs | 2 +- forth/util/util.fs | 9 ++ {arch => include/arch}/sparc32/pgtsrmmu.h | 0 include/drivers/drivers.h | 4 +- packages/disk-label.fs | 39 ++++++++ 21 files changed, 646 insertions(+), 77 deletions(-) rename {arch => include/arch}/sparc32/pgtsrmmu.h (100%) -- 2.11.0

1 16

[PATCH] pci: fix OHCI driver PCI address
by Mark Cave-Ayland 22 May '18

22 May '18

Commit a1c2e4f "Add USB OHCI + HID driver" hardcoded the high order bit of the PCI address to that used on PPC machines instead of using the correct PCI_ADDR() macro. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- drivers/pci.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/pci.c b/drivers/pci.c index 295be7e..7085a3a 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1111,7 +1111,10 @@ int i82378_config_cb(const pci_config_t *config) int usb_ohci_config_cb(const pci_config_t *config) { #ifdef CONFIG_DRIVER_USB - ob_usb_ohci_init(config->path, 0x80000000 | config->dev); + pci_addr addr = PCI_ADDR( + PCI_BUS(config->dev), PCI_DEV(config->dev), PCI_FN(config->dev)); + + ob_usb_ohci_init(config->path, addr); #endif return 0; } -- 2.11.0

2 2

← Newer
1
...
9
10
11
12
13
14
15
...
429
Older →

Jump to page: