Fucking Kmail is broken. How many times did it reply to the original sender instead of the list?
On Friday, March 14, 2014 11:51:54 AM you wrote:
On Friday, March 14, 2014 08:58:01 AM you wrote:
CBFS is definitely not friendly to environments that can't map() the storage area of the CBFS itself. Beyond that in-storage format with metadata tightly coupled to the data itself leads to needing to stream large amounts of data through the working set just to locate the piece that is desired.
On top of that the CBFS API doesn't allow for freeing up of used resources. Yes, there is the construct of map() and unmap(), but the used API in the code base returns pointers from map() and that means there is no way to free up the internal cache.
I found out that keeping track of the last map() pointer allows you to free the cache during unmap(), as currently, operations come in map/unap pairs. Sadly, this is just an accident of how CBFS core works. This design also places the burden of cache management on the backend, which also has to deal with whatever device it deals with. A pretty bad abstraction model.
However, read() doesn't solve the map() problem. read() and map() both need memory so in a constrained environment w/o memory-mapped access to the CBFS storage.
The CBFS core doing map() + memcpy() doubles the resource requirements with no real gain.
Lastly, the big reason for large map() requests is because we don't have a pipelined lzma path.
Compression is "don't care" for the CBFS core until the stage is decompressed. By the time you realize you don't need to decompress, you've already map()ed the whole of romstage, which you now need to memcpy() to its destination.
For the non-lzma files read() will work exactly as you described.
Not for non-lzma stages, which is the relevant bit for the bootblock, before you get to romstage, where supposedly, you'll have RAM later on.
I don't care that much anymore about this problem. I found a workaround for it, but someone else will drop the soap when doing the next little SoC.
I noticed in your code [1] you just read in all of the CBFS in-core. Or did I misread that? And your init_default_cbfs_media() always re-initializes and reads the CBFS again? I take it that function only gets called once? Most likely because that is the bootblock.
I only initialize the CBFS mirror once. If the code finds a valid CBFS signature in RAM, it skips the whole re-read-this step.
[1] https://github.com/mrnuke/coreboot/blob/369998920685852246dcae4c3e88b268 c1 c9f2dc/src/cpu/allwinner/a10/bootblock_media.c