Posted 15 September 2012 - 08:23 AM
I found that sometimes putting in CWM recovery messes up the logo - that might be why you see the white screen. I made a CWM recovery flash that includes logo, so they both go in at the same time, and that fixed my white screen. You might try that, just take any logo out of any firmware, I don't think any of them are different.
As for snatching the kernel out of your unflashed unit (you should have got the recovery out of it too before you put CWM in) what I did is use dd or you can also use cat and pipe the output to a file. You have to find a rw part of the filesystem that will hold the kernel, which is usually a little over 2mb. But the flash partition it lives on is 8mb. So when you do the dump, you get 8mb.
I found some of the kernel backup tools that others said would back up your kernel did not work on the novel, so I had to do it manually.
First do a cat /proc/mtd to see what lives in which flash block. The kernel lives in mtd1.
The syntax is:
dd if=/dev/block/mtdblock1 of=/data/misc/mykernel
then adb pull /data/misc/mykernel and use a hex editor to look at it (I use HxD)
then rm /data/misc/mykernel (optional)
or
cat /dev/block/mtdblock1 > /data/misc/mykernel
then adb pull /data/misc/mykernel and use a hex editor to look at it (I use HxD)
then rm /data/misc/mykernel (optional)
Then you have to use a hex editor and try to figure out where the end of the kernel is, and delete all the junk after that, and you end up with just the kernel. Start looking around 2mb down with the hex editor and suddenly the data will change to a few 00's, then the rest will be FF's all the way to 8mb. This is the tricky part - deciding where the kernal actually ends. It's probably harmless to have a few extra bytes on it, but fatal to cut it too short and cut off some of the real code. I ended up with 12 bytes of 00's only because other kernels from older firmware versions always seemed to have that. Then I cut off the rest, saved the file, and it works!
I'm not sure what would happen if you just left the junk in there - in other words put the full 8k in your flash image and not worry about finding the end. It probably would still work because after all it's an image out of the device. But would waste time flashing so best to trim it to the actual size.
Some of the other flash partitions are harder to deal with, because they are gzip files with a fuse header on them, or they are yaffs2 images.
Recovery.img, and ramdisk.img are gzip files with fuse headers stuck on them. Others, like system.img, userdata.img, , cache.img and bootloader.img are yaffs2 images. I guess fuse figures this all out when flashing a unit.
What I did was remove the fuse header with a hex editor (you can spot the start of the gzip file by the bytes 1F 8B on the hex editor), then try to find the end of the file, which are some checksum bytes, and kept saving that and opening the result with 7-zip until it had a valid gzip file with valid start and end lengths. If the size is bogus then you don't have the end just right - try again. Once I knew where the gzip file really ended, then I want back to the original image with the fuse header in it, and took the crap off the end from where I found the file really ended, and saved that as an image, say ramdisk.img - with the fuse header present. Those will then flash properly with fuse. I also looked at other firmware versions with the hex editor to help me spot what the "end" looks like.
Hope that makes sense... some are just binary (like the kernel), some are gzips with fuse headers on them, and some are yaffs2 images.. I guess fuse figures out what is what when it flashes.
This is sort of complicated but it's how you reconstruct the complete firmware when all you have is a flashed device and Pandigital won't release the firware that is in your device. Makes no sense to me why they won't release it, as all it is going to do is cause them to get lots of returns for messed up devices that could be reset easily without causing a return.