[PATCH] add STM32H7 BSP variant to support STM32H7B3I-DK board

[Sebastian Huber]

On 30/01/2022 20:41, Karel Gardas wrote:
> 
> Hello Sebastian,
> 
> I guess you will be in charge of reviewing this patch. Please allow me
> to explain motivation behind it plus add some questions.
> 
> You know I'd like to update STM32H7 HAL to the latest code provided by
> STMicro to be able to use it on my stm32h735g-dk board. Before doing
> that I'd like to have some reference working point of the current RTEMS
> HEAD. The problem is that so far supported nucleo board is unavailable
> anymore and stm32h743-eval(2) board is hard to find and not in the price
> range of hobby hacking anymore.
> So I purchased stm32h7b3i-dk which should be supported by HEAD HAL and
> this BSP variant is kind of what I needed to do in order to get that
> working.
> 
> Generally speaking I have two questions with regarding to code:
> 
> 1) I'm not sure about balance between adding parameters into the yaml
> files and between simply #ifdefing code for different bsp variants. E.g.
> U(S)ART config is clear, this belongs to yaml, power supply too. But
> then what about AHB clock divider? What about flash latency? Those are
> just one liners so they may go to yaml too (although not that user
> related), but then what about all those oscilator and peripherals
> configuration bits? I've rather #ifdefed those. So the question is: what
> to put into yaml and what to keep in C. >
> 2) system_stm32h7xx.c -- although this file should support several mcus
> from h7 family it looks like it is generated just for one particular
> board configuration. I've done some experiments, installed STMCubeIDE
> and generated few demos for few boards and compared the file:
> system_stm32h7xx.c -- it's the same name but different or slightly
> different content between demos. In submitted code I #ifdefed bsp
> variant code, but I'm not sure if we should not rename the file to
> system_stm32h743.c and create a new file for every MCU variant and then
> use yaml logic to conditionally include only the file related to
> selected variant/mcu variant. What's your opinion on that?

I guess there will be no perfect solution. It should be possible to pick 
up a BSP variant for an evaluation board and run the tests without 
having to touch BSP option values. It would be nice if the BSP can be 
configured to run on custom boards without having to change the BSP 
source code. This means that things should be configurable through BSP 
options and through application defined configuration data structures.

> 
> The submitted BSP variant code was tested by compiling all three BSP
> variants and by running stm32h7b3i-dk variant on my board. Only
> hello/ticker/paranoia/unlimited/malloctest were tested but provided no
> visible error/failure. IMHO submitted code may be committed as it is and
> question/issue to be solved later when adding/replacing with new HAL and
> adding new BSP variant to support h735g-dk board. But you are the man in
> charge here so you decide that...

The patch looks good. Please just split it into a couple of smaller pieces.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/