FDT IMMR confusion

Kristof Provost kristof at sigsegv.be
Tue Dec 27 13:57:38 UTC 2011


Hi,

I've been playing with mu OpenRD board and noticed something odd about
the FDT implementation.  In fdt_reg_to_rl, called among others from 
newbus_device_create the assumption seems to be that all addresses are 
relative to the SOC base address.
The fdt_reg_to_rl function even masks of the top 12 bits of the address
before adding it to the base address.
This addresses is set to the base address of the SOC by fdt_immr_addr,
from initarm function (arm/mv/mv_machdep.c in case of the
OpenRD/Sheevaplug). According to the commit message I found
(http://p4web.freebsd.org/@md=d&cd=//&c=ZnH@/174262?ac=10) IMMR is
Internal Mem-Mapped Registers.

I don't understand why it was implemented this way. The ePAPR
specification doesn't seem to agree with this. Instead it says 
(in 2.3.6 reg):

> The reg property describes the address and length of a device's memory 
> mapped register space within its parent's address space. 

Specifically, this is a problem for the SDRAM mapping on my OpenRD. The
SDRAM address range is outside the SOC range, and with the current code 
it's simply not possible access this range.
The FDT is very similar to the Sheevaplug, which also has this problem.
There's no way to get a resource for address 0xfd000000 if the SOC base
address is 0xf1000000.

Is there a good reason for this, or was it simply an implementation
shortcut which still needs to be fixed?

Regards,
Kristof



More information about the freebsd-arm mailing list