↓ Skip to main content

Adventure of Compiling Uboot for the Radxa Cm3 - Part2

Introduction
#

So in part1 i was busy compiling Uboot and experimenting with the different releases. Now the SPI flash chips arrived, i want to make a SPI compatible Image so the EMMC does not have Uboot on it so in case the EMMC fails or gets corrupted, i can always have a working Uboot which lives on its own “isolated island”, the SPI flash chip.

It came, it finally came!
#

So finally the flash chips arrived. They ofcourse came a few days (about a week or so) earlier than i wrote this article but i am hapy they came into the mail. The flash chips i ordered where GD25lq128fwsig by Gigadevice and they are a special 1.8v SPI flash chip as the radxa only supports 1.8v flash ic’s. They are in a WSON package so a bit hard to solder, as instead of pins coming out of the sides, they have little pads directly under them and on some chips you also need to solder the middle ground pad for proper function and or thermal transition. So i cant use my normal soldering iron, although i did try that a bit and failed. I soldered all pins but because the middle pad was not connected, they did not work. So i tediously desoldered it, cleaned up the pads with desoldering-braid and decided to buy some solderpaste. When the solderpaste came in i forgot to also order a solderpaste stencil which normally would be a piece of plastic or metal with holes in it where the pins of the chip are so when you smear solderpaste on the stencil, it would only put paste in the empty holes where the pins would go and thus perfectly aligning everything and making sure every pin is covered.

I did not have a stencil and did not want to wait for one to arrive, so i tried it without, using a fine tip tweezer to spread the paste a bit evenly. And often solderpaste due to attracting to the pad and surface tension would often flow to the pads or align the chip automatically. So thern i placed the chip on the paste and used a hot air gun at 350 degrees celsius and kept heating the board until the soldepraste was melting/molten and then indeeed the chip automatically moved into position and all pins looked fine apart from a minor solderbridge which i could fix using a fine tip soldering iron. Then i tested it and low and behold, ‘sf probe’ returned the flash chip partnumber and no errors!

COmpiling Uboot for the SPI flash chip - branch rk3xxx-2024.01
#

So next up was the challenge of compilig Uboot for the flash chip. I first was curious if the idbloader.img and u-boot.itb i alrerady compiled would work. So i held both buttons, plugged in the board (to force it into bootrom mode) and then flashed the spl_loader via rkdeveloptool. After that i held down the EMMC disable button and released the SPI flash disable button and started my own rkflash script which would flash the SPL loader to intiailise the board far enough to accept commands and for it to be able to talk to spi/emmc flash and then flashed idbloader.img and u-boot.itb to the Flash at their default location. After that i rebooted the board holding the EMMC disable button so it would hopefully boot from the SPI flash and while it did load a tiny SPL segment, it quickly froze and did not enter into the Uboot Image so i think it either has no drivers to also load uboot image from spi flash or that there is a configuration issue. On the radxa website, the cm3j did have a optional spi flash option and did list it under the Specs > Storage list but the cm3 (normal consumer cm3) did not list the spi flash as an option so maybe i have to enable support for that.

First problem
#

So i enabled SPL_SPI, SPL_SPI_FLASH and other options those depended on and i was met with an erro when compiling. It said that sys_spi_u-boot_offs was overlapping with something. By default (in the defaultconfig after turning on SPL_SPI) it was set to 0x0 but i set it to 0x60000 as the rockchip documentation had set and also is what claude gave me as an answer for the issue. Then i tried compiling it and this time there where no errors.

First SPL boot problem
#

So i flashed it to the board’s SPI flash and rebooted it (with EMMC disable button ofc held in) and it booted into the SPL but after the SPL it would give an error that it could not boot from MMC (obviously as i held that disabled), but there where no mentions of it even attempting to boot from SPI. SO i looked at the configuration and simply enabled all SPL_SPI and SPI_FLASH related options and enabled the option ‘generate rockchip spi image’. This generated a u-boot-rockchip-spi.bin and idbloader-spi.img. So then i thought lets flash this u-boot-rockchip-spi.bin to the spi flash.

U-boot-rockchip-spi.bin or idbloader-spi.img did not work
#

SO sadly this also did not work and gave the same issue. So i moved on from this and looked through the config a bit more and decided to flash the idbloader-spi.img but that also did not work.

Flashing regular idbloader.img and u-boot.itb
#

So next i tried to flash the normal files. This did work and i did briefly get a “trying to boot from SPI…” entry but it quickly moved to “Trying to boot from EMMC” and obviously after that it locked up as it could not found any other bootdevice to laod stage2 from (u-boot image itself). So this is annoying! I enabled litteraly every option related to spl_spi and spi loading and while it did briefly attempt too or look for the Image on the SPI flash, it simply skipped it even though i wrote it on there. SO it must be having an issue or it does not like it, idk. And because there is litteraly little to zero documentation either from radxa or good uboot docs, this was another rabbit hole i am now stuck in.

Using AI to debug
#

So i decided to talk a bit to claude ai and google gemini-ai. I told them the issue and claude came with the testing of the SPI flash and gemini with possible vendor quirks. I decided to follow claude as that AI model is quite good and it does not halucinate as much as the other AI models. So i had some conversation and tried a bunch of stuf but that did not work and or was not relevant to the real isue. ‘sf test 0x0 0x1000000’ failed and i think claude was more focussing on getting that working than getting SPI flash boot working. I myself spent some time trying diferent things, even mainline but that also did not work.

Trying branch rk35xx-2024.01
#

Because i was already busy with this for a couple days, i decided to switch branch to rk35xx-2024.01 as i though “maybe the rk35xx branch has better support/dts configurations or configurations than the rk3xxx branch” and maybe 2024.04 or 2026-mainline was too bleeding edge.

So i distcleaned it and then checked out the rk35xx-2024.01 branch and started configuring it. I first wanted to test spi flash boting so i only turned on the bare minimum, but seems this branche’s defconfig already ahd most options set and also here i did not have to set/define the u_boot_offs variable as that was already set to 0x60000. So maybe this really has a greater chance of working.

Victory and it works!
#

SO i compiled it and then used my rkflash script to flash it on the SPI flash the same way i done before. Then i held the EMMC disable button down while plugging in the board and low and behold, we got victory!

U-Boot SPL 2024.01-309_Mus!cB0x_V1.0-UBOOT_SPI-RADXA_rk35xx-2024.01--40842-g31b85240876 (May 14 2026 - 18:07:41 +0200)
Trying to boot from SPI
## Checking hash(es) for config config-1 ... OK
## Checking hash(es) for Image atf-1 ... sha256+ OK
## Checking hash(es) for Image u-boot ... sha256+ OK
## Checking hash(es) for Image fdt-1 ... sha256+ OK
## Checking hash(es) for Image atf-2 ... sha256+ OK
## Checking hash(es) for Image atf-3 ... sha256+ OK
NOTICE:  BL31: v2.14.0(release):9a80def
NOTICE:  BL31: Built : 23:00:05, May 10 2026
NOTICE:  BL31: Rockchip release version: v1.0


U-Boot 2024.01-309_Mus!cB0x_V1.0-UBOOT_SPI-RADXA_rk35xx-2024.01--40842-g31b85240876 (May 14 2026 - 18:07:41 +0200)

Model: Radxa Compute Module 3(CM3) IO Board
DRAM:  2 GiB
PMIC:  RK8170 (on=0x40, off=0x00)
Core:  325 devices, 32 uclasses, devicetree: separate
MMC:   mmc@fe2b0000: 1, mmc@fe2c0000: 2, mmc@fe310000: 0
Loading Environment from FAT... ** No device specified **
Loading Environment from MMC... OK
In:    serial@fe660000
Out:   serial@fe660000
Err:   serial@fe660000
Model: Radxa Compute Module 3(CM3) IO Board
Net:   not found
309_MusicBox_V1.0=> 

Now i dont know what the problem was. Was it the fact i simply started with a fresh configuration or is this rk35xx branch just better? i am still figuring this out. Also weird how it did not work with the mainline version. Anyways, i will now compile in all stuff i need and all commands and modify it to my likings and see if it still boots.

Configuring it
#

So i configured things like network interface and led and gpio the same way and then compiled it. It did boot but still there where no network interfaces detected so i saw i forgot to enable rgmii and the designware rockchip phy. Now with those enabled and recompiled it works! Ethernet device eth0 is detected.

U-Boot SPL 2024.01-309_Mus!cB0x_V1.0-UBOOT_SPI-RADXA_rk35xx-2024.01--40842-g31b85240876 (May 14 2026 - 18:07:41 +0200)
Trying to boot from SPI
## Checking hash(es) for config config-1 ... OK
## Checking hash(es) for Image atf-1 ... sha256+ OK
## Checking hash(es) for Image u-boot ... sha256+ OK
## Checking hash(es) for Image fdt-1 ... sha256+ OK
## Checking hash(es) for Image atf-2 ... sha256+ OK
## Checking hash(es) for Image atf-3 ... sha256+ OK
NOTICE:  BL31: v2.14.0(release):9a80def
NOTICE:  BL31: Built : 23:00:05, May 10 2026
NOTICE:  BL31: Rockchip release version: v1.0


U-Boot 2024.01-309_Mus!cB0x_V1.0-UBOOT_SPI-RADXA_rk35xx-2024.01--40842-g31b85240876 (May 14 2026 - 18:07:41 +0200)

Model: Radxa Compute Module 3(CM3) IO Board
DRAM:  2 GiB
PMIC:  RK8170 (on=0x40, off=0x00)
Core:  325 devices, 32 uclasses, devicetree: separate
MMC:   mmc@fe2b0000: 1, mmc@fe2c0000: 2, mmc@fe310000: 0
Loading Environment from FAT... ** No device specified **
Loading Environment from MMC... OK
In:    serial@fe660000
Out:   serial@fe660000
Err:   serial@fe660000
Model: Radxa Compute Module 3(CM3) IO Board
Net:   eth0: ethernet@fe010000
309_MusicBox_V1.0=> 

So i ran the ‘dhcp’ command and that worked too!. Yay, leds and network are now also working.

End
#

So this article is a bit short and i did not include all th bits as i am aslo kind of tired/frustrated after having spend +3 days on getting it booting from the SPI flash without those stupid SPL errors and i am only done with Uboot and still have to tackle the building of the Linux kernel and rootfs for the device and that in itself is another can of worms/rabbit holes. I will tackle the Linux os but first i will take a few days break. I am happy that now it fully boots from SPI but the issues are not gone yet. ‘sf test’ still fails and when i do saveenv it does say that it saves the environment file to the SPI flahs but upon reboot it seems like that it has not done it as it boots up every time with an error down below.

Loading Environment from SPIFlash... SF: Detected gd25lq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
*** Warning - bad CRC, using default environment

But this could just be a simple configuration issue (or at most some issue with timing or configuration of the SPI flash or Uboot/the Devicetree) but i will tackle this later.

I also have plans on working on the blog a bit more, cleaning up/optimising things and maybe adding a newsleter service that people can sign up for (free ofcourse) so they can be notified and up to date when i post a new article or when i have news to share like (planned) downtime/maintenance moments and more. But thats mostly a WIP and is in its early stages.It will again be a system i either selfhost or thats privacy focussed and by preference european.

Author
309Electronics