Jump to content

MichaIng

Members
  • Posts

    52
  • Joined

  • Last visited

Reputation Activity

  1. Like
    MichaIng reacted to TonyMac32 in USB3 port on ROCK64 is not functional since Linux 5.15   
    Moved.  Also checking this out tonight.
  2. Like
    MichaIng reacted to TonyMac32 in USB3 port on ROCK64 is not functional since Linux 5.15   
    I'll take a look momentarily, the same patch enabled the usb3 for both the Rock64 and the Renegade, and it looks like mainline has that enabled by default but the patch still exists.  May or may not be a cause, I would hope redundant entries simply got ignored...
  3. Like
    MichaIng got a reaction from Werner in USB3 port on ROCK64 is not functional since Linux 5.15   
    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?
  4. Like
    MichaIng reacted to usual user in Odroid N2: Issues with recent firmware and emmc modules   
    I have nothing to decide here, if you want it to be in Armbian you have to convince an Armbian maintainer to pick it up. I also use Armbian only very sporadically for board bring-up and initial tests. Nevertheless, when the release has taken place, I will build a uboot-tools package for me and can, if you wish, upload the firmware.
     
    I use it to start my system from SD card or via USB connection. I don't see  any reason why it shouldn't work with eMMC, but you only know for sure if  you've tested it. For me it was the first action to replace Petitboot with  a mainline uboot.
    You have to wait a little longer, see here.
  5. Like
    MichaIng reacted to usual user in Odroid N2: Issues with recent firmware and emmc modules   
    The firmware (uboot) is loaded by the maskrom code in the safest and slowest mode to use only minimal eMMC requirements. When uboot takes over, an attempt  is made to switch to a more efficient mode. If this does not succeed, it can  lead to the observed behavior. Since I don't know if more recent uboot  versions have already fixed a possible problem, I had offered my v2022.07-rc2  build for a quick test. Unfortunately, in the other thread it looked like the maskrom code couldn't even read the firmware blobs and without console logs  it's not really to analyze. So if you want, try v2022.07-rc2 it's a simple:
    dd bs=512 seek=1 conv=notrunc if=u-boot-meson.bin of=/dev/${entire-card-device-to-be-used} ; sync  
  6. Like
    MichaIng reacted to lpirl in NanoPi NEO3: dtb gone since linux-dtb-current-rockchip64 22.02.1   
    Meanwhile, I got a used device and I'll see how I setup the infrastructure for continuously maintaining the device.
  7. Like
    MichaIng got a reaction from joho500 in USB devices not recognized on Odroid C2   
    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
     
  8. Like
    MichaIng reacted to Igor in USB devices not recognized on Odroid C2   
    Means nothing. https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one
     
     
    Anyone can adopt it for you.
     
    Armbian is free software and provides best effort help through community forums. If you can't find answer there and/or with help of general project search engine and documentation, consider hiring an expert. 

    We are already blowing too much for public good and there is nothing coming back:
    https://docs.armbian.com/User-Guide_FAQ/#why-is-armbian-constantly-asking-for-money-free-software-should-be-free
     
    When / if solution is found, this way its implemented with lowest additional damages https://docs.armbian.com/Process_Contribute/ Of course project problems doesn't stop here. Review process is needed and long term code maintainace also contributes to the costs. Again FAQ: https://docs.armbian.com/User-Guide_FAQ/#support-time
  9. Like
    MichaIng reacted to schwar3kat in GPIO depreciation sysfs on O-PI; No /sys/class/gpio/... anymore?   
    Thanks MichaIng,  that's what I thought too.    Seems the linux kernel people are trying purposely to make it difficult.

    I eventually found it
    I compared the compile artifacts from legacy and current /drivers/gpio (before the build cleaned them) and found that .gpiolib-legacy.o.cmd and .gpiolib-sysfs.o.cmd were missing.  They were not compiling. This was in spite of kernel config containing CONFIG_GPIO_SYSFS=y and Makefile containing obj-$(CONFIG_GPIOLIB) += gpiolib-legacy.o and obj-$(CONFIG_GPIO_SYSFS) += gpiolib-sysfs.o

    I then compared Kconfig, hoping to find a hint in the comments. There was a hint in the comments "select GPIO_CDEV # We need to encourage the new ABI"

    but also... bool "/sys/class/gpio/... (sysfs interface)" if EXPERT  (this I did not expect).

    I patched Kconfig to remove the if EXPERT, built it and it worked.  I tested the GPIO and was able to toggle a pin.  I will prep a PR for current and edge.

    Kat
  10. Like
    MichaIng got a reaction from struthio in NanoPi NEO3: dtb gone since linux-dtb-current-rockchip64 22.02.1   
    I got it working with the R2 rev00 device tree:
     
    verbosity=4 bootlogo=false overlay_prefix=rockchip fdtfile=rockchip/rk3328-nanopi-r2-rev00.dtb rootdev=UUID=31d2bbea-e3ea-497d-a5cd-69a0d829f5fc rootfstype=ext4 console=serial earlycon=on usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u  
    Ethernet, USB (including USB 3.0 and UAS, from what I see) work well, even GPIO devices show up. Not sure whether the missing UART output is related to the kernel upgrade or not. 1,500,000 baudrate assured, pins should have been attached correct, however at least the board is back up. We can ship the device tree switch for our users, but I can only encourage Armbian to re-enable the NEO3 device tree or find another way to prevent users from breaking their system, for reputation reasons. The NEO3 is a small board, but there will be some important production systems live as well, and there are always users who do not have an up-to-date SD card backup, in which cases they run into their personal GAU, without (working) debug console not even a way to get any related output of the failing boot 😉.
  11. Like
    MichaIng reacted to Alan L. in NanoPi NEO3: dtb gone since linux-dtb-current-rockchip64 22.02.1   
    @Igor
     
    Can I donate either hardware, money or both to resume official Armbian support for NanoPi Neo3?  I use several of these little machines for a variety of purposes.  Thanks!
  12. Like
    MichaIng reacted to StoneHead in NanoPi NEO3: dtb gone since linux-dtb-current-rockchip64 22.02.1   
    I was actualy looking at modding the neo3 dtb file just the other day. Found it had gone missing from the dts makefile . (arch/arm64/boot/dts/rockchip/Makefile)
     
    --- Makefile.orig 2022-03-31 23:09:30.840184181 +0200 +++ Makefile 2022-03-31 23:14:43.734675836 +0200 @@ -25,6 +25,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3326-odroid-go2.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-a1.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-evb.dtb +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-neo3-rev02.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-r2s.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e.dtb  
  13. Like
    MichaIng reacted to TRS-80 in Rock Pi 4B (RK3399) Sound Broken After Latest Kernel Update   
    Done.
     
    Next time @MichaIng (or anyone, really) please 'flag' the post to bring it to (all) moderator attention.  I only happened to notice your request because I was skimming through the All Activity feed like I usually do.
  14. Like
    MichaIng got a reaction from TRS-80 in [Info] FriendlyARM PCM5102A-Hat with NanoPi Neo under mainline 4.x.x and dev 5.x.x   
    Instead of manipulating the main device tree, enabling i2s@1c22000 should be possible via overlay as well, like:
        fragment@0 {         target-path = "/soc/i2s@1c22000";         __overlay__ {             status = "okay";         };     };  
    Hence the whole overlay:
    /dts-v1/; /plugin/; / {     compatible = "allwinner,sun8i-h3";     fragment@0 {         target-path = "/soc/i2s@1c22000";         __overlay__ {             status = "okay";         };     };     fragment@1 {          target-path = "/";          __overlay__ {              pcm5102a: pcm5102a {                 #sound-dai-cells = <0>;                 compatible = "ti,pcm5102a";                 pcm510x,format = "i2s";             };         };      };     fragment@2 {         target = <&i2s0>;         __overlay__ {             status = "okay";             pinctrl-0 = <&i2s0_pins>;             sound-dai = <&pcm5102a>;             pinctrl-names = "default";         };     };     fragment@3 {         target-path = "/";         __overlay__ {             sound_i2s {                 compatible = "simple-audio-card";                 simple-audio-card,name = "I2S-master";                 simple-audio-card,mclk-fs = <256>;                 simple-audio-card,format = "i2s";                 status = "okay";                 simple-audio-card,cpu {                     sound-dai = <&i2s0>;                 };                 simple-audio-card,codec {                     sound-dai = <&pcm5102a>;                 };             };         };     }; };
    I will verify that the path /soc/i2s@1c22000 is correct, I guess there is a symbol for this as well, but obviously it is not <&i2s0>.
  15. Like
    MichaIng got a reaction from guidol in [Info] FriendlyARM PCM5102A-Hat with NanoPi Neo under mainline 4.x.x and dev 5.x.x   
    Instead of manipulating the main device tree, enabling i2s@1c22000 should be possible via overlay as well, like:
        fragment@0 {         target-path = "/soc/i2s@1c22000";         __overlay__ {             status = "okay";         };     };  
    Hence the whole overlay:
    /dts-v1/; /plugin/; / {     compatible = "allwinner,sun8i-h3";     fragment@0 {         target-path = "/soc/i2s@1c22000";         __overlay__ {             status = "okay";         };     };     fragment@1 {          target-path = "/";          __overlay__ {              pcm5102a: pcm5102a {                 #sound-dai-cells = <0>;                 compatible = "ti,pcm5102a";                 pcm510x,format = "i2s";             };         };      };     fragment@2 {         target = <&i2s0>;         __overlay__ {             status = "okay";             pinctrl-0 = <&i2s0_pins>;             sound-dai = <&pcm5102a>;             pinctrl-names = "default";         };     };     fragment@3 {         target-path = "/";         __overlay__ {             sound_i2s {                 compatible = "simple-audio-card";                 simple-audio-card,name = "I2S-master";                 simple-audio-card,mclk-fs = <256>;                 simple-audio-card,format = "i2s";                 status = "okay";                 simple-audio-card,cpu {                     sound-dai = <&i2s0>;                 };                 simple-audio-card,codec {                     sound-dai = <&pcm5102a>;                 };             };         };     }; };
    I will verify that the path /soc/i2s@1c22000 is correct, I guess there is a symbol for this as well, but obviously it is not <&i2s0>.
  16. Like
    MichaIng got a reaction from Werner in Support of Raspberry Pi   
    True, in many cases I see Armbian's kernel distribution as only real option for many of those, at least ~1 year after release, when the manufacturer provided images start to become too old. When there is a well maintained Debian based image from manufacturer and few or no chances to provide a capable one with higher FLOSS degree, the question indeed is how much benefit an Armbian image has, of course also a question of the actual goal with it.
     
     
    Some Ethernet and many WiFi chips do not run well or not at all without the non-free driver blobs. The armbian-firmware package ships these as well, btw, reasonably, as otherwise many SBCs couldn't establish a WiFi connection in the first place, causing a bootstrap issue when there is no Ethernet adapter or port nearby.
     
     
    Making hamburger for dinner now, fits well with a beer, cheers . Well fed I'll read through the whole topic.
  17. Like
    MichaIng reacted to TRS-80 in Support of Raspberry Pi   
    Besides freedom reasons, there are user/support and practical (limited) resource ones, too.  But there are 5 pages in this thread about that already (but see first page for some interesting historical perspective however).  We are after all just few guys and RPi have tons of resources already.  There are 100+ other (often more interesting) boards out there not seeing anywhere near that attention.  So we try to give attention to those otherwise orphaned ones.  Maybe we should rename the project to SBC orphanage, or use that as a subtitle.  
     
    Competition and diversity are good for keeping corporations on their toes and innovating.
     
    In fact, a lot of early criticisms of RPi 2/3 hardware have been fixed by now in newer versions.  Would that have happened if no one else were making and developing other SBC?  I think probably not.  Look at current web browser situation which is a nightmare due to no real competition.  Or places which have only one ISP (cough Comcast cough).  Many examples.
     
     
    I guess it's like the debate between Free Software and 'Open Source' approaches.  I am in favor of the former but some times I wonder.  Hard line stance or 'swim with the flow'?  In fact Debian themselves are somewhere in between (allowing non-free and contrib repos, just not by default).
     
    Also as you said above:
     
     
    Some times I wonder, too.  I guess we will never know?
     
    Allwinner is a sort of similar example, those devices became well supported in Linux not because of Allwinner (who were (are still?) famously hostile towards GPL) but they were sold so inexpensively they got into hands of a lot of hackers and ended up with good support in spite of them.  I see a sort of similar thing going on with PinePhone lately (as compared to Librem 5).[0]
     
    Anyway, it's Friday afternoon, let's grab a beer. 
     
    [0] PINE64 are no where near flaunting GPL like Allwinner, I was just contrasting their 'sell many cheap units but hire no devs' approach to that of Purism's, the latter who more explicitly promote freedom and mainlining as a feature (but at higher cost).
  18. Like
    MichaIng got a reaction from lanefu in Bring up for Odroid N2 (Meson G12B)   
    schedutil is my default governor, where I recognised the issue first. Tested several times, same like with ondemand the little cores stay at 100 MHz during tmpfs file read and write. Also I'm not sure whether it triggers on I/O alone, as has no option for this like ondemand.
  19. Like
    MichaIng got a reaction from lanefu in Some experiences with Odroid-N2+ on Debian Bullseye   
    Many thanks for this. I played a bit more around with these and found the following logic:
    With TOACODEC OUT EN and TOHDMITX one can enable analogue 3.5mm output and digital HDMI output. With TOACODEC SRC resp. TOHDMITX I2S SRC one can select the I2S device used for 3.5mm output respectively HDMI output. I cannot get I2S A working (because there is no TDMOUT_A at all), but I2S B and I2S C work for both HDMI and 3.5mm each. I assign it like you did, I2S B to TOHDMITX I2S SRC and I2S C to TOACODEC SRC. Now, with TDMOUT_B SRC SLT resp. TDMOUT_C SRC SLT one can assign I2S B resp. I2S C to an ALSA device, i.e. which one will be hw:0,0, hw;0,1 or hw:0,2. Since there is no TDMOUT_A, I cannot assign I2S A to any ALSA device. I set TDMOUT_B SRC SLT (HDMI) to IN 0 (device 0) and TDMOUT_C SRC SLT to IN 1 (device 1). FRDDR_[ABC] SRC [123] EN needs to additionally enable the I2S sources on the ALSA device, but somehow it is associated in a confusing way: FRDDR_A is related to ALSA device 0, FRDDR_B to ALSA device 1 etc, SRC 1 is related to I2S A, SRC 2 to I2C B etc. Would have been easier to understand when those would be named FRDDR_[012] SRC [ABC] so that device index and I2C identifier match. However, hence I need to enable FRDDR_A SRC 2 and FRDDR_B SRC 3, matching the TDMOUT_[BC] SRC SLT assignments above. Finally I think its the output channels which need to be split for the used ALSA devices, FRDDR_[ABC] SINK [123] SEL. Basically, at least when all channels are used, the three sinks for the used ALSA devices need to be split. With my 2.0/2.1 test audio hardware I just use OUT 0, OUT 1 resp. OUT 2 for each FRDDR_[AB] SINK 1, 2 resp. 3. All other controls seem to have no effect in my case, I guess its about SPDIF input and assigning capture devices/microphones, as of TODDR (to) and FRDDR (from) hence to which audio device input is sent compared what we assigned from which audio device the stream is received and sent to which sinks/channels, or so.
  20. Like
    MichaIng reacted to qwr in Some experiences with Odroid-N2+ on Debian Bullseye   
    I first used Kingston endurance SD card with Armbian Buster image. This failed due some incompability with Odroid N2 UHS implementation, but Sandisk extreme SD card worked with same image.
    After successful boot runned nand-sata-install to ADATA SP 550NS38 SSD connected using VL817 SATA Adaptor (2109:0715).
    Upgraded the Debian to Bullseye and installed Mesa 21.2.0 packages from experimental repositories, arm64 firefox-esr and armhf Chromium via multiarch to use widevine extracted from ChromeOS images (local err.ee web broadcasts some programs with widevine encryption). This was in the end of august. It mostly worked, but had 3 weird problems that I think to have solved now having some free time.
     
    The USB boot hanged up about half of times after kernel detected the SATA drive. Turns out that UAS is culprit, disabling UAS with usb-storage.quirks=2109:0715:u made it now boot every time without problems (modified /boot/boot.ini). About 2-3 minutes after boot the compositor froze (no matter which - tried Xorg compton, wayland Weston and Wayfire (self compiled). Turns out armbian has /etc/udev/rules.d/hdmi.rules which runs /usr/local/bin/hdmi-hotplug. For some reason the hdmi-hotplug script stalls on my Odroid installation and when systemd finally killed it, something went wrong and the compositors froze. Diverting the hdmi.rules fixed it. This was/is weirdest - when TV connected via HDMI was off and turned on, then sometimes the board would shutdown. Found from auth log "auth.log.1:Dec 25 19:04:59 piix systemd-logind[1641]: Power key pressed." Like WTF, i don't have any "power key" and why it gets invoked when TV is turned on. Set the *Key=ignore in /etc/systemd/logind.conf and it seems fine now, no idea what went wrong there. The kernel even don't have CEC enabled (CONFIG_CEC_MESON_AO and CONFIG_CEC_MESON_G12A_AO are not set for some reason in the armbian kernels).  
    A bit later I also saw 5.15.8-meson64 kernel OOPS "Unable to handle kernel execute from non-executable memory" at regmap_update_bits_base+0x74/0x98, meson_clk_cpu_dyndiv_set_rate+0xf4/0x118. As I hadn't seen this before, downgraded to 5.13.12-meson64. I plan to report the OOPS with full kernel dmesg output, when I'll have a bit more time (probably the https://bugzilla.kernel.org/ would be right place?).
     
    Currently it seems to work fine, with the 5.13.12-meson64 kernel and mesa/panfrost 21.2.1-2 (from snapshot.debian.org). Weston is used as Wayland compositor. It is important to note that I have 1080p TV, and all video decoding is done on CPU without using the Amlogic VPU acceleration, as the VPU driver is currently both broken in the kernel and unsupported in unpatched userspace. I expected this when choosing the board. Fortunately the 4xA73@2.4GHz is fast enough for decoding most 1080p videos and panfrost is fine for doing the video output after decoding. AFAIK playing 4K videos is currently not possible on Odroid N2 with mainline kernel and the vendors proprietary VPU decoder isn't supported by any software in open source distributions like Debian. Interesting is that Firefox seems to handle the video decoding pathway better for Youtube in this configuration,
    while Chromium occasionally stutters on some Youtube videos, these seem to be fine with Firefox. Luckily this seems to not affect the site where I needed widevine (that works only with Chromium in practice). In september widevine upgraded to version needing patched libc. I got patched armhf libc6 package from apt.xbian.org repository.
     
    The ALSA configuration is weird, amixer scontrols | wc gives 50 controls, and if misconfigured, then the thing doesn't give any audio output. I found the following script from somewhere that "fixes" it into working state:
     
    amixer sset 'FRDDR_A SINK 1 SEL' 'OUT 1' amixer sset 'FRDDR_A SRC 1 EN' 'on' amixer sset 'TDMOUT_B SRC SEL' 'IN 0' amixer sset 'TOHDMITX I2S SRC' 'I2S B' amixer sset 'TOHDMITX' 'on' amixer sset 'FRDDR_B SINK 1 SEL' 'OUT 2' amixer sset 'FRDDR_B SRC 1 EN' 'on' amixer sset 'TDMOUT_C SRC SEL' 'IN 1' amixer sset 'TOACODEC SRC' 'I2S C' amixer sset 'TOACODEC OUT EN' 'on' amixer sset 'TOACODEC Lane Select' '0' amixer sset 'ACODEC' '255' amixer sset 'FRDDR_C SINK 1 SEL' 'OUT 3' amixer sset 'FRDDR_C SRC 1 EN' 'on' amixer sset 'SPDIFOUT SRC SEL' 'IN 2'  
    After that ALSA pcm "hw:0,1" output works. I configured dmixed and removed pulseaudio, as it seemed to complicate things with no benefit when mpc and browser run as different users.
     
    Armbian is great (couldn't have the board working so well without armbian) and merry holidays for you
    Hoping this helps others having Odroid N2(+) board.
  21. Like
    MichaIng reacted to usual user in Odroid N2 Plus, Kernel 5.8.5 and above shows [Firmware Bug]: Kernel image misaligned at boot   
    I can now confirm that HDMI audio is up for me. I am still on my NanoPC-T4 MicroSD card but it was only necessary to insert appropriate Odroid-N2+ configurations.
     
    I used the settings from here.
  22. Like
    MichaIng got a reaction from lanefu in Bring up for Odroid N2 (Meson G12B)   
    I have two questions regarding mainline (5.10.x) kernel on Odroid N2(+), hope it is fine to ask them here:
    It is expected that the boot.ini contains legacy kernel command-line parameters, which are not supported by mainline kernel anymore, including HDMI settings, HPD, overscan, CPU count and clock, right? I saw https://github.com/armbian/build/pull/2629 but the CPU frequency settings are still/again ignored, the CPU always runs at highest possible frequencies. However, it is not a big issue since min/max frequencies can be easily set via CPUFreq API. Interestingly, when using display_autodetect "true", hdmimode "custombuilt" and modeline are set and "hdmitx edid" seems to create two related files in /boot, but all without effect, it seems? I did RAM R/W benchmarks by writing and reading back a ~2 GiB file to /tmp (tmpfs) and evicting filesystem cache between both steps (sync; echo 3 > /proc/sys/vm/drop_caches), via dd (+conv=fdatasync on write step) which reports back the read/write speeds. Somehow with Linux 4.9 provided by Hardkernel (e.g. with the image provided by Meveric here: https://oph.mdrjr.net/meveric/images/Buster/), I get ~doubled speeds, compared to Armbian Linux 5.10 (reproducible, with nice -19, no other significant processes running etc). I have not yet tested the Armbian image with legacy kernel, but has anyone an idea what the reason could be, or whether the benchmark method is faulty for some reason?
  23. Like
    MichaIng reacted to lanefu in update in buster is failing with redirection from https to 'http://armbian.tnahosting.net/apt/dists/buster/Release' is forbidden   
    Great fixes @MichaIng code is deployed.  Thank you so much!
  24. Like
    MichaIng got a reaction from lanefu in update in buster is failing with redirection from https to 'http://armbian.tnahosting.net/apt/dists/buster/Release' is forbidden   
    I would say same script, but changing the list to not include scheme, and then prepend scheme of client request to target mirror: https://github.com/armbian/dl-router/blob/master/app/mirrors.yaml
    I also see that mirrors.netix.net entry is with HTTP, but it has forced redirect to HTTPS, at least after receiving the HSTS header once.
     
    I'm learning Python by doing little contributions here and there, so I'll have a look if I can add this feature :).
  25. Like
    MichaIng got a reaction from lanefu in update in buster is failing with redirection from https to 'http://armbian.tnahosting.net/apt/dists/buster/Release' is forbidden   
    I created a pull request: https://github.com/armbian/dl-router/pull/14
×
×
  • Create New...