TRS-80

  • Posts

    542
  • Joined

  • Last visited

Reputation Activity

  1. Like
    TRS-80 reacted to tparys 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.
     
  2. Like
    TRS-80 got a reaction from lanefu in Firefly Station P2 (rk3568) M2 (rk3566)   
    You Keep Using That Word, I Do Not Think It Means What You Think It Means
     

  3. Like
    TRS-80 got a reaction from qualle337 in Fail to Boot with Serial Device Connected to USB   
    No PoE at that end, I just bought a cheap splitter off AliExpress for a few bucks to separate the Ethernet from power at that end.
     
    Yep, using same W5100 module.  Not even a "shield" I just connected it with dupont wires.  But a shield is probably a more reliable connection, now that I think about it.
  4. Like
    TRS-80 reacted to jako in armbian on cheap chinese netbook?   
    Thanks for this wise reply, I already loose too much time with computers.
    My wife thanks you very much
    Have a nice day
  5. Like
    TRS-80 reacted to going in RFC: armbian-build architecture   
    I want to add to the list the topic userpatches organization #2915, which @TonyMac32 started.
    This is a fundamental principle and it requires attention.
     
  6. Like
    TRS-80 got a reaction from going in RFC: armbian-build architecture   
    I guess I felt like that great discussion in rpardini's PR was sort of shut down prematurely.  Maybe the forum is a better place where we can take the long view over time and build more consensus about some of these bigger changes.
     
    Here, everyone have a beer and relax, get into right frame of mind.   
  7. Like
    TRS-80 got a reaction from lanefu in RFC: armbian-build architecture   
    I guess I felt like that great discussion in rpardini's PR was sort of shut down prematurely.  Maybe the forum is a better place where we can take the long view over time and build more consensus about some of these bigger changes.
     
    Here, everyone have a beer and relax, get into right frame of mind.   
  8. Like
    TRS-80 got a reaction from TonyMac32 in RFC: armbian-build architecture   
    I guess I felt like that great discussion in rpardini's PR was sort of shut down prematurely.  Maybe the forum is a better place where we can take the long view over time and build more consensus about some of these bigger changes.
     
    Here, everyone have a beer and relax, get into right frame of mind.   
  9. Like
    TRS-80 reacted to Виктор Васильевич in Orangepi 3 h6 allwiner chip   
    Hello! The OPI3 manufacturer in the manual directly warns not to be supplied through OTG. Too thin conductors! Alternatively, check these electrical chains and restore. If it does not help, then the AXP805 is destroyed. You can, of course, replace it if there are skills. OS is not exactly here.
    Sincerely, Viktor Chekasin.
    P.S. Sorry, this is a machine forever from Russian into English.
  10. Like
    TRS-80 got a reaction from qualle337 in Fail to Boot with Serial Device Connected to USB   
    Yes it's a bit of an architectural change.  But one I actually prefer.  In fact, I have MQTT server running on one SBC, controller (OpenHAB in my case) running on another, etc...  But you could just as easily containerize things (and one day I probably will, too).
     
    You can also position the gateway in a more ideal location (for the radio).  Mine is centrally located in our home.  I actually bought a PoE switch and run the power and data to it all in one wire.
  11. Like
    TRS-80 reacted to Halolo in Add support for GPT table inside nand-sata-install   
    Hi,
     
    I just had a brief look at the script and I'm still unfamiliar with armbian-config tools and the image building process, but I see 3 options for nand-sata-install:
    GPT Capability checked against a hardcoded list of platform that supports it. GPT is preferred if available. An input/option for the script - but as to be validated with 1. The script replicates the partition table type of the running system If the sdcard images are now generated with GPT when it is supported, then I think #3 is a good option. What do you think?
  12. Like
    TRS-80 got a reaction from Werner in The repository 'http://apt.armbian.com bionic Release' is not signed.   
    Good for you, you deserve it.
     
    No wonder your tone is more calm than usual. 
  13. Like
    TRS-80 got a reaction from lanefu in The repository 'http://apt.armbian.com bionic Release' is not signed.   
    Good for you, you deserve it.
     
    No wonder your tone is more calm than usual. 
  14. Like
    TRS-80 reacted to mo123 in Board Bring Up Station P1 rk3399, M1 rk3328   
    You have to wait until Armbian adds support for RK3566/RK3568 processors, only RK3328 & RK3399 are supported at the moment since the new processors are still very new and no one has them except a few people.
    They are very different from RK3399 ones used in devices like the Station P1, so won't boot.
    Station P2 will get mainline Linux support so in future it should work with most Linux ARM OS's.
    Yes, Armbian boots automatically from micro-sd card on Rockchip devices.
  15. Like
    TRS-80 reacted to balbes150 in [Invalid] - Device based on rk3399   
    IMHO the right option is to buy technical support for your model from Armbian. You will get a ready-made, normally working system and a constant update of your devices, taking into account security and new packages. As a bonus, you will get a wide selection of different Debian\Ubuntu systems with a desktop or server versions.
  16. Like
    TRS-80 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
  17. Like
    TRS-80 reacted to jofland in [solved] BananaPi Pro: boot directory still on sd card after moving to sata ssd   
    I solved it by my own:
     
    I had to mount the boot directory of the sd card over the boot directory of the ssd. Therefore I added two lines to the /etc/fstab of my ssd:
     
    /dev/mmcblk0p1  /media/mmcboot           ext4    defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide    0       1
    /media/mmcboot/boot  /boot           none    bind
     
    (had to create the directory /media/mmcboot first)
     
    Now the kernel loads in the right version. Kernel update works. Topic can be closed.
     
     
    Some information:
     
    root@pi-nas:~# uname -a
    Linux pi-nas 5.10.34-sunxi #21.05.1 SMP Thu May 6 20:13:21 UTC 2021 armv7l GNU/Linux

    root@pi-nas:~# ls /boot
    armbianEnv.txt                  boot.scr.bak              System.map-5.10.34-sunxi
    armbian_first_run.txt.template  config-5.10.34-sunxi      uInitrd
    boot.bmp                        dtb                       uInitrd-5.10.34-sunxi
    boot.cmd                        dtb-5.10.34-sunxi         vmlinuz-5.10.34-sunxi
    boot.cmd.bak                    dtb-5.4.20-sunxi          zImage
    boot-desktop.png                initrd.img-5.10.34-sunxi
    boot.scr                        overlay-user

    root@pi-nas:~# mount | grep boot
    /dev/mmcblk0p1 on /media/mmcboot type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600,x-gvfs-hide)
    /dev/mmcblk0p1 on /boot type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600)
  18. Like
    TRS-80 reacted to Jeremiah Cornelius in Release Announcement: TWO New, Community Unofficial Armbian MAINLINE Desktop Images for Khadas VIM3 Pro   
    I just released Armbian Focal Desktop MAINLINE images for Khadas VIM3 Pro. These are individually, pure arm64 and hybrid arm64/armhf variations.
    Thanks go to @lanefu for key pointers in understanding how to "re-arm" the firstboot and firstboot-config mechanism in current-state Armbian.
     
    Please offer feedback and experiences if you test these. The images are currently hand-built, but if enough interest is generated, and time permitting, I will commit to a git fork for an unsupported standard building process.
     

     
    I have more detail on the distribution site at archive.org, and in the corresponding posts to the Khadas forums:
     
    armhf Hybrid
    LightDM will NOT work as display manager in this configuration, and I've chromed-up lxdm as a replacement. Autologin may be a work still in progress.
    Archive.org: Armbian 21.02.3 MAINLINE Image For Khadas VIM3 Pro - 32-bit Userspace - Ubuntu Focal Xfce Desktop Forums.khadas.com: Community Armbian 21.02.3 MAINLINE Image For Khadas VIM3 Pro With 32-bit Userspace  
    arm64 Native
    UPDATED INFO
    HDMI audio out is non-functional with the 64-bit userspace, which is true for all Debian and Ubuntu systems, including Khadas Fenix builds.
    This capability may be a user's deciding factor in chosing between builds.
    With further testing, HDMI AUDIO NOW WORKS in arm64 image build!
    Archive.org: Armbian 21.02.3 MAINLINE Image For Khadas VIM3 Pro - arm64 - Ubuntu Focal Xfce Desktop Forums.khadas.com: Community Armbian 21.02.3 MAINLINE Image For Khadas VIM3 Pro arm64 Native  
  19. Like
    TRS-80 reacted to dippywood in Unable to boot 'focal' or 'buster' images on SOPine Clusterboard   
    So, here's the problem, and its resolution:
     
    Comparing the decompiled DTBs for the SOPine for 21.02.1 and 21.02.3, diff gives me 
    565d564 < non-removable; 600c599 < max-frequency = <0xbebc200>; --- > max-frequency = <0x8f0d180>; 681a681,682 > phys = <0x2d 0x00>; > phy-names = "usb"; 691a693,694 > phys = <0x2d 0x00>; > phy-names = "usb";  
    Working through these show that only the first of these seems to make a difference. The definition for mmc@1c0f000 no longer contained the 'non-removable' entry. 
     
    Therefore, inserting "non-removable;" at line 565 of sun50i-a64-sopine-baseboard.dts and compiling to /boot/dtb/allwinner/sun50i-a64-sopine-baseboard.dtb resolves this issue.
     
    I can supply a patched focal image if requested.
     
     
  20. Like
    TRS-80 got a reaction from soerenderfor in ROCKPro64 as NAS?   
    You know, at one point I thought "maybe I should just try" (exactly as you say). 
     
    I dunno, I prefer to actually try to read/research and know what I am doing beforehand as much as possible.  But I know, some times you have to just go for it.
     
    EDIT:  I figured it out, simple instructions now here: ZFS "just works" now on Armbian (2 step instructions if you are thick like me)!
  21. Like
    TRS-80 got a reaction from soerenderfor in ZFS "just works" now on Armbian (2 step instructions if you are thick like me)!   
    Following the @lanefu School of Systems Administration ("here, hold my beer!"), I decided to just give it a go.  And IT VEERRRRRKS!   
     
    Here are step by step instructions for my fellow nervous, trepidatious sorts out there:
     
    1. Install kernel headers.  I did this through armbian-config (Software -> Headers_install), rather than dicker around trying to figure out which exact package I needed for my board and architecture.
     
    2. Issue the following command:
     
    $ sudo apt -t buster-backports install zfs-dkms zfsutils-linux  
    Note: I did not have to enable backports, as apparently they already are "out of the box" in Armbian; however, follow instructions at link if this is not the case for you.
     
    Result:
     
     
    It took "a little while" to build the module(s).  Just be patient, go grab $BEVERAGE or whatever, take a break...
     
    I don't know how to express how happy I am about this.  I have wanted to do ZFS on some ARM based device for literally years now.  RK3399 was very exciting when it came out, but took years to finally get stable.
     
    A special thanks to all RK3399 devs, here and elsewhere, for making this a reality.  Beers are on me if/when we ever get around to having ArmbianCon!     
     
  22. Like
    TRS-80 got a reaction from Werner in ZFS "just works" now on Armbian (2 step instructions if you are thick like me)!   
    Following the @lanefu School of Systems Administration ("here, hold my beer!"), I decided to just give it a go.  And IT VEERRRRRKS!   
     
    Here are step by step instructions for my fellow nervous, trepidatious sorts out there:
     
    1. Install kernel headers.  I did this through armbian-config (Software -> Headers_install), rather than dicker around trying to figure out which exact package I needed for my board and architecture.
     
    2. Issue the following command:
     
    $ sudo apt -t buster-backports install zfs-dkms zfsutils-linux  
    Note: I did not have to enable backports, as apparently they already are "out of the box" in Armbian; however, follow instructions at link if this is not the case for you.
     
    Result:
     
     
    It took "a little while" to build the module(s).  Just be patient, go grab $BEVERAGE or whatever, take a break...
     
    I don't know how to express how happy I am about this.  I have wanted to do ZFS on some ARM based device for literally years now.  RK3399 was very exciting when it came out, but took years to finally get stable.
     
    A special thanks to all RK3399 devs, here and elsewhere, for making this a reality.  Beers are on me if/when we ever get around to having ArmbianCon!     
     
  23. Like
    TRS-80 reacted to lanefu in ZFS "just works" now on Armbian (2 step instructions if you are thick like me)!   
    That's how it done my friend.  nice work!
  24. Like
    TRS-80 reacted to balbes150 in So, I bought a PinePhone :) (I used to be, well still am in fact, a Librem 5 guy)   
    I'm just starting to get into the specifics of Allwinner, so my interests in this area are limited to H6 and H5 (in the future, H616). A year ago, I was interested in the possibility of acquiring PinePhone and PinebucPro, but due to the peculiarities of delivery in my area, Pine64 politely explained that this is not possible (I have no complaints about them, this is their business, they decide how to run it).
  25. Like
    TRS-80 reacted to MarkLuun in Best SBC to run as network relay with "high" bandwidth   
    After having the NanoPi Neo 3 in use for some time, I can say the white case shipped by FriendlyElec is a little problematic seen from the site of cooling down the CPU.
    The colocation room has full AC with 15 *C room temp but under high load, the CPU temp goes up to 61-62 *C.
    I think something like this might be a better choise because the air flow is much higher:
     
    https://www.ebay.at/itm/333921941529
     
    The producer of this case told me another case with the possibility to add a 40 cm fan gets addet soon. Might even be better!