Skip to content

Conversation

@ktrzcinx
Copy link
Member

@ktrzcinx ktrzcinx commented Oct 6, 2020

After merge #2957, extended manifest is included in each firmware image. Data structs from fw_ready_metadata has already been ported to extended manifest so there's no need to duplicate the same data in mailbox in the fw_ready_metadata section. Kernel code scan has support for both data location, so it shouldn't be an issue.
After changes 448 bytes has been saved from .TEXT segment and 536 bytes from .DATA and data duplication has been deleted.

I didn't delete fw_ready_metadata mechanism to keep possibility of passing eg. hardware related information (doesn't known at compilation time) to kernel, at start-up.

Kernel can parse:

@paulstelian97
Copy link
Collaborator

You claim extended manifest is enabled by default, not force-enabled. So what's gonna happen on systems where it is disabled?

I'd say this patch is welcome when extended manifest loses its kconfig and is always available.

@ktrzcinx
Copy link
Member Author

ktrzcinx commented Oct 6, 2020

@paulstelian97 there's no kconfig option for extended manifest on/off, after #2957 merge each build should contain this part. I have edited initial PR description.

@ktrzcinx ktrzcinx requested a review from a team as a code owner October 6, 2020 11:53
Copy link
Member

@lgirdwood lgirdwood left a comment

Choose a reason for hiding this comment

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

@kv2019i fyi - does the kernel still read some items from mailbox ?

@lgirdwood lgirdwood added this to the ABI-3.18 milestone Oct 6, 2020
@lgirdwood lgirdwood added the ABI ABI change involved label Oct 6, 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 good from kernel point of view. SOF1.7 will anyways require a recent kernel to load the FW, and these kernels can parse the info from ext_manifest, so we have no strict need to keep this around.

And as far as I can see, the IPC message ABI is not modified (which is good).

@lgirdwood
Copy link
Member

@kv2019i just to confirm, this is good to merge today with no kernel update ?

This information is already provided by extended manifest,
so there is no need to double it in runtime code.
It allows to save 92 bytes from .DATA and 128 bytes from .TEXT
for cnl platform.

Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
This information is already provided by extended manifest,
so there is no need to double it in runtime code.
It allows to save 28 bytes from .DATA and  128 bytes from .TEXT
for cnl platform.

Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
@ktrzcinx ktrzcinx force-pushed the slim-fw branch 2 times, most recently from 628f6f4 to acf6454 Compare October 7, 2020 08:43
This information is already provided by extended manifest,
so there is no need to double it in runtime code.
It allows to save 400 bytes from data .DATA and 64 bytes from .TEXT
for cnl platform.
EXT_MAP_PORT() macro is no longer needed.
Created __unused macro in compiler_attributes.h as compiler
attributes shouldn't be used directly, to allow easy compiler change.

Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
This information is already provided by extended manifest,
so there is no need to double it in runtime code.
It allows to save 16 bytes from .DATA and 128 bytes from .TEXT
for cnl platform.
`data_structs` library from src/ipc/CMakeLists.txt is no longer
needed. Moreover empty library may lead to cmake fail.
SMEX needs little update, to read DBG_ABI from .fw_metadata section
instead of .fw_ready.

Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
@ktrzcinx
Copy link
Member Author

ktrzcinx commented Oct 8, 2020

@lgirdwood kernel is prepared for this for a long time (I add kernel support for this while extended manifest introduction) - jenkins CI results are good proof of it. Internal Intel CI must be updated, this work is in progress (near finish).

@lgirdwood
Copy link
Member

@ktrzcinx ok, please ping when CI is finished. jenkins looks like a HW DUT is not booting.

@zrombel
Copy link

zrombel commented Oct 9, 2020

CI is ready, all tests are PASS, PR is good to merge.

@lgirdwood
Copy link
Member

CI jenkins looks like DUT HW issues as it's not booting.

@lgirdwood lgirdwood merged commit f97e9f0 into thesofproject:master Oct 12, 2020
@lyakh
Copy link
Collaborator

lyakh commented Oct 15, 2020

@lgirdwood @ktrzcinx this broke Zephyr boot

@lgirdwood lgirdwood added the Zephyr Issues only observed with Zephyr integrated label Oct 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ABI ABI change involved Zephyr Issues only observed with Zephyr integrated

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants