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