R69 TV box cananot boot

[ljones0]

Hello all!

 

I have one of these (possibly!) a sunvell R69 tv- box (it says R69 on top and has a green line going around it). I did try to check on its built-in android to see what CPU is in this box; I couldn't really find a 100% answer but it is either an H2+ or H3.

 

I did download and manage to get to work one of the armbian images (but I cannot remember which one it was) but then later used the micro sd for other purposes. I then tried downloading the armbian image for the orange pi one (I can't remember if that was the one I chose earlier; I've seen others use this image for 'a' R69 and some say it works) and writing it but my R69 refuses to boot; all I get is a blank screen, nothing.  I've also tried different micro SD cards, but again nothing.

 

The built-in android still works and can read from the micro sd card.

 

Which is the correct image? Or is my R69 broken?

 

BTW I have attached an actual image of the device (I believe it to be the correct device; R69, H2+ or H3 based).

 

Update: I did manage to get it to boot again but only briefly. I used an image ment for the beelink x2 (Armbian 5.75 beelink x2 stretch 4.19.20). I saw the armbian logo and some messages but it then "died" and after that blank screen. Power cycling the device using the same micro sd does nothing and the blank screen remains (internal android still running btw).

 

ljones

[NightMean]

It's not dead, you just don't have the correct dtb. For me it was trial and error until I figured out which worked the best. I don't have your box though. I have 2 identically looking boxes from the outside but the internals were different.In my opinion It's best to open it and see what the CPU is. 

[ljones0]

44 minutes ago, NightMean said:

It's not dead, you just don't have the correct dtb. For me it was trial and error until I figured out which worked the best. I don't have your box though. I have 2 identically looking boxes from the outside but the internals were different.In my opinion It's best to open it and see what the CPU is. 

 

Intresting but how do I go about getting the dtb file from the device? I'm also going to try a different computer and see if it is something there which is causing a problem.

[ljones0]

Still no joy with booting. Here's what android has to say about the CPU btw;

$ cat /proc/cpuinfo

processor	: 0
model name	: ARMv7 Processor rev 5 (v7l)
BogoMIPS	: 48.00
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 5

processor	: 1
model name	: ARMv7 Processor rev 5 (v7l)
BogoMIPS	: 48.00
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 5

processor	: 2
model name	: ARMv7 Processor rev 5 (v7l)
BogoMIPS	: 48.00
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 5

Hardware	: sun8iw7
Revision	: 0000
Serial		: 14107892c71064360753

[jock]

Is the same as this?

 

[ljones0]

:-( I don't know.

 

I'm not even getting that far. Any attempt to boot from the SD just results in an empty screen - about the only thing I do see if I try to go off the microsd card is from the display itself, "No signal". 

 

I'm starting to think my box is faulty, it would not suprise me as a lot of these boxes are cheapo chinese devices. Only other thing I can think of is maybe the way this device boots gets locked down or corrupted in some way?

 

ljones

[ljones0]

I managed to get the top off the device as it appears to only be clipped on. Here's one side of the board;

 

ljones

[ljones0]

If my device is a wechip one then one thing I thought about doing is trying to see if there was a copy of the original android firmware about for it, download it and then write it to a micro sd card. Since I installed a terminal program on my device in android if it boots from microsd to android then it would be clear to see as the terminal program wouldn't be there.

 

I did find wechips' support website but they don't seem to support their own device; no mention of an R69 device on the support page, and although that sticker on my device says "MXQ-4K" and there's a MXQ-4K device on their website you might think that was it, but that link references files for an RK3229-based device.....unless my device really is an RK3229 device and the whole android image that is installed on this device is set up to lie about what it really is...

 

Did have a look for rk3229 linux or kodi images to try but could only find a "ReSpeaker Core V2.0 rk3229" device and no the supplied images didn't boot, they were ignored by my R69 box which booted into android.

 

Links:

https://respeaker.io/rk3229_core/

https://v2.fangcloud.com/share/7395fd138a1cab496fd4792fe5?folder_id=188000207914&lang=en

 

Not sure of the relevence but another link;

https://forum.freaktab.com/forum/tv-player-support/rockchip-based-tv-players/rk3229-devices/firmware-roms-tools-bg/672259-debian-on-rk3229-is-it-possible

 

On trying to identify this device - I suspect like the other posters' device (above) the other side of the board that contains the CPU will also have a heatsink on it making actual identification impossible without tearing off the heatsink...

 

For now I'm going to have to give up on this one :-( . I can't identify the CPU and neither h2+/h3 nor rk3229 images will boot. For now this device uses a "?" cpu.

 

ljones

[DeltaLima]

"Glad" to see that another person has the same problem as me with this device!

 

Your PCB pictures looks exatkly the same like mine - so I guess we have the same device.

 

I don't think that's a Rockhip SOC is on there, because your cat of /proc/cpuinfo shows as Hardware also "sun8iw7" which is definitely an Allwinner SoC.

 

To get 100% sure that's an Allwinner i will disamble the heatsink of mine and post a picture later on!

[martinayotte]

6 minutes ago, DeltaLima said:

Hardware also "sun8iw7" which is definitely an Allwinner SoC.

This is and H3 or H2+ ...

http://linux-sunxi.org/Allwinner_SoC_Family

[jock]

The sticker on the PCB also says H3, also the XR819 is the companion WiFi chip from Allwinner... That's definitely an Allwinner chip, most probably an H3 with a minor possibility it is an H2+ (which is almost the same as H3)

[ljones0]

Well I decided to give it another go, and this time I seem to have gotten slightly further. I managed to find the one-and-only local copy of the image that I used originally (I'd remembered to copy it onto a *very* old and painfully slow kingston 1gb usb memory stick).

 

As a precaution however I also decided to buy a new sd card writer (and a new micro sd card) just in case the one I have was playing up for some reason; I'm now using it.

 

I've been trying it and my device (R69) seems to really *hate* some of my micro sd cards. I tried a  sandisk ultra 8gb to start with and it refused point blank to boot from it. A different microsd, a 32gb integral got a little further (I can see messages and the armbian boot logo) but it dosen't get much further. Next up was an ancient 16gb sandisk (very slooow) microsd which booted, gave a green screen after the armbian logo and then stopped working. I then tried a newer sandisk 32gb (but still not very fast) which like the sandisk ultra 8gb failed to boot.

 

I also have a brand new 16gb samsung pro to try out although I'll have to do that later.

 

Never come across such an amazingly picky device!

 

BTW the image I used was "Armbian_5.75_Beelinkx2_Debian_stretch_next_4.19.20.img" .

 

ljones

[DeltaLima]

3 hours ago, ljones0 said:

A different microsd, a 32gb integral got a little further (I can see messages and the armbian boot logo) but it dosen't get much further.

 

I can confirm this! Thanks! I found a Sony 16GB SD Card and tried it - It boots now the Kernel and also starts the kernel and systemd. Then i get a kernel panic, which I post later

[DeltaLima]

This image is working for me fine:

https://dl.armbian.com/beelinkx2/archive/Armbian_5.65_Beelinkx2_Debian_stretch_next_4.14.78.7z

 

unfortunate my sd card died But its booting without kernel panic!

[DeltaLima]

Maybe this R69 device is not able to handle at boot stage the Micro SDXC Cards, I think the Sandisk Ultra and Transcent Premium are those. The Sony Card seems to be a "normal" Class 10 SDHC Card, which worked. I order a new SD card, a Kingston SDHC Class 10 - i hope this will work and live longer then the Sony card  

 

@ljones0

 

Could you please post an image of your SD Cards? Would be interesting if the working ones are SDHC oder SDXC

[ljones0]

I tried the branad new samsung 16gb btw. It failed to boot like many of the others.

 

BTW Here is a picture of the sd cards.

 

ljones

[ljones0]

22 hours ago, DeltaLima said:

This image is working for me fine:

https://dl.armbian.com/beelinkx2/archive/Armbian_5.65_Beelinkx2_Debian_stretch_next_4.14.78.7z

 

unfortunate my sd card died But its booting without kernel panic!

 

Intresting that one worked for me on the integral micro sd - I managed to boot to a login prompt (though I've not tried it beyond that). I did try also that image on the new samsung 16gb, but it didn't work on that one.

 

ljones

[jock]

@ljones0 Besides, use a proper image writer (like the armbian-advertised BalenaEtcher) when do you burn images on SD card: it will take care to unmount the device, burn the image and verify the image by itself.

 

If you want to use dd, always remember to unmount the mounted SD-card partitions first.

 

 

[ljones0]

3 hours ago, jock said:

@ljones0 Besides, use a proper image writer (like the armbian-advertised BalenaEtcher) when do you burn images on SD card: it will take care to unmount the device, burn the image and verify the image by itself.

 

If you want to use dd, always remember to unmount the mounted SD-card partitions first.

 

 

 

I'll give it a go again but I did try both etcher and dd and they both gave me the same results. I've not tried it recently but even using a different PC resulted in the same thing happening. One guess - maybe not every micro sd is created equally?

 

I'm really not sure but from memory don't some of these arm-based devices require some sort of boot code to be written at a very specific place on a microsd? Maybe that's the problem or prehaps the data "ends up in the wrong place" so to speak as (for example) one 16gb card and another might be just very slightly different capacities. That's just a guess.

 

ljones

[martinayotte]

8 minutes ago, ljones0 said:

arm-based devices require some sort of boot code to be written at a very specific place on a microsd

Yes, but this is already taken care during image creation, so image has to be written as is at byte address 0.

[ljones0]

One more thing -- I managed to even get xorg and xfce to start on mine(!). But X dosen't seem to have any acceleration however. After looking around online I see (if this is correct btw as I'm still not 100% on what the CPU is on my device without pulling the heatsink off x.x ) the H2+ CPU and H3 CPU are very similar - it's just that the H2+ is a cheapo version of the H3 with no 4K output and gigabit ethernet. At a guess they both use the same video chipset (Mali400) but there dosen't seem to be any x accel for mali 400 in armbian? 

 

I did try to install xserver-xorg-video-armsoc-sun4i but that just resulted in no X and errors in /var/log/Xorg.0.log, e.g. Cannot set the DRM interface version/Cannot open a connection with the DRM - Permission denied .

 

Currently btw I'm waiting for delivery on another new micro sd this time an integral. WIll be intrested to try to write the image on another machine onto the new samsung microsd I got and this integral and see if there's any differences.

 

ljones

[jock]

@ljones0 Well, presuming the SD cards you're owning are sane and not counterfeit, it should be that most SD cards are compatible and works ok and maybe a few may have some sort of issues, not the opposite like you're experiencing.

It looks to me there is something wrong, possibly in the device tree. The first thing that comes up to my mind is an erroneous configuration of the sdcard pins or UHS mode not properly working, since you're using the Beelink X2 device tree which is not fully suited for your device.

 

It worth mentioning the armbian documentation, and its SD card preparing tips and hints.

 

About the X acceleration, you can get 3D acceleration, but it requires you to compile the Mali kernel module, install the userland Mali drivers and use a working xf86-video-armsoc driver. The armsoc driver packaged with armbian probably does not work with mainline kernel. Here there is some work in progress pull request for an armsoc driver for mainline kernels: https://github.com/armbian/build/pull/1409

 

PS: the out-of-the-box configuration is still viable for decent 2D performance, but first you have to disable the window manager composition in Settings -> Window Manager Tweaks menu.

[DeltaLima]

On 7/13/2019 at 3:42 PM, jock said:

@ljones0

It looks to me there is something wrong, possibly in the device tree. The first thing that comes up to my mind is an erroneous configuration of the sdcard pins or UHS mode not properly working, since you're using the Beelink X2 device tree which is not fully suited for your device.

 

would be interesting how exactly and on the correct way we could extract the DTB on this device - is there a guide for extacting DTB on allwinner devices corretly?

[jock]

4 hours ago, DeltaLima said:

 

would be interesting how exactly and on the correct way we could extract the DTB on this device - is there a guide for extacting DTB on allwinner devices corretly?

 

All DTB files are pretty standard and they are decompiled/converted between binary and source form using the dtc tool.

This is sufficient to convert a binary device tree (dtb) to a human readable device tree (dts):

dtc -I dtb -O dts <your_dtb_file.dtb> -o <extracted_dts_file.dts>

DTS files converted from DTB are not the best way to deal with them, because many human-readable constants and values are converted into hexadecimal values and references to nodes are summed up as integer values (called phandles), where in a real source device tree you get a string reference to the node which is much easier to follow.

A quick test you can do is to disable the UHS mode: find in the source device tree the strings starting with "sd-uhs-" and remove them. Make a backup copy of the original DTB file and then convert back the DTS to DTB using dtc.

Those strings, when present, tell the sdmmc driver to enable UHS modes that on some devices are troubling.

 

If this quick hack does not work, then the problem requires more attention and knowledge

[ljones0]

How would I go about getting the relevent files from my R69 though? Or do they have to  be done manually (presumably android uses some other method for booting?).

 

All this reminds me of a problem I had years back with a similar (in form factor) device, I believe it was an RK3288 based device, "MK902II". Closest thing to it I think was a device called a 'firefly' but my device was just too different (it did not boot, like the R69). Might eventually be worth retrying what with the situation with dtb files and microsd cards.

 

ljones

[jock]

2 hours ago, ljones0 said:

How would I go about getting the relevent files from my R69 though? Or do they have to  be done manually (presumably android uses some other method for booting?).

Sorry, I didn't understand what you mean... If you are looking for dtb files, they are located in /boot/dtb directory on the sdcard.

 

2 hours ago, ljones0 said:

All this reminds me of a problem I had years back with a similar (in form factor) device, I believe it was an RK3288 based device, "MK902II". Closest thing to it I think was a device called a 'firefly' but my device was just too different (it did not boot, like the R69). Might eventually be worth retrying what with the situation with dtb files and microsd cards.

You may try with this image for rk3288-based tv boxes. It's not exactly for the MK902II, but probably it will boot but many devices won't be available, nonetheless it could be a jump start.

This is the forum page for discussion:

 

[ljones0]

Ok I gave that image a go for the rk3288 device on several different microsd cards, but it failed to boot from any of them. However I managed to find some old bits 'n' pieces here and here it consitsts of downloading a script which writes some boot files to a micro sd card and also someone's ancient pre-rolled version of ubuntu. That worked although I am not sure quite how everything ties up -- that's the first time it has worked.

 

If anyone wants it I could always put up an image of the micro sd I created with those old files and scripts for the rk3288/mk902ii. It worked on my old 4GB card so at least that should make it a bit smaller, more if I compress and upload.

 

As for the dtb files was meaning is there some way I can use the device itself as I don't have any dtb files for the R69 at all.

 

ljones

[jock]

10 hours ago, ljones0 said:

Ok I gave that image a go for the rk3288 device on several different microsd cards, but it failed to boot from any of them. However I managed to find some old bits 'n' pieces here and here it consitsts of downloading a script which writes some boot files to a micro sd card and also someone's ancient pre-rolled version of ubuntu. That worked although I am not sure quite how everything ties up -- that's the first time it has worked.

 

If anyone wants it I could always put up an image of the micro sd I created with those old files and scripts for the rk3288/mk902ii. It worked on my old 4GB card so at least that should make it a bit smaller, more if I compress and upload.

 

As for the dtb files was meaning is there some way I can use the device itself as I don't have any dtb files for the R69 at all.

 

ljones

I'm aware of the bootloader tinkering, but in the armbian download page there are the instructions to wipe the internal eMMC to enable the straight usage of armbian image (and mainline u-boot). If you don't mind to lose the embedded Android, you may try to follow those instructions.

BTW: it's better to discuss about this other tv box on the other thread

[Evelyn257]

The "failed to set core voltage" error message should be harmless: I think either the device tree misses here the proper reference to the CPU current regulator and/or u-boot is compiled without the support for it.

1. As a result, u-boot is not able to change the voltage to the CPU and thus change its frequency from the default setting.
2. This is common when you use an image which gaana is compiled for a "close" device but not exactly the same.

A quick test you can do is to disable the UHS mode:

• find in the source here device tree the strings starting with "sd-uhs-"
• remove them.
• Make a backup copy of the original DTB file and then convert back the DTS to DTB using dtc.

Edited July 20, 2019 by Evelyn257

[ljones0]

So after looking at this website am I correct in thinking that there's no xorg accel/drivers for the R69 until the 5.2 kernel?

 

ljones