[U-Boot] [PATCH] sunxi: Add CONFIG_MACH_TYPE defines to sun4i, sun5i and sun7i

[Ian Campbell <ijc@hellion.org.uk>]

On Mon, 2014-10-13 at 14:55 +0200, Hans de Goede wrote:
> Many people are still using old linux-sunxi-3.4 kernels on sunxi devices,
> adding the proper MACH_TYPE defines for this allows people to switch to
> upstream u-boot, so that we can stop maintaining the linux-sunxi u-boot fork.
> 
> These machine-ids are all properly registered at:
> 
> http://www.arm.linux.org.uk/developer/machines/

/me thinks having a machine id per soc (as opposed to,er, per machine)
is a bit odd, but whatever:
Acked-by: Ian Campbell <ijc@hellion.org.uk>

> +#define CONFIG_MACH_TYPE		4104

The description of this in the machine registry is "interesting".

Further to our conversation last night about the need to know whether to
boot in hyp or svc mode for these older kernels... The 3.4 kernel entry
point has very early on (like in the first dozen instructions): 
       setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode
                                               @ and irqs disabled

IOW it should be dropping straight to svc mode.

So I'm not sure why it doesn't work for you. Perhaps u-boot is failing
to do some el1 level setup/teardown as we launch, e.g. flushing the svc
mode tlb, flushing caches etc. It's also possible there are simply bug
fixes from later kernels which are missing.

It might be interesting to try backporting:

        commit 80c59dafb1a9a86fa996e6e34d06b60567c925ca
        Author: Dave Martin <dave.martin@linaro.org>
        Date:   Thu Feb 9 08:47:17 2012 -0800
        
            ARM: virt: allow the kernel to be entered in HYP mode
        
              * Ensure that asynchronous aborts are masked at kernel entry.
                The bootloader should be masking these anyway, but this reduces
                the damage window just in case it doesn't.
            
              * Enter svc mode via exception return to ensure that CPU state is
                properly serialised.  This does not matter when switching from
                an ordinary privileged mode ("PL1" modes in ARMv7-AR rev C
                parlance), but it potentially does matter when switching from a
                another privileged mode such as hyp mode.
            
            This should allow the kernel to boot safely either from svc mode or
            hyp mode, even if no support for use of the ARM Virtualization
            Extensions is built into the kernel.
            
            Signed-off-by: Dave Martin <dave.martin@linaro.org>
            Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
        
[dropping all the #ifdef CONFIG_ARM_VIRT_EXT bits, makes the patch much
smaller/simpler and you don't actually want those bits anyway]

The second bullet there looks interesting.

It's probable that if you did this you would also want these followups:
2a552d5e63d7    ARM: 7549/1: HYP: fix boot on some ARM1136 cores
1ecec696c8bb    ARM: 7599/1: head: Remove boot-time HYP mode check for v5 and below
8e9c24a2b2e0    ARM: virt: avoid clobbering lr when forcing svc mode
0e0779da2233    ARM: 8053/1: kernel: sleep: restore HYP mode configuration in cpu_resume

Most of those would be pretty small backports once the
CONFIG_ARM_VIRT_EXT bits are nuked.

Ian.