Re: [PATCH] STM32F100: support different density lines

[Alistair Francis]

On Mon, Jun 26, 2023 at 4:24 PM Alexandre IOOSS <erdnaxe@crans.org> wrote:
>
> On 6/20/23 00:18, Lucas Villa Real wrote:
> > This patch adds support for the emulation of different density lines
> > (low, medium, and high). A new class property stm32f100-soc.density=
> > has been introduced to allow users to state the desired configuration.
> > That property is recognized by a new machine, stm32f1-generic. The SOC
> > is configured according to the following:
> >
> >     density=low       32 KB FLASH, 2 SPIs
> >     density=medium   128 KB FLASH, 2 SPIs
> >     density=high     512 KB FLASH, 3 SPIs
> >
> > With this code change we should be able to introduce richer features
> > to STM32F100, such as support for FSMC (so that a machine with more
> > RAM capacity can be properly emulated). FSMC is supported on high
> > density line devices only.
>
> Thanks a lot for the patches!
>
> STM32 families look very similar to each other, it makes great sense to
> take a generic approach rather than bloating QEMU with many machines.
>
> You patch proposes to create a "stm32f1-generic" machine. I believe we
> should rather name this machine "stm32f100-generic":
>    - STM32F101 has a XL-density line, STM32F100 does not have a
> XL-density line.
>    - STM32F100 high density line does not have the same maximum SRAM
> size, timers, USART numbers, clock frequencies and CEC peripherals as
> the STM32F101 high density line.
>
> Regarding the stm32vldiscovery machine, I am not against deprecating it
> if we warn users to use stm32f100-generic with density=medium. This
> makes sense as the development board does not add anything more than
> just some buttons and LED.
> Maybe "stm32vldiscovery" could become an alias for stm32f100-generic
> machine ?
> @Alistair: Do you have an opinion on aliasing the old machine? Is this
> something common in QEMU?

I don't think we have any aliased machines. I think we could do
something like that as well. So the "aliased" machines end up just
being pre-configured generic machines. We just want to do it in a way
to avoid code duplication where we can.

>
> In the long run, we should maybe rename "stm32f100-soc.c" to
> "stm32f1-soc.c" and add another class property to choose the sub-family.
> This would highly reduce potential code duplication.
> STM32F1 machines could take this structure:
>   - stm32f100-generic machine
>     - stm32f1-soc.family=f100 stm32f1-soc.density=low
>     - stm32f1-soc.family=f100 stm32f1-soc.density=medium
>       (alias stm32vldiscovery)
>     - stm32f1-soc.family=f100 stm32f1-soc.density=high
>   - stm32f101-generic machine
>     - stm32f1-soc.family=f101 stm32f1-soc.density=low
>     - stm32f1-soc.family=f101 stm32f1-soc.density=medium
>     - stm32f1-soc.family=f101 stm32f1-soc.density=high
>     - stm32f1-soc.family=f101 stm32f1-soc.density=xl
>   - stm32f102-generic machine
>     - stm32f1-soc.family=f102 stm32f1-soc.density=low
>     - stm32f1-soc.family=f102 stm32f1-soc.density=medium
>   - stm32f103-generic machine
>     - stm32f1-soc.family=f103 stm32f1-soc.density=low
>     - stm32f1-soc.family=f103 stm32f1-soc.density=medium
>       (alias stm32-nucleo-f103rb)
>     - stm32f1-soc.family=f103 stm32f1-soc.density=high
>     - stm32f1-soc.family=f103 stm32f1-soc.density=xl
> @Alistair: Would such modification make also sense regarding stm32f2 and
> stm32f4 families?

I think that's also ok, but it really only makes sense to do when we
have differentiating features implemented in QEMU.

Alistair

>
> Thanks,
> --
> Alexandre