[WiP / Orange Pi One] Support for the upcoming Orange Pi One?

[thc013]

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
 

[tkaiser]

Ok, I'm finished for now and sent some pull requests. Successfully tested Orange Pi One (jessie, no X) and Orange Pi PC (trusty, X and desktop)

 

Major changes:

• Added orangepipc and orangepione to the build system
• Changed kernel source to https://github.com/O-Computers/linux-sunxi/tree/h3-wip
• Since there the GMAC patch for the Plus is already applied I used a reverse patch for Orange Pi PC/One/2
• Added orangepi_h3_gc2305_camera.patch based on @lex' work
• MALI acceleration should work theoretically (not been able to test)

(complete list of Armbian changes, complete list of kernel changes)

 

Main resolved issues:

• dvfs working on Orange Pi One (adjusted cpufreq settings for all H3 Orange Pi)
• average load 0 when idle (USB OTG definition and disabling the vsync processes)
• ability to choose orangepipc and orangepione as target

 

Unresolved issues:

• still no HDMI output

 

TODO:

• testing (especially on the Plus)
• when $BOARD = orangepiplus rename opi_pc_one_disable_gmac.patch to opi_pc_one_disable_gmac.patch.disabled prior to patching
• refactor the whole stuff to base on ssvb's repository again and create one huge patchset to get all stuff fixed
• 1wire still missing
• checking/integrating jernej's patches: https://github.com/jernejsk/OpenELEC-OPi2/tree/master/projects/H3/patches/linux
• somehow deal correctly with HDMI-DVI converters (maybe a 2nd fex file for all H3 devices with the necessary fix?)
• support Orange Pi 2 (hub and Wi-Fi but Ethernet like PC? So just $MODULES definition and fex file adjustment necessary?)
• support Orange Pi Lite (Wi-Fi, one more USB host port, no Ethernet? So just $MODULES definition and fex file adjustment necessary?)
• check whether "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" is still necessary in /etc/rc.local
• check/adjust GPU memory reservations (applies especially to One/Lite)

[zador.blood.stained]

• when $BOARD = orangepiplus rename opi_pc_one_disable_gmac.patch to opi_pc_one_disable_gmac.patch.disable prior to patching

 

You can move this patch to 

lib/patch/kernel/sun8i-default/orangepiplus/

so it will apply only when BOARD=orangepiplus

 

Of course this should be resolved differently later for automated image creation (different kernel package names?)

[tkaiser]

so it will apply only when BOARD=orangepiplus

 

Unfortunately it should work the other way around since I used Yann Dirson's kernel sources where the patch for orangepiplus is already applied. So on all boards != orangepiplus the patch to remove this has to be applied. But since most of the people that looked over this are confident that it should work with one single kernel binary if done correctly this is stuff for the refactoring of all these patches later.

 

I won't touch this stuff in the next time since I already spent too much time on it (busy doing normal work). Next weekend I'll commit the armbianmonitor stuff to Github and send Igor a pull request but then I'm also not able to spend much time on it any further the next weeks.

[zador.blood.stained]

I won't touch this stuff in the next time since I already spent too much time on it (busy doing normal work). Next weekend I'll commit the armbianmonitor stuff to Github and send Igor a pull request but then I'm also not able to spend much time on it any further the next weeks.

OK

 

Unfortunately it should work the other way around since I used Yann Dirson's kernel sources where the patch for orangepiplus is already applied. So on all boards != orangepiplus the patch to remove this has to be applied. 

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

[Igor]

My 5 cents

uname -a
Linux orangepiplus 3.4.110-sun8i

https://github.com/igorpecovnik/lib/commit/abc80fc98893c88e81d286df0094f47b4530ffec

[tkaiser]

3.4.110-sun8i

 

You're crazy

 

Just sent you a pull request to enable 1-Wire. So 'all' that's left is resolving the HDMI issue and checking the CMA/kswapd problem to provide first test images to our users?

[Igor]

It took hours, virtually an whole working day.

 

I also made test images for all three boards, currently uploading to server. OrangePiPlus is tested, others I don't own.

 

HDMI must be related to U-boot ...

[tkaiser]

HDMI must be related to U-boot ...

 

Strange since lima-memtester for H3 uses the very same u-boot version and is able to draw the spinning cube on the display...

 

Anyway -- for the impatient: Igor's test images can be found at the usual location: http://mirror.igorpecovnik.com

 

Regarding the HDMI-to-DVI converter issue: what about something like this added after makeboarddeb.sh's line 117:

case ${i%*.fex} in
	orangepiplus|orangepi2|orangepipc|orangepione|orangepilite)
		sed '/\[hdmi_para\]/a \
hdcp_enable = 0\
hdmi_cts_compatibility = 1\
' <"${SRC}/lib/config/${i%*.fex}.fex" | fex2bin - "${destination}/boot/bin/${i%*.fex}_hdmi2dvi.bin"
		;;
esac

[tkaiser]

My 5 cents

uname -a
Linux orangepiplus 3.4.110-sun8i

https://github.com/igorpecovnik/lib/commit/abc80fc98893c88e81d286df0094f47b4530ffec

 

@Igor: Did you read https://groups.google.com/forum/#!topic/linux-sunxi/9jvMNBD-vV4?

 

I asked Yann in linux-sunxi IRC whether he plans to maintain his h3 fork and the clear answer was no. So what to do? Open question -- currently I have not the slightest idea how to deal with this situation.

 

Yann said he ordered an Orange Pi PC for his personal use (his initial work seemed to be business related) so I would assume once the device arrives he will commit a few fixes. Forking his branch to get a stable base for Armbian will be a burden given the raising popularity of H3 devices (pull requests will happen). So maybe switching back to Siarhei's fork and using a huge initial patchset?

 

Or simply rely on the availability of the repo? I would believe we all agree that relying on this kernel version is just an intermediate action until mainline kernel is ready? On the other hand since Jernej got HW accelerated video decoding working on H3 (something that might never happen with mainline kernel?) this 3.4.something version might be the kernel of choice for some use cases.

[Igor]

Yes, I read. I can't take H3 kernel maintaining either - it's for someone who have more free time.

 

Let's wait and see how things will develop. You did a great job and maybe others will step in with their input as well. It's too much job for a person / few persons.

 

Strange since lima-memtester for H3 uses the very same u-boot version and is able to draw the spinning cube on the display...

 

Don't know. Speculating.

 

Regarding the HDMI-to-DVI converter issue:

 

OK, yes, why not.

[tkaiser]

BTW: Just a quick hack to get RPi-Monitor up and running quickly on a H3 device running 3.4.x kernel (to compare settings for example). The following script will install/setup everything automagically within minutes:

 

install-rpi-monitor-for-h3.sh:

 

 

 

#!/bin/bash
#
# install-rpi-monitor-for-h3.sh -- install eg. with 
# wget -q -O - http://kaiser-edv.de/tmp/4U4tkD/install-rpi-monitor-for-h3.sh | /bin/bash

InstallRPiMonitor() {
	# Installs rpimonitord based on the official instructions from
	# http://rpi-experiences.blogspot.fr/p/rpi-monitor-installation.html
	apt-get -qq -y update
	apt-get -f -qq -y install apt-transport-https ca-certificates
	wget -q http://goo.gl/rsel0F -O /etc/apt/sources.list.d/rpimonitor.list
	apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 2C0D3C0F
	apt-get -qq -y update
	apt-get -f -qq -y install rpimonitor
	# apt-get -f -qq -y upgrade
	/usr/share/rpimonitor/scripts/updatePackagesStatus.pl &
} # InstallRPiMonitor

CheckSunxiTools() {
	which bin2fex >/dev/null 2>&1 || apt-get -f -qq -y install sunxi-tools || InstallSunxiTools
} # CheckSunxiTools

InstallSunxiTools() {
	sleep 5
	apt-get -f -qq -y install libusb-1.0-0-dev || (echo " failed" ; exit 1)
	cd /tmp
	git clone https://github.com/linux-sunxi/sunxi-tools
	cd sunxi-tools
	make
	make install
} # InstallSunxiTools

PatchAndRestart() {
	sleep 2
	cd / && wget -q -O - http://kaiser-edv.de/downloads/RPi-Monitor-for-H3.tgz | tar xzf -
	
	which systemctl >/dev/null 2>&1
	case $? in
		0)
			# Jessie
			systemctl enable rpimonitor-helper
			systemctl start rpimonitor-helper
			systemctl restart rpimonitor
			;;
		*)
			# Wheezy|Trusty
			insserv rpimonitor-helper || update-rc.d rpimonitor-helper defaults 90 10
			cd /tmp && nohup /usr/local/sbin/rpimonitor-helper.sh &
			/etc/init.d/rpimonitor stop
			/etc/init.d/rpimonitor start
			;;
	esac
} # PatchAndRestart

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

if [ "$(id -u)" != "0" ]; then
        echo "This script must be executed as root. Exiting" >&2
        exit 1
fi

MyLog=/var/log/rpi-monitor-install.log
echo -e "$(date) Start RPi-Monitor installation\n" >"${MyLog}"

echo -e "Installing RPi-Monitor. This can take up to 5 minutes. Be patient please\c"
InstallRPiMonitor >>"${MyLog}" 2>&1
echo -e " [x] done\nChecking and installing sunxi-tools if not available\c"
CheckSunxiTools >>"${MyLog}" 2>&1
echo -e " [x] done\nPatching RPi-Monitor to deal correctly with H3\c"
PatchAndRestart >>"${MyLog}" 2>&1

echo -e "\n$(date) Finished RPi-Monitor installation" >>"${MyLog}"
echo -e " [x] done\n\nNow you're able to enjoy RPi-Monitor at http://$((ifconfig -a) | sed -n '/inet addr/s/.*addr.\([^ ]*\) .*/\1/p' | head -1):8888"

 

 

 

It's available here: http://kaiser-edv.de/tmp/4U4tkD/install-rpi-monitor-for-h3.sh and then you can watch the health of your Orange Pi from within a browser window:

 

 

[tkaiser]

Small update: Latest fixes Igor just merged enable 1-wire properly (at least on Orange Pi PC, on the One the connected 18B20 thermal sensors wasn't recognized first since I forgot that the GPIO header is rotated by 180°!). I went the loboris route to use pin 20 (logical) that is physical GPIO pin 37 in reality and added a note to the Wiki: http://linux-sunxi.org/Orange_Pi_PC#1-Wire_support

 

So the main showstopper is non working HDMI at the moment, everything else looks quite good to me.

 

I will leave the H3 Orange Pi playground for now and wait for new heatsinks to arrive to be able to do some more testing regarding cpufreq/dvfs stuff (useless without a heatsink since cpu cores get killed too quickly due to overheating)

[Jacob Gadikian]

@tkaiser

 

Do I understand that the networking now works on the opi-pc?  

 

Or is that just not a showstopper?  

 

Thanks!

 

-Jake

[tkaiser]

Do I understand that the networking now works on the opi-pc?  

 

You're talking about the situation with mainline kernel. Still unresolved/WiP (since Allwinner uses a new IP block for Ethernet on H3, A83T and A64)

 

If we're talking about OS images for H3 boards then three different combinations are in the wild

1. combining Allwinner's 2011.09 u-boot with Allwinner's 3.4.39 kernel (Xunlong/loboris images)
2. combining mainline u-boot 2016.03-rc2 with community 3.4.110 kernel (Armbian and now also Jernej's OpenELEC)
3. combining mainline u-boot 2016.03-rc2 with mainline kernel (Armbian)

Igor started with 3) back in December (IMO not worth to try out now, there are too much patches missing and Ethernet and display stuff isn't working -- but using 'dpkg -i' with these fixes brings you USB and SMP with Mainline kernel).

 

Now we decided to give 2) also a try relying on Yann Dirson's work who adopted many/most of loboris patches. And Igor patched Allwinner's kernel from 3.4.39 up to the most recent 3.4.110 version (the 3.4 LTS version's EOL is estimated September 2016). With the latest fixes applied most of the stuff is working correctly but at least I don't get any HDMI output (maybe my display's broken). So feedback still welcome.

 

As soon as H3 mainline kernel support improves we will also maintain/provide H3 images with kernel 4.5. So the usual 6 variants will be available: Wheezy, Jessie, Trusty (with Desktop) with both legacy and vanilla kernel.

 

But at the moment we need feedback especially for the 3.4.110 version! OS images available from here: http://www.armbian.com/download/ (they don't contain all fixes but that should only affect missing 1-wire functionality and maybe quality of the camera module)

[tkaiser]

Since I'm experiencing rather strange thermal results when comparing Orange Pi One and PC (probably caused by the voltage regulator being somewhat off and we're not switching between 1.1V and 1.3V but slightly higher values) I thought about switching SD cards between One PC to be able to get thermal graphs from both boards in a single RRD database.

 

I thought about automagically exchanging fex files prior to reboot (quite easy) and then thought: "Why not providing one single OS image for all H3 based boards and adjusting everything in firstrun script?"

 

We currently have

1. Orange Pi Plus with GbE (external PHY), USB hub, 8189ES Wi-Fi and SY8106A
2. Orange Pi Plus 2 (same as the above with 2 GB DRAM)
3. Orange Pi 2 with Fast Ethernet, USB hub, 8189ES Wi-Fi and SY8106A
4. Orange Pi 2 Mini with Fast Ethernet, USB hub and SY8106A
5. Orange Pi PC with Fast Ethernet, no USB hub and SY8106A
6. Orange Pi One with Fast Ethernet, no USB hub and SY8113B
7. Orange Pi Lite without Ethernet, no USB hub, 8189ES Wi-Fi and SY8113B

1) and 2) need no differentiation since only the amount of DRAM differs. When dealing with zImage built for the Plus we would've to check for eth0 and if it's there we know we're running on the Plus: keep zImage, u-boot and script.bin

 

3) and 4) need no differentiation since all that differs is Wi-Fi and it doesn't matter if the module is loaded on the Mini 2 or not. So if eth0 isn't there but lsusb lists the Terminus hub we're running on Orange Pi 2 (Mini): exchange zImage/u-boot and use script.bin for OPi 2

 

5) When lsusb doesn't list the Terminus hub then we're running on Orange Pi PC: exchange zImage/u-boot and use script.bin for OPi PC

 

6) or 7) need no differentiation if my assumption is correct that Steven/Xunlong is smart enough to use identical mappings for the 2nd USB host port (usbc2). So in case 'dmesg | grep "ARISC ERROR"' complains about missing SY8106A: exchange zImage/u-boot and use a unified not yet made script.bin for OPi One/Lite (defining 2 USB host ports and Wi-Fi)

 

So we would ship with 2 zImages and 2 u-boot versions, the one for the Plus being the default, then determine on which board we're running in firstrun, adjust everything correctly and after the mandatory reboot everything is up and running automagically.

 

When Olimex' H3-OLinuXino-NANO and H3-OLinuXino will be ready later that year I would suspect we can use the same kernel as for the H3 Orange Pi != Plus (internal Ethernet PHY) and everything's different there is fex stuff. And maybe we're able to detect these boards automagically too.

 

Any thoughts on that?

[Igor]

If we go into consolidation it would be better to expand similar system among all boards, not just Oranges. I am thinking about this for some time.

 

What about to differentiate things in u-boot and use of single sun8i kernel? Is it possible?

[csl1982]

Hi,

 

first, thanks for your efforts. I've just receiver my OPI One, and downloaded your image.

I see that HDMI is not yet available, and it is not a problem for me as ssh works, but one noob question: should I see anything at boot over HDMI - like with a regular pc before booting from the SD card?

 

 

Thanks

[tkaiser]

What about to differentiate things in u-boot and use of single sun8i kernel? Is it possible?

 

You speak about different Ethernet initialisation for Orange Pi Plus and the other boards? If so I still don't know but most likely it should be possible with a single kernel binary for all sun8i devices. BTW: Siarhei started a more generic attempt to support all Allwinner devices from within u-boot:

 

http://lists.denx.de/pipermail/u-boot/2015-January/202309.html

https://github.com/ssvb/sunxi-bootsetup/releases/tag/20141215-sunxi-bootsetup-prototype

 

The most critical part with such a setup might be update/upgrade procedure?

 

should I see anything at boot over HDMI - like with a regular pc before booting from the SD card?

 

Nope, unless you use FEL boot or boot from SD card or NAND/eMMC you won't see anything on Allwinner devices. And even then with our H3 images at the moment there won't be HDMI output (we suspect it's an u-boot issue but I'm still not sure but stopped testing it since it's already too time consuming -- it might be worth a look how the OpenELEC folks solves this since they use the same u-boot/kernel configuration like we. But I lost my logon credentials to the Orange Pi forum and they never sent out a mail when I requested a password reset)

[funkypunkskunk]

For what it's worth, i've booted my orange pi one with the jessie legacy image and built a wireless hotspot with it - using a usb with ap mode enabled. 

 

The dongle was a rather cheap chinese one, and melted (literally) halfway through the night and stopped working. I managed to get the pieces out and of the usb port and it was still functional. 

 

Tried another dongle and right now I've a orange pi one with just the power supply connected beside me. I just ssh into it if I want to fix something. And i can use it as a hotspot to connect wireless clients to it. 

[tkaiser]

Since I'm experiencing rather strange thermal results when comparing Orange Pi One and PC (probably caused by the voltage regulator being somewhat off and we're not switching between 1.1V and 1.3V but slightly higher values) I thought about switching SD cards between One PC to be able to get thermal graphs from both boards in a single RRD database.

 

Finished with this and it's time to draw conclusion or ask questions. Same installation running on One until 17:05 and then on PC:

 

 

 

Test setup as follows: Identical SD card, just exchanged script.bin and tested with One/PC lying flat at the desk at the same location with only Ethernet and power connected (no heatsink applied): Simple test: Idling through different dvfs operating points:

 

Orange Pi PC with SY8106A/ssvb settings:

 

Idle at 648 MHz @ 1040mV: 29°C / 1.3W

Idle at 1296 MHz @ 1340mV: 36°C / 1.6W

 

Orange Pi One with SY8113B/tkaiser settings:

 

Idle at 648 MHz @ 1100mV: 45°C / 1.6W

Idle at 1200 MHz @ 1300mV: 55°C / 2.0W

 

There's clearly something wrong (and Orange Pi PC would shine even more with default Armbian settings since for whatever reasons our Plus/PC fex files do not contain ssvb/linux-sunxi dvfs settings but my experimental from last year instead so temperatures would be even lower due to lower Vcore voltage)

 

Unfortunately I have not the slightest idea what's going on. The SY8113B voltage regulator is said to support just switching between 1.1V and 1.3V. As a reference the very same test with Orange Pi PC without heatsink and based on loboris Ubuntu Mate image. Vcore voltage was even 200mV higher between lowest and highest clockspeed!

 

Idle at 480MHz @ 1300mV: 48°C / 1.7W

Idle at 1536MHz @ 1500mV: 60°C / 2.1W

 

Under the assumption that we're not really switching between 1100mV and 1300mV on Orange Pi One but instead 1270mV and 1470mV (massive overvolting!) the results back then and now would match perfectly. So unlike someone in Orange Pi forums told me SY8113B will not just switch between 1.1V and 1.3V but exceeds these voltages by approx. 170mV (which seems possible after studying the datasheet "Vout=0.6*(1+R1/R2)")

 

Since Xunlong doesn't provide schematics it's a bit useless to further investigate. On the other hand I don't trust the thermal read-outs we now get that much (29°C idle temp without heatsink at an ambient temperature of 24°C is crap especially since Orange Pi PC reports after a cold boot an internal temperature that is below ambient -- simply impossible)

 

I would suspect we have two issues:

• wrong thermal read-outs (relevant for 'budget cooling'/thermal throttling)
• wrong configuration of SY8113B step-down converter (most probably leading to overvolting the SoC -- conclusion more based on idle consumption than temperatures)

Update: Temperature read-outs definitely wrong. 34°C temperature reported, I put my thumb on the SoC (definitely hot) and reported temperature decreases by 3°C -- since i would assume my own temperature is at ~37°C this is a clear sign for wrong temperature (calibration).

[Igor]

 

You speak about different Ethernet initialisation for Orange Pi Plus and the other boards? If so I still don't know but most likely it should be possible with a single kernel binary for all sun8i devices. BTW: Siarhei started a more generic attempt to support all Allwinner devices from within u-boot:

 

http://lists.denx.de...ary/202309.html

https://github.com/s...setup-prototype

 

The most critical part with such a setup might be update/upgrade procedure?

 

I saw that some time ago. That's user selected u-boot ... I would prefer auto selection like my bash script do (armhwinfo) but that's probably a little harder.

[tkaiser]

I've just receiver my OPI One, and downloaded your image.

 

For what it's worth, i've booted my orange pi one with the jessie legacy image

 

It would be great if you could contribute to resolving the thermal/dvfs issues by installing RPi-Monitor (see above -- it's just a matter of a few minutes if you use the script I provide) and reporting back which idle/ambient temperature you can read-out.

[csl1982]

It would be great if you could contribute to resolving the thermal/dvfs issues by installing RPi-Monitor (see above -- it's just a matter of a few minutes if you use the script I provide) and reporting back which idle/ambient temperature you can read-out.

 

I guest this is the information you need:

 

Load:

1 min - 0.04

5 min - 0.32

15 min - 0.37

 

Temp - SoC: 43°C

 

Room temp ~20°C, the board is not yet in a case, as they left out of my package   

 

 

[tkaiser]

Temp - SoC: 43°C [...] Room temp ~20°C, the board is not yet in a case

 

Great, so at least I'm not alone with my read-outs. In the meantime I tried it again with loboris' kernel and our script.bin just to realise that his thermal read-outs match reality more closer. Just created a patch for this, recompiled the kernel and tested. Unfortunately to no avail: I still get thermal values that are way too low.

 

Simple test on an Orange Pi PC that reports eg. 36°C: Press carefully a finger on the SoC (acting like a heatsink) to realise temperature decreases down to 32°C (impossible -- and with loboris kernel it was 45°C decreasing down to 41°C which makes sense since my finger is at ~37°C)

 

Currently I test with loboris' kernel and our fex for the Orange Pi One. Be prepared that SoC temperature is a few degrees higher in reality. And it seems we really suffer from an overvoltage problem on the One. It's not 1.1V/1.3V but most likely 200mV more each

[zurueck]

I also recently became the owner of an orange pi one.

But I have a more serious problem with overheating than other people. Maybe my Opi One defective(?)

Or pin(pmu_gpio0 = port:PL06<1><1><2><1>)configuration is wrong?

Or, these values must be other:

pmu_level0 = 11300 - there should be 5 digits?

pmu_level1 = 1100 - but there 4 digits?

 

; pmuic_type:0:none, 1:gpio, 2:i2c
; pmu_gpio0: gpio config.

 ; pmu_levelx: 0~9999: voltage(mV), 10000~90000:gpio0 state. voltage form high to low.

If we used gpio configuration, there should be values 10000 + 1300 = 11300, and 10000 + 1100 = 11100?

 

I tried a different configuration of script.bin(with different parameters of these values), different distributives - armbian, lubuntu from Jacer(from Opi PC, works adequately with low ram consumption - at least before overheating), lubuntu from Loboris(from Opi PC) and other. 
In all cases, with a small aluminium heatsink with thermal paste
 - the temperatures in the idle approximately 60(according to sensor) 
 - with chromium and web benchmarks in less than 10 minutes - up to 80 degrees, turning off cores(in htop), lags and throttling.

By touch - SoC extremely hot, even network connector case is hot.

It may be defective, or the five hours uptime at this temperatures have damaged the chip or power elements on board? 
I do not know what to do, maybe wait for oficial images, especially script.bin, from manufacturer. 

 

I do not understand why there is still no software support from the manufacturer, if the difference in comparison with the Opi PC is minimal - only removed some modules and port. The only significant difference is the charge controller.

 

Pardon for my bad english.

[tkaiser]

Please look at the comments here: https://github.com/O-Computers/linux-sunxi/blob/h3/drivers/arisc/interfaces/arisc_dvfs.c#L219-L225

pmu_level0 = 11300 # read as: GPIO state 1, voltage 1300
pmu_level1 =  1100 # read as: GPIO state 0, voltage 1100

Obviously only 2 states are used and the Vcore voltage supplied to the SoC depends on a resistor that is switched through GPIO. Vcore voltage is then defined as: Vout=0.6*(1+R1/R2). Do we have schematics for Orange Pi One? No. Do we know the tolerances of these resistors? No.

 

It's obvious that switching between both voltages work (therefore definition of pmu_gpio0 is correct) but I doubt we're switching between 1.1V (648 MHz) and 1.3V (everything above) but instead 200mV more (which would violate the H3's specs). What's also problematic: The kernel Armbian uses shows wrong thermal read-outs. And when looking at loboris kernel read-outs (closer to reality) and also having a look at the consumption then it gets even more weird (since with loboris' kernel consumption is 0.4W higher -- maybe caused due to different u-boot used).

 

Just tested again:

 

Orange Pi One with SY8113B/tkaiser settings and Armbian kernel (thermal read-outs too low!):

 

Idle at 648 MHz: 45°C / 1.6W

Idle at 1200 MHz: 55°C / 2.0W

 

Orange Pi One with SY8113B, tkaiser settings and loboris kernel:

 

Idle at 648 MHz: 56°C / 1.9W

Idle at 1200 MHz: 67°C / 2.4W

 

As a reference Orange Pi PC with SY8106A, loboris settings and loboris kernel back in December:

 

Idle at 480MHz @ 1300mV: 48°C / 1.7W

Idle at 1536MHz @ 1500mV: 60°C / 2.1W

 

Now measured again:

 

Idle at 480MHz @ 1300mV: 51°C / 1.9W

Idle at 1536MHz @ 1500mV: 66°C / 2.6W

 

 

BTW: I'm not even able to reset my password at the crappy Orange Pi forum since they do not send out any emails on request. They don't care about their forums, they don't release schematics, they don't release OS images, they don't release informations. That's what to expect for $9.99

[tkaiser]

BTW: If anyone wants to look into the problem with our kernel reporting wrong thermal values. I started adopting loboris' changes: https://github.com/ThomasKaiser/lib/commit/93d50e2df130fd5a7d0d2e9036b15368be38fe5a

 

The only change to that was to enable 1296MHz in default_budgets_table and to adjust the values to the one from the Orange Pi PC's new fex file (if something's defined in fex/script.bin this stuff has no relevance at all)

[zurueck]

 

 

Now I understand that the values from 0 to 9999 is a logical 0 for the GPIO pin - 1.1V, and the values of 10000 to 99999 is a logical unit and 1.3V.

 

But how do you know that the voltage is higher than 0.2V? Tried to measure the voltage directly on the chip with multimeter?

Pinout H3 probably is in the public domain.

 

If we confirmed this "0.2V overstatement", the sequential addition of the resistor can be solve the problem with the heating. But all this can be done only after receiving schematics from producer.

 

I also can not get an email, even to confirm my account. And right of this unverified user does not even have to watch forum and threads.

Hope some kind of software support will be(maybe even this month ).

[ivann]

 

BTW: I'm not even able to reset my password at the crappy Orange Pi forum since they do not send out any emails on request. They don't care about their forums, they don't release schematics, they don't release OS images, they don't release informations. That's what to expect for $9.99

 

 

I have not problem with reg. on OPI forum.

Try this: xxxxxxx - in message

 

P.s:

I have OPI ONE and CPU temp is 44C with no load (46C in start). I will put finger on the CPU and CPU not hot . I think, the problem is not overheating, but the problem is in the calculation only.