Jump to content


  • Posts

  • Joined

Posts posted by tkaiser

  1. 13 hours ago, jsfrederick said:

    Are the eMMC modules more reliable and less prone to corruption that USB Flash Drives?


    Depends. IMO the vast majority of problems with suddenly dying flash media (SD cards or USB pendrives) is related to fraud flash: flash memory products that fake their capacity so all of a sudden they stop working once the total amount of data written to exceeds the drive's real capacity (see here for a tool to check for this).


    If you manage to buy genuine flash products (not the brands matter but where you buy -- with eBay, Aliexpress & Co. chances to get fake flash are most probably well above 50%) then there are still huge differences. Pine's cheap FORESEE eMMC modules with low capacity are way slower than the Samsung or SanDisk (Pine and other SBC vendors use for their higher capacity modules). But no idea about reliability since AFAIK all you can do here is to trust and believe since without extensive testing it's impossible to predict longevity of SD cards, eMMC and USB flash storage.


    My personal take on this is

    • trying to minimize writes to flash storage ('Write Amplifcation' matters here, keeping stuff like logs in RAM and only write them once per hour and so on)
    • When using low-end flash storage preferring media that supports TRIM (that's SD cards and most probably also eMMC supporting ERASE CMD38 -- you can then TRIM them manually from time to time and maybe we get filesystem drivers in Linux that will support TRIM on (e)MMC too in the future)
    • Weighing eMMC with A1 rated SD cards
    • If huge amounts of important data need to be written to the media then always using SSDs that can be queried with SMART. The better ones provide a SMART attribute that indicates how much the storage is already worn out

    Some more info:

  2. 10 hours ago, sfx2000 said:

    the zram.sh script is something that's been tuned for quite some time and experience across multiple archs/distros...


    Huh? This script is not 'tuned' whatsoever. It basically sets up some zram devices in an outdated way (since recent kernels do not need one zram device per CPU core, this could have even negative effects on big.LITTLE designs and that's why we made all of this configurable in Armbian via /etc/default/armbian-zram-config).


    vm.swappiness... the 'default' is from 100 years ago when we had neither fast flash storage nor compressed zram block devices. Back then swapping happened on spinning rust! With zram any value lower than 100 makes no sense at all.

  3. 15 hours ago, chwe said:

    But as an other example, pinebook is marked as 'supported'. 3.10 got EOL a year ago (and was likely never fully reviewed too) and mainline has (as far as I know) issues with the PMIC (which will be important for a 'notebook') and only marked as beta. By those standards Pinebook should go back to wip or CSC


    Sorry, I don't find the time to answer to all of this stuff in detail.


    My opinion on Pinebook and A64 in general: EOS for more than one reason. Also you seem to miss that I used A64 legacy kernel as an example where one developer at least took the time to rebase the vendor BSP mess on top of an outdated mainline kernel version so at least it was possible to get an idea what Allwinner changed where. A64 devices are toys, the majority of users who play with them doesn't care about security anyway.


    Same could be said about H3 and I really wonder why you don't get how things changed over time. At the end of 2015 Armbian supported just a few boards, H3 devices looked somewhat promising based on features and costs. Back then we took another Allwinner BSP and simply added the missing 3.4.x patches on top (and at the same time few of us already started to use H3 with mainline kernel). To be clear: THIS WAS A MISTAKE (as could be seen just a few months later --> rootmydevice). Why should we repeat mistakes? Since we're totally stupid? Or just too dumb to learn from mistakes?


    15 hours ago, chwe said:

    in this case we had to drop a bunch of 'suggested' images from the download page (e.g. RK3399, RK3328 Rock64/Renegade, A64 Pine64 et al, )


    Seriously? Are you able to spot the difference between Rockchip's 4.4 BSP kernel that is based on a clean Linux mainline version (see the +609,000 commits) and RealTek's code drop that is now available without any history? The difference between Rockchip as one the few ARM vendors who learned some lessons pretty fast and became open source friendly while there's nothing (especially zero experiences) now with RealTek?


    And you talk about standards and 'double standards'? As in 'now we need to support this new platform since board vendor did what he had to do anyway'. Yeah! Sure, let's add more SoC families to Armbian. That's what is truly needed. More boards, less quality.


    But hey, since this projects suffers from total lack of agreed project goals such useless babbling will happen over and over again. I have no idea why we currently support way too much boards we can handle and why constantly new stuff that requires enormous efforts should be added and why are talking about stuff like this anyway.

  4. 2 hours ago, chwe said:

    I don't think this will ever happen


    Exactly. So no Armbian support for RTD1295 or RTD1296. My last actions around this SoC were pushing BPi folks to stop behaving stupid (switching from "let's wait a bit' blabla to opening sources and hopefully in general moving to an 'release early, release often' cycle) and informing Andreas about the repo. No more interest since the initial efforts are way too high. Let's have another look in 2020.


    On related news, FriendlyELEC confirmed they're working on a 4 port NAS HAT for NanoPi M4 using Marvell 88SE9235 controller :)

  5. 7 minutes ago, guidol said:

    root@npi-neo-core2:~# armbianmonitor -u
    System diagnosis information will now be uploaded to http://ix.io/1n6C


    The card is here:

    ### quick iozone test: 4 1175 2216 8181 8187 8813 186

    That's just 186/4 --> ~45 random write IOPS with 4k blocksize. Seriously way too low for good rootfs performance. The Samsung EVO/EVO+ recommendation isn't valid since 2017 any more. A1 rated cards are the only things to buy.


    What's also interesting: 'Armbian ramlog partition with lz4 compression' turned into lz4hc later. I need to check this again. On the other hand once the kernels are upgraded to 4.18 or above we'll have zstd anyway so most probably not worth the efforts to analyze...



  6. On 9/15/2018 at 6:42 PM, jmandawg said:

    on the renegade page: https://www.armbian.com/renegade/


    It says we can run this cpu at 1.51Ghz


    Sorry, I was confused all the time. We only added the 1.4 GHz OPP back then: https://github.com/armbian/build/commit/a79d5932cf21c1c7221bfa6cd036a3f47e506318


    And even more confusion since Igor added 1.5 GHz later: https://github.com/armbian/build/blob/master/patch/kernel/rockchip64-default/enable-1512mhz-opp.patch


    Does it work now after updating to 5.60?

  7. 15 hours ago, chwe said:
    • patchlevel 119 --> head is at 127 that's okay (or surprisingly high IMO)
    • there's no much of a githistory for this kernel 
    • the dts are refracted hardly..   but overall DT stuff looks quite properly made..  (I didn't saw any License headers in all related dts files)


    Anyone interested in RTD1295/RTD1296 platform would need to do something like this first

    • check out upstream mainline kernel at version 4.9.119
    • import changes from RealTek's kernel above (you then end up with one giant commit like this -- context)
    • Now you can spend some days or weeks to have a look what's different, where security holes exist (remember Allwinner's 'rootmydevice'?) and what's not properly licensed

    If this step is skipped there exists no reason to trust into RealTek's 4.9 at all. Especially if this step is skipped it's impossible to start with Armbian support for RTD1295/RTD1295 devices since it would harm the project repeating mistakes like with Allwinner's H3 BSP kernel again (where something like rootmydevice was only discovered by accident).


    We can't trust Android vendor's BSP kernels since those employees forced to hack driver support into something they're not interested in (the Linux kernel and its concepts) never worked with mechanisms like peer review or code quality control. If those employees would've started to submit patches upstream where all this stuff happens (Linux kernel community) then this would be something entirely different. But RealTek just like Allwinner and the majority of ARM SoC vendors has no interest in properly upstreaming their code so this code can't be trusted.


    If their stuff is not properly licensed this will most likely prevent developing mainline drivers for the affected hardware (but I doubt anyone will do this anyway since so far only Suse's Andreas Färber worked on the platform -- tried to inform him via CNX but no idea whether he's aware that some RealTek kernel sources are now provided).


    Having now sources does not mean everything's fine now. Next step is looking at the mess contained (if anyone wants to spend weeks of his life with something like this).



  8. 17 hours ago, chwe said:

    Just a short one which we can link to in case we need it for debugging end-users board


    Well, if this article is meant to be something for an average Armbian user you should IMO elaborate a bit on what a serial console is and how it's possible over an USB cable. Also not looking at this from the Windows perspective (ignoring +90% of our users?) makes the whole attempt more or less useless. And then I don't understand how you built the list of affected boards (since those the feature has been implemented for are all missing: the inexpensive and headless H2+/H3 boards)

  9. 56 minutes ago, 5kft said:

    I ask because I'm running my H5 boards with my overlays that increase the maximum clock rates to 1.3GHz/1.4GHz, and every time I do an Armbian nightly upgrade and the BSP package is upgraded, I have to re-edit /etc/default/cpufrequtils and remove the MAX_SPEED line (e.g., from the default of 816MHz)


    Honestly: I think you're the only one doing this ;)


    The reasons to specify these settings are as follows:

    • CPUMIN: Some kernels/settings define awfully low cpufreq OPP that result in no further consumption savings but crappy IO performance (e.g. Tinkerboard: the default kernel defines lowest cpufreq as low as 100 MHz which makes zero difference to 600 MHz from a consumption/heat point of view but destroys IO performance with ondemand governor since clockspeeds do not ramp up quickly enough)
    • CPUMAX: Sometimes used to allow users who know what they do to enter experimental area while keeping safe defaults (e.g. allowing Rock64 to clock up to 1.5GHz by patching DT but since we had some reports about instabilities at 1.5 GHz defining CPUMAX still as 1.4GHz -- for an experienced user it's a lot easier to adjust a config file than to deal with overlays on most platforms or playing around with dtc binary)

    I agree that current situation with overwriting /etc/default/cpufrequtils with board support package updates is not ideal. But no idea how to improve situation. My personal workaround is two lines in /etc/rc.local overwriting /etc/default/cpufrequtils contents and reloading the daemon.

  10. 1 minute ago, chwe said:

    then.. I suggest you fix it.. cause the link you shared contains https... :P 


    You don't get it. @Nora Lee edited her post above in the meantime. She posted just http://forum.banana-pi.org/t/banana-pi-bpi-w2-source-code-public-on-github/6802 directly below the http://forum.banana-pi.org/t/banana-pi-bpi-w2-source-code-public-on-github/6802 @Lion Wang already posted (you as moderator might see the edit history).


    So I thought it would be a nice joke to again post http://forum.banana-pi.org/t/banana-pi-bpi-w2-source-code-public-on-github/6802 (which is plain stupid of course since there's no information anyway in that forum post other than a link to the sources) but then decided to switch to https:// since the last time it already worked that great.


    Remember thishttps://github.com/BPI-SINOVOIP/BPI-W2-bsp was a 404 yesterday but an hour ago Bananas delivered. Now they can show their superior performance again and make HTTPS work with their forum so they can again repair a broken link.


    BTW: Armbian is not affected: Accessing http://dl.armbian.com will redirect automagically to https://dl.armbian.com -- apt with HTTP only is not that much of an issue.



  11. 4 minutes ago, martinayotte said:

    It did work for me 2 weeks ago, then I've used nand-sata-install ...


    And you did not use nand-sata-install prior to this? Since then eMMC would've been empty anyway and booting from SD card would be normal behavior even without pressing boot button?

  12. 7 minutes ago, chwe said:
    47 minutes ago, tkaiser said:

    at least for me https doesn't work


    Of course it does NOT work which is a problem since BPi folks distribute all their software solely through their unprotected forum:


    http://www.banana-pi.org/download.html (no HTTPS) --> http://www.banana-pi.org/downloadall.html (no HTTPS) --> http://forum.banana-pi.org/c/Banana-pi-BPI-W2/BPI-W2-image (no HTTPS)


    For any serious or professional use cases it's impossible to continue since a MITM (man-in-the-middle) attacker would download an image from them, open/modify it adding some nice backdoors, then uploading it somewhere on Google Drive, setting up something that looks like a download page and then doing some DNS spoofing. Not very likely but software downloads in general that are not protected by at least HTTPS aren't trustworthy at all. Any potential professional customer like @botfap will immediately turn away when seeing stuff like this.


    This was just another free community service for our beloved Banana folks which of course will result in @Lion Wang talking about some evil individual (me) constantly attacking him. :lol::lol::lol:

  13. 4 hours ago, hjc said:

    u-boot SPL tries loading u-boot from SD card first (reference), so if there's a valid SPL on eMMC, you might still have a chance to boot from SD...


    Doesn't work for me.


    37 minutes ago, martinayotte said:

    Is it not what the "boot" button does by shorting the eMMC-D0 line ?


    Just tested this too and it also does not work. Quoting the wiki:


    Press BOOT key to prevent the board from eMMC booting, making the board enter MASKROM mode


    Well, I need to do my homework first. Set up another SBC for serial console access (don't want to install CH340T drivers on my new MacBook), then check for a working USB-C cable and so on...

  14. 1 hour ago, Malz said:

    I can still boot Armbian from eMMC but can‘t install anything new to eMMC. Are there any advices for fixing the problem?


    Boot priority with Rockchip boards is AFAIK always eMMC first then SD card. So once RK3399 finds a bootloader signature on the eMMC it will boot from there even if a bootable SD card is inserted. If you want to reflash eMMC in this situation you 

    • either need to use Maskrom mode (or how it's called exactly) which requires another host and USB
    • delete the bootloader on the eMMC (can be done from the running system: 'dd if=/dev/null of=/dev/mmcblk1 bs=1M count=64 ; sync')

    I successfully bricked my NanoPC-T4 while developing with nand-sata-install and now have working bootloader on the eMMC that is not able to boot a kernel so I'm locked out and would need to try variants 2) or 3) here: http://wiki.friendlyarm.com/wiki/index.php/NanoPC-T4#Flash_Image_to_eMMC (which is not that easy since my physical x86 machines all run macOS and my Linux boxes are all ARM based -- I might try a VM with USB pass-thru soon)


    I asked @mindee for help but his advice to boot an eflasher image from SD card doesn't work since I have a working bootloader on the eMMC (but an otherwise bricked system).


    Would be great to temporarily disable the eMMC as it can be done on Rock64 and RockPro64 (a jumper allows the eMMC to be grounded or something like that so you can boot with this jumper set from a bootable SD card inserted and if you remove the jumper within 2 seconds after boot you can even access the eMMC afterwards to flash a new image)

  15. 38 minutes ago, MadMax said:

    That was the answer to my question in the first place


    Well, don't think so. You asked another entirely different question:

    5 hours ago, MadMax said:

    I'm interested on the boot time of the Rock64 (eMMC or USB/SSD).


    And... Rock64 will boot way faster than your outdated Banana Pi regardless of the boot media. But as already said: if you're interested in a specific use case IMO you should look also at this use case. Stop watch waiting for login prompt is pretty much irrelevant for 'wireless NAS being ready to serve'


    Check your own armbianmonitor -u output for 'link becomes ready' occurrences then you know how much time it already takes since the kernel has started for the wireless link to come up. I've seen quite some delays with some USB wireless dongles in the past so this is something at least I would take care of.

  16. 51 minutes ago, MadMax said:

    Question was more if eMMC is much faster than a A1 SD and not why mine is so slow


    These are two different questions.

    1. The media makes no difference whatsoever if it's about booting times, even most crappy SD cards perform the same: https://forum.armbian.com/topic/4167-f2fs-revisited/?do=findComment&comment=30835
    2. If you for whatever reasons need short boot times Armbian is not for you. We optimize constantly but never for short boot times but for better operation once the board has finished booting

    If you need short boot times you need to become an expert to learn how to eliminate the various bottlenecks (see https://forum.armbian.com/topic/1089-usbootpi/ for example)



    If you're interested in times relevant for your use case you need to measure the time until the respective service is usable (and not until a login prompt appears somewhere).


  17. 49 minutes ago, MadMax said:

    Also the Banana has the advantage that you can solder a battery to it


    Useless since BPi people 'forgot' to think also about powering a SATA disk when running on battery. You need an Olimex Lime or better Lime2 for this.


    Here is a table of our boards containing also 'armbianmonitor -u' output where you can see average boot times: https://github.com/armbian/testings/blob/master/table.md -- you need to provide 'armbianmonitor -u' output too of course if you want other opinions on why your booting takes too long.

  18. 3 hours ago, Lion Wang said:

    code have update to github


    https://github.com/BPI-SINOVOIP/BPI-W2-bsp --> (not so) surprisingly a 404!


    Ok, we all knew already that you don't understand what 'open source' and GPL mean. The GPL requires you to provide access to sources and not screenshots.


    If we can trust your screenshot you put something 17 days ago on Github (1 contributor, 21 commits, the last commits all BLOBs -- that's not that promising as usual, maybe u-boot-rt and linux-rt directories contain only BLOBs and no sources?). So if you would want to stop violating the GPL you now have two options:

    • In case there are really sources available in this Github repo --> open the repo for everyone
    • In case there are no sources or you feel bound to an NDA stop providing binary images like the 'Ubuntu 18.04' pushed yesterday

    It's really that simple if you want to be GPL compliant. Hope it helps!

  19. 1 hour ago, el_pablo said:

    Knowing that Microchip is very reliable


    Is that the same company responsible for the new RPi 3 B+ not even able to do a fallback to Fast Ethernet with older or broken network cables unlike every other GbE NIC out there?


    'Sadly, as far as we know, the LAN7800 chip doesn't support a fallback mode to 100Mbit/s should the extra pairs not be available. There is still an open enquiry with Microchip over this. If you are missing the pairs then the link will simply not come up.'

  • Create New...