[PATCH v6 6/9] ARM: vexpress: Motherboard RS1 memory map support

[David Vrabel]

On 19/01/12 13:21, Pawel Moll wrote:
> Hi,
> 
> Sorry about loooong delay - I've been on holiday.
> 
> On Wed, 2012-01-04 at 16:35 +0000, David Vrabel wrote:
>> On 15/12/11 14:02, Pawel Moll wrote:
>>> This patch adds support for RS1 memory map based Versatile Express
>>> motherboard.
>>>
>> [...]
>>> --- a/arch/arm/mach-vexpress/include/mach/debug-macro.S
>>> +++ b/arch/arm/mach-vexpress/include/mach/debug-macro.S
>>> @@ -10,12 +10,41 @@
>>>   * published by the Free Software Foundation.
>>>   */
>>>  
>>> -#define DEBUG_LL_UART_OFFSET	0x00009000
>>> +#define DEBUG_LL_PHYS_BASE		0x10000000
>>> +#define DEBUG_LL_UART_OFFSET		0x00009000
>>> +
>>> +#define DEBUG_LL_PHYS_BASE_RS1		0x1c000000
>>> +#define DEBUG_LL_UART_OFFSET_RS1	0x00090000
>>> +
>>> +#define DEBUG_LL_VIRT_BASE		0xf8000000
>>>  
>>>  		.macro	addruart,rp,rv,tmp
>>> -		mov	\rp, #DEBUG_LL_UART_OFFSET
>>> -		orr	\rv, \rp, #0xf8000000	@ virtual base
>>> -		orr	\rp, \rp, #0x10000000	@ physical base
>>> +
>>> +		@ Check the MMU state
>>> +#if defined(CONFIG_MMU)
>>> +		mrc	p15, 0, \tmp, c1, c0	@ SCTRL
>>> +		tst	\tmp, #1		@ MMU enabled?
>>> +		moveq	\tmp, #DEBUG_LL_PHYS_BASE
>>> +		movne	\tmp, #DEBUG_LL_VIRT_BASE
>>> +#else
>>> +		mov	\tmp, #DEBUG_LL_PHYS_BASE
>>> +#endif
>>> +
>>> +		@ PL011 present in "original" place?
>>> +		orr	\tmp, \tmp, #DEBUG_LL_UART_OFFSET
>>> +		ldr	\tmp, [\tmp, #0xfe0]	@ PeriphID0
>>
>> This doesn't work with CONFIG_EARLY_PRINTK=y on a system with the RS1
>> memory map.  
> 
> It does for me:
> 
> # zcat /proc/config.gz | grep EARLY_PRINTK
> CONFIG_EARLY_PRINTK=y
> # cat /proc/device-tree/motherboard/arm,v2m-memory-map && echo
> rs1     
> #

earlyprintk needs to be on the kernel command line to enable it.
Without this option it will work fine.

> Can you tell me what exactly is going wrong in your case? Does it hang
> without any warning? Do you get at least part of the boot log? Can you
> send me (privately probably) your kernel config?

The only output is from the zImage decompressor.

It's a synchronous data fault and DFAR is 0xf8009fe0.

>>  __create_page_tables has only mapped the single physical
>> page at 0x1c090000 and thus the test for the UART in the other memory
>> map faults.
> 
> I investigated this when writing the code and I vaguely remember it was
> fine, partly by accident. I'll dig in again and let you know my
> findings.

It's also a problem when running as a guest under a hypervisor as there
won't be any stage 2 translation table entries for non-existent peripherals.

I think there needs to be someway of finding out from the DTB which UART
to use.

David