BRT Community
General Category => Discussion - EVE => Topic started by: lorcap on September 13, 2019, 04:36:47 PM
-
Hi everyone,
I'm trying to wrap my head around CMD_INFLATE2. I'm always getting ERROR: corrupted DEFFLATE data in cmd_inflate2(). FLASH is in attached state and I can read/write to it in no-fast mode. No blob is present in the FLASH.
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);
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)? Chapter 2.1 Addressing Space cites CMD_INFLATE2 when talking about Flash memory. Chapter 5.86 CMD_FLASHSOURCE – Specify the Flash Source Address doesn't say anything about address space.
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?
By the way, byte1 at page 115 starts at byte 12, doesn't it?
-
>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.
-
To use the compressed assets in flash by cmd_inflate2, you need send cmd_flashsource to specify the address, which is offset from address 0. In the image enclosed,you can see the number 4096
is the parameter of cmd_flashsource, which is the first asset after flash driver (unified.blob).
Check the image enclosed for details.
CLEAR(1, 1, 1)
CMD_FLASHSOURCE(4096)
CMD_INFLATE2(0, OPT_FLASH)
CMD_SETBITMAP(0, RGB565, 128,128)
BEGIN(BITMAPS)
VERTEX2II(104, 93, 0, 0)
-
Forgot to mention one point: The cmd_inflate2 fetching data from flash only works correctly when flash is in full speed mode. So remember to issue command cmd_flashfast before all other commands are sent.
-
Thank to everyone. Working in full speed mode fixed my issue with CMD_INFLATE2.