yashsingh1/xdaforums huggingface dataset:
[Android Head-Units] pdanders11:
I wasn't sure if your CWM was ready for use. You mentioned here that you still had a small issue so I haven't tried it. So this recovery is good to go? http://xdaforums.com/showpost.php?p=54494785&postcount=544
[Android Head-Units] radux.m.dan:
recovery

Here I attach the recovery image.

It's almost done, the only thing missing is the keypad buttons still don't work, but you can use the touch.

Use the external SD card for back-up or restore. It will back-up the system, data, cache and userdata partitions.

ADB over USB is active as before. You have the option to update using the update.zip from SD card.

You can use your own build update.zip without the need of signature, CWM will ask you for install confirmation.

ENJOY!
[Android Head-Units] pdanders11:
Also have you looked into a patch for NAND corruption issue? It seems like this existed in many kernels long past 3.0.8 so I've had a hard time figuring out how to patch 3.0.8 when the generic answer I find is to use a newer kernel which we don't seem to have the opportunity. The telechips 3.1 kernel on their website seems to has the same fs/ext4 code as 3.0.8 so I'm guessing that won't help.

---------- Post added at 10:56 AM ---------- Previous post was at 10:55 AM ----------

Very much appreciated.
[Android Head-Units] radux.m.dan:
Hehe.. now that you have the kernel source from Kenwood we can patch the EXT4 and rebuild the kernel.

Another thing I want to try is to run a fsck at boot before mounting the system partiton, this could help to prevent the erorrs we see, but first I need to reproduce the issue on my unit, which I didn't had too much time lately, sorry.

By the way, who can help me to buy a DNN990 unit from US? I want to install my unit back in my car cause I miss it, so I would like to use one unit on my desk for testing / developing.
[Android Head-Units] pdanders11:
No problem, I understand the time issues. Just wanted to see how far you looked into that. The example Chris gave gave me the error right away. Then I soft bricked my unit :p I'll try to recovery it now or later tonight.

I can help you get a unit. Refurbished units are going for $650. That's what I'm using on the bench. I can provide via ebay, maybe swappa's new boneyard (haven't looked into it), outside ebay. I'm sure we can work something out. PM your thoughts.
[Android Head-Units] chris.davis925:
Likewise I can help you too - I am actually planning on selling the unit I have on my desk soon.

[MENTION=465217]pander[/MENTION]s11 - You can trigger the system rebuilding by interrupting the boot 6 times in a row. This is how I trigger the rebuilding of Dalvik cache in my root exploit. I should note that I have mixed results with this working after applying the recovery. [MENTION=5909218]radux.m.dan[/MENTION] has indicated that this has worked for him, even with CWM - which means that the system rebuilding process is likely the kpanic partition.

I realize this might not be useful if the unit is not even getting far enough into the boot process.
[Android Head-Units] radux.m.dan:
If you have a custom recovery in place you need to keep the protection in place, recovery-from-boot.p and install-recovery.sh

otherwise it will not trigger the rebuild.
[Android Head-Units] pdanders11:
I have no idea if I did what I tried to do or if the system just isn't how i expected, but I intended to update the kernel to prior to the bug and now see this error

<4>[ 236.830954] OnAction_p2p

<4>[ 238.264739] OnAction_p2p

<4>[ 238.740994] UMP<2>: New session opened

<4>[ 238.938400] Manual calibration succeed.

<4>[ 239.186041] OnAction_p2p

<2>[ 239.267661] EXT4-fs error (device ndda2): ext4_lookup:1044: inode #15043:

comm AsyncTask #1: deleted inode referenced: 779 .ext

<3>[ 239.267687] Aborting journal on device ndda2-8.

<2>[ 239.268231] EXT4-fs (ndda2): Remounting filesystem read-only

<4>[ 239.903192] OnAction_p2p

<4>[ 241.541604] OnAction_p2p

<4>[ 241.541709] OnAction_p2p

<4>[ 243.896906] OnAction_p2p

<4>[ 245.022822] OnAction_p2p

Attempt 2

<4>[ 150.959871] rtw_set_ps_mode(): Enter 802.11 power save mode...

<4>[ 150.961272] rtl8192c_dm_RF_Saving(): RF_Normal

<4>[ 150.961288] rtl8192c_set_FwPwrMode_cmd(): Mode = 1, SmartPS = 2

<4>[ 155.473473] UMP<2>: New session opened

<4>[ 155.998057] UMP<2>: New session opened

<2>[ 156.466773] EXT4-fs error (device ndda2): ext4_lookup:1044: inode #15043:

comm AsyncTask #1: deleted inode referenced: 779 .ext

<3>[ 156.466797] Aborting journal on device ndda2-8.

<2>[ 156.467328] EXT4-fs (ndda2): Remounting filesystem read-only

<4>[ 162.825886] [set_dma_outbuffer], original len[32768]

root@android:/system #

---------- Post added at 04:29 AM ---------- Previous post was at 04:21 AM ----------

If I'm really updating the kernel,shouldn't the build date or something change?
[Android Head-Units] radux.m.dan:
Hi!

Yes, we talk about the big SDCARD behind the LCD.

You need to use an SD card with one FAT32 partition.

run a ls -al in /dev/block while in recovery so I can see if the SD card is getting initialized. You mounted mmcblk0p1 which is a FAT12 partition on the internal microSD with some Garmin info about the unit ID.

---------- Post added at 12:30 PM ---------- Previous post was at 12:24 PM ----------

Did you actually rebuild the Kernel? check the version with uname -a

The problem you see here is coming from EXT4 library.. but to be honest I think there is something else coming from Kenwood.

While you are in our custom recovery you can run

e2fsck -fy /dev/block/ndda2

this will scan and fix the /system partition. While still in recovery you can write anything you want on the system partition when you boot in Main OS and remount as rw the system partition you will see that very soon when you try to write some file you get this error and go to RO mode.

The kernel image is in boot.img and also in recovery.img, in our case ndda1 is boot and ndda6 is recovery.

Cheers!
[Android Head-Units] pdanders11:
Thank you.

I ran uname and looked at the kernel version in settings about devices and both look unchanged. I was thinking the build date would update or something.

So I think I did it right. I just replaced balloc.c with the version prior to where I read the bug was introduced. Rebuilt. I guess I don't know if I grabbed the right image. I used the 'kernel/arch/arm/boot/Image' file to replace in the boot.img. I chose this image purely based on file size vs the original kernel. The bzimage version of the kernel was 2x smaller. I probably should look around the build directory more.

This may be a fluke or of interest. I was connected to the unit over adb at the user login in screen and tried to trip the nand to RO. I couldn't. Whether that was a fluke or the Kenwood protection doesn't kick in until Android login may be worth noting/investigating.

Ok. I have the sd cards right. Just wanted to be sure. I don't have the Garmin card installed for fear of deleting it even though I made a copy. I have a blank micro sdcard in the Garmin slot and large sdcard in the other.

I'm not sure how either has Garmin info. The unit must be formatting one of the cards to what you said. Maybe no Garmin card is messing me up. I'll make a raw copy and put it in and see.

Thanks again fit the classifications. Sometimes a bad assumption can send one down the wrong path.
[Android Head-Units] pdanders11:
[MENTION=5909218]radux.m.dan[/MENTION] running e2fsck -fy /dev/block/ndda2 and the screen just filled with errors for 10 seconds. no chance to read them. I wish i would have logged it. I will next time.

---------- Post added at 10:59 PM ---------- Previous post was at 10:44 PM ----------

After one reboot and RO trigger so 2nd e2fsk

e2fsck -fy /dev/block/ndda2 > log.txt

e2fsck 1.41.12 (17-May-2010)

~ # more log.txt

more log.txt

/dev/block/ndda2: recovering journal

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Unattached inode 776

Connect to /lost+found? yes

Inode 776 ref count is 2, should be 1. Fix? yes

Pass 5: Checking group summary information

Block bitmap differences: +(108020--108031) +(111104--111107)

Fix? yes

Free blocks count wrong for group #3 (8243, counted=8227).

Fix? yes

Free blocks count wrong (9172, counted=9156).

Fix? yes

Inode bitmap differences: +776

Fix? yes

--More-- (68% of 837 bytes)

Free inodes count wrong for group #0 (6745, counted=6744).

Fix? yes

Free inodes count wrong (18235, counted=18234).

Fix? yes

/dev/block/ndda2: ***** FILE SYSTEM WAS MODIFIED *****

/dev/block/ndda2: 11846/30080 files (3.6% non-contiguous), 111164/120320 blocks

I ran on ndda3

~ # e2fsck -fy /dev/block/ndda3 > log.txt

e2fsck -fy /dev/block/ndda3 > log.txt

e2fsck 1.41.12 (17-May-2010)

~ # more log.txt

more log.txt

/dev/block/ndda3: recovering journal

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Inode 2 ref count is 20, should be 21. Fix? yes

Pass 5: Checking group summary information

/dev/block/ndda3: ***** FILE SYSTEM WAS MODIFIED *****

/dev/block/ndda3: 763/22416 files (14.5% non-contiguous), 19325/89600 blocks

ndda2 is clean in recovery

reboot recovery still clean

reboot recovery still clean

reboot system and immediately reboot recovery still clean

reboot system and adb root and adb remount => mounting rw flags file system modified?

~ # e2fsck -fy /dev/block/ndda2

e2fsck -fy /dev/block/ndda2

e2fsck 1.41.12 (17-May-2010)

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

/dev/block/ndda2: ***** FILE SYSTEM WAS MODIFIED *****

/dev/block/ndda2: 11846/30080 files (3.6% non-contiguous), 111164/120320 blocks

~ #
[Android Head-Units] chris.davis925:
[MENTION=465217]pander[/MENTION]s for the kernel / build version not changing, this might be due to Quick-Boot. Try rebuilding the quick-boot image after you applied your new build by doing a "System Rebuilding" process (interrupt the boot 6 times).

(I know how to delete the quickboot image, but I am not clear on how to generate the new one on demand except for interrupting boot)
[Android Head-Units] pdanders11:
[MENTION=5909218]radux.m.dan[/MENTION]

what am I'm missing here?
[Android Head-Units] chris.davis925:
After rebuild, can you still confirm that the writing to /system doesn't work as expected?
[Android Head-Units] pdanders11:
yes, when i get back there. I'm seeing what messed me up the other day. snapshot x6, then snapshot sig fail, and now system is corrupted

---------- Post added 12th August 2014 at 12:25 AM ---------- Previous post was 11th August 2014 at 11:55 PM ----------

it won't rebuild with my boot.img

it's either a bad image or it's detecting the image is not valid.

---------- Post added at 12:41 AM ---------- Previous post was at 12:25 AM ----------

it won't rebuild on the 1.3 boot.img either.
[Android Head-Units] pdanders11:
I think I see it........
[Android Head-Units] radux.m.dan:
If you want to rebuild the quick boot image you need to flash the OEM recovery, which you already have and then just boot in recovery mode, it will automatically trigger a rebuild.
[Android Head-Units] pdanders11:
So I did that. I restored ndda6. I restored the 2 files in the system partition but when I reboot into recovery with any boot.img besides the original 1.5 firmware boot.img, I reboot to recovery, I get the oem 'waiting' screen and reboot, but on my images the unit just hangs at this point at the Kenwood splash screen. The rebuild never kicks off.The unit just hangs.

I was able to sit there and fastboot the original 1.5 image and see the rebuild start and then flash my image and see the rebuild hang.

You mentioned something about booting a unsecured image and default.prop also so I was thinking that a default.prop change was required per your message. Can you confirm? I tried changing one value but it made made no difference.

I guess I need to take a step back and see and see what specifically what step I'm doing that it's preventing the rebuild.

The weird thing also is my system partition has also gotten completely hosed at least 2 times. I'm not sure what is doing this. What I see is cwm will not be able to mount the partition and I have to format system and then dd an old image.

But I guess my main question is on your default.prop statement with a non one boot image.

Thanks
[Android Head-Units] radux.m.dan:
When I say unsecured boot.img I mean you can modify the default.prop file and change the ro.secure=0 .

This gives you root access with ADB without the need to run adb root command.
[Android Head-Units] pdanders11:
I can't get anything to rebuild other then the stock 1.5 boot image so I'm not that far.

I guess that's what I need to figure out.
[Android Head-Units] chris.davis925:
Excuse my ignorance, but what exactly is your goal / problem?

Does your unit still not work?
[Android Head-Units] pdanders11:
Trying to get a custom kernel to load and fully boot.

If a custom kernel requires a custom boot.img as I understand, I must get the unit to do a rebuild on that image. The unit won't rebuild on my custom images. It won't rebuild with stock boot.img from a different firmware release either.
[Android Head-Units] chris.davis925:
And by rebuild you mean that you are interrupting the boot six times, and then waiting for "system rebuilding"?

I know that Dan mentions that booting into recovery triggers a rebuild, but this has not been my experience.
[Android Head-Units] pdanders11:
I've tried both methods. I've I'll tried a corrupted update.zip from a snapshot boot which will fail upgrade and rebuild.

The unit sees it needs to rebuild, I get the waiting screen and quick reboot. With the stock boot.img rebuild kicks off fine. Custom boot.omg and the rebuild never starts. Freezes at Kenwood boot screen.

I figured if my custom boot.img was bad I would just cross flash another unmodified from a different release and it also failed.

I seems whatever kicks the rebuild sees the boot.img is wrong and halts or crashes.
[Android Head-Units] chris.davis925:
Can someone dump the contents of kpanic? Or recovery script? I assume it's an sh script or similar that triggers the rebuild process that we could infer from.
[Android Head-Units] pdanders11:
So I was able to unpack ndda6.img but didn't look at kpanic. My ability to read the unpacked images is another story.

So yes I can provide later today. Thanks
[Android Head-Units] radux.m.dan:
Setting apk

Hi!

Here is a settings.apk that was build from ICS 12.04 realease from Telechips. This gives you access to the other menus.

About the quick boot image you are trying to build, what we call system rebuild and Chris is triggering this by interrupting the boot 6 consecutive times, you are right.

I'm not able to trigger the rebuild if the boot partiton is modified, it will only work with the stock boot and recovery partition from the same update package.

I think this is based on SHA and it has to be related with the bootloader.

In my case, if I have stock boot and recovery images I just need to run adb reboot recovery and this will rebuild the quick boot image.

Things are more complicated than I thought.

Cheers!
[Android Head-Units] pdanders11:
This reminds me of the Samsung boot loader which each stage of boot verified the next. If Kenwood it's running little kernel which it appears to be, I wonder if it's patched for the Loki exploit.

I ran the Loki tool on the loader but did not find the signature but I think that is device dependent.

I agree opening the boot loader wasn't what I was hoping for. If the boot loader gets hosed will fwdn still work I wonder?
[Android Head-Units] radux.m.dan:
Can you take logs on uart for the case the rebuilding is not tiggering?

I'm serching for strings now in the bootloader.img

I used a command in linux like strings -a bootloader.img
[Android Head-Units] radux.m.dan:
Can you also try to boot in fastboot and run: fastboot erase snapshot

I'm wandering if this will rebuild the partition.
[Android Head-Units] chris.davis925:
When I did a similar command from within Android, the result is that the screen will turn black on next boot and just hang.

I should also mention that clearing Dalvik Cache seems to also not rebuild automatically (Like is my experience with other Android devices) and that the System Rebuild also triggers this.
[Android Head-Units] pdanders11:
stock recovery
[Android Head-Units] pdanders11:
stock ndda6 is loaded with sha and hash strings. using ARMu
[Android Head-Units] radux.m.dan:
Hello!

Can you dd the ndda11 partition? The signature is normally a string from what I see in the telechips bootloader but maybe Kenwood changed that to a SHA or something else so we need to check what is there on the snapshot image.

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

adb pull /data/local/tmp/ndda11.img
[Android Head-Units] pdanders11:
Hello

file/img is to big to upload here. Check your PM shortly

---------- Post added at 12:58 PM ---------- Previous post was at 12:39 PM ----------

This is what I see in the logs. a good rebuild goes to BOOTMODE INIT forced rebuild goes to BOOTMODE garbage

I was just seeing the sig fail in both but your right the bootloader mode is not correct

Good

partition update exist

##########bootmode :INIT

##########bootmode = INIT

##########wakecnt = 6

##########wake error

##########snapshot image clear

##########qbrecover:QB

##########qb count = 1

BAD

##########bootmode :▒▒▒▒▒

##########qbrecover:QB

##########qb count = 1
[Android Head-Units] radux.m.dan:
I've also spotted these differences.

The image you attached is a good one or a bad one?
[Android Head-Units] pdanders11:
It should be a good one. I pulled the image long ago before trying to change boot
[Android Head-Units] radux.m.dan:
Ok, I found the S1SUSPEND string it is at 0xFF6

Can you get an image for the case that we see the error in the logs with signature fail? You can do it in CWM recovery, dd should work.

use it like this dd if=/dev/block/ndda11 of=/your_location count=10000 cause we only need the beginning of the image.
[Android Head-Units] pdanders11:
so unit was working. fastboot new boot.img. force reboot into stock recovery. quick reboot and halt. fastfoot CWM. DD snapshot
[Android Head-Units] pdanders11:
looks like a lot of 0's

is the the snapshot erased and then fails
[Android Head-Units] radux.m.dan:
OK, so now the signature is not there anymore....

Now the question is who is actually erasing the image. We need to try to write the string back using dd in order to test. I'm not sure what will be the output.

Which image do you use for boot?
[Android Head-Units] pdanders11:
I used my boot image with updated kernel.

When I force recovery after flashing a custom boot, I get a very short boot with the words 'waiting' on the screen. It's like 1 to 2 seconds and another reboot to halt state. I assume this short boot erases the snapshot?

When I do get in the halt state I do have adb access but the /bin/sh is missing as previously discovered in stock recovery.

There should be a way to get the log probably. Like the early development, maybe adb push sh or pack custom recovery with /bin/sh ?
[Android Head-Units] chris.davis925:
adb push sh.
[Android Head-Units] radux.m.dan:
Can you tell me what do you mean by custom boot? How did you rebuild the kernel? Is it the one from kenwood source?

You need to have some options enabled in the kernel for quickboot, in fact the kernel will actually build this image.
[Android Head-Units] pdanders11:
I followed this

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

For boot.img.

I just replaced the kernel with what I received with a older ballot.c that I compiled.

I can try the 1.3 boot.img also since its known good but also fails in the 1.5 environment.
[Android Head-Units] chris.davis925:
It's especially fun because XDA forum converted some of it into a smiley face :p
[Android Head-Units] chris.davis925:
Hi guys,

Thank you for the behind the scenes work you guys are doing on this. I can't help out in the Linux kernel rebuilding process, but I want to note more precisely my experience with the "mount lock".

Even after running fsck in recovery (thanks Dan) the Android environment still appears locked. As Dan stated earlier, it appears that it will accept writing something to /system followed by the journal error - which then locks the partition again until another fsck scan. However, I don't think it actually ever writes the data the second time. You can see this for yourself by attempting to remove data from /system.

For example, here is a timeline of events.

-Writing to /system works for a period of time after the 1.5 update is applied

-Mounting of /system to rw no longer works.

-Running fsck in recovery "fixes" the journal errors that we think are causing the mount lock.

-Mount of /system to rw "works" again for a total of one write command to /system, followed by the journal error again.

-The interesting thing at this point is that if I run a rm command on a file on /system, it will show that it removed that file during this session. however, upon reboot the file is back in its original form - which indicates that it was never removed in the first place.

-repeat

It seems to me that somehow Kenwood is actually locking (at least) the /system partition from rw in such a way that the kernel /. system doesn't know about it, and thus when it detects the write failed it flags the partition as having corruption - when in reality, Kenwood has blocked any writing (or removing) of data.

The good news is that after applying the 1.5 update again, there is a window of time where you can write any amount of data you wish to /system, however once this window of time expires, some locking mechanism kicks in.

Hope this is helpful.
[Android Head-Units] pdanders11:
This is sort of interesting

as usual i was messing around in the filesystem and eventually locked the board up.

FWDN, fastboot, CWM, DD this and that and somehow got into a non-stable yet stable normal boot.

How should I say this. Android is up and running but the Kenwood apps are failing launch. the just loop failing launch. I hit OK and the next fails. I have a orange non kenwood wallpaper on the unit.

But what i find interesting is adb is still up and I can't trigger the NAND lock. Is the lock in one of the APK's? Interesting.............
[Android Head-Units] chris.davis925:
Try removing all of the KW system apps from /system/app

Don't remove BCNNotifier, since the unit will bootloop if you do that.

Make sure you have a backup. Might be worth turning off quickboot.
[Android Head-Units] chris.davis925:
I was playing around with my unit and I have found myself in a bit of a problem.

Basically, I used the CWM to install the Kenwood 1.5 update. I did this by letting Android auto launch the installation of update.kw from within Android. Interestingly, CWM (toward the end of the update) advised that the update might try to overwrite custom recovery. It asked if I wanted to "fix" this and not allow the recovery to be overwritten. I selected yes, and the unit rebooted.

Now the unit will only reboot into recovery. It's as if the recovery is now the primary partition. I cannot get it to boot Android at all. I also cannot get it to apply an update.zip file since it looks for the data on /sdcard and there is no option to apply the update from /sda, which is the USB partition.

Any ideas on how I could get back to booting Android? Also, any idea how or why applying the update.kw has somehow created Recovery image as the default boot? Or perhaps it just boots into recovery because there is something wrong with regular boot.

PS: Interrupting boot six times is not working.