Active Topics

 


Page 1 of 2 1 2
Reply
Thread Tools
jdb2 is offline jdb2
2019-03-01 , 18:06
Posts: 51 | Thanked: 63 times | Joined on Jun 2010 @ Klein/Spring, Texas, USA
#1
I have a Nokia N9 64GB that I've used without problems for years. Some time ago, I started noticing that the N9 was getting slower and losing battery life. This progressed until the N9 would make a "whimper" "dead battery sound" and turn off. I tried charging it but the N9 would just vibrate briefly, the charging LED would flash and then turn off. Then, it would turn itself on again, in an infinite loop. Eventually the phone would not even turn on and no vibration was exhibited and no LEDs turned on. Anyways, when I got the time to investigate the problem, I partially disassembled my N9 until I could access the battery. And, what do you know : The battery was *bloated* . I checked it with a multimeter and it read 0 volts. So, I got a new battery for the N9 recently. After installing the new battery, the phone didn't seem to want to charge. After a while though, and after unplugging and re-plugging the N9's USB connector into my laptop, the LED lit up. It would light up dimly white, vibrate briefly, and then the LED would light up brightly for about 30 seconds or so and then blink 3 or 4 times and then turn off. After having my N9 plugged into a Plugable fast charging USB hub with a generic micro-USB to USB type A connector, and, after having turned the phone back on and off again it finally "came to life", or so I thought. The Nokia logo and a small USB icon were displayed but then, almost immediately, a screen with a caution symbol would be displayed which read "Warning! you have modified the device software" . My N9 would display this screen for a while and then turn off. I did modify the software in that I disabled Aegis and rooted my N9, but, it never threw this warning screen at me before.

I have never flashed my N9's firmware in such a way as to brick it and before it died, it was working normally. Now I'm stuck on this warning screen. I've tried multiple methods of trying to un-brick the N9 but when connected via USB to a Windows or Linux box, the N9's USB connection doesn't even show up ( eg. "sudo lsusb -v | grep -i -P '(Nokia)|(n9)'" shows nothing).

I'm also considering that I was possibly using only charging USB cables and I'll test the N9 again today with a data/charge cable. My hypothesis is that the warning screen is blocking the charging code from operating and that the battery goes below 10% after a little while. But, I don't know how to get the N9 to bypass the warning screen.

I have all the service manuals and schematics, and I'm hoping that might help. The reason is that if my phone is truly dead, then I can suck off the user data from the eMMC using a ribbon cable and an SD card connector. I could then swap out the system board and then re-flash the phone with my original firmware and user data and it should be back to normal. But, I *really* don't want to have to do this because it's such a PITA.

Any suggestions or help would be greatly appreciated.

Thanks,

jdb2

EDIT : I said "but I think I'd have to use JTAG for the NAND flash root/boot file system", which is of course wrong for the N9 -- I was thinking of the N900. Sorry for the brain fault :P
Last edited by jdb2; 2019-03-04 at 20:33. Reason: The N9's rootfs is on the eMMC and not on a separate device...
 

The Following 2 Users Say Thank You to jdb2 For This Useful Post:
peterleinchen's Avatar
peterleinchen is offline peterleinchen
2019-03-01 , 20:44
Posts: 4,118 | Thanked: 8,901 times | Joined on Aug 2010 @ Ruhrgebiet, Germany
#2
Sounds like highlight=malf+state+n9
__________________
SIM-Switcher, automated SIM switching with a Double (Dual) SIM adapter
--
Thank you all for voting me into the Community Council 2014-2016!

Please consider your membership / supporting Maemo e.V. and help to spread this by following/copying this link to your TMO signature:
[MC eV] Maemo Community eV membership application, http://talk.maemo.org/showthread.php?t=94257

editsignature, http://talk.maemo.org/profile.php?do=editsignature
 

The Following 4 Users Say Thank You to peterleinchen For This Useful Post:
robthebold is offline robthebold
2019-03-01 , 21:54
Posts: 1,038 | Thanked: 3,980 times | Joined on Nov 2010 @ USA
#3
And NB this post regarding removing the malf file. This has saved me a few times without resorting to a complete reflash before my first n9 ultimately succumbed to a more fatal fate.
 

The Following 3 Users Say Thank You to robthebold For This Useful Post:
juiceme is offline juiceme
2019-03-01 , 23:23
Community Council | Posts: 4,920 | Thanked: 12,867 times | Joined on May 2012 @ Southerrn Finland
#4
Yep, the whole thing was most likely caused by repeated restarts due to the blown-up battery. And the new one being empty in the beginning, though how could that be escapes me?
__________________
Dave999: Meateo balloons. What’s so special with em? Is it a ballon?
 

The Following 2 Users Say Thank You to juiceme For This Useful Post:
jdb2 is offline jdb2
2019-03-02 , 17:59
Posts: 51 | Thanked: 63 times | Joined on Jun 2010 @ Klein/Spring, Texas, USA
#5
Thanks for all the replies! After having repeatedly trying to get the flasher tool to connect to my N9 by unplugging and re-plugging the USB cable, the flasher finally recognized my N9! I then was able to charge the battery past 10% using the flasher tool. After that, I let it charge for another 15 minutes or so and then I plugged it into a wall charger.

I thought I had fixed the problem with my phone, but, when I turned it on, it would only boot up with the Nokia logo in the center ( with no animation ) and a USB charging symbol towards the upper right. Then, I started getting that warning screen again. I then used the Ubiboot rescue kernel to export the N9's filesystems and that worked ( I'm on a Linux box ) but it looks like there may be some hardware level corruption in the eMMC's flash ( link to Ubiboot dmesg log file -- too long to include here ) :

http://www.mediafire.com/file/yyk6fy...mesg-log-5.zip

With the Ubiboot rescue kernel I was able to export the 3 partitions on my N9 as /dev/sdg1, /dev/sdg2 and /dev/sdg3 :

Code:
$sudo lsblk
sdg                                                                   
├─sdg1
│    vfat   Nokia N9                                        
├─sdg2
│    ext4de rootfs                
└─sdg3
     ext4
The strange thing is the partition/device that has the "ext4de" fs type, which I found out later stands for "ext4dev" which was ext4's fs type during its development. I ran parted on /dev/sdg but it couldn't detect the sdg2 "ext4de" rootfs partition. The vfat "Nokia N9" partition looks to be intact and as does the sdg3 partition which
holds a lost+found directory and the "user" directory. I have been unable to mount the "ext4de" rootfs partition as I get strange errors such as "stale file handle" when I try.

After having exported the eMMC partitions via the Ubiboot rescue kernel, I tried to use dd to suck all the data ( while disregarding blocks with errors ) off of the 64GiB eMMC, but, the Ubiboot kernel, apparently, doesn't run the battery charging code so my backup operation failed at about 6GiB because the phone's battery got drained again. I'm wondering if the Nokia N9 rescue initrd and kernel have the same problem. If so, then I'll have to buy a used, say, Nokia Lumia 800 ( which one can get pretty cheap ), disassemble it and use it to charge my Nokia N9's battery.

My device info is :

Code:
$ sudo flasher -i
flasher 3.12.1 (Oct  5 2011) Harmattan
WARNING: This tool is intended for professional use only. Using it may result
in permanently damaging your device or losing the warranty.

Suitable USB interface (bootloader/phonet) not found, waiting...
USB device found at bus 001, device address 039.
Device identifier: 351669051318639 (SN: N/A)
Found device RM-696, hardware revision 1601
NOLO version 2.3.6
Version of 'sw-release': DFL61_HARMATTAN_40.2012.21-3.454.6_PR_454
Success
Anyways, I think if there are bad blocks on my device's eMMC, there aren't many, and I may be able to recover almost everything, possibly by using ddrescue and Testdisk. First, though, thanks to everyone for pointing out the MALF problem Possibly stupid question, but where is the MALF file located and do I just delete it when I find it? If it's on the rootfs partition, then, I might be screwed because there seems to be a problem with that partition and I don't know how to mount it.

Thanks,

jdb2
 

The Following 4 Users Say Thank You to jdb2 For This Useful Post:
jdb2 is offline jdb2
2019-03-02 , 18:03
Posts: 51 | Thanked: 63 times | Joined on Jun 2010 @ Klein/Spring, Texas, USA
#6
Originally Posted by jdb2 View Post
First, though, thanks to everyone for pointing out the MALF problem Possibly stupid question, but where is the MALF file located and do I just delete it when I find it? If it's on the rootfs partition, then, I might be screwed because there seems to be a problem with that partition and I don't know how to mount it.
Well, it's in /var/malf, but, I need to figure out how to mount the "ext4de" rootfs partition or possibly repair it via Testdisk after I suck off its data via ddrescue.

Thanks,

jdb2
 

The Following User Says Thank You to jdb2 For This Useful Post:
juiceme is offline juiceme
2019-03-02 , 23:20
Community Council | Posts: 4,920 | Thanked: 12,867 times | Joined on May 2012 @ Southerrn Finland
#7
You are correct about ubiboot not charging the device. That's a problem I could not overcame at that time; there was a lot we did not know about the device and charging logic was one of the things I was unfamiliar with.

By the time I knew how to do that things had moved forward and N9 was fading into obsolency...
__________________
Dave999: Meateo balloons. What’s so special with em? Is it a ballon?
 

The Following 4 Users Say Thank You to juiceme For This Useful Post:
jdb2 is offline jdb2
2019-03-03 , 16:49
Posts: 51 | Thanked: 63 times | Joined on Jun 2010 @ Klein/Spring, Texas, USA
#8
Originally Posted by juiceme View Post
You are correct about ubiboot not charging the device. That's a problem I could not overcame at that time; there was a lot we did not know about the device and charging logic was one of the things I was unfamiliar with.

By the time I knew how to do that things had moved forward and N9 was fading into obsolency...
Thanks for your reply It seems that the N9 rescue initrd and kernel doesn't run or enable the charging code either. I say this because I had used it yesterday to export my N9's partitions in the hopes that I might get a successful dd copy of my 64GiB eMMC and that the rescue kernel would enable the charging code. Well, yesterday, I had to charge the N9 just past 10% and then I let it trickle charge for about an hour. When I plugged it into the wall charger, that same boot-loop with the warning screen was displayed. This, however, didn't stop me from loading the N9 rescue kernel and initrd. I would have backed up all my data, but, I forgot to tell pv not to abort on read or I/O errors and by the time I checked back on the N9, it had discharged its battery again.

Right now, there seems to be some slight, but fixable, corruption in the rootfs partition. dumpe2fs shows that the filesystem on the partition is mostly healthy, save for a few errors. When I try to mount it I either get errors such as "stale file handle" or "missing/corrupt root inode". If the superblock is corrupt, then I have several backups in the filesystem, which I hope bodes well for recovering the rootfs.

Running dumpe2fs on the rootfs partition shows :

Code:
$ sudo dumpe2fs /dev/sdg2 | grep -i backup
dumpe2fs 1.44.1 (24-Mar-2018)
Journal backup:           inode blocks
  Backup superblock at 32768, Group descriptors at 32769-32769
  Backup superblock at 98304, Group descriptors at 98305-98305
  Backup superblock at 163840, Group descriptors at 163841-163841
  Backup superblock at 229376, Group descriptors at 229377-229377
  Backup superblock at 294912, Group descriptors at 294913-294913
  Backup superblock at 819200, Group descriptors at 819201-819201
  Backup superblock at 884736, Group descriptors at 884737-884737
Code:
$ sudo dumpe2fs -h /dev/sdg2 | grep -i super
dumpe2fs 1.44.1 (24-Mar-2018)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Code:
$ sudo dumpe2fs -h /dev/sdg2
dumpe2fs 1.44.1 (24-Mar-2018)
Filesystem volume name:   rootfs
Last mounted on:          /
Filesystem UUID:          4127add5-d4f3-48d1-abdf-f4cf6a99b0f6
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash test_filesystem 
Default mount options:    (none)
Filesystem state:         clean with errors
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              262144
Block count:              1048576
Reserved block count:     52428
Free blocks:              407449
Free inodes:              194775
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      255
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
RAID stripe width:        8
Flex block group size:    16
Filesystem created:       Wed Feb 29 04:21:42 2012
Last mount time:          Wed Dec 31 18:00:01 1969
Last write time:          Wed Dec 31 18:00:07 1969
Mount count:              320
Maximum mount count:      32
Last checked:             Wed Feb 29 04:21:42 2012
Check interval:           15552000 (6 months)
Next check after:         Mon Aug 27 05:21:42 2012
Lifetime writes:          96 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      79f02ced-f80d-4173-85c1-f7601c5bc4f7
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             8M
Journal length:           2048
Journal sequence:         0x001a9f8f
Journal start:            0
Notice the "Lifetime writes: 96 GB" field. I think that the flash is corrupt due to normal flash wear caused by too much writing, but, once I recover the partitions, I should be able to mark the bad blocks without having to swap out the mainboard or eMMC chip.

Here is a link to the full dumpe2fs output :

http://www.mediafire.com/file/36gj9v...log-4.zip/file

I'm hoping that if I can recover most of the sectors from the eMMC with ddrescue then I'll be able to fix the fs corruption errors and/or restore the superblock. I can then wipe the eMMC using the flasher tool and then mark bad blocks and then, hopefully, copy all the partitions back.

Any opinions or advice as to the rootfs fs corruption issue would be appreciated

All I need to do now is charge the N9 with the flasher tool again, then let it trickle charge for about an hour and then run ddrescue after having booted into Ubiboot

Thanks,

jdb2
 

The Following 5 Users Say Thank You to jdb2 For This Useful Post:
jdb2 is offline jdb2
2019-03-09 , 17:44
Posts: 51 | Thanked: 63 times | Joined on Jun 2010 @ Klein/Spring, Texas, USA
#9
Well, after charging my N9 with the flasher tool and then letting it trickle charge for at least 12 hours, I loaded the Ubiboot rescue kernel into it. I then ran ddrescue 3 times having to recharge the N9 after each recovery so that I could perform smaller, slower sector reads with more retries.

I've completely recovered the FAT32 "MyDocs" partition, apparently with no errors, but my rootfs ext4 partition seems to be extremely corrupted. I'm no ext4 expert and I've been trying to use my backup superblocks but I'm not sure if the superblock position is relative to the eMMC device's starting address or the partition's starting address. Also, I don't know if the superblock positions are in units of the filesystem block size ( 4096 bytes ), the logical block size ( which is 512 bytes ) or the flash erase block size, which is 64KiB. When I try to mount the rootfs partition, I get a "stale file handle" failure.

When I'm running the Ubiboot rescue kernel, I can see 3 exported filesystems complete with labels, UUIDs and fs types. But, when I image the eMMC using ddrescue my rootfs is marked as empty space. Somehow, I need to get more direct access to the eMMC, especially since ddrescue's minimum error skip size is 64KiB, which is the size of a flash erase block, IIRC. I may have to use a JTAG to USB interface, but I'd rather have that as a last resort.

Does anyone have any ideas?

Thanks,

jdb2
 

The Following 2 Users Say Thank You to jdb2 For This Useful Post:
jdb2 is offline jdb2
2019-03-09 , 18:55
Posts: 51 | Thanked: 63 times | Joined on Jun 2010 @ Klein/Spring, Texas, USA
#10
Does anyone have the datasheet for the 64GiB eMMC? The only reference I could find to "JTAG" in the schematics were connections on the OMAP processor. I think that the part number for the eMMC is either "KLMCG8GE4A-A00x" or "KLMCG8GE2A-A00x" and I believe it was manufactured by Samsung. The schematics just list the chip contacts that are connected to the OMAP, with no mention of the JTAG connections or what other NC lines are used for.

Thanks,

jdb2
 

The Following User Says Thank You to jdb2 For This Useful Post:
Reply
Page 1 of 2 1 2

Tags
aegis, battery, bricked, n9-00, warning

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 01:36.

Contact Us - Home - Archive - Top