Jump to content

Armbian Buster current (with Linux 5.4.y) on the Rock Pi 4


diginet

Recommended Posts

Started to test Armbian_19.11.5_Rockpi-4b_buster_current_5.4.6.img and I could not boot off of the eMMC.  So I put Armbian_19.11.5_Rockpi-4b_buster_current_5.4.6.img on an SD card and formatted my eMMC.  I was then able to get the Rock Pi 4 to boot successfully.  It looks like the kernel can not initialize the eMMC.  Here are some messages from dmesg on boot:
 

[   53.338988] dwmmc_rockchip fe310000.dwmmc: IDMAC supports 32-bit address mode.
[   53.339028] dwmmc_rockchip fe310000.dwmmc: Using internal DMA controller.
[   53.339048] dwmmc_rockchip fe310000.dwmmc: Version ID is 270a
[   53.339126] dwmmc_rockchip fe310000.dwmmc: DW MMC controller at irq 28,32 bit host data width,256 deep fifo
[   53.339411] dwmmc_rockchip fe310000.dwmmc: allocated mmc-pwrseq
[   53.339426] mmc_host mmc0: card is non-removable.
[   53.351589] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[   53.364798] dwmmc_rockchip fe320000.dwmmc: IDMAC supports 32-bit address mode.
[   53.364825] dwmmc_rockchip fe320000.dwmmc: Using internal DMA controller.
[   53.364840] dwmmc_rockchip fe320000.dwmmc: Version ID is 270a
[   53.364898] dwmmc_rockchip fe320000.dwmmc: DW MMC controller at irq 29,32 bit host data width,256 deep fifo
[   53.365040] dwmmc_rockchip fe320000.dwmmc: Got CD GPIO
[   53.377851] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[   53.393119] mmc2: CQHCI version 5.10
[   53.399037] mmc0: queuing unknown CIS tuple 0x80 (2 bytes)
[   53.400631] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
[   53.402215] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
[   53.405068] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[   53.408569] mmc0: queuing unknown CIS tuple 0x81 (9 bytes)
[   53.417703] mmc2: SDHCI controller on fe330000.sdhci [fe330000.sdhci] using ADMA
[   53.427277] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[   53.427416] mmc1: new high speed SDHC card at address 0001
[   53.432073] mmcblk1: mmc1:0001 00000 7.41 GiB 
[   53.434118]  mmcblk1: p1
[   53.463648] mmc_host mmc0: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
[   53.515437] mmc2: mmc_select_hs400es failed, error -84
[   53.515446] mmc2: error -84 whilst initialising MMC card
[   53.599556] dwmmc_rockchip fe310000.dwmmc: Successfully tuned phase to 224
[   53.601739] mmc0: new ultra high speed SDR104 SDIO card at address 0001
[   53.637621] mmc2: mmc_select_hs400es failed, error -84
[   53.637632] mmc2: error -84 whilst initialising MMC card
[   53.777039] mmc2: mmc_select_hs400es failed, error -110
[   53.777059] mmc2: error -110 whilst initialising MMC card
[   53.968760] mmc2: mmc_select_hs400es failed, error -110
[   53.968777] mmc2: error -110 whilst initialising MMC card

 I brought this up in the Raxda forum: https://forum.radxa.com/t/armbian-buster-5-4-6-emmc-slot-not-being-detected/2422/2 and it was suggested to switch to hs200.  I made the following modifications to the dtb like below on a freshly imaged eMMC:
 

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts
index 1ae1ebd4efdd..5ea6286e5faa 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts
@@ -592,8 +592,7 @@
 
 &sdhci {
        bus-width = <8>;
-       mmc-hs400-1_8v;
-       mmc-hs400-enhanced-strobe;
+       mmc-hs200-1_8v;
        non-removable;
        status = "okay";
 };

This works, though hs400 seemed to be working on the Kernel 4.4 and I also see posts in this forum that suggests it was possibly working on 5.3.y?  I reviewed the kernel docs for ../5.4.y/Documentation/devicetree/bindings/mmc/mmc-controller.yaml, though to be honest I'm a little out of my depth on proper configuration and if there are currently config issues preventing the eMMC from being initialized properly.  My next step are to try and setup the build environment and figure out how to build 5.3.y branch to see if eMMC was working off of that branch?  If anyone could confirm booting off of eMMC on 5.3.y that would be helpful, as then I could start a git bisect in the kernel source to try and figure out what commit broke support.  Any further advice for someone more experienced with these SoC boards would be appreciated.

Link to comment
Share on other sites

16 hours ago, diginet said:

If anyone could confirm booting off of eMMC on 5.3.y that would be helpful

My Rock Pi 4B boots fine from eMMC in hs400es mode with 5.4.x but... I remember having similar issues to yours on one of Rock Pi 4A I had.

I found the difference between 5.x and 4.4 in regards to hs400es initialisation that made it work but finally returned the unit and did not pursue it any further.

 

Can you try building yourself an image with below patch applied or use the precompiled image I shared and see if it boots fine using eMMC?

fix-hs400es-init-on-some-boards.patch

Link to comment
Share on other sites

Sorry for the late reply but have been tied up.  I've tried your compiled image which leads to good and bad news...   The card booted and is using hs400es mode though the image is unstable.   Networking seems to be broken and when I run any type of commands geared towards networking to troubleshoot, the whole board freezes.  After booting in again I see the below from dmesg.  I noticed the image is at 5.4.7 where I was testing 5.4.6.  So unsure if something released in 5.4.7 caused this issue or if your changes are causing the null pointer.  :shrug:
 

[   56.465005] Unable to handle kernel NULL pointer dereference at virtual addre
ss 0000000000000378
[   56.465802] Mem abort info:
[   56.466056]   ESR = 0x96000004
[   56.466331]   EC = 0x25: DABT (current EL), IL = 32 bits
[   56.466803]   SET = 0, FnV = 0
[   56.467079]   EA = 0, S1PTW = 0
[   56.467360] Data abort info:
[   56.467621]   ISV = 0, ISS = 0x00000004
[   56.467964]   CM = 0, WnR = 0
[   56.468327] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000f063a000
[   56.468907] [0000000000000378] pgd=0000000000000000
[   56.469347] Internal error: Oops: 96000004 [#1] PREEMPT SMP
cie phy_rockchip_typec dwmac_rk stmmac_platform stmmac phylink
 #19.11.5
[   56.473501] Hardware name: Radxa ROCK Pi 4 (DT)
[   56.473905] pstate: 80000005 (Nzcv daif -PAN -UAO)
[   56.474340] pc : mdiobus_get_phy+0x4/0x20
[   56.474721] lr : stmmac_open+0x1c0/0xa38 [stmmac]
[   56.475139] sp : ffff800012e932d0
[   56.475434] x29: ffff800012e932d0 x28: 0000000000000000 
[   56.475906] x27: ffff0000eddf88c0 x26: ffff0000eff1ec10 
[   56.476376] x25: 0000000000000001 x24: 0000000000000000 
[   56.476847] x23: ffff0000eddf8000 x22: ffff80001134b000 
[   56.477317] x21: ffff800012e93ab0 x20: ffff0000edc26c80 
[   56.477787] x19: 00000000ffffffff x18: 0000000000000000 
[   56.478258] x17: 0000000000000000 x16: 0000000000000000 
[   56.478728] x15: 0000000000000000 x14: 0000000000000000 
[   56.479199] x13: 0000000000000000 x12: 0000000000000000 
[   56.479669] x11: 0000000000000003 x10: 0101010101010101 
[   56.480140] x9 : fffffffffffffffc x8 : 7f7f7f7f7f7f7f7f 
[   56.480610] x7 : fefefeff646c606d x6 : 1e091448e4e5f6e9 
[   56.481082] x5 : 697665644814091e x4 : 8080808000000000 
[   56.481553] x3 : 0000000000000001 x2 : e099978523b21300 
[   56.482027] x1 : 00000000ffffffff x0 : fffffffffffffff8 
[   56.482500] Call trace:
[   56.482734]  mdiobus_get_phy+0x4/0x20
[   56.483066]  __dev_open+0xe4/0x160
[   56.483375]  __dev_change_flags+0x164/0x1c8
[   56.483749]  dev_change_flags+0x20/0x60
[   56.484096]  do_setlink+0x2a4/0xc50
[   56.484410]  __rtnl_newlink+0x3dc/0x6e8
[   56.484755]  rtnl_newlink+0x48/0x70
[   56.485069]  rtnetlink_rcv_msg+0x120/0x368
[   56.485436]  netlink_rcv_skb+0x58/0x118
[   56.485778]  rtnetlink_rcv+0x14/0x20
[   56.486097]  netlink_unicast+0x180/0x1f8
[   56.486446]  netlink_sendmsg+0x17c/0x318
[   56.486796]  ____sys_sendmsg+0x248/0x290
[   56.487145]  ___sys_sendmsg+0x80/0xc0
[   56.487473]  __sys_sendmsg+0x68/0xb8
[   56.487792]  __arm64_sys_sendmsg+0x20/0x28
[   56.488161]  el0_svc_common.constprop.1+0x88/0x178
[   56.488588]  el0_svc_handler+0x20/0x80
[   56.488924]  el0_svc+0x8/0xc
[   56.489189] Code: a8c17bfd d65f03c0 00000000 8b21cc00 (f941c000) 
[   56.489730] ---[ end trace f74d1a4658838e92 ]---

 

Link to comment
Share on other sites

5 hours ago, diginet said:

The card booted and is using hs400es mode

So it seems to be the same issue I had.

I will add the patch to the build as it does not seem to harm the eMMC modules that boot also without it.

 

5 hours ago, diginet said:

After booting in again I see the below from dmesg.  I noticed the image is at 5.4.7 where I was testing 5.4.6.  So unsure if something released in 5.4.7 caused this issue or if your changes are causing the null pointer. 

The problem is definitely with 5.4.7+.

Others also started noticing and patching for it: https://gist.github.com/jakogut/bc21de0535b640f2374c1d07a710e8ab

I did not notice it as currently I am mostly spending time with NanoPi M4V2 which have mdio and phy nodes already setup in device tree.

Will dig a bit more into that issue.

Link to comment
Share on other sites

3 hours ago, diginet said:

it looks like you already made these changes to the Armbian project?


This should already be fixed, but perhaps we didn't update all images yet. Self build image must work.

Link to comment
Share on other sites

4 hours ago, diginet said:

Looking at more recent posts, it looks like you already made these changes to the Armbian project?

Network issues are solved upstream.

eMMC tweak for your board is not in the build system yet. I will prepare it soon and give you a shout.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines