cso support

[sundance2]

Thanks also for the technical elements describing the behavior of that feature.

Trying to get into some details :

> You are absolutely right, just did not take into account one more nuance. The LZO code itself takes up memory Smile ~2 Kb and it's essential.

2 KB for an LZO decoder feels overkill.
This kind of trivial compression format should be decodable using a ~200 bytes routine.
Granted, hand assembly is likely out of scope,
but given the baseline, I would have hoped that a good compiler would make it < 1 KB.

I expect the compiler to use DCE (dead code elimination),
but even in these cases, there might be some code which is integrated into the package and not especially useful.

Well, I guess it's probably a hard topic, out of your scope.

> the current implementation of reading lzo-compressed images in the loader requires additional *dynamic* memory, unfortunately. The implementation that does not use additional memory is disabled there were some problems with it.

I presume the "implementation that does not use additional memory" would be employing in-place decompression ?
This is a feature for many of these low-complexity formats, allowing decompressed data to overwrite the compressed one previously stored in the same buffer.
In general, there is a need for some margin for it to work properly (aka, the end of the compressed block is not positioned at the end of the decompressed block, but rather a few bytes beyond that).
How much is the margin depend on each format. If it's not known or not documented, it can be generously evaluated. Typically one cache line (32-bytes on SH4) should be enough.

> Of course you can! Just uncomment ENABLE_CISO=1 in Makefile.cfg of isoldr firmware.

I believe I did that when investigating the topic earlier this year.
But it did not solve the issue, as apparently the crash happens before reaching the loader.