H2: Sunvell R69 Android TV Box (AliExpress)

[guidol]

I also do get

504 Gateway Time-out

The server didn't respond in time.

 

just test it later again... maybe the web. archive do work on the servers.... 

[Allwonder]

Armbian images for R69 on Google Drive.

Edited February 16, 2018 by Allwonder
Update To 5.41

[raschid]

Mainline kernel vers. 4.14.17 also works quite well (supporting eth, wifi, both usb-ports, emmc, ir, audio, ...). You could build it yourself with the armbian build system (https://docs.armbian.com/Developer-Guide_Build-Preparation/)

# git clone --depth 1 https://github.com/armbian/build
# cd build
# ./compile.sh BOARD=sunvell-r69

for media stuff you better stay with the legacy kernel though ...

[manuti]

  On 2/6/2018 at 11:57 AM, raschid said:

Mainline kernel vers. 4.14.17 also works quite well

Expand  

 

Nice to know!!! maybe I give a second chance to my Sunvell R69.

 

  On 2/6/2018 at 11:57 AM, raschid said:

for media stuff you better stay with the legacy kernel

Expand  

 

or better stay with stock Android version or H3droid

[guidol]

  On 2/6/2018 at 11:57 AM, raschid said:

Mainline kernel vers. 4.14.17 also works quite well (supporting eth, wifi, both usb-ports, emmc, ir, audio, ...). You could build it yourself with the armbian build system

Expand  

I did build 4.14.17 today as stretch and as xenial (Armbian_5.40_Sunvell-r69_Ubuntu_xenial_next_4.14.17.img) ,

but both wouldnt boot on the same card where the "old"

Armbian_5.34_Sunvell-r69_Ubuntu_xenial_default_3.4.113

does boot at first try successfully.

 

Do you got HDMI output with 4.14.17? Do you boot from uSD-Card?

I got the original Android on eMMC

[raschid]

  On 2/6/2018 at 6:13 PM, guidol said:

Do you got HDMI output with 4.14.17?

Expand  

Yes.

  On 2/6/2018 at 6:13 PM, guidol said:

Do you boot from uSD-Card?

Expand  

Yes.

 

Sometimes the device seems to hang on first boot. Disconnecting and reconnectig power works.

I have upgraded to 4.14.17 via deb-upgrade. I will try a clean install tomorrow.

 

[guidol]

  On 2/6/2018 at 6:22 PM, raschid said:

Sometimes the device seems to hang on first boot. Disconnecting and reconnectig power works.

I have upgraded to 4.14.17 via deb-upgrade. I will try a clean install tomorrow.

Expand  

I did try many boots (I know it could hang) with a 8GB and a 16GB SanDisk Card.

Didnt boot

Now I did try a 32B Lexar and the Ubuntu/xenial did boot.... so now I will try to boot the stretch version with the 32GB Lexar Card....

 

Hmm... after this one boot from the 32GB Lexar Card it doesnt boot with stretch AND after reimage with the new Ubuntu/xenial the 32GB also doenst boot anymore

 

BUT my "old" 8GB SanDisk is booting the old legacy without any problems.

 

Maybe the new image has some setting/tweaks and (maybe) the Ram timing isnt OK for this new setting?

[raschid]

OK, I am building an image with a 408MHz DRAM clk ... let's see ...

you could try to change the following def-config line:

CONFIG_DRAM_CLK=408

The current setting is 576MHz which seems to work without problems with legacy builds.

[guidol]

  On 2/6/2018 at 7:25 PM, raschid said:

OK, I am building an image with a 408MHz DRAM clk ... let's see ...

you could try to change the following def-config line:

CONFIG_DRAM_CLK=408

The current setting is 576MHz which seems to work without problems with legacy builds.

Expand  

I dont know if it is the DRAM-setting - was "a shot into the blue"

 

I did remind me that I - in the first try - wrote the new Ubunti image to the 32GB Lexar with etcher 1.2.1 (Windows) and the second time "only" with USB-IT.

So I updated etcher (poup did come) to 1.3.1. Formatted the 32GB Lexar with SD-Formatter and wrote the Image with the new etcher 1.3.1 to the 32Gb Lexar.

 

This time the 32Gb Lexar card could be booted. I assigned a IP and did apt update & upgrade:
ARMBIAN 5.40 user-built Ubuntu 16.04.3 LTS 4.14.17-sunxi
Linux sunvell 4.14.17-sunxi #4 SMP Tue Feb 6 20:41:23 +03 2018 armv7l armv7l armv7l GNU/Linux

 

After the upgrade the reboot did hang like on the legacy armbian ==> Power cycle - and it did boot again *pui*

 

But the same image with the new etcher doenst work with the 8GB SanDisk card, which do work with the legacy image.

 

Maybe it isnt a DRAM-setting but a speed-setting for the sdcard-slot? maybe the 32GB Card could be initialized faster?

 

System-Info:
root@sunvell:/# armbianmonitor -u
System diagnosis information will now be uploaded to http://ix.io/Fnl

 

[EDIT] CPU is at max Mhz all the time
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
20:10:55: 1008MHz  0.05   0%   0%   0%   0%   0%   0% 63.8°C  0/7
20:11:00: 1008MHz  0.05   0%   0%   0%   0%   0%   0% 64.1°C  0/7
20:11:05: 1008MHz  0.04   2%   1%   0%   0%   0%   0% 64.1°C  0/7
20:11:11: 1008MHz  0.04   0%   0%   0%   0%   0%   0% 63.8°C  0/7
20:11:16: 1008MHz  0.04   0%   0%   0%   0%   0%   0% 64.0°C  0/7
20:11:21: 1008MHz  0.03   0%   0%   0%   0%   0%   0% 64.1°C  0/7
20:11:26: 1008MHz  0.03   0%   0%   0%   0%   0%   0% 64.0°C  0/7
20:11:31: 1008MHz  0.03   1%   0%   0%   0%   0%   0% 63.5°C  0/7
20:11:36: 1008MHz  0.02   0%   0%   0%   0%   0%   0% 63.9°C  0/7
20:11:41: 1008MHz  0.02   0%   0%   0%   0%   0%   0% 63.9°C  0/7

 

but https://github.com/armbian/build/blob/master/config/boards/sunvell-r69.csc

say as min. Mhz: CPUMIN=240000

 

Any idea why we got the max Mhz only?: CPUMAX=1008000
 

root@sunvell:/# more /etc/default/cpufrequtils
# WARNING: this file will be replaced on board support package (linux-root-...) upgrade
ENABLE=true
MIN_SPEED=240000
MAX_SPEED=1008000
GOVERNOR=ondemand

maybe armbianmonitor -m does raise the cpu, because the stats does show another picture:

 

 current CPU frequency is 1.01 GHz (asserted by call to hardware).
 cpufreq stats:

240 MHz: 81.58%,

480 MHz: 3.35%, 

648 MHz: 0.05%,

816 MHz: 0.04%,

912 MHz: 0.02%,

960 MHz: 0.20%,

1.01 GHz: 14.60%,

1.10 GHz: 0.16% 
 

 

[raschid]

new 4.14.17-next/stretch build has booted several times without a hitch (using a 32G SANdisk ULTRA btw.) ... more testing ...

 

[guidol]

  On 2/6/2018 at 8:32 PM, raschid said:

new 4.14.17-next/stretch build has booted several times without a hitch (using a 32G SANdisk ULTRA btw.) ... more testing ...

 

Expand  

did try to boot the stretch version written with etcher 1.3.1 on a 32GB SanDisk Extreme (faster than ultra) - but no boot serveral times...
inserting the 32GB Lexar with ububtu-mainline 4.14.17 did boot in the 1st try now *strange*

[manuti]

  On 2/6/2018 at 7:53 PM, guidol said:

etcher 1.2.1

Expand  

With Ubuntu and this Etcher version,  have 2 broken microSD cards. It's  supposed that can't happen but for sure the SD card never works properly. 

[manuti]

  On 2/6/2018 at 8:50 PM, guidol said:

strange

Expand  

I post here: 

And rise an issue on Etcher GitHub https://github.com/resin-io/etcher/issues/1955

[raschid]

@guidol: Does the boot-stability improve, when you replace build/patch/u-boot/u-boot-sunxi/add-sunvell-r69.patch with the attached file (reduces DRAM clck to 408)?

If stability improves, could you copy the OS to eMMC via armbian-config and check boot-stability?

add-sunvell-r69.patch

[guidol]

  On 2/6/2018 at 8:50 PM, guidol said:

did try to boot the stretch version written with etcher 1.3.1 on a 32GB SanDisk Extreme (faster than ultra) - but no boot serveral times...
inserting the 32GB Lexar with ububtu-mainline 4.14.17 did boot in the 1st try now *strange*

Expand  

Next successfull check: I wrote the mainline stretch image 4.14.17 to this "special" Lexar 32GB card - and now the stretch image is also booting in the first try.

 

Dont know why all cards - who have been useable on the R69 before - now didnt work

I have them formatted with SD-Formatter (like also the Lexar 32GB) and wrote the image with the same etcher and same card-reader/writer.

I also did try a slow/complete format with the sd-formatter.

 

As attachment a picture of the Lexar 32GB who did work as the only one at this time on my R69

[raschid]

  On 2/7/2018 at 8:13 AM, guidol said:

As attachment a picture of the Lexar 32GB who did work as the only one at this time on my R69

Expand  

@guidol I don't think this is an etcher issue - there may not be anything wrong with SD cards (for once). Could you connect via console and post the output for a hanging boot?

[guidol]

  On 2/7/2018 at 8:12 AM, raschid said:

@guidol: Does the boot-stability improve, when you replace build/patch/u-boot/u-boot-sunxi/add-sunvell-r69.patch with the attached file (reduces DRAM clck to 408)?

If stability improves, could you copy the OS to eMMC via armbian-config and check boot-stability?

Expand  

I did build the image with this patch as Armbian_5.40_Sunvell-r69_Debian_stretch_next_4.14.17_RAM_408Mhz.img

and now all the others cards (8GB Ultra and 32GB Exteme) DO boot again in the first try

ARMBIAN 5.40 user-built Debian GNU/Linux 9 (stretch) 4.14.17-sunxi
Linux sunvell-r69 4.14.17-sunxi #6 SMP Wed Feb 7 11:31:13 +03 2018 armv7l GNU/Linux

I didnt want to copy the OS to eMMC, because for future purposes I want to leave the original Android there.
As I have the case closed I dont want to open these clips again - because Iam afraid they could break in a additional try

[guidol]

  On 2/7/2018 at 8:56 AM, raschid said:

@guidol I don't think this is an etcher issue - there may not be anything wrong with SD cards (for once). 

Expand  

No - it isnt a etcher issue - but without the case open I cant see what there is going on.
Maybe not all board-components have the same specs on all boards.

[raschid]

  On 2/7/2018 at 9:11 AM, guidol said:

now all the others cards (8GB Ultra and 32GB Exteme) DO boot again in the first try

Expand  

Good news but still odd: the legacy image's FEX file indicates a DRAM clock of 576MHz. Never mind, I created a pull request with an updated u-boot patch which should solve the issue for other users as well.

Thx for raising the issue and the extensive testing

 

[manuti]

  On 2/7/2018 at 9:42 AM, raschid said:

Good news but still odd: the legacy image's FEX file indicates a DRAM clock of 576MHz. Never mind, I created a pull request with an updated u-boot patch which should solve the issue for other users as well.

Thx for raising the issue and the extensive testing

 

Expand  

 

Hi @raschid or @guidol can you share this new image?

Or is going to be included in the official repo from armbian in the future?

Thanks in advance.

[guidol]

  On 2/8/2018 at 8:41 AM, manuti said:

 

Hi @raschid or @guidol can you share this new image?

Or is going to be included in the official repo from armbian in the future?

Thanks in advance.

Expand  

Its only a build out of the build-system, which do you could install on your PC.
Its VirtualBox + the mini ISO of Ubuntu 16.04 and a clone of github and you can build your own image

 

See https://docs.armbian.com/Developer-Guide_Build-Preparation/

 

and you need to add the patched version of raschid for the 408Mhz DRAM-version.

 

compressed size is: 336 MB (353.022.379 Bytes) for the image 
I have no own webspace to upload it. ;(

[manuti]

  On 2/8/2018 at 8:56 AM, guidol said:

Its only a build out of the build-system, which do you could install on your PC.
Its VirtualBox + the mini ISO of Ubuntu 16.04 and a clone of github and you can build your own image

 

See https://docs.armbian.com/Developer-Guide_Build-Preparation/

 

and you need to add the patched version of raschid for the 408Mhz DRAM-version.

 

compressed size is: 336 MB (353.022.379 Bytes) for the image 
I have no own webspace to upload it. ;(

Expand  

OK, I'm a lazy guy. I run Ubuntu in my main computer so I only need to download, apply patch and compile.

At the end of the process I obtain a complete .img file ready to write in the card?

[guidol]

  On 2/8/2018 at 10:56 AM, manuti said:

OK, I'm a lazy guy. I run Ubuntu in my main computer so I only need to download, apply patch and compile.

At the end of the process I obtain a complete .img file ready to write in the card?

Expand  

Yes - if you do not only compile a Kernel - you will get a full image which can be written to uSD,

BUT you need a 64Bit Ubuntu on your main computer and some disk space.

The image will be written to ./build/output/images - for me thats /home/guido/build/output/images/

 

Because I got it in a VirtualBox - I created only a 30GB Disk.
Before compiling I have 9GB free Disk-Space and the build-process does warn me.

But when I do compile for the R69 I have mostly ofer 6.7GB free (looking with df at the disks).

 

On my QuadCore AMD 3GHz the compile does run in the frist try 26 Minutes.... later if I compile another image with other kernel then it could run as fast as 16 minutes (less download?)

 

[raschid]

  On 2/8/2018 at 10:56 AM, manuti said:

OK, I'm a lazy guy

Expand  

 

Here's a link to the headless version:

https://drive.google.com/file/d/1oGjWHzDMU7bfB_ywpG4Lods3Gva7KVcI/view?usp=sharing

u need desktop?

 

[raschid]

  On 2/8/2018 at 8:56 AM, guidol said:

and you need to add the patched version of raschid for the 408Mhz DRAM-version

Expand  

This is not necessary anymore (and not recommended).

 

This now builds a kernel with the adapted DRAM clock freq.:

# git clone --depth 1 https://github.com/armbian/build
# cd build
# ./compile.sh BOARD=sunvell-r69

 

[guidol]

  On 2/8/2018 at 3:44 PM, raschid said:

This now builds a kernel with the adapted DRAM clock freq.

Expand  

Is this your 408MHz version or is "the adapted DRAM clock freq." anything newer?

[raschid]

nope, same thing.

[hekkru]

hey! using this h2 beast, completely unusable when hdmi is connected(96C degrees), without hdmi is okay(55C).

nand install, self-compiled headless debian9 image.

Edited February 23, 2018 by hekkru

[guidol]

  On 2/23/2018 at 7:57 AM, hekkru said:

hey! using this h2 beast, completely unusable when hdmi is connected(96C degrees), without hdmi is okay(55C).

nand install, self-compiled headless debian9 image.

Expand  

you got 96C degrees on the headless image? Did yoi build it with the help of the armbian-build-system?
which processes do run when you got 96 degree?
My r69 is running at the same temperatur with or without HDMI connected, when running the samen processes.

[hekkru]

  On 2/23/2018 at 10:10 AM, guidol said:

you got 96C degrees on the headless image? Did yoi build it with the help of the armbian-build-system?
which processes do run when you got 96 degree?
My r69 is running at the same temperatur with or without HDMI connected, when running the samen processes.

Expand  

Welcome to ARMBIAN 5.41 user-built Debian GNU/Linux 9 (stretch) 4.14.20-sunxi
System load:   0.07 0.06 0.07  	Up time:       13:59 hours
Memory usage:  8 % of 1000MB 	IP:            10.250.250.78 172.24.1.1
CPU temp:      49°C
Usage of /:    17% of 7.1G

yes, it was compiled with build system inside vagrant. even on powersave governor on 242(or whatever it was)MHz i was getting 96C. mine display is 2560x1440, maybe this is the point.  when i disconnected hdmi i got instant temperature drop. also load average was close to null all this time so i assume there was no process-eating tasks.