OpenBIOS

openbios@openbios.org

4289 discussions

Start a nNew thread

The question ?
by Hacker 22 Feb '17

22 Feb '17

Where the tutorial to install openbios. Thanks

2 1

Detoke and the Openbios video console driver?
by Jd Lyons 19 Feb '17

19 Feb '17

I’ve been trying to add graphics acceleration to Qume-PPC and have a few questions about how Open Bios deals with FCode option roms. I noticed when I build Openbios, it creates a file called QEMU,VGA.bin. Is this file the video console driver for Openbios? I’d like to replace it with an FCode option rom from one of the proprietary Video cards supported by the Mac OS, is this feasible? What parts of Openbios would need to be changed to support proprietary FCode option roms from cards like the ATI,Rage 128 Pro? Would I need to rewrite some part of Openbios to support the VGA? The file QEMU,VGA doesn’t appear to be Tokenized, can Openbios deal with Tokenized option roms, or do I need to pass it a Detokenized Rom? I noticed Fcode-Utils has a detoke tool, I’d like to use it to detoke FCode roms, but I’m not sure of it’s usage, do I need to remove the PCI Header from the FCode rom? If so, how long is the header, is it a standard length, or does it vary from Rom to Rom? Thanks, JD

3 2

[PATCH 3/4 v3] arch/ppc/qemu: Add a node for the other (empty) PCI bus to the device tree
by BALATON Zoltan 15 Feb '17

15 Feb '17

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 workaround for this to be reverted. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- arch/ppc/qemu/init.c | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) v3: Move device tree patching in its own function and call it from init (otherwise same as v2, take which you like) v2: Move to init.c from tree.fs and only add it for mac99 Patches 1 and 2 from original series https://www.coreboot.org/pipermail/openbios/2016-November/009825.html https://www.coreboot.org/pipermail/openbios/2016-November/009824.html are still valid and needed, patch 4 was already applied so only this one (3/4) is resent but 1 and 2 should be applied as well with this. diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index ffbf08d..46a56a0 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -668,6 +668,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 -- ) */ @@ -755,6 +797,7 @@ arch_of_init(void) openbios_init(); modules_init(); setup_timers(); + empty_pci_bus_init(); #ifdef CONFIG_DRIVER_PCI ob_pci_init(); #endif -- 2.7.4

2 3

[PATCH] mac-parts.c: restrict checking of partition status flags to CHRP partitions only
by Mark Cave-Ayland 13 Feb '17

13 Feb '17

Early versions of MacOS X don't correctly set the partition status flags when creating the OS partition. Relax the status flag checks so they are only applied to CHRP partitions which allows us to both meet the intention of the CHRP specification and also enable OpenBIOS to boot OS partitions from OSs such as MacOS X DPs. With thanks to Steven Troughton-Smith <steve(a)highcaffeinecontent.com> for the in-depth investigation. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- packages/mac-parts.c | 41 +++++++++++++++++++---------------------- 1 file changed, 19 insertions(+), 22 deletions(-) diff --git a/packages/mac-parts.c b/packages/mac-parts.c index 16c87ca..d4faf71 100644 --- a/packages/mac-parts.c +++ b/packages/mac-parts.c @@ -158,32 +158,31 @@ macparts_open( macparts_info_t *di ) DPRINTF("found partition %d type: %s with status %x\n", i, par.pmPartType, __be32_to_cpu(par.pmPartStatus)); + /* Unfortunately Apple's OF implementation doesn't follow the OF PowerPC CHRP bindings + * and instead will brute-force boot the first valid partition it finds with a + * type of either "Apple_Boot", "Apple_HFS" or "DOS_FAT_". Here we store the id + * of the first partition that matches these criteria to use as a fallback later + * if required. */ + if (apple_parnum == -1 && + (strcmp(par.pmPartType, "Apple_Boot") == 0 || + strcmp(par.pmPartType, "Apple_Bootstrap") == 0 || + strcmp(par.pmPartType, "Apple_HFS") == 0 || + strcmp(par.pmPartType, "DOS_FAT_") == 0)) { + apple_parnum = i; + + DPRINTF("Located Apple OF fallback partition %d\n", apple_parnum); + } + /* If we have a valid, allocated and readable partition... */ if( (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsValid) && - (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsAllocated) && - (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsReadable) ) { - - /* Unfortunately Apple's OF implementation doesn't follow the OF PowerPC CHRP bindings - * and instead will brute-force boot the first valid partition it finds with a - * type of either "Apple_Boot", "Apple_HFS" or "DOS_FAT_". Here we store the id - * of the first partition that matches these criteria to use as a fallback later - * if required. */ - - if (apple_parnum == -1 && - (strcmp(par.pmPartType, "Apple_Boot") == 0 || - strcmp(par.pmPartType, "Apple_Bootstrap") == 0 || - strcmp(par.pmPartType, "Apple_HFS") == 0 || - strcmp(par.pmPartType, "DOS_FAT_") == 0)) { - apple_parnum = i; - - DPRINTF("Located Apple OF fallback partition %d\n", apple_parnum); - } + (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsAllocated) && + (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsReadable) ) { /* If the partition is also bootable and the pmProcessor field matches "PowerPC" (insensitive * match), then according to the CHRP bindings this is our chosen partition */ for (j = 0; j < strlen(par.pmProcessor); j++) { par.pmProcessor[j] = tolower(par.pmProcessor[j]); - } + } if ((__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsBootValid) && strcmp(par.pmProcessor, "powerpc") == 0) { @@ -225,8 +224,7 @@ macparts_open( macparts_info_t *di ) if(! ((__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsValid) && (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsAllocated) && (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsReadable)) ) { - DPRINTF("Partition %d is not valid, allocated and readable\n", parnum); - goto out; + DPRINTF("WARNING: Partition %d is not valid, allocated and readable\n", parnum); } ret = -1; @@ -235,7 +233,6 @@ macparts_open( macparts_info_t *di ) size = (long long)__be32_to_cpu(par.pmPartBlkCnt) * bs; if (want_bootcode) { - /* If size == 0 then fail because we requested bootcode but it doesn't exist */ size = (long long)__be32_to_cpu(par.pmBootSize); if (!size) { -- 1.7.10.4

1 1

Re: [OpenBIOS] Beginners How-To for DTS and OpenFirmware?
by Michael 13 Feb '17

13 Feb '17

Hello Zoltan, hey list, On Mon, Nov 21, 2016 at 07:15:21PM +0100, BALATON Zoltan wrote: > ... > For forth commands I've found this page useful (not sure if this is linked > from somewhere): > http://www.firmworks.com/QuickRef.html Thank you, I found this (and more) last week. The OLPC sites are the best for me: 1: http://wiki.laptop.org/go/Open_Firmware 2: http://wiki.laptop.org/go/Forth_Lessons 3: http://wiki.laptop.org/go/Cross_Compiling_Open_Firmware > ... > This is a bit confusing. There are multiple implementations of the IEEE > standard (commonly referred to as Open Firmware) and one of these is also > called Open Firmware. These are listed under Implementations on the left of > the page at www.openfirmware.info. Another implementation used by QEMU for Yes and I looked at them. But they are either very old or not usable for ppc (too much work to implement a new arch). > ... > talking about Open Firmware: the standard or the implementation with the > same name. One thing is left which confuses me: In wikipedia and you say, that you use the name "Open Firmware" (also, besides as name for a standard) for an implementation. OK. But the website gives the impression (and G 3 says), that the implementation has the name "OpenBIOS"... So I have two statements which don't fit well. Please remember that I am new to this and did not live through the history. > ... > Actually running OpenBIOS on real hardware is not something that is well > tested (I'm not sure if it was ever tried but I think it wasn't done > recently) so if you try to do that be prepared for likely needing some The OLPC project did it, e.g. > fixing. This is true for any implementation that does not support the > hardware you want to run it on, then you likely need to port it. That there will be the need for porting was clear. > ... > it's enough to have the basics in there. Not sure how much up to date is > this but this is discussed in the kernel documentation here: > https://www.kernel.org/doc/Documentation/devicetree/booting-without-of.txt > Thank you, I missed this source. > As for giving the device tree to OpenBIOS I think it should just know it or > construct it from discovering the hardware as the point of the device tree > is to describe the hardware for the operating system so the firmware should > know the hardware and provide the device tree. It does not get it from The "firmware" is our handmade init-assemblercode. It has to enable the machine (beginning from Adam...) to run C-code in its RAM. If there is no software-interface, then we provide the device-tree maybe in forth or in a blob. Just thinking loudly. > ... > In fact OpenBIOS does not have that many drivers but maybe the basics are > there, only the platform specific init code might need to be adapted for a That would be very nice. We give it a try. Maybe with help from you / the list. > new board. For ppc these would be in arch/ppc. Running on QEMU is quite a > bit simpler as we can skip a lot of init code (such as memory controller or > other hardware) so maybe these are not well implemented or buggy as they > were not tested with real hardware for a while. > ... Did you use OpenBIOS in a recent qemu and have you been able to remote-debug it there? I was able to load and run the old OpenBIOS code (from svn repo) on "qemu-system-ppc". Thank you for your time and suggestions, greetings, Michael

7 10

[PATCH 3/4 v2] arch/ppc/qemu: Add a node for the other (empty) PCI bus to the device tree
by BALATON Zoltan 27 Jan '17

27 Jan '17

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 workaround for this to be reverted. Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- arch/ppc/qemu/init.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) v2: Move to init.c from tree.fs and only add it for mac99 Patches 1 and 2 from original series https://www.coreboot.org/pipermail/openbios/2016-November/009825.html https://www.coreboot.org/pipermail/openbios/2016-November/009824.html are still valid and needed, patch 4 was already applied so only this one (3/4) is resent but 1 and 2 should be applied as well with this. diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index ffbf08d..629d71b 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -755,6 +755,44 @@ arch_of_init(void) openbios_init(); modules_init(); setup_timers(); + 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(); + } #ifdef CONFIG_DRIVER_PCI ob_pci_init(); #endif -- 2.7.4

2 2

SPARC32 : SMP
by Olivier Danet 27 Jan '17

27 Jan '17

I splitted the patch. It was tested with an old Linux distro (RH 4.2) and with NetBSD. The SMP kernel must be selected during install. Here is, for example, a NetBSD/sparc32 image with SMP enabled : temlib.org/pub/net702.qcow.bz2 qemu-system-sparc net702.qcow -M SS-20 -vga cg3 -smp 2 This SMP mode used to work a while ago, but it has so far no practical purpose as enabling it slows down QEMU considerably.

2 1

ping: vga patch
by G 3 13 Jan '17

13 Jan '17

Hi, I was wondering if you could manage to look at my vga patch.

1 0

[PATCH 2/2] SPARC32 : Fix SMP boot
by Olivier Danet 09 Jan '17

09 Jan '17

Only the first CPU shall clear the RAM. Signed-off-by: Olivier Danet <odanet(a)caramail.com> --- arch/sparc32/entry.S | 31 ++++++++++++------------------- 1 file changed, 12 insertions(+), 19 deletions(-) diff --git a/arch/sparc32/entry.S b/arch/sparc32/entry.S index 7dc9fc8..74841c5 100644 --- a/arch/sparc32/entry.S +++ b/arch/sparc32/entry.S @@ -126,6 +126,17 @@ entry: or %g3, %g4, %g1 ! %g1 contains end of memory + ! Get CPU number + ! XXX: not all CPUs should have MXCC + set 0x1c00f00, %g2 + ldda [%g2] ASI_CONTROL, %g2 + srl %g3, 24, %g7 + subcc %g7, 8, %g7 + + ! Only the first CPU clears memory + bnz clear_done + nop + ! Get kernel address from configuration device ! NB: little endian format mov FW_CFG_KERNEL_ADDR, %g2 @@ -168,23 +179,6 @@ clear_done: set 0x2000, %g3 sub %g1, %g3, %g6 - ! Check if this is the boot CPU and skip SMP table check if yes - ! XXX: not all CPUs should have MXCC - set 0x1c00f00, %g2 - ldda [%g2] ASI_CONTROL, %g2 - srl %g3, 24, %g7 - sub %g7, 8, %g7 - tst %g7 - bz skip_table - nop - - ! Calculate SMP table location - set 0x1f0c, %g2 - add %g6, %g2, %g2 ! valid? - lda [%g2] ASI_M_BYPASS, %g7 - sta %g0, [%g2] ASI_M_BYPASS - -skip_table: ! Get machine ID from configuration device mov FW_CFG_MACHINE_ID, %g2 sub %g5, 2, %g5 @@ -217,14 +211,13 @@ ss10: ! Clear softints used for SMP CPU startup set PHYS_SS10_INTR0 + 0x04, %g1 - sll %g2, 12, %g2 + sll %g7, 12, %g2 add %g1, %g2, %g2 set 0xffffffff, %g1 sta %g1, [%g2] ASI_M_CTL ! clear softints add %g2, 4, %g2 sta %g0, [%g2] ASI_M_CTL ! clear softints -load_ctx: ! SMP init, jump to user specified address set 0x1f04, %g5 add %g6, %g5, %g5 ! ctxtbl -- 2.7.4

1 0

[PATCH 1/2] SPARC32: Remove SMP detection for SS-5
by Olivier Danet 09 Jan '17

09 Jan '17

SparcStation 5 can only use one CPU. Signed-off-by: Olivier Danet <odanet(a)caramail.com> --- arch/sparc32/entry.S | 36 ++++++++++++------------------------ 1 file changed, 12 insertions(+), 24 deletions(-) diff --git a/arch/sparc32/entry.S b/arch/sparc32/entry.S index 82aa88e..7dc9fc8 100644 --- a/arch/sparc32/entry.S +++ b/arch/sparc32/entry.S @@ -179,7 +179,7 @@ clear_done: nop ! Calculate SMP table location - set 0x1f0c, %g2 + set 0x1f0c, %g2 add %g6, %g2, %g2 ! valid? lda [%g2] ASI_M_BYPASS, %g7 sta %g0, [%g2] ASI_M_BYPASS @@ -205,36 +205,40 @@ skip_table: blu ss2 nop - ! Ok, this is SS-5 + ! Ok, this is SS-5, uniprocessor + ba first_cpu + nop +ss10: + ! Ok, this is SS-10/20 or SS-600MP tst %g7 bz first_cpu nop ! Clear softints used for SMP CPU startup - set PHYS_JJ_INTR0 + 0x04, %g1 + set PHYS_SS10_INTR0 + 0x04, %g1 sll %g2, 12, %g2 add %g1, %g2, %g2 set 0xffffffff, %g1 - sta %g1, [%g2] ASI_M_BYPASS ! clear softints + sta %g1, [%g2] ASI_M_CTL ! clear softints add %g2, 4, %g2 - sta %g0, [%g2] ASI_M_BYPASS ! clear softints + sta %g0, [%g2] ASI_M_CTL ! clear softints load_ctx: ! SMP init, jump to user specified address - set 0x1f04, %g5 + set 0x1f04, %g5 add %g6, %g5, %g5 ! ctxtbl lda [%g5] ASI_M_BYPASS, %g2 sta %g0, [%g5] ASI_M_BYPASS set AC_M_CTPR, %g1 sta %g2, [%g1] ASI_M_MMUREGS ! set ctx table ptr - set 0x1f00, %g5 + set 0x1f00, %g5 add %g6, %g5, %g5 ! ctx lda [%g5] ASI_M_BYPASS, %g2 sta %g0, [%g5] ASI_M_BYPASS set AC_M_CXR, %g1 sta %g2, [%g1] ASI_M_MMUREGS ! set context - set 0x1f08, %g5 + set 0x1f08, %g5 add %g6, %g5, %g5 ! entry lda [%g5] ASI_M_BYPASS, %g2 sta %g0, [%g5] ASI_M_BYPASS @@ -242,22 +246,6 @@ load_ctx: jmp %g2 ! jump to kernel sta %g1, [%g0] ASI_M_MMUREGS ! enable mmu -ss10: - ! Ok, this is SS-10 or SS-600MP - tst %g7 - bz first_cpu - nop - - ! Clear softints used for SMP CPU startup - set PHYS_SS10_INTR0 + 0x04, %g1 - sll %g2, 12, %g2 - add %g1, %g2, %g2 - set 0xffffffff, %g1 - sta %g1, [%g2] ASI_M_CTL ! clear softints - add %g2, 4, %g2 - b load_ctx - sta %g0, [%g2] ASI_M_CTL ! clear softints - ss2: ! Ok, this is SS-2 set ss2_error, %o2 -- 2.7.4

1 0

Jump to page: