From: "Pali Rohár" <pali@kernel.org>
To: Priyanka Jain <priyanka.jain@nxp.com>, Wolfgang Denk <wd@denx.de>,
u-boot@lists.denx.de
Subject: Re: Bug in p1_p2_rdb_pc? Caching-inhibited bit for initial L2 SRAM entry in TLB
Date: Wed, 13 Apr 2022 11:26:33 +0200 [thread overview]
Message-ID: <20220413092633.gmz4rqpiha4rwecb@pali> (raw)
In-Reply-To: <20220405085737.s34rfws7rg2zhe2n@pali>
On Tuesday 05 April 2022 10:57:37 Pali Rohár wrote:
> Hello!
>
> I suspect that there is a bug in board/freescale/p1_p2_rdb_pc/tlb.c code
> which configures TLB entry for initial L2 SRAM.
>
> When L2 is 512 kB long (e.g. on P2020) then U-Boot *unsets* MAS2_I bit
> for first half of L2 and for second half of L2 U-Boot *sets* this bit.
>
> See code:
> https://source.denx.de/u-boot/u-boot/-/blob/v2022.04/board/freescale/p1_p2_rdb_pc/tlb.c#L99-104
>
> I do not think that one part of L2 SRAM should be configured differently
> as second part. Therefore I think that this is a bug in U-Boot code.
>
> Do you know is correct configuration of TLB entries for initial L2 SRAM?
>
> MAS2_I is Caching-inhibited bit which is described as:
>
> Caching-inhibited:
> * 0 - Accesses to this page are considered cacheable.
> * 1 - The page is considered caching-inhibited. All loads and stores to
> the page bypass the caches and are performed directly to main
> memory. A read or write to a caching-inhibited page affects only
> the memory element specified by the operation.
Hello! I found EREF: A Programmer’s Reference Manual for Freescale Power
Architecture Processors Supports e500 core family (e500v1, e500v2,
e500mc, e5500, e6500) e200 core family document at NXP web:
https://www.nxp.com/files-static/32bit/doc/ref_manual/EREF_RM.pdf
And section "Cache and MMU Architecture" in part 7.3.1.2.2 Unable to
Lock Conditions (page 763) contains following information:
If no exceptions occur and no overlocking condition exists, an attempt
to set a lock can fail if any of the following is true:
• The target address is marked cache-inhibited, or the storage
attributes of the address uses a coherency protocol that does not
support locking
So for me it looks like that L2 SRAM (which works at L2 with locked
cache lines) should not set MA2_I (cache-inhibited) bit.
Any opinion? Or you do have some more information?
next prev parent reply other threads:[~2022-04-13 9:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-05 8:57 Bug in p1_p2_rdb_pc? Caching-inhibited bit for initial L2 SRAM entry in TLB Pali Rohár
2022-04-13 9:26 ` Pali Rohár [this message]
2022-04-14 21:05 ` Pali Rohár
2022-05-08 15:08 ` Pali Rohár
2022-05-12 8:41 ` Sinan Akman
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=20220413092633.gmz4rqpiha4rwecb@pali \
--to=pali@kernel.org \
--cc=priyanka.jain@nxp.com \
--cc=u-boot@lists.denx.de \
--cc=wd@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;
as well as URLs for NNTP newsgroup(s).