Add board BananaPi F3 (Platform SpacemiT) v2 #6800
Conversation
Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
SpacemiT Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
This gets compiled into the kernel and embedded in the initramfs. It will also be available on the finished img at /lib/firmware. Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
Tag: 1.3 Source: https://gitee.com/bianbu-linux/opensbi Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
Branch: v2022.10 Source: https://gitee.com/bianbu-linux/uboot-2022.10 Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
Linux 6.1.15 Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
Linux 6.1.y Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
github-actions
bot
added
Hardware
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
Very good job. |
|
Nice one 👍 Nit: The commit subjects should reflect if the commit is for either Banana Pi F3 or for the SoC Family (Spacemit K1). |
legacy: k1-x_deb1.dts Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
k1-bananapi-f3.dts Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
Removed bluetooth service and function as they are no longer required. Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
Signed-off-by: Patrick Yavitz <pyavitz@armbian.com>
|
I just tried the rtl8852bs driver with armsom sige5 and rk's 6.1 kernel and made it work with patch: |
What's against using vendor's KERNELSOURCE instead a mega patchset? This would mean almost no maintenance at all since stuff gets pulled automatically. This is what other vendor kernels do. Have you tested it? But if I were to download one image and had to decide between two kernels, an outdated one (6.1.15) and a recent one (6.1.95) , I would without hesitation choose the up-to-date one, if only for the fixes and security updates 😄
I don't get it, maybe we're talking about different things 😄 i just didn't understand this or what or who Leonid is:
|
If you want to talk about this topic, then please write me a private message on the forum |
| # SpacemiT K1 octa core RISC-V SoC 2GB/4GB RAM 8GB/16GB eMMC 4x USB3 2x GbE | ||
| BOARD_NAME="Banana Pi F3" | ||
| BOARDFAMILY="spacemit" | ||
| BOARD_MAINTAINER="" |
There was a problem hiding this comment.
is this supposed to be blank?
There was a problem hiding this comment.
I don't plan to be the official maintainer, so I left it empty. Do you want the job?
There was a problem hiding this comment.
Having it empty is correct -- Igor's secret script will PR updates to it later. Not-having it will block such machinery from working
There was a problem hiding this comment.
If the board does not have a maintainer attached, shouldn't it be .csc then?
|
Would you like me to make this adjustment? |
That's great! |
The related defconfig will need to be modified. That is beyond the scope of this PR. Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
Signed-off-by: Patrick Yavitz <pyavitz@xxxxx.com>
|
I've been working on an update, stay tuned 😄 |
|
@pyavitz Maybe you shouldn't have closed it? |
What's the point? Another PR was opened. If that is the approach that best fits Armbians needs, than so be it. |
Patrick, I suggest we just continue working on this branch in your repository. |
|
We will just do something while the community decides how to formalize and accept it. |
I just want one of these PR's to be accepted so that we can close the door on this. This could have been accepted days ago and adjustments made after the fact. Now we are at v3 and we are downloading from gitee and also pulling in a wireless repo? All to save 100MBs give or take on our armbian/build git clone. Unfortunately now we are downloading even more to build the kernel and wireless driver. This seems counterproductive to me; but... whatever. I'm sick of looking at this PR. |
It is also going beyond my (any of) concentration to review it ... I had a discussion with @pyavitz and @ColorfulRhino an hour ago regarding this PR. This is new SoC and its not expected that everything is pushed to perfection at the time of adding. There was a lot of discussions in those PRs and this is good, but let's not fragment this further. I will merge v3 of this PR, so we can make it available for more people that has hw. Also its easier to keep track when contributions are smaller. HW will remain unsupported / WIP until its decided otherwise. If image can be built and it boots with "some" functionality, I suggest its merged like "now". |
|
I didn't realize there were more discussions going on here 😅 I apologize if I annoyed anyone, that was not my intention. I also apologize if my earlier comments were not clear enough and led to misunderstandings. I will refrain from further comments on this topic but would like to explain my perspective on the size issue.
A general user who does not have any RISCV board is actually downloading less, not more. The build framework only downloads the kernel and driver when needed, which is consistent with the behavior of most boards and board families. Imagine if every vendor kernel and driver were patched-in using patches instead of being downloaded from repositories like https://github.com/armbian/linux-rockchip or the driver repos. This would significantly increase the repo size, potentially pushing it over 1GB. If someone wants to clone the repo to build an image for their RaspberryPi or OrangePi, they would have to download all the other unnecessary components. By downloading from repos dynamically, we avoid this issue. Additionally, the caching in Armbian works really well, thanks to whoever developed this.
For smaller adjustments, I fully agree. Returning to the example of patching-in all kernels and drivers, this approach would mean that all past kernels and drivers, even those deleted, would bloat the repo size due to Git's history storage. We already face this issue with some old blobs in the armbian/build git history. These files contribute to unnecessary repo size because of design choices made years ago (not blaming anyone; Armbian was likely much smaller back then, and its current popularity was hard to foresee 😄). GitHub recommends keeping repository sizes ideally below 1GB. Larger repository sizes can also slow down Git operations. For instance, working within the full Linux kernel repo can be very slow, and my IDE takes several seconds to display file histories and In summary, this is a complex topic, but I hope my explanation clarifies why size matters (at least in the context of Git), why I intervened and spent way too much time and effort on a family/board that I don't even own, and why we need to take the future (5+ years) into account for certain design choices. |
|
I understand everything perfectly. After discussion, it would be possible to make version 3 to merge into the main branch. Even if we add 3 gigabytes of new files and 1000 commits to this branch, after deleting it, What's done is done. |
I understand the argument and agree to an extent. I had made a comment "not sure if it was here or to Igor" that the wireless driver patch set was really large and would be better suited in a repo. With that said, the other patches don't amount to very much I'm fairly certain we are gonna be downloading way more from gitee :) The CURRENT patch dir is 16M. I'm not a mathematician, but if you add those two numbers together it doesn't seem like we are adding much to As to the argument of "this will affect other people", well this is a builder after all. Everytime I git clone this repo I am pulling whatnots someone else put here. Pretty sure no one is gonna lose sleep over 33MB. |
I do agree with you that concerning disk space, 16MB is not a lot in todays standards. But this will add up over the years, different families, different branches, then when bumping someone copies instead of renames and so on. If you do this for lets say 5 different families over 3 branches (5x3x16=240MB, very simplified dumb example), it might still not seem much when only looking at disk space. But for Git, these numbers are pretty big, especially when added up over 5, 10, 20 years 😄 To put this into perspective, the spacemit patch set is now the 2nd largest one, with the biggest one being sunxi-6.1 which is only so huge because it includes a 14MB driver patch. The 3rd largest is only half the size at around 8MB. Most patch folders are below 1MB. The total size of the upstream U-Boot repo since 2005 is 228MB. I will refrain from further commenting on the topic now, but I hope this clears some things up on my perspective. |
This picks up from where we left off: #6771
Added Linux Legacy and Current.
Wireless has been given its own function and patch directory.
Bluetooth firmware added to
armbian/firmware.esos.elf moved to:
packages/blobs/riscv64/spacemit/Host machine used for builds: Ubuntu Noble (aarch64)
Images tested: Ubuntu Noble Minimal and Debian Sid
Information:
https://docs.banana-pi.org/en/BPI-F3/BananaPi_BPI-F3
https://gitee.com/bianbu-linux
Flashing u-boot to eMMC: (This is not apart of the PR and needs to be added in the future.)
Tested:
Bluetooth and Wifi (useless without an ANT) (bluetooth is iffy)
Ethernet (1 and 2)
PCIe
USB
HDMI (LEGACY)
Debug UART
NOTE:
One major difference between this build and the others available else where is the use of SYSLINUX/EXTLINUX instead of the ENV file.
BUGS:
HDMI currently broke on CURRENT. The screen just displays red.