OpenBIOS March 2013

openbios@openbios.org

10 participants
31 discussions

setting the reg property of the mac-io node
by Programmingkid 02 Apr '13

02 Apr '13

I am trying to set the reg property of the mac-io node so it matches the properties of a real Beige G3 computer. Does anyone know the file that this information is kept in? Mac OS X is very sensitive to the value of properties in Open Firmware. One wrong value is enough to stop Mac OS X from booting. Since OpenBIOS has a ton of missing and different values for properties with respect to the Beige G3, I theorized that this might be the reason why OpenBIOS can't make Mac OS X run. Any help with locating the reg property for the mac-io node would be great.

2 1

Re: [OpenBIOS] [Qemu-devel] OpenBios in Sparc can't handle long kernel command lines.
by Mark Cave-Ayland 30 Mar '13

30 Mar '13

On 22/03/13 05:19, Rob Landley wrote: > If I do this: > > qemu-system-sparc -nographic -no-reboot -kernel image -hda hda.sqf > -append 'root=/dev/sda rw init=/sbin/init.sh panic=1 > PATH=/usr/distcc:/bin:/sbin console=ttyS0 HOST=sparc CPUS=1 > DISTCC_HOSTS=10.0.2.2:31322/1 FTP_SERVER=10.0.2.2 FTP_PORT=31307 > NATIVE_BUILD=lfs-bootstrap ' -hdb hdb.img -hdc lfs-bootstrap.hdc -m 256 > > qemu goes: > > ^[[H^[[JConfiguration device id QEMU version 1 machine id 32 > CPUs: 1 x FMI,MB86904 > Unhandled Exception 0x00000007 > PC = 0xffd07d28 NPC = 0xffd07d2c > Stopping execution > > And then hangs. I've never figured out why it clears the screen first > (none of the other targets do), but I _have_ figured out that the > unhandled exception is "kernel command line too long". Because 197 bytes > is just too much data for Sparc to cope with. This is actually a bug in OpenBIOS which declares the command line storage like this: static void arch_init( void ) { static char cmdline[128]; .... kernel_cmdline = (const char *) fw_cfg_read_i32(FW_CFG_KERNEL_CMDLINE); if (kernel_cmdline) { size = strlen(kernel_cmdline); memcpy(cmdline, kernel_cmdline, size); obp_arg.argv[1] = cmdline; } cmdline[size] = '\0'; .... } Would increasing it to 256 bytes be enough? I can't say I've ever come across command lines in a normal environment with more than about 80 characters, but I don't see an issue with increasing it. ATB, Mark.

3 2

Re: [OpenBIOS] selecting a sparc framebuffer from command line
by Mark Cave-Ayland 30 Mar '13

30 Mar '13

On 27/03/13 16:43, Artyom Tarasenko wrote: >> So as a stepping stone, should we create an FCode ROM for TCX? > > Sounds reasonable to me, but > - afaik the current TCX implementation is written in C, no Forth. So > maybe it's easier to keep the current implementation in OpenBIOS and > just add some kind of auto-detection. > - I'm not a graphic guy. :) I run qemu -nographic whenever possible. > So I'd wait till someone from the graphic side comments on it. > > Blue? Mark? I'm actually slightly ahead of you here. Take a look at my OpenBIOS console patchset I posted a couple of weeks ago, and in particular this patch: http://www.openfirmware.info/pipermail/openbios/2013-March/007491.html. Both tcx.fs and vga.fs were deliberately designed so that with minimum effort they can be converted to an Fcode payload suitable for a display device, similar to as mentioned here: http://docs.oracle.com/cd/E19683-01/806-1379-10/displydv.html. The minor downside is that we'd have to specify fcode-utils as a dependency for building the resulting Fcode images, but that's not insurmountable. So yes, if QEMU are happy to host the FCode binaries then it would be great if we could specify the SPARC cg3 framebuffer using something like: -device cg3,rom=QEMU,cg3.bin Obviously the in-built QEMU,cg3.bin would be the default file if rom= was not specified, but it means that people booting using real SUN OBP images can point to a real SUNW Fcode display ROM and use that if desired with the same patch. ATB, Mark.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Artyom Tarasenko 28 Mar '13

28 Mar '13

On Thu, Mar 28, 2013 at 4:04 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > On Thu, Mar 28, 2013 at 3:23 PM, Mark Cave-Ayland > <mark.cave-ayland(a)ilande.co.uk> wrote: > >> obp_nextnode() is actually very simple in that it just calls the Forth >> "peer" word. Do you see the same phandles if you cycle through the device >> tree using "peer" directly from the OpenBIOS prompt? >> >> 0 peer >> dup u. peer > > 0 > 0 peer dup u. ffd2e31c ok > 1 > peer u. 0 ok > > I guess '/' has no peers, one would have to descend. > > Otherwise it looks sane: > > 0 > ffd2e438 ok > 1 > peer dup u. ffd2e4dc ok > 1 > peer dup u. ffd2e684 ok > 1 > peer dup u. ffd2e6fc ok > 1 > peer dup u. ffd2e7e0 ok > 1 > peer dup u. ffd34050 ok > 1 > peer dup u. ffd35a58 ok > 1 > peer dup u. ffd35afc ok > 1 > peer dup u. ffd35ba8 ok > 1 > peer dup u. ffd36360 ok > 1 > peer dup u. ffd3972c ok > 1 > peer dup u. 0 ok > > ffd3972c - is the same value as in the show-devs output. No, that's a wrong trail. The address of the "FMI,MB86904" node is just different depending on whether the -prom-env 'auto-boot?=false' is used. Might be a bug (all other nodes don't depend on the qemu command line), but irrelevant to this case. If I boot with auto-boot?=false and then boot disk it shows the proper address, but crashes the same way. Will give it another try next week(end). -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 28 Mar '13

28 Mar '13

On 28/03/13 13:52, Artyom Tarasenko wrote: >> Can you put together a quick patch for obp_child() and obp_nextnode() so >> that if CONFIG_DEBUG_OBP is enabled, they also output the package name in >> the debug string as well as the phandle? Take a look at how obp_proplen uses >> get-package-property in order to get hold of the "name" property from the >> package. >> >> (Or in fact, for an even quicker hack, the (void) POP() in obp_proplen() is >> dropping a pointer to a string itself. So if you display that instead then >> for your output above you should see the package name displayed) > > Ok. Did the later, and now it looks even stranger: > > obp_proplen(0xffd35ba8, name) = 6 (iommu) > obp_nextnode(0xffd35ba8) = 0xffd36360 > obp_proplen(0xffd36360, name) = 5 (obio) > obp_nextnode(0xffd36360) = 0xffd39724 > obp_proplen(0xffd39724, name) = 12 (FMI,MB86904) > obp_nextnode(0xffd39724) = 0x0 > Unhandled Exception 0x00000007 > > But: > 0> show-devs > ffd2e31c / > [...] > ffd35ba8 /iommu > [...] > ffd36360 /obio (hierarchical) > [...] > ffd3972c /FMI,MB86904 (cpu) > > Why does obp_nextnode(0xffd36360) return 0xffd39724 ? According to > show-devs it must be 0xffd3972c ! Yeah... that doesn't like quite right at all :/ obp_nextnode() is actually very simple in that it just calls the Forth "peer" word. Do you see the same phandles if you cycle through the device tree using "peer" directly from the OpenBIOS prompt? 0 peer dup u. peer dup u. peer dup u. peer ..etc.. ATB, Mark.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 28 Mar '13

28 Mar '13

On 28/03/13 08:38, Artyom Tarasenko wrote: > Back to the original topic: > > Here is the boot log with romvec debug: > > Configuration device id QEMU version 1 machine id 32 > CPUs: 1 x FMI,MB86904 > UUID: 00000000-0000-0000-0000-000000000000 > Welcome to OpenBIOS v1.0 built on Mar 26 2013 13:29 > Type 'help' for detailed information > Trying disk... > Not a bootable ELF image > Loading a.out image... > Loaded 7680 bytes > entry point is 0x4000 > bootpath: /iommu/sbus/espdma/esp/sd@0,0 > > Jumping to entry point 00004000 for type 00000005... > switching to new context: > obp_nextnode(0x0) = 0xffd4531c > obp_child(0xffd4531c) = 0xffd45438 > obp_proplen(0xffd45438, name) = 8 > obp_nextnode(0xffd45438) = 0xffd454dc > obp_proplen(0xffd454dc, name) = 9 > obp_nextnode(0xffd454dc) = 0xffd45684 > obp_proplen(0xffd45684, name) = 8 > obp_nextnode(0xffd45684) = 0xffd456fc > obp_proplen(0xffd456fc, name) = 7 > obp_nextnode(0xffd456fc) = 0xffd457e0 > obp_proplen(0xffd457e0, name) = 8 > obp_nextnode(0xffd457e0) = 0xffd4b084 > obp_proplen(0xffd4b084, name) = 9 > obp_nextnode(0xffd4b084) = 0xffd4ca8c > obp_proplen(0xffd4ca8c, name) = 7 > obp_nextnode(0xffd4ca8c) = 0xffd4cb30 > obp_proplen(0xffd4cb30, name) = 15 > obp_nextnode(0xffd4cb30) = 0xffd4cbdc > obp_proplen(0xffd4cbdc, name) = 6 > obp_nextnode(0xffd4cbdc) = 0xffd4d394 > obp_proplen(0xffd4d394, name) = 5 > obp_nextnode(0xffd4d394) = 0xffd50758 > obp_proplen(0xffd50758, name) = 12 > obp_nextnode(0xffd50758) = 0x0 > obp_devopen(/iommu/sbus/espdma/esp/sd@0,0) = 0xffc831f8 > obp_devseek(fd 0xffc831f8, hi 0, lo 3637248) = 0 > obp_devread(fd 0xffc831f8, buf 0x4000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3645440) = 0 > obp_devread(fd 0xffc831f8, buf 0x6000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3653632) = 0 > obp_devread(fd 0xffc831f8, buf 0x8000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3661824) = 0 > obp_devread(fd 0xffc831f8, buf 0xa000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3670016) = 0 > obp_devread(fd 0xffc831f8, buf 0xc000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3678208) = 0 > obp_devread(fd 0xffc831f8, buf 0xe000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3686400) = 0 > obp_devread(fd 0xffc831f8, buf 0x10000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3694592) = 0 > obp_devread(fd 0xffc831f8, buf 0x12000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3702784) = 0 > obp_devread(fd 0xffc831f8, buf 0x14000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3710976) = 0 > obp_devread(fd 0xffc831f8, buf 0x16000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3719168) = 0 > obp_devread(fd 0xffc831f8, buf 0x18000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3727360) = 0 > obp_devread(fd 0xffc831f8, buf 0x1a000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3743744) = 0 > obp_devread(fd 0xffc831f8, buf 0x1c000, nbytes 8192) = 8192 > obp_devclose(0xffc831f8) = 1 > obp_nextnode(0x0) = 0xffd4531c > obp_child(0xffd4531c) = 0xffd45438 > obp_proplen(0xffd45438, name) = 8 > obp_nextnode(0xffd45438) = 0xffd454dc > obp_proplen(0xffd454dc, name) = 9 > obp_nextnode(0xffd454dc) = 0xffd45684 > obp_proplen(0xffd45684, name) = 8 > obp_nextnode(0xffd45684) = 0xffd456fc > obp_proplen(0xffd456fc, name) = 7 > obp_nextnode(0xffd456fc) = 0xffd457e0 > obp_proplen(0xffd457e0, name) = 8 > obp_nextnode(0xffd457e0) = 0xffd4b084 > obp_proplen(0xffd4b084, name) = 9 > obp_nextnode(0xffd4b084) = 0xffd4ca8c > obp_proplen(0xffd4ca8c, name) = 7 > obp_nextnode(0xffd4ca8c) = 0xffd4cb30 > obp_proplen(0xffd4cb30, name) = 15 > obp_nextnode(0xffd4cb30) = 0xffd4cbdc > obp_proplen(0xffd4cbdc, name) = 6 > obp_nextnode(0xffd4cbdc) = 0xffd4d394 > obp_proplen(0xffd4d394, name) = 5 > obp_nextnode(0xffd4d394) = 0xffd50758 > > ^^^^ is that correct? > > obp_proplen(0xffd50758, name) = 12 > obp_nextnode(0xffd50758) = 0x0 > Unhandled Exception 0x00000007 > PC = 0x00401a04 NPC = 0x00401a08 > Stopping execution > > Now, the last obp_nextnode looks suspicious. It looks like the boot > process is iterating over the devices in / without descending, but I > don't see the node 0xffd50758. The last two known ones are /iommu > (0xffd4cbdc) and /obio (0xffd4d394) Interesting. Perhaps it could be being added by something earlier in the bootcode? Can you put together a quick patch for obp_child() and obp_nextnode() so that if CONFIG_DEBUG_OBP is enabled, they also output the package name in the debug string as well as the phandle? Take a look at how obp_proplen uses get-package-property in order to get hold of the "name" property from the package. (Or in fact, for an even quicker hack, the (void) POP() in obp_proplen() is dropping a pointer to a string itself. So if you display that instead then for your output above you should see the package name displayed) ATB, Mark.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Lennart Sorensen 28 Mar '13

28 Mar '13

On Tue, Mar 26, 2013 at 08:28:58PM +0100, Artyom Tarasenko wrote: > That would explain it, but are you sure that was already so in the > SunOS 4.x times? > > $ dd if=sunos.img of=sunos4.bb bs=512 skip=1 count=15 > 15+0 records in > 15+0 records out > 7680 bytes (7.7 kB) copied, 6.3956e-05 s, 120 MB/s > $ file sunos4.bb > sunos4.bb: sparc executable not stripped > $ sparc64-linux-gnu-objdump -x sunos4.bb > > sunos4.bb: file format a.out-sunos-big > sunos4.bb > architecture: sparc, flags 0x0000003e: > EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS > start address 0x00440000 > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 00001a58 00000000 00000000 00000020 2**3 > CONTENTS, ALLOC, LOAD, CODE > 1 .data 00000310 00001a58 00001a58 00001a78 2**3 > CONTENTS, ALLOC, LOAD, DATA > 2 .bss 0000c588 00001d68 00001d68 00000000 2**3 > ALLOC > sparc64-linux-gnu-objdump: sunos4.bb: File truncated The boot file for sunos4 at http://chris.shenton.org/sysadm/xterminals/ is a 110336 byte a.out binary by the looks of it. I am not sure if all sun machines used openboot with forth. Anyone know? -- Len Sorensen

4 10

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Lennart Sorensen 27 Mar '13

27 Mar '13

On Wed, Mar 27, 2013 at 06:04:07PM +0100, Artyom Tarasenko wrote: > On Wed, Mar 27, 2013 at 5:44 PM, Lennart Sorensen > <lsorense(a)csclub.uwaterloo.ca> wrote: > > On Tue, Mar 26, 2013 at 04:07:15PM -0400, wrote: > >> On Tue, Mar 26, 2013 at 08:28:58PM +0100, Artyom Tarasenko wrote: > >> > That would explain it, but are you sure that was already so in the > >> > SunOS 4.x times? > >> > > >> > $ dd if=sunos.img of=sunos4.bb bs=512 skip=1 count=15 > >> > 15+0 records in > >> > 15+0 records out > >> > 7680 bytes (7.7 kB) copied, 6.3956e-05 s, 120 MB/s > >> > $ file sunos4.bb > >> > sunos4.bb: sparc executable not stripped > >> > $ sparc64-linux-gnu-objdump -x sunos4.bb > >> > > >> > sunos4.bb: file format a.out-sunos-big > >> > sunos4.bb > >> > architecture: sparc, flags 0x0000003e: > >> > EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS > >> > start address 0x00440000 > >> > > >> > Sections: > >> > Idx Name Size VMA LMA File off Algn > >> > 0 .text 00001a58 00000000 00000000 00000020 2**3 > >> > CONTENTS, ALLOC, LOAD, CODE > >> > 1 .data 00000310 00001a58 00001a58 00001a78 2**3 > >> > CONTENTS, ALLOC, LOAD, DATA > >> > 2 .bss 0000c588 00001d68 00001d68 00000000 2**3 > >> > ALLOC > >> > sparc64-linux-gnu-objdump: sunos4.bb: File truncated > >> > >> The boot file for sunos4 at http://chris.shenton.org/sysadm/xterminals/ > >> is a 110336 byte a.out binary by the looks of it. > >> > >> I am not sure if all sun machines used openboot with forth. Anyone know? > > > > Well I found a page that said the sun4/110 does not use forth (and > > apparently this made the firmware interface vastly faster to work with > > than the ones written in forth). So at least some early sparc boxes > > had a sun3 style firmware. Probably meant the boot code would be different > > too on those. > > > > My guess would be that the sun4/1xx and sun4/2xx were not openboot, > > while the sparcstation and sparcserver models probable all are. > > So probably sun4c and sun4m were the first with openboot then. Sure is > > hard to find good details on these old things. > > It doesn't look like FCode: > > $ hexdump -C sunos4.bb |head > 00000000 01 03 01 07 00 00 1a 58 00 00 03 10 00 00 c5 88 |.......X........| > 00000010 00 00 06 cc 00 44 00 00 00 00 00 00 00 00 00 00 |.....D..........| > 00000020 30 80 00 43 00 1b c0 10 00 1b d0 10 00 1b e0 10 |0..C............| > 00000030 00 1b f0 10 00 1c 00 10 00 1c 10 10 00 1c 20 10 |.............. .| > > There is no marker fd 03, mentioned by Tarl. > > But still it's somehow strange a.out: I tried objdump from Linux/sparc > and from Solaris/Sparc. Both of them can't extract the symbols, in > spite of claiming that "HAS_DEBUG, HAS_SYMS". The one I looked at says: boot.sun4c.sunos.4.1.3: file format a.out-sunos-big boot.sun4c.sunos.4.1.3 architecture: sparc, flags 0x00000002: EXEC_P start address 0x00300000 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00016960 00000000 00000000 00000020 2**3 CONTENTS, ALLOC, LOAD, CODE 1 .data 00004580 00016960 00016960 00016980 2**3 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00018550 0001aee0 0001aee0 00000000 2**3 ALLOC SYMBOL TABLE: no symbols -- Len Sorensen

1 0

Re: [OpenBIOS] selecting a sparc framebuffer from command line
by Artyom Tarasenko 27 Mar '13

27 Mar '13

On Wed, Mar 27, 2013 at 3:54 PM, Bob Breuer <breuerr(a)mc.net> wrote: > On 3/26/2013 12:24 PM, Artyom Tarasenko wrote: >> On Tue, Mar 26, 2013 at 4:08 PM, Bob Breuer <breuerr(a)mc.net> wrote: >>> On 3/26/2013 6:13 AM, Artyom Tarasenko wrote: >>>> It looks like we will have more framebuffers beside TCX in the near future. >>>> One way to use them would be to make new machines combining a base >>>> machine name with a framebuffer name, like ss5tcx and ss5cg3, but I >>>> guess this would produce too many machines if we have more than 2 >>>> framebuffers. >>>> >>>> Should the "-vga" option be (mis)used for selecting a framebuffer? >>>> They are not called "VGA" in the wild, but maybe the name VGA is >>>> obvious enough for a modern user? After all there is already a "-hda" >>>> option in the SPARCStation-5 emulation command line, although in the >>>> non-emulating world no one calls scsi disk "hda". >>>> >>>> Or should an architecture-specific option, like -framebuffer be added? >>>> >>> >>> I would like to see -device used. With a better sbus framework, adding >>> multiple video devices on sparc32 should be really easy to do. >>> >>> I just looked at how "-device cirrus-vga" works. To get -device to >>> override the default video, we need to add minimal support into vl.c to >>> recognize each video device and handle the default_vga flag. Then >>> sparc32 could limit itself to handling either VGA_NONE or VGA_STD when >>> it adds the default video. >> >> Oh, that's even better! >> And then how would the OpenBIOS find out what framebuffer to use? > > For a single display device, can it do just like OBP? Run all FCode > roms, then find the display device in the device tree. > > For multiple devices, how to select the primary? Possibly just use the > first one found. OBP provides some control over this with > sbus-probe-list. As a parallel question, for a PC with 2 PCI video > cards, which one gets used as the BIOS display? Just trying > "qemu-system-i386 -device cirrus-vga -device cirrus-vga" gives an error > about RAMBlock already registered. > >> Would -device cg3 add the FCode ROM? Or do we need another -device for that? > > The FCode ROM should be integrated with the device, similar to a PCI > device with an expansion rom. The SBUS specification defines a rom to > be at offset 0 of the slot. Probably setup a memory region container > for each sbus slot so that the device addresses are relative to the slot > base and isolated from the system address space. > > For the existing TCX, looks like it also has space for a rom at offset > 0. See ftp://ftp.rodents-montreal.org/pub/mouse/docs/Sun/S24/memory-map > > So as a stepping stone, should we create an FCode ROM for TCX? Sounds reasonable to me, but - afaik the current TCX implementation is written in C, no Forth. So maybe it's easier to keep the current implementation in OpenBIOS and just add some kind of auto-detection. - I'm not a graphic guy. :) I run qemu -nographic whenever possible. So I'd wait till someone from the graphic side comments on it. Blue? Mark? -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Tarl Neustaedter 26 Mar '13

26 Mar '13

[ oops. Re-sending to entire alias. ] On 2013-Mar-26 15:28 , Artyom Tarasenko wrote: >> >It shouldn't be a.out. The bootloader (on blocks 1-15) of a Solaris disk is >> >an fcode file (compiled forth). >> > > That would explain it, but are you sure that was already so in the > SunOS 4.x times? Ah. Sorry, missed the SunOS 4.x comment. That was before my time (I started at Sun in 1994, when we had just transitioned to Solaris 2), so I wouldn't know for sure. If the first two bytes of the bootloader are "fd 03", it's FCode (That's the "fcode-version3"). Otherwise it may be a.out

1 0