Jump to content

Rock 4 SE unable to run armbian on emmc or nvme

kse

By kse
in Rockchip

 Share

Recommended Posts

kse

kse

Posted
Posted

Hi,

i just received my Rock 4 Se and a 32GB eMMC module today, and i'm currently not sure if the Image is incompatible, or if my storage modules are broken.

I tried emmc standalone and SD for boot with nvme (from an dell notebook) for rootfs

 

When i use the emmc, the filesystem goes into read only as soon as i do some apt upgrade.

On reboot i often end up in initramfs nd have to fsck.

I could gether some dmesg output:

 

  Zitat

[  161.444536] ------------[ cut here ]------------
[  161.444544] mmc1: cqhci: spurious TCN for tag 14
[  161.444629] WARNING: CPU: 0 PID: 494 at drivers/mmc/host/cqhci-core.c:787 cqhci_irq+0x4b4/0x640
[  161.444658] Modules linked in: lz4hc snd_soc_es8316 snd_soc_simple_card snd_soc_audio_graph_card btsdio snd_soc_rockchip_i2s snd_soc_simple_card_utils joydev snd_soc_hdmi_codec lz4 snd_soc_rockchip_pcm hci_uart snd_soc_core hantro_vpu(C) btqca btrtl rockchip_vdec(C) btbcm rockchip_iep btintel rockchip_rga v4l2_h264 videobuf2_dma_contig bluetooth videobuf2_dma_sg v4l2_mem2mem videobuf2_vmalloc snd_pcm_dmaengine snd_pcm snd_timer brcmfmac videobuf2_memops videobuf2_v4l2 videobuf2_common brcmutil cfg80211 videodev mc snd soundcore rfkill cpufreq_dt zram ip_tables x_tables autofs4 realtek panfrost gpu_sched dw_hdmi_cec dw_hdmi_i2s_audio dwmac_rk stmmac_platform stmmac pcs_xpcs
[  161.444931] CPU: 0 PID: 494 Comm: kworker/0:2H Tainted: G         C        5.15.80-rockchip64 #22.11.1
[  161.444944] Hardware name: Radxa ROCK Pi 4B (DT)
[  161.444952] Workqueue: kblockd blk_mq_run_work_fn
[  161.444972] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  161.444985] pc : cqhci_irq+0x4b4/0x640
[  161.444997] lr : cqhci_irq+0x4b4/0x640
[  161.445008] sp : ffff800008003d10
[  161.445014] x29: ffff800008003d10 x28: ffff00000626ac40 x27: ffff000005348580
[  161.445036] x26: ffff00000530a298 x25: ffff800009529d90 x24: ffff800009d06d88
[  161.445056] x23: ffff80000954e228 x22: 0000000000000002 x21: ffff000005348000
[  161.445076] x20: 000000000000000e x19: ffff00000530a280 x18: 0000000000000001
[  161.445096] x17: ffff8000edfe6000 x16: ffff800008004000 x15: 00000000000002aa
[  161.445116] x14: ffff800008003a20 x13: 00000000ffffffea x12: ffff800009b2fd10
[  161.445136] x11: 0000000000000003 x10: ffff800009b17cd0 x9 : ffff800009b17d28
[  161.445157] x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001
[  161.445176] x5 : ffff8000edfe6000 x4 : 0000000000000000 x3 : 0000000000010004
[  161.445196] x2 : 0000000000010003 x1 : 806d525e9addfc00 x0 : 0000000000000000
[  161.445215] Call trace:
[  161.445222]  cqhci_irq+0x4b4/0x640
[  161.445234]  sdhci_arasan_cqhci_irq+0x5c/0x88
[  161.445246]  sdhci_irq+0xcc/0x10c0
[  161.445261]  __handle_irq_event_percpu+0x60/0x248
[  161.445277]  handle_irq_event_percpu+0x38/0x88
[  161.445289]  handle_irq_event+0x48/0xe8
[  161.445301]  handle_fasteoi_irq+0xb8/0x148
[  161.445313]  handle_domain_irq+0x90/0xd8
[  161.445325]  gic_handle_irq+0xb8/0x134
[  161.445338]  call_on_irq_stack+0x28/0x54
[  161.445350]  do_interrupt_handler+0x58/0x68
[  161.445362]  el1_interrupt+0x30/0x78
[  161.445374]  el1h_64_irq_handler+0x18/0x28
[  161.445384]  el1h_64_irq+0x74/0x78
[  161.445394]  preempt_count_sub+0x20/0xc0
[  161.445407]  _raw_spin_unlock_irqrestore+0x20/0x40
[  161.445424]  sdhci_cqe_enable+0x130/0x228
[  161.445437]  sdhci_arasan_cqe_enable+0x94/0xb8
[  161.445449]  cqhci_request+0xd0/0x650
[  161.445460]  mmc_cqe_start_req+0xb4/0x198
[  161.445474]  mmc_blk_mq_issue_rq+0x49c/0x9b0
[  161.445486]  mmc_mq_queue_rq+0x114/0x2b0
[  161.445497]  blk_mq_dispatch_rq_list+0x124/0x838
[  161.445512]  __blk_mq_sched_dispatch_requests+0xc4/0x1c8
[  161.445523]  blk_mq_sched_dispatch_requests+0x3c/0x78
[  161.445533]  __blk_mq_run_hw_queue+0x64/0xa0
[  161.445545]  blk_mq_run_work_fn+0x20/0x30
[  161.445557]  process_one_work+0x20c/0x4c8
[  161.445571]  worker_thread+0x48/0x478
[  161.445582]  kthread+0x138/0x150
[  161.445593]  ret_from_fork+0x10/0x20
[  161.445605] ---[ end trace 5f45817fb9424389 ]---
[  196.340714] mmc1: running CQE recovery
[  196.373413] mmc1: running CQE recovery
[  299.787333] mmc1: running CQE recovery

Expand  

 

After this trace i get a lot of I/O Errors:

 

  Zitat

[  385.832307] blk_update_request: I/O error, dev mmcblk1, sector 2653184 op 0x1:(WRITE) flags 0x0 phys_seg 8 prio class 0
[  385.832338] EXT4-fs warning (device mmcblk1p1): ext4_end_bio:348: I/O error 10 writing to inode 2500 starting block 331776)
[  385.832482] Buffer I/O error on device mmcblk1p1, logical block 325632
[  385.832519] Buffer I/O error on device mmcblk1p1, logical block 325633
[  385.832539] Buffer I/O error on device mmcblk1p1, logical block 325634
[  385.832557] Buffer I/O error on device mmcblk1p1, logical block 325635
[  385.832575] Buffer I/O error on device mmcblk1p1, logical block 325636
[  385.832593] Buffer I/O error on device mmcblk1p1, logical block 325637
[  385.832611] Buffer I/O error on device mmcblk1p1, logical block 325638
[  385.832628] Buffer I/O error on device mmcblk1p1, logical block 325639
[  385.832645] Buffer I/O error on device mmcblk1p1, logical block 325640
[  385.832663] Buffer I/O error on device mmcblk1p1, logical block 325641

Expand  

 

 

Im not sure if this is an os or an emmc module issue. Any guess whats going wrong here?

 

after that i coppied the current image ( Armbian_22.11.1_Rockpi-4b_bullseye_current_5.15.80.img.xz) onto a micro SD card, addedthe nvme drive, bootet that and made an armbian-install to migrate the rootfs to the nvme. After a reboot, i could actually start to instlall software. But after a while i still had some freeze of the whole system, so i had to power the board off and turn it on again.

Sadly i do not have any more output from this situation.

 

i'm also going to try a version with older kernel, will reportlater if that worked

0
Damo

Damo

Posted
Posted

Hi,

 

I'm having the same problem with two 4SE boards with 32gb emmcs installed with Armbian 23.02.2  Bullseye with Linux 5.15.93-rockchip64.

 

Seems to be some sort of driver issue that appear on heavy write activity to the emmc (apt upgrade or when using dd write test ) . Image was installed onto emmcs using armbian-install. Have also tried directly imaging emmc using usb adapter with same result. 

 

Have been testing to try and work out cause (no result, I'm just a linux hack, by no means a expert) seems if I slow CPU down problem becomes less of an issue. 

 

kern.log dump:

  Reveal hidden contents

 

Eventually, with enough IO errors, system remounts into read only. 

 

Haven't extensively tested yet, but haven't seen same problem using Radxa images (have tried Debian 4.4 and 5.10).

0
hygy

hygy

Posted
Posted

I have exactly the same problem.  I tried it with armbian, ubuntu, debian images with cli.

 

When I want to install packages I got:  Buffer I/O errors... Then the filesystem is mounted as a readonly filesystem.

 

Is any solution?

0
erazer1

erazer1

Posted
Posted

Hi!

I can confirm that the problem exists on Rock4 SE using the latest Armbian.

Image boots correct from uSD, but does not boot from eMMC. Verified the eMMC using different methods on desktop computer, it is definately not faulty.

You can try images with kernel version 5.10 or lower, it may work for you, as it does for me.

I have tested several archived older images - most do not work until this kernel or lower. F.e you can try:

Armbian_21.08.1_Rockpi-4b_bullseye_current_5.10.60.img.xz, Armbian_21.05.1_Rockpi-4b_buster_current_5.10.35.img.xz, Armbian_21.02.1_Rockpi-4b_focal_current_5.10.12.img.xz

which are working for me.

 

The problem was already analyzed by PPl on the forum, see


however, it seems the fix was not applied to the later kernels device tree overlays yet.

I managed to apply the mentioned fix for booting the emmc and recompile the device tree overlay. After applying the compiled file to the image it was able to boot.

However, i got filesystem errors later. Possibly the timeout mentioned in the solution was not high enough?

 

Using the archived images above, the file system corruption does not occur.

If anyone is willing to fix this I could help with testing/compiling etc.

 

Regards, erazer

 

0
Igor

Igor

Posted
Posted
  On 3/24/2023 at 7:41 AM, erazer1 said:

If anyone is willing to fix this I could help with testing/compiling etc.

Expand  

 

Look at forums. Its mainly developers, mainly hard problems. Many topics remain unanswered as there are very little people that are able to understand and answer. I am happy you are offering your help, but estimated several weeks of developers time for few minutes of yours? Try to picture how this sounds from other party perspective. Try to find out how to provide help that would match this. I don't have few weeks, sadly not even a minutes to put into this exchange. Just a tip.

0
erazer1

erazer1

Posted
Posted

Hi Igor!

 

Thanks for your response! I wonder how you come to the conclusion that this problem takes several weeks to fix? I have already invested not only few minutes but at least two mandays into testing different images, comparing kernel commits, reading forum posts, compiling device tree and testing images.

Maybe another developer owning the board and interested in a solution can give hints so we can work out a fix together and integrate into the armbian code.

This could be useful for other owners not having to go through the same hassle of finding out the board does not work correctly using the image.

 

Regards, erazer1

0
Igor

Igor

Posted
Posted
  On 3/24/2023 at 9:50 AM, erazer1 said:

I wonder how you come to the conclusion that this problem takes several weeks to fix?

Expand  

 

That would be my guess based on experiences. The more people are inexperienced, the more this assesment is underestimated. End users perception on this is bizarre on the other end. They report a problem and come looking for a solution right next day, the day after, ... then they write an email and complain about. This is not personal or directed to you - I don't know you. Its more like a general observation.

 

Bugs are hard to estimate right. Sometimes you find a problem in no time, sometimes you drag it for months sometimes you tune out, forgot about ...

 

You were doing something, other people were doing something ... problem is still here. I am more afraid this was estimated too low as this common research goes on the bill too.

0
danilovitch

danilovitch

Posted
Posted

Hello, I also had problems to boot RockPi 4 SE and transfer it to a NVME card. However my misstake was to update the initial install of the SD card. 

It was true that the Armbian 5.10 could be updated first and then transferred to a NVME card and it worked good. Thank you erazer1.

The way to install Armbian_22.11.0-trunk_Rockpi-4b_bullseye_current_5.15.76_minimal was just to boot it up make your user account. Then, 1. sudo apt update 2. sudo apt install armbian-config 3. run armbian-config and follow step 1 there. Both install to USB and NVME worked for me. I also made the firmware update from armbian-config.

After reboot I made all the upgrades and so on, install Openmediavault and PLEX. Quite nice!

 

I got this RockPi 4 SE just three days ago as an upgrade for my Raspberry which is now retired. I was quite disappointed that this  Rock had problems but luckily I found this tread.

 

Never give up!

1

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept