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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
