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]

4 hours ago, raschid said:

Mainline kernel vers. 4.14.17 also works quite well

 

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

 

4 hours ago, raschid said:

for media stuff you better stay with the legacy kernel

 

or better stay with stock Android version or H3droid

[guidol]

6 hours ago, 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

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]

6 minutes ago, guidol said:

Do you got HDMI output with 4.14.17?

Yes.

6 minutes ago, guidol said:

Do you boot from uSD-Card?

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]

Just now, 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.

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]

1 hour ago, 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.

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]

25 minutes ago, raschid said:

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

 

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]

2 hours ago, guidol said:

etcher 1.2.1

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]

11 hours ago, guidol said:

strange

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]

11 hours ago, 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*

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]

39 minutes ago, guidol said:

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

@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]

3 hours ago, 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?

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]

14 minutes ago, raschid said:

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

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]

26 minutes ago, guidol said:

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

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]

22 hours ago, 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

 

 

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]

15 minutes ago, 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.

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]

1 hour ago, 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. ;(

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]

1 hour ago, 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?

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]

4 hours ago, manuti said:

OK, I'm a lazy guy

 

Here's a link to the headless version:

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

u need desktop?

 

[raschid]

6 hours ago, guidol said:

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

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]

35 minutes ago, raschid said:

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

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]

2 hours ago, 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.

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]

43 minutes ago, 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.

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.