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

[Stefan Roese]

Hi Simon,

On 12.04.19 14:35, Simon Glass wrote:
> Hi,
> 
> On Thu, 11 Apr 2019 at 06:55, Stefan Roese <sr at denx.de> wrote:
>>
>> 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.
> 
> I don't like dm_set_translation_offset() very much. As some said, you
> have to call it after DM is up but before any affected drivers are
> bound. Tricky.

Yes. We missing this very important fact while implementing this
solution.

> How about adding a field in global_data, which can be set early, them
> have dm_init() pick it up?

Okay. I could come up with a patch for this quickly, I think. I would
prefer to add a Kconfig option for this, to not add size to GD for
platforms not needed this option. This could also save a bit of SPL
size as well.

Let me see...

Thanks,
Stefan