OpenBIOS December 2013

openbios@openbios.org

10 participants
27 discussions

by Mark Cave-Ayland

On 29/12/13 14:12, Artyom Tarasenko wrote: >> Gah. Sorry Nick - this message was definitely a case of "fingers before >> brain. What I meant to say was that I see the "VAC too big!" error on my >> local copy of *64-bit* Solaris 9 too. I currently don't have access to a >> Solaris 9 32-bit image for testing, but it sounds as if it is working fine >> for you which is great. > > Actually "VAC too big" is a pretty nice error: it should happen in the > early sfmmu initialization phase, but for some reason I never get it. > I tried to make the boot process more verbose, but for this I'd need a > working kadb. Maybe it's easy to make it working? > With CIF_DEBUG booting kadb looks like this: > > Jumping to entry point 0000000000100000 for type 0000000000000001... > switching to new context: entry point 0x100000 stack 0x00000000ffe86a01 > finddevice("/chosen") = 0x00000000ffe1bed0 > getproplen(0x00000000ffe1bed0, "mmu") = 0x0000000000000004 > getproplen(0x00000000ffe1bed0, "mmu") = 0x0000000000000004 > getprop(0x00000000ffe1bed0, "mmu", 0x000000000013e02c, 4) = service > getprop: possible argument error (0 1) > > ^^^ The message about possible argument error keeps appearing on every > call after this point. > [...] > > getprop(0x00000000ffe30940, "clock-frequency", 0x0000000000138608, 4) > = service getprop: possible argument error (0 1) > 3990516880 > 0x00138608 05 f5 e1 00 __ __ __ __ __ __ __ __ __ __ __ __ .��. > getproplen(0x00000000ffe30940, "status") = 0xffffffffffffffff > > ^^^ are we missing "status" property? > > child(0x00000000ffe30940) = 0x0000000000000000 > peer(0x00000000ffe30940) = 0x0000000000000000 > peer(0x00000000ffe1b838) = 0x0000000000000000 > of_client_interface: interpret 00000000eddac894 0000000000000000 > 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > interpret : kadb_callback %pc dup f000.0000 ffff.ffff between if > drop exit then h# eddda630 x! %npc h# eddb0758 x! %g1 h# > eddda6d0 x! %g2 h# eddda6d8 x! %g3 h# eddda6e0 x! %g4 h# > eddda720 x! %g5 h# eddda728 x! %g6 h# eddda730 x! %g7 h# > eddda738 x! 1 %tstate h# eddaf070 x! 1 %tt h# eddd9e48 l! h# > edd008ec set-pc go ; ([6] -- [0]) > %pc:interpret: exception -13 caught > > ^^^ I guess things go wrong after this point. > > interpret ': kadb_callback %pc dup f000.0000 ffff.ffff between if > drop exit then h# eddda630 x! %npc h# eddb0758 x! %g1 h# > eddda6d0 x! %g2 h# eddda6d8 x! %g3 h# eddda6e0 x! %g4 h# > eddda720 x! %g5 h# eddda728 x! %g6 h# eddda730 x! %g7 h# > eddda738 x! 1 %tstate h# eddaf070 x! 1 %tt h# eddd9e48 l! h# > edd008ec set-pc go ; ': possible argument error (4--0) got 0 > handle_calls return: > of_client_interface: interpret 00000000edd28010 0000000000000000 > 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > interpret ['] kadb_callback init-debugger-hook ([6] -- [0]) > kadb_callback:interpret: exception -13 caught > interpret ' ['] kadb_callback init-debugger-hook ': possible argument > error (4--0) got 0 > > And then kadb prompt appears but it can't start executing the kernel: > > kadb[0]: :c > of_client_interface: call-method 00000000eddac6e0 00000000ffc847f0 > 0000000001006000 > call-method translate ([3] -- [5]) > handle_calls return: 0000000000000000 ffffffffffffffff > 0000000000000032 0000000000000000 000000001f806000 > of_client_interface: call-method 00000000eddac668 00000000ffc847f0 > 0000000000000033 0000000000002000 00000000ffc7e000 0000000000000000 > 000000001f806000 > call-method map ([7] -- [1]) > handle_calls return: 0000000000000000 > of_client_interface: call-method 00000000eddac6c8 00000000ffc847f0 > 0000000000002000 00000000ffc7e000 > call-method unmap ([4] -- [0]) > call-method 'unmap': possible argument error (2--0) got 0 > handle_calls return: > Unhandled Exception 0x000000000000017e > PC = 0x0000000001006f90 NPC = 0x0000000001006f94 > Stopping execution Ah this is because of a bug in Solaris whereby it requests too many parameters to be returned with respect to the CIF method that is being called. The fix is for OpenBIOS to not allow the client to POP() more items from the stack than were there before the CIF call, for which I have a local patch whilst I wait for the QEMU guys to update their git repository from our SVN. Please try the attached and let me know if you manage to get any further. ATB, Mark.

6 years

Can init-program cause code to run?

by Mark Cave-Ayland

Hi all, I've recently seen a couple of test cases in SPARC64 Forth bootloaders whereby during execution, the bootloaders call "init-program" on an address and expect it to start executing immediately. My understanding from reading the IEEE1275 specification is that "init-program" merely sets up the execution state ready for it to be invoked by "go" and doesn't start execution itself - or could it be that because "go" is currently running then "init-program" detects this and automatically re-invokes "go" on the new payload itself? ATB, Mark.

6 years

Qemu/OpenBIOS 64-bit

by Nick Couchman

So, I have Solaris 9 working inside a qemu-system-sparc (32-bit) environment with OpenBIOS, but no such luck getting 64-bit Solaris (8/9/10/11) to boot. I've attached boot output from Solaris verions 8, 9, 10, and 11. Getting a later version (10+) to work would be nice, since it seems that at least up to Solaris 9 doesn't support CPU power management, which means the qemu-system-sparc process runs at 100% CPU usage constantly. If I need to hook up a debugger and do more digging, I can...just let me know. Thanks, Nick -------- This e-mail may contain SEAKR Engineering (SEAKR) Confidential and Proprietary Information. If this message is not intended for you, you are strictly prohibited from using this message, its contents or attachments in any way. If you have received this message in error, please delete the message from your mailbox. This e-mail may contain export-controlled material and should be handled accordingly.

6 years

Qemu, OpenBIOS, and HostID

by Nick Couchman

First, thanks to everyone who has worked to get OpenBIOS up to its current functional level over the past couple of years. I'm using Solaris 9 on OpenBIOS with pretty good success these days, which is awesome. I do have a question about Qemu, OpenBIOS, and the Solaris hostid. It seems that, currently, when booting Solaris with Qemu, the host ID is set to "80000000." As far as I can tell, this isn't near correct - according to all of the documentation I've read, the host ID should be calculated based on the machine type, and some portion of the MAC address. This may be the wrong forum in which to ask this, but I'm wondering if someone could shed light on why it shows up that way, and if there's a way in OpenBIOS via the PROM/NVRAM data to set the host ID to something a little bit closer to normal? Thanks! -Nick -------- This e-mail may contain SEAKR Engineering (SEAKR) Confidential and Proprietary Information. If this message is not intended for you, you are strictly prohibited from using this message, its contents or attachments in any way. If you have received this message in error, please delete the message from your mailbox. This e-mail may contain export-controlled material and should be handled accordingly.

6 years

Re: [OpenBIOS] Qemu, OpenBIOS, and HostID

by Olivier Danet

On 28/12/2013 22:16, Artyom Tarasenko wrote: > Hi Oliver, > > On Fri, Dec 27, 2013 at 10:56 PM, Olivier Danet <odanet(a)caramail.com> wrote: >> On 27/12/2013 20:42, Tarl Neustaedter wrote: >>> On 2013-Dec-27, 14:10 , Nick Couchman wrote: >>>> First, thanks to everyone who has worked to get OpenBIOS up to its >>>> current functional level over the past couple of years. I'm using Solaris 9 >>>> on OpenBIOS with pretty good success these days, which is awesome. >>>> >>>> I do have a question about Qemu, OpenBIOS, and the Solaris hostid. It >>>> seems that, currently, when booting Solaris with Qemu, the host ID is set to >>>> "80000000." As far as I can tell, this isn't near correct - according to >>>> all of the documentation I've read, the host ID should be calculated based >>>> on the machine type, and some portion of the MAC address. This may be the >>>> wrong forum in which to ask this, but I'm wondering if someone could shed >>>> light on why it shows up that way, and if there's a way in OpenBIOS via the >>>> PROM/NVRAM data to set the host ID to something a little bit closer to >>>> normal? >>> >>> The HOSTID used to have embedded knowledge about the system type and other >>> details. As of (I recall) Sun4u, the hostid is 0x8000.0000 plus a serial >>> number. Openbios should pick a number other than "0" for the serial number >>> :-) >>> >>> >> [On 32bits SparcStations] >> The Host ID is made of the machine type and the serial number. >> the serial number is identical to three bytes of the Ethernet MAC address, >> shown as decimal during boot. >> All that stuff is written into the NVRAM >> >> For example, on a SparcStation 20 : >> MAC Address = 08:00:20:74:FB:DA >> Host ID = 7274FBDA (72 is the machine type of the SS20) >> Serial number = #7666650 = 0x74FBDA >> >> (And the barcode on the NVRAM chip is also "74FBDA" ) >> >> On a SparcStation5, the machine type is 0x80, everything else is identical. >> >> Maybe this small patch for QEMU could help : >> ------------------------------------------------------------------------ >> diff --git a/include/hw/nvram/openbios_firmware_abi.h >> b/include/hw/nvram/openbios_firmware_abi.h >> index 5e6e5d4..492c8d5 100644 >> --- a/include/hw/nvram/openbios_firmware_abi.h >> +++ b/include/hw/nvram/openbios_firmware_abi.h >> @@ -62,6 +62,8 @@ Sun_init_header(struct Sun_nvram *header, const uint8_t >> *macaddr, int machine_id >> header->type = 1; >> header->machine_id = machine_id & 0xff; >> memcpy(&header->macaddr, macaddr, 6); >> + memcpy(&header->hostid , &macaddr[3],3); >> + >> /* Calculate checksum */ >> tmp = 0; >> tmpptr = (uint8_t *)header; >> ------------------------------------------------------------------------ > Can you please submit this patch (+ SoB) to the qemu-devel mailing list? > It's short and beautiful. > > Artyom > The "idprom" property produced by OpenBIOS is modified with this patch, but I do not have any Solaris image. Can you test it ? Olivier

6 years

Probably a dumb question - Intel MB DG45ID

by Philip Rhoades

People, I have been on this list for some time lurking - just because I think it is interesting that a bit of firmware can allow hardware to be actually useful! I haven't done more than read the occasional post that was of interest but the thought occurred to me again about replacing the BIOS that is on my current machine with something that is open so I went back to the OpenBIOS home page but was a bit puzzled to see on the Download page: "Do not try to put OpenBIOS in a real boot ROM, it will not work and may damage your hardware!". After a little more looking around I am still confused - the ultimate aim of this software is to eventually allow people to replace their proprietary BIOSes right? I have an Intel MB DG45ID but I couldn't Google much overlap with OpenBIOS . . Thanks for any enlightenment! Regards, Phil. -- Philip Rhoades GPO Box 3411 Sydney NSW 2001 Australia E-mail: phil(a)pricom.com.au

6 years

Re: [OpenBIOS] Qemu, OpenBIOS, and HostID

by Mark Cave-Ayland

On 28/12/13 17:37, Artyom Tarasenko wrote: >> Okay that's something that's fairly easy to do. My main questions would be: >> >> i) if nothing looks at hostid, then would it matter that it is all zeros? >> >> ii) if we do set it to 8012.3456 then if something did happen to check >> hostid then would it detect this special magic number and start to behave >> differently? (e.g. kernels detecting prototype hardware) > > I'd suggest we fix it in QEMU, not in OpenBIOS. Some software may get > unhappy when a hostid in firmware diverges from the one in NVRAM. Yes, if things do try and access the NVRAM directly then that would definitely be a better solution (I had no idea that QEMU did this until I read your previous email!). It's not particularly on my radar at the moment as I'm back deep in SPARC64-land, but I'd be happy to support anyone that did come up with something suitable. ATB, Mark.

6 years

[commit] r1246 - trunk/openbios-devel/drivers

by repository service

Author: mcayland Date: Fri Dec 20 11:45:54 2013 New Revision: 1246 URL: http://tracker.coreboot.org/trac/openbios/changeset/1246 Log: tcx/cgthree: remove hard OpenBIOS dependency from driver Since QEMU 1.7, the OpenBIOS TCX framebuffer FCode ROM is made available to Open Firmware upon boot. However, this causes a boot failure for people who use a Sun OBP firmware with QEMU since the FCode throws an exception trying to access some OpenBIOS-specific variables. This causes an invalid device node to be created in the tree, causing a crash on boot as reported by Peter Bartoli and Artyom Tarasenko. Fix both drivers so that if OpenBIOS is not detected, we fall back to the QEMU framebuffer defaults of 1024x768x8 which should generate a valid device node and avoid the crash. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/drivers/cgthree.fs trunk/openbios-devel/drivers/tcx.fs Modified: trunk/openbios-devel/drivers/cgthree.fs ============================================================================== --- trunk/openbios-devel/drivers/cgthree.fs Mon Dec 16 19:06:28 2013 (r1245) +++ trunk/openbios-devel/drivers/cgthree.fs Fri Dec 20 11:45:54 2013 (r1246) @@ -18,20 +18,57 @@ $find if exit else + 2drop -1 then ; +: (is-openbios) \ ( -- true | false ) + " openbios-video-width" (find-xt) -1 <> if + -1 + else + 0 + then +; + " openbios-video-width" (find-xt) cell+ value openbios-video-width-xt " openbios-video-height" (find-xt) cell+ value openbios-video-height-xt " depth-bits" (find-xt) cell+ value depth-bits-xt " line-bytes" (find-xt) cell+ value line-bytes-xt " debug-type" (find-xt) value debug-type-xt -: openbios-video-width openbios-video-width-xt @ ; -: openbios-video-height openbios-video-height-xt @ ; -: depth-bits depth-bits-xt @ ; -: line-bytes line-bytes-xt @ ; +: openbios-video-width + (is-openbios) if + openbios-video-width-xt @ + else + h# 400 + then +; + +: openbios-video-height + (is-openbios) if + openbios-video-height-xt @ + else + h# 300 + then +; + +: depth-bits + (is-openbios) if + depth-bits-xt @ + else + h# 8 + then +; + +: line-bytes + (is-openbios) if + line-bytes-xt @ + else + h# 400 + then +; + : debug-type debug-type-xt execute ; \ @@ -113,6 +150,12 @@ : qemu-cg3-driver-install ( -- ) cg3-dac -1 = if map-regs + + \ Initial pallette taken from Sun's "Writing FCode Programs" + h# ff h# ff h# ff h# 0 color! \ Background white + h# 0 h# 0 h# 0 h# ff color! \ Foreground black + h# 64 h# 41 h# b4 h# 1 color! \ SUN-blue logo + fb-addr to frame-buffer-adr default-font set-font Modified: trunk/openbios-devel/drivers/tcx.fs ============================================================================== --- trunk/openbios-devel/drivers/tcx.fs Mon Dec 16 19:06:28 2013 (r1245) +++ trunk/openbios-devel/drivers/tcx.fs Fri Dec 20 11:45:54 2013 (r1246) @@ -18,19 +18,55 @@ $find if exit else + 2drop -1 then ; +: (is-openbios) \ ( -- true | false ) + " openbios-video-width" (find-xt) -1 <> if + -1 + else + 0 + then +; + " openbios-video-width" (find-xt) cell+ value openbios-video-width-xt " openbios-video-height" (find-xt) cell+ value openbios-video-height-xt " depth-bits" (find-xt) cell+ value depth-bits-xt " line-bytes" (find-xt) cell+ value line-bytes-xt -: openbios-video-width openbios-video-width-xt @ ; -: openbios-video-height openbios-video-height-xt @ ; -: depth-bits depth-bits-xt @ ; -: line-bytes line-bytes-xt @ ; +: openbios-video-width + (is-openbios) if + openbios-video-width-xt @ + else + h# 400 + then +; + +: openbios-video-height + (is-openbios) if + openbios-video-height-xt @ + else + h# 300 + then +; + +: depth-bits + (is-openbios) if + depth-bits-xt @ + else + h# 8 + then +; + +: line-bytes + (is-openbios) if + line-bytes-xt @ + else + h# 400 + then +; \ \ Registers @@ -183,6 +219,12 @@ : qemu-tcx-driver-install ( -- ) tcx-dac -1 = if map-regs + + \ Initial pallette taken from Sun's "Writing FCode Programs" + h# ff h# ff h# ff h# 0 color! \ Background white + h# 0 h# 0 h# 0 h# ff color! \ Foreground black + h# 64 h# 41 h# b4 h# 1 color! \ SUN-blue logo + fb-addr to frame-buffer-adr default-font set-font

6 years, 1 month

[PATCH 1/2] ide: change ob_ide_init() to take usual control base addresses

by Hervé Poussineau

The +2 offset comes from the PCI IDE controllers, where control status must be accessed at BAR1+2 and BAR3+2. Signed-off-by: Hervé Poussineau <hpoussin(a)reactos.org> --- arch/amd64/openbios.c | 2 +- arch/x86/openbios.c | 2 +- drivers/ide.c | 4 ++-- drivers/pci.c | 4 ++-- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/amd64/openbios.c b/arch/amd64/openbios.c index f632e93..15d3b62 100644 --- a/arch/amd64/openbios.c +++ b/arch/amd64/openbios.c @@ -44,7 +44,7 @@ arch_init( void ) modules_init(); #ifdef CONFIG_DRIVER_IDE setup_timers(); - ob_ide_init("/pci/pci-ata", 0x1f0, 0x3f4, 0x170, 0x374); + ob_ide_init("/pci/pci-ata", 0x1f0, 0x3f6, 0x170, 0x376); #endif device_end(); bind_func("platform-boot", boot ); diff --git a/arch/x86/openbios.c b/arch/x86/openbios.c index 23721bc..6145436 100644 --- a/arch/x86/openbios.c +++ b/arch/x86/openbios.c @@ -57,7 +57,7 @@ arch_init( void ) #endif #ifdef CONFIG_DRIVER_IDE setup_timers(); - ob_ide_init("/pci/isa", 0x1f0, 0x3f4, 0x170, 0x374); + ob_ide_init("/pci/isa", 0x1f0, 0x3f6, 0x170, 0x376); #endif #ifdef CONFIG_DRIVER_FLOPPY ob_floppy_init("/isa", "floppy0", 0x3f0, 0); diff --git a/drivers/ide.c b/drivers/ide.c index 125b9ce..0e0f0cf 100644 --- a/drivers/ide.c +++ b/drivers/ide.c @@ -1372,9 +1372,9 @@ int ob_ide_init(const char *path, uint32_t io_port0, uint32_t ctl_port0, u32 props[6]; io_ports[0] = io_port0; - ctl_ports[0] = ctl_port0 + 2; + ctl_ports[0] = ctl_port0; io_ports[1] = io_port1; - ctl_ports[1] = ctl_port1 + 2; + ctl_ports[1] = ctl_port1; for (i = 0; i < IDE_NUM_CHANNELS; i++, current_channel++) { diff --git a/drivers/pci.c b/drivers/pci.c index c13f031..ee35b61 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -584,9 +584,9 @@ int ide_config_cb2 (const pci_config_t *config) { ob_ide_init(config->path, config->assigned[0] & ~0x0000000F, - config->assigned[1] & ~0x0000000F, + (config->assigned[1] & ~0x0000000F) + 2, config->assigned[2] & ~0x0000000F, - config->assigned[3] & ~0x0000000F); + (config->assigned[3] & ~0x0000000F) + 2); return 0; } -- 1.7.10.4

6 years, 1 month

[commit] r1245 - trunk/openbios-devel/packages

by repository service

Author: mcayland Date: Mon Dec 16 19:06:28 2013 New Revision: 1245 URL: http://tracker.coreboot.org/trac/openbios/changeset/1245 Log: sun-parts.c: only interpose ufs-file-system if an argument (filename) is specified The code to interpose ufs-file-system similar to OBP would always interpose the package if it existed, causing Solaris ufsboot to fail when the package was subsequently opened on a raw disk device without a filename. Fix the code so that interposition only occurs when a filename is passed as an argument, which enables us to complete the load and start executing the Solaris 9 kernel on SPARC64. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/packages/sun-parts.c Modified: trunk/openbios-devel/packages/sun-parts.c ============================================================================== --- trunk/openbios-devel/packages/sun-parts.c Mon Dec 16 19:06:24 2013 (r1244) +++ trunk/openbios-devel/packages/sun-parts.c Mon Dec 16 19:06:28 2013 (r1245) @@ -217,7 +217,7 @@ feval("find-package"); ph = POP_ph(); - if (argstr && ph) { + if (argstr && strlen(argstr) && ph) { ph = POP_ph(); push_str(argstr); PUSH_ph(ph);

6 years, 1 month