Quote:
Originally Posted by DNSB
You seem to be assuming that all Kobo ereaders have a vcom value stored in that area and all Kobo ereaders have a waveform table. The waveform table is only present when you have a eInk display with Regal capability.
If you want it to boot, you need the MBR (or a GPT). If you want to write a utility that allows skipping portions of the source or destination, have fun.
Being honest, no. The chances are good that a slightly mismatched waveform table would be better than none. And one of my recommendations is to use a new µSD card. Very often the issues are due to the card having problems.
Most of the data stored in the unallocated area is not stored as a file but rather as blocks of raw data. If you are lucky, you get a length written at the start of the block but there is no filename. I mostly use a hex editor to take a look at the image data.
Basically, I imaged a flash drive from the Kobo image, copied the contents of the FAT32 partition to a directory on my computer and then made sure quick format is not checked and formatted the partition. This wipes the deleted but not overwritten data by overwriting with whatever value is used (0x00, 0xF6, 0xE5 and oxFF are ones I remember being used (the 0xFF is likely the most popular now being used for solid state storage)) and then copied the files back to the partition, recreated the image and then compressed it. Those repeated fill byte strings compress very enthusiastically reducing the image size and allow me a bit of piece of mind knowing that stray data is not floating around waiting for someone to use an undelete utility or similar to try to recover it.
In the case of your image, you can do the copy/format/copy back with your ereader mounted to your computer though that would be slow. Mounting the uSD card directly to your computer is faster but for Windows, you end up with issues if you don't pay attention. I've used the MiniTool Partition Wizard to format the FAT32 partition on the mounted µSD card.
|
I guess Im only talking about Nia bc thats all i have
the linux dd utility can skip destination AND source, im about to test if i can change waveforms/vcoms with this. do u think using rev a waveform on rev c motherboard will damage the display? rev a and c have different waveforms or maybe its unqiue to each panel. the only diff between rev a and c seems to ne the PMIC according to niljue on github, at the very least.
i see, so most people are using this to repllace a dead sd card? but if the original card is not dead, the original waveform or vcom would be good to have?I suppose people can already do this on their own with your images by simply using dd skip and seek. by waveform do u mean vcom or waveform? i read that waveforms are unique to each panel as well as vcom but its v hard to find reliable information
i have just checked various images, waveforms are indeed unique to each panel... sigh so that means using a rev c on a rev a should be fine...
hex editor? i see thanks. explaining to idiots like me is a sysphean task