cli: added support to sparse images flashing#21
cli: added support to sparse images flashing#21gfabiano wants to merge 2 commits intoqualcomm:mainfrom
Conversation
Signed-off-by: Giuseppe Fabiano <gfabiano40@gmail.com>
cli/src/programfile.rs
Outdated
|
|
||
| let mut fill_vec = Vec::<u8>::with_capacity(out_size); | ||
| for _ in 0..out_size / 4 { | ||
| fill_vec.extend_from_slice(&fill_value[..]); |
There was a problem hiding this comment.
We do something roughly equivalent inside program_storage already, so all this can simplify this branch to passing a &mut &[0u8][..] as an argument
There was a problem hiding this comment.
It's not the same because the fill value is a 4 bytes that you get from the sparse file and you repeat for N times. If you set &mut &[0u8][..] you will get zero repeated for N times that not respect the sparse format.
Giving a let mut fill_value = [1, 2, 3, 4]; read from files and an let out_size = 25 ( N=5 ) you shall get something like that
[1, 2, 3, 4, 1, 2, 3, 4, 1, 2, 3, 4, 1, 2, 3, 4, 1, 2, 3, 4]
It can sure be improved but I decided to keep it simple and not modify also the firehose_program_storage function.
If you have some hint on how to handle it better I can sure improve it.
There was a problem hiding this comment.
How about:
fill_vec.iter().repeat(fill_value).take(out_size/4);
since the value will likely be the same, we can perhaps cache fill_value and check if it differs on each found Fill chunk, and only re-assign the vector if we need to, taking away some overhead
|
I think that I must improve the implementation because typically raw chunks are contiguos so calling for every chunk |
| } | ||
| ChunkType::Crc32 => { | ||
| // Not supported, on qcom tools is ignored, seek if present | ||
| buf.seek_relative(4)?; |
There was a problem hiding this comment.
Out of curiosity, is the CRC valid on your images?
I think the current approach is ok - IIUC sparse chunks can be as big as you want (which |
The previous logics tried to flash each useful chunk one by one in 4KB chunks but this hogged the speed due to firehose transfers that took ~20-50ms for each XML command ACK cycle. Inspired by official qcom tool I merged different type of sparsed image chunks filling also the gaps of don't care with zeroes and try to keep large contiguous transfers. This allowed the flash to speedup from minutes to some seconds on sparse images like persist. Signed-off-by: Giuseppe Fabiano <gfabiano40@gmail.com>
gfabiano
force-pushed
the
sparse_image_support
branch
from
19b275e to
42cd9cb
Compare
2 participants
A first implementation to sparse images flashing. I tested it with some images and it works correctly on my qcom bench.