Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled

[Angelo Dureghello <angelo@sysam.it>]

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
> 
> 
>