Release Plan for Image, Kernel, Uboot etc

Hello starfive,

is it an Release Plan available for the next Image ?
Or update’s for

  • kernel
  • u-boot
  • opensbi

The last update is more then 1 month old.
Best regards


Next Debian image is planned to be released end of this month.


I’ve been a bit frustrated by the idea of an image to begin with, so I’ve hooked it up to the debian sid repos, and updated everything to the latest, excepting the kernel… since there appears to be a fair amount of starfive specific patches there, however I needed a bunch of extra modules, so since I had to recompile it, I also rolled it forward, so now I have the latest 5.15 (5.15.94) kernel with starfive patches, and a lot of modules… I didn’t manage to re-factor the camera driver, but otherwise I think it’s all good… if anyone is interested in the source or binary packages, let me know and I’ll post them up somewhere.

root@vector:/home/james# uname -a
Linux vector 5.15.94-4jlriscv #1 SMP Mon Feb 20 21:33:43 UTC 2023 riscv64 GNU/Linux

root@vector:/home/james# lsmod
Module                  Size  Used by
xt_LOG                 16384  1
nf_log_syslog          28672  1
xt_conntrack           16384  3
nf_conntrack_netlink    65536  0
xt_addrtype            16384  2
br_netfilter           36864  0
veth                   40960  0
nft_masq               16384  1
nft_counter            16384  22
nft_chain_nat          16384  4
nft_compat             24576  9
l2tp_ppp               32768  6
nf_tables             303104  95 nft_compat,nft_counter,nft_masq,nft_chain_nat
pppox                  16384  1 l2tp_ppp
rtl8xxxu              151552  0
mac80211             1011712  1 rtl8xxxu
cfg80211              536576  2 mac80211,rtl8xxxu
libarc4                16384  1 mac80211
btrfs                1839104  1
zstd_compress         290816  1 btrfs
lzo_compress           16384  1 btrfs
raid10                 86016  0
raid456               217088  0
async_raid6_recov      16384  1 raid456
async_memcpy           16384  1 raid456
async_pq               16384  1 raid456
async_xor              16384  2 async_pq,raid456
async_tx               16384  5 async_pq,async_memcpy,async_xor,raid456,async_raid6_recov
xor                    16384  2 async_xor,btrfs
raid6_pq               98304  4 async_pq,btrfs,raid456,async_raid6_recov
raid1                  69632  0
raid0                  24576  0
multipath              16384  0
linear                 16384  0
md_mod                225280  6 raid1,raid10,raid0,linear,raid456,multipath


Some of the stuff I want really needs kernel 6.1+ though, so I really hope we’ll see new kernel packages at some point… porting the patches forward from 5.15 to 6.1 is a little beyond my ability…

I hope ultimately the patches required will get upstreamed, it’d be amazing to be able to run a mainline kernel.


Hello @blueadept,

i think (my own opinion) you have to wait until Linux 6.4. We are now in the merge window for Linux Kernel 6.3.
But i dont know the relase plan from starfive.



@blueadept - like mentioned in the other thread, it would be nice if you could upload your source somewhere

best wishes - hexdump

Hope it’s of some use… I’m not really very experienced such obscure platforms, but well… I wanted BTRFS on my NVMe drive, and that got me looking at the kernel sources.

Let me know if it works for you too!


How did you get pass 5.15.2? I stuck when I tried to applied the incremental patch 5.15.2 to 5.15.3

I actually went directly from 5.15.0 to 5.15.93, and used that for a while then moved forward to 94 when I needed to recompile because, why not.

There were some rejected patches that I had to merge manually, but nothing too taxing, just something in the code moved around or something added so patch couldn’t find the right place to make the change…

1 Like

Thanks, I’m trying to apply the 5.15.95 patch.
What did you answer when the patch asked this?

Reversed (or previously applied) patch detected! Assume -R? [n]

You’d need to answer no, and it will then ask if you want to “apply anyway”, and you should also answer “no”… it will write a file with the extension “.rej” next to the source file with the changes it could not apply… make a note of each of these as you will need to go back afterwards and manually merge the change… sometimes you might need to compare the different versions to work out what needs to be done to merge it… there’s never a guarantee that it will be easy or even possible but I thought it was OK this time… are you going from my 5.15.94 to 95, or are you trying to patch directly from the 5.15.0-starfive kernel?


I’m patching directly on 5.15.0-starfive

I think you’ll have ~7-10 files to manually merge in that case…


Incase you give up, feel free to use my patch, apply it to vanilla .94 and then roll forward to 95… (it might apply to .95 directly TBH)

I made my patch to apply against the vanilla kernel because I wanted to use it to see how far the starfive kernel is from mainline… I’m starting to think that with the latest, perhaps 6.2 or 6.3 kernel you could probably boot vanilla and get the system up, but you would have no graphics, no ethernet, no sound etc etc…

These are the kernel configuration parameters which are in starfive’s 6.2 kernel and not in the vanilla 6.2 kernel:-




I didn’t manage to re-factor the camera driver

You mean you didn’t fix this error, right?

CC      drivers/media/platform/starfive/v4l2_driver/stf_dmabuf.o
drivers/media/platform/starfive/v4l2_driver/stf_dmabuf.c:34:17: error: too many arguments to function call, expected 3, have 5
                                head->size, vb.vb2_queue->dma_dir, vb.vb2_queue->gfp_flags);
drivers/media/platform/starfive/v4l2_driver/stf_dmabuf.c:41:60: error: too few arguments to function call, expected 3, have 2
        dmabuf = vb2_dma_contig_memops.get_dmabuf(mem_priv, O_RDWR);
                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                 ^
drivers/media/platform/starfive/v4l2_driver/stf_dmabuf.c:54:47: error: too few arguments to function call, expected 2, have 1
        paddr = vb2_dma_contig_memops.cookie(mem_priv);
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~         ^
3 errors generated.
make[4]: *** [scripts/ drivers/media/platform/starfive/v4l2_driver/stf_dmabuf.o] Error 1
make[3]: *** [scripts/ drivers/media/platform/starfive] Error 2
make[2]: *** [scripts/ drivers/media/platform] Error 2
make[1]: *** [scripts/ drivers/media] Error 2
make: *** [Makefile:1903: drivers] Error 2

I put option -F3 to the patch command, and I have only 3 rejected files. I think it’s just this, and the Eswin WiFi driver that cannot build.

Pretty sure I enabled every wifi driver and didn’t have a problem, but if you can tell me which one that is, I’ll check I have it enabled… as for the v4l camera driver above, it looked to me as tho it’s calling a function that has changed somewhere else in the kernel… so I decided that I probably couldn’t fix that, and just disabled it in the .config file… I don’t have an MIPI camera anyway.

Edit, I’m wondering now if I might be able to look at the camera driver from 6.1 or something to see what changed to fix that issue… Hmm.

these were the patch errors i ran into as well when i tried it some weeks back: the v4l stuff and the eswin driver - i think the eswin one was somehow resolvable but for that v4l stuff i also did not find an easy fix and gave up on the idea to patch the tree up in the end

eswin is a problematic by the way, on the standard Arch and Fedora Linux kernel config, the CONFIG_FUNCTION_TRACER should be enabled, but if I enable this config, the eswin driver can’t be build neither in-kernel driver nor as an external module.

1 Like