From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Thu, 3 Dec 2015 12:31:37 +0100 Subject: [U-Boot] [PATCH] dm: core: Add platform specific bus translation function In-Reply-To: References: <1448619748-26759-1-git-send-email-sr@denx.de> <565BF232.4030602@denx.de> <565D38B3.6010602@denx.de> <565EFC09.3070209@denx.de> <565F0D37.30700@denx.de> <565F15AE.7010004@denx.de> <565F2DC1.7040608@denx.de> Message-ID: <56602819.5040006@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Simon, On 02.12.2015 18:45, Simon Glass wrote: > Hi Stefan, > > On 2 December 2015 at 10:43, Stefan Roese wrote: >> Hi Simon, >> >> ( Last mail for tonight - a glass of quite nice red wine is >> waiting for me ... ;) ) >> > > That's the only sad thing about me being so many hours behind. Still I > can do the same thing with people in Asia I suppose :-) Right. I'm not sure about the wine quality in Asia though... ;) >> >> On 02.12.2015 17:53, Simon Glass wrote: >>> >>> Hi Stefan, >>> >>> On 2 December 2015 at 09:00, Stefan Roese wrote: >>>> >>>> >>>> Hi Simon, >>>> >>>> On 02.12.2015 16:50, Simon Glass wrote: >>>> >>>> >>>> >>>>>>> I think it would be better to make it depend on whether the bit is >>>>>>> flipped, rather than whether you are in SPL or not. >>>>>> >>>>>> >>>>>> >>>>>> You simply can't detect if this "bit is flipped". You just have >>>>>> to know. This is a long lasting ugly thing on some Marvell >>>>>> patforms. Here the comment from armada-xp-gp.dts: >>>>> >>>>> >>>>> >>>>> Can you point me to the place in U-Boot where this bit is flipped? >>>>> Something, somewhere has to make the change. So something has to know. >>>>> Before it makes the change, the range works one way. Afterwards it >>>>> works another way. >>>> >>>> >>>> >>>> Sure. I've mentioned this before. Its here: >>>> >>>> arch/arm/mach-mvebu/cpu.c: >>>> >>>> int arch_cpu_init(void) >>>> { >>>> ... >>>> >>>> /* Linux expects the internal registers to be at 0xf1000000 */ >>>> writel(SOC_REGS_PHY_BASE, INTREG_BASE_ADDR_REG); >>>> >>>> This is the line that changes the register base address. And >>>> to change it back you need to write to the new address, as the >>>> address holding this base address is also moved. Quite ugly! >>>> >>>> So its really right at the start of U-Boot proper. >>> >>> >>> OK I see. So really we can determine which way the address 'switch' >>> it. It's just a case of making the change when we are ready, and >>> keeping a record of that. >> >> >> Yes. But how is the "common code" in dev_get_addr() supposed to know >> which version of U-Boot we are running on? This boils down to some >> callback again, or not? Or even worse the ugly #ifdef. > > You would call a driver-model core function to select the ranges > property to prefer. Then driver model will remember this setting and > use it. Yes. This can be done. I've taken the time to implement such a version. And attached a small patch in a hackish version, just as an RFC. As you will see, I've added the "ranges-spl" property to some of the DT nodes. And added the DM core functions to enable to usage of a different, non-standard "ranges" property name. All this is not really "clean" and will definitely break non-DM usage of fdt_support.c. Not sure where to go from here. I would still prefer my first patch version, even though I know that you don't like to add this hook / callback into the DM core code. Let me know what you think. Thanks, Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-dm-Add-option-to-configure-a-different-non-standard-.patch Type: text/x-diff Size: 5494 bytes Desc: not available URL: