MEGAFLASH: Slot 0 flashing might still leave system broken

[lydon42]

Senfsauce had again the problem with a aborted flash not booting into slot 1, even with the new mechanism.

We found out that the sync word might be part of the bitstream data itself, and that this is the case for Release 0.95:

❯ xxd mega65r3-rel0.95-test.cor | grep "aa99 5566"
000011a0: ffff ffff ffff ffff aa99 5566 2000 0000  ..........Uf ...
00361930: aaff aa99 5566 3333 0c03 555a 0000 0001  ....Uf33..UZ....

To circumvent this we need to do the following:

• always erase the whole slot 0 before start flashing
• make sure new factory cores do not contain duplicate sync words in bit2core
• change flashing of slot 1 and upwards so that it only erases the first sector (i.e. the core header)

[lydon42]

Confirmed second sync word does kill slot 1 recovery be flashing until before and after a known second sync word. Powerloss before 2nd sync word will not recover, powerloss at second sync word sector after erase recovers as expected.

[lydon42]

Essentially the flash process could look into the install flags of the installed slot 0 core. If the core has no FACTORY bit set it is an old core, and a full erase is needed. If it has the FACTORY bit set, it is a new core which was checked against double sync words and it would be save to just erase the first 64k(all 4k parameter sectors on r3)/256k(on r3a plus).

[lydon42]

New idea needed: cores can have multiple sync words. There is no way to predict them or remove them. So we need a method for MEGAFLASH to get rid of those first.

For this bit2core saves a list of max 15 sector positions (64k granularity, so 0x00-0x7f) to 0xf0-0xff in the core header, and sets bit 6 in the install flags to inform about this list.

MEGAFLASH then can first erase those sectors, before starting the full erase.