Jump to content

MichaIng

Members
  • Posts

    51
  • Joined

  • Last visited

Recent Profile Visitors

617 profile views
  1. v21.08.2 (Linux 5.10) is the latest which works. U-boot seems irrelevant since only updating the kernel breaks it and updating/flashing U-boot doesn't solve it. It works on NanoPi NEO3 (same SoC), which probably indicates an issue with the device tree, if the USB3 host is the same?
  2. Since Linux 5.15, the USB3 port on ROCK64 does not work anymore with Armbian. The following kernel errors are shown: usb 5-1: USB disconnect, device number 2 [...] usb usb5-port1: Cannot enable. Maybe the USB cable is bad? This has been reported by multiple users with multiple drives and cables, also disabling UAS does not help. lsusb shows the drive/device, but lsblk does not. I know the ROCK64 is not currently supported by Armbian/has no maintainer, so I'm not expecting anything, just posting this as information and probably someone with more insights into the rockchip64 kernel build has an idea or workaround.
  3. I leave it to you whether a quicker RC-based release or little later stable-based release is feasible. I tested it with eMMC and SD card and it works pretty well. It does support being loaded from SPI flash as well? That is nice indeed, at least as backup bootloader, haven't tested this yet.
  4. The rk3399-opp-2ghz overlay is currently broken on all RK3399 SBCs since Linux 5.15 kernel btw (including both, "current" 5.15 and "edge" 5.18). Another report on this forum: And we replicated on NanoPi R4S and got reports on ROCK Pi 4 and NanoPi M4.
  5. That works, awesome! It's still a release candidate (now RC5 is available), I guess it is not feasible to use it for a new Armbian N2 U-Boot package before being a stable release right? But great to have a workaround, many thanks!
  6. I can confirm this and posted a serial console log here: EDIT: Ah sorry, I see my logs just match the ones that have been posted here already. It's also the same orange 16 GiB eMMC module. I'll try with edge firmware and upstream U-Boot when I find time. EDIT2: I cannot replicate ATM, but it indeed seems that it boots fine with at least one other eMMC module, reported by one of our users. Probably it's some sort of timing, i.e. the eMMC takes too long to become ready resp. the bootloader tries too early to read its partition table? The bootloader itself however was loaded successfully from that same eMMC obviously 🤔. I clearly lack if insights, just guessing around 😅.
  7. @Franky66 did you manage to boot from eMMC when flashing it directly there? I'm not able to get the recent Odroid N2 Bullseye image to boot from eMMC at all, regardless which way. Doing the exactly same on SD card works fine. I also tried it with a custom image build, installing the Armbian "current" kernel package (Linux 5.10.123) and flashing respective U-Boot via write_uboot_platform: Fails the same way when flashing to eMMC, works from SD card. Here is the log from serial console: It seems to have issues to detect the partitions on the eMMC, but of course they are fine when mounting and fscking the eMMC from a different system.
  8. At least Linux v5.15 by default has the old sysfs API disabled, so if anything depends on it (has not been migrated to use libgpiod) and it hasn't been explicitly enabled for the build like Armbian did now, then yes.
  9. Issue solved with latest kernel release, many thanks guys!
  10. Let me know if I can help with testing, reviews or such. However, as being owned by full time job and own OOS projects, I cannot be a reliable official maintainer.
  11. Ah you're right, I realised that it is the old Linux 3.x kernel and that there is no mainline kernel image provided by e.g. Tobetter for Odroid C2, like it is for newer Odroids. Testing this old image has no value in this regards. Just for reference, the mainline kernel thread on the Odroid forum may contain some hints or may be used to discuss the topic: https://forum.odroid.com/viewtopic.php?t=22717
  12. The point of testing it with the official Armbian Bullseye image is very valid, which also allows to run the armbianmonitor: https://www.armbian.com/odroid-c2/ (bottom of the page) Also the official Odroid Ubuntu image could be tested: https://wiki.odroid.com/odroid-c2/os_images/ubuntu/ubuntu If it does work there, Hardkernel obviously found a solution which probably can be adapted to Armbian.
  13. This affects all RK3399 SBCs btw, the related overclocking device tree overlays have no effect since Linux v5.15.
  14. This issue is not related to the "module not found" errors. modprobe and update-initramfs run without errors, and it is Debian Bullseye which supports xz-compressed modules (the userland tools).
  15. Ah thanks, found it, uses the same https://github.com/brektrou/rtl8821CU repo, but a specific commit. That was raised after last release via https://github.com/armbian/build/commit/98ccbc9d264e6aee3ac69692bb4ef694c079eb17, pointing to https://github.com/brektrou/rtl8821CU/commit/de68bd50671ad8a5c09af97def3f2059b4a088aa now. Trying edge kernel... Okay works very well with edge kernel indeed. So again, I can only speak for RTL8811CU (not RTL8821CU) on NanoPi R4S (Rockchip RK3399): It compiles well on "current" kernel (Linux 5.15, Armbian 22.02.1) and works well OOTB on "edge" kernel (Linux 5.16, Armbian 22.05.0 at time of writing) where the source commit has been raised to nearly latest. Now I realised that OP was able to get it working on Odroid HC4 but not on N2+. So I'll try it on N2+ as well the next days and report back.
×
×
  • Create New...