[OpenBIOS] [PATCH v3 3/5] Pretty-print reg property

Andreas Färber andreas.faerber at web.de
Sat Nov 6 11:43:17 CET 2010

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.


More information about the OpenBIOS mailing list