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

[stefan@agner.ch (Stefan Agner)]

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@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@gmail.com>
>>> [ukl: fix spelling in commit log, return early in call_cache_fn]
>>> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@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?

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

--
Stefan