discussion about OpenBIOS - a free portable firmware implementation ()

Hanusz L. | 6 Oct 2009 10:10

Support for 16 head harddisk on OLD Interactive Unix configured for 15 head harddisk

Hello,

I have an old system running Interactive Unix on a 15 head harddisk (4Gb).

I would like to clone this system to a 16 head harddisk because it is now difficult to find 15 head harddisks.

The problem is that I cannot modify the system which think it has a 15 head harddisk.

I suppose that Interactive unix use the Int13 interrupt mechanism to access the disk (am I wrong ?).

I wonder if there is a possibility to modify openbios so that a 16 head harddisk is used and is simulated as a 15 head harddisk by the bios ?

I would probably have to modify the drivers/ide.c file to do a conversion.

My questions are:

- Can openbios boot Interactive Unix ?

- What implementation should I use ?

Thanks for any help,

Leszek Hanusz

This e-mail message has been scanned for Viruses and Content and cleared by Mailsecurity software

<div>

<div class="Section1">

<p class="MsoNormal"><span>Hello,</span></p>

<p class="MsoNormal"><span>&nbsp;</span></p>

<p class="MsoNormal"><span lang="EN-GB">I have an old system running Interactive Unix on a 15
head harddisk (4Gb).</span></p>

<p class="MsoNormal"><span lang="EN-GB">I would like to clone this system to a 16 head harddisk
because it is now difficult to find 15 head harddisks.</span></p>

<p class="MsoNormal"><span lang="EN-GB">&nbsp;</span></p>

<p class="MsoNormal"><span lang="EN-GB">The problem is that I cannot modify the system which
think it has a 15 head harddisk.</span></p>

<p class="MsoNormal"><span lang="EN-GB">I suppose that Interactive unix use the Int13
interrupt mechanism to access the disk (am I wrong ?).</span></p>

<p class="MsoNormal"><span lang="EN-GB">&nbsp;</span></p>

<p class="MsoNormal"><span lang="EN-GB">I wonder if there is a possibility to modify openbios
so that a 16 head harddisk is used and is simulated as a 15 head harddisk by
the bios ?</span></p>

<p class="MsoNormal"><span lang="EN-GB">I would probably have to modify the drivers/ide.c
file to do a conversion.</span></p>

<p class="MsoNormal"><span lang="EN-GB">&nbsp;</span></p>

<p class="MsoNormal"><span lang="EN-GB">My questions are:</span></p>

<p class="MsoNormal"><span lang="EN-GB">-<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><span lang="EN-GB">Can openbios boot Interactive Unix ?</span></p>

<p class="MsoNormal"><span lang="EN-GB">-<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><span lang="EN-GB">What implementation should I use ?</span></p>

<p class="MsoNormal"><span lang="EN-GB">&nbsp;</span></p>

<p class="MsoNormal"><span lang="EN-GB">Thanks for any help,</span></p>

<p class="MsoNormal"><span lang="EN-GB">&nbsp;</span></p>

<p class="MsoNormal"><span lang="EN-GB">Leszek Hanusz</span></p>

</div>

This e-mail message has been scanned for Viruses and Content and cleared 
by&nbsp; Mailsecurity software 
</div>

headers

Lennart Sorensen | 6 Oct 2009 19:49

Re: Support for 16 head harddisk on OLD Interactive Unix configured for 15 head harddisk

On Tue, Oct 06, 2009 at 10:10:10AM +0200, Hanusz L. wrote:
> I have an old system running Interactive Unix on a 15 head harddisk (4Gb).
> I would like to clone this system to a 16 head harddisk because it is now difficult to find 15 head harddisks.
> 
> The problem is that I cannot modify the system which think it has a 15 head harddisk.
> I suppose that Interactive unix use the Int13 interrupt mechanism to access the disk (am I wrong ?).

I highly suspect you are wrong.  DOS uses INT13.  Boot loaders use INT13.
Anything runing protected mode does not.  Anything 32bit is protected mode.

> I wonder if there is a possibility to modify openbios so that a 16 head harddisk is used and is simulated as a
15 head harddisk by the bios ?
> I would probably have to modify the drivers/ide.c file to do a conversion.
> 
> My questions are:
> -          Can openbios boot Interactive Unix ?
> -          What implementation should I use ?
> 
> Thanks for any help,

Are you running this on real hardware or on qemu or what?  If the OS
actually uses CHS access to the disk, then I don't think you can do
anything on real hardware since the disk isn't likely to help you out
translating.  If the OS actually uses LBA (as most sane OSs have done for
many years), then it doesn't matter and the CHS is just partition table
related and doesn't do anything after the partitions have been located.

I am sure qemu could be made to emulate a disk with any desired geometry
though.

If real hardware, well replacing the BIOS on a system is a lot of hard
work given you have to figure out all the hardware initialization that
must be done.  It still doesn't solve the fact that the disk when
receiving CHS based commands isn't going to be 15 heads.

--

-- 
Len Sorensen

headers

G 3 | 14 Oct 2009 15:45

OpenBIOS version 1.1?

Is there a roadmap or plan that states when version 1.1 of OpenBIOS  
will be declared? I'm wondering this because a lot of features have  
been added to OpenBIOS since version 1.0 was released (7 months ago).

headers

Blue Swirl | 14 Oct 2009 19:57

Re: OpenBIOS version 1.1?

On Wed, Oct 14, 2009 at 4:45 PM, G 3 <programmingkidx@...> wrote:
> Is there a roadmap or plan that states when version 1.1 of OpenBIOS will be
> declared? I'm wondering this because a lot of features have been added to
> OpenBIOS since version 1.0 was released (7 months ago).

Well, my plan was to follow QEMU releases, with OpenBIOS 1.1 released
together with QEMU 0.11, but that didn't happen.

We could still retroactively tag the revisions, for example r505 ->
openbios-1.0-qemu-0.11.

headers

svn | 20 Oct 2009 01:02

r590 - trunk/openbios-devel/arch/ppc/qemu

Author: laurent
Date: 2009-10-20 01:02:10 +0200 (Tue, 20 Oct 2009)
New Revision: 590

Modified:
   trunk/openbios-devel/arch/ppc/qemu/main.c
Log:
ppc: if "\\:tbxi" (mac) fails, try "ppc\bootinfo.txt" (chrp).

This is needed to load the bootloader of OpenBSD.

Signed-off-by: Laurent Vivier <Laurent@...>

Modified: trunk/openbios-devel/arch/ppc/qemu/main.c
===================================================================
--- trunk/openbios-devel/arch/ppc/qemu/main.c	2009-09-21 23:12:02 UTC (rev 589)
+++ trunk/openbios-devel/arch/ppc/qemu/main.c	2009-10-19 23:02:10 UTC (rev 590)
 <at>  <at>  -205,8 +205,12  <at>  <at> 
 static void
 newworld_boot( void )
 {
-        static const char * const chrp_path = "\\\\:tbxi" ;
+        static const char * const chrp_path[] = { "\\\\:tbxi",
+						  "ppc\\bootinfo.txt",
+						  NULL
+						  };
         char *path = pop_fstr_copy(), *param;
+	int i;

 	param = strchr(path, ' ');
 	if (param) {
 <at>  <at>  -237,7 +241,8  <at>  <at> 
                     param = pop_fstr_copy();
                 }
                 try_path(path, NULL, param);
-	        try_path(path, chrp_path, param);
+                for (i = 0; chrp_path[i]; i++)
+	            try_path(path, chrp_path[i], param);
             } else {
                 uint16_t boot_device = fw_cfg_read_i16(FW_CFG_BOOT_DEVICE);
                 switch (boot_device) {
 <at>  <at>  -249,12 +254,14  <at>  <at> 
                     path = strdup("cd:");
                     break;
                 }
-	        try_path(path, chrp_path, param);
+                for (i = 0; chrp_path[i]; i++)
+	            try_path(path, chrp_path[i], param);
             }
         } else {
             NEWWORLD_DPRINTF("Entering boot, path %s\n", path);
 	    try_path(path, NULL, param);
-            try_path(path, chrp_path, param);
+            for (i = 0; chrp_path[i]; i++)
+	        try_path(path, chrp_path[i], param);
         }
 	printk("*** Boot failure! No secondary bootloader specified ***\n");
 }

headers

Mark Cave-Ayland | 31 Oct 2009 12:02

PATCH: Implement Forth source debugger for OpenBIOS

Hi all,

Whilst spending some time working on debugging SPARC64 support with 
Qemu/OpenBIOS, it became readily apparent that progress was being 
hampered by the lack of debugging facilities in OpenBIOS (see 
http://lists.openbios.org/pipermail/openbios/2009-August/003949.html). 
Hence I've been working on adding a source debugger to OpenBIOS which 
should enable developers to step/trace through Forth words in order to 
locate bugs in the lower level Forth OpenBIOS code.

The attached patch implements a Forth Source Debugger based upon the 
IEEE-1275 specification; it is not a comprehensive implementation but 
has already proved to be very useful in my tests here. A sample session 
using the debugger goes something like this:

Welcome to OpenBIOS v1.0 built on Oct 31 2009 10:09
   Type 'help' for detailed information

[unix] Booting default not supported.

0 > : bar ." test " ;  ok
0 > debug bar
Stepper keys: <space>/<enter> Up Down Trace Rstack Forth
  ok
0 > bar
: bar  ( Empty )
0xf7e11f0c: (")
: (")  ( Empty )
0xf7dfd928: r>  ( f7e11f0c )
0xf7dfd92c: dup  ( f7e11f0c f7e11f0c )
0xf7dfd930: 2  ( f7e11f0c f7e11f0c 2 )
0xf7dfd934: cells  ( f7e11f0c f7e11f0c 8 )
0xf7dfd938: +  ( f7e11f0c f7e11f14 )
0xf7dfd93c: over  ( f7e11f0c f7e11f14 f7e11f0c )
0xf7dfd940: cell+  ( f7e11f0c f7e11f14 f7e11f10 )
0xf7dfd944:  <at>   ( f7e11f0c f7e11f14 5 )
0xf7dfd948: rot  ( f7e11f14 5 f7e11f0c )
0xf7dfd94c: over  ( f7e11f14 5 f7e11f0c 5 )
0xf7dfd950: +  ( f7e11f14 5 f7e11f11 )
0xf7dfd954: aligned  ( f7e11f14 5 f7e11f14 )
0xf7dfd958: cell+  ( f7e11f14 5 f7e11f18 )
0xf7dfd95c: >r  ( f7e11f14 5 )
0xf7dfd960: (semis)
[ Finished (") ]  ( f7e11f14 5 )
0xf7e11f1c: type test  ( Empty )
0xf7e11f20: (semis)
[ Finished bar ]  ok
0 > bar
: bar  ( Empty )
0xf7e11f0c: (")
: (")  ( Empty )
0xf7dfd928: r>
[ Up to bar ]  ( f7e11f14 5 )
0xf7e11f1c: type test  ( Empty )
0xf7e11f20: (semis)
[ Finished bar ]  ok
0 >

As eluded to in earlier posts to the list, my initial attempts at adding 
debug support were focused on storing additional information in the 
rstack. Unfortunately this created extra problems in debugging some of 
the more interesting Forth words, since they would manipulate the return 
stack and cause the debugger to get confused.

My final implementation works in a much more simple way; when the debug 
word is invoked with the name of the word to debug, the start and end 
addresses of the word are added to a debug linked list. Then in the 
next() function, we iterate through the linked list to see if the 
current PC lies within one of the functions within. If this is the case, 
we enter the source debugger in step/trace mode as appropriate.

Having given the patch a reasonably good test here, I'm quite pleased 
with the additional functionality it provides. The only minor downsides 
I can see are that the patch adds extra work in docol(), semis() and 
next() in order to update the debug linked list. I've tried to wrap most 
of the complexity in conditional while() statements so that it is only 
invoked while the debugger is active, and so should have a minimal 
impact on normal runtime performance (which seems to be the case here).

Please test the patch and let me know if it requires extra work in order 
for it to be considered ready for committing to the OpenBIOS SVN repository.

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

Attachment (openbios-add-debug.patch): text/x-diff, 15 KiB

Hi all,

Whilst spending some time working on debugging SPARC64 support with 
Qemu/OpenBIOS, it became readily apparent that progress was being 
hampered by the lack of debugging facilities in OpenBIOS (see 
http://lists.openbios.org/pipermail/openbios/2009-August/003949.html). 
Hence I've been working on adding a source debugger to OpenBIOS which 
should enable developers to step/trace through Forth words in order to 
locate bugs in the lower level Forth OpenBIOS code.

The attached patch implements a Forth Source Debugger based upon the 
IEEE-1275 specification; it is not a comprehensive implementation but 
has already proved to be very useful in my tests here. A sample session 
using the debugger goes something like this:

Welcome to OpenBIOS v1.0 built on Oct 31 2009 10:09
   Type 'help' for detailed information

[unix] Booting default not supported.

0 > : bar ." test " ;  ok
0 > debug bar
Stepper keys: <space>/<enter> Up Down Trace Rstack Forth
  ok
0 > bar
: bar  ( Empty )
0xf7e11f0c: (")
: (")  ( Empty )
0xf7dfd928: r>  ( f7e11f0c )
0xf7dfd92c: dup  ( f7e11f0c f7e11f0c )
0xf7dfd930: 2  ( f7e11f0c f7e11f0c 2 )
0xf7dfd934: cells  ( f7e11f0c f7e11f0c 8 )
0xf7dfd938: +  ( f7e11f0c f7e11f14 )
0xf7dfd93c: over  ( f7e11f0c f7e11f14 f7e11f0c )
0xf7dfd940: cell+  ( f7e11f0c f7e11f14 f7e11f10 )
0xf7dfd944:  <at>   ( f7e11f0c f7e11f14 5 )
0xf7dfd948: rot  ( f7e11f14 5 f7e11f0c )
0xf7dfd94c: over  ( f7e11f14 5 f7e11f0c 5 )
0xf7dfd950: +  ( f7e11f14 5 f7e11f11 )
0xf7dfd954: aligned  ( f7e11f14 5 f7e11f14 )
0xf7dfd958: cell+  ( f7e11f14 5 f7e11f18 )
0xf7dfd95c: >r  ( f7e11f14 5 )
0xf7dfd960: (semis)
[ Finished (") ]  ( f7e11f14 5 )
0xf7e11f1c: type test  ( Empty )
0xf7e11f20: (semis)
[ Finished bar ]  ok
0 > bar
: bar  ( Empty )
0xf7e11f0c: (")
: (")  ( Empty )
0xf7dfd928: r>
[ Up to bar ]  ( f7e11f14 5 )
0xf7e11f1c: type test  ( Empty )
0xf7e11f20: (semis)
[ Finished bar ]  ok
0 >

As eluded to in earlier posts to the list, my initial attempts at adding 
debug support were focused on storing additional information in the 
rstack. Unfortunately this created extra problems in debugging some of 
the more interesting Forth words, since they would manipulate the return 
stack and cause the debugger to get confused.

My final implementation works in a much more simple way; when the debug 
word is invoked with the name of the word to debug, the start and end 
addresses of the word are added to a debug linked list. Then in the 
next() function, we iterate through the linked list to see if the 
current PC lies within one of the functions within. If this is the case, 
we enter the source debugger in step/trace mode as appropriate.

Having given the patch a reasonably good test here, I'm quite pleased 
with the additional functionality it provides. The only minor downsides 
I can see are that the patch adds extra work in docol(), semis() and 
next() in order to update the debug linked list. I've tried to wrap most 
of the complexity in conditional while() statements so that it is only 
invoked while the debugger is active, and so should have a minimal 
impact on normal runtime performance (which seems to be the case here).

Please test the patch and let me know if it requires extra work in order 
for it to be considered ready for committing to the OpenBIOS SVN repository.

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

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