On 26.09.2007 18:11, ron minnich wrote:
On 9/26/07, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
OK, this patch is not for the weak of hart because it touches some logic we had lots of problems with in the past. Basically, the lar archive header walk will not see a header at the end of the archive if nothing is after that header. However, since a file with zero size is a legal lar member, we really can't forbid to look at a header terminating the archive.
I need to be convinced that there is any value if having a header for a zero-length file at the very end of the archive. I think this is way more capability than we need, and I am very paranoid about LAR, given the subtle bugs that we have had. Otherwise, I would rather not commit this.
I have a case where this is needed if we don't want to maintain two different lar archive formats: AFAIK not all architectures start executing code at the top of ROM, some start at the bottom (low address). In that case, we can't start the archive with a LAR header, but we can end it with one. We could redefine offset as signed instead of unsigned and make the last lar header point to the boot block at the beginning. That way, even bottom boot architectures can use the current format unless the flash size is >2GB.
Current LAR archives look like this:
Hn=header n -=padding Dn=data n H0D0D0D0H1D1----H2D2D2 where the last bytes of D2 are executed after poweron.
The patch (together with signed offset) would make archives like the below one possible: D0D0D0H1D1----H2D2D2H0 (header at end of archive points to boot block) or this one: D0D0D0H0H1D1----H2D2D2 (header after boot block points to boot block)
Both new archives allow placing a boot block at the beginning without sacrificing the goal of one common archive format. However, there are two potential problems: - endless loops if we aren't careful when walking the LAR - "nobody will need more than 640kB", in our case it would be 2GB
Regards, Carl-Daniel