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