SOC Archive on lore.kernel.org
 help / color / Atom feed
From: Alexandre TORGUE <alexandre.torgue@foss.st.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>,
	Kevin Hilman <khilman@baylibre.com>, SoC Team <soc@kernel.org>,
	arm-soc <arm@kernel.org>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Marek Vasut <marex@denx.de>,
	Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: Re: [GIT PULL] STM32 DT changes for v5.11 #1
Date: Mon, 7 Dec 2020 17:20:57 +0100
Message-ID: <3bc1fce7-0c51-38a9-407b-5aa105d1162b@foss.st.com> (raw)
In-Reply-To: <CAK8P3a11yRgy9x-cHNDsuYfLPcg0YFs92T+BxzfNisOqjNCjNw@mail.gmail.com>

Hi Arnd

On 12/2/20 2:32 PM, Arnd Bergmann wrote:
> On Wed, Dec 2, 2020 at 12:00 PM Alexandre TORGUE
> <alexandre.torgue@foss.st.com> wrote:
>> On 11/27/20 8:42 PM, Arnd Bergmann wrote:
>>> On Fri, Nov 27, 2020 at 9:54 AM Alexandre TORGUE
>>> <alexandre.torgue@foss.st.com> wrote:
>>>>
>>>> Please consider this first round of STM32 DT updates for v5.11. As usual
>>>> main changed concern MPU part. Various fixes have been done, a new board
>>>> has been added for DH and USB type C support has been added for ST DK
>>>> boards.
>>>
>>> Out of curiosity, what is your impression of the state of the MCU port?
>>>
>>> It seems to me that STM32H7/STM32F7 is by far the most active NOMMU
>>> platform in mainline Linux (with some activity for j2 and recently rv64), but
>>> it's also much less active than it was a few years ago and slowly winding down
>>> further, presumably as other OSs are getting better and full-featured MPUs
>>> are getting almost as cheap.
>>
>> There is 2 kinds of activity around our MCU products: one coming from ST
>> team (as most of peripherals are common with our MPU, changes done for
>> MPU are reported to MCU). And another coming from external people using
>> those MCU boards (few people).
>> There are still improvements to do for those platforms like adding dma
>> support on cortex-M7 (which implies to use dedicated MPU region ...) but
>> I don't have as much time as I would like to work on this subject so it
>> is still pending.
>> I would say that stm32 mcu linux support continues to survive with
>> incoming patches and at rhythm of the incoming patches.
> 
> Ok, thanks for the background!
> 
>>> I also tried to find modern distro support, but I couldn't find anything that
>>> has the elf-fdpic changes that were merged into mainline gcc, instead
>>> it seems any user space is either on binfmt-flat or using elf-fdpic with
>>> ancient patched compilers that can build user space but no longer
>>> build the kernel (which now requires gcc-4.9 or higher), so I wonder if
>>> I'm looking in the wrong places, or if this just doesn't work.
>>
>> Some STM32 MCU are supported in buildroot (not all), using u-boot as
>> bootloader and binfmt-flat for user space. Concerning fdpic, IIRC
>> support has been added in buildroot but we don't use it yet for our STM32.
>>
>>> Overall, is this something where you only support existing users for
>>> as long as they are around, or do you keep seeing new products based
>>> on STM32F4/F7/H7?
>>
>> I just continue to support existing users and I don't plan to push
>> another STM32 MCU.
>>
>> Do you think we should better promote/support NOMMU
>> platform in  mainline?
> 
> No, I think what you do is absolutely appropriate given the current
> state: keep the existing users happy but minimise the work needed
> for that.
> 
> It would however be good if you could let everyone know once
> you notice a further decrease in interest over time, as I think we
> do want to retire NOMMU kernels eventually, and confine the users
> to stable kernels once there are few enough of them. Out of the
> remaining NOMMU architectures, this is what I observe:
> 
> - ARM: most activity is on stm32, once this one gets retired, the
>    other ones can probably go as well
> 
> -  m68k: actively maintained, but aging: the newest NOMMU
>     chip (MCF537x) is from 2007.
> 
> - SuperH: SH2/SH2A is practically dead, minimal J2 support
>    was added in 2016, apparently it is still work-in-progress
>    but progressing slowly
> 
> - riscv: K210 support was only added in 2020 and is
>    actively being worked on at the moment, as there are
>    very few affordable RISC-V systems at all. This might
>    change as soon as one can easily buy a cheap RV64
>    board with an MMU.
> 
> - microblaze: NOMMU support to be removed in v5.11 or v5.12
> 
> - h8300: there is talk of removing the architecture
> 
> - c6x: still (barely) maintained, but I could find no indication of
>    actual users
> 
> - xtensa: one defconfig has MMU disabled, but has always
>    failed to build as far as I can tell. Max has an out-of-tree
>    patch series for the ESP32, but has not updated it since
>    v5.6.
> 
> Overall, there is clearly still enough going on to keep it around
> for a while, but not much that anyone gets excited about.
> If you ever stop testing and updating the STM32 MCU platform,
> I think we should ask the other maintainers if any of the
> remaining platforms are important enough to keep NOMMU
> supported at all, or if one of the future LTS releases should be
> planned as the last  one to have a NOMMU option.

So let's continue like that for now. I'll keep you aware if I get new 
inputs on my side and if we observe some PR without MCU patches we could 
reconsider the question.

Cheers
Alex



>        Arnd
> 

  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-27  8:54 Alexandre TORGUE
2020-11-27 17:10 ` patchwork-bot+linux-soc
2020-11-27 19:42 ` Arnd Bergmann
2020-12-02 11:00   ` Alexandre TORGUE
2020-12-02 13:32     ` Arnd Bergmann
2020-12-07 16:20       ` Alexandre TORGUE [this message]
2020-12-07 16:31         ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3bc1fce7-0c51-38a9-407b-5aa105d1162b@foss.st.com \
    --to=alexandre.torgue@foss.st.com \
    --cc=a.fatoum@pengutronix.de \
    --cc=arm@kernel.org \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=khilman@baylibre.com \
    --cc=marex@denx.de \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=olof@lixom.net \
    --cc=soc@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

SOC Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/soc/0 soc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 soc soc/ https://lore.kernel.org/soc \
		soc@kernel.org
	public-inbox-index soc

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.lore.soc


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git