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