>FLASH is in attached state and I can read/write to it in no-fast mode. No blob is present in the FLASH.
For this to work the FLASH has to be in full-speed mode and for full-speed mode a .blob must be installed.
>First of all, am I wrong in assuming that CMD_INFLATE2 reads the FLASH from an address given by >CMD_FLASHSOURCE? Something like:
cmd_flashsource(flash_addr);
cmd_inflate2(ram_g, 64);
Yes, it works this way.
>Secondly, which kind of flash_addr does CMD_INFLATE2 need? A physical address or a >BITMAP_SOURCE-like one (i.e., 0x800000 | phy_addr/32)?
The adress is relative to the FLASH itself, so exactly like in the map file:
unified.blob : 0 : 4096
map_64x64_ARGB1555.bin : 4096 : 7040
Wolf_96x96_ARGB1555.bin : 11136 : 5184
EVE_cmd_flashsource(4096);
EVE_cmd_inflate2(MEM_PIC2, EVE_OPT_FLASH,0,0);
EVE_cmd_flashsource(11136);
EVE_cmd_inflate2(MEM_PIC3, EVE_OPT_FLASH,0,0);
>Thirdly, what does CMD_INFLATE2 exactly do? Does it read data from FLASH and inflate them on-the-fly,
>writing the result to RAM_G? Or does it read from FLASH, write data to RAM_CMD,
>then command CMD_INFLATE to RAM_G?
As there are no precautions listed this should decompress directly from FLASH to RAM_G.
Otherwise it would destroy whatever commands that are waiting to be executed in RAM_CMD.
And RAM_CMD is only 4kB anyways.
>By the way, byte1 at page 115 starts at byte 12, doesn't it?
Yes, I would think so as well.
And to be consistent with other commands it should be called byte0.
Since cmd_inflate2() is practically a twin of cmd_loadimage() I wonder why we even have cmd_inflate2().
A flag OPT_INFLATE for cmd_loadimage() would have been nice as well, and it could have been defined to include OPT_NODL.