Jump to content

Gammel

Validating
  • Posts

    1
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Gammel reacted to tparys 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
  2. Like
    Gammel reacted to Igor in 2021: Year of the Armbian Desktop!   
    Armbian have historically been much more geared towards "server/headless" usage, for many different reasons.  It has taken a much longer time not only for upstream development of underlying graphical libraries / drivers to mature, but also for us (the Armbian project itself) to come up with a sensible implementation that would fit nicely into our existing build framework.
     
    However, this work has been going on in the background for quite some time already. 
     
    Announcement
     
    Finally, the time is right to announce we are publishing our initial implementation of these "desktop" features!
     
    Warning!

    We are only announcing this here on our own forums for the time being, as this is still early days.  In fact, at this point we are still mainly looking for testers. You should consider this an alpha quality release at this time!
     
    What works so far?

    Features we plan to develop works, we are already hunting bugs for months, but they are certainly still present. Remember, we are not looking for bugs that are tied to specific hardware feature, but bugs that are linked to the build process, userland and basic desktop functionality. 
     
    Report bugs in Armbian build framework section: https://forum.armbian.com/forum/12-armbian-build-framework/
     
    Currently, the following Desktop Environments (DEs) are considered to have early "support":
     

     

     
    In addition, there are more DEs which should be considered very much WIP, in other words, not really fully working (yet), but we designed a system that can have unlimited variants.
     
    Help Wanted!
     
    These changes are wide ranging and touch many parts of the code.  Therefore even if you don't plan on using any "desktop" features, your testing can help to find bugs, even in "server" versions (as eventually this code will be merged with master in matter of weeks).
     
    If you have been looking for some opportunity to help the project by getting involved a bit more, this could be your chance!

    When you notice a problem make a pull request: https://github.com/armbian/build/pulls ( currently sits on a branch "desktop" )
     
    Going forward we will be looking for additional desktop maintainers.  Currently the plan is for the Armbian core team to maintain the framework and perhaps settle on 2-3 DE options.  Any which are to be considered in addition to that, will need to come with some commitment to ongoing maintenance by whoever is interested in those additional desktops.
     
    Join #armbian-devel IRC channel for development level chat and strengthen the desktop team. Welcome!
     
    Getting Started
     
    If this is your very first time using the build scripts, start with general instructions. If you are already familiar with the basics of building, some additional detailed instructions pertaining to desktop features can be found here.  You will also need to add:
     
    ./compile.sh LIB_TAG=desktop EXPERT=yes  
    If you don't have option or desire to build from sources, you can also check if your board has nightly images - we are compiling them from this new development branch for a few weeks now - for the desktop you want to try / see:


     
    Documentation
     
    For end users, if you just want to build image interactively and by choosing supported OS variants, things hasn't changed much and should just work while advanced documentation has changed significantly. Its pretty much WIP and is scattered around in those files:
     
    https://github.com/armbian/build/blob/desktop/config/desktop/README.md
    https://github.com/armbian/documentation/pull/125
    https://github.com/armbian/documentation/pull/98
     
    Additional
     
    During this change we also added most recent userland(s):
     

  3. Like
    Gammel reacted to tjay in SSD Unexpected_Power_Loss / POR_Recovery_Count on Reboot   
    Inspired by this topic https://forum.odroid.com/viewtopic.php?t=29069 I installed a shutdown script in /lib/systemd/system-shutdown:
    #!/bin/bash case "$1" in kexec) # Do not park disks when switching kernels. ;; *) for disk in /sys/block/sd* ; do echo 1 > /sys/class/block/${disk##*/}/device/delete done sleep 1 ;; esac this works for my needs.
     
    I don’t know if this problem is Helios64 specific, if not please move this topic to armbian common issues..
  4. Like
    Gammel reacted to Zageron in Armbian 20.11 on Helios64.... Feedback?   
    sudo insmod /lib/modules/5.9.11-rockchip64/kernel/drivers/leds/trigger/ledtrig-netdev.ko sudo systemctl restart helios64-heartbeat-led.service  
  5. Like
    Gammel got a reaction from Zageron in Armbian 20.11 on Helios64.... Feedback?   
    To activate the network activity led load kernel module ledtrig-netdev and restart helios64-heartbeat-led.service.
     
     
  6. Like
    Gammel reacted to Werner in Forum adjustments   
    To strengthen the symbiosis between Kobol and Armbian a new dedicated club has been created for Kobol products with Armbian support. It will be maintained directly by Kobol associates @gprovost and @aprayoga.
    Check it out:
     
  7. Like
    Gammel reacted to aprayoga in Helios64 Support   
    you could re-enable auto power on by removing /lib/systemd/system-shutdown/disable_auto_poweron . You can check the file to see how to control the gpio pin for the auto power on feature.
    The auto power on is always enabled by bootloader.
     
     
    As @flower answered,  SPI boot is not yet working. Theoretically after boot from SPI  you could change boot target to first SATA drive
×
×
  • Create New...