Hi all,
After all the refactoring work, I got around to re-working the init-program and go words and plugging the new unified ELF loader into the SPARC64 build.
And the result? As of SVN r730, I'm pleased to report that the Solaris kernel starts to execute on my Milax test ISO. After typing "go" to execute the loaded ELF image manually, I see a twirly baton rotating on the console for about 0.5s before the inevitable segfault. So it's a small step, but still a great milestone for the OpenBIOS project :D
Happy holidays,
Mark.
On 4/2/10, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Hi all,
After all the refactoring work, I got around to re-working the init-program and go words and plugging the new unified ELF loader into the SPARC64 build.
And the result? As of SVN r730, I'm pleased to report that the Solaris kernel starts to execute on my Milax test ISO. After typing "go" to execute the loaded ELF image manually, I see a twirly baton rotating on the console for about 0.5s before the inevitable segfault. So it's a small step, but still a great milestone for the OpenBIOS project :D
Nice work, there was a lot of cleaning up to do. How do you get the kernel loaded manually?
Blue Swirl wrote:
Nice work, there was a lot of cleaning up to do. How do you get the kernel loaded manually?
Thanks :)
I'm not sure what you mean by that? The Fcode in the ISO does all of the loading, and the OpenBIOS ELF loader does the relocation when the Fcode calls init-program. If you try and boot from the Milax ISO under qemu, all you have to do is type "go" once you get returned to the Forth prompt to move the PC to the relocated image and start executing.
ATB,
Mark.
On 4/2/10, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Blue Swirl wrote:
Nice work, there was a lot of cleaning up to do. How do you get the kernel loaded manually?
Thanks :)
I'm not sure what you mean by that? The Fcode in the ISO does all of the loading, and the OpenBIOS ELF loader does the relocation when the Fcode calls init-program. If you try and boot from the Milax ISO under qemu, all you have to do is type "go" once you get returned to the Forth prompt to move the PC to the relocated image and start executing.
Sorry, I misread that you had loaded the kernel manually.
The crash seems to happen within OpenBIOS.
Blue Swirl wrote:
Sorry, I misread that you had loaded the kernel manually.
The crash seems to happen within OpenBIOS.
Yeah, it did seem to lie within the OpenBIOS symbol range. Perhaps it's something going wrong in one of the CIF calls from the kernel into OB? I seem to recall there's a DEBUG_CIF in libopenbios/client.c that traces these things...
ATB,
Mark.
Mark Cave-Ayland wrote:
Yeah, it did seem to lie within the OpenBIOS symbol range. Perhaps it's something going wrong in one of the CIF calls from the kernel into OB? I seem to recall there's a DEBUG_CIF in libopenbios/client.c that traces these things...
Indeed. And that gives the following:
0 > go Jumping to entry point 00000000010071d8 for type 0000000000000001... switching to new context: entry point 0x10071d8 stack 0x00000000ffe02a91 finddevice("/chosen") = 0xffe1d918 peer(0x00000000) = 0xffe1d280 getproplen(0xffe1d918, "elfheader-address") = 0x00000004 getprop(0xffe1d918, "elfheader-address", 0xffe0328c, 4) = service getprop: argument count error (0 1) 0 getproplen(0xffe1d280, "device_type") = 0xffffffffffffffff child(0xffe1d280) = 0xffe1d458 getproplen(0xffe1d458, "device_type") = 0xffffffffffffffff child(0xffe1d458) = 0x00000000 peer(0xffe1d458) = 0xffe1d580 getproplen(0xffe1d580, "device_type") = 0x00000008 getproplen(0xffe1d580, "device_type") = 0x00000008 getprop(0xffe1d580, "device_type", 0xffe02ce0, 8) = service getprop: argument count error (0 1) 8 0xffe02ce0 42 6f 6f 74 52 4f 4d 00 __ __ __ __ __ __ __ __ BootROM. child(0xffe1d580) = 0xffe26c00 getproplen(0xffe26c00, "device_type") = 0xffffffffffffffff child(0xffe26c00) = 0x00000000 peer(0xffe26c00) = 0x00000000 peer(0xffe1d580) = 0xffe1d838 getproplen(0xffe1d838, "device_type") = 0xffffffffffffffff child(0xffe1d838) = 0x00000000 peer(0xffe1d838) = 0xffe1d918 getproplen(0xffe1d918, "device_type") = 0xffffffffffffffff child(0xffe1d918) = 0x00000000 peer(0xffe1d918) = 0xffe1dab8 getproplen(0xffe1dab8, "device_type") = 0xffffffffffffffff child(0xffe1dab8) = 0xffe1dbe0 getproplen(0xffe1dbe0, "device_type") = 0xffffffffffffffff child(0xffe1dbe0) = 0x00000000 peer(0xffe1dbe0) = 0x00000000 peer(0xffe1dab8) = 0xffe266c8 getproplen(0xffe266c8, "device_type") = 0xffffffffffffffff child(0xffe266c8) = 0xffe28498 getproplen(0xffe28498, "device_type") = 0xffffffffffffffff child(0xffe28498) = 0x00000000 peer(0xffe28498) = 0xffe286e8 getproplen(0xffe286e8, "device_type") = 0xffffffffffffffff child(0xffe286e8) = 0x00000000 peer(0xffe286e8) = 0xffe29de8 getproplen(0xffe29de8, "device_type") = 0xffffffffffffffff child(0xffe29de8) = 0x00000000 peer(0xffe29de8) = 0xffe2a440 getproplen(0xffe2a440, "device_type") = 0xffffffffffffffff child(0xffe2a440) = 0x00000000 peer(0xffe2a440) = 0xffe2aa68 getproplen(0xffe2aa68, "device_type") = 0xffffffffffffffff child(0xffe2aa68) = 0x00000000 peer(0xffe2aa68) = 0xffe2ad28 getproplen(0xffe2ad28, "device_type") = 0xffffffffffffffff child(0xffe2ad28) = 0x00000000 peer(0xffe2ad28) = 0xffe31268 getproplen(0xffe31268, "device_type") = 0xffffffffffffffff child(0xffe31268) = 0x00000000 peer(0xffe31268) = 0xffe3a050 getproplen(0xffe3a050, "device_type") = 0xffffffffffffffff child(0xffe3a050) = 0x00000000 peer(0xffe3a050) = 0x00000000 peer(0xffe266c8) = 0xffe290a0 getproplen(0xffe290a0, "device_type") = 0x00000007 getproplen(0xffe290a0, "device_type") = 0x00000007 getprop(0xffe290a0, "device_type", 0xffe02ce0, 7) = service getprop: argument count error (0 1) 7 0xffe02ce0 6d 65 6d 6f 72 79 00 __ __ __ __ __ __ __ __ __ memory. child(0xffe290a0) = 0x00000000 peer(0xffe290a0) = 0xffe29200 getproplen(0xffe29200, "device_type") = 0xffffffffffffffff child(0xffe29200) = 0x00000000 peer(0xffe29200) = 0xffe2ae88 getproplen(0xffe2ae88, "device_type") = 0x00000004 getproplen(0xffe2ae88, "device_type") = 0x00000004 getprop(0xffe2ae88, "device_type", 0xffe02ce0, 4) = service getprop: argument count error (0 1) 4 0xffe02ce0 70 63 69 00 __ __ __ __ __ __ __ __ __ __ __ __ pci. child(0xffe2ae88) = 0xffe2b728 getproplen(0xffe2b728, "device_type") = 0x00000004 getproplen(0xffe2b728, "device_type") = 0x00000004 getprop(0xffe2b728, "device_type", 0xffe02ce0, 4) = service getprop: argument count error (0 1) 4 0xffe02ce0 70 63 69 00 __ __ __ __ __ __ __ __ __ __ __ __ pci. child(0xffe2b728) = 0xffe2bdd0 getproplen(0xffe2bdd0, "device_type") = 0x00000004 getproplen(0xffe2bdd0, "device_type") = 0x00000004 getprop(0xffe2bdd0, "device_type", 0xffe02ce0, 4) = service getprop: argument count error (0 1) 4 0xffe02ce0 70 63 69 00 __ __ __ __ __ __ __ __ __ __ __ __ pci. child(0xffe2bdd0) = 0xffe2c450 getproplen(0xffe2c450, "device_type") = 0x00000008 getproplen(0xffe2c450, "device_type") = 0x00000008 getprop(0xffe2c450, "device_type", 0xffe02ce0, 8) = service getprop: argument count error (0 1) 8 0xffe02ce0 64 69 73 70 6c 61 79 00 __ __ __ __ __ __ __ __ display. child(0xffe2c450) = 0x00000000 peer(0xffe2c450) = 0xffe2cc08 getproplen(0xffe2cc08, "device_type") = 0xffffffffffffffff child(0xffe2cc08) = 0xffe2d250 getproplen(0xffe2d250, "device_type") = 0x00000006 getproplen(0xffe2d250, "device_type") = 0x00000006 getprop(0xffe2d250, "device_type", 0xffe02ce0, 6) = service getprop: argument count error (0 1) 6 0xffe02ce0 62 6c 6f 63 6b 00 __ __ __ __ __ __ __ __ __ __ block. child(0xffe2d250) = 0x00000000 peer(0xffe2d250) = 0xffe2d750 getproplen(0xffe2d750, "device_type") = 0x00000007 getproplen(0xffe2d750, "device_type") = 0x00000007 getprop(0xffe2d750, "device_type", 0xffe02ce0, 7) = service getprop: argument count error (0 1) 7 0xffe02ce0 73 65 72 69 61 6c 00 __ __ __ __ __ __ __ __ __ serial. child(0xffe2d750) = 0x00000000 peer(0xffe2d750) = 0xffe2da50 getproplen(0xffe2da50, "device_type") = 0x00000007 getproplen(0xffe2da50, "device_type") = 0x00000007 getprop(0xffe2da50, "device_type", 0xffe02ce0, 7) = service getprop: argument count error (0 1) 7 0xffe02ce0 73 65 72 69 61 6c 00 __ __ __ __ __ __ __ __ __ serial. child(0xffe2da50) = 0x00000000 peer(0xffe2da50) = 0x00000000 peer(0xffe2cc08) = 0xffe2dd80 getproplen(0xffe2dd80, "device_type") = 0x00000008 getproplen(0xffe2dd80, "device_type") = 0x00000008 getprop(0xffe2dd80, "device_type", 0xffe02ce0, 8) = service getprop: argument count error (0 1) 8 0xffe02ce0 6e 65 74 77 6f 72 6b 00 __ __ __ __ __ __ __ __ network. child(0xffe2dd80) = 0x00000000 peer(0xffe2dd80) = 0xffe2e360 getproplen(0xffe2e360, "device_type") = 0x00000008 getproplen(0xffe2e360, "device_type") = 0x00000008 getprop(0xffe2e360, "device_type", 0xffe02ce0, 8) = service getprop: argument count error (0 1) 8 0xffe02ce0 70 63 69 2d 69 64 65 00 __ __ __ __ __ __ __ __ pci-ide. child(0xffe2e360) = 0xffe2e950 getproplen(0xffe2e950, "device_type") = 0x00000004 getproplen(0xffe2e950, "device_type") = 0x00000004 getprop(0xffe2e950, "device_type", 0xffe02ce0, 4) = service getprop: argument count error (0 1) 4 0xffe02ce0 69 64 65 00 __ __ __ __ __ __ __ __ __ __ __ __ ide. child(0xffe2e950) = 0xffe2ec40 getproplen(0xffe2ec40, "device_type") = 0x00000006 getproplen(0xffe2ec40, "device_type") = 0x00000006 getprop(0xffe2ec40, "device_type", 0xffe02ce0, 6) = service getprop: argument count error (0 1) 6 0xffe02ce0 62 6c 6f 63 6b 00 __ __ __ __ __ __ __ __ __ __ block. child(0xffe2ec40) = 0x00000000 peer(0xffe2ec40) = 0x00000000 peer(0xffe2e950) = 0xffe2f290 getproplen(0xffe2f290, "device_type") = 0x00000004 getproplen(0xffe2f290, "device_type") = 0x00000004 getprop(0xffe2f290, "device_type", 0xffe02ce0, 4) = service getprop: argument count error (0 1) 4 0xffe02ce0 69 64 65 00 __ __ __ __ __ __ __ __ __ __ __ __ ide. child(0xffe2f290) = 0xffe2f580 getproplen(0xffe2f580, "device_type") = 0x00000006 getproplen(0xffe2f580, "device_type") = 0x00000006 getprop(0xffe2f580, "device_type", 0xffe02ce0, 6) = service getprop: argument count error (0 1) 6 0xffe02ce0 62 6c 6f 63 6b 00 __ __ __ __ __ __ __ __ __ __ block. child(0xffe2f580) = 0x00000000 peer(0xffe2f580) = 0x00000000 peer(0xffe2f290) = 0x00000000 peer(0xffe2e360) = 0x00000000 peer(0xffe2bdd0) = 0x00000000 peer(0xffe2b728) = 0x00000000 peer(0xffe2ae88) = 0xffe2fbd0 getproplen(0xffe2fbd0, "device_type") = 0x00000004 getproplen(0xffe2fbd0, "device_type") = 0x00000004 getprop(0xffe2fbd0, "device_type", 0xffe02ce0, 4) = service getprop: argument count error (0 1) 4 0xffe02ce0 63 70 75 00 __ __ __ __ __ __ __ __ __ __ __ __ cpu. getproplen(0xffe2fbd0, "name") = 0x00000013 getproplen(0xffe2fbd0, "name") = 0x00000013 getprop(0xffe2fbd0, "name", 0x0181c770, 19) = service getprop: argument count error (0 1) 19 0x0181c770 53 55 4e 57 2c 55 6c 74 72 61 53 50 41 52 43 2d SUNW,UltraSPARC- 0x0181c780 49 49 00 __ __ __ __ __ __ __ __ __ __ __ __ __ II. getproplen(0xffe2fbd0, "compatible") = 0xffffffffffffffff parent(0xffe2fbd0) = 0xffe1d280 getproplen(0xffe1d280, "compatible") = 0x00000006 getproplen(0xffe1d280, "device_type") = 0xffffffffffffffff getproplen(0xffe1d918, "whoami") = 0x00000024 getprop(0xffe1d918, "whoami", 0xffe02d50, 36) = service getprop: argument count error (0 1) 3 0xffe02d50 2f 70 6c __ __ __ __ __ __ __ __ __ __ __ __ __ /pl getproplen(0xffe1d918, "bootfs") = 0x00000004 getprop(0xffe1d918, "bootfs", 0x01812588, 4) = service getprop: argument count error (0 1) 4 0x01812588 ff e4 7d e0 __ __ __ __ __ __ __ __ __ __ __ __ ��}� getproplen(0xffe1d918, "archfs") = 0x00000004 getprop(0xffe1d918, "archfs", 0x0181258c, 4) = service getprop: argument count error (0 1) 4 0x0181258c ff e6 ac b8 __ __ __ __ __ __ __ __ __ __ __ __ �欸 getproplen(0xffe1d918, "impl-arch-name") = 0x00000006 getprop(0xffe1d918, "impl-arch-name", 0xffe027c8, 6) = service getprop: argument count error (0 1) 0 of_client_interface: call-method 10baf58 ffe6acb8 35 1861508 call-method open-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 0 getproplen(0xffe1d918, "mmu") = 0x00000004 getproplen(0xffe1d918, "mmu") = 0x00000004 getprop(0xffe1d918, "mmu", 0x01821fac, 4) = service getprop: argument count error (0 1) 4 0x01821fac ff e4 83 d8 __ __ __ __ __ __ __ __ __ __ __ __ ��.� of_client_interface: call-method 10bb110 ffe483d8 0 2000 4c000000 call-method claim ([5] -- [2]) handle_calls return: 0 4c000000 getproplen(0xffe1d918, "memory") = 0x00000004 getproplen(0xffe1d918, "memory") = 0x00000004 getprop(0xffe1d918, "memory", 0x01821fa8, 4) = service getprop: argument count error (0 1) 4 0x01821fa8 ff e4 8e 58 __ __ __ __ __ __ __ __ __ __ __ __ ��.X of_client_interface: call-method 10bb0a8 ffe48e58 8 2000 call-method claim ([4] -- [3]) handle_calls return: 0 0 5700000 of_client_interface: call-method 10bb108 ffe483d8 ffffffffffffffff 2000 4c000000 0 5700000 call-method map ([7] -- [1]) handle_calls return: 0 of_client_interface: call-method 10bafa8 ffe6acb8 0 call-method cinfo-file ([3] -- [4]) handle_calls return: 0 0 1d2a8 2000 of_client_interface: call-method 10bb110 ffe483d8 0 2000 4c002000 call-method claim ([5] -- [2]) handle_calls return: 0 4c002000 of_client_interface: call-method 10bb0a8 ffe48e58 8 2000 call-method claim ([4] -- [3]) handle_calls return: 0 0 5702000 of_client_interface: call-method 10bb108 ffe483d8 ffffffffffffffff 2000 4c002000 0 5702000 call-method map ([7] -- [1]) handle_calls return: 0 of_client_interface: call-method 10bafb8 ffe6acb8 0 call-method close-file ([3] -- [1]) handle_calls return: 0 of_client_interface: call-method 10baf58 ffe6acb8 26 1865998 call-method open-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 0 of_client_interface: call-method 10bafa8 ffe6acb8 0 call-method cinfo-file ([3] -- [4]) handle_calls return: 0 0 449508 2000 of_client_interface: call-method 10bb110 ffe483d8 0 2000 4c004000 call-method claim ([5] -- [2]) handle_calls return: 0 4c004000 of_client_interface: call-method 10bb0a8 ffe48e58 8 2000 call-method claim ([4] -- [3]) handle_calls return: 0 0 5704000 of_client_interface: call-method 10bb108 ffe483d8 ffffffffffffffff 2000 4c004000 0 5704000 call-method map ([7] -- [1]) handle_calls return: 0 of_client_interface: call-method 10baf78 ffe6acb8 0 0 call-method seek-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 0 getproplen(0xffe1d918, "stdout") = 0x00000004 getproplen(0xffe1d918, "stdout") = 0x00000004 getprop(0xffe1d918, "stdout", 0x01821fa0, 4) = service getprop: argument count error (0 1) 4 0x01821fa0 ff e4 88 b0 __ __ __ __ __ __ __ __ __ __ __ __ ��.� of_client_interface: call-method 10baf88 ffe6acb8 0 2000 4c004000 call-method read-file ([5] -- [2]) handle_calls return: 0 2000 of_client_interface: call-method 10baf78 ffe6acb8 0 448000 call-method seek-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 448000 of_client_interface: call-method 10baf88 ffe6acb8 0 2000 4c004000 call-method read-file ([5] -- [2]) handle_calls return: 0 1508 of_client_interface: call-method 10baf78 ffe6acb8 0 0 call-method seek-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 0 of_client_interface: call-method 10baf88 ffe6acb8 0 2000 4c004000 call-method read-file ([5] -- [2]) handle_calls return: 0 2000 of_client_interface: call-method 10baf78 ffe6acb8 0 2000 call-method seek-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 2000 of_client_interface: call-method 10baf88 ffe6acb8 0 17e000 10c1310 call-method read-file ([5] -- [2]) handle_calls return: 0 17e000 of_client_interface: call-method 10baf78 ffe6acb8 0 180000 call-method seek-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 180000 of_client_interface: call-method 10baf88 ffe6acb8 0 2000 4c004000 call-method read-file ([5] -- [2]) handle_calls return: 0 2000 of_client_interface: call-method 10baf78 ffe6acb8 0 182000 call-method seek-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 182000 of_client_interface: call-method 10baf88 ffe6acb8 0 62000 1241310 call-method read-file ([5] -- [2]) handle_calls return: 0 62000 of_client_interface: call-method 10baf78 ffe6acb8 0 1e4000 call-method seek-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 1e4000 of_client_interface: call-method 10baf88 ffe6acb8 0 2000 4c004000 call-method read-file ([5] -- [2]) handle_calls return: 0 2000 of_client_interface: call-method 10baf78 ffe6acb8 0 1e6000 call-method seek-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 1e6000 of_client_interface: call-method 10baf88 ffe6acb8 0 10000 12a5310 call-method read-file ([5] -- [2]) handle_calls return: 0 10000 of_client_interface: call-method 10baf78 ffe6acb8 0 1f6000 call-method seek-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 1f6000 of_client_interface: call-method 10baf88 ffe6acb8 0 2000 4c004000 call-method read-file ([5] -- [2]) handle_calls return: 0 2000 of_client_interface: call-method 10baf78 ffe6acb8 0 1f8000 call-method seek-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 1f8000 of_client_interface: call-method 10baf88 ffe6acb8 0 e000 1867490 call-method read-file ([5] -- [2]) handle_calls return: 0 e000 of_client_interface: call-method 10baf78 ffe6acb8 0 206000 call-method seek-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 206000 of_client_interface: call-method 10baf88 ffe6acb8 0 2000 4c004000 call-method read-file ([5] -- [2]) handle_calls return: 0 2000 of_client_interface: call-method 10bb110 ffe483d8 0 15c000 4c006000 call-method claim ([5] -- [2]) handle_calls return: 0 4c006000 of_client_interface: call-method 10bb0a8 ffe48e58 8 15c000 call-method claim ([4] -- [3]) handle_calls return: 0 0 6000000 of_client_interface: call-method 10bb108 ffe483d8 ffffffffffffffff 15c000 4c006000 0 6000000 call-method map ([7] -- [1]) handle_calls return: 0 of_client_interface: call-method 10baf78 ffe6acb8 0 29a000 call-method seek-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 29a000 of_client_interface: call-method 10baf88 ffe6acb8 0 2000 4c004000 call-method read-file ([5] -- [2]) handle_calls return: 0 2000 of_client_interface: call-method 10baf78 ffe6acb8 0 29c000 call-method seek-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 29c000 of_client_interface: call-method 10baf88 ffe6acb8 0 158000 4c006e38 call-method read-file ([5] -- [2]) handle_calls return: 0 158000 of_client_interface: call-method 10baf78 ffe6acb8 0 3f4000 call-method seek-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 3f4000 of_client_interface: call-method 10baf88 ffe6acb8 0 2000 4c004000 call-method read-file ([5] -- [2]) handle_calls return: 0 2000 of_client_interface: call-method 10bb110 ffe483d8 0 2000 4c162000 call-method claim ([5] -- [2]) handle_calls return: 0 4c162000 of_client_interface: call-method 10bb0a8 ffe48e58 8 2000 call-method claim ([4] -- [3]) handle_calls return: 0 0 5706000 of_client_interface: call-method 10bb108 ffe483d8 ffffffffffffffff 2000 4c162000 0 5706000 call-method map ([7] -- [1]) handle_calls return: 0 of_client_interface: call-method 10baf78 ffe6acb8 0 3f6000 call-method seek-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 3f6000 of_client_interface: call-method 10baf88 ffe6acb8 0 2000 4c004000 call-method read-file ([5] -- [2]) handle_calls return: 0 2000 of_client_interface: call-method 10bb110 ffe483d8 0 e000 4c164000 call-method claim ([5] -- [2]) handle_calls return: 0 4c164000 of_client_interface: call-method 10bb0a8 ffe48e58 8 e000 call-method claim ([4] -- [3]) handle_calls return: 0 0 5708000 of_client_interface: call-method 10bb108 ffe483d8 ffffffffffffffff e000 4c164000 0 5708000 call-method map ([7] -- [1]) handle_calls return: 0 of_client_interface: call-method 10baf78 ffe6acb8 0 3f8000 call-method seek-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 3f8000 of_client_interface: call-method 10baf88 ffe6acb8 0 a000 4c164838 call-method read-file ([5] -- [2]) handle_calls return: 0 a000 of_client_interface: call-method 10baf78 ffe6acb8 0 402000 call-method seek-file ([4] -- [3]) handle_calls return: 0 ffffffffffffffff 402000 of_client_interface: call-method 10baf88 ffe6acb8 0 2000 4c004000 call-method read-file ([5] -- [2]) handle_calls return: 0 2000 of_client_interface: call-method 10bb110 ffe483d8 0 6a000 4c172000 call-method claim ([5] -- [2]) handle_calls return: 0 4c172000 of_client_interface: call-method 10bb0a8 ffe48e58 8 6a000 call-method claim ([4] -- [3]) handle_calls return: 0 0 5716000 of_client_interface: call-method 10bb108 ffe483d8 ffffffffffffffff 6a000 4c172000 0 5716000 call-method map ([7] -- [1]) Unhandled Exception 0x582c01ed41000000 PC = 0x00000000ffd0e94c NPC = 0x00000000ffd0e950 Stopping execution
So looks like its possibly related to the MMU? What I do find interesting aswell is that the getprop CIF calls seem to throw argument count errors too...
ATB,
Mark.
Mark Cave-Ayland wrote:
So looks like its possibly related to the MMU? What I do find interesting aswell is that the getprop CIF calls seem to throw argument count errors too...
On closer inspection, the key turned out to be the argument count errors. It seems that the client interface code for returning arguments back to the caller was broken (off by one error) :(
I believe I've fixed this in r732 and now get this:
0 > go Jumping to entry point 00000000010071d8 for type 0000000000000001... switching to new context: entry point 0x10071d8 stack 0x00000000ffe02a91 krtld: load_exec: fail to expand cpu/$CPU krtld: error during initial load/link phase
krtld could neither locate nor resolve symbols for: /platform/sun4u/kernel/sparcv9/unix in the boot archive. Please verify that this file matches what is found in the boot archive. You may need to boot using the Solaris failsafe to fix this. panic - kernel: Unable to boot EXIT 0 >
Which is an improvement ;) Incidentally, it may be worth someone trying a Linux boot again to see if my last CIF fix enables things to get a bit further there too.
ATB,
Mark.
On 4/3/10, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Mark Cave-Ayland wrote:
So looks like its possibly related to the MMU? What I do find interesting
aswell is that the getprop CIF calls seem to throw argument count errors too...
On closer inspection, the key turned out to be the argument count errors. It seems that the client interface code for returning arguments back to the caller was broken (off by one error) :(
I believe I've fixed this in r732 and now get this:
0 > go Jumping to entry point 00000000010071d8 for type 0000000000000001... switching to new context: entry point 0x10071d8 stack 0x00000000ffe02a91 krtld: load_exec: fail to expand cpu/$CPU krtld: error during initial load/link phase
krtld could neither locate nor resolve symbols for: /platform/sun4u/kernel/sparcv9/unix in the boot archive. Please verify that this file matches what is found in the boot archive. You may need to boot using the Solaris failsafe to fix this. panic - kernel: Unable to boot EXIT 0 >
Which is an improvement ;) Incidentally, it may be worth someone trying a Linux boot again to see if my last CIF fix enables things to get a bit further there too.
Unfortunately some Linux images break, for example like this: OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 kernel addr 404000 size 404d61 kernel cmdline root=/dev/ram -p console=prom init=/sbin/init of_debug=3 ofpci_debug=1 CPUs: 1 x SUNW,UltraSPARC-II UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 2 2010 14:10 Type 'help' for detailed information
[sparc64] Kernel already loaded Unhandled Exception 0x0000000000000010 PC = 0x0000000000404380 NPC = 0x0000000000404384 Stopping execution
With r731 I get:
OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 kernel addr 404000 size 404d61 kernel cmdline root=/dev/ram -p console=prom init=/sbin/init of_debug=3 ofpci_debug=1 CPUs: 1 x SUNW,UltraSPARC-II UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 2 2010 14:10 Type 'help' for detailed information
[sparc64] Kernel already loaded
PROMLIB: Sun IEEE Boot Prom 'OBP 3.10.24 1999/01/01 01:01' PROMLIB: Root node compatible: sun4u Linux version 2.6.32 (test@host) (gcc version 4.2.4) #20 SMP Wed Jan 27 21:44:29 UTC 2010 bootconsole [earlyprom0] enabled ARCH: SUN4U Ethernet address: 52:54:00:12:34:56 Kernel: Using 2 locked TLB entries for main kernel image. Remapping the kernel... done. OF stdout device is: /pci@1fe,0/pci@1/pci@1,1/ebus@3/su@1fe PROM: Built device tree with 32987 bytes of memory. Top of RAM: 0x7e80000, Total RAM: 0x7e80000 Memory hole size: 0MB Zone PFN ranges: Normal 0x00000000 -> 0x00003f40 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x00000000 -> 0x00003f40 Booting Linux... PERCPU: Embedded 5 pages/cpu @fffff80001400000 s16000 r0 d24960 u4194304 pcpu-alloc: s16000 r0 d24960 u4194304 alloc=1*4194304 pcpu-alloc: [0] 0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16065 Kernel command line: root=/dev/ram -p console=prom init=/sbin/init of_debug=3 ofpci_debug=1 PID hash table entries: 512 (order: -1, 4096 bytes) Dentry cache hash table entries: 16384 (order: 4, 131072 bytes) Inode-cache hash table entries: 8192 (order: 3, 65536 bytes) Memory: 116272k available (2656k kernel code, 784k data, 216k init) [fffff80000000000,0000000007e80000] SLUB: Genslabs=14, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation. NR_IRQS:255 clocksource: mult[a0000] shift[16] clockevent: mult[19999999] shift[32] Console: colour dummy device 80x25 Calibrating delay using timer specific routine.. 247.67 BogoMIPS (lpj=495348) Mount-cache hash table entries: 512 Brought up 1 CPUs NET: Registered protocol family 16 /memory reg[0] -> 0 /pci reg[0] -> 1fe00000000 /pci reg[1] -> 1fe01000000 /pci: direct translate 7f0 --> 1 /pci: direct translate 7ee --> 1 /pci: direct translate 7ef --> 1 /pci: direct translate 7e5 --> 1 /pci/pci@1/pci@1,1/QEMU,VGA@2 reg[0] -> 1ff00800000 /pci/pci@1/pci@1,1/ebus@3 reg[0] -> 1ff01000000 /pci/pci@1/pci@1,1/ebus@3 reg[1] -> 1ff02000000 /pci/pci@1/pci@1,1/NE2000@4 reg[0] -> 1fe02000400 /pci/pci@1/pci@1,1/NE2000@4: PCI swizzle [/pci/pci@1/pci@1,1] 1 --> 1 /pci/pci@1/pci@1,1/NE2000@4: PCI swizzle [/pci/pci@1] 1 --> 2 /pci/pci@1/pci@1,1/NE2000@4: PCI swizzle [/pci] 2 --> fffffffd /pci/pci@1/pci@1,1/NE2000@4: Apply IRQ trans [/pci] 1 --> 1 /pci/pci@1/pci@1,1/pci-ata@5 reg[0] -> 1fe02000500 /pci/pci@1/pci@1,1/pci-ata@5 reg[1] -> 1fe02000580 /pci/pci@1/pci@1,1/pci-ata@5 reg[2] -> 1fe02000600 /pci/pci@1/pci@1,1/pci-ata@5 reg[3] -> 1fe02000680 /pci/pci@1/pci@1,1/pci-ata@5 reg[4] -> 1fe02000700 /pci/pci@1/pci@1,1/pci-ata@5: PCI swizzle [/pci/pci@1/pci@1,1] 1 --> 2 /pci/pci@1/pci@1,1/pci-ata@5: PCI swizzle [/pci/pci@1] 2 --> 3 /pci/pci@1/pci@1,1/pci-ata@5: PCI swizzle [/pci] 3 --> fffffffe /pci/pci@1/pci@1,1/pci-ata@5: Apply IRQ trans [/pci] 1 --> 1 /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500 reg[0] -> 50000000000 /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500 reg[1] -> 582 /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500: PCI swizzle [/pci/pci@1/pci@1,1] 0 --> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500: PCI swizzle [/pci/pci@1] 0 --> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500: PCI swizzle [/pci] 0 --> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500: Apply IRQ trans [/pci] 0 --> 2 /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500: PCI swizzle [/pci/pci@1/pci@1,1] e --> e /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500: PCI swizzle [/pci/pci@1] e --> e /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500: PCI swizzle [/pci] e --> e /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500: Apply IRQ trans [/pci] e --> 3 /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500: PCI swizzle [/pci/pci@1/pci@1,1] 0 --> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500: PCI swizzle [/pci/pci@1] 0 --> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500: PCI swizzle [/pci] 0 --> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500: Apply IRQ trans [/pci] 0 --> 2 /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500: PCI swizzle [/pci/pci@1/pci@1,1] 0 --> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500: PCI swizzle [/pci/pci@1] 0 --> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500: PCI swizzle [/pci] 0 --> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500: Apply IRQ trans [/pci] 0 --> 2 /pci/pci@1/pci@1,1/pci-ata@5/ide0@0,500/disk@0,0 reg[0] -> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600 reg[0] -> 60000000000 /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600 reg[1] -> 682 /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600: PCI swizzle [/pci/pci@1/pci@1,1] 0 --> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600: PCI swizzle [/pci/pci@1] 0 --> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600: PCI swizzle [/pci] 0 --> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600: Apply IRQ trans [/pci] 0 --> 2 /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600: PCI swizzle [/pci/pci@1/pci@1,1] e --> e /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600: PCI swizzle [/pci/pci@1] e --> e /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600: PCI swizzle [/pci] e --> e /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600: Apply IRQ trans [/pci] e --> 3 /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600: PCI swizzle [/pci/pci@1/pci@1,1] 0 --> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600: PCI swizzle [/pci/pci@1] 0 --> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600: PCI swizzle [/pci] 0 --> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600: Apply IRQ trans [/pci] 0 --> 2 /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600: PCI swizzle [/pci/pci@1/pci@1,1] 0 --> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600: PCI swizzle [/pci/pci@1] 0 --> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600: PCI swizzle [/pci] 0 --> 0 /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600: Apply IRQ trans [/pci] 0 --> 2 /pci/pci@1/pci@1,1/pci-ata@5/ide1@0,600/cdrom@0,0 reg[0] -> 0 /pci: PCI IO[1fe02000000] MEM[1ff00000000] /pci: SABRE PCI Bus Module ver[0:0] PCI: Scanning PBM /pci PCI: scan_bus[/pci] bus no 0 * /pci/pci@1 create device, devfn: 8, type: pci class: 0x60400 device name: 0000:00:01.0 adding to system ... PCI: dev header type: 1 of_scan_pci_bridge(/pci/pci@1) bus name: PCI Bus 0000:00 PCI: scan_bus[/pci/pci@1] bus no 0 * /pci/pci@1/pci@1,1 create device, devfn: 9, type: pci class: 0x60400 device name: 0000:00:01.1 adding to system ... PCI: dev header type: 1 of_scan_pci_bridge(/pci/pci@1/pci@1,1) bus name: PCI Bus 0000:00 PCI: scan_bus[/pci/pci@1/pci@1,1] bus no 0 * /pci/pci@1/pci@1,1/QEMU,VGA@2 create device, devfn: 10, type: display class: 0x30000 device name: 0000:00:02.0 parse addresses (20 bytes) @ fffff80007e75ac0 start: 1ff00800000, end: 1ff00ffffff, i: 10 adding to system ... PCI: dev header type: 0 * /pci/pci@1/pci@1,1/ebus@3 create device, devfn: 18, type: class: 0x68000 device name: 0000:00:03.0 parse addresses (40 bytes) @ fffff80007e74640 start: 1ff01000000, end: 1ff01ffffff, i: 10 start: 1ff02000000, end: 1ff027fffff, i: 14 adding to system ... PCI: dev header type: 0 * /pci/pci@1/pci@1,1/NE2000@4 create device, devfn: 20, type: network class: 0x20000 device name: 0000:00:04.0 parse addresses (20 bytes) @ fffff80007e728c0 start: 1fe02000400, end: 1fe020004ff, i: 10 adding to system ... PCI: dev header type: 0 * /pci/pci@1/pci@1,1/pci-ata@5 create device, devfn: 28, type: pci-ide class: 0x1018f device name: 0000:00:05.0 parse addresses (100 bytes) @ fffff80007e71780 start: 1fe02000500, end: 1fe02000507, i: 10 start: 1fe02000580, end: 1fe02000583, i: 14 start: 1fe02000600, end: 1fe02000607, i: 18 start: 1fe02000680, end: 1fe02000683, i: 1c start: 1fe02000700, end: 1fe0200070f, i: 20 adding to system ... PCI: dev header type: 0 ------------[ cut here ]------------ WARNING: at /src/linux.git/fs/sysfs/dir.c:491 sysfs_add_one+0x8c/0xc0() sysfs: cannot create duplicate filename '/class/pci_bus/0000:00' Call Trace: [000000000045cd68] warn_slowpath_fmt+0x28/0x40 [0000000000507bac] sysfs_add_one+0x8c/0xc0 [0000000000508dbc] sysfs_do_create_link+0x9c/0x160 [00000000005c3648] device_add+0x3c8/0x500 [0000000000578494] pci_bus_add_child+0x14/0x80 [00000000005786a4] pci_bus_add_devices+0x144/0x200 [000000000057864c] pci_bus_add_devices+0xec/0x200 [000000000069000c] pci_scan_one_pbm+0x6c/0xa0 [0000000000690850] sabre_probe+0x2d0/0x5a0 [000000000060e61c] of_platform_device_probe+0x3c/0x80 [00000000005c60d0] driver_probe_device+0x70/0x160 [00000000005c6238] __driver_attach+0x78/0xa0 [00000000005c558c] bus_for_each_dev+0x4c/0x80 [00000000005c5b9c] bus_add_driver+0x9c/0x240 [00000000005c65f0] driver_register+0x50/0x160 [0000000000426ab8] do_one_initcall+0x18/0x160 ---[ end trace 139ce121c98e96c9 ]--- pci 0000:00:01.1: Error adding bus, continuing ------------[ cut here ]------------ WARNING: at /src/linux.git/fs/sysfs/dir.c:491 sysfs_add_one+0x8c/0xc0() sysfs: cannot create duplicate filename '/class/pci_bus/0000:00' Call Trace: [000000000045cd68] warn_slowpath_fmt+0x28/0x40 [0000000000507bac] sysfs_add_one+0x8c/0xc0 [0000000000508dbc] sysfs_do_create_link+0x9c/0x160 [00000000005c3648] device_add+0x3c8/0x500 [0000000000578494] pci_bus_add_child+0x14/0x80 [00000000005786a4] pci_bus_add_devices+0x144/0x200 [000000000069000c] pci_scan_one_pbm+0x6c/0xa0 [0000000000690850] sabre_probe+0x2d0/0x5a0 [000000000060e61c] of_platform_device_probe+0x3c/0x80 [00000000005c60d0] driver_probe_device+0x70/0x160 [00000000005c6238] __driver_attach+0x78/0xa0 [00000000005c558c] bus_for_each_dev+0x4c/0x80 [00000000005c5b9c] bus_add_driver+0x9c/0x240 [00000000005c65f0] driver_register+0x50/0x160 [0000000000426ab8] do_one_initcall+0x18/0x160 [00000000007683c8] kernel_init+0x1c8/0x240 ---[ end trace 139ce121c98e96ca ]--- pci 0000:00:01.0: Error adding bus, continuing bio: create slab <bio-0> at 0 vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=none,locks=none vgaarb: loaded usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb Switching to clocksource tick CE: tick increasing min_delta_ns to 3000 nsec CE: tick increasing min_delta_ns to 4500 nsec CE: tick increasing min_delta_ns to 6750 nsec CE: tick increasing min_delta_ns to 10124 nsec CE: tick increasing min_delta_ns to 15186 nsec NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 8192 bytes) TCP established hash table entries: 4096 (order: 3, 65536 bytes) TCP bind hash table entries: 4096 (order: 3, 65536 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered NET: Registered protocol family 1 Unpacking initramfs... Freeing initrd memory: 392k freed io scheduler noop registered (default) ------------[ cut here ]------------ WARNING: at /src/linux.git/fs/proc/generic.c:590 proc_register+0x108/0x200() proc_dir_entry 'pci/0000:00' already registered Call Trace: [000000000045cd68] warn_slowpath_fmt+0x28/0x40 [0000000000500568] proc_register+0x108/0x200 [0000000000500870] proc_mkdir_mode+0x30/0x60 [0000000000581514] pci_proc_attach_device+0xb4/0xe0 [000000000077d65c] pci_proc_init+0x5c/0xa0 [0000000000426ab8] do_one_initcall+0x18/0x160 [00000000007683c8] kernel_init+0x1c8/0x240 [000000000042b3b0] kernel_thread+0x30/0x60 [000000000068d0b8] rest_init+0x18/0x80 ---[ end trace 139ce121c98e96cb ]--- ------------[ cut here ]------------ WARNING: at /src/linux.git/fs/proc/generic.c:590 proc_register+0x108/0x200() proc_dir_entry 'pci/0000:00' already registered Call Trace: [000000000045cd68] warn_slowpath_fmt+0x28/0x40 [0000000000500568] proc_register+0x108/0x200 [0000000000500870] proc_mkdir_mode+0x30/0x60 [0000000000581514] pci_proc_attach_device+0xb4/0xe0 [000000000077d65c] pci_proc_init+0x5c/0xa0 [0000000000426ab8] do_one_initcall+0x18/0x160 [00000000007683c8] kernel_init+0x1c8/0x240 [000000000042b3b0] kernel_thread+0x30/0x60 [000000000068d0b8] rest_init+0x18/0x80 ---[ end trace 139ce121c98e96cc ]--- su: probe of ffe2d750 failed with error -12 loop: module loaded nbd: registered device at major 43 Uniform Multi-Platform E-IDE driver cmd64x 0000:00:05.0: IDE controller (0x1095:0x0646 rev 0x07) cmd64x 0000:00:05.0: 100% native mode on irq 1 ide0: BM-DMA at 0x1fe02000700-0x1fe02000707 ide1: BM-DMA at 0x1fe02000708-0x1fe0200070f hda: QEMU HARDDISK, ATA DISK drive hda: UDMA/33 mode selected hdc: QEMU DVD-ROM, ATAPI CD/DVD-ROM drive hdc: UDMA/33 mode selected ide0 at 0x1fe02000500-0x1fe02000507,0x1fe02000582 on irq 1 (serialized) ide1 at 0x1fe02000600-0x1fe02000607,0x1fe02000682 on irq 1 (serialized) ide-gd driver 1.18 hda: max request size: 512KiB hda: 20971520 sectors (10737 MB) w/256KiB Cache, CHS=16383/255/63 hda: lost interrupt hda: lost interrupt
Blue Swirl wrote:
Unfortunately some Linux images break, for example like this: OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 kernel addr 404000 size 404d61 kernel cmdline root=/dev/ram -p console=prom init=/sbin/init of_debug=3 ofpci_debug=1 CPUs: 1 x SUNW,UltraSPARC-II UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 2 2010 14:10 Type 'help' for detailed information
[sparc64] Kernel already loaded Unhandled Exception 0x0000000000000010 PC = 0x0000000000404380 NPC = 0x0000000000404384 Stopping execution
Hmmmm that's strange. Perhaps since the CIF argument array is passed in by the client then we do need to respect pb->nrets since the client has allocated the appropriate memory? What happens if you simply add the missing "0" from r732 in forth/system/ciface.fs to r731 and leave libopenbios/client.c as it was?
ATB,
Mark.
On 4/3/10, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Blue Swirl wrote:
Unfortunately some Linux images break, for example like this: OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 kernel addr 404000 size 404d61 kernel cmdline root=/dev/ram -p console=prom init=/sbin/init of_debug=3 ofpci_debug=1 CPUs: 1 x SUNW,UltraSPARC-II UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 2 2010 14:10 Type 'help' for detailed information
[sparc64] Kernel already loaded Unhandled Exception 0x0000000000000010 PC = 0x0000000000404380 NPC = 0x0000000000404384 Stopping execution
Hmmmm that's strange. Perhaps since the CIF argument array is passed in by the client then we do need to respect pb->nrets since the client has allocated the appropriate memory? What happens if you simply add the missing "0" from r732 in forth/system/ciface.fs to r731 and leave libopenbios/client.c as it was?
I took the other approach and this seems to work:
diff --git a/forth/system/ciface.fs b/forth/system/ciface.fs index aada422..b2035bc 100644 --- a/forth/system/ciface.fs +++ b/forth/system/ciface.fs @@ -341,5 +341,4 @@ device-end : client-call-iface ( [args] name len -- [args] -1 | [rets] 0 ) ciface-ph find-method 0= if -1 exit then execute - 0 ;
Blue Swirl wrote:
Hmmmm that's strange. Perhaps since the CIF argument array is passed in by the client then we do need to respect pb->nrets since the client has allocated the appropriate memory? What happens if you simply add the missing "0" from r732 in forth/system/ciface.fs to r731 and leave libopenbios/client.c as it was?
I took the other approach and this seems to work:
diff --git a/forth/system/ciface.fs b/forth/system/ciface.fs index aada422..b2035bc 100644 --- a/forth/system/ciface.fs +++ b/forth/system/ciface.fs @@ -341,5 +341,4 @@ device-end : client-call-iface ( [args] name len -- [args] -1 | [rets] 0 ) ciface-ph find-method 0= if -1 exit then execute
- 0
;
AFAICT that really should not work because line 297 in libopenbios/client.c will drop the top-most stack argument for any successful call.
I wonder if it's calling the special code for "call-method" and "interpret" instead? Are you able to send me a DEBUG_CIF output for your Linux kernel boot against r732 or point me towards how you are booting the kernel so I can try myself?
Many thanks,
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
Mark Cave-Ayland wrote:
I wonder if it's calling the special code for "call-method" and "interpret" instead? Are you able to send me a DEBUG_CIF output for your Linux kernel boot against r732 or point me towards how you are booting the kernel so I can try myself?
Okay, I've been experimenting with the Debian Lenny SPARC netinst ISO at the same time and have found that what I suspected was the case. I've committed a fix at r733 which now gets the Milax boot further than the previous error (good), but now segfaults again (bad) :(
Interestingly enough, the Debian ISO now does a lot better. Partway through I get a lot of junk on the console, however if you leave it long enough then you get as far as this, although sometimes I get kernel panics before this point (I wonder if some MMU/CPU emulation is broken somewhere?)
[ 22.433828] Console: switching to mono PROM 128x96 [ 33.617482] [drm] Initialized drm 1.1.0 20060810 [ 33.674609] su: probe of ffe2d758 failed with error -12 [ 33.766561] brd: module loaded [ 33.821616] loop: module loaded [ 33.863748] Uniform Multi-Platform E-IDE driver [ 33.916168] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx [ 34.003501] mice: PS/2 mouse device common for all mice [ 34.067544] usbcore: registered new interface driver usbhid [ 34.128004] usbhid: v2.6:USB HID core driver [ 34.187412] TCP cubic registered [ 34.229665] NET: Registered protocol family 17 [ 34.284422] registered taskstats version 1 [ 34.335301] drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [ 34.405875] RAMDISK: Compressed image found at block 0 [ 38.876574] List of all partitions: [ 38.921149] No filesystem could mount root, tried: ext2 [ 38.995468] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 39.076635] Press Stop-A (L1-A) to return to the boot prom
Blue - can you confirm at your end?
ATB,
Mark.
On 4/3/10, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Mark Cave-Ayland wrote:
I wonder if it's calling the special code for "call-method" and
"interpret" instead? Are you able to send me a DEBUG_CIF output for your Linux kernel boot against r732 or point me towards how you are booting the kernel so I can try myself?
Okay, I've been experimenting with the Debian Lenny SPARC netinst ISO at the same time and have found that what I suspected was the case. I've committed a fix at r733 which now gets the Milax boot further than the previous error (good), but now segfaults again (bad) :(
Interestingly enough, the Debian ISO now does a lot better. Partway through I get a lot of junk on the console, however if you leave it long enough then you get as far as this, although sometimes I get kernel panics before this point (I wonder if some MMU/CPU emulation is broken somewhere?)
[ 22.433828] Console: switching to mono PROM 128x96 [ 33.617482] [drm] Initialized drm 1.1.0 20060810 [ 33.674609] su: probe of ffe2d758 failed with error -12 [ 33.766561] brd: module loaded [ 33.821616] loop: module loaded [ 33.863748] Uniform Multi-Platform E-IDE driver [ 33.916168] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx [ 34.003501] mice: PS/2 mouse device common for all mice [ 34.067544] usbcore: registered new interface driver usbhid [ 34.128004] usbhid: v2.6:USB HID core driver [ 34.187412] TCP cubic registered [ 34.229665] NET: Registered protocol family 17 [ 34.284422] registered taskstats version 1 [ 34.335301] drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [ 34.405875] RAMDISK: Compressed image found at block 0 [ 38.876574] List of all partitions: [ 38.921149] No filesystem could mount root, tried: ext2 [ 38.995468] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 39.076635] Press Stop-A (L1-A) to return to the boot prom
Blue - can you confirm at your end?
My test are again like with r731, but Milax does not get as far as with r732.
The tests which had problems in r733 were Ubuntu 20080110.1, Aurora 2.0 and 2.1 install CDs.
Blue Swirl wrote:
My test are again like with r731, but Milax does not get as far as with r732.
Really? I know Milax segfaults with r733 but it's definitely getting a lot further if you enable DEBUG_CIF - it looks like it's trying to read files from the UFS filesystem before it finally dies.
The tests which had problems in r733 were Ubuntu 20080110.1, Aurora 2.0 and 2.1 install CDs.
I think we're definitely chasing an emulation/IO bug here. For example, trying to boot MarTux (Natamar_0.4__b96_sparc_cdrom.iso) with current OpenBIOS SVN gives the following:
OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 kernel cmdline CPUs: 1 x SUNW,UltraSPARC-II UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 5 2010 10:06 Type 'help' for detailed information
[sparc64] Booting file 'disk' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Loading FCode image... Loaded 7392 bytes entry point is 0x4000
Jumping to entry point 0000000000004000 for type 0000000000000010... Evaluating FCode... Unhandled Exception 0x0000000000000032 PC = 0x00000000ffd1bf10 NPC = 0x00000000ffd1bf14 Stopping execution
Checking openbios-builtin.syms shows that the exception is happening in drivers/ide.c:ob_ide_insw. Adding a debugging printk confirms this:
(lots cut) port: 500 addr: 00000000ffec66c0 count: 100 port: 500 addr: 0000000008002000 count: 100 port: 500 addr: 0000000008002200 count: 100 port: 500 addr: 0000000008002400 count: 100 port: 500 addr: 0000000008002600 count: 100 port: 500 addr: 0000000051000000 count: 100 Unhandled Exception 0x0000000000000032 PC = 0x00000000ffd1df74 NPC = 0x00000000ffd1df78 Stopping execution
Note that 0x51000000 is the address where the Fcode normally loads the ELF image from disk/CDROM. What is more interesting is that the same call with the same parameters seems to work fine if I leave the printk in place while booting Milax:
(lots cut) port: 500 addr: 00000000ffec66c0 count: 100 port: 500 addr: 0000000008002000 count: 100 port: 500 addr: 0000000008002200 count: 100 port: 500 addr: 0000000008002400 count: 100 port: 500 addr: 0000000008002600 count: 100 port: 500 addr: 0000000051000000 count: 100 port: 500 addr: 0000000051000200 count: 100 port: 500 addr: 0000000051000400 count: 100 port: 500 addr: 0000000051000600 count: 100 port: 500 addr: 0000000051000800 count: 100 port: 500 addr: 0000000051000a00 count: 100 port: 500 addr: 0000000051000c00 count: 100 port: 500 addr: 0000000051000e00 count: 100 port: 500 addr: 0000000051001000 count: 100 (lots cut)
So I'm thinking perhaps that this is some kind of emulation rather than IO bug. The SPARC docs refers to trap 0x32 as a "data_access_error" which is being generated by qemu in response to a certain condition, but I'm not exactly sure what that is yet.
ATB,
Mark.
2010/4/3 Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk:
Mark Cave-Ayland wrote: (I wonder if some MMU/CPU emulation is broken somewhere?)
Actually a very good question. Does qemu emulate any sun4u machine good enough to have a chance running with OBP? It may be a good strategy for fixing the "hardware". At least it was fruitful on sun4m. Blue?
On 4/3/10, Artyom Tarasenko atar4qemu@googlemail.com wrote:
2010/4/3 Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk:
Mark Cave-Ayland wrote: (I wonder if some MMU/CPU emulation is broken somewhere?)
Actually a very good question. Does qemu emulate any sun4u machine good enough to have a chance running with OBP? It may be a good strategy for fixing the "hardware". At least it was fruitful on sun4m. Blue?
One problem with that strategy is that QEMU does not implement any real machines now. Typical Ultra machines had HME NICs, 53C875 SCSI controller but we have random PCI NICs and IDE (CMD646 exists but usually it's only used for CDROM). OSes probably don't care whether the machine matches any real one or not.
One solution would be to implement the first Ultra machines, which were partially SBUS based and had many common devices with Sun4m.
We could also implement some mid-class machine with HME and 53C875 (it may even be similar to lsi53c895a, which we have). PCI bridging does not work well in QEMU. The docs aren't very good I think. This is closest to what we have now. It could be interesting to see what OBP from a real machine would think of the QEMU machine.
Third option would be to aim for T1/T2 class machines. The docs are good and there is even Verilog implementation to compare with because most of the devices are inside the CPU. The devices aren't very simple and there is very little commonality with old HW. There are also CPU features to be implemented (CMT). The boot ROM architecture is interesting, there is a hypervisor which OBP uses. Everything is open source, including the CPU. QEMU's Niagara machine can boot the hypervisor, which will output a few lines before crashing.
The options aren't mutually exclusive, so if we had an infinite number of monkeys we could advance in all three areas simultaneously. There's a lot of playground. :-)
2010/4/3 Blue Swirl blauwirbel@gmail.com:
On 4/3/10, Artyom Tarasenko atar4qemu@googlemail.com wrote:
2010/4/3 Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk:
Mark Cave-Ayland wrote:
> (I wonder if some MMU/CPU emulation is broken somewhere?)
Actually a very good question. Does qemu emulate any sun4u machine good enough to have a chance running with OBP? It may be a good strategy for fixing the "hardware". At least it was fruitful on sun4m. Blue?
One problem with that strategy is that QEMU does not implement any real machines now. Typical Ultra machines had HME NICs, 53C875 SCSI controller but we have random PCI NICs and IDE (CMD646 exists but usually it's only used for CDROM). OSes probably don't care whether the machine matches any real one or not.
One solution would be to implement the first Ultra machines, which were partially SBUS based and had many common devices with Sun4m.
We could also implement some mid-class machine with HME and 53C875 (it may even be similar to lsi53c895a, which we have). PCI bridging does not work well in QEMU. The docs aren't very good I think. This is closest to what we have now. It could be interesting to see what OBP from a real machine would think of the QEMU machine.
How is SBUS connected to the IO-MMU? Directly or through a PCI bridge? Quick google search didn't help me to find it. I only found that in the Russian sparc32 PCI machine (Elbrus-90) SBUS is connected through a PCI-bridge. If that's the case in early Ultras too, OBP probably won't be able to tell us much via the serial port connected to the SBUS.
Third option would be to aim for T1/T2 class machines. The docs are good and there is even Verilog implementation to compare with because most of the devices are inside the CPU. The devices aren't very simple and there is very little commonality with old HW. There are also CPU features to be implemented (CMT). The boot ROM architecture is interesting, there is a hypervisor which OBP uses. Everything is open source, including the CPU. QEMU's Niagara machine can boot the hypervisor, which will output a few lines before crashing.
How about one more. The fourth option (or the second one for the OpenBIOS team) would be using Sun's legion T1/T2 emulator as the hardware for the OpenBIOS. It may be the shortest path to get OpenSolaris booting under OpenBIOS.
The options aren't mutually exclusive, so if we had an infinite number of monkeys we could advance in all three areas simultaneously. There's a lot of playground. :-)
On 2010-4-3 6:24 PM, Artyom Tarasenko wrote:
[...] How is SBUS connected to the IO-MMU? Directly or through a PCI bridge? Quick google search didn't help me to find it. I only found that in the Russian sparc32 PCI machine (Elbrus-90) SBUS is connected through a PCI-bridge. If that's the case in early Ultras too, OBP probably won't be able to tell us much via the serial port connected to the SBUS.
SBUS long pre-dated PCI. The original UltraSPARC machines (Ultra/1, Ultra/2) were SBUS machines, which used a SYSIO bridge instead of PSYCHO. I think the root bus on those machines was UPA (a Sun-proprietary bus). Once Sun's PCI machines came on strong, SBUS pretty much went away.
On 4/4/10, Artyom Tarasenko atar4qemu@googlemail.com wrote:
2010/4/3 Blue Swirl blauwirbel@gmail.com:
On 4/3/10, Artyom Tarasenko atar4qemu@googlemail.com wrote:
2010/4/3 Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk:
Mark Cave-Ayland wrote: (I wonder if some MMU/CPU emulation is broken somewhere?)
Actually a very good question. Does qemu emulate any sun4u machine good enough to have a chance running with OBP? It may be a good strategy for fixing the "hardware". At least it was fruitful on sun4m. Blue?
One problem with that strategy is that QEMU does not implement any real machines now. Typical Ultra machines had HME NICs, 53C875 SCSI controller but we have random PCI NICs and IDE (CMD646 exists but usually it's only used for CDROM). OSes probably don't care whether the machine matches any real one or not.
One solution would be to implement the first Ultra machines, which were partially SBUS based and had many common devices with Sun4m.
We could also implement some mid-class machine with HME and 53C875 (it may even be similar to lsi53c895a, which we have). PCI bridging does not work well in QEMU. The docs aren't very good I think. This is closest to what we have now. It could be interesting to see what OBP from a real machine would think of the QEMU machine.
How is SBUS connected to the IO-MMU? Directly or through a PCI bridge? Quick google search didn't help me to find it. I only found that in the Russian sparc32 PCI machine (Elbrus-90) SBUS is connected through a PCI-bridge. If that's the case in early Ultras too, OBP probably won't be able to tell us much via the serial port connected to the SBUS.
There's SYSIO bridge (U2S, STP2220ABGA-100). I couldn't find the user manual (U2S User Manual, Part Number: 805-0168-01) but arch/sparc64/kernel/sbus.c in Linux has some register information.
Third option would be to aim for T1/T2 class machines. The docs are good and there is even Verilog implementation to compare with because most of the devices are inside the CPU. The devices aren't very simple and there is very little commonality with old HW. There are also CPU features to be implemented (CMT). The boot ROM architecture is interesting, there is a hypervisor which OBP uses. Everything is open source, including the CPU. QEMU's Niagara machine can boot the hypervisor, which will output a few lines before crashing.
How about one more. The fourth option (or the second one for the OpenBIOS team) would be using Sun's legion T1/T2 emulator as the hardware for the OpenBIOS. It may be the shortest path to get OpenSolaris booting under OpenBIOS.
That's also possible. Also OpenBIOS could operate only as the hypervisor and use OBP, or vice versa.
One problem with that strategy is that QEMU does not implement any real machines now. Typical Ultra machines had HME NICs, 53C875 SCSI controller but we have random PCI NICs and IDE (CMD646 exists but usually it's only used for CDROM).
IIRC the 53C875 is virtually identical to the 53C895A emulated by qemu.
Paul
2010/4/3 Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk:
Mark Cave-Ayland wrote:
So looks like its possibly related to the MMU? What I do find interesting aswell is that the getprop CIF calls seem to throw argument count errors too...
On closer inspection, the key turned out to be the argument count errors. It seems that the client interface code for returning arguments back to the caller was broken (off by one error) :(
I believe I've fixed this in r732 and now get this:
0 > go Jumping to entry point 00000000010071d8 for type 0000000000000001... switching to new context: entry point 0x10071d8 stack 0x00000000ffe02a91 krtld: load_exec: fail to expand cpu/$CPU
Looks like the last stage of the kernel loader wasn't able to determine the CPU model? Or at least didn't like it. Maybe the OpenSolaris version you are booting doesn't support the specified (or default) cpu model?
krtld: error during initial load/link phase
krtld could neither locate nor resolve symbols for: /platform/sun4u/kernel/sparcv9/unix in the boot archive. Please verify that this file matches what is found in the boot archive. You may need to boot using the Solaris failsafe to fix this. panic - kernel: Unable to boot EXIT 0 >
And... Solaris 2.5.1 on sparc32 also looks pretty similar with r733:
Jumping to entry point 00004000 for type 00000005... null path krtld: error during initial load/link phase Unhandled Exception 0x00000007 PC = 0x0010724c NPC = 0x00107250 Stopping execution
Unmodified Solaris 2.6 doesn't get this far, I guess due to the 80 chars limitation. Will check the patched version later.
But all in all it looks like the problem is buried in OpenBIOS, since qemu is definitely good enough to boot 2.5.1 under sparc32.
Which is an improvement ;) Incidentally, it may be worth someone trying a Linux boot again to see if my last CIF fix enables things to get a bit further there too.
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
Artyom Tarasenko wrote:
Looks like the last stage of the kernel loader wasn't able to determine the CPU model? Or at least didn't like it. Maybe the OpenSolaris version you are booting doesn't support the specified (or default) cpu model?
krtld: error during initial load/link phase
krtld could neither locate nor resolve symbols for: /platform/sun4u/kernel/sparcv9/unix in the boot archive. Please verify that this file matches what is found in the boot archive. You may need to boot using the Solaris failsafe to fix this. panic - kernel: Unable to boot EXIT 0 >
r733 actually gets further than this now. It seems to die whilst trying to load files from the file system/map virtual memory.
And... Solaris 2.5.1 on sparc32 also looks pretty similar with r733:
Jumping to entry point 00004000 for type 00000005... null path krtld: error during initial load/link phase Unhandled Exception 0x00000007 PC = 0x0010724c NPC = 0x00107250 Stopping execution
Unmodified Solaris 2.6 doesn't get this far, I guess due to the 80 chars limitation. Will check the patched version later.
Hmmmm this looks more promising. If you compile with DEBUG_CIF enabled in libopenbios/client.c and try again then you can see all the calls into OpenBIOS, and hence the device nodes and properties that are being accessed. This will probably tell you why you are getting the null path error. It's interesting to note that type 0x5 is an a.out as opposed to an ELF binary.
But all in all it looks like the problem is buried in OpenBIOS, since qemu is definitely good enough to boot 2.5.1 under sparc32.
Probably. All we need now is the debug information so that we can fix it :)
ATB,
Mark.
Mark Cave-Ayland wrote:
Unmodified Solaris 2.6 doesn't get this far, I guess due to the 80 chars limitation. Will check the patched version later.
Hmmmm this looks more promising. If you compile with DEBUG_CIF enabled in libopenbios/client.c and try again then you can see all the calls into OpenBIOS, and hence the device nodes and properties that are being accessed. This will probably tell you why you are getting the null path error. It's interesting to note that type 0x5 is an a.out as opposed to an ELF binary.
Actually, I was totally wrong. SPARC32 uses the romvec interface, so instead have a look at compiling with CONFIG_DEBUG_OBP set in arch/sparc32/romvec.c to see what the client is trying to do.
HTH,
Mark.
2010/4/5 Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk:
Mark Cave-Ayland wrote:
Unmodified Solaris 2.6 doesn't get this far, I guess due to the 80 chars limitation. Will check the patched version later.
Hmmmm this looks more promising. If you compile with DEBUG_CIF enabled in libopenbios/client.c and try again then you can see all the calls into OpenBIOS, and hence the device nodes and properties that are being accessed. This will probably tell you why you are getting the null path error. It's interesting to note that type 0x5 is an a.out as opposed to an ELF binary.
Actually, I was totally wrong. SPARC32 uses the romvec interface, so instead have a look at compiling with CONFIG_DEBUG_OBP set in arch/sparc32/romvec.c to see what the client is trying to do.
ok, 2.6 confirms that there is a problem with 80 characters limit: ...
obp_devread(fd 0xffd9e740, buf 0xe110, nbytes 8192) = 8192 obp_devseek(fd 0xffd9e740, hi 0, lo 15065088) = 0 obp_devread(fd 0xffd9e740, buf 0xe110, nbytes 8192) = 8192 obp_devclose(0xffd9e740) = 1 obp_fortheval_v2( ['] find-device catch if 2drop true else current-device device-end then swap l!) Unhandled Exception 0x00000007 PC = 0xffd05580 NPC = 0xffd05024 Stopping execution
2.5.1 :
obp_devread(fd 0xffd9eb94, buf 0xf00a0778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275275776) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a2778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275283968) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a4778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275292160) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a6778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275316736) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a8778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275324928) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00aa778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275333120) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00ac778, nbytes 8192) = 8192
And then it just hangs. I don't see the "krtld: error during initial load/link phase" message.
Artyom Tarasenko wrote:
ok, 2.6 confirms that there is a problem with 80 characters limit: ...
obp_devread(fd 0xffd9e740, buf 0xe110, nbytes 8192) = 8192 obp_devseek(fd 0xffd9e740, hi 0, lo 15065088) = 0 obp_devread(fd 0xffd9e740, buf 0xe110, nbytes 8192) = 8192 obp_devclose(0xffd9e740) = 1 obp_fortheval_v2( ['] find-device catch if 2drop true else current-device device-end then swap l!) Unhandled Exception 0x00000007 PC = 0xffd05580 NPC = 0xffd05024 Stopping execution
Definitely time for you to build a cross-gdb :) I notice a comment in obp_fortheval_v2 that reads:
// for now, move something to the stack so we // don't get a stack underrun. // // FIXME: find out why solaris doesnt put its stuff on the stack // fword("0"); fword("0");
So perhaps the OpenBIOS marshalling code for romvec doesn't handle passing Forth stack parameters correctly? Try searching for Sun romvec documentation to see what you can find about how parameters are passed to/from the BIOS.
2.5.1 :
obp_devread(fd 0xffd9eb94, buf 0xf00a0778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275275776) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a2778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275283968) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a4778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275292160) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a6778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275316736) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a8778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275324928) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00aa778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275333120) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00ac778, nbytes 8192) = 8192
And then it just hangs. I don't see the "krtld: error during initial load/link phase" message.
Again, you'll need a cross-gdb to check this. At least you can then break into OpenBIOS and find out at which point you're getting stuck in a loop.
HTH,
Mark.
2010/4/6 Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk:
Artyom Tarasenko wrote:
ok, 2.6 confirms that there is a problem with 80 characters limit: ...
obp_devread(fd 0xffd9e740, buf 0xe110, nbytes 8192) = 8192 obp_devseek(fd 0xffd9e740, hi 0, lo 15065088) = 0 obp_devread(fd 0xffd9e740, buf 0xe110, nbytes 8192) = 8192 obp_devclose(0xffd9e740) = 1 obp_fortheval_v2( ['] find-device catch if 2drop true else current-device device-end then swap l!) Unhandled Exception 0x00000007 PC = 0xffd05580 NPC = 0xffd05024 Stopping execution
Definitely time for you to build a cross-gdb :)
how to see in the gdb how many items are on a forth stack?
I notice a comment in obp_fortheval_v2 that reads:
// for now, move something to the stack so we // don't get a stack underrun. // // FIXME: find out why solaris doesnt put its stuff on the stack // fword("0"); fword("0");
So perhaps the OpenBIOS marshalling code for romvec doesn't handle passing Forth stack parameters correctly? Try searching for Sun romvec documentation to see what you can find about how parameters are passed to/from the BIOS.
Yep, found that too. Actually I was wrong: replacing second space with 0x0a doesn't bring it further. Don't know why it did before. Probably I messed up the binary. So, obp_fortheval_v2 is broken regardless of the line length:
obp_getprop(0xffd72f88, reg) = 00 00 00 05 08 80 00 00 00 00 00 10 obp_fortheval_v2( ['] find-device catch if 2drop true else current-device device-end then swap l!) Unhandled Exception 0x00000007 PC = 0xffd05f44 NPC = 0xffd05f48
2.5.1 :
obp_devread(fd 0xffd9eb94, buf 0xf00a0778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275275776) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a2778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275283968) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a4778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275292160) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a6778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275316736) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a8778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275324928) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00aa778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275333120) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00ac778, nbytes 8192) = 8192
And then it just hangs. I don't see the "krtld: error during initial load/link phase" message.
Again, you'll need a cross-gdb to check this. At least you can then break into OpenBIOS and find out at which point you're getting stuck in a loop.
debugging a program which behaves differently with debugging switched on and off is no fun. I can try though. What would you suggest as a breakpoint? obp_devread is not the best candidate as it's called like a thousand times.
Artyom Tarasenko wrote:
how to see in the gdb how many items are on a forth stack?
See include/kernel/stack.h for the Forth stack operations. rstack and dstack are the return and data arrays stacks respectively, while rstackcnt and dstackcnt point to the topmost stack item. So the current item at the top of the stack is viewable with:
print dstack[dstackcnt]
Also make sure you alter obj-sparc32/Makefile so that CFLAGS uses -O0 rather than -Os - otherwise the optimiser will be quite aggressive and lose debug information.
Yep, found that too. Actually I was wrong: replacing second space with 0x0a doesn't bring it further. Don't know why it did before. Probably I messed up the binary. So, obp_fortheval_v2 is broken regardless of the line length:
Okay. That's useful to know.
obp_getprop(0xffd72f88, reg) = 00 00 00 05 08 80 00 00 00 00 00 10 obp_fortheval_v2( ['] find-device catch if 2drop true else current-device device-end then swap l!) Unhandled Exception 0x00000007 PC = 0xffd05f44 NPC = 0xffd05f48
2.5.1 :
obp_devread(fd 0xffd9eb94, buf 0xf00a0778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275275776) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a2778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275283968) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a4778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275292160) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a6778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275316736) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a8778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275324928) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00aa778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275333120) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00ac778, nbytes 8192) = 8192
And then it just hangs. I don't see the "krtld: error during initial load/link phase" message.
Again, you'll need a cross-gdb to check this. At least you can then break into OpenBIOS and find out at which point you're getting stuck in a loop.
debugging a program which behaves differently with debugging switched on and off is no fun. I can try though. What would you suggest as a breakpoint? obp_devread is not the best candidate as it's called like a thousand times.
If the above trace is accurate I'd probably add something like the following to obp_devread:
if (fd == 0xffd9eb94 && buf == 0xf00ac778 && nbytes == 8192) { printk("Debug here!\n"); }
And then use gdb to place a breakpoint on the specific line above containing the printk statement.
HTH,
Mark.
2010/4/6 Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk:
Artyom Tarasenko wrote:
how to see in the gdb how many items are on a forth stack?
See include/kernel/stack.h for the Forth stack operations. rstack and dstack are the return and data arrays stacks respectively, while rstackcnt and dstackcnt point to the topmost stack item. So the current item at the top of the stack is viewable with:
print dstack[dstackcnt]
Also make sure you alter obj-sparc32/Makefile so that CFLAGS uses -O0 rather than -Os - otherwise the optimiser will be quite aggressive and lose debug information.
Yep, found that too. Actually I was wrong: replacing second space with 0x0a doesn't bring it further. Don't know why it did before. Probably I messed up the binary. So, obp_fortheval_v2 is broken regardless of the line length:
Okay. That's useful to know.
obp_getprop(0xffd72f88, reg) = 00 00 00 05 08 80 00 00 00 00 00 10 obp_fortheval_v2( ['] find-device catch if 2drop true else current-device device-end then swap l!) Unhandled Exception 0x00000007 PC = 0xffd05f44 NPC = 0xffd05f48
2.5.1 :
obp_devread(fd 0xffd9eb94, buf 0xf00a0778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275275776) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a2778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275283968) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a4778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275292160) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a6778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275316736) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00a8778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275324928) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00aa778, nbytes 8192) = 8192 obp_devseek(fd 0xffd9eb94, hi 0, lo 275333120) = 0 obp_devread(fd 0xffd9eb94, buf 0xf00ac778, nbytes 8192) = 8192
And then it just hangs. I don't see the "krtld: error during initial load/link phase" message.
Again, you'll need a cross-gdb to check this. At least you can then break into OpenBIOS and find out at which point you're getting stuck in a loop.
debugging a program which behaves differently with debugging switched on and off is no fun. I can try though. What would you suggest as a breakpoint? obp_devread is not the best candidate as it's called like a thousand times.
If the above trace is accurate I'd probably add something like the following to obp_devread:
if (fd == 0xffd9eb94 && buf == 0xf00ac778 && nbytes == 8192) { printk("Debug here!\n"); }
And then use gdb to place a breakpoint on the specific line above containing the printk statement.
Got me. I spent too much time debugging stuff without the source. :)
qemu+gdb seem to be unstable though: sometimes qemu crash, and here it just hangs:
(gdb) break ../arch/sparc32/romvec.c:324 (gdb) target remote :1234 Remote debugging using :1234 0x00000000 in ?? () (gdb) cont Continuing.
Breakpoint 1, obp_devread (dev_desc=<value optimized out>, buf=0xffd36138 "\377\326,L\377\326*\364\377\325\365@\377\326D\250\377\326Ix\377\331\316\200\377\331\317\024", nbytes=1508192) at ../arch/sparc32/romvec.c:324 324 printk("Debug here!\n"); (gdb) step
<hangs>
stepi and cont do the same. Which gdb version do you use? Mine is 7.1.
Artyom Tarasenko wrote:
Got me. I spent too much time debugging stuff without the source. :)
qemu+gdb seem to be unstable though: sometimes qemu crash, and here it just hangs:
Hmmm it's always been fairly solid for me. If you can get qemu to crash consistently, attach a separate gdb to that and then post the backtrace to the qemu list :)
(gdb) break ../arch/sparc32/romvec.c:324 (gdb) target remote :1234 Remote debugging using :1234 0x00000000 in ?? () (gdb) cont Continuing.
Breakpoint 1, obp_devread (dev_desc=<value optimized out>, buf=0xffd36138 "\377\326,L\377\326*\364\377\325\365@\377\326D\250\377\326Ix\377\331\316\200\377\331\317\024", nbytes=1508192) at ../arch/sparc32/romvec.c:324 324 printk("Debug here!\n"); (gdb) step
<hangs>
stepi and cont do the same. Which gdb version do you use? Mine is 7.1.
Firstly, because you have "dev_desc=<value optimized out>" in the above output it means you didn't compile with -O0 rather than -Os. Hence because of the low level optimisations you won't be able see certain values, or a step may not necessarily correlate to a single line.
Secondly, you may need to try building gdb with "./configure --target=sparc-linux" as the standard sparc-elf-gdb binaries caused me problems with missing register sets (particularly on SPARC64 but YMMV).
And finally, the output of my cross-gdb here is:
build@zeno:~/src/openbios/openbios-devel$ sparc64-linux-gdb -v GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=sparc64-linux"
HTH,
Mark.
2010/4/6 Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk:
Firstly, because you have "dev_desc=<value optimized out>" in the above output it means you didn't compile with -O0 rather than -Os. Hence because of the low level optimisations you won't be able see certain values, or a step may not necessarily correlate to a single line.
it seems that make clean && make is not enough to rebuild. Or -O is redefined somewhere.
Secondly, you may need to try building gdb with "./configure --target=sparc-linux" as the standard sparc-elf-gdb binaries caused me problems with missing register sets (particularly on SPARC64 but YMMV).
Yes, that was the problem. I intended to debug ufsboot, so I compiled gdb with --target=sparc-solaris. With sparc-linux it is working.
Artyom Tarasenko wrote:
it seems that make clean && make is not enough to rebuild. Or -O is redefined somewhere.
Normally I do the following:
rm -rf obj-sparc32 ./config/scripts/switch-arch cross-sparc32 (edit obj-sparc32/Makefile to add -O0 -g) make cp obj-sparc32/openbios-builtin.elf.nostrip path/to/qemu/share/openbios-sparc32
Then fire up qemu with -s -S, connect with "target remote :1234" and set the symbols with "symbol-file openbios-builtin.elf.nostrip". Finally set everything back in motion with "cont".
Secondly, you may need to try building gdb with "./configure --target=sparc-linux" as the standard sparc-elf-gdb binaries caused me problems with missing register sets (particularly on SPARC64 but YMMV).
Yes, that was the problem. I intended to debug ufsboot, so I compiled gdb with --target=sparc-solaris. With sparc-linux it is working.
Excellent :)
HTH,
Mark.
On 4/2/10, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Blue Swirl wrote:
Sorry, I misread that you had loaded the kernel manually.
The crash seems to happen within OpenBIOS.
Yeah, it did seem to lie within the OpenBIOS symbol range. Perhaps it's something going wrong in one of the CIF calls from the kernel into OB? I seem to recall there's a DEBUG_CIF in libopenbios/client.c that traces these things...
No, this is fetch from kernel/forth.c:589. Pretty difficult to use breakpoints directly.
But I put a breakpoint in trap table to get at least the registers: Breakpoint 3, 0x00000000ffd00680 in trap_table () at ../arch/sparc64/vectors.S:123 123 BTRAPS(0x30) BTRAPS(0x38) Current language: auto; currently asm (gdb) info registers g0 0x0 0x0 g1 0x1b3c059d7 0x1b3c059d7 g2 0x1b327c357 0x1b327c357 g3 0x0 0x0 g4 0x0 0x0 g5 0x0 0x0 g6 0x0 0x0 g7 0x0 0x0 o0 0xffe13a08 0xffe13a08 o1 0x20 0x20 o2 0xffee3000 0xffee3000 o3 0x108 0x108 o4 0xffee3c00 0xffee3c00 o5 0x138 0x138 sp 0xffe019f9 0xffe019f9 o7 0xffd0ce70 0xffd0ce70 l0 0x18125a0 0x18125a0 l1 0x1c00 0x1c00 l2 0x10ba168 0x10ba168 l3 0x10ba000 0x10ba000 l4 0x2 0x2 l5 0x5 0x5 l6 0x10ba128 0x10ba128 l7 0x10ba000 0x10ba000 i0 0x1b8 0x1b8 i1 0xffe28280 0xffe28280 i2 0x0 0x0 i3 0x1a 0x1a i4 0xd8 0xd8 i5 0xffee3000 0xffee3000 fp 0xffe01ab9 0xffe01ab9 i7 0xffd0f714 0xffd0f714 pc 0xffd00680 0xffd00680 <trap_table+1664> npc 0xffd00684 0xffd00684 <trap_table+1668> state 0x4400001505 0x4400001505 fsr 0x0 [ ] fprs 0x0 [ ] y 0x0 0x0 cwp 0x5 0x5 pstate 0x15 [ AG PRIV PEF ] asi 0x0 0x0 ccr 0x44 0x44
The offending instruction is: 0x00000000ffd0e920 <fetch+64>: ldx [ %g2 ], %g2
I can't remember offhand if the global registers are from the caller or alternate ones. If they are already from alternate sets, then we have to use additional GDB to debug also QEMU.
On 4/2/10 4:23 PM, Mark Cave-Ayland wrote:
Hi all,
After all the refactoring work, I got around to re-working the init-program and go words and plugging the new unified ELF loader into the SPARC64 build.
And the result? As of SVN r730, I'm pleased to report that the Solaris kernel starts to execute on my Milax test ISO. After typing "go" to execute the loaded ELF image manually, I see a twirly baton rotating on the console for about 0.5s before the inevitable segfault. So it's a small step, but still a great milestone for the OpenBIOS project :D
Great work! Thank you!
Stefan
Hi Mark,
After all the refactoring work, I got around to re-working the init-program and go words and plugging the new unified ELF loader into the SPARC64 build.
And the result? As of SVN r730, I'm pleased to report that the Solaris kernel starts to execute on my Milax test ISO. After typing "go" to execute the loaded ELF image manually, I see a twirly baton rotating on the console for about 0.5s before the inevitable segfault. So it's a small step, but still a great milestone for the OpenBIOS project :D
Wow! Hats off! Congratulations!
Hi all,
After all the refactoring work, I got around to re-working the init-program and go words and plugging the new unified ELF loader into the SPARC64 build.
And the result? As of SVN r730, I'm pleased to report that the Solaris kernel starts to execute on my Milax test ISO. After typing "go" to execute the loaded ELF image manually, I see a twirly baton rotating on the console for about 0.5s before the inevitable segfault. So it's a small step, but still a great milestone for the OpenBIOS project :D
Happy holidays,
Mark.
Awesome, Mark - this is great news! Thanks for all the work put into this!
-Nick
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
-
Artyom Tarasenko -
Blue Swirl -
Mark Cave-Ayland -
Nick Couchman -
Paul Brook -
Stefan Reinauer -
Tarl Neustaedter