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 … [View More]

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 &… [View More]

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. > > … [View More]

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.… [View More]

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 >> … [View More]

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 > … [View More]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. [View Less]

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 > … [View More]

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.… [View More]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 [View Less]

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 … [View More]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 [View Less]

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. … [View More]

1 0