Undemo/Unbrick PW1 3G: Can't write to flash?

JackPack · 03-07-2015, 12:22 AM

I'm a bit reluctant to open another thread like this, but this is a bit peculiar and I've been all over the forums and web the last several days with no resolution and am out of ideas.

I have two model EY21 Gen 1 3G PaperWhite demo units I am trying to undemo/unbrick. I've tried multiple methods, and they all appear to have the same result: Any updates just do not take effect. They are both apparently running 5.2.0. Symptomatically, one seems fine, just in demo mode, the other is in a boot loop, and has a corrupt diags image (bootm 0xE41000 fails with bad CRC). I have serial console so can see everything, use uboot, CLI, etc. I have tried:

- interrupt uboot, boot diags image, USB mode, copy file, dd to mmcblk0p1
- boot to recovery menu, export to USB, copy file, dd, etc.
- the above using an update*bin file including the latest 5.4.4.2 directly from amazon
- fastboot, flashing both main and diag kernels, and main and diag partitions
- probably a few other permutations of the above

I have done this on a linux VM, Win7 VM, and OSX native. Nothing seems to change. It's almost like it's silently write protected, or there's an unlock that needs to be done. I kind of doubt that both units (and actually I have a third, so far untested) have exactly the same failure (if it's a failure).

I would appreciate any suggestions. Thanks!

Jack

JackPack · 03-07-2015, 06:54 PM

As a followup to my previous post, I can confirm that these symptoms are a case of bad flash. This looks to be the same situation as the 'read-only' problem described in https://www.mobileread.com/forums/sho...d.php?t=256723

I had a third unit on which I successfully disabled demo mode, and there are some differences in behavior that are definite clues that the flash does not store data and is bad.

1) Apparent inability to update data in the partitions. kernels, system, diag images, user files revert after an update. E.g. write a file to /mnt/us in USB mode. Reboot. The file will be gone.
2) Using idme, changed nvram values do not stick. E.g. 'idme bootmode diags' followed by idme will still show bootmode main and the unit will boot into main instead of diags on next startup
3) When writing files to the unit, either in USB mode or via fastboot, the write speed will be too high. i.e. the copy will finish too quickly. If operating correctly, it should be around 3MB/s - if bad, may be 3x that.

I sacrificed the unit that was in the boot loop and removed the shields on the PCB. I attempted to reflow the BGA memory chips, but it didn't help. If you have the skills, the chip is a Samsung KLM2G1HE3F-B001 153 FBGA. It's under the longer rectangular shield.

Hope this helps someone else in the future.

Jack

knc1 · 03-07-2015, 08:32 PM

Two other "demo unit" specific points:

The demo units are intended to be on external power 100% of the time;

The demo units call home on a regular basis for both updates to the demo images and updates to the firmware;

If they are allowed to run on battery, it is very likely that they will attempt an update with the battery not charged enough to complete the function.

I.E: Same thing as removing the power from the flash chip while it is still running its internal sequencing.
(Which destroys the device in the sense that its micro-controller can not recover.)

JackPack · 03-08-2015, 09:20 PM

Duly noted.

Looking at the 'gas gauge' (the battery monitor chip) in the diags, this battery show a cycle count of 484. So it's been through a pretty good number of cycles that an always on unit wouldn't expect to have. On the other hand, a display model is going to see some pretty rough service what with John Q Public trying to break it every day.

It's almost funny though, that using option 4 to erase the MMC (twice) does nothing. The unit still boots and acts just like nothing ever happened. Which is true I guess

So I can't even brick this thing if I try.

At least I have some good pare parts- the batteries still take a FULL charge and the screens are good. Not to mention I learned a good bit along the way. Thanks for chiming in.

03-07-2015, 12:22 AM	#1
JackPack Junior Member Posts: 3 Karma: 10 Join Date: Mar 2015 Device: Kindle PWG	Undemo/Unbrick PW1 3G: Can't write to flash? I'm a bit reluctant to open another thread like this, but this is a bit peculiar and I've been all over the forums and web the last several days with no resolution and am out of ideas. I have two model EY21 Gen 1 3G PaperWhite demo units I am trying to undemo/unbrick. I've tried multiple methods, and they all appear to have the same result: Any updates just do not take effect. They are both apparently running 5.2.0. Symptomatically, one seems fine, just in demo mode, the other is in a boot loop, and has a corrupt diags image (bootm 0xE41000 fails with bad CRC). I have serial console so can see everything, use uboot, CLI, etc. I have tried: - interrupt uboot, boot diags image, USB mode, copy file, dd to mmcblk0p1 - boot to recovery menu, export to USB, copy file, dd, etc. - the above using an update*bin file including the latest 5.4.4.2 directly from amazon - fastboot, flashing both main and diag kernels, and main and diag partitions - probably a few other permutations of the above I have done this on a linux VM, Win7 VM, and OSX native. Nothing seems to change. It's almost like it's silently write protected, or there's an unlock that needs to be done. I kind of doubt that both units (and actually I have a third, so far untested) have exactly the same failure (if it's a failure). I would appreciate any suggestions. Thanks! Jack

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Questions about undemo-ing a Kindle DX graphite	megacoupe	Kindle Developer's Corner	35	09-23-2012 12:04 PM
To Flash or Not to Flash? For the Eee Transformer	Ken Maltby	Android Devices	4	06-28-2011 04:58 PM
Can't get new f/w - flash site broken again and non-flash not updated	jusmee	Astak EZReader	8	03-13-2010 11:26 AM
Write Fast, Write Slow?	Moejoe	Writers' Corner	14	03-25-2009 09:55 AM
iLiad Reflash from Compact Flash (aka Unbrick) available to all!	Adam B.	iRex	18	08-11-2007 07:42 AM

03-07-2015, 06:54 PM	#2
JackPack Junior Member Posts: 3 Karma: 10 Join Date: Mar 2015 Device: Kindle PWG	As a followup to my previous post, I can confirm that these symptoms are a case of bad flash. This looks to be the same situation as the 'read-only' problem described in https://www.mobileread.com/forums/sho...d.php?t=256723 I had a third unit on which I successfully disabled demo mode, and there are some differences in behavior that are definite clues that the flash does not store data and is bad. 1) Apparent inability to update data in the partitions. kernels, system, diag images, user files revert after an update. E.g. write a file to /mnt/us in USB mode. Reboot. The file will be gone. 2) Using idme, changed nvram values do not stick. E.g. 'idme bootmode diags' followed by idme will still show bootmode main and the unit will boot into main instead of diags on next startup 3) When writing files to the unit, either in USB mode or via fastboot, the write speed will be too high. i.e. the copy will finish too quickly. If operating correctly, it should be around 3MB/s - if bad, may be 3x that. I sacrificed the unit that was in the boot loop and removed the shields on the PCB. I attempted to reflow the BGA memory chips, but it didn't help. If you have the skills, the chip is a Samsung KLM2G1HE3F-B001 153 FBGA. It's under the longer rectangular shield. Hope this helps someone else in the future. Jack

03-07-2015, 08:32 PM	#3
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	Two other "demo unit" specific points: The demo units are intended to be on external power 100% of the time; The demo units call home on a regular basis for both updates to the demo images and updates to the firmware; If they are allowed to run on battery, it is very likely that they will attempt an update with the battery not charged enough to complete the function. I.E: Same thing as removing the power from the flash chip while it is still running its internal sequencing. (Which destroys the device in the sense that its micro-controller can not recover.)

03-08-2015, 09:20 PM	#4
JackPack Junior Member Posts: 3 Karma: 10 Join Date: Mar 2015 Device: Kindle PWG	Duly noted. Looking at the 'gas gauge' (the battery monitor chip) in the diags, this battery show a cycle count of 484. So it's been through a pretty good number of cycles that an always on unit wouldn't expect to have. On the other hand, a display model is going to see some pretty rough service what with John Q Public trying to break it every day. It's almost funny though, that using option 4 to erase the MMC (twice) does nothing. The unit still boots and acts just like nothing ever happened. Which is true I guess So I can't even brick this thing if I try. At least I have some good pare parts- the batteries still take a FULL charge and the screens are good. Not to mention I learned a good bit along the way. Thanks for chiming in.

Advert