Shimon

Only the latter. Changing root's password and creating a user account has been compulsory for quite a while now on first boot.

If my reading over the boot method of these devices is correct, you should be able to trigger it to boot from an SD card via shorting a couple wires together, I think the UT3S uses that recovery button to do it.  Similar buttons probably exist on the cheapies.

If anyone picked up the UGOOS box:  http://freaktab.com/forum/tv-player-support/ugoos-aa/530975-official-ugoos-firmwares-for-devices-based-on-rk3288
 
Quite a bit of info on how to flash it/etc.  I picked one up because, why not...

You can actually buy Ugoos UT3S 2GB/16GB on gearbest for less than 40$ (or 36.50€) with GBUT3S coupon: http://www.gearbest.com/tv-box/pp_141997.html?wid=21&lkid=10695139
There is already a dualboot between android and ubuntu, so it's maybe easier to port armbian to it.
 

Still no luck getting the Q8 to boot linux, it seems all roads lead to frustration at the moment. The furthest I've got so far has been with the Tim Potter kernel from
https://bitbucket.org/DengueTim/q8-rk3288-kernel/overview
 
That kernel seems to get quite a long way into the boot sequence, bringing all four processors up and probing a lot of hardware. It even brings up the firefly splash screen on the monitor, but then it starts hitting kernel oops and eventually seems to lock up solid.
 
I confirmed that shorting pins 7 & 8 on the flash chip can bring it into maskrom mode, but I haven't figured out what to do with it from there.

A little more progress - I did some debugging on the create-linux-sdcard script from
and found that the assumptions it was making about the device naming scheme for the sd card reader didn't match my build environment (it assumed a root device such as sda with partition sda1, where as I have a root device mmcblk0 and partition mmcblk0p1). After fixing that the resulting sd card gets further into the boot process and starts bringing up the kernel. Unfortunately the boot appears to hang with no network or screen. The serial log stops at what looks like random places on each attempt, I'm not sure if this reflects the boot crashing randomly or if it's just the non-flow-controlled serial connection overflowing.
 
This all has the feeling of re-discovering what other people did two or three years ago, but at least it doesn't look like I've completely trashed the system yet.

Mine arrived today. Power up with the reset button held makes it accessible to the Rockchip rkflashtool and upgrade_tool, which seems promising.
 
Here's the cmdline section from the parameter data of the stock firmware
CMDLINE:console=ttyFIQ0 androidboot.hardware=rk30board androidboot.console=ttyFIQ0 board.ap_has_alsa=0 init=/init initrd=0x62000000,0x00800000 mtdparts=rk29xxnand:0x00002000@0x00002000(uboot),0x00002000@0x00004000(misc), 0x00008000@0x00006000(resource),0x00008000@0x0000e000(kernel),0x00010000@0x00016000(boot), 0x00010000@0x00026000(recovery),0x0001a000@0x00036000(backup),0x00040000@0x00050000(cache), 0x00002000@0x00090000(kpanic),0x00280000@0x00092000(system),0x00002000@0x00312000(metadata), 0x00200000@0x00314000(userdata),0x00020000@0x00514000(radical_update),-@0x00534000(user) Inserting a tf card prevents it from booting up, suggesting that it might be possible to boot from tf card instead of getting straight into blowing away the stock firmware. However there's no sign of life trying to boot either the miqi or tinkerboard images from the card.
 
Anyone know how to open the box? I'm guessing that serial connection is going to be needed
 
 

Actually, I remember noticing a few pages back in c-ray, 8-core performance was not scaling as expected, so the issue was already there as well. We were trying to test HMP at the time, that's why nobody thought about doing single-threaded tests.
 
Turning off little cores makes the frequency scaling behave like any 4-core S905 system, including single-core performance. That's the problem (bug?) here, that is, as long as all cores are online, the frequency gets lowered, even if just 1-2 cores are being used. 
 
@buvaluy Could you try the most obvious test, activating just one little core to see what happens? Provided you already have just 4 cores active, add one more:
echo 1 | sudo tee /sys/devices/system/cpu/cpu4/online  

There could be some throttling at temps close to 80 but the main problem seems to be single-core performance. I didn't expect any difference between those boxes there, and yet, it looks like that H96 could be underclocked. For example 8-core performance scaled as if the frequencies never reached 1.5Ghz. 
 
 A repeat on a GT1 would be interesting; even my MX3 is palpably heavier (same cooling solution) and runs much cooler at idle.
 
As for the fan, no idea, have a look at some board photos in the freaktab threads.
 
 
After installing phoronix-test-suite and php, you can simply do:
$  ./phoronix-test-suite benchmark java

Ok, the borrowed Alfa is almost certainly a DDR3 box and it looks like it has some single-threaded and memory performance issues (hopefully due to the dtb file used):
 
http://openbenchmarking.org/result/1704102-RI-1609084HA38
 
and a most suspicious memory performance result:
http://openbenchmarking.org/result/1704107-RI-1702269RI77
 
It also gets as hot as 80 deg. Celsius during 8-core operation. More results will be added retroactively to this post.
 
http://openbenchmarking.org/result/1704101-RI-1609236LO94
http://openbenchmarking.org/result/1704103-RI-1703186RI71
 
 
 
 

[ This thread started more or less here :  And what do you think about porting to a cheap Android TVBox ]
 
If anyone's interested we can discuss Armbian or linux for those rk3288 devices here.
 
I'll start with mine (Q8 without front panel) which is the XT-Q8L-V10 from enybox (Chiptrip Q8 on gearbest or that other EKB328 on Aliexpress with front panel).
 
I have a feeling that those boards are discontinued and being put on sale as end of stock.
There are various other boxes with rk3288 which prices are pretty high (>80e) and were probably seen at some point as high end boxes.
 
Other threads for that board can be found here : 
- freaktab.com serial header thread
- Timp74 bitbucket.org
(both pretty old sources from mid 2015)
 
the board is the following :  (front panel is optional)
 

 
 
I already own and use many arm boards, regular ones like raspberry pi, odroid, orange pi and tv boxes mainly amlogic ones from s805 to s912.
I favor amlogic for their large availability and good linux and armbian support (thx to @balbes150 ).
 
My decision of trying to get a working rk3288 linux, is only driven by the high single core performance of that soc.
Mostly in an (high speed >100Mbps) openvpn context (openssl), some figures showed it was 30-40% faster than the s905 which is already quite fast compared to other allwinner socs.
 
I'm only looking for cheap tv boxes and for any price over 50e i would turn to dev boards with good support.
 
The idea is to take advantage of the recent popularity of rk3288 dev boards, Miqi and asus tinker although other boards already existed which is not surprising considering that soc entered the market in 2014.
Rockchip seems to be very active on the linux front and rk3288 is getting mainline uboot / kernel support.
 

Here are the results for pigz VS gzip:
 
backup and compress
pigz 7752122368 bytes (7.8 GB, 7.2 GiB) copied, 193.749 s, 40.0 MB/s
gzip 7752122368 bytes (7.8 GB, 7.2 GiB) copied, 292.576 s, 26.5 MB/s
 
test the compressed backup
pigz 0m26.781s
gzip 1m18.495s
 
decompress
pigz 9m55.684s
gzip 9m51.756s
 
All in all pigz will be a good addition in the dd_backup script.
So if balbes150 feels like adding pigz in his images, he only have to do:
sed -i "s/gzip/pigz/g" /usr/sbin/dd_backup(_x) and if decompession is also desired
sed -i "s/gunzip/unpigz/g" /usr/sbin/dd_backup(_x) and compression step will be faster and maybe decompression also a bit (according to pigz man pages).
 
The only thing to be checked is if restoring will be working as expected ( should be, but not tested ).

i expect it will, and i suppose it will greatly depend on the quality of the kernel source provided by the  MiQi or Asus projects..
 
But i can already see that the official Rockchip git (linux kernel) is quite active.
@tkaiser will probably elaborate on that front.
 
That's another nice cheap one i see, and very good to see it has gigabit, i hope my Q8 will be as well.
Could i ask you to test the Gigabit speed quality on your android (adb or terminal with iperf or iperf3).
 
Also i don't see serial headers on your picture, did you locate it ?
It would also be nice to see if you can access command prompt i uboot.
 
But considering its price, if your Gbe tests are good, i'll probably order one of those.
 
-- edit --
 
can you tell me what's the reference of the small chip next to the mini/micro usb port ?
thx

flashed it to my a95x box with ubuntu server rootfs on emmc and it booted okay here.
 
 
On another topic i'm currently trying to get an hw accelerated version of the kernel/kodi/mpv, mostly from kszaq git onto your armbian ubuntu image.
Can you confirm that you are not using any of his 3.14 kernel patches in your kernel ?
I'm also not quite sure which mali version you are using at the moment. 
 
I'm not done browsing through kszaq LE 8 files, and LE get script output,  so i'll get my answers in time but if you're kind enough to tell me what you know is missing in your image, it would be nice. thx.
 

I've just given the latest Ubuntu image a test drive and I'm delighted to report it's much better compared to the one I've been using so far (20160625):

- the temp sensor as well as WiFI works out of the box
- no problem with ZRAM swapping, I was able to go up to 3G without any OOM kills whatsoever (@balbes150, you can safely make ZRAM the default, dispensing with that puny swapfile)
- persistent eth0 MAC address
- the kernel still only supports 1.5GHz max clock (instead of 1.6GHz)
- I was unable to free the reserved memory which used to work with the old kernel

For now, I've copied the new kernel to my own image and love the benefits

@balbes150 Could you suggest a proper way of integrating the fdt commands via the s905x_init.sh script perhaps?