Hi Greg, Geert,
Sorry for late response and thanks for your reviews and comments,
These patchs can gives an overview of the work that *seem* required for MMU
support on 5441x, but clearly there still some unknown behaviour under
study.
It looks like the address translation is not always took into account by
HW, but this
needs a deeper investigation which is on going.
This is good to know the 5475 MMU support is Ok on latest kernel version.
I have checked deeper in datasheets to study differences. MMU are quite
similar,
but few differences are present.
At register level, there are additional bits on M5441x serie :
MMUCR[UVE] : User virtual mode enable.
0: Virtual mode activation based on MMUCR[EN], (default)
1: based on MMUCR[EN] && CPU *not* in Supervisor mode.
MMUCR[SAL] : Select ASID location
0: defined by ASID register, (default)
1: defined by MMUAR[9:2]
From my understanding of current CFV4e MMU support, I think the MMUCR[SAL]
needs to be set. ASID register is set in head.S but *not* used in
cf_tlb_miss() missed.
Regarding MMUCR[UVE], I think the default configuration is coherent with
address
translation requirement while running in kernel mode.
Another difference between M5441x & 5475 is Peripheral memory mapping
which is
relative to MBAR ( == 0xff000000 in defconfig ) register on 5475, and
fixed on M5441x.
Also, physical RAM is accessible from 0x40000000 on m5441x, and starts
at 0x0 on 5475.
Don't think it should have an impact on the virtual address translation
mechanism, but
if for some reason this is faulty or disable at some point, there may be
an "overlap"
between virtual and physical address space on 5441x which is not present
on 5475.
Just an assumption...
Other comments in threads as well.
Best Regards,
Yannick
Le 08/07/2015 16:07, Greg Ungerer a écrit :
Hi Yannick,
On 08/07/15 19:51, Yannick GICQUEL wrote:
Here is a patchset proposal for MMU support on Coldfire 5441x serie.
Nice.
This patchset allows building the mcfmmu on chip without FPU, enable the
elf binary support and report some code from m54xx to m5441x sources
files.
Also, it contains a proposal for uImage generation.
Functional status is OK on kernel v3.14.
But on v4.2-rc1, we observe a map_err exit fail in do_page_fault().
After bisecting, we point out the regression appears after the
vm_ops->map_pages() feature integration (introduced in 8c6e50b and
later)
I haven't looked in detail into this yet. But I can confirm
that it still works fine on a 5475 with MMU enabled.
Some other comments as replies to specific patches.
Regards
Greg
Your feedbacks are welcome on this.
Best Regards,
Yannick
Yannick GICQUEL (8):
m68k: coldfire: unlink FPU presence from MMU activation
m68k: fix build issue in setup_arch() when no FPU
m68k: add dummy dump_fpu() when FPU is not present
m68k: m5441x: add ColdFire 5441x CPU MMU memory init code
m68k: m5441x: fix ACR0 base address when MBAR is not present
m68k: m5441x: set rambar to end of SRAM physical addr space
m68k: mmu: add u-boot command line support in setup_arch()
m68k: uImage generation support
arch/m68k/Kconfig | 2 +-
arch/m68k/Kconfig.cpu | 4 +-
arch/m68k/Makefile | 8 +++-
arch/m68k/boot/Makefile | 45 ++++++++++++++++++++++
arch/m68k/coldfire/head.S | 9 +++++
arch/m68k/coldfire/m5441x.c | 47 +++++++++++++++++++++++
arch/m68k/include/asm/m54xxacr.h | 13 ++++++-
arch/m68k/kernel/process.c | 6 ++-
arch/m68k/kernel/setup_mm.c | 82
+++++++++++++++++++++++++++++++++++++++-
9 files changed, 209 insertions(+), 7 deletions(-)
create mode 100644 arch/m68k/boot/Makefile
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
