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

[rreignier]

Oh, your quote is quite right in my case

 

I have tried:

dmesg | grep oom-killer

But I did not get any result.

 

Looking at dmesg, the only output I had during the test was only a LOT of lines like this one;:

[ 2339.900090] [ddrfreq] temperature=70 C, ddr freq up

[tkaiser]

[ http://www.brendangregg.com/activebenchmarking.html ]

Oh, your quote is quite right in my case

 

That happens most of the times.

 

When I started with this SBC stuff I tried out 2 different 'distros' for the Cubietruck. One worked perfectly, the other not. A few days later it changed for no apparent reason. And a few days later I realised that I didn't test 2 OS images (software) but two SD cards (hardware) instead. Lesson learned: Never ever use any of these cards without checking first: https://github.com/igorpecovnik/lib/blob/master/documentation/user-faq.md#how-to-prepare-sd-card/  (background info: http://www.bunniestudios.com/blog/?page_id=1022)

 

The 'oom-killer' was just meant as an example: you think you started 4 or 8 threads $something to put some load on your machine for stresstests just to realise (way too late) that the kernel killed all but one for whatever reason. Without some sort of realiable monitoring (in our case the lightweight rpimonitord) you're always lost since you draw wrong conclusions way too easy/early.

[bjorn]

Another update. To change easily the HDMI resolution and take care of HDMI-to-DVI converters (they need special settings otherwise display shows wrong colors), I improved h3disp a bit. Unless this is part of new OS images you can grab it at the usual location: http://kaiser-edv.de/tmp/4U4tkD/h3disp.sh

 

45a304303f51053402be6e60d1706399  h3disp.sh

 

If called without arguments it just outputs a help text now. But you can specify display resolution and whether you've to use DVI or HDMI on the command line:

root@orangepione:~# h3disp.sh -m 348974398
/usr/local/bin/h3disp.sh: Illegal video mode "-m 348974398". Try one of the following:

    480i        use "-m 480i" or "-m 0"
    576i        use "-m 576i" or "-m 1"
    480p        use "-m 480p" or "-m 2"
    576p        use "-m 576p" or "-m 3"
    720p50      use "-m 720p50" or "-m 4"
    720p60      use "-m 720p60" or "-m 5"
    1080i50     use "-m 1080i50" or "-m 6"
    1080i60     use "-m 1080i60" or "-m 7"
    1080p24     use "-m 1080p24" or "-m 8"
    1080p50     use "-m 1080p50" or "-m 9"
    1080p60     use "-m 1080p60" or "-m 10"

 Two examples:

    h3disp -m 1080p60 -d' (1920x1080@60Hz DVI)
    h3disp -m 720i' (1280x720@30Hz HDMI)

Simply save it as /usr/local/bin/h3disp.sh, make it executable (chmod 755 /usr/local/bin/h3disp.sh) and enjoy resolution switching the easy way (just kidding -- but at least it's easier than tweaking fex files manually -- our goal is still to provide a solution to use any display resolution sometimes in the future).

 

BTW: The script should also work with Xunlong's or loboris' OS images but untested there. Feedback welcome.

 

This is awesome, thanks, I tried this on Orange PI 2, and it works great, first time I ever see Orange PI on other resolution.

[ipsilondev]

HI,

 

i just want to report my experience with Armbian_5.03_Orangepione_Debian_jessie_3.4.110 image. i had a very strange behavior, not consistent at all when using tthe DVI script.bin file (i have erased symbolic link /boot/script.bin that pointed to /boot/bin/orangepione.bin and replaced it with a new one pointing to orangepione_hdmi2dvi.bin). i'm also using a passive hdmi to dvi adapted in a LG LCD with DVI-D input.

 

i have 5 boards, all of them orange pi one, and i tested in 3 of them, with this result:

 

1) first one, booted successfully, and showed the console, i could actually used it, but cfinteractive, used 100% of the cpu, oscilating the load between 2.0 and 3.0, with a notorious lag at tipping. i shutdown the device with shutdown -h now. unplugged and reviewed the .bin file to see if dvfs config was the one for the overpowered board. it was. i tried to boot again, but i had no image.

 

2) i tried with a second board, same SD card. this showed a picture, but then i saw a message that the third core halted 22s. then black screen and i never saw an image.

 

3) third board, it boot, show the console, with glitches, then suddenly image dissapear, and never saw the image again.

 

i tested several times with new images, tested the 3 boards again too with the default hdmi image, and had no troubles at all. no load, no temperature.

 

when it was on DVI mode, the temp was 33c, when was in hdmi mode, was in 40c.  with a base temp of 29.3c/30c

 

so, if someone wants me to do some other kind of testing, i'm willing to help in anyway i can. i will try tomorrow to set up the SSH connection to the board, so i could get the console stream, see logs and execute code in the meantime is plugged into the monitor with no image.

[tkaiser]

Armbian_5.03_Orangepione_Debian_jessie_3.4.110 image

 

This is pretty outdated (over 3 days old). Please try it with the Jessie image from here again: http://forum.armbian.com/index.php/topic/617-wip-orange-pi-one-support-for-the-upcoming-orange-pi-one/?p=5476

 

And please be patient, the 1st automated reboot may take some time (up to 2-5 minutes). Regarding DVI please read the next post too and consider installing RPi-Monitor to be able to report more precisely what's going on.

 

Please also be patient regarding next steps. Igor's out of lab now so expect new images in a few days.

[ipsilondev]

This is pretty outdated (over 3 days old). Please try it with the Jessie image from here again: http://forum.armbian.com/index.php/topic/617-wip-orange-pi-one-support-for-the-upcoming-orange-pi-one/?p=5476

 

And please be patient, the 1st automated reboot may take some time (up to 2-5 minutes). Regarding DVI please read the next post too and consider installing RPi-Monitor to be able to report more precisely what's going on.

 

Please also be patient regarding next steps. Igor's out of lab now so expect new images in a few days.

 

i'm not in a hurry, just trying to help

 

i will download this one and try it to see if it improves.

 

i want to be clear that all that happened with the DVI support, was AFTER the first reboot, that i made using the hdmi mode.

[tkaiser]

i want to be clear that all that happened with the DVI support, was AFTER the first reboot, that i made using the hdmi mode.

 

The changes in our build system removed the duplicate fex files for DVI mode already since with the next images h3disp is included (add the -d switch in your case and choose one of the available resolutions). OPi users -- especially OPi 2 (or 2 Mini) owners -- can have a look at these three preliminary builds:

 

cbd303d71da6207e727f60c5943954ff  Armbian_5.03_Orangepih3_Debian_jessie_3.4.110.zip

71087e71c0ab226f15800b29a648ffcb  Armbian_5.03_Orangepih3_Debian_wheezy_3.4.110.zip

9459673a680eb8bfa3c33f48d4481a13  Armbian_5.03_Orangepiplus_Debian_jessie_3.4.110_desktop.zip

 

Available as usual from http://kaiser-edv.de/tmp/4U4tkD/ until Igor's back.

 

Feedback needed especially from Orange Pi 2 [Mini] users. Regarding Wi-Fi it seems necessary to add 8189es manually to /etc/modules. And Wi-Fi might not work afterwards since untested and I have no Orange Pi with Wi-Fi. If you've trouble with Wi-Fi and are able to resolve it detailed feedback welcomed.

[tkaiser]

Small update: Regarding the upcoming 5.04 release of the images (will be mostly identical with the images you can try out from the link in the post above) I created a mini FAQ.

 

Please don't ask when they're released -- I simply don't know, we'll have to wait for Igor getting back

[yovio]

Hi Igor,

 

I made a patch file for u-boot mmc driver to support slow/cheap MMC card. I have submit pulled request, please review it.

[ipsilondev]

tested the new image, jessy version, directly with DVI, it booted the first time, showing image, and after the reboot, i had no image over DVI (i could access, through ssh). i'm attaching the log.

 

i tested the ubuntu version with XFCE, and that worked perfectly (but i started it first with HDMI).

orangepione-jessy-25-02-2016.zip

[tkaiser]

BTW: I think Armbian could have kswapd issue too if some memory heavy process is run.

 

Ok, will try this out next. Does the machine really swap or is just the daemon busy? I ask since I could try to test it automated and look at RPi-Monitor graphs later (would safe some time).

 

BTW: Why do you set gpio set PG11 for all boards now and not only the Plus (where it should fix the 'SATA' issue?). And can you please elaborate a bit on your latest changes? Adding 'noram' to kernel command line and the CMA stuff?

[tkaiser]

tested the new image, jessy version, directly with DVI, it booted the first time, showing image, and after the reboot, i had no image over DVI (i could access, through ssh)

 

Ok, to get an idea what's going on. We're speaking about this image?

 

cbd303d71da6207e727f60c5943954ff  Armbian_5.03_Orangepih3_Debian_jessie_3.4.110.zip

 

Then: When you started the first time with the One connected through DVI did you get a purple or black background on the display? And please execute

h3disp -m4 -d -v

and post the support URL here. Thx

[tkaiser]

the red LED comes on initially, but then turns off again after a period of time

 

Thanks for bringing this to our attention (user feedback through led). I now implemented that the red LED lights all the time (can be disabled with 'echo none >/sys/class/leds/red_led/trigger' eg. in /etc/rc.local) and that it starts to blink after the first boot to indicate that's something important going on and the user should wait for the 1st automated reboot without interrupting it (works with legacy kernel but not vanilla, there currently the leds don't work)

 

 I will start testing I2C.

 

It would be great if you could test again with either Armbian_5.03_Orangepih3_Debian_jessie_3.4.110.zip or Armbian_5.03_Orangepih3_Debian_wheezy_3.4.110.zip from http://kaiser-edv.de/tmp/4U4tkD/ again and provide some sort of a mini tutorial to get I2C with a device up and running. I'm a bit worried since we get I2C error messages with every boot and I'm not able to even see the SY8106A 'PMIC' with i2cdetect on the PC.

 

Any chance you've SPI devices lying around to test with?

 

and perhaps increase the DRAM speed to the "listed" value.

 

If you do this please do a before/after test and report back. The difference between 624 MHz and 672 MHz DRAM clockspeed when we're talking about performance is laughable and by staying at the lower level we increase reliability (you really don't want bit flips to occur) and even more importantly: a lower DRAM clockspeed leads to more realistic temperatures reported from the internal H3's thermal sensor. Which is good since then we've also same safety headroom regarding thermal throttling (first tests showed that the driver that reads out the sensor's value reports thermal values being too low when we're combining mainline u-boot with Allwinner's old 3.4.x kernel as Armbian does now)

[jernej]

Ok, will try this out next. Does the machine really swap or is just the daemon busy? I ask since I could try to test it automated and look at RPi-Monitor graphs later (would safe some time).

 

BTW: Why do you set gpio set PG11 for all boards now and not only the Plus (where it should fix the 'SATA' issue?). And can you please elaborate a bit on your latest changes? Adding 'noram' to kernel command line and the CMA stuff?

 

Ok, I didn't try this systematically. Most probably everything is ok now that I think about it.

 

PG11 pin is used on every board except on OPi2 where is unused and it is safe to toggle it. On Plus it is for enabling SATA & USB, on PC and One it is for enabling CSI port. At least I think it is and I love unified things

 

About "noram" and CMA: I tried hard to solve this issue, especially because on Armbian everything was ok but not on OpenELEC. I come to the point that I set every thing in kernel that is set for Armbian, even if it was suboptimal. Issue was still there. After that I realized that issue is somewhere else. First I thought about initramfs, but then I figured out that it is not in the CMA controlled RAM region. At the end, I remembered that OpenELEC has some switches which are passed via kernel command line. You can check here what this means. Basically it changes the way how root filesystem is mounted.

[emsi88]

Hi all, I'm new there. Good job Igor and Tkaiser, thank You, I donate.

 

I have two boards PC and One(also BananaPI,RPi etc....

 

I can help with test DRAM speed, but how I can enter to FEL mode ? I have UART but if I connect board without SDcard, nothing shown...

[tkaiser]

PG11 pin is used on every board except on OPi2

 

Understood (also the 'noram' stuff). BTW: Do you have an Orange Pi 2? We're currently missing user feedback for the 2 since none of the users with this board got back to us. In case you've a 2 it would be great if you could try out http://kaiser-edv.de/tmp/4U4tkD/Armbian_5.03_Orangepih3_Debian_jessie_3.4.110.zipand report at least the output of dmesg, lsmod and "cat /proc/interrupts". In the meantime I don't care whether WiFi works on any of the Orange Pi boards since user feedback here really sucks.

 

I can help with test DRAM speed, but how I can enter to FEL mode ? I have UART but if I connect board without SDcard, nothing shown...

 

If no SD card is inserted One and PC fall back to FEL mode. Then you could use another Linux host to load u-boot and additional stuff through USB. We're currently evaluating to include these parts in every Armbian image (so you could use an ODROID XU4 to fel-boot a Banana Pro for example)

 

BTW: Anyone here with device tree knowledge? It would be great if we could get all this LED stuff working with mainline kernel since user experience especially when starting our images the first time (automatic reboot -- please do not interrupt) is important. By looking at this thread it seems to me adding this would be easy (dislcaimer: not knowing that much about DT!)

[rreignier]

Hi,

 

The mini FAQ is a good idea, it is nice to have all the infos gathered in one place. There should be a link in the Download page of the different H3 boards.

 

Tonight, I have planned to test i2c and SPI but I don't have many experience on that field on Linux because until now I have mostly used libraries on the RPi so everything was working out of the box.

 

I have spent some time to understand the GPIO system. I was trying to use the classical /sys/class/gpio/gpioX structure like explained in the linux-sunxi wiki but most of the GPIOs were "busy" (only the 4, 5, 11, 12 were free and 11 and 12 drive TWI0_SDA and TWI0_SCK, respectively PA11 and PA12). Then I have figured that the GPIOs are already exported in /sys/class/gpio_sw. I found it strange that it was different than the wiki.

But with this issue, I did not have enough time to test the SPI and i2c yet. I won't be able to test them before next week

 

I have tested the UART1 and trying to use UART1_RTS signal to trigger a RS-485 transceiver but I have measured a 3 ms turnaround (the delay to put back the transceiver in receiver mode after the transmission) and it is too long for my application. There is no RS-485 driver for Allwinner (yet). But the UART1_RX and UART1_TX work well for classical communication.

I have also tried some USB Wifi dongles. The one based RT5370 works well, but the other one, an Atheros AR9271 (which is one of the only Wifi chipset with a full open source driver since Linux 2.6) did not work because the firmware htc_9271.fw was missing:

[    5.503980] usb 2-1: ath9k_htc: Firmware htc_9271.fw requested
[    5.517296] usb 2-1: ath9k_htc: Failed to get firmware htc_9271.fw

While talking about drivers, it would be nice to have the Linux USB Gadgets modules (g_serial, g_ether, g_mass_storage, g_multi) available for the OTG port. I found them very useful to connect to the board and get a serial port and network connection when the Wifi or Ethernet is not set.

[Igor]

The mini FAQ is a good idea, it is nice to have all the infos gathered in one place. There should be a link in the Download page of the different H3 boards.

 

It is now.

[kripo]

Hey there!

First of all, thx for your affort to get this little thing running! I just got mine, and the first thing i noticed was that it is bended... just a little bit, but nevertheless recognizably bended. am i the only one?

 

EDIT: my orange pi one seems to have the same overvolting/overheating problem. i would try to measure v12c with my multimeter... but i am not totaly shure how...

 

EDIT 2 : i measured 1,122V in idle and 1,340V under load

[martinayotte]

It would be great if you could test again with either Armbian_5.03_Orangepih3_Debian_jessie_3.4.110.zip or Armbian_5.03_Orangepih3_Debian_wheezy_3.4.110.zip from http://kaiser-edv.de/tmp/4U4tkD/ again and provide some sort of a mini tutorial to get I2C with a device up and running. I'm a bit worried since we get I2C error messages with every boot and I'm not able to even see the SY8106A 'PMIC' with i2cdetect on the PC.

 

Any chance you've SPI devices lying around to test with?

 

I've already done some I2C tests on port TWI1, and it is working fine. I was using python library orangepi_PC_gpio_pyH3-master. I will try the same on TWI0 when I get the chance.

About SY8106, I've look at the schematic and it seems to be hook up on another port, the PL00 and PL01 pins, which seems to be defined in FEX as follow :

[s_rsb0]
s_rsb_used = 1
s_rsb_sck = port:PL00<2><1><2><default>
s_rsb_sda = port:PL01<2><1><2><default>

But I don't know how to access them. Is RSB other kind of Kernel driver ? Maybe we need to copy/paste an existing TWI and tweak it to use those 2 pins, I'm really not a FEX expert ...

 

SPI ? I've never tried it under Linux, but I will do, but need to learn about it first, although I know SPI under smaller MCU such STM32. I've several devices to try such SPI Flash or LCD.

 

EDIT : TWI0 is also working fine.

 

EDIT2 : doing some search about RSB, I've found that means "Reduced Serial Bus", and there are commits about it in linux-vanilla/v4.4.1/drivers/bus/sunxi-rsb.c, but nothing in legacy 3.4.

I've also seen some posts/commits in Mainline about "drivers/i2c/busses/i2c-sunxi-rsb.c"

[jernej]

I have also tried some USB Wifi dongles. The one based RT5370 works well, but the other one, an Atheros AR9271 (which is one of the only Wifi chipset with a full open source driver since Linux 2.6) did not work because the firmware htc_9271.fw was missing:

[    5.503980] usb 2-1: ath9k_htc: Firmware htc_9271.fw requested
[    5.517296] usb 2-1: ath9k_htc: Failed to get firmware htc_9271.fw

 

Kernel is missing support for loading firmware directly. Patch is needed for that, because newer versions of systemd doesn't support that functionality.

 

 

BTW: Do you have an Orange Pi 2? We're currently missing user feedback for the 2 since none of the users with this board got back to us. In case you've a 2 it would be great if you could try out http://kaiser-edv.de/tmp/4U4tkD/Armbian_5.03_Orangepih3_Debian_jessie_3.4.110.zipand report at least the output of dmesg, lsmod and "cat /proc/interrupts". In the meantime I don't care whether WiFi works on any of the Orange Pi boards since user feedback here really sucks.

[...]

 

BTW: Anyone here with device tree knowledge? It would be great if we could get all this LED stuff working with mainline kernel since user experience especially when starting our images the first time (automatic reboot -- please do not interrupt) is important. By looking at this thread it seems to me adding this would be easy (dislcaimer: not knowing that much about DT!)

 

Will do, but not before sunday evening I'm afraid. I have some limited knowledge of DT, because I tried to enable leds in mainline U-Boot This feature is a bit harder in U-Boot but should be easy in mainline kernel. I can try sometime next week if you want.

[tkaiser]

EDIT 2 : i measured 1,122V in idle and 1,340V under load

 

That seems quite ok. But the temperature doesn't match at all. You could try to adjust MAX_SPEED in /etc/default/cpufrequtils so that it also reads 648000 (just a try)

 

EDIT: Have you checked real temperatures? Eg. trying to touch the SoC shortly and get at least a feeling whether it's that hot as shown in the graphs? But I would adjust cpufreq settings first since I woudln't that anything that hot with a finger.

 

 TWI0 is also working fine.

 

Thx for the confirmation! I'm currently lacking a bit spare time and can't do this stuff by myself. But it would be really great if we could collect some of this stuff in a tutorial like manner. No idea where (maybe linux-sunxi wiki that will then not only be the place for geek stuff but also user tutorials) but I strongly believe that we need some tutorials that are freely available and show at least the differences to the many thousand RPi tutorials available on the net. 

 

Kernel is missing support for loading firmware directly. [...] I have some limited knowledge of DT, because I tried to enable leds in mainline U-Boot

 

LOL, I think I now know why Armbian still doesn't include this patch. I thought a few hours ago 'damn, you forgot to include an important patch', tried to apply the patch from your repo just to realise that compilation breaks (I tried it already two times in the last few days). This time I submitted the patch disabled so others with more knowledge could have a look into.

 

Would be great if you could've a look into DT/LED stuff for mainline. No need to hurry since we decided to not release vanilla OS images until Ethernet for H3 will be ready with mainline kernel. But I believe the leds are a great way to provide user feedback especially on the first boot where Armbian is somewhat special (board auto detection and automated reboot in case it's necessary) 

[emsi88]

Thanks tkaiser, I'm only power-up board with connected USB cable and if I run script 2-3 times, then it catch USB and run test...

 

Result of tests on my One: 696Mhz is running, 720Mhz frozing after >2hours, 744MHz frozing after ~25seconds

I writed it to sunxi-wiki. I also test my PC board...

 

[kripo]

EDIT: Have you checked real temperatures? Eg. trying to touch the SoC shortly and get at least a feeling whether it's that hot as shown in the graphs? But I would adjust cpufreq settings first since I woudln't that anything that hot with a finger.

i measured it with a pyrometer. in reality the temperature were 2-3 degrees higher. i contacted steven zhao. his advice: use heat sink... not entirely the german standards of Customer-Experience-Management that i am used to...

[tkaiser]

I writed it to sunxi-wiki. I also test my PC board...

 

Thx, I would hope for users would contribute to community efforts like you!

 

i measured it with a pyrometer. in reality the temperature were 2-3 degrees higher. i contacted steven zhao. his advice: use heat sink... not entirely the german standards of Customer-Experience-Management that i am used to...

 

Indeed. So at least both you and me experience this overheating problem. I applied this heatsink and while it helps in reducing temp in the upper range by ~15°C (also performs better than the 20x20mm heatsinks I use normally) this is no real solution. Thx for confirming real temperatures even if I believe temperature on the surface and inside do not have to match and we still experience wrong thermal read outs with out combination of u-boot and kernel (a bit too low)

 

In case you can spend some time on further investigation it would be great if you could grab 

OrangePI_Ubuntu_Vivid_Mate.img.xz and update_kernel.sh from this mirror http://filez.zoobab.com/allwinner/orangepi/mega/ (or directly from loboris' Mega/GD). Burn his image (instructions and logon credentials), start it, run his update_kernel.sh and then either apply my fix for the Orange Pi One or directly overwrite his script.bin with ours, install RPI-Monitor again, reboot and report the thermal values you get then.

 

I would suspect thermal read outs are higher and throttling occurs earlier? In this case I would highly recommend to use a good heatsink, adjust cpufreq_max to the cpufreq_min and/or think also about decreasing all thermal triggers by 10°C: https://github.com/igorpecovnik/lib/blob/master/config/orangepione.fex#L255-L281

[martinayotte]

Thx for the confirmation! I'm currently lacking a bit spare time and can't do this stuff by myself. But it would be really great if we could collect some of this stuff in a tutorial like manner. No idea where (maybe linux-sunxi wiki that will then not only be the place for geek stuff but also user tutorials) but I strongly believe that we need some tutorials that are freely available and show at least the differences to the many thousand RPi tutorials available on the net. 

 

"Time" is always the "missing ingredient" ...

But at least, there is some existing documentation, although a bit outdated : http://linux-sunxi.org/I2Cdev

Maybe I will try to get chance to contribute in this page by adding some testing python code for controlling a GPIO expander such MCP23017.

 

EDIT : For SPI, there is a simlar page : http://linux-sunxi.org/SPIdev

 

EDIT2 : I've ran successfully this quick SPI test : https://raw.githubusercontent.com/loboris/OrangePI-Kernel/master/linux-3.4/Documentation/spi/spidev_test.c

[cbm801]

Hello,

 

Yesterday I tested Armbian 5.03 in Orange Pi PC and tried One. Unfortunately version for one wasn't booting at all.

Regarding OPiPC:

Thomas, I like your work for thermal issues. This board now can work even without heat sink nor fan. I made a few tests with different max clock set manually using sysbench as a load.

My results are:

@1296MHz:  T=69C

@1200MHz:  T=60C

@1008MHz:  T=48C

@648MHz:  T=43C

Idle - little above 30C, probably because voltage is less then 1V

No throtling - works perfectly! And works faster then at 1536MHz like in other distros.

I measured voltage at different clocks and it seems it works exactly like set in your fex/bin file.

Yesterday I tried also my fresh OPiOne. As I mentioned none of Armbian distros worked. So I took loboris' Ubuntu image and replaced script.bin to yours for OPiOne. It is definitely much warmer than OPiPC! At full speed (1200) without fan/heatsink it was throttling  and I couldn't finish sysbench test with same result as OPiPC.

Today fortunately new version of Armbian was available so I tried it on my OPiOne. It is little better then on previous Ubuntu but still much worse than on OPiPC.

Some results:

idle @480 T=44-47C V=1.120
@1296MHz: (throttling to 1200,1008)  T=80C+ V=1.335
@1200MHz: (some rare throttling to 1008) T=80C+
@1200MHz: with fan  T=61C+ but no throttling
@1008MHz: T=80C
@480MHz:  T=60C (on OPiPC such temperature was observed at 1200MHz)

 

In my case there is no problem with voltage - I measured it at test point near SD card with accurate DMM and results seem to be ok. But at the same voltage OPiPC has lower temperature.

I compared briefly the temperature using my IR thermometer and it is rather true. So probably it is better to limit max freq to 1008 to avoid overheating or buy heat sink (what I'm planning to do).

 

Big thanks for your awesome scripts: h3disp and fix-thermal-problems.

[cbm801]

By the way - I have a huge request. Could you please use 720p60 as a default resolution. Typicaly on TVs 60Hz is treated as PC HDMI so no overscan is used. At 50Hz I have such huge overscan that is is really problematic to setup Armbian without seeing last lines of the screen.Especially that new Armbian has more things to setup.

[tkaiser]

By the way - I have a huge request. Could you please use 720p60 as a default resolution. Typicaly on TVs 60Hz is treated as PC HDMI so no overscan is used. At 50Hz I have such huge overscan that is is really problematic to setup Armbian without seeing last lines of the screen.

 

I realised that yesterday later in the evening too and we already tried a workaround (yet not present in the images). But your suggestion sounds plausible. Will test it with my two problem displays and in case it helps, changing the default in all 5 fex files.

 

EDIT: At least for me switching between 720p50 and 720p60 doesn't improve anything. But we're still open for suggestions if others report that this helps on the majority of displays. Since h3disp exists this is easy to test (but I fear we get no feedback as it was already in the past when I asked for testers using Orange Pi 2 and 2 Mini)

 

Thx also for getting back with thermal values and comprehensive descriptions.

[cbm801]

I installed Armbian image once again from scratch but now on OPiOne. It seems that now min freq is 648MHz and max 1296. Why min is not set to 480 like on OPiPC? However I have similar temperature (about 45-46C) like when I set min freq to 480.

What is the difference between OPiPC and OPiOne versions - only script.bin file or kernel is modified too?