tkaiser

FYI: https://groups.google.com/forum/#!topic/linux-sunxi/ld7lem8QTv0

Nope, didn't even tried it due to focus on other problems (strange network performance stuff I'm currently after).

I read it like 'powering the board using the Micro-USB-pwr-in connector and using a LiPo battery as UPS'. And the question is whether the board will supply power to a SATA disk when running on battery (UPS mode). This is somewhat different to the mode we power the board (providing more than 4.2V on the LiPo connector therefore forcing the AXP209 into 'non battery' mode). And according to 'multi' then the disk won't work: http://www.bananapi.com/index.php/forum/general/391-why-the-sata-disk-doesnt-work-on-bpi-r1?start=24#1817

Put this in /etc/rc.local prior to the last line "exit 0"

Depends on what you want. I would have a look at http://www.i4wifi.eu/MikroTik-RouterBoards-1/and http://www.pcengines.ch/apu.htm If it's just about routing and maybe Wi-Fi as well, check which cheap TP-Link router is fully supported by OpenWRT.

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.

Also 480 MHz but I still doubt that this is correct since A10-Lime and A20-Lime are the same regarding PCB layout.

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

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.

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

This is part LT-1318 from https://www.led-tech.de/de/High-Power-Zubehoer/Kuehlkoerper-c_106_114.html

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)

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.

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.

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.

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.

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

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.)

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?)

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

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

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

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.

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

Update: Still missing with Cubietruck_Debian_4.0_wheezy_4.1.1 -- I will try out replacing .dtb files later this weekend.