Jump to content

Hannspree AK01 "bricked"


Mierscheid

Recommended Posts

I have a Hannspree TV box with RK3288 (Android mini PC) on which I would like to install Armbian according to instructions from this forum (Multitool).
 

  • Multitool booted
  • Backup of the original firmware
  • Flash written with Armbian.
  • Reboot (did not happen, box does not respond)
  • Power off and power on.
  • Monitor stays black, monitor goes into standby

 

Just now I have to note that there would have been a more appropriate thread (without Q8), so I fucked up from the start.


I tried to recover the box with the original firmware I had backed up with the multitool using a USB-A to USB-A cable. But this image was not recognized.


I tried to install the Rikomagic firmware (MK902II seems to be identical in construction), but it kept aborting at 99% (download firmware fail).

I tried several times, but after some time the recovery tool under Windows (*sic*), did not recognize the box.


Also under Ubuntu, the box no longer appears under lsusb.


I made a connection via UART. The first error message is:
 

GPT 0x3337df8 signature is wrong
recovery gpt...
GPT 0x3337df8 signature is wrong
recovery gpt fail!

 

UBoot still seems to work?
 

CPU: rk3288
cpu version = 0
CPU's clock information:
    arm pll = 8160000HZ
    periph pll = 3000000HZ
    ddr pll = 3960000HZ
    codec pll = 5940000HZ
Board:    Rockchip platform Board
Uboot as second level loader

 

or not?

 

#Boot ver: 2019-07-11#2.54
empty serial no.
normal boot.
checkKey
vbus = 1
board_fbt_key_pressed: ir_keycode = 0x0, frt = 0
no fuel gauge found
no fuel gauge found
Rockchip UBOOT DRM driver version: develop-v1.0.0
Warn: route-hdmi: can't find connector driver
read logo on state from dts [1]
no fuel gauge found


Sorry, this is rather new territory for me.

Anyway, the boot process ends with:
 

[ 19.162284] init: Starting service 'clear-bcb'...
[ 19.173024] fs_mgr: Warning: unknown flag resize
[ 19.959316] read descriptors
[ 19.959347] read strings
[ 19.959992] pcd_pullup, is_on 1
[ 20.162759] fs_mgr: Warning: unknown flag resize
[ 20.165006] init: Service 'clear-bcb' (pid 1802) exited with status 0


Nevertheless a Linux starts:
 

cat /proc/version
Linux version 4.4.143 (work2@czkj) (gcc version 4.9 20150123 (prerelease) (GCC) ) #23 SMP PREEMPT Fri Jul 5 16:35:06 CST 2019


But there is no signal output via HDMI.

How should I proceed to bring the box back to life? Does anyone have a link to a manual that could help me?
 

Thanks in advance

Mierscheid

Edited by Mierscheid
Link to comment
Share on other sites

  • Mierscheid changed the title to Hannspree AK01 "bricked"

Hello, I noticed the message on the Q8 thread yesterday and noticed this other thread here right now... one baby step after another :D

 

I gave you some general hints on that thread (this post), but I guess it is more appropriate to keep the conversation here.

 

From what I see from your logs, you installled something on the board which is a legacy android, if I understand correctly you still have the backup you took with the multitool and now you have this other rikomagic firmware installed which is not really working on the box.

 

The backup took with multitool is just a raw gzipped imaged of the internal flash, I wonder what you intended with "the image was not recognized"; by whom? If the multitool is not able to recognize the backup image produced by itself probably the sdcard is faulty and the backup data is broken.

 

Multitool should allow you to backup as well restore the backed up image. Surely if you want to use the backup in AndroidTool for windows or rkdeveloptool for linux you first need to unpack (I'm not even sure AndroidTool is capable to write a raw image).

 

In the other post I mention to use maskrom mode to exclude eMMC and be able to use rkdeveloptool with USB male-to-male cable: rkdeveloptool can be used either to flash directly the backup image or erase the flash and let multitool boot again and flash image with it.

 

Since the board is booting, it is possible that the multitool boots when you put in the sdcard and give power, but as long as the firmware you installed on the eMMC is not the original one it may not be true anymore.

Link to comment
Share on other sites

Hi Jock!

Sorry about the threads, I thought the box in the Q8 thread was completely wrong.

There are days when it's best not to do anything. Lie quietly on the sofa and passively watch a complete series. Then you don't stress yourself or others.

 

  1. I had forgotten to mention that the box no longer started with Multiboot and I therefore tried to get the unpacked backup onto the box with the RockChipBatchTool (and other, apparently more or less identical tools).
  2. I changed the monitor in between, thought nothing of it, but this monitor shows no picture with this box.
  3. When I use another monitor, I see that the box does(!) start with Android 7.1, which means that the update with the tools for the Rikomagic TV-Box worked despite the error message!
  4. I don't know why the box no longer appears as a USB device, maybe it's because of the update to 7.1?


The joke of the whole story is that just now, on my own website with articles on smarthome devices, a comment came in with a question about reading out a smart meter under an article on window contacts, to which I said please work through the instructions again in a structured and step-by-step manner.


I will heed my own advice and now follow your instructions step by step in the normal RK8288 thread.
Read.
Read again.
Understand.
Only then begin.


Thank you for your work, your answer and your efforts. I will now make an effort to work properly and not have panic attacks if something does not go as expected.

Regards
Mierscheid

Edit: Okay, one moment ... Q8 means RK3288? Every RK3288 is also a Q8-Board? My understanding of the text (and even numbers!) is an absolute disaster. I will use the instructions for the Q8-Board again.

Edit 2: That is my board "R36-V2.2", Q8 ist a real board, not a board-family.
I have access again via USB-MaskROM-Mode. I was just so stupid and somehow mixed up the port. How stupid can you be? 😞
Now I have burned Multitool on a SD-Card again, but it doesn't start at all. Via picocom, I get this error message at the end:

Spoiler
... several RAM tests ...

Memory OK
Memory OK
OUT
Boot1 Release Time: Mar 28 2019 17:00:20, version: 2.54
ChipType = 0x8, 264
mmc2:cmd19,100
SdmmcInit=2 0
BootCapSize=2000
UserCapSize=7456MB
FwPartOffset=2000 , 2000
mmc0:cmd5,20
SdmmcInit=0 0
BootCapSize=0
UserCapSize=7384MB
FwPartOffset=2000 , 0
run on sd0
StorageInit ok = 103505
atags_set_bootdev: ret:(0)
GPT 0x3337df8 signature is wrong
recovery gpt...
GPT 0x3337df8 signature is wrong
recovery gpt fail!
tag:LOADER error,addr:0x2000
hdr 033377e0 + 0x0:0x45435352,0x00000000,0x00010101,0x00000001,
LOADER Check OK! 0x10000000, 181379
tag:TOS    error,addr:0x4000
hdr 033377e0 + 0x0:0x44414f4c,0x20205245,0x00000000,0x00000000,
tag:TOS    error,addr:0x6000
hdr 033377e0 + 0x0:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,

tag:TOS    error,addr:0x4800
hdr 033377e0 + 0x0:0x44414f4c,0x20205245,0x00000000,0x00000000,
tag:TOS    error,addr:0x6800
hdr 033377e0 + 0x0:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,

tag:TOS    error,addr:0x5000
hdr 033377e0 + 0x0:0x44414f4c,0x20205245,0x00000000,0x00000000,
tag:TOS    error,addr:0x7000
hdr 033377e0 + 0x0:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,

tag:TOS    error,addr:0x5800
hdr 033377e0 + 0x0:0x44414f4c,0x20205245,0x00000000,0x00000000,
tag:TOS    error,addr:0x7800
hdr 033377e0 + 0x0:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,

tag:TOS    error,addr:0x6000
hdr 033377e0 + 0x0:0x00000000,0x00000000,0x00000000,0x00000000,
tag:TOS    error,addr:0x8000
hdr 033377e0 + 0x0:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,

tag:TOS    error,addr:0x6800
hdr 033377e0 + 0x0:0x00000000,0x00000000,0x00000000,0x00000000,
tag:TOS    error,addr:0x8800
hdr 033377e0 + 0x0:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,

tag:TOS    error,addr:0x7000
hdr 033377e0 + 0x0:0x00000000,0x00000000,0x00000000,0x00000000,
tag:TOS    error,addr:0x9000
hdr 033377e0 + 0x0:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,

tag:TOS    error,addr:0x7800
hdr 033377e0 + 0x0:0x00000000,0x00000000,0x00000000,0x00000000,
tag:TOS    error,addr:0x9800
hdr 033377e0 + 0x0:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,

Enter uboot 10000000 337098


U-Boot 2018.11-armbian (Feb 05 2020 - 20:05:07 +0000)

Model: XT-Q8L-V10-RK3288
DRAM:  2 GiB
MMC:   dwmmc@ff0c0000: 1, dwmmc@ff0f0000: 0
Loading Environment from EXT4... ** File not found /boot/boot.env **

** Unable to read "/boot/boot.env" from mmc0:1 **

 

 

I'm a bit confused that it recognises the board as Q8. Or does it misrecognise it? Is my board compatible with the Q8 after all?
And at first I was still able to boot with Multitool. It's the same image from my download folder that worked.

 

Edited by Mierscheid
Link to comment
Share on other sites

4 hours ago, Mierscheid said:

Okay, one moment ... Q8 means RK3288? Every RK3288 is also a Q8-Board? My understanding of the text (and even numbers!) is an absolute disaster. I will use the instructions for the Q8-Board again.

Q8 boards are those with "Q8" in the name. Mine is a xt-q8l-v10, but there are others like eny-q8l-v10 and so on... all of them are pretty similar in the board design.

Yours has a different signature, R36 you say, and in fact it is somehow different from q8 boards.

All the boards have the rockchip rk3288 SoC, but as I said in the post of the other thread, some differences may be so important that some hardware may not work (wifi is one of the best candidates), or even don't the let kernel or the board boot at all.

 

4 hours ago, Mierscheid said:

I have access again via USB-MaskROM-Mode. I was just so stupid and somehow mixed up the port. How stupid can you be? 😞

It happens 🤷‍♂️

 

4 hours ago, Mierscheid said:

Now I have burned Multitool on a SD-Card again, but it doesn't start at all. Via picocom, I get this error message at the end:

The error message is not really an error message. That file does not exists and should not exist, therefore I don't see any other message: it looks like u-boot got stuck there because I don't see the usual messages about mmc/sdcard probing for the kernel. Are you sure it does not progress further?

 

Anyway, you can even try to burn armbian on the sdcard and let it boot from there to see if it works or not; of course if multitool does not boot probably armbian neither will, but surely worth a try.

 

As last resort, you can restore the original firmware using rkdeveloptool (and just that one, not other tools) following these instructions; just be sure to unpack the backup before running rkdeveloptool wl command

 

4 hours ago, Mierscheid said:

I'm a bit confused that it recognises the board as Q8. Or does it misrecognise it? Is my board compatible with the Q8 after all?

No, the board is not recognized as Q8. The board can't be recognized in any way from the software; instead u-boot is configured to use a stripped-down version of the device tree originally made for xt-q8l-v10. It should be generic enough to run on more rk3288 boards. If you're questioning yourself about the device tree, it is a file that contains the specs of the board hardware. Maybe you heard about ACPI/Plug and Play on x86 world, so the specs of the hardware are supplied by the BIOS to the operating system; in the ARM world there is no such thing like BIOS and ACPI, except on some server hardware. The specs of the hardware are described in a static and handwritten file given to u-boot and linux kernel, so they can know what is the hardware they have to deal with.

Link to comment
Share on other sites

Just for the record and for others who may have similar problems in the future:
 

I restored the multitool backup using sudo ./rkdeveloptool wl 0x0 tvbox-backup.data. The unpacked image had no extension. I simply added ".data". 

This may have been a mistake, because the box seemed to be really bricked now, because the box doesn't start anymore and no LED lights up.


I no longer get any input via picocom, only brief confused characters when I press the reset button.
 

Even without pressing the reset button, the box appears via USB as "2207:320a Fuzhou Rockchip Electronics Company RK3288 in Mask ROM mode".
It also does this without me connecting the power supply.


rkdeveloptool can no longer do anything with the box. Every operation "failed".


I removed the battery and left the board without power for a while, but this behaviour does not change.


All right, so now I have plugged in the multi-boot SD card and lo and behold: now I can get back into the multitool. This box seems to be unbrickable.


I installed the above-mentioned Armbian image again, but the screen remains black.

Via picoterm I see that the start-up procedure stops at "Starting kernel ...".

Spoiler
DDR Version 1.08 20190523
In
Channel a: LPDDR3 400MHz
MR0=0x88774458
MR1=0x88774458
MR2=0x88774458
MR3=0x88774458
MR4=0x88774403
MR5=0x88774401
MR6=0x88774403
MR7=0x88774400
MR8=0x8877441B
MR9=0x8877441B
MR10=0x8877441B
MR11=0x8877441B
MR12=0x8877441B
MR13=0x8877441B
MR14=0x8877441B
MR15=0x8877441B
MR16=0x8877441B
Bus Width=32 Col=10 Bank=8 Row=14/14 CS=2 Die Bus-Width=32 Size=1024MB
Channel b: LPDDR3 400MHz
MR0=0x88774458
MR1=0x88774458
MR2=0x88774458
MR3=0x88774458
MR4=0x88774403
MR5=0x88774401
MR6=0x88774403
MR7=0x88774400
MR8=0x8877441B
MR9=0x8877441B
MR10=0x8877441B
MR11=0x8877441B
MR12=0x8877441B
MR13=0x8877441B
MR14=0x8877441B
MR15=0x8877441B
MR16=0x8877441B
Bus Width=32 Col=10 Bank=8 Row=14/14 CS=2 Die Bus-Width=32 Size=1024MB
Memory OK
Memory OK
OUT

U-Boot SPL 2022.04-armbian (Apr 24 2022 - 12:52:02 +0000)


U-Boot 2022.04-armbian (Apr 24 2022 - 12:52:02 +0000)

Model: XT-Q8L-V10-RK3288
DRAM:  2 GiB
Core:  189 devices, 22 uclasses, devicetree: separate
MMC:   dwmmc@ff0c0000: 1, dwmmc@ff0f0000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial
Out:   vidconsole
Err:   vidconsole
Model: XT-Q8L-V10-RK3288
Net:   eth0: ethernet@ff290000
starting USB...
Bus usb@ff540000: USB DWC2
Bus usb@ff580000: USB DWC2
scanning bus usb@ff540000 for devices... 3 USB Device(s) found
scanning bus usb@ff580000 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0 
Card did not respond to voltage select! : -110

Device 0: unknown device
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
3395 bytes read in 3 ms (1.1 MiB/s)
## Executing script at 00000000
Boot script loaded from mmc 0
147 bytes read in 2 ms (71.3 KiB/s)
7072772 bytes read in 169 ms (39.9 MiB/s)
9368192 bytes read in 222 ms (40.2 MiB/s)
58202 bytes read in 7 ms (7.9 MiB/s)
232 bytes read in 4 ms (56.6 KiB/s)
Applying kernel provided DT fixup script (rockchip-fixup.scr)
## Executing script at 39000000
Kernel image @ 0x2000000 [ 0x000000 - 0x8ef280 ]
## Loading init Ramdisk from Legacy Image at 21000000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    7072708 Bytes = 6.7 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
   Loading Ramdisk to 0f941000, end 0ffffbc4 ... OK
   Loading Device Tree to 0f8ca000, end 0f940fff ... OK

Starting kernel ...

 

 


I will now try another image and report back.
Or how would you proceed?
 

And yes: the device tree is very reminiscent of the Kext (kernel extensions) of macOS, which you sometimes have to deal with if you want to get natively unsupported hardware to work on a Hackintosh.

Unfortunately, I would have to get _some_ OS to work on the box before I could read out the configuration. Dumb.

Edit:

Oh yes, okay, that doesn't work properly, because after the Armbian installation it is again not possible to boot from the SD card. 

So I wanted to install the original image again with the rkdeveloptool, even if this is not executable, you can still boot from an SD card with it.

But now I have the problem that the rkdevelop tool no longer recognises the box. Every operation ends in a failure, even if lsusb shows me the box correctly.

Status:

  • Box boots with non-functioning armbian (kernel panic?)
  • Box no longer boots from SD card
  • rkdevelopetool can no longer read the box (Getting flash info from device failed!


Any suggestions? 🙂
 

Spoiler
DDR Version 1.08 20190523
In
Channel a: LPDDR3 400MHz
MR0=0x88774458
MR1=0x88774458
MR2=0x88774458
MR3=0x88774458
MR4=0x88774403
MR5=0x88774401
MR6=0x88774403
MR7=0x88774400
MR8=0x8877441B
MR9=0x8877441B
MR10=0x8877441B
MR11=0x8877441B
MR12=0x8877441B
MR13=0x8877441B
MR14=0x8877441B
MR15=0x8877441B
MR16=0x8877441B
Bus Width=32 Col=10 Bank=8 Row=14/14 CS=2 Die Bus-Width=32 Size=1024MB
Channel b: LPDDR3 400MHz
MR0=0x88774458
MR1=0x88774458
MR2=0x88774458
MR3=0x88774458
MR4=0x88774403
MR5=0x88774401
MR6=0x88774403
MR7=0x88774400
MR8=0x8877441B
MR9=0x8877441B
MR10=0x8877441B
MR11=0x8877441B
MR12=0x8877441B
MR13=0x8877441B
MR14=0x8877441B
MR15=0x8877441B
MR16=0x8877441B
Bus Width=32 Col=10 Bank=8 Row=14/14 CS=2 Die Bus-Width=32 Size=1024MB
Memory OK
Memory OK
OUT

U-Boot SPL 2022.04-armbian (Apr 24 2022 - 12:52:02 +0000)


U-Boot 2022.04-armbian (Apr 24 2022 - 12:52:02 +0000)

Model: XT-Q8L-V10-RK3288
DRAM:  2 GiB
Core:  189 devices, 22 uclasses, devicetree: separate
MMC:   dwmmc@ff0c0000: 1, dwmmc@ff0f0000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial
Out:   vidconsole
Err:   vidconsole
Model: XT-Q8L-V10-RK3288
download key pressed, entering download mode...resetting ...

 

 

Edited by Mierscheid
Link to comment
Share on other sites

2 hours ago, Mierscheid said:

I restored the multitool backup using sudo ./rkdeveloptool wl 0x0 tvbox-backup.data. The unpacked image had no extension. I simply added ".data". 

This may have been a mistake, because the box seemed to be really bricked now, because the box doesn't start anymore and no LED lights up.

Extensions have no meaning in the Unix world, you can even rename that file with a ".exe" extension but it does not change anything. What counts is the data in the file.

 

The procedure requires that you first erase the eMMC with rkdeveloptool ef command; when done turn the box off, then turn the box on and you will be in MaskROM mode .

Once there, follow the steps from "Restore backup" paragraph in the link above:

  • you have to first use rkdeveloptool db command to upload a program to the SoC to program (no pun intended) the eMMC
  • you can skip the rkdeveloptool ul command (it was necessary for manual backups, not for multitool backups)
  • run the rkdeveloptool wl command

 

2 hours ago, Mierscheid said:

I no longer get any input via picocom, only brief confused characters when I press the reset button.

Maybe the serial is switched to 1.5Mbps; some firmwares use 115200, some others use 1.5Mbps and may show you garbled data.

On multitool and armbian by default I use 115200bps for compatibility.

 

2 hours ago, Mierscheid said:

Even without pressing the reset button, the box appears via USB as "2207:320a Fuzhou Rockchip Electronics Company RK3288 in Mask ROM mode".
It also does this without me connecting the power supply.


rkdeveloptool can no longer do anything with the box. Every operation "failed".

Yes, both of these behaviours are expected.

 

The OTG port works as a power supply since it is supposed to be bidirectional. In fact when you do maintenance in maskrom mode you have not to connect the regular power supply but just the USB cable. Not all boards work this way though, but it looks like that both mine and yours behave this way.

rkdeveloptool does not let you do anything with the box in MaskROM mode because you first have to upload the famous program with rkdeveloptool db I talked above. Once you do that, then you can use the other rkdeveloptool commands (including ef, wl, etc...)

 

A lot of confusion comes from a fact: rockchip u-boot bootloader that is shipped with original firmwares, when stuck or when the reset button is pressed, provides the RockUSB mode, which is similar to MaskROM, but it is not the same! Unfortunately lsusb has no chances to recognize the difference and will tell you the board is in MaskROM mode, but it is not true. When you are in RockUSB mode, rkdeveloptool works without the bootstrap program because on the other side there is u-boot that is already answering.

Another very very important difference between MaskROM and RockUSB modes is that the latter does not allow you to write the whole firmware: it will skip the first 0x2000 sectors, not allowing to overwrite the bootloader part, plus it will shift by the same amount the image you're going to write on the internal flash. Clearly this breaks everything, because partitions will not be in the expected positions anymore.

 

To make the long story short: always operate on the internal flash when you're in real MaskROM mode.

To get into real MaskROM mode you have to:

  • erase the internal flash, or
  • gate the clock pin with the screwdriver/whatever trick

This is because the SoC on first instance tries to boot from eMMC. If it does not find a valid bootloader, then tries to boot from sdcard. If a valid bootloader is not there too, then stays there waiting in MaskROM mode waiting for an input from USB OTG port. No firmware/software has been loaded at this point, and that's the reason why you must upload the bootstrap program with rkdeveloptool db command before you can do anything else.

 

2 hours ago, Mierscheid said:

I installed the above-mentioned Armbian image again, but the screen remains black.

Via picoterm I see that the start-up procedure stops at "Starting kernel ...".

Yes, this is the problem I talked you about the differences on the boards: the kernel is stuck somewhere because the device tree tells about a hardware configuration but your board has a different hardware configuration.

If you burn the image on a sdcard, you can edit the file /boot/armbianEnv.txt and change verbosity=1 to verbosity=7 to let the kernel to show the whole log on the serial. This is of great help when you're debugging.

 

You may also try armbian images for the Asus Tinkerboard-S, which has the rk3288 SoC as well and share many similarities.

 

edit: you didn't say if you tried to just restore the backup with the multitool. Did you try? That's the easiest way to restore the backup...

Link to comment
Share on other sites

First of all, more than heartfelt thanks for all your effort and the excellent and detailed explanations that serve as self-help.
 

I don't know what's wrong with me. I'm afraid the first time I didn't activate bootloader. *facepalm*
Therefore, rkdevelopetool does not work the second time until I loaded the Bootloader. *sic*


So the procedure is as follows (on Ubuntu, hence sudo *sic*). I wrote it down for myself, but I will publish it on my german website with reference to you and the forum.


Restore


We first have to activate the real MaskROM mode and then restore the backup of our firmware.
Note: This is actually RockUSB mode, which cannot write the first 0x2000 sectors, even if lsusb reports "2207:320a Fuzhou Rockchip Electronics Company RK3288 in Mask ROM mode".


1) Press the reset button (download button).
 

2) Plug the USB-A to USB-A cable into the slave USB (OTG) port of the box.


3.) Release button


4) Download the bootloader to the box:

sudo ./rkdeveloptool db ../rk32/rk3288_ubootloader_v1.01.06.bin


5) Activate bootloader

./rkdeveloptool ul ../rk32/rk3288_ubootloader_v1.01.06.bin


6) Delete Flash:

./rkdeveloptool ef


Only now is the Mask-ROM-USB-Mode also activated!


7) Restore image

sudo ./rkdeveloptool wl 0x0 tvbox-backup.data

Now the original Android 5.1 from Hannspree boots again.

 

Strange: As soon as you do it right, it works.

 

But without your explanations I wouldn't have noticed that I had forgotten the line with the more active one. It looks identical at first glance, so I must have made a mistake in the line.

I'm sorry for all the effort you had to put in.

 

I will now try out some Armbian images (only find Asus TB-2 instead of -S). 

Edited by Mierscheid
Link to comment
Share on other sites

6 hours ago, Mierscheid said:

I will now try out some Armbian images (only find Asus TB-2 instead of -S). 

This is the download page for Tinkerboard / Tinkerboars-S: https://www.armbian.com/tinkerboard/

 

Well, there is still confusion in your steps:

If you want to write a full image (step 7) to the eMMC, you don't need step 5 and step 6.

If you want to erase the flash and let the device always boot from sdcard, you step 5 is not needed

 

Also when you do step 6, the device is not automatically in maskrom mode... it will enter maskrom mode when you turn it off and turn it on again!

Remember that you are in real maskrom mode when you first need to run rkdeveloptool db command.

 

6 hours ago, Mierscheid said:

5) Activate bootloader

./rkdeveloptool ul ../rk32/rk3288_ubootloader_v1.01.06.bin

This is not exactly "activation" of the bootloader. ul means upgrade loader: it will write the bootloader on the eMMC in the famous first 0x2000 sectors.

 

Although it is very harmless to run the command after db command, you don't really need ul if you're going to erase the internal flash right after with ef command.

You also don't need to do ul if you're going to burn a full image, either taken from multitool backup or a pristine armbian image.

 

I'm sorry about the confusion, but it is so because the instructions on the linked page assumed that you are going to do a manual backup in rockusb mode (that will skip the first 0x2000 sectors), and then restore in maskrom mode.

Multitool came much later than those instructions, I left them there for reference. Multitool is the preferred way to do backup and restore because has no limitations and indeed is much easier to use.

 

 

 

Link to comment
Share on other sites

Hi,

 

thank you for your posts, jock and Mierscheid! They got me out of trouble with my "bricked" Hannspree TV Box.

But right now, I am standing at the same point like you, Mierscheid.

 

Did you finally find any Armbian image that works on this specific box? Or should I give up my hope and send that thing back?

Link to comment
Share on other sites

Hi,i have an rockchip device but i have a problem,after some firmware wirting on eMMC my device not detected as rockchip .... it detect as multifunction gadget and rkdeveloptool and factorytool cant detect the device any more so i cant writing any firmware on it this is the detection output (lsusb) /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
    |__ Port 1: Dev 10, If 0, Class=Vendor Specific Class, Driver=, 480M
    |__ Port 1: Dev 10, If 1, Class=Communications, Driver=cdc_ether, 480M
    |__ Port 1: Dev 10, If 2, Class=CDC Data, Driver=cdc_ether, 480M

anybody can HELP?!

Edited by someone666
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines