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

[Ezequiel Garcia]

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?

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.
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar