closed source?

[frostworx]

interesting device, found it via https://www.cnx-software.com/2024/07/08/20-nanokvm-is-a-tiny-low-power-risc-v-kvm-over-ip-solution/#comments

but are you really planning to keep it closed source?

edit: finally ordered one 2 month later :)

[frostworx]

mount -t ext4 -o loop,offset=16777728 20240702_NanoKVM_Rev1_0_0.img /random/mountpoint

for the curious

edit:

whoops, forgot

mount -t vfat -o loop,offset=512 20240702_NanoKVM_Rev1_0_0.img /random/mountpoint

for the first partition

[frostworx]

a bit random grepping reveals that at least

https://github.com/hodgef/react-simple-keyboard
is used in the firmware

server/web/assets/index-u2n1Wr7j.css: * https://github.com/hodgef/react-simple-keyboard

[frostworx]

see also
https://news.ycombinator.com/item?id=40903461

[Zepan]

We are wondering wheter open or not.
At the early time (3month ago), we want make it opensource, only make the hardware, and port PiKVM on it with few develop work. but we realize it is not easy to run PiKVM on it, as it not support V4L2.
We send the hardware sample to some community developer who familiar with PiKVM, and they worked for 3month to port V4L2, and still working...(may finished in few month, when it finished, we will open PiKVM port)
we have to develop FW ourself, it takes about 2~3month, and we see >95% commit of PiKVM is written by author, so we think it may not help much if we opensource at the first time? keep this as a bug report repo maybe better?
Welcome feed back if you have better suggestion to work with community, we want a good balance with opensource and commerce.

[Zepan]

At least, we will open most interfaces/API for images,HID operations, that DIYer can customize their own functions without dig hard into complex bsp sdk.

[Zepan]

I make a vote on twitter: https://x.com/SipeedIO/status/1810508366336115192

[frostworx]

thank you for the comprehensive answer and also thanks for creating the poll.
(personally I don't use x-twitter, so I won't take part)

[ThomasKaiser]

Not using X/Twitter either but wanting to emphasis on the open source aspect -> trust into the device being not equipped with a backdoor.

Folks are fine using whatever commercial iKVM solution but once it's open hardware but comes from China they start to worry. Especially residents of the Five Eyes states who are absolutely fine with their governments/agencies spying on everyone on this planet are trained to believe that everything that originates from China must be evil.

As such allowing users to build their own firmware image from sources will at least be a try to stop these 'concerns' your KVM device being backdoored by design.

[shangri26199]

+1 for opensource without X account

[Zepan]

Not using X/Twitter either but wanting to emphasis on the open source aspect -> trust into the device being not equipped with a backdoor.

Folks are fine using whatever commercial iKVM solution but once it's open hardware but comes from China they start to worry. Especially residents of the Five Eyes states who are absolutely fine with their governments/agencies spying on everyone on this planet are trained to believe that everything that originates from China must be evil.

As such allowing users to build their own firmware image from sources will at least be a try to stop these 'concerns' your KVM device being backdoored by design.

what about open backend(go), close frontend(react)?

[ThomasKaiser]

what about open backend(go), close frontend(react)?

I don't think that will stop people talking about your device being backdoored...

[seichold]

I bought a full and lite through the pre-order to check them out, but without the firmware being open source I do not think this will gain wide traction.

I really want this project to be successful as it brings a near order of magnitude cost reduction (and size!) to the ip based KVM world .

So take this as my (non X using) vote to work toward open source firmware.

[ElbPirat]

Also +1 on open source.
Pre-Ordered one for personal use, but searching something similar for my workshop/lab at work, other professional devices are too expensive for my superior... Would try to order a few once released.

[mintisan]

If it's just for playing around, closed-source is fine, but if it involves projects or production data, then I wouldn't use it [I have already bought one].

[bilogic]

i need HDMI to a monitor as well, is it possible with this hardware? or splitter?

[denern]

I have the LicheeRV Nano board and am familiar with PiKVM, how can I help you to finish?

[M0NsTeRRR]

I'm waiting for the code to be open source before buying one :)

[joubin]

evil.

Not using X/Twitter either but wanting to emphasis on the open source aspect -> trust into the device being not equipped with a backdoor.
Folks are fine using whatever commercial iKVM solution but once it's open hardware but comes from China they start to worry. Especially residents of the Five Eyes states who are absolutely fine with their governments/agencies spying on everyone on this planet are trained to believe that everything that originates from China must be evil.
As such allowing users to build their own firmware image from sources will at least be a try to stop these 'concerns' your KVM device being backdoored by design.

what about open backend(go), close frontend(react)?

I know many downvoted this. But if you’re willing to open source the backend and sell an SDK for enterprises that want to build their own front end anyways and integrate with their own Idps. Not sure. There might be something there

[brainstorm]

Here's another strategy that can be a win-win for both Sipeed and regular consumers of your product:

Commit to releasing it as opensource as soon as you've sold, say, 3000 units (arbitrary amount to be decided by Sipeed). Motivation behind this is:

1. It "secures" a (fixed, minimum) income threshold for Sipeed.
2. It motivates those buyers to purchase your product to accelerate it being opensource faster.

As it stands right now I'm siding with @M0NsTeRRR's position: if there is no clear commitment to release it as opensource, I'm not interested since I know that sooner or later the binary will be reverse engineered and re-implemented as OSS anyway (plus all the other security and future maintenance related concerns outlined in this issue).

EDIT: Current reversing efforts uncover worrying flaws: https://lichtlos.weblog.lol/2024/08/how-to-reverse-the-sipeed-nanokvm-firmware

[timonoj]

I bought it first, assuming it was OSS from the beginning. I'm gonna wait for the OSS release. I can see them adding new features to their private fw every few days, but I'd rather very much just use OSS.

[scpcom]

I already took some look at LicheeRV-Nano-Build and this is what I found so far:

• freertos: contains pre-built cvitek audio libraries, did not take a closer look if this is required
• host-tools: pre-built compilers (no problem for me, can be replaced by distro/standard compliers)
• linux_5.10, opensbi and u-boot-2021.10: fully open source, can be built outside of LicheeRV-Nano-Build with minimal modifications
• middleware: contains pre-built libraries, I could not find the source for it
• osdrv: contains two pre-built modules (soph_vc_driver.ko and soph_jpeg.ko) but the source code was already released by cvitek/sophgo
• ramdisk: contains pre-built versions of standard packages like busybox (no problem for me, can be replaced by distro/standard versions)

The middleware should also be open-sourced (by the SoC vendor), it seems to be required for NanoKVM

PS: To get a better overview of the hardware related changes, I splitted out opensbi, u-boot and linux, re-based it to the original project git:
https://github.com/scpcom/linux/tree/licheervnano-5.10.y
https://github.com/scpcom/u-boot/tree/licheervnano-2021.10
https://github.com/scpcom/opensbi/tree/licheervnano-0.9
Currently the difference between LicheeRV-Nano-Build and my branches are only non-hardware-related like whitepaces and .gitignore.

[scpcom]

I almost finished my research on LicheeRV-Nano-Build and created the branches on forks of existing projects:

https://github.com/scpcom/linux/tree/licheervnano-5.10.y
https://github.com/scpcom/opensbi/tree/licheervnano-0.9
https://github.com/scpcom/u-boot/tree/licheervnano-2021.10

https://github.com/scpcom/buildroot/tree/licheervnano-2023.11
https://github.com/scpcom/FreeRTOS/tree/licheervnano

https://github.com/scpcom/sophgo-fsbl/tree/licheervnano
https://github.com/scpcom/sophgo-ramdisk/tree/licheervnano

https://github.com/scpcom/sophgo-build/tree/licheervnano
https://github.com/scpcom/sophgo-middleware/tree/licheervnano
https://github.com/scpcom/sophgo-osdrv/tree/licheervnano

Currently I am locally connecting them together as submodules, I may create and publish a top-level repo next, to make it easier.

If you look in the history you can see a replay of the commits to LicheeRV-Nano-Build splitted in to the sub projects.
They are similar with one exception:
The most interesting part is the 2.6G sized initial commit named "release" (bd39c05f39ab6d850d7c2c29a6b5ac617efc698a).
If you look in the history of my branches the size is reduced to less than 2M. You can easily watch it on github or in an editor.
It contains only the changes relevant for LicheeRV Nano now.

First I needed to find a point on the original project which is close to the current LicheeRV Nano version.
Then I made a diff and searched for more parts to exclude. I put things like wireless drivers into separate commits.
The goal was to get a better history and find the hardware relevant changes, the resulting code is identical.

Some notes about the content and references to the original projects:

buildroot
sophgo does also have a 2023.11 branch, but it s not the same:
https://github.com/sophgo/buildroot-2021.05/tree/buildroot-2023.11
It is clean 2023.11.2 plus overlay and some extra packages (downloads wifi firmware blobs and pre-built ld-musl-riscv64 libs)
https://github.com/buildroot/buildroot

freertos
Based on sophgo version with five extra tasks: camera, isp, vcodec, vi and vip
https://github.com/sophgo/freertos (https://github.com/FreeRTOS/FreeRTOS)
https://github.com/sophgo/FreeRTOS-Kernel (https://github.com/FreeRTOS/FreeRTOS-Kernel)
https://github.com/FreeRTOS/Lab-Project-FreeRTOS-POSIX
The binaries are just temp files from the compiler.

fsbl
No modifications, just one extra directory symlink (plat/sg200x)
https://github.com/sophgo/fsbl

host-tools
Not part of LicheeRV-Nano-Build, just:
https://github.com/sophgo/host-tools
compilers and toolchain

linux_5.10
sophgo linux_5.10 is very close to the XUANTIE-RV version but they decided to start
there branch with a blank 5.10.4 and mix XUANTIE-RV and there changes into one big commit
https://github.com/sophgo/linux_5.10/ (https://github.com/XUANTIE-RV/linux)

opensbi
Only few lines changed
https://github.com/XUANTIE-RV/opensbi

oss
Identical to:
https://github.com/sophgo/oss
Does not seem to contain sources, just older pre-compiled libs with headers and pkgconfig.

ramdisk
Contains some extra static linked binaries and configuration.
Two extra firmware blobs in rootfs/common_arm/usr/share/fw_vcodec,
I do not know if the blobs are really relevant or just leftovers from older sdk version.
https://github.com/sophgo/ramdisk

u-boot-2021.10
https://github.com/sophgo/u-boot-2021.10

The delta between LicheeRV-Nano-Build and the following repos (also some parts of the others)
is a bit dirty because sipeed used some sdk with a different naming scheme for the chips.
On the sophgo git versions they use "cv181x" in almost all cases for the chip used in LicheeRV Nano.
On the sdk used by sipeed they reference 3 different names in the code and directory/file names: cv181x, mars and sg200x.

build
https://github.com/sophgo/build
middleware
https://github.com/sophgo/middleware
osdrv
https://github.com/sophgo/osdrv

middleware
Still the repo with most blobs:
middleware/v2/modules/audio/lib
middleware/v2/modules/isp/lib
middleware/v2/3rdparty/cli

middleware/v2/sample/test_mmf (KVM Demo)
Contains a pre-compiled lib named libmaix_mmf.a (only for riscv64)
If you look in the history of LicheeRV-Nano-Build, you may find a file named
sophgo_middleware.c which seems to be/was the source code for it (and sophgo_middleware.h is equal to maix_mmf.h).

middleware/v2/sample/test_mmf/media_server-1.0.1
Contains fragments based on:
https://github.com/ireader/media-server
https://github.com/ireader/avcodec
https://github.com/ireader/sdk

If you add the missing parts you may be able to compile the libs found in
middleware/v2/sample/test_mmf/media_server-1.0.1/libs

[brainstorm]

Good reversing writeup on:

https://lichtlos.weblog.lol/2024/08/how-to-reverse-the-sipeed-nanokvm-firmware

[scpcom]

Here is my version of the Nano-Build repo using the submodules described above:
https://github.com/scpcom/LicheeSG-Nano-Build

[polyzium]

The frontend was recently open sourced, and the backend will be open sourced when the repository reaches 2k stars or the NanoKVM sells 10k units. See this tweet

[M0NsTeRRR]

The frontend was recently open sourced, and the backend will be open sourced when the repository reaches 2k stars or the NanoKVM sells 10k units. See this tweet

A good start, glad to see that !

[ckotte]

They should open source everything in the first hand and not wait for whatever. I bought one too because I'm interested, but I can understand why people not want to buy it if it's running on closed source.

[MatthewCroughan]

How am I supposed to trust a device that gives backdoor access to my hardware, without the ability to run or maintain my own operating system or software for it?

[polyzium]

How am I supposed to trust a device that gives backdoor access to my hardware, without the ability to run or maintain my own operating system or software for it?

The NanoKVM is based on the LicheeRV Nano. If you want to make your own firmware, feel free, the information is located here.
That being said, I saw your tweet regarding concerns about stolen PiKVM code. The answer is no, their firmware is original and does not use PiKVM code. In fact, they even tried to port PiKVM to the NanoKVM hardware (if they are to be believed), but I assume it is either unoptimized or the hardware is a bit weak for it.
I also suggest you look at this article regarding reverse engineering of the firmware and software inside. I am pretty sure that the firmware is original again, considering that most of PiKVM is written in Python+C, while Sipeed's implementation uses Golang.
As for the security concerns, Sipeed has acknowledged them and will release a stable and more secure firmware in the near future. The product listing says "beta version" for a reason.

[MatthewCroughan]

@polyzium I saw those claims that they tried to port kvmd and related code, which is why I am surprised to see that they have none in their end product. Overall the release process for this thing hasn't been transparent enough for what the product does (provide backdoor access to your hardware). I'm aware of all of the things I can do myself, but I haven't got my hands on the hardware yet, despite applying for the beta boards. I was looking forward to putting NixOS and kvmd on the device, or building open firmware with Nix, for it.

[IngwiePhoenix]

GG @geerlingguy ! Came and subscribed to this ticket too.

No more excuses now - super cheap epic KVM, here we come!

[J-Siu]

Waiting for update/announcement😁

[gshpychka]

Waiting for update/announcement😁

There has already been one - check above. (Targeting mid-October)

[J-Siu]

Waiting for update/announcement😁

There has already been one - check above. (Targeting mid-October)

Oops! My bad! Time to get couples of them😁 It is not only about the price, the compact size matter in my case too.

[scpcom]

I updated my submodule based repo and did larger changes to get the firmware to a more recent level:
https://github.com/scpcom/LicheeSG-Nano-Build/tree/develop

• switched to sophgo weekly rls 2024.09.11
• switched to buildroot to 2024.05.3
• merged mainline kernel v5.10.226
• added media_server submodule and rtsp_server source from MaixCDK to middleware/sample/test_mmf
• all LicheeRV Nano/NanoKVM related patches are still included.

Some more details can be found in the README.md

The source code for the 7 libs listed here...
#1 (comment)
...is still missing, the source code for libcvi_bin_isp is included but I kept using the pre-built version because it must match with the older (but optimized) isp_tuning binaries found in /mnt/cfg/param/ and I was not able yet to make the open source version compatible.
nanokvm and other apps maybe linked to more closed binaries but the code is not used - especially audio libs and libcli (telnet server?) can be removed from Makefiles.
For a full open source solution we may need source code for 7 cvi/sophgo libs and sipeed libmaixcam_lib (almost 80% to 90% maybe already available as maix_mmf in middleware/sample/test_mmf) and upcoming nanokvm app source :-)

I updated the "/mnt/system/usr/bin/test_mmf 10" sample to get a stable rtsp stream (stable but still with some delay), no OLED or other display required. camera works with 1440P 30fps and HDMI input with 720P 60fps stream resolution.

Tested on LicheeRV Nano W with gc4653 and on NanoKVM.
RTSP ist tested with VLC as client (needs live555 plugin, current windows VLC has it, some linux versions may not include it, should be in a folder like /usr/lib/x86_64-linux-gnu/vlc/plugins/access/liblive555_plugin.so).

[askmrsinh]

Looks like the server code just went up on GitHub!

[scpcom]

Added to buildroot:
https://github.com/scpcom/buildroot/tree/nanokvm-2024.05/package/nanokvm-server
kvm_stream and kvm_system ist not published yet? :-)

[mtlynch]

I saw this release on Twitter:

https://x.com/SipeedIO/status/1844035902596956574

And the linked folder has this note:

10. With regard to the open source note

As the current basic engineering is based on the company openbmc project based on the transplant, so the current release of the mirror of the source project will not be open-source, the follow-up time may be based on the openbmc community original project to pull a version to merge into the open-source again, but only part of the open-source (related to the company's related technology can not be open-source out of the content [such as kvm basedon the vnc of the h265 encoding and decoding etc.], will only be open source in the form of a binary bin file).

This is a violation of the OpenBMC project (mixture of MIT and GPL licenses) and likely any other open-source code this project relies on.

If you're compiling or including open-source code into your app, obeying the license is not optional, and you can't distribute the license "in the form of a binary bin file."

Read the terms of the license of the projects you're including. MIT and GPL both require license notices for each project you're including/compiling, and GPL requires you to provide sources, including any modifications or derivations.

[geerlingguy]

@mtlynch - This particular issue is regarding the software they're currently running on the NanoKVM — the linked Twitter post is about an experimental OpenBMC port, that I don't believe is being supported or recommended at this point, just mentioned.

It would probably be best to open a new issue to discuss that port.

The source code for NanoKVM's backend is now in this repository—see https://github.com/sipeed/NanoKVM/tree/3b2e142657d24337d8b3cedefdaea0777d81ec0d/server (however also some things might not be fully integrated, see @scpcom's comment above).

[gshpychka]

I expect to be able to flash the device completely from scratch with everything built from source - that's the only way NanoKVM could be truly considered open source. Hopefully we'll get that mid-october as promised.

[shaver]

Until we see concrete evidence otherwise, I think we should assume a good-faith effort on Sipeed's behalf to get their system opened up. From what I've seen they are doing real, difficult, uncompensated work to satisfy those of us who prefer open source for network control components, while still meeting their previous commitments to the customers who bought the devices already, and keeping the business afloat.

Sipeed has been unusually transparent about how the source license interacts with their business needs, and the decisions that they faced around that licensing. I think it was tremendously generous of them to offer open sourcing based on source demand (GitHub stars) and not just business milestones like recovery of R&D costs or similar. I feel that this has earned them some patience and grace from the community, and I hope that they see the comments here making demands of them as being excessive enthusiasm rather than hostility. I don't want them to regret their decision to offer the open source path.

If nothing else, we should treat "mid-October" as an estimate and desire, rather than an iron-clad commitment.

[174n]

Any plans on open-sourcing the firmware itself or will it stay closed-source forever?

[J-Siu]

@174n The source tree was updated a few days ago, and README is also updated. However, I am not knowledgeable enough to verify it has everything to compile. Maybe @scpcom can confirm?

[scpcom]

Yes, you can compile NanoKVM server and web and it works on the hardware.
But the sources for 3 binaries are still missing:

• kvm_system: Responsible for OLED output and some few copy operations (prepares the kvm_stream folder).
• kvm_stream: Runs a MJPEG stream listening on 127.0.0.1:8000
• libmaixcam_lib: Abstraction layer used by kvm_stream to get HDMI input and encode it to jpeg.

Since I also have a plain Lichee RV Nano and MaixCDK did not work I started to create a replacement for libmaixcam_lib based on the found sources some weeks ago, now it is a fully functional replacement (only vdec missing, not required for NanoKVM):
https://github.com/scpcom/sophgo-middleware/tree/maix_mmf-cvisdk/sample/test_mmf/maixcam_lib
https://github.com/scpcom/sophgo-middleware/tree/maix_mmf-cvisdk/sample/test_mmf/maix_mmf

Next step was not much to do, just using the code from test_mmf sample to get a kvm_system replacement:
https://github.com/scpcom/sophgo-middleware/tree/maix_mmf-cvisdk/sample/kvm_system

Some days ago I wanted to know what was happening on port 8000 and at the end I found a cool project that works as perfect replacement:
https://github.com/scpcom/streameye/tree/kvm_stream

I would prefer the original code but it is optional now :-)

[174n]

you can compile NanoKVM server and web

I meant the firmware. The stuff that gets flashed to the device from the .img file.
I heard from someone that they were going to release the firmware source code sometime in October, so I was wondering if they would release the firmware after they released server's source code

[shaver]

Perhaps this is a naive question, but isn't the server flashed to the device as part of the image?

[scpcom]

you can compile NanoKVM server and web

I meant the firmware. The stuff that gets flashed to the device from the .img file. I heard from someone that they were going to release the firmware source code sometime in October, so I was wondering if they would release the firmware after they released server's source code

The current official firmware image is created with this:
https://github.com/sipeed/LicheeRV-Nano-Build
The base firmware image was already open source since beginning. But NanoKVM does not work without the NanoKVM app.
The server (app) in the official image is included but does (did) not work without pressing the update button in the web interface to download a dongled lib.
If you are thinking about PiKVM or OpenBMC: This is not officially released or supported yet. There is only a test image of openbmc.

[burner-]

If you are thinking about PiKVM or OpenBMC: This is not officially released or supported yet. There is only a test image of openbmc.

Do you meant that install openBMC to nanoKVM hardware or nanokvm firmware to some of openbmc hardware?

[J-Siu]

@scpcom Thank you for the info! As your repo can serve as a fall back for future maintenance, I am ordering now😁

[scpcom]

Some conclusion about my work done.

If you want to use a fork of the original project:
https://github.com/scpcom/LicheeRV-Nano-Build/tree/develop

• Easier to fork, less updated components
• Builds NanoKVM server, web, maixcam_lib, kvm_system and kvm_stream from source

If you want to use a more recent base system:
https://github.com/scpcom/LicheeSG-Nano-Build/tree/develop

• Complex git with submodules, much updated components
• Builds NanoKVM server, web, maixcam_lib, kvm_system and kvm_stream from source
• Updated buildroot, linux and sophgo sdk

Building an SD/TF card image is similar for both:

• Run on Ubuntu 22.04 or higher is recommended
• Clone the repostirory
• Execute:
  ./build-nanokvm.sh

During the build process the original latest.zip is downloaded but no binaries are used from it anymore. It is just needed for the init scripts and config files.

The resulting image works out of the box, NanoKVM itself does not need any internet connection to work, no additional downloads required.

[scpcom]

The make the build more reproducible I removed the download of latest.zip and added the non-binary files to a git instead:
https://github.com/scpcom/buildroot/tree/nanokvm-2024.05/package/nanokvm-sg200x
https://github.com/scpcom/nanokvm-skeleton

I also updated the build script for NanoKVM server and web:
https://github.com/scpcom/buildroot/tree/nanokvm-2024.05/package/nanokvm-server

On NanoKVM 2.1.0 the kvm_stream binary was replaced with libkvm.so binary:
https://github.com/sipeed/NanoKVM/tree/main/server/dl_lib

I started my own implementation here:
https://github.com/scpcom/sophgo-middleware/tree/maix_mmf-cvisdk/sample/test_mmf/kvm_vision

Most magic ist still done inside maixcam_lib:
https://github.com/scpcom/sophgo-middleware/tree/maix_mmf-cvisdk/sample/test_mmf/maix_mmf
https://github.com/scpcom/sophgo-middleware/tree/maix_mmf-cvisdk/sample/test_mmf/maixcam_lib

And the middleware libs are also still required.

The h264 implementation in my maixcam_lib variant is complete (including avc2flv converter).
My h264 implementation in kvm_vison is just a draft at this moment
(m)jpeg is working fast and stable.

[scpcom]

h264 is working with my kvm_vision variant too now.

[AkechiShiro]

@scpcom Is it possible that your changes make it upstream to the official firmware/linux (maybe not all changes but the improvements at least), basically into this repository?

[VFansss]

I know this will sound quite annoying, but I'm not able to truly understand all the comments and what happened with trying to fully open source the firmware/libraries: if someone buy a NanoKVM today, what kind of things can use/flash onto it to possibly only use open source components? There's still something closed source that must be used? What's the degree of risk using it, eventually?

Sorry for this "non technical" question but as everyone else I'm concerned about security of the device, and I'm not able to truly understand (as someone that doesn't have it right now, but plan to buy it if everything matches) the degree of uncertainty/obscurity if I use the device like it is vs what's available as totally open source

[scpcom]

@scpcom Is it possible that your changes make it upstream to the official firmware/linux (maybe not all changes but the improvements at least), basically into this repository?

I already created two pull requests in September:
sipeed/LicheeRV-Nano-Build#44
sipeed/LicheeRV-Nano-Build#45
Since there was no response I keep them opened and up-to-date but did not try to open new pull requests.

if someone buy a NanoKVM today, what kind of things can use/flash onto it to possibly only use open source components? There's still something closed source that must be used? What's the degree of risk using it, eventually?

If you use the original sources from Sipeed you have to put them all together yourself, and not all official sources are published yet, you still would require some closed source libs.
This is the reason why I created my own fork, put it all together and created open source replacements for the few missing libs. If you follow this comment you are able build your own image from source:
#1 (comment)

[scpcom]

Let's talk about the 7 closed source libs remaining.
This is not limited to Sipeed, they are part of cvitek/sophgo middleware.

libae.so, libaf.so, libawb.so: responsible for things like gain control
libisp_algo.so: algos for color correction, filters and profiles
libcvi_json-c.a, libcvi_miniz.a and libjson-c.so: used to parse isp_tuning sensor parameters found in /mnt/cfg/param/

If you have a Lichee RV Nano with camera module (a.k.a. MaixCAM) you may want to keep them.
But do we need them for NanoKVM? No.

Many of the lib symbols are referenced but during runtime of NanoKVM only 3 of them are really used in addition to the (Un)Register functions:
CVI_ISP_GetExposureAttr
CVI_ISP_SetExposureAttr
CVI_ISP_SetWDRExposureAttr

I did not want to harm the source code which is referencing ae, af and awb so I created dummy libs that almost do nothing:
https://github.com/scpcom/sophgo-middleware/tree/maix_mmf-cvisdk/modules/dummy

algo, json-c and miniz is only used in libcvi_bin.so, libcvi_bin_isp.so and libisp.so.
There are two existing complier flags that allow to stop using them by just adding a Makefile:
https://github.com/scpcom/sophgo-middleware/tree/maix_mmf-cvisdk/modules/isp_light
I added a thrid compiler flag named ISP_LIGHT which disables the few remaining parts:
https://github.com/scpcom/sophgo-middleware/blob/maix_mmf-cvisdk/modules/isp_light/Makefile#L69

On NanoKVM you will see not difference in quality, speed or functionality.
I made sure the dummy and light libs are only used inside the kvmapp folder, all other projects still can use the fully featured versions.
At this stage NanoKVM runs full open source now.

Something about licenses: I put my own commits under BSD 3-clause.
But since all work is based on existing code or part of existing project you have to check the source tree for the license used there.

[scpcom]

Now I took a look at the host-tools.

The arm versions are from linaro and can be found here too:
https://releases.linaro.org/components/toolchain/binaries/6.3-2017.05/aarch64-linux-gnu/
https://releases.linaro.org/components/toolchain/binaries/6.3-2017.05/aarch64-elf/
https://releases.linaro.org/components/toolchain/binaries/6.3-2017.05/arm-linux-gnueabihf/
Since they maybe not customized or required for NanoKVM I did not look at the git.

The riscv versions are based on Xuantie-900 GNU Toolchain V2.6.1 which can be found here:
https://github.com/XUANTIE-RV/xuantie-gnu-toolchain/tree/2023.03.08

This contains almost all we need with one exception: T-Head does not seem to offer a repository for the riscv-musl libc submodule.
I created a repository based on the patches found here:
https://github.com/openembedded/openembedded-core/blob/langdale/meta/recipes-core/musl/musl_git.bb
https://github.com/thead-yocto-mirror/meta-riscv/blob/langdale-thead-V1.1.2/recipes-core/musl/musl_%25.bbappend

The result can be found here:
https://github.com/scpcom/riscv-gnu-toolchain/tree/xuantie-gnu-toolchain-v2.6.x
https://github.com/scpcom/riscv-musl/tree/thead-sdk-v1.1.2
I put a copy of the build scipts here:
https://github.com/scpcom/LicheeSG-Nano-Build/tree/develop/host

The scripts work standalone, for example you can copy build-riscv-thead-musl-toolchain.sh to somewhere else and run it there. It will clone all required code before build.
Be aware if you build all three variants you need about 40GB free space and it takes about 12 hours to finish (multiple days on slower hosts).
If the build is done (or you download them from the Releases page) you can empty the host-tools/gcc folder and unpack the three tar archives there to use them to build the firmware image.

[scpcom]

All other pre-built host-tools like genimage are also build from source now, provided by linux, u-boot and buildroot:
scpcom/buildroot@02116db
scpcom/sophgo-build@682a4db
scpcom/sophgo-build@cec9ba1
scpcom/sophgo-build@f19053c
Now you do not need a AMD/Intel x86_64 host anymore to build the image. I verified the build is working at least on ARM aarch64 machines too.

Building tailscale from source is now also possible with LicheeSG-Nano-Build:
https://github.com/scpcom/buildroot/blob/nanokvm-2024.05/package/tailscale-riscv64/tailscale-riscv64.mk

You can enable it with:
./build-nanokvm.sh --tailscale
I keep it disabled by default because tailscaled is permanently calling the tailscale servers even if you not configured it and there is no option yet in the NanoKVM web interface to completely disable it.