Introduce Bouffalo Lab SoC's #78795
Introduce Bouffalo Lab SoC's #78795
Conversation
|
The following west manifest projects have changed revision in this Pull Request:
⛔ DNM label due to: 1 added project Note: This message is automatically posted and updated by the Manifest GitHub Action. |
zephyrbot
added
manifest
manifest-hal_bouffalolab
DNM
nandojve
force-pushed
the
bflb/bflb_upstream
branch
3 times, most recently
from
36aa581 to
7b2500b
Compare
nandojve
force-pushed
the
bflb/bflb_upstream
branch
3 times, most recently
from
f026bea to
3ee0c70
Compare
nandojve
requested review from
mateusz-holenko,
kgugala and
pgielda
as code owners
zephyrbot
added
area: GPIO
area: Pinctrl
area: Interrupt Controller
area: Timer
zephyrbot
requested review from
carlocaione,
dcpleung,
edersondisouza,
fkokosinski,
gmarull and
henrikbrixandersen
Switch to use the riscv-privileged mode. Signed-off-by: Gerson Fernando Budke <[email protected]>
Add Bouffalo Lab pinctrl driver. Signed-off-by: Gerson Fernando Budke <[email protected]>
Add Bouffalo Lab serial driver. The driver uses pinctrl to configure pins and have power management capabilities. Signed-off-by: Gerson Fernando Budke <[email protected]>
Enable interrupt support in the driver. Signed-off-by: Gerson Fernando Budke <[email protected]>
Add Bouffalo Lab ISP console flash runner. This tool enable bootloader to flash devices using serial port. The blflash Rust tool can be found at https://github.com/spacemeowx2/blflash Signed-off-by: Gerson Fernando Budke <[email protected]>
Add initial version. Signed-off-by: Gerson Fernando Budke <[email protected]>
This replace the SDK 1.4.2 by a direct register access aproach. This means that future operations on hal_bouffalolab do not require any dependency of a SDK from Bouffalo Lab anymore. The code was inspired by the newer SDK 2.0. Signed-off-by: Camille BAUD <[email protected]> Signed-off-by: Gerson Fernando Budke <[email protected]>
Make all changes on the SoC to remove SDK dependency. Signed-off-by: Camille BAUD <[email protected]> Signed-off-by: Gerson Fernando Budke <[email protected]>
Update the BL60x cpu devicetree definitions. Signed-off-by: Camille BAUD <[email protected]> Signed-off-by: Gerson Fernando Budke <[email protected]>
Update pinctrl driver to be SDK independent. Signed-off-by: Camille BAUD <[email protected]> Signed-off-by: Gerson Fernando Budke <[email protected]>
Add Bouffalo Lab gpio driver. Signed-off-by: Camille BAUD <[email protected]> Signed-off-by: Gerson Fernando Budke <[email protected]>
Update serial driver to be SDK independent. Signed-off-by: Camille BAUD <[email protected]> Signed-off-by: Gerson Fernando Budke <[email protected]>
Add Bouffalo Lab ISP console flash runner. This tool enable bootloader
to flash devices using serial port.
The blflash Rust tool can be found at
https://pypi.org/project/bflb-mcu-tool
Signed-off-by: Camille BAUD <[email protected]>
Signed-off-by: Gerson Fernando Budke <[email protected]>
Move the board to the new SoC directory. Signed-off-by: Gerson Fernando Budke <[email protected]>
Use official flash tool by default. Signed-off-by: Gerson Fernando Budke <[email protected]>
Introduce Bouffalo Lab platform. Signed-off-by: Gerson Fernando Budke <[email protected]>
nandojve
force-pushed
the
bflb/bflb_upstream
branch
from
2f8e682 to
6cfc420
Compare
dts/riscv/bouffalolab/bl6.dtsi
Outdated
| }; | ||
| dtcm: dtcm@42014000 { | ||
| compatible = "zephyr,memory-region", "sifive,dtim0"; | ||
| reg = <0x42014000 DT_SIZE_K(48)>; | ||
| zephyr,memory-region = "DTCM"; | ||
| }; | ||
|
|
||
| sram0: memory@42020000 { | ||
| compatible = "mmio-sram"; | ||
| }; | ||
| sram1: memory@42030000 { |
There is a middle ground between squashing everything and losing the entire, original Bad news: squashing such renames, typo fixes and other noises ONLY while preserving git blame elsewhere requires a fair amount of git expertise and work, sorry about that. But reviewer manpower is generally more scarce and trumps that. The git command line is not ideal, look for a better git client. The good news is: this history cleanup experience is useful in very many open-source projects - especially the ones older than GitHub. This old issue is relevant: Generally speaking, if you only make an effort to clean the history then I bet you'll be surprised by how well this will be received. You can and probably should keep an archive of the original progression and history in some personal branch somewhere. Just for fun: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md (totally wrong) EDIT: a closer look shows only TWO authors in this entire PR. So it seems that you're blowing this credit/recognition complexity out of proportion. I mean here in this specific PR, not in general. |
| @@ -23,6 +23,8 @@ manifest: | |||
| url-base: https://github.com/zephyrproject-rtos | |||
| - name: babblesim | |||
| url-base: https://github.com/BabbleSim | |||
| - name: nandojve | |||
There was a problem hiding this comment.
this should never be in the commit history, I am not sure what exactly are we achieving by leaving something like that in the manifest. Manifest changes must be squashed and always point to a tree hosted by the zephyr project.
There was a problem hiding this comment.
Definitely, but there is no hal_bouffalolab yet. It is possible to use only one manifest version if we delay to introduce the board as one the latest commits. That will prevent bisect errors for this new platform because there won't be a target until the first board.
There was a problem hiding this comment.
Definitely, but there is no hal_bouffalolab yet.
Until there is, a PR pointing at your personal repo is a "demo" PR, not ready for merge yet. It should be demoted to a GitHub draft to make sure it cannot be merged and to be excluded from PR scrubbing and stats. The PR name should be adjusted accordingly. There's also a DNM label.
It is possible to use only one manifest version if we delay to introduce the board as one the latest commits.
Yes: bisectability requires that dependencies are always added before dependants. That's true no matter how many commits or PRs there are. It's fine if brand new code or HAL is not immediately tested yet but in the next commits/PRs coming right after.
The documentation had for a long time a section that specifically recommends to submit "smaller PRs" for review: https://docs.zephyrproject.org/latest/contribute/contributor_expectations.html#defining-smaller-prs Yet submitters keep submitting large PRs on a regular basis, sometimes very large ones. See a couple of very recent examples below. (Reminder: submitting a giant, draft PR for pure _testing_ purposes and NOT for review is a perfectly fine) The "natural" explanation is that submitters optimistically and wrongly believe that dumping a large amount of code at once onto reviewers will be dealt with faster than in smaller chunks. This is most likely a contributing factor but most people should quickly learn from bad experience. Yet we keep seeing large PRs on a regular basis. So there must be other factors too. Based on personal but fairly extensive git support experience, another top reason is likely git usability and some lack of git knowledge (neither the first nor the last time git usability would have a significant impact) To help with this, add to the existing git guide the simple command that lets split a large submission in several, smaller PRs. This can only help demystify and promote smaller PRs while barely growing the size of the documentation. While at it, also add a couple missing benefits of smaller PRs. Recent examples of large PRs: - In the controversial and giant PR zephyrproject-rtos#77368 (comment) the exhausted submitter wrote: > Every time any one person requests a rebase that changes the PR, > unless there's consensus, there's no mechanism (manual/project process > or built into GitHub) to know/prevent a different person from rejecting > the new changes. That PR had 21 commits (18 in the final version), 82 files changed and 400 (!) comments. The sheer size massively increased the likelihood of the problem described. Re-submitting it in smaller chunks would obviously have mitigated that problem. Yet that PR was never split and stayed huge...? - In this second example, a large PR was submitted with different authors. A disagreement emerged about squashing across different authors: zephyrproject-rtos#78795 (comment) If this PR had been split in smaller chunks, then the squashing discussion might have been avoided entirely. Whether squashing is good or bad in this particular case is irrelevant (and already discussed at great in length in zephyrproject-rtos#83117). What matters here is: the submitter lost that chance by submitting a larger PR with different authors. Signed-off-by: Marc Herbert <[email protected]>
|
will continue on #84173 |
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.
dt_bl10_devkit (from DOIT) - easy to find and startwill come in a future PR as requestedThis work is Co-Authored by Camille BAUD [email protected]
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.