Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Jinyang He <hejinyang@loongson.cn>
To: Jiaxun Yang <jiaxun.yang@flygoat.com>,
	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: Fri, 26 Feb 2021 15:10:50 +0800	[thread overview]
Message-ID: <15ea0085-eaf6-13aa-9568-9405fe9d48b6@loongson.cn> (raw)
In-Reply-To: <ba014ac1-6a83-7b11-e9a7-e6ad9ba1aa62@flygoat.com>

On 02/26/2021 02:52 PM, Jiaxun Yang wrote:

> 在 2021/2/26 上午9:37, Jinyang He 写道:
>> On 02/24/2021 11:40 PM, Jiaxun Yang wrote:
>>
>>>
>>> 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
>>
>> Hi, Jiaxun,
>>
>> Thank you for answering this puzzle for me in detail.
>>
>> Assume that the machine has 8MB real memory and dm address is (base + 
>> 3M).
>> When size = 8MB, there will be a phenomenon of `wrap around`, the actual
>> content of (dm + 8M + 3M) is content of (dm + 3M), so it will trigger
>> `break`, right? At this time, the kernel will add 8M to the memory.
>
> Hi Jingyang,
>
> How can you boot kernel with 8M memory in present days ;-)
> (Ohh with respect to Nintendo64 developer who had proven it's possible)
>
> For what I can say, detect_memory_region exists because many devices
> doesn't have a way to pass memory size information from bootloader to
> kernel. Or their bootloader even don't care about memory size.
>
> Kernel needs it to get memory size correctly. Although it seems fragile.
>
> That's life, we must accept imperfect past and don't repeat it in future.
>
> Thanks.
>
> - Jiaxun
>
>
That's just a assume. Because it looks fresh to me.
Thank you very much. :-D

>>
>> Thanks,
>> Jinyang
>>


      reply	other threads:[~2021-02-26  7:11 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
2021-02-26  1:37   ` Jinyang He
2021-02-26  6:52     ` Jiaxun Yang
2021-02-26  7:10       ` Jinyang He [this message]

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=15ea0085-eaf6-13aa-9568-9405fe9d48b6@loongson.cn \
    --to=hejinyang@loongson.cn \
    --cc=jiaxun.yang@flygoat.com \
    --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