Date: Tue, 27 Dec 2011 14:57:32 +0100 From: Kristof Provost <kristof@sigsegv.be> To: freebsd-arm@FreeBSD.org Subject: FDT IMMR confusion Message-ID: <20111227135732.GB9051@thebe.jupiter.sigsegv.be>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111227135732.GB9051>