MobileRead Forums - View Single Post - How to update Kindle 2/DX/DXG with YifanLu's firmware from 3.2.1 to 3.4.2

knc1 · 12-02-2015, 02:09 AM

The Linux flash storage stack will not allow writes outside of the partition area addressed.
That would be just like allowing excessive writes to one partition to overwrite the next partition. The emulation of a device handles that.

Writing to the raw device, outside of a partition (outside of an emulated device) is left to the programmer (person, not device).
Things like the primary and secondary kernels in the case of a series 2 device.

There is no magic in these apparent magic numbers.
Although some factors of purely historic interest creeps in.

Kindles that use a single eMMC device (K3 and more recent). . . .
(I think, but have not confirmed, that this same logic was used in the series 2 design - K2/DX/DXG).

The raw storage uses a "DOS disk label" - which implies an MBR followed by a partition table.
The layout format used is the "hard disk" format for a DOS disk label.

The label occupies the first track in CISC machines (Intel) and the first cylinder in RISC machines (the 64bit Alpha).
Tracks where 16 sectors.
Cylinders where 2 tracks (hard disks only had two platter sides externally accessible for storage).

ARM is RISC.
The RISC code for the MBR will not (would not) fit in one track of 16 sectors, which is why the allowance for the first cylinder (32 sectors).

In flash storage, multiples of an erase block are ok, fractions of an erase block are a big no-no.
Erase blocks are 4,096 bytes. I.E: the sector size of flash is 4096 (8*512).
16 sectors per track, 2 tracks per cylinder ==
(8*512)*16*2 = 131072 bytes (a hard disk layout mapped to a 4096 byte sector) == space occupied by the disk label.

That first disk label defines four primary partitions.
Each of the first three contain **only** a file system (ext3 in our case).
The fourth primary partition contains another "DOS disk label" (this is legal per the Microsoft specifications - any partition may have its own (additional) disk label - nested to any depth)

Which means you will find another MBR area prior to the partition table.
A handy place to put custom code, since it is exported along with the USB storage area and accessible with Linux (and Windows, with custom code).
We don't (yet) use that area (neither does Amazon).

This partition table defines only a single, 'hard disk layout' partition. A.K.A: USB mass storage.

It could define more than one and some people here have posted about doing just that - - the Kindle firmware survives the experience.

Or - at least it used to, I don't think anyone has checked recently.

The file system on this single partition is FAT32.
Which has an internal structure defined in terms of sectors (not bytes).

To keep all of the internal structure erase block aligned, that FAT32 area is formated as if it had a sector size of 8,192 bytes (2 erase blocks).

See? Nothing magic about the numbers used.

= = = =

Note:
People who get the bright idea to re-format their Kindle's USB mass storage area using a disk format program that does not allow specifing a non-default (512 byte) sector size (translation: Microsoft CICS disk formatters) are doing themselves a great dis-service.
It'll work, but not very well, since the erase block boundraries are not observed.

Much better to just invalidate the USB mass storage area (trash its MBR and partition table area) and re-boot the Kindle.
The Kindle's start-up routines will discover the trashed USB mass storage and re-format it to fit the flash structure.
You may have to look at the boy under the tree an unusually long time, but it will do the job.

12-02-2015, 02:09 AM	#176
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	The Linux flash storage stack will not allow writes outside of the partition area addressed. That would be just like allowing excessive writes to one partition to overwrite the next partition. The emulation of a device handles that. Writing to the raw device, outside of a partition (outside of an emulated device) is left to the programmer (person, not device). Things like the primary and secondary kernels in the case of a series 2 device. There is no magic in these apparent magic numbers. Although some factors of purely historic interest creeps in. Kindles that use a single eMMC device (K3 and more recent). . . . (I think, but have not confirmed, that this same logic was used in the series 2 design - K2/DX/DXG). The raw storage uses a "DOS disk label" - which implies an MBR followed by a partition table. The layout format used is the "hard disk" format for a DOS disk label. The label occupies the first track in CISC machines (Intel) and the first cylinder in RISC machines (the 64bit Alpha). Tracks where 16 sectors. Cylinders where 2 tracks (hard disks only had two platter sides externally accessible for storage). ARM is RISC. The RISC code for the MBR will not (would not) fit in one track of 16 sectors, which is why the allowance for the first cylinder (32 sectors). In flash storage, multiples of an erase block are ok, fractions of an erase block are a big no-no. Erase blocks are 4,096 bytes. I.E: the sector size of flash is 4096 (8512). 16 sectors per track, 2 tracks per cylinder == (8512)162 = 131072 bytes (a hard disk layout mapped to a 4096 byte sector) == space occupied by the disk label. That first disk label defines four primary partitions. Each of the first three contain only a file system (ext3 in our case). The fourth primary partition contains another "DOS disk label" (this is legal per the Microsoft specifications - any partition may have its own (additional) disk label - nested to any depth) Which means you will find another MBR area prior to the partition table. A handy place to put custom code, since it is exported along with the USB storage area and accessible with Linux (and Windows, with custom code). We don't (yet) use that area (neither does Amazon). This partition table defines only a single, 'hard disk layout' partition. A.K.A: USB mass storage. It could define more than one and some people here have posted about doing just that - - the Kindle firmware survives the experience. Or - at least it used to, I don't think anyone has checked recently. The file system on this single partition is FAT32. Which has an internal structure defined in terms of sectors (not bytes). To keep all of the internal structure erase block aligned, that FAT32 area is formated as if it had a sector size of 8,192 bytes (2 erase blocks). See? Nothing magic about the numbers used. = = = = Note: People who get the bright idea to re-format their Kindle's USB mass storage area using a disk format program that does not allow specifing a non-default (512 byte) sector size (translation: Microsoft CICS disk formatters) are doing themselves a great dis-service. It'll work, but not very well, since the erase block boundraries are not observed. Much better to just invalidate the USB mass storage area (trash its MBR and partition table area) and re-boot the Kindle. The Kindle's start-up routines will discover the trashed USB mass storage and re-format it to fit the flash structure. You may have to look at the boy under the tree an unusually long time, but it will do the job.