Jump to content

tkaiser

Members
  • Posts

    5462
  • Joined

Everything posted by tkaiser

  1. Igor's stuff is on github and he applied some tweaks: https://github.com/igorpecovnik/lib/commits/next/config/cubietruck.fex
  2. 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 :-)
  3. 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-controller; #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.
  4. 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 CONFIG_CPUFREQ_DT=y # CONFIG_ARM_KIRKWOOD_CPUFREQ is not set CONFIG_QORIQ_CPUFREQ=m 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
  5. 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 /sys/devices/system/cpu/cpu0/cpufreq/ 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? Thx, Thomas [1] Cubietruck_defconfig: CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPH(12),USB_EHCI" CONFIG_FDTFILE="sun7i-a20-cubietruck.dtb" CONFIG_GMAC_TX_DELAY=1 CONFIG_VIDEO_VGA=y CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_MACH_SUN7I=y CONFIG_DRAM_CLK=432 CONFIG_DRAM_ZQ=127 CONFIG_DRAM_EMR1=4
  6. 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.
  7. 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 with if [ "/path/to/my/config" -nt "$SRC/lib/config/$LINUXCONFIG.config" ]; then cp -p "/path/to/my/config" "$DEST/$LINUXSOURCE/.config" else cp -p "$SRC/lib/config/$LINUXCONFIG.config" "$DEST/$LINUXSOURCE/.config" fi
  8. Thx, now I power one R1 this way. Works like a charm. I added description/picture to the sunxi wiki: http://linux-sunxi.org/Lamobo_R1
  9. It's a 'JST XH 0.1"/2.5mm' connector, just uploaded a picture of my R1 powered this way to http://linux-sunxi.org/Lamobo_R1
  10. 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)
  11. 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.
  12. 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: /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20-supplyer.28/power_supply/ac/current_now /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20-supplyer.28/power_supply/ac/voltage_now If you're using the battery connector you can have a look below /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20-supplyer.28/power_supply/battery/ 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 /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20-supplyer.28/power_supply/battery/voltage_now but just confirmed it's 5.1V present at the battery connector using a multimeter.
  13. Don't know whether that helps but I just did a search for 'spi device tree a20' and ended up here: https://www.olimex.com/forum/index.php?topic=3687.0
  14. 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 960000 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 1008000 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 1008000 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 1056000 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
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. You can safely ignore that since script.bin will not be used when using mainline kernel any more.
  20. 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)
  21. 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.
  22. 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)
  23. Just to be sure: The pin closer to the PCB edge is 5V and the inner one GND? Or vice versa? Thx for confirmation that a SATA disk will work when powered this way.
  24. Interesting. A cold/warm/hot boot issue (there seem to be a couple of related issues, eg. memory calibration: http://linux-sunxi.org/A10_DRAM_Controller_Calibration) Maybe the whole problem is related to DRAM (initialisation). IIRC Igor already included the a10-meminfo tool so it would be worth a look to compare dqs gating delay settings in both cases (please compare with http://irclog.whitequark.org/linux-sunxi/2015-04-27)
  25. The kernel version and settings might be the same. But since hardware is different some low level drivers will be different that might also affect this and that. Same applies to board initialisation from within u-boot. But you can switch between different boards by simply exchanging SPL+u-boot+kernel and use an otherwise unmodified image with all the boards. I would think about what you can expect if you're after the cheapest device possible (it's neither stability nor realiability ) I like the Olimex boards (due to being real OSHW) but still experience worse network and overall performance with my Lime2 compared to the original Banana Pi (no need for the Pro -- if I would need onboard Wi-Fi I would give the BPi M1+ a try -- nearly same connector layout and identical hardware but the chips that might overheat at the upper side of the PCB: http://kaiser-edv.de/tmp/Nyiuha/) There's another A20 board that's worth to mention: pcDuino3 Nano. Feature wise comparable to Banana Pi and regarding NAS useage faster than my Lime2: http://forum.lemaker.org/forum.php?mod=redirect&goto=findpost&ptid=12167&pid=66487&fromuid=33332
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines