jobenvil
-
Posts
60 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jobenvil
-
-
There is one image for all bananas and DTB file is encoded into u-boot.
For bananapro you only need to change:
ext4load mmc 0 0x49000000 /boot/dtb/${fdtfile} || fatload mmc 0 0x49000000 /dtb/${fdtfile}to
ext4load mmc 0 0x49000000 /boot/dtb/sun7i-a20-bananapro.dtb || fatload mmc 0 0x49000000 /dtb/sun7i-a20-bananapro.dtb
and recompile the boot.cmd to boot.scr as stated in file. reboot and you are done.
I got it, shame on me! thanx, thanx!!
and thanx!
this looks like much better now:
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 4.2.3-sunxi (root@production) (gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) ) #2 SMP S un Oct 11 14:12:18 CEST 2015 [ 0.000000] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine model: LeMaker Banana Pro <=======================THANKS!!=================================== [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] On node 0 totalpages: 262144 [ 0.000000] free_area_init_node: node 0, pgdat c0a2c800, node_mem_map eeef8000
-
I cannot understand how the drivers (dtb) could be choosen properly for banana pi pro. I download the 4.5 wheezy version for Banana Pi Pro but dmesg shows that the board is a "banana pi BP1-M1":
[ 0.000000] Linux version 4.2.3-sunxi (root@production) (gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) ) #2 SMP Sun Oct 11 14:12:18 CEST 2015 [ 0.000000] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine model: Banana Pi BPI-M1
I checked the /boot directory and I see that the script.bin is linked with "bananapi.bin" even inside /boot/bin we can find the "bananapipro.bin" file:
root@bananapi:/boot# ls -ltr total 7396 -rwxr-xr-x 1 root root 5468416 Oct 11 14:12 vmlinuz-4.2.3-sunxi -rw-r--r-- 1 root root 1955569 Oct 11 14:12 System.map-4.2.3-sunxi -rw-r--r-- 1 root root 115484 Oct 11 14:12 config-4.2.3-sunxi lrwxrwxrwx 1 root root 25 Oct 11 19:10 zImage -> /boot/vmlinuz-4.2.3-sunxi drwxr-xr-x 2 root root 4096 Oct 11 19:10 dtb -rw-r--r-- 1 root root 6944 Oct 11 19:10 boot.bmp -rw-r--r-- 1 root root 1901 Oct 11 19:11 boot.cmd -rw-r--r-- 1 root root 1973 Oct 11 19:11 boot.scr drwxr-xr-x 2 root root 4096 Oct 11 19:11 bin lrwxrwxrwx 1 root root 25 Oct 19 11:23 script.bin -> /boot/bin/bananapi.bin
I modified the link to point to bananapipro.bin, but theoretically this has no sense anymore because with this new kernel we use the dtb files and I see that in dmesg has nothing changed. Is my supposition correct?
When I check the boot.cmd:
--------- # Boot loader script to boot with different boot methods for old and new kernel #-------------------------------------------------------------------------------------------------------------------------------- if ext4load mmc 0 0x00000000 /boot/.next || fatload mmc 0 0x00000000 .next then # sunxi mainline kernel #-------------------------------------------------------------------------------------------------------------------------------- ext4load mmc 0 0x49000000 /boot/dtb/${fdtfile} || fatload mmc 0 0x49000000 /dtb/${fdtfile} ext4load mmc 0 0x46000000 /boot/zImage || fatload mmc 0 0x46000000 zImage env set fdt_high ffffffff bootz 0x46000000 - 0x49000000 #-------------------------------------------------------------------------------------------------------------------------------- else # sunxi android kernel #-------------------------------------------------------------------------------------------------------------------------------- ext4load mmc 0 0x43000000 /boot/script.bin || fatload mmc 0 0x43000000 script.bin ext4load mmc 0 0x48000000 /boot/zImage || fatload mmc 0 0x48000000 zImage bootz 0x48000000I cannot understand how the boot process chooses the properly "sun7i-a20-bananapro.dtb" between all the *.dtb files:
... -rw-r--r-- 1 root root 27637 Oct 11 14:13 sun7i-a20-bananapro.dtb -rw-r--r-- 1 root root 27261 Oct 11 14:13 sun7i-a20-bananapi-r1.dtb -rw-r--r-- 1 root root 27902 Oct 11 14:13 sun7i-a20-bananapi-m1-plus.dtb -rw-r--r-- 1 root root 27145 Oct 11 14:13 sun7i-a20-bananapi.dtb -rw-r--r-- 1 root root 19291 Oct 11 14:13 sun6i-a31s-cs908.dtb -rw-r--r-- 1 root root 23022 Oct 11 14:13 sun6i-a31s-bananapi-m2.dtb ...
and how to confirm it with CLI that I'm using the properly .dtb file after every kernel update.
Thanks in advance!
-
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.
Thanks Kaiser, I research in Internet/Wiki for this; how accurate are the results or how the fit to the reality I don't know. I will check both programms you wrote. Thanks again. BTW, I installed the orange pi of Igor and runned the sata script. Now I have rootfs on SATA HDD, but the **wa** value of top is higher than I imagined; around 7 % even in EXT4 file system. I will perform some SAMBA /Seafile tests and probably think I will come back to the rootfs on SD Card. It is important for me to let save energy when there is no activity on SATA HDD -which should be the normal case-. I realized that the RAM (if less than 1GB) plays a nice efficient role and doesn't carry about HDD/SD.
-
and hdparm:
-
The values differ regarding the size of the testfile. Like you wrote before, may assume that they are sequencial reading/writing.
-
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.
Thanks for the really good technical explanation!
I will post the dd and hdparm tests of microSD Kingston UHS-1 8GB that I made.
-
I don't know if this is normal. Sorry if this a stupid question,
:huh: but I don't know why there are inside of the /boo/bin directory a bananapi.bin and bananapipro.bin but on the /boot directory the image target the bananapi.bin instead of bananapipro.bin.Board: banana pi pro; debian wheezy 4.04.4 (igor image) shows:
root@bananapi:/boot# ls -ltr total 12852 -rwxr-xr-x 1 root root 5030568 May 21 21:59 vmlinuz-4.0.4-bananapi -rw-r--r-- 1 root root 1788788 May 21 21:59 System.map-4.0.4-bananapi -rwxr-xr-x 1 root root 95973 May 21 21:59 config-4.0.4-bananapi lrwxrwxrwx 1 root root 28 May 21 22:31 zImage -> /boot/vmlinuz-4.0.4-bananapi drwxr-xr-x 2 root root 4096 May 21 22:31 dtb -rw-r--r-- 1 root root 1476 May 21 22:31 boot.cmd lrwxrwxrwx 1 root root 22 May 21 22:31 script.bin -> /boot/bin/bananapi.bin -rw-r--r-- 1 root root 1548 May 21 22:31 boot.scr -rwxr-xr-x 1 root root 6220856 May 21 22:31 boot.bmp drwxr-xr-x 2 root root 4096 May 21 22:31 bin root@bananapi:/boot# cd bin root@bananapi:/boot/bin# ls -ltr total 660 -rw-r--r-- 1 root root 50928 May 21 22:31 orangepi.bin -rw-r--r-- 1 root root 52608 May 21 22:31 micro.bin -rw-r--r-- 1 root root 52616 May 21 22:31 lime.bin -rw-r--r-- 1 root root 53480 May 21 22:31 lime2.bin -rw-r--r-- 1 root root 51012 May 21 22:31 lamobo-r1.bin -rw-r--r-- 1 root root 46360 May 21 22:31 cubietruck.bin -rw-r--r-- 1 root root 43724 May 21 22:31 cubieboard.bin -rw-r--r-- 1 root root 46184 May 21 22:31 cubieboard2.bin -rw-r--r-- 1 root root 50612 May 21 22:31 bananapiprolcd7.bin -rw-r--r-- 1 root root 50612 May 21 22:31 bananapipro.bin -rw-r--r-- 1 root root 50580 May 21 22:31 bananapilcd7.bin -rw-r--r-- 1 root root 50516 May 21 22:31 bananapi.bin -rw-r--r-- 1 root root 45936 May 21 22:31 aw-som-a20.bin
Is this normal?
-
Just as a small addendum: Many things one might attribute to "new kernel" are just side effects of different 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)What soll I tell you more? you are absolutely right; regarding to the SATA and bottlenecks as well. I tested your settings; they are really good for iperf. TX and RX are almost the same.
The values are:
from Laptop-to-> Banana Pro 686Mbits/s (Bananae Server) = 85MB/s
from Banana Pro-to->Laptop 568Mbits/s (Banana Client) = 71 MB/s
(somehow I'm not more able to upload the screenshoot I took)
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.
I had no problems booting even from USB drive on kernel 4.x ... with latest kernel configuration updates of course. My pre-build images are not fixed yet! (I think only OrangePi)
What do you mean with pre-build images? Which are already to download 3.0.107/4.0.4 (M)® in your internet page?
Do you mean to apply the last Github changes (config/linux-sunxi-next.config ) and compile the kernel? Because I supposse that your (SATA) changes are for compiling, isn't it?
Many thanks in advance
-
used your script to make rootfs on SATA device but it doesn't boot up. I just modified your script:
if [[ $KERNEL == *"3.4"* ]]; then sed -e 's,root=\/dev\/mmcblk0p1,root=/dev/'"$DESTPART"',g' -i /boot/boot.cmd mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr else sed -e 's,root=\/dev\/mmcblk0p1,root=/dev/'"$DESTPART"',g' -i /boot/uEnv.txt sed -e 's,root=\/dev\/mmcblk0p1,root=/dev/'"$DESTPART"',g' -i /boot/boot.cmd if [ -f /boot/boot.cmd ]; then mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr fi fi # change fstab sed -e 's/mmcblk0p1/sda1/g' -i /mnt/etc/fstab sed -i "s/data=writeback,//" /mnt/etc/fstab mkdir -p /mnt/media/mmc echo "/dev/mmcblk0p1 /media/mmc ext4 defaults 0 0" >> /mnt/etc/fstab echo "/media/mmc/boot /boot none bind 0 0" >> /mnt/etc/fstab fi
to Kernel 4.0.4 but it doesn't help as well. It is not possible for R4.0.4 to boot from sata at all?, or making more changes to the script could be possible? Thank you very much Igor. I appreciate much your work.
BTW I want to share with you/other that using kernel 4.0.4 the ethernet speed (696Mbits/s) increased a lot, compared with the 3.4.107 (412Mbits/s) acting the bananapi pro like as server (-s) testing with iperf. This kernel has "something" which it works more effizient. I checked the dmseg for 4.0.4 and is free of errors. All what I need works (SATA/Eth) and it works, until now, very stable.
Regards
Jobenvil
changing motd on banana pro
in Beginners
Posted
Hello Igor,
I want to put my own stuff inside motd.
I'm not sure which scripts are responsible. In
there is your banana text, but this is dinamically changing.
how is the best approach to exchange the motd on your distros?
Regards
José