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

[Stefan Roese]

Adding Simon to Cc...

On 11.04.19 14:07, Baruch Siach wrote:
> Hi Pierre,
> 
> On Thu, Apr 11, 2019 at 01:45:51PM +0200, Pierre Bourdon wrote:
>> On Thu, Apr 11, 2019 at 11:21 AM Stefan Roese <sr at denx.de> wrote:
>>>> However, this is
>>>> called *after* spl_init, which triggers a DM scan. So at the point
>>>> where the DM subsystem is aware of the translation offset, drivers
>>>> might have already cached addresses (priv->base) or even performed
>>>> initialization (the TWSI i2c module does some configuration at bind
>>>> time).
>>>
>>> Yes, you might be correct here. Thanks for spotting. This might
>>> be the root cause for the I2C binding hang reported by Baruch
>>> (added to Cc):
>>>
>>> https://marc.info/?l=u-boot&m=155462955329578&w=2
>>>
>>> Is this the same issue that you have noticed?
>>
>> Yes, the original symptom I was debugging was indeed the mvtwsi I2C
>> bind handler causing an early freeze in SPL. That patch from Baruch
>> seems like it's trying to address the exact same issue. Thanks for
>> pointing it out.
>>
>> 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.
> 
> I guess that calling dm_set_translation_offset() before spl_init would fail
> because dm_root is not initialized yet. Is that correct?

Yes, I pretty much suspect so too.

> I could not find the
> code that initializes dm_root. The correct fix would probably involve setting
> translation_offset at the earliest possible point.

Something like this, yes. Or use a callback in the DM infrastructure
at the time where this translation offset is needed to get a board
specific value here. I remember that I first had another solution
for this (perhaps similar to a callback or some Kconfig option). But
Simon suggested to move into this API that we have right now (IIRC).

Simon, what are your thoughts about this issue here with the
translation offset (hen egg problem)?

Thanks,
Stefan