OpenBIOS

openbios@openbios.org

4289 discussions

Re: [OpenBIOS] Porting to custom board
by Mark Cave-Ayland 29 Nov '17

29 Nov '17

On 28/11/17 20:45, Max Ruttenberg wrote: > Hi all, > > I'm interested in porting openbios to a board with QorIQ ppce5500 > processor. The board currently uses U-Boot as its primary and > secondary boot loader. > > Is it possible to boot into an openbios image from U-Boot? > Is there a porting guide? Hi Max, Building OpenBIOS generates an ELF image, so if you can include an ELF payload then this should be possible. Regarding porting to a new board, I wrote some notes last year in response to a similar query at https://mail.coreboot.org/pipermail/openbios/2016-November/009837.html which you may find useful. Hopefully that gives you a good starting point, and feel free to ask any further questions you may have on list (posts are moderated by default unless you are a list member). ATB, Mark.

1 0

Porting to custom board
by Max Ruttenberg 28 Nov '17

28 Nov '17

Hi all, I'm interested in porting openbios to a board with QorIQ ppce5500 processor. The board currently uses U-Boot as its primary and secondary boot loader. Is it possible to boot into an openbios image from U-Boot? Is there a porting guide? Thank you, Max

1 0

Re: [OpenBIOS] Where is the issue tracker?
by Mark Cave-Ayland 09 Nov '17

09 Nov '17

On 07/11/17 02:23, Huang, Jie (Jackie) wrote: > Hi, > > I wanted to report an issue for openbios but failed to access the issue tracker: > > https://tracker.coreboot.org/trac/openbios > > Is this the correct issue tracker openbios is using? > > I found openbios is also in github, so I reported the issue there instead(but it > doesn't seem to be the correct one, there is 0 issue before I reported): > https://github.com/openbios/openbios/issues/2 > > Thanks, > Jackie Hi Jackie, The official OpenBIOS bug tracker moved to github a while back, so the above link is no longer correct. I updated the OpenBIOS wiki at https://www.openfirmware.info/OpenBIOS to reflect the new link *within* the page, however I don't currently have access to the link in the sidebar which might be where the confusion comes from. I'll see if I can talk to someone to get this fixed. Thanks for reporting the issue, I will try and take a look at this later. ATB, Mark.

2 1

Where is the issue tracker?
by Huang, Jie (Jackie) 07 Nov '17

07 Nov '17

Hi, I wanted to report an issue for openbios but failed to access the issue tracker: https://tracker.coreboot.org/trac/openbios Is this the correct issue tracker openbios is using? I found openbios is also in github, so I reported the issue there instead(but it doesn't seem to be the correct one, there is 0 issue before I reported): https://github.com/openbios/openbios/issues/2 Thanks, Jackie

1 0

[PATCH 0/3] SPARC64: update to simba PCI bridge configuration
by Mark Cave-Ayland 15 Oct '17

15 Oct '17

It looks as if the sun4u sabre/simba patchset is close to being merged into QEMU, so here are the related changes queued for OpenBIOS. All of the patches except the last have previously been posted on-list. Since QEMU freeze is coming up soon I plan to apply these as soon as possible once the QEMU changes land upstream. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (3): SPARC64: switch to simba PCI bridge machine configuration pci: set cmd646 name and device_type properties to "ide" pci: set sunhme name to "network" arch/sparc64/openbios.c | 2 +- drivers/pci.c | 22 ++++++++++++++-------- drivers/pci_database.c | 4 ++-- 3 files changed, 17 insertions(+), 11 deletions(-) -- 1.7.10.4

1 3

[PATCH] pci: add PCI bridge support for 32-bit PCI IO address spaces
by Mark Cave-Ayland 30 Sep '17

30 Sep '17

Make sure that we set the upper 16-bits of the IO address for both the PCI IO base and PCI IO limit registers. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- drivers/pci.c | 3 +++ drivers/pci.h | 2 ++ 2 files changed, 5 insertions(+) diff --git a/drivers/pci.c b/drivers/pci.c index 265ab0c..672dcd0 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -1494,6 +1494,7 @@ static void ob_configure_pci_bridge(pci_addr addr, /* Set the base limit registers */ pci_config_write16(addr, PCI_MEMORY_BASE, ((*mem_base >> 16) & ~(0xf))); + pci_config_write16(addr, PCI_IO_BASE_UPPER, (*io_base >> 16)); pci_config_write8(addr, PCI_IO_BASE, ((*io_base >> 8) & ~(0xf))); /* Always ensure legacy ioports are accessible during enumeration. @@ -1501,6 +1502,7 @@ static void ob_configure_pci_bridge(pci_addr addr, the configuration process, so we allow them during the secondary bus scan and then set the correct IO limit below. */ io_scan_limit = *io_base + (0xffff - *io_base); + pci_config_write16(addr, PCI_IO_LIMIT_UPPER, (io_scan_limit >> 16)); pci_config_write8(addr, PCI_IO_LIMIT, (io_scan_limit >> 8) & ~(0xf)); /* make pci bridge parent device, prepare for recursion */ @@ -1535,6 +1537,7 @@ static void ob_configure_pci_bridge(pci_addr addr, /* Set the limit registers */ pci_config_write16(addr, PCI_MEMORY_LIMIT, (((*mem_base - 1) >> 16) & ~(0xf))); + pci_config_write16(addr, PCI_IO_LIMIT_UPPER, ((*io_base - 1) >> 16)); pci_config_write8(addr, PCI_IO_LIMIT, (((*io_base - 1) >> 8) & ~(0xf))); /* Disable unused address spaces */ diff --git a/drivers/pci.h b/drivers/pci.h index ea70e8a..883a531 100644 --- a/drivers/pci.h +++ b/drivers/pci.h @@ -47,7 +47,9 @@ #define PCI_BASE_ADDR_5 0x24 #define PCI_IO_BASE 0x1c +#define PCI_IO_BASE_UPPER 0x30 #define PCI_IO_LIMIT 0x1d +#define PCI_IO_LIMIT_UPPER 0x32 #define PCI_MEMORY_BASE 0x20 #define PCI_MEMORY_LIMIT 0x22 -- 1.7.10.4

1 1

[PATCH] package.fs: don't reveal interposed packages
by Mark Cave-Ayland 22 Sep '17

22 Sep '17

The IEEE-1275 interpose specification suggests that interposed packages should not be visible unless an interpose-aware Forth word is used. Commit 247c6169 "Fix for interpose problem" realised this by converting the romvec obp_inst2pkg() function over to use ihandle>non-interposed-phandle but didn't make the same change to the equivalent CIF call instance-to-path (which is presumably correct since the interpose specification also states that interposed packages are only visible to a new instance-to-interposed-path CIF call). Here we add a new instance-to-package word as a wrapper to ihandle>non-interposed-phandle and update obp_inst2pkg() and instance-to-path to use it accordingly. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- arch/sparc32/romvec.c | 2 +- forth/device/package.fs | 4 ++++ forth/system/ciface.fs | 2 +- 3 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/sparc32/romvec.c b/arch/sparc32/romvec.c index 8757c28..7a01035 100644 --- a/arch/sparc32/romvec.c +++ b/arch/sparc32/romvec.c @@ -372,7 +372,7 @@ int obp_inst2pkg(int dev_desc) int ret; PUSH(dev_desc); - fword("ihandle>non-interposed-phandle"); + fword("instance-to-package"); ret = POP(); DPRINTF("obp_inst2pkg(fd 0x%x) = 0x%x\n", dev_desc, ret); diff --git a/forth/device/package.fs b/forth/device/package.fs index d5b52c3..3056c1d 100644 --- a/forth/device/package.fs +++ b/forth/device/package.fs @@ -32,6 +32,10 @@ >in.device-node @ ; +: instance-to-package ( ihandle -- phandle ) + dup 0<> if ihandle>non-interposed-phandle then +; + : ihandle>phandle ( ihandle -- phandle ) >in.device-node @ ; diff --git a/forth/system/ciface.fs b/forth/system/ciface.fs index 85a6076..9dc433c 100644 --- a/forth/system/ciface.fs +++ b/forth/system/ciface.fs @@ -159,7 +159,7 @@ external ; : instance-to-package ( ihandle -- phandle ) - ?ihandle ihandle>phandle + ?ihandle instance-to-package ; : package-to-path ( buflen buf phandle -- length ) -- 1.7.10.4

2 4

[PATCH 0/6] Improve network device support (with a bit of PCI map work)
by Mark Cave-Ayland 10 Sep '17

10 Sep '17

Now that QEMU 2.10 is out, here's the next set of patches in preparation for improving the NIC support for PPC Mac machines (sungem) and sun4u machines (sunhme). Also included is a little rework of the Forth ob_pci_bus_map_in() so PCI BARs can be mapped within the various _cb C functions which is needed to extract the MAC address from the sungem hardware and add it to the DT. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Mark Cave-Ayland (6): pci: move pci_decode_pci_addr() towards the top of pci.c pci: split the PCI mapping code out of ob_pci_bus_map_in() into ob_pci_map() pci: add basic support for Apple SunGEM pci: add ob_pci_unmap() to unmap PCI memory pci: add SUN hme network device pci: add Intel e1000 network device to PCI database drivers/pci.c | 134 ++++++++++++++++++++++++++++++++++-------------- drivers/pci_database.c | 18 +++++++ drivers/pci_database.h | 2 + include/drivers/pci.h | 3 ++ 4 files changed, 118 insertions(+), 39 deletions(-) -- 1.7.10.4

1 7

System Health Monitoring and current build compatibility
by Rohret, David M 12 Aug '17

12 Aug '17

Greetings, I have a project to monitor the voltage from a mainboards power conditioner and trigger a warning when it exceeds normal parameters by more than 7%. Commercial bios dev teams are reluctant to divulge any information, so I would like to install my own instance to do the job. I have 1 quick and 1 not so quick questions: 1. ??I'm not confined to a specific motherboard, so I would like to use one that is compatible with the latest build of OpenBios; suggestions? 2. If anyone has dealt with system health, any suggestions where to start? I appreciate any help! Dave David M. Rohret, CSRA, Inc. Senior Principal Systems Engineer // Distinguished Engineer CSRA Inc. | Defense | Air force | FIERCE Labs david.rohret(a)csra.com<mailto:bob.donnelly@csra.com> Unique Mission Cell/JVAB, p: 210-218-1954 This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe you have received this message in error, please contact me immediately and be aware that any use, disclosure, copying or distribution of the contents of this message is strictly prohibited. NOTE: Regardless of content, this email shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of email for such purpose.

3 2

Re: [OpenBIOS] [Qemu-ppc] Windows NT 4.0 for PowerPC
by Programmingkid 31 Jul '17

31 Jul '17

> On Jul 30, 2017, at 11:25 AM, Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> wrote: > > On 28/07/17 02:27, Programmingkid wrote: > >>> On Jul 27, 2017, at 12:36 PM, Răzvan Corneliu C.R. VILT <razvan.vilt(a)gmail.com> wrote: >>> >>> Andrei Warkentin managed to get as far as booting veneer.exe but it crashes at the NT Kernel using his prephv build (https://github.com/andreiw/prephv/). >>> >>> OpenBIOS cannot load PE Images and I believe that even if PE loading was added to it, it wouldn't help since you also have some special >> requirements for little endian booting and some for the load-base. > > I'd be very interested to discuss some of this over on the OpenBIOS > mailing list - writing a PE driver should be fairly simple these days. > >>> Veneer.exe is basically an emulator for the ARC Firmware needed by the NT OSLoader.exe on top of the openfirmware environment. >>> >>> About one year ago I did some digging into this documented on Artyom's blog. >>> http://tyom.blogspot.ro/2014/09/open-firmware-for-qemu-system-ppc-m-prep.ht… >>> >>> If you want, you can write a minimal MZ-PE Loader in Forth and we'll take it from there. > > All of the other OpenBIOS loaders are written in C, so I don't see why > the same couldn't be done for MZ-PE, especially as most people find that > considerably easier than Forth. > > > ATB, > > Mark. Hi Mark. I was just thinking about asking you about this. It would be fun to make Windows NT 4.0 PowerPC work in QEMU. For anyone who is interested I found this page on the PE format. It might be helpful: https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).…

3 6

Jump to page: