On Mon, Jul 24, 2023 at 3:30 PM Karel Gardas <karel@functional.vision> wrote:
> > Hello Kinsey, > > honestly I don't know what to do about this patch. Let me explain a bit > history behind STM32h7. It was originally submitted by embedded brains > guys (Sebastian main, Christian added few things later) supporting the > only eval board of that time stm32h743-eval(2). Sebastian also added > support for nucleo with h743zi and Robin Mueller fixed several things on > that. So this was 2 boards supported. Then I came and added support for > 3 more boards where two was with 2 BSPs variants each (one for M7 and > one for M4). Due to amount of code in #ifdef for various boards we (my > customer and me) have decided to de-cpp code a bit and divide it into > different supported board directories. Basically we have also followed a > lead by embedded brains guys and their imxrt bsps family (and boards > directory). This was accepted and now you have this boards directory > with different boards providing just as lean as possible configuration > in C files sharing some common generic in bspstarthooks.c from start > subdirectory. > > So basically the idea was to avoid complex #ifdefs and rather copy clean > C files around. (as much as possible, realistically). > > Now, your patch seems to be going a bit in reverse direction and I do > not see clearly the motivation behind it, why do you do that this way? > > I mean, you edit peripherals clock for stm32h743-eval(2) board BSP. > AFAIK this file is not reused on any other BSP variant (different board) > at all. > The board in question (stm32h743-eval) supports only UART1 on its > ST-Link or DB-9 canon connection. The UART1 is shared between those two > mechanisms, which one is used, you define by jumper placed on the board. > There is no other UART1 connector provided on the board. So I do not see > reason why you add all other UARTs into #ifdefs for this particular > board/bsp variant? And hence my question about your motivation and where > you are heading... > 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. Kinsey
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
