OpenBIOS

openbios@openbios.org

4284 discussions

[PATCH 0/2] 40p: update interrupt routing and model name
by Mark Cave-Ayland 05 Oct '18

05 Oct '18

These patches update OpenBIOS to match the lastest 40p changes merged into QEMU and allow the Linux sandalfoot zImage to boot all the way to userspace. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (2): 40p: update interrupt routing code to match QEMU 40p: change residual data model name to IBM PPS Model 6015 arch/ppc/qemu/context.c | 2 +- arch/ppc/qemu/init.c | 2 +- drivers/pci.c | 24 ++++++++++++++++++++---- 3 files changed, 22 insertions(+), 6 deletions(-) -- 2.11.0

2 7

[PATCH] prep: change residual data model name to IBM PPS Model 6015
by Mark Cave-Ayland 10 Sep '18

10 Sep '18

With the corresponding QEMU patches applied, it is now possible to change the reported firmware name to that of a real 40p machine and boot to a working userspace with the Linux sandalfoot zImage. Note that whilst guest OSs should be relying on residual data rather than the OF device tree to determine the hardware, we still update the interrupt properties to match the new code in QEMU for consistency. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- arch/ppc/qemu/context.c | 2 +- drivers/pci.c | 24 ++++++++++++++++++++---- 2 files changed, 21 insertions(+), 5 deletions(-) diff --git a/arch/ppc/qemu/context.c b/arch/ppc/qemu/context.c index 06e0122..5815895 100644 --- a/arch/ppc/qemu/context.c +++ b/arch/ppc/qemu/context.c @@ -111,7 +111,7 @@ static void * residual_build(uint32_t memsize, uint32_t load_base, uint32_t load_size) { residual_t *res; - const unsigned char model[] = "Qemu\0PPC\0"; + const unsigned char model[] = "IBM PPS Model 6015\0"; int i; res = malloc(sizeof(residual_t)); diff --git a/drivers/pci.c b/drivers/pci.c index 8f97ae1..df6d9d0 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1986,10 +1986,26 @@ static phandle_t ob_pci_host_set_interrupt_map(phandle_t host) static void ob_pci_host_bus_interrupt(ucell dnode, u32 *props, int *ncells, u32 addr, u32 intno) { *ncells += pci_encode_phys_addr(props + *ncells, 0, 0, addr, 0, 0); - props[(*ncells)++] = intno; - props[(*ncells)++] = dnode; - props[(*ncells)++] = arch->irqs[((intno - 1) + (addr >> 11)) & 3]; - props[(*ncells)++] = 1; + + if (is_oldworld() || is_newworld()) { + /* Mac machines */ + props[(*ncells)++] = intno; + props[(*ncells)++] = dnode; + props[(*ncells)++] = arch->irqs[((intno - 1) + (addr >> 11)) & 3]; + props[(*ncells)++] = 1; + } else { + /* PReP machines */ + props[(*ncells)++] = intno; + props[(*ncells)++] = dnode; + + if (PCI_DEV(addr) == 1 && PCI_FN(addr) == 0) { + /* LSI SCSI has fixed routing */ + props[(*ncells)++] = 2; + } else { + props[(*ncells)++] = arch->irqs[((intno - 1) + (addr >> 11)) & 1]; + } + props[(*ncells)++] = 1; + } } #elif defined(CONFIG_SPARC64) -- 2.11.0

2 2

[PATCH 0/2] 40p minor fixes
by Mark Cave-Ayland 31 Aug '18

31 Aug '18

Here are a couple of 40p fixes I noticed whilst debugging the interrupt routing in QEMU's 40p PReP machine. Note that the IRQ changes in patch 2 are dependent upon my fix for the 40p PCI IRQ routing posted at https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg05705.html. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (2): 40p: fix up generation of interrupt properties 40p: update PReP configuration to match 40p machine arch/ppc/qemu/init.c | 4 ++-- drivers/pci.c | 15 +++++++-------- 2 files changed, 9 insertions(+), 10 deletions(-) -- 2.11.0

3 6

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

31 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 virtio-1.0 compliant virtio-blk PCI driver. Patch 4 enables the new driver for both PPC and SPARC64 architectures so that virtio-blk-pci 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-pci 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> v3: - Rebase onto master - Convert from legacy driver to virtio-1.0 driver 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 virtio-1.0 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 | 63 +++++ drivers/pci_database.c | 14 +- drivers/pci_database.h | 1 + drivers/virtio.c | 555 +++++++++++++++++++++++++++++++++++++ drivers/virtio.h | 370 +++++++++++++++++++++++++ include/drivers/drivers.h | 5 + include/drivers/pci.h | 6 + 14 files changed, 1093 insertions(+), 21 deletions(-) create mode 100644 drivers/virtio.c create mode 100644 drivers/virtio.h -- 2.11.0

1 5

[PATCH] ppc: make sure that we correctly map loader RAM at load-base
by Mark Cave-Ayland 31 Aug '18

31 Aug '18

An error in the logic related to FREE_BASE meant that instead of mapping the RAM for the loader at load-base, a small section was being mapped at the bottom of RAM instead. Fix this by deferring the mapping of the load-base RAM to arch_init() when we can access the load-base variable and map 8MB RAM with a 1:1 phys to virt mapping. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- arch/ppc/qemu/init.c | 8 ++++++++ arch/ppc/qemu/ofmem.c | 12 ------------ 2 files changed, 8 insertions(+), 12 deletions(-) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index af15682..f5acf87 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -844,6 +844,7 @@ arch_of_init(void) uint32_t temp = 0; char *boot_device; ofmem_t *ofmem = ofmem_arch_get_private(); + ucell load_base; openbios_init(); modules_init(); @@ -1105,4 +1106,11 @@ arch_of_init(void) bind_func("platform-boot", boot); bind_func("(arch-go)", arch_go); + + /* Allocate 8MB memory at load-base */ + fword("load-base"); + load_base = POP(); + ofmem_claim_phys(load_base, 0x800000, 0); + ofmem_claim_virt(load_base, 0x800000, 0); + ofmem_map(load_base, load_base, 0x800000, 0); } diff --git a/arch/ppc/qemu/ofmem.c b/arch/ppc/qemu/ofmem.c index 7b8ced0..7a78a1e 100644 --- a/arch/ppc/qemu/ofmem.c +++ b/arch/ppc/qemu/ofmem.c @@ -46,7 +46,6 @@ extern void setup_mmu(unsigned long code_base); * */ -#define FREE_BASE 0x00004000UL #define OF_CODE_START 0xfff00000UL #define OF_CODE_SIZE 0x00100000 #define IO_BASE 0x80000000UL @@ -81,12 +80,6 @@ get_ram_top(void) return get_hash_base() - (32 + 64 + 64) * 1024 - OFMEM_SIZE; } -static unsigned long -get_ram_bottom(void) -{ - return FREE_BASE; -} - static unsigned long get_heap_top(void) { return get_hash_base() - (32 + 64 + 64) * 1024; @@ -578,11 +571,6 @@ ofmem_init(void) { ofmem_t *ofmem = ofmem_arch_get_private(); - /* Map the memory (don't map page 0 to allow catching of NULL dereferences) */ - ofmem_claim_phys(PAGE_SIZE, get_ram_bottom() - PAGE_SIZE, 0); - ofmem_claim_virt(PAGE_SIZE, get_ram_bottom() - PAGE_SIZE, 0); - ofmem_map(PAGE_SIZE, PAGE_SIZE, get_ram_bottom() - PAGE_SIZE, 0); - /* Mark the first page as non-free */ ofmem_claim_phys(0, PAGE_SIZE, 0); ofmem_claim_virt(0, PAGE_SIZE, 0); -- 2.11.0

1 3

[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

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

Jump to page: