Bernie_O

  • Content Count

    44
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Bernie_O reacted to barish in Espressobin support development efforts   
    Finally, Globalscale did the trick and pushed the modifications, that they had added to make 17.10 stable for all EspressoBin-Boards, to 18.12 as well. Thanks a lot, Globalscale!!
     
    Unfortunately, they did this in their repos and not in the official Marvell repos. I extracted the changes and made a pull request at the Marvell repo. I hope the changes will be merged soon, because I can then use the official Armbian build tools to generate a U-Boot/firmware that flawlessly works with my EspressoBin v7 DDR4 1cs 1GB boards. For now, I compile using the Globalscale repo and got a really stable firmware (tested on three boards for now), I am using the mainline U-Boot (2020.10), too and have no problems – but have not tested this with PCIe periphery (like wifi or SATA adaptors).
  2. Like
    Bernie_O reacted to Igor in A20 SATA write speed improvement   
    Old kernel naming doesn't receive updates anymore. You have to do this manual procedure / switch to new naming ... then update goes the usual way. It could be done automatically, but even without it was already insane lots of work most people don't even notice or support. Manual updating is a small price you need to pay.
  3. Like
    Bernie_O reacted to martinayotte in Switching sunxi current to 5.4.y   
    I will spend sometime during next 2 weeks to migrate DEV to @megi 's 5.5.y branch ...
  4. Like
    Bernie_O reacted to Igor in Armbian 19.11.y release notes   
    Release details

    https://docs.armbian.com/Release_Changelog/
     
    Upgrading your Armbian to v19.11.y
     
    This upgrade is changing kernel branch names and first upgrade is not done via regular apt-upgrade process, but you have to login as root or get super user privileges with sudo su. Than do the following:
    apt update apt upgrade armbian-config -> system -> Other -> select either legacy or current with v19.11.3
     
     
    Choose latest version of 19.11.x and select upgrade according to this scheme:
    Odroid XU4 default, next or dev -> legacy (stock 4.14.y) Allwinner default, next, dev -> legacy (4.19.y), current (5.3.y) Odroid C2 and other meson64 boards -> current (5.3.y) Odroid N2 -> legacy (4.4.y), current (5.3.y) Tinkerboard and other rockchip boards -> legacy (4.4.y), current (5.3.y) Cubox and Udoo -> imx6 current (5.3.y) Helios 4 and Clearfog -> mvebu legacy (4.14.y), current (4.19.y) Espressobin -> mvebu64 legacy (4.14.y), current (4.19.y) Those upgrades were tested manually:
     

    Note: upgrade will replace your boot script. In case you made changes, you can find a backup in /usr/share/armbian
    Main build system changes
    Due to changes in branch names and removal of all legacy kernels < 4 your predefined automatic scripts might need updating. Temporally quick fix is to add
    LIB_TAG="v19.08" to your build config file which by default is:
    userpatches/config-default.conf Then run your script as you did before.
     
    Thanks to all who are contributing their time to Armbian in various forms and especially developers who contributed to this release. Also thanks to the greater kernel developers community which are playing great role in this.

    In case you want to participate, you are more then welcome. Step up and start making changes! In case you run into the troubles or find a bug, forum is the place for talking about while fixes you are welcome to prepare and send here.

    Note: some images will be missing today and tomorrow from the download section. Missing one are being created and uploaded but this takes time ... Most of the images were manually tested for booting, upgrades as stated above, but we can't afford to make stability, functional or just boot auto tests on industrial scale. Not with our ultra tiny resources. Perhaps in the future if "you" will support that.
     
    Enjoy! 
  5. Like
    Bernie_O reacted to ww9rivers in Banana Pi running 5.90 random freezes & workaround   
    No. I have not, since the stress test didn't show any problem with power supply.
     
    The workaround has kept the box up for 11 days now:
     
    $ uptime
     04:42:34 up 11 days,  5:02,  9 users,  load average: 0.21, 0.28, 0.28
  6. Like
    Bernie_O reacted to ww9rivers in Banana Pi running 5.90 random freezes & workaround   
    I have read two old threads in this forum:
    I have been running this (will post more details if needed) for a few days:
    VERSION=5.90
    DISTRIB_ID=Ubuntu
    DISTRIB_RELEASE=18.04
    DISTRIB_CODENAME=bionic
    DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"
    NAME="Ubuntu"
    VERSION="18.04.3 LTS (Bionic Beaver)"
     
    Kernel is 4.19.62-sunxi
     
    The BPi would hang/freeze, seemingly randomly within a day or two. When it does that, there is no HDMI video or response to ping.
     
    After reading the first thread, I did stress test on the BPi for more than 2 days. The BPi actually hold up.
     
    So, next I ran "ping -i 30 -D 192.168.8.1" -- pinging my home gateway every 30 seconds. The BPi has also been up while that is going on. Now its uptime is more than 5 days.
     
    I have no problem keeping this going as a workaround -- just thought it may also be of interest to some one.
  7. Like
    Bernie_O reacted to Dysmas in SOLVED - How to disable armbian-ram-logging correctly?   
    I posted the full solution here   :  https://github.com/armbian/build/issues/1582
    The basic idea is :
     
    Once the "--delete" issue is corrected, log.hdd is better, but there is still an issue : the rotated files overlap, because the effect of the rotation is not mirrored to /var/log. I have a log rotated daily, but each rotated file contains 3 or 4 days.
    This can be solved easily by the following process :
    ramlog write (to update log.hdd before rotation) logrotate ramlog postrotate (which will copy to /var/log the modified files of /ram/log.hdd).  
    See the code on Github, link above.
  8. Like
    Bernie_O reacted to Igor in linux-firmware-image-next-sunxi ?   
    You don't need it.
  9. Like
    Bernie_O reacted to sfx2000 in /tmp gets eventually full. How to purge it?   
    logrotate is one item to look at to close out logs and age them out.
     
    FWIW -  There's armbian specific services in systemd that you might want to actually disable - armbian-ramlog for example, as when it runs out of space it gets ugly.
    systemctl list-unit-files | grep armbian armbian-firstrun-config.service            enabled         armbian-firstrun.service                   disabled        armbian-hardware-monitor.service           enabled         armbian-hardware-optimize.service          enabled        armbian-ramlog.service                     disabled        armbian-resize-filesystem.service          disabled        armbian-zram-config.service                disabled  Anyways - the ram logging and ZRAM stuff tend to be problematic for some that come into Armbian from other platforms...
     
    The two services I would disable from SystemD are below:
    armbian-ramlog.service armbian-zram-config.service  
    I know folks might be offended here - but disabling this results in expected behavior.
     
     
  10. Like
    Bernie_O reacted to Igor in Updated sunxi-next and sunxi64-next kernel   
    I made typo  We are at 5.2.5 ...
  11. Like
    Bernie_O reacted to Franky66 in Summer update. Bust.er4all boards   
    @Igor
    My big thank to you for your work. I will check the images and will give feedback for errors etc.
  12. Like
    Bernie_O reacted to Igor in Summer update. Bust.er4all boards   
    v5.90 / 7.7.2019
    All images were updated. It mainly goes for a bugfix update, cleanup, adding Debian Buster release. Beware that software maturity with Buster is not just there yet (even it was declared stable) and with some applications (like OMV) you will encounter problems. Kernel/BSP wise, Debian Buster is the same, uses Armbian kernel, as our other builds. Most of the builds were briefly tested, but bugs might be hiding somewhere. This is the best what is out there thanks to greater Debian community, those around boards and of course ours which pushes generic Debian/Linux to the sky . Enjoy the summer time.
     
    What's new? -> https://docs.armbian.com/Release_Changelog/
  13. Like
    Bernie_O reacted to jeloneal in K-worker problem on A20 based boards   
    Is there any news on this kworker issue? Actually, I'm running armbian 5.90 with 4.19.57 kernel an the problem persists. Before, I was running dev-kernel 5.1 which didn't fix the issue either.
  14. Like
    Bernie_O reacted to barish in A20 SATA write speed improvement   
    To sum up my not too excessive tests of the new kernel on the Lime2 - I did not encounter any read/write errors up to now. Right from the start I switched to nightly builds and still had a reasonably stable system. What I found dissapointing were the speeds over network (SMB): I did never exceed 44MB/s in any condition (reading, writing, HDD, SSD, SD card, SATA, USB, always GBit-Ethernet).
    If there's any procedure of testing read/write over SATA excessively - please let me know. Does a benchmark apply?
    OT: So this board might be a good update to my first generation Raspberry Pi (which makes 6MB/s ;-) ) but compared to the EspressoBin V5, which I obtained a couple of days ago and which is stable (other than the V7 I had to send back), it is about half as fast. And I am running the EspressoBin at a conservative 800MHz.
  15. Like
    Bernie_O reacted to barish in A20 SATA write speed improvement   
    Thanks @Tido for this link, I hadn't seen it and it gives quite a good explanation to why it took so long and why it's so difficult to have a decent SATA speed on Allwinner boards. :-)  So I think testing should include all different kinds of transfer block sizes, verifying the write result on the fly, just to be sure that one trial-and-error-finding is as good as the previous trial-and-error-finding, which has already been tested since 2014.
  16. Like
    Bernie_O reacted to martinayotte in I2C busses changed with update?   
    If you do a "i2cdetect -l", you will probably see that i2c-0 is dedicated to "sun4i_hdmi_i2c adapter", which maybe wasn't present before ...
     
  17. Like
    Bernie_O got a reaction from chwe in SD card performance   
    I saw that you tested a SanDisk Extreme Pro 64GB - A2 card with ext4 and didn't get the expected results (https://github.com/ThomasKaiser/Knowledge/blob/master/articles/A1_and_A2_rated_SD_cards.md)
     
    I tested my SanDisk Extreme Pro A2 256GB micro with A2 logo (bought beginning of October 2018), formatted ExFAT under MacOS 10.14 (iozone installed via homebrew). I thought this might be interesting for you:
     
    Test 1:
    random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 1 71735 74819 750573 769362 416685 61419 102400 2 72975 74808 1324810 1342211 787443 65213 102400 4 74887 76056 2067185 2154206 1440308 67627 102400 16 75828 76580 3978854 3807129 3004696 70542 102400 128 70181 75891 5519047 5797444 4493592 70074 102400 512 76834 76954 5866896 5991461 5061787 71180 102400 1024 79300 79602 5903994 4940446 5571237 72008 102400 16384 82960 82502 6244310 5044075 6105069 75332  
    Test 2:
    random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 1 72111 74632 706436 714325 388037 60997 102400 2 75580 74301 1283544 1363348 783629 64232 102400 4 76621 75244 2168159 2201398 1419623 66416 102400 16 76340 77138 4087649 3789092 3370748 69204 102400 128 75380 75991 5518693 4827877 5774217 71572 102400 512 63009 77769 5990458 5759273 5894918 66458 102400 1024 73595 68298 5961108 5981698 6634301 62683 102400 16384 72310 72862 5990121 6236754 6470780 68542  
    Test 3:
    random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 1 72706 72637 767523 787172 422875 61073 102400 2 73304 73348 1330300 1374293 800613 64702 102400 4 72564 74550 2140561 2198186 1445840 67664 102400 16 72701 76324 4004190 3749432 3430462 69190 102400 128 74825 76603 5780123 5851070 4953780 70198 102400 512 76477 76923 5890148 5900993 5225541 71628 102400 1024 77942 80417 5930079 5984115 5487737 72037 102400 16384 82740 82455 5965766 5569606 6449524 74115  
     
  18. Like
    Bernie_O reacted to Igor in What is the difference between Armbian and Debian Linux   
    I am not sure if this is what you want to know, but:

    - Debian.org or Ubuntu.com officially does not support any of those boards/boxes,
    - Armbian userspace has many small but vital performance or security adjustments,
    - Armbian fancy some kernel development and a lot of its maintaining. Debian relies on upstream sources for ARM hardware which can be years behind and/or lack of many functions,
    - Armbian userspace is lean, clean but 100% Debian (or Ubuntu) compatible
    - many stock Debian bugs are fixed on the way, "better than original :)"
    - a build system is a central part of this whole ecosystem. You can DIY. Debian much harder.
    - dedicated support forums per boards/boxes
    - plug and play vs. complicated install scenarios on Stock Debian
    - unified development scenarios and user experience vs. mess of different setup instructions scattered all around
     
    I must have forgotten many other important points
  19. Like
    Bernie_O reacted to Rfreire in And my RPI is now RIP.   
    Hi there Board,
     
    I have bought my Tinkerboard after some good research with my fellow techies at Red Hat and reading thoroughly that 19+pages Tinkerboard Thread.
     
    After crafting a super lean/mean kernel (kconfig at https://gist.github.com/rfrht/5f0fa113f12fbacf832e57ff4967785a ), I got a stable and lightweight kernel configuration.
     
    Things got a lot funnier when doing some compatibility tests with specific Asterisk versions, I was able to install and run cleanly a Raspi .DEB pkg. And that got me thinking.
     
    I have now JUST replaced the Raspberry Pi with the Tinkerboard. And guess what: It was a _inplace_ upgrade! Using the same userland, same hard drive, same everything.
     
    I just had to set the MMC card with Tinkerboard /boot stuffs, specified the USB root device using rootdev=<proper clause> (in my case, rootdev=LABEL=TinkerRoot), edited /etc/fstab accordingly and... It RAN!
     
    Smoothly. Perfectly. My 120 Mbps from carrier being diligently delivered. My userspace apps running nicely.
     
    Well, I would like to send my deep respect and special thanks to @TonyMac32 for exploring Tinkerboard and putting it to work nicely, and  @Igor for hosting the project.
     
    We grow when we share! ;-)
  20. Like
    Bernie_O got a reaction from Naguissa in Problems after last kernel update   
    Well... At least I did not. Upgraded two Banana Pis without any issues.
  21. Like
    Bernie_O got a reaction from JRoe in Sound output clipped with Cubieboard3 ARMBIAN stretch   
    If you are using mainline kernel this might help:
     
  22. Like
    Bernie_O got a reaction from gas_85 in [SOLVED] Cubietruck strange CPU load after purge rpimonitor on 5.36 in headless mode   
    Now that you wrote that, I also remember, that it took quite a while for  the „freeze“ to disappear. So all you have to do is being patient ;-)
  23. Like
    Bernie_O got a reaction from gas_85 in [SOLVED] Cubietruck strange CPU load after purge rpimonitor on 5.36 in headless mode   
    I also had this problem after updating to 5.36. I then noticed a permission error in  /var/log/syslog. Once I corrected the permissions of the appropriate path/file the welcome-screen did not „hang“ anymore with old information.
    Unfortunately I can‘t remember which path or file I had to change the permissions, but it was clear when I saw the error in syslog.
    Hope that helps at least for that „hanging“-with-old-information issue.
  24. Like
    Bernie_O reacted to Igor in upgrade jessie to stretch   
    Nope.
     

    Thank you. Fixed.
  25. Like
    Bernie_O reacted to Igor in upgrade jessie to stretch   
    Yes, it is correct. But there is always but ... unrelated to armbian. Distribution upgrades might sometimes cause troubles.

    In case you are running kernel 3.4.y you need to upgrade to NEXT kernel first since 3.4.y is not sufficient for running Stretch.
     
    Add: it is possible that you might need to deinstall jessie-root package and manually install stretch.