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: Sat, 12 Aug 2017 13:17:51 +0200 Message-ID: References: <30318b18-e955-1615-975e-9b378d3201b8@westnet.com.au> <0e1723eb-0724-7007-5b63-7d80112268a2@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]:59023 "EHLO sysam.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752031AbdHLLRy (ORCPT ); Sat, 12 Aug 2017 07:17:54 -0400 In-Reply-To: <0e1723eb-0724-7007-5b63-7d80112268a2@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 10/08/2017 09:06, Greg Ungerer wrote: > Hi Angelo, > > 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. 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 ? 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 ? Waiting your suggestion on how to proceed. Regards, Angelo Dureghello > Regards > Greg >