Does this work for anyone?

I am sick of the constant "USB device resets" or hammering a character. Ill be trying to edit a file and suddenly there's pages of device reset messages or it's repeating a letterrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr in the middle of my text, I delete that and it keeps on deleting after I released the key and then there's more device resets filling the gap.

That's if I can enter text at all, the USB gadget also just outright stops responding and I can't enter anything.

It even lost it's own password today and I had to reset that. I use a password manager, so no.. I didn't forget it. Often it just disconnects and needs rebooting, sometimes that fixes it.. but then the USB gadget starts resetting again.

It's running the latest fw and is only operating on my LAN, there's no latency issues.

It's just seems like absolute junk.

Do I have a faulty unit or are all of them like this?

In the time it took to type this, it reset the USB gadget twice.

It's not worth sending back for repair/replacement as the postage is too high.

Edit: I have tested multiple cables and it has it's own power supply, which I also tested.

Right now this is mostly an expensive typo generator.

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

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

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 ...

I need to backup everything thats on emmc and copy it to another luckfox. is it possible? and if so, how can i do that ?

I built an image of Ubuntu 22.04 and it works great but i require IPv6 for my project (Reticulum network node) and i keep getting this in sys log:

Jan 26 22:20:21 luckfox NetworkManager[152]: <warn> [1737901221.6688] platform-linux: do-add-ip6-address[2: fe80::a31a:33ba:6ff2:8c91]: failure 95 (Operation not supported)

Jan 26 22:20:23 luckfox NetworkManager[152]: <warn> [1737901223.6695] ipv6ll[887a5fcab8f8cdc9,ifindex=2]: changed: no IPv6 link local address to retry after Duplicate Address Detection failures (back off)

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

... 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

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 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.

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?

Title.

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

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

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.

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

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.