After shooting myself in the foot a few times (mostly running out of disk space to create the ext4 image) I’ve got a better build from the SeeedStudio release which has Docker built in along with a bunch of other things. So many things now, in fact, that I need to copy new images onto the H68K and run sysupgrade interactively on there rather than upload through the Luci interface which times out.
This is working really nicely for me now as my HomeAssistant server - all running in Docker, using an NVMe SSD in a USB-C enclosure for storage.
I did have a brief attempt to apply the H68K patches against the HEAD of the OpenWRT tree but it was non-trivial and I didn’t have the time to dig into the details of what was going wrong.
Thanks for the info. Did you extend the image and using /opt for docker?
I cannot get home assistant to pull the image as I keep getting too many symbolic links error.
I 'git clone’d the OpenWRT source from github and built it using ‘make menuconfig; make clean; make -j 12’ on my laptop which is running Debian. I’m happy to share the ‘.config’ file I am currently using which builds an ext4 sysupgrade image of around 312M compressed (it uses a 2TB partition).
I actually configured docker to be in /docker rather than /opt/docker and I have that mounted to an 80G partition on a 256G NVMe SSD.
the issue with the self-built image not being able to boot from TF,
This seems to be improved by removing the
Openwrt/target/linux/rockchip/files/arch/arm64/boot/dts/rockchip/rk3568-linkstar-opc.dtsi:Line 594 in 8ad4fbf
There may be a compatibility issue with the boot loader, which is flashed on the eMMC, though.
The results of my tests are described in the following Issue.
SO I feel your pain with this in General the more I look the more I find, You are NOT alone.
I was going to separate title this, bit I feel it dovetails into what they understand as Open-Source and just the “RIGHT THING” to Do!
Seeed has a secret that is unflattering…
Who is in Charge?
Who makes the final Decisions?
Who reviews the companies policies?
Is it a team effort or does One person hold the BUCK$ ?
Consider the case of mainline " Zephyr "
The reason there is no official Xiao nRF52840 DTS in mainline Zephyr is that Seeed Studio has not upstreamed it to Zephyr’s main repository. Instead, they added their own DTS in Nordic’s NCS (nRF Connect SDK).
Why is it missing from mainline Zephyr?
Seeed Studio created their own Zephyr board definition
Seeed provided a Zephyr board file for the Xiao nRF52840 inside Nordic’s NCS SDK, not in Zephyr’s mainline repo.
That means if you use mainline Zephyr, you won’t find xiao_ble.dts, but it exists in NCS.
Zephyr’s mainline repo only includes officially submitted and accepted board files
Companies like Seeed must submit their board files to Zephyr as a Pull Request (PR).
Since they didn’t do that, Zephyr never included Xiao nRF52840 officially.
Zephyr prefers upstreamed contributions that meet its standards
If a board’s support isn’t properly documented, tested, and actively maintained, Zephyr may reject or delay its inclusion.
* Seeed likely chose to only support their board in NCS instead of maintaining it in both NCS and Zephyr.
What does this mean for you?
You have the Xiao BLE DTS file inside NCS (v2.8.0/zephyr/boards/seeed/xiao_ble/) But it is NOT in mainline Zephyr (if you use Zephyr separately, it won’t be there).
If you only use NCS, then you’re fine—but if you ever switch to mainline Zephyr, you’ll need to manually port the DTS file.
You are cutting off your nose to spite your face… WHY? or choosing to look the other way. This is the future and should still be done, for the Nrf52840 Xiao It’s like building a 4 story building with NO foundation. Put one of you brilliant software engineers on it and get this house in order because the work NOW will pave the way to the future and guarantee Seeed-Studio’s dominance in the market because they have the receipts.
Bottom Line
Zephyr does have a DTS for Xiao BLE, but it is seriously incomplete.
Now it’s not affecting me directly but using the west commands in Zephyr at the low level and ability to direct write to io and periphery
Hyper-speeds code development and requires less debugging time.
(like talking to GPIO with a terminal or in RPI)
If you want to be a OPEN_SOURCE source you need to do the Right thing.
You have the Xiao BLE DTS file inside NCS (
But it is NOT in mainline Zephyr (if you use Zephyr separately, it won’t be there).
PJ 