crosser
-
Posts
10 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by crosser
-
-
On 6/8/2022 at 12:51 AM, prahal said:
Do you mean all kernel from below 5.10.63 up to 5.10.63 ?
If so could you report your serial console u-boot boot output ?
5.10.60 in https://mirrors.xtom.de/armbian/pool/main/l/linux-5.10.60-rockchip64/ are broken for most (all) of us.
It would be really helpfull if an u-boot version could be related to working vs not working
I found a bad commit in the kernel between 5.10.43 and 5.10.60 bu it makes no sense to me that it breaks emmc (though I don't know much about emmc)
But if you manage to run 5.10.60 on emmc that would help us both.
-110 means timeout attempting to contact the emmc,
I remember _one_ version of the kernel (released as a package in the focal channel) about a year ago was broken, but I don't remember details. I do remember that I booted from the (stock) SD, ran dist-upgrade, and things returned to norm. It is possible that 5.10.60 was the one that was broken for me too.
I am attaching a log from reset to "Welcome" when the system is booted, with kernel 5.15.35. At this point, internal mmc is not visible in the system (and obviously not mountable).
Eugene
-
Kernel 5.15 is unusable for me (helios64), 5.15.25 and 5.15.35 do not see internal mmc:
[ 2.404726] mmc1: SDHCI controller on fe330000.mmc [fe330000.mmc] using ADMA [ 2.474955] mmc1: mmc_select_hs200 failed, error -110 [ 2.475458] mmc1: error -110 whilst initialising MMC card [ 2.592202] mmc1: mmc_select_hs200 failed, error -110 [ 2.592665] mmc1: error -110 whilst initialising MMC card [ 2.724392] mmc1: mmc_select_hs200 failed, error -110 [ 2.724853] mmc1: error -110 whilst initialising MMC card
It works with all previous kernels (up to 5.10.63), u-boot boots from it just fine.
Is it a known problem?
-
On 9/3/2021 at 6:56 AM, aprayoga said:
Hi @crosser, what Armbian version do you use?
Could elaborate what did you do with the NFS? Maybe you were doing big file transfer.
crosser@kobol:~$ uname -a Linux kobol 5.10.60-rockchip64 #21.08.1 SMP PREEMPT Wed Aug 25 18:56:55 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux crosser@kobol:~$ cat /etc/os-release NAME="Ubuntu" VERSION="20.04.3 LTS (Focal Fossa)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Armbian 21.08.1 Focal"
Cannot really "elaborate" what I am doing with NFS, I just use it lol! There was no special excessive data transfer at the time, to the best of my knowledge. And it was just one such occurrence so far, since I am using the device. It's not a problem for me (so far at least), I simply thought that it would be right to report.
-
Make it easier to disconnect fans, so the back plane is not hanging on the wires when disassembling.
-
This happened out of the blue, without indication of anything else being wrong. I just noticed that NFS stalled, and realized that the server is not on the network. The system on the box was running fine, but there were no lights on the network connector (it is connected with the upper, 1Gb, adapter). I replugged the cable into the 2.5G socket and it went online. Then I powered the box off and on again, with the cable in the 1G socket, and it came online normally.
This is what I found in dmesg/syslog:
Aug 31 09:31:39 localhost kernel: [379809.423687] NETDEV WATCHDOG: eth0 (rk_gmac-dwmac): transmit queue 0 timed out Aug 31 09:31:39 localhost kernel: [379809.424506] WARNING: CPU: 2 PID: 0 at net/sched/sch_generic.c:468 dev_watchdog+0x398/0x3a0 [...] Aug 31 09:31:39 localhost kernel: [379809.447941] rk_gmac-dwmac fe300000.ethernet eth0: Reset adapter. [...] Aug 31 09:31:39 localhost kernel: [379809.688895] rk_gmac-dwmac fe300000.ethernet: Failed to reset the dma Aug 31 09:31:39 localhost kernel: [379809.689493] rk_gmac-dwmac fe300000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed Aug 31 09:31:39 localhost kernel: [379809.690302] rk_gmac-dwmac fe300000.ethernet eth0: stmmac_open: Hw setup failed
Full log attached.
-
On 3/2/2021 at 6:12 AM, aprayoga said:
@crosser please modify /boot/armbianEnv.txt and add/modify following lines:
verbosity=7 console=serial extraargs=earlyprintk ignore_loglevel
It should make the serial console more verbose.
mortomanos is referring to Armbian Device Tree Overlays
Whether it is a coincidence, newer kernel after one of recent updates, or changed timing due to increased verbosity, but the system comes up all right after `reboot` command last few times. Knocking on wood. And thank you in any case!
-
I have armbian focal installed in mmc, kernel 5.10.16-rockchip64.
After `reboot` command, boot never completes (no heatbeat LED, no network access), though boot process seem to go quite far:
[ 10.832087] rk_gmac-dwmac fe300000.ethernet: TX Checksum insertion supported [ 10.832732] rk_gmac-dwmac fe300000.ethernet: Wake-Up On Lan supported [ 10.833507] rk_gmac-dwmac fe300000.ethernet: Normal descriptors [ 10.834059] rk_gmac-dwmac fe300000.ethernet: Ring mode enabled [ 10.834594] rk_gmac-dwmac fe300000.ethernet: Enable RX Mitigation via HW Watchdog Timer [ 10.843920] rockchip-vop ff8f0000.vop: Adding to iommu group 2 [ 10.847541] rockchip-vop ff900000.vop: Adding to iommu group 3 [ 10.973820] libphy: stmmac: probed [ 10.974169] RTL8211F Gigabit Ethernet stmmac-0:00: attached PHY driver [RTL8211F Gigabit Ethernet] (mii_bus:phy_addr=stmmac-0:00, irq=POLL) [ 10.975287] RTL8211F Gigabit Ethernet stmmac-0:01: attached PHY driver [RTL8211F Gigabit Ethernet] (mii_bus:phy_addr=stmmac-0:01, irq=POLL) [ 11.294450] async_tx: api initialized (async) [ 11.450714] BTRFS: device label export devid 3 transid 224560 /dev/sdb1 scanned by btrfs (353) [ 11.452467] BTRFS: device label export devid 2 transid 224560 /dev/sda1 scanned by btrfs (353) [ 33.760041] vcc3v0_sd: disabling [ 33.760359] vcc5v0_typec: disabling [ 42.900266] random: crng init done
After reset button, boot sometimes completes, sometimes not. After power cycle, boot always completes.
Should I, too, contact support?
And what is "armbian overlay"?
-
Thanks!
I could not respond earlier because forum allows to make only one post in the first day.
It is embarrassing, I am actually quite certain that I tried to boot with SD card and without it several times, and the result was the same (no signs of life). And I even wrote the image to the card again and tried again. But when I tried to boot yet again with the same card the next day, after reading @SIGSEGV's answer, it booted! I can only suspect lousy contact on the card or something?..
@gprovost yes, of course I did. And believe that I explained clear enough at "which step".
Anyway all is well now, thank you for your help!
-
I got my box yesterday and assembled it (looks gorgeous, and reasonably easy to assemble).
Without external power and with battery connected, green led 1 is on. With external power, orange led 9 in addition to that.
FTDI chip is recognized regardless of power status, I can connect to the console.
After pressing power button, green LEDs 2 and 3 and blue LEDs 4 and 5 light up immediately, and after that nothing else happens. Nothing on the serial console, no LEDs change status.
Tried disconnecting the battery. Then without external power, all LEDs are dark (but FTDI chip is still visible), with external power orange LED 9 blinks, the rest is exactly the same: four more LEDs light up on pressing the power button, and no other signs of life.
Looks to me as if either u-boot is absent / corrupted / inaccessinle, or the SoC does not enter boot mode.
No jumpers connected. There is no CR1225 (the board arrived without it. But with the 18660 pack).
Any advise? (I would be comfortable to play with low level boot tools).
Stability with kernel 5.15?
in Rockchip
Posted
There's been a problem when 5.15 was first rolled out (mmc access, fan control, ...) and I pinned 5.10 for a while.
A couple of months ago I tried Lunar with edge kernel (6.1) and it worked fine. So I switched and run it now, without any problems(*). I tried 5.15 as well, and it worked fine too. Things look quite good now, great thanks to the unsung heroes who are keeping the distro for this hardware alive!
(*) I use NFS server, and due to a problem not specific to the kernel, it fails to start at boot. That is because `nfsd` module is not included in initramfs, and `proc-fs-nfsd.mount` unit tries to load before the "real" root fs is mounted. And fails, and prevents all other nfs services from starting. That is solved by adding `After=local-fs.target` to the unit.