[PATCH v6] ARM: zImage: add support for ARMv7-M

[Ezequiel Garcia]

On 12/20/2014 07:48 PM, Stefan Agner wrote:
> On 2014-12-20 20:12, Ezequiel Garcia wrote:
>> Stefan,
>>
>> On 12/20/2014 10:33 AM, Stefan Agner wrote:
>>> On 2014-12-17 09:56, Uwe Kleine-König wrote:
>>>> From: Joachim Eastwood <manabian at gmail.com>
>>>>
>>>> This patch makes it possible to enter zImage in Thumb mode for ARMv7-M
>>>> (Cortex-M) CPUs that do not support ARM mode. The kernel entry is also
>>>> made in Thumb mode.
>>>>
>>>> Signed-off-by: Joachim Eastwood <manabian at gmail.com>
>>>> [ukl: fix spelling in commit log, return early in call_cache_fn]
>>>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig at pengutronix.de>
>>>> ---
>>>> Hello,
>>>>
>>>> I just picked up Joachim's patch and fixed the small concerns I had in
>>>> the last round.
>>>>
>>>> I thought about adding a wrapper for accessing the CPUID registers that
>>>> are located in cp15 on v7-A/R and memory mapped on v7-M. The
>>>> corresponding registers and their address are as follows:
>>>>
>>>> name		cp15 reg [1] on -A/R	address on -M
>>>> MIDR/CPUID  	CRm=c0, opc2=0  	0xe000ed00
>>>> PFR0   		CRm=c1, opc2=0  	0xe000ed40
>>>> PFR1   		CRm=c1, opc2=1  	0xe000ed44
>>>> DFR0   		CRm=c1, opc2=2  	0xe000ed48
>>>> AFR0   		CRm=c1, opc2=3  	0xe000ed4c
>>>> MMFR0  		CRm=c1, opc2=4  	0xe000ed50
>>>> MMFR1  		CRm=c1, opc2=5  	0xe000ed54
>>>> MMFR2  		CRm=c1, opc2=6  	0xe000ed58
>>>> MMFR3  		CRm=c1, opc2=7  	0xe000ed5c
>>>> ISAR0  		CRm=c2, opc2=0  	0xe000ed60
>>>> ISAR1  		CRm=c2, opc2=1  	0xe000ed64
>>>> ISAR2  		CRm=c2, opc2=2  	0xe000ed68
>>>> ISAR3  		CRm=c2, opc2=3  	0xe000ed6c
>>>> ISAR4  		CRm=c2, opc2=4  	0xe000ed70
>>>> ISAR5  		CRm=c2, opc2=5  	0xe000ed74
>>>>
>>>> But there is no nice translation and as cache handling is implementation
>>>> defined on v7-M anyhow there is not much use and I decided to just
>>>> return early in the cache function.
>>>>
>>>> This patch is only compile tested as I don't have a machine with enough
>>>> RAM to run a non-XIP kernel, so Tested-by tags are welcome.
>>>
>>> Hi Uwe,
>>>
>>> Tried the patch on Vybrid's M4 CPU. Since the M4 has full access to the
>>> DDR3 RAM, it is even possible to use AUTO_ZRELADDR for both CPU's: The
>>> Colibri VF61 has 256MB of RAM: A5 relocates to 0x80008000, M4 to
>>> 0x88008000.
>>>
>>> The uncompressing stage seems to work fine, however it seems I hit a
>>> different bug which is triggered by using the zImage: Freeing the memory
>>> location used by the compressed image seems to fail:
>>>
>>
>> Does this happen systematically for you?
> 
> Yes, that happens all the time, same address.
> 
>>
>> I tried this patch on a LPC4337 based board, and came across very
>> strange and random memory corruptions, ranging from hitting strange
>> WARN(), BUG(), to OOM, to unhandled exceptions.
>>
>> Rebuilding the kernel caused the different results (perhaps due to link
>> differences?).
>>
>> The problem is this machine is not yet mainlined, so I'm not yet sure
>> it's this patch the one to blame.
> 
> Does it happen for you with xipImage?
> 

Unfortunately, I haven't been able to prepare a XIP image and boot it.

> I had some issues with kuser helpers, which now are disabled by default
> for non-MMU systems:
> 
> http://www.spinics.net/lists/arm-kernel/msg374425.html
> 

Yeah, saw that, but my unhandled exceptions are different to that (and
different each time I build and boot a new kernel).

-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar