From mboxrd@z Thu Jan 1 00:00:00 1970 From: Angelo Dureghello Subject: Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled Date: Sun, 20 Aug 2017 15:26:50 +0200 Message-ID: References: <30318b18-e955-1615-975e-9b378d3201b8@westnet.com.au> <0e1723eb-0724-7007-5b63-7d80112268a2@westnet.com.au> <590226cf-890a-449b-6bd4-f461fff2938b@westnet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from sysam.it ([5.39.81.93]:33858 "EHLO sysam.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752866AbdHTN0w (ORCPT ); Sun, 20 Aug 2017 09:26:52 -0400 In-Reply-To: <590226cf-890a-449b-6bd4-f461fff2938b@westnet.com.au> Content-Language: en-US Sender: linux-m68k-owner@vger.kernel.org List-Id: linux-m68k@vger.kernel.org To: Greg Ungerer , Linux/m68k Hi Greg, On 20/08/2017 14:44, Greg Ungerer wrote: > Hi Angelo, > > On 18/08/17 01:02, Angelo Dureghello wrote: >> On 14/08/2017 06:16, Greg Ungerer wrote: >>> On 12/08/17 21:17, Angelo Dureghello wrote: >>>> On 10/08/2017 09:06, Greg Ungerer wrote: >>>>> On 10/08/17 01:32, Angelo Dureghello wrote: >>>>> [snip] >>>>>> sure, on this board http://sysam.it/cff_stmark2.html >>>>>> there are 128MB of ddr2. >>>>>> >>>>>> External SDRAM is accessible, at least without any mmc support enabled, >>>>>> from 0x40000000. >>>>>> >>>>>> I have following test config: >>>>>> >>>>>> GNU nano 2.8.6 File: arch/m68k/configs/stmark2_defconfig >>>>>> >>>>>> CONFIG_LOCALVERSION="stmark2-001" >>>>> [snip] >>>>>> >>>>>> >>>>>> I tried still yesterday a bit, but seems there is no much support for >>>>>> earlyprintk / low level debug for this architecture. >>>>>> >>>>>> In case i can try with a gpio toggling routine, at least to find >>>>>> where kernel stops. >>>>> >>>>> The attached patch, is a quick and dirty early console output method. >>>>> It works for me on the m5475, should work for you "as is" on the 5441x too. >>>>> >>>>> It is kind of an early printk. Of course it still needs the early >>>>> kernel boot to have succeeded before you will get anything much coming out. >>>>> But it is worth trying. >>>> >>>> Ok many thanks. Btw i used a __square(); function written in asm, so i am >>>> sure i see the gpio toggling in very early stages. >>>> >>>>> >>>>> I am wondering if the non-0 base RAM may be a problem. I have only run >>>>> the MMU enabled code on platforms with 0 based RAM so far. But lets see if >>>>> the early console trace attached gives us anything before digging into that. >>>>> >>>> >>>> This MCU has sdram area physically mapped at 0x4000 0000 so U-Boot, to be >>>> able to execute the kernel must load it to that location/area anyway. >>>> >>>> But i have seen that it is not a problem, after MMU is enabled in head.S >>>> the jump >>>> movel #_vstart,%a0 /* jump to "virtual" space */ >>>> jmp %a0@ >>>> >>>> works fine. Since that range is not hitting anything that is maintained >>>> physical, it can be translated into virtual without any issue. >>> >>> Yeah, it is not so much the initial start up that I think will >>> be the problem. More the setup of the MMU mapping tables later >>> in boot. >>> >>> >>>> After some hard debug, i see the execution stops at: >>>> >>>> asmlinkage __visible void __init start_kernel(void) >>>> ... >>>> setup_arch(&command_line); setup_mm.c >>>> ... >>>> paging_init(); mm/mcfmmu.c >>>> ... >>>> empty_zero_page = (void *) alloc_bootmem_pages(PAGE_SIZE); >>>> ^line 47 mcfmmu.c >>>> >>>> Inside alloc_bootmem_pages(), execution seems to end up finally to >>>> mm/bootmem.c and likely to alloc_bootmem_bdata(). >>>> In case i can still proceed to find the exact place where execution stops, >>>> but i suspect in the while(1), line 545. >>>> >>>> As a curious thing, i find in a different cf CPU code "m54xx.c" >>>> the following: >>>> >>>> void __init config_BSP(char *commandp, int size) >>>> { >>>> #ifdef CONFIG_MMU >>>> cf_bootmem_alloc(); >>>> mmu_context_init(); >>>> #endif >>>> Do also m5441x.c maybe need this calls ? >>> >>> Yes, you will need this. So that code above is only getting run when >>> configured for a 547x CPU family. Attached is a rework of that code >>> so that it will be run for all ColdFire MMU varients. Can you try >>> that out? >>> >>> >>>> Would be very nice to have MMU working. Strangely, i don't see any >>>> board_config with it enabled. Was it ever tested on some Coldfire ? >>> >>> Oh, yeah, I run this on a real M5475 EVB board for every kernel >>> mainline release, with and without MMU enabled. See the >>> arch/m68k/configs/m5475evb_defconfig, it will default to having >>> the MMU enabled. >>> >>> I have todays linux-4.13-rc5 running on it here now: >>> >>> # cat /proc/version >>> Linux version 4.13.0-rc5-00001-gb014090-dirty (gerg@goober) (gcc version 5.4.0 (GCC)) #1 Mon Aug 14 10:14:12 AEST 2017 >>> >>> # cat /proc/cpuinfo >>> CPU: ColdFire >>> MMU: ColdFire >>> FPU: ColdFire >>> Clocking: 264.1MHz >>> BogoMips: 264.19 >>> Calibration: 1320960 loops >>> # >>> >>> Regards >>> Greg >> >> Ok, i applied your patch, and still the kernel is hanging silently, >> so i started up a new debug session again. >> >> What is actually happening (after your patch has been applied) is: >> >> setup_arch() arch/m68k/kernel/setup_mm.c >> paging_init() >> memmap_init() mm/page_alloc.c >> memmap_init_zone() >> __init_single_page() >> set_page_links() include/linux/mm.h >> set_page_zone() >> kernel hangs silently on this line >> page->flags &= ~(ZONES_MASK << ZONES_PGSHIFT); >> >>> >> >> I am wondering how mmu works, so at the moment mmu is enabled, >> in head.S, i would expect that code compiled for 0x40001000 would >> not run, since jumps would be translated to some different physical >> addresses, but execution sill works. >> At the same, after enabling mmu i would expect .data vars to be >> invalid, since their address would be translated to a different >> location, while not, the init values of .data variables are still >> valid. In case, i am interested to understand this points. > > On the ColdFire the kernel relies on all RAM and IO peripheral > addresses) to "hit" the ACR registers - and essentially be passed > through as an identity physical = virtual mapping. If you look at > the operation of the memory address translation when virtual mode > is enabled (in the ColdFire MMU sections of the 5475 and 54411 > reference manual) you will see that addresses are checked in order > to be for the MMUBAR, RAMBAR, ACR, then MMU. > > For example a kernel address when in supervisor mode will hit > ACR1 or ACR3 the way we set them up in arch/m68k/coldfire/head.S. > And that is why you see kernel code and data still being valid after > the MMU is enabled in virtual mode. No TLB entries required for this. > > Looking at your call sequence above I can see that the physical > RAM start address being non-zero is going to come into play. I'll > dig into this a little more tomorrow see if I can figure out what > is going on. > Thanks for the kind clarifications. I'll look in this things too in next days, learning is always nice. Btw, about load/entry address, i have noticed a possible basic difference betweeen mcf5441x and mcf547x series: The second one (your cpu) is v4e and probably more recent i guess, and one major difference from datasheet seems to be that it is Harvard. So probably, for this reason, you can address ram from 0 there. > Regards > Greg > > Reagrds Angelo > > >