Re: [OpenBIOS] Qemu/OpenBIOS 64-bit
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.
5 years, 7 months
- 2
- 2
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.
5 years, 7 months
- 1
- 0
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.
5 years, 7 months
- 4
- 9
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.
5 years, 7 months
- 5
- 10
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
5 years, 7 months
- 1
- 0
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
5 years, 7 months
- 3
- 3
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.
5 years, 7 months
- 1
- 0
[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
5 years, 8 months
- 1
- 0
[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
5 years, 8 months
- 1
- 1
[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);
5 years, 8 months
- 1
- 0