Viper Posted March 6, 2022 Posted March 6, 2022 Armbianmonitor: http://ix.io/3Rw6 Hi, since latest upgrade to new kernel 22.02 stable the system becomes unstable. There are issues writing to mmc2 and "EXT4-fs (mmcblk2p1): Remounting filesystem read-only". This does not allow most of the apps to work properly (e.g. openmediavault stops working) I tried to switch back to previous kernel version through armbian-config but that does not work too Pls help. Thanks 0 Quote
haajee Posted March 9, 2022 Posted March 9, 2022 I got the problem with my orange pi4 that even the network doesn't work and got a lot of errors in the display. network connection stops working also! 0 Quote
fraz0815 Posted March 14, 2022 Posted March 14, 2022 HS400 for onboard emmc broke somewhere between 5.10 and 5.15 on nanopct4 (and a few others afaik). If you boot from SD card, at first everything looks great, because CD GPIO is set: dmesg | grep mmc [ 0.104269] platform ff770000.syscon:phy@f780: Fixing up cyclic dependency with fe330000.mmc [ 1.647160] dwmmc_rockchip fe310000.mmc: IDMAC supports 32-bit address mode. [ 1.647892] dwmmc_rockchip fe310000.mmc: Using internal DMA controller. [ 1.648508] dwmmc_rockchip fe310000.mmc: Version ID is 270a [ 1.649120] dwmmc_rockchip fe310000.mmc: DW MMC controller at irq 32,32 bit host data width,256 deep fifo [ 1.649759] mmc2: CQHCI version 5.10 [ 1.676546] mmc2: SDHCI controller on fe330000.mmc [fe330000.mmc] using ADMA [ 1.750545] mmc2: Command Queue Engine enabled [ 1.750984] mmc2: new HS400 MMC card at address 0001 [ 1.752515] mmcblk2: mmc2:0001 AJTD4R 14.6 GiB [ 1.755656] mmcblk2: p1 [ 1.756614] mmcblk2boot0: mmc2:0001 AJTD4R 4.00 MiB [ 1.759327] mmcblk2boot1: mmc2:0001 AJTD4R 4.00 MiB [ 1.761918] mmcblk2rpmb: mmc2:0001 AJTD4R 4.00 MiB, chardev (241:0) [ 2.956947] dwmmc_rockchip fe320000.mmc: IDMAC supports 32-bit address mode. [ 2.957632] dwmmc_rockchip fe320000.mmc: Using internal DMA controller. [ 2.957769] dwmmc_rockchip fe310000.mmc: IDMAC supports 32-bit address mode. [ 2.958230] dwmmc_rockchip fe320000.mmc: Version ID is 270a [ 2.958902] dwmmc_rockchip fe310000.mmc: Using internal DMA controller. [ 2.959430] dwmmc_rockchip fe320000.mmc: DW MMC controller at irq 33,32 bit host data width,256 deep fifo [ 2.960026] dwmmc_rockchip fe310000.mmc: Version ID is 270a [ 2.961467] dwmmc_rockchip fe320000.mmc: Got CD GPIO [ 2.962269] dwmmc_rockchip fe310000.mmc: DW MMC controller at irq 32,32 bit host data width,256 deep fifo [ 2.965754] dwmmc_rockchip fe310000.mmc: allocated mmc-pwrseq [ 2.966290] mmc_host mmc0: card is non-removable. [ 2.976026] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) [ 2.979901] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) [ 3.071609] mmc_host mmc1: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0) [ 3.092749] mmc_host mmc0: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0) [ 3.250481] dwmmc_rockchip fe320000.mmc: Successfully tuned phase to 218 [ 3.251121] mmc1: new ultra high speed SDR104 SDHC card at address aaaa [ 3.253087] mmcblk1: mmc1:aaaa SC32G 29.7 GiB [ 3.258541] mmcblk1: p1 [ 3.360734] dwmmc_rockchip fe310000.mmc: Successfully tuned phase to 211 [ 3.367492] mmc0: new ultra high speed SDR104 SDIO card at address 0001 [ 6.616181] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac4356-sdio.friendlyarm,nanopc-t4.bin failed with error -2 [ 6.620630] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac4356-sdio.friendlyarm,nanopc-t4.txt failed with error -2 [ 6.691061] systemd[1]: Mounting /media/mmcboot... [ 6.708099] EXT4-fs (mmcblk1p1): mounted filesystem with writeback data mode. Opts: commit=600,errors=remount-ro. Quota mode: none. [ 6.729629] systemd[1]: Mounted /media/mmcboot. But simple tasks like formatting, keep crashing: sudo mkfs.ext4 /dev/mmcblk2p1 mke2fs 1.46.5 (30-Dec-2021) /dev/mmcblk2p1 contains a ext4 file system last mounted on /home/nano/emmc on Fri Mar 11 04:31:46 2022 Proceed anyway? (y,N) y Discarding device blocks: done Creating filesystem with 3812864 4k blocks and 954720 inodes Filesystem UUID: 38f1e32f-13ca-4e77-b8ec-2691d7065062 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208 Allocating group tables: done Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: mkfs.ext4: Input/output error while writing out and closing file system dmesg [ 201.765056] mmc2: running CQE recovery [ 370.548084] mmc2: running CQE recovery [ 370.615609] mmc2: running CQE recovery [ 370.623274] mmc2: running CQE recovery [ 370.631096] mmc2: running CQE recovery [ 370.638104] mmc2: running CQE recovery [ 370.640653] I/O error, dev mmcblk2, sector 12890136 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 0 [ 370.646122] mmc2: running CQE recovery [ 370.653205] mmc2: running CQE recovery [ 370.660399] mmc2: running CQE recovery [ 370.662973] I/O error, dev mmcblk2, sector 12891160 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0 [ 370.668034] mmc2: running CQE recovery [ 370.675353] mmc2: running CQE recovery [ 370.677244] I/O error, dev mmcblk2, sector 12886040 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 0 [ 370.681954] mmc2: running CQE recovery [ 370.691242] mmc2: running CQE recovery [ 370.697018] mmc2: running CQE recovery [ 370.698975] I/O error, dev mmcblk2, sector 12887064 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0 [ 370.703727] mmc2: running CQE recovery .......... This can lead to unexpected behaviour, when using sata-nand-installer e.g., because partition can be mounted but doesn't work as expected. I suggest to disable hs400 for now, this will fallback to hs200. Cold boot prints no errors, while reboots have some lines mmc2: mmc_select_hs200 failed, error -110 mmc2: error -110 whilst initialising MMC card but gets the job done. board-nanopct4-disable-hs400.patch 0 Quote
balbes150 Posted March 15, 2022 Posted March 15, 2022 06.03.2022 в 20:38, Viper сказал: since latest upgrade to new kernel 22.02 stable the system becomes unstable. There are issues writing to mmc2 and "EXT4-fs (mmcblk2p1): Remounting filesystem read-only". This does not allow most of the apps to work properly (e.g. openmediavault stops working) I tried to switch back to previous kernel version through armbian-config but that does not work too Can you check the last one and show the result using the versions from here ? https://disk.yandex.ru/d/_CAf6mgtVDGS4A 0 Quote
fraz0815 Posted March 15, 2022 Posted March 15, 2022 I tested Armbian_22.02.0-trunk_Nanopct4_bullseye_edge_5.16.8.img, same errors on media kernel for me: http://ix.io/3SjQ [ 656.511836] ------------[ cut here ]------------ [ 656.511851] mmc2: cqhci: spurious TCN for tag 7 [ 656.511959] WARNING: CPU: 0 PID: 6 at drivers/mmc/host/cqhci-core.c:786 cqhci_irq+0x504/0x670 [ 656.511988] Modules linked in: crct10dif_ce snd_soc_spdif_tx gpio_ir_recv rc_core snd_soc_simple_card snd_soc_simple_card_utils panfrost pwm_fan hantro_vpu(C) gpu_sched hci_uart rockchip_vdec(C) rockchip_rga btqca rockchip_iep v4l2_h264 videobuf2_dma_sg videobuf2_vmalloc v4l2_mem2mem videobuf2_dma_contig snd_soc_rockchip_i2s btrtl videobuf2_memops btbcm btsdio btintel videobuf2_v4l2 bluetooth videobuf2_common fusb302 tcpm brcmfmac videodev typec snd_soc_rt5651 ecdh_generic brcmutil ecc cfg80211 rfkill mc zram sunrpc fuse adc_keys [ 656.512272] CPU: 0 PID: 6 Comm: kworker/0:0H Tainted: G C 5.16.8-media #trunk [ 656.512289] Hardware name: FriendlyElec NanoPC-T4 (DT) [ 656.512298] Workqueue: kblockd blk_mq_run_work_fn [ 656.512324] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 656.512340] pc : cqhci_irq+0x504/0x670 [ 656.512353] lr : cqhci_irq+0x504/0x670 [ 656.512365] sp : ffff800008003d90 [ 656.512373] x29: ffff800008003d90 x28: 0000000000004000 x27: ffff800009a91000 [ 656.512399] x26: ffff00000063c580 x25: ffff00000070fa98 x24: ffff800009846fb8 [ 656.512425] x23: ffff80000a14cf00 x22: 0000000000000002 x21: ffff00000063c000 [ 656.512451] x20: ffff00000070fa80 x19: 0000000000000007 x18: 0000000000000020 [ 656.512476] x17: ffff8000edc74000 x16: ffff800008004000 x15: ffffffffffffffff [ 656.512502] x14: 0000000000000000 x13: 0000000000000328 x12: ffff800008003aa0 [ 656.512527] x11: ffff800009f1f458 x10: 00000000ffffe000 x9 : ffff800009f1f458 [ 656.512553] x8 : ffff800009e6f458 x7 : ffff800009f1f458 x6 : 0000000000000000 [ 656.512578] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000027 [ 656.512602] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000000685a00 [ 656.512627] Call trace: [ 656.512636] cqhci_irq+0x504/0x670 [ 656.512649] sdhci_arasan_cqhci_irq+0x54/0x84 [ 656.512669] sdhci_irq+0xc4/0xf30 [ 656.512682] __handle_irq_event_percpu+0x60/0x250 [ 656.512704] handle_irq_event+0x64/0x150 [ 656.512722] handle_fasteoi_irq+0xc0/0x1bc [ 656.512738] generic_handle_domain_irq+0x3c/0x60 [ 656.512756] gic_handle_irq+0xd8/0x2c4 [ 656.512776] call_on_irq_stack+0x2c/0x38 [ 656.512793] do_interrupt_handler+0xd4/0xe0 [ 656.512809] el1_interrupt+0x48/0xf0 [ 656.512826] el1h_64_irq_handler+0x18/0x24 [ 656.512842] el1h_64_irq+0x78/0x7c [ 656.512856] preempt_count_sub+0x4c/0xe0 [ 656.512874] sdhci_cqe_enable+0x12c/0x2a0 [ 656.512892] sdhci_arasan_cqe_enable+0xa4/0xf0 [ 656.512911] cqhci_request+0xd4/0x680 [ 656.512923] mmc_cqe_start_req+0xb4/0x1a0 [ 656.512940] mmc_blk_mq_issue_rq+0x4d0/0xa60 [ 656.512954] mmc_mq_queue_rq+0x118/0x2ac [ 656.512968] blk_mq_dispatch_rq_list+0x198/0x824 [ 656.512987] __blk_mq_sched_dispatch_requests+0xb4/0x170 [ 656.513004] blk_mq_sched_dispatch_requests+0x3c/0x80 [ 656.513019] __blk_mq_run_hw_queue+0x54/0x90 [ 656.513035] blk_mq_run_work_fn+0x24/0x30 [ 656.513051] process_one_work+0x1fc/0x4b0 [ 656.513071] worker_thread+0x13c/0x470 [ 656.513088] kthread+0x164/0x180 [ 656.513104] ret_from_fork+0x10/0x20 [ 656.513120] ---[ end trace 7498d4113b84f613 ]--- 0 Quote
Ogy Posted March 21, 2022 Posted March 21, 2022 (edited) On Nanopc M4v2 not even boot from emmc, bionic/buster legacy latest update from 2-3 days ago (probably 22.02..). Edited March 21, 2022 by Ogy 0 Quote
balbes150 Posted March 22, 2022 Posted March 22, 2022 I checked this information, yes there is a problem on T4. A PR with the proposed correction will be sent in the near future. As a temporary solution for already downloaded 5.16 kernel images, you can replace DTB with a new one. rk3399-nanopc-t4.dtb 1 Quote
balbes150 Posted March 24, 2022 Posted March 24, 2022 The test version of ArmbianTV 20220324 with a new version of u-boot-2022. Allows you to select different systems when starting on the TV screen from the keyboard. This will allow you to have several different systems on eMMC at once and choose which system to run. Please note, this is a test version and there may be errors in it. I recommend checking its operation by launching it from an SD card. 1 Quote
fraz0815 Posted March 25, 2022 Posted March 25, 2022 Am 24.3.2022 um 13:25 schrieb balbes150: The test version of ArmbianTV 20220324 with a new version of u-boot-2022. Allows you to select different systems when starting on the TV screen from the keyboard. This will allow you to have several different systems on eMMC at once and choose which system to run. Please note, this is a test version and there may be errors in it. I recommend checking its operation by launching it from an SD card. Multiboot sounds great. Could we use this feature even when running headless? Maybe with a simple file, which tells uboot what to boot. 0 Quote
balbes150 Posted March 25, 2022 Posted March 25, 2022 42 минуты назад, fraz0815 сказал: Multiboot sounds great. Could we use this feature even when running headless? Maybe with a simple file, which tells uboot what to boot. This has been possible for a long time (available in all versions of Armbian that switched to using extlinux.conf), but requires manual editing of extlinux.conf (changing the parameter that is responsible for loading by default it is enough to change one line). Please note, extlinux.conf is a standard settings file that is well documented in u-boot. In fact, it is very close to the logic of using grub.cfg 1 Quote
balbes150 Posted March 31, 2022 Posted March 31, 2022 New version 20220331-edge with kernel 5.16.18. Important. Now u-boot-2022 is used with the enabled function of displaying the system (kernel) selection menu immediately at the startup stage. This allows you to have multiple systems (cores) on the media and select them from the keyboard immediately when the system starts. 0 Quote
prahal Posted April 1, 2022 Posted April 1, 2022 @fraz0815 Could you try to revert those kernel commits : 06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66 and probably also aea6cb99703e17019e025aa71643b4d3e0a24413 (both commits are related). see Those commits are proper fixes but trigger the emmc hs400 breakage on helios64 rockchip 3399 . 1 Quote
fraz0815 Posted April 3, 2022 Posted April 3, 2022 Thank you, I will try reverting and report back. Just disabling hs400 is not perfect, since it breaks reboot now, but works fine after shutdown/power disconnect. I tried some sdhci.debug_quirks(2), but they did not help so far. 0 Quote
fraz0815 Posted April 11, 2022 Posted April 11, 2022 @prahal That worked indeed, thanks! Emmc is working perfectly fine for me (reboot, poweroff etc), even in hs400-es mode. Does this patch break any other boards? I am afraid it might does, so it sounds like a bad idea to make a PR for all rk3399 boards. Any suggestions are welcome, guess I have to look how Helios64 handles this. :edit What I did: I removed rk3399-nanopc-t4-emmc.patch, so re-enabling hs400 --- a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts +++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts @@ -109,10 +109,10 @@ }; }; -&sdhci { - mmc-hs400-1_8v; - mmc-hs400-enhanced-strobe; -}; +//&sdhci { +// mmc-hs400-1_8v; +// mmc-hs400-enhanced-strobe; +//}; &u2phy0_host { phy-supply = <&vcc5v0_host0>; and reverted both commits you mentioned. diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index d9540a845..0e3192e55 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -1525,12 +1525,7 @@ static int set_machine_constraints(struct regulator_dev *rdev) * and we have control then make sure it is enabled. */ if (rdev->constraints->always_on || rdev->constraints->boot_on) { - /* If we want to enable this regulator, make sure that we know - * the supplying regulator. - */ - if (rdev->supply_name && !rdev->supply) - return -EPROBE_DEFER; - + if (rdev->supply) { ret = regulator_enable(rdev->supply); if (ret < 0) { @@ -5470,24 +5465,11 @@ regulator_register(const struct regulator_desc *regulator_desc, else if (regulator_desc->supply_name) rdev->supply_name = regulator_desc->supply_name; + if (regulator_resolve_supply(rdev)) + rdev_dbg(rdev, "unable to resolve supply\n"); + ret = set_machine_constraints(rdev); - if (ret == -EPROBE_DEFER) { - /* Regulator might be in bypass mode and so needs its supply - * to set the constraints - */ - /* FIXME: this currently triggers a chicken-and-egg problem - * when creating -SUPPLY symlink in sysfs to a regulator - * that is just being created - */ - rdev_dbg(rdev, "will resolve supply early: %s\n", - rdev->supply_name); - ret = regulator_resolve_supply(rdev); - if (!ret) - ret = set_machine_constraints(rdev); - else - rdev_dbg(rdev, "unable to resolve supply early: %pe\n", - ERR_PTR(ret)); - } + if (ret < 0) goto wash; 0 Quote
ScottP Posted June 10, 2022 Posted June 10, 2022 I did apt upgrade today on my nanoPC T4 and kernel updated from 5.10.63 to 5.15.35. EMMC went readonly, I assume due to errors. There was no Networking, ethernet and wifi not present. NVME not working either. I could not easily get an ambianmonitor due to my storage being read only or missing and no networking. I resolved the issue by attaching serial console, booting from my install sd, fsck my emmc, mount it and copy over the 5.10.63 boot files and modules. I then froze kernel. ambian-config is only offering legacy kernels now I probably need to downgrade via apt so that the running kernel reflects what apt says I have. I cant do testing as this board is in production. I will watch this and other threads so determine what and when to upgrade kernel 0 Quote
Viper Posted June 10, 2022 Author Posted June 10, 2022 3 hours ago, ScottP said: I did apt upgrade today on my nanoPC T4 and kernel updated from 5.10.63 to 5.15.35. EMMC went readonly, I assume due to errors. There was no Networking, ethernet and wifi not present. NVME not working either. I could not easily get an ambianmonitor due to my storage being read only or missing and no networking. I resolved the issue by attaching serial console, booting from my install sd, fsck my emmc, mount it and copy over the 5.10.63 boot files and modules. I then froze kernel. ambian-config is only offering legacy kernels now I probably need to downgrade via apt so that the running kernel reflects what apt says I have. I cant do testing as this board is in production. I will watch this and other threads so determine what and when to upgrade kernel I did the same ..with exactly the same result, however downloading and installing the latest Bullseye image it works. Latest image contains 5.17.9. It includes a patch to reduce speed in accessing eMMC, that is the root issue (it moves from HS400 to HS200) 0 Quote
balbes150 Posted June 10, 2022 Posted June 10, 2022 4 часа назад, ScottP сказал: I did apt upgrade today on my nanoPC T4 and kernel updated from 5.10.63 to 5.15.35. What exactly is the version of the image and where (eMMC\NVMe etc) do you have installed? 0 Quote
Viper Posted June 10, 2022 Author Posted June 10, 2022 1 hour ago, balbes150 said: What exactly is the version of the image and where (eMMC\NVMe etc) do you have installed? https://redirect.armbian.com/region/NA/nanopct4/Bullseye_current Bullseye 5.17.x (.9 actually) 0 Quote
Viper Posted June 10, 2022 Author Posted June 10, 2022 Just now, Viper said: https://redirect.armbian.com/region/NA/nanopct4/Bullseye_current Bullseye 5.17.x (.9 actually) I have the standard eMMC which comes with Nanopc T4. I do not know the exact chipset. 0 Quote
ScottP Posted June 13, 2022 Posted June 13, 2022 (edited) @balbes My system was originally installed with armbian 21.08.03 bullseye, updated infrequently. The last upgrade took it to Armbian 22.05.1 and the kernel version to 5.15.35. I have standard EMMC that the nanopc T4 comes with soldered to the board. My NVME drive is a samsung one that had been working fine for many months until this update. I can see that the current mainline images for download all contain either 5.17.* or 5.18.* and as @Viper says 5.17.9 does not exhibit the problem. So I will install 5.17.* or 5.18.* at some point Maybe 5.15.* should be removed from the repo for rockchip64: ii linux-image-current-rockchip64 22.05.1 arm64 Linux kernel, armbian version 5.15.35-rockchip64 current and the 5.17.* ones not marked as bleeding edge any more, since they are included in the latest supported downloads. edit: I installed 5.18.3 and NVME not found, EMMC is readonly and no networking - the same as 5.15.35. I will try to install 5.17.* but armbian-config is not showing it as an option. edit2: 5.16.11 - same issues as 5.18.3 and 5.15.35. armbian-config is not showing 5.17.* as an option to install. I will try booting an image instead. Eventually got 5.17.9 kernel which works without the above issues. Copied over files manually, extlinux.conf contains root uuid so that needs editing if installing Edited June 13, 2022 by ScottP Updated 0 Quote
prahal Posted February 10, 2023 Posted February 10, 2023 On 4/11/2022 at 6:52 PM, fraz0815 said: Emmc is working perfectly fine for me (reboot, poweroff etc), even in hs400-es mode. Does this patch break any other boards? I am afraid it might does, so it sounds like a bad idea to make a PR for all rk3399 boards. This code should be fine for all boards, this is the way the code was doing before v5.10.44. Though the developers patch upon the code that made this regression (code which looks fine on the paper but in practice breaks hs400es on rk3399 at least). I though that 8a866d527ac0 ("regulator: core: Resolve supply name earlier to prevent double-init") would also fix rk3399 emmc CQHCI but it did not. 0 Quote
prahal Posted February 10, 2023 Posted February 10, 2023 Good news. Without the revert and on Armbian v6.11 with a few v6.12 patches for drivers/regulator/core.c (that are in stable/master) I can mount my EMMC partition on my rk3399 with hs400es enabled without getting the cqhci error (not tested extensively but at least an improvement. I applied above Armbian edge v6.11: cb3543cff90a regulator: core: fix deadlock on regulator enable 0debed5b117d regulator: core: Fix resolve supply lookup issue 8f3cbcd6b440 regulator: core: Use different devices for resource allocation and DT lookup ba62319a42c5 regulator: core: fix resource leak in regulator_register() da46ee19cbd8 regulator: core: fix module refcount leak in set_supply() 0591b14ce039 regulator: core: fix use_count leakage when handling boot-on dc8d006d15b6 regulator: core: use kfree_const() to free space conditionally f2b41b748c19 regulator: core: fix unbalanced of node refcount in regulator_dev_lookup() fd1845069711 regulator: devres: Add devm_regulator_bulk_get_exclusive() Likely the fix would be 0debed5b117d regulator: core: Fix resolve supply lookup issue though that needs testing. 0 Quote
prahal Posted July 8, 2023 Posted July 8, 2023 This was not fixed. Testing thoroughly on 6.3 the write path I can reproduce the cqhci errors. I don't understand why commits 06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66 and aea6cb99703e17019e025aa71643b4d3e0a24413 broke hs400 support on rk3399 (but as anybody disabled hs400 on rk339 at least nobody notice anymore). 0 Quote
RussianNeuroMancer Posted October 18, 2023 Posted October 18, 2023 On 7/8/2023 at 6:08 AM, prahal said: but as anybody disabled hs400 on rk339 at least nobody notice anymore What do you mean? hs400 is still there. 0 Quote
prahal Posted December 14, 2023 Posted December 14, 2023 (edited) On 10/19/2023 at 1:13 AM, RussianNeuroMancer said: On 7/8/2023 at 6:08 AM, prahal said: but as anybody disabled hs400 on rk339 at least nobody notice anymore What do you mean? hs400 is still there. I did not check every board file. But most did remove it explaining it was not working. It could be nobody run the rk339-nanpc-t4 dts from mainline so nobody disabled it. I you have such a board and can write to emmc with hs400 enabled that would help a lot. But I doubt it would work on nanopc-t4 while I saw tenths of boards. in 2023 so pretty late after the issue arised (maybe 2 years) Rock 4C+ https://github.com/torvalds/linux/commit/2bd1d2dd808c60532283e9cf05110bf1bf2f9079 Rock Pi 4 https://github.com/torvalds/linux/commit/cee572756aa2cb46e959e9797ad4b730b78a050b and all armbian rk3399 boards have it disabled as far as I know. by the way, thanks for the challenge to prove my point 🙂 . I found this https://github.com/torvalds/linux/commit/463be3cb357dab7d7e4d8dcc7c15c642e10c5bef arm64: dts: rockchip: add enable-strobe-pulldown to emmc phy on nanopi4 and this https://github.com/torvalds/linux/commit/8b5c2b45b8f0a11c9072da0f7baf9ee986d3151e phy: rockchip: set pulldown for strobe line in dts which might be related to this emmc issue (as noted in the mainline patch in the rockchip kernel this emmc pulldown setting is always enabled while in mainline it is disabled by default). This patch introduced in 5.11 might explain why even with the regulator issue fixed (the one I found by regression testing) with newer kernel I still had hs400 failing on me. Edit: indeed with this emmc_phy pulldown setting in the dts I can now write to the emmc in hs400es mode ! Thanks a lot for pointing out that nanopc-t4 was working with hs400es! The thing is they never posted a message binding the CQE error messages to their fix.. they tell it fixes a write error. And knowing how many hs400 broken leftover there was - including the two above commit from 2023 - this was pretty hard to guess they had a fix for their board dts. I believe the rationale is the same as for rk3588 "arm64: dts: rockchip: Fix eMMC Data Strobe PD on rk3588" https://github.com/torvalds/linux/commit/37f3d6108730713c411827ab4af764909f4dfc78 " JEDEC standard JESD84-B51 defines the eMMC Data Strobe line, which is currently used only in HS400 mode, as a device->host clock signal that "is used only in read operation. The Data Strobe is always High-Z (not driven by the device and pulled down by RDS) or Driven Low in write operation, except during CRC status response." RDS is a pull-down resistor specified in the 10K-100K ohm range. Thus per the standard, the Data Strobe is always pulled to ground (by the eMMC and/or RDS) during write operations. Evidently, the eMMC host controller in the RK3588 considers an active voltage on the eMMC-DS line during a write to be an error. The default (i.e. hardware reset, and Rockchip BSP) behavior for the RK3588 is to activate the eMMC-DS pin's builtin pull-down. As a result, many RK3588 board designers do not bother adding a dedicated RDS resistor, instead relying on the RK3588's internal bias. The current devicetree, however, disables this bias (`pcfg_pull_none`), breaking HS400-mode writes for boards without a dedicated RDS, but with an eMMC chip that chooses to High-Z (instead of drive-low) the eMMC-DS line. (The Turing RK1 is one such board.) Fix this by changing the bias in the (common) emmc_data_strobe case to reflect the expected hardware/BSP behavior. This is unlikely to cause regressions elsewhere: the pull-down is only relevant for High-Z eMMCs, and if this is redundant with a (dedicated) RDS resistor, the effective result is only a lower resistance to ground -- where the range of tolerance is quite high. If it does, it's better fixed in the specific devicetrees. except for rk3588 they decided to do the opposite, that is set the pulldown for all and let specific boards disabled it. So to fix hs400es on rk3399 add under the emmc_phy node on most (if not all) boards dts: rockchip,enable-strobe-pulldown; Edited December 15, 2023 by prahal 0 Quote
Recommended Posts
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.