![]() ![]() then flash times would be dynamic, ~9s or ~18s for a NC2, plus a possible time of ~27s for NC1.ĭefinitions for the calibrations in hand have been updated in GitHub. What should take ~18s will now take ~27s.ĭef could make romdrop diff the last successful flash. it will sequentially erase blocks 1, 2, and 3. So if you have a NC1 with a change in data block 1, that change will update the checksum in block 3. The last bump in the road, the native code erases sequentially. The NC1’s data offset forces it to cover 3 blocks, the NC2 covers 2. Any additional blocks will increment the flash time by ~9sec. So ~9secs is the fastest possible flash time if the data you change is in the last block along with the checksum. the catch is, any change in data, will also change the last block due to the checksums living there. So thats pretty much fastest possible flash time. so I can’t really write individual bytes. Unfortunately from what I’ve seen so far, the chipset erases flash memory in blocks. Not that 19 seconds is exactly holding things up. Minor table changes could be made in the blink of an eye. As long as you have a previous ROM image, you can compare the old and new and only download the bytes actually changed. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |