From: Greg Ungerer <gerg@linux-m68k.org>
To: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>,
Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] m68k: disable SRAM at startup
Date: Thu, 5 Sep 2024 17:52:33 +1000 [thread overview]
Message-ID: <30445b83-50eb-40ae-a2db-43b98d0c3224@linux-m68k.org> (raw)
In-Reply-To: <20240904-fix-cf-virt-mem-sram-v1-1-fb007028d717@yoseli.org>
Hi JM,
On 5/9/24 00:26, Jean-Michel Hautbois wrote:
> Some of the internal SoC registers have a higher priority over the MMU
> virtual mappings. The SRAM bank is one of them. If the bootloader
> enables the internal SRAM at address 0x80000000, virtual memory access
> at this address will not hit the MMU - so no TLB data misses would
> occurr.
>
> Since 0x80000000 is the virtual start address of all applications that
> bit of memory is getting stomped over with inconsistent code and data
> access.
>
> Fix it by disabling the internal SRAM at startup.
>
> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
> Tested-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
> Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
I know this change fixed your specific problem, but it is not going
to work as a general solution.
For one not all ColdFire parts have an SRAM region and thus not all have
a valid %rambar register. Secondly some ColdFire parts (like the 5249)
have 2 SRAM regions, with mapping control registers named %rambar0
and %rambar1.
Some ColdFire uClinux applications use the mapped SRAM, so a blanket
disable is not the best idea in any case.
I am thinking it would be better to have a new Kconfig option that
allows disabling by the startup code for those ColdFire parts that
have SRAM (so appropriate "depends on"). That way it will only be
disable when that is what is needed. Maybe also have that configuration
allowing to configure and set the rambars so that a mapping
can be forced on if wanted.
Regards
Greg
> ---
> arch/m68k/coldfire/head.S | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/m68k/coldfire/head.S b/arch/m68k/coldfire/head.S
> index c6d7fd28c6023..3901a49c47c89 100644
> --- a/arch/m68k/coldfire/head.S
> +++ b/arch/m68k/coldfire/head.S
> @@ -207,6 +207,10 @@ _start:
> movec %d0,%CACR
> nop
>
> + movel #0,%d0
> + movec %d0,%rambar
> + nop
> +
> #ifdef CONFIG_MMU
> /*
> * Identity mapping for the kernel region.
>
> ---
> base-commit: 431c1646e1f86b949fa3685efc50b660a364c2b6
> change-id: 20240904-fix-cf-virt-mem-sram-abadb27fff2f
>
> Best regards,
next prev parent reply other threads:[~2024-09-05 7:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-04 14:26 [PATCH] m68k: disable SRAM at startup Jean-Michel Hautbois
2024-09-05 6:58 ` Philippe De Muyter
2024-09-05 7:52 ` Greg Ungerer [this message]
2024-09-05 14:03 ` Jean-Michel Hautbois
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=30445b83-50eb-40ae-a2db-43b98d0c3224@linux-m68k.org \
--to=gerg@linux-m68k.org \
--cc=geert@linux-m68k.org \
--cc=jeanmichel.hautbois@yoseli.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
/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