Bernie_O

Members
  • Content Count

    41
  • Joined

  • Last visited


Reputation Activity

  1. 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.
     
     
  2. Like
    Bernie_O reacted to Igor in Updated sunxi-next and sunxi64-next kernel   
    I made typo  We are at 5.2.5 ...
  3. 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.
  4. 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/
  5. 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.
  6. 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.
  7. 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.
  8. 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 ...
     
  9. 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  
     
  10. Like
    Bernie_O reacted to Igor in what difference between armium 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
  11. 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! ;-)
  12. 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.
  13. 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:
     
  14. 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 ;-)
  15. 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.
  16. Like
    Bernie_O reacted to Igor in upgrade jessie to stretch   
    Nope.
     

    Thank you. Fixed.
  17. 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. 
  18. Like
    Bernie_O got a reaction from Tido in Mainline A10/A20 audio driver   
    Just for the record:
    the noise is actually a result of the mainline kernel powering down the audio subsystem when not in use. Disabling this as described in the below quoted post works also with my Banana Pi. With using a cable (as described above) the noise is gone, but still there is quite a loud "plop" when the audio-subsystem changes its power-state. Disabling the powering down of the audio subsystem removes also the "plop" - so I removed my cable.... and the "plop" :-)
    Cheers, Bernie_O
  19. Like
    Bernie_O reacted to Fex in Power line hum on Lime2 with mainline kernel   
    I found a workaround!
     
    After looking at some kernel stack traces, I found that this guy was responsible: https://www.kernel.org/doc/html/latest/sound/soc/dapm.html
     
    When the PCM device is closed the following happens in the kernel:
    snd_pcm_release() -> soc_pcm_close() -> delay of `pmdown_time` -> close_delayed_work() The last function powers down the audio subsystem, causing the hum. To circumvent this behavior, I simply set `pmdown_time` to -1:
    echo -1 > /sys/devices/platform/soc@01c00000/1c22c00.codec/cdc/pmdown_time Now, once the sound subsystem is powered on, it stays powered on. Not ideal but it seems to work.
  20. Like
    Bernie_O reacted to AnonymousPi in Thank you heaps for making Armbian!   
    Hi,
     
    Just joined to say thanks to all to those that are involved in the development of Armbian. I recently bought an Orange Pi PC after reading the internet full of people bitching about non-booting devices, HDMI issues, overheating and general crapness.
     
    Decided to buy a Orange Pi PC nonetheless, found an old crap micro SD card, burnt Armbian (the internet has made it clear to not bother with the crap on the official Orange Pi website!) onto it and the thing booted without any issues! Typing this message from it as we speak in Iceweasel!
     
    The thing only cost me 9 quid, so decided to donate what I would have wasted in cash on a Raspberry Pi 3 (which is anything but the 25 dollar SBC it seems to be advertised) as a donation to Igor and co.
     
    I just run the Orange Pi PC out of the plastic static bag it came in LOL!
     
    Once again, great work.
  21. Like
    Bernie_O got a reaction from Igor in Mainline A10/A20 audio driver   
    I found a solution:
    There seems to be a voltage difference between ground on AV jack and actual ground on Banana Pro which is responsible for that noise: http://forum.lemaker.org/forum.php?mod=viewthread&tid=23054&page=1#pid91781
    My device is a Banana Pi, but I suspected that there is a similar voltage difference.
    By connecting a cable from ground pin on AV jack and GPIO-ground (PIN 9) the noise is gone :-)
    Cheers, Bernie_O
  22. Like
    Bernie_O reacted to Igor in Prepare v5.1 & v2016.04   
    - added already mentioned R1 patch for 4.5.x. Zador made a great job, again.
    - upgraded Guitar kernel
    - added / fixed C1. Thanks to Joe for C1 and Armbian mugs! My generic mugs has been replaced 

    - various small bugfixes
  23. Like
    Bernie_O reacted to zador.blood.stained in Mainline A10/A20 audio driver   
    It should work on kernel 4.4 with this patch (which is planned for 4.5).
  24. Like
    Bernie_O reacted to tkaiser in Marriage between A20 and H3, UPS mode, sunxi-pio utility   
    Let's start with a weird image first:
     

     
    In the plastic box is an Olimex A20-Lime2, a 2.5" HDD with 2TB and Olimex' largest battery with 6600mAh. Mounted on the top cover (box standing on the side) is a Banana Pi M2+ (to be replaced with NanoPi M1 or OPi One/PC in the future)
     
    Why Lime2? Since this board from our friends at Olimex is designed intelligently and provides DC-DC step-up converters on the board providing the ability to power also the connected SATA disk when running from battery (unlike most other A10/A20 boards that do only provide 5V on USB ports in battery mode but not to the disk!). And since A20 is perfectly supported by mainline kernel (I run 4.6.4 on it with btrfs on both SD card and connected SATA disk. Since the Lime2 is used as monitoring/rsyslog host btrfs compression is active and the 2TB HDD might store up to 20TB of raw log/monitoring data)
     
    Why BPi M2+? Since board was lying around and I have no other use for it (SinoVoip sent me a review sample a while ago). The idea to combine A20 with a H3 device was simply to add a camera capable and performant device that is ultra cheap (does not apply to BPi M2+ but to NanoPi M1 or OPi One for example). The H3 device will be used to off-load some stuff (eg. OpenVPN encryption), to capture images and do other hardware monitoring (eg. checking temperature in server racks using 1-Wire sensors)
     
    Both boards in this mode run up to 8 hours on battery (6h when the 2 TB disk is also always spinning -- but I use a large 64GB Samsung EVO in the Lime2 and wake up the HDD only from time to time to move data over from SD card). And in this special mode the Lime2 is acting as UPS for the H3 board too since BPi M2+ is powered through Micro USB from Lime2's left USB type A receptacle. The same USB connection is also used as a 'private' network utilizing Ethernet gadget driver on the H3 device.
     
    BPi M2+ is running our sun8i legacy kernel, g_ether module is active and configuration using a link local address as outlined in this thread. Therefore as soon as BPi M2+ boots and brings up his usb0 interface the board appears as Ethernet USB dongle on the Lime2 and can be used easily with the following settings as directly connected network device (providing ~120 Mbits/sec throughput over the USB cable):
     
     
     
    This USB connection can now be used as a directly wired network connection (BPI M2+ is 169.254.2.1 and Lime2 169.254.2.2 and both can interact through this connection or use it as 'heartbeat' connection to monitor network outages). And using BPi M2+ or NanoPi M1 or NEO the very same USB connection can also be used to power the H3 device (not with Oranges there a hardware mod is needed).
     
    Now the fun part: In case the USB powered H3 device freezes or is shut down and has to be restarted... how to do so? Some/most A10/A20 boards provide the 5V on their USB ports not directly from DC-IN but through their AXP209 PMU. And if the board is designed that way, power can be switched on/off on request. This is where the sunxi-pio tool gets interesting since with this tool you can query and switch pin state.
     
    In the above example BPi M2+ is powered through Lime2's left USB port. VDD_USB of this port can be controlled through PH06 pin. So to cut power from Lime2 to BPi M2+ all I have to do is
    sunxi-pio -m PH06'<default><default<default><0>' And to provide power again, it's the opposite:
    sunxi-pio -m PH06'<default><default<default><1>' (at least on my Lime2 the left USB port is more reliable than the right port that can be controlled through PH03 pin). To be able to use the sunxi-pio tool you need a recent sunxi-tools version. As Armbian user you don't have to care since we ship always the most recent version.
     
    Not all A10/A20 boards support this and pin mappings differ between different boards. So where to look? In the fex files (don't trust them blindly, some vendors horribly suck providing documentation for their own hardware, compare the pin mappings in bananapiprolcd7.fex and bananapipro.fex for example).
     
    EDIT: Checked with both Banana Pi and Banana Pro: The USB voltage pin mappings in the fex files are plain BS and do not work (obviously 'copy&paste gone wrong' when they copied all of CubieTech's work in the beginning)
     
    I let a script check the fex files of all Allwinner boards we currently support. Two H3 devices show the ability to switch USB voltage (OPi 2 and Plus/Plus2 -- the pin here most probably controls power for the internal Terminus USB hub) but all the others are A10/A20 based:
     
     
    Edit: But at least on H3 Orange Pi boards it's possible to toggle power available on Micro USB port from userspace.
     
    So if you want to switch power on the USB ports of a Banana Pro you would not use PH03/PH06 but PH00/PH01 instead (and yes, sunxi-pio works with exactly these settings/syntax even when the board runs vanilla/mainline kernel). Since we're talking about A20 Bananas now: These devices do not provide power to a connected SATA disk when running on battery unlike Olimex' boards. So in case you want to ensure that a connected SATA disk keeps spinning when DC-IN is not available then you have to DIY a cable solution taking power from the 2 USB ports and feeding SATA power this way (the SATA power connector on Banana boards is directly wired to the Micro USB DC-IN jack so you can both provide DC-IN here more reliably and have to keep in mind that battery/AXP209 is not involved at all)
     
    BTW: sunxi-pio can be used for more than just switching power on USB ports. Simply call it without arguments to get the idea / help text. Anyone trying to decrease consumption of his Allwinner board might love this tool since you're able to switch off on-board consumers from user space.
  25. Like
    Bernie_O reacted to tkaiser in Marriage between A20 and H3, UPS mode, sunxi-pio utility   
    Yesterday I showed in the first post above how on some AXP209 equipped boards like Lime2 the 5V provided through the USB host ports can be switched on/off using the sunxi-pio utility. So if we use a battery equipped A10/A20 board we can use this also to power other consumers through the USB ports, can switch them off and on and provide an 'uninterruptable power supply' (UPS) mode.
     
    The same way we can also cut power to on-board components that are controlled through AXP209, for example a connected SATA disk. The following graph shows Lime2 powered through USB OTG (to get the 'big picture' regarding consumption -- see the post before for reasons when to choose which powering mode). On the left the 2TB Samsung is in 'active/idle' state (spinning but doing nothing -- ~480 mA consumption), then my power management settings in /etc/rc.local let the disk switch to 'standby' mode after 5 minutes of inactivity (340 mA) and then I switched off power to the disk completely using sunxi-pio (230 mA):
     

     
    How to know which pin has to be toggled? I just looked into the fex file again:
    sata_power_en = port:PC03<1><default><default><0> So by using the following we can physically power off the disk after unmounting the filesystems of course (not available as device later until we power it on with sunxi-pio again or reboot the board):
    sunxi-pio -m PC03'<default><default<default><0>' # off sunxi-pio -m PC03'<default><default<default><1>' # on Unfortunately from all our AXP209 equipped boards only a few support powering the disk through AXP209:
     
     
     
    But what about other onboard components that might not be used but are by default in 'powered on' state and add to the board's consumption while not needed. Let's search for the magical word '_power' inside the fex files:
     
     
    Would be interesting to play around with LCD and CSI power settings and to have a look whether switching those pins off where defined as on by default makes any difference regarding consumption (or for example the GBit Ethernet PHY on some boards when they do not need network connectivity). But this is stuff I leave for others to test and get back to this thread with results.
     
    Since we're talking about disks. These are the two lines I add to /etc/rc.local to spin-down Samsung/Seagate SATA disks on A20 boards after 5 minutes of inactivity:
    hdparm -B 254 /dev/sda hdparm -S 60 /dev/sda And to manually send SATA disks to sleep 'hdparm -Y /dev/sdX' can be used. Please keep in mind that this is SATA stuff and not every USB-to-SATA bridge contained in USB disk enclosures supports this. Also some disks ignore sleep and power management settings and then scripted approaches like hdd-spindown.sh are needed (as we can see above physically powering off a disk leads to further energy savings but without switching power on the disk won't come back when needed -- unlike sleeping since then the disk's controller simply wakes it up when a new disk access happens)