input length

[Artyom Tarasenko]

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?

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu progress: http://tyom.blogspot.com/

[Mark Cave-Ayland]

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.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: [phone]

Sirius Labs: http://www.siriusit.co.uk/labs

[Artyom Tarasenko]

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!

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/

[Artyom Tarasenko]

2010/3/28 Artyom Tarasenko <atar4qemu(a)googlemail.com>om>:
  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?


-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/

[Mark Cave-Ayland]

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.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: [phone]

Sirius Labs: http://www.siriusit.co.uk/labs

[Tarl Neustaedter]

  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.

[Artyom Tarasenko]

2010/3/23 Tarl Neustaedter <Tarl.Neustaedter(a)sun.com>om>:
 

  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?

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/