Creating a firmware mirror

[threexc]

Hi @yingjie-liu-spacemit, in this repo you have a k3-rootfs-overlay.bb recipe, which installs various firmware modules for use with the K3 BSPs.

In Yocto, what we typically do if these binaries aren't available in the upstream firmware repo (here) is create a custom recipe pointing at a vendor's repository. Here is an example for the OrangePi RV2 from when the initial K1 BSP was made:

https://github.com/riscv/meta-riscv/blob/master/recipes-kernel/firmware/linux-firmware-orangepi.bb

Can you create a similar mirror with the firmware binaries we need from k3-bootfs-overlay? Once that is done, I will quickly make a recipe similar to the one I linked above to make use of it.

Thank you!

[yingjie-liu-spacemit]

Hi @threexc,

Thank you for the valuable suggestion!

I have refactored the recipe to align with the Yocto/upstream standards. Instead of creating a separate vendor firmware mirror, I realized that the required Realtek firmware blobs are already available upstream.

I have submitted this commit: k3-rootfs-overlay: use linux-firmware for rtw89 WiFi/BT firmware.

• Changes: Dropped all bundled rtw89 firmware blobs and shifted to depending on the upstream linux-firmware subpackages (rtl8851/rtl8852/rtl8922).
• License: Updated the recipe LICENSE to MIT since it now only contains configuration files.

Regarding the ongoing discussion in meta-riscv#636, I would also like to clarify the purpose of the remaining files in k3-rootfs-overlay:

1. Network Configuration: It contains necessary rules to resolve the issue where the system fails to automatically obtain an IP address via DHCP after an ethernet cable is plugged in.
2. Weston Configuration: It ensures Weston's auto-detection correctly maps and displays on the proper cardX DRM node, preventing black screens or initialization failures on the K3 platform.

Please let me know if this works for you or if any further adjustments are needed for upstream integration!

[threexc]

@yingjie-liu-spacemit thank you for clarifying that. I will keep this as a reference for further additions to the meta-riscv layer after the initial BSP support is added.

[threexc]

@yingjie-liu-spacemit I have two questions:

1. Can you clarify why we need a custom toolchain for the esos recipe? Can it be built without that?

2. For attribution, I will want to change most of the commits I am reworking so that they assign original authorship for the work to you. Is it OK to use this signoff for you: Signed-off-by: Yingjie Liu <yingjie-liu@spacemit.com> ?

To be clear, in the end most commits should include something like:

Co-developed-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Yingjie Liu <yingjie-liu@spacemit.com>
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>

[yingjie-liu-spacemit]

@threexc,

@yingjie-liu-spacemit I have two questions:

1. Can you clarify why we need a custom toolchain for the esos recipe? Can it be built without that?

I performed a test build using the community pre-built riscv64-elf-gcc from riscv-collab (specifically riscv64-elf-ubuntu-22.04-gcc.tar.xz (release 2026.05.19)), and it failed due to a RISC-V Code Model mismatch between esos and the pre-compiled newlib libraries (libc.a, libgcc.a).

Here is the technical root cause:

• esos utilizes -mcmodel=medany in its rtconfig.py, and its link address is set to 0x100200000 (which is above 4GB).
• The pre-built toolchain from riscv-collab compiles its bundled newlib with the default -mcmodel=medlow, which restricts symbol addressing to the ±2GB range.
• SpacemiT's custom toolchain works because we rebuilt newlib specifically with -mcmodel=medany.

Given this architectural limitation, I see two potential paths forward for upstreaming right now:

• Option A (Pre-built Firmware Approach): Instead of compiling esos from source during the Yocto image build, we can provide the pre-compiled firmware components (rt24_os0_rcpu.elf, rt24_os1_rcpu.elf, and esos.itb) directly as firmware blobs. This is very similar to how the Orange Pi K1 BSP handled its specific firmware in upstream meta-riscv. It removes any compiler/toolchain dependencies entirely and is often the cleanest way for upstream integration when custom toolchains are involved.
• Option B (Custom Toolchain/Rebuild Approach): Keep the compilation from source, but document that it explicitly requires a toolchain built with -mcmodel=medany (like SpacemiT's toolchain), or configure Yocto's internal native/cross-toolchain to build its runtime libraries with medany.

Ultimately, we strongly hope that the toolchain upstream (riscv-collab/riscv-gnu-toolchain) will consider providing pre-built elf releases with medany support out-of-the-box in the future, as this has become a common requirement for RISC-V platforms with higher address maps. There are already relevant discussions upstream regarding similar toolchain configurations (such as riscv-collab/riscv-gnu-toolchain#1864).

But for now, Option A might be the most frictionless way to get the initial K3 BSP support merged into upstream without blocking on toolchain bootstrap issues. What are your thoughts on this? Do you prefer we switch to the pre-built firmware blobs for this PR?

2. For attribution, I will want to change most of the commits I am reworking so that they assign original authorship for the work to you. Is it OK to use this signoff for you: Signed-off-by: Yingjie Liu <yingjie-liu@spacemit.com> ?

To be clear, in the end most commits should include something like:

Co-developed-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Yingjie Liu <yingjie-liu@spacemit.com>
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>

Yes, that looks perfect to me. I really appreciate your effort to preserve the original authorship and set up the co-development credits. Please feel free to use my sign-off:

Signed-off-by: Yingjie Liu <yingjie-liu@spacemit.com>

Thanks again for your great work on pushing this upstream!

[yingjie-liu-spacemit]

Hi @threexc ,

Just a quick update on the toolchain/esos topic.

I managed to test another pre-built toolchain artifact that explicitly enables medany support: riscv64-elf-ubuntu-22.04-gcc-build-medany. Using this specific toolchain, I successfully built both esos and core-image-minimal from source, and the system boots up perfectly.

This proves that Option B is completely workable if we want to build from source. However, I’m still totally open to Option A (pre-built firmware blobs) if you feel that’s cleaner for the initial upstream PR. What are your thoughts?

Aside from that, I have also submitted a commit to address the earlier firmware/rtw89 cleanup we discussed: 9298914.

[threexc]

@yingjie-liu-spacemit I think the pre-built blobs approach may be simplest. If you can provide a mirror for them, I will create a recipe and add it to my PR on the meta-riscv repo.

[yingjie-liu-spacemit]

Hi @threexc :

That makes sense, let's go with the pre-built firmware blobs approach to keep things simple and frictionless.

I have pushed the relevant changes here: 01fe48b.

Please take a look and see if this structure works for your recipe. Let me know if we need any adjustments!

[threexc]

@yingjie-liu-spacemit thank you very much, I will test with this shortly.

[threexc]

@yingjie-liu-spacemit Hi, see the latest here: riscv/meta-riscv#636

I've updated the commits with proper attribution (you are listed as author on almost all the commits while I am co-developer, as discussed) and I've done some more testing. I think this is nearly the final PR for review and merge over there. Right now it only targets a headless image for the K3 Pico-ITX - more features and board support will be tested and confirmed as we go, and once K3 mainline kernel + U-Boot support improves, we'll make a variant BSP for that too.

It seems that I can't interact with the NVMe drive from U-Boot. I was hoping to chainload the core-image-minimal from there to prove that the drive flashing logic with bmaptool worked OK, but that doesn't work right now. Here's what I see:

=> [   9.961] nvme
Now int init_x2_puphy...
[  13.014] waiting pll lock...
[  13.016] PHY PLL Locked.
[  13.029] Now int init_x2_puphy...
[  13.029] waiting pll lock...
[  13.032] PHY PLL Locked.
[  13.034] pcie_dw_spacemit pcie@80000000: pcie config device cmd in rc mode: 0x3bf
[  13.178] PCIE-0: Link up (Gen3-x4, Bus0)
[  13.182] pcie_dw_spacemit pcie@80400000: failed to map lanes: -22
[  13.185] pcie_dw_spacemit pcie@80400000: failed to init phy: -22
[  13.191] nvme - NVM Express sub-system

[  13.195] Usage:
nvme scan - scan NVMe devices
nvme detail - show details of current NVMe device
nvme info - show all available NVMe devices
nvme device [dev] - show or set current NVMe device
nvme part [dev] - print partition table of one or all NVMe devices
nvme read addr blk# cnt - read `cnt' blocks starting at block
     `blk#' to memory address `addr'
nvme write addr blk# cnt - write `cnt' blocks starting at block
     `blk#' from memory address `addr'
=> nvme scan
pcie_dw_spacemit pcie@80400000: failed to map lanes: -22
[  18.305] pcie_dw_spacemit pcie@80400000: failed to init phy: -22

[yingjie-liu-spacemit]

Hi @threexc ,

Thanks for the update and your incredible work on the PR! I really appreciate the effort to preserve the proper attribution and set up the co-development credits.

Regarding the NVMe issue you encountered: thanks for catching this, but please don't worry! This is actually expected behavior when only one SSD is installed on the K3 platform.

The SpacemiT K3 SoC has two separate PCIe controllers:

• Controller 0 (pcie@80000000) is successfully up and running, as shown in your log: PCIE-0: Link up (Gen3-x4, Bus0).
• Controller 1 (pcie@80400000) throws the -22 (-EINVAL) error during nvme scan simply because there is no device connected to the second PCIe slot/lanes at the moment. It fails to map lanes and initialize the PHY for the empty slot, but this does not affect the functionality of Controller 0 at all.

To prove that, here is a console screenshot from my side with two NVMe SSDs plugged in simultaneously:

As you can see, once both slots are populated, both controllers initialize flawlessly without any errors.

If you want to tweak the boot sequence or handle multi-device initialization later, the official K3 NOR Second Boot Device Guide should be a helpful reference.

Let me know if the first drive can be fully interacted with now despite that noisy log!

Best regards,
Yingjie

[threexc]

Hi @threexc ,

Thanks for the update and your incredible work on the PR! I really appreciate the effort to preserve the proper attribution and set up the co-development credits.

Regarding the NVMe issue you encountered: thanks for catching this, but please don't worry! This is actually expected behavior when only one SSD is installed on the K3 platform.

The SpacemiT K3 SoC has two separate PCIe controllers:

* **Controller 0 (`pcie@80000000`)** is successfully up and running, as shown in your log: `PCIE-0: Link up (Gen3-x4, Bus0)`.

* **Controller 1 (`pcie@80400000`)** throws the `-22` (`-EINVAL`) error during `nvme scan` simply because there is no device connected to the second PCIe slot/lanes at the moment. It fails to map lanes and initialize the PHY for the empty slot, but this **does not affect the functionality of Controller 0 at all**.

To prove that, here is a console screenshot from my side with two NVMe SSDs plugged in simultaneously:

As you can see, once both slots are populated, both controllers initialize flawlessly without any errors.

If you want to tweak the boot sequence or handle multi-device initialization later, the official K3 NOR Second Boot Device Guide should be a helpful reference.

Let me know if the first drive can be fully interacted with now despite that noisy log!

Best regards, Yingjie

Thank you! I was not actually able to get the NOR guide's instructions to work. I see:

=> tlv_eeprom dev
TLV: 0 (*)
=> [ 395.384] tlv_eeprom
TLV: 0
[ 396.388] TlvInfo Header:
[ 396.389]    Id String:    TlvInfo
[ 396.392]    Version:      1
[ 396.395]    Total Length: 78
[ 396.397] TLV Name             Code Len Value
[ 396.401] -------------------- ---- --- -----
[ 396.406] Product Name         0x21  11 k3-pico-itx
[ 396.410] Serial Number        0x23  16 HW3MPK3321280188
[ 396.415] Base MAC Address     0x24   6 50:0A:52:0B:E7:17
[ 396.421] MAC Addresses        0x2A   2 1
[ 396.424] DDR Part Number      0x45  13 MT62F4G32D8DV
[ 396.429] Part Number          0x22   4 MPK3
[ 396.433] PMIC Type            0x80   6 au4562
[ 396.438] CRC-32               0xFE   4 0xAAE82B7B
[ 396.442] Checksum is valid.
=> [ 399.221] tlv_eeprom set 0x83 SSD
ERROR: Non-digit found in byte string: (SSD)
=>

Maybe there is a bug?

Meanwhile, I was able to do a secondary boot from the minimal Yocto image I've built with the latest version of the PR. Here's what I did in U-Boot:

[  10.005] Autoboot in 5 seconds
=> [  14.049] nvme
Now int init_x2_puphy...
[  15.932] waiting pll lock...
[  15.934] PHY PLL Locked.
[  15.946] Now int init_x2_puphy...
[  15.946] waiting pll lock...
[  15.949] PHY PLL Locked.
[  15.952] pcie_dw_spacemit pcie@80000000: pcie config device cmd in rc mode: 0x3bf
[  16.095] PCIE-0: Link up (Gen3-x4, Bus0)
[  16.100] pcie_dw_spacemit pcie@80400000: failed to map lanes: -22
[  16.103] pcie_dw_spacemit pcie@80400000: failed to init phy: -22
[  16.109] nvme - NVM Express sub-system

[  16.113] Usage:
nvme scan - scan NVMe devices
nvme detail - show details of current NVMe device
nvme info - show all available NVMe devices
nvme device [dev] - show or set current NVMe device
nvme part [dev] - print partition table of one or all NVMe devices
nvme read addr blk# cnt - read `cnt' blocks starting at block
     `blk#' to memory address `addr'
nvme write addr blk# cnt - write `cnt' blocks starting at block
     `blk#' from memory address `addr'
=> nvme scan
pcie_dw_spacemit pcie@80400000: failed to map lanes: -22
[  17.584] pcie_dw_spacemit pcie@80400000: failed to init phy: -22
=> [  17.958] nvme info
pcie_dw_spacemit pcie@80400000: failed to map lanes: -22
[  19.424] pcie_dw_spacemit pcie@80400000: failed to init phy: -22
[  19.430] Device 0: Vendor: 0x144d Rev: BL2QHXC7 Prod: S67WNF1W173513
[  19.437]             Type: Hard Disk
[  19.440]             Capacity: 244198.3 MB = 238.4 GB (500118192 x 512)
=> [  27.421] part uuid nvme 0:7 nvme_rootfs_partuuid
=> printenv nvme_rootfs_partuuid
nvme_rootfs_partuuid=7e40f472-1884-4de8-a469-64e1dd76d731
=> [ 108.768] load nvme 0:6 ${kernel_addr_r} /vmlinuz-6.18.3-k3
12948785 bytes read in 20 ms (617.4 MiB/s)
=> [ 117.395] load nvme 0:6 ${fdt_addr_r} /spacemit/6.18.3-k3/k3-pico-itx.dtb
138304 bytes read in 0 ms
=> [ 122.964] setenv bootargs 'root=PARTUUID=7e40f472-1884-4de8-a469-64e1dd76d731 rw rootwait rootfstype=ext4 earlycon=sbi console=ttyS0,115200'
=> booti ${kernel_addr_r} - ${fdt_addr_r}

after waiting for it to boot, I saw:

OpenEmbedded nodistro.0 k3-pico-itx ttyS0

Type 'root' to login with superuser privileges (no password will be asked).

k3-pico-itx login: [   10.720189] dwmac-spacemit-ethqos cac80000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[   14.910940] platform soc:sound-card@1: deferred probe pending: asoc-simple-card: parse error
root
root@k3-pico-itx:~# cat /proc/version
Linux version 6.18.3-k3 (oe-user@oe-host) (riscv64-oe-linux-gcc (GCC) 16.1.0, GNU ld (GNU Binutils) 2.46) #1 SMP PREEMPT_DYNAMIC Thu Apr 30 08:02:53 UTC 2026
root@k3-pico-itx:~#

[yingjie-liu-spacemit]

Hi @threexc,

Great to see that the core-image-minimal successfully booted via U-Boot manual loading, and that the 1Gbps Ethernet link is up and running!

Regarding the tlv_eeprom issue you encountered:

To help narrow this down and verify the behavior, could you please double-check if your current U-Boot build includes the tag k3-br-v1.0.0?

Here is my test result based on this version:

=> version
U-Boot 2022.10 (Apr 28 2026 - 15:32:04 +0000)

riscv64-poky-linux-gcc (GCC) 15.2.0
GNU ld (GNU Binutils) 2.45.1.20251126
=> [  39.117] tlv_eeprom read
EEPROM data loaded from device to memory.
=> [  41.996] tlv_eeprom list
TLV Code    TLV Name
[  44.471] ========    =================
[  44.473] 0x21        Product Name
[  44.477] 0x22        Part Number
[  44.480] 0x23        Serial Number
[  44.483] 0x24        Base MAC Address
[  44.487] 0x60        Wifi MAC Address
[  44.490] 0x61        Bluetooth Address
[  44.494] 0x25        Manufacture Date
[  44.497] 0x26        Device Version
[  44.501] 0x27        Label Revision
[  44.504] 0x28        Platform Name
[  44.507] 0x29        ONIE Version
[  44.511] 0x2A        MAC Addresses
[  44.514] 0x2B        Manufacturer
[  44.517] 0x2C        Country Code
[  44.520] 0x2D        Vendor Name
[  44.523] 0x2E        Diag Version
[  44.527] 0x2F        Service Tag
[  44.530] 0xFD        Vendor Extension
[  44.533] 0x44        DDR tx odt
[  44.536] 0x45        DDR Part Number
[  44.540] 0x80        PMIC Type
[  44.543] 0x83        Second Boot Device
[  44.547] 0xFE        CRC-32
=> [  45.820] tlv_eeprom set 0x83 SSD
=> tlv_eeprom
TLV: 0
[  70.845] TlvInfo Header:
[  70.846]    Id String:    TlvInfo
[  70.849]    Version:      1
[  70.852]    Total Length: 83
[  70.854] TLV Name             Code Len Value
[  70.859] -------------------- ---- --- -----
[  70.863] Serial Number        0x23  16 HW3MPK3161280022
[  70.868] Base MAC Address     0x24   6 50:0A:52:0B:CA:16
[  70.873] MAC Addresses        0x2A   2 1
[  70.877] DDR Part Number      0x45  13 MT62F2G32D4DS
[  70.882] Part Number          0x22   4 MPK3
[  70.886] Product Name         0x21  11 k3-pico-itx
[  70.891] PMIC Type            0x80   6 au4562
[  70.895] Second Boot Device   0x83   3 SSD
[  70.899] CRC-32               0xFE   4 0x990864DB
[  70.903] Checksum is valid.

I went through the codebase, and the 0x83 (Second Boot Device) feature was officially implemented in this commit: 2e7931a1.

Please let me know if your build aligns with this version, and we can look further into it. I'll also review and clear up our official guide to avoid any potential confusion.

Best regards,
Yingjie