[U-Boot] Question about device tree usage and ranges
Hi,
In my device tree I need to translate some address via ranges but I'm running into some issues. If I use ofnode_get_addr_size() it is not using the #address-cells and #size-cells nor is it performing the ranges translation. It always assumes #address-cells and #size-cells is 2 and doesn't translate. Is this by design?
If, on the other hand, I use ofnode_get_addr_size_index, it is having problems on ARM64. One problem I see is in of_translate_one in fdt_support.c. Shouldn't there be a fdt32_to_cpu or fdt64_to_cpu for the address after the memcpy in of_translate_one? I'm seeing the wrong endian address and size show up.
OF: ** translation for device console@0 ** __of_translate_address: bus: default, address: 00000007fff46d7d OF: bus is default (na=1, ns=1) on pci-console@0x03000000 OF: translating address: 00000000 OF: parent bus is default (na=2, ns=2) on soc@0 OF: walking ranges... OF: default map, cp=0, s=1, da=0 OF: parent translation for: 80003000 80400000 <======= WRONG ENDIAN! OF: with offset: 0 OF: one level translation: 80003000 80400000 <======= WRONG ENDIAN! OF: parent bus is default (na=2, ns=2) on OF: no ranges, 1:1 translation
-Aaron
Hi Aaron,
On 19.09.19 13:35, Aaron Williams wrote:
Hi,
In my device tree I need to translate some address via ranges but I'm running into some issues. If I use ofnode_get_addr_size() it is not using the #address-cells and #size-cells nor is it performing the ranges translation. It always assumes #address-cells and #size-cells is 2 and doesn't translate. Is this by design?
If, on the other hand, I use ofnode_get_addr_size_index, it is having problems on ARM64. One problem I see is in of_translate_one in fdt_support.c. Shouldn't there be a fdt32_to_cpu or fdt64_to_cpu for the address after the memcpy in of_translate_one? I'm seeing the wrong endian address and size show up.
OF: ** translation for device console@0 ** __of_translate_address: bus: default, address: 00000007fff46d7d OF: bus is default (na=1, ns=1) on pci-console@0x03000000 OF: translating address: 00000000 OF: parent bus is default (na=2, ns=2) on soc@0 OF: walking ranges... OF: default map, cp=0, s=1, da=0 OF: parent translation for: 80003000 80400000 <======= WRONG ENDIAN! OF: with offset: 0 OF: one level translation: 80003000 80400000 <======= WRONG ENDIAN! OF: parent bus is default (na=2, ns=2) on OF: no ranges, 1:1 translation
Without looking deeper into your mail, let me ask if you enabled CONFIG_(SPL_)OF_TRANSLATE?
Thanks, Stefan
Hi Stefan,
That doesn't explain the wrong endian. The code should be using fdt32_to_cpu for little-endian CPUs.
-Aaron
On Thursday, September 19, 2019 4:43:27 AM PDT Stefan Roese wrote:
Hi Aaron,
On 19.09.19 13:35, Aaron Williams wrote:
Hi,
In my device tree I need to translate some address via ranges but I'm running into some issues. If I use ofnode_get_addr_size() it is not using the #address-cells and #size-cells nor is it performing the ranges translation. It always assumes #address-cells and #size-cells is 2 and doesn't translate. Is this by design?
If, on the other hand, I use ofnode_get_addr_size_index, it is having problems on ARM64. One problem I see is in of_translate_one in fdt_support.c. Shouldn't there be a fdt32_to_cpu or fdt64_to_cpu for the address after the memcpy in of_translate_one? I'm seeing the wrong endian address and size show up.
OF: ** translation for device console@0 ** __of_translate_address: bus: default, address: 00000007fff46d7d OF: bus is default (na=1, ns=1) on pci-console@0x03000000 OF: translating address: 00000000 OF: parent bus is default (na=2, ns=2) on soc@0 OF: walking ranges... OF: default map, cp=0, s=1, da=0 OF: parent translation for: 80003000 80400000 <======= WRONG ENDIAN! OF: with offset: 0 OF: one level translation: 80003000 80400000 <======= WRONG ENDIAN! OF: parent bus is default (na=2, ns=2) on OF: no ranges, 1:1 translation
Without looking deeper into your mail, let me ask if you enabled CONFIG_(SPL_)OF_TRANSLATE?
Thanks, Stefan
On Thursday, September 19, 2019 4:43:27 AM PDT Stefan Roese wrote: Hi Stefan,
Hi Aaron,
On 19.09.19 13:35, Aaron Williams wrote:
Hi,
In my device tree I need to translate some address via ranges but I'm running into some issues. If I use ofnode_get_addr_size() it is not using the #address-cells and #size-cells nor is it performing the ranges translation. It always assumes #address-cells and #size-cells is 2 and doesn't translate. Is this by design?
If, on the other hand, I use ofnode_get_addr_size_index, it is having problems on ARM64. One problem I see is in of_translate_one in fdt_support.c. Shouldn't there be a fdt32_to_cpu or fdt64_to_cpu for the address after the memcpy in of_translate_one? I'm seeing the wrong endian address and size show up.
OF: ** translation for device console@0 ** __of_translate_address: bus: default, address: 00000007fff46d7d OF: bus is default (na=1, ns=1) on pci-console@0x03000000 OF: translating address: 00000000 OF: parent bus is default (na=2, ns=2) on soc@0 OF: walking ranges... OF: default map, cp=0, s=1, da=0 OF: parent translation for: 80003000 80400000 <======= WRONG ENDIAN! OF: with offset: 0 OF: one level translation: 80003000 80400000 <======= WRONG ENDIAN! OF: parent bus is default (na=2, ns=2) on OF: no ranges, 1:1 translation
Without looking deeper into your mail, let me ask if you enabled CONFIG_(SPL_)OF_TRANSLATE?
Thanks, Stefan
Yes, CONFIG_OF_TRANSLATE is enabled.
In looking at the code, it does not come into the picture when ofnode_get_addr_size() is called. It is used in ofnode_get_addr_size_index(), however. Also, ofnode_get_addr_size() does not honor the #address-cells and #size-cells whereas the other function does. Furthermore, the code does not translate the endianess in of_translate_one() which is used in ofnode_get_addr_size_index().
-Aaron
participants (2)
-
Aaron Williams -
Stefan Roese