fraz0815
-
Posts
41 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by fraz0815
-
-
I built Armbian_22.08.2_Nanopct4_jammy_edge_5.19.10.img with following command, no changes made:
./compile.sh BOARD=nanopct4 BRANCH=edge RELEASE=jammy BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no COMPRESS_OUTPUTIMAGE=sha,gpg,img
Same error, see screenshot.
As mentioned earlier when changing boardfamily to rockchip64, so their patch directories (kernel+uboot) are used to build the image instead of media, it works fine.
Maybe some patch is missing?
I also made a build from master branch, Armbian_22.11.0-trunk_Nanopct4_jammy_edge_5.19.10.img which also does not get beyond uboot.
-
Hmm, i deleted mmcblk2 to be sure to have no remaining stuff on it, booting with any 5.18 image like Armbian_22.08.1_Nanopct4_jammy_current_5.18.19.img and dd it.
sudo dd if=/dev/zero of=/dev/mmcblk2 bs=1M
Then tried Armbian_22.08.1_Nanopct4_sid_edge_5.19.5.img again, here is a screenshot of uboot, after that the screen loses signal and device does not boot (checked through dhcp on router).
-
I planned to upgrade and skip current 5.18 (EOL) with edge 5.19 or just use LTS 5.15.
Offcial images 5.19/edge (e.g. Armbian_22.08.1_Nanopct4_sid_edge_5.19.5.img.xz) won't boot at all, maybe a short uboot screen.
Using uboot v22.04 like other rk3399 boards did not fix it.
SInce the nanopct4.conf is boardfamily=media but also works with rockchip64 (which was changed some time ago),
building with boardfamily=rockchip64 current 5.15 or edge 5.19 works fine, the cli builds boot as expected.
Maybe a general question, which bordfamily fits now best to nanopct4. I remember exactly problems which were fixed bei 150balbes maintainer when pulling it to media.
Thankfully all patches found their way to rockchip64, which seems to be more active for rk3399 in general.
Do you have any plans to combine them again?
-
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;
-
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.
-
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.
-
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 ]---
-
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 linesmmc2: mmc_select_hs200 failed, error -110
mmc2: error -110 whilst initialising MMC card
but gets the job done.
-
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).
-
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. -
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...
-
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
-
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/shto
#!/bin/bashSources:
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.
-
Some users report that this works for them:
-
On 12/24/2018 at 9:34 PM, martinayotte said:
Just a side note here : Is there any nightly build NanoPCT4 users who are using 4.19.y builds on eMMC ?
I ask that because I've some local patch for months that I never committed related to eMMC, which in my case was required since my T4 have an older eMMC, I had to comment those lines in DT :
//mmc-hs400-1_8v;
//mmc-hs400-enhanced-strobe;
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-strobeBut 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.
Kernel 5.19.x not working for me with media branch (rockchip64 works)
in Rockchip
Posted
Armbian_22.08.0-trunk_Nanopct4_sid_edge_5.19.0.img.xz from your link works fine.
Sorry, no UART yet, I should get one 😕