Jump to content

tkaiser

Members
  • Posts

    5462
  • Joined

Reputation Activity

  1. Like
    tkaiser got a reaction from jmarcelino in [WiP / Orange Pi One] Support for the upcoming Orange Pi One?   
    Just to emphasise on this a little. The most important part when running these tests is this:
     
     
    That means running cpufreq-ljt-stress-test alone isn't enough on a quad-core H3. You have to use 'cpuburn-a7' or 'stress -c 4' or 'sysbench --test=cpu --cpu-max-prime=100000 run --num-threads=4' running in parallel and it's a good idea to start a few minutes in advance since then the SoC gets closer to worst case conditions.
     
    Since you did not apply a heatsink already the whole test is useless since thermal throttling will occur and cpufreq-ljt-stress-test simply isn't able to test the higher operating points (use RPi-Monitor to get a clue). When I ran cpuburn-a7 with overvolted settings and a heatsink the second protection method jumped in: CPU cores got killed, see a few posts before  (always use RPi-Monitor to get a clue)
     
    So in your situation without a heatsink the best test would be to set scaling_max_freq to 648000 as already suggested, fire up cpuburn-a7 and start the test script 5 minutes later. If that fails then you've the clear indication that on your Orange Pi One the lower voltage is definitely too low. And fex settings that will feed the SoC always with the higher voltage might be an idea. Something like (the voltage value being without any meaning only the 1st bit being important):
    pmu_level0 = 11300 pmu_level1 = 11300 LV1_volt = 1300 LV2_volt = 1300 
  2. Like
    tkaiser reacted to jmarcelino in [WiP / Orange Pi One] Support for the upcoming Orange Pi One?   
    So I reverted config/orangepione.fex back to 80e7d5a while keeping the rest of the tree up to date and my Orange Pi One is now happy again, booting correctly, has network.
     
    Boot log: http://pastebin.com/AdfaAUYe
     
    I'll see if I can narrow it further.
  3. Like
    tkaiser reacted to jernej in [WiP / Orange Pi One] Support for the upcoming Orange Pi One?   
    I hope you don't mind if I join your party
     
    My fbdev patch allows changing only to already supported resolutions on the fly, but you must be aware of two things:
    1. video memory gets reserved at boot, so you can't change to resolution bigger than it was set at boot,
    2. fbset changes only framebuffer resolution info, but doesn't actually switch to it in HW - that can be done via debugfs or disp2's ioctl interface
     
    debugfs method:
    sudo su cd /sys/kernel/debug/dispdbg/ echo "switch" > command echo "disp" > name echo "4 5" > param echo "1" > start where 4 means HDMI output and 5 has the same meaning as in script.bin. For ioctl variant, which is more C friendly, you can check my Kodi patch.
     
    Also one note on your unifying attempt and gmac patch / script.bin dilemma. Please check my github for updated patch. Idea behind it is that driver doesn't fail if there is no [gmac_phy_power] section in script.bin. That way you don't need to change script.bin at all.
     
    And last but not least, if you want to use sy8106a patch on u-boot, you must update u-boot to version 2016.03-rc2.
  4. Like
    tkaiser got a reaction from Igor in [WiP / Orange Pi One] Support for the upcoming Orange Pi One?   
    I took PL08 and it works: https://github.com/igorpecovnik/lib/pull/154
     
    You're hero of the day
  5. Like
    tkaiser got a reaction from jmarcelino in [WiP / Orange Pi One] Support for the upcoming Orange Pi One?   
    Can confirm this. To check whether my display is working correctly I used loboris' Ubuntu 15.04 Mate image and connected it (with script.bin fixes for DVI applied). Worked flawlessly.
     
    Then I made his image 'hybrid':
    cd /tmp && wget http://kaiser-edv.de/tmp/4U4tkD/kernel_5.01_h3.tgz tar xf kernel_5.01_h3.tgz dpkg -i linux-headers-sun8i_5.01_armhf.deb linux-image-sun8i_5.01_armhf.deb mkimage -A arm -O linux -T kernel -C none -a 0x40008000 -e 0x40008000 -n "Armbian-sun8i-3.4.110" -d /boot/vmlinuz-3.4.110-sun8i /media/boot/uImage.armbian shutdown -r now And loaded our kernel in u-boot manually. Et voilà: HDMI works with '2011.09-rc1' and our latest kernel. And surprisingly the SoC's temperature is now also reported in the 'usual' range and not way off as when booting mainline u-boot (currently testing)
  6. Like
    tkaiser got a reaction from Igor in [WiP / Orange Pi One] Support for the upcoming Orange Pi One?   
    Can confirm this. To check whether my display is working correctly I used loboris' Ubuntu 15.04 Mate image and connected it (with script.bin fixes for DVI applied). Worked flawlessly.
     
    Then I made his image 'hybrid':
    cd /tmp && wget http://kaiser-edv.de/tmp/4U4tkD/kernel_5.01_h3.tgz tar xf kernel_5.01_h3.tgz dpkg -i linux-headers-sun8i_5.01_armhf.deb linux-image-sun8i_5.01_armhf.deb mkimage -A arm -O linux -T kernel -C none -a 0x40008000 -e 0x40008000 -n "Armbian-sun8i-3.4.110" -d /boot/vmlinuz-3.4.110-sun8i /media/boot/uImage.armbian shutdown -r now And loaded our kernel in u-boot manually. Et voilà: HDMI works with '2011.09-rc1' and our latest kernel. And surprisingly the SoC's temperature is now also reported in the 'usual' range and not way off as when booting mainline u-boot (currently testing)
  7. Like
    tkaiser reacted to zador.blood.stained in [sunxi A31S / Banana-pi M2] Syntax error in configuration.sh   
    Thanks. Will be fixed soon.
  8. Like
    tkaiser reacted to zador.blood.stained in [WiP / Orange Pi One] Support for the upcoming Orange Pi One?   
    OK
     
    Then this can be resolved by creating empty file (with same file name) in "lib/patch/kernel/sun8i-default/orangepiplus/" if needed, so patch will be disabled when BOARD=orangepiplus
  9. Like
    tkaiser reacted to thc013 in [WiP / Orange Pi One] Support for the upcoming Orange Pi One?   
    tkaiser good work
     
    added your fex to the openelec build of jernesk and working properly
     
    http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=1124&extra=page%3D1
     
    temps are ok
     
    [ 5825.541921] [pm]state:0 invalid!
    [ 5825.541936] [pm]state:1 valid
    [ 5825.541944] [pm]state:3 valid
    [ 5825.541950] [pm]state:7 valid
     
  10. Like
    tkaiser got a reaction from wildcat_paris in [WiP / Orange Pi One] Support for the upcoming Orange Pi One?   
    Funny: I downloaded loboris' Ubuntu Mate 15.04 image for Orange Pi PC, applied all available fixes to kernel/script.bin and tried out our fex file for the Orange Pi One with his image: Both temperature and consumption are higher than with Igor's image and cpufreq scaling behaves strangely with the new fex (only jumping between 1008 and 1200 MHz). When testing the usual sysbench run I even managed to exceed 90°C and ended up with only one remaining active CPU core since 'budget cooling' disabled the other due to overheating.
     
    According to the sources loboris uses it might be necessary to also apply the fex fixes prior to building u-boot (boot log here: http://pastebin.com/12eKRhfY)
     
    But at least situation improves when using our fex file with loboris' OS images. With his script.bin stuff for Orange Pi PC syslog gets flooded with "ARISC ERROR" messages due to wrong voltage regulator type, idle temperature is at 70-75°C and consumption at ~3.0W. Combining our fex settings with his image the error messages disappear, idle temperature is at approx. 54°C and consumption is at ~2.0W. When using Igor's image with our fex file for the 'One' then we're talking about ~45°C and 1.6W when being idle (dvfs settings leading to 648 MHz @ 1.1V).
     
    Our OS image is also way more performant since thermal throttling jumps in later and CPU cores aren't killed unless I ran cpuburn-a7.
     
    All this happened on an Orange Pi One without heatsink (ambient temperature at ~24°C)
  11. Like
    tkaiser got a reaction from wildcat_paris in Need help on Pine A64, 64bit Quad Core 1.2GHz Single board computer   
    It's 3 GB: http://linux-sunxi.org/A64#A64_SoC_Features(and this means unless someone manufactures 12gb DDR3/LPDDR3 modules you will be limited to 2 GB).
     
    But that seems to be a common problem with all those cheap Cortex-A53 ARMv8 implementations. While you can benefit from a huge virtual address space the useable physical address space doesn't exceed the 'magical' 64-bit border of 4 GB. And if you don't move both kernel and userspace from ARMv7 to ARMv8 code you won't get that much more performance either. According to Allwinner's PM A64/H64/R18 (all the same more or less) are made in a 40nm process (so the linux-sunxi wiki is still wrong) which might be responsible for the low clockspeeds possible (1152 MHz max.). The A64 seems to be just a bunch of 64-bit Cortex-A53 cores in a 32-bit SoC and the whole '64-bit thing' is more or less marketing and no technical improvement.
     
    But hey, people buy numbers: They need 64 bit since... that's twice as much as 32 bit. Same with memory: the very same people cry for 4 GB RAM instead of reading through http://www.linuxatemyram.comand being happy with 1 GB.
  12. Like
    tkaiser reacted to zador.blood.stained in [WiP] axp209 mainline sysfs interface   
    Well, I managed to extract OCV curve from PMU, right now it matches default settings in fex file for cubietruck. It should be possible to change it, I'll think about the best way to implement it.
  13. Like
    tkaiser got a reaction from djmanas in Banana Pi M3   
    The A83T used on the M3 has an internal temperature sensor and I provide RPi-Monitor templates to monitor this stuff (see above).
     
    Regarding useable OS images from 'them': well, they suck more or less and you won't see Armbian support anytime soon for any device based on A83T. Why don't you try to get support from the vendor? Why don't you push them to provide something more useable? Why do all the M3 users accept that they bought an expensive paperweight and do not complain publicly so others could learn to avoid the so called 'Banana Pi' M2/M3?
  14. Like
    tkaiser reacted to Igor in [WiP / Orange Pi One] Support for the upcoming Orange Pi One?   
    I added separate config with this change already applied.
     
    https://github.com/igorpecovnik/lib/commit/1992ab5693a753aeaf62ee860d807c16a97ca52c
  15. Like
    tkaiser got a reaction from PoV in Quick review of Orange Pi PC   
    I powered the OPi PC with
    passive PoE (supply 6V to PoE injector, extract 4.5V-5.5V at the PoE splitter and feed it to GPIO pins) normal 5V/2A PSU with 1.7/4.1mm barrel plug normal 5V/2A USB PSU together with USB 'Type A to 1.7/4.1mm barrel plug' cable bench PSU to GPIO pins 12V PSU with step-down converter to GPIO pins (this was my test setup to get the valid DC-IN voltage range for headless operation: 4.5V-5.5V on the PC) Regarding UART-to-USB solutions: They backpower the board somehow so you get often in trouble when you try to do a clean restart. This leads to all sorts of weird problems (for example DRAM calibration might go wrong). As a rule of thumb: If strange stuff happens after a reboot think about shutting the board down and disconnect the adapter for a couple of seconds (or look for a working reset switch on the boards -- this was one of the first things linux-sunxi devs did on the Pine64: Solder this button/switch)
     
    Regarding the new H3-OLinuXino-NANO I see two potential disadvantages compared to the Orange Pis:
    It seems Olimex is now using Micro USB for DC-IN They will use a fixed voltage regulator for the SoC's core voltage so you will be limited by the voltage they choose regarding maximum cpufreq I hope Tsvetan will answer/clarify my last comment here: https://olimex.wordpress.com/2016/02/03/h3-olinuxino-nano-is-only-50x50-mm-but-has-everything-one-computer-must-have/#comment-21665 (I wrote 2W instead of 2A in the hope that this will trigger a reflex)
  16. Like
    tkaiser got a reaction from wildcat_paris in [WiP / Orange Pi One] Support for the upcoming Orange Pi One?   
    Just FYI: Orange Pi One arrived today and runs Igor's Orange Pi image with Orange Pi PC settings. Ethernet and the one USB port work.
     
    But as expected since due to the different voltage regulator different dvfs settings should've been applied:
      [ 2745.863456] [ARISC WARING] :callback not install [ 2745.863466] [cpu_freq] ERR:set cpu frequency to 1008MHz failed! [ 2746.477043] [ARISC ERROR] :message process error [ 2746.477055] [ARISC ERROR] :message addr : f004b840 [ 2746.477065] [ARISC ERROR] :message state : 5 [ 2746.477074] [ARISC ERROR] :message attr : 2 [ 2746.477082] [ARISC ERROR] :message type : 30 [ 2746.477092] [ARISC ERROR] :message result : ff Apart from that the reported SoC temperature is rather high, so next step is to just try out to adjust https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/h3/xunlong_orange_pi_pc.fex#L738
     
    Simply changing pmuic_type = 1 didn't do the trick: http://pastebin.com/Q3taqHbL
     
    EDIT: The different thermal values are related to cold boot vs. reboot. I exchanged pmuic_type several times but that didn't change anything but after a simple reboot the reported temperature was a few degress higher. But by changing pmuic_type I was able to further increase idle temperature so at least something seems to work (on the Orange Pi One the voltage regulator is not accessible through I2C but GPIO instead. It seems a few resistors should switch between 1.1V - 1.3V core voltage.
  17. Like
    tkaiser got a reaction from wildcat_paris in Strange network behavior?   
    Please do the Apple support staff a favour, close the bug report on your own and read through RFC 6886 and https://support.apple.com/kb/PH5103
  18. Like
    tkaiser got a reaction from Tido in Banana Pi M3   
    Ah, now I know what 'some other things' means. I just realised I need to improve my visionary skills to answer questions in a way you're pleased with...
  19. Like
    tkaiser got a reaction from Tido in Creating a backup SD card (* .img) to another media or network   
    We're talking more about 'SBC world' than 'OSS world' here. And in the SBC world often things are simply the result of 'copy&paste gone wrong' especially when the origin was the Raspberry Pi. That applies not only to scripting stuff but to manuals or 'quick start' guides as well. For example: How moronic is a 'guide' that teaches you to partition/format your SD card just to overwrite partitions/filesystems one second later: http://www.lemaker.org/product-bananapro-guide.html
     
    Using SD Formatter with large SD cards is necessary when you try to use the card with any Raspberry Pi (since there the boot process is totally different and the VideoCore GPU/VPU starts first and is only able to read from FAT and not from exFAT most large cards are formatted with). But this step is totally useless with any other ARM board. Why do we find SD Formatter mentioned in the 'guides' of so many vendors when it's completely useless here?
     
    Think about it. Same applies to script snippets the net is flooded with...
  20. Like
    tkaiser got a reaction from zador.blood.stained in Banana Pi M3   
    Tido, why should I start recommending crap? Have a look at this (incomplete) list to get the idea that there is a little bit more than the few SBC vendors you personally know: https://en.wikipedia.org/wiki/Comparison_of_single-board_computers  (you should really accept that there exist more than 5 vendors and there's no need to choose vendors that got somewhat known/famous for supporting product A -- Banana Pi/Pro -- and now are only dealing with totally incompatible products B, C and D)
     
    When I read "some kind of debian for a webserver/hotspot and some other things which my current rasperry pi B+ is doing way too slow" I'm not able to recommend anything since I neither know a single SBC suitable as 'hotspot' nor do I have an idea what specific criteria are needed for 'some other things'.
     
    For a webserver I would've a look at boards with high I/O and network bandwidth that are able to run with mainline kernel. But regarding AP mode and 'some other things' I still have not the slightest idea. Since if one of these other things would be HW accelerated video encoding/decoding recommendations might look totally different.
  21. Like
    tkaiser got a reaction from Igor in Banana Pi M3   
    Why are you thinking about this Banana Pi M3 in the first place? It name tries to suggest it's being compatible with the original Banana Pi but it isn't. It's incompatible in the following areas:
    hardware: way less I/O bandwidth compared to A20 based Banana Pi/Pro/M1/M1+, based on totally different SoC software: simply sucks, it will take months until 'Team BPi' might deliver OS images where everything works as it should and that can be upgraded to a newer version support/community: sucks totally, nothing you'll find on the net regarding Raspberry or Banana Pi applies to M2/M3 and if you ask questions in their forum you'll either get no or most of the times wrong answers I had to learn that people still think the well known Banana brand would mean something regarding the totally incompatible M3 even if you tell them ten times that it's not the case. And also people seem to be impressed by (false) hardware specifications:
    octa-cora CPU @ 2 GHz (no way to get there without a huge fan and resoldering a sane DC-IN solution since if thermal throttling won't prevent the CPUs clocking at 1.8GHz or above the board will power off due to undercurrent situation since 'Team BPi' chose the crappiest DC-IN connector ever: Micro USB) SATA (not true, they chose the crappiest USB-to-SATA bridge in the crappiest possible mode ever: only one of the 2 SoC's USB host ports used to connect to an internal USB hub and connecting the USB-to-SATA bridge to this hub and not the other available USB host port the A83T features) 2 GB RAM: So what? Time to read/understand http://www.linuxatemyram.com onboard Wi-Fi: I've not heard of anyone using AP6212 on the M3 in AP mode and would suspect it's the same situation as with nearly every other onboard Wi-Fi on SBCs: crap Considering all that and adding both software/support situation and the price of this device the conclusion should be rather simple.
  22. Like
    tkaiser reacted to matt in Banana Pi: BTRFS worth trying for SATA SSD?   
    Hello!
     
    I am using BTRFS with Bananian and Armbian. (3 Banana Pies: 4x external USB hard drives, 1x SATA SSD… everything with BTRFS)
     
    Armbian with an external SSD (SATA):
    root@bananatest:~# uname -a Linux bananatest 4.3.3-sunxi #3 SMP Mon Dec 28 11:27:16 CET 2015 armv7l GNU/Linux root@bananatest:~# dpkg -l | grep btrfs ii  btrfs-progs                     4.2-1                        armhf        Package created with checkinstall 1.6.2 root@bananatest:~# btrfs --version btrfs-progs v4.2 root@bananatest:~# mount | grep btrfs /dev/sda1 on /mnt/BTRFS_POOL_SSD type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/) /dev/sda1 on /mnt/Data type btrfs (rw,relatime,ssd,space_cache,subvolid=257,subvol=/@Data) root@bananatest:~# cat /sys/block/sda/queue/rotational 0 I am still using btrfs-progs 4.2 (self-compiled). It's working good (compression: lzo and zlib, subvolumes, snapshots, scrub, checksums). If you want to use compression, you should use lzo.
     
    With BTRFS I was able to detect a buggy USB hard drive controller.
  23. Like
    tkaiser got a reaction from matt in Banana Pi: BTRFS worth trying for SATA SSD?   
    And you always should keep in mind: 100% of all commonly used benchmarks are just wrong. Without a deeper understanding and an 'active benchmarking' approach you will always end up with misleading results and draw the wrong conclusions.
     
    A great source of information is provided by one of my personal heroes: 
    http://www.brendangregg.com/activebenchmarking.html http://slideshare.net/brendangregg/linux-performance-analysis-and-tools http://slideshare.net/brendangregg/broken-linux-performance-tools-2016
  24. Like
    tkaiser got a reaction from c3po in Banana Pi: BTRFS worth trying for SATA SSD?   
    And you always should keep in mind: 100% of all commonly used benchmarks are just wrong. Without a deeper understanding and an 'active benchmarking' approach you will always end up with misleading results and draw the wrong conclusions.
     
    A great source of information is provided by one of my personal heroes: 
    http://www.brendangregg.com/activebenchmarking.html http://slideshare.net/brendangregg/linux-performance-analysis-and-tools http://slideshare.net/brendangregg/broken-linux-performance-tools-2016
  25. Like
    tkaiser got a reaction from Tido in Need help on Pine A64, 64bit Quad Core 1.2GHz Single board computer   
    It's 3 GB: http://linux-sunxi.org/A64#A64_SoC_Features(and this means unless someone manufactures 12gb DDR3/LPDDR3 modules you will be limited to 2 GB).
     
    But that seems to be a common problem with all those cheap Cortex-A53 ARMv8 implementations. While you can benefit from a huge virtual address space the useable physical address space doesn't exceed the 'magical' 64-bit border of 4 GB. And if you don't move both kernel and userspace from ARMv7 to ARMv8 code you won't get that much more performance either. According to Allwinner's PM A64/H64/R18 (all the same more or less) are made in a 40nm process (so the linux-sunxi wiki is still wrong) which might be responsible for the low clockspeeds possible (1152 MHz max.). The A64 seems to be just a bunch of 64-bit Cortex-A53 cores in a 32-bit SoC and the whole '64-bit thing' is more or less marketing and no technical improvement.
     
    But hey, people buy numbers: They need 64 bit since... that's twice as much as 32 bit. Same with memory: the very same people cry for 4 GB RAM instead of reading through http://www.linuxatemyram.comand being happy with 1 GB.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines