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

[Stefan Roese]

Hi Pierre,

On 10.04.19 22:19, Pierre Bourdon wrote:
> [cc: mvebu maintainers]
> 
> I've spent the best part of today trying to get upstream u-boot
> running on my Armada 835 device (Turris Omnia). I think in the process
> I might have uncovered a bug with SPL u-boot on these SoC.
> 
> mvebu is "special" in having a different memory map in SPL vs. "main"
> mode. The arch SPL initialization code calls dm_set_translation_offset
> to tell the DM subsystem how to translate addresses.

I remember working on this a few years ago, so my memory is still
at bit foggy here. ;)

> 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?
  
> This seems broken but I'm not experienced enough with u-boot to
> suggest a good fix here. Could someone confirm that at least I'm not
> completely off base with this analysis?

Yes, please see above. I believe you are correct here. This issue
was hidden until patch 173ec35191 (i2c: mvtwsi: disable i2c slave on
Armada 38x) introduced a driver bind function, which is called very
early, before the address translation has been changed.

I'm also not sure, how to best solve this issue (if I am correct).
We could rework patch 173ec35191 to move this out of this driver
into board specific code (or some other way). But this would not
solve the main issue, with the incorrect address translation at
binding time.

Does anyone else have an idea on this?

Thanks,
Stefan