OpenBIOS

openbios@openbios.org

4289 discussions

openbios support for netboot? (qemu-system-sparc32/solaris)
by Joe Dery 22 Dec '18

22 Dec '18

Intrepid openBIOS developers, Though not new news, thank you for providing an openBIOS that is able to boot solaris in qemu-system-sparc32! While I am able to disk boot (with qcow2 image containing ufs filesystems), but would prefer to serve as much of my guest filesystem from NFS as possible. Netboot allows a 'diskless' system, so that is the most extreme case, but I'm open to other suggestions. Does OpenBIOS 1.1 (eg the snapshot attached to QEMU GIT HEAD as of last Friday) support boot net:rarp, boot net:dhcp, or any other more manual method of providing the kernel&parameters? I haven't been able to find this in the documentation or code so I imagine it does not. PS - FWIW this is the command line I am presently using for a 'disk0' boot. Note that the tftp/bootfile do not do anything, but I included them as an example based on the other qemu documentation. qemu/sparc-softmmu/qemu-system-sparc \ -net nic,macaddr=00:03:BA:04:A5:AD -net user,hostfwd=tcp::8023-:23,hostfwd=tcp::5911-:5911,tftp=/tftpboot,bootfile=inetboot.sun4m \ -hda sol8_36G.disk.install \ -nographic -serial telnet:0.0.0.0:3000,server \ -m 256 PPS Mark Cave-Ayland, it appears you're active on this list. Thanks again for your help (now years ago!) fixing the MUTEX_HELD & related problems in 2.6.... the current GIT still runs clean. I have not really worked with QEMU since ~2.6, around that time I picked up a SunBlade 1000, which is supported by the old kernel I need, and is able to run the (mostly CC compile) workloads an order of magnitude faster. QEMU remains interesting for applications requiring less performance, e.g. lmgrd license server.

2 1

SVN to github migration
by BALATON Zoltan 09 Dec '18

09 Dec '18

Hello, The links on the pages https://www.openfirmware.org/Open_Firmware https://www.openfirmware.org/SmartFirmware https://www.openfirmware.org/OpenBOOT seem to be broken since the SVN to github migration. I think these are now at https://github.com/openbios but the above pages should also be updated to point to there instead. Thank you, BALATON Zoltan

2 1

Need help : sparc64 ULTRA5 under Solaris 7 64 bits
by BALARD Arnaud 07 Dec '18

07 Dec '18

Bonjour, je vous envoie un mail car j'essaie de virtualiser une machine ULTRA5 sous solaris 7 en 64 bits. j'ai réussi à démarrer sur un cd solaris 7 32bits pour restaurer les partitions sur mon disque virtuel (ufsrestore). Quand j'essaie de démarrer avec qemu-system-sparc64 j'obtiens l'erreur "no valid state has been set by load or init-program" dans le prompt qemu "Not linux kernel image, Not a bootable ELF image, Not a bootable a.out image, Not a bootable FCode image" au bout d'un certain nombre de test ma dernière commande ressemble à ca : sparc64-softmmu#./qemu-system-sparc64 -M sun4u -bios /usr/local/share/qemu/openbios-sparc64 -m 256 -drive file=/home/qemu/QEMU_SRV/SRV.qcow2 -prom-env "auto-boot?=flase" Je vois bien mon disque présent sur /pci@1fe,0/pci@1,1/ide@3/ide@0/disk@0 est-t 'il possible de virtualiser une machine ultra5 sous solaris 7 64bits ? La barrière de ma machine réel ressemble à ca : Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 400MHz),OpenBoot 3.25 256 MB.... J'ai entendu parler de ce patch : https://patchwork.kernel.org/patch/9175879/ ou est-ce qu'il y a une configuration à faire dans sparc64-softmmu ? Je ne sais pas si il peut m'aider à trouver mon bonheur. Dans l'attente de votre réponse, merci. **************************************************************************************************************************************************************** Hello, I send you an email because I try to virtualize an ULTRA5 machine under solaris 7 in 64 bits. I managed to boot on a cd solaris 7 32bits to restore the partitions on my virtual disk (ufsrestore). When I try to start with qemu-system-sparc64 I get the error "no valid state has been set by load or init-program" in the qemu prompt "Not linux kernel image, Not a bootable ELF image, Not a bootable a.out image, Not a bootable Image mode " after a certain number of tests my last command looks like this: sparc64-softmmu#./qemu-system-sparc64 -M sun4u -bios /usr/local/share/qemu/openbios-sparc64 -m 256 -drive file=/home/qemu/QEMU_SRV/SRV.qcow2 -prom-env "auto-boot? = flase" I can see my disk present on /pci@1fe,0/pci@1,1/ide@3/ide@0/disk@0 is it possible to virtualize an ultra5 machine under solaris 7 64bits? The barrier of my real machine looks like this: Sun Ultra 5/10 UPA / PCI (UltraSPARC-IIi 400MHz), OpenBoot 3.25 256 MB .... I heard about this patch: https://patchwork.kernel.org/patch/9175879/ or is there a configuration to do in sparc64-softmmu? I do not know if he can help me find my happiness. Looking forward to your reply, thank you. Libre (C=0) Interne (C=1) Restreint (C=2) Confidentiel (C=3) X [X] Arnaud BALARD Chargé d'Exploitation et d'Affaires EDF - DPNT - DAIP - UNITEP AEI - Groupe SIMU UFPI Bugey CD 20 - BP 70130 01155 LAGNIEU arnaud.balard(a)edf.fr Tél. : 04 37 63 62 72 Un geste simple pour l'environnement, n'imprimez ce message que si vous en avez l'utilité. Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message. Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus. ____________________________________________________ This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. E-mail communication cannot be guaranteed to be timely secure, error or virus-free.

2 1

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

18 Oct '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> 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 | 424 +++++++++++++++++++++++++++++++++++++ drivers/virtio.h | 331 +++++++++++++++++++++++++++++ include/drivers/drivers.h | 4 + 13 files changed, 862 insertions(+), 20 deletions(-) create mode 100644 drivers/virtio.c create mode 100644 drivers/virtio.h -- 2.11.0

3 8

Ppc guest debugging?
by Jd Lyons 14 Oct '18

14 Oct '18

I need to try and debug the macOS trampoline inits during the early boot process of OS 9. I’m thinking Qemu supports this, but I’m unsure how to set it up? I installed gdb-multiarch and started qemu with: Qemu-system-ppc -s -S The launched gdb-multiarch and connected to port 1234. Is this the correct toolchain for debugging PPC code on an X86 host, or do I need to do something else?

3 11

[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

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

Jump to page: