All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baruch Siach <baruch@tkos.co.il>
To: u-boot@lists.denx.de
Subject: [U-Boot] mvebu spl: translation offset set too late?
Date: Thu, 11 Apr 2019 15:07:18 +0300	[thread overview]
Message-ID: <20190411120718.4spy5oaolcm3hwf2@sapphire.tkos.co.il> (raw)
In-Reply-To: <CA+V6dmh4ifQ9_oA5GB9EGGyi7sBokpntzurzmcn6B7XOvhQy1g@mail.gmail.com>

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@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? I could not find the 
code that initializes dm_root. The correct fix would probably involve setting 
translation_offset at the earliest possible point.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

  reply	other threads:[~2019-04-11 12:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-10 20:19 [U-Boot] mvebu spl: translation offset set too late? Pierre Bourdon
2019-04-11  9:21 ` Stefan Roese
2019-04-11 11:45   ` Pierre Bourdon
2019-04-11 12:07     ` Baruch Siach [this message]
2019-04-11 12:26       ` Pierre Bourdon
2019-04-11 12:55         ` Stefan Roese
2019-04-12 12:35           ` Simon Glass
2019-04-12 13:14             ` Stefan Roese
2019-04-11 12:51       ` Stefan Roese

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190411120718.4spy5oaolcm3hwf2@sapphire.tkos.co.il \
    --to=baruch@tkos.co.il \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.