Add board BananaPi F3

[pyavitz]

Information:
https://docs.banana-pi.org/en/BPI-F3/BananaPi_BPI-F3
https://gitee.com/bianbu-linux

Boot log: https://paste.armbian.com/ucabodotet.yaml
Linux dmesg: https://paste.armbian.com/exagihupok.yaml

Currently booting from SPI is an unknown.

Flashing u-boot to eMMC: (This is not apart of the PR and needs to be added in the future.)

echo 0 > /sys/block/mmcblk2boot0/force_ro
sleep .50
dd if="bootinfo_emmc.bin" of="/dev/mmcblk2boot0" bs=512 conv=notrunc
dd if="FSBL.bin" of="/dev/mmcblk2boot0" bs=512 seek=1 conv=notrunc
dd if="FSBL.bin" of="/dev/mmcblk2boot0" bs=512 seek=512 conv=notrunc
dd if="fw_dynamic.itb" of="/dev/mmcblk2" bs=512 seek=1280 conv=notrunc
dd if="u-boot.itb" of="/dev/mmcblk2" bs=512 seek=2048 conv=notrunc
sync

Tested:
Bluetooth and Wifi (useless without an ANT)
Ethernet (1 and 2)
PCIe
USB
HDMI
Debug UART

The only IMG I was able to build and test on was Ubuntu Noble Minimal. Not sure if that is a limitation of RISCV in the builder or a problem elsewhere. Neither Debian Sid or Ubuntu Noble Standard would build without error.

NOTE:
One major difference between this build and the others available else where is the use of SYSLINUX/EXTLINUX instead of the ENV file.

[ColorfulRhino]

So many patches and 2 million lines of code as well as some blobs 🤯

Since this PR is adding a whole new family, using only one commit `[Add board BananaPi F3] might not do the whoel thing justice :)
Maybe do at least two commits instead of a huge single one (add family, then add board).

[ColorfulRhino]

Maybe these blobs are better suited inside the packages/blobs directory?

[pyavitz]

I think we can safely move the firmware into armbian/firmware, including this elf file. It would still need to be available for the kernel build process and if moving it into packages/blobs makes people happier, that's fine by me.

[pyavitz]

So many patches and 2 million lines of code as well as some blobs 🤯

Since this PR is adding a whole new family, using only one commit `[Add board BananaPi F3] might not do the whoel thing justice :) Maybe do at least two commits instead of a huge single one (add family, then add board).

I'll be honest. "and I'm not trying to be a dick" If the commit isn't acceptable because of its size, it can just be rejected and closed. Submitting the PR in TWOS will be the same amount code, but just making me do extra work. I was asked if I could do the PR, so I did so. If its size is a problem, than someone else can pick it up and redo it how ever they see fit.

I've spent enough time working on this :)

Peace.

[ColorfulRhino]

So many patches and 2 million lines of code as well as some blobs 🤯
Since this PR is adding a whole new family, using only one commit `[Add board BananaPi F3] might not do the whoel thing justice :) Maybe do at least two commits instead of a huge single one (add family, then add board).

I'll be honest. "and I'm not trying to be a dick" If the commit isn't acceptable because of its size, it can just be rejected and closed.

Sorry, I wrote this in a way that can be easily misunderstood 😅 I was simply surprised whe I opened this PR that says "Add board x" and it was much larger than I expected, since the last few "add board x" PRs that I opened were basically just a board file 😄

Submitting the PR in TWOS will be the same amount code, but just making me do extra work.

It makes the history cleaner, as well as git blame:

When someone hovers over a line and sees that this was added by bananapi they might be confused. But when it says "add family keystone-k1", it's instantly clear that this line was part of the initial family addition.
This can be fixed in 1 minute with a quick git rebase -i though, so no worries. I'm not trying to make you do extra work, but save potential minutes and confusions for people looking at these files in the next years :)
But that's just my opinion regarding git history.

Just let me know and I'll do the work for you 😄

I was asked if I could do the PR, so I did so. If its size is a problem, than someone else can pick it up and redo it how ever they see fit.

I don't think size is a problem neccessarily. When this board reaches mainline, probably 95% of the patches and blobs can be removed again so it's not a permament thing.

I've spent enough time working on this :)

Appreciated!

Btw I have tested to build this board's kernel with the latest mainline 6.1 version. "Only" 9 of the patches are failing to apply. So whoever did these patches can likely port them over to the latest kernel version in a comparatively low amount of time, compared to the time it took to make all these patches :) (Before any misunderstanding happens, no I'm not saying you should do this work)

[pyavitz]

So many patches and 2 million lines of code as well as some blobs 🤯
Since this PR is adding a whole new family, using only one commit `[Add board BananaPi F3] might not do the whoel thing justice :) Maybe do at least two commits instead of a huge single one (add family, then add board).

I'll be honest. "and I'm not trying to be a dick" If the commit isn't acceptable because of its size, it can just be rejected and closed.

Sorry, I wrote this in a way that can be easily misunderstood 😅 I was simply surprised whe I opened this PR that says "Add board x" and it was much larger than I expected, since the last few "add board x" PRs that I opened were basically just a board file 😄

Submitting the PR in TWOS will be the same amount code, but just making me do extra work.

It makes the history cleaner, as well as git blame:

When someone hovers over a line and sees that this was added by bananapi they might be confused. But when it says "add family keystone-k1", it's instantly clear that this line was part of the initial family addition. This can be fixed in 1 minute with a quick git rebase -i though, so no worries. I'm not trying to make you do extra work, but save potential minutes and confusions for people looking at these files in the next years :) But that's just my opinion regarding git history.

Just let me know and I'll do the work for you 😄

I was asked if I could do the PR, so I did so. If its size is a problem, than someone else can pick it up and redo it how ever they see fit.

I don't think size is a problem neccessarily. When this board reaches mainline, probably 95% of the patches and blobs can be removed again so it's not a permament thing.

I've spent enough time working on this :)

Appreciated!

Btw I have tested to build this board's kernel with the latest mainline 6.1 version. "Only" 9 of the patches are failing to apply. So whoever did these patches can likely port them over to the latest kernel version in a comparatively low amount of time, compared to the time it took to make all these patches :) (Before any misunderstanding happens, no I'm not saying you should do this work)

Feel free to fixup whatever you want.

As for application of the patches further up the branch. I've been slowly working on that. Around rev .28 the PCIe becomes non-functional, so I stopped at that point. SpacemiT recently submitted a v1.0.3 to their github, which is apart of this PR, but I have yet to test it and see if that fixes anything up the line. Overall though the board becomes slightly unstable after 6.1.15.

There is this, so by 2027 we should be good. I guess ;)
https://lore.kernel.org/linux-riscv/20240618-hardwood-footrest-ab5ec5bce3cf@wendy/T/#t

[ColorfulRhino]

Feel free to fixup whatever you want.

I did (mainly splitting the initial commit into two), but can't push to your branch, so here you go: https://github.com/armbian/build/tree/BPI-F3-001 😄
(To add this: undo your last commits (can also use git reset ...) then checkout this linked branch and cherry pick all commits from there; alternatively just open a new PR from that branch, you should be able to)

Around rev .28 the PCIe becomes non-functional, so I stopped at that point. SpacemiT recently submitted a v1.0.3 to their github, which is apart of this PR, but I have yet to test it and see if that fixes anything up the line. Overall though the board becomes slightly unstable after 6.1.15.

Ah that's a shame, but maybe they will be able to improve it soon.

There is this, so by 2027 we should be good. I guess ;)
https://lore.kernel.org/linux-riscv/20240618-hardwood-footrest-ab5ec5bce3cf@wendy/T/#t

That's awesome! Even i fit's just a first step, this is an important one :)

[pyavitz]

Feel free to fixup whatever you want.

I did (mainly splitting the initial commit into two), but can't push to your branch, so here you go: https://github.com/armbian/build/tree/BPI-F3-001 😄 (To add this: undo your last commits (can also use git reset ...) then checkout this linked branch and cherry pick all commits from there; alternatively just open a new PR from that branch, you should be able to)

Around rev .28 the PCIe becomes non-functional, so I stopped at that point. SpacemiT recently submitted a v1.0.3 to their github, which is apart of this PR, but I have yet to test it and see if that fixes anything up the line. Overall though the board becomes slightly unstable after 6.1.15.

Ah that's a shame, but maybe they will be able to improve it soon.

There is this, so by 2027 we should be good. I guess ;)
https://lore.kernel.org/linux-riscv/20240618-hardwood-footrest-ab5ec5bce3cf@wendy/T/#t

That's awesome! Even i fit's just a first step, this is an important one :)

As long as all the work is in this new branch, you can just open a new PR and we can close this one.

[ColorfulRhino]

As long as all the work is in this new branch, you can just open a new PR and we can close this one.

No need, it just needed a sync :) Done.

[The-going]

PR armbian:main from pyavitz:BPI-F3-001

Maybe it's better to take the first steps here:
wip-spacemit

[The-going]

Stupid question. Why family:
LINUXFAMILY="keystone-k1"

[pyavitz]

Stupid question. Why family: LINUXFAMILY="keystone-k1"

It's my bad. The short of it is; I was working out of two WORK-DIR and for reasons changed it to keystone in the second. I ended up going with the second WORK-DIR and forgot to change it back to spacemit. I noticed it as well last night. It is an easy fix.

[pyavitz]

@The-going What do we wanna call it? spacemit or spacemit-k1?

There is also BOARDFAMILY. Should we keep that the same or change it?

[The-going]

I did (mainly splitting the initial commit into two), but can't push to your branch, so here you go: https://github.com/armbian/build/tree/BPI-F3-001 😄
(To add this: undo your last commits (can also use git reset ...) then checkout this linked branch and cherry pick all commits from there; alternatively just open a new PR from that branch, you should be able to)

Good. I'll take that as a basis. All the main work is done here.

When splitting commits for the kernel, I got more than 100 patches.
And I had to remove a lot of garbage from them.
And I want the patches to be presented as a series, similar to sunxi. If you gentlemen don't mind?

What do we wanna call it? spacemit or spacemit-k1?

There is also BOARDFAMILY. Should we keep that the same or change it?

I think spacemit is better.
k1 is a chip, but they have and will have others in the future.

[pyavitz]

I did (mainly splitting the initial commit into two), but can't push to your branch, so here you go: https://github.com/armbian/build/tree/BPI-F3-001 😄
(To add this: undo your last commits (can also use git reset ...) then checkout this linked branch and cherry pick all commits from there; alternatively just open a new PR from that branch, you should be able to)

Good. I'll take that as a basis. All the main work is done here.

When splitting commits for the kernel, I got more than 100 patches. And I had to remove a lot of garbage from them. And I want the patches to be presented as a series, similar to sunxi. If you gentlemen don't mind?

What do we wanna call it? spacemit or spacemit-k1?
There is also BOARDFAMILY. Should we keep that the same or change it?

I think spacemit is better. k1 is a chip, but they have and will have others in the future.

If you wanna take over the PR that's fine by me.

[The-going]

If you wanna take over the PR that's fine by me.

Maybe I put it wrong.
I thought that we would all do PR together in this BPI-F3-001 branch
or in this wip-spacemit branch until we decide that the code is satisfactory.
Then we will merge this branch into the main one.

As for my job, I would prefer to do patches for the kernel, u-boot.
And I would not like to contribute to the build system itself.
I haven't used it for over a year. It's difficult for me to read it today.

[The-going]

And I want the patches to be presented as a series, similar to sunxi. If you gentlemen don't mind?

Are there any objections?

[pyavitz]

If you wanna take over the PR that's fine by me.

Maybe I put it wrong. I thought that we would all do PR together in this BPI-F3-001 branch or in this wip-spacemit branch until we decide that the code is satisfactory. Then we will merge this branch into the main one.

As for my job, I would prefer to do patches for the kernel, u-boot. And I would not like to contribute to the build system itself. I haven't used it for over a year. It's difficult for me to read it today.

Well besides changing the BOARD and LINUXFAMILY and renaming some bits, not much else to do on that front concerning the build system. In the future we may want to add some of the extra firmware and services, but that can be done after.
https://gitee.com/organizations/bianbu-linux/projects

As for the patching you are welcome to clean that up. I only ask we keep it on EXTLINUX. It is more practical than using the ENV file. Unless you have some idea on how to make the boot.cmd file functional in its place?

[pyavitz]

If we keep the EXTLINUX bit we can boot from NVMe without much effort.

patrick@bananapif3:~$ lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mmcblk2      179:0    0  14.6G  0 disk 
└─mmcblk2p1  179:1    0  14.5G  0 part 
mmcblk2boot0 179:8    0     4M  1 disk 
mmcblk2boot1 179:16   0     4M  1 disk 
zram0        250:0    0     1G  0 disk [SWAP]
nvme0n1      259:0    0 238.5G  0 disk 
├─nvme0n1p1  259:1    0   412M  0 part /boot
└─nvme0n1p2  259:2    0   238G  0 part /

Basically erase the eMMC, flash u-boot to it, flash an img or transfer an SD install to the NVMe, pull the SD and it will then boot from NVMe. This should also work using SPI once its figured out.

[The-going]

I'll change them to spacemit. We gonna work out of my REPO or the ARMBIAN one? If mine I can give you access.

Let's start making pull requests from our repositories to the branch:
https://github.com/armbian/build/tree/wip-spacemit
Let's start making pull requests from our repositories to the branch.
It seems to me that this is a more correct approach.

[pyavitz]

I'll change them to spacemit. We gonna work out of my REPO or the ARMBIAN one? If mine I can give you access.

Let's start making pull requests from our repositories to the branch: https://github.com/armbian/build/tree/wip-spacemit Let's start making pull requests from our repositories to the branch. It seems to me that this is a more correct approach.

My gitfoo is not all that amazing. Can you handle this?

I made the change you requested.

[ColorfulRhino]

Let's start making pull requests from our repositories to the branch: https://github.com/armbian/build/tree/wip-spacemit
It seems to me that this is a more correct approach.

There is no correct or wrong approach, at least comparing the two approaches.

Armbian is currently doing Trunk Based Development: https://trunkbaseddevelopment.com/
If just by accident or on purpose, I don't know.

Also, since I'm already posting links, I'm just gonna leave this here since this (or similar posts) helped me personally on my journey 😄 :

• https://skerritt.blog/writing-better-commit-messages/
• https://github.blog/2022-06-30-write-better-commits-build-better-projects/

[The-going]

My gitfoo is not all that amazing. Can you handle this?

No problems!

I made the change you requested.

Thank you. I see and will try to make an image assembly.
I accepted the invite.
We will be able to do some complex things directly in your repository,
which may need to be redone before sending.

Let's start making pull requests from our repositories to the branch: https://github.com/armbian/build/tree/wip-spacemit
It seems to me that this is a more correct approach.

There is no correct or wrong approach, at least comparing the two approaches.

Nevertheless, you made the right move yourself.
You have split and sent the changes to a branch that is not the main one.

If I had sent the changes to this auxiliary branch from the very beginning,
then Patrick would not have had to do the duplicate work.
And you would not have to do the separation, but only give advice on the design.
That's the point.

Armbian is currently doing Trunk Based Development: https://trunkbaseddevelopment.com/

I raise both hands for this document.
The main branch (trunk) must always remain stable for assembly.

[The-going]

@pyavitz Which commit do the kernel patches correspond to?

No need to worry. I figured it out.

[pyavitz]

Progress.

patrick@bpif3:~$ uname -a
Linux bpif3 6.1.95 #1 SMP Sat Jun 22 14:52:26 EDT 2024 riscv64 GNU/Linux
patrick@bpif3:~$ lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mmcblk0      179:0    0  29.7G  0 disk 
└─mmcblk0p1  179:1    0  29.6G  0 part /
mmcblk2      179:8    0  14.6G  0 disk 
└─mmcblk2p1  179:9    0  14.5G  0 part 
mmcblk2boot0 179:16   0     4M  1 disk 
mmcblk2boot1 179:24   0     4M  1 disk 
zram0        250:0    0     1G  0 disk [SWAP]
nvme0n1      259:0    0 238.5G  0 disk 
├─nvme0n1p1  259:1    0   412M  0 part 
└─nvme0n1p2  259:2    0   238G  0 part

I had to revert a few things to get NVMe to come up though.

[The-going]

@pyavitz I can't find some files after applying all the patches to the kernel tree:
drivers/net/wireless/realtek/rtl8852be
drivers/net/wireless/aic8800
Was there a reason to skip them?

[pyavitz]

@pyavitz I can't find some files after applying all the patches to the kernel tree: drivers/net/wireless/realtek/rtl8852be drivers/net/wireless/aic8800 Was there a reason to skip them?

As far as I know they aren't actually required to bring up the board. Unless you know something I don't? The driver source for them is also HUGE, just like the rtl8852bs, so I left them out until it was decided what Armbian wanted to do about them.

[pyavitz]

This driver is questionable as well config USB_NET_ASIX. I removed it from my own builds, along with the edits made to drivers/net/usb/r8152.c. Also all that K1XPRO stuff could probs be torn out, as a lot of the menu options don't have a driver that correlates to it. Buts thats just nitpicking.

[pyavitz]

@The-going As for rtl8852bs; We could probably create a repo for that? It would decrease the overall size of the patch set by 51MB.

[The-going]

@pyavitz Alternatively, we can do the same as sunxi:
sunxi-6.1/series.conf#L120-L148
Initially, the driver was extracted as a set of patches,
but later the community decided to use and maintain it for all families.
It was marked (-) and stopped being used patching process.

[The-going]

The kernel build is successful, but:

[🌱] Compiling ATF
[🌱] Compiler version [ riscv64-linux-gnu-gcc 11.4.0 ]
[🌱] Started patching process for [ atf spacemit-bananapif3-legacy ]
......
[🔨]    CARRAY    lib/sbi/sbi_ecall_exts.c
[🔨]   Assembler messages:
[🔨]   Error: rv64imafdc_zicbom: unknown prefixed ISA extension `zicbom'
[🔨]    CC        lib/sbi/sbi_ecall.o
[🔨]    CC        lib/sbi/sbi_ecall_rfence.o
[🔨]   make: *** [Makefile:525: /home/leo/build/cache/sources/opensbi/v1.3/build/lib/sbi/riscv_hardfp.o] Error 1
[🔨]   make: *** Waiting for unfinished jobs....
[🔨]   Assembler messages:
[🔨]   Error: rv64imafdc_zicbom: unknown prefixed ISA extension `zicbom'
[🔨]   make: *** [Makefile:511: /home/leo/build/cache/sources/opensbi/v1.3/build/lib/sbi/riscv_locks.o] Error 1
[🔨]   Assembler messages:
[🔨]   Error: rv64imafdc_zicbom: unknown prefixed ISA extension `zicbom'
[🔨]   make: *** [Makefile:511: /home/leo/build/cache/sources/opensbi/v1.3/build/lib/sbi/riscv_atomic.o] Error 1
[🔨]   Assembler messages:
[🔨]   Error: rv64imafdc_zicbom: unknown prefixed ISA extension `zicbom'
[🔨]   lib/sbi/sbi_ecall_rfence.c:26: Error: unrecognized opcode `csrr s3,0xf14'
[🔨]   lib/sbi/sbi_ecall_rfence.c:58: Error: unrecognized opcode `csrr a5,0x680'
[🔨]   lib/sbi/sbi_ecall_rfence.c:51: Error: unrecognized opcode `csrr a5,0x680'
......

Compilation on VM ubuntu-22.04

leo@armbuild:~/build$ riscv64-linux-gnu-gcc --version
riscv64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

@pyavitz Which compiler (version) was used in your case?

[The-going]

Which compiler (version) was used in your case?

I saw:
Noble.

[pyavitz]

Which compiler (version) was used in your case?

I saw: Noble.

Indeed; Ubuntu Noble

[ColorfulRhino]

Compilation on VM ubuntu-22.04

leo@armbuild:~/build$ riscv64-linux-gnu-gcc --version
riscv64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

GCC11 is too old, you need to use GCC13 (which comes with Ubuntu 24.04) or GCC14.

Just tested to build a minimal Sid image, it compiles just fine:

Build command:
./compile.sh build BOARD=bananapif3 BRANCH=legacy RELEASE=sid EXPERT=yes KERNEL_CONFIGURE=no BUILD_MINIMAL=yes BUILD_DESKTOP=no EXTRAWIFI=no

Compiler:

riscv64-linux-gnu-gcc --version
riscv64-linux-gnu-gcc (Ubuntu 13.2.0-23ubuntu4) 13.2.0

Edit: (Don't use Debian Trixie, doesn't currently work because of missing packages, only Debian Sid builds fine)

[The-going]

 ____  ____  _   _____ _____ 
| __ )|  _ \(_) |  ___|___ / 
|  _ \| |_) | | | |_    |_ \ 
| |_) |  __/| | |  _|  ___) |
|____/|_|   |_| |_|   |____/ 
                             
Welcome to Armbian_community 24.8.0-trunk Noble with Linux 6.1.15-legacy-spacemit

No end-user support: built from trunk

System load:   37%              Up time:       0 min
Memory usage:  4% of 3.72G      IP:            192.168.100.101
CPU temp:      42�°C            Usage of /:    7% of 15G    

To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

leo@bananapif3:~$ armbianmonitor -m
Two CPU clusters are available for monitoring
Stop monitoring using [ctrl]-[c]
Time    CPU_cl0/CPU_cl1  load %cpu %sys %usr %nice %io %irq   Tcpu  C.St.

22:20:02  1600/1600 MHz  2.75  16%   6%   3%   0%   6%   0%  41,0 �°C  0/4
22:20:07  1600/1600 MHz  2.69   0%   0%   0%   0%   0%   0%  41,0 �°C  0/4
22:20:12  1600/1600 MHz  2.64   0%   0%   0%   0%   0%   0%  40,0 �°C  0/4^C

@pyavitz Patrick, you're doing great. Good job.

P.S. My kernel patches are more strongly separated.
There are more than a hundred of them, but they will give the same result.
I don't see any point in changing them now.

[pyavitz]

 ____  ____  _   _____ _____ 
| __ )|  _ \(_) |  ___|___ / 
|  _ \| |_) | | | |_    |_ \ 
| |_) |  __/| | |  _|  ___) |
|____/|_|   |_| |_|   |____/ 
                             
Welcome to Armbian_community 24.8.0-trunk Noble with Linux 6.1.15-legacy-spacemit

No end-user support: built from trunk

System load:   37%              Up time:       0 min
Memory usage:  4% of 3.72G      IP:            192.168.100.101
CPU temp:      42�°C            Usage of /:    7% of 15G    

To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

leo@bananapif3:~$ armbianmonitor -m
Two CPU clusters are available for monitoring
Stop monitoring using [ctrl]-[c]
Time    CPU_cl0/CPU_cl1  load %cpu %sys %usr %nice %io %irq   Tcpu  C.St.

22:20:02  1600/1600 MHz  2.75  16%   6%   3%   0%   6%   0%  41,0 �°C  0/4
22:20:07  1600/1600 MHz  2.69   0%   0%   0%   0%   0%   0%  41,0 �°C  0/4
22:20:12  1600/1600 MHz  2.64   0%   0%   0%   0%   0%   0%  40,0 �°C  0/4^C

@pyavitz Patrick, you're doing great. Good job.

Thanx.

P.S. My kernel patches are more strongly separated. There are more than a hundred of them, but they will give the same result. I don't see any point in changing them now.

Wow. You are way more patient than me.

As an aside, we've been trying to figure out this horrid load avg problem it currently has. So far we've discovered if you remove remoteproc and the board actually boots "it for obvious reasons doesn't always boot :)" the load avg is as it should be. I've looked over the file several times, but nothing has really stood out to me.

[pyavitz]

P.S. My kernel patches are more strongly separated. There are more than a hundred of them, but they will give the same result. I don't see any point in changing them now.

Does this mean you won't be making any changes to this PR?

[The-going]

P.S. My kernel patches are more strongly separated. There are more than a hundred of them, but they will give the same result. I don't see any point in changing them now.

Does this mean you won't be making any changes to this PR?

This means that I do not plan to change, add, or modify patches for the kernel in this pull request.

But I want to correct the story a little, if you don't mind.

[pyavitz]

P.S. My kernel patches are more strongly separated. There are more than a hundred of them, but they will give the same result. I don't see any point in changing them now.

Does this mean you won't be making any changes to this PR?

This means that I do not plan to change, add, or modify patches for the kernel in this pull request.

But I want to correct the story a little, if you don't mind.

I only ask as I am thinking about submitting another PR that is more segmented "and closing this one" and adding the BT firmware to armbian/firmware. Which I will then follow up with a $CURRENT linux patch set that will get us up to v6.1.95.

Linux bananapif3 6.1.95 #1 SMP Tue Jun 25 04:52:36 EDT 2024 riscv64 riscv64 riscv64 GNU/Linux

[The-going]

I only ask as I am thinking about submitting another PR that is more segmented "and closing this one" and adding the BT firmware to armbian/firmware. Which I will then follow up with a $CURRENT linux patch set that will get us up to v6.1.95.

Good. If you've already done it, then I'm all for it.

And leave this one for comparison for now.

[The-going]

@pyavitz Patrick, then please make commits for the files separately:
config/boards/*
config/kernel/*
config/source/*
packages/*
lib/*
patch/atf/*
patch/u-boot/*
patch/kernel/archive/*

[ColorfulRhino]

I only ask as I am thinking about submitting another PR that is more segmented "and closing this one" and adding the BT firmware to armbian/firmware. Which I will then follow up with a $CURRENT linux patch set that will get us up to v6.1.95.

Sounds nice!

@pyavitz Patrick, then please make commits for the files separately:
config/boards/*
config/kernel/*
config/source/*
packages/*
lib/*
patch/atf/*
patch/u-boot/*
patch/kernel/archive/*

Looks good!

Most important is imo the differentiation between the addition of the "Spacemit K1" SoC and the addition of the board "BananaPi F3" (which is what I did in the beginning)
But a more segmented approach is even better. Using atomic commits is great :)

[pyavitz]

v2 of this PR: #6800

This one can be closed.

[The-going]

v2 of this PR: #6800

This one can be closed.

Congratulations!
I feel like an old bearded turtle next to you. Well done.