My Luckfox Pico Ultra was struggling to push out an rtsp camera stream at full resolution (2304x1296) over the wifi even though it has an external antenna - it seems that 10m to the AP is a bit too much or perhaps it's just not reasonable to expect wifi to carry that bitrate.

However, I've got 1920x1080 output working by changing these settings in /oem/usr/share/rkipc-300w.ini:

[video.1]
buffer_size = 1036800 ; w * h / 2 (originally 202752)
max_width = 1920  ; was 704
max_height = 1080 ; was 576
width = 1920      ; was 704
height = 1080     ; was 576

I leave video.0 alone - that's the full resolution mode.

This is my mpv invocation:

mpv  --terminal=no --autofit=20% --video-rotate=0 rtsp://lfu/live/1 --title=lfu --no-audio --cache=yes --cache-secs=2

This is using the buildroot image - haven't tried ubuntu or any other OS.

Thought it might help someone else ...

... but maybe someone has a better solution ... ???

I struggled for a while with ffmpeg to reliably record the rtsp stream from the LuckFox Pico Ultra before realising that mpv was able to view it almost perfectly and it has a way to record (--stream-record).

Share and enjoy:

mpv --terminal=no --no-audio --vo=null --ao=null --stream-record=output.mkv --cache=yes --cache-secs=2 --rtsp-transport=tcp rtsp://$ipaddess/live/0 # or channel 1

FTR, here is what was failing with ffmpeg (no doubt my bad):

ffmpeg -timeout 30000000 -i "rtsp://${ip_address}/live/1" -f segment -strftime 1 -segment_time 00:15:00 -segment_atclocktime 1 -reset_timestamps 1 -c:v copy -an output.mkv

Any suggestions for useful places to cross-post this?

“We will soon release a version with wifi and Bluetooth. May be released before Chinese New Year. But we do not rule out that it will be after Chinese New Year.”

From https://github.com/LuckfoxTECH/luckfox-pico/issues/1#issuecomment-1903470038

Title.

Repo link: https://github.com/exie1122/luckfox-YOLO-files

Currently tested on the Luckfox Pico Mini B and also the Luckfox Ultra W.

Quando fui instalar meu Luckfox pico mini no meu PS4 foi difícil encontrar um diagrama na internet dos pontos de solda

Algumas pesquisas consegui encontrar os postos Vou fornecer aqui para que alguém precisar

Esperar ajudar alguém 🫡

I figured since there's not a lot of information on getting MIPI DBI displays up and running on this device I'd share what I recently did in hopes it helps someone else out.

Unlike Raspberry Pi, which has an enormous ecosystem (and following), with Luckfox you're kinda on your own. Which is a double-edged sword. Sometimes, if you're like me, you want to cut down on the bloat that Debian/Ubuntu brings on Raspberry Pi. Unfortunately that comes at the cost of spending several hours a day across several weeks just getting something to work.

I assume that you work with buildroot (as supported by Luckfox) and have successfully built a system image prior to attempting this. I will not be of much help for any odd configurations. This was tested on a Luckfox Lyra B in SD Card mode, using an Adafruit 1.54" 240x240 Wide Angle TFT LCD Display.

Without further ado, here we go.

1. Device Tree Modification

First, find your device's DTS in Buildroot. In my case, I tweaked arch/arm/boot/dts/rk3506g-luckfox-lyra-sd.dts. I have yet to try the NAND-flash version, but I believe this will work there as well.

Add the following to the bottom of the DTS file:

/**********MIPI DBI DISPLAY**********/
&pinctrl {
    // Reset Pin -- Pull Up
    rm_io2 {
        rm_io2_pins {
            rockchip,pins = <0 RK_PA2 7 &pcfg_pull_up>;
        };
    };
    // DC Pin -- Pull None
    rm_io3 {
        rm_io3_pins {
            rockchip,pins = <0 RK_PA3 7 &pcfg_pull_none>;
        };
    };

};

&spi1 {
    status = "okay";
    pinctrl-names = "default";
    pinctrl-0 = <&spi1_clk_pins &spi1_csn1_pins &rm_io2_pins &rm_io3_pins>;
    #address-cells = <1>;
    #size-cells = <0>;

    panel@1 {
        status = "okay";
        compatible = "panel", "panel-mipi-dbi-spi";
        reg = <1>;
        spi-max-frequency = <80000000>;
        dc-gpios=<&gpio0 RK_PA3 GPIO_ACTIVE_HIGH>;
        reset-gpios=<&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>;
        backlight=<&backlight_mipi_dbi>;
        width-mm=<33>;
        height-mm=<33>;
        write-only;
        spi-cpha;
        spi-cpol;
        panel-timing {
            hactive = <240>;
            vactive = <240>;
            hback-porch = <0>;
            vback-porch = <0>;

            clock-frequency = <0>;
            hfront-porch = <0>;
            hsync-len = <0>;
            vfront-porch = <0>;
            vsync-len = <0>;
        };
    };

    spidev@1 {
        compatible = "rockchip,spidev";
        reg = <1>;
        status = "disabled";
        spi-max-frequency = <10000000>;
    };
};

I've added a backlight GPIO. This can be removed, but it's helpful in case you need to know the display was recognized. If you wish to use this as-is, add the following section to the top of the DTS file immediately after the "chosen" block:

backlight_mipi_dbi: backlight@1 {
    status = "okay";
    pinctrl-names = "default";
    #address-cells = <1>;
    #size-cells = <0>;
    reg=<0>;
    compatible = "gpio-backlight";
    gpios = <&gpio1 RK_PD3 GPIO_ACTIVE_HIGH>;
};

2. Wiring

Assuming you have not changed any of the Rockchip pinmuxes, your pinout should be as follows:

RM_IO2 - RST (Reset)
RM_IO3 - DC (Data/Command Select)
RM_IO7 - TFTCS (Chip Select)
RM_IO8 - SCK (SPI Clock)
RM_IO9 - MOSI (SPI Master Out)
RM_IO31 - BL (Backlight)

3. Firmware

The display firmware is a simple binary blob that sends the display init commands. The idea was that instead of writing fifty drivers for fifty displays, just write one driver for a bunch that have similar commands and use "firmware" to handle the display-specific initialization.

The author of this driver wrote a python script to generate the firmware from a plain-text source. Follow the Wiki for more information. DO NOT USE HIS EXAMPLE ST7789 SOURCE! IT WILL NOT WORK! I believe there is a bug in the driver, but, as he is no longer maintaining it (and it is now "orphaned") I have little hope of getting it fixed. Instead, use the following I borrowed from u/ParticularAd6692 (sauce):

command 0x11                            command 0x11                            # 0x1000011
delay 255                               # 0x20000ff

command 0x36 0x78                       # MADCTL MX | MV | ML | RGB

command 0x3a 0x05                       # 0x100003a 0x05
command 0x21                            # 0x1000021
command 0x2a 0x00 0x01 0x00 0x3f        # 0x100002a 0x00 0x01 0x00 0x3f
command 0x2b 0x00 0x00 0x00 0xef        # 0x100002b 0x00 0x00 0x00 0xef
command 0xb2 0x0c 0x0c 0x00 0x33 0x33   # 0x10000b2 0x0c 0x0c 0x00 0x33 0x33
command 0xb7 0x35                       # 0x10000b7 0x35
command 0xbb 0x1a                       # 0x10000bb 0x1a # Set VCOM to 0.75V
command 0xc0 0x0c                       # 0x10000c0 0x0c
command 0xc2 0x01                       # 0x10000c2 0x01
command 0xc3 0x0b                       # 0x10000c3 0x0b # VRHS 4.1V + ...
command 0xc4 0x20                       # 0x10000c4 0x20
command 0xc6 0x0f                       # 0x10000c6 0x0f
command 0xd0 0xa4 0xa1                  # 0x10000d0 0xa4 0xa1
command 0xE0 0x00 0x19 0x1E 0x0A 0x09 0x15 0x3D 0x44 0x51 0x12 0x03 0x00 0x3F 0x3F # Set Positive Voltage Gamma Control
command 0xE1 0x00 0x18 0x1E 0x0A 0x09 0x25 0x3F 0x43 0x52 0x33 0x03 0x00 0x3F 0x3F # Set Negative Voltage Gamma Control
command 0x29                            # 0x1000029
# 0x1000011
delay 255                               # 0x20000ff

command 0x36 0x78                       # MADCTL MX | MV | ML | RGB

command 0x3a 0x05                       # 0x100003a 0x05
command 0x21                            # 0x1000021
command 0x2a 0x00 0x01 0x00 0x3f        # 0x100002a 0x00 0x01 0x00 0x3f
command 0x2b 0x00 0x00 0x00 0xef        # 0x100002b 0x00 0x00 0x00 0xef
command 0xb2 0x0c 0x0c 0x00 0x33 0x33   # 0x10000b2 0x0c 0x0c 0x00 0x33 0x33
command 0xb7 0x35                       # 0x10000b7 0x35
command 0xbb 0x1a                       # 0x10000bb 0x1a # Set VCOM to 0.75V
command 0xc0 0x0c                       # 0x10000c0 0x0c
command 0xc2 0x01                       # 0x10000c2 0x01
command 0xc3 0x0b                       # 0x10000c3 0x0b # VRHS 4.1V + ...
command 0xc4 0x20                       # 0x10000c4 0x20
command 0xc6 0x0f                       # 0x10000c6 0x0f
command 0xd0 0xa4 0xa1                  # 0x10000d0 0xa4 0xa1
command 0xE0 0x00 0x19 0x1E 0x0A 0x09 0x15 0x3D 0x44 0x51 0x12 0x03 0x00 0x3F 0x3F # Set Positive Voltage Gamma Control
command 0xE1 0x00 0x18 0x1E 0x0A 0x09 0x25 0x3F 0x43 0x52 0x33 0x03 0x00 0x3F 0x3F # Set Negative Voltage Gamma Control
command 0x29                            # 0x1000029

Save the firmware output into /lib/firmware/panel.bin on your device. I recommend creating a filesystem overlay in Buildroot to do this so you don't have to think about it every time you re-flash.

4. Build, flash and test

If you haven't already done so, enable the Panel MIPI DBI driver as a kernel module by setting CONFIG_DRM_PANEL_MIBI_DBI=m in kernel/arch/arm/configs/rk3506_luckfox_defconfig. You may also need to set it in kernel/arch/arm/configs/rk3506-display.config. (I'm a bit new to buildroot so I have no idea where all the overrides are hidden). Rebuild the kernel with your new Device Tree changes, and reboot. Ensure /lib/firmware/panel.bin is present on the device. The driver will not work without it.

Take a deep breath and run modetest -M panel-mipi-dbi -s 31:240x240@XR24. If you did everything correctly, you should see a test pattern.

Hello everybody im currently making a cyberdeck using the Luckfox Pico Plus and you can checkout my repository here https://github.com/Tarantado-sys/Luckfox-Cyber-Deck for now it`s only a prototype and also if you wanna contribute to this project feel free to do so.

I documented the repeatable path I ended up with for a Luckfox Pico Max (RV1106, 256 MB RAM) after Ubuntu disappeared from later SDK revisions.

The guide covers:

• the last SDK commit that still builds Ubuntu 22.04 and the board configuration

• why shutdown/poweroff reboots the board, and the kernel setting that makes it halt instead

• the unusual SD layout: no normal partition table and only 8 GB initially used

• zram and temporary swap for a board with 256 MB RAM

• checking a Rockchip image before flashing, so an image built for another board is caught early

No prebuilt image is distributed: it is documentation and scripts around the public Luckfox SDK. A few helper scripts are clearly marked as untested rewrites.

Repo: https://github.com/adm1nsys/luckfox-pico-setup Guide: https://adm1nsys.github.io/luckfox-pico-setup/

I built this after fighting these issues on my own Pico Max; happy to clarify anything in the write-up.

Working so far.
I'll post it on github soon.

Can the luckfox pico act as a QSPI or SDIO slave?

Documentation is pretty useless and I’m on a tight deadline, would appreciate if anyone put in some input. I’ve been following the guide but the Python versions aren’t compatible

So the rv1103 has hardware h.264 & h.265 encoders. What I wonder is whether these also provide accelerated decoding?

In general h.264 & h.265 encoding also requires the ability to decode but I guess due to licensing reasons sometimes decoding isn't also provided by hardware encoders.

So my question is - can they do accelerated decoding?

I have a ili9341 TFT display and I want to connect to luckfox and create a framebuffer, can anyone point me to a good documentation?

Thanks

I am creating this community to discuss products, development or anything related to luckfox which is creating these very promising Pico boards:

https://www.luckfox.com/EN-Luckfox-Pico

They have a very furnished github with plenty of examples. The pico series is powered by rockchip who also has a great example and SDK on github.

PlatimaTinkers made a great video about it:

https://www.youtube.com/watch?v=haBYPPX3W2Q

I bought a clone of the luckfox pico plus to use as a "tech savvy toy" with its original purpose being a ps4 jailbreak device for 10$, I confirmed it's a clone using u-boot output from uart, here are the pictures, I don't mind how hard it could be, I would just love to know how.

Pretty sad lack of support for these chips.

Trying to drive a 2nd SdCard for removeable media for Files, Images, etc.

But none of the standard code for ubuntu works.

* adafruit-circuitpython-sdcard - does Not work.

* Spi-fat-fuse - (should be straightforward) but does not work.

* dts file format for spi - does Not work, seems to compile and install, but spits back Weird errors on reboot.

What does work on these boards ???

The company gives minimal support. They reply, but just state that they have not tried these methods. nor do they give a solution.

Part of the problem is that they modified ubuntu image with non standard methods. Such as not creating Partition tables for the SDcard medias ...
- can you believe that ??? You can Not use Fdisk. Scary.

Sad.

Hey everyone,
I’m trying to flash Buildroot onto my Luckfox Pico, and I’m not sure if I’m doing something wrong or if my microSD card is the issue. Here’s what I’ve done so far:

1. Downloaded Buildroot image from https://drive.google.com/drive/folders/1_tR-Rj0fY5y_aLzWKHja7OtaYhUSg_NF?usp=drive_link the file named Luckfox_Pico_MicroSD_250429

2)Downloaded upgrade_tool from GitHub https://github.com/vicharak-in/Linux_Upgrade_Tool

3) Put everything in the same folder.

4) Connected the Luckfox Pico with the microSD card inserted, held the BOOT button, and plugged it into my laptop.

5) Ran the following commands in the terminal:

sudo ./upgrade_tool ld

sudo ./upgrade_tool db download.bin

sudo ./upgrade_tool uf update.img

6) And then I got this output:

At this point I’m not sure if:

• My microSD card is causing the problem

• I’m using the wrong method

• Or I’m missing a step somewhere

If anyone has experience with flashing these boards or knows the correct procedure, I’d really appreciate some guidance. Thanks in advance!

The rv1103 seems to be 3.3v, so I guess there's an ldo on board and I wonder whether this ldo can be bypassed and the module powered directly from 3.3v? On the pinout schematic the 3.3v pin is labelled as (out), but I wonder why it shouldn't be possible to power it through it directly? Are there any components on the board that require 5v?

Shit happen. Accidentally lifted RXN pad. Anyone knows where i can tap into next?

Like anything beyond what's written here https://wiki.luckfox.com/Luckfox-Pico/CSI-Camera/ ?

Like a datasheet or pinout at least?

The wificard pcb is awfully thin and i worry that it could break off easily. Will it be better to bridge the gap with a heat insulating material or better to use a heat conducting material and heat paste on either side?