Jump to content

tkaiser

Members
  • Posts

    5462
  • Joined

Posts posted by tkaiser

  1. Everything now works as expected:

    root@cubietruck:~# uname -a
    Linux cubietruck 4.1.2-cubietruck #16 SMP Fri Jul 24 18:43:14 CEST 2015 armv7l GNU/Linux
    
    root@cubietruck:~# zgrep CONFIG_REGULATOR_AXP20X /proc/config.gz
    CONFIG_REGULATOR_AXP20X=y
    
    root@cubietruck:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 
    312000 528000 720000 864000 912000 960000 
    

    I added a request for enhancement on Igor's github and provide the kernel dpkgs temporarely here: http://kaiser-edv.de/tmp/4.1.2-cubietruck-next.tar

  2. I am having the same problem. Did you ever figure out how to get cpufreq to working on the Cubietruck?

    Seems to be related to CONFIG_REGULATOR_AXP20X -- compare with the thread mentioned above. In the cubietruck's device tree CPU voltage scaling is also enabled but Igor's kernel config reads 'CONFIG_REGULATOR_AXP20X not set' at the moment. So Igor pointed already in the right direction and I missed these obvious differences between both .dts completely :-\

     

    You should try to build the kernel yourself using CONFIG_REGULATOR_AXP20X=y (or watch the aforementioned thread whether Leonardo provides informations what went wrong in his case -- the Debian kernel builds this stuff as a module and that seems to not load correctly -- so you might also be able to compile the module).

  3. so charge the LiPo and powering the board at the same time?

     

    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

  4. 2. No ideas at this point. I guess it's not a proper FEX script. I use the one from here.

     

    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

  5. When I measured temperature on A20 with 3.4 kernel, with heatsink temperature decreased by 3°C, so I expect similar behaviour on broadcom chip

     

    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:

     

    IMG_4942.JPG

     

    After I attached a heatsink and operated the thing vertically problems were gone:

     

    IMG_4945.JPG

     

     

    And the good news is: The way convection works the better it cools parts that get hotter than others.

  6. Ok, I will drill several holes on upper cover here http://petasek.ddns.net/R1-holes.jpg to improve airflow??

    Heatsinks I ordered already, so I have to wait several days for delivery.

     

    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.

  7. I agree with you, that it's the BCM chip. I put the box verticaly:

     

    http://petasek.ddns.net/R1-001.jpg

     

    and stability is better. I will buy cooler for the BCM chip too and we will see :)

     

    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.

  8. altough i might paint it black 2 :P

     

    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.

  9. On the other hand I manage to write a script manual v1.0 :)

     

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

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

  11. 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
    
  12. 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
    

     

     
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines