PINE64 - Linux on RockPro64

Freezes and kernel panics with Debian trixie

Tue, 13 Jan 2026 13:58:43 +0000

Hi there,

after running quite smoothly for several years, since the upgrade to Debian trixie, my ROCKPro64 has become quite unstable.

I am using a JMicron Technology Corp. JMB58x AHCI SATA controller in the PCIe slot. The first symptom I had was that after the reboot after the upgrade, the status LEDs on the controller did not turn on. I connected a monitor on HDMI and there was no signal.

I have now advanced a couple iterations of debugging and here is what I have.

If the PCIe card is in, I get panics related to PCIe, such as:

Code:
[    4.965205] SError Interrupt on CPU5, code 0x00000000bf000002 -- SError

[    4.965230] CPU: 5 UID: 0 PID: 52 Comm: kworker/u25:3 Tainted: G   M               6.12.63+deb13-arm64 #1  Debian 6.12.63-1

[    4.965249] Tainted: [M]=MACHINE_CHECK

[    4.965253] Hardware name: Pine64 RockPro64 v2.1 (DT)

[    4.965260] Workqueue: events_unbound deferred_probe_work_func

[    4.965285] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)

[    4.965297] pc : rockchip_pcie_rd_conf+0x194/0x2c0

[    4.965315] lr : rockchip_pcie_rd_conf+0x188/0x2c0

[    4.965326] sp : ffff8000828037a0

[    4.965331] x29: ffff8000828037a0 x28: ffff000001fbf800 x27: 0000000000000001

[    4.965348] x26: 0000000000000000 x25: 0000000000000001 x24: 0000000000000001

[    4.965362] x23: ffff800082485000 x22: 0000000000000000 x21: ffff8000828037e4

[    4.965377] x20: 0000000000000000 x19: 0000000000000004 x18: ffffffffffffffff

[    4.965390] x17: 30302f30303a3030 x16: 30306963702f6569 x15: 63702e3030303030

[    4.965404] x14: ffff8000824bb460 x13: 0000000000000326 x12: 0000000000000000

[    4.965418] x11: 0000000000000001 x10: 0000000000000000 x9 : ffff8000808698d0

[    4.965431] x8 : 0000000124f798bc x7 : ffff000005740380 x6 : ffff000005747000

[    4.965445] x5 : ffff000001fbf800 x4 : ffff800087000000 x3 : 0000000000c00008

[    4.965458] x2 : 000000000080000a x1 : ffff800087c00008 x0 : ffff800087c0000c

[    4.965475] Kernel panic - not syncing: Asynchronous SError Interrupt

[    4.965481] CPU: 5 UID: 0 PID: 52 Comm: kworker/u25:3 Tainted: G   M               6.12.63+deb13-arm64 #1  Debian 6.12.63-1

[    4.965496] Tainted: [M]=MACHINE_CHECK

[    4.965500] Hardware name: Pine64 RockPro64 v2.1 (DT)

[    4.965505] Workqueue: events_unbound deferred_probe_work_func

[    4.965517] Call trace:

[    4.965521]  dump_backtrace+0xd8/0x130

[    4.965534]  show_stack+0x20/0x38

[    4.965543]  dump_stack_lvl+0x60/0x80

[    4.965556]  dump_stack+0x18/0x28

[    4.965566]  panic+0x164/0x378

[    4.965582]  nmi_panic+0x90/0x98

[    4.965598]  arm64_serror_panic+0x78/0x90

[    4.965608]  do_serror+0x30/0x80

[    4.965617]  el1h_64_error_handler+0x30/0x48

[    4.965629]  el1h_64_error+0x64/0x68

[    4.965638]  rockchip_pcie_rd_conf+0x194/0x2c0

[    4.965650]  pci_bus_read_config_dword+0x8c/0x140

[    4.965663]  pci_bus_generic_read_dev_vendor_id+0x38/0x178

[    4.965678]  pci_scan_single_device+0xb4/0x120

[    4.965691]  pci_scan_slot+0x60/0x230

[    4.965703]  pci_scan_child_bus_extend+0x4c/0x2e0

[    4.965717]  pci_scan_bridge_extend+0x180/0x5a8

[    4.965731]  pci_scan_child_bus_extend+0x1c4/0x2e0

[    4.965744]  pci_scan_root_bus_bridge+0x6c/0xe8

[    4.965758]  pci_host_probe+0x38/0xe0

[    4.965771]  rockchip_pcie_probe+0x3a0/0x530

[    4.965782]  platform_probe+0x70/0xe8

[    4.965796]  really_probe+0xc8/0x3a0

[    4.965806]  __driver_probe_device+0x84/0x160

[    4.965815]  driver_probe_device+0x44/0x130

[    4.965825]  __device_attach_driver+0xc4/0x170

[    4.965836]  bus_for_each_drv+0x90/0x100

[    4.965845]  __device_attach+0xa8/0x1c8

[    4.965854]  device_initial_probe+0x1c/0x30

[    4.965864]  bus_probe_device+0xb0/0xc0

[    4.965873]  deferred_probe_work_func+0xbc/0x120

[    4.965883]  process_one_work+0x178/0x3e0

[    4.965895]  worker_thread+0x204/0x3f0

[    4.965907]  kthread+0xe8/0xf8

[    4.965916]  ret_from_fork+0x10/0x20

[    4.965929] SMP: stopping secondary CPUs

[    4.965945] Kernel Offset: disabled

[    4.965948] CPU features: 0x08,00002082,c0200000,4200421b

[    4.965957] Memory Limit: none

[    4.994272] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---

If I boot without the PCIe card, I got what looked like a freeze on HDMI, but the UART logged this kernel panic:

Code:
[  106.672016] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000037

[  106.676856] Mem abort info:

[  106.681157]   ESR = 0x0000000096000004

[  106.685537]   EC = 0x25: DABT (current EL), IL = 32 bits

[  106.690074]   SET = 0, FnV = 0

[  106.694416]   EA = 0, S1PTW = 0

[  106.698736]   FSC = 0x04: level 0 translation fault

[  106.703208] Data abort info:

[  106.707515]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000

[  106.712069]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0

[  106.716632]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0

[  106.721166] user pgtable: 4k pages, 48-bit VAs, pgdp=000000000df71000

[  106.725827] [0000000000000037] pgd=0000000000000000, p4d=0000000000000000

[  106.730563] Internal error: Oops: 0000000096000004 [#1] SMP

[  106.735036] Modules linked in: nft_limit nft_masq nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables binfmt_misc snd_soc_hdmi_codec hantro_vpu aes_ce_blk rockchip_vdec(C) hci_uart v4l2_jpeg aes_ce_cipher crct10dif_ce v4l2_vp9 btqca polyval_ce v4l2_h264 polyval_generic rockchip_rga btrtl videobuf2_dma_contig btintel ghash_ce videobuf2_dma_sg gf128mul v4l2_mem2mem btbcm sha2_ce videobuf2_memops sha256_arm64 videobuf2_v4l2 snd_soc_audio_graph_card snd_soc_simple_card sha1_ce panfrost snd_soc_rockchip_i2s bluetooth snd_soc_spdif_tx snd_soc_es8316 snd_soc_simple_card_utils snd_soc_core videodev ofpart gpu_sched dw_hdmi_i2s_audio gpio_ir_recv des_generic dw_hdmi_cec pwm_fan snd_compress ecdh_generic leds_gpio spi_nor snd_pcm_dmaengine rk_crypto rfkill drm_shmem_helper snd_pcm videobuf2_common pwrseq_core crypto_engine snd_timer mtd mc libdes snd rockchip_saradc coresight_cpu_debug industrialio_triggered_buffer soundcore coresight_etm4x kfifo_buf rockchip_thermal industrialio coresight

[  106.735344]  cpufreq_dt evdev dm_mod nfsd auth_rpcgss nfs_acl lockd grace sunrpc efi_pstore configfs nfnetlink ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq libcrc32c crc32c_generic raid1 raid0 realtek md_mod xhci_plat_hcd xhci_hcd dwc3 rockchipdrm fusb302 udc_core rk808_regulator dw_hdmi tcpm cec ulpi dwmac_rk typec rc_core stmmac_platform fan53555 stmmac dw_mipi_dsi analogix_dp pwm_regulator gpio_rockchip drm_display_helper pcs_xpcs dwc3_of_simple phylink ohci_platform gpio_keys sdhci_of_arasan ohci_hcd mdio_devres drm_dma_helper ehci_platform phy_rockchip_inno_usb2 ehci_hcd of_mdio drm_kms_helper phy_rockchip_emmc sdhci_pltfm phy_rockchip_typec fixed_phy phy_rockchip_pcie usbcore nvmem_rockchip_efuse pl330 drm dw_wdt fwnode_mdio pwm_rockchip io_domain rockchip_dfi libphy cqhci dw_mmc_rockchip i2c_rk3x usb_common spi_rockchip dw_mmc_pltfm sdhci dw_mmc fixed

[  106.806464] CPU: 2 UID: 0 PID: 900 Comm: nft Tainted: G         C         6.12.63+deb13-arm64 #1  Debian 6.12.63-1

[  106.811298] Tainted: [C]=CRAP

[  106.815326] Hardware name: Pine64 RockPro64 v2.1 (DT)

[  106.819469] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)

[  106.823730] pc : nf_ct_iterate_cleanup+0xd4/0x240 [nf_conntrack]

[  106.827937] lr : nf_ct_iterate_cleanup+0xc0/0x240 [nf_conntrack]

[  106.832067] sp : ffff8000832f33b0

[  106.835817] x29: ffff8000832f33b0 x28: ffff8000832f3450 x27: 0000000000000000

[  106.839909] x26: ffff80007b451680 x25: ffff00000b594a00 x24: ffff80007b443538

[  106.844018] x23: ffff80007b452688 x22: ffff80007b451c40 x21: 000000000001eb80

[  106.848126] x20: 0000000000003d70 x19: ffff000020700000 x18: ffffffffffffffff

[  106.852210] x17: 000000000f7574be x16: 0000000094c09be4 x15: ffff00000529f895

[  106.856295] x14: ffff8000832f3240 x13: 0000000000000801 x12: ffff0000f77e0178

[  106.860330] x11: 000000007fffffff x10: 0000000000000064 x9 : ffff80007b43b308

[  106.864328] x8 : ffff0000f1072920 x7 : ffff0000f105a9c0 x6 : ffff80007b47eb10

[  106.868342] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000

[  106.872386] x2 : 0000000000000001 x1 : 0000000000000000 x0 : 0000000000000000

[  106.876346] Call trace:

[  106.879844]  nf_ct_iterate_cleanup+0xd4/0x240 [nf_conntrack]

[  106.883757]  nf_ct_iterate_cleanup_net+0x50/0x70 [nf_conntrack]

[  106.887678]  nf_ct_netns_do_get+0x1c0/0x220 [nf_conntrack]

[  106.891556]  nf_ct_netns_get+0xc8/0x100 [nf_conntrack]

[  106.895426]  nft_ct_get_init+0xa8/0x1b0 [nft_ct]

[  106.899134]  nf_tables_newrule+0x2d4/0x898 [nf_tables]

[  106.902984]  nfnetlink_rcv_batch+0x698/0x960 [nfnetlink]

[  106.906751]  nfnetlink_rcv+0x16c/0x1b0 [nfnetlink]

[  106.910483]  netlink_unicast+0x304/0x380

[  106.914126]  netlink_sendmsg+0x1ac/0x410

[  106.917709]  __sock_sendmsg+0x64/0xc0

[  106.921245]  ____sys_sendmsg+0x270/0x308

[  106.924786]  ___sys_sendmsg+0xb8/0x118

[  106.928209]  __sys_sendmsg+0x90/0x100

[  106.931533]  __arm64_sys_sendmsg+0x2c/0x40

[  106.934808]  invoke_syscall+0x6c/0x100

[  106.937919]  el0_svc_common.constprop.0+0x48/0xf0

[  106.941022]  do_el0_svc+0x24/0x38

[  106.943932]  el0_svc+0x38/0x150

[  106.946699]  el0t_64_sync_handler+0x120/0x138

[  106.949477]  el0t_64_sync+0x190/0x198

[  106.952089] Code: 3600009b 1400003b f940037b 3700073b (3940df60)

[  106.954847] ---[ end trace 0000000000000000 ]---

[  106.957390] Kernel panic - not syncing: Oops: Fatal exception in interrupt

[  106.960080] SMP: stopping secondary CPUs

[  106.962488] Kernel Offset: disabled

[  106.964664] CPU features: 0x08,00002082,c0200000,4200421b

[  106.966962] Memory Limit: none

[  106.968990] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---

These two panics were captured with the Debian trixie kernel 6.12.63+deb13-arm64, but I managed to get the same HDMI-level symptoms (cursor stops blinking) as with the second panic with the Debian bookworm kernel 6.1.0-42-arm64.

I am currently running memtest86.com on the board, but so far (58% of the first pass) I see no errors. The panics do not always occur. Sometimes I can get it to boot through completely, at which point it seems to be stable for multiple days. The likelihood of a successful boot is lower if the SATA controller is in, to the point that I haven't yet checked if (other) panics occur if I manage to boot through with the SATA controller installed. I don't want to find out, because that'd likely risk the data on the attached disks.

(there are no peripherials attached to the Pi header, except a Raspberry Pico-based UART adapter on UART0. there's nothing connected to any other port except a keyboard on USB, a display on HDMI, and a network cable on the 8P8C/RJ-45 port.)

Once the memtest86 is done, I'll try to capture tracebacks with the 6.1.0 kernel. As mentioned, though, the system used to run fine (as far as I can tell: there *were* issues where reboots got stuck, but I had those attributed to something on UART0 interrupting u-boot. there's a chance >0 that there were, in fact, similar issues before the trixie upgrade).

One thing I already investigated is the kernel_comp_size variable for u-boot, which I found as a possible cause for funny crashes in another thread. I raised it to 128 MiB, which initially seemed to fix things, but then I managed to create the errors again. That seems plausible, because the distance between initramfs and kernel (according to the kernel_addr_r and ramdisk_addr_r in u-boot) was ~94 MiB anyway and the trixie kernel is only ~38 MiB in size. I'm running u-boot from June 2021 from here: https://github.com/sigmaris/u-boot/releases

To me, this looks like some kind of hardware fault, most likely bad RAM. Does anyone have another idea?

[Manjaro] Fixing /etc/fstab from serial console while using lvm2

Thu, 16 Oct 2025 23:58:51 +0000

"Remember, it's not an adventure if part of it doesn't suck!"

I just moved my Rockpro64 from a 128GB emmc to a 256GB emmc, and I remembered everything except one thing: Updating /etc/fstab to use different UUIDs before swapping the emmcs. So it wouldn't finish booting. I attach the serial console, figure out what the problem is, and the question is, how do you fix it without using anything else?

I was in U-Boot to begin with, so we want to get to the initramfs where we have lvm tools. We have commands like 'fatls mmc 0:1' to look around. (List files on a FAT-formatted filesystem, emmc interface, device 0, partition 1)

https://docs.u-boot.org/en/stable/usage/index.html
https://docs.u-boot.org/en/stable/usage/cmd/booti.html

Code:
setenv bootargs break

fatload mmc 0:1 $fdt_addr_r /dtbs/rockchip/rk3399-rockpro64.dtb

fatload mmc 0:1 $kernel_addr_r Image

fatload mmc 0:1 $ramdisk_addr_r initramfs-linux.img

booti $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r

Now we are in the initramfs environment.

Code:
# blkid

# mkdir /mnt

# mount /dev/VG1/LV1 /mnt

# chroot /mnt

# vi /etc/fstab

Done, now we can reboot.

OpenEuler OS on RockPro64

Sat, 15 Jun 2024 15:38:40 +0000

Hi All,

Any ideas to run https://gitee.com/openeuler/rockchip openEuler 22.03 LTS SP3 Firefly-RK3399 on RockPro64.

It seams to be easy, but actually not know how. The boards FireFly and RockPro64 are 99% similar hardware.

https://hackerboards.com/compare/t-chip-...rockpro64/

Br,
Yuriy Gavrilov

RK3399 PCIe enumeration

Wed, 31 Jan 2024 14:56:31 +0000

I have a custom PCIe x4 lane card that I'm trying to integrate with a RockPro64 SBC. This custom card has been tested with many users on different platforms including a linux x86 system. When I try this card in a RK3399 system, I get a strange result when I view the assigned address space with the lspci command. It appears the address assigned is the exact value of the BAR address size for each BAR. If I change the BAR size the assigned address changes to that value. Below is a dmesg dump along with a lspci output for my device. Device is [ad00:001e]. Any guidance?

dmesg:
[ 2.395091] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges:
[ 2.395148] rockchip-pcie f8000000.pcie: MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000
[ 2.395175] rockchip-pcie f8000000.pcie: IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000
[ 2.396226] rockchip-pcie f8000000.pcie: supply vpcie1v8 not found, using dummy regulator
[ 2.396376] rockchip-pcie f8000000.pcie: supply vpcie0v9 not found, using dummy regulator
[ 2.571466] rockchip-pcie f8000000.pcie: wait 1000 ms (from device tree) before bus scan
[ 3.582289] rockchip-pcie f8000000.pcie: PCI host bridge to bus 0000:00
[ 3.582303] pci_bus 0000:00: root bus resource [bus 00-1f]
[ 3.582316] pci_bus 0000:00: root bus resource [mem 0xfa000000-0xfbdfffff]
[ 3.582330] pci_bus 0000:00: root bus resource [io 0x0000-0xfffff] (bus address [0xfbe00000-0xfbefffff])
[ 3.582387] pci 0000:00:00.0: [1d87:0100] type 01 class 0x060400
[ 3.582547] pci 0000:00:00.0: supports D1
[ 3.582557] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
[ 3.588072] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 3.588301] pci 0000:01:00.0: [ad00:001e] type 00 class 0x000000
[ 3.588382] pci 0000:01:00.0: reg 0x10: [mem 0xfffffe00-0xffffffff]
[ 3.588455] pci 0000:01:00.0: reg 0x18: [mem 0xffe00000-0xffffffff]
[ 3.588606] pci 0000:01:00.0: Upstream bridge's Max Payload Size set to 128 (was 256, max 256)
[ 3.588632] pci 0000:01:00.0: Max Payload Size set to 128 (was 128, max 128)
[ 3.589238] pci_bus 0000:01: busn_res: [bus 01-1f] end is updated to 01
[ 3.589272] pci 0000:00:00.0: BAR 14: assigned [mem 0xfa000000-0xfa2fffff]
[ 3.589287] pci 0000:00:00.0: PCI bridge to [bus 01]
[ 3.589302] pci 0000:00:00.0: bridge window [mem 0xfa000000-0xfa2fffff]
[ 3.589497] pcieport 0000:00:00.0: enabling device (0000 -> 0002)
[ 3.589853] pcieport 0000:00:00.0: PME: Signaling with IRQ 37
[ 3.590302] pcieport 0000:00:00.0: AER: enabled with IRQ 37

lspci -v:
00:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3399 PCI Express Root Port (prog-if 00 [Normal decode])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0
Interrupt: pin A routed to IRQ 37
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: fa000000-fa2fffff [size=3M] [32-bit]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities:
Kernel driver in use: pcieport

01:00.0 Non-VGA unclassified device: Alta Data Technologies LLC Device 001e
Subsystem: Alta Data Technologies LLC Device 001e
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Interrupt: pin A routed to IRQ 0
Region 0: Memory at fffffe00 (32-bit, non-prefetchable) [disabled] [size=512]
Region 2: Memory at ffe00000 (32-bit, non-prefetchable) [disabled] [size=2M]
Capabilities:

irradium (based on crux linux) RockPro64 riscv64, aarch64

Tue, 05 Dec 2023 12:35:24 +0000

irradium - source based Linux distribution CRUX adhering to ideology keep it simple, has its own package system, also supports the port system.

irradium development

packages aarch64
packages riscv64

installation README.TXT

irradium-3.7-aarch64-core-rockpro64-6.6.4-build-20231205.img.zst
irradium-3.7-aarch64-core-rockpro64-6.6.4-build-20231205.img.zst.sha256
irradium-3.7-aarch64-xfce-rockpro64-6.6.4-build-20231205.img.zst
irradium-3.7-aarch64-xfce-rockpro64-6.6.4-build-20231205.img.zst.sha256

Ethernet regression on Linux Kernel 6.5.4?

Thu, 21 Sep 2023 12:03:33 +0000

Today I tried upgrading my board to the 6.5 series kernel and it seems eth0 no longer shows up.

the typical "rk_gmac-dwmac" dmesg entries don't show up at all.

Anyone else facing this issue? This is a headless system and debugging via UART isn't much fun, so I've booted back into the working 6.4 kernel.

Installing CH431SER on Ayufan 0.9.14: gitlab-ci-linux-build-159

Tue, 11 Jul 2023 07:12:37 +0000

Hello

when I try to install the Driver CH341SER from CH341SER_LINUX.ZIP - 南京沁恒微电子股份有限公司 (wch.cn) for the Ayufan linux build. I get this error Message during the compilation:

Code:
rock64@rockpro64:~/CH341SER_LINUX/driver$ make

make -C /lib/modules/4.4.190-1233-rockchip-ayufan-gd3f1be0ed310/build  M=/home/rock64/CH341SER_LINUX/driver  

make[1]: Entering directory '/usr/src/linux-headers-4.4.190-1233-rockchip-ayufan-gd3f1be0ed310'

  CC [M]  /home/rock64/CH341SER_LINUX/driver/ch341.o

gcc: error: unrecognized command line option '-mgeneral-regs-only'

gcc: error: unrecognized command line option '-mcmodel=large'

scripts/Makefile.build:283: recipe for target '/home/rock64/CH341SER_LINUX/driver/ch341.o' failed

make[2]: *** [/home/rock64/CH341SER_LINUX/driver/ch341.o] Error 1

Makefile:1479: recipe for target '_module_/home/rock64/CH341SER_LINUX/driver' failed

make[1]: *** [_module_/home/rock64/CH341SER_LINUX/driver] Error 2

make[1]: Leaving directory '/usr/src/linux-headers-4.4.190-1233-rockchip-ayufan-gd3f1be0ed310'

Makefile:5: recipe for target 'default' failed

make: *** [default] Error 2

I want to use the PineDisplay as Display on Linux and since Ayufan has a Documentation how to use it on his Linux Build, i use it.
But i need to install the Driver to use a CH340c RS485 to USB converter.

Any help is greatly appreciated.

How do I compile an arbitrary kernel for U-Boot?

Tue, 30 May 2023 03:39:44 +0000

I have been trying to get a DVD drive to work with the RockPRO64, but for some reason the kernel is not properly operating the drive and the open/close button does not work.
I researched the problem, and it seems like this is a general problem with the Linux kernel or its modules on multiple architectures — some versions of the "linux" package in Manjaro/Arch properly provided CD drive support and some did not. So, now I simply have to compile kernels from source until I get the right one. [2]

The only problem is, after a week or so of trying to compile kernels and comb through source code for rockpro U-Boot packages I still have no idea how to compile a kernel for U-Boot that actually boots. I have tried "mkimage" and putting a regular compiled kernel stripped of debug information into mkimage, but the kernel always fails to boot and restarts the CPU. I read and re-read the documentation for the U-Boot packages and saw that I'm apparently supposed to have a kernel tree with "make uImage" or "make pImage", but none of the kernel.org trees had this so I'm not sure where to get this source tree. [1]
I am also confused where the blobless package "uboot-rockpro64-foss" finds the kernel if it does not install one to /boot, or in any case where my kernel is on disk after I boot into a Manjaro partition.

How do I compile a kernel from source into an "Image" file loaded by extlinux.conf?
Is that even the same kernel that loads when I boot my eMMC and run "uname -a" to describe the kernel? How do I compile and use a new one?

[1] edit 6/07: so, apparently new kernel trees have "make Image". I tried this with kernel version 6.4.0-rc4 and it did not boot past what seems to be the Secondary Program Loader (SPL).

[2] edit 6/17: well now I feel really stupid. The problem with the DVD drive was that I kept trying to plug it into a USB 2.0 port and it really needed a USB 3.0 port. I just never figured this out because I always had something else in the single one the ROCKPro has.
That said, it would still probably be helpful to people to know how to compile a kernel, so I will still test it if anybody figures out how. I have already been messing with creating distro images for a while now.

How to enable CoreSight ETM trace on RockPro64

Mon, 22 May 2023 05:34:10 +0000

Hi,

I am trying to reproduce coresight-trace, a CoreSight ETMv4 trace decoder utility, on RockPro64 running vanilla 6.3.1 Linux kernel and dtbs (https://github.com/RICSecLab/coresight-trace).

The utility depends on a library called CSAL (upstream: https://github.com/arm-software/CSAL, fork: https://github.com/RICSecLab/CSAL/tree/f...dd5e7a744e) which is used to configure CoreSight registers.

I found that the helper script, csscan.py (https://github.com/ARM-software/CSAL/blo.../csscan.py), is supposed to print the topology of CoreSignt components given the address of the ROM table, but it ends up halting the whole machine when trying to access CoreSight components within Big core cluster. Here are the failing output:

Code:
sudo python3 coresight-tools/csscan.py --topology 0xfe400000 

@0xfe400000    0x000 0x000 r0.0                        ROM table

@0xfe401000    0x23b 0x908 r2.0  CS Funnel             funnel                 in-ports:6

@0xfe403000    0x23b 0x906 r4.0  CS CTI                CTI                    channels:4 triggers:8

@0xfe404000    0x23b 0x101 r1.0  TM101 Timestamp       CoreSight timestamp generator

@0xfe405000    0x23b 0x912 r4.0  CS TPIU               port                   TPIU

@0xfe420000    0x23b 0x4a3 r4.0                        ROM table

@0xfe430000 - device excluded from scan

@0xfe431000    0x23b 0x9d3 r4.0  Cortex-A53 PMU        PMU (core)     Arm PMUv3 rev0   aff=0x80000000 not acessing

@0xfe432000 - device excluded from scan

@0xfe433000    0x23b 0x9d3 r4.0  Cortex-A53 PMU        PMU (core)     Arm PMUv3 rev0   aff=0x80000001 not acessing

@0xfe434000 - device excluded from scan

@0xfe435000    0x23b 0x9d3 r4.0  Cortex-A53 PMU        PMU (core)     Arm PMUv3 rev0   aff=0x80000002 not acessing

@0xfe436000 - device excluded from scan

@0xfe437000    0x23b 0x9d3 r4.0  Cortex-A53 PMU        PMU (core)     Arm PMUv3 rev0   aff=0x80000003 not acessing

@0xfe438000    0x23b 0x9a8 r4.0  Cortex-A53 CTI        CTI            Arm CTI rev0     aff=0x80000000 channels:4 triggers:8 gate

@0xfe439000    0x23b 0x9a8 r4.0  Cortex-A53 CTI        CTI            Arm CTI rev0     aff=0x80000001 channels:4 triggers:8 gate

@0xfe43a000    0x23b 0x9a8 r4.0  Cortex-A53 CTI        CTI            Arm CTI rev0     aff=0x80000002 channels:4 triggers:8 gate

@0xfe43b000    0x23b 0x9a8 r4.0  Cortex-A53 CTI        CTI            Arm CTI rev0     aff=0x80000003 channels:4 triggers:8 gate

@0xfe43c000    0x23b 0x95d r4.0  Cortex-A53 ETM        ETM            Arm ETMv4 rev0   aff=0x80000000 pdsr=0x00000023 ETMv4.0 ts:64 bb cc min-ccit:4 retstack stall events:4 resources:16 addrcomp:4 ssc:1 pecomp:0 counters:2 seqstates:4 extin:30 extinsel:4

@0xfe43d000    0x23b 0x95d r4.0  Cortex-A53 ETM        ETM            Arm ETMv4 rev0   aff=0x80000001 pdsr=0x00000023 ETMv4.0 ts:64 bb cc min-ccit:4 retstack stall events:4 resources:16 addrcomp:4 ssc:1 pecomp:0 counters:2 seqstates:4 extin:30 extinsel:4

@0xfe43e000    0x23b 0x95d r4.0  Cortex-A53 ETM        ETM            Arm ETMv4 rev0   aff=0x80000002 pdsr=0x00000023 ETMv4.0 ts:64 bb cc min-ccit:4 retstack stall events:4 resources:16 addrcomp:4 ssc:1 pecomp:0 counters:2 seqstates:4 extin:30 extinsel:4

@0xfe43f000    0x23b 0x95d r4.0  Cortex-A53 ETM        ETM            Arm ETMv4 rev0   aff=0x80000003 pdsr=0x00000023 ETMv4.0 ts:64 bb cc min-ccit:4 retstack stall events:4 resources:16 addrcomp:4 ssc:1 pecomp:0 counters:2 seqstates:4 extin:30 extinsel:4

@0xfe600000    0x23b 0x4a4 r0.0                        ROM table

@0xfe610000 - device excluded from scan

@0xfe620000    0x23b 0x906 r4.0  CS CTI                CTI                    channels:4 triggers:8

(halt)

Based on the TRM, the address it starts to fail seems to be around the CLUSTERB_CTI0 or CLUSTERB_PMU0, implying that there are some issues with accessing CoreSight components on the Big core cluster.

I'd like to ask if you have any recommendations on what should I do to resolve this issue.

Any information would be deeply appreciated.

Best Regards,
Seonghyun

USB3 xhci-hcd in SuperSpeed mode

Thu, 11 May 2023 11:35:10 +0000

Hello everybody!

I try to use USB3 and USB3 port C in Super Speed mode, but all gadgets speed is downgrade to High Speed (USB2.0).

Tested on OpenWRT / Armbian_23.02.1_Rockpro64_bullseye_current_5.15.96_minimal

There is kernel log for USB3 flash stick on my PC:

Code:
[82897.181855] usb 4-4: new SuperSpeed USB device number 3 using xhci_hcd

[82897.202426] usb 4-4: New USB device found, idVendor=125f, idProduct=105b

[82897.202429] usb 4-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[82897.202431] usb 4-4: Product: ADATA USB Flash Drive

[82897.202432] usb 4-4: Manufacturer: ADATA

[82897.202434] usb 4-4: SerialNumber: 2180800000000263

Same USB3 flash stick on rockpro64-v2.1 (armbian):

Code:
[  239.045083] usb 3-1: new high-speed USB device number 2 using xhci-hcd

[  239.194061] usb 3-1: New USB device found, idVendor=125f, idProduct=105b, bcdDevice= a.00

[  239.194098] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[  239.194121] usb 3-1: Product: ADATA USB Flash Drive

[  239.194140] usb 3-1: Manufacturer: ADATA

[  239.194157] usb 3-1: SerialNumber: 2180800000000263

root@rockpro64:~# lsusb -tv

/:  Bus 08.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M

    ID 1d6b:0001 Linux Foundation 1.1 root hub

/:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M

    ID 1d6b:0001 Linux Foundation 1.1 root hub

/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M

    ID 1d6b:0002 Linux Foundation 2.0 root hub

/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M

    ID 1d6b:0002 Linux Foundation 2.0 root hub

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M

    ID 1d6b:0003 Linux Foundation 3.0 root hub

/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M

    ID 1d6b:0002 Linux Foundation 2.0 root hub

    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M

        ID 125f:105b A-DATA Technology Co., Ltd. 

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M

    ID 1d6b:0003 Linux Foundation 3.0 root hub

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M

    ID 1d6b:0002 Linux Foundation 2.0 root hub

Do rockpro64-v2.1 support Super Speed at all?

Thanks

rk3399 and Visual Output Processor 2 (VOP2)

Mon, 24 Apr 2023 08:33:44 +0000

Hello everyone!

That is VOP2 and why it is better than VOP?

I find some information about VOP v1
Can anyone show info about VOP2?

----

According this news VOP2 is used by Rockchip SoCs starting with the RK3566 / RK3568 SoCs.
Do the rk3399 is supported it?

Thanks

How do I enable Pine touchdisplay as display on Debian?

Mon, 24 Apr 2023 05:02:56 +0000

Hello
Does someone know, how to use the Pinedisplay on Debian 12?

GPIO on Ayufan 0.9.14 Build

Sat, 22 Apr 2023 17:16:20 +0000

Hello

I'm trying to use the GPIOs on the Ayufan Ubuntu Build (bionic-mate-rockpro64-0.9.14-1159-armhf), but can't seem to get it working.
Apperently the libgpiod uses /dev/Gpiochip0, which is not on this version.

Problem is, that i have to use a Desktop Image, which supports the Pine Touchdisplay, for the Rest of the Program, and i can't seem to get the other Versions (like focal-mate-rockpro64-0.10.12-1184-armhf) running.

So is there a way to use the GPIO pins on the 0.9.14 Version?

yocto for RockPro64

Thu, 20 Apr 2023 12:16:19 +0000

Hello,

I just ordered my RockPro64 board today and want to create a poky reference image for it.

But I wonder whether meta-rockchip metalayer here supports it?

I saw couple of similar questions in the forum but they are very old.
Nowadays we use yocto-dunfell or kirkstone and wonder RockPro64 is directly supported by them.

Thank you.

Accidentally updated Ubuntu/ Revert possible?

Wed, 19 Apr 2023 06:03:27 +0000

Hello,

I'am using the Ayufan Ubuntu Mate desktop package, and (because I'm new to this and didn't know what I was doing) I accidentally updated Ubuntu to from 18.04 to 20.04 and now everything looks wrong. Is there any way to revert the changes without reinstalling everything?