-
Notifications
You must be signed in to change notification settings - Fork 140
ASoC: SOF: Introduce extended manifest #1818
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
551a2d0 to
b5754d8
Compare
plbossart
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting idea, but this needs a lot of work... See comments below
I think it'd be worth documenting what information remains provided by the firmware after it boots, and what is provided by the extended manifest.
Also all the firmware handling is really questionable.
include/sound/sof/xman.h
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
type, size of blob, binary blob.
Why add a size and remove 2*sizeof(uint32_t) to get to the array...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reordered. Using struct is much more descriptive solution than raw array reading and remembering data format
|
There's probably a corresponding PR for the rimage tool to generate that manifest - could you point out to it, please? I don't know how high on the agenda (or even how realistic) this is, but we're talking from time to time about adding support for or entirely moving to RPMSG for IPC (@lgirdwood). RPMSG includes support for loading firmware and the only currently supported firmware format is ELF. In ELF format a part of this information is contained in .comment section, specifically the compiler version. So, if we're moving over to RPMSG / ELF - this shouldn't be done in this way. If we aren't moving over at least for now, maybe we can at least reuse the .comment section for this purpose? |
de84923 to
2abbb33
Compare
|
I design extended manifest to be very extensible, you will can add there some extra without big effort and impact on firmware flash size. But section name |
ranj063
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ktrzcinx looking almost good but still some typos, minor changes and clarifications in comments needed.
It makes possible to provide extra information to host before downloading firmware. Extra data should be put at the beginning of firmware binary. Exchange is done without any effort on DSP side. This mechanism will be used in extended manifest. Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
kv2019i
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks still good to me -- waiting for an ack from @ranj063 . To me there was one very minor spelling error, but otherwise looks everything else is addressed now.
Extended manifest is a place to store build time known firmware metadata, for example firmware version or used compiler description. Given information is read on host side before firmware startup. This part of output binary is located as a first structure in binary file. Extended manifest should be skipped in firmware loading routine. Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
The firmware version can be extracted from the extended manifest content. This information known at build time does not need to be provided in a mailbox. Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
The window description can be extracted from the extended manifest content. This information known at build time does not need to be provided in a mailbox. Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
The compiler version and description can be extracted from the extended manifest content. This information known at build time does not need to be provided in a mailbox. Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
ranj063
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @ktrzcinx for being patient with so many review comments. Looks good now!
|
Thank you @ktrzcinx , merging now! |
lyakh
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just noticed it's been merged in the meantime. Never mind.
|
|
||
| stripped_firmware.data = plat_data->fw->data; | ||
| stripped_firmware.size = plat_data->fw->size; | ||
| if (plat_data->fw->size < plat_data->fw_offset) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it should ne <= probably?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least "<" guarantees the wrap around, that's the purpose of this check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kv2019i sorry, don't understand. The difference between <= and < is the == case. With <= == would also trigger the error path. And indeed, that would fit the error message ("must be larger") and 0 size after the offset doesn't indeed seem to make much sense. As for wrapping around 4GiB - wouldn't you have to catch that earlier - when performing calculations, that potentially can wrap?
| struct snd_sof_fw_header *header; | ||
| size_t fw_size = fw->size - fw_offset; | ||
|
|
||
| if (fw->size < fw_offset) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
| #ifndef __SOF_FIRMWARE_EXT_MANIFEST_H__ | ||
| #define __SOF_FIRMWARE_EXT_MANIFEST_H__ | ||
|
|
||
| #include <linux/const.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you also need <linux/types.h> and <linux/bits.h>. Strictly speaking also <linux/compiler.h> but it looks like nobody does that, that will be pulled in for you somewhere along the way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will keep it in mind and make a proper fix.
|
|
||
| #include <linux/firmware.h> | ||
| #include <sound/sof.h> | ||
| #include <uapi/sound/sof/ext_manifest.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not quite clear about this myself and I've done this myself that way before, but I think now, that it should be sufficient to just #include <sound/sof/ext_manifest.h>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This header if designed to be read from host side and giving possibility for example to check fw version from user space is not so bad. Moreover thanks to keeping this file in uapi/, include/kernel folder from sof repo is mapped in a whole to uapi/.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, I didn't mean that the header was wrongly placed, I just meant, that I think, just #include <sound/sof/ext_manifest.h> would find the header under uapi/ too.
|
|
||
| static ssize_t snd_sof_ext_man_size(const struct firmware *fw) | ||
| { | ||
| const struct sof_ext_man_header *head = (void *)fw->data; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would be much better to cast to the target type, i.e. (const struct sof_ext_man_header *)fw->data
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any difference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so, yes. Type-casting should be avoided whenever possible and where not possible, done in the most appropriate and careful way.
|
@lyakh wrote:
My apologies. GH showed you had no changes requested, so given the many approvals, I went and merged it. I did have to use maintainer override, so I think GH tried to warn me that you had review in progress, but it was not visible in the issue status, so I thought it was just a glitch and went ahead. I'll do better next time. In general, we should be more synchronized with the review process. This has received almost 300 comments and in more than 3 big waves spanning over three weeks, which is not very efficient. I miss the "author+1" feature from Gerrit, to have a more clear sign that the author thinks the change is now ready for merging and is a queue for reviews to happen. |
|
Thanks @plbossart @ranj063 @kv2019i @lyakh |
Extended manifest is a place to store metadata about firmware, known during
compilation time - for example firmware version or used compiler.
Given information are read on host side before firmware startup.
This part of output binary is located as first struct in binary file and
is not signed. This part of file shouldn't be loaded into DSP memory.
Signed-off-by: Karol Trzcinski karolx.trzcinski@linux.intel.com
thesofproject/sof#2427