Hi Simon,
On 02.12.2015 18:45, Simon Glass wrote:
Hi Stefan,
On 2 December 2015 at 10:43, Stefan Roese sr@denx.de 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 sr@denx.de wrote:
Hi Simon,
On 02.12.2015 16:50, Simon Glass wrote:
<snip>
> 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