Jump to content

MichaIng

Members
  • Posts

    62
  • Joined

  • Last visited

Reputation Activity

  1. Like
    MichaIng reacted to usual user in RK3399 DWC3 USB3.0 driver failed after recent kernel update   
    FWIW, I've moved to 6.7.0.rc2 and the mainline USB regression can no longer be observed:
    /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 1: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M |__ Port 4: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M |__ Port 2: Dev 6, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M But new toys in town to play with:
     
  2. Like
    MichaIng reacted to lk404 in Orange Pi Zero 3   
    Device tree is in
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts?h=v6.6-rc3
  3. Like
    MichaIng reacted to joe38 in I2S Problems with Respeaker MIC2 Hat on Banana PI Zero M2   
    Hello,
     
    Solution to run a pcm5102a module on a BPi M2 Zero board (Allwinner H2+/H3).
     
    Becarfull , the connection is different compared to the GPIO 40 of the Raspberry !
     
    Wiring of the DAC on GPIO40 of the BPi M2 Zero:
     
    SCLK (not connected)
    BCK on CON2-P27 (PA19-EINT19)
    LCK on CON2-P28 (PA18-EINT18)
    DIN on CON2-P40 (PA20-EINT20)
    VIN (5v) on CON2-P02 or CON2-P04
    GND on CON2-P06
     
    Image linux Armbian used :

    Armbian_22.11.0-trunk_Bananapim2zero_bullseye_edge_6.0.9.img

    Enabled i2s via overlay :
     
     
    Create a file sun8i-h3-I2S-out.dts containing the text of the discussion indicated above /boot/overlay-user
    The contents of sun8i-h3-I2S-out.dts should look like:
     
    /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>;
                    };
                };
            };
        };
    };
     
    Launch the command :
    armbian-add-overlay ./sun8i-h3-I2S-out.dts

    The sun8i-h3-I2S-out.dtbo file is created
    The /boot/armbianEnv.txt file is modified, now you should find the line "user_overlays=sun8i-h3-I2S-out"

    reboot BPi M2 Zero
     
    The aplay -l command verifies the presence of the pcm5102a DAC.

    aplay -l
    **** List of PLAYBACK Hardware Devices ****
    card 0: I2Smaster [I2S-master], device 0: 1c22000.i2s-pcm5102a-hifi pcm5102a-hifi-0 [1c22000.i2s-pcm5102a-hifi pcm5102a-hifi-0]
      Subdevices: 1/1
      Subdevice #0: subdevice #0
    card 1: sun9ihdmi [sun9i-hdmi], device 0: SUN9I-HDMI PCM i2s-hifi-0 [SUN9I-HDMI PCM i2s-hifi-0]
      Subdevices: 1/1
      Subdevice #0: subdevice #0
     
    Thanks to everyone who writes in the forums otherwise I wouldn't have been able to get the whole thing working.
    For information, works very well with Logitech Media Server and the Squeezlite player (and certainly others but I haven't tried).
  4. Like
    MichaIng got a reaction from jumbo125 in Odroid C2 never starting after a soft reboot (reboot command)   
    To me this sounds like a kernel issue, not an individual support request. Or can't it be replicated by others?
     
    I see that the smoke tests go through: https://github.com/armbian/build/runs/5793093247?check_suite_focus=true
    But this is "edge" kernel, not "current".
     
    @yandritos
    Can you verify that the edge kernel solves it:
    apt install linux-image-edge-meson64 linux-dtb-edge-meson64 linux-u-boot-odroidc2-edge
  5. Like
    MichaIng reacted to c0rnelius in RK3399 RAM overclocking rockpro64   
    I've also noticed using an overlay to overclock the RK3399 on 5.15.y doesn't work, although in my testing it does work fine on 5.17 / 5.18.y. One solution is to patch the rk3399-opp.dtsi and add a turbo-mode switch. This way the board can be overclocked on the fly with a simple `echo "1" > sudo tee /sys/devices/system/cpu/cpufreq/boost`.
     
     
    013-rk3399-opp-overclock-2GHz-turbo-mode.patch
  6. Like
    MichaIng reacted to chewitt in USB devices not recognized on Odroid C2   
    See https://github.com/chewitt/linux/commit/aee6af1b7f123920a3f43afcdb5832c335df909c for a workaround (both patch and boot params alternative). I'll ask Marting to nag the USB list for a response again, but we already did this about four times and nobody is responding.
  7. Like
    MichaIng reacted to Sl8rBug in NEO3 and the nanopi-R2 Device-Tree   
    Because I have updated to Armbian 22.02 with the linux 5.15.25 kernel and I am using the rk3328-nanopi-r2-rev00 device tree, I thought I should share what I have discovered.
     
    1/
    I had trouble setting up a one-wire device (ds18b20 temperature sensor).
    I think the w1-gpio pin assigned in the supplied overlay is messing up access of the SD card.
     
    I found some helpful information from this post:
    https://forum.pine64.org/showthread.php ... #pid100639
     
    I copied the overlay code, modified it to use GPIO2_A2 (pin 7 on the 26pin header), compiled it and copied the new dtbo file to "/boot/overlay-user/" . Added the "user_overlays=rockchip-w1-gpio" line to "/boot/armbianEnv.txt" and rebooted.
    Success. I was able to read the ds18b20.
    (I have since discovered the utility "armbian-add-overlay" would have done the compile, copy and edit steps all at once.)
     
    The steps I took:
    Overlay filename: rockchip-w1-gpio.dts
    /dts-v1/; /plugin/; / { compatible = "rockchip,rk3328"; fragment@0 { target-path = "/"; __overlay__ { w1: onewire@0 { compatible = "w1-gpio"; pinctrl-names = "default"; gpios = <&gpio2 2 0>; status = "okay"; }; }; }; };  
    You will probably need to install the device-tree-compiler.
     
    sudo apt install device-tree-compiler  
    Compile the overlay:
    dtc -I dts -O dtb -o rockchip-w1-gpio.dtbo rockchip-w1-gpio.dts  
    Copy the compiled overlay:
    sudo cp rockchip-w1-gpio.dtbo /boot/overlay-user/  
    Add the "user_overlays=rockchip-w1-gpio" line (without quotes) to "/boot/armbianEnv.txt" and reboot.
     
    I have learnt a bit more about "Device Trees" and "dt overlays" (I still don't understand how it all works), it turns out overlays can be used to change (somewhat) what has been configured in the Device Tree being used.
    So here are some more overlays that I have come up with after grabbing snippets from here and there.
     
    2/
    I have read of people editing and recompiling the device tree dtb file to enable the USB-OTG to be used as a "normal" USB port.
    I have created an overlay that changes the dr_mode of the USB-OTG from "otg" to "host".
     
    Overlay filename: rockchip-usb-otg.dts
     
    /dts-v1/; /plugin/; / { compatible = "rockchip,rk3328-usb\0rockchip,rk3066-usb\0snps,dwc2"; fragment@0 { target-path = "/usb@ff580000"; __overlay__ { dr_mode = "host"; }; }; };  
    Compile:
    dtc -@ -I dts -O dtb -o rockchip-usb-otg.dtbo rockchip-usb-otg.dts
    Copy the compiled overlay to /boot/overlay-user/ and add "rockchip-usb-otg" (without quotes) to /boot/armbianEnv.txt on the "user_overlays=" line.
    After a reboot, check by plugging a "9-hole To Dual USB2.0 Female Header Adapter Cable" (or similar) onto the USB header and plug a couple of flash drives in to the USB sockets.
    Type lsblk and the resulting output should show /dev/sda and /dev/sdb.
     
    3/
    The rk3328-nanopi-r2.dtb doesn't enable "pwm".
    PWM is handy for controlling the speed of a cooling fan. There is a header on the board for just a thing. (2Pin JST ZH 1.5mm Connector for 5V Fan)

    Overlay filename: rockchip-pwm-gpio.dts
    /dts-v1/; /plugin/; / { compatible = "rockchip,rk3328"; fragment@0 { target-path = "/pwm@ff1b0020"; __overlay__ { status = "okay"; }; }; };  
    Compile, copy and edit as above and reboot.
     
    ls /sys/class/pwm/
     
    This should show "pwmchip0" is available.
    To be able to control "PWM" from userspace, a couple of other things need to be in place.
    The user needs to be a member of the "gpio" group and some udev rules need to be in place.
     
    filename: 50-pwm.rules
     
    SUBSYSTEM=="pwm*", PROGRAM="/bin/sh -c '\ chown -R root:gpio /sys/class/pwm && chmod -R 770 /sys/class/pwm;\ chown -R root:gpio /sys/devices/platform/*.pwm/pwm/pwmchip* && chmod -R 770 /sys/devices/platform/*.pwm/pwm/pwmchip*\ '"
     
    Copy the 50-pwm.rules file to:- "/etc/udev/rules.d/" (without the quotes)
     
    Reload the udev rules.
     
    udevadm control --reload-rules ; udevadm trigger  
    Here is a shell script to setup the PWM. Values for period and duty-cycle width may be changed as required.

    filename: setpwm.sh
     
    #! /usr/bin/bash # activate the PWM. echo 0 > /sys/class/pwm/pwmchip0/export #Wait for export to settle sleep 2 # set period to 10ms echo 10000000 > /sys/class/pwm/pwmchip0/pwm0/period # set normal polarity. needs to be reset explicitly. Bug? echo "inversed" > /sys/class/pwm/pwmchip0/pwm0/polarity echo "normal" > /sys/class/pwm/pwmchip0/pwm0/polarity # enable the PWM echo 1 > /sys/class/pwm/pwmchip0/pwm0/enable # set duty cycle to 1ms echo 1000000 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle  
     
    4/
    The NanoPi NEO3 has a push button. From documentation I have found, indicates that it is supposedly a reset button, but it seems to have no effect.
     
    This overlay renames the button and sets the function to "Power Off" (or "Reset"). I wanted it to shutdown the NEO3, so I have configured it as "KEY_POWER" (0x74). Change line 15 to "linux,code = <0x198>;" for a Reset button.
     
    Overlay filename: rockchip-power-button.dts
     
    /dts-v1/; /plugin/; / { compatible = "rockchip,rk3328"; fragment@0 { target-path = "/"; __overlay__ { gpio-keys { button@0 { label = "k1_button"; linux,code = <0x74>; //0x198 = KEY_RESTART, 0x74 = KEY_POWER }; }; }; }; };
    Compile, copy and edit as above and reboot.
     
    Press the button and the NEO3 should shutdown (or restart).
     
    5/
    Apparently the NanoPi R2 has two additional LEDS, ("lan-led" and "wan-led") that the NEO3 does not. The rk3328-nanopi-r2.dtb assigns these LEDS to GPIO pins that are on the 26pin header that would be used as normal GPIO or used by I2S and SPI on the NEO3.
    To make these pins available for use, I have made an overlay that re-assigns the "lan-led" and "wan-led" to gpios that (according to the NEO3 schematic) are not used on the NEO3.

    Overlay filename: rockchip-leds.dts
     
    /dts-v1/; /plugin/; / { compatible = "rockchip,rk3328"; fragment@0 { target-path = "/"; __overlay__ { gpio-leds { led@2 { gpios = <&gpio0 5 0>; }; led@3 { gpios = <&gpio0 6 0>; }; }; }; }; };  
    Compile, copy and edit as above and reboot.
    Check by using "gpioinfo"
     
    gpioinfo gpiochip0  
    The output will show that the "lan-led" and "wan-led" are now assigned to gpiochip0, lines 5 and 6 respectively.
     
     
    I believe that using these simple Device Tree Overlays, has made my NanoPi NEO3 perform as it was intended.
     
     
    I have found one flaw. After upgrading to the latest armbian kernel, 20.02, two GPIO pins will not change state.
    They are GPIO2_B7/I2S1_MCLK (gpiochip2, 15) and GPIO3_B0/SPI_CSN0 (gpiochip3, 8).
    Something is loaded during boot that sets them both High (I have LEDs connected and can see when they go High).
    Using the commands "gpioset gpiochip2 15=0" and "gpioset gpiochip3 8=0" does not turn the LEDs off.
    There are no errors or warnings when using the commands and "gpioinfo" shows that the pins are "input active-high".
    This effect did not happen using the previous kernel and happens late in the boot process.
    I am ruling out any Device Tree problems as the Green Status LED is flashing happily well before either pin goes high.

    Regards,
    John
     
  8. Like
    MichaIng reacted to TonyMac32 in USB3 port on ROCK64 is not functional since Linux 5.15   
    I've pushed the fix to the build system, this new forum organization stuck my answer at the very top so it was removed from the discussion flow.
  9. Like
    MichaIng reacted to useful64 in USB3 port on ROCK64 is not functional since Linux 5.15   
    The only way I found to get it work was unbind the device and rebind it again:
     
    # printf 'ff600000.dwc3' > /sys/bus/platform/drivers/dwc3/unbind
    printf 'ff600000.usb' > /sys/bus/platform/drivers/dwc3/unbind
    sleep 5
    # printf 'ff600000.dwc3' > /sys/bus/platform/drivers/dwc3/bind
    printf 'ff600000.usb' > /sys/bus/platform/drivers/dwc3/bind
     
    If it is already working, I recommend syncing and powering off the device before (sync /dev/sdx; udisksctl power-off --block-device /dev/sdx), unbind it (if you want to do it for testing purposes).
  10. 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...
  11. 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?
  12. 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.
    Release v2022.07 has taken place and the uboot-tools package has been build. I am running the firmware from SPI flash and it is working flawless for me.
    Since distro-boot is supported for free, the use of an extlinux.conf allows to select the current kernel, an previous one and a persistent one with the option to enable SPI flash for ODROID-N2 or ODROID-N2+. See the attached extlinux.conf as an example implementation.
    More details can be extracted from this thread, with its distracting posts in between. It is possible to keep as many different kernels installed as persistent space is available. A kernel upgrade will never leave an unbootable system behind as long as a previously working one is still installed.
    So if someone wants to experiment with u-boot-meson.bin, you have to let me know and I will upload the file.
    extlinux.conf
  13. 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  
  14. 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.
  15. 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
     
  16. 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
  17. 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
  18. 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 😉.
  19. 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!
  20. 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  
  21. 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.
  22. 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>.
  23. 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>.
  24. 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.
  25. 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).
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines