From: "Jiaxun Yang" <jiaxun.yang@flygoat.com>
To: "Jinyang He" <hejinyang@loongson.cn>,
"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
"John Crispin" <john@phrozen.org>
Cc: "linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] MIPS: Remove detect_memory_region()
Date: Wed, 24 Feb 2021 23:40:28 +0800 [thread overview]
Message-ID: <987b0dc5-9306-4271-afc0-7c44dba644b7@www.fastmail.com> (raw)
In-Reply-To: <1614171720-13221-1-git-send-email-hejinyang@loongson.cn>
On Wed, Feb 24, 2021, at 9:02 PM, Jinyang He wrote:
> detect_memory_region() was committed by Commit 4d9f77d25268 ("MIPS: add
> detect_memory_region()"). Then it was equipped by Commit dd63b00804a5
> ("MIPS: ralink: make use of the new memory detection code") and
> Commit 9b75733b7b5e ("MIPS: ath79: make use of the new memory detection
> code"). Its code is based on early ath79 platform code.
>
> What puzzles me is that how memcmp() detect the memory region. If `break`
> was touched, the function could make sense. That means memcmp() should
> return zero. Otherwise, the loop will be end by size > sz_max.
>
> I have tested detect_memory_region() on Loongson64 3A3000. On our design,
> kseg0 low 256MB maps real memory and kseg0 high 256MB maps IO/PCI. The
> function runs and last stopped on kseg1 where is uncached. In this process
> memcmp also returned non-zero when detected kseg0 high 256MB. Then I did
> another thing. memcpy first and test memcmp then (after &_end). It works
> well on 3A3000 but badly on 3A4000. Maybe because kseg0 high 256MB maps
> IO/PCI and it is dangerous to write like write memory.
>
> At last, read memory from where is not memory region may always return 0.
> (Or trigger exception.) This function have been used several years and
> seems no error occur. Maybe it's a fallback way.
That is not true for other platforms like ath79 or mtk.
They'll wrap around or return 0xffffffff for out of boundary accessing.
Loongson does not apply to this case as it have special "Address Window"
design to accurately describe address regions.
Any access beyond described windows will be handled by MC and return 0 or random stuff.
Again, please don't make changes because you can.
Thanks.
- Jiaxun
next prev parent reply other threads:[~2021-02-24 16:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-24 13:02 [PATCH RFC] MIPS: Remove detect_memory_region() Jinyang He
2021-02-24 15:40 ` Jiaxun Yang [this message]
2021-02-26 1:37 ` Jinyang He
2021-02-26 6:52 ` Jiaxun Yang
2021-02-26 7:10 ` Jinyang He
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=987b0dc5-9306-4271-afc0-7c44dba644b7@www.fastmail.com \
--to=jiaxun.yang@flygoat.com \
--cc=hejinyang@loongson.cn \
--cc=john@phrozen.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=tsbogend@alpha.franken.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