TL;DR: Still failing. Gave up again.
Back when I bought a RK3066 based device, I had seen rockchip developers start contributing directly upstream. However, the RK3066 just missed the boat, and while I poked and prodded a bit, it was all just a bit too difficult and a bit too complicated a bit too much not much fun. Still, I followed what was going on. The plan was to use the swell of consumer electronics to get a cheap android tv box that I could run linux on, and use as a small home server. “Just use a raspi” you say. Well, no. Raspi3 is at least decently powerful, but running everything off a sdcard, and not having a case is really not what I was looking for. Little tiny cute black boxes, with a remote control and a power supply and ethernet and usb shipped for $30? That’s what I want to reuse. Rockchip continued to contribute upstream, so I bought a MXQ 4K (RK3229). New hotness I thought, but the cheap end. I still believed that rockchip was doing the best job of upstream support. Note: My copy of this device has a much smaller heatsink, Spectek flash, not Sandisk, and some generic no name ram chips. (See pics)
Top side, smaller heatsink, no name ram.
Maybe they are. And I’ve not worked on amlogic or sunxi chips, but goddamn, the work environment is still just as sucky. A garbage world of “custom roms” and complicated documentation detailing multiple ways of doing things with rarely any explanation of why. I’ve still no idea, but some things seem a little clearer than last time… maybe?
If you just want to run linux, in _theory_ you can just use the existing android kernel shipped stock. It has support for all your hardware, you just need to replace the root file system (RFS) and amend the kernel command line to say where your rootfs is. Except, because some of the drivers are actually separate binary proprietary modules, you end up needing a fucking initrd/initramfs timewaste so it can have such core details like a functional fucking nand driver. Why the fuck rockchip is keeping _this_ bit proprietary is beyond me. So that gets non-trivial quickly. You can in theory extract the modules from your android system image. If you have a stock firmware, (“update.img”) you can use rkunpack from the rkflashtool repository. you’ll probably have to unpack more than once. Documentation on what’s what is less than forthcoming. The “system.img” wil be a raw ext4 image (in theory) and you can mount it locally to explore with “sudo mount -o loop blah.img somemountpoint”
anyway, while some of this is just for my own notes, not really for anyone else, one thing has stuck out. First, the default serial console is at 1500000 baud. Thanks for nothing rockchip. On a cp2102 serial dongle, you’ll need to use the silabs baud rate aliasing software to get to this baud rate. Thanks for nothing silabs. and yeah, again, thanks for nothing rockchip. The serial console is in the picture below.
Bottom side, spectek flash, serial console details
Oh yeah, the “thing that has stuck out” Despite being “unbrickable” because they have a maskrom bootloader, and normally just going into recovery mode, I’ve had great difficulty. After some bad flashing, (bad why? no idea, rkflashtool or upgrade_tool both successfully report the flashing complete, then I reboot, and get…. bad things) the serial console will hang on a line like…
In 300MHz DDR3 Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB mach:2 OUT Boot1 Release Time: 2016-03-15, version: 2.31 ChipType = c 275 No.1 FLASH ID:2c 64 64 56 a5 4 ECC:60 ReadRetry pageadd=15d800 ecc=3c err=ffffffff Read pageadd=15d800 ecc=3c err=ffffffff spare: 0x0:b8679151 b8679151 b8679151 b8679151 ReadRetry pageadd=15d801 ecc=3c err=ffffffff Read pageadd=15d801 ecc=3c err=ffffffff spare: 0x0:527ded0c 527ded0c 527ded0c 527ded0c SdmmcInit=0 20 StorageInit ok = 134644 SecureMode : SBOOT_MODE_NS powerOn 812121 Usb re Boot. 6812118
At this point, rkflashtool v will “fail” like so… (notice mangled text)
$ rkflashtool v rkflashtool: info: rkflashtool v5.2 rkflashtool: info: Detected RK322X... rkflashtool: info: interface claimed rkflashtool: info: chip version: 322A-��..��-��
upgrade_tool will still say the device is connected, in “Loader” mode, and TestDevice, ReadFlashID, ReadFlashInfo and ReadChipInfo all still work. But attempting to download any image will fail saying parameter is invalid. rkflashtool p agrees.
rkflashtool p rkflashtool: info: rkflashtool v5.2 rkflashtool: info: Detected RK322X... rkflashtool: info: interface claimed rkflashtool: info: reading parameters at offset 0x00000000 rkflashtool: info: size: 0x0000ffff rkflashtool: fatal: Bad parameter length!
One time this happened, I got out of it by having the USB-A-A cable disconnected (oh yeah, A-A for OTG? thanks for fucking nothing rockchip, hooray port overloads and reverse powering disasters) holding the recovery button down (with a toothpick down the SPDIF hole. (button down the AV hole _should_ be different but seems to behave the same for me)) and then plugging in the main power supply. Perhaps it had been a problem with powering the device purely via the A-A cable as I’d normally been doing?
Who knows. It’s currently in this state again, the unbrickable “bricked” Even shorting pins 7-8 on the NAND chip itself and powering up isn’t helping. (The “standard” rockchip method of getting back to maskrom mode) I get a different log, but it’s still non-responsive, even after inserting the A-A cable. (Still in loader, but not really working)
DDR Version V1.04 20160504 In 300MHz DDR3 Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB mach:2 OUT Boot1 Release Time: 2016-03-15, version: 2.31 ChipType = c 276 No.1 FLASH ID:2c 64 64 56 a5 4 FlashLoadPhyInfo fail 2bc!! sync para 32 sync para 32 ECC:60 ReadRetry pageadd=15d800 ecc=3c err=ffffffff Read pageadd=15d800 ecc=3c err=ffffffff spare: 0x0:b8679151 b8679151 b8679151 b8679151 ReadRetry pageadd=15d801 ecc=3c err=ffffffff Read pageadd=15d801 ecc=3c err=ffffffff spare: 0x0:527ded0c 527ded0c 527ded0c 527ded0c SdmmcInit=0 20 StorageInit ok = 93093 SecureMode : SBOOT_MODE_NS powerOn 770567 Usb re Boot. 6770565
So. No results, no future, but at least a weird log for the internet to archive if it helps anyone sometime.
It looks like you were getting into maskrom mode, which won’t show anything on the serial. Once you’re there, use rkdeveloptool ef to erase the flash. Then, you can load a full upgrade.img and it will “just work”.