Introduce Bouffalo Lab SoC's

[nandojve]

This PR is intent to continue the work started at #37686. It rewrite the original work to be compatible with Zephyr 3.7. It extends the original work to complete remove the Bouffalo Lab SDK. This means that a re-write was made to use direct register access. This proves to drop ~8k Flash content.

• Introduces Bouffalo Lab BL-60x SoC.
• Add following drivers:
  • Pinctrl
  • Serial
  • GPIO
• Add following boards:
• bl604e_iot_dvk (from Bouffalo Lab) - can only be obtained directly with Bouffalo Lab
• dt_bl10_devkit (from DOIT) - easy to find and start will come in a future PR as requested
• Add bflb_mcu_tool runner to easy flash

This work is Co-Authored by Camille BAUD mail@massdriver.space

In the first wave we will introduce BL 60x/70x series, with uses E24 SiFive's core. On a second moment we will add the newer XuanTie-902/6/7 (LP/M/D) from T-Head BL61x/80x.

[zephyrbot]

The following west manifest projects have been modified in this Pull Request:

Name	Old Revision	New Revision	Diff
hal_bouffalolab	N/A	nandojve/hal_bouffalolab@main	N/A

Note: This message is automatically posted and updated by the Manifest GitHub Action.

[ycsin]

This work was made by 2 persons. My first try was on Ago/2021 when I used the Bouffalo Lab SDK 1.4.x, see #37686. I kept the code working over time locally and last year Camille started to extend the implementation. At first, the idea was to use the newer Bouffalo Lab SDK 2.0 but we saw that it will be a waist of time. Then we decided to use only registers and the code was partially rewritten by him from 82e3a9f forward. Because of this, the PR was submitted in a way that we can keep clear what each one made. This is the why the PR have intermediary stages.

A commit can have multiple sign-offs / authors, I don't see why we can't squash them and need to upstream local history, you can add a reference to a local branch with the history in the upstream commit message if you like.

About the below suggested order.

1. devicetree bindings
2. introduction of soc
3. introduction of board
4. drivers

IMHO this order does not fit. Usually it is necessary to introduce first the code that will be used by the module/board. This means that to have a serial device working you may need pinctrl and serial at minimum. On the same way, to flash a board you need to have the flasher available. I'm mentioning this because someone could then argue that we should start introducing an empty board and then fill all the details on each commit, which makes no sense because can create problems with git bisect. At end, the sequence must not be broke from a bisect perspective because you must not enable something that is not yet available in the tree.

I'm sorry that the sample order doesn't fit, I guess it is bisectable if you introduce the drivers first, followed by board, I believe I was referring to #56370 at the time of comment, but typed something wrong

not convinced, but don't want to block

[nandojve]

Rebased on top of RC-3.

This work was made by 2 persons. My first try was on Ago/2021 when I used the Bouffalo Lab SDK 1.4.x, see #37686. I kept the code working over time locally and last year Camille started to extend the implementation. At first, the idea was to use the newer Bouffalo Lab SDK 2.0 but we saw that it will be a waist of time. Then we decided to use only registers and the code was partially rewritten by him from 82e3a9f forward. Because of this, the PR was submitted in a way that we can keep clear what each one made. This is the why the PR have intermediary stages.

A commit can have multiple sign-offs / authors, I don't see why we can't squash them and need to upstream local history, you can add a reference to a local branch with the history in the upstream commit message if you like.

Hi @ycsin,

This is not about local history is about what each person contributed. If you squash the content you don't know what each person made. This is a Open Source project and we want to keep clear what each person made.

[nandojve]

• Update board docs
• drop bflb-mcu-tool from requirements to avoid problems with dependencies.

[fkokosinski]

Rebased on top of RC-3.

This work was made by 2 persons. My first try was on Ago/2021 when I used the Bouffalo Lab SDK 1.4.x, see #37686. I kept the code working over time locally and last year Camille started to extend the implementation. At first, the idea was to use the newer Bouffalo Lab SDK 2.0 but we saw that it will be a waist of time. Then we decided to use only registers and the code was partially rewritten by him from 82e3a9f forward. Because of this, the PR was submitted in a way that we can keep clear what each one made. This is the why the PR have intermediary stages.

A commit can have multiple sign-offs / authors, I don't see why we can't squash them and need to upstream local history, you can add a reference to a local branch with the history in the upstream commit message if you like.

Hi @ycsin,

This is not about local history is about what each person contributed. If you squash the content you don't know what each person made. This is a Open Source project and we want to keep clear what each person made.

If you want to keep attribution, you could always add Co-authored-by at the end of the commit message. It's a fairly wide-spread convention.

But the most important question is - does this PR include any commit that can result in a failed build? If so, then this will make bisecting unnecessarily difficult in the future.