[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d890eecc-97de-4abf-8e0e-b881d5db5c1d@gmail.com>
Date: Fri, 6 Dec 2024 12:23:38 +0100
From: Ferry Toth <fntoth@...il.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>,
Arnd Bergmann <arnd@...nel.org>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
Arnd Bergmann <arnd@...db.de>, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andy Shevchenko <andy@...nel.org>, Matthew Wilcox <willy@...radead.org>,
Sean Christopherson <seanjc@...gle.com>,
Davide Ciminaghi <ciminaghi@...dd.com>, Paolo Bonzini <pbonzini@...hat.com>,
kvm@...r.kernel.org
Subject: Re: [PATCH 08/11] x86: document X86_INTEL_MID as 64-bit-only
Hi,
Op 04-12-2024 om 19:55 schreef Andy Shevchenko:
> +Cc: Ferry
>
> On Wed, Dec 4, 2024 at 12:31 PM Arnd Bergmann <arnd@...nel.org> wrote:
>> From: Arnd Bergmann <arnd@...db.de>
>>
>> The X86_INTEL_MID code was originally introduced for the
>> 32-bit Moorestown/Medfield/Clovertrail platform, later the 64-bit
>> Merrifield/Moorefield variant got added, but the final
> variant got --> variants were
>
>> Morganfield/Broxton 14nm chips were canceled before they hit
>> the market.
> Inaccurate. "Broxton for Mobile", and not "Broxton" in general.
>
>
>> To help users understand what the option actually refers to,
>> update the help text, and make it a hard dependency on 64-bit
>> kernels. While they could theoretically run a 32-bit kernel,
>> the devices originally shipped with 64-bit one in 2015, so that
>> was proabably never tested.
> probably
>
> It's all other way around (from SW point of view). For unknown reasons
> Intel decided to release only 32-bit SW and it became the only thing
> that was heavily tested (despite misunderstanding by some developers
> that pointed finger to the HW without researching the issue that
> appears to be purely software in a few cases) _that_ time. Starting
> ca. 2017 I enabled 64-bit for Merrifield and from then it's being used
> by both 32- and 64-bit builds.
>
> I'm totally fine to drop 32-bit defaults for Merrifield/Moorefield,
> but let's hear Ferry who might/may still have a use case for that.
Do to the design of SLM if found (and it is also documented in Intel's
HW documentation)
that there is a penalty introduced when executing certain instructions
in 64b mode. The one I found
is crc32di, running slower than 2 crc32si in series. Then there are
other instructions seem to runs faster in 64b mode.
And there is of course the usual limited memory space than could benefit
for 32b mode. I never tried the mixed (x86_32?)
mode. But I am building and testing both i686 and x86_64 for each Edison
image.
I think that should at minimum be useful to catch 32b errors in the
kernel in certain areas (shared with other 32b
archs. So, I would prefer 32b support for this platform to continue.
> ...
>
>> - Moorestown MID devices
> FTR, a year or so ago it was a (weak) interest to revive Medfield, but
> I think it would require too much work even for the person who is
> quite familiar with HW, U-Boot, and Linux kernel, so it is most
> unlikely to happen.
>
> ...
>
>> Select to build a kernel capable of supporting Intel MID (Mobile
>> Internet Device) platform systems which do not have the PCI legacy
>> - interfaces. If you are building for a PC class system say N here.
>> + interfaces.
>> +
>> + The only supported devices are the 22nm Merrified (Z34xx) and
>> + Moorefield (Z35xx) SoC used in Android devices such as the
>> + Asus Zenfone 2, Asus FonePad 8 and Dell Venue 7.
> The list is missing the Intel Edison DIY platform which is probably
> the main user of Intel MID kernels nowadays.
Despite the Dell Venue 7 originally running a 32b Android kernel (I
think), I got it run linux/Yocto in 64 bits.
> ...
>
>> - Intel MID platforms are based on an Intel processor and chipset which
>> - consume less power than most of the x86 derivatives.
> Why remove this? AFAIK it states the truth.
>
>
Powered by blists - more mailing lists