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

[Simon Glass]

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.

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

Regards,
Simon