Luckfox Forums

I do not have an Ubuntu Intel box to generate Luckfox-pico bootable Ubuntu SD micro card.

A workable solution was achieved using an old Intel-based MacBook Pro running Ubuntu 22.04 in Parallels. This is 6 years old kit and not supportable into the future. I have access to Arm-based Macs and Arm-based Ubuntu boxes (e.g. Raspberry Pi and Arm-based Parallel-hosted virtual Ubuntu).

It appears that although Luckfox-pico is itself Arm-based, it is a requirement that an Intel box runs the cross compilation and a Windows box runs the SocToolKit image-burner (which no longer runs in a Ubuntu 22.04 GUI).

The major Arm-only stopping point is that Ubuntu does not host non-Intel gcc-multilib and g++-multilib.

Has anyone found a solution to generating Luckfox Pico bootable SD images that do not require an Intel box somewhere in the process?

Hello
When building an image, you need to rely on arm-rockchip830-linux-uclibcgnueabihf, but the X86-64 cross-compilation tool provided by Rockchip is arm32, so there is currently no solution to build an image of luckfox pico on MAC

Using docker or replacing the cross-compilation tool arm-linux-gnueabihf-binutils might be a viable solution, but we don't have MAC M-series machines so we haven't tested it

Crocodile wrote: ↑2025-03-31 2:12 Hello
When building an image, you need to rely on arm-rockchip830-linux-uclibcgnueabihf, but the X86-64 cross-compilation tool provided by Rockchip is arm32, so there is currently no solution to build an image of luckfox pico on MAC

Using docker or replacing the cross-compilation tool arm-linux-gnueabihf-binutils might be a viable solution, but we don't have MAC M-series machines so we haven't tested it

Thank you for your quick and helpful response. Much appreciated. I've tried some work-arounds to avoid the use of a real X86 processor to build a luckfox pico SD image. Parallels won't let me run an X86 Ubuntu OS on my Arm M-series Mac. Perhaps UTM on QEMU might work instead (I'll try to get this going soon).

Similarly Linux running on Raspberry Pi (Arm processor) does not let me run a cross compiler that requires X86 components. I have not yet tried to get an X86-capable docker setup which would have to include an X86 order-code translator which I've not yet found.

I will try to get arm-linux-gnueabihf-binutils working on my M-series Mac ("homebrew" ported. Do you have any hints on how I would get this cross-compiler integrated into luckfox build.sh. My most recent attempt at switching the cross-compiler gave:

[build.sh:error] Not found toolchain arm-rockchip830-linux-uclibcgnueabihf-gcc for [rv1106] !!!

I'll try UTM first. If that does not work I'll get back to modifying build.sh and will report back for the forum. Oddly, there are a bunch of similar M-series questions scattered in this forum dating back to last October with no follow-ups.

(ASIDE: where you see "{SDK_PATH}" in luckfox Wiki, if you can, please change it to "${SDK_PATH}")

We are unable to provide effective assistance regarding issues on Mac M-series devices in the forum. This is not only because we do not have Mac M-series machines, but also because the Rockchip platform does not have as mature an ecosystem as Raspberry Pi.
Most Rockchip embedded developers, including Rockchip officials, primarily use x86_64 Windows and Linux systems. Many related development tools do not support running on Mac. For example, RV1103/RV1106, which uses uClibc as the main compilation tool, has even lower platform compatibility. Unless there are special circumstances, we recommend using an x86_64 platform to avoid unnecessary effort on environment compatibility issues.

Solely M-Series cross-compiling for Luckfox Pico Max solution has been achieved. Here are the details of one solution that avoids any actual (real) X86 hardware.

Used:

• Mac M-Series (tested with MacOS Sequoia).
• UTM (https://mac.getutm.app) with "Emulate" X86-64 Ubuntu Server 8GB(RAM)/30GB(virtual disk)/2 cores (ubuntu-22.04.5-live-server-amd64.iso). I chose the server (all CLI) to avoid having to run a GUI desktop, which is *very* slow.
• Parallels with virtual X86 Windows 11

Steps: (from https://wiki.luckfox.com/Luckfox-Pico/Luckfox-Pico-SDK)

Start UTM install and boot Emulated X-86-64 Ubuntu Server 22.04.5.
Configure for 8GB RAM, 30GB virtual disk and, in my case a user "alien".
Once logged in, to the newly booted server, the command:

(shell commands, "$ " is the bash prompt (not typed))

$ ip a

shows the current UTM server's IP number, which was also magically auto configured into the Mac's TCP-IP remote ssh access. e.g. From my Mac's Terminal.app I could type:

$ ssh alien@192.168.64.9

to get remote CLI access to the Ubuntu server via as many Mac terminal windows as I wanted.

As a crosscheck, I installed "neofetch" on the server by typing:

$ sudo apt install neofetch
$ neofetch

outputs:
Starting the cross compiler:

$ sudo apt update
$ sudo apt upgrade

The next apt-get is all on one line from "git" to "rsync"

$ sudo apt-get install -y git ssh make gcc gcc-multilib g++-multilib module-assistant expect g++ gawk texinfo libssl-dev bison flex fakeroot cmake unzip gperf autoconf device-tree-compiler libncurses5-dev pkg-config bc python-is-python3 passwd openssl openssh-server openssh-client vim file cpio rsync

$ cd ${HOME}; git clone https://github.com/LuckfoxTECH/luckfox-pico.git

$ export SDK_PATH=${HOME}/luckfox-pico

Here I edited the file:

"BoardConfig-SD_CARD-Buildroot-RV1106_Luckfox_Pico_Max-IPC.mk"

in the directory:

"${HOME}/luckfox-pico/project/cfg/BoardConfig_IP"

changing 6G to 56G to accommodate a larger 64GB SD card rootfs.img "/" partition. I probably could have gone larger (perhaps to 62GB) but did not push it.

The next ./build.sh I chose [6] RV1106_Luckfox_Pico_Max, [0] SD_CARD, and [1] Ubuntu

$ sudo ./build.sh lunch
$ date; sudo ./build.sh; date

After an initial short delay, followed by 1 hour and 45 mins of build progress, finally ending with these 2 green lines of output:

[build.sh:info] Running build_save succeeded.
[build.sh:info] Running build_allsave succeeded.

The configured 30GB of allocated drive started with 22GB free and ended with 4.1GB free. The build script appears to make 2 full copies of the SD card images on the Ubuntu filestore. One in:
and the other in:
the latter being the only directory containing a hidden file named:
Having generated the SD ".img" files, the next task is to write them to the SD card. I'm using MicroSDXC UHS-I Class 10 Memory Cards, (A2, U3, V30). They usually get around 90MB/seconds read and write speeds.

The Linux version of the tool that writes the images to an SD card (SocToolKit) fails to launch with a silent GUI error. There is a python CLI version of the writer found here:

https://gist.github.com/Spiritdude/da36 ... 0a8b9f972f

(thanks Spiritdude) but that takes more than 20 minutes to complete (it writes to the device in 1kB chunks).

Parallels-hosted X86 Windows 11 runs the official version of SocToolKit, documented here:

https://wiki.luckfox.com/Luckfox-Pico/L ... d-flashing (make sure to right-click and run as admin).

To allow Windows to gain access to the images, I need to copy them to my Mac's filestore. Given I know the IP number assigned to the virtual Ubuntu machine using

$ ip a

which, on my VM gives:
I was able to recursively copy the ".img" files running "scp" using my Mac terminal with this command:
which created and filled a new "image" folder in the current working directory on my Mac's terminal. Having set up my Windows VM to share access to my Mac's files, I was able to access the Mac copy of the images from within the Windows SocToolKit app and write them to a new SD device just plugged in and assigned to Windows 11 via a Parallels popup.

Logging in to Luckfox pico max board from a Mac:
Just in case this is of use, there are two main methods to actually talk to the booted Ubuntu on the Luckfox board:

1. Direct Ethernet connection using ssh over TCP-IP (as many simultaneous connections as you like, including Samba volume mounting, scb, sftp, etc.).

Connecting the Luckfox board using an Ethernet RJ45 cable, to your router, works without any further software setup. The trick is to discover the DHCP-allocated IP number assigned to the Luckfox board upon connection. I cheat by using the LAN/Scan action provided by the iOS and Android application called "Net Analyzer" found at https://techet.net/netanalyzer/. The Luckfox board's IP number is labeled with the name "LUCKFOX" or "luckfox" once the Net Analyzer LAN->Scan operation is complete. Once you know the Luckfox board's IP number you can use a terminal from any device on your subnet with:

$ ssh pico@<IP number>

(with default password luckfox (case sensitive)). The discovered <IP number> is of the form 192.168.1.99 (no angle brackets and your numbers will likely be different). As before, "$ " represents the terminal app's shell prompt (don't type it).

Normal Ubuntu mechanisms to set up and use a static IP number ("interfaces" file, "netplan" application) don't seem to be configured in the supported Luckfox Ubuntu distribution. The recommended mechanism to set up, and use, a static IP number (that works) is documented here:

https://wiki.luckfox.com/Luckfox-Pico/L ... nvironment

2. 3-wire UART<->USB, single terminal connection. e.g.
https://www.aliexpress.us/item/2251832450947101.html
and https://wiki.luckfox.com/Luckfox-Pico/L ... trol-shell

With or without a connected RJ45 Ethernet cable you can achieve a console terminal connection by attaching a USB UART board using 3 wires. i.e. board-pin#1->UART-rx, board-pin#2->UART-tx, and board-pin#3->UART-ground. I would not power the board from the USB UART in case your UART provides 5V and you connect that to a Luckfox 3.3V board-pin. I usually power the Luckfox board from the USB-C cable. This also means you can see the early booting-activity console messages by having the console connected while plugging in the USB-C cable. Lots and lots of info.

Running a Luckfox console terminal via the correct Mac device is also an interesting exercise. If you connect the USB UART board to the Mac, the UART should auto configure itself on your Mac and create two new /dev entries. Just after I plug in the USB UART board I type:

$ ls -latr /dev | tail -20

That command reverse orders the most recently modified /dev entries at the bottom of its output and displays just the last 20 entries. Within those last 20 entries two lines should appear that look similar to these:
The important info in that command is just the names of the newly created devices. You can probably use either device nowadays as "cu" stands for call-unit and used to mean that hardware modem flow-control signals were implemented (CTS/RTS/DTS). Modern UARTs and CPUs should be fast enough so that flow control should be irrelevant especially since we're just using 3-wires here and modem control signals have nowhere to go.

The Mac has a built in terminal (CLI) command to connect the terminal to a serial device. Given my USB UART device names as shown above, I would use:

$ screen /dev/tty.usbserial-0001 115200
(to quit type "^a" followed by "k" and a "y" to confirm the quit ("^a" means control+a, and again, don't type the quote marks)).

$ man screen

Should be sufficiently confusing for anyone. I usually use the 3rd party command "tio" https://github.com/tio/tio instead of "screen".

All done on an M-series Mac (avoiding having to run on "real" X86 kit).

ASIDE @Crocodile: I understand how difficult it can be to support a broader development tool base. I too am a developer with my own GUI-based toolset that has migrated across many OSs and platform-independent presentation layers (Classic Mac->MacOSX and iOS, ThinkC->Symantec-C->Metrowerks->Xcode, 68000->PowerPC->X86->Arm, XVT->SDL->SDL-2->SDL-3). Oddly the X86 environment has always been more work-intensive to keep it running as a development/support platform and in my environment has been relegated to purely a delivery platform. A long-standing practical decision that I keep revisiting in the hope of discovering increased development leverage but have always been disappointed (except to keep my room warm during the winter, for which X86 hardware excels).

FWIW luckfox paired with Ubuntu is currently the most reliable, versatile, cost-effective, well documented, low power-consumption, & supported, micro delivery platform. Kudos.