discussion about OpenBIOS - a free portable firmware implementation ()

svn | 1 Jan 2010 19:17

r655 - in trunk/openbios-devel/forth: device packages system

Author: mcayland
Date: 2010-01-01 19:17:15 +0100 (Fri, 01 Jan 2010)
New Revision: 655

Modified:
   trunk/openbios-devel/forth/device/builtin.fs
   trunk/openbios-devel/forth/device/device.fs
   trunk/openbios-devel/forth/device/tree.fs
   trunk/openbios-devel/forth/packages/deblocker.fs
   trunk/openbios-devel/forth/packages/disklabel.fs
   trunk/openbios-devel/forth/packages/obp-tftp.fs
   trunk/openbios-devel/forth/packages/packages.fs
   trunk/openbios-devel/forth/packages/terminal-emulator.fs
   trunk/openbios-devel/forth/system/ciface.fs
Log:
Change the new-device word so that subsequent words within a new device are added to the public wordlist and
not 
the private wordlist by default. This is required for executing Milax Fcode which defines package words
which need to be externally 
visible.

As a consequence, it is now possible to remove lots of "external" words used building the device tree since
this is now the 
default.

Modified: trunk/openbios-devel/forth/device/builtin.fs
===================================================================
--- trunk/openbios-devel/forth/device/builtin.fs	2009-12-30 10:54:52 UTC (rev 654)
+++ trunk/openbios-devel/forth/device/builtin.fs	2010-01-01 18:17:15 UTC (rev 655)
 <at>  <at>  -14,13 +14,11  <at>  <at>

(Continue reading)

headers

svn | 1 Jan 2010 19:21

r656 - trunk/openbios-devel/forth/admin

Author: mcayland
Date: 2010-01-01 19:21:18 +0100 (Fri, 01 Jan 2010)
New Revision: 656

Modified:
   trunk/openbios-devel/forth/admin/nvram.fs
Log:
Add load-base NVRAM variable for SPARC64.

Modified: trunk/openbios-devel/forth/admin/nvram.fs
===================================================================
--- trunk/openbios-devel/forth/admin/nvram.fs	2010-01-01 18:17:15 UTC (rev 655)
+++ trunk/openbios-devel/forth/admin/nvram.fs	2010-01-01 18:21:18 UTC (rev 656)
 <at>  <at>  -356,6 +356,11  <at>  <at> 
 s" false"    s" ttyb-rts-dtr-off"      bool-config
 [THEN]

+[IFDEF] CONFIG_SPARC64
+\ ---- SPARC64 ----
+s" 4000000"  s" load-base"          int-config
+[THEN]
+
 \ --- ??? ---
 s" "         s" boot-screen"          str-config
 s" "         s" boot-script"          str-config

headers

Mark Cave-Ayland | 1 Jan 2010 19:37

Latest SPARC64 & Milax update

Hi folks,

I'm pleased to report that as of r656, OpenBIOS now successfully 
executes all of the Fcode from within the Milax 0.3.2 ISO image under 
Qemu :) The current output from Qemu looks like this:

OpenBIOS for Sparc64
Configuration device id QEMU version 1 machine id 0
CPUs: 1 x SUNW,UltraSPARC-II
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.0 built on Jan 1 2010 18:04
   Type 'help' for detailed information

[sparc64] Booting file 'cdrom' with parameters ''
Not a bootable ELF image
Not a Linux kernel image
Not a bootable a.out image
Loading FCode image...
Loaded 7084 bytes
entry point is 0x4000
Evaluating FCode...
Unhandled Exception 0xe81ac700ffdba000
PC = 0x00000000ffd12ffc NPC = 0x00000000ffd13000
Stopping execution

Stepping through with the debugger shows that it is now dying in the 
very last line of exec-file which reads:

" to load-base init-program"  evaluate

(Continue reading)

headers

Mark Cave-Ayland | 1 Jan 2010 20:47

Re: Latest SPARC64 & Milax update

Mark Cave-Ayland wrote:

> Stepping through with the debugger shows that it is now dying in the 
> very last line of exec-file which reads:
> 
> " to load-base init-program"  evaluate
> 
> So it looks as if we're very nearly there. My guess would be that 
> OpenBIOS is dying somewhere within init-program. Does anyone know 
> anything about what init-program should be doing under SPARC64? Has it 
> ever been tested before?

Hmmmm now I see what the problem is - load-base is actually a special 
configuration word and not a variable. Hence when the Fcode executes "to 
load-base" it overwrites the first part of the load-base word causing 
the crash.

Reading the OF specification in section 7.4.4.1 it seems that OpenBIOS 
violates the Fundamental Data Type property of configuration variables 
since they are stored in a special configuration word format. I think 
the only way to solve this is rework the NVRAM code so that it respects 
the fundamental data types when creating the configuration variables. 
Does everyone agree that this is the way forward?

ATB,

Mark.

--

-- 
Mark Cave-Ayland - Senior Technical Architect

(Continue reading)

headers

Tarl Neustaedter | 1 Jan 2010 21:02

Re: Latest SPARC64 & Milax update

Mark Cave-Ayland wrote:
> [...]
> Stepping through with the debugger shows that it is now dying in the 
> very last line of exec-file which reads:
>
> " to load-base init-program"  evaluate
>
> So it looks as if we're very nearly there. My guess would be that 
> OpenBIOS is dying somewhere within init-program. Does anyone know 
> anything about what init-program should be doing under SPARC64? Has it 
> ever been tested before?

In Sun's openboot, that's in go.fth (lives in obp/ach/sun4u/go.fth), and 
it does an execute-buffer on whatever's in load-base, followed by 
initializing the registers, trap-table and stack for the client 
interface. Specifically (I can include this because it has been 
open-sourced):

: (init-program)  ( -- )

   cif-64    \ 64-Bit IEEE 1275 Client Interface

   init-c-stack    \ Erase any previous C stack state

   \ Zero all the general registers.
   0w
   0 to %g0  0 to %o0  0 to %l0  0 to %i0
   0 to %g1  0 to %o1  0 to %l1     0 to %i1
   0 to %g2  0 to %o2  0 to %l2     0 to %i2
   0 to %g3  0 to %o3  0 to %l3     0 to %i3

(Continue reading)

headers

Stefan Reinauer | 1 Jan 2010 21:46

Re: Latest SPARC64 & Milax update

On 1/1/10 8:47 PM, Mark Cave-Ayland wrote:
> Mark Cave-Ayland wrote:
>
>> Stepping through with the debugger shows that it is now dying in the
>> very last line of exec-file which reads:
>>
>> " to load-base init-program"  evaluate
>>
>> So it looks as if we're very nearly there. My guess would be that
>> OpenBIOS is dying somewhere within init-program. Does anyone know
>> anything about what init-program should be doing under SPARC64? Has
>> it ever been tested before?
>
> Hmmmm now I see what the problem is - load-base is actually a special
> configuration word and not a variable. Hence when the Fcode executes
> "to load-base" it overwrites the first part of the load-base word
> causing the crash.
>
> Reading the OF specification in section 7.4.4.1 it seems that OpenBIOS
> violates the Fundamental Data Type property of configuration variables
> since they are stored in a special configuration word format. I think
> the only way to solve this is rework the NVRAM code so that it
> respects the fundamental data types when creating the configuration
> variables. Does everyone agree that this is the way forward?
I don't think that's the right approach, because the code in Milax seems
to be what's not standard conform here. It relies on an implementation
specific detail of SUN's OFW.

IEEE 1275-1994 says:
> Thus, they cannot be accessed at fixed locations, but instead must be

(Continue reading)

headers

Stefan Reinauer | 1 Jan 2010 21:52

Solaris in Qemu

Hi,

just a side note for those who are not on the Qemu mailing list:

Artyom Tarasenko used original SUN OBP images in Qemu in order to boot SunOS/Solaris on Sparc32.

http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html

Nice work!

Stefan

<div>
Hi,<br><br>
just a side note for those who are not on the Qemu mailing list:<br><br>
Artyom Tarasenko used original SUN OBP images in Qemu in order to boot
SunOS/Solaris on Sparc32.<br><br><a class="moz-txt-link-freetext" href="http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html">http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html</a><br><br>
Nice work!<br><br>
Stefan<br><br><br>
</div>

headers

Mark Cave-Ayland | 2 Jan 2010 12:39

Re: Latest SPARC64 & Milax update

Stefan Reinauer wrote:

> I don't think that's the right approach, because the code in Milax seems
> to be what's not standard conform here. It relies on an implementation
> specific detail of SUN's OFW.
> 
> IEEE 1275-1994 says:
>> Thus, they cannot be accessed at fixed locations, but instead must be
> accessed by name. Users can access them by name using printenv and setenv.
> 
> Note there is no mentioning of any specific data type for configuration
> variables anywhere in 7.4.4.1. Milax assumes that load-base is a value
> (not a variable), hence the "to".

Alas it seems this is still present in OpenSolaris too :(  I'm guessing 
they should be using "printenv", right?

> I suggest as a workaround for this particular bug in Milax to add
> something like the following code at the end of nvram.fs:
> 
>>  load-base value load-base
> 
> This will leave the environment variable "load-base" intact for the use
> in the standard conform way and create a shadow value that will be used
> by Milax. This shadow value will be initialized with the initial value
> of load-base.

Nice hack ;) At least now the Fcode finishes execution, but it doesn't 
seem to load anything from the ramdisk.

ATB,

Mark.

--

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs

headers

Mark Cave-Ayland | 2 Jan 2010 12:58

Re: Latest SPARC64 & Milax update

Tarl Neustaedter wrote:

> In Sun's openboot, that's in go.fth (lives in obp/ach/sun4u/go.fth), and 
> it does an execute-buffer on whatever's in load-base, followed by 
> initializing the registers, trap-table and stack for the client 
> interface. Specifically (I can include this because it has been 
> open-sourced):

(lots cut)

With Stefan's hack in place, the Fcode finishes execution but it doesn't 
seem to load anything from the ramdisk. AFAICT at the moment the 
contents of /platform/sun4u/boot_archive is being loaded at 0x51000000, 
and a new node /ramdisk-root is being created with methods that seem to 
point into this memory space.

What I can't see at the moment is how the device switch takes place, 
i.e. when /ramdisk-root is used to load the kernel from the image. There 
are several checks for nested? in do-boot and friends which make me 
think that something in init-program should be calling do-boot again 
once the ramdisk switch has taken place...

ATB,

Mark.

--

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs

headers

Stefan Reinauer | 2 Jan 2010 13:16

Re: Latest SPARC64 & Milax update

On 1/2/10 12:39 PM, Mark Cave-Ayland wrote:
> Stefan Reinauer wrote:
>
>> I don't think that's the right approach, because the code in Milax seems
>> to be what's not standard conform here. It relies on an implementation
>> specific detail of SUN's OFW.
>>
>> IEEE 1275-1994 says:
>>> Thus, they cannot be accessed at fixed locations, but instead must be
>> accessed by name. Users can access them by name using printenv and
>> setenv.
>>
>> Note there is no mentioning of any specific data type for configuration
>> variables anywhere in 7.4.4.1. Milax assumes that load-base is a value
>> (not a variable), hence the "to".
>
> Alas it seems this is still present in OpenSolaris too :(  I'm
> guessing they should be using "printenv", right?
Milax writes some value on the stack to "load-base".  So I think they
should be using something like

<# u#s u#> " load-base" " $setenv init-program" evaluate

I wonder why load-base is an environment variable at all, since it seems
to be calculated on every boot anyways.

Stefan

11	May 2013
139	April 2013
72	March 2013
56	February 2013
147	January 2013
98	December 2012
78	November 2012
40	October 2012
39	September 2012
64	August 2012
3	July 2012
28	June 2012
50	May 2012
85	April 2012
16	March 2012
14	February 2012
1	January 2012
1	November 2011
4	October 2011
12	September 2011
131	August 2011
28	July 2011
58	June 2011
85	May 2011
86	April 2011
1	March 2011
79	February 2011
86	January 2011
186	December 2010
342	November 2010
316	October 2010
130	September 2010
117	August 2010
35	July 2010
60	June 2010
137	May 2010
172	April 2010
101	March 2010
47	February 2010
85	January 2010
178	December 2009
216	November 2009
6	October 2009
26	September 2009
150	August 2009
63	July 2009
12	June 2009
61	May 2009
66	April 2009
53	March 2009
91	February 2009
242	January 2009
112	December 2008
85	November 2008
2	October 2008
18	September 2008
20	August 2008
39	July 2008
2	June 2008
11	May 2008
6	April 2008
5	March 2008
21	February 2008
58	January 2008
21	December 2007
47	November 2007
80	October 2007
60	September 2007
118	August 2007
68	July 2007
32	June 2007
112	May 2007
69	April 2007
24	March 2007
6	February 2007
21	January 2007
9	December 2006
6	November 2006
44	October 2006
44	September 2006
26	August 2006
20	July 2006
88	June 2006
57	May 2006
22	April 2006
2	March 2006
1	December 2005
4	October 2005
4	August 2005
11	July 2005
3	June 2005
14	May 2005
9	March 2005
13	January 2005
5	December 2004
5	October 2004
28	September 2004
2	August 2004
2	July 2004

Mon	Tue	Wed	Thu	Fri	Sat	Sun

				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31