Adding support of ARM board B-L475E-IOT01A using STM32L475 SoC

Adding support of ARM board B-L475E-IOT01A using STM32L475 SoC

[Inès Varhol]

Hello,

Along with my fellow student Arnaud Minier, we're looking to implement support for a new ARM board for a university project.

As of now we've have implemented a minimal version for the machine and the SoC without any syscfg, timers or usart implementation. 
We have looked at the relevant informations about the procedure to submit a patch, however we aren't sure if we should submit a patch now already, 
as a way to get acquainted with the procedure and expectations, or if we should rather implement more peripherals and submit the patch all at once.

For further details about project, the end-goal is to emulate a maximum of peripherals and be able to display an emulated LED matrix driven by the QEMU-emulated board.

How we're proceding for now is replicating code designed for the stm32f405 SoC and other specific stm32f4xx code and adapting it for the stm32l475 SoC (both are Cortex-M4 SoC). 
Is it alright if the patch commits reflect this copy-paste then incrementaly change details procedure ?


Of course, we would greatly appreciate any guidance, suggestions, or insights you may offer regarding our current progress and the best course of action. 
Moreover, if there are other pertinent issues we should consider, we are eager to learn and adapt our approach accordingly.

Thank you for your time and consideration.

Best regards,

Inès Varhol

Re: Adding support of ARM board B-L475E-IOT01A using STM32L475 SoC

[Peter Maydell]

On Mon, 6 Nov 2023 at 13:57, Inès Varhol <ines.varhol@telecom-paris.fr> wrote:
>
> Hello,
>
> Along with my fellow student Arnaud Minier, we're looking to implement support for a new ARM board for a university project.
>
> As of now we've have implemented a minimal version for the machine and the SoC without any syscfg, timers or usart implementation.
> We have looked at the relevant informations about the procedure to submit a patch, however we aren't sure if we should submit a patch now already,
> as a way to get acquainted with the procedure and expectations, or if we should rather implement more peripherals and submit the patch all at once.

You might as well send an RFC now if you have a minimal
working subset of devices. That will help you get used to the
process. If you haven't read
https://www.qemu.org/docs/master/devel/submitting-a-patch.html
that is our description of how it works.

> For further details about project, the end-goal is to emulate a maximum of peripherals and be able to display an emulated LED matrix driven by the QEMU-emulated board.
>
> How we're proceding for now is replicating code designed for the stm32f405 SoC and other specific stm32f4xx code and adapting it for the stm32l475 SoC (both are Cortex-M4 SoC).
> Is it alright if the patch commits reflect this copy-paste then incrementaly change details procedure ?

Generally speaking, no. The patch series as submitted should
be a sequence of self-contained changes which all do one
thing (eg "add SoC device framework", "add UART model";
"add new board model", etc). They shouldn't have extra
"fix this bug" or "change this thing" patches on top that
fix problems in earlier patches.

thanks
-- PMM