From owner-freebsd-arm@FreeBSD.ORG Tue Dec 27 13:57:38 2011 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB6941065676 for ; Tue, 27 Dec 2011 13:57:38 +0000 (UTC) (envelope-from kp@sigsegv.be) Received: from mercury.codepro.be (mercury.codepro.be [IPv6:2001:4b98:dc0:51:216:3eff:feb7:3147]) by mx1.freebsd.org (Postfix) with ESMTP id 55DE68FC12 for ; Tue, 27 Dec 2011 13:57:35 +0000 (UTC) Received: from adrastea.jupiter.sigsegv.be (adrastea.jupiter.sigsegv.be [IPv6:2001:6f8:1498:1::3]) by mercury.codepro.be (Postfix) with ESMTP id 988E5D3C for ; Tue, 27 Dec 2011 14:57:33 +0100 (CET) Received: from thebe.jupiter.sigsegv.be (thebe.jupiter.sigsegv.be [172.16.1.5]) by adrastea.jupiter.sigsegv.be (Postfix) with ESMTP id 222A15067 for ; Tue, 27 Dec 2011 14:57:33 +0100 (CET) Received: by thebe.jupiter.sigsegv.be (Postfix, from userid 1000) id 0B47915559; Tue, 27 Dec 2011 14:57:33 +0100 (CET) Date: Tue, 27 Dec 2011 14:57:32 +0100 From: Kristof Provost To: freebsd-arm@FreeBSD.org Message-ID: <20111227135732.GB9051@thebe.jupiter.sigsegv.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: FDT IMMR confusion X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 13:57:38 -0000 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