Ok, here's what I'm getting now: C>> annot manage 'VGA controller' PCI device type 'display':
10de 141 (3 0 0)
============================================================= OpenBIOS 1.1 [Dec 17 2017 13:36] Configuration device id QEMU version 1 machine id 2 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,750
milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on Dec 17 2017 13:36
0 > load hd:,\ppc\6600.fcode ok 0 > 4000000 400 dump 4000000 55 aa 40 00 00 00 00 00 00 00 00 00 00 00 00 00 U�@............. 4000010 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ........ ....... 4000020 50 43 49 52 de 10 41 01 00 00 20 00 00 00 00 03 PCIR�.A... ..... 4000030 84 00 00 00 01 80 00 00 00 00 00 00 00 00 00 00 �....�.......... 4000040 f1 08 17 0f 00 01 06 55 12 2a 00 00 00 00 00 00 �......U.*...... 4000050 00 00 00 00 de 10 50 00 3e 00 21 00 81 90 40 a3 ....�.P.>.!.��@� 4000060 00 00 00 00 90 04 00 80 00 00 a5 f4 00 00 00 00 ....�..�..��.... 4000070 00 00 00 00 52 a5 b5 08 00 ba a5 10 00 00 00 08 ....R��..��..... 4000080 b5 08 01 be a7 b5 08 02 be a7 b5 08 03 be 10 00 �..���..���..�.. 4000090 00 00 04 b5 08 04 be a7 b5 08 05 be a6 b5 08 06 ...�..���..���.. 40000a0 be a6 b5 08 07 be a6 b5 08 08 be a6 b5 08 09 be ���..���..���..� 40000b0 a6 b5 08 0a be a6 b5 08 0b be a6 b5 08 0c be 10 ��..���..���..�. 40000c0 00 00 00 0a b5 08 0d be a5 b5 08 0e be a6 b5 08 ....�..���..���. 40000d0 0f be a6 b5 08 10 be a6 b5 08 11 be 10 00 00 00 .���..���..�.... 40000e0 10 b5 08 12 be 10 00 00 00 48 b5 08 13 be a6 b5 .�..�....H�..��� 40000f0 08 14 be a6 b5 08 15 be b5 08 16 ba a5 a7 b5 08 ..���..��..����. 4000100 17 be a6 b5 08 18 be a6 b5 08 19 be a6 b5 08 1a .���..���..���.. 4000110 be a6 b5 08 1b be a6 b5 08 1c be a6 b5 08 1d be ���..���..���..� 4000120 a6 b5 08 1e be a6 b5 08 1f be a6 b5 08 20 be a6 ��..���..���. �� 4000130 b5 08 21 be a6 b5 08 22 be a6 b5 08 23 be a6 b5 �.!���."���.#��� 4000140 08 24 be a6 b5 08 25 be a6 b5 08 26 be a6 b5 08 .$���.%���.&���. 4000150 27 be b5 08 28 ba a5 a6 b5 08 29 be a6 b5 08 2a '��.(����.)���.* 4000160 be a5 b5 08 2b be a6 b5 08 2c be 10 00 00 00 04 ���.+���.,�..... 4000170 b5 08 2d be a6 b5 08 2e be a6 b5 08 2f be a6 b5 �.-���..���./��� 4000180 08 30 be a7 b5 08 31 be a7 b5 08 32 be 10 00 00 .0���.1���.2�... 4000190 00 06 b5 08 33 be 10 00 00 00 23 b5 08 34 be 10 ..�.3�....#�.4�. 40001a0 00 00 00 11 b5 08 35 be 10 00 00 00 09 b5 08 36 ....�.5�.....�.6 40001b0 be 10 00 00 00 2e b5 08 37 be a6 b5 08 38 be b5 �.....�.7���.8�� 40001c0 08 39 ba a5 a6 b5 08 3a be a6 b5 08 3b be a6 b5 .9����.:���.;��� 40001d0 08 3c be a6 b5 08 3d be a7 b5 08 3e be a7 b5 08 .<���.=���.>���. 40001e0 3f be a7 b5 08 40 be a7 b5 08 41 be a7 b5 08 42 ?���.@���.A���.B 40001f0 be a7 b5 08 43 be a7 b5 08 44 be a7 b5 08 45 be ���.C���.D���.E� 4000200 a7 b5 08 46 be a7 b5 08 47 be a7 b5 08 48 be a7 ��.F���.G���.H�� 4000210 b5 08 49 be 10 00 00 00 04 b5 08 4a be a6 b5 08 �.I�.....�.J���. 4000220 4b be a6 b5 08 4c be a6 b5 08 4d be a6 b5 08 4e K���.L���.M���.N 4000230 be a6 b5 08 4f be a6 b5 08 50 be a6 b5 08 51 be ���.O���.P���.Q� 4000240 a6 b5 08 52 be 10 00 00 00 04 b5 08 53 be 10 00 ��.R�.....�.S�.. 4000250 00 00 18 b5 08 54 be a6 b5 08 55 be a6 b5 08 56 ...�.T���.U���.V 4000260 be a6 b5 08 57 be a6 b5 08 58 be a6 b5 08 59 be ���.W���.X���.Y� 4000270 a6 b5 08 5a be a6 b5 08 5b be a6 b5 08 5c be 10 ��.Z���.[���.\�. 4000280 00 00 00 04 b5 08 5d be a6 b5 08 5e be a6 b5 08 ....�.]���.^���. 4000290 5f be a6 b5 08 60 be a6 b5 08 61 be a6 b5 08 62 _���.`���.a���.b 40002a0 be a6 b5 08 63 be a6 b5 08 64 be a6 b5 08 65 be ���.c���.d���.e� 40002b0 a7 b5 08 66 be a7 b5 08 67 be b5 08 68 ba a5 a6 ��.f���.g��.h��� 40002c0 b5 08 69 be a6 b5 08 6a be a6 b5 08 6b be a6 b5 �.i���.j���.k��� 40002d0 08 6c be a7 b5 08 6d be a7 b5 08 6e be a7 b5 08 .l���.m���.n���. 40002e0 6f be a7 b5 08 70 be a7 b5 08 71 be a6 b5 08 72 o���.p���.q���.r 40002f0 be a6 b5 08 73 be a6 b5 08 74 be a6 b5 08 75 be ���.s���.t���.u� 4000300 a6 b5 08 76 be b5 08 77 ba a5 a6 b5 08 78 be a6 ��.v��.w����.x�� 4000310 b5 08 79 be a6 b5 08 7a be a6 b5 08 7b be 10 00 �.y���.z���.{�.. 4000320 00 00 04 b5 08 7c be 10 00 00 00 04 b5 08 7d be ...�.|�.....�.}� 4000330 10 00 00 00 04 b5 08 7e be 10 00 00 00 04 b5 08 .....�.~�.....�. 4000340 7f be 10 00 00 00 04 b5 08 80 be 10 00 00 00 04 �.....�.��..... 4000350 b5 08 81 be b5 08 82 ba a5 10 00 00 00 04 b5 08 �.���.���.....�. 4000360 83 be 10 00 00 00 04 b5 08 84 be 10 00 00 00 04 ��.....�.��..... 4000370 b5 08 85 be 10 00 00 00 04 b5 08 86 be 10 00 00 �.��.....�.��... 4000380 00 04 b5 08 87 be 10 00 00 00 04 b5 08 88 be 10 ..�.��.....�.��. 4000390 00 00 00 04 b5 08 89 be 10 00 00 00 04 b5 08 8a ....�.��.....�.� 40003a0 be 10 00 00 00 04 b5 08 8b be 10 00 00 00 04 b5 �.....�.��.....� 40003b0 08 8c be 10 00 00 00 04 b5 08 8d be 10 00 00 00 .��.....�.��.... 40003c0 04 b5 08 8e be b5 08 8f ba a5 a6 b5 08 90 be a6 .�.���.�����.��� 40003d0 b5 08 91 be a6 b5 08 92 be a6 b5 08 93 be b5 08 �.����.����.���. 40003e0 94 ba a5 a6 b5 08 95 be a6 b5 08 96 be a7 b5 08 �����.����.����. 40003f0 97 be 10 00 00 00 04 b5 08 98 be 10 00 00 00 04 ��.....�.��..... ok 0 > 0 0 " 4,0" " /pci@80000000" begin-package ok 0 > dev /pci ls fff8043c QEMU,VGA@1 fff84a84 NE2000@2 fff84e5c mac-io@3 fff878ac pci10de,141@4 fff884f4 <noname> ok 0 > setenv focde-debug? true ok 0 > 4000020 1 byte-load ok 0 > dev /pci ls fff8043c QEMU,VGA@1 fff84a84 NE2000@2 fff84e5c mac-io@3 fff878ac pci10de,141@4 fff884f4 <noname> ok 0 > printenv name "options" boot-args "" boot-device "hd:,\:tbxi hd:,\ppc\bootinfo.txt hd:,%BOOT" use-generic? "false" boot-script "" boot-screen "" vga-ndrv? "true" virt-size "-1" virt-base "-1" load-base "4000000" real-size "-1" real-base "-1" real-mode? "false" little-endian? "false" scroll-lock "true" skip-netboot? "false" default-mac-address "false" pci-probe-mask "-1" selftest-#megs "0" screen-#rows "75" screen-#columns "100" output-device "/pci@80000000/mac-io@3/escc/ch-a" input-device "/pci@80000000/mac-io@3/escc/ch-a" use-nvramrc? "false" oem-logo? "false" oem-banner "" oem-banner? "false" nvramrc "" fcode-debug? "false" diag-switch? "false" boot-file "" boot-command "boot" auto-boot? "false" focde-debug? "true" ok 0 > setenv fcode-debug? true ok 0 > 4000020 1 byte-load byte-load: warning stack overflow, diff -3 ok 0 >
I'm not sure, I'm assuming something in the Rom is casing a stack overflow? Does openbios support fcode-verbose? gdb '/home/jam/os9.2/obj-ppc/openbios-qemu.elf.nostrip' GNU gdb (Debian 7.12-6) 7.12.0.20161007-git Copyright (C) 2016 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 "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/jam/os9.2/obj-ppc/openbios-qemu.elf.nostrip...done. (gdb) target remote :1234 Remote debugging using :1234 warning: while parsing target description (at line 1): Target description specified unknown architecture "powerpc:common" warning: Could not load XML target description; ignoring 0x00000000 in ?? () (gdb) b load Breakpoint 1 at 0xfff16f7c: file /Users/jam/OpenBios/master/libopenbios/load.c, line 55. (gdb) c Continuing.
gdb isn't breaking at the load command, but I'm not sure that matters anymore, as it's working, anyway. On Sunday, December 17, 2017, 9:44:34 AM EST, Jd Lyons lyons_dj@yahoo.com wrote:
Sorry, I forgot I remained the Rom file and was trying to load a file that didn’t exist, lead us down a false path.
Loading the correct file and dumping the load base address does yell the Rom.
On Dec 17, 2017, at 9:02 AM, Mark Cave-Ayland mark.cave-ayland@ilande.co.uk wrote:
On 17/12/17 13:53, Jd Lyons wrote:
On Dec 17, 2017, at 7:56 AM, Mark Cave-Ayland mark.cave-ayland@ilande.co.uk wrote:
On 17/12/17 12:41, Jd Lyons wrote:
> Also what FS is your HD image? HFS/HFS+ should work best on qemu-system-ppc, ISO9660 works but is case-sensitive from memory. FS is HFS+, when I execute: > dir hd:,\ I get the list of files, so I know I’m trying to load the Rom from the correct place, and OB can read the drive. I can: > 4000 load hd:,\System\Library\CoreServices\BootX And the system boots.
Which version of QEMU/OpenBIOS are you using? load should only copy the code and run init-program, rather than set up a CPU context and execute go.
Presumably you are building OpenBIOS from git master to get extra debugging information?
git clone https://github.com/openbios/openbios.git. ?????
Yes, that looks correct.
Not sure I’m pulling from the master or not. Is there anything I need to do to enable extra debugging when I build? PATH=:/usr/local/ppcelf/ppcelf/bin:/users/hsp/src/fcode-utils-devel/toke:$PATH export PATH Make -j8
My normal build process for debugging OpenBIOS looks like this:
vi Makefile.target
(alter line 28 to build a debug ELF executable by changing the -Os option in CFLAGS to -O0)
rm -rf obj-*; ./config/scripts/switch-arch ppc
Then start QEMU from a separate terminal like this:
./qemu-system-ppc -bios /patch/to/openbios/obj-pp/openbios-qemu.elf.nostrip -s -S
Seems to fail here, never boots with -S?
Yes indeed. -s -S tell QEMU to wait until the remote gdb connects to QEMU before starting the VM.
Swtich back to your OpenBIOS terminal and then do:
powerpc-linux-gdb obj-ppc/openbios-qemu.elf.nostrip target remote :1234 (connect to QEMU gdbstub) b load (set breakpoint in libopenbios/load.c's load() function) c
You should then find that when you type load into OpenBIOS gdb hits the breakpoint and you can step through the C parts of the code to see what happens. Sadly gdb doesn't have support for debugging Forth, but if you can get this working it will help a lot since all of the ELF/load/init-program and PCI routines are all in C.
I didn’t thing the 4000 load hd:,\bootx should boot the system, yet it does. Assuming I put BootX at the root of my drive, I was thinking it should just load it into system memory at the address 4000. Adding -h doesn’t help, nor does adding -h to the boot command, I’m assuming -h is unemiplmented in Openbios.
You actually don't need the 4000 since according to the specification "load" places the resulting image at the location specified by load-base:
0 > cd /options ok 0 > .properties name "options" boot-args "" boot-device "hd:,\:tbxi hd:,\ppc\bootinfo.txt hd:,%BOOT" use-generic? "false" boot-script "" boot-screen "" vga-ndrv? "true" virt-size "-1" virt-base "-1" load-base "4000000" real-size "-1" real-base "-1" real-mode? "false" little-endian? "false" scroll-lock "true" skip-netboot? "false" default-mac-address "false" pci-probe-mask "-1" selftest-#megs "0" screen-#rows "75" screen-#columns "100" output-device "/pci@80000000/mac-io@3/escc/ch-a" input-device "/pci@80000000/mac-io@3/escc/ch-a" use-nvramrc? "false" oem-logo? "false" oem-banner "" oem-banner? "false" nvramrc "" fcode-debug? "false" diag-switch? "false" boot-file "" boot-command "boot" auto-boot? "true" ok 0 >
Ahhh so wait a second - load-base is set to 0x4000000 rather than 0x4000 which is the default in SPARC. So how about something like:
load hd:,\6600.fcode 4000000 40 dump
Any luck with this bit on your existing setup?
ATB,
Mark.
On 17/12/17 16:00, Jd Lyons wrote:
Ok, here's what I'm getting now:
C>> annot manage 'VGA controller' PCI device type 'display':
10de 141 (3 0 0)
============================================================= OpenBIOS 1.1 [Dec 17 2017 13:36] Configuration device id QEMU version 1 machine id 2 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,750
milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on Dec 17 2017 13:36
0 > load hd:,\ppc\6600.fcode ok 0 > 4000000 400 dump 4000000 55 aa 40 00 00 00 00 00 00 00 00 00 00 00 00 00 U�@............. 4000010 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ........ ....... 4000020 50 43 49 52 de 10 41 01 00 00 20 00 00 00 00 03 PCIR�.A... ..... 4000030 84 00 00 00 01 80 00 00 00 00 00 00 00 00 00 00 �....�.......... 4000040 f1 08 17 0f 00 01 06 55 12 2a 00 00 00 00 00 00 �......U.*...... 4000050 00 00 00 00 de 10 50 00 3e 00 21 00 81 90 40 a3 ....�.P.>.!.��@� 4000060 00 00 00 00 90 04 00 80 00 00 a5 f4 00 00 00 00 ....�..�..��.... 4000070 00 00 00 00 52 a5 b5 08 00 ba a5 10 00 00 00 08 ....R��..��..... 4000080 b5 08 01 be a7 b5 08 02 be a7 b5 08 03 be 10 00 �..���..���..�.. 4000090 00 00 04 b5 08 04 be a7 b5 08 05 be a6 b5 08 06 ...�..���..���.. 40000a0 be a6 b5 08 07 be a6 b5 08 08 be a6 b5 08 09 be ���..���..���..� 40000b0 a6 b5 08 0a be a6 b5 08 0b be a6 b5 08 0c be 10 ��..���..���..�. 40000c0 00 00 00 0a b5 08 0d be a5 b5 08 0e be a6 b5 08 ....�..���..���. 40000d0 0f be a6 b5 08 10 be a6 b5 08 11 be 10 00 00 00 .���..���..�.... 40000e0 10 b5 08 12 be 10 00 00 00 48 b5 08 13 be a6 b5 .�..�....H�..��� 40000f0 08 14 be a6 b5 08 15 be b5 08 16 ba a5 a7 b5 08 ..���..��..����. 4000100 17 be a6 b5 08 18 be a6 b5 08 19 be a6 b5 08 1a .���..���..���.. 4000110 be a6 b5 08 1b be a6 b5 08 1c be a6 b5 08 1d be ���..���..���..� 4000120 a6 b5 08 1e be a6 b5 08 1f be a6 b5 08 20 be a6 ��..���..���. �� 4000130 b5 08 21 be a6 b5 08 22 be a6 b5 08 23 be a6 b5 �.!���."���.#��� 4000140 08 24 be a6 b5 08 25 be a6 b5 08 26 be a6 b5 08 .$���.%���.&���. 4000150 27 be b5 08 28 ba a5 a6 b5 08 29 be a6 b5 08 2a '��.(����.)���.* 4000160 be a5 b5 08 2b be a6 b5 08 2c be 10 00 00 00 04 ���.+���.,�..... 4000170 b5 08 2d be a6 b5 08 2e be a6 b5 08 2f be a6 b5 �.-���..���./��� 4000180 08 30 be a7 b5 08 31 be a7 b5 08 32 be 10 00 00 .0���.1���.2�... 4000190 00 06 b5 08 33 be 10 00 00 00 23 b5 08 34 be 10 ..�.3�....#�.4�. 40001a0 00 00 00 11 b5 08 35 be 10 00 00 00 09 b5 08 36 ....�.5�.....�.6 40001b0 be 10 00 00 00 2e b5 08 37 be a6 b5 08 38 be b5 �.....�.7���.8�� 40001c0 08 39 ba a5 a6 b5 08 3a be a6 b5 08 3b be a6 b5 .9����.:���.;��� 40001d0 08 3c be a6 b5 08 3d be a7 b5 08 3e be a7 b5 08 .<���.=���.>���. 40001e0 3f be a7 b5 08 40 be a7 b5 08 41 be a7 b5 08 42 ?���.@���.A���.B 40001f0 be a7 b5 08 43 be a7 b5 08 44 be a7 b5 08 45 be ���.C���.D���.E� 4000200 a7 b5 08 46 be a7 b5 08 47 be a7 b5 08 48 be a7 ��.F���.G���.H�� 4000210 b5 08 49 be 10 00 00 00 04 b5 08 4a be a6 b5 08 �.I�.....�.J���. 4000220 4b be a6 b5 08 4c be a6 b5 08 4d be a6 b5 08 4e K���.L���.M���.N 4000230 be a6 b5 08 4f be a6 b5 08 50 be a6 b5 08 51 be ���.O���.P���.Q� 4000240 a6 b5 08 52 be 10 00 00 00 04 b5 08 53 be 10 00 ��.R�.....�.S�.. 4000250 00 00 18 b5 08 54 be a6 b5 08 55 be a6 b5 08 56 ...�.T���.U���.V 4000260 be a6 b5 08 57 be a6 b5 08 58 be a6 b5 08 59 be ���.W���.X���.Y� 4000270 a6 b5 08 5a be a6 b5 08 5b be a6 b5 08 5c be 10 ��.Z���.[���.\�. 4000280 00 00 00 04 b5 08 5d be a6 b5 08 5e be a6 b5 08 ....�.]���.^���. 4000290 5f be a6 b5 08 60 be a6 b5 08 61 be a6 b5 08 62 _���.`���.a���.b 40002a0 be a6 b5 08 63 be a6 b5 08 64 be a6 b5 08 65 be ���.c���.d���.e� 40002b0 a7 b5 08 66 be a7 b5 08 67 be b5 08 68 ba a5 a6 ��.f���.g��.h��� 40002c0 b5 08 69 be a6 b5 08 6a be a6 b5 08 6b be a6 b5 �.i���.j���.k��� 40002d0 08 6c be a7 b5 08 6d be a7 b5 08 6e be a7 b5 08 .l���.m���.n���. 40002e0 6f be a7 b5 08 70 be a7 b5 08 71 be a6 b5 08 72 o���.p���.q���.r 40002f0 be a6 b5 08 73 be a6 b5 08 74 be a6 b5 08 75 be ���.s���.t���.u� 4000300 a6 b5 08 76 be b5 08 77 ba a5 a6 b5 08 78 be a6 ��.v��.w����.x�� 4000310 b5 08 79 be a6 b5 08 7a be a6 b5 08 7b be 10 00 �.y���.z���.{�.. 4000320 00 00 04 b5 08 7c be 10 00 00 00 04 b5 08 7d be ...�.|�.....�.}� 4000330 10 00 00 00 04 b5 08 7e be 10 00 00 00 04 b5 08 .....�.~�.....�. 4000340 7f be 10 00 00 00 04 b5 08 80 be 10 00 00 00 04 �.....�.��..... 4000350 b5 08 81 be b5 08 82 ba a5 10 00 00 00 04 b5 08 �.���.���.....�. 4000360 83 be 10 00 00 00 04 b5 08 84 be 10 00 00 00 04 ��.....�.��..... 4000370 b5 08 85 be 10 00 00 00 04 b5 08 86 be 10 00 00 �.��.....�.��... 4000380 00 04 b5 08 87 be 10 00 00 00 04 b5 08 88 be 10 ..�.��.....�.��. 4000390 00 00 00 04 b5 08 89 be 10 00 00 00 04 b5 08 8a ....�.��.....�.� 40003a0 be 10 00 00 00 04 b5 08 8b be 10 00 00 00 04 b5 �.....�.��.....� 40003b0 08 8c be 10 00 00 00 04 b5 08 8d be 10 00 00 00 .��.....�.��.... 40003c0 04 b5 08 8e be b5 08 8f ba a5 a6 b5 08 90 be a6 .�.���.�����.��� 40003d0 b5 08 91 be a6 b5 08 92 be a6 b5 08 93 be b5 08 �.����.����.���. 40003e0 94 ba a5 a6 b5 08 95 be a6 b5 08 96 be a7 b5 08 �����.����.����. 40003f0 97 be 10 00 00 00 04 b5 08 98 be 10 00 00 00 04 ��.....�.��..... ok 0 > 0 0 " 4,0" " /pci@80000000" begin-package ok 0 > dev /pci ls fff8043c QEMU,VGA@1 fff84a84 NE2000@2 fff84e5c mac-io@3 fff878ac pci10de,141@4 fff884f4 <noname> ok 0 > setenv focde-debug? true ok 0 > 4000020 1 byte-load ok 0 > dev /pci ls fff8043c QEMU,VGA@1 fff84a84 NE2000@2 fff84e5c mac-io@3 fff878ac pci10de,141@4 fff884f4 <noname> ok 0 > printenv name "options" boot-args "" boot-device "hd:,\:tbxi hd:,\ppc\bootinfo.txt hd:,%BOOT" use-generic? "false" boot-script "" boot-screen "" vga-ndrv? "true" virt-size "-1" virt-base "-1" load-base "4000000" real-size "-1" real-base "-1" real-mode? "false" little-endian? "false" scroll-lock "true" skip-netboot? "false" default-mac-address "false" pci-probe-mask "-1" selftest-#megs "0" screen-#rows "75" screen-#columns "100" output-device "/pci@80000000/mac-io@3/escc/ch-a" input-device "/pci@80000000/mac-io@3/escc/ch-a" use-nvramrc? "false" oem-logo? "false" oem-banner "" oem-banner? "false" nvramrc "" fcode-debug? "false" diag-switch? "false" boot-file "" boot-command "boot" auto-boot? "false" focde-debug? "true" ok 0 > setenv fcode-debug? true ok 0 > 4000020 1 byte-load byte-load: warning stack overflow, diff -3 ok 0 >
I'm not sure, I'm assuming something in the Rom is casing a stack overflow?
Looks good. I'm fairly sure from the ROM dump above that the FCode start byte is 0xf1 which is located at offset 0x40, so try changing the byte-load line to:
true to ?fcode-verbose 4000040 1 byte-load
Does openbios support fcode-verbose?
Yes - I've added it into the snippet above for reference.
gdb '/home/jam/os9.2/obj-ppc/openbios-qemu.elf.nostrip' GNU gdb (Debian 7.12-6) 7.12.0.20161007-git Copyright (C) 2016 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 "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/jam/os9.2/obj-ppc/openbios-qemu.elf.nostrip...done. (gdb) target remote :1234 Remote debugging using :1234 warning: while parsing target description (at line 1): Target description specified unknown architecture "powerpc:common" warning: Could not load XML target description; ignoring 0x00000000 in ?? () (gdb) b load Breakpoint 1 at 0xfff16f7c: file /Users/jam/OpenBios/master/libopenbios/load.c, line 55. (gdb) c Continuing.
gdb isn't breaking at the load command, but I'm not sure that matters anymore, as it's working, anyway.
If you want to build OpenBIOS yourself and use QEMU's gdbstub on an x86 host then you'll need to build yourself a powerpc cross-compiler and cross-gdb - a search using Google will give you lots of different tutorials as to how to do this.
ATB,
Mark.
On Dec 17, 2017, at 11:12 AM, Mark Cave-Ayland mark.cave-ayland@ilande.co.uk wrote:
On 17/12/17 16:00, Jd Lyons wrote:
Ok, here's what I'm getting now: C>> annot manage 'VGA controller' PCI device type 'display':
10de 141 (3 0 0)
OpenBIOS 1.1 [Dec 17 2017 13:36] Configuration device id QEMU version 1 machine id 2 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,750
milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on Dec 17 2017 13:36 0 > load hd:,\ppc\6600.fcode ok 0 > 4000000 400 dump 4000000 55 aa 40 00 00 00 00 00 00 00 00 00 00 00 00 00 U�@............. 4000010 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ........ ....... 4000020 50 43 49 52 de 10 41 01 00 00 20 00 00 00 00 03 PCIR�.A... ..... 4000030 84 00 00 00 01 80 00 00 00 00 00 00 00 00 00 00 �....�.......... 4000040 f1 08 17 0f 00 01 06 55 12 2a 00 00 00 00 00 00 �......U.*...... 4000050 00 00 00 00 de 10 50 00 3e 00 21 00 81 90 40 a3 ....�.P.>.!.��@� 4000060 00 00 00 00 90 04 00 80 00 00 a5 f4 00 00 00 00 ....�..�..��.... 4000070 00 00 00 00 52 a5 b5 08 00 ba a5 10 00 00 00 08 ....R��..��..... 4000080 b5 08 01 be a7 b5 08 02 be a7 b5 08 03 be 10 00 �..���..���..�.. 4000090 00 00 04 b5 08 04 be a7 b5 08 05 be a6 b5 08 06 ...�..���..���.. 40000a0 be a6 b5 08 07 be a6 b5 08 08 be a6 b5 08 09 be ���..���..���..� 40000b0 a6 b5 08 0a be a6 b5 08 0b be a6 b5 08 0c be 10 ��..���..���..�. 40000c0 00 00 00 0a b5 08 0d be a5 b5 08 0e be a6 b5 08 ....�..���..���. 40000d0 0f be a6 b5 08 10 be a6 b5 08 11 be 10 00 00 00 .���..���..�.... 40000e0 10 b5 08 12 be 10 00 00 00 48 b5 08 13 be a6 b5 .�..�....H�..��� 40000f0 08 14 be a6 b5 08 15 be b5 08 16 ba a5 a7 b5 08 ..���..��..����. 4000100 17 be a6 b5 08 18 be a6 b5 08 19 be a6 b5 08 1a .���..���..���.. 4000110 be a6 b5 08 1b be a6 b5 08 1c be a6 b5 08 1d be ���..���..���..� 4000120 a6 b5 08 1e be a6 b5 08 1f be a6 b5 08 20 be a6 ��..���..���. �� 4000130 b5 08 21 be a6 b5 08 22 be a6 b5 08 23 be a6 b5 �.!���."���.#��� 4000140 08 24 be a6 b5 08 25 be a6 b5 08 26 be a6 b5 08 .$���.%���.&���. 4000150 27 be b5 08 28 ba a5 a6 b5 08 29 be a6 b5 08 2a '��.(����.)���.* 4000160 be a5 b5 08 2b be a6 b5 08 2c be 10 00 00 00 04 ���.+���.,�..... 4000170 b5 08 2d be a6 b5 08 2e be a6 b5 08 2f be a6 b5 �.-���..���./��� 4000180 08 30 be a7 b5 08 31 be a7 b5 08 32 be 10 00 00 .0���.1���.2�... 4000190 00 06 b5 08 33 be 10 00 00 00 23 b5 08 34 be 10 ..�.3�....#�.4�. 40001a0 00 00 00 11 b5 08 35 be 10 00 00 00 09 b5 08 36 ....�.5�.....�.6 40001b0 be 10 00 00 00 2e b5 08 37 be a6 b5 08 38 be b5 �.....�.7���.8�� 40001c0 08 39 ba a5 a6 b5 08 3a be a6 b5 08 3b be a6 b5 .9����.:���.;��� 40001d0 08 3c be a6 b5 08 3d be a7 b5 08 3e be a7 b5 08 .<���.=���.>���. 40001e0 3f be a7 b5 08 40 be a7 b5 08 41 be a7 b5 08 42 ?���.@���.A���.B 40001f0 be a7 b5 08 43 be a7 b5 08 44 be a7 b5 08 45 be ���.C���.D���.E� 4000200 a7 b5 08 46 be a7 b5 08 47 be a7 b5 08 48 be a7 ��.F���.G���.H�� 4000210 b5 08 49 be 10 00 00 00 04 b5 08 4a be a6 b5 08 �.I�.....�.J���. 4000220 4b be a6 b5 08 4c be a6 b5 08 4d be a6 b5 08 4e K���.L���.M���.N 4000230 be a6 b5 08 4f be a6 b5 08 50 be a6 b5 08 51 be ���.O���.P���.Q� 4000240 a6 b5 08 52 be 10 00 00 00 04 b5 08 53 be 10 00 ��.R�.....�.S�.. 4000250 00 00 18 b5 08 54 be a6 b5 08 55 be a6 b5 08 56 ...�.T���.U���.V 4000260 be a6 b5 08 57 be a6 b5 08 58 be a6 b5 08 59 be ���.W���.X���.Y� 4000270 a6 b5 08 5a be a6 b5 08 5b be a6 b5 08 5c be 10 ��.Z���.[���.\�. 4000280 00 00 00 04 b5 08 5d be a6 b5 08 5e be a6 b5 08 ....�.]���.^���. 4000290 5f be a6 b5 08 60 be a6 b5 08 61 be a6 b5 08 62 _���.`���.a���.b 40002a0 be a6 b5 08 63 be a6 b5 08 64 be a6 b5 08 65 be ���.c���.d���.e� 40002b0 a7 b5 08 66 be a7 b5 08 67 be b5 08 68 ba a5 a6 ��.f���.g��.h��� 40002c0 b5 08 69 be a6 b5 08 6a be a6 b5 08 6b be a6 b5 �.i���.j���.k��� 40002d0 08 6c be a7 b5 08 6d be a7 b5 08 6e be a7 b5 08 .l���.m���.n���. 40002e0 6f be a7 b5 08 70 be a7 b5 08 71 be a6 b5 08 72 o���.p���.q���.r 40002f0 be a6 b5 08 73 be a6 b5 08 74 be a6 b5 08 75 be ���.s���.t���.u� 4000300 a6 b5 08 76 be b5 08 77 ba a5 a6 b5 08 78 be a6 ��.v��.w����.x�� 4000310 b5 08 79 be a6 b5 08 7a be a6 b5 08 7b be 10 00 �.y���.z���.{�.. 4000320 00 00 04 b5 08 7c be 10 00 00 00 04 b5 08 7d be ...�.|�.....�.}� 4000330 10 00 00 00 04 b5 08 7e be 10 00 00 00 04 b5 08 .....�.~�.....�. 4000340 7f be 10 00 00 00 04 b5 08 80 be 10 00 00 00 04 �.....�.��..... 4000350 b5 08 81 be b5 08 82 ba a5 10 00 00 00 04 b5 08 �.���.���.....�. 4000360 83 be 10 00 00 00 04 b5 08 84 be 10 00 00 00 04 ��.....�.��..... 4000370 b5 08 85 be 10 00 00 00 04 b5 08 86 be 10 00 00 �.��.....�.��... 4000380 00 04 b5 08 87 be 10 00 00 00 04 b5 08 88 be 10 ..�.��.....�.��. 4000390 00 00 00 04 b5 08 89 be 10 00 00 00 04 b5 08 8a ....�.��.....�.� 40003a0 be 10 00 00 00 04 b5 08 8b be 10 00 00 00 04 b5 �.....�.��.....� 40003b0 08 8c be 10 00 00 00 04 b5 08 8d be 10 00 00 00 .��.....�.��.... 40003c0 04 b5 08 8e be b5 08 8f ba a5 a6 b5 08 90 be a6 .�.���.�����.��� 40003d0 b5 08 91 be a6 b5 08 92 be a6 b5 08 93 be b5 08 �.����.����.���. 40003e0 94 ba a5 a6 b5 08 95 be a6 b5 08 96 be a7 b5 08 �����.����.����. 40003f0 97 be 10 00 00 00 04 b5 08 98 be 10 00 00 00 04 ��.....�.��..... ok 0 > 0 0 " 4,0" " /pci@80000000" begin-package ok 0 > dev /pci ls fff8043c QEMU,VGA@1 fff84a84 NE2000@2 fff84e5c mac-io@3 fff878ac pci10de,141@4 fff884f4 <noname> ok 0 > setenv focde-debug? true ok 0 > 4000020 1 byte-load ok 0 > dev /pci ls fff8043c QEMU,VGA@1 fff84a84 NE2000@2 fff84e5c mac-io@3 fff878ac pci10de,141@4 fff884f4 <noname> ok 0 > printenv name "options" boot-args "" boot-device "hd:,\:tbxi hd:,\ppc\bootinfo.txt hd:,%BOOT" use-generic? "false" boot-script "" boot-screen "" vga-ndrv? "true" virt-size "-1" virt-base "-1" load-base "4000000" real-size "-1" real-base "-1" real-mode? "false" little-endian? "false" scroll-lock "true" skip-netboot? "false" default-mac-address "false" pci-probe-mask "-1" selftest-#megs "0" screen-#rows "75" screen-#columns "100" output-device "/pci@80000000/mac-io@3/escc/ch-a" input-device "/pci@80000000/mac-io@3/escc/ch-a" use-nvramrc? "false" oem-logo? "false" oem-banner "" oem-banner? "false" nvramrc "" fcode-debug? "false" diag-switch? "false" boot-file "" boot-command "boot" auto-boot? "false" focde-debug? "true" ok 0 > setenv fcode-debug? true ok 0 > 4000020 1 byte-load byte-load: warning stack overflow, diff -3 ok 0 > I'm not sure, I'm assuming something in the Rom is casing a stack overflow?
Looks good. I'm fairly sure from the ROM dump above that the FCode start byte is 0xf1 which is located at offset 0x40, so try changing the byte-load line to:
true to ?fcode-verbose 4000040 1 byte-load
Does openbios support fcode-verbose?
Yes - I've added it into the snippet above for reference.
gdb '/home/jam/os9.2/obj-ppc/openbios-qemu.elf.nostrip' GNU gdb (Debian 7.12-6) 7.12.0.20161007-git Copyright (C) 2016 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 "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/jam/os9.2/obj-ppc/openbios-qemu.elf.nostrip...done. (gdb) target remote :1234 Remote debugging using :1234 warning: while parsing target description (at line 1): Target description specified unknown architecture "powerpc:common" warning: Could not load XML target description; ignoring 0x00000000 in ?? () (gdb) b load Breakpoint 1 at 0xfff16f7c: file /Users/jam/OpenBios/master/libopenbios/load.c, line 55. (gdb) c Continuing. gdb isn't breaking at the load command, but I'm not sure that matters anymore, as it's working, anyway.
If you want to build OpenBIOS yourself and use QEMU's gdbstub on an x86 host then you'll need to build yourself a powerpc cross-compiler and cross-gdb - a search using Google will give you lots of different tutorials as to how to do this.
I made one a while ago for building OpenBIOS on Mac OS X. It is a bit dated but it should be helpful to you: https://www.openfirmware.info/How_to_build_OpenBIOS_on_Mac_OS_X
On 2017-Dec-17 11:00 , Jd Lyons wrote: [...]
0 > load hd:,\ppc\6600.fcode ok 0 > 4000000 400 dump 4000000 55 aa 40 00 00 00 00 00 00 00 00 00 00 00 00 00 U�@............. 4000010 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ........ ....... 4000020 50 43 49 52 de 10 41 01 00 00 20 00 00 00 00 03 PCIR�.A... ..... 4000030 84 00 00 00 01 80 00 00 00 00 00 00 00 00 00 00 �....�..........
That looks like stuff from a PCI option ROM. But you can't start at 4000020, that's still in the PCI header overhead.
See
https://code.coreboot.org/p/openboot/source/tree/1/obp/dev/pci/fcode-rom.fth
Follow the code in locate-fcode and fcode-image? to find where the code starts. From my recollection, this looks like the FCode is for a card with vendor ID 10de and device ID 0141. It looks like the FCode should start at 4000040, so that's the address you should feel into byte-load.
0 > 0 0 " 4,0" " /pci@80000000" begin-package ok 0 > dev /pci ls
That "dev" is harmful, it's taking you out of the PCI node, you need to stay inside unnamed node. Don't do that.
0 > setenv focde-debug? true ok 0 > 4000020 1 byte-load ok
If this had worked with fcode-debug? set to true, I think you would normally have gotten the name of the device printed out.
0 > dev /pci ls
This is again taking you out of wherever you had run the FCode.
0 > setenv fcode-debug? true ok 0 > 4000020 1 byte-load byte-load: warning stack overflow, diff -3 ok 0 >
At this point, you're doing a second execution of the PCI header, and I have no idea what "PCIR" does as FCodes. It undoubtedly got confused and did something dumb.
Ok, now I think we're getting somewhere:
4010006 : (compile) encode-bytes [ 0x115 ]4010008 : (compile) encode+ [ 0x112 ] 4010009 : (compile) b(endof) [ 0xc6 ] (offset) 5 401000d : (compile) [ 0xe05 ] 401000e : (compile) b(endcase) [ 0xc5 ] 401000f : (compile) over [ 0x48 ] 4010010 : (compile) b(to) [ 0xc3 ] 4010014 : (compile) [ 0xe36 ] 4010016 : (compile) encode+ [ 0x112 ] 4010017 : (compile) 2dup [ 0x53 ] 4010018 : (compile) b(to) [ 0xc3 ] 401001b : (compile) b(to) [ 0xc3 ] 401001f : (compile) [ 0xc7b ] 4010021 : (compile) property [ 0x110 ] 4010022 : (compile) b(;) [ 0xc2 ] 4010023 : b(') [ 0x11 ] 4010026 : b(to) [ 0xc3 ] 401002a : [ 0xe34 ]
byte-load: exception caught! ok
On Sunday, December 17, 2017, 11:21:11 AM EST, Tarl Neustaedter tarl-b2@tarl.net wrote:
On 2017-Dec-17 11:00 , Jd Lyons wrote: [...]
0 > load hd:,\ppc\6600.fcode ok 0 > 4000000 400 dump 4000000 55 aa 40 00 00 00 00 00 00 00 00 00 00 00 00 00 U�@............. 4000010 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ........ ....... 4000020 50 43 49 52 de 10 41 01 00 00 20 00 00 00 00 03 PCIR�.A... ..... 4000030 84 00 00 00 01 80 00 00 00 00 00 00 00 00 00 00 �....�..........
That looks like stuff from a PCI option ROM. But you can't start at 4000020, that's still in the PCI header overhead.
See
https://code.coreboot.org/p/openboot/source/tree/1/obp/dev/pci/fcode-rom.fth
Follow the code in locate-fcode and fcode-image? to find where the code starts. From my recollection, this looks like the FCode is for a card with vendor ID 10de and device ID 0141. It looks like the FCode should start at 4000040, so that's the address you should feel into byte-load.
0 > 0 0 " 4,0" " /pci@80000000" begin-package ok 0 > dev /pci ls
That "dev" is harmful, it's taking you out of the PCI node, you need to stay inside unnamed node. Don't do that.
0 > setenv focde-debug? true ok 0 > 4000020 1 byte-load ok
If this had worked with fcode-debug? set to true, I think you would normally have gotten the name of the device printed out.
0 > dev /pci ls
This is again taking you out of wherever you had run the FCode.
0 > setenv fcode-debug? true ok 0 > 4000020 1 byte-load byte-load: warning stack overflow, diff -3 ok 0 >
At this point, you're doing a second execution of the PCI header, and I have no idea what "PCIR" does as FCodes. It undoubtedly got confused and did something dumb.
0 > 4010026 400 dump 4010026 c3 09 a9 0e 34 0d ff 09 3d 10 00 00 00 0f 3d 14 �.�.4.�.=.....=. 4010036 00 26 09 bd 10 00 00 00 ff 23 01 03 1e 0a 08 10 .&.�....�#...... 4010046 00 00 00 06 23 10 00 00 00 04 3c 14 00 09 11 09 ....#.....<..... 4010056 c1 c3 09 c0 b2 b2 0d df 0e 04 0e 38 0e 06 0c e5 ��.���.�...8...� 4010066 0d b0 0e 07 0e 1a 0c 5b 0e 28 0e 20 0d fa 0e 37 .�.....[.(. .�.7 4010076 0e 2c 0e 2d 12 0b 4e 56 44 41 2c 50 61 72 65 6e .,.-..NVDA,Paren 4010086 74 02 01 a6 01 11 12 0e 23 61 64 64 72 65 73 73 t..�....#address 4010096 2d 63 65 6c 6c 73 01 10 a5 01 11 12 0b 23 73 69 -cells..�....#si 40100a6 7a 65 2d 63 65 6c 6c 73 01 10 09 c7 09 3d 10 00 ze-cells...�.=.. 40100b6 00 00 35 42 14 00 0d a6 09 33 27 09 35 24 c3 09 ..5B...�.3'.5$�. 40100c6 35 b2 09 41 10 00 00 00 10 27 09 35 24 01 11 12 5�.A.....'.5$... 40100d6 0d 4e 56 44 41 2c 46 65 61 74 75 72 65 73 01 10 .NVDA,Features.. 40100e6 a6 01 11 12 0a 4e 56 44 41 2c 4c 65 76 65 6c 01 �....NVDA,Level. 40100f6 10 a5 a5 0e 2e 09 bc 09 c3 0e 2e 01 12 09 c0 09 .��...�.�.....�. 4010106 c6 0e 2e 01 12 09 be 09 c4 0e 2e 01 12 09 bf 09 �.....�.�.....�. 4010116 c5 0e 2e 01 12 12 03 72 65 67 01 10 a6 01 11 12 �......reg..�... 4010126 0e 23 61 64 64 72 65 73 73 2d 63 65 6c 6c 73 01 .#address-cells. 4010136 10 a5 01 11 12 0b 23 73 69 7a 65 2d 63 65 6c 6c .�....#size-cell 4010146 73 01 10 12 1a 3a 20 64 65 63 6f 64 65 2d 75 6e s....: decode-un 4010156 69 74 20 70 61 72 73 65 2d 31 68 65 78 20 3b cd it parse-1hex ;� 4010166 0c 7c 47 01 11 4a 01 11 01 12 12 0c 56 52 41 4d .|G..J......VRAM 4010176 2c 6d 65 6d 73 69 7a 65 01 10 a5 c3 09 52 09 51 ,memsize..��.R.Q 4010186 a5 18 00 16 19 0a 41 0a 4a 08 ea 3d 14 00 08 19 �.....A.J.�=.... 4010196 c3 09 52 1b b2 15 ff ee 09 46 38 14 01 b0 09 52 �.R.�.��.F8..�.R 40101a6 0a 41 01 1f 0e 32 b5 0e 39 b7 09 52 0a 41 0d f1 .A...2�.9�.R.A.� 40101b6 c3 01 62 c2 b5 0e 3a b7 09 52 0a 41 0d f2 c2 b6 �.bµ.:�.R.A.�¶ 40101c6 08 67 65 74 2d 6d 6f 64 65 0e 3b b7 0d cb c2 b6 .get-mode.;�.�¶ 40101d6 0a 73 68 6f 77 2d 6d 6f 64 65 73 0e 3c b7 0d cc .show-modes.<�.� 40101e6 c2 ca 08 73 65 74 2d 6d 6f 64 65 0e 3d b7 09 52 ��.set-mode.=�.R 40101f6 0a 41 0d ca c2 ca 0e 64 72 61 77 2d 72 65 63 74 .A.���.draw-rect 4010206 61 6e 67 6c 65 0e 3e b7 09 52 0a 41 0d d5 c2 ca angle.>�.R.A.��� 4010216 0e 66 69 6c 6c 2d 72 65 63 74 61 6e 67 6c 65 0e .fill-rectangle. 4010226 3f b7 09 52 0a 41 0d d7 c2 ca 0e 72 65 61 64 2d ?�.R.A.���.read- 4010236 72 65 63 74 61 6e 67 6c 65 0e 40 b7 09 52 0a 41 rectangle.@�.R.A 4010246 0d d6 c2 ca 06 63 6f 6c 6f 72 21 0e 41 b7 09 52 .���.color!.A�.R 4010256 0a 41 0c f7 c2 ca 06 63 6f 6c 6f 72 40 0e 42 b7 .A.���.color@.B� 4010266 09 52 0a 41 0c f9 c2 ca 0a 73 65 74 2d 63 6f 6c .R.A.���.set-col 4010276 6f 72 73 0e 43 b7 09 52 0a 41 0c f3 c2 ca 0a 67 ors.C�.R.A.���.g 4010286 65 74 2d 63 6f 6c 6f 72 73 0e 44 b7 09 52 0a 41 et-colors.D�.R.A 4010296 0c f5 c2 ca 0a 64 69 6d 65 6e 73 69 6f 6e 73 0e .���.dimensions. 40102a6 45 b7 0b 70 0b 71 c2 ca 0e 64 64 63 32 2d 73 65 E�.p.q��.ddc2-se 40102b6 74 2d 73 74 61 72 74 0e 46 b7 09 52 0a 41 0d f3 t-start.F�.R.A.� 40102c6 c2 ca 0d 64 64 63 32 2d 73 65 74 2d 73 74 6f 70 ��.ddc2-set-stop 40102d6 0e 47 b7 09 52 0a 41 0d f4 c2 ca 0e 64 64 63 32 .G�.R.A.���.ddc2 40102e6 2d 73 65 6e 64 2d 62 79 74 65 0e 48 b7 09 52 0a -send-byte.H�.R. 40102f6 41 0d f5 c2 09 5f a6 09 52 27 23 35 14 00 42 ca A.��._�.R'#5..B� 4010306 13 70 6f 77 65 72 2d 73 77 69 74 63 68 2d 65 6e .power-switch-en 4010316 61 62 6c 65 0e 49 b7 09 52 0d d8 c2 ca 14 70 6f able.I�.R.���.po 4010326 77 65 72 2d 73 77 69 74 63 68 2d 64 69 73 61 62 wer-switch-disab 4010336 6c 65 0e 4a b7 09 52 0d d9 c2 09 52 0d d9 b2 11 le.J�.R.��.R.ٲ. 4010346 0e 39 01 1c 11 0e 3a 01 1d 01 27 b2 09 46 a6 3b .9....:...'�.F�; 4010356 14 01 dc a4 09 51 a5 18 00 25 19 09 52 3d 14 00 ..ܤ.Q�..%..R=.. 4010366 1b 47 a4 3c 14 00 05 46 19 b2 19 0a 41 0a 4a 08 .G�<...F.�..A.J. 4010376 ea 3d 14 00 06 46 19 1b b2 b2 15 ff df 47 c3 09 �=...F..��.��G�. 4010386 53 0a 41 01 1f 0e 32 b5 0e 4b b7 09 53 0a 41 0d S.A...2�.K�.S.A. 4010396 f1 c3 01 62 c2 b5 0e 4c b7 09 53 0a 41 0d f2 c2 ��.bµ.L�.S.A.�� 40103a6 b6 08 67 65 74 2d 6d 6f 64 65 0e 4d b7 0d cb c2 �.get-mode.M�.�� 40103b6 b6 0a 73 68 6f 77 2d 6d 6f 64 65 73 0e 4e b7 0d �.show-modes.N�. 40103c6 cc c2 ca 08 73 65 74 2d 6d 6f 64 65 0e 4f b7 09 ���.set-mode.O�. 40103d6 53 0a 41 0d ca c2 ca 0e 64 72 61 77 2d 72 65 63 S.A.���.draw-rec 40103e6 74 61 6e 67 6c 65 0e 50 b7 09 53 0a 41 0d d5 c2 tangle.P�.S.A.�� 40103f6 ca 0e 66 69 6c 6c 2d 72 65 63 74 61 6e 67 6c 65 �.fill-rectangle 4010406 0e 51 b7 09 53 0a 41 0d d7 c2 ca 0e 72 65 61 64 .Q�.S.A.���.read 4010416 2d 72 65 63 74 61 6e 67 6c 65 0e 52 b7 09 53 0a -rectangle.R�.S. ok
Looks like trouble when Openbios tries to build the device up in Name Space? On Sunday, December 17, 2017, 11:25:08 AM EST, Jd Lyons lyons_dj@yahoo.com wrote:
Ok, now I think we're getting somewhere:
4010006 : (compile) encode-bytes [ 0x115 ]4010008 : (compile) encode+ [ 0x112 ] 4010009 : (compile) b(endof) [ 0xc6 ] (offset) 5 401000d : (compile) [ 0xe05 ] 401000e : (compile) b(endcase) [ 0xc5 ] 401000f : (compile) over [ 0x48 ] 4010010 : (compile) b(to) [ 0xc3 ] 4010014 : (compile) [ 0xe36 ] 4010016 : (compile) encode+ [ 0x112 ] 4010017 : (compile) 2dup [ 0x53 ] 4010018 : (compile) b(to) [ 0xc3 ] 401001b : (compile) b(to) [ 0xc3 ] 401001f : (compile) [ 0xc7b ] 4010021 : (compile) property [ 0x110 ] 4010022 : (compile) b(;) [ 0xc2 ] 4010023 : b(') [ 0x11 ] 4010026 : b(to) [ 0xc3 ] 401002a : [ 0xe34 ]
byte-load: exception caught! ok
On Sunday, December 17, 2017, 11:21:11 AM EST, Tarl Neustaedter tarl-b2@tarl.net wrote:
On 2017-Dec-17 11:00 , Jd Lyons wrote: [...]
0 > load hd:,\ppc\6600.fcode ok 0 > 4000000 400 dump 4000000 55 aa 40 00 00 00 00 00 00 00 00 00 00 00 00 00 U�@............. 4000010 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ........ ....... 4000020 50 43 49 52 de 10 41 01 00 00 20 00 00 00 00 03 PCIR�.A... ..... 4000030 84 00 00 00 01 80 00 00 00 00 00 00 00 00 00 00 �....�..........
That looks like stuff from a PCI option ROM. But you can't start at 4000020, that's still in the PCI header overhead.
See
https://code.coreboot.org/p/openboot/source/tree/1/obp/dev/pci/fcode-rom.fth
Follow the code in locate-fcode and fcode-image? to find where the code starts. From my recollection, this looks like the FCode is for a card with vendor ID 10de and device ID 0141. It looks like the FCode should start at 4000040, so that's the address you should feel into byte-load.
0 > 0 0 " 4,0" " /pci@80000000" begin-package ok 0 > dev /pci ls
That "dev" is harmful, it's taking you out of the PCI node, you need to stay inside unnamed node. Don't do that.
0 > setenv focde-debug? true ok 0 > 4000020 1 byte-load ok
If this had worked with fcode-debug? set to true, I think you would normally have gotten the name of the device printed out.
0 > dev /pci ls
This is again taking you out of wherever you had run the FCode.
0 > setenv fcode-debug? true ok 0 > 4000020 1 byte-load byte-load: warning stack overflow, diff -3 ok 0 >
At this point, you're doing a second execution of the PCI header, and I have no idea what "PCIR" does as FCodes. It undoubtedly got confused and did something dumb.
On 2017-Dec-17 11:29 , Jd Lyons wrote:
0 > 4010026 400 dump 4010026 c3 09 a9 0e 34 0d ff 09 3d 10 00 00 00 0f 3d 14 �.�.4.�.=.....=. 4010036 00 26 09 bd 10 00 00 00 ff 23 01 03 1e 0a 08 10 .&.�....�#...... 4010046 00 00 00 06 23 10 00 00 00 04 3c 14 00 09 11 09 ....#.....<..... 4010056 c1 c3 09 c0 b2 b2 0d df 0e 04 0e 38 0e 06 0c e5 ��.���.�...8...� 4010066 0d b0 0e 07 0e 1a 0c 5b 0e 28 0e 20 0d fa 0e 37 .�.....[.(. .�.7 4010076 0e 2c 0e 2d 12 0b 4e 56 44 41 2c 50 61 72 65 6e .,.-..NVDA,Paren 4010086 74 02 01 a6 01 11 12 0e 23 61 64 64 72 65 73 73 t..�....#address
That sure looks like Fcode for an nvidia card.
Looks like trouble when Openbios tries to build the device up in Name Space?
The code had just created an array property of some kind, maybe the "reg" property (if you looked back, you could probably figure out what it was). It looks like the next thing it's going to do is deal with some nvidia-specific features.
Either way, try "words" to see if it got around to doing any definitions. Also, since it blew up, at that point it's worth doing the "dev /pci ls" and see what got created.
Yes, trying to get PCI Passthough working for an Apple OEM nVidia 6600 PCI-E card, on a x86 host in Qemu-PPC. Fcode looks like: (unnamed-fcode) [0xe34] 25615: (unnamed-fcode) [0xdff] 25616: (unnamed-fcode) [0x93d] 25617: b(lit) ( 0x010 ) 0xf 25618: <> ( 0x03d ) 25619: b?branch ( 0x014 ) 0x0026 ( =dec 38) 25620: (unnamed-fcode) [0x9bd] 25621: b(lit) ( 0x010 ) 0xff 25622: and ( 0x023 ) 25623: my-space ( 0x103 ) 25624: + ( 0x01e ) 25625: (unnamed-fcode) [0xa08] 25626: b(lit) ( 0x010 ) 0x6 25627: and ( 0x023 ) 25628: b(lit) ( 0x010 ) 0x4 25629: = ( 0x03c ) 25630: b?branch ( 0x014 ) 0x0009 () 25631: b(') ( 0x011 ) (unnamed-fcode) [0x9c1] 25632: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9c0] 25633: b(>resolve) ( 0x0b2 ) 25634: b(>resolve) ( 0x0b2 ) 25635: (unnamed-fcode) [0xddf] 25636: (unnamed-fcode) [0xe04] 25637: (unnamed-fcode) [0xe38] 25638: (unnamed-fcode) [0xe06] 25639: (unnamed-fcode) [0xce5] 25640: (unnamed-fcode) [0xdb0] 25641: (unnamed-fcode) [0xe07] 25642: (unnamed-fcode) [0xe1a] 25643: (unnamed-fcode) [0xc5b] 25644: (unnamed-fcode) [0xe28] 25645: (unnamed-fcode) [0xe20] 25646: (unnamed-fcode) [0xdfa] 25647: (unnamed-fcode) [0xe37] 25648: (unnamed-fcode) [0xe2c] 25649: (unnamed-fcode) [0xe2d] 25650: b(") ( 0x012 ) ( len=0xb [11 bytes] ) " NVDA,Parent" 25651: device-name ( 0x201 ) 25652: 1 ( 0x0a6 ) 25653: encode-int ( 0x111 ) 25654: b(") ( 0x012 ) ( len=0xe [14 bytes] ) " #address-cells" 25655: property ( 0x110 ) 25656: 0 ( 0x0a5 ) 25657: encode-int ( 0x111 ) 25658: b(") ( 0x012 ) ( len=0xb [11 bytes] ) " #size-cells" 25659: property ( 0x110 ) 25660: (unnamed-fcode) [0x9c7] 25661: (unnamed-fcode) [0x93d] 25662: b(lit) ( 0x010 ) 0x35 25663: >= ( 0x042 ) 25664: b?branch ( 0x014 ) 0x000d ( =dec 13) 25665: 1 ( 0x0a6 ) 25666: (unnamed-fcode) [0x933] 25667: lshift ( 0x027 ) 25668: (unnamed-fcode) [0x935] 25669: or ( 0x024 ) 25670: b(to) ( 0x0c3 ) (unnamed-fcode) [0x935] 25671: b(>resolve) ( 0x0b2 ) 25672: (unnamed-fcode) [0x941] 25673: b(lit) ( 0x010 ) 0x10 25674: lshift ( 0x027 ) 25675: (unnamed-fcode) [0x935] 25676: or ( 0x024 ) 25677: encode-int ( 0x111 ) 25678: b(") ( 0x012 ) ( len=0xd [13 bytes] ) " NVDA,Features" 25679: property ( 0x110 ) 25680: 1 ( 0x0a6 ) 25681: encode-int ( 0x111 ) 25682: b(") ( 0x012 ) ( len=0xa [10 bytes] ) " NVDA,Level" 25683: property ( 0x110 ) 25684: 0 ( 0x0a5 ) 25685: 0 ( 0x0a5 ) 25686: (unnamed-fcode) [0xe2e] 25687: (unnamed-fcode) [0x9bc] 25688: (unnamed-fcode) [0x9c3] 25689: (unnamed-fcode) [0xe2e] 25690: encode+ ( 0x112 ) 25691: (unnamed-fcode) [0x9c0] 25692: (unnamed-fcode) [0x9c6] 25693: (unnamed-fcode) [0xe2e] 25694: encode+ ( 0x112 ) 25695: (unnamed-fcode) [0x9be] 25696: (unnamed-fcode) [0x9c4] 25697: (unnamed-fcode) [0xe2e] 25698: encode+ ( 0x112 ) 25699: (unnamed-fcode) [0x9bf] 25700: (unnamed-fcode) [0x9c5] 25701: (unnamed-fcode) [0xe2e] 25702: encode+ ( 0x112 ) 25703: b(") ( 0x012 ) ( len=3 ) " reg" 25704: property ( 0x110 ) 25705: 1 ( 0x0a6 ) 25706: encode-int ( 0x111 ) 25707: b(") ( 0x012 ) ( len=0xe [14 bytes] ) " #address-cells" 25708: property ( 0x110 ) 25709: 0 ( 0x0a5 ) 25710: encode-int ( 0x111 ) 25711: b(") ( 0x012 ) ( len=0xb [11 bytes] ) At the point where it breaks. On Sunday, December 17, 2017, 11:41:55 AM EST, Tarl Neustaedter tarl-b2@tarl.net wrote:
On 2017-Dec-17 11:29 , Jd Lyons wrote:
0 > 4010026 400 dump 4010026 c3 09 a9 0e 34 0d ff 09 3d 10 00 00 00 0f 3d 14 �.�.4.�.=.....=. 4010036 00 26 09 bd 10 00 00 00 ff 23 01 03 1e 0a 08 10 .&.�....�#...... 4010046 00 00 00 06 23 10 00 00 00 04 3c 14 00 09 11 09 ....#.....<..... 4010056 c1 c3 09 c0 b2 b2 0d df 0e 04 0e 38 0e 06 0c e5 ��.���.�...8...� 4010066 0d b0 0e 07 0e 1a 0c 5b 0e 28 0e 20 0d fa 0e 37 .�.....[.(. .�.7 4010076 0e 2c 0e 2d 12 0b 4e 56 44 41 2c 50 61 72 65 6e .,.-..NVDA,Paren 4010086 74 02 01 a6 01 11 12 0e 23 61 64 64 72 65 73 73 t..�....#address
That sure looks like Fcode for an nvidia card.
Looks like trouble when Openbios tries to build the device up in Name Space?
The code had just created an array property of some kind, maybe the "reg" property (if you looked back, you could probably figure out what it was). It looks like the next thing it's going to do is deal with some nvidia-specific features.
Either way, try "words" to see if it got around to doing any definitions. Also, since it blew up, at that point it's worth doing the "dev /pci ls" and see what got created.
On 2017-Dec-17 11:47 , Jd Lyons wrote:
Yes, trying to get PCI Passthough working for an Apple OEM nVidia 6600 PCI-E card, on a x86 host in Qemu-PPC.
Oh, crud. It's likely you're tripping over some code created specifically for the Apple due to Apple's implementation being defective. I remember this caused many pci card vendors to create vendor-specific FCodes for their cards, when Apple decided to not fix the bug in their FCode interpretation. That made it incompatible with other vendors. I don't remember what the bug was, I retired a couple of years ago, but we'd periodically run into someone with a PCI card that didn't work, find out it was supposed to be for an Apple, and they'd have to get new FCode for their card.
Nvidia considered their FCode highly proprietary, so you won't be able to get ahold of the source for it. At Sun/Oracle, we had a copy of their source under a protected tree, which was only available to a limited number of engineers who had signed non-disclosure agreements with them. So unfortunately, you aren't likely to be able to get a copy of their source to debug this.
It looks like it got far enough to create the basic properties in the tree where it's going to start mapping the card into your virtual address space (that's what usually follows creating the reg and address-cells properties). It's worth dumping out the device tree to see what got created - I see multiple creations of the "#address-cells" property, which suggests it might have created multiple nodes (you generally don't want to create the same property twice).
On Sun, Dec 17, 2017 at 11:59:04AM -0500, Tarl Neustaedter wrote:
On 2017-Dec-17 11:47 , Jd Lyons wrote:
Yes, trying to get PCI Passthough working for an Apple OEM nVidia 6600 PCI-E card, on a x86 host in Qemu-PPC.
Oh, crud. It's likely you're tripping over some code created specifically for the Apple due to Apple's implementation being defective. I remember this caused many pci card vendors to create vendor-specific FCodes for their cards, when Apple decided to not fix the bug in their FCode interpretation. That made it incompatible with other vendors. I don't remember what the bug was, I retired a couple of years ago, but we'd periodically run into someone with a PCI card that didn't work, find out it was supposed to be for an Apple, and they'd have to get new FCode for their card.
Nvidia considered their FCode highly proprietary, so you won't be able to get ahold of the source for it. At Sun/Oracle, we had a copy of their source under a protected tree, which was only available to a limited number of engineers who had signed non-disclosure agreements with them. So unfortunately, you aren't likely to be able to get a copy of their source to debug this.
It looks like it got far enough to create the basic properties in the tree where it's going to start mapping the card into your virtual address space (that's what usually follows creating the reg and address-cells properties). It's worth dumping out the device tree to see what got created - I see multiple creations of the "#address-cells" property, which suggests it might have created multiple nodes (you generally don't want to create the same property twice).
Apple has a bunch of extra FCodes for local variables, etc. The really big thing though is that quite a lot of FCode drivers were only tested on one implementation, and depends on peculiarities of that implementation.
But, in this case it looks like the loader code itself is crashing, so there is hope left.
Segher
These are the properties I noticed made:
NVDA,Parent #address-cells #size-cells NVDA,Features NVDA,Level reg
For some reason the #address-cells property is made twice.
Are you able to dump all the properties from the card and send it to us? There are many ways to do this. I think taking a picture of the screen with a phone might be the easiest way. There might be some kind of terminal program that does it as well. Not sure though.