[U-Boot] mvebu spl: translation offset set too late?

[Stefan Roese]

Adding Simon to Cc (again)...

On 11.04.19 14:26, Pierre Bourdon wrote:
> On Thu, Apr 11, 2019 at 2:07 PM Baruch Siach <baruch at tkos.co.il> wrote:
>>> Note that on Turris Omnia the SPL needs a working I2C0 to fetch RAM
>>> configuration from an EEPROM. The "band-aid" fix of disabling the
>>> debug register write in SPL mode would break Omnia boards in 2GB RAM
>>> configuration.
>>
>> Would it? You should be able to communicate with the EEPROM at 100KHz without
>> any problem.
>>
>> My use case is also EEPROM access from SPL for RAM configuration on a future
>> revision (2.1) of the SolidRun Armada 388 SOM. It works here with the patch
>> applied.
> 
> Cc-ing Tomas who wrote the original code in the Turris u-boot fork [1]
> and may have a deeper understanding of why it is needed.
> 
> My understanding from the comments and description of the patch is
> that this might be i2c address dependent. I will do some more testing
> tonight, but I'm almost sure that removing this code causes my Turris
> Omnia to fail talking to any device on i2c0 (MCU, EEPROM, atsha204a).
> 
> [1] https://gitlab.labs.nic.cz/turris/turris-omnia-uboot/commit/590200da03fc0c04992722a50ed949981dded713
> 
>> I guess that calling dm_set_translation_offset() before spl_init would fail
>> because dm_root is not initialized yet. Is that correct? I could not find the
>> code that initializes dm_root. The correct fix would probably involve setting
>> translation_offset at the earliest possible point.
> 
> Correct. dm_root is initialized by dm_init (look for
> DM_ROOT_NON_CONST). But the way dm_init is called in SPL is via
> dm_init_and_scan, which does not let boards / machine definitions
> configure the translation offset before driver->bind is called.

I also see no easy way to solve this "hen egg problem" with the
translation offset before bind for the drivers is being called with
the current API. Perhaps Simon (or someone else) has an idea?

As mentioned in my earlier reply, moving to a callback from the
DM code into a board specific code or using a Kconfig option could
solve this issue.

Thanks,
Stefan