From: York Sun <yorksun@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Commit 294b91a5817147d4b7f47be2ac69bac2a1f26491 broke mpc85xx
Date: Wed, 1 Oct 2014 09:27:48 -0700 [thread overview]
Message-ID: <542C2B84.1090706@freescale.com> (raw)
In-Reply-To: <CAPnjgZ1jSJd1GV0EFWhvaQvYxdsQ7kJ5yEh5hLDyvED8Sp0xqw@mail.gmail.com>
On 10/01/2014 08:11 AM, Simon Glass wrote:
> Hi York,
>
>
> On 30 September 2014 22:06, York Sun <yorksun@freescale.com> wrote:
>> Simon,
>>
>> I didn't notice until today the commit
>> 294b91a5817147d4b7f47be2ac69bac2a1f26491 broke at least T4240QDS. I have
>> narrowed down to these two lines in common/board_r.c
>>
>> initr_barrier,
>> initr_malloc,
>>
>> If I move these two lines below this part
>>
>>
>> #if defined(CONFIG_SYS_INIT_RAM_LOCK) && defined(CONFIG_E500)
>> initr_unlock_ram_in_cache,
>> #endif
>>
>>
>> U-boot boots OK on T4240QDS (I can see the prompt). But if I move them
>> anywhere above this initr_unlock_ram_in_cache, it hangs the core when
>> initializing PCI. It may break other mpc85xx platforms but I didn't have
>> time to check more today. I haven't figured out why you have to move these
>> two lines up. Please take a close look.
>
> I could adjust this so that the ordering changes only when driver model is used.
>
> This would be a case of putting '#ifdef CONFIG_DM' around the first
> section, then repeating it later with '#ifndef CONFIG_DM'. You can see
> that I did this for stdio out of an abundance of caution.
>
> However, in the interests of supporting driver model on these
> platforms I wonder if it might be possible to move the cache logic
> earlier. I suspect that the unlock/invalidate should happen before
> post-relocation RAM is used.
>
> Please take a look and let me know if that might be possible.
> Otherwise we'll have to go with the fallback.
I can change init sequence as far as I put initr_unlock_ram_in_cache before
initr_malloc, T4240QDS still boots.
I examine the code but don't understand why I have to do so. P4080DS doesn't
suffer this issue. I am going to seek some help from Scott and other in-house
experts.
>
> BTW I don't have any of these boards. If there is one that is readily
> and cheaply available, or if you have an old one you can send me, I'd
> be happy to test on this and take a closer look at driver model
> support.
I checked but we don't have surplus. This board is relatively new and it sells
for $4000. I will keep an eye on it.
York
next prev parent reply other threads:[~2014-10-01 16:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-01 4:06 [U-Boot] Commit 294b91a5817147d4b7f47be2ac69bac2a1f26491 broke mpc85xx York Sun
2014-10-01 15:11 ` Simon Glass
2014-10-01 16:27 ` York Sun [this message]
2014-10-01 16:37 ` Simon Glass
2014-10-01 16:52 ` York Sun
2014-10-01 18:01 ` Simon Glass
2014-10-01 18:25 ` York Sun
2014-10-02 2:15 ` Scott Wood
2014-10-02 3:29 ` York Sun
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=542C2B84.1090706@freescale.com \
--to=yorksun@freescale.com \
--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