KPW3-32 debricking

[coplate]

D:\Ninite\kndle-jb\development\kindletool-v1.6.4-mingw>"c:\Program Files (x86)\GnuWin32\bin\diff.exe" -r  -bw ub5.8.1 ub5.8.9.2
diff -r -bw ub5.8.1/board/imx60_wario/imx60_wario.c ub5.8.9.2/board/imx60_wario/imx60_wario.c
1726a1727
>       extern int g_fl_override;
1816c1817
<       } else if (!strncmp(boot_mode, "main", 4)) {
---
>       } else if (!strncmp(boot_mode, "main", 4) || !strncmp(boot_mode, "ota", 3)) {
1821a1823,1827
>
>               if (!strncmp(boot_mode, "ota", 3)) {
>                       printf("BOOTMODE OTA : DONT EXPECT FL\n");
>                       g_fl_override = 1;
>               }
diff -r -bw ub5.8.1/board/imx60_wario/wario_iomux/wdog1_iomux_config.c ub5.8.9.2/board/imx60_wario/wario_iomux/wdog1_iomux_config.c
11d10
< #include <linux/kernel.h>
diff -r -bw ub5.8.1/drivers/misc/pmic_max77696.c ub5.8.9.2/drivers/misc/pmic_max77696.c
32a33
> int g_fl_override = 0;
387c388
<     if (!BOARD_IS_BOURBON(rev))
---
>     if (!BOARD_IS_BOURBON(rev) && !g_fl_override)
diff -r -bw ub5.8.1/include/asm-arm/arch-mx6/mx60_wario_board.h ub5.8.9.2/include/asm-arm/arch-mx6/mx60_wario_board.h
173a174,179
>       .id = BOARD_ID_MUSCAT_32G_WFO,
>       .name = "Muscat WFO 32GB",
>       .mem_type = MEMORY_TYPE_LPDDR2,
>       .mem_size = MEMORY_SIZE_512MB,
>     },
>     {
diff -r -bw ub5.8.1/tools/Makefile ub5.8.9.2/tools/Makefile
70c70
< BIN_FILES-y += mkimage$(SFX)
---
> #BIN_FILES-y += mkimage$(SFX)
96c96
< OBJ_FILES-y += mkimage.o
---
> #OBJ_FILES-y += mkimage.o

D:\Ninite\kndle-jb\development\kindletool-v1.6.4-mingw>D:\Ninite\diffutils-2.8.7-1-bin\bin

it looks like they call that board "Muscat WFO 32GB", mine is just called "Muscat WFO"

[knc1]

Originally Posted by coplate

- - - -
it looks like they call that board "Muscat WFO 32GB", mine is just called "Muscat WFO"

I think I see what you did there.
Your comparing a version prior to the introduction of the PW3-32 vs the current version.
Just to see what, if anything, was added PW3-32 specific.

- - - -

Yes, I agree, it does look like the same source (and binary?) is intended to run both models.
Reasonable.

But the sh.. is so deep now I felt we had better check everything we could think of to check.

= = = =

Get a newer KindleTool from the snapshots thread.
The Cygwin build has failed to build for the last 2 years, but I see your using the MinGW build.
That is still building, so you should be able to use the newest version (which will still have a few unknowns, but does list the two PW3-32 models we are certain of).

- - - -

I think NiLuJe had to give up on the Cygwin build due to some system changes at his end, at home.

[coplate]

Yeah, I don't know how old that kindletool folder is, but its just where I untarred the amazon gpl source trees.

Al I did was extract the uboot source files form the 5.8.1 and 5.8.9.2 sources provided by amazon, and ran a diff compare on them, and that's the only difference in those files.

I'm not exactly clear how the whole boot process works, so I'm not sure what else to do a comparison on.

My gut is telling me at this point that using the 5.8.9.2 uboot would move forward, but I don't know how to get it loaded either.

[knc1]

It has been raining here all day, still raining this evening.
For "fun" I have been reading the u-boot sources.
Nothing of any interest found (yet).

It may be a more interesting read, after it is configured.

I will be using an out of tree build directory(ies), just to make generated files more visible.

I do have a PW3-4Gbyte Kindle, with a serial port.
I don't really want to screw it up, testing something (new u-boot builds) I don't have any use for.
But I also can't see myself spending $165 + whatever on an off-shore purchasing service would charge to get a PW3-32Gbyte Kindle.

I still have a lot of reading to do before I have to decide on any of the above.

[coplate]

I've got my water damaged pw3 I'm happy to run any commands on

[Hexadecimal]

Originally Posted by coplate

It is probably worth trying regular customer service, and just telling them your symptoms, of using the wrong update, without mentiontinng anything you have done here.

It's possible that they can do a replacement of the manga model, even if they ship it from japan to you, the worst they can say is no, and you are just out about 15 minutes in their chat or on the phone. Best case is they ship you a new one form Japan, and you don't have to do anything.

You could say something like, "I bought it on vacation, but I'm back in the US now ( or wherever you are )"

OK. This morning I contacted them and got a new one... But still need to get it shipped to China.

[knc1]

Originally Posted by Hexadecimal

OK. This morning I contacted them and got a new one... But still need to get it shipped to China.

There are purchasing services that will do that for you.
Use your favorite web search utility to find them.

Since you have replaced your damaged one - there is no longer any reason for us to try making you special firmware to rescue it.

[Hexadecimal]

Originally Posted by knc1

There are purchasing services that will do that for you.
Use your favorite web search utility to find them.

Since you have replaced your damaged one - there is no longer any reason for us to try making you special firmware to rescue it.

Thanks. Maybe I'll try to make some day...

[coplate]

I'm not sure if theres a better place to put this than here, just wanted to add some info. If anyone can think of a better thread for me to move this.

I was playing around with my old board again, and one of the USB Boot pads has about 3.3v which looks like a USB data pin high level.

I took a usb cord I had with loose wores, and trid probing that, with unhelpful results.

I grounded my USB cord to the logic board, and probed those two pins, and with one of the data lines connected to the 3.3v one, my computer would register SOMETHING has connected to USB, but it didn't get any Device ID or anything else useful, the USBDeview app just change the USB port to purple, and highlighted it as some knd of connection.

[coplate]

@knc1

If Hexadecimal has gotten his replacement, he may not need this, But I'd love to understand this.

You had said in an earlier post in here that there may be some ways to replace uboot on this device, where he cannot load bist.

I'd love to give that a try on my device.

since the uboot that comes up first does not have loady or loadb ( ymodem or kermit ), it seemed like we might have to run a script to run the memory set commands some small number of byes at a time, with a very long running shell script?

Was there some other where you thought would be the way he could fix this?

[knc1]

Originally Posted by coplate

- - - -
You had said in an earlier post in here that there may be some ways to replace uboot on this device, where he cannot load bist.
- - - -

I do not know if it will meet the requirement: "cannot load bist".
Or more to the point: "cannot start external RAM" (which was the root problem here).

The amount of on-board (static) RAM is rather small.
You have to have either a program sized to run in that tiny static RAM or already programed in the internal ROM that can accept and set the hardware data it takes to start external RAM.

IIRC, the i.MX6_Loader program is that solution.
It can 'talk' to the daemon programmed in the internal ROM of the i.MX6 series of chips.
Somewhere around here we have a build (or builds) of i.MX6 loader posted.

I don't know of any way to get the i.MX6 loader deamon to run, other than have u-boot fail to load.
U-boot is checksummed, if the ROM code is testing the checksum, it should only take destroying the checksum (one byte change in the installed u-boot binary) to force it to start.
**should** - I don't have a clue if it will.

Then at a slightly higher level, there is a special "USB i.MX6 Bootstrap" file/application.
Buildroot(.org) build system will build a version for the i.MX6SL SoC.
Hmm...
It might also build i.MX6_Loader for you.

There should be a lot to find on the subject in the Buildroot.org mailing list archives.
I used to follow that ML, but unsubscribed 6 months or so ago.

= = = =

I know it sounds like: "poor mouthing" but I really do not have the hobby time available it would take to do anything about this area of discovery.

When the Kindle Touch first appeared on the market, a Wiki page was started on the topic of "Kindle Touch Hacking".
(Click the link in my signature to get a statement of my feelings of using that word in the context of this forum.)
<rant> ... </rant>

All Kindles starting with the PW2, so far, use the i.MX6SL version of the NXP(.com)* SoC.
And with the exception of the Oasis, have the same serial port connector pad/connector pin-out.

It would be a "good idea" (tm) to start a "Kindle i.MX6SL Reference" Wiki page.
Right now, it might only have three links back into the forum -
Serial Debricking, Recovery with Fastboot, and the Initializing a eMMC replacement threads.

That would be the place to put your findings, not scattered about in posts of this forum.
And other people could help out by adding to the new topic page.


* Formally: Freescale, Formally: Motorola