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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
