openbios / openbios Goto Github PK

First published Open Source implementation of OpenFirmware

License: GNU General Public License v2.0

Makefile 0.30% C 83.06% Forth 10.38% Assembly 4.51% C++ 0.39% QMake 0.04% Shell 0.44% XSLT 0.88% Ruby 0.01%

forth

openbios's Introduction

Welcome to OpenBIOS
-------------------

OpenBIOS is a free, portable implementation of IEEE 1275-1994 
(Open Firmware). Find detailed information about OpenBIOS at 
http://www.openbios.org/

What is OpenBIOS?
-----------------

OpenBIOS can replace your system firmware (BIOS) partly or completely. It
can also be used as a bootloader to create an Open Firmware compatible
interface between legacy firmware and an operating system.

This is achieved by a modular concept that consists of a portable Forth
kernel and three interfaces for user interaction, device initialization
and client (operating system) control.

While far not all possible applications of OpenBIOS are implemented yet,
a lot of functionality is already there. OpenBIOS can be used to enhance
LinuxBIOS (http://www.linuxbios.org), or be booted from any multiboot
capable bootloader to bring Open Firmware to your machine. OpenBIOS can
also be used when an operating system is already running. It provides
the needed OpenFirmware functionality to MOL (MacOnLinux) to boot MacOS
9 and X on PPC machines, as well as Linux (all supported platforms)

OpenBIOS build options
---------------------

   config/scripts/switch-arch <platform>  - build for specified platform
   					    Look in config/example for
					    platforms.

   make            - build all configured binaries

   make run        - run unix example.

   
How OpenBIOS works
------------------

 The OpenBIOS forth core is split into a forth kernel written in portable 
 C and a forth dictionary which operated on by the kernel.

 When building the forth core, you get different versions of
 the forth kernel: 

 * a unix executable program

   - to execute a forth dictionary from a file. This can be used for
     easily testing and developing OpenBIOS on a unix host.

   - to create a dictionary file. Such a dictionary file sets up
     all of the forth language. Primitives are indexed to save relocations.

     The default is to create a forth dictionary forth.dict from
     forth/start.fs. This file includes all of the basic forth language
     constructs from forth/bootstrap.fs and starts the interpreter.

     To achieve this, the hosted unix version contains a basic set of
     forth words coded in C that allow creating a full dictionary.

 * a varying number of target specific binaries. On x86 you can start 
   openbios for example from GRUB or LinuxBIOS. They are all based on
   the same forth engine consisting of a dictionary scheduler, primitive 
   words needed to build the forth environment, 2 stacks and a simple 
   set of console functions. These binaries can not be started directly
   in the unix host environment.

Requirements
------------
 * gcc
 * gnu make
 * OpenBIOS FCode Utils
   Download with svn co svn://openbios.org/openbios/fcode-utils
 * grub or any other multiboot loader to run the multiboot
   binary "openbios.multiboot" with it's module "openbios-<platform>.dict"
 * xsltproc
 
Building & Usage
----------------

 * make

   this builds "openbios.multiboot", the standalone image and "openbios-unix", 
   the hosted image. Additionally it creates a forth dictionary
   file from forth/start.fs. All generated files are written to 
   the absolute directory held by the variable BUILDDIR, which defaults
   to obj-[platform]. Some compile time parameters can be tweaked in
   include/config.h
   
 * use "openbios-unix" to create a forth dictionary on your own:
   $ obj-x86/openbios-unix -Iforth start.fs
   creates the file forth.dict from forth source forth/start.fs.

 * use "openbios-unix" to run a created dictionary: 
   $ obj-x86/openbios-unix obj-x86/openbios-unix.dict
   This is useful for testing
 
 * booting openbios
   You can boot openbios i.e. in grub. Add the following lines to
   your menu.lst:

    title openbios
      kernel (hd0,2)/boot/openbios.multiboot
      module (hd0,2)/boot/openbios-x86.dict

   Note: change (hd0,2) to the partition you copied the openbios image and
   openbios-x86.dict to.

   To boot OpenBIOS from LinuxBIOS/etherboot, you can either use
   "openbios-plain.elf" or "openbios-builtin.elf":

   - openbios-plain.elf is the pure kernel that loads the dictionary from a 
     hardcoded address in flash memory (0xfffe0000)

   - openbios-builtin.elf also includes the dictionary directly so that it
     can be easily used from etherboot or the LinuxBIOS builtin ELF
     loader without taking care of the dictionary

CREDITS
-------
OpenBIOS was developed by Stefan Reinauer, Samuel Rydh and Patrick Mauritz.
The OpenBIOS IDE driver was written by Jens Axboe.
For license details on this piece of software, see the file COPYING.


If you have patches, questions, comments, feel free to contact the OpenBIOS
mailinglist.

Regards,
     the OpenBIOS team

openbios's People

Contributors

Stargazers

Watchers

Forkers

mcayland legoater ozbenh davidgiven sfrias edwardbetts jameslinus rbarraud mmuszkow tonyho722 ericyao2013 zhoujk0520 jantatje sahni007 iam41xin structure-charger wnitbrrt faststarliu arjuncr resonancellc monty-pavel bdragon28 davidwu1999 anlaneg rokkubro nolancui abyssds chipsetx niwp zombydogs philmd jtlsq hnylcxq ra2003 pinpiew hummans christoferlv dgsga zanehenderson wangxianzhen gitboy129 jowinjohnchemban thoangtrvn chleroy 0xgpapad what-is-the-pc-doing dbc-chenf upwar aurxenon adityavs mafiaboys bitofhope aquaboxs daniel-yangdong vv2zp millak schwarzemann tadryanom ajgappmark b1ng05 xinjiezhu maoyuze nkunkee arryboom alxbnct jamestiotio manelpin sungog jevinskie w019746

openbios's Issues

ppc: block-size method failing and failing to read disk

QEMU: QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-11+deb11u2)
OpenBIOS: PPC debug build of latest v1.1 release in releases
GRUB ISO: grub.iso.gz
CMD: qemu-system-ppc -M mac99,via=pmu -nographic -drive file=luks.disk,media=disk,format=raw,if=ide,id=luks -nographic -monitor file:/dev/null -chardev stdio,mux=on,id=serdev -serial chardev:serdev -serial chardev:serdev --drive if=ide,media=cdrom,file=grub.iso -boot d
LUKS DISK: luks.disk.gz

This is a test GRUB test to verify decrypting contents from LUKS disk. I've truncated the LUKS disk image built by the test to 1M, but the failure is the same on the untruncated image.

kern/disk.c:196:disk: Opening `ieee1275/ide0'...
disk/ieee1275/ofdisk.c:472:disk: Opening `ide0'.
call-method block-size: exception -21 
>> call-method block-size failed with error ffffffdf
disk/ieee1275/ofdisk.c:724:disk: can't get block size: 1
kern/disk.c:386:disk: ieee1275/ide0 read failed
kern/disk.c:386:disk: ieee1275/ide0 read failed
kern/disk.c:299:disk: Closing `ieee1275/ide0'.
kern/disk.c:196:disk: Opening `ieee1275/ide0'...
disk/ieee1275/ofdisk.c:472:disk: Opening `ide0'.
kern/disk.c:386:disk: ieee1275/ide0 read failed
kern/disk.c:386:disk: ieee1275/ide0 read failed
kern/disk.c:386:disk: ieee1275/ide0 read failed
kern/disk.c:386:disk: ieee1275/ide0 read failed
kern/disk.c:386:disk: ieee1275/ide0 read failed
kern/disk.c:386:disk: ieee1275/ide0 read failed

There looks to be two issues here:

The block-size method is failing. I don't think this matters for the test to pass, but seems like a legitimate issue. By compiling with DEBUG_IDE, I see that the IDE openbios IDE code has a correct block size for both devices. And block-size is failing for both the CDROM and disk devices.

>> IDE - ob_ide_open: opening channel 0 unit 130654868
>> IDE DRIVE @7c9a294:
>> unit: 1
>> present: 1
>> type: 2
>> media: 5
>> model: QEMU DVD-ROM
>> nr: 1
>> cyl: 0
>> head: 0
>> sect: 0
>> bs: 2048
>> IDE - ob_ide_atapi_drive_ready: 
>> IDE - ob_ide_block_size: block size 800
>> IDE - ob_ide_max_transfer: max_transfer f800
call-method block-size: exception -21 
>> call-method block-size failed with error ffffffdf

>> IDE - ob_ide_open: opening channel 0 unit 130654788
>> IDE DRIVE @7c9a244:
>> unit: 0
>> present: 1
>> type: 1
>> media: 32
>> model: QEMU HARDDISK
>> nr: 0
>> cyl: 40
>> head: 16
>> sect: 63
>> bs: 512
>> IDE - ob_ide_block_size: block size 200
>> IDE - ob_ide_max_transfer: max_transfer 1fe00
call-method block-size: exception -21 
>> call-method block-size failed with error ffffffdf
disk/ieee1275/ofdisk.c:724:disk: can't get block size: 1

The read to ide0 is failing.

>> IDE - ob_ide_open: opening channel 0 unit 130654788
>> IDE DRIVE @7c9a244:
>> unit: 0
>> present: 1
>> type: 1
>> media: 32
>> model: QEMU HARDDISK
>> nr: 0
>> cyl: 40
>> head: 16
>> sect: 63
>> bs: 512
>> IDE - ob_ide_block_size: block size 200
>> IDE - ob_ide_max_transfer: max_transfer 1fe00
>> IDE - ob_ide_read_blocks: fffffcb8 block=0 n=1
>> IDE - ob_ide_read_sectors: block=0 sectors=1
>> MAC-PARTS: macparts_probe 4c55 ?= 4552
>> IDE - ob_ide_read_blocks: 7d18fcc block=2 n=2
>> IDE - ob_ide_read_sectors: block=2 sectors=2
>> IDE - ob_ide_read_blocks: 7d19404 block=2 n=2
>> IDE - ob_ide_read_sectors: block=2 sectors=2
>> IDE - ob_ide_read_blocks: 7d1983c block=2 n=2
>> IDE - ob_ide_read_sectors: block=2 sectors=2
>> IDE - ob_ide_read_blocks: fffff428 block=64 n=4
>> IDE - ob_ide_read_sectors: block=64 sectors=4
>> Unknown filesystem type
kern/disk.c:386:disk: ieee1275/ide0 read failed
kern/disk.c:299:disk: Closing `ieee1275/ide0'.
error: [12] can't open device.

The "Unknown filesystem type" leads me to suspect that the read is failing because OpenBIOS isn't detecting a known filesystem. And I see that OpenBIOS supports reading from various filesystems. I'm not sure why this should matter as GRUB should be reading from a block device and the firmware should not care if there is a valid filesystem there or not.

code where: the openbios can't boot kdump kernel

I am looking in the openbios source code, I want to find where refused the kdump kernel and how the openbios identify the kdump kernel? Please help me.

Build failure on linux-gnu-aarch64

Guix's openbios-qemu-ppc package currently fails to compile on aarch64 (64 bit arm). (Issue thread here.) After some investigation, it appears that the problem is that the eventual ./target/include/asm/types.h shadows <asm/types.h>, which is transitively included by <signal.h> on aarch64 (gcc version 10.3.0, linux headers 5.10.35). When the necessary types aren't available, the build fails.

The failing guix build log is attached: openbios-qemu-ppc-guix-build-log.txt; otherwise, I'm happy to post whatever other information I can.

qemuppc: Cannot manage 'undefined' PCI device type '<NULL>'

There is an annoying error message when run qemuppc with option "-device virtio-rng-pci":

>> Cannot manage 'undefined' PCI device type '<NULL>':
>>  1af4 1005 (0 ff 0)

We found this in yocto project and the detail logs:

$ runqemu qemuppc core-image-minimal nographic slirp
runqemu - INFO - Running MACHINE=qemuppc bitbake -e...
runqemu - INFO - Continuing with the following parameters:

KERNEL: [tmp/deploy/images/qemuppc/vmlinux]
MACHINE: [qemuppc]
FSTYPE: [ext4]
ROOTFS: [tmp/deploy/images/qemuppc/core-image-minimal-qemuppc.ext4]
CONFFILE: [/myproject/tmp/deploy/images/qemuppc/core-image-minimal-qemuppc.qemuboot.conf]

runqemu - INFO - Port forward: hostfwd=tcp::2222-:22 hostfwd=tcp::2323-:23
runqemu - INFO - Running tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin//qemu-system-ppc -device virtio-net-pci,netdev=net0,mac=52:54:00:12:35:02 -netdev user,id=net0,hostfwd=tcp::2222-:22,hostfwd=tcp::2323-:23,tftp=tmp/deploy/images/qemuppc -drive file=tmp/deploy/images/qemuppc/core-image-minimal-qemuppc.ext4,if=virtio,format=raw -show-cursor -usb -device usb-tablet -device virtio-rng-pci  -nographic -machine mac99 -cpu G4 -m 256 -serial mon:stdio -serial null -kernel tmp/deploy/images/qemuppc/vmlinux -append 'root=/dev/vda rw highres=off  console=ttyS0 mem=256M ip=dhcp console=tty console=ttyS0 '

C>> annot manage 'undefined' PCI device type '<NULL>':
>>  1af4 1005 (0 ff 0)

>> =============================================================
>> OpenBIOS 1.1 [Jul 13 2017 18:28]
>> Configuration device id QEMU version 1 machine id 1
>> CPUs: 1
>> Memory: 256M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,G4
milliseconds isn't unique.
Welcome to OpenBIOS v1.1 built on Jul 13 2017 18:28
>> [ppc] Kernel already loaded (0x01000000 + 0x00c1368c) (initrd 0x00000000 + 0x00000000)
>> [ppc] Kernel command line: root=/dev/vda rw highres=off  console=ttyS0 mem=256M ip=dhcp console=tty console=ttyS0
----snip----

It was reported in Yocto but is suggested to be reported in openbios:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12209

Comments from yocto:

Saul Wold 2017-10-17 22:35:29 UTC

After messing around with qemu source and enabling qemu tracing, I am convinced that the problem > here is the openbios when it enumerates the PCI devices, it does find the VIRTIO_RNG device in it's
tables.

Currently, the openbios code is not rebuilt, we purely use the upstream binary from the qemu tarball. > An entry would be needed in the pci_database.c code in the rom/openbios code for the Virtio_rng.

I did verify via the tracing, that while the openbios does not know how to handle the virtio-rng PCI > entry, the kernel correctly identifies it and I see correct tracing output when the device is accessed.

I would suggest you report it upstream and then close this bug as reported upstream.

openbios wrongly considers e300 core as a 64 bits CPU

openbios replaces rfi by rfid on e300 processors, leading to program check exception.

Following function seems wrong, the pvr for CPUs with e300 core are inside the range

static int is_ppc64(void)
{
#ifdef __powerpc64__
    return 1;
#elif defined(CONFIG_PPC_64BITSUPPORT)
    unsigned int pvr = mfpvr();
    return ((pvr >= 0x330000) && (pvr < 0x70330000));
#else
    return 0;
#endif
}

$ qemu-system-ppc -cpu help | grep -e mpc83 -e e300
PowerPC mpc8343          PVR 00830010
PowerPC mpc8349a         PVR 00830010
PowerPC mpc8347at        PVR 00830010
PowerPC mpc8347a         (alias for mpc8347at)
PowerPC e300c1           PVR 00830010
PowerPC mpc8343ea        PVR 00830010
PowerPC mpc8349e         PVR 00830010
PowerPC mpc8347ep        PVR 00830010
PowerPC mpc8347p         PVR 00830010
PowerPC mpc8347eap       PVR 00830010
PowerPC mpc8349          PVR 00830010
PowerPC mpc8347et        PVR 00830010
PowerPC mpc8347e         (alias for mpc8347et)
PowerPC mpc8347t         PVR 00830010
PowerPC mpc8347          (alias for mpc8347t)
PowerPC mpc8343a         PVR 00830010
PowerPC mpc8347eat       PVR 00830010
PowerPC mpc8347ea        (alias for mpc8347eat)
PowerPC mpc8347ap        PVR 00830010
PowerPC mpc8349ea        PVR 00830010
PowerPC mpc8343e         PVR 00830010
PowerPC e300c2           PVR 00840010
PowerPC e300c3           PVR 00850010
PowerPC e300             (alias for e300c3)
PowerPC mpc8379e         PVR 00860010
PowerPC e300c4           PVR 00860010
PowerPC mpc8377e         PVR 00860010
PowerPC mpc8377          PVR 00860010
PowerPC mpc8378          PVR 00860010
PowerPC mpc8379          PVR 00860010
PowerPC mpc8378e         PVR 00860010

sparc64: GRUB causes Unhandled Exception in firmware

QEMU: QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-11+deb11u2)
OpenBIOS: Sparc64 debug build of latest v1.1 release in releases
GRUB ISO: grub.iso.gz

Here's the initial output from OpenBIOS:

OpenBIOS for Sparc64
Configuration device id QEMU version 1 machine id 0
kernel cmdline 
CPUs: 1 x SUNW,UltraSPARC-IIi
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.1 built on Jan 31 2023 22:09
  Type 'help' for detailed information
Trying cdrom:f...
Trying cdrom...
Not a bootable ELF image
Loading a.out image...
Loaded 7680 bytes
entry point is 0x4000
GRUB call-method color!: exception -21 
call-method color! failed with error ffffffffffffffdf
call-method color!: exception -21

Here is the last many lines when running the GRUB iso in qemu:

kern/ieee1275/openfw.c:57:devalias: device path=/virtual-memory
kern/ieee1275/openfw.c:90:devalias: iterating children of /virtual-memory
kern/ieee1275/openfw.c:57:devalias: device path=/pci@1fe,0
kern/ieee1275/openfw.c:90:devalias: iterating children of /pci@1fe,0
kern/ieee1275/openfw.c:57:devalias: device path=/pci@1fe,0/pci@1,1
kern/ieee1275/openfw.c:90:devalias: iterating children of /pci@1fe,0/pci@1,1
kern/ieee1275/openfw.c:57:devalias: device path=/pci@1fe,0/pci@1,1/ebus@1
kern/ieee1275/openfw.c:90:devalias: iterating children of /pci@1fe,0/pci@1,1/ebus@1
kern/ieee1275/openfw.c:57:devalias: device path=/pci@1fe,0/pci@1,1/ebus@1/eeprom@0
kern/ieee1275/openfw.c:90:devalias: iterating children of /pci@1fe,0/pci@1,1/ebus@1/eeprom@0
kern/ieee1275/openfw.c:57:devalias: device path=/pci@1fe,0/pci@1,1/ebus@1/power@0
kern/ieee1275/openfw.c:90:devalias: iterating children of /pci@1fe,0/pci@1,1/ebus@1/power@0
kern/ieee1275/openfw.c:57:devalias: device path=/pci@1fe,0/pci@1,1/ebus@1/fdthree@0
Unhandled Exception 0x0000000000000030
PC = 0x00000000ffd164c8 NPC = 0x00000000ffd164cc
Stopping execution

Command to reproduce the issue:
qemu-system-sparc64 -no-reboot -nographic -monitor file:/dev/null -serial file:/dev/stdout -cdrom grub.iso -boot d -bios ./openbios-multiarch-latest.zip.d/debug/obj-sparc64/openbios-builtin.elf

The exception happens on an open call into the firmware with path /pci@1fe,0/pci@1,1/ebus@1/fdthree@0. I've followed execution into the forth interpreter and then gave up. It looks like its an issue opening the floppy device, but I've not told QEMU to have anything in the floppy.

Here's a log file of a build from master with some debugging options enabled: grub-openbios-crash.log.gz

Bootlin toolchains build OpenBIOS on Sparc64, but cause QEMU to immediately abort

These (and possibly all the others) bootlin cross compile toolchains for sparc64 successfully compile OpenBIOS, but get the following QEMU abort: sparc64--glibc--stable-2021.11-1 (GCC 10.3.0), sparc64--glibc--stable-2021.11-1.

qemu: fatal: Trap 0x0064 while trap level (5) >= MAXTL (5), Error state
pc: 0000000000004c80  npc: 0000000000004c84
%g0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%g4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%o0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
%o4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
%l0-3: 0000000007f001d8 000001ff00000000 000001fff0080000 0000000000000000 
%l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
%i0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
%i4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
%f00:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f08:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f16:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f24:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f32:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f40:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f48:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f56:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
pstate: 00000414 ccr: 44 (icc: -Z-- xcc: -Z--) asi: 00 tl: 5 pil: 0 gl: 2
tbr: 0000000000000000 hpstate: 0000000000000000 htba: 0000000000000000
cansave: 6 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 7
fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000

Aborted

The toolchain GCC 10.3.0 toolchain from kernel.org runs fine in QEMU. While this is likely an issue with bootlin's build. I create this issue here for others who might run into this issue.

Compiling problem

make
/usr/bin/xsltproc
Building OpenBIOS for amd64
Building...
error:
make[1]: Entering directory '/tmp/openbios/obj-amd64'
CC target/arch/unix/unix.o
/tmp/openbios/arch/unix/unix.c: In function ‘read_from_disk’:
/tmp/openbios/arch/unix/unix.c:420:2: error: ignoring return value of ‘read’, declared with attribute warn_unused_result [-Werror=unused-result]
read(diskemu, buf, size);
^~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
rules.mak:209: recipe for target 'target/arch/unix/unix.o' failed
make[1]: *** [target/arch/unix/unix.o] Error 1
make[1]: Leaving directory '/tmp/openbios/obj-amd64'
Makefile:19: recipe for target 'build' failed
make: *** [build] Error 1

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.4.0-1ubuntu118.04.1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu118.04.1)

openbios / openbios Goto Github PK

openbios's Introduction

openbios's People

Contributors

Stargazers

Watchers

Forkers

openbios's Issues

ppc: block-size method failing and failing to read disk

code where: the openbios can't boot kdump kernel

Build failure on linux-gnu-aarch64

qemuppc: Cannot manage 'undefined' PCI device type '<NULL>'

openbios wrongly considers e300 core as a 64 bits CPU

sparc64: GRUB causes Unhandled Exception in firmware

Bootlin toolchains build OpenBIOS on Sparc64, but cause QEMU to immediately abort

Compiling problem

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent