OpenBIOS August 2011

openbios@openbios.org

19 participants
88 discussions

Re: [OpenBIOS] [PATCH 10/10] Adding filll Forth primitive
by Tarl Neustaedter 16 Aug '11

16 Aug '11

On 2011-Aug-15 23:16 , William Hahne wrote: > Well, the point of these patches is to allow Mac OS to be booted from > OpenBIOS. So actually in this case using Apple's implementation as a > reference is exactly what should be done. > Right. Just be careful of busting everything else in the name of making MacOS work.

1 0

Re: [OpenBIOS] [PATCH 10/10] Adding filll Forth primitive
by Tarl Neustaedter 16 Aug '11

16 Aug '11

On 2011-Aug-15 22:04 , William Hahne wrote: > [...] This suggests that it may be an non-standard addition by Apple. You > are right about the inconsistency. [...] I will comment that back when 1275 was still active, we noted that Apple's implementation had sufficiently diverged from Sun's, Firmworks and IBM's implementations (and the standard) that PCI card vendors who did FCode ended up shipping two different versions - an Apple version and a Sun version. I just mention this in terms of being careful not to take Apple's implementation as a reference standard.

2 1

Re: [OpenBIOS] [PATCH 10/10] Adding filll Forth primitive
by Andreas Färber 16 Aug '11

16 Aug '11

Am 09.08.2011 um 23:55 schrieb William Hahne: > This is a forth primitive that is required by BootX. It just fills > some specified memory address and length with longs. > > > Index: kernel/forth.c > =================================================================== > --- kernel/forth.c (revision 1041) > +++ kernel/forth.c (working copy) > @@ -1610,6 +1616,20 @@ > memset(src, value, count); > } > > +/* > + * filll ( addr len byte -- ) > + */ > +static void filll(void) > +{ > + ucell value = POP(); > + ucell count = POP(); > + ucell *dest = (ucell *)cell2pointer(POP()); > + > + int i; > + for (i = 0; i <= count / 4; i++) { > + dest[i] = value; > + } > +} This word puzzles me: The extra l in filll seems to be for "long" according to the patch description. But there's a hardcoded arithmetic with 4 and the parameter is documented as byte yet is being written ucell-wide. That strikes me as inconsistent. Either 4 needs to be replaced with sizeof(ucell) to fit sparc64, or the division by 4 dropped and uint8_t* written len times. Andreas

2 1

Re: [OpenBIOS] [PATCH 5/10] Add draw-rectangle to the display package
by Mark Cave-Ayland 16 Aug '11

16 Aug '11

On 10/08/11 16:35, William Hahne wrote: > I am not sure if it is officially part of any specification. BootX > doesn't even assume that it was there and attempted to add its own > "draw-rectangle" word, but unfortunately the method it uses to add words > to packages doesn't work with OpenBIOS. Just adding draw-rectangle > seemed like a much simpler and safer solution than changing the way > device packages work. Also from what I could see it looked like a > serious rewrite might be necessary just to get one small edge case to work. Ah I see - so the real bug is that OpenBIOS can't add the word correctly? Do you have any DEBUG_CIF traces so we can determine the Forth being sent to OpenBIOS and come up with a fix for that? 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

2 1

Re: [OpenBIOS] [PATCH 7/10] Apple local variables implementation in Forth
by Programmingkid 16 Aug '11

16 Aug '11

On Aug 15, 2011, at 11:01 AM, openbios-request(a)openbios.org wrote: > Message: 2 > Date: Mon, 15 Aug 2011 13:03:29 +0100 > From: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> > To: openbios(a)openbios.org > Subject: Re: [OpenBIOS] [PATCH 7/10] Apple local variables > implementation in Forth > Message-ID: <4E490B11.2040806(a)siriusit.co.uk> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 10/08/11 16:43, William Hahne wrote: > >> Very interesting. I think this needs someone with quite strong >> Forth-fu (Stefan) to review this one. Also I can't see any related >> documentation with this patch related to locals support? >> >> >> This is an Apple specific thing. See >> http://www.openfirmware.info/How_Local_Variables_in_Forth_Work_---_Using_Ap… > > Right I understand this, but I'm fairly sure there is an official spec > for Forth local variables somewhere. For something to be committed, I'd > expect the commit reference to contain a link to the source > specification and comments in the code giving an indication as to what > the level of implementation actually is (I absolutely understand that it > can be impractical to implement everything within the time available). > > > ATB, > > Mark. There doesn't appear to be any official specification to local variables in Forth. From what I remember, the very creator of Forth was against them. It looks like the only way to understand Apple's local variables support is to see how their own code behaves in OpenFirmware. I have found suggestions on how to add local variables support to forth, but never any thing "official".

1 0

Help with libopenbios/ofmem_common.c line 175 "insert in the freelist"
by Kenneth Salerno 15 Aug '11

15 Aug '11

Hi, I finally got around to running QEMU in gdb to debug the AIX V6.1 boot hang and was able to get past where I got stuck previously: ------------------------------------------------------------------------------- Welcome to AIX. boot image timestamp: 00:39 35/2D NULL ihandle The current time and date: 00:00:00 228784/00/0008 processor count: 1; memory size: 1024MB; kernel size: 2293829 boot device: cd:\ppc\chrp\bootfile.exe Validation failed: the "/rtas" device node does not exist. EXIT It used to hang after "boot device: cd:\ppc\chrp\bootfile.exe" with OpenBIOS stuck at line 175 of libopenbios/ofmem_common.c: for( pp=&ofmem->mfree; *pp && (**pp).size < d->size ; pp = &(**pp).next ) { } I made the following hack to get it to progress to the RTAS validation: --- ofmem_common.c.ORIG 2011-08-08 17:04:25.375000000 -0400 +++ ofmem_common.c 2011-08-08 17:04:45.875000000 -0400 @@ -172,8 +172,9 @@ d->next = ofmem->mfree; /* insert in the (sorted) freelist */ - for( pp=&ofmem->mfree; *pp && (**pp).size < d->size ; pp = &(**pp).next ) { - } +/* for( pp=&ofmem->mfree; *pp && (**pp).size < d->size ; pp = &(**pp).next ) { + } */ + pp=&ofmem->mfree; d->next = *pp; *pp = d; Before I made the above change, the following is what I saw in gdb and qemu console: (qemu) info cpus * CPU #0: nip=0x00000000fff91a84 thread_id=6828 (gdb) 0x00000000fff91a84 in ofmem_free (ptr=0x3fca1774) at ../libopenbios/ofmem_common.c:175 175 for( pp=&ofmem->mfree; *pp && (**pp).size < d->size ; pp = &(**pp).next ) { (gdb) print /x pp $1 = 0x3fc9e0ac The value 0x3fc9e0ac can be found in register GPR08: (qemu) info registers NIP 00000000fff91a84 LR 00000000fff91a58 CTR 00000000fff93784 XER 000000002000 0000 MSR 0000000000003032 HID0 0000000060000000 HF 0000000000002000 idx 1 TB 00000001 7638146663 DECR 951787926 GPR00 000000003fca1764 000000003fdf69e0 00000000fffc68e8 000000003fc9e0ac GPR04 00000000fffc0088 000000003fc5bc68 00000000fffc0860 0000000000044200 GPR08 0000000000000002 000000003fc9e0ac 0000000000000024 0000000000000810 GPR12 00000000000088ac 0000000000000000 00000000fffb6703 00000000fffb7b65 GPR16 00000000fffb8331 00000000fffb6706 0000000004000000 00000000fffbf6b8 GPR20 00000000fffbf634 00000000fffc68e8 00000000fffbf634 00000000fffb650a GPR24 00000000fffb64f8 00000000fffb6478 00000000fffb6500 00000000fffb6505 GPR28 00000000fffb707e 0000000000000027 0000000000000027 000000003fca1774 CR 48000084 [ G L - - - - L G ] RES ffffffffffffffff FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPSCR 00000000 SRR0 00000000fffaa590 SRR1 0000000000003032 PVR 00000000003c0301 VRSAVE 000 0000000000000 SPRG0 000000003fe00000 SPRG1 000000003fdf6630 SPRG2 0000000000000000 SPRG3 000 0000000000000 SPRG4 0000000000000000 SPRG5 0000000000000000 SPRG6 0000000000000000 SPRG7 000 0000000000000 SDR1 000000003fe00000 Here is my QEMU command: ./testing/qemu/ppc64-softmmu/qemu-system-ppc64 \ -L ./testing/qemu/pc-bios \ -m 1024 \ -bios ./testing/openbios-devel/obj-ppc64/openbios-qemu.elf -drive file=images/aix.img,index=0,media=disk,cache=writeback -cdrom images/ibmaix.iso \ -boot d \ -nographic \ -rtc base=localtime,clock=host \ -uuid 17202d0a-45f8-4159-a8e1-78b866f50aa7 \ -serial tcp::9979,server,nowait \ -monitor tcp::9980,server,nowait \ -gdb tcp::1234 powerpc64-unknown-linux-gnu-gdb testing/openbios-devel/obj-ppc64/openbios-qemu.elf-nostrip I don't really know what I'm doing so any help explaining this function in ofmem_common.c would be appreciated. Thank you, Ken

2 3

Re: [OpenBIOS] [PATCH 6/10] Wrapped HFS+ incorrectly recognized
by Natalia Portillo 15 Aug '11

15 Aug '11

I confirm the patch is correct. As of Apple TechNote 1150 at http://developer.apple.com/library/mac/#technotes/tn/tn1150.html the wrapper address is at byte 0x07c. vol is declared as UInt16 and so the offset advanced two bytes each step, then correct offset is 0x3e in 16-bit words. El 10/08/2011, a las 16:41, William Hahne escribió: > > > On Wed, Aug 10, 2011 at 5:56 AM, Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> wrote: > On 09/08/11 22:54, William Hahne wrote: > > The code for checking for a wrapped HFS+ volume looks at the wrong offset. > > Index: fs/hfsplus/hfsp_volume.c > =================================================================== > --- fs/hfsplus/hfsp_volume.c (revision 1041) > +++ fs/hfsplus/hfsp_volume.c (working copy) > @@ -302,7 +302,7 @@ > os_read(fd, vol, 2, HFSP_BLOCKSZ_BITS); > if (__be16_to_cpu(vol[0]) == HFS_VOLHEAD_SIG && > - __be16_to_cpu(vol[0x7c]) == HFSP_VOLHEAD_SIG) { > + __be16_to_cpu(vol[0x3e]) == HFSP_VOLHEAD_SIG) { > ret = -1; > } else if (__be16_to_cpu(vol[0]) == HFSP_VOLHEAD_SIG) { > ret = -1; > > Same comment as for patch 2/10. > > > Actually I think this one is not contrary to the specification but is just a mix up between a 8bit and 16bit array. The original value seems to assume that vol is an array of 8bit integers while it is an array of 16bit integers. If you notice the corrected value is half of the original value. I can look up the documentation but it seems unnecessary in this case. > > > 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 > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you > > William Hahne > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you

2 1

Re: [OpenBIOS] [PATCH 2/10] Ignore extraneous partitions
by Natalia Portillo 15 Aug '11

15 Aug '11

Hi, There is no documentation saying that but you may freely interpret as those things are NOT partitions in apple speaking, they are ALWAYS called just drivers. El 10/08/2011, a las 16:23, William Hahne escribió: > On Wed, Aug 10, 2011 at 5:48 AM, Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> wrote: > On 09/08/11 22:54, William Hahne wrote: > > BootX will only check the first few partitions from mac-parts to find > the Mac OS partition. So it must expect drivers and void partitions to > be ignored. This patch makes it so that if you specify the partition > cd:1 and partition 1 is a driver it will keep checking partitions until > reaching the first non-driver and non-void partition. > > Index: packages/mac-parts.c > =================================================================== > --- packages/mac-parts.c (revision 1041) > +++ packages/mac-parts.c (working copy) > @@ -200,15 +203,26 @@ > } else { > /* Another partition was explicitly requested */ > - SEEK( bs * parnum ); > - READ( &par, sizeof(par) ); > + > + /* We have to find the first valid partition corresponding to the > given number. > + This is because Apple sometimes includes a bunch of extra partitions > that > + BootX expects to be ignored */ > + while (parnum < par.pmMapBlkCnt) { > + SEEK( bs * parnum ); > + READ( &par, sizeof(par) ); > - if( (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsValid) && > - (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsAllocated) && > - (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsReadable) ) { > + /* Check if valid, also device driver partitions are expected to be > ignored */ > + if( (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsValid) && > + (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsAllocated) && > + (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsReadable) && > + !(__be32_to_cpu(par.pmPartStatus) & kPartitionIsRealDeviceDriver)) { > - offs = (long long)__be32_to_cpu(par.pmPyPartStart) * bs; > - size = (long long)__be32_to_cpu(par.pmPartBlkCnt) * bs; > + offs = (long long)__be32_to_cpu(par.pmPyPartStart) * bs; > + size = (long long)__be32_to_cpu(par.pmPartBlkCnt) * bs; > + break; > + } > + > + parnum++; > } > } > > I remember last time I reworked this, I had to spend a lot of time reading the Apple HFS documentation with regard to this. Could you add a link to the documentation on the Apple site into the commit message, and confirm whether this is something I missed which is documented or it's new behaviour that you have discoverd through testing. > > This is something I discovered through testing and carefully looking through the BootX source code. I don't know if there is documentation on this or not. > > William Hahne > > > 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 > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you

2 1

Re: [OpenBIOS] [PATCH 10/10] Adding filll Forth primitive
by Mark Cave-Ayland 15 Aug '11

15 Aug '11

On 10/08/11 16:50, William Hahne wrote: > This looks reasonably straightforward - again, can you add a > reference to the documentation for this word as part of the commit > message? > > I wish I could. I had to do reverse engineer it from Apple's OF > implementation. I don't believe it is an official OF word. Right that makes sense. Looking closer at the code, it strikes me that this particular word should be written in Forth rather than C (i.e. we don't really want to have to drop into C unless we really have to). After that I can't think there would be much else the PPC maintainers would object to. 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

1 0

Re: [OpenBIOS] [PATCH 8/10] Check that stdout variable is not null
by Mark Cave-Ayland 15 Aug '11

15 Aug '11

On 10/08/11 16:44, William Hahne wrote: > Hmmm isn't this just hiding another bug which is that the stdout > variable/defer is being set? > > I think it is a bug in BootX (at least I would call it a bug.) Modifying > BootX isn't a particularly realistic option so the workaround is necessary. Right so it definitely looks as if BootX is overriding the default value in arch/ppc/qemu/init.c. Do you have any suitable DEBUG_CIF traces for us to look at? 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

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →