On Tue, Feb 28, 2017 at 5:07 PM, Bryan O'Donoghue <pure.logic@xxxxxxxxxxxxxxxxx> wrote: > On 28/02/17 13:36, Andy Shevchenko wrote: >> On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko >> <andy.shevchenko@xxxxxxxxx> wrote: >>> On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel >>> <ard.biesheuvel@xxxxxxxxxx> wrote: >>>> On 28 February 2017 at 12:29, Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> wrote: >>>>> On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote: >>> >>>> As I said before, I'd be ok with it if we select it compile time, >>>> i.e., no runtime logic that infers whether we are running on such a >>>> system or not, and no carrying both implementations in all kernels >>>> that have capsule loading built in. >>> >>> Actually it most likely that Quark kernel (kernel compiled to be run >>> on Quark) will be ever used on the rest of (modern) x86 since it's >>> 486+ architecture (kernel has specific option for it, 586TSC). >> >> + it's UP only! >> >>> So, we might just be dependent or chosen by Quark. >> > > Still though the current ia32 kernel runs on Quark and all other ia32 > systems. How come? Quark has a silicon bug (SMP kernel might oops) and it is not even i586! > It would be a pity/shame to make this feature dependent on > compiling a Quark specific kernel, after all its only a header on a > capsule as opposed to a large hardware-level architectural divergence. > > I'd still like us to try for a low-fat hook that would a big fat ia32 > kernel just work without having to force a user compile up a > Quark-specific kernel. Can you elaborate how to run i686 kernel (which is default for x86 32-bit AFAIK) on Quark? -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
