Re: [Sound-open-firmware] [PATCH v3 10/14] ASoC: SOF: Add userspace ABI support

Pierre-Louis Bossart
2018-12-21T14:59:15Z

On 12/21/18 5:10 AM, Daniel Baluta wrote:
> <snip>
> I have one question here, it is more related to the design of address
> space you are using.
>
>> --- /dev/null
>> +++ b/include/uapi/sound/sof/fw.h
>> +/*
>> + * Firmware module is made up of 1 . N blocks of different types. The
>> + * Block header is used to determine where and how block is to be copied in the
>> + * DSP/host memory space.
>> + */
>> +enum snd_sof_fw_blk_type {
>> + SOF_BLK_IMAGE = 0, /* whole image - parsed by ROMs */
>> + SOF_BLK_TEXT = 1,
>> + SOF_BLK_DATA = 2,
>> + SOF_BLK_CACHE = 3,
>> + SOF_BLK_REGS = 4,
>> + SOF_BLK_SIG = 5,
>> + SOF_BLK_ROM = 6,
>> + /* add new block types here */
>> +};
>> +
>> +struct snd_sof_blk_hdr {
>> + enum snd_sof_fw_blk_type type;
>> + uint32_t size; /* bytes minus this header */
>> + uint32_t offset; /* offset from base */
>> +} __packed;
> This assumes that all sections of the firmware are placed in the same
> "type" of memory area, right?
>
> We can go with that for the moment.
>
> On our side, because OCRAM is pretty small we found it useful to place
> some parts of the binary in SDRAM.
>
> So, I'm wondering if you considered that? I think with the current design
> is fairly easy to support that. Just add inside snd_sof_blk_hdr also the "base",
> make the loader.c correctly parse that. Also, make rimage aware of this.
It's a generic requirement indeed. Even on Baytrail we could run from
internal SRAM or external SDRAM, and a combination of the two. There are
also firmware modules that need to be placed in specific memories with
lower power, etc.