On Mon, Jun 26, 2023 at 4:24 PM Alexandre IOOSS <[email protected]> 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
