Jump to content

Recommended Posts

Posted

Good evening! :)

 

I've bought the R69 1GB TV-Box on eBay some days ago with the plan in mind to run Armbian there. Sadly the box even dont want to start the kernel, it's stuck in U-Boot Loader when a SD is inserted:

 

U-Boot SPL 2018.05-armbian (Jul 31 2018 - 05:08:39 +0200)
DRAM: 1024 MiB
Trying to boot from MMC1

And then nothing happens.

 

I've tried couple of images. Beelink Image with Mainline and legacy Kernel, RetroOrangePi Images and so on - for now I haven't found a working one.

 

In some other Thread someone mentioned that there are different versions of this device, and i found some Thread where someone also has trouble with the 2GB Version.

 

For the case there are helpful information, here is the android Boot-Log

 
  Reveal hidden contents


And some photos of the Device:

 

IMG_0203.JPGIMG_0204.JPG                                                                                                                                                                                                                              

 

It looks kinda different like the other PCBs i found from the r69, also the Revision "R69-4x4Bit DDR3_V1.0_20181210" i havent seen before when i was searching about this Box

 

Has anyone suggestions what i can try to get there Armbian running? I already tried different dtb, builds, mainline and legacy kernel versions.

 

Thanks for reading! I hope someday Armbian will boot on this little guy! :)

 

 

Board: Not on the list
Posted

Thanks for moving the thread into the correct place!

 

Now i've tried a nightly image from Libreelec (https://test.libreelec.tv/LibreELEC-H3.arm-9.80-nightly-20190628-bb9c865-orangepi_pc.img.gz) with a recent mainline u-boot. now i get some more errors:

 

  Reveal hidden contents

 

In this log you see when i plugged in and out the power cable. i'm bit confused about "Failed to set core voltage! Can't set CPU frequency" and when he was trying to start something but got stuck there.

 

Maybe this is  a useful information: In Android CPU-Z just shows me an Unknown SOC Type with a Clock Speed of 1GHz - I guess the H3 should be able to run at 1,3-1,5GHz.

 

 

EDIT: This BeelinkX2 image from libreelec https://test.libreelec.tv/LibreELEC-H3.arm-9.80-nightly-20190628-bb9c865-beelink_x2.img.gz just gives me the same:

 

U-Boot SPL 2019.04 (Jun 28 2019 - 10:15:24 +0200)
DRAM: 1024 MiB
Trying to boot from MMC1

Edit2: Just as note, I also trying different SD-Cards. A Sandisk Ultra 16GB and a Transcend Premium 16GB - Just the same with both cards.

 

Edit3: For case it's helpful, here are the Screenshots from CPU-Z:

Screenshot_20190630-073218.png

Screenshot_20190630-073224.png

Screenshot_20190630-073235.png

 

Edit4: Some links to the device:

https://www.cnx-software.com/2019/02/09/wechip-r69-cheap-allwinner-h3-tv-box/

https://www.ebay.de/itm/R69-Quad-Core-Android-7-1-Smart-TV-Box-4K-3D-WIFI-HDMI-H-265-Media-Streamer-DE/133075545075?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649

 

Posted

I tried to dump the /dev/block/nand devices, i just dumped that ones, that looked interesting to me. You can find them here for interest:

 

http://blx274.tk/r69/images.tgz

 

Content of this archive:

 

-rwxrwxrwx 1 marcus marcus 67108864 Jun 30 15:18 alog_nandi
-rwxrwxrwx 1 marcus marcus 16777216 Jun 30 15:16 bootloader_nanda
-rwxrwxrwx 1 marcus marcus 33554432 Jun 30 15:15 boot_nandc
-rwxrwxrwx 1 marcus marcus 16777216 Jun 30 15:16 env_nandb
-rwxrwxrwx 1 marcus marcus 16777216 Jun 30 15:17 misc_nandf
-rwxrwxrwx 1 marcus marcus 16777216 Jun 30 15:17 verity_block_nande

 

Posted

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

As a result, u-boot is not able to change the voltage to the CPU and thus change its frequency from the default setting.

This is common when you use an image which is compiled for a "close" device but not exactly the same.

 

Apart from the messy serial port output, the image for Orange Pi PC seems to be booting u-boot, but then it does not go further because of wrong commands in the initialization script (the "MC" errors), which is although strange because the environment is restored from default.

You may try to interrupt u-boot autoboot during countdown and use help and mmc commands to gather some info to understand if the sdcard is really the MMC0 device.

 

BTW, the booting issue is surely a device tree problem

 

Posted

Thanks for the reply! :)

 

I guess the damaged serial output is caused by my UART Adapter, which is an Arduino Uno with following circuits: c616b050-d64a-11e6-9b87-ae33f1c0c8f1.png

 

I've ordered a "real" UART Adapter to ensure there are no probles caused by that and make debugging easier :)

 

When the new Adapter is here i will try to interact with the uboot command line.

 

 

  Quote

BTW, the booting issue is surely a device tree problem

Expand  

 

I also thought that this could be the problem. For now I haven't found a suitable DTB File for this device. I tried to extract it from the dumped files, but I only got garbage. 

I used the file "boot_nandc" from my archive , which is the android kernel, with this tool: github.com/PabloCastellano/extract-dtb

 

Is there any other way to get the correct DTB file for this device? 

Posted

I'm not really sure you need the two resistors circuit to make the serial adapter work. I mean, if the Arduino Uno has a TTL (which I guess it is) serial, you should be able to connect Arduino TX to Box RX and Arduino RX to Box TX and Arduino GND to Box GND to get the things done.

 

A device tree for your device could be in the wild somewhere, your device does not sound new to me;

BTW you should first understand if the device tree is packaged with the kernel and the initramfs in an "Android boot image". file utility should be able to detect if the partition is an Android image.

If so, there are tools to extract the files from the archive.

 

The extract-dtb is useful when the device tree is attached at the tail of the kernel image, but nowadays shipping the dtb this way is seldom used.

Posted

I will close this Topic, because the discussion is going on here 

 

Conclusion for this Topic:

 

Choosing a Sony SD-Card solved my problem. In the other topic discuission is going on why the device is picky with SD-Cards. Maybe the wrong DTB causes this behaviour.

  • Werner locked this topic
Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines