lanefu

Administrators
  • Content Count

    744
  • Joined

  • Last visited


Reputation Activity

  1. Like
    lanefu reacted to sfx2000 in Placemaker - H5 crashing under SMP load   
    In any event, the clock diffs from "stable" to "unstable" - performance overall isn't enough to justify the risks, unless one looks at specific benchmarks...
     
    I'm not into benchmarking - I've got an interest in operational usage of the device.
     
    just my thoughts...
     
    sfx
  2. Like
    lanefu got a reaction from sfx2000 in Placemaker - H5 crashing under SMP load   
    Well.... that seemed to take it down pretty quick

     
  3. Like
    lanefu reacted to le51 in Multiple audio in and out   
    Hi,
     
    I bought a module on aliexpress which is more or less the same as the audioinjector zero : https://www.aliexpress.com/item/1674210328.html
    Both use the wm8731 audio codec. It provides stereo line input, and microphone input (Note that uou can't use them simultaneously), headphone and stereo line outputs.
    Codec is supported by linux kernel.
     I've managed to get it recognized by armbian on a nanoPi K1 plus with 4.19.83-sunxi64 self build kernel (aplay -L and arecord -L have shown the interface) after some manipulations but unfortunately:
    1/ I had no sound output (didn't tried the record feature) , maybe because board is sold without any crystal oscillator soldered on it
    2/ I've lost the board :-( 
     
    Now some guidelines: the post I've mentioned above is really helpful
    - check that the i2s channel you want to use is enabled (status: "okay";)
    - see in /lib/modules/YourKernelVersion/kernel/sound/soc/codecs/ if snd-soc-wm8731.ko is there otherwise you will have to compile it
    - the dts file I've used for that (you will have to adjust it regarding your hardware) with "armbian-add-overlay wm8731.dts" :
    ## file wm8731.dts /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target-path = "/"; __overlay__ { wm8731: wm8731 { #sound-dai-cells = <0>; compatible = "wlf,wm8731"; status = "okay"; wm873x,format = "i2s"; }; }; }; fragment@1 { target = <&i2s0>; __overlay__ { status = "okay"; pinctrl-0 = <&i2s0_pins>; sound-dai = <&wm8731>; pinctrl-names = "default"; }; }; fragment@2 { target-path = "/"; __overlay__ { sound { compatible = "simple-audio-card"; simple-audio-card,name = "wm8731-hifi"; simple-audio-card,format = "i2s"; simple-audio-card,bitclock-master = <&codec_master>; simple-audio-card,frame-master = <&codec_master>; simple-audio-card,widgets = "Headphone", "Headphone Jack", "Microphone", "Microphone Jack", "Line", "Line Jack"; simple-audio-card,routing = "Headphone Jack", "RHPOUT", "Headphone Jack", "LHPOUT", "LLINEIN", "Line Jack", "MICIN", "Mic Bias", "Mic Bias", "Microphone Jack"; simple-audio-card,cpu { sound-dai = <&i2s0>; system-clock-frequency = <12000000>; }; codec_master: simple-audio-card,codec { sound-dai = <&wm8731>; system-clock-frequency = <12000000>; }; }; }; }; fragment@3 { target = <&i2c0>; __overlay__ { #address-cells = <1>; #size-cells = <0>; status = "okay"; wm8731@1a { #sound-dai-cells = <0>; compatible = "wlf,wm8731"; reg = <0x1a>; status = "okay"; }; }; }; }; Hope this helps.
  4. Like
    lanefu reacted to UniformBuffer in Various AML-S905X-CC bugs (Le Potato)   
    Thanks for the info, now i can check if some patches are applied.
    Anyway after some troubleshooting, i think that the problem with the drm has something related with the monitor (that is initializated by the lima driver? i don't know). Even with randr if i try to get some info, it report:
    Searching a bit deeper i tried to get some info directly from the edid of the monitor using the program "edid-decode"(maybe the monitor is not recognized correctly).
    In the /sys/class/drm/ folder i have:
    card0/             card0-HDMI-A-1/    renderD128/        
    card0-Composite-1/ card1/             version
     
    If i check the edid in card0-HDMI-A-1, it report:
    It sounds correct, but I could be wrong.
     
    Instead if i try to read the edid of card0-Composite-1 i got:
    EDID extract of '/sys/class/drm/card0-Composite-1/edid' failed
     
    In the previous posts i have reported the "modetest" result and it says that the composite connector have 2 resolution modes, 720x576i and 720x480i, that i think they are wrong. The HDMI connector instead report a lot of resolutions, including as first 1280x800 that is the native resolution of the monitor.
     
    I think that drm programs crash because they select the first connector they get from the drm resources enumeration (so the "corrupted" one).
    There is any way to blacklist that connector?
    Also, for curiosity, there are any other people that have the same problem (if not, probably has something to do with my strange monitor). To check i think is sufficient to be able to run weston or kmscube successfully.
     
    Thanks for the attention and the dedicated effort,
    Have a nice day
  5. Like
    lanefu got a reaction from UniformBuffer in Various AML-S905X-CC bugs (Le Potato)   
    Here are the patches currently used in the v20.02 kernel

    https://github.com/armbian/build/tree/v20.02/patch/kernel/meson64-current
  6. Like
    lanefu reacted to Lion Wang in Banana PI BPI-W2   
    Realtek RTD1296 Intelligent voice, video processing platform
     
    Main spec:
    Realtek RTD1296, Quad-core ARM Cortex-A53
    Mali T820 MP3 GPU
    4G DDR4 SDRAM
    8G eMMC flash (Max to 32 G)
    Realtek rtl8275 b/g/n wifi and BT 4.0 support
    M.2 Key E interface
    MicroSD slot supports up to 256GB expansion
    1 SATA interface
    1XGigabit LAN
    1xUSB 3.0 1xUSB 2.0
    HDMI in & HDMI out support HDMI bypass function
    TYPE C /Power
    IR support
     
     
    http://forum.banana-pi.org/t/realtek-rtd1296-intelligent-voice-video-processing-platform/10727
  7. Like
    lanefu reacted to UniformBuffer in Various AML-S905X-CC bugs (Le Potato)   
    After some research i discovered some error in the dmesg log regarding the lima driver initialization. Following an extract of dmesg:
     
    I'm refering to the errors like: IRQ ppmmu3 not found. Maybe have something to do with the drm problem.
    I found a report on the lima git where the author of the post have the exactly same error on the dmesg: https://gitlab.freedesktop.org/lima/linux/issues/26
    He s905 with kernel 5.4. These should be similar to my configuration.
    On the same post a patch is suggested to fix the problem and seems, from the author reaction, that worked. I don't know if this patch is already merged or not and i have not tried myself. Anyway i thought it could be useful for solving the problem, so i posted it.
    Thanks again for the hard work and dedicated effort.
  8. Like
    lanefu got a reaction from Werner in Waveshare 2.8 A (or 3.2 B) TFT LCD with Orange Pi Zero LTS   
    Beating your head is half the fun.   Glad you got it working and thank you for sharing your notes.
  9. Like
    lanefu reacted to Werner in How do I do this?   
    Me neither by a quick look. Just found a small typo in the first line of Common features: availble
     
  10. Like
    lanefu reacted to ej0rge in Waveshare 2.8 A (or 3.2 B) TFT LCD with Orange Pi Zero LTS   
    I don't want to talk about how long i beat my head against this but i have it working so i thought i would share. 
     
    First, in the 5.4.y kernels, the fbtft_device module seems to be missing? So i am using 5.90 oragepizero ubuntu bionic next 4.19.57 as my image, kernel is upgraded to 4.19.62-sunxi via regular apt-get upgrade.
     
    I have a genuine waveshare 2.8 A rpi lcd. Waveshare states repeatedly that it is compatible with the 3.2 B rpi lcd except for the screen size and number of buttons, so this should work for the 3.2 B lcd as well. 
     
    This blog post was pretty helpful: https://kaspars.net/blog/spi-display-orange-pi-zero
     
    But it leaves out the necessity of enabling the spi bus overlays. 
     
    So, using armbian-config, go into system -> hardware -> and enable spi-spidev and (I think?) spi-add-cs1 (as recommended by some other posts i have seen). 
     
    Then edit (as root) /boot/armbianEnv.txt and add these lines: 
     
    param_spidev_spi_bus=1
    param_spidev_spi_cs=1
    extraargs="fbcon=map:8"
     
    edit /etc/modules-load.d/modules.conf and add these lines: 
     
    fbtft
    fbtft_device
     
    create /etc/modprobe.d/fbtft.conf containing this line: 
     
    options fbtft_device rotate=90 name=waveshare32b busnum=1 gpios=dc:3,reset:0 speed=32000000
     
    Here's the kicker though. According to the wiki page for this lcd, the lcd cable select is connected to pin 24 and the touchscreen cs pin is on pin 26
     
    https://www.waveshare.com/wiki/2.8inch_RPi_LCD_(A)
     
    But i only had a white screen until i removed the "CS=1" argument from the options line. 
     
    I don't' get it. Maybe this means i can't use the touch screen, but I'm not sure i want it for my application. 
     
    But if someone can explain what the logic is there, that would be great. 
     
    My plan is to ultimately install retropie on it, and remix the "mini commodore pet" retropie enclosure to fit an opi zero instead of a raspberry pi. I've looked at retrorangepi and they don't really target this kind of configuration so that seems like the way to go. 
  11. Like
    lanefu reacted to martinayotte in Switching SUNXI-DEV to 5.6.y   
    Ok ! I passed the main hurdles ... The worst one was that many obsolete time32 helpers that are now definitively gone/erased, but we still need them for out-of-the-tree wifi drivers, so I had to put them back using timekeeping32.patch.
    I will do few more test images for my different Allwinner boards, then I will be ready for commit ...
  12. Like
    lanefu reacted to q-bert in Odroid N2 - btrfs missing in mainline kernel   
    found it, had to install btrfs-progs. Sorry for the confusion.
  13. Like
    lanefu reacted to Alexey in Passing configuration to docker build   
    No more questions  Just fixed BOARD_NAME in /etc/armbian-release, motd now displays correct name.

    PS. great job guys, userpatches concept is just great. Working firmware for the new board in 2 days - that took me 6 months before with Buildroot.
  14. Like
    lanefu reacted to Alexey in Passing configuration to docker build   
    Ok, original issue is fixed. I had BOARD_NAME instead of BOARD in my userpatches config. Now ./compile docker myconfig works.

    Thanks a lot, but with the network issue I think I can find a workaround with some little hint from you.

    Actually, what I'm trying to achieve is customizing image. I copied config/boards/lime2.conf  to config/boards/myboard.conf,  renamed the BOARD_NAME="MyBoard" to change the default hostname. BOARDFAMILY and BOOTCONFIG are the same as for Lime2,  it is the nearest compatible board, original Lime2 build works fine.  The desired image should include some pre-installed stuff (Node.js 10x, my app,  dependencies),  I did it with customize-image.sh.  Now setting BOARD=myboard creates the image I need, with the changed hostname and preinstalled software, but the network does not work.  Obviously, some patches are BOARD  -depended, not the board family. Workaround is leaving BOARD as is, and renaming the host in customize-image.sh script.  And here I need a hint - hostnamectl does not work in build time, what is the better approach? 

      
  15. Like
    lanefu reacted to Igor in Armbian 20.02 (Chiru) Release Thread   
    Yes, forgot. https://github.com/armbian/build/commit/24013582eba4ad3300d0996cf9afa3dde8513327
  16. Like
    lanefu reacted to Patrick Peters in Pine64-LTS getting all serial ports to work.   
    I am currently using the Armbian 20.02 release and doing some tests with the serial ports of a
    Pine64-LTS board. I noticed that i could not get all the serial ports to work. I needed to make a
    couple of changes in order to get them all working. Maybe i did something wrong and my changes
    were not needed, but i still would like to list them here in order to help other users who are
    having problems with the serial ports.
     
    When first starting up the armbian release i used the armbian-config tool to enable the uart 1,
    uart 2, uart 3 and uart4. I rebooted but noticed not all ports where present. I noticed a message
    in the dmesg log showing ttyS4 error -28. After some research (zcat /proc/config.gz) i noticed the
    kernel was compiled with only max 4 serial ports -> CONFIG_SERIAL_8250_NR_UARTS=4 
    Sadly this meant i had to recompile the kernel since this item can't be increased with a
    kernel parameter setting.
     
    After recompiling the kernel with CONFIG_SERIAL_8250_NR_UARTS=16 and
    CONFIG_SERIAL_8250_RUNTIME_UARTS=5 i rebooted the system with the new kernel and
    this time got the last uart 4 (addressed by 1c29000.serial) initialized (no more error -28).
    I did noticed a new problem. The uart 1 (addressed by 1c28400.serial) was initialized by
    the kernel as /dev/ttyS1 but after looking in the /dev directory there was no /dev/ttyS1
    I did some more research and thought this was due to the bluetooh hci_uart or other
    bluetooth items. So i blacklisted the modules by creating files in
    /dev/modprobe.d/<module name>.conf containing the line 'blacklist <module name>'.
    This stopped the bluetooth modules from loading but still the /dev/ttyS1 got lost.
    I thought this was probably due to some issue in the dtb file so i converted the
    /boot/dtb/allwinner/sun50i-a64-pine64-lts.dtb file to a dts file so i could read what was
    going on (using the dtc command):
     
    dtc -I dtb -O dts -o sun50i-a64-pine64-lts.dts sun50i-a64-pine64-lts.dtb  
    In the dts file i noticed the uart 1 (addressed by 1c28400.serial) also contained a bluetooth
    part:
     
    serial@1c28400 { compatible = "snps,dw-apb-uart"; reg = < 0x1c28400 0x400 >; interrupts = < 0x00 0x01 0x04 >; reg-shift = < 0x02 >; reg-io-width = < 0x04 >; clocks = < 0x02 0x44 >; resets = < 0x02 0x2f >; status = "okay"; pinctrl-names = "default"; pinctrl-0 = < 0x32 0x33 >; phandle = < 0x76 >; bluetooth { compatible = "realtek,rtl8723bs-bt"; reset-gpios = < 0x34 0x00 0x04 0x01 >; device-wake-gpios = < 0x34 0x00 0x05 0x00 >; host-wake-gpios = < 0x34 0x00 0x06 0x00 >; firmware-postfix = "pine64"; }; }; I removed the complete bluetooth part, so this part looked like:
    serial@1c28400 { compatible = "snps,dw-apb-uart"; reg = < 0x1c28400 0x400 >; interrupts = < 0x00 0x01 0x04 >; reg-shift = < 0x02 >; reg-io-width = < 0x04 >; clocks = < 0x02 0x44 >; resets = < 0x02 0x2f >; status = "okay"; pinctrl-names = "default"; pinctrl-0 = < 0x32 0x33 >; phandle = < 0x76 >; };  
    I first made a backup of the original dtb file:
     
    cp /boot/dtb/allwinner/sun50i-a64-pine64-lts.dtb /boot/dtb/allwinner/sun50i-a64-pine64-lts.dtb-orig  
    I then converted the altered dts file back into a dtb format with the help of the following command:
     
    dtc -I dts -O dtb -o sun50i-a64-pine64-lts.dtb sun50i-a64-pine64-lts.dts  
    I rebooted the system and this time i did got all 5 serial ports working and also available via /dev/ttyS* device nodes.
     
    dmesg log (serial lines) [ 2.877614] 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 30, base_baud = 1500000) is a U6_16550A [ 2.929097] 1c28400.serial: ttyS1 at MMIO 0x1c28400 (irq = 31, base_baud = 1500000) is a U6_16550A [ 2.952307] 1c28800.serial: ttyS2 at MMIO 0x1c28800 (irq = 32, base_baud = 1500000) is a U6_16550A [ 2.975520] 1c28c00.serial: ttyS3 at MMIO 0x1c28c00 (irq = 33, base_baud = 1500000) is a U6_16550A [ 2.998728] 1c29000.serial: ttyS4 at MMIO 0x1c29000 (irq = 34, base_baud = 1500000) is a U6_16550A ls -al /dev/ttyS* crw-rw---- 1 root dialout 4, 64 Feb 25 12:54 /dev/ttyS0 crw-rw---- 1 root dialout 4, 65 Feb 25 11:42 /dev/ttyS1 crw-rw---- 1 root dialout 4, 66 Feb 25 11:42 /dev/ttyS2 crw-rw---- 1 root dialout 4, 67 Feb 25 11:42 /dev/ttyS3 crw-rw---- 1 root dialout 4, 68 Feb 25 11:42 /dev/ttyS4  
    I do not know who is maintaining these parts of Armbian but would like to propose to remove the bluetooth item
    from the default DTB file and create an overlay for enabling bluetooth. Possibly with the help of armbian-config
    to enable and disable it. Also the kernel should have at least the amount of uarts enabled to make use of it
    without recompiling it.
     
     
     
     
     
     
     
     
     
  17. Like
    lanefu reacted to Anders in Mainline Linux not running at 1Ghz (ESPRESSObin)   
    I'm getting tired of Globalscale deleting my post from the Espressobin forums, instead of either fixing or acknowledging the problem.
    So I'll repost this here for future reference. This is the URL to the original thread: http://espressobin.net/forums/topic/mainline-linux-not-running-at-1ghz/
     
    Hi All
    That the Espressobin aims to support mainline is awesome – a lot of the benefits are described here http://espressobin.net/mainline-linux/.
     
    But I’m unable to get my v7 board running at more than 800MHz using the mainline kernel (for some reason cpufreq-info insists on reporting 1GHz with actual benchmarking only showing 800MHz).
     
    For the sake of this post, I tried pulling the most recent linux-next kernel. I’m using the config file from armbian.
    export ARCH=arm64 export CROSS_COMPILE=aarch64-linux-gnu- git checkout next-20190614 curl https://raw.githubusercontent.com/armbian/build/master/config/kernel/linux-mvebu64-next.config > .config make oldconfig # Just picked the defaults for new options make -j7 Image dtbs modules cp arch/arm64/boot/Image /mnt/sdcard/boot/ cp arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtb /mnt/sdcard/boot/dtb/marvell/ make modules_install INSTALL_MOD_PATH=/mnt/sdcard/ Here are the results. Notice the performance numbers and CPU Freq reported by 7-Zip:
    root@espressobin:~# uname -a Linux espressobin 5.2.0-rc4-next-20190614 #7 SMP PREEMPT Sun Jun 16 10:27:52 CEST 2019 aarch64 GNU/Linux root@espressobin:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 250 MHz and 1000 MHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 1000 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:0.09%, 250 MHz:3.60%, 500 MHz:0.16%, 1000 MHz:96.15% (152) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 250 MHz and 1000 MHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 1000 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:0.09%, 250 MHz:3.60%, 500 MHz:0.16%, 1000 MHz:96.15% (152) root@espressobin:~# lscpu Architecture: aarch64 Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 1 NUMA node(s): 1 Model: 4 CPU max MHz: 1000.0000 CPU min MHz: 200.0000 BogoMIPS: 25.00 NUMA node0 CPU(s): 0,1 Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid root@espressobin:~# 7za b 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 794 794 794 794 794 794 794 794 RAM size: 986 MB, # CPU hardware threads: 2 RAM usage: 441 MB, # Benchmark threads: 2 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 709 148 467 690 | 17938 199 771 1532 23: 701 149 480 715 | 17737 199 770 1535 24: 696 149 503 749 | 17395 199 768 1527 25: 688 149 528 786 | 17149 198 769 1526 ---------------------------------- | ------------------------------ Avr: 149 494 735 | 199 770 1530 Tot: 174 632 1133  
    The following are the performance numbers I’m looking for, achieved using 4.4.8-armada-17.02-espressobin kernel downloaded from http://espressobin.net/tech-spec/. That one, and 4.4.52-armada-17.10.4-g719fc86-dirty are the only kernels I have been able to actually get 1GHz performance with:
    root@espressobin:~# uname -a Linux espressobin 4.4.52-armada-17.10.4-g719fc86-dirty #7 SMP PREEMPT Tue Jul 3 10:59:53 UTC 2018 aarch64 GNU/Linux root@espressobin:~# 7za b 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 734 997 998 998 998 992 996 996 RAM size: 927 MB, # CPU hardware threads: 2 RAM usage: 441 MB, # Benchmark threads: 2 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 870 150 563 847 | 22431 198 969 1915 23: 860 151 582 876 | 22154 198 968 1918 24: 854 151 607 918 | 21735 198 963 1908 25: 848 152 639 969 | 21341 198 960 1900 ---------------------------------- | ------------------------------ Avr: 151 598 903 | 198 965 1910 Tot: 174 781 1406 Following http://wiki.espressobin.net/tiki-index.php?page=Build+From+Source+-+Kernel to build 4.4.52-armada-17.10.4-g719fc86-dirty also works fine at 1GHz.
     
    I’ve tried a bunch of different U-boots, all with the same result, so I really think the bug is in Linux.
     
    (FYI this is not the only problem I have been having with the v7, but lets focus on one bug at a time. Not to mention that Globalscale claims 1.2 GHz for v7 which seems entirely out of reach as any 1200 u-boot bricks my board).
  18. Like
    lanefu reacted to martinayotte in Orangepi 3 h6 allwiner chip   
    I'm currently busy on switching sunxi-dev to 5.6.y, but if any PR is provided, I'm ready to merge it ...
  19. Like
    lanefu reacted to Shoka in Odd behavior from systemd-networkd and lldp   
    Fixed
     
    There is a file /etc/machine-id that controls (among other things) the machine id broadcast by systemd-networkd.
    It's set during first boot, by systemd-machine-id-setup.  Another thing to fix on a cloned system
     
    In principal simply deleting this file and running systemd-machine-id-setup should generate a new random machine-id file.
    Unfortunately systemd-machine-id-setup takes its preferred id from another file  /var/lib/dbus/machine-id I think, so you get straight back to the original, duplicated file.
    Answer 2 (29) here gives a sequence that recreates a random /etc/machine-id file compatible with dbus/machine-id, and replaces the dbus/machine-id with the new /etc/machine-id.  Notes elsewhere suggest that "bad things will happen" if you replace dbus machine-id on a running system, but  as noted in that solution, a boot fixes any bad things that occur.
     
    sequence here in case that link disintegrates...
    # Messing with machine-id at al  sudo rm -f /etc/machine-id sudo dbus-uuidgen --ensure=/etc/machine-id sudo rm /var/lib/dbus/machine-id sudo dbus-uuidgen --ensure # immediate reboot. Done and rebooted all five machines in my test setup.
     
    netadmin@ups-monitor:~$ networkctl lldp LINK             CHASSIS ID        SYSTEM NAME      CAPS        PORT ID           PORT DESCRIPTION eth0             2ddb2dd5c7ab115e… probe3           .......a... eth0              \"probe3 uplink… eth0             6c44cc9224724968… probe2           .......a... eth0              \"probe2 uplink… eth0             a304dbe115289f1c… nanopi           .......a... eth0              \"nanopir1 upli… eth0             abe4d225ff47687e… probe2           .......a... eth0              \"probe2 uplink… eth0             eaf8d1906e1149a0… probe1           .......a... eth0              \"probe1 uplink… Capability Flags: a - Station 5 neighbors listed. Yay    
     
     
    Harry

     
     
     
  20. Like
    lanefu reacted to Shoka in Odd behavior from systemd-networkd and lldp   
    More info, it's not a bug.
    I moved the nanopi to the test network and it demonstrated the same symptoms.
     
    Digging into the lldp traffic as captured by tshark.
     
    chassis subtype:                 device:     Chassis ID: 8ebf95efbfdc41c5bfc98ebddaf49b68 ups_monitor 386562663935656662666463343163356266633938656264... 6c44cc9224724968bd3c53bef6a26a11 probe1      366334346363393232343732343936386264336335336265... 6c44cc9224724968bd3c53bef6a26a11 probe2      366334346363393232343732343936386264336335336265... 6c44cc9224724968bd3c53bef6a26a11 probe3      366334346363393232343732343936386264336335336265... 6c44cc9224724968bd3c53bef6a26a11 nanopir1    366334346363393232343732343936386264336335336265... All the orangepi r1's and (possibly the nanopir1 were cloned from the same sd card.
    It looks like systemd-networkd is seeing all the r1's and the nanopi as the same device, despite the differing MAC addresses, and thus the difference between the orangepi zero, which sees only one unique device, and the ri's and the nano, which see two unique devices. It's just an unhappy coincidence that the number of unique devices seen matches the number of interfaces on the device.
     
    lldpd allows per system configuration of chassis subtype and chassis ID.
     
    Off to find out if the same is possible with systemd-networkd
     
    Suggestion to switch ports is a good one, but I'm not sure if systemd-networkd would consider them different devices, with the those properties matching, so going down fixing that mistake first.
     
    I can probably persuade systemd-networkd to use the mac address in it's lldp broadcasts, but if anyone knows where those chassis type and chassis ID strings are stored, generated from etc, I'd love to find out.
     
    Thanks for the help and suggestions so far.
     
    Harry
     
  21. Like
    lanefu reacted to Shoka in /etc/update-motd.d/41-armbian-config   
    Pull request generated. Will consider requesting changes to 30-armbian-sysinfo if there is consensus that that change is desirable.
  22. Like
    lanefu got a reaction from UniformBuffer in Various AML-S905X-CC bugs (Le Potato)   
    best thing you can do is probably roll back
     
    sudo apt install linux-image-current-meson64=19.11.3
     
     
  23. Like
    lanefu got a reaction from UniformBuffer in Various AML-S905X-CC bugs (Le Potato)   
    Here's lepotato holding together and using lots of ram. with 2 instances of armbianmonitor -z running
     

  24. Like
    lanefu got a reaction from UniformBuffer in Various AML-S905X-CC bugs (Le Potato)   
    Okay i've got patched 5.4..... sound works.... was able to use more than a gig of ram when i ran armbianmonitor -z and watched htop from the desktop
     
    https://github.com/armbian/build/pull/1805
  25. Like
    lanefu reacted to UniformBuffer in Various AML-S905X-CC bugs (Le Potato)   
    Just downloaded the new kernel with your fixes. Like you said, audio and memory bug is now fixed. Also the meminfo now report correctly:
    CmaTotal: 262144 kB instead of ~1GB
    Thanks again for the effort and the dedicated time!