fraz0815

Members
  • Posts

    12
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

fraz0815's Achievements

  1. @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;
  2. 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.
  3. Multiboot sounds great. Could we use this feature even when running headless? Maybe with a simple file, which tells uboot what to boot.
  4. 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 ]---
  5. 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
  6. It is a RockPi labeled power supply with output listed as 5V@3A / 9V@2A /12V@1.5A. I switched it always to some other PSU's laying around when having difficulties, with no success. I will see what happens this time and report back eventually (and keep it powered for now).
  7. Ok, it looked like an obvious correlation to me, sorry - it was not. Long story short: I don't know what it was, sometimes the rockpi-4b gives me headaches. Fresh install of Armbian_20.08.1_Rockpi-4b_buster_current_5.8.6_desktop.img (ckecksum checked) to sdcard with etcher (which also validates) results in: To double check I also disconnected emmc and nvme extension (even though they were not used or mounted for anything) armbianmonitor -u : http://ix.io/2AeJ and it runs fine - should have done this earlier -.- Let's see when the errors come back, plugged back in the emmc and installed boot+system to it via armbian-config, verything running fine: http://ix.io/2AeP Now the nvme: http://ix.io/2AeT seems fine, no checksum errors or whatsoever. Thanks for your time, my best guess is either emmc module gets corrupted over time with no power attached or the nvme extension made trouble, or using sd+emmc+nvme together at the same time is a bad idea. Next time this happens, I will try to better investigate instead of guessing about some commits.
  8. Ok thanks for clarification, I did not really understand whats going on now, or why sometimes BLOBS are used or what TPL/SPL does instead. But I will post detailed tomorrow what I did and its results, spoiler so far: downloaded (and also updated) Armbian_20.08.1_Rockpi-4b_buster_current_5.8.6_desktop.img is not able to run simple 'apt update' without errors, or download a larger file with correct checksum., e.g. 'wget someubuntu.iso'. It is exactly the same behavior prior first commit when it was changed to 1.20, which made the board nearly useless if using 1GB ethernet. 100MB helps, playing with offloading may help a bit, but it never gets stable. Right next to the rockpi-4b (was not running last months) is a nanopc-t4 running 24/7 perfectly fine. Compiling and logs follow...
  9. hey, this change https://github.com/armbian/build/pull/2010/files made my rockpi-4b (with 4GB ram) finally stable some time ago DDR_BLOB='rk33/rk3399_ddr_933MHz_v1.20.bin' #instead of 1.24 After messing with rx/tx offloading, this was the solution, no more failed apt and download errors, great! It seems that this change got lost in the transition to the new u-boot / different logical structure or is not needed anymore for the 1GB models it was mentioned originally, see here: https://github.com/armbian/build/commit/f2db96252530d2f5585755b518e7fd020b5f0392#diff-18c1f509b638f24dc14854e6af5173bb Any chance to get it back for rockpi-4b without creating trouble, I am not sure where this change should go: /build/config/sources/families/rk3399.conf or build/config/sources/families/include/rockchip64_common.inc ? Thanks
  10. hey, after updating my nanopct4 and rockpi-4b to from 20.05 to 20.08 RDP stopped working for me, only black screen. After reading all the messy logs, fresh install etc, I found a simple working solution online: In /etc/xrdp/startwm.sh change #!/bin/sh to #!/bin/bash Sources: https://github.com/neutrinolabs/xrdp/issues/1630 https://askubuntu.com/questions/1166568/remote-desktop-blue-screen-after-login Maybe others are affected too, don't know about Ubuntu.
  11. fraz0815

    NanoPC T4

    mmc-hs400-1_8v only worked for me with 4.4. Can't say when it broke, but i did a lot of testing and building my own image with all sorts of various patches you can find across the internet. Pretty common problem on many boards, but nothing worked. It would be interesting if mmc-hs400 works on any T4, or anyone could confirm. My simple and lazy workaround is editing /boot/boot.cmd fdt rm /sdhci@fe330000 mmc-hs400-1_8v fdt rm /sdhci@fe330000 mmc-hs400-enhanced-strobe But I am afraid this could easily break with an automatic u-boot update? Does this file get touched, or is there another way through /boot/armbianEnv.txt to make this change permanent. I would like to stick to original 2019-11-19 wich works very good for me, eg rootfs on nvme though armbian-config in a few seconds.