Meanwhile qemu-system-sparc is good enough to boot most Solaris versions with OBP. ( http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html )
I'm trying to find out what is missing in OpenBIOS to do the same. Currently the boot just hangs. I did a wild guess: $ strings sun4m/ufsboot ... ['] find-device catch if 2drop true else current-device device-end then swap l! ...
It looks like all the keywords are known to the OpenBIOS, but I can't input the test string: " /options" ['] find-device catch if 2drop true else current-device device-end then swap l!
it is longer than 80 characters, and OpenBIOS lets me enter only the part of the string up to "device-end t".
The questions are: - is it just an interactive command line limitation, or an api limitation? - where is it defined? I couldn't find anything useful with grep -r 80 . - is there a forth debugger in OpenBIOS?
Artyom Tarasenko wrote:
Hi Artyom,
Meanwhile qemu-system-sparc is good enough to boot most Solaris versions with OBP. ( http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html )
Great to have you working on OpenBIOS - the story on your blog of getting Solaris to boot with OBP has been really fascinating.
I'm trying to find out what is missing in OpenBIOS to do the same. Currently the boot just hangs. I did a wild guess: $ strings sun4m/ufsboot ... ['] find-device catch if 2drop true else current-device device-end then swap l! ...
It looks like all the keywords are known to the OpenBIOS, but I can't input the test string: " /options" ['] find-device catch if 2drop true else current-device device-end then swap l!
it is longer than 80 characters, and OpenBIOS lets me enter only the part of the string up to "device-end t".
You should be able to split the above test string at any whitespace character, since the Forth engine handles the switch between word interpreting/compiling automatically. All whitespace, including CRs/LFs is generally ignored.
The questions are:
- is it just an interactive command line limitation, or an api limitation?
I suspect just an interactive command limitation.
- where is it defined? I couldn't find anything useful with grep -r 80 .
Possibly you can find the answer in libopenbios/console_common.c?
- is there a forth debugger in OpenBIOS?
Yes indeed. See Documentation/README.debugger for a quick overview.
HTH,
Mark.
Hi Mark,
Meanwhile qemu-system-sparc is good enough to boot most Solaris versions with OBP. ( http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html )
Great to have you working on OpenBIOS - the story on your blog of getting Solaris to boot with OBP has been really fascinating.
Thanks. But I think my success was partly a pure luck, and partly a lack of interest in launching Solaris from more experienced people and then again a luck of getting these experienced people on board. Anyone who had debugged Solaris kernel on a real hardware would have probably achieved in hours the things for which I needed months. Basically Mitch Bradley proved this by going all the chain from what looked like a scsi-disk bug to finding a cpu math bug within just one day.
But overall the idea of using OBP to find bugs in qemu was good. After we fixed qemu-sparc, you guys have more solid base to improve OpenBIOS. Having two suspects for bugs is always worse than one.
I'm trying to find out what is missing in OpenBIOS to do the same. Currently the boot just hangs. I did a wild guess: $ strings sun4m/ufsboot ... ['] find-device catch if 2drop true else current-device device-end then swap l! ...
It looks like all the keywords are known to the OpenBIOS, but I can't input the test string: " /options" ['] find-device catch if 2drop true else current-device device-end then swap l!
it is longer than 80 characters, and OpenBIOS lets me enter only the part of the string up to "device-end t".
You should be able to split the above test string at any whitespace character, since the Forth engine handles the switch between word interpreting/compiling automatically. All whitespace, including CRs/LFs is generally ignored.
The questions are: - is it just an interactive command line limitation, or an api limitation?
I suspect just an interactive command limitation.
Doesn't look like this: I patched ufsboot by replacing space character with 0x0a and now it gets a bit further!
2010/3/28 Artyom Tarasenko atar4qemu@googlemail.com:
Hi Mark,
Meanwhile qemu-system-sparc is good enough to boot most Solaris versions with OBP. ( http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html )
Great to have you working on OpenBIOS - the story on your blog of getting Solaris to boot with OBP has been really fascinating.
Thanks. But I think my success was partly a pure luck, and partly a lack of interest in launching Solaris from more experienced people and then again a luck of getting these experienced people on board. Anyone who had debugged Solaris kernel on a real hardware would have probably achieved in hours the things for which I needed months. Basically Mitch Bradley proved this by going all the chain from what looked like a scsi-disk bug to finding a cpu math bug within just one day.
But overall the idea of using OBP to find bugs in qemu was good. After we fixed qemu-sparc, you guys have more solid base to improve OpenBIOS. Having two suspects for bugs is always worse than one.
I'm trying to find out what is missing in OpenBIOS to do the same. Currently the boot just hangs. I did a wild guess: $ strings sun4m/ufsboot ... ['] find-device catch if 2drop true else current-device device-end then swap l! ...
It looks like all the keywords are known to the OpenBIOS, but I can't input the test string: " /options" ['] find-device catch if 2drop true else current-device device-end then swap l!
it is longer than 80 characters, and OpenBIOS lets me enter only the part of the string up to "device-end t".
You should be able to split the above test string at any whitespace character, since the Forth engine handles the switch between word interpreting/compiling automatically. All whitespace, including CRs/LFs is generally ignored.
The questions are: - is it just an interactive command line limitation, or an api limitation?
I suspect just an interactive command limitation.
Doesn't look like this: I patched ufsboot by replacing space character with 0x0a and now it gets a bit further!
is there a forth debugger in OpenBIOS?
Yes indeed. See Documentation/README.debugger for a quick overview.
Ok, now that I've got through the first Forth problem, the next question is if there is an assembler/machine code debugger too?
Artyom Tarasenko wrote:
Ok, now that I've got through the first Forth problem, the next question is if there is an assembler/machine code debugger too?
No, not built-in. However it's very easy to use qemu in conjunction with the -S and -s command line options to attach a cross-gdb to your virtual machine. In fact, using this approach in conjunction with the unstripped OpenBIOS image makes it possible to insert breakpoints into the C sections of OpenBIOS and step through as required.
See my post from the archives here: http://lists.openbios.org/pipermail/openbios/2009-January/003418.html for more detail on how I managed it for SPARC64.
HTH,
Mark.
It looks like all the keywords are known to the OpenBIOS, but I can't input the test string: " /options" ['] find-device catch if 2drop true else current-device device-end then swap l!
The above executed at the command line will get you in trouble - it's expecting arguments on the stack you don't have.
" /options" ['] find-device catch
This finds the "/options" node in the device tree and makes it the active device context. The top argument on the stack will tell you whether find-device caused a problem (aborted).
if 2drop true else current-device device-end then
The above says to drop two arguments from the stack (hopefully the string "/options") if find-device aborted, otherwise get the phandle of "/options" and put it on the stack. The device-end destroys the device context of /options. I'm not sure why this code does this, a simpler way would have been to simply call find-package, which doesn't set your device context in the first place.
swap l!
The above depends on something else being on the stack, telling you where to store the /options phandle.
2010/3/23 Tarl Neustaedter Tarl.Neustaedter@sun.com:
It looks like all the keywords are known to the OpenBIOS, but I can't input the test string: " /options" ['] find-device catch if 2drop true else current-device device-end then swap l!
The above executed at the command line will get you in trouble - it's expecting arguments on the stack you don't have.
Yes, thanks. Probably would have noticed stack underflow if I were able to execute the command as-is. My point was the limit of the command line length.
" /options" ['] find-device catch
This finds the "/options" node in the device tree and makes it the active device context. The top argument on the stack will tell you whether find-device caused a problem (aborted).
if 2drop true else current-device device-end then
The above says to drop two arguments from the stack (hopefully the string "/options") if find-device aborted, otherwise get the phandle of "/options" and put it on the stack. The device-end destroys the device context of /options. I'm not sure why this code does this, a simpler way would have been to simply call find-package, which doesn't set your device context in the first place.
Maybe the earlier versions of OBP didn't have find-package or it was buggy?
-
Artyom Tarasenko -
Mark Cave-Ayland -
Tarl Neustaedter