RussianNeuroMancer

Members
  • Content Count

    29
  • Joined

  • Last visited

About RussianNeuroMancer

  • Rank
    Member

Recent Profile Visitors

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

  1. I briefly tested 5.7.6 kernel and found that Samsung 970 EVO still doesn't work with same PCIe link training gen1 timeout error. Rollback to 5.4.49, and it works again.
  2. A bit of offtopic, but if anyone is interested Hardkernel is more open about RMA.
  3. Try to contact sales from different e-mail, say you would like to place new order, ask them if something (for example if NEO2 Black is available for order directly from their store, or if K1 Plus fits into RPi3 cases, etc.; but don't copy this blindly, come up with your own questions) when sales answer, continue asking them about other items for your new order. Then say that before placing your new order you need to resolve issue with board from previous order (mention order number here) describe how board died, attach video of attempt to power on the board, describe troubleshooting steps (that you tested different PSU, etc.) and so on. If they stop answering at this point, start conversation with sales again from different e-mail, and after few e-mail mention order with faulty board again. When I did so, they gave up, and agreed to put replacement into new order. Yeah, it's hard to make them replace faulty board, but I assure you that it's possible - I did this. (But, yeah, maybe I was just lucky, but it didn't hurt to try, right?)
  4. One of my NanoPC T4 also died a four months ago for no apparent reason, some symptoms was similar to description from Oleksii post. Initially it always printed long stack trace to serial console during rockchip_drm initialization, and then reboot on emmc initialization attempt. Later it stopped booting from emmc as if it's empty, but attempts to boot from microsd always lead to same outcome - boot loop. And finally it stopped even trying to boot from microsd with only red light. FriendlyARM send replacement for this board, but making them doing so certainly wasn't easy - when all troubleshooting steps doesn't help, they decided to stop answering until I tried to place a new order via sales e-mail and asked them to put replacement board into this order.
  5. Hello! I found that on NanoPi K1 Plus there is issues with both of integrated audio adapter (H3 Audio Codec) and HDMI Audio (allwinner-hdmi 1c22800.i2s-i2s-hifi) 1. With H3 Audio Codec I getting only silence, altrought there is short click on starting and end of playback. "Stereo" mode was chosen in pavucontrol for this audio adapter. 2. With allwinner-hdmi audio playback is working, but left and right channels is swapped. Like above "Stereo" mode was chosen in pavucontrol for this audio adapter. Tests was performed from Mate desktop installed on top of Armbian 20.05.4 with Linux 5.4.45-sunxi64. "speaker-test -t wav -c 2" command was used for testing. To make sure that PulseAudio will route audio from speaker-test to right audio adapter I used pavucontrol to disable all other audio adapters besides the one I currently test. I wonder if anyone else experiencing same issues with this board? Should I report allwinner-hdmi channels issue or H3 Audio Codec issue to kernel bugzilla or some Armbian-specific patches is involved in enabling audio adapters on this board?
  6. To achieve what specifically? As you can see in this post launching chrony manually works, what doesn't work is automatic start via systemd service.
  7. Two lines appear in journalctl -xe after every attempt to start chrony.service: May 14 03:15:58 nanopim1 chronyd[1334]: chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG) May 14 03:15:58 nanopim1 chronyd[1334]: Frequency 25.014 +/- 0.137 ppm read from /var/lib/chrony/chrony.drift Nothing else besides that and service log chrony.service log I posted yesterday. btw, I noticed that Ubuntu Server 19.10 and 20.04 (I tested generic aarch64 build of Ubuntu Server) ship systemd-timesynd by default, and it sync with ntp.ubuntu.com with default config.
  8. I checked this issue once again today - it start on boot on bionic image, but no longer works after upgrade to focal. Focal image doesn't even boot (no uboot on HDMI, solid green led; I didn't checked serial). Log: May 13 03:04:42 nanopim1 systemd[1]: Starting chrony, an NTP client/server... May 13 03:04:42 nanopim1 chronyd[8395]: chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG) May 13 03:04:42 nanopim1 chronyd[8395]: Frequency 20.659 +/- 0.346 ppm read from /var/lib/chrony/chrony.drift May 13 03:04:43 nanopim1 systemd[1]: chrony.service: New main PID 8395 does not exist or is a zombie. May 13 03:04:43 nanopim1 systemd[1]: chrony.service: Failed with result 'protocol'. May 13 03:04:43 nanopim1 systemd[1]: Failed to start chrony, an NTP client/server. However, manual launch via /usr/lib/systemd/scripts/chronyd-starter.sh (found it in /lib/systemd/system/chrony.service) indeed works fine - chrony start and synchronize time.
  9. Sure, tried to good this error too, but didn't found anything useful. Anyway, this error is either reproducible on every other supported board (in this case you can reproduce it easily) or specific to NanoPi-M1 (not supported anymore, so I guess there is no point to dig further?) There is also possibility that error is specific to H3-based or Allwinner-based SBCs, but I can't verify this as I don't have other Allwinner-based boards.
  10. I deployed Armbian to NanoPi-M1 couple of weeks ago and noticed that chrony fail to start for some reason, so clocks remain not syncronized. Replacing chrony with systemd-timesyncd solved this.
  11. https://developer.solid-run.com/knowledge-base/i-mx6-u-boot/ page mention For presenting the eMMC (mmc1) as a usb storage device, execute ums 0 mmc 1 Now on a connected PC a new usb drive should have shown up. From this point onwards anything is possible! Partitioning, mounting, writing binaries in arbitrary locations, … Did you tried that?
  12. Ok, I get why you won't to submit this change. Just want to notice that it looks like Type-C port is in host mode in case legacy 4.4 kernel and in FriendlyDesktop (I don't remember kernel version, probably 4.4 too). So it looks like Type-C is intended to run in host mode after all.
  13. I could, but this solution does not scale (specifically "things that don’t scale ... fix a problem for myself" and "things that scale ... fix the problem in way that will just work for most people, most of the time"). I there reason why you can't submit patch for type-c port to Armbian? You have better understanding of Armbian internals than I do, for sure.
  14. I briefly tested 5.6.10 kernel and found that Samsung 970 EVO doesn't work again, same PCIe link training gen1 timeout. Rollback to 5.4.32, and it works again. Manually compiled dtb will be overwritten during linux-dtb-current-rockchip64 package updates, I guess?
  15. I guess he found it here: https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/codecs/es8316/EnableSeq.conf#L16