Jump to content

tparys

Members
  • Posts

    198
  • Joined

  • Last visited

Reputation Activity

  1. Like
    tparys got a reaction from Benedito Portela in Creating a .dtb/.dts file from an unknown/unsupported android TV box   
    If it's a TV box, you might get better results in the TV box forum.
     
    But some systems have the DTB embedded in the kernel image. If you can get to a shell, you can dump it from a running system sorta like:
     
    dtc -I fs -o devicetree.dts /sys/firmware/devicetree/base  
    Keep in mind that there are periodic changes to the DT format over time, and some vendors put in nonstandard hacks. Keeping these DTB files current is a major issue for Armbian devs. If it's for an unsupported box, it'll almost certainly require changes for everything to work properly.
  2. Like
    tparys got a reaction from Jens J. in Managing cpufreq on big.LITTLE   
    Ever since I read through THIS POST a while back, I started digging through the cpufrequtils init script, and was a more or less disappointed with what I found. It's largely a product of the CPUs that were available around that time (eg - Pentium 3). Namely that all cores in the system are the same, and there's should be only one master policy that controls everything.
     
    Of course ARM big.LITTLE totally breaks these assumptions, and leaves the script with no viable way to specify different schedulers or frequency ranges for each CPU cluster. It still runs, but not really correctly. For example, you can't set the RK3399 little cores above 1.4 GHz, but that's basically what it attempts to do on every boot.
     
    Also it needs use "cpufreq-set" to do it's job, which seems too hard when the sysfs interface is already pretty simple. Really, that extra complexity isn't buying you a single thing. Maybe it made more sense 10-15 years ago.
     
    So I took a crack at doing a far simpler, stupid version of that script (on perhaps smarter depending on perspective). It can generate it's own config, and I think that it comes across much more readable and accessible.
     
    ### # CPUFreq policy for CPUs: 0 1 2 3 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY0_GOVERNOR=ondemand # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 POLICY0_MIN_FREQ=408000 POLICY0_MAX_FREQ=1416000 ### # CPUFreq policy for CPUs: 4 5 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY4_GOVERNOR=conservative # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 POLICY4_MIN_FREQ=408000 POLICY4_MAX_FREQ=1800000  
    And using it isn't too hard ...
     
    cp cpufrequtils-bl /etc/init.d/ sudo /etc/init.d/cpufrequtils-bl save sudo vi /etc/default/cpufrequtils-bl sudo systemctl disable cpufrequtils sudo systemctl enable cpufrequtils-bl  
    I know that this is probably pretty far down on the list of priorities, but does anyone thing that this would be useful to others?
     
    cpufrequtils-bl
  3. Like
    tparys got a reaction from Lobosito in Proper way to enumerate a PPS device on odroid-C2 (Focal, 5.9.14)   
    The pps_gpio module does not take parameters. Definitions of a PPS device must be in the DTB, or overlay: https://mjmwired.net/kernel/Documentation/devicetree/bindings/pps/pps-gpio.txt
     
     
    That's because you're missing parts of the DTB overlay. Notably, you need to specify that:
    It's an overlay Where it applies ("target" or "target-path") What you're doing there (overlay or fixup) And in this case, what you're adding ... You probably meant to do something like this instead. Note that I don't have your setup, nor your board, so can't test this. But probably a better start than where you are.
     
    /dts-v1/; /plugin/; / { compatible = "rockchip,rk3328"; // Define a PPS device on GPIO Bank 1, pin 2 fragment@0 { target-path = "/"; __overlay__ { pps0: pps-gpio0 { compatible = "pps-gpio"; gpios = <&gpio1 2 0>; assert-falling-edge; }; }; }; };  
  4. Like
    tparys got a reaction from Gammel in Managing cpufreq on big.LITTLE   
    Ever since I read through THIS POST a while back, I started digging through the cpufrequtils init script, and was a more or less disappointed with what I found. It's largely a product of the CPUs that were available around that time (eg - Pentium 3). Namely that all cores in the system are the same, and there's should be only one master policy that controls everything.
     
    Of course ARM big.LITTLE totally breaks these assumptions, and leaves the script with no viable way to specify different schedulers or frequency ranges for each CPU cluster. It still runs, but not really correctly. For example, you can't set the RK3399 little cores above 1.4 GHz, but that's basically what it attempts to do on every boot.
     
    Also it needs use "cpufreq-set" to do it's job, which seems too hard when the sysfs interface is already pretty simple. Really, that extra complexity isn't buying you a single thing. Maybe it made more sense 10-15 years ago.
     
    So I took a crack at doing a far simpler, stupid version of that script (on perhaps smarter depending on perspective). It can generate it's own config, and I think that it comes across much more readable and accessible.
     
    ### # CPUFreq policy for CPUs: 0 1 2 3 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY0_GOVERNOR=ondemand # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 POLICY0_MIN_FREQ=408000 POLICY0_MAX_FREQ=1416000 ### # CPUFreq policy for CPUs: 4 5 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY4_GOVERNOR=conservative # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 POLICY4_MIN_FREQ=408000 POLICY4_MAX_FREQ=1800000  
    And using it isn't too hard ...
     
    cp cpufrequtils-bl /etc/init.d/ sudo /etc/init.d/cpufrequtils-bl save sudo vi /etc/default/cpufrequtils-bl sudo systemctl disable cpufrequtils sudo systemctl enable cpufrequtils-bl  
    I know that this is probably pretty far down on the list of priorities, but does anyone thing that this would be useful to others?
     
    cpufrequtils-bl
  5. Like
    tparys got a reaction from Dennboy in classic networking stopped working after network-manager update   
    Interesting. Doing some more digging into the debian postinst scripts. May be useful for you in the future if this becomes a continuing issue.
     
    The resolvconf package touches this file after installation (/var/lib/dpkg/info/resolvconf.postinst), but only once (tracked via a file you can pre-place, and disable any action on its part).
     
    # Linkify /etc/resolv.conf if appropriate if [ ! -e /var/lib/resolvconf/linkified ] ; then ... <snip> ... ln -nsf ../run/resolvconf/resolv.conf /etc/resolv.conf # Make a record that we have created it :> /var/lib/resolvconf/linkified fi  
    Looks like network-manager does too (/var/lib/dpkg/info/network-manager.postinst), but only if it's already a link.
     
    SystemD appears to poke this file on a fresh installation (/var/lib/dpkg/info/systemd.postinst), but not on upgrade.
     
    Might be useful to find out what /etc/resolv.conf is pointing to, and look for that pattern in /var/lib/dpkg/info? Might tell you which package is tripped you up, and how to prevent it from doing that in the future?
  6. Like
    tparys got a reaction from Rodrigo V. Lopes in ALERT! /dev/mmcblk0p1 does not exist   
    First, "armbian-monitor -u". Edit your top post and add it at the top.
     
    What you're seeing is initial ramfs (or initramfs), but is often written as inital ramdisk (or initrd) for historical reasons. It's singular job is to mount the root filesystem before init / SystemD takes over. It's basically a compressed archive (CPIO) of a bunch of scripts made by initramfs-tools (or dracut on systems like Redhat) that load drivers and pivot to the real filesystem before continuing.
     
    In this case, it's attempting to mount the device listed as "/dev/mmcblk0p1", and it can't find it, and eventually gave up. Linux is running, but boot is stuck.
     
    If the MMC interface is anything like the Ethernet subsystem, devices get enumerated based on the order they are found. So eth0 is first, eth1 is second and so forth. If two drivers load at the same time, there's a possible race condition and they can flip occasionally, and even change behavior after a software update. This is also the reason for the "persistent" Ethernet device names like "enp3s2" which are crazy looking, but deterministic.
     
    I've noticed that many ARM boards get device names from the DTB aliases. But maybe it's not being used for whatever reason? Not sure.
     
    In the meantime, if mmcblk0 and mmcblk1 occasionally swap position, it's probably far better to specify your root device via LABEL or even better, by UUID.
     
    $ sudo blkid /dev/mmcblk0p1  
    Then change your boot arguments to include "root=UUID=<WHATEVER>". Should be in /etc/armbianEnv.txt. but don't have it in front of me at the moment.
     
    Also update your /etc/fstab to point to "UUID=<WHATEVER>", else you won't get much further.
     
    More information on initramfs-tools, and boot arguments: https://manpages.debian.org/testing/initramfs-tools-core/initramfs-tools.7.en.html
  7. Like
    tparys got a reaction from TRS-80 in no properly formatted SHA checksum lines found   
    The -c was there before. It's yelling about the extra file on the end which isn't a .sha file ...
     
    https://github.com/armbian/documentation/pull/160
  8. Like
    tparys got a reaction from Werner in CREATE_PATCHES and how to diff two folders and copy over just the diffs or something   
    Depending on how different the u-boot sources are, the patches may or may not work.
     
    You can always make those changes by hand to create a new set of patches, but might be some work.
     
    Unfortunately, if it were simple, Armbian would not be dropping support for some boards.
  9. Like
    tparys got a reaction from Werner in no properly formatted SHA checksum lines found   
    The -c was there before. It's yelling about the extra file on the end which isn't a .sha file ...
     
    https://github.com/armbian/documentation/pull/160
  10. Like
    tparys got a reaction from Ucino in no properly formatted SHA checksum lines found   
    Looks like you're passing both the checksum file and the image file to " shasum -c ".
     
    The checksum file looks to be loading correctly, but obviously the image file is not a text file with checksums, so it's failing.
     
    Maybe just call it like this?
     
    shasum -a 256 -c Armbian_21.08.1_Orangepipcplus_buster_current_5.10.60.img.xz.sha  
  11. Like
    tparys got a reaction from Werner in OverlayFS - read only root filesystem   
    My understanding is that the overlayfs package is provided by the Ubuntu upstream packages, and is not part of the Debian repositories. Armbian does not provide or directly support this software package.
     
    It's likely that with some minor work, it would be compatible with the base Debian image, however is out of scope of the Armbian project.
  12. Like
    tparys reacted to Igor in Do you like to see your favorite board supported?   
    Recently we announced that we are going to drop support for bulk of boards to secure better quality for those that will remain. But which will remain? Those who will have at least one dedicated maintainer - anyone can become one. 

    Check new "Armbian standard" support policy:
     
    Armbian team took over what was possible while the remaining boards, which won't get a maintainer by December 1st, will loose support status and will be removed from the download pages.
    https://github.com/armbian/build/pull/3148

    Apply and help
     
    Apply for maintainership by contacting @yang or @Werner
  13. Like
    tparys got a reaction from Igor in Lead maintainer: armbian-config refactor   
    In that case, it looks like I misunderstood you. Apologies for that.
  14. Like
    tparys got a reaction from Werner in Orange Pi Zero error during apt update   
    Offhand, probably not a great idea to mix and match Debian and Ubuntu repositories. You may want to reinstall with the Debian derived Armbian before continuing. There's a very good chance you'll end up with library versioning issues, unless you know what you're doing.
     
    That said, it looks like you put "stable/updates" instead of "stable-updates" in your /etc/apt/sources.list ...
     
  15. Like
    tparys got a reaction from Heisath in initramfs-tools not fully installed on Debian Stretch with Armbian Linux 4.19.56-mvebu64   
    EspressoBin is currently in CSC support, so best to submit bugs/questions in in Peer to Peer Support.
     
    Also need to submit armbianmonitor output. It seems dumb, but there's a lot of necessary information in there.
     
     
    However, in this case, it tells you exactly what died. You've somehow uninstalled busybox (directly or indirectly), and initramfs-tools can't work properly without it.
     
     
    Not advisable. The initramfs-tools package generates the initrd file for the kernel, which is generally a required part of the boot process. You'll want to get this fixed, and probably not reboot in the meantime until you do.
  16. Like
    tparys got a reaction from phosgene in Trouble with Armbian Build CRYPTROOT "Starting Kernel..."   
    https://forum.armbian.com/topic/18583-encrypted-image-no-prompt/?tab=comments#comment-126748
  17. Like
    tparys got a reaction from Myron in How do I turn on networking using bash commands if I've accidentally disabled networking within the GUI shell?   
    Took a quick look on my system doing that.
     
    Doing "systemctl status", I don't see any obvious services that were started or stopped.
     
    You might learn more reading up on the options in the NetworkManager command line tool:
     
    $ man nmcli  
    Or check with the XFCE guys over at https://forum.xfce.org/ what exactly that network widget does.
  18. Like
    tparys got a reaction from Myron in The LED1 and LED2 on the BanabaPi Pro. How do I get them to show MMC card usage and the watchdog heart beat?   
    Pssst ... If you cat the trigger file, it'll tell you the valid options, and which one is currently selected.
     
    tparys@laptop:~$ cat /sys/class/leds/input4\:\:capslock/trigger none usb-gadget usb-host rfkill-any rfkill-none kbd-scrolllock kbd-numlock [kbd-capslock] kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock ACAD-online BAT0-charging-or-full BAT0-charging BAT0-full BAT0-charging-blink-full-solid disk-activity disk-read disk-write ide-disk mtd nand-disk cpu cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7 panic mmc0 rfkill0 phy0rx phy0tx phy0assoc phy0radio rfkill1 audio-mute audio-micmute  
    I'd wager the correct trigger is "mmc0", unless there's a both a SD card and eMMC slot on that board?
  19. Like
    tparys got a reaction from Willy Moto in Creating a .dtb/.dts file from an unknown/unsupported android TV box   
    If it's a TV box, you might get better results in the TV box forum.
     
    But some systems have the DTB embedded in the kernel image. If you can get to a shell, you can dump it from a running system sorta like:
     
    dtc -I fs -o devicetree.dts /sys/firmware/devicetree/base  
    Keep in mind that there are periodic changes to the DT format over time, and some vendors put in nonstandard hacks. Keeping these DTB files current is a major issue for Armbian devs. If it's for an unsupported box, it'll almost certainly require changes for everything to work properly.
  20. Like
    tparys got a reaction from Werner in how to make the Ubutu Scripts useful in Armbian? / to make the fan of nanopi M4V2 SATA hat always running...   
    nanopim4v2 rc.local[3751]: /etc/rc.local: 16: echo: echo: I/O error  
    That's the script error, probably line 16. Not sure why it failed. I don't see anything obviously wrong.
     
    Depending, it's possible the kernel is still initializing the PWM device at the time it runs. You can add some print statements like "echo HERE" to you script to confirm where it dies. You can try to add a delay like a "sleep 30" at the start of the script, but that's just a guess. Not sure why you'd be getting an I/O error.
     
    It's also possible that there's some kernel version differences between the FriendlyElec build and Armbian's kernel, so that scripting might need some changes.
     
    For example, I had to do this to turn on the PWM fan on my M4V2 metal case. You may need to experiment a bit.
     
    echo 0 > /sys/class/pwm/pwmchip1/export echo normal > /sys/class/pwm/pwmchip1/pwm0/polarity echo 50000 > /sys/class/pwm/pwmchip1/pwm0/period echo 40000 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle echo 1 > /sys/class/pwm/pwmchip1/pwm0/enable  
     
    Edit: As a note, my M4V2 had pwm0 set as inverted by default. Your settings of 90% power could be interpreted as 10% instead, and may not be enough for the fan to spin.
  21. Like
    tparys got a reaction from gounthar in How would you implement a super precise clock with a board running Armbian?   
    For what it's worth, Microsemi sells lots of stuff designed by Jackson Labs Technologies, which might open up the market options.
     
    Also, if you're looking for accurate clocks you can disconnect and take indoors, the term you're looking for is GPS Holdover. Just fair warning that the more accurate the clock, the longer it might take with view of the sky before it hits full accuracy (though Microsemi won't advertise that). FYI, double oven temperature compensated oscillators can get better accuracy than the some commercial grade atomic clock options, but may take up to 3 days of warmup to get to full spec..
     
    But if you're going to procure a couple and take them inside, consider a battery backup to avoid the initial training time, and make sure they get lots of sunlight before you need them.
  22. Like
    tparys got a reaction from TRS-80 in How would you implement a super precise clock with a board running Armbian?   
    On a local network, NTP tends to have an offset/jitter of around 20-50 ms.
     
    Distributing PPS to all your computers (may require signal buffering / EMI shielding) should get it down to <10 ms.
     
    You can also consider Chrony w/ PTP support, but will require all your network switches to support it to get the best performance. I don't recall offhand if it requires driver/kernel support.
     
  23. Like
    tparys got a reaction from gounthar in How would you implement a super precise clock with a board running Armbian?   
    On a local network, NTP tends to have an offset/jitter of around 20-50 ms.
     
    Distributing PPS to all your computers (may require signal buffering / EMI shielding) should get it down to <10 ms.
     
    You can also consider Chrony w/ PTP support, but will require all your network switches to support it to get the best performance. I don't recall offhand if it requires driver/kernel support.
     
  24. Like
    tparys got a reaction from StickyPine in Encrypted image no prompt   
    When using an encrypted root, it needs to be unlocked and prepared for mount in the kernel initramfs. This part runs after u-boot, but before SystemD takes over. It also have slightly different rules on where kernel output goes, where it only goes to one "console", which is specified in the kernel arguments (visible after boot in /proc/cmdline).
     
    If memory serves, the last "console=" argument takes priority during initramfs (though its hazy sometimes and it might be the first). You may need to adjust the order of the kernel arguments to make your password prompt appear on VGA or serial console (whichever you expect).
     
    I don't have a rockpro64 to test with, but you should verify that it's not doing something silly like going to a serial port with a different baud rate than your uboot. FYI, RK3399's use an odd baud rate of 1.5 megabaud.
  25. Like
    tparys got a reaction from MastinZgZ in RS485 in NanoPi Neo Core   
    I've not tried this, but you might start looking at the 485 specific device tree bindings. If it's possible, you'll almost certainly need to write your own overlay.
     
    Also, USB to 485 adapters are only around ~$15 USD on amazon. Unless you need to to use an onboard UART, or want to do it as a project, it may not be worth the time investment.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines