OpenBIOS February 2018

openbios@openbios.org

4 participants
5 discussions

[PATCH] ofmem: restrict ofmem_claim() allocations to RAM size

by Mark Cave-Ayland

As OFMEM memory ranges don't provide an explicit upper limit, we must manually check that CIF claim calls lie within a valid maxmimum range if attempting to allocate a specific address. Since the claim method provides a 1:1 mapping between physical and virtual addresses, the valid maximum address is therefore equivalent to the machine RAM size. This fixes booting yaboot 1.3.17 which implements a top-down search using claim to find the next free memory region to locate its heap. Without this fix we blindly accept a claim for physical addresses far above the available RAM which fails silently when we try to use the mapping later. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- libopenbios/ofmem_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libopenbios/ofmem_common.c b/libopenbios/ofmem_common.c index 217bd9b..fc19d27 100644 --- a/libopenbios/ofmem_common.c +++ b/libopenbios/ofmem_common.c @@ -623,7 +623,7 @@ ucell ofmem_claim( ucell addr, ucell size, ucell align ) virt = phys = 0; if( !align ) { if( is_free(addr, size, ofmem->virt_range) && - is_free(addr, size, ofmem->phys_range) ) { + is_free(addr, size, ofmem->phys_range) && addr < get_ram_size() ) { ofmem_claim_phys_( addr, size, 0, 0, 0, 0 ); ofmem_claim_virt_( addr, size, 0, 0, 0, 0 ); virt = phys = addr; -- 2.11.0

2 years, 11 months

Re: [OpenBIOS] SunOS 5.8 64bit emulate SUNW, Ultra 2

by Mark Cave-Ayland

On 14/02/18 10:57, Weidemann, Maik (M-SO) wrote: > Hello Mark, > > thanks for your answer. > > The tip with the bios binary from git was good. It’s look like my own > build is faulty. > > Now I get this error messages: > > #qemu-system-sparc64 -uuid 0120b64e-5d86-41a9-8763-07f8d64f9f9c > -nographic -drive unit=1,file=sun14_disk.raw,format=raw -L . -bios > pc-bios_openbios-sparc64 > > OpenBIOS for Sparc64 > > Configuration device id QEMU version 1 machine id 0 > > kernel cmdline > > CPUs: 1 x SUNW,UltraSPARC-IIi > > UUID: 0120b64e-5d86-41a9-8763-07f8d64f9f9c > > Welcome to OpenBIOS v1.1 built on Jan 26 2018 07:53 > > Type 'help' for detailed information > > Trying disk:a... > > Not a bootable ELF image > > Not a bootable a.out image > > Loading FCode image... > > Loaded 5936 bytes > > entry point is 0x4000 > > Evaluating FCode... > > open isn't unique. > > Alloc of 0x2000 bytes at 0x16000 refused. > > panic[cpu0]/thread=10408000: BOP_ALLOC failed > > 0000000010406e90 unix:boot_alloc+44 (2000, 2000, 1000, 30000016000, > 10775860, 30000014000) > > %l0-3: 000000001041aac0 0000030ffffff138 0000000000000001 > 000000001044a9c8 > > %l4-7: 0000000010449b20 0000000010449b00 000000001044a928 > 000000000000000b > > 0000000010406f40 unix:segkmem_alloc+30 (30000016000, 2000, 0, 0, > 1044dbe8, 10449f08) > > %l0-3: 0000030ffffff5c0 ffffffffffffe000 0000000000000000 > 000000001044a9c8 > > %l4-7: 0000000010449b20 0000000010449b00 000000001044e448 > 0000000010045d68 > > 0000000010407000 genunix:vmem_xalloc+3d8 (1044d620, 1044da28, > ffffffffffffffff, ffffffffffffffff, 0, 0) > > %l0-3: 0000000010045ce4 ffffffffffffe000 000000001044d620 > 0000000000002000 > > %l4-7: 0000000000000000 0000000000000000 0000000000002000 > 000000001044d640 > > 0000000010407130 genunix:kmem_slab_create+8c (0, 0, 2000, 300000043c0, > 0, 1044d620) > > %l0-3: 0000000000000000 0000030ffffff220 0000000000000000 > 000000001044a9c8 > > %l4-7: 0000000010449b20 00000300000043c0 000000001044e448 > 00000000ffecb1d0 > > 0000000010407220 genunix:kmem_cache_alloc+180 (0, 0, 0, 300000043c0, 0, 0) > > %l0-3: 0000030000004740 ffffffffffffe000 000000001044d620 0000000000002000 > > %l4-7: 0000030ffffff220 0000000000000000 0000000000002000 > 000000001044d640 > > 00000000104072d0 genunix:kmem_slab_create+130 (200, 30000014000, 2000, > 3000000da40, 0, 200) > > %l0-3: 0000000000000000 ffffffffffffe000 000000001044d620 > 0000000000002000 > > %l4-7: 0000030fffffef68 000003000000da40 0000000000002000 > 000000001044d640 > > 00000000104073c0 genunix:kmem_cache_alloc+180 (0, 0, 0, 3000000da40, 0, 0) > > %l0-3: 000003000000ddc0 0000000000000000 0000000000010000 > ffffffffffffffff > > %l4-7: 0000030000013fc8 00000300000052c0 0000030000013fc8 > 0000030000013fc0 > > 0000000010407470 genunix:kmem_alloc+2c (2000, 0, 2000, 3000000da40, 0, > 30000013fb8) > > %l0-3: 0000030000005640 000000001013671a 0000000000000000 0000000000000020 > > %l4-7: 0000000010445280 000000001045114b 0000000000000000 > 0000000000000000 > > 0000000010407520 krtld:kobj_zalloc+c (2000, 1000, 2000, 300000052c0, f0, 0) > > %l0-3: 000003000000e740 ffffffffffffffc0 000000001044e4e8 00000000000003c0 > > %l4-7: 0000000010449678 0000000000000000 0000000000000000 > 000000000000000b > > 00000000104075d0 krtld:kobj_open_file+38 (2000, 30000011f88, 10438418, > 0, 0, 1) > > %l0-3: 0000000000000008 0000000000000000 0000000000000000 > 0000000000000000 > > %l4-7: 0000000000000008 0000000010045ce4 0000000010451140 > 0000000010045d68 > > 0000000010407680 genunix:mod_read_system_file+70 (10436800, 2000, 1, 0, > 26, 10438d20) > > %l0-3: 0000000000004000 0000000000000008 0000000000004008 > 0000000000000000 > > %l4-7: 0000000000002000 0000000010045ce4 0000000010450278 > 0000000010045d68 > > 00000000104077a0 genunix:kmem_init+1b8 (10460470, 0, 0, 10614bd0, > 10775c80, 30000016160) > > %l0-3: 000000001041d000 0000000000002000 0000000010045ce4 > 0000000010045d68 > > %l4-7: 0000000010417ea8 0000000000001fff 000000001040d920 > 00000000ffecb1d0 > > 0000000010407870 unix:startup_memlist+99c (10417c00, 300000160a0, > 10417ee0, 10417eb0, 10417ec8, 30000016000) > > %l0-3: 0000000000000103 0000030000000000 0000000010423000 > 0000000010424190 > > %l4-7: 0000000000000000 0000000000002000 0000030000016000 > 000000001041c800 > > 0000000010407970 unix:startup+c (10428000, 0, 0, 7e7c000, 2000, > ffffffffffffffff) > > %l0-3: 00000000100243b8 000000000000cbec 000000000000114c > 0000000000000000 > > %l4-7: 00000000104619b8 00000000002de9d8 00000000000b514c > 000000000000114c > > 0000000010407a20 genunix:main+4 (1040d400, 2000, 10407ec0, 10408030, > fff2, 1004df8c) > > %l0-3: 0000000010408000 0000000000000001 0000000000000015 > 0000000000000e69 > > %l4-7: 00000000104287b0 00000000104619b8 00000000000ca6a0 > 0000000000000540 > > skipping system dump - no dump device configured > > rebooting... > > BOOTpanic - kernel: prom_reboot: reboot call returned! > > EXIT > > 0 > ok > > 0 > ok > > 0 > ok > > 0 > ok > > 0 > ok > > 0 > ok > > 0 > boot disk > > Not a Linux kernel image > > Not a bootable ELF image > > Not a bootable a.out image > > Loading FCode image... > > Loaded 5936 bytes > > entry point is 0x6000 > > Evaluating FCode... > > open isn't unique. > > Boot load failed. > > Do the error messages come from the Bios or already from the booting OS? Those are from the Solaris kernel so that's a good start. This looks similar to what I get from my Solaris 9 test ISO and I suspect it's related to memory initialisation. Solaris 11 gets all the way to userspace, but still needs the MMU IE support added to QEMU. > When I try to start the vm with the define of the disk, who it described > in the current documentation > (https://wiki.qemu.org/Documentation/Platforms/SPARC#All_PCI_devices_are_att…), > > then I get this notification: > > #qemu-system-sparc64 > > -uuid 0120b64e-5d86-41a9-8763-07f8d64f9f9c \ > > -nographic \ > > -drive > id=hd,if=none,file=/var/lib/libvirt/images/sun14_disk.raw,format=raw \ > > -device virtio-blk-pci,bus=pciB,drive=hd \ > > -L . \ > > -bios pc-bios_openbios-sparc64 \ > > -m 256 > > OpenBIOS for Sparc64 > > Configuration device id QEMU version 1 machine id 0 > > kernel cmdline > > CPUs: 1 x SUNW,UltraSPARC-IIi > > UUID: 0120b64e-5d86-41a9-8763-07f8d64f9f9c > > Welcome to OpenBIOS v1.1 built on Jan 26 2018 07:53 > > Type 'help' for detailed information > > Trying disk:a... > > No valid state has been set by load or init-program > > What mean the message “No valid state has been set by load or > init-program”? Wrong disk? Or try to boot form wrong / faulty partion? Yeah, that means that "load" couldn't locate a supported binary format to execute from the boot device. Sadly OpenBIOS doesn't (yet) boot from virtio devices, but you can boot from the CDROM in Linux and add a separate virtio drive to get extra speed if you really want to. Also I believe that Solaris has doesn't have virtio drivers anyway, so I don't think you'd manage to get far there either. To the best of my knowledge, only Linux and NetBSD support virtio devices on qemu-system-sparc64 to date. ATB, Mark.

2 years, 11 months

Re: [OpenBIOS] SunOS 5.8 64bit emulate SUNW, Ultra 2

by Mark Cave-Ayland

On 13/02/18 13:15, Weidemann, Maik (M-SO) wrote: Hi Maik, > Hello, > > I try do emulate / virtualize a very old Sun Workstation Ultra 2 with a SunOs 5.8 with KVM/qemu. > As host system I use a Ubuntu 17.10 with the qemu packages from http://ppa.launchpad.net/jacob/virtualisation/ubuntu. > The qemu Version is: > QEMU emulator version 2.11.0(Debian 1:2.11+dfsg-1ubuntu1~ppa0) > > I tried to start a virtual machine with the default bios (Version: 1.1.git20161120-2). But I get this error message: > # qemu-system-sparc64 -nographic -drive unit=1,file=sun14_disk.raw,format=raw > OpenBIOS for Sparc64 > set_property: NULL phandle > set_property: NULL phandle > Unhandled Exception 0x0000000000000030 > PC = 0x00000000ffd0f6b8 NPC = 0x00000000ffd0f6bc > Stopping execution Yes, unfortunately that combination of QEMU/OpenBIOS won't work because at the moment there is no way to pass the device tree from QEMU to OpenBIOS and so the two must generally be kept in sync. Hopefully this requirement will be something that can be relaxed in time. > I see that was some new commits at the git repository, so I clone the repo an build a new openbios-file (https://www.openbios.org/OpenBIOS#Building_OpenBIOS) an start the vm with this new bios. But I get also a error message: > # qemu-system-sparc64 -nographic -drive unit=1,file=sun14_disk.raw,format=raw -L . -bios openbios-builtin.elf > Unhandled Exception 0x0000000000000030 > PC = 0x00000000ffd21368 NPC = 0x00000000ffd2136c > Stopping execution Something definitely looks wrong there - for 2.11 have you tried grabbing the relevant OpenBIOS binary direct from git? It's available as a direct download from https://git.qemu.org/?p=qemu.git;a=blob;f=pc-bios/openbios-sparc64;h=a4a3b8…. > Is it even possible to emulate a Sun Sparc Ultra 2 with a SunOs 5.8 (64bit)? > SunOS satnw014 5.8 Generic_108528-06 sun4u sparc SUNW,Ultra-2 The default sun4u model emulates an Ultra 5, so assuming your image contains enough drivers then in theory you should be able to at least boot into the kernel and get somewhere close to userspace. To the best of my knowledge the main outstanding feature missing from the SPARC64 emulation preventing it from booting SunOS is the MMU IE bit which is required to program PCI devices. I suspect this will still be the case for SunOS 5.8. There has been a lot of work done over the past couple of releases to fix up all the PCI bridge issues so I would hope that getting qemu-system-sparc64 to boot Solaris 64-bit is now within reach, so watch this space :) ATB, Mark.

2 years, 11 months

SunOS 5.8 64bit emulate SUNW, Ultra 2

by Weidemann, Maik (M-SO)

Hello, I try do emulate / virtualize a very old Sun Workstation Ultra 2 with a SunOs 5.8 with KVM/qemu. As host system I use a Ubuntu 17.10 with the qemu packages from http://ppa.launchpad.net/jacob/virtualisation/ubuntu. The qemu Version is: QEMU emulator version 2.11.0(Debian 1:2.11+dfsg-1ubuntu1~ppa0) I tried to start a virtual machine with the default bios (Version: 1.1.git20161120-2). But I get this error message: # qemu-system-sparc64 -nographic -drive unit=1,file=sun14_disk.raw,format=raw OpenBIOS for Sparc64 set_property: NULL phandle set_property: NULL phandle Unhandled Exception 0x0000000000000030 PC = 0x00000000ffd0f6b8 NPC = 0x00000000ffd0f6bc Stopping execution I see that was some new commits at the git repository, so I clone the repo an build a new openbios-file (https://www.openbios.org/OpenBIOS#Building_OpenBIOS) an start the vm with this new bios. But I get also a error message: # qemu-system-sparc64 -nographic -drive unit=1,file=sun14_disk.raw,format=raw -L . -bios openbios-builtin.elf Unhandled Exception 0x0000000000000030 PC = 0x00000000ffd21368 NPC = 0x00000000ffd2136c Stopping execution Is it even possible to emulate a Sun Sparc Ultra 2 with a SunOs 5.8 (64bit)? SunOS satnw014 5.8 Generic_108528-06 sun4u sparc SUNW,Ultra-2 Best regards Maik

2 years, 11 months

Apple's BootX

by Jd Lyons

In an effort to figure out why qemu-system-ppc hangs at BootX when using some emulated and KVM CPU’s, I suppose it would be good to enter some breakpoints in the code. I found some BootX sources at: https://opensource.apple.com/tarballs/BootX/ <https://opensource.apple.com/tarballs/BootX/> Tho I’m not sure what versions correspond to which release of OS X? And it’s not clear how to build them, tho I haven’t tried yet. I found some info on BootX as well as some idea how to do what I’m looking to do: https://people.ffii.org/~zoobab/bh.udev.org/filez/apple/mac6100/BootX.pdf There are few other useful debugging tech- niques. Setting "auto-boot?" to false will cause the system to enter the OpenFirmware User In- terface by default. Changing kFailToBoot to 0 in include.tproj/sl.h will alter BootX’s default be- havior on error, so that it will return to Open- Firmware. Finally, calling Enter(), will cause BootX to drop back into the OpenFirmware User Interface. This can be used as a break point. The "dumpl" word will dump some memory, by en- tering the address, then the length, then "dumpl". By calling printf in BootX immediately before En- ter(), the address can be easily determined, and the variable can then be examined and altered from OpenFirmware. Finally typing the "go" command will resume BootX’s execution. I noted when I boot from boot usb0/disk:3,\\:tbxi while holding command+v BootX sends some info to the screen, seemingly via open firware, while displaying the “Apple Logo” boot graphic. The info show some of the boot process and what stage it’s loading” loading mach_kernel’ “ loading the .mkext” It would be nice to get this output going via Open Bios, if anyone has any idea how I might be able to do that?

2 years, 11 months