Re: [PATCH 1/2] stm32f100: Add the stm32f100 SoC

[Alistair Francis]

On Tue, Jun 15, 2021 at 7:15 PM Alexandre IOOSS <erdnaxe@crans.org> wrote:
>
>
>
> On 6/15/21 10:04 AM, Alistair Francis wrote:
> > On Tue, Jun 15, 2021 at 5:50 PM Alexandre IOOSS <erdnaxe@crans.org> wrote:
> >>
> >> On 6/15/21 9:41 AM, Alistair Francis wrote:
> >>> Aren't you missing some timers, like timer[5] 0x4000_0C00?
> >>>
> >>> Alistair
> >>
> >> I double-checked using the reference manual and the datasheet and there
> >> is not timer[5]:
> >> - page 36 of
> >> https://www.st.com/resource/en/reference_manual/cd00246267-stm32f100xx-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf
> >
> > Strange, https://www.st.com/resource/en/datasheet/stm32f100rc.pdf
> > describes Timer 5 and page 282 of the document you linked talks about
> > timer 5 as well.
> >
> > Alistair
> >
> >> - page 30 of https://www.st.com/resource/en/datasheet/stm32f100cb.pdf
> >>
> >> I believe ST is skipping numbers to guarantee that timer[n] will have a
> >> consistent address on different STM32 SoC.
> >>
> >> Thanks,
> >> -- Alexandre
> >>
>
>  From what I understand from other STM32F100xx reference manuals:
> I am implementing all peripherals in the STM32F100xx reference manual
> which match with what is actually in the STM32F100RB SoC (used in the
> STM32VLDISCOVERY).

Ah, my mistake. The STM numbering always confuses me.

>
> STM32F100RC SoC implements more peripherals (more USART, more
> timers...). Adding these peripherals in stm32f100.c means that the
> STM32VLDISCOVERY machine would have peripherals that does not exist on
> the real target. Do we want to avoid that?

Yep, this is fine as is.

>
> Should we keep stm32f100.c with the common subset of peripherals and
> extend it when a machine is using a variant with more peripherals?
>
> I believe this issue is also linked with what Philippe proposed: we
> could abstract STM32 SoC in the same way ATMEGA is abstracted. This
> would make a lot of sense since the STM32 family has a lot of
> similarities and we don't want to bloat QEMU with N times the same code.

I agree. That's the best way forward and I think it's a good goal. We
don't have to block this series on that though. If you would like to
work on a shared abstraction that would be great :)

Once the IRQs are fixed:

Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

Alistair

>
> Thanks,
> -- Alexandre
>