.properties before: someproperty -- 3 : 1 42 3 Now: someproperty -- 3 : 01 42 03 Signed-off-by: Andreas Färber <andreas.faerber@web.de> --- forth/admin/devices.fs | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index e24c6da..dbb4646 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -283,7 +283,7 @@ dup r@ + c@ ( len n ch ) - pocket tohexstr type ." " + pocket tohexstr dup 2 <> if ." 0" then type ." " 1+ repeat 2drop r> drop 1 -- 1.7.3
Executing .properties for, e.g., the /memory node would print the "reg" property as a series of bytes. Modify the .properties and (.property) words to special-case property display based on property name. Visualize the "reg" format as a table. Signed-off-by: Andreas Färber <andreas.faerber@web.de> --- Hello, This prettification was tested for qemu-ppc (#address-cells == 1 && #size-cells == 1) with a local patch to fix the /memory reg property (uses 2 cells currently). Is it permissible to modify the (.property) "signature" in this way? Regards, Andreas forth/admin/devices.fs | 34 +++++++++++++++++++++++++++++++--- 1 files changed, 31 insertions(+), 3 deletions(-) diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index dbb4646..4c72cbb 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -289,9 +289,37 @@ 2drop r> drop 1 ; +\ TODO honor #address-cells and #size-cells +: (.p-reg) ( data len -- ) + swap >r 0 + begin 2dup > while + dup r@ + c@ + ( len n ch ) + pocket tohexstr dup 2 <> if ." 0" then type + 1+ + dup 8 mod 4 = if + ." " + then + dup 8 mod 0 = if + 2dup <> if + cr 0 begin ." " 1+ dup d# 26 >= until drop + then + then + repeat + 2drop r> drop +; + \ this function tries to heuristically determine the data format -: (.property) ( data len -- ) - dup 0= if 2drop ." <empty>" exit then +: (.property) ( name-str name-len data len -- ) + dup 0= if 2drop 2drop ." <empty>" exit then + + 2over + ( name-str name-len data len name-str name-len ) + s" reg" strcmp 0= if (.p-reg) 2drop exit then + ( name-str name-len data len ) + \ TODO this should be limited to /memory device + 2swap s" available" strcmp 0= if (.p-reg) exit then + ( data len ) .p-string? if exit then .p-int? if exit then @@ -307,7 +335,7 @@ while cr 2dup dup -rot type begin ." " 1+ dup d# 26 >= until drop - 2dup active-package get-package-property drop (.property) + 2dup 2dup active-package get-package-property drop (.property) repeat then r> drop -- 1.7.3
Thanks, applied. On Mon, Oct 4, 2010 at 8:08 PM, Andreas Färber <andreas.faerber@web.de> wrote:
.properties before: someproperty -- 3 : 1 42 3
Now: someproperty -- 3 : 01 42 03
Signed-off-by: Andreas Färber <andreas.faerber@web.de> --- forth/admin/devices.fs | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index e24c6da..dbb4646 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -283,7 +283,7 @@ dup r@ + c@ ( len n ch )
- pocket tohexstr type ." " + pocket tohexstr dup 2 <> if ." 0" then type ." " 1+ repeat 2drop r> drop 1 -- 1.7.3
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
v2: * Use my-#acells for address size. * Introduce my-#scells for size size. * Confine special-handling of "available" to /memory and MMU. --- Hi, How can we determine the cell size within Forth? 64bit? wouldn't work as criteria for ppc64. Is an explicit [IFDEF] CONFIG_{SPARC64,PPC64} the only way here? Thanks, Andreas arch/ppc/qemu/init.c | 14 +++++++++----- forth/admin/devices.fs | 40 +++++++++++++++++++++++++++++++++------- forth/device/property.fs | 16 +++++++++++++++- 3 files changed, 57 insertions(+), 13 deletions(-) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 08eb59c..d7ebc15 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -774,15 +774,19 @@ arch_of_init( void ) /* all memory */ - PUSH(ram_size >> 32); - fword("encode-int"); - PUSH(ram_size & 0xffffffff); - fword("encode-int"); + PUSH(0); + fword("encode-phys"); +#if 0 fword("encode+"); PUSH(0); fword("encode-int"); fword("encode+"); - PUSH(0); +#endif +#if 0 + PUSH(ram_size >> 32); + fword("encode-int"); +#endif + PUSH(ram_size & 0xffffffff); fword("encode-int"); fword("encode+"); push_str("reg"); diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index 4c72cbb..6662a7e 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -289,18 +289,27 @@ 2drop r> drop 1 ; -\ TODO honor #address-cells and #size-cells -: (.p-reg) ( data len -- ) +\ Helpers: Convert number of cells into number of bytes +\ TODO honor cell size, currently assumes 4 (wrong for sparc64) +: my-#acellbytes ( -- #bytes) + my-#acells 4 * +; + +: my-#scellbytes ( -- #bytes) + my-#scells 4 * +; + +: .p-reg ( data len -- ) swap >r 0 begin 2dup > while dup r@ + c@ ( len n ch ) pocket tohexstr dup 2 <> if ." 0" then type 1+ - dup 8 mod 4 = if + dup my-#acellbytes my-#scellbytes + mod my-#acellbytes = if ." " then - dup 8 mod 0 = if + dup my-#acellbytes my-#scellbytes + mod 0= if 2dup <> if cr 0 begin ." " 1+ dup d# 26 >= until drop then @@ -315,10 +324,27 @@ 2over ( name-str name-len data len name-str name-len ) - s" reg" strcmp 0= if (.p-reg) 2drop exit then + " reg" strcmp 0= if .p-reg 2drop exit then + ( name-str name-len data len ) + " name" active-package get-package-property 0= if + drop + ( name-str name-len data len prop-name ) + " memory" comp0 0= if + 2over + " available" strcmp 0= if .p-reg 2drop exit then + then + then + ( name-str name-len data len ) + " device_type" active-package get-package-property 0= if + drop + ( name-str name-len data len prop-name ) + " cpu" comp0 0= if + 2over + " available" strcmp 0= if .p-reg 2drop exit then + then + then ( name-str name-len data len ) - \ TODO this should be limited to /memory device - 2swap s" available" strcmp 0= if (.p-reg) exit then + 2swap 2drop ( data len ) .p-string? if exit then diff --git a/forth/device/property.fs b/forth/device/property.fs index 285113b..d0a46a0 100644 --- a/forth/device/property.fs +++ b/forth/device/property.fs @@ -143,7 +143,7 @@ then ; -\ HELPER: get #address-cell value (from parent) +\ HELPER: get #address-cells value (from parent) \ Legal values are 1..4 (we may optionally support longer addresses) : my-#acells ( -- #address-cells ) my-self ?dup if >in.device-node @ else active-package then @@ -157,6 +157,20 @@ then ; +\ HELPER: get #size-cells value (from parent) +\ Legal values are 1..4 (we may optionally support longer addresses) +: my-#scells ( -- #size-cells ) + my-self ?dup if >in.device-node @ else active-package then + ?dup if >dn.parent @ then + ?dup if + " #size-cells" rot get-package-property if 2 exit then + \ we don't have to support more than 4 (and 0 is illegal) + decode-int nip nip 4 min 1 max + else + 2 + then +; + : decode-string ( prop-addr1 prop-len1 -- prop-addr2 prop-len2 str len ) dup 0> if 2dup bounds \ check property for 0 bytes -- 1.7.3
Am 05.10.2010 um 01:22 schrieb Andreas Färber:
Executing .properties for, e.g., the /memory node would print the "reg" property as a series of bytes. Modify the .properties and (.property) words to special-case property display based on property name. Visualize the "reg" format as a table.
Signed-off-by: Andreas Färber <andreas.faerber@web.de> --- Hello,
This prettification was tested for qemu-ppc (#address-cells == 1 && #size-cells == 1) with a local patch to fix the /memory reg property (uses 2 cells currently).
Is it permissible to modify the (.property) "signature" in this way?
It seems it's not mentioned in IEEE 1275 or used elsewhere, so I guess it's okay. "dev mac-io .properties" on ppc is a test case for different cell counts btw. Andreas
Executing .properties for, e.g., the /memory node would print the "reg" property as a series of bytes. Modify the .properties and (.property) words to special-case property display based on property name. Visualize the "reg" format as a table. v2: * Use my-#acells for address size. * Introduce my-#scells for size size. * Confine special-handling of "available" to /memory and MMU. Signed-off-by: Andreas Färber <andreas.faerber@web.de> --- forth/admin/devices.fs | 60 +++++++++++++++++++++++++++++++++++++++++++-- forth/device/property.fs | 16 +++++++++++- 2 files changed, 72 insertions(+), 4 deletions(-) diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index dbb4646..6662a7e 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -289,9 +289,63 @@ 2drop r> drop 1 ; +\ Helpers: Convert number of cells into number of bytes +\ TODO honor cell size, currently assumes 4 (wrong for sparc64) +: my-#acellbytes ( -- #bytes) + my-#acells 4 * +; + +: my-#scellbytes ( -- #bytes) + my-#scells 4 * +; + +: .p-reg ( data len -- ) + swap >r 0 + begin 2dup > while + dup r@ + c@ + ( len n ch ) + pocket tohexstr dup 2 <> if ." 0" then type + 1+ + dup my-#acellbytes my-#scellbytes + mod my-#acellbytes = if + ." " + then + dup my-#acellbytes my-#scellbytes + mod 0= if + 2dup <> if + cr 0 begin ." " 1+ dup d# 26 >= until drop + then + then + repeat + 2drop r> drop +; + \ this function tries to heuristically determine the data format -: (.property) ( data len -- ) - dup 0= if 2drop ." <empty>" exit then +: (.property) ( name-str name-len data len -- ) + dup 0= if 2drop 2drop ." <empty>" exit then + + 2over + ( name-str name-len data len name-str name-len ) + " reg" strcmp 0= if .p-reg 2drop exit then + ( name-str name-len data len ) + " name" active-package get-package-property 0= if + drop + ( name-str name-len data len prop-name ) + " memory" comp0 0= if + 2over + " available" strcmp 0= if .p-reg 2drop exit then + then + then + ( name-str name-len data len ) + " device_type" active-package get-package-property 0= if + drop + ( name-str name-len data len prop-name ) + " cpu" comp0 0= if + 2over + " available" strcmp 0= if .p-reg 2drop exit then + then + then + ( name-str name-len data len ) + 2swap 2drop + ( data len ) .p-string? if exit then .p-int? if exit then @@ -307,7 +361,7 @@ while cr 2dup dup -rot type begin ." " 1+ dup d# 26 >= until drop - 2dup active-package get-package-property drop (.property) + 2dup 2dup active-package get-package-property drop (.property) repeat then r> drop diff --git a/forth/device/property.fs b/forth/device/property.fs index 285113b..d0a46a0 100644 --- a/forth/device/property.fs +++ b/forth/device/property.fs @@ -143,7 +143,7 @@ then ; -\ HELPER: get #address-cell value (from parent) +\ HELPER: get #address-cells value (from parent) \ Legal values are 1..4 (we may optionally support longer addresses) : my-#acells ( -- #address-cells ) my-self ?dup if >in.device-node @ else active-package then @@ -157,6 +157,20 @@ then ; +\ HELPER: get #size-cells value (from parent) +\ Legal values are 1..4 (we may optionally support longer addresses) +: my-#scells ( -- #size-cells ) + my-self ?dup if >in.device-node @ else active-package then + ?dup if >dn.parent @ then + ?dup if + " #size-cells" rot get-package-property if 2 exit then + \ we don't have to support more than 4 (and 0 is illegal) + decode-int nip nip 4 min 1 max + else + 2 + then +; + : decode-string ( prop-addr1 prop-len1 -- prop-addr2 prop-len2 str len ) dup 0> if 2dup bounds \ check property for 0 bytes -- 1.7.3
Am 04.11.2010 um 01:25 schrieb Andreas Färber:
v2: * Use my-#acells for address size. * Introduce my-#scells for size size. * Confine special-handling of "available" to /memory and MMU. --- Hi,
How can we determine the cell size within Forth?
64bit? wouldn't work as criteria for ppc64. Is an explicit [IFDEF] CONFIG_{SPARC64,PPC64} the only way here?
Thanks, Andreas
arch/ppc/qemu/init.c | 14 +++++++++----- forth/admin/devices.fs | 40 ++++++++++++++++++++++++++++++++ +------- forth/device/property.fs | 16 +++++++++++++++- 3 files changed, 57 insertions(+), 13 deletions(-)
Sorry, too tired... I merged the wrong patches. Above question still applies to the v2 "Pretty-print reg property" though! Below is my obviously-to-be-cleaned-up fix for the ppc /memory reg property, which my other patch pretty-prints to properly debug such issues. ;) Andreas
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 08eb59c..d7ebc15 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -774,15 +774,19 @@ arch_of_init( void )
/* all memory */
- PUSH(ram_size >> 32); - fword("encode-int"); - PUSH(ram_size & 0xffffffff); - fword("encode-int"); + PUSH(0); + fword("encode-phys"); +#if 0 fword("encode+"); PUSH(0); fword("encode-int"); fword("encode+"); - PUSH(0); +#endif +#if 0 + PUSH(ram_size >> 32); + fword("encode-int"); +#endif + PUSH(ram_size & 0xffffffff); fword("encode-int"); fword("encode+"); push_str("reg");
+\ Helpers: Convert number of cells into number of bytes +\ TODO honor cell size, currently assumes 4 (wrong for sparc64) +: my-#acellbytes ( -- #bytes) + my-#acells 4 * +;
Device tree property "cells" aren't Forth cells; that's why the documentation always talks about "integer as encoded with encode-int", i.e., four bytes big-endian twos' complement.
+: .p-reg ( data len -- ) + swap >r 0 + begin 2dup > while + dup r@ + c@ + ( len n ch ) + pocket tohexstr dup 2 <> if ." 0" then type
: 0.r ( u minlen -- ) 0 swap <# 1 ?DO # LOOP #s #> type ; and then you can use here: 2 0.r
+ 1+ + dup my-#acellbytes my-#scellbytes + mod my-#acellbytes = if
It is very expensive to use the tree queries in the loop.
+ ." " + then + dup my-#acellbytes my-#scellbytes + mod 0= if + 2dup <> if + cr 0 begin ." " 1+ dup d# 26 >= until drop
26? Why that?
+ then + then + repeat + 2drop r> drop +;
Maybe something like this: : .p-reg ( prop len -- )
r >r my-#scells my-#acells dup r> r> bounds ?DO 2dup = IF cr THEN \ start of line dup 0= IF 2 spaces THEN \ start of "size" part dup 3 and 0= IF space THEN \ make numbers more readable i c@ 2 0.r \ print byte 1- 3dup nip + 0= IF drop dup THEN \ update counter LOOP ;
(untested, mind the bogons).
+\ HELPER: get #size-cells value (from parent) +\ Legal values are 1..4 (we may optionally support longer addresses) +: my-#scells ( -- #size-cells ) + my-self ?dup if >in.device-node @ else active-package then + ?dup if >dn.parent @ then + ?dup if + " #size-cells" rot get-package-property if 2 exit then + \ we don't have to support more than 4 (and 0 is illegal) + decode-int nip nip 4 min 1 max + else + 2 + then +;
Default for #size-cells is 1, not 2. Segher
Am 04.11.2010 um 05:05 schrieb Segher Boessenkool:
+\ Helpers: Convert number of cells into number of bytes +\ TODO honor cell size, currently assumes 4 (wrong for sparc64) +: my-#acellbytes ( -- #bytes) + my-#acells 4 * +;
Device tree property "cells" aren't Forth cells; that's why the documentation always talks about "integer as encoded with encode-int", i.e., four bytes big-endian twos' complement.
Thanks for clarifying.
+: .p-reg ( data len -- ) + swap >r 0 + begin 2dup > while + dup r@ + c@ + ( len n ch ) + pocket tohexstr dup 2 <> if ." 0" then type
: 0.r ( u minlen -- ) 0 swap <# 1 ?DO # LOOP #s #> type ; and then you can use here: 2 0.r
+ 1+ + dup my-#acellbytes my-#scellbytes + mod my-#acellbytes = if
It is very expensive to use the tree queries in the loop.
+ ." " + then + dup my-#acellbytes my-#scellbytes + mod 0= if + 2dup <> if + cr 0 begin ." " 1+ dup d# 26 >= until drop
26? Why that?
Indentation of non-first line, adapted from .properties.
+ then + then + repeat + 2drop r> drop +;
Maybe something like this:
: .p-reg ( prop len -- )
r >r my-#scells my-#acells dup r> r> bounds ?DO 2dup = IF cr THEN \ start of line dup 0= IF 2 spaces THEN \ start of "size" part dup 3 and 0= IF space THEN \ make numbers more readable i c@ 2 0.r \ print byte 1- 3dup nip + 0= IF drop dup THEN \ update counter LOOP ;
(untested, mind the bogons).
Leads to: 0 > dev /memory ok 0 > .properties name "memory" device_type "memory" reg 00 00 00 00 40 00 00 00 N?!H -- 5 : 4e 80 04 21 48 available 00 00 40 00 3f bd 40 00 <empty> ok My patch did: 0 > dev /memory ok 0 > .properties name "memory" device_type "memory" reg 00000000 40000000 available 00004000 3fbd4000 ok Any hint? My code may have been inefficient but better unstandable for a Forth newbie...
+\ HELPER: get #size-cells value (from parent) +\ Legal values are 1..4 (we may optionally support longer addresses) +: my-#scells ( -- #size-cells ) + my-self ?dup if >in.device-node @ else active-package then + ?dup if >dn.parent @ then + ?dup if + " #size-cells" rot get-package-property if 2 exit then + \ we don't have to support more than 4 (and 0 is illegal) + decode-int nip nip 4 min 1 max + else + 2 + then +;
Default for #size-cells is 1, not 2.
Copied from my-#acells. Is it wrong for #address-cells, too? Andreas
+ dup my-#acellbytes my-#scellbytes + mod 0= if + 2dup <> if + cr 0 begin ." " 1+ dup d# 26 >= until drop
26? Why that?
Indentation of non-first line, adapted from .properties.
Ah I see.
Maybe something like this:
: .p-reg ( prop len -- )
r >r my-#scells my-#acells dup r> r> bounds ?DO 2dup = IF cr THEN \ start of line dup 0= IF 2 spaces THEN \ start of "size" part dup 3 and 0= IF space THEN \ make numbers more readable i c@ 2 0.r \ print byte 1- 3dup nip + 0= IF drop dup THEN \ update counter LOOP ;
(untested, mind the bogons).
Leads to:
0 > dev /memory ok 0 > .properties name "memory" device_type "memory" reg 00 00 00 00 40 00 00 00 N?!H -- 5 : 4e 80 04 21 48 available 00 00 40 00 3f bd 40 00 <empty> ok
My patch did:
0 > dev /memory ok 0 > .properties name "memory" device_type "memory" reg 00000000 40000000 available 00004000 3fbd4000 ok
Any hint? My code may have been inefficient but better unstandable for a Forth newbie...
I found it quite the opposite -- I'm not a newbie but I found it very hard to read. Maybe needs a bit more factoring? I forgot to multiply acells and scells by 4; also, no indent, and I put the newlines at the start of the line, not the end (this is normal in Forth, and has some advantages). This needs changing here of course.
Default for #size-cells is 1, not 2.
Copied from my-#acells. Is it wrong for #address-cells, too?
It is correct for acells. Segher
Am 04.11.2010 um 23:16 schrieb Segher Boessenkool:
Maybe something like this:
: .p-reg ( prop len -- )
r >r my-#scells my-#acells dup r> r> bounds ?DO 2dup = IF cr THEN \ start of line dup 0= IF 2 spaces THEN \ start of "size" part dup 3 and 0= IF space THEN \ make numbers more readable i c@ 2 0.r \ print byte 1- 3dup nip + 0= IF drop dup THEN \ update counter LOOP ;
(untested, mind the bogons).
Leads to:
0 > dev /memory ok 0 > .properties name "memory" device_type "memory" reg 00 00 00 00 40 00 00 00 N?!H -- 5 : 4e 80 04 21 48 available 00 00 40 00 3f bd 40 00 <empty> ok
My patch did:
0 > dev /memory ok 0 > .properties name "memory" device_type "memory" reg 00000000 40000000 available 00004000 3fbd4000 ok
Any hint? My code may have been inefficient but better unstandable for a Forth newbie...
I found it quite the opposite -- I'm not a newbie but I found it very hard to read. Maybe needs a bit more factoring?
I forgot to multiply acells and scells by 4; also, no indent, and I put the newlines at the start of the line, not the end (this is normal in Forth, and has some advantages). This needs changing here of course.
Figured that out myself in the meantime, also the 3drop after some trial and error: : .p-reg ( data len -- )
r >r my-#scells 4 * my-#acells 4 * dup r> r> ( #sbytes #abytes #abytes data len ) bounds ( #sbytes #abytes #abytes data+len data ) ?do \ 2dup = if cr then \ start of line dup 0= if 2 spaces then \ start of "size" part 2dup <> if dup 3 and 0= if space then \ make numbers more readable then i c@ 2 0.r \ print byte 1- 3dup nip + 0= if cr 0 begin ." " 1+ dup d# 26 >= until drop drop dup \ update counter then loop 3drop ;
This also fixes a leading space. Thanks a lot for your review and suggestions, I'll put together a patch series tomorrow. Andreas
Am 04.11.2010 um 23:16 schrieb Segher Boessenkool:
My code may have been inefficient but better unstandable for a Forth newbie...
I found it quite the opposite -- I'm not a newbie but I found it very hard to read. Maybe needs a bit more factoring?
Yeah, my problem in particular was your use of a number of unknown-to- me words combined with a lack of inline stack diagrams. Starting with, Leo Brodie doesn't cover ?do, just do. It might've manipulated the stack, who knows. The `grep -r ": ?do" forth/` hit in OpenBIOS wasn't too helpful, and Google doesn't distinguish between "do" and "?do" so you get too many unrelated "do" hits. I got along by hoping it doesn't place anything on the stack. Similar issues for <# etc., still no clue there but it works. Do you happen to know a suitable reference for looking up the meaning of such words? Mind to explain your 0.r choice of name? What's the r for? Andreas
Yeah, my problem in particular was your use of a number of unknown-to-me words combined with a lack of inline stack diagrams. Starting with, Leo Brodie doesn't cover ?do, just do. It might've manipulated the stack, who knows. The `grep -r ": ?do" forth/` hit in OpenBIOS wasn't too helpful, and Google doesn't distinguish between "do" and "?do" so you get too many unrelated "do" hits. I got along by hoping it doesn't place anything on the stack. Similar issues for <# etc., still no clue there but it works. Do you happen to know a suitable reference for looking up the meaning of such words?
The IEEE 1275 spec describes anything you can use in this code. ?do doesn't start the loop if the limits won't allow it.
Yeah, my problem in particular was your use of a number of unknown-to- me words combined with a lack of inline stack diagrams. Starting with, Leo Brodie doesn't cover ?do, just do.
Do you happen to know a suitable reference for looking up the meaning of such words?
Have a look at http://forth.sourceforge.net/standard/dpans/
Mind to explain your 0.r choice of name? What's the r for?
There is a standard word .r ( n len -- ) that prints a number in a field at least len chars long, or as much as needed. My 0.r does the same, but fills to the left with zeroes instead of spaces. The "r" stands for "right(-aligned)" I believe. Segher
Introduce a 0.r word, suggested by Segher. Optimize r890 by using this helper. Cc: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Andreas Färber <andreas.faerber@web.de> --- Segher, mind adding your SoB for 0.r? Thanks. forth/admin/devices.fs | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index dbb4646..b48e2f1 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -276,6 +276,11 @@ . ; +\ Print a number zero-padded +: 0.r ( u minlen -- ) + 0 swap <# 1 ?do # loop #s #> type +; + : .p-bytes? ( data len -- 1 | data len 0 ) ." -- " dup . ." : " swap >r 0 @@ -283,7 +288,7 @@ dup r@ + c@ ( len n ch ) - pocket tohexstr dup 2 <> if ." 0" then type ." " + 2 0.r ." " 1+ repeat 2drop r> drop 1 -- 1.7.3
v3: * Preserve (.property) as heuristic function. Signed-off-by: Andreas Färber <andreas.faerber@web.de> --- forth/admin/devices.fs | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index b48e2f1..33ad0de 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -304,6 +304,12 @@ 2drop ." <unimplemented type>" ; +\ This function hardwires data formats to particular node properties +: (.property-by-name) ( name-str name-len data len -- ) + 2swap 2drop ( data len ) + (.property) +; + : .properties ( -- ) ?active-package dup >r if 0 0 @@ -312,7 +318,10 @@ while cr 2dup dup -rot type begin ." " 1+ dup d# 26 >= until drop - 2dup active-package get-package-property drop (.property) + 2dup + 2dup active-package get-package-property drop + ( name-str name-len data len ) + (.property-by-name) repeat then r> drop -- 1.7.3
Executing .properties for, e.g., the /memory node would print the "reg" property as a series of bytes. Visualize the "reg" format as a table. v3: * Optimization, based on code suggested by Segher. v2: * Use my-#acells for address size. * Introduce my-#scells for size size. Cc: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Andreas Färber <andreas.faerber@web.de> --- forth/admin/devices.fs | 24 ++++++++++++++++++++++++ forth/device/property.fs | 14 ++++++++++++++ 2 files changed, 38 insertions(+), 0 deletions(-) diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index 33ad0de..93f306c 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -304,8 +304,32 @@ 2drop ." <unimplemented type>" ; +\ Print the value of a property in "reg" format +: .p-reg ( data len -- ) + 2dup + -rot ( data+len data len ) + >r >r my-#scells 4 * my-#acells 4 * dup r> r> + ( data+len #sbytes #abytes #abytes data len ) + bounds ( data+len #sbytes #abytes #abytes data+len data ) ?do + dup 0= if 2 spaces then \ start of "size" part + 2dup <> if + dup 3 and 0= if space then \ make numbers more readable + then + i c@ 2 0.r \ print byte + 1- 3dup nip ( data+len #sbytes #abytes n #sbytes n ) + 0= if + 3 pick i 1+ > if + cr \ start new line + d# 26 spaces \ indentation + then + drop dup \ update counter + then + loop + 3drop drop +; + \ This function hardwires data formats to particular node properties : (.property-by-name) ( name-str name-len data len -- ) + 2over " reg" strcmp 0= if .p-reg 2drop exit then + 2swap 2drop ( data len ) (.property) ; diff --git a/forth/device/property.fs b/forth/device/property.fs index 285113b..fb529a5 100644 --- a/forth/device/property.fs +++ b/forth/device/property.fs @@ -157,6 +157,20 @@ then ; +\ HELPER: get #size-cells value (from parent) +\ Legal values are 1..4 (we may optionally support larger sizes) +: my-#scells ( -- #size-cells ) + my-self ?dup if >in.device-node @ else active-package then + ?dup if >dn.parent @ then + ?dup if + " #size-cells" rot get-package-property if 1 exit then + \ we don't have to support more than 4 (and 0 is illegal) + decode-int nip nip 4 min 1 max + else + 1 + then +; + : decode-string ( prop-addr1 prop-len1 -- prop-addr2 prop-len2 str len ) dup 0> if 2dup bounds \ check property for 0 bytes -- 1.7.3
v3: * Simplify condition. Signed-off-by: Andreas Färber <andreas.faerber@web.de> --- forth/admin/devices.fs | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index 93f306c..db7b48c 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -330,6 +330,10 @@ : (.property-by-name) ( name-str name-len data len -- ) 2over " reg" strcmp 0= if .p-reg 2drop exit then + active-package get-nodename " memory" strcmp 0= if + 2over " available" strcmp 0= if .p-reg 2drop exit then + then + 2swap 2drop ( data len ) (.property) ; -- 1.7.3
v3: * Evaluate /chosen mmu property rather than device_type "cpu". Signed-off-by: Andreas Färber <andreas.faerber@web.de> --- forth/admin/devices.fs | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index db7b48c..ecd2358 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -333,6 +333,13 @@ active-package get-nodename " memory" strcmp 0= if 2over " available" strcmp 0= if .p-reg 2drop exit then then + " /chosen" find-dev if + " mmu" rot get-package-property 0= if + decode-int nip nip ihandle>phandle active-package = if + 2over " available" strcmp 0= if .p-reg 2drop exit then + then + then + then 2swap 2drop ( data len ) (.property) -- 1.7.3
Am 05.11.2010 um 19:05 schrieb Tarl Neustaedter:
Do you happen to know a suitable reference for looking up the meaning of [...] words?
The IEEE 1275 spec describes anything you can use in this code.
Ouch, sometimes answers are right in front of your eye, where you least expect them... Thanks. Andreas
Introduce a 0.r word, suggested by Segher. Optimize r890 by using this helper.
Cc: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Andreas Färber <andreas.faerber@web.de> --- Segher, mind adding your SoB for 0.r? Thanks.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org> If you replace ." " by space , here's my Acked-by: Segher Boessenkool <segher@kernel.crashing.org> for the rest of the patch :-)
forth/admin/devices.fs | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index dbb4646..b48e2f1 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -276,6 +276,11 @@ . ;
+\ Print a number zero-padded +: 0.r ( u minlen -- ) + 0 swap <# 1 ?do # loop #s #> type +; + : .p-bytes? ( data len -- 1 | data len 0 ) ." -- " dup . ." : " swap >r 0 @@ -283,7 +288,7 @@ dup r@ + c@ ( len n ch )
- pocket tohexstr dup 2 <> if ." 0" then type ." " + 2 0.r ." " 1+ repeat 2drop r> drop 1 -- 1.7.3
Executing .properties for, e.g., the /memory node would print the "reg" property as a series of bytes.
Visualize the "reg" format as a table.
v3: * Optimization, based on code suggested by Segher.
v2: * Use my-#acells for address size. * Introduce my-#scells for size size.
Cc: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Andreas Färber <andreas.faerber@web.de>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org> (assuming you tested it :-) )
--- forth/admin/devices.fs | 24 ++++++++++++++++++++++++ forth/device/property.fs | 14 ++++++++++++++ 2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index 33ad0de..93f306c 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -304,8 +304,32 @@ 2drop ." <unimplemented type>" ;
+\ Print the value of a property in "reg" format +: .p-reg ( data len -- ) + 2dup + -rot ( data+len data len ) + >r >r my-#scells 4 * my-#acells 4 * dup r> r> + ( data+len #sbytes #abytes #abytes data len ) + bounds ( data+len #sbytes #abytes #abytes data+len data ) ?do + dup 0= if 2 spaces then \ start of "size" part + 2dup <> if + dup 3 and 0= if space then \ make numbers more readable + then + i c@ 2 0.r \ print byte + 1- 3dup nip ( data+len #sbytes #abytes n #sbytes n ) + 0= if + 3 pick i 1+ > if + cr \ start new line + d# 26 spaces \ indentation + then + drop dup \ update counter + then + loop + 3drop drop +; + \ This function hardwires data formats to particular node properties : (.property-by-name) ( name-str name-len data len -- ) + 2over " reg" strcmp 0= if .p-reg 2drop exit then + 2swap 2drop ( data len ) (.property) ; diff --git a/forth/device/property.fs b/forth/device/property.fs index 285113b..fb529a5 100644 --- a/forth/device/property.fs +++ b/forth/device/property.fs @@ -157,6 +157,20 @@ then ;
+\ HELPER: get #size-cells value (from parent) +\ Legal values are 1..4 (we may optionally support larger sizes) +: my-#scells ( -- #size-cells ) + my-self ?dup if >in.device-node @ else active-package then + ?dup if >dn.parent @ then + ?dup if + " #size-cells" rot get-package-property if 1 exit then + \ we don't have to support more than 4 (and 0 is illegal) + decode-int nip nip 4 min 1 max + else + 1 + then +; + : decode-string ( prop-addr1 prop-len1 -- prop-addr2 prop-len2 str len ) dup 0> if 2dup bounds \ check property for 0 bytes -- 1.7.3
Am 06.11.2010 um 01:19 schrieb Segher Boessenkool:
Introduce a 0.r word, suggested by Segher. Optimize r890 by using this helper.
Cc: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Andreas Färber <andreas.faerber@web.de> --- Segher, mind adding your SoB for 0.r? Thanks.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
If you replace ." " by space , here's my
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
for the rest of the patch :-)
Done, thanks, applied v4 as r946. Andreas
Am 06.11.2010 um 01:23 schrieb Segher Boessenkool:
Executing .properties for, e.g., the /memory node would print the "reg" property as a series of bytes.
Visualize the "reg" format as a table.
v3: * Optimization, based on code suggested by Segher.
v2: * Use my-#acells for address size. * Introduce my-#scells for size size.
Cc: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Andreas Färber <andreas.faerber@web.de>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
(assuming you tested it :-) )
I did, 1/1, 3/2 and now 1/0, all for ppc. It looks okay. But...
diff --git a/forth/device/property.fs b/forth/device/property.fs index 285113b..fb529a5 100644 --- a/forth/device/property.fs +++ b/forth/device/property.fs @@ -157,6 +157,20 @@ then ;
+\ HELPER: get #size-cells value (from parent) +\ Legal values are 1..4 (we may optionally support larger sizes) +: my-#scells ( -- #size-cells ) + my-self ?dup if >in.device-node @ else active-package then + ?dup if >dn.parent @ then + ?dup if + " #size-cells" rot get-package-property if 1 exit then
+ \ we don't have to support more than 4 (and 0 is illegal) + decode-int nip nip 4 min 1 max
This seems wrong: 0 appears be a valid #size-cells value for device_type cpu. If I use 0 max here though, I just get one column for the /cpus/ PowerPC,970FX available property instead of two... Andreas
+ else + 1 + then +; + : decode-string ( prop-addr1 prop-len1 -- prop-addr2 prop-len2 str len ) dup 0> if 2dup bounds \ check property for 0 bytes -- 1.7.3
+\ HELPER: get #size-cells value (from parent) +\ Legal values are 1..4 (we may optionally support larger sizes) +: my-#scells ( -- #size-cells ) + my-self ?dup if >in.device-node @ else active-package then + ?dup if >dn.parent @ then + ?dup if + " #size-cells" rot get-package-property if 1 exit then
+ \ we don't have to support more than 4 (and 0 is illegal) + decode-int nip nip 4 min 1 max
This seems wrong: 0 appears be a valid #size-cells value for device_type cpu.
It is valid. Why are you bounding the value here at all?
If I use 0 max here though, I just get one column for the /cpus/ PowerPC,970FX available property instead of two...
But that's correct then, isn't it. Segher
Am 06.11.2010 um 03:39 schrieb Segher Boessenkool:
+\ HELPER: get #size-cells value (from parent) +\ Legal values are 1..4 (we may optionally support larger sizes) +: my-#scells ( -- #size-cells ) + my-self ?dup if >in.device-node @ else active-package then + ?dup if >dn.parent @ then + ?dup if + " #size-cells" rot get-package-property if 1 exit then
+ \ we don't have to support more than 4 (and 0 is illegal) + decode-int nip nip 4 min 1 max
This seems wrong: 0 appears be a valid #size-cells value for device_type cpu.
It is valid. Why are you bounding the value here at all?
Again, copy and paste from my-#acells.
If I use 0 max here though, I just get one column for the /cpus/ PowerPC,970FX available property instead of two...
But that's correct then, isn't it.
Hm. It's right for reg, with is one cell (0) only. But it logically doesn't fit the MMU's available property. So it's telling me we need to special-case that somehow for 5/5. Which in turn means that we'll need to pass the #address-cells and #size-cells via stack in 3/5 to cover this use case. "The property values are as defined for the standard “reg” format, with single-cell virtual addresses. The regions of virtual address space denote the virtual address space that is currently unallocated by the Open Firmware and is available for use by client programs." (IEEE 1275 3.6.5) The ppc and CHRP bindings make no statement on that. So, independent of #address-cells, the address will always use one cell. I therefore assume that the size is fixed at one cell, too. Andreas
Executing .properties for, e.g., the /memory node would print the "reg" property as a series of bytes. Visualize the "reg" format as a table. v4: * Fix my-#scells to allow 0 return value. * Pass #address-cells and #size-cells as arguments. * Add some more comments. v3: * Optimization, based on code suggested by Segher. v2: * Use my-#acells for address size. * Introduce my-#scells for size size. Cc: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Andreas Färber <andreas.faerber@web.de> --- forth/admin/devices.fs | 27 +++++++++++++++++++++++++++ forth/device/property.fs | 14 ++++++++++++++ 2 files changed, 41 insertions(+), 0 deletions(-) diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index 91fbde5..b7415b6 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -304,8 +304,35 @@ 2drop ." <unimplemented type>" ; +\ Print the value of a property in "reg" format +: .p-reg ( #acells #scells data len -- ) + 2dup + -rot ( #acells #scells data+len data len ) + >r >r -rot ( data+len #acells #scells R: len data ) + 4 * swap 4 * dup r> r> ( data+len #sbytes #abytes #abytes data len ) + bounds ( data+len #sbytes #abytes #abytes data+len data ) ?do + dup 0= if 2 spaces then \ start of "size" part + 2dup <> if \ non-first byte in row + dup 3 and 0= if space then \ make numbers more readable + then + i c@ 2 0.r \ print byte + 1- 3dup nip + 0= if \ end of row + 3 pick i 1+ > if \ non-last byte + cr \ start new line + d# 26 spaces \ indentation + then + drop dup \ update counter + then + loop + 3drop drop +; + \ This function hardwires data formats to particular node properties : (.property-by-name) ( name-str name-len data len -- ) + 2over " reg" strcmp 0= if + my-#acells my-#scells 2swap .p-reg + 2drop exit + then + 2swap 2drop ( data len ) (.property) ; diff --git a/forth/device/property.fs b/forth/device/property.fs index 285113b..c24584a 100644 --- a/forth/device/property.fs +++ b/forth/device/property.fs @@ -157,6 +157,20 @@ then ; +\ HELPER: get #size-cells value (from parent) +\ Legal values are 0..4 (we may optionally support larger sizes) +: my-#scells ( -- #size-cells ) + my-self ?dup if >in.device-node @ else active-package then + ?dup if >dn.parent @ then + ?dup if + " #size-cells" rot get-package-property if 1 exit then + \ we don't have to support more than 4 + decode-int nip nip 4 min 0 max + else + 1 + then +; + : decode-string ( prop-addr1 prop-len1 -- prop-addr2 prop-len2 str len ) dup 0> if 2dup bounds \ check property for 0 bytes -- 1.7.3
v4: * Pass #address-cells and #size-cells as arguments. v3: * Simplify condition. Signed-off-by: Andreas Färber <andreas.faerber@web.de> --- forth/admin/devices.fs | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index b7415b6..441cfad 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -333,6 +333,13 @@ 2drop exit then + active-package get-nodename " memory" strcmp 0= if + 2over " available" strcmp 0= if + my-#acells my-#scells 2swap .p-reg + 2drop exit + then + then + 2swap 2drop ( data len ) (.property) ; -- 1.7.3
v4: * Pass 1 as #acells and #scells, following IEEE 1275 sect. 3.6.5. On ppc the cpu nodes would've had #size-cells as 0. v3: * Evaluate /chosen mmu property rather than device_type "cpu". Signed-off-by: Andreas Färber <andreas.faerber@web.de> --- forth/admin/devices.fs | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index 441cfad..56d657d 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -339,6 +339,16 @@ 2drop exit then then + " /chosen" find-dev if + " mmu" rot get-package-property 0= if + decode-int nip nip ihandle>phandle active-package = if + 2over " available" strcmp 0= if + 1 1 2swap .p-reg + 2drop exit + then + then + then + then 2swap 2drop ( data len ) (.property) -- 1.7.3
Am 06.11.2010 um 12:57 schrieb Andreas Färber:
v4: * Pass 1 as #acells and #scells, following IEEE 1275 sect. 3.6.5. On ppc the cpu nodes would've had #size-cells as 0.
v3: * Evaluate /chosen mmu property rather than device_type "cpu".
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
Available for testing here: http://repo.or.cz/w/openbios/afaerber.git ppc-queue
On 2010-11-6 6:43 AM, Andreas Färber wrote:
[...] Hm. It's right for reg, with is one cell (0) only. But it logically doesn't fit the MMU's available property. So it's telling me we need to special-case that somehow for 5/5. Which in turn means that we'll need to pass the #address-cells and #size-cells via stack in 3/5 to cover this use case.
"The property values are as defined for the standard “reg” format, with single-cell virtual addresses. The regions of virtual address space denote the virtual address space that is currently unallocated by the Open Firmware and is available for use by client programs." (IEEE 1275 3.6.5)
Hmm. It's "recommended", and I believe that is incorrect for SPARC 64. I'll check on monday - I remember recently seeing that the /virtual-memory available property used two-cell virtual addresses. I'll check what it does with MMUs.
On 2010-11-6 1:46 PM, Tarl Neustaedter wrote:
On 2010-11-6 6:43 AM, Andreas Färber wrote:
[...] Hm. It's right for reg, with is one cell (0) only. But it logically doesn't fit the MMU's available property. So it's telling me we need to special-case that somehow for 5/5. Which in turn means that we'll need to pass the #address-cells and #size-cells via stack in 3/5 to cover this use case.
"The property values are as defined for the standard “reg” format, with single-cell virtual addresses. The regions of virtual address space denote the virtual address space that is currently unallocated by the Open Firmware and is available for use by client programs." (IEEE 1275 3.6.5)
Hmm. It's "recommended", and I believe that is incorrect for SPARC 64. I'll check on monday - I remember recently seeing that the /virtual-memory available property used two-cell virtual addresses. I'll check what it does with MMUs.
Duhh... Sun systems haven't had an MMU node for a _long_ time. I think the SS5 had one, but I literally can't find a Sun old enough to have such a node. Never mind...
Am 08.11.2010 um 22:53 schrieb Tarl Neustaedter:
On 2010-11-6 1:46 PM, Tarl Neustaedter wrote:
On 2010-11-6 6:43 AM, Andreas Färber wrote:
[...] Hm. It's right for reg, with is one cell (0) only. But it logically doesn't fit the MMU's available property. So it's telling me we need to special-case that somehow for 5/5. Which in turn means that we'll need to pass the #address-cells and #size- cells via stack in 3/5 to cover this use case.
"The property values are as defined for the standard “reg” format, with single-cell virtual addresses. The regions of virtual address space denote the virtual address space that is currently unallocated by the Open Firmware and is available for use by client programs." (IEEE 1275 3.6.5)
Hmm. It's "recommended", and I believe that is incorrect for SPARC 64. I'll check on monday - I remember recently seeing that the / virtual-memory available property used two-cell virtual addresses. I'll check what it does with MMUs.
Duhh... Sun systems haven't had an MMU node for a _long_ time. I think the SS5 had one, but I literally can't find a Sun old enough to have such a node. Never mind...
Thanks for looking! It would indeed make sense for a hypothetic sparc64 MMU node to have a 2-4byte-cell virtual address. If this ever pops up, I guess we could use [IFDEF] CONFIG_SPARC64 2 [ELSE] 1 [ENDIF] or something in 5/5. Are there any general objections against patch 2/5? Andreas
On Mon, Nov 8, 2010 at 10:53 PM, Tarl Neustaedter <tarl-b2@tarl.net> wrote:
On 2010-11-6 1:46 PM, Tarl Neustaedter wrote:
On 2010-11-6 6:43 AM, Andreas Färber wrote:
[...] Hm. It's right for reg, with is one cell (0) only. But it logically doesn't fit the MMU's available property. So it's telling me we need to special-case that somehow for 5/5. Which in turn means that we'll need to pass the #address-cells and #size-cells via stack in 3/5 to cover this use case.
"The property values are as defined for the standard “reg” format, with single-cell virtual addresses. The regions of virtual address space denote the virtual address space that is currently unallocated by the Open Firmware and is available for use by client programs." (IEEE 1275 3.6.5)
Hmm. It's "recommended", and I believe that is incorrect for SPARC 64. I'll check on monday - I remember recently seeing that the /virtual-memory available property used two-cell virtual addresses. I'll check what it does with MMUs.
Duhh... Sun systems haven't had an MMU node for a _long_ time. I think the SS5 had one, but I literally can't find a Sun old enough to have such a node. Never mind...
I guess the first one which had it was Ultra-1. SS-5 didn't have it: ok .version Release 2.15 Version 5 created 95/03/29 14:21:55 ok show-devs /FMI,MB86904 /virtual-memory@0,0 /memory@0,0 /obio /iommu@0,10000000 /openprom /aliases /options /packages /obio/SUNW,fdtwo@0,400000 /obio/power@0,910000 /obio/interrupt@0,e00000 /obio/counter@0,d00000 /obio/auxio@0,900000 /obio/slavioconfig@0,800000 /obio/eeprom@0,200000 /obio/zs@0,0 /obio/zs@0,100000 /iommu@0,10000000/sbus@0,10001000 /iommu@0,10000000/sbus@0,10001000/power-management@4,a000000 /iommu@0,10000000/sbus@0,10001000/SUNW,CS4231@4,c000000 /iommu@0,10000000/sbus@0,10001000/ledma@5,8400010 /iommu@0,10000000/sbus@0,10001000/SUNW,bpp@5,c800000 /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000 /iommu@0,10000000/sbus@0,10001000/ledma@5,8400010/le@5,8c00000 /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/st /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd /packages/obp-tftp /packages/deblocker /packages/disk-label -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
Am 09.11.2010 um 11:02 schrieb Artyom Tarasenko:
On Mon, Nov 8, 2010 at 10:53 PM, Tarl Neustaedter <tarl-b2@tarl.net> wrote:
On 2010-11-6 1:46 PM, Tarl Neustaedter wrote:
On 2010-11-6 6:43 AM, Andreas Färber wrote:
[...] Hm. It's right for reg, with is one cell (0) only. But it logically doesn't fit the MMU's available property. So it's telling me we need to special-case that somehow for 5/5. Which in turn means that we'll need to pass the #address-cells and #size-cells via stack in 3/5 to cover this use case.
"The property values are as defined for the standard “reg” format, with single-cell virtual addresses. The regions of virtual address space denote the virtual address space that is currently unallocated by the Open Firmware and is available for use by client programs." (IEEE 1275 3.6.5)
Hmm. It's "recommended", and I believe that is incorrect for SPARC 64. I'll check on monday - I remember recently seeing that the / virtual-memory available property used two-cell virtual addresses. I'll check what it does with MMUs.
Duhh... Sun systems haven't had an MMU node for a _long_ time. I think the SS5 had one, but I literally can't find a Sun old enough to have such a node. Never mind...
I guess the first one which had it was Ultra-1. SS-5 didn't have it:
ok .version Release 2.15 Version 5 created 95/03/29 14:21:55 ok show-devs [snip]
Just so that we don't misunderstand each other, this is not about a node named "MMU" that we might see in show-devs. It's about some node - anonymous or named - that gets referenced by the mmu property in the /chosen node. On my PowerMac G3 it points to /cpus/PowerPC,750@0 (the CPU), for example. Andreas
On Tue, Nov 9, 2010 at 10:49 PM, Andreas Färber <andreas.faerber@web.de> wrote:
Am 09.11.2010 um 11:02 schrieb Artyom Tarasenko:
On Mon, Nov 8, 2010 at 10:53 PM, Tarl Neustaedter <tarl-b2@tarl.net> wrote:
On 2010-11-6 1:46 PM, Tarl Neustaedter wrote:
On 2010-11-6 6:43 AM, Andreas Färber wrote:
[...] Hm. It's right for reg, with is one cell (0) only. But it logically doesn't fit the MMU's available property. So it's telling me we need to special-case that somehow for 5/5. Which in turn means that we'll need to pass the #address-cells and #size-cells via stack in 3/5 to cover this use case.
"The property values are as defined for the standard “reg” format, with single-cell virtual addresses. The regions of virtual address space denote the virtual address space that is currently unallocated by the Open Firmware and is available for use by client programs." (IEEE 1275 3.6.5)
Hmm. It's "recommended", and I believe that is incorrect for SPARC 64. I'll check on monday - I remember recently seeing that the /virtual-memory available property used two-cell virtual addresses. I'll check what it does with MMUs.
Duhh... Sun systems haven't had an MMU node for a _long_ time. I think the SS5 had one, but I literally can't find a Sun old enough to have such a node. Never mind...
I guess the first one which had it was Ultra-1. SS-5 didn't have it:
ok .version Release 2.15 Version 5 created 95/03/29 14:21:55 ok show-devs
[snip]
Just so that we don't misunderstand each other, this is not about a node named "MMU" that we might see in show-devs. It's about some node - anonymous or named - that gets referenced by the mmu property in the /chosen node.
Yes, but there is no "/chosen" node on SPARCstations. I think it first appeared in 64 bit (Ultra) machines.
On my PowerMac G3 it points to /cpus/PowerPC,750@0 (the CPU), for example.
-- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
On 2010-11-9 4:49 PM, Andreas Färber wrote:
[...] [snip]
Just so that we don't misunderstand each other, this is not about a node named "MMU" that we might see in show-devs. It's about some node - anonymous or named - that gets referenced by the mmu property in the /chosen node.
On my PowerMac G3 it points to /cpus/PowerPC,750@0 (the CPU), for example.
Ah. O.k. - on current (sun4v) Sparcs, that's an anonymous node without properties (just vocabulary for CIF calls), so pretty-print isn't relevant to it.
Am 06.11.2010 um 03:39 schrieb Segher Boessenkool:
+\ HELPER: get #size-cells value (from parent) +\ Legal values are 1..4 (we may optionally support larger sizes) +: my-#scells ( -- #size-cells ) + my-self ?dup if >in.device-node @ else active-package then + ?dup if >dn.parent @ then + ?dup if + " #size-cells" rot get-package-property if 1 exit then
+ \ we don't have to support more than 4 (and 0 is illegal) + decode-int nip nip 4 min 1 max
This seems wrong: 0 appears be a valid #size-cells value for device_type cpu.
It is valid. Why are you bounding the value here at all?
Segher, thinking more about your question, are you referring to what became in v4 "0 max" (arguments are signed so this should still rule out -1, no?) or the general concept of limiting the value range here? I am planning to apply the series tomorrow unless I hear a strong objection. Optimizations could still be applied later. Andreas
+\ HELPER: get #size-cells value (from parent) +\ Legal values are 1..4 (we may optionally support larger sizes) +: my-#scells ( -- #size-cells ) + my-self ?dup if >in.device-node @ else active-package then + ?dup if >dn.parent @ then + ?dup if + " #size-cells" rot get-package-property if 1 exit then
+ \ we don't have to support more than 4 (and 0 is illegal) + decode-int nip nip 4 min 1 max
This seems wrong: 0 appears be a valid #size-cells value for device_type cpu.
It is valid. Why are you bounding the value here at all?
Segher, thinking more about your question, are you referring to what became in v4 "0 max" (arguments are signed so this should still rule out -1, no?) or the general concept of limiting the value range here?
[Sorry for not replying earlier -- my mail went dead, and then I forgot.] I mean the "4 min", it makes no sense. If something similar is in the original code, it is a bug there as well. It makes no sense to limit the number of address/size cells unnecessary. It is absolutely wrong to silently use a different number, instead of failing, when the number requested is bigger than implementation limits.
I am planning to apply the series tomorrow unless I hear a strong objection. Optimizations could still be applied later.
This is not an optimisation; but you can incrementally fix it, as far as I am concerned. Ask someone else for an ack though. Segher
Executing .properties for, e.g., the /memory node would print the "reg" property as a series of bytes. Visualize the "reg" format as a table, with address and size columns. v5: * Drop the upper limit for my-#scells, suggested by Segher. * Fix indentation. v4: * Fix my-#scells to allow 0 return value. * Pass #address-cells and #size-cells as arguments. * Add some more comments. v3: * Optimization, based on code suggested by Segher. v2: * Use my-#acells for address size. * Introduce my-#scells for size size. Cc: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Andreas Färber <andreas.faerber@web.de> --- forth/admin/devices.fs | 27 +++++++++++++++++++++++++++ forth/device/property.fs | 14 ++++++++++++++ 2 files changed, 41 insertions(+), 0 deletions(-) diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index 91fbde5..7313a35 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -304,8 +304,35 @@ 2drop ." <unimplemented type>" ; +\ Print the value of a property in "reg" format +: .p-reg ( #acells #scells data len -- ) + 2dup + -rot ( #acells #scells data+len data len ) + >r >r -rot ( data+len #acells #scells R: len data ) + 4 * swap 4 * dup r> r> ( data+len #sbytes #abytes #abytes data len ) + bounds ( data+len #sbytes #abytes #abytes data+len data ) ?do + dup 0= if 2 spaces then \ start of "size" part + 2dup <> if \ non-first byte in row + dup 3 and 0= if space then \ make numbers more readable + then + i c@ 2 0.r \ print byte + 1- 3dup nip + 0= if \ end of row + 3 pick i 1+ > if \ non-last byte + cr \ start new line + d# 26 spaces \ indentation + then + drop dup \ update counter + then + loop + 3drop drop +; + \ This function hardwires data formats to particular node properties : (.property-by-name) ( name-str name-len data len -- ) + 2over " reg" strcmp 0= if + my-#acells my-#scells 2swap .p-reg + 2drop exit + then + 2swap 2drop ( data len ) (.property) ; diff --git a/forth/device/property.fs b/forth/device/property.fs index 285113b..4479e6e 100644 --- a/forth/device/property.fs +++ b/forth/device/property.fs @@ -157,6 +157,20 @@ then ; +\ HELPER: get #size-cells value (from parent) +\ Legal values are >= 0 +: my-#scells ( -- #size-cells ) + my-self ?dup if >in.device-node @ else active-package then + ?dup if >dn.parent @ then + ?dup if + " #size-cells" rot get-package-property if 1 exit then + \ we don't have to support more than 4 + decode-int nip nip 0 max + else + 1 + then +; + : decode-string ( prop-addr1 prop-len1 -- prop-addr2 prop-len2 str len ) dup 0> if 2dup bounds \ check property for 0 bytes -- 1.7.3
+ " #size-cells" rot get-package-property if 1 exit then + \ we don't have to support more than 4 + decode-int nip nip 0 max
It's not a signed number, so it should be umax, not max. But "0 umax" is a noop. Just remove it, use the value as-is. A sanity check somewhere (probably not here though) might be useful; but mangling the data if deemed out-of-range is hiding the problem, at best. Segher
Am 12.11.2010 um 23:26 schrieb Segher Boessenkool:
+ " #size-cells" rot get-package-property if 1 exit then + \ we don't have to support more than 4 + decode-int nip nip 0 max
It's not a signed number, so it should be umax, not max. But "0 umax" is a noop. Just remove it, use the value as-is.
Your loop uses them as signed numbers though... Your quote also shows a stray comment that I'll remove. Andreas
A sanity check somewhere (probably not here though) might be useful; but mangling the data if deemed out-of-range is hiding the problem, at best.
Segher
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
+ " #size-cells" rot get-package-property if 1 exit then + \ we don't have to support more than 4 + decode-int nip nip 0 max
It's not a signed number, so it should be umax, not max. But "0 umax" is a noop. Just remove it, use the value as-is.
Your loop uses them as signed numbers though...
"My loop"?
Your quote also shows a stray comment that I'll remove.
Yeah, it's somewhat out of place here. Thanks, Segher
Am 12.11.2010 um 23:40 schrieb Segher Boessenkool:
+ " #size-cells" rot get-package-property if 1 exit then + \ we don't have to support more than 4 + decode-int nip nip 0 max
It's not a signed number, so it should be umax, not max. But "0 umax" is a noop. Just remove it, use the value as-is.
Your loop uses them as signed numbers though...
"My loop"?
Your optimized version of my .p-reg word - iiuc - uses a loop counter going from + my-#acells to - my-#scells, thereby treating the property values as signed numbers on sparc32, ppc, ppc64 (where cell size == 4). Practically speaking it doesn't matter though since I haven't seen such large #size-cells anywhere yet. :) Andreas
Executing .properties for, e.g., the /memory node would print the "reg" property as a series of bytes. Visualize the "reg" format as a table, with address and size columns. v6: * Drop lower limit for my-#scells, since #size-cells is unsigned. Pointed out by Segher. * Drop comment outdated by v5. v5: * Drop the upper limit for my-#scells, suggested by Segher. * Fix indentation. v4: * Fix my-#scells to allow 0 return value. * Pass #address-cells and #size-cells as arguments. * Add some more comments. v3: * Optimization, based on code suggested by Segher. v2: * Use my-#acells for address size. * Introduce my-#scells for size size. Cc: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Andreas Färber <andreas.faerber@web.de> --- forth/admin/devices.fs | 27 +++++++++++++++++++++++++++ forth/device/property.fs | 12 ++++++++++++ 2 files changed, 39 insertions(+), 0 deletions(-) diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs index 91fbde5..7313a35 100644 --- a/forth/admin/devices.fs +++ b/forth/admin/devices.fs @@ -304,8 +304,35 @@ 2drop ." <unimplemented type>" ; +\ Print the value of a property in "reg" format +: .p-reg ( #acells #scells data len -- ) + 2dup + -rot ( #acells #scells data+len data len ) + >r >r -rot ( data+len #acells #scells R: len data ) + 4 * swap 4 * dup r> r> ( data+len #sbytes #abytes #abytes data len ) + bounds ( data+len #sbytes #abytes #abytes data+len data ) ?do + dup 0= if 2 spaces then \ start of "size" part + 2dup <> if \ non-first byte in row + dup 3 and 0= if space then \ make numbers more readable + then + i c@ 2 0.r \ print byte + 1- 3dup nip + 0= if \ end of row + 3 pick i 1+ > if \ non-last byte + cr \ start new line + d# 26 spaces \ indentation + then + drop dup \ update counter + then + loop + 3drop drop +; + \ This function hardwires data formats to particular node properties : (.property-by-name) ( name-str name-len data len -- ) + 2over " reg" strcmp 0= if + my-#acells my-#scells 2swap .p-reg + 2drop exit + then + 2swap 2drop ( data len ) (.property) ; diff --git a/forth/device/property.fs b/forth/device/property.fs index 285113b..d19546c 100644 --- a/forth/device/property.fs +++ b/forth/device/property.fs @@ -157,6 +157,18 @@ then ; +\ HELPER: get #size-cells value (from parent) +: my-#scells ( -- #size-cells ) + my-self ?dup if >in.device-node @ else active-package then + ?dup if >dn.parent @ then + ?dup if + " #size-cells" rot get-package-property if 1 exit then + decode-int nip nip + else + 1 + then +; + : decode-string ( prop-addr1 prop-len1 -- prop-addr2 prop-len2 str len ) dup 0> if 2dup bounds \ check property for 0 bytes -- 1.7.3
Your loop uses them as signed numbers though...
"My loop"?
Your optimized version of my .p-reg word - iiuc - uses a loop counter going from + my-#acells to - my-#scells, thereby treating the property values as signed numbers on sparc32, ppc, ppc64 (where cell size == 4).
It doesn't treat them as signed; it does however assume #a + #s fits in a single cell, without overflow :-) Open Firmware requires two's complement arithmetic, so you can treat all arithmetic (except signed division) as unsigned. Quite handy. My loop used a biased index so that it could test for the "middle" condition by testing against zero, which saves some stack juggling; it's just a little trick, there's no special meaning to it.
Practically speaking it doesn't matter though since I haven't seen such large #size-cells anywhere yet. :)
Yeah :-) Segher
Am 12.11.2010 um 23:54 schrieb Andreas Färber:
Executing .properties for, e.g., the /memory node would print the "reg" property as a series of bytes.
Visualize the "reg" format as a table, with address and size columns.
v6: * Drop lower limit for my-#scells, since #size-cells is unsigned. Pointed out by Segher. * Drop comment outdated by v5.
v5: * Drop the upper limit for my-#scells, suggested by Segher. * Fix indentation.
v4: * Fix my-#scells to allow 0 return value. * Pass #address-cells and #size-cells as arguments. * Add some more comments.
v3: * Optimization, based on code suggested by Segher.
v2: * Use my-#acells for address size. * Introduce my-#scells for size size.
Cc: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Andreas Färber <andreas.faerber@web.de> ---
Applied remaining parts of v6 series in r956-r959. Thanks for your comments. Andreas
Am 09.11.2010 um 11:02 schrieb Artyom Tarasenko:
On Mon, Nov 8, 2010 at 10:53 PM, Tarl Neustaedter <tarl-b2@tarl.net> wrote:
On 2010-11-6 1:46 PM, Tarl Neustaedter wrote:
On 2010-11-6 6:43 AM, Andreas Färber wrote:
[...] Hm. It's right for reg, with is one cell (0) only. But it logically doesn't fit the MMU's available property. So it's telling me we need to special-case that somehow for 5/5. Which in turn means that we'll need to pass the #address-cells and #size-cells via stack in 3/5 to cover this use case.
"The property values are as defined for the standard “reg” format, with single-cell virtual addresses. The regions of virtual address space denote the virtual address space that is currently unallocated by the Open Firmware and is available for use by client programs." (IEEE 1275 3.6.5)
Hmm. It's "recommended", and I believe that is incorrect for SPARC 64. I'll check on monday - I remember recently seeing that the / virtual-memory available property used two-cell virtual addresses. I'll check what it does with MMUs.
Duhh... Sun systems haven't had an MMU node for a _long_ time. I think the SS5 had one, but I literally can't find a Sun old enough to have such a node. Never mind...
I guess the first one which had it was Ultra-1. SS-5 didn't have it:
ok .version Release 2.15 Version 5 created 95/03/29 14:21:55 ok show-devs /FMI,MB86904 /virtual-memory@0,0
Just wondering, what does /virtual-memory@0,0 contain? /virtual-memory is where I saw "available" and "translations" properties on a Sun Fire V480. Andreas
On 2010-12-4 8:54 AM, Andreas Färber wrote:
[...] Just wondering, what does /virtual-memory@0,0 contain? /virtual-memory is where I saw "available" and "translations" properties on a Sun Fire V480.
Yup. In a recent (sun4v, T5240) system: {0} ok cd /virtual-memory {0} ok .properties translations 00 00 00 00 00 00 20 00 00 00 00 00 00 9f e0 00 ... existing 00000000 00000000 00000800 00000000 fffff800 00000000 00000800 00000000 available fffff800 00000000 000007fc 00000000 00000001 00000000 000007ff 00000000 00000000 ffff0000 00000000 0000e000 00000000 00000000 00000000 f0000000 00000000 fe99e000 00000000 00002000 00000000 fe986000 00000000 00012000 00000000 fe89c000 00000000 00090000 00000000 f2200000 00000000 0c688000 page-size 00002000 name virtual-memory {0} ok The translations property is usually *huge*, and we (sun@oracle) don't pretty-print it. It gets dumped out as a byte-array and we stop printing anything after the 16th byte. On the rare occasion we need to look at the values inside, we dump the property itself: {0} ok " translations" get-property fff47fe0 168 0 {0} ok drop dump \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef fff47fe0 00 00 00 00 00 00 20 00 00 00 00 00 00 9f e0 00 ...... .......`. fff47ff0 80 00 00 00 0e 40 27 40 00 00 00 00 f0 00 00 00 .....@'@....p... fff48000 00 00 00 00 00 40 00 00 80 00 00 00 0e 00 07 50 .....@.........P fff48010 00 00 00 00 fe 88 80 00 00 00 00 00 00 00 a0 00 ....~......... . fff48020 80 00 00 0f ff 98 87 50 00 00 00 00 fe 89 20 00 .......P....~. . fff48030 00 00 00 00 00 00 a0 00 80 00 00 0f ff 99 47 50 ...... .......GP fff48040 00 00 00 00 fe 92 c0 00 00 00 00 00 00 05 a0 00 ....~.@....... . fff48050 80 00 00 0f ff 89 67 50 00 00 00 00 fe 99 80 00 ......gP....~... fff48060 00 00 00 00 00 00 20 00 80 00 00 0f ff 98 67 50 ...... .......gP fff48070 00 00 00 00 fe 99 a0 00 00 00 00 00 00 00 40 00 ....~. .......@. fff48080 80 00 00 0f ff 9a 07 50 00 00 00 00 fe 9a 00 00 .......P....~... fff48090 00 00 00 00 00 01 20 00 80 00 00 0f ff 9a 47 50 ...... .......GP fff480a0 00 00 00 00 fe 9b 20 00 00 00 00 00 00 08 00 00 ....~. ......... fff480b0 80 00 00 0f ff 90 07 50 00 00 00 00 fe a3 20 00 .......P....~# . fff480c0 00 00 00 00 00 38 e0 00 80 00 00 0f ff 9b 67 50 .....8`.......gP fff480d0 00 00 00 00 fe dc 00 00 00 00 00 00 00 24 00 00 ....~\.......$.. fff480e0 80 00 00 0f ff d9 27 50 00 00 00 00 ff f0 00 00 .....Y'P.....p.. fff480f0 00 00 00 00 00 04 00 00 80 00 00 0f ff d4 47 50 .............TGP fff48100 00 00 00 00 ff f4 40 00 00 00 00 00 00 00 c0 00 .....t@.......@. fff48110 80 00 00 0f ff d8 47 50 00 00 00 00 ff f5 00 00 .....XGP.....u.. fff48120 00 00 00 00 00 02 00 00 80 00 00 0f ff fd 27 50 .............}'P fff48130 00 00 00 00 ff f7 00 00 00 00 00 00 00 01 00 00 .....w.......... More [<space>,<cr>,q,n,p,c] ? More commonly, we simply swear at the property when we have to do a "prtconf -pv" from Solaris, which prints every property of every node - and often more than half the resulting output is this property by itself.
Am 05.12.2010 um 03:08 schrieb Tarl Neustaedter:
On 2010-12-4 8:54 AM, Andreas Färber wrote:
[...] Just wondering, what does /virtual-memory@0,0 contain? /virtual-memory is where I saw "available" and "translations" properties on a Sun Fire V480.
Yup. In a recent (sun4v, T5240) system:
Actually the context here was sparc32/sun4m. Artyom reported no / chosen node on an SS-5 but apparently some /virtual-memory@0,0 node. OpenBIOS/sparc32 on the other hand does have a /chosen node and an "mmu" property, but its value is 0 so that pretty-printing of /virtual- memory's "available" isn't triggered. So I'm thinking, if the virtual memory "available" property is there and we do have a /chosen node then "mmu" should point to /virtual-memory, even if there's no "translations" property. The alternative would be to [IFDEF] CONFIG_SPARC32 a special handling of "available" in the /virtual- memory node. Andreas
On Sun, Dec 5, 2010 at 12:21 PM, Andreas Färber <andreas.faerber@web.de> wrote:
Am 05.12.2010 um 03:08 schrieb Tarl Neustaedter:
On 2010-12-4 8:54 AM, Andreas Färber wrote:
[...] Just wondering, what does /virtual-memory@0,0 contain?
Actually the context here was sparc32/sun4m. Artyom reported no /chosen node on an SS-5 but apparently some /virtual-memory@0,0 node.
I thought he also reported the contents of the node here: http://lists.openbios.org/pipermail/openbios/2010-October/005611.html For SS-5: ok .attributes available 00000000 fff00000 00100000 00000000 fef00000 00e00000 00000000 00000000 fe400000 00000000 ffe15000 000cd000 00000000 ffd00000 00008000 00000000 fe400000 00b00000 reg 00000000 00000000 80000000 00000000 80000000 80000000 name virtual-memory Btw, the contents of this node is the same regardless whether the ram size is 256M or 32M.
OpenBIOS/sparc32 on the other hand does have a /chosen node and an "mmu" property, but its value is 0 so that pretty-printing of /virtual-memory's "available" isn't triggered. So I'm thinking, if the virtual memory "available" property is there and we do have a /chosen node then "mmu" should point to /virtual-memory, even if there's no "translations" property. The alternative would be to [IFDEF] CONFIG_SPARC32 a special handling of "available" in the /virtual-memory node.
The question is how does the OS get this information. Can it be that the name of the node doesn't matter? It Solaris wouldn't get the available memory from the firmware I'd expect some error message like "Can't deduct msgbuf from physical memory list". (had it when qemu had math and mmu problems). -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
participants (5)
-
Andreas Färber -
Artyom Tarasenko -
Blue Swirl -
Segher Boessenkool -
Tarl Neustaedter