public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2 V2] arm926: Flush the data cache before disabling it.
Date: Mon, 30 Jan 2012 07:39:15 +0100	[thread overview]
Message-ID: <4F263B13.2090403@denx.de> (raw)
In-Reply-To: <CABkLObp3hwmYUjN5HjghCH=O6Agh6MBQUiv=-V8Tyk_rEO5HxA@mail.gmail.com>

Hello Christian,

Christian Riesch wrote:
> Hi all,
> 
> On Fri, Jan 27, 2012 at 7:33 PM, Tom Rini <tom.rini@gmail.com> wrote:
>> So, what do we want to do here?  We really want to get this fix in so
>> we can get the hawkboard SPL changes in, and the other platforms /
>> fixups that are gated by that.
>>
>> If I can sum it up, in the relevant section of code we have incorrect
>> comments and the init code is not following what the manual says the
>> correct sequence is.  However, given the (potentially wide) impact the
>> changes would have, Albert had previously requested making the change
>> opt-in (but I believe this request came before the "the manual says we
>> must do ...").  If this is still the case?  If so, can we get an
>> updated patch?  Thanks!
> 
> A few thoughts:
> 
> 1) Before commit ca4b55800ed74207c35271bf7335a092d4955416 the low
> level initialization code that we are discussing here was only
> executed if CONFIG_SKIP_LOWLEVEL_INIT is not defined. For ARM926EJS
> the relevant section in start.S looked like this
> 
> #ifndef CONFIG_SKIP_LOWLEVEL_INIT
> flush caches
> turn off dcache, do some other configurations of the CPU, enable icache
> call the SoC specific lowlevel_init
> #endif
> 
> For DA850 SoCs we had no lowlevel_init routine and therefore
> CONFIG_SKIP_LOWLEVEL_INIT defined in all board configurations. The
> lowlevel initialization was done by TI's UBL boot loader. Now we have
> boards that don't use UBL (e.g. enbw_cmc, calimain, da850evm when used
> with the SPL), therefore we need some lowlevel init. Most important
> configuration is enabling icache, otherwise u-boot startup gets really
> slow.
> 
> Since commit ca4b55800ed74207c35271bf7335a092d4955416 it is
> 
> flush caches
> turn off dcache, do some other configurations of the CPU, enable icache
> #ifndef CONFIG_SKIP_LOWLEVEL_INIT
> call the SoC specific lowlevel_init
> #endif
> 
> So the change that has a big impact is already done and in mainline.

Yep.

> Perhaps we should revert that change and instead remove
> CONFIG_SKIP_LOWLEVEL_INIT from the da850 board config files. But since
> we don't need the lowlevel_init function for DA850 SoCs we must either
> add a dummy function or add some additional defines that allow
> removing the CONFIG_SKIP_LOWLEVEL_INIT define without calling
> lowlevel_init. Any suggestions how such defines should be called or
> how the logic behind them should be so it doesn't cause breakage of
> existing boards?

or we should introduce a "CONFIG_SKIP_CPU_CRIT_INIT" define, which
if defined, prevent the jump to cpu_init_crit ... so we have the same
behaviour as before commit "ca4b55800ed74207c35271bf7335a092d4955416"

Boards which have problems with cpu_crit_init, should define
this new define ... but it would be better to find out, what
is really going on here ...

> What do you think? Or is reverting to dangerous since we would change
> the behavior of start.S twice if we do so?

See comment above. I can send such a patch for this, if we decide to go
this direction ... as I need the cpu_init_crit part for the enbw_cmc
board, but do not need the branch to "lowlevel_init" ...

> 2) The current version of Sughosh's patch does not change the logic
> behind the LOWLEVEL_INIT defines but just fixes the code to agree with
> ARM's manual. Instead of invalidating the cache it now is flushed. I
> think we should therefore merge his patch (@Tom: Yes, the manual says
> we must do.). The big change that Albert fears was already done
> earlier in commit ca4b55800ed74207c35271bf7335a092d4955416. And while
> we are doing this we also get the comments right.

What do you mean with commit "ca4b55800ed74207c35271bf7335a092d4955416"?
I could not find it in mainline ...

> 3) As Sughosh pointed out, the current code changes the V bit
> (location of exceptions). Sughosh's patch removes this code that does
> this change.  I'm not sure if this is correct or not, so maybe you,
> Tom, could put your TI hat on again and clarify this?

Yes, I am also not sure, what to do with this V Bit ...

> 4) The current code turns on icache. This is great since my board
> executes u-boot directly from flash until it relocates itself and thus
> the startup time is greatly reduced by using icache. However, there is
> this CONFIG_SYS_ICACHE_OFF define. Should the code be changed to
> respect this define?

Yep, that should be done. Default should be icache on, so we do
not change exisiting behaviour.

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

  reply	other threads:[~2012-01-30  6:39 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-09 18:25 [U-Boot] [PATCH 1/2] Flush the date cache before disabling it Sughosh Ganu
2012-01-09 18:41 ` Mike Frysinger
2012-01-09 18:51   ` Sughosh Ganu
2012-01-10 18:12 ` [U-Boot] [PATCH 1/2 V2] arm926: Flush the data " Sughosh Ganu
2012-01-10 20:07   ` Marek Vasut
2012-01-11  6:20     ` Sughosh Ganu
2012-01-11 10:47       ` Marek Vasut
2012-01-11 12:11         ` Sughosh Ganu
2012-01-11 12:42           ` Marek Vasut
2012-01-11 13:31             ` Sughosh Ganu
2012-01-11 13:51               ` Marek Vasut
2012-01-11 13:52                 ` Marek Vasut
2012-01-11 14:50                   ` Sughosh Ganu
2012-01-11 15:01                     ` Marek Vasut
2012-01-11 15:09                       ` Sughosh Ganu
2012-01-11 18:50                         ` Marek Vasut
2012-01-11 21:07                           ` Christian Riesch
2012-01-11 22:13                             ` Marek Vasut
2012-01-12  5:56                               ` Christian Riesch
2012-01-12  6:29                                 ` Sughosh Ganu
2012-01-14  9:09                                   ` Albert ARIBAUD
2012-01-14 17:18                                     ` Christian Riesch
2012-01-12 12:03   ` Christian Riesch
2012-01-12 13:53     ` Sughosh Ganu
2012-01-12 14:04       ` Christian Riesch
2012-01-12 14:43         ` Sughosh Ganu
2012-01-14 17:20           ` Christian Riesch
2012-01-14 18:02             ` Sughosh Ganu
2012-01-13  8:06   ` Christian Riesch
2012-01-13  8:26     ` Sughosh Ganu
2012-01-13 14:41       ` Tom Rini
2012-01-13 17:23         ` Sughosh Ganu
2012-01-13 15:29       ` Heiko Schocher
2012-01-13 17:38         ` Sughosh Ganu
2012-01-13 18:19           ` Aneesh V
2012-01-14  7:45             ` Sughosh Ganu
2012-01-15  8:13           ` Heiko Schocher
2012-01-16 17:57           ` Tom Rini
2012-01-17  6:39             ` Heiko Schocher
2012-01-17  6:46             ` Sughosh Ganu
2012-01-17 15:27               ` Tom Rini
2012-01-19  6:53                 ` Sughosh Ganu
2012-01-19 10:17                   ` Aneesh V
2012-01-19 11:30                     ` Christian Riesch
2012-01-19 11:54                       ` Aneesh V
2012-01-20  7:28                         ` Christian Riesch
2012-01-20  8:52                           ` Aneesh V
2012-01-20  9:21                             ` Christian Riesch
2012-01-20 12:13                               ` Aneesh V
2012-01-20 12:48                                 ` Christian Riesch
2012-01-20 13:06                                   ` Aneesh V
2012-01-27 18:33                                     ` Tom Rini
2012-01-29 13:36                                       ` Christian Riesch
2012-01-30  6:39                                         ` Heiko Schocher [this message]
2012-01-30  8:10                                           ` Christian Riesch
2012-01-30  9:04                                             ` Sughosh Ganu
2012-01-30 10:38                                           ` Christian Riesch
2012-01-30  7:06                                         ` Sughosh Ganu
2012-01-30 17:03                                         ` Tom Rini
2012-01-31  4:09                                           ` Sughosh Ganu
2012-01-31 13:58                                           ` Christian Riesch
2012-01-20 11:56                           ` Tom Rini
2012-01-13 15:06     ` Heiko Schocher
2012-01-13 17:22       ` Sughosh Ganu
2012-01-14  7:49   ` [U-Boot] [PATCH 1/2 V3] " Sughosh Ganu
2012-01-14  9:02     ` Albert ARIBAUD
2012-01-14  9:21       ` Sughosh Ganu
2012-01-14 10:34         ` Albert ARIBAUD
2012-01-14 14:02     ` [U-Boot] [PATCH 1/2 V4] " Sughosh Ganu
2012-02-18 15:41       ` Albert ARIBAUD
2012-02-18 18:51         ` [U-Boot] [PATCH 1/2 V3] " Christian Riesch
2012-02-19  8:31           ` Albert ARIBAUD
2012-01-20  9:22   ` [U-Boot] [PATCH 1/2 V2] " James W.

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=4F263B13.2090403@denx.de \
    --to=hs@denx.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox