Skip to content

Conversation

@ktrzcinx
Copy link
Member

@ktrzcinx ktrzcinx commented Feb 21, 2020

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

Copy link
Member

@plbossart plbossart left a 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.

Copy link
Member

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...

Copy link
Member Author

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

@lyakh
Copy link
Collaborator

lyakh commented Feb 24, 2020

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?

@ktrzcinx ktrzcinx changed the title WIP: ASoC: SOF: Introuce extended manifest WIP: ASoC: SOF: Introduce extended manifest Feb 24, 2020
@ktrzcinx ktrzcinx force-pushed the ext-mnf branch 3 times, most recently from de84923 to 2abbb33 Compare February 24, 2020 11:26
@ktrzcinx
Copy link
Member Author

@lyakh

thesofproject/sof#2427

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 .comment doesn't sounds good for me so I will stay with my name.

Copy link
Collaborator

@ranj063 ranj063 left a 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
kv2019i previously approved these changes Mar 16, 2020
Copy link
Collaborator

@kv2019i kv2019i left a 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>
Copy link
Collaborator

@ranj063 ranj063 left a 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!

@ktrzcinx ktrzcinx requested a review from kv2019i March 17, 2020 05:49
@kv2019i
Copy link
Collaborator

kv2019i commented Mar 17, 2020

Thank you @ktrzcinx , merging now!

@kv2019i kv2019i merged commit 8ffa879 into thesofproject:topic/sof-dev Mar 17, 2020
Copy link
Collaborator

@lyakh lyakh left a 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) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it should ne <= probably?

Copy link
Collaborator

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.

Copy link
Collaborator

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) {
Copy link
Collaborator

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>
Copy link
Collaborator

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.

Copy link
Member Author

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>
Copy link
Collaborator

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>

Copy link
Member Author

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/.

Copy link
Collaborator

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;
Copy link
Collaborator

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any difference?

Copy link
Collaborator

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.

@kv2019i
Copy link
Collaborator

kv2019i commented Mar 17, 2020

@lyakh wrote:

just noticed it's been merged in the meantime. Never mind.

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.

@ktrzcinx
Copy link
Member Author

Thanks @plbossart @ranj063 @kv2019i @lyakh

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ABI involves ABI changes, need extra attention

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants