| Message ID | 1413204935-9157-1-git-send-email-hdegoede@redhat.com |
|---|---|
| State | Accepted |
| Headers | show |
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.
On Mon, 13 Oct 2014 14:55:35 +0200 Hans de Goede <hdegoede@redhat.com> 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/ > > Signed-off-by: Hans de Goede <hdegoede@redhat.com> > --- > include/configs/sun4i.h | 1 + > include/configs/sun5i.h | 1 + > include/configs/sun7i.h | 1 + > 3 files changed, 3 insertions(+) > > diff --git a/include/configs/sun4i.h b/include/configs/sun4i.h > index 5611ecc..d0191a3 100644 > --- a/include/configs/sun4i.h > +++ b/include/configs/sun4i.h > @@ -15,6 +15,7 @@ > #define CONFIG_CLK_FULL_SPEED 1008000000 > > #define CONFIG_SYS_PROMPT "sun4i# " > +#define CONFIG_MACH_TYPE 4104 > > #ifdef CONFIG_USB_EHCI > #define CONFIG_USB_EHCI_SUNXI > diff --git a/include/configs/sun5i.h b/include/configs/sun5i.h > index 6066371..7b683e9 100644 > --- a/include/configs/sun5i.h > +++ b/include/configs/sun5i.h > @@ -15,6 +15,7 @@ > #define CONFIG_CLK_FULL_SPEED 1008000000 > > #define CONFIG_SYS_PROMPT "sun5i# " > +#define CONFIG_MACH_TYPE 4138 > > #ifdef CONFIG_USB_EHCI > #define CONFIG_USB_EHCI_SUNXI > diff --git a/include/configs/sun7i.h b/include/configs/sun7i.h > index a902b84..966cbd8 100644 > --- a/include/configs/sun7i.h > +++ b/include/configs/sun7i.h > @@ -16,6 +16,7 @@ > #define CONFIG_CLK_FULL_SPEED 912000000 > > #define CONFIG_SYS_PROMPT "sun7i# " > +#define CONFIG_MACH_TYPE 4283 > > #ifdef CONFIG_USB_EHCI > #define CONFIG_USB_EHCI_SUNXI This patch is just trying to remove the safety guards (which exist there for a reason!) without addressing the real compatibility issues. This is a very bad idea in my opinion. We can do a better job.
Hi, On 10/15/2014 12:48 PM, Siarhei Siamashka wrote: > On Mon, 13 Oct 2014 14:55:35 +0200 > Hans de Goede <hdegoede@redhat.com> 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/ >> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> include/configs/sun4i.h | 1 + >> include/configs/sun5i.h | 1 + >> include/configs/sun7i.h | 1 + >> 3 files changed, 3 insertions(+) >> >> diff --git a/include/configs/sun4i.h b/include/configs/sun4i.h >> index 5611ecc..d0191a3 100644 >> --- a/include/configs/sun4i.h >> +++ b/include/configs/sun4i.h >> @@ -15,6 +15,7 @@ >> #define CONFIG_CLK_FULL_SPEED 1008000000 >> >> #define CONFIG_SYS_PROMPT "sun4i# " >> +#define CONFIG_MACH_TYPE 4104 >> >> #ifdef CONFIG_USB_EHCI >> #define CONFIG_USB_EHCI_SUNXI >> diff --git a/include/configs/sun5i.h b/include/configs/sun5i.h >> index 6066371..7b683e9 100644 >> --- a/include/configs/sun5i.h >> +++ b/include/configs/sun5i.h >> @@ -15,6 +15,7 @@ >> #define CONFIG_CLK_FULL_SPEED 1008000000 >> >> #define CONFIG_SYS_PROMPT "sun5i# " >> +#define CONFIG_MACH_TYPE 4138 >> >> #ifdef CONFIG_USB_EHCI >> #define CONFIG_USB_EHCI_SUNXI >> diff --git a/include/configs/sun7i.h b/include/configs/sun7i.h >> index a902b84..966cbd8 100644 >> --- a/include/configs/sun7i.h >> +++ b/include/configs/sun7i.h >> @@ -16,6 +16,7 @@ >> #define CONFIG_CLK_FULL_SPEED 912000000 >> >> #define CONFIG_SYS_PROMPT "sun7i# " >> +#define CONFIG_MACH_TYPE 4283 >> >> #ifdef CONFIG_USB_EHCI >> #define CONFIG_USB_EHCI_SUNXI > > This patch is just trying to remove the safety guards (which exist > there for a reason!) without addressing the real compatibility > issues. Erm, no the mach_type-s are not "safety-guards", they are absolutely necessary to get old non devicetree kernels to work at all. With just this single patch, sunxi-3.4 kernels with fixed PLL5 support, will happily boot on sun4i and sun5i. And with the bootm_boot_mode patch + env setting sun7i will boot fine too. Regards, Hans
Hello Hans, On 16-10-14 10:50, Hans de Goede wrote: > [...] > Erm, no the mach_type-s are not "safety-guards", they are absolutely > necessary to get old non devicetree kernels to work at all. fyi: That is not strictly true, you should be able to do: setenv machid 4283 and it should work as well. Anyway I have no problem with the patch. Regards, Jeroen
On Thu, 16 Oct 2014 10:50:42 +0200 Hans de Goede <hdegoede@redhat.com> wrote: > Hi, > > On 10/15/2014 12:48 PM, Siarhei Siamashka wrote: > > On Mon, 13 Oct 2014 14:55:35 +0200 > > Hans de Goede <hdegoede@redhat.com> 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/ > >> > >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> > >> --- > >> include/configs/sun4i.h | 1 + > >> include/configs/sun5i.h | 1 + > >> include/configs/sun7i.h | 1 + > >> 3 files changed, 3 insertions(+) > >> > >> diff --git a/include/configs/sun4i.h b/include/configs/sun4i.h > >> index 5611ecc..d0191a3 100644 > >> --- a/include/configs/sun4i.h > >> +++ b/include/configs/sun4i.h > >> @@ -15,6 +15,7 @@ > >> #define CONFIG_CLK_FULL_SPEED 1008000000 > >> > >> #define CONFIG_SYS_PROMPT "sun4i# " > >> +#define CONFIG_MACH_TYPE 4104 > >> > >> #ifdef CONFIG_USB_EHCI > >> #define CONFIG_USB_EHCI_SUNXI > >> diff --git a/include/configs/sun5i.h b/include/configs/sun5i.h > >> index 6066371..7b683e9 100644 > >> --- a/include/configs/sun5i.h > >> +++ b/include/configs/sun5i.h > >> @@ -15,6 +15,7 @@ > >> #define CONFIG_CLK_FULL_SPEED 1008000000 > >> > >> #define CONFIG_SYS_PROMPT "sun5i# " > >> +#define CONFIG_MACH_TYPE 4138 > >> > >> #ifdef CONFIG_USB_EHCI > >> #define CONFIG_USB_EHCI_SUNXI > >> diff --git a/include/configs/sun7i.h b/include/configs/sun7i.h > >> index a902b84..966cbd8 100644 > >> --- a/include/configs/sun7i.h > >> +++ b/include/configs/sun7i.h > >> @@ -16,6 +16,7 @@ > >> #define CONFIG_CLK_FULL_SPEED 912000000 > >> > >> #define CONFIG_SYS_PROMPT "sun7i# " > >> +#define CONFIG_MACH_TYPE 4283 > >> > >> #ifdef CONFIG_USB_EHCI > >> #define CONFIG_USB_EHCI_SUNXI > > > > This patch is just trying to remove the safety guards (which exist > > there for a reason!) without addressing the real compatibility > > issues. > > Erm, no the mach_type-s are not "safety-guards", they are absolutely > necessary to get old non devicetree kernels to work at all. If it looks like a safety-guard, swims like a safety-guard, and quacks like a safety-guard, then it probably is a safety-guard. The users of the u-boot from the v2014.10 tag can't easily hurt themselves, because the old non-mainline 3.4 kernel will just refuse to boot. Yes, the users can easily patch the sources to add the machine id or provide it via the environment variable. But it requires some action from the user. This is kind of like a "no trespassing" tape, which can be easily stepped over. But a certain level of protection is still there. > With just this single patch, sunxi-3.4 kernels with fixed PLL5 support, > will happily boot on sun4i and sun5i. > > And with the bootm_boot_mode patch + env setting sun7i will boot fine too. Yes, it's a very simple problem. And multiple simple solutions are available. You just hastily picked one of them. And it has some unfortunate practical implications related to DRAM configuration opportunities, which I have already explained to you. As a custodian, you take full responsibility for your actions. If you think that this was the best choice, then so be it.
diff --git a/include/configs/sun4i.h b/include/configs/sun4i.h index 5611ecc..d0191a3 100644 --- a/include/configs/sun4i.h +++ b/include/configs/sun4i.h @@ -15,6 +15,7 @@ #define CONFIG_CLK_FULL_SPEED 1008000000 #define CONFIG_SYS_PROMPT "sun4i# " +#define CONFIG_MACH_TYPE 4104 #ifdef CONFIG_USB_EHCI #define CONFIG_USB_EHCI_SUNXI diff --git a/include/configs/sun5i.h b/include/configs/sun5i.h index 6066371..7b683e9 100644 --- a/include/configs/sun5i.h +++ b/include/configs/sun5i.h @@ -15,6 +15,7 @@ #define CONFIG_CLK_FULL_SPEED 1008000000 #define CONFIG_SYS_PROMPT "sun5i# " +#define CONFIG_MACH_TYPE 4138 #ifdef CONFIG_USB_EHCI #define CONFIG_USB_EHCI_SUNXI diff --git a/include/configs/sun7i.h b/include/configs/sun7i.h index a902b84..966cbd8 100644 --- a/include/configs/sun7i.h +++ b/include/configs/sun7i.h @@ -16,6 +16,7 @@ #define CONFIG_CLK_FULL_SPEED 912000000 #define CONFIG_SYS_PROMPT "sun7i# " +#define CONFIG_MACH_TYPE 4283 #ifdef CONFIG_USB_EHCI #define CONFIG_USB_EHCI_SUNXI
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/ Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- include/configs/sun4i.h | 1 + include/configs/sun5i.h | 1 + include/configs/sun7i.h | 1 + 3 files changed, 3 insertions(+)