<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 24, 2023 at 3:30 PM Karel Gardas <karel@functional.vision> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
  Hello Kinsey,<br>
<br>
honestly I don't know what to do about this patch. Let me explain a bit <br>
history behind STM32h7. It was originally submitted by embedded brains <br>
guys (Sebastian main, Christian added few things later) supporting the <br>
only eval board of that time stm32h743-eval(2). Sebastian also added <br>
support for nucleo with h743zi and Robin Mueller fixed several things on <br>
that. So this was 2 boards supported. Then I came and added support for <br>
3 more boards where two was with 2 BSPs variants each (one for M7 and <br>
one for M4). Due to amount of code in #ifdef for various boards we (my <br>
customer and me) have decided to de-cpp code a bit and divide it into <br>
different supported board directories. Basically we have also followed a <br>
lead by embedded brains guys and their imxrt bsps family (and boards <br>
directory). This was accepted and now you have this boards directory <br>
with different boards providing just as lean as possible configuration <br>
in C files sharing some common generic in bspstarthooks.c from start <br>
subdirectory.<br>
<br>
So basically the idea was to avoid complex #ifdefs and rather copy clean <br>
C files around. (as much as possible, realistically).<br>
<br>
Now, your patch seems to be going a bit in reverse direction and I do <br>
not see clearly the motivation behind it, why do you do that this way?<br>
<br>
I mean, you edit peripherals clock for stm32h743-eval(2) board BSP. <br>
AFAIK this file is not reused on any other BSP variant (different board) <br>
at all.<br>
The board in question (stm32h743-eval) supports only UART1 on its <br>
ST-Link or DB-9 canon connection. The UART1 is shared between those two <br>
mechanisms, which one is used, you define by jumper placed on the board. <br>
There is no other UART1 connector provided on the board. So I do not see <br>
reason why you add all other UARTs into #ifdefs for this particular <br>
board/bsp variant? And hence my question about your motivation and where <br>
you are heading...<br></blockquote><div><br></div><div>Given that, I now understand the confusion. I have a board in hand that will never 
see an upstream BSP and I was hoping to be able to configure the base 
STM32H7 BSP for it, but what I interpreted as the "base" STM32H7 BSP is not actually a generic base BSP. I was also contemplating moving more of the peripheral configuration into shared files since the enable/disable configuration items are already there and it would be convenient for the various BSPs to exist as some custom code and then a selection of presets for those configuration items. I'll have to think about the best way forward for the project I'm working with.<br></div><div><br></div><div>Kinsey<br></div></div></div>