On Sun, May 01, 2016 at 10:57:55PM -0700, Steve Rae wrote: > On Apr 15, 2016 21:14, "Steve Rae" <steve....@broadcom.com> wrote: > > > > Maxime, > > > > I suspect that the issue fixed > > in commit c7529db fastboot: sparse: fix block addressing for > > don't care chunk type > > > > complicated the assumptions which led to the implementation of the > "sessionId" > > in commit 1f8690a sparse: Implement several chunks flashing > > > > The fastboot client will split the sparse images into several chunks > if the > > image that it tries to flash is bigger than what the device can > handle. > > > > In such a case, the bootloader is supposed to retain the last offset > to > > which it wrote to, so that it can resume the writes at the right > offset > > when flashing the next chunk. > > > > Retain the last offset we used, and use the session ID to know if we > need > > it or not. > > > > > > Testing of this scenario has revealed that "fastboot flash" works as > follows: > > > > When the image to download is larger than the > > "target reported max download size of 40960000 bytes", > > the fastboot client (running on the host) essentially performs > > multiple, independent fastboot download/write steps. > > > > As seen in the logs below, each download/write step: > > (a) starts at the same address (the address of the first block of the > > partition...) > > (b) ends at the same address (start address plus number of blocks > "written"...) > > (c) and uses the CHUNK_TYPE_DONT_CARE 'chunk_sz' to manipulate the > > addresses to achieve (a) and (b) > > > > Here is an example of the first three fastboot download/writes for a > > large image to "file-system": > > - in the first, data is written to 0x24000-0x37848, then there is a > > CHUNK_TYPE_DONT_CARE which "moves" the address pointer to 0x424000 > > - in the second, it starts with a CHUNK_TYPE_DONT_CARE which "moves" > > the address from 0x24000 to 0x37848, then writes from 0x37848-0x4b098, > > then there is a CHUNK_TYPE_DONT_CARE which "moves" the address pointer > > to 0x424000 > > - in the third, it starts with a CHUNK_TYPE_DONT_CARE which "moves" > > the address from 0x24000 to 0x4b098, then writes from 0x4b098-0x5e8e0, > > then there is a CHUNK_TYPE_DONT_CARE which "moves" the address pointer > > to 0x424000 > > > > > > Starting download of 40932412 bytes > > .......................................................................... > > downloading of 40932412 bytes finished > > Flashing sparse image at offset 147456 > > Flashing Sparse Image > > - this is the starting address: 0x24000 > > ++++ (writing to flash) > > - this is the CHUNK_TYPE_DONT_CARE (before) address: 0x37848 > > - this is the CHUNK_TYPE_DONT_CARE (after) address: 0x424000 > > - this is the ending address: 0x424000 > > ........ wrote 4194304 blocks to 'file-system' > > > > Starting download of 40954208 bytes > > .......................................................................... > > downloading of 40954208 bytes finished > > Flashing sparse image at offset 147456 > > Flashing Sparse Image > > - this is the starting address: 0x24000 > > - this is the CHUNK_TYPE_DONT_CARE (before) address: 0x24000 > > - this is the CHUNK_TYPE_DONT_CARE (after) address: 0x37848 > > ++++ (writing to flash) > > - this is the CHUNK_TYPE_DONT_CARE (before) address: 0x4b098 > > - this is the CHUNK_TYPE_DONT_CARE (after) address: 0x424000 > > - this is the ending address: 0x424000 > > ........ wrote 4194304 blocks to 'file-system' > > > > Starting download of 40955896 bytes > > .......................................................................... > > downloading of 40955896 bytes finished > > Flashing sparse image at offset 147456 > > Flashing Sparse Image > > - this is the starting address: 0x24000 > > - this is the CHUNK_TYPE_DONT_CARE (before) address: 0x24000 > > - this is the CHUNK_TYPE_DONT_CARE (after) address: 0x4b098 > > ++++ (writing to flash) > > - this is the CHUNK_TYPE_DONT_CARE (before) address: 0x5e8e0 > > - this is the CHUNK_TYPE_DONT_CARE (after) address: 0x424000 > > - this is the ending address: 0x424000 > > ........ wrote 4194304 blocks to 'file-system' > > > > [... snip ...] > > > > > > Therefore, I think that the "sessonId" that is implemented in U-Boot > > is actually incorrect. There is no need to keep track of the addresses > > as each "fastboot flash" download/write step is completely > > independent. > > And I actually need to remove it in order to get this working again: > > > > - if (session_id > 0) > > - start = last_offset; > > - else > > - start = storage->start; > > + start = storage->start; > > > Maxime: > (nudge) > Any comments here? > Would you like me to submit a patch to fix this?
I think if you can fix this issue, please do. Thanks! -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
