tkaiser

  • Posts

    5445
  • Joined

 Content Type 

Forums

Member Map

Store

Crowdfunding

Applications

Everything posted by tkaiser

  1. Maybe a driver is missing? Use the output of 'lsusb' to get device/vendor ID of the used chip and use that to get a clue which driver you need.
  2. Also 480 MHz but I still doubt that this is correct since A10-Lime and A20-Lime are the same regarding PCB layout.
  3. This one initialises DRAM with 480 MHz which according to Olimex (when they released the A20 Lime2 they talked about "much better routing of DDR3 memory" and what's said regarding A20-Lime should apply to the A10-Lime as well) might not work reliable. @Yuri: Can you try to have a look what Olimex sets in the script.bin they use with their own images? Might be 384 MHz instead. BTW: Using A10 together with HW accelerated desktop (or desktop at all) is no good idea: http://linux-sunxi.org/Optimizing_system_performance#Using_a_lower_resolution_graphics_mode
  4. So it seems, GNUTLS development stuff is missing. Did you try to install libcurl4-gnutls-dev already? Or try apt-cache search gnutls | grep dev and install the packages listed one by one.
  5. So you downloaded the wrong image or use the wrong board? If you really want Jessie on the Banana Pi then use eg. this: http://mirror.igorpecovnik.com/Bananapi_Debian_3.2_jessie_4.1.2.zip
  6. This is part LT-1318 from https://www.led-tech.de/de/High-Power-Zubehoer/Kuehlkoerper-c_106_114.html
  7. Just FYI: By simply exchanging U-Boot and the board's .dtb file Armbian is able to run on a Banana Pi M2 which is based on the A31s SoC: http://www.bananapi.com/index.php/forum/general-discussion-for-bpi-m2/995-working-wifi-on-modern-kernels-4-1-tested?start=6 (comprehensive instructions for Arch Linux on the M2 available there)
  8. Again: Use a good heatsink, use thermal paste and most importantly: Let convection do the work. I have a cheap port multiplier here that automatically starts to corrupt data under load due to overheating: After I attached a heatsink and operated the thing vertically problems were gone: And the good news is: The way convection works the better it cools parts that get hotter than others.
  9. Given the positions of the other openings I really doubt that a few holes on top are sufficient. If you're using 3.4.x kernel you can at least read out the temperature values of SoC and PMU. Store this code here eg. as /usr/local/bin/gettemp.sh and do a source /usr/local/bin/gettemp.sh pmutemp soctemp afterwards (it might be necessary to become root and soctemp sometimes works only if you called it a couple of times). I found that reading out temperatures in mainline is way more difficult/wrong: With kernel 4.x you can query the SoC's temperature sensor using /sys/devices/virtual/thermal/thermal_zone0/temp but the values provided are slightly off in 4.0 and completely messed up in 4.1.x Sysfs/I2C integration for the PMU is gone in mainline and while there exist patches (see the end of this page http://sunxi.montjoie.ovh) it's obvious that the values measured are wrong (this was the same with the SoC's temp patches from the same author with kernel 3.4 -- also wrong values without further adjustment): SoC's temperature +40.6°C and PMU's just 23.5°C --> nearly impossible. When I made some extensive tests half a year ago I realized that the IC's temperature is always at least 10°C above ambient (10°/7°C when using an efficient SMD heatsink) and that it's nearly impossible to create a workload on the CPU cores that leads to the SoC's temp being 17°C exceeding the PMU's.
  10. Always keep in mind that an applied heatsink won't help that much if there's no airflow possible. If you don't have a fan or let convection do the work this might only help in situations where ICs overheat temporarely due to load peaks. But if the chip always heats up then a heatsink won't help since surrounding temperature will increase over time and then no heat dissipation or cooling is possible any more.
  11. Well, in my case I chose the wrong color since the customer now wants to put the device somewhere where it's exposed to sunlight from noon till five. I will include 2 DS18B20 temperature sensors to get a clue how hot it gets inside regardless of internal chip temperatures. The next time I'll build such a device (main part is the 24V PSU in the left and an 8-port Pover over Ethernet injector to provide a couple of Raspberry Pis with network and power) I'll replace the 5V/12 PSU for board and display with 2 step-down converters and use a Banana Pi together with a small 8-port-switch.
  12. It's one of the known problems of this board: http://linux-sunxi.org/Lamobo_R1#Available_enclosures_and_thermal_issues Try to operate it vertically since then convection jumps in
  13. Thx, great job. I hope the URL remains since I will link often to it Regarding the filesystems. In my opinion btrfs is only interesting for disk storage (SATA, USB) and for people who know what they do (creating snapshots, transferring these snapshots incrementally using 'btrfs send/receive' to other disks/machines and so on -- all this has drawbacks, for example getting a clue how much space is really available on the disk in question). So regarding btfrs this is more a candidate for nand-sata-install: Allowing to use btrfs for sda1 and recommending to partition the disk prior to that and to use a separate partition for / and for other/media data (since using snapshots this makes backing up everything way more easy). Regarding F2FS: It should be superiour compared to ext4 when used on NAND/SD Cards or other flash based media. But I'm still not convinced whether it's worth the efforts since the resizing problem remains. Would be great to be able to choose it optionally but I doubt that it's ready for your normal OS images. Regarding cpufreq stuff: This remains the same in mainline: You can adjust the sysfs values as you want but all values will be rounded down in 48 MHz steps. BTW: I will try to add a few additional operating points in arch/arm/boot/dts/sun7i-a20.dtsi to slightly 'overclock' some A20 boards: operating-points = < /* kHz uV */ 1200000 1600000 1152000 1550000 1104000 1500000 1056000 1450000 1008000 1450000 960000 1400000 912000 1400000 864000 1300000 720000 1200000 528000 1100000 312000 1000000 144000 900000 >; I'll report back if I find anything interesting (A20 specs say that 1.4V is max.)
  14. I made a few other tests and noticed that using a very slow SD card the system behaved 'snappier' (at least this was my feeling maybe only driven by 'it has to be more snappy after hours of fiddling around'). But I wasn't able to get the performance gains others reported (eg. Phoronix). Maybe just a matter of methodogloy and more time (but I've enough) Anyway I patched your build system 'statically' and made a diff of the changes: http://pastebin.com/hidkugaG Would be better to make this stuff optional, eg. introducing ROOTFS=ext4|btrfs|f2fs -- but the main problem is that neither f2fs nor btrfs are resizeable and therefore an $SDSIZE value chosen too large will result in an image not able to write to SD card or NAND. So if $ROOTFS isn't set as ext4 the user should be asked for the size of his SD card (2, 4, 8, 16, ...) and then $SDSIZE should be set appropriately. Anyway. You/we have to fix the build system since setting $BOOTSIZE greater than 0 currently fails (wrong entries in boot.cmd/boot.scr, wrong symlink creation in patch/packaging-next.patch, wrong fstab contents). And since you're using mainline u-boot I would suggest switching from VFAT to ext4 in deboostrap.sh (line 66). BTW: In configuration.sh $CPUMAX should be set to "1080000" otherwise a fallback to 960MHz will happen (or maybe this is intended since with mainline 960000 is the maximum without patching arch/arm/boot/dts/sun7i-a20.dtsi?)
  15. And now with cpufreq settings changed to "performance" (the cpufreq defaults starting with kernel 4.0 are somewhat problematic if you're after storage performance since defaults means: ondemand without io_is_busy) f2fs with performance cpufreq governor on the same fast SanDisk "Extreme Pro" TF card: Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP bananapipro 2G 117 99 18831 12 9967 8 675 100 28788 9 2037 75 Latency 70771us 29371us 5436ms 14823us 38940us 20005us Version 1.96 ------Sequential Create------ --------Random Create-------- bananapipro -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 2446 31 +++++ +++ 12839 87 2762 37 +++++ +++ 6759 82 Latency 782us 847us 3372us 753us 85us 2021us
  16. Some results (tested using "bonnie++ -u nobody" on a Banana Pro with kernel 4.1.1 and default settings): ext4 on slow Intenso TF card: Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP bananapipro 2G 93 95 9875 19 6020 12 650 99 19163 13 38.5 3 Latency 236ms 27892us 6445ms 49584us 134ms 29474us Version 1.96 ------Sequential Create------ --------Random Create-------- bananapipro -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 2059 20 +++++ +++ 932 10 1661 16 +++++ +++ 605 10 Latency 1632ms 10146us 4828ms 5130ms 10087us 5125ms ext4 on fast SanDisk "Extreme Pro" TF card: Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP bananapipro 2G 96 99 21209 15 10929 8 675 99 28457 8 1737 63 Latency 92653us 18445us 2968ms 15123us 25312us 11677us Version 1.96 ------Sequential Create------ --------Random Create-------- bananapipro -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 6862 60 +++++ +++ 2151 14 5815 49 +++++ +++ 1545 10 Latency 137ms 2480us 1429ms 670ms 97us 1671ms f2fs on the same fast SanDisk "Extreme Pro" TF card: Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP bananapipro 2G 116 99 20736 22 10241 18 664 99 27806 20 2012 147 Latency 196ms 5023ms 4332ms 41126us 119ms 36883us Version 1.96 ------Sequential Create------ --------Random Create-------- bananapipro -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 2446 35 +++++ +++ 12308 87 2778 38 +++++ +++ 6677 83 Latency 13341us 1319us 9974us 10020us 154us 10824us
  17. I removed 'errors=remount-ro' from fstab that now looks like: /dev/mmcblk0p2 / f2fs defaults,noatime,nodiratime 0 0 /dev/mmcblk0p1 /boot ext4 defaults,noatime,nodiratime 0 0 And now I'm in: root@bananapipro:/bonnie# cat /etc/mtab /dev/root / f2fs rw,noatime,nodiratime,background_gc=off,nouser_xattr,noacl,noinline_data,active_logs=6 0 0 devtmpfs /dev devtmpfs rw,relatime,size=514128k,nr_inodes=128532,mode=755 0 0 tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=131072k,mode=755 0 0 tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 tmpfs /run/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=131072k 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 /dev/mmcblk0p1 /boot ext4 rw,noatime,nodiratime,data=ordered 0 0 tmpfs /tmp tmpfs rw,nosuid,nodev,relatime,size=1048576k 0 0
  18. 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 then # sunxi mainline kernel #-------------------------------------------------------------------------------------------------------------------------------- ext4load mmc 0 0x49000000 /dtb/${fdtfile} ext4load mmc 0 0x46000000 /zImage env set fdt_high ffffffff bootz 0x46000000 - 0x49000000 #-------------------------------------------------------------------------------------------------------------------------------- else # sunxi android kernel #-------------------------------------------------------------------------------------------------------------------------------- ext4load mmc 0 0x43000000 /boot/script.bin ext4load mmc 0 0x48000000 /boot/zImage bootz 0x48000000 #-------------------------------------------------------------------------------------------------------------------------------- fi 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 Password: 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.
  19. 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: apt-get install f2fs-tools define size of f2fs partition in compile.sh (eg. for a 4 GB SD card use »SDSIZE="3600"«) adjust »BOOTSIZE=16« in lib/configuration.sh (line 26) replace »mkfs.vfat -n "$IMAGEVOLUME"« with »mkfs.ext4 -q« in lib/deboostrap.sh (line 66) replace »mkfs.ext4 -q« with »mkfs.f2fs« in lib/deboostrap.sh (line 67) add »-tf2fs« to mount option in lib/deboostrap.sh (line 68) comment »shrinking_raw_image "$DEST/output/$VERSION.raw"« out in lib/common.sh (line 463) change fstab entry to »echo "/dev/mmcblk0p2 / f2fs defaults,noatime,nodiratime,errors=remount-ro 0 0" >> $DEST/output/sdcard/etc/fstab« in lib/distributions.sh (line 105) comment »install -m 755 $SRC/lib/scripts/resize2fs $DEST/output/rootfs/$CHOOSEN_ROOTFS/etc/init.d« out in lib/distributions.sh (line 138) avoid partition resizing on first run by removing lines 89-101 in lib/scripts/firstrun But the Banana Pro I test with doesn't boot. I would assume that I have to modify boot.cmd (and exchange /boot/ with /)? Thx
  20. Update: Still missing with Cubietruck_Debian_4.0_wheezy_4.1.1 -- I will try out replacing .dtb files later this weekend.
  21. Igor's stuff is on github and he applied some tweaks: https://github.com/igorpecovnik/lib/commits/next/config/cubietruck.fex
  22. 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 :-)
  23. 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.
  24. 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
  25. 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