tkaiser Posted February 21, 2016 Posted February 21, 2016 The Orange Pi One is the most recent SBC from Xunlong. It's clearly the Orange Pi PC's little sibling. In case you haven't read the PC's review already maybe it's time to do it now since here only important differences will be shown. Since it's based on an Allwinner SoC (system on chip) please keep in mind that you will always find the most comprehensive and up-to-date information in the linux-sunxi wiki: http://linux-sunxi.org/Orange_Pi_One The most important differences between One and PC as follows: Smaller size: the PC used the RPi form factor (85mm x 55mm) while the One is just 69mm x 48mm in size 512MiB instead of 1GiB DRAM (still two DDR3L modules making use of the full 32 bit memory bandwidth) 2 USB host ports less (available through solder points) IR receiver, microphone and TRRS jack for Audio/CVBS video also missing (available through solder points) GPIO header rotated by 180° A different method to regulate the SoC's core voltage (VDD-CPUX) responsible for a few issues currently The One costs $10 whereas the PC is been sold at $15. Since you don't get large volume discounts on shipping you should better compare prices with shipping included and end up now with $13.63 vs. $18.69 if you order directly in Xunlong's aliexpress store. So you get less for less money but should keep in mind that the size reduction has one serious drawback: Due to the height of USB and Ethernet jacks Xunlong chose to rotate the 40 pin GPIO header and now Add-On boards (RPi HATs) project over the board. And while you can combine for example an Orange Pi PC with a 3.2" Touchscreen LCD to a compact package this isn't possible with the One any longer. The Orange Pi PC fits exactly: And that's how it looks with the One: You should also take care of the header's orientation when trying out GPIO/1-Wire/I2C stuff and especially when you try to power the board through GPIO pins 2/4/6. They are not where you would expect them like on any other board using the RPi connector (except of Lamobo R1) but on the other side of the header (180° rotation). Different voltage regulator and the consequences: Now to the most important change: the different method to switch the SoC's core voltage. What is this switching for? This thing is called dynamic voltage frequency scaling (dvfs) and the idea behind is to keep the voltage of the SoC's core components as low as possible unless needed. If you want to clock the CPU/GPU cores higher you need more voltage to let them work reliably. On the other hand higher voltage negatively affects temperature, consumption and maybe also longevity. Here the combination of cpufreq scaling and dvfs jumps in. When the CPUs are clocked lower also less voltage is used to feed them. And when they're clocked higher the voltage rises automatically to ensure reliable operation. With dvfs a few operating points are defined that specify at which cpufreq traversal which voltage should be used. This looks then like this example for Orange Pi PC. On the Orange Pi PC a voltage regulator called SY8106A adjustable through I2C is used and it's easy to define up to 16 dvfs operating points. On the Orange Pi One this is different and a more simple voltage regulator has been used (according to schematic the SY8113B should be used but users spotted that on their boards in reality the rather similar AX3833 is used). This voltage regulator supports only two states and according to the Orange Pi forums this should be used to switch the voltage between 1.1V at the lowest CPU clockspeed and 1.3V with the higher clockspeeds (confirmed in the meantime to work on at least one board). Fex/script.bin fixes necessary when using OS images for PC: When you're using OS images for Orange Pi PC on the One then due to the different voltage regulator the log gets filled with countless messages like this: [ARISC ERROR] :message process error [ARISC ERROR] :message addr : f004b840 [ARISC ERROR] :message state : 5 [ARISC ERROR] :message attr : 2 [ARISC ERROR] :message type : 30 [ARISC ERROR] :message result : ff [ARISC WARING] :callback not install [cpu_freq] ERR:set cpu frequency to 1008MHz failed! Therefore it's necessary to fix this by tweaking the so called fex file when using OS images that still rely on kernel 3.4.x (applies to all currently). It's necessary to exchange the pmuic_type (2 is I2C, 1 is GPIO) and to define at which clockspeed the regulator should switch between its two states. So the most easy solution seems to define 2 operating points as outlined in the sunxi wiki: http://linux-sunxi.org/Orange_Pi_One#Normal_dvfs_settings At least on one board the real voltages used aren't 1.1V and 1.3V but significantly higher instead. My assumption is based on thermal behaviour: the main heat source is the core voltage (VDD-CPUX). Unfortunately my Multimeter died so we're waiting for others to investigate further by checking the 1V2C and VDD_CPUFB test points on the PCB. There is an active discussion in our developer section regarding this at the moment. So there is at least one board where voltages are significantly higher then they should be (leading to overvolted/overheating behaviour without adjusted fex settings) and there is at least another where everything works as expected (and which runs into stability issues when preventing to switch to the higher voltage). Now it's time to collect feedback from users how many are affected by wrong voltage values. How does voltage switching works on the One? So let's have a closer look how the switch between the two voltages works (regardless of the real voltages used -- they have to be confirmed by measuring the 1V2C and TP1 test points on the PCB). In the fex file after changing the pmuic_type to 1 you can define two voltage values and the switch state: pmu_level0 = 11300 pmu_level1 = 1100 LV1_freq = 1200000000 LV1_volt = 1300 LV2_freq = 648000000 LV2_volt = 1100 This reads like 648MHz @ 1100mV and 1200MHz @ 1300mV. But you could also write the following into and it would work exactly the same: pmu_level0 = 15000 pmu_level1 = 1500 LV1_freq = 1200000000 LV1_volt = 5000 LV2_freq = 648000000 LV2_volt = 1500 Now it reads 648MHz @ 1500mV and 1200MHz @ 5000mV (clearly exceeding the max. 1400mV allowed for the H3) but it doesn't matter since this just triggers at which cpufreq change the voltage should be switched between the lower and the higher value. So to stay always on the lower voltage you could use pmu_level0 = 5000 pmu_level1 = 5000 LV1_freq = 1200000000 LV1_volt = 5000 LV2_freq = 648000000 LV2_volt = 5000 And to always use the higher voltage (necessary in case some users are really affected by undervoltage when using the lower available) it could read: pmu_level0 = 11000 pmu_level1 = 11000 LV1_freq = 1200000000 LV1_volt = 1000 LV2_freq = 648000000 LV2_volt = 1000 This will prevent using the higher voltage in the former case even if there 5000mV are written to the fex and will force the higher in the 2nd example regardless of the voltage value (1000mV). Only the first bit set or not defined in pmu_level0/pmu_level1 is important. Unless this issue is resolved I would stay away from the device. And if you're already an owner of the Orange Pi One you should check whether you're affected by undervoltage/overvoltage issues. Final chapter: Software support for the Orange Pi One: First of all you could use any of the available OS images for Orange Pi PC but would've to adjust the voltage regulator stuff in script.bin/fex. I already updated my fix-thermal-problems.sh script known from the Orange Pi forums to fix overvolted settings for the older Orange Pis to be useable with Orange Pi One/Lite too. In the meantime Armbian started to support all available H3 Orange Pi boards just recently: http://www.armbian.com/download/ (please don't expect yet too much, we're moving fast but it's still a bit early and a lot of work in progress!) Jernej's OpenELEC port also progresses nicely and fully supports Orange Pi One in the meantime (in fact he helped us a lot to improve Armbian support for the One) It can be expected that a lot of improvements for sun7i (A20 SoC used on Cubieboards, the original Bananas and a few more) will be ported over to sun8i/H3 in the next time. And then mainlining effort for the H3 is still improving more and more. I'm using one Orange Pi PC since weeks as NAS with mainline kernel (4.5) and an USB-to-Ethernet dongle since native Ethernet is still not supported. Same applies to display stuff. You can inform yourself about the status always here: http://linux-sunxi.org/Mainlining_Effort#Work_In_Progress Using Orange Pi One with the most recent kernel is already possible combining a few patches and I would suspect that it's just a few weeks until Ethernet and display is working. EDIT: In the meantime enclosures are available (a bit problematic since OPi One suffers from heat issues more than its bigger siblings): laser cut DIY made of 3 mm crystal-clear acrylic and one on Aliexpress. 5
Tido Posted February 21, 2016 Posted February 21, 2016 Thank you for your review and update on the current software development from the community. My conclusion of this is, that the Orange Pi PC is the far better choice for only $5.- more, but without Ethernet-Driver kind of useless. The OPi One may be smaller in size but same height as OPi PC, so the advantage of the RPi-Zero is not given here. I wonder if Orange will sell again the A20 Model. Did you attach the heat-sink or did they come with?
tkaiser Posted February 21, 2016 Author Posted February 21, 2016 Ethernet works with kernel 3.4.x. Mainline driver for Ethernet in H3 (same as in A64 and A83T -- Allwinner chose a new IP block compared to the older SoCs) will be ready in a few weeks. And USB-to-Ethernet adapters do exist if you want to use mainline kernel right now with the One or PC or any other H3 device. The heatsinks are mine, if you get an Orange Pi One where voltage switching works as expected no heatsink is necessary -- compare with our latest findings: http://forum.armbian.com/index.php/topic/617-wip-orange-pi-one-support-for-the-upcoming-orange-pi-one/?p=5420 But thx for mentioning heatsinks: I normally use one for A20 (20x20 mm). These fit on the PC but won't fit on the Orange Pi One due to placement of other components. You need heatsinks that do not exceed 16x16 mm in size. But as already said: They're not necessary if you've a board that is not defective (mine is obviously). Regarding RPi Zero: comparing real products with virtual products is not that fair http://whereismypizero.com And it's simply a matter of the use case. For the project we're currently developing the One can always be used instead of the PC when only one USB port is needed (printing/scanning workflow with RFID authentication). You should keep in mind that the Orange Pi One is many times faster than the 'Zero' (important since we're using the device as software RIP converting PDF to primitive PDLs), there Ethernet and USB do not have to share bandwidth and it's also cheaper (when you add shipping costs to the virtual product that no one can buy). Most importantly: Would you use an SBC that is not capable of running Armbian?! 1
Tido Posted February 22, 2016 Posted February 22, 2016 Ethernet works with kernel 3.4.x. Mainline driver for Ethernet in H3 But thx for mentioning heatsinks: I normally use one for A20 (20x20 mm). These fit on the PC but won't fit on the Orange Pi One due to placement of other components. And it's simply a matter of the use case. For the project we're currently developing the One can always be used instead of the PC when only one USB port is needed Most importantly: Would you use an SBC that is not capable of running Armbian?! This is good to know as not everybody needs the latest kernel. Heat Sink, can you tell how well your heat sink works on a A20, I mean how many degrees it does reduce the temperature? This is what "I" meant; in order to take a OPi ONE over the OPi PC you have to have a really big quantity or no space, otherwise these $5.- do not really count if you talk about 5-10 piece. The major show Stopper, no armbian on RPi zero, but I have to admit that there are a couple nice mini distro's out there for the Pi. I wonder how much longer it takes until really everything works as OSS for the RPi (beside the license key for HW decoding MPEG2 & VC1).
tkaiser Posted February 22, 2016 Author Posted February 22, 2016 Heat Sink, can you tell how well your heat sink works on a A20, I mean how many degrees it does reduce the temperature? The specific SoC doesn't matter that much. With the ones I use normally (cheap, $0.5, just do a search for 'heatsink 20x20 cubie') you get 50°C instead of 60°C (A20 will not get that hot -- and you should keep in mind that newer SoCs with their budget cooling strategies are somewhat different since throttling is part of the design -- compare with 'Turbo boost' in x86 land): http://linux-sunxi.org/User:Tkaiser#Xunlong_settings And you should keep in mind that your set of criteria to choose between different devices might not match those of anyone else. I would also suspect if you try to buy 100 or more you can make a good deal with Xunlong and then choosing Ones instead of PCs is simply a reduction of costs by a third since customs/VAT should scale almost linearly (at least we want to use these devices on a larger scale in projects -- and unlike the 'RPi Zero' toy the One is a solid product for the use cases we have in mind) 1
Tido Posted February 23, 2016 Posted February 23, 2016 around 10° sounds interesting, while booting my A20 gets pretty hot, above 80 and so I guess if a thread gets stuck it can heat up quite good. Thank you for the tipp to find these. I would also suspect if you try to buy 100 or more you can make a good deal A good deal ? In my daily live I am a senior purchaser and I would never buy more than 10-20 without knowing the manufacturer and their principles (i.e. child labour), plus without guaranteed BOM, plus at least a couple pieces for free because of warranty return does not make sense. And this list is not exhaustive. All these parts are Toys. Maybe an Odroid or Olimex is different, but all the others I would not trust. Probably with SinoVoip, with a contract, you can work something out, but the way we met them, no way (I speak for myself).
tkaiser Posted February 23, 2016 Author Posted February 23, 2016 around 10° sounds interesting, while booting my A20 gets pretty hot, above 80 and so I guess if a thread gets stuck it can heat up quite good. Ok, so you're not talking about chip temperatures but readouts from a thermal sensor somewhere inside a chip that are interpreted by a driver and that might be somewhat off directly after booting? Good luck trying to solve software/calibration issues with a heatsink To stop this useless discussion: Use cpuburn-a7 for several minutes, check the temperature readout (and keep in mind that it's still uncalibrated since no one did the work to do calibration for A20) and check the real temperature on the chip's surface. As I already tried to point out: the A20 is from a different SoC generation, the contained thermal sensor is part of a touch screen controller and more included by accident than by design. That's different on more recent SoCs like the H3: They contain a thermal sensor by design to prevent overheating and to be used for cooling strategies (throttling, disabling CPU cores). And even with these sensors that are way more reliable than the one in A20 we have calibration problems. Don't trust in numbers generated by software! Regarding toys you started with the RPi Zero. Always out of stock, if not you have to order an expensive bundle containing a bunch of crap and you're limited to one piece per order: https://shop.pimoroni.com/products/pi-zero-complete-starter-kit And if you're not a tinkerer/maker you can't do anything with a 'Zero' except of using it as a very slow desktop without connections to the outside. I'm talking about IoT/controller stuff where I need connectivity (Ethernet, USB), a few sensors (SPI, I2C, maybe 1-Wire) and sometimes also performance. And I need to get this up and running quickly and reliably. The board in question doesn't matter that much if it has the necessary features and is supported by my distro of choice: Armbian. Now we can also use cheap Orange Pis too (hardware quality is good, software/support from the vendor sucks -- but the latter doesn't matter at all fortunately) And BTW: You should really open your eyes and realise that there exist more than 3-5 SBC manufacturers in this world 1
Tido Posted February 23, 2016 Posted February 23, 2016 Aha, I thought the A20's information about it is already reliable - good to know. The OPi One is the answer to RPi Zero, so I just compared them on size and prize. I stay with my answers given in the threads above. If you do IoT seriously, with quantity and maybe with SCADA and such - you better have standardized, reliable tools (SBCs). If you just do some home automation, your approach is fine. ToC (total cost of ownership) is not just based on purchasing. I own an R1, LeMaker Guitar and a RPi 2 - I am not a collector. What R1 is for, is clear. Guitar and RPi I am uncertain, some Retro-Game console would be fun and or for music, maybe with display in conjunction of the R1. My time given there is more than enough to do. So why would I care about every product out there, why? Same for Linux Distro's, there are big ones, Fedora, SuSE, Ubuntu and 1000 more.I run an Ubuntu derivate, because I know APT and such - and I am happy with this. How about you set up a list on your Website how many devices you already had or have had (SBCs) in the last 24 months. And which of those were really good :-) (the very very short part of this list :-) )
tkaiser Posted February 25, 2016 Author Posted February 25, 2016 Just a small update. After we added H3 support to the Armbian build system the last weeks I just tried it out with mainline kernel and let a Jessie image build. The usual Armbian experience: The whole dmesg output: [ 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.4.2-sunxi (root@opennms) (gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) ) #1 SMP Thu Feb 25 12:10:54 CET 2016 [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine model: Xunlong Orange Pi PC [ 0.000000] cma: Reserved 16 MiB at 0x5ec00000 [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] On node 0 totalpages: 131072 [ 0.000000] free_area_init_node: node 0, pgdat c08fd2c0, node_mem_map de780000 [ 0.000000] Normal zone: 1152 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 131072 pages, LIFO batch:31 [ 0.000000] psci: probing for conduit method from DT. [ 0.000000] psci: Using PSCI v0.1 Function IDs from DT [ 0.000000] PERCPU: Embedded 12 pages/cpu @dffb3000 s19008 r8192 d21952 u49152 [ 0.000000] pcpu-alloc: s19008 r8192 d21952 u49152 alloc=12*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129920 [ 0.000000] Kernel command line: console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 cgroup-enable=memory swapaccount=1 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 [ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes) [ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Memory: 493096K/524288K available (6827K kernel code, 256K rwdata, 1760K rodata, 332K init, 280K bss, 14808K reserved, 16384K cma-reserved, 0K highmem) [ 0.000000] Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xffc00000 - 0xfff00000 (3072 kB) vmalloc : 0xe0800000 - 0xff800000 ( 496 MB) lowmem : 0xc0000000 - 0xe0000000 ( 512 MB) pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) modules : 0xbf000000 - 0xbfe00000 ( 14 MB) .text : 0xc0008000 - 0xc086aedc (8588 kB) .init : 0xc086b000 - 0xc08be000 ( 332 kB) .data : 0xc08be000 - 0xc08fe220 ( 257 kB) .bss : 0xc0901000 - 0xc0947340 ( 281 kB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] Build-time adjustment of leaf fanout to 32. [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] Architected cp15 timer(s) running at 24.00MHz (phys). [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns [ 0.000005] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns [ 0.000015] Switching to timer-based delay loop, resolution 41ns [ 0.000177] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns [ 0.000338] Console: colour dummy device 80x30 [ 0.000457] console [tty1] enabled [ 0.000477] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=240000) [ 0.000489] pid_max: default: 32768 minimum: 301 [ 0.000591] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.000601] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.001183] Initializing cgroup subsys io [ 0.001206] Initializing cgroup subsys memory [ 0.001233] Initializing cgroup subsys devices [ 0.001246] Initializing cgroup subsys freezer [ 0.001258] Initializing cgroup subsys net_cls [ 0.001269] Initializing cgroup subsys perf_event [ 0.001280] Initializing cgroup subsys net_prio [ 0.001326] CPU: Testing write buffer coherency: ok [ 0.001608] /cpus/cpu@0 missing clock-frequency property [ 0.001624] /cpus/cpu@1 missing clock-frequency property [ 0.001635] /cpus/cpu@2 missing clock-frequency property [ 0.001646] /cpus/cpu@3 missing clock-frequency property [ 0.001656] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.001706] Setting up static identity map for 0x400082c0 - 0x40008318 [ 0.003188] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.003794] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002 [ 0.004381] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003 [ 0.004434] Brought up 4 CPUs [ 0.004457] SMP: Total of 4 processors activated (192.00 BogoMIPS). [ 0.004462] CPU: All CPU(s) started in HYP mode. [ 0.004467] CPU: Virtualization extensions available. [ 0.005236] devtmpfs: initialized [ 0.008510] VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5 [ 0.008791] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 0.009476] xor: measuring software checksum speed [ 0.100016] arm4regs : 1374.400 MB/sec [ 0.200070] 8regs : 853.600 MB/sec [ 0.300118] 32regs : 875.600 MB/sec [ 0.400172] neon : 1284.800 MB/sec [ 0.400179] xor: using function: arm4regs (1374.400 MB/sec) [ 0.400289] pinctrl core: initialized pinctrl subsystem [ 0.401175] NET: Registered protocol family 16 [ 0.402257] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.430217] cpuidle: using governor ladder [ 0.460229] cpuidle: using governor menu [ 0.463480] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers. [ 0.463489] hw-breakpoint: maximum watchpoint size is 8 bytes. [ 0.640516] raid6: int32x1 gen() 153 MB/s [ 0.810656] raid6: int32x1 xor() 122 MB/s [ 0.980708] raid6: int32x2 gen() 205 MB/s [ 1.150708] raid6: int32x2 xor() 132 MB/s [ 1.320896] raid6: int32x4 gen() 217 MB/s [ 1.490956] raid6: int32x4 xor() 134 MB/s [ 1.661036] raid6: int32x8 gen() 198 MB/s [ 1.831261] raid6: int32x8 xor() 128 MB/s [ 2.001304] raid6: neonx1 gen() 482 MB/s [ 2.171292] raid6: neonx1 xor() 358 MB/s [ 2.341441] raid6: neonx2 gen() 638 MB/s [ 2.511510] raid6: neonx2 xor() 468 MB/s [ 2.681684] raid6: neonx4 gen() 781 MB/s [ 2.851753] raid6: neonx4 xor() 530 MB/s [ 3.021840] raid6: neonx8 gen() 707 MB/s [ 3.191990] raid6: neonx8 xor() 498 MB/s [ 3.191997] raid6: using algorithm neonx4 gen() 781 MB/s [ 3.192002] raid6: .... xor() 530 MB/s, rmw enabled [ 3.192008] raid6: using intx1 recovery algorithm [ 3.193335] SCSI subsystem initialized [ 3.193563] libata version 3.00 loaded. [ 3.193849] usbcore: registered new interface driver usbfs [ 3.193907] usbcore: registered new interface driver hub [ 3.193979] usbcore: registered new device driver usb [ 3.194159] media: Linux media interface: v0.10 [ 3.194237] Linux video capture interface: v2.00 [ 3.194317] pps_core: LinuxPPS API ver. 1 registered [ 3.194324] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 3.194348] PTP clock support registered [ 3.195646] clocksource: Switched to clocksource arch_sys_counter [ 3.204138] NET: Registered protocol family 2 [ 3.204750] TCP established hash table entries: 4096 (order: 2, 16384 bytes) [ 3.204800] TCP bind hash table entries: 4096 (order: 3, 32768 bytes) [ 3.204861] TCP: Hash tables configured (established 4096 bind 4096) [ 3.204920] UDP hash table entries: 256 (order: 1, 8192 bytes) [ 3.204953] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes) [ 3.205158] NET: Registered protocol family 1 [ 3.206793] futex hash table entries: 1024 (order: 4, 65536 bytes) [ 3.207175] Initialise system trusted keyring [ 3.214535] zbud: loaded [ 3.217758] JFS: nTxBlock = 3980, nTxLock = 31842 [ 3.222068] SGI XFS with ACLs, security attributes, realtime, no debug enabled [ 3.228863] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249) [ 3.228988] io scheduler noop registered [ 3.229001] io scheduler deadline registered [ 3.229043] io scheduler cfq registered (default) [ 3.231673] sun8i-h3-pinctrl 1c20800.pinctrl: initialized sunXi PIO driver [ 3.287165] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled [ 3.309781] 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 33, base_baud = 1500000) is a U6_16550A [ 3.316332] loop: module loaded [ 3.317466] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 3.317479] ehci-platform: EHCI generic platform driver [ 3.317690] ehci-platform 1c1b000.usb: EHCI Host Controller [ 3.317722] ehci-platform 1c1b000.usb: new USB bus registered, assigned bus number 1 [ 3.318014] ehci-platform 1c1b000.usb: irq 23, io mem 0x01c1b000 [ 3.335658] ehci-platform 1c1b000.usb: USB 2.0 started, EHCI 1.00 [ 3.335937] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 3.335949] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.335958] usb usb1: Product: EHCI Host Controller [ 3.335967] usb usb1: Manufacturer: Linux 4.4.2-sunxi ehci_hcd [ 3.335975] usb usb1: SerialNumber: 1c1b000.usb [ 3.336588] hub 1-0:1.0: USB hub found [ 3.336635] hub 1-0:1.0: 1 port detected [ 3.337151] ehci-platform 1c1c000.usb: EHCI Host Controller [ 3.337187] ehci-platform 1c1c000.usb: new USB bus registered, assigned bus number 2 [ 3.337354] ehci-platform 1c1c000.usb: irq 25, io mem 0x01c1c000 [ 3.355662] ehci-platform 1c1c000.usb: USB 2.0 started, EHCI 1.00 [ 3.355885] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [ 3.355896] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.355905] usb usb2: Product: EHCI Host Controller [ 3.355913] usb usb2: Manufacturer: Linux 4.4.2-sunxi ehci_hcd [ 3.355921] usb usb2: SerialNumber: 1c1c000.usb [ 3.356490] hub 2-0:1.0: USB hub found [ 3.356531] hub 2-0:1.0: 1 port detected [ 3.356975] ehci-platform 1c1d000.usb: EHCI Host Controller [ 3.357001] ehci-platform 1c1d000.usb: new USB bus registered, assigned bus number 3 [ 3.357159] ehci-platform 1c1d000.usb: irq 27, io mem 0x01c1d000 [ 3.375661] ehci-platform 1c1d000.usb: USB 2.0 started, EHCI 1.00 [ 3.375876] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [ 3.375886] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.375895] usb usb3: Product: EHCI Host Controller [ 3.375903] usb usb3: Manufacturer: Linux 4.4.2-sunxi ehci_hcd [ 3.375911] usb usb3: SerialNumber: 1c1d000.usb [ 3.376465] hub 3-0:1.0: USB hub found [ 3.376513] hub 3-0:1.0: 1 port detected [ 3.376913] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 3.376937] ohci-platform: OHCI generic platform driver [ 3.377085] ohci-platform 1c1b400.usb: Generic Platform OHCI controller [ 3.377111] ohci-platform 1c1b400.usb: new USB bus registered, assigned bus number 4 [ 3.377246] ohci-platform 1c1b400.usb: irq 24, io mem 0x01c1b400 [ 3.439939] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001 [ 3.439951] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.439960] usb usb4: Product: Generic Platform OHCI controller [ 3.439968] usb usb4: Manufacturer: Linux 4.4.2-sunxi ohci_hcd [ 3.439976] usb usb4: SerialNumber: 1c1b400.usb [ 3.440557] hub 4-0:1.0: USB hub found [ 3.440599] hub 4-0:1.0: 1 port detected [ 3.441054] ohci-platform 1c1c400.usb: Generic Platform OHCI controller [ 3.441080] ohci-platform 1c1c400.usb: new USB bus registered, assigned bus number 5 [ 3.441230] ohci-platform 1c1c400.usb: irq 26, io mem 0x01c1c400 [ 3.499870] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001 [ 3.499882] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.499891] usb usb5: Product: Generic Platform OHCI controller [ 3.499900] usb usb5: Manufacturer: Linux 4.4.2-sunxi ohci_hcd [ 3.499908] usb usb5: SerialNumber: 1c1c400.usb [ 3.500461] hub 5-0:1.0: USB hub found [ 3.500511] hub 5-0:1.0: 1 port detected [ 3.500914] ohci-platform 1c1d400.usb: Generic Platform OHCI controller [ 3.500938] ohci-platform 1c1d400.usb: new USB bus registered, assigned bus number 6 [ 3.501061] ohci-platform 1c1d400.usb: irq 28, io mem 0x01c1d400 [ 3.559873] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001 [ 3.559885] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.559895] usb usb6: Product: Generic Platform OHCI controller [ 3.559903] usb usb6: Manufacturer: Linux 4.4.2-sunxi ohci_hcd [ 3.559911] usb usb6: SerialNumber: 1c1d400.usb [ 3.560454] hub 6-0:1.0: USB hub found [ 3.560499] hub 6-0:1.0: 1 port detected [ 3.561032] usbcore: registered new interface driver usb-storage [ 3.561655] sun6i-rtc 1f00000.rtc: rtc core: registered rtc-sun6i as rtc0 [ 3.561666] sun6i-rtc 1f00000.rtc: RTC enabled [ 3.561800] i2c /dev entries driver [ 3.562549] sunxi-wdt 1c20ca0.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0) [ 3.562981] sunxi-mmc 1c0f000.mmc: No vqmmc regulator found [ 3.563313] sunxi-mmc 1c0f000.mmc: Got CD GPIO [ 3.595870] sunxi-mmc 1c0f000.mmc: base:0xe0a9c000 irq:22 [ 3.596133] ledtrig-cpu: registered to indicate activity on CPUs [ 3.596211] hidraw: raw HID events driver (C) Jiri Kosina [ 3.596351] usbcore: registered new interface driver usbhid [ 3.596357] usbhid: USB HID core driver [ 3.597206] Initializing XFRM netlink socket [ 3.598159] NET: Registered protocol family 10 [ 3.598926] NET: Registered protocol family 17 [ 3.598966] NET: Registered protocol family 15 [ 3.599020] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this. [ 3.599034] 8021q: 802.1Q VLAN Support v1.8 [ 3.599086] Key type dns_resolver registered [ 3.599529] Registering SWP/SWPB emulation handler [ 3.600217] registered taskstats version 1 [ 3.600232] Loading compiled-in X.509 certificates [ 3.600324] zswap: loaded using pool lzo/zbud [ 3.602858] Btrfs loaded [ 3.603861] Key type encrypted registered [ 3.606926] vcc3v0: disabling [ 3.606946] vcc5v0: disabling [ 3.607251] Waiting for root device /dev/mmcblk0p1... [ 3.634511] mmc0: host does not support reading read-only switch, assuming write-enable [ 3.638260] mmc0: new high speed SDHC card at address aaaa [ 3.638892] mmcblk0: mmc0:aaaa SL08G 7.40 GiB [ 3.640040] mmcblk0: p1 [ 3.655671] usb 1-1: new high-speed USB device number 2 using ehci-platform [ 3.726232] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null) [ 3.726282] VFS: Mounted root (ext4 filesystem) readonly on device 179:1. [ 3.728350] devtmpfs: mounted [ 3.728687] Freeing unused kernel memory: 332K (c086b000 - c08be000) [ 3.806565] usb 1-1: New USB device found, idVendor=0424, idProduct=7500 [ 3.806583] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 3.806591] usb 1-1: Product: USB Gigabit LAN [ 3.806599] usb 1-1: Manufacturer: WS [ 3.806607] usb 1-1: SerialNumber: 0000000814 [ 3.976945] random: systemd urandom read with 3 bits of entropy available [ 3.981373] systemd[1]: systemd 215 running in system mode. (+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR) [ 3.981658] systemd[1]: Detected architecture 'arm'. [ 3.998171] systemd[1]: Set hostname to <orangepione>. [ 4.281398] systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory. [ 4.283822] systemd[1]: Starting Forward Password Requests to Wall Directory Watch. [ 4.284135] systemd[1]: Started Forward Password Requests to Wall Directory Watch. [ 4.284207] systemd[1]: Expecting device dev-ttyS0.device... [ 4.284578] systemd[1]: Starting Remote File Systems (Pre). [ 4.284772] systemd[1]: Reached target Remote File Systems (Pre). [ 4.284879] systemd[1]: Starting Dispatch Password Requests to Console Directory Watch. [ 4.285042] systemd[1]: Started Dispatch Password Requests to Console Directory Watch. [ 4.285095] systemd[1]: Starting Paths. [ 4.285265] systemd[1]: Reached target Paths. [ 4.285372] systemd[1]: Starting Arbitrary Executable File Formats File System Automount Point. [ 4.286081] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. [ 4.286161] systemd[1]: Starting Encrypted Volumes. [ 4.286332] systemd[1]: Reached target Encrypted Volumes. [ 4.286394] systemd[1]: Starting Root Slice. [ 4.286616] systemd[1]: Created slice Root Slice. [ 4.286672] systemd[1]: Starting User and Session Slice. [ 4.286967] systemd[1]: Created slice User and Session Slice. [ 4.287026] systemd[1]: Starting Delayed Shutdown Socket. [ 4.287286] systemd[1]: Listening on Delayed Shutdown Socket. [ 4.287344] systemd[1]: Starting /dev/initctl Compatibility Named Pipe. [ 4.287607] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe. [ 4.287664] systemd[1]: Starting Journal Socket (/dev/log). [ 4.287917] systemd[1]: Listening on Journal Socket (/dev/log). [ 4.287991] systemd[1]: Starting udev Control Socket. [ 4.288213] systemd[1]: Listening on udev Control Socket. [ 4.288282] systemd[1]: Starting udev Kernel Socket. [ 4.288492] systemd[1]: Listening on udev Kernel Socket. [ 4.288569] systemd[1]: Starting Journal Socket. [ 4.288853] systemd[1]: Listening on Journal Socket. [ 4.288963] systemd[1]: Starting System Slice. [ 4.289264] systemd[1]: Created slice System Slice. [ 4.289335] systemd[1]: Starting system-serial\x2dgetty.slice. [ 4.289698] systemd[1]: Created slice system-serial\x2dgetty.slice. [ 4.289754] systemd[1]: Starting system-getty.slice. [ 4.290070] systemd[1]: Created slice system-getty.slice. [ 4.290184] systemd[1]: Starting Increase datagram queue length... [ 4.326210] systemd[1]: Starting Restore / save the current clock... [ 4.330587] systemd[1]: Starting udev Coldplug all Devices... [ 4.333303] systemd[1]: Mounted Huge Pages File System. [ 4.333430] systemd[1]: Mounting POSIX Message Queue File System... [ 4.347015] systemd[1]: Started Set Up Additional Binary Formats. [ 4.347581] systemd[1]: Mounting Debug File System... [ 4.350323] systemd[1]: Starting Create list of required static device nodes for the current kernel... [ 4.376113] systemd[1]: Starting Load Kernel Modules... [ 4.378635] systemd[1]: Starting LSB: Set keymap... [ 4.381124] systemd[1]: Starting Slices. [ 4.381487] systemd[1]: Reached target Slices. [ 4.387551] systemd[1]: Started LSB: Set keymap. [ 4.398581] systemd[1]: Started Create list of required static device nodes for the current kernel. [ 4.399326] systemd[1]: Starting Create Static Device Nodes in /dev... [ 4.434811] systemd[1]: Mounted Debug File System. [ 4.435354] systemd[1]: Mounted POSIX Message Queue File System. [ 4.437743] systemd[1]: Started Increase datagram queue length. [ 4.447076] fuse init (API version 7.23) [ 4.456176] systemd[1]: Started Load Kernel Modules. [ 4.473999] systemd[1]: Started Restore / save the current clock. [ 4.481772] systemd[1]: Time has been changed [ 4.490208] systemd[1]: Started Create Static Device Nodes in /dev. [ 4.524294] systemd[1]: Started udev Coldplug all Devices. [ 4.574479] systemd[1]: Starting udev Kernel Device Manager... [ 4.636321] systemd[1]: Mounting FUSE Control File System... [ 4.638699] systemd[1]: Starting Apply Kernel Variables... [ 4.641750] systemd[1]: Mounted Configuration File System. [ 4.641902] systemd[1]: Starting Syslog Socket. [ 4.642475] systemd[1]: Listening on Syslog Socket. [ 4.642598] systemd[1]: Starting Journal Service... [ 4.646213] systemd[1]: Started Journal Service. [ 4.654732] systemd-udevd[160]: starting version 215 [ 4.880092] cpu cpu0: failed to get cpu0 clock: -2 [ 4.880132] cpufreq-dt: probe of cpufreq-dt failed with error -2 [ 5.092068] smsc75xx v1.0.0 [ 5.165176] smsc75xx 1-1:1.0 eth0: register 'smsc75xx' at usb-1c1b000.usb-1, smsc75xx USB 2.0 Gigabit Ethernet, 80:3f:5d:70:45:80 [ 5.165349] usbcore: registered new interface driver smsc75xx [ 5.561268] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=writeback,commit=600,errors=remount-ro [ 5.657160] Adding 131068k swap on /var/swap. Priority:-1 extents:1 across:131068k SSFS [ 5.681864] systemd-journald[163]: Received request to flush runtime journal from PID 1 [ 6.221570] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 8.559846] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 8.561452] smsc75xx 1-1:1.0 eth0: link up, 1000Mbps, full-duplex, lpa 0xCDE1 [ 70.140896] random: nonblocking pool is initialized Doing this on the Orange Pi One is a bit weird since you would've to waste the only available USB port for an Ethernet dongle now (Ethernet for H3 still not ready in mainline kernel -- we will add this soon to our Armbian H3 Mini FAQ). But at least it serves as a proof of concept, Ethernet is way faster and it worked almost out of the box (I did it mainly to find out what we've to do to tweak auto detection of the OPi in question. Our goal is still to ship with just one OS image for the various H3 boards and adjust everything that's necessary at the first boot).
tkaiser Posted February 27, 2016 Author Posted February 27, 2016 Small update or let's better say a quick look at the direct competition: Banana Pi M2+: 65x65mm in size, GBit Ethernet, 1 GB RAM, AP6212 WiFi/BT (unlike the Orange's WiFi chip this is already supported with mainline kernel), 8 GB eMMC (they already said they might remove this for a cost down variant). Unfortunately not all 3 USB host ports exposed and still relying on the crappy Micro USB connector to power the board. EDIT: build system prepared for M2+ 3 days ago and M2+ maybe fully supported starting with Armbian 5.05 H3-OLinuXino-NANO: Only 50x50mm in size, Fast Ethernet, 512 MB RAM (maybe 1 GB as option/later), also not all 3 USB host ports exposed and using Micro USB for DC-IN Prices/availability yet unknown. Olimex chose to use a fixed voltage on the H3-OLinuXino-NANO so max. cpufreq depends on that (they're still testing). So most probably Orange Pi One will be faster (at least memory bandwidth is 32-bit vs. 16-bit). Regarding Banana Pi M2+ I would be careful unless it's confirmed if/how the CPU's voltage is regulated there and whether they managed to implement a few more design flaws as they did with their last boards. The good news: Since we're already supporting H3 with Armbian only minor modifications should be necessary to support these 2 new boards when they're available. 2
tkaiser Posted March 2, 2016 Author Posted March 2, 2016 Small update on the One: How to fix thermal problems with Orange Pi One? (more interesting for users of other distros since we developed a tool that tries to patch settings for the different voltage regulator on the One) How does switching display settings work on Armbian? (might work for other distros also) And now that most of the stuff is working on H3 with Armbian release 5.04 our users start to produce tutorials: How to get back missing ports on the OPi One with a solder iron? (almost all the ports from Orange Pi PC are still there) Use I2S on Orange Pi To be continued -- the next tutorials that are announced will cover I2C, SPI and dealing with RFID readers: 1
Tido Posted March 6, 2016 Posted March 6, 2016 Small update or let's better say a quick look at the direct competition: Banana Pi M2+: 65x65mm in size, GBit Ethernet, 1 GB RAM, AP6212 WiFi/BT The good news: Since we're already supporting H3 with Armbian only minor modifications should be necessary to support these 2 new boards when they're available. If you want to see this M2+ powered with a coaxial power connector, watch the video. I guess before they sell it, they will replace it with a high-quality MicroUSB connector *ironie*
tkaiser Posted March 16, 2016 Author Posted March 16, 2016 Regarding Banana Pi M2+ I would be careful unless it's confirmed if/how the CPU's voltage is regulated there Since 'Team BPi' released another scary BSP we now know that there's no adjustable voltage regulator so the H3 will be fed all the time with 1.3V and is supposed to run with a maximum clockspeed of 1200 MHz. So the device will consume more and gets hotter than Orange Pi One/Lite and is slower than any other Orange Pi. 'Team BPi' thinks also it's a good idea to kill CPU cores instead of throttling so the board will become way slower when overheating compared to Orange Pi's (at least when the Orange Pis run Armbian). According to the fex they use exactly the same DRAM type as Xunlong on all Orange Pi and also exactly identical GMAC settings but only one USB port? We'll see whether these are just the common copy&paste errors SinoVoip is famous for or this is really an appropriate hardware definition (would be the first board then they ship with) The kernel they use is 3.4.39 cloned from loboris (of course throwing away the whole git history... and hey, why keeping the kernel up to date like Armbian does it -- we ship with 3.4.110 for H3 devices -- if our customers don't care anyway). Kind of fascinating/unbelievable
zador.blood.stained Posted May 3, 2016 Posted May 3, 2016 On @tkaiser's board I'm now reading CPU voltage as 1.13V with PL06 LOW, 1.33V with PL06 HIGH (set in u-boot). But with OS loaded it stays at 1.33 even if I force CPU frequency to 648MHz. So looks like GPIO regulator code in the kernel is broken? dmesg is flooded with these (with different frequencies): [ 12.579768] [cpu_freq] ERR:set cpu frequency to 480MHz failed!
tkaiser Posted May 3, 2016 Author Posted May 3, 2016 [ 12.579768] [cpu_freq] ERR:set cpu frequency to 480MHz failed! Is /boot/script.bin linking to orangepione.bin or any of the other variants that use SY8106A? Since 480 MHz is also an indidication that firstrun detected the wrong board (648 should be minimum currently).
zador.blood.stained Posted May 3, 2016 Posted May 3, 2016 Yes, script.bin symlink was the first thing I checked, it is linked to orangepione.bin 480 is one of the first messages in gmesg, after complete boot-up it complains only about 648 and 720MHz. Output of "cpufreq-info" driver: cpufreq-sunxi CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 2.00 ms. hardware limits: 480 MHz - 1.20 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, interactive, performance current policy: frequency should be within 648 MHz and 1.20 GHz. The governor "interactive" may decide which speed to use within this range. current CPU frequency is 648 MHz (asserted by call to hardware). cpufreq stats: 60.0 MHz:0.00%, 120 MHz:0.00%, 240 MHz:0.00%, 312 MHz:0.00%, 408 MHz:0.05%, 480 MHz:0.00%, 504 MHz:0.00%, 600 MHz:0.00%, 648 MHz:28.16%, 720 MHz:0.00%, 816 MHz:0.00%, 912 MHz:5.69%, 1.01 GHz:35.14%, 1.10 GHz:7.00%, 1.20 GHz:23.95%, 1.30 GHz:0.00%, 1.34 GHz:0.00%, 1.44 GHz:0.00%, 1.54 GHz:0.00% (37) There are also these message with different device addresses Edit: and different i2c buses), Edit 2: but only at the start of boot process: [ 1.325021] sunxi_i2c_do_xfer()985 - [i2c1] incomplete xfer (status: 0x20, dev addr: 0x4e)
tkaiser Posted May 3, 2016 Author Posted May 3, 2016 Yes, script.bin symlink was the first thing I checked, it is linked to orangepione.bin Ok, then maybe this commit was wrong since the driver might only be able to deal correctly with 2 dvfs operating points (this might then also explain this issue). You could try to revert it or to change 648MHz to 816MHz so 1.1V will be entered earlier. But I made the experience that if cpufreq_min is allowed to be lower than the lowest dvfs operating point that the driver gets confused and switches again to the higher voltage. So maybe it's the best to simply revert the commit, see what's happening and then further improve? Entering 1.1V at 816MHz should help with throttling but having 816MHz then also as minimum allowed clockspeed would be a drawback I defined the 648MHz for a reason when playing with OPi One. But maybe I was wrong. Up2u now Regarding the sunxi_i2c_do_xfer issues no clue unfortunately. I think that's spitten out by BSP kernel anyway.
zador.blood.stained Posted May 3, 2016 Posted May 3, 2016 OK, this is more interesting, and the problem is second voltage being "01100" in orangepione.fex root@orangepione:~# grep pmu_level1 orangepione.fex pmu_level1 = 01100 root@orangepione:~# fex2bin orangepione.fex orangepione.bin root@orangepione:~# bin2fex orangepione.bin test.fex fexc-bin: orangepione.bin: version: 0.1.2 fexc-bin: orangepione.bin: size: 35480 (80 sections) root@orangepione:~# grep pmu_level1 test.fex pmu_level1 = 576 root@orangepione:~# fex/bin/fex conversion parsed "01100" as a number in octal (base 8) system, which is normal in IT sphere for numbers with leading zero. Removing leading zero from this number fixes the issue and all works with 4 original operating points.
tkaiser Posted May 3, 2016 Author Posted May 3, 2016 fex/bin/fex conversion parsed "01100" as a number in octal (base 8) system, which is normal in IT sphere for numbers with leading zero. Removing leading zero from this number fixes the issue and all works with 4 original operating points. Great! Thx for finding the culprit and explanantion. And my mistake, I just did copy&paste without thinking. Now it would be cool if you could also test out lower clockspeeds (480MHz being a reasonable lower limit) and see how VDD_CPUX behaves. If we can allow lower minimum clockspeed than lowest dvfs operating point we can revert to 2 dvfs entries (since we only deal with 2 voltages anyway) and use 1.1V for 816MHz already. I currently believe such an error like this has been responsible for the weird results I got back then when I started testing OPi One a few months ago.
zador.blood.stained Posted May 3, 2016 Posted May 3, 2016 [dvfs_table] pmuic_type = 1 pmu_gpio0 = port:PL06<1><1><2><1> pmu_level0 = 11300 pmu_level1 = 1100 max_freq = 1200000000 min_freq = 480000000 LV_count = 5 LV1_freq = 1200000000 LV1_volt = 1300 LV2_freq = 1008000000 LV2_volt = 1300 LV3_freq = 816000000 LV3_volt = 1100 LV4_freq = 648000000 LV4_volt = 1100 LV5_freq = 480000000 LV5_volt = 1100 This seems to work without any issues after changing minimal frequency in /etc/default/cpufrequtils 1
tkaiser Posted May 3, 2016 Author Posted May 3, 2016 This seems to work without any issues after changing minimal frequency in /etc/default/cpufrequtils Great, then we should use these values for OPi One/Lite and NanoPi M1 and also adjust minimal frequency to 480MHz (my attempt to set it to 648MHz back then was most probably the result of testing wrong and running in exactly the issue you explained now! ) I don't think there's an urgent need to push this fix out. Unfortunately current users of Orange Pi One or NanoPi M1 with Armbian 5.10 get Banana Pi M2+ behaviour (always at 1.3V) but even in this situation you would need really heavy workloads to run in troubles (tested it on BPi M2+ and throttling down to 648MHz helps when running the new cpuburn-a7). When 5.11 is released users of Orange Pi One and NanoPi M1 without heatsink get a faster board than with 5.05 due to switching to 1.1V at 816Mhz already since throttling will be more efficient. And the board also stays overall cooler. And in the meantime the fix is documented above
zador.blood.stained Posted May 3, 2016 Posted May 3, 2016 I don't think there's an urgent need to push this fix out. Unfortunately current users of Orange Pi One or NanoPi M1 with Armbian 5.10 get Banana Pi M2+ behaviour (always at 1.3V) but even in this situation you would need really heavy workloads to run in troubles (tested it on BPi M2+ and throttling down to 648MHz helps when running the new cpuburn-a7). If Igor is not busy he can create and push 5.11 board support packages for H3 boards (after all fex files are patched and CPUMIN is updated) and change next version to 5.12 after that.
rodolfo Posted May 3, 2016 Posted May 3, 2016 Fix posted under http://forum.armbian.com/index.php/topic/1122-arisc-errors-have-returned/ 1
aegrotatio Posted May 8, 2016 Posted May 8, 2016 OK, this is more interesting, and the problem is second voltage being "01100" in orangepione.fex root@orangepione:~# grep pmu_level1 orangepione.fex pmu_level1 = 01100 root@orangepione:~# fex2bin orangepione.fex orangepione.bin root@orangepione:~# bin2fex orangepione.bin test.fex fexc-bin: orangepione.bin: version: 0.1.2 fexc-bin: orangepione.bin: size: 35480 (80 sections) root@orangepione:~# grep pmu_level1 test.fex pmu_level1 = 576 root@orangepione:~# fex/bin/fex conversion parsed "01100" as a number in octal (base 8) system, which is normal in IT sphere for numbers with leading zero. Removing leading zero from this number fixes the issue and all works with 4 original operating points. Thank you! This was vexing me for a long time. I knew they had to be changed but had no idea why because the values "look" fine. Great catch!
Lope Posted August 10, 2016 Posted August 10, 2016 My Orange Pi one arrived yesterday. I'd like to mention that I was planning to solder wires to the additional USB D+/D- pins, but they're a lot smaller in real life than I thought they were by looking at the picture. It looks like a very sharp soldering iron tip would be best. They're also a bit hard to access because they're right next to the H3 and near some other taller components. It's a pity Xunlong made the pads so small and close together. It's probably doable, but it will be tricky.
tkaiser Posted August 10, 2016 Author Posted August 10, 2016 It's a pity Xunlong made the pads so small and close together. It's probably doable, but it will be tricky. If you love soldering USB ports for whatever reasons maybe NanoPi NEO is the better board for you (two USB ports available for soldering experiments)? Or using pogo-pins (see post #23 here)? Since I'm pretty bad at soldering I would spend the additional $5 to get an Orange Pi PC or NanoPi M1 if I need all 3 of H3's USB host ports readily exposed.
beic Posted September 13, 2016 Posted September 13, 2016 Hi there, Maybe it's not a good place to ask or post it but,... I received my Orange Pi One today,... Used Rufus to burn the Armbian (Jessie - Desktop) version to Transcend 8Gb MicroSD HC card. It's boots up (restarted), but it stuck after that restart at: orangepi login: and the SMD Green Led on the board start to blink all the time! Do I need to login manually or it need to boot directly to the GUI (Desktop)? Thank you for your answer! Kind regards
Igor Posted September 13, 2016 Posted September 13, 2016 Do I need to login manually or it need to boot directly to the GUI (Desktop)? Yes. First time you need to login via console to change password and add regular user.
beic Posted September 13, 2016 Posted September 13, 2016 Yes. First time you need to login via console to change password and add regular user. Thanks, but how can I do that?!
Igor Posted September 13, 2016 Posted September 13, 2016 There are 3 options: Attach a keyboard + monitor, login via SSH or via serial console. http://docs.armbian.com/User-Guide_Getting-Started/#how-to-login
Recommended Posts