Jump to content


  • Posts

  • Joined

Posts posted by tkaiser

  1. Made some progress:


    I ended up with this boot.cmd:

    setenv bootargs console=tty1 root=/dev/mmcblk0p2 rootwait rootfstype=f2fs sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1
    # Boot loader script to boot with different boot methods for old and new kernel
    if ext4load mmc 0 0x00000000 /.next
    # sunxi mainline kernel
    ext4load mmc 0 0x49000000 /dtb/${fdtfile} 
    ext4load mmc 0 0x46000000 /zImage
    env set fdt_high ffffffff
    bootz 0x46000000 - 0x49000000
    # sunxi android kernel
    ext4load mmc 0 0x43000000 /boot/script.bin
    ext4load mmc 0 0x48000000 /boot/zImage
    bootz 0x48000000


    And I had to relink the kernel (since pointing to /boot/ does not work when /dev/mmcblk0p1 is / from U-boot's point of view:

    zImage -> vmlinuz-4.1.1-bananapipro

    But now I'm stuck at this point:

    Debian GNU/Linux 7 bananapipro ttyS0
    bananapipro login: root
    You are required to change your password immediately (root enforced)
    Changing password for root.
    (current) UNIX password: 
    Enter new UNIX password: 
    Retype new UNIX password: 
    Authentication token manipulation error
    Debian GNU/Linux 7 bananapipro ttyS0
    bananapipro login: 

    Looks like for whatever reasons / is mounted read-only. 

  2. What to do to switch from ext4 to F2FS (one big caveat: Partition/filesystem resizing doesn't work with F2FS so this is only for you if you know the size of your SD card prior to building the image)? I tried the following so far:

    But the Banana Pro I test with doesn't boot. I would assume that I have to modify boot.cmd (and exchange /boot/ with /)?



  3. I assume, the 600 was meant for data on a flash storage in order to reduce the writes on it!? But in order to keep "things in sync", shouldn't I better reduce it? Or delete the whole commit option?


    Simply remove it. The commit option had bad SD cards in mind that implement only crappy/insufficient forms of wear-leveling. You won't find any SSD today that is affected by that (and the references to commit=600 are copy&paste from aging SSD experiences linux users had 5 or more years ago). Same applies to "noatime" (no real need to supply this parameter since no SSD today will wear out significantly faster if not set). But I would set it since these small writes might come along with high write amplification.


    BTW: recommendations to disable journaling with ext4 since 'the SSD might wear out faster' one can read still here and there -- same outdated stuff / 'urban myths' today.


    In my opinion there's also no need to not rely on discard as long as you have ensured that your SSD implements TRIM correctly -- see here for a recent example where this did not happen: https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/


    Exception: If you use a modern filesystem like btrfs then you shouldn't use discard because btrfs is more of a combined volume manager / filesystem than just the latter and does care for TRIM on it's own (also detects SSDs automagically and adjusts accesses/settings accordingly).


    If you really care about low wear-out on your SSD and want to stick with ext4 then to avoid high write amplification it would be necessary to adjust filesystem boundaries to the SSD's page and erase block sizes (compare with Theodore Ts'o's observations and keep in mind that this isn't that easy with some modern SSDs)


    Regarding SSDs an Armbian with Mainline kernel: I wouldn't rely on ext4 but go with btrfs instead and use the following mount options: "-o compress=lzo,noatime"


    EDIT: Haha, should've answered Blisk instead :-)

  4. Since cpufrequency scaling is working on Banana with the same kernel the problem must be elsewhere. DTB?


    Try boot with altered banana DTB.


    Just made a diff between sun7i-a20-bananapi.dts and sun7i-a20-cubietruck.dts and found only one suspicious looking difference (since all the other stuff seems to be related to differing hardware and pin mappings):

    &i2c0 {
    	pinctrl-names = "default";
    	pinctrl-0 = <&i2c0_pins_a>;
    	status = "okay";
    	axp209: pmic@34 {
    		compatible = "x-powers,axp209";
    		reg = <0x34>;
    		interrupt-parent = <&nmi_intc>;
    		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
    		#interrupt-cells = <1>;

    (only "compatible = "x-powers,axp209";" was missing in cubietruck's .dts but this should be unrelated to cpufreq stuff). I also searched the web but to no avail. I'll give up here for the moment and try to get Armbian into NAND using LiveSuite.

  5. I did an upgrade to 4.1 (using the tar archive Igor supplied a few days ago) but that didn't change anything (expect the funny temperature readouts):


    root@cubietruck:~# uname -a
    Linux cubietruck 4.1.0-bananapi #26 SMP Wed Jun 24 09:25:45 CEST 2015 armv7l GNU/Linux
    root@cubietruck:~# zgrep CPUFREQ /proc/config.gz
    root@cubietruck:~# zgrep CPU_THERMAL /proc/config.gz 
    # CONFIG_CPU_THERMAL is not set

    I still have no /sys/devices/system/cpu/cpu0/cpufreq/ dir. Maybe related to 'CPU_THERMAL'?


    And installing to NAND also doesn't work  :( :

    root@cubietruck:~# /root/nand-sata-install 
    No targets avaliable!

    Hmm... seems a lot of things to consider are waiting on the Cubietruck  :)

  6. Hi,


    I just started to fiddle around with my Cubietruck (since I exchanged it with a Banana Pi for productive stuff). I had to realize that 


    is missing and that cpufreq-info outputs "no or unknown cpufreq driver is active on this CPU" correctly. Anyone else seeing this behaviour? Cpufreq support should be back with 4.0?


    Based on a sysbench run ("sysbench --test=cpu --cpu-max-prime=5000 run --num-threads=2" -- takes 58 seconds) I would suppose it's running not even at 960 MHz (since 960 should finish in less than 54 seconds).


    I did some iperf tests (not that promising, just 600/650 Mbits/sec) and iozone with my usual test SSD (writes below 40MB/s, reads max out at 130MB/s).


    Am I'm right and the u-boot defaults [1] remain unpatched in this image? Does anyone have tested out other CONFIG_GMAC_TX_DELAY values?







    [1] Cubietruck_defconfig:

  7. Please keep in mind that we're talking about cheap ARM SoCs and not x86 CPUs that ran through an extensive/expensive quality ensurance and selection process. What might work with your A20 (operating the beast at 2.0GHz with 0.1V) might break everywhere else. And vice versa.

  8. I have the need to been able to push my own kernel .config into your https://github.com/igorpecovnik/lib in an automated way.


    Why don't you just do it? Search for "# Load libraries" in main.sh and add 

    cat "/path/to/my/config" >"$SRC/config/linux-sunxi-next.config"

    or replace in common.sh

    cp $SRC/lib/config/$LINUXCONFIG.config $DEST/$LINUXSOURCE/.config


    if [ "/path/to/my/config" -nt "$SRC/lib/config/$LINUXCONFIG.config" ]; then
        cp -p "/path/to/my/config" "$DEST/$LINUXSOURCE/.config"
        cp -p "$SRC/lib/config/$LINUXCONFIG.config" "$DEST/$LINUXSOURCE/.config"
  9. Thank you for the explanation. Everytihg is clear now. I will connect secondary power. 

    Don't know if I understand you correctly since the AXP209 PMU can be fed through 3 different sources: pwr-in (unfortunately using a crappy Micro-USB connector on R1), USB-OTG (unfortunately using a crappy Micro-USB connector on R1) and Li-Po battery connector (using a JST XH 2.5mm header on the R1 and not the smaller and more common JST PHR-2 header normally used for connecting Li-Po batteries)


    You can do some experimentation with different power sources available in parallel and see how the AXP209 PMU behaves. But I would rely on a single power source. And that means either soldering and still using pwr-in (see two examples in this thread) or relying on the Li-Po connector (only downside: you have to press the power button to boot the board)

  10. First have a look at https://github.com/igorpecovnik/lib/tree/next/patch/


    Igor adapts changes/fixes really fast and the same applies to feedback from users regarding functionality. So you can expect Armbian always to be some time ahead (for example Lamobo R1 and Orange Pi aren't added to mainline kernel or Debian yet but work out of the box with his build system). Simply try it out, get 2 quality SD cards and switch.


    The good news: Since Igor's build system creates kernel and even u-boot as .deb packages you might be able to use patched/fixed versions of this stuff from Armbian with a normal Debian installation (given the partition layout matches otherwise your board might not boot afterwards).


    If your focus is on _using_ the board then I would choose Armbian, if you're trying to _learn_ a lot then use standard Debian Jessie (still not recommended -- better stay with wheezy IMO). And dont't forget to donate if you're using Armbian.  :)


    Regarding the board: If you don't need Wi-Fi why not giving the original Banana Pi a try? Based on my testings it's the fastest board around regarding GMAC: http://linux-sunxi.org/Ethernet#GMAC


    Other A20 based boards that use GMAC (and therefore both SATA and GBit Ethernet) are: A20-OLinuXino-Lime2, Banana Pi M1+, Cubietruck, Hummingbird A20, Lamobo R1, Orange Pi, Orange Pi Mini or pcDuino3 Nano.

  11. I have 3000mA power supply, it should be enough.


    As Igor already pointed out: If you feed the R1 via the standard power-in Micro USB then you won't be able to inject more than 5V/1.8A since this crappy connector isn't made for more (too tiny contacts). The original manufacturer lists 5V/2.7A as minimum requirements but when using an Micro-USB connector this is simply a bad joke.


    An alternative is to use the battery connector. When you're using Kernel 3.4 then it is highly recommended to have a look what's happening in reality (an external power meter tells you a different story than the AXP209 PMU might tell you that reports what's really available to and used by the board):


    You can query the PMU using I2C/sysfs. When using the Micro-USB-power-in connector (and kernel 3.4) you get both amperage currently used as well as voltage available to the R1 by querying these:


    If you're using the battery connector you can have a look below


    Unfortunately when you power the board using the Battery connector only the current used by the board can be read out but not voltage:

    awk '{printf ("%0.2f",$1/1000000); }' </devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20-supplyer.28/power_supply/battery/current_now

    will print out the amperage used in A. 'voltage_now' is in this special mode without meaning: I get 134000 when querying


    but just confirmed it's 5.1V present at the battery connector using a multimeter.


    Mainline, currently (4.0.5) we have:

     available frequency steps: 144 MHz, 312 MHz, 528 MHz, 720 MHz, 864 MHz, 912 MHz, 960 MHz


    Yes, but I meant the increment in 48MHz steps. So I just tried it out myself (with kernel 4.0.4 and ready to overclock up to 1.2 GHz):

    root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 
    144000 312000 528000 720000 864000 912000 960000 1008000 1056000 1104000 1152000 1200000 
    root@bananapi:/# echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    root@bananapi:/# echo 1000000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 
    root@bananapi:/# echo 1008000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 
    root@bananapi:/# echo 1009000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 
    root@bananapi:/# echo 1056000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 

    Same behaviour as with kernel 3.4. So the operating points available in kernel 4.0 or above are the equivalent to the former dvfs_table entries. They define a relationship between core voltage and clock speed but the actual cpufreq settings are still only possible in steps of 48 MHz. But what's different: Starting with kernel 4.0 thermal throttling is implemented on sun7i (A10/A20). If the temperature that will be read out from the thermal sensor inside the A20's touchpad controller exceeds defined values then the cpufreq driver will start to throttle. The temperature can be read out using the following code starting with 4.0:

    awk '{printf ("%0.1f",$1/1000); }' </sys/devices/virtual/thermal/thermal_zone0/temp
  13. In Bananian with kernel 3,4 (that means "NOT from Igor") I could change freq as I wanted and I did not respected 48MHz steps and it worked.


    Please check youself. If you write 1100000 in scaling_max_freq and put some load on the board you will end up with 1056000 scaling_cur_freq (1056 MHz). Because the code only accepts increments of 48000 (for reasons unknown to me). Maybe the same applies to mainline kernel. But there the cpufreq code jumps between the different operating points defined in the .dtsi file.


    Regarding "don't do this at home". I tend to write some warnings/disclaimers to this stuff since in my normal job I've to deal with large scale data corruption from time to time. And since other people that might come across this thread then think 'overclocking' is safe and risk their data I just want to point this out again and again.


    One of the main 'problems' compared to x86 is that the SoCs we're talking about are so cheap that they won't be subject to an extensive QA or selection process prior to being sold. Settings that might work on your board will lead to silent data corruption on another board (applies to both undervoltage and overclocking scenarios). And since people also try to play RAID with crappy SATA port multipliers connected to their A20 based SBCs and store valuable data on it (and also confuse RAID with backup) some warnings are necessary  :)


    Regarding voltages and DRAM clock: In the first days of Cubietruck developers decided to set some entries in the dvfs_table based on experiences with their boards. In the meantime it became clear that for the majority of boards these settings led to undervoltage situations. Same regarding DRAM clock. LeMaker started with 480 MHz for the Banana Pi. And while that worked for their first batch of SBCs without errors later/different batches of boards differed so they decided to lower the DRAM clock speed to 432 MHz which should be considered a sane default.

  14. Do I understand correctly that with this I can manualy set voltage in 3.4 kernels


    For older kernels/u-boot you set the available cpu frequency/voltage settings in script.bin, prior to 4.0 there was no way to set it in mainline and starting with 4.0 you can modify arch/arm/boot/dts/sun7i-a20.dtsi to add additional operating points (if you understand what you're doing).


    The 48 MHz cpufreq steps are a software thing to deal with the values you provide via sysfs (eg. settings /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq), This applies to 3.4 and maybe to mainline as well (just give it a try, use ondemand, modify scaling_max_freq, create some load and check scaling_cur_freq)


    Do NOT adjust DRAM clocks unless you really understand what you're doing and don't even think about overclocking unless you really understand what performance implications cpufreq settings have for your specifig use case. In case you want to do number crunching then an ARM SBC is simply the wrong choice. So if you're after performance you chose the wrong hardware platform. For other use cases related cpufreq settings might do the difference and there's no need to overclock anything if these settings are adjusted appropriately (see for example NAS/fileserver stuff: http://forum.lemaker.org/forum.php?mod=viewthread&tid=15543)


    BTW: Increasing voltages leads to a reduced lifespan of your device. Unfortunately I don't find the link any more but I read a developer discussion where they talked about slightly increasing the core voltages might lead to the SoC dying twice as fast.

  15. Sorry, but both dd as well as hdparm aren't benchmark tools. They're abused in this way but the results are simply crap.


    When you use dd with filesizes too small and without the appropriate flags ('direct' parameter) it always tests partially caches/buffers and sequential throughput seems to be higher than it is in reality. Same applies to 'hdparm -tT'. One parameter just shows RAM throughput and when used together with the other parameter a so called 'correction factor' will be applied to the results shown. In other words: The results given do NOT show what the disk in question is able to deliver.


    And both pseudo benchmarks only test sequential throughput. Use bonnie++ or iozone (and use always at least twice as much as RAM available for test filesizes) to get a clue how the SD card or disk in question really performs. And both tools are able to show the performance of random I/O with different block/sector sizes.

  16. May I ask you, because your many experience in testing, if it makes really/"auf jdem fall" sense (why? CPU/GMAC/acces time to SATA) to have rootfs in SATA and not in MicroSD UHS-1 (classs 10) in a banana Pi Pro? Basically should run Seafile Server/SAMBA and on the background typical LEMP Stack.


    All A20 based boards seem to be limited to approx. 16,x MB/s when reading/writing sequentially from/to SD card. What really makes a difference when you're frequently accessing files on the SD card will be random I/O. And there some SD cards outperforman others easily and sequential writes (or class xy) do not count any more.


    In my eyes it depends whether you use an SSD or a HDD on the SATA port. In case it's a spinning disk there might be many situations where it's better to keep the rootfs on SD card (and using Wheezy and Igor's ramlog configuration to minimize writes to SD card) to let the HDD spin down when idle after longer periods. When you're using an SSD IMO it's a no-brainer to move the rootfs to SSD.


    On my TODO list are experiments with F2FS on SD card (only possible using a different partition scheme than the one Igor's using now since u-boot can not directly read from F2FS at the moment). That might both decrease wear-out of the SD card and increase (random) performance. But I won't have the time to test this the next weeks/months. But if I'm done I'll report back.

  17. Just as a small addendum: Many things one might attribute to "new kernel" are just side effects of different settings.


    Given the hardware implementation of the GMAC ethernet (everything has to be done by the CPU) clock speeds and cpufreq settings matter. So you should check what you had when running Igor's image with kernel 3.4 (I would assume interactive governor and max. 912 MHz?) and what you've now.


    If you didn't change anything then kernel 4.0.x with the new cpufreq stuff comes with these defaults:

    /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor = ondemand
    /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq = 960000
    /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq = 144000
    /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy = 0
    /sys/devices/system/cpu/cpufreq/ondemand/up_threshold = 95
    /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor = 1

    And while this might be nice on a tablet or on a machine that's mostly idling around it leads to bad throughput especially when it comes down to NAS useage. By tweaking mostly these settings as well as TCP/IP and CPU affinity settings you can double throughput in one direction and let it max out in the other: http://forum.lemaker.org/forum.php?mod=viewthread&tid=15543&fromuid=33332


    Which results do you get when you try it with the following settings?

    echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    echo 960000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    echo 528000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy
    echo 25 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
    echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
    sysctl -w net/core/rmem_max=8738000
    sysctl -w net/core/wmem_max=6553600
    sysctl -w net/ipv4/tcp_rmem="8192 873800 8738000"
    sysctl -w net/ipv4/tcp_wmem="4096 655360 6553600"
    sysctl -w vm/min_free_kbytes=65536
    sysctl -w net.ipv4.tcp_window_scaling=1
    sysctl -w net.ipv4.tcp_timestamps=1
    sysctl -w net.ipv4.tcp_sack=1
    sysctl -w net.ipv4.tcp_no_metrics_save=1

    BTW: Solely relying on iperf is wrong judging from my experiences. Real-world performance might differ. So I always double-check with a combined benchmark that checks a couple of different things including disk access (unfortunetaly we have a SATA write limitation where network throughput is faster in this direction and vice versa. When writing from client to Banana Pi disk I/O is the bottleneck and in the other direction it's network when using a SATA disk)

  18. The performance measurement you have done shows that Banana Pi and pcDuino3 Nano are comparable, right?


    Nope, Banana Pi was always better. But for the next test runs I will wait for kernel 4.1 when pcDuino3 Nano will be officially supported in mainline kernel. I will contact Igor before I modify his scripts to support the board and maybe he'll accept my patches and includes them (without having the hardware and being able to verify himself). We'll see. 

  19. BTW: For whatever reasons the Banana Pi is still the fastest A20 based board I own regarding NAS useage (I compared myself Banana Pi, Olimex Lime2, pcDuino3 Nano and Lamobo R1 -- the so called 'Banana Pi Router Board' -- the Cubietruck I also own wasn't included in tests since it's productive all the time).


    Regarding SATA performance all the boards perform nearly identical. But something's different regarding Ethernet (on the Lamobo R1 it's clearly a different situation since there the PHY is not a RTL8211 but the BCM53125 switch IC). Must be something related to timings and maybe crosstalk between different ICs/traces on the PCB.


    I'll give it again a try with Kernel 4.1 (since pcDuino3 Nano will then be supported officially by mainline) and report back. In the meantime I collected some first results regarding cpufreq/overclocking with 4.0.x, made some tests regarding whether it's worth or not when you want to use the device as NAS server and collected some informations regarding 'factory defaults' vs. optimised settings (applies to default cpufreq as well as network and scheduler settings): http://forum.lemaker.org/forum.php?mod=viewthread&tid=15543&fromuid=33332


    (will be one of my last lengthy and tutorial-like posts there since I currently only use Armbian any more and maybe Igor provides a section 'tutorials/how-to' here or github is the place to write -- we will see)

  • Create New...