yashsingh1/xdaforums huggingface dataset:
[Android Head-Units] radux.m.dan:
Recovery partition

Hi Chris!

I made some progress with custom recovery image. I was able to find out that our recovery partition is /dev/block/ndda6 and it has a protection mechanism, it is being restored every boot if it detects some modification. The size of the partition is 10.5MB

You can read more about this protection here: http://www.droidforums.net/threads/...ure-to-undo-custom-recovery-partitions.73565/

I was able to compile CyanogenMod for our device using the boot.img file from the update archive. This was just for test, I still need to set some variables and I'll give it a try, as anyway I have this protection in place so only at first boot in recovery it should use the custom one, after that it will be restored with stock one.

Cheers!
[Android Head-Units] chris.davis925:
Thanks for researching this. I saw this type of behavior as well, but I wasn't sure if it was okay to delete the recovery-from-boot.p file.

For those interested, here is the install-recovery.sh that appears to reconstruct the recovery image dynamically from our Kenwood

#!/system/bin/sh

if ! applypatch -c EMMC:/dev/block/ndda6:9883648:6b774091d234b18d3deb91cd89c0a378854129fb; then

log -t recovery "Installing new recovery image"

applypatch EMMC:/dev/block/ndda1:9838592:ec4c8e1de5b450c0053f48d68700348723694af3 EMMC:/dev/block/ndda6 6b774091d234b18d3deb91cd89c0a378854129fb 9883648 ec4c8e1de5b450c0053f48d68700348723694af3:/system/recovery-from-boot.p

else

log -t recovery "Recovery image already installed"

fi

[MENTION=5909218]radux.m.dan[/MENTION] Have you tried deleting recovery-from-boot.p from the /system partition?

---------- Post added at 03:22 PM ---------- Previous post was at 03:16 PM ----------

Also, you should be able to see a similar behavior on other partitions, though I don't think it's done the same way as recovery. If you trip some service in Android that detects /system changes you can see that that the log file will display something like ***/SYSTEM has been modified!*** on every boot, in which case I think it tries to revert back changes. I am guessing that this is also what is causing the problem of some apps stopping to work - usually (but not always) after you update an existing app that resides on a quasi locked / monitored partition.

Last update - the init.rc file also appears to be settings the USB and OTG functionality. It might be worth checking into.
[Android Head-Units] radux.m.dan:
Hi!

Can you please tell me on which pins did you found the serial port? Maybe you already mentioned this but it's a very long thread and I couldn't find it.

Regards,

-Radu.
[Android Head-Units] pdanders11:
Hello. This is what I rigged up. I'll add the pins when I see how these post. So picture 4 is the pins I've identified in picture 3 looking at the pinfield.

so if we say the numbering at the pin header is

1 2

3 4

5 6

7 8

9 10

11 12

13 14

15 16

17 18

19 20

I have pin 16 as the TX. 3.3VDC TTL
[Android Head-Units] pdanders11:
Thanks for this info. if you check the serial port it says recovery is ndda5 or i had a copy and past error or everything is shifted off one partition.

NAND ] V8.60.86

[NAND ] TH58NVG4S0F

[TNFTL ] Die_0:.

[TNFTL ] Die_1:3002 .

[NAND ] Die=2, B/D=4096, P/B=64, Pg=4096 CW=512 Pln/D=2

[NAND ] [RO] sectors

2002432 ndda [PARTITION : boot] [START : 32] [SIZE : 20480] [TYPE : 0]

10240 ndda1 [PARTITION : system] [START : 20512] [SIZE : 962560] [TYPE : 83]

481280 ndda2 [PARTITION : userdata] [START : 983072] [SIZE : 716800] [TYPE : 83]

358400 ndda3 [PARTITION : ] [START : 1699872] [SIZE : 2304992] [TYPE : f]

1 ndda4 [PARTITION : cache] [START : 1699904] [SIZE : 307200] [TYPE : 83]

153600 ndda5 [PARTITION : recovery] [START : 2007136] [SIZE : 20480] [TYPE : 0]

10240 ndda6 [PARTITION : kpanic] [START : 2027648] [SIZE : 10240] [TYPE : 0]

5120 ndda7 [PARTITION : splash] [START : 2037920] [SIZE : 10240] [TYPE : 0]

5120 ndda8 [PARTITION : misc] [START : 2048192] [SIZE : 2048] [TYPE : 0]

1024 ndda9 [PARTITION : tcc] [START : 2050272] [SIZE : 2048] [TYPE : 0]

1024 ndda10 [PARTITION : snapshot] [START : 2052352] [SIZE : 307200] [TYPE : 0]

153600 ndda11 [PARTITION : kw] [START : 2359584] [SIZE : 20480] [TYPE : 83]

10240 ndda12 [PARTITION : navi] [START : 2380096] [SIZE : 16384] [TYPE : 83]

8192 ndda13 [PARTITION : update] [START : 2396512] [SIZE : 2048] [TYPE : 0]

1024 ndda14 [PARTITION : ] [START : 2398592] [SIZE : 1606272] [TYPE : 6]

803136 ndda15

anyway I tried flashing a custom recovery with the .p and .sh renamed and it still rebuilt. Curious what you find.

Have you unpacked boot.img?

http://androtab.info/arm/telechips/customize-firmware/

interesting stuff in there.

init.factory.rc

In the ramdisk image in the boot.img looks like it may be rebuilding the system. Not sure. Seems like the recovery and system checks are early on maybe in very early boot. Really makes tinkering seems dangerous it seems if we can't get back to recovery. I'm still slowing trying to get a JTAG loader going. FWDN mode may be able to unbrick a board.

Maybe I missed something obvious and it's not this bad.
[Android Head-Units] chris.davis925:
Hope this helps.
[Android Head-Units] chris.davis925:
Are you sure it actually removed and not just removed from cache/memory? The NAND lock goes into effect after some changes. If you rooted the deck with my process, that's enough to trigger the lock.

Try to write some extra data to one of those files and see if that extra data is present on the next reboot. If it's not, the locking of /system is the reason. In which case, apply the update file again and delete the required data and apply the recovery rom during the root process.
[Android Head-Units] radux.m.dan:
Many thanks for the info regarding serial port. This is the log from the bootloader.

The recovery partition is ndda6 for sure, your log is misaligned.

NAND ] V8.60.86

[NAND ] TH58NVG4S0F

[TNFTL ] Die_0:.

[TNFTL ] Die_1:3002 .

[NAND ] Die=2, B/D=4096, P/B=64, Pg=4096 CW=512 Pln/D=2

[NAND ] [RO] sectors 2002432 ndda

[PARTITION : boot] [START : 32] [SIZE : 20480] [TYPE : 0] 10240 ndda1

[PARTITION : system] [START : 20512] [SIZE : 962560] [TYPE : 83] 481280 ndda2

[PARTITION : userdata] [START : 983072] [SIZE : 716800] [TYPE : 83] 358400 ndda3

[PARTITION : ] [START : 1699872] [SIZE : 2304992] [TYPE : f] 1 ndda4 -----> this is extended partition

[PARTITION : cache] [START : 1699904] [SIZE : 307200] [TYPE : 83] 153600 ndda5

[PARTITION : recovery] [START : 2007136] [SIZE : 20480] [TYPE : 0] 10240 ndda6

[PARTITION : kpanic] [START : 2027648] [SIZE : 10240] [TYPE : 0] 5120 ndda7

[PARTITION : splash] [START : 2037920] [SIZE : 10240] [TYPE : 0] 5120 ndda8

[PARTITION : misc] [START : 2048192] [SIZE : 2048] [TYPE : 0] 1024 ndda9

[PARTITION : tcc] [START : 2050272] [SIZE : 2048] [TYPE : 0] 1024 ndda10

[PARTITION : snapshot] [START : 2052352] [SIZE : 307200] [TYPE : 0] 153600 ndda11

[PARTITION : kw] [START : 2359584] [SIZE : 20480] [TYPE : 83] 10240 ndda12

[PARTITION : navi] [START : 2380096] [SIZE : 16384] [TYPE : 83] 8192 ndda13

[PARTITION : update] [START : 2396512] [SIZE : 2048] [TYPE : 0] 1024 ndda14

[PARTITION : ] [START : 2398592] [SIZE : 1606272] [TYPE : 6] 803136 ndda15 ------> this is a FAT32 partition

Another good thing that you found is that boot select pin to enter FWDN mode, with this you can make the parition table and download any of them.

The bootloader named lk.rom that FWDN is using is in fact renamed and is in our update file and is named bootloader.img

As I live in Romania my unit is secured in the dash and I have to take out the dashboard first to be able to remove it, I need to run some tests on the bench :)

Best regards!

---------- Post added at 09:50 AM ---------- Previous post was at 09:37 AM ----------

I forgot to mention, in the Telechips PDK that is flying around on the internet you will find some scripts for Trace32, just in case you want to attach with Lauterbach on JTAG. The files are located in bootloade/lk directory.
[Android Head-Units] radux.m.dan:
small demo

It is far from final but it is a start.;)
[Android Head-Units] pdanders11:
Sweet! That's awesome.

Thanks for the other info. If you need to test something out of your car, I have a unit on my bench I can try things out on.
[Android Head-Units] chris.davis925:
Thanks!

When you get a chance, can you download the various partitions and post them here? I need to get my unit back on the bench too.
[Android Head-Units] jbeavis19:
I got it working, I think I just had the car too far from the wifi router. Thanks though.
[Android Head-Units] pdanders11:
Just saw you last comment. Yes, I have both SDK's that are floating around ( the one with Android 4.0.4 was harder to find) and have built "a kernel" and bootloader. I just haven't had the guts to load them as I had to tweak a few things. I was going to go back and rebuild with a clean .config . May need the Kenwood source was my concern at the time but the (most) bugs were just in the telechips/Android code that were documented on the web.

What's not clear to me are the non-standard partitions referenced like the Telechips TCC partition. I'm not sure what would happen if that got blown away. I'm also a bit confused about the MTD partition and the more standard ndda (mmcblk) partitions. I haven't dealt with MTD and what I seen out there most devices that use MTD have all the standard partitions in MTD. This just shows mtd0 and mtd0ro. So the mix has me confused. I've been able to read and write back mtd0 with MTD utils. But I assume just DD is needed for the others.

I've also been trying/reading about the boot modes and trying to get a SD-CARD boot. Would require a hardware mod but with the partitioning seemed like a safer way to mess around if it was possible to copy and boot off the SDCARD. The documentation seems to indicate I need a new bootloader/Kernel.

Unfortunately my debuger doesn't support the full TRACE32 command set so I've been trying to get them converted/dumbed down and updated for the Kenwood configuration.

PS I think I had the UART pin on the wrong side of my original pinout. It's should be pin 16.

PPS if anyone is still messing around with the OTG interface, I may have more reliable connection with a capacitor between pins 1 and pin 4 added. I can't see why it helps on a scope (or it's just acting flaky and now its working), but there is 47 nF cap on the board from pins 1 to 4. I'm now running with a cap in my USB cable and am no longer grounding the pin nearest the pack of the unit.

---------- Post added at 06:27 AM ---------- Previous post was at 06:25 AM ----------

I just used another 47 nF cap
[Android Head-Units] radux.m.dan:
Hello!

As you've seen in my posts before I tested a custom recovery, what is funny is that the protection to restore the OEM recovery is not working, I guess I have a different boot image and has a different SHA so the script fails.

Now, I have to ask you a small favor, I need to check something in the OEM recovery and now I don't have it.

If one of you can read it and post it here it would be great. I give you the steps below, in fact I need partition ndda6

Connect with ADB, use adb root or use su command to become root.

1. dd if=/dev/block/ndda6 of=/data/local/tmp/recovery.img

2. exit

3. adb pull /data/local/tmp/recovery.img .

Now attach the file here so I can get it :)

Cheers!
[Android Head-Units] aplusmiami:
I tried putting a cap across pins 1 and 4 and I still only got unknown device. I honestly think I damaged or tripped some sort of security on my 2 units.
[Android Head-Units] pdanders11:
I can do it when I get home from work if no-one beats me too it.

Also, there is Linux utility unpackbootimg or something like that that will dump recovery from the boot.img. Not sure if that would give you what you what toy need from the update.zip

---------- Post added at 03:14 PM ---------- Previous post was at 02:48 PM ----------

I smoked one of my boards. There was a pretty much a dead short on one if the usb lines to ground.

If that's not the case, it's strange what trips and brings back that port.

---------- Post added at 03:21 PM ---------- Previous post was at 03:14 PM ----------

I went back and tried to rebuild the kernel and they're some i2c sensors that's failing build. The.config extracted from the unit wants to compile some camera modules. I assume for backup camera or dead code

I assume there is something in Linux to interrogate the I2C bus. I'll try to find those.id's
[Android Head-Units] chris.davis925:
I'll have my unit on the back on the bench this evening, in case no one else has posted it by then I can get it for you.

Also, I have some information on getting the unit to boot from USB in order to test various boot images. If this is still helpful let me know and I'll try to dig that up.
[Android Head-Units] radux.m.dan:
In order to compile the kernel we need to move the nand V8 driver from the newer package, because if you look in the PDK 4.0.4 you will see it is only V7 driver.

I really want to make a test with FWDN and check if we are able to connect and download the bootloader at least. I still didn't had time to remove the unit from my car and won't have time this week cause I'll go to formula one during the weekend :D
[Android Head-Units] pdanders11:
Thanks for the info on the driver.

I have verified the unit will grab the boot loader lk.Rom. I did this with the loader I built and yesterday I did what you said and let it load the boot loader from the update package.

Then it says something about USB mode.
[Android Head-Units] pdanders11:
Here you go.
[Android Head-Units] pdanders11:
So confirmed FWDN can be entered via the test connector. FWDN mode = BM2 = GND.
[Android Head-Units] chris.davis925:
Nice!

What does your screen display when in FWDN mode?
[Android Head-Units] pdanders11:
Nothing exciting. Fans spins up, screen just stays blank but VTC drivers wake up and FWDN.exe will serve the bootloader over USB.
[Android Head-Units] chris.davis925:
Figures.

Can you dump all of the partitions and post them here for review?
[Android Head-Units] radux.m.dan:
Thank you very much for the stock recovery file.

Good to know that FWDN connects to our target, this means we have the option to create a new partition table, I think the recovery partition size is at the limit, I hope I will be able make CWM fit.

[MENTION=219148]Chris[/MENTION], can you tell us how to boot from USB?

Why do you need all the images of the partitions? I already copied mine, but you can do it also, just use dd.

Connect with ADB as root and insert a USB memory stick, then use dd if=/dev/block/nddax of=/dev/mnt/usb_sda1/nddax.img where x is a number from 1 to 14, do not use 4 as this is the extended partition. That is all :)

Best regards!
[Android Head-Units] radux.m.dan:
test recovery

Hello!

Who has a unit on the bench and is willing to test this recovery image and send me the logs. It is not functional so I would need the kernel log, dmesg.

What you need to do is download this file and use ADB to connect to your unit.

adb push recovery.img /data/local/tmp

adb root

adb shell

dd if=/data/local/tmp/recovery.img of=/dev/block/ndda6

reboot recovery

Now once you are in recovery mode connect the USB cable to your PC and ADB port should be available.

adb shell dmesg > kernel.log

Now just attach the log file here.

Cheers!
[Android Head-Units] chris.davis925:
I think i can make my unit go into FWDN mode via software, but I am not sure since I can't get USB to present itself anymore. I can make the stock boot loader sit on "waiting" after initiating the Android update mode.

I will test your recovery as soon as I get the unit out of this mode, but I am afraid that USB still might not present itself.

---------- Post added at 04:10 PM ---------- Previous post was at 03:37 PM ----------

Alright I had to force the unit to reset itself.

Anyhow, I applied your recovery image. I can't get USB to present itself, though I fear this might be problem with my cable / connector since I can't even get an unknown device to populate.

I would like to note that I was able to reboot three times into recovery and it still has not reset itself back to the factory recovery.
[Android Head-Units] pdanders11:
Got it installed. logs shortly.
[Android Head-Units] pdanders11:
I copied the image over on a USB drive and used SSH to install. USB must not work on Wednesdays.lol. USB did wake up in recovery though.
[Android Head-Units] aplusmiami:
What USB port are you using?
[Android Head-Units] pdanders11:
I copied the recovery image to a flash drive and connected it to the "USB" port aka the upgrade port (not wifi, not ipod). As Dan mentioned it shows up under /mnt/usb_sda1 .

I run DroidSSH and just connect that way so I don't have to mess with the OTG port. Today OTG wasn't working until I booted into recovery.

If I have to pull a file and OTG isn't working I use busybox ftpd to serve the file.

Does that answer your question?
[Android Head-Units] aplusmiami:
Yes it does - I am waiting to see the progress of the recovery image. After using this unit more and more - I am left a little disappointed even after root. I hope you guys can progress and get a custom rom that improves the functionality. I don't understand why would JVC/Kenwood would builtin so many brick walls or use the telechip (OLD) CPU as the foundation of this unit.. It's great to see at least some of our work was noticed and some bigger/smarter players have jumped onboard to crack this thing. I'll jump in when I can and help out when I can...
[Android Head-Units] pdanders11:
I agree, the Telechips CPU is pretty pathetic. Has anyone verified if the 991 also uses this crap CPU? I see nothing in the new features that the 8801 can't "do" like HDMI.

It's also not like Telechips doesn't have a upgrade path to the TCC88xx. They have many newer processors that should be easy to for Kenwood/JVC to migrate too. Research and Development dollars must have been blown on going from Win CE to Android. Hopefully they'll do a significant upgrade soon. It truly is sad that we have quad and octa core CPU's in our phones for what Kenwood charges for these stereo's with single core processors.
[Android Head-Units] chris.davis925:
991 uses the same CPU - TCC8801

I agree that the CPU is slow and memory is not enough - but in hindsight the Android system actually boots rather quickly for a single core CPU. KWLauncher on the other hand is a piece of garbage.
[Android Head-Units] chris.davis925:
I have attempted another cable and USB does not present a hardware/device ID in Android or custom recovery right now.

Could be any number of reasons, but that primarily means that I cannot supply the logs right now.
[Android Head-Units] radux.m.dan:
Great! Thanks a lot for the logs.

Now, at least I know ADB is working on OTG port. I checked the logs and it seems that that the NAND driver was not loaded so that is why you could see some error messages on the screen when entering recovery. I've made some progress, now I have a recovery that is half functional, I mean we have all the partitions mounted, but we are not able to use the buttons to use the menu. For this I think we need to activate some I2C device that is connected to the front panel buttons.

Another open issue is how to boot in recovery using buttons or something else beside the reboot recovery command in ADB.

I attach you another recovery file here(NAND driver solved) and I have the same request to get the kernel log plus to issue mount command and attach the output here.

Thanks and regards!
[Android Head-Units] pdanders11:
no errors on screen. Headed out of town for a day or so but I'll be back tomorrow.
[Android Head-Units] radux.m.dan:
Thanks for the logs, good news, it's like I said we are half way done. There is only the keyboard that needs to be activated now and we are done.

I'll be off for the next 4 days as I travel to Hungary to Formula 1.

We'll continue when I'm back.

Cheers!
[Android Head-Units] pdanders11:
no problem. Safe travels.

my thoughts on the keyboard

- since normal mode supports a qwerty keyboard, would having recovery support a qwerty keyboard over USB be a good step #1?

- on the hard keys, I'm looking through what I have and not having much luck. about all I have so far is the data from logcat in normal mode.

I/OSC ( 1353): [[[ KeyPressEvent ]]]KeyID = 2055, KeyKind = 2, nowSceneID_=-1

I/OSC ( 1353): [[[ KeyPressEvent ]]]KeyID = 2055, KeyKind = 2, nowSceneID_=-1

I/OSC ( 1353): [[[ KeyPressEvent ]]]KeyID = 2055, KeyKind = 2, nowSceneID_=-1

I/OSC ( 1353): [[[ KeyPressEvent ]]]KeyID = 2055, KeyKind = 2, nowSceneID_=-1

I/OSC ( 1353): [[[ KeyPressEvent ]]]KeyID = 2055, KeyKind = 2, nowSceneID_=-1

I/OSC ( 1353): [[[ KeyPressEvent ]]]KeyID = 2055, KeyKind = 2, nowSceneID_=-1

I/OSC ( 1353): [[[ KeyPressEvent ]]]KeyID = 2055, KeyKind = 2, nowSceneID_=-1

I/OSC ( 1353): [[[ KeyPressEvent ]]]KeyID = 2053, KeyKind = 2, nowSceneID_=-1

:eek:
[Android Head-Units] pdanders11:
So I built the kernel with USB modules including HID, keyboard, and mouse and unpacked/packed the modules to the the recovery image and the new image was too big as Dan warned earlier on. I'll probably try to blow away some of these but space in that partition does seem to be tight.

This is what I built. More then what I needed but i thought I could delete as needed. I need to verify I'm packing/unpacking ok,

LD [M] drivers/hid/usbhid/usbhid.ko

LD [M] drivers/usb/serial/usbserial.ko

LD [M] drivers/hid/usbhid/usbmouse.ko

LD [M] drivers/usb/host/ehci-hcd.ko

LD [M] drivers/hid/usbhid/usbkbd.ko

LD [M] drivers/media/video/gspca/gspca_main.ko

LD [M] drivers/usb/core/usbcore.ko

LD [M] drivers/usb/serial/ftdi_sio.ko

LD [M] drivers/scsi/scsi_wait_scan.ko

LD [M] drivers/usb/host/ohci-hcd.ko

LD [M] net/sched/sch_dsmark.ko

LD [M] drivers/usb/storage/usb-storage.ko
[Android Head-Units] chris.davis925:
Anyone know if TWRP recovery is smaller / same size-ish as CWM?

If so, this might be something to look at? Might also be more user friendly.
[Android Head-Units] radux.m.dan:
CWM Touch

Hello all!

TWRP is much bigger in size.

HID is already built in kernel, no need to add it.

I have a very good news, we now have a CWM touch that is functional. I managed to find the keypads, but they don't work for the moment, so we have to use touch for the moment.

There is just a small configuration for the partition file that I have to correct and we'll have a full functional custom recovery. :)

I attach you the current image, please don't try to use it, you can install it just to check the touch and scroll through the menu.

It would be great if any of you can give me the dmesg log as I previously asked.

The last issue that needs to be solved is to find a way to boot in recovery mode, beside the adb command.

Cheers!