You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently SOF driver only support modular mode, but we have requirement to support built-in mode, the main gap currently is that rootfs may be unavailable yet during SOF driver loading stage.
I initiated this with intention to reminding about trying to implement built-in driver support without built-in FW/tplg images using some retry(later) logic once request_firmware fails.
As we have implemented runtime suspend/resume now, it's possible to do this retry in runtime resume, though it fails at the first boot with built-in driver(need keep pci driver working at this fails), @plbossart what do you think about this?
@keyonjie I don't think we should try this. We need to verify all the boot flows immediately, not rely on some sort of retry. In other implementations such as Edison where everything was built-in, the firmware was embedded in the kernel and that's an acceptable restriction to me.
@plbossart
Then it may not be easy to try with the CI. It will need the firmware inside the kernel build folder. And the kernel config set to include the binaries.
Maybe I can come up with some scripts to test it once a week. I will upload the scripts and the def-config to kconfig repo once I have done the test.
Anecdotally, I can confirm success with both built-in FW/tplg and in the initramfs on bdw-rt5677 (samus).
Kernel 5.9.0-rc5+ eb5f95f
FW/tplg latest release v1.5.1
NXP side (also anecdotal), we had used built in (with in-kernel-image firmware) as well (a while ago actually). A bit hacky but that's how we did it for a while. Had to do that because built-in SOF somehow loaded before the networked rootfs...
I wonder if there's a de facto solution for having builtin modules which load the firmware from rootfs (to avoid building the firmware inside the kernel image).
When we tried this solution loading the firmware always failed because the rootfs wasn't available at that time.
I wonder if there's a de facto solution for having builtin modules which load the firmware from rootfs (to avoid building the firmware inside the kernel image).
using a userspace fallback mechanism is currently the only viable solution as only userspace can know for sure when the real rootfs is ready and mounted.
I wonder if there's a de facto solution for having builtin modules which load the firmware from rootfs (to avoid building the firmware inside the kernel image).
using a userspace fallback mechanism is currently the only viable solution as only userspace can know for sure when the real rootfs is ready and mounted.
Problem with that is that a weird cyclic dependency happens that prevents the rootfs from ever mounting (nfsroot comes after sof for some reason?).
Also AFAICT we at NXP do not use any initramfs at all.
Activity
wenqingfu commentedon Apr 1, 2019
Is this request still valid? If so, any idea can throw on the table?
plbossart commentedon Apr 1, 2019
I think it could be done by baking the firmware and topology files inside of the kernel, otherwise the dependency with the filesystem remains.
keyonjie commentedon Apr 2, 2019
I initiated this with intention to reminding about trying to implement built-in driver support without built-in FW/tplg images using some retry(later) logic once request_firmware fails.
As we have implemented runtime suspend/resume now, it's possible to do this retry in runtime resume, though it fails at the first boot with built-in driver(need keep pci driver working at this fails), @plbossart what do you think about this?
plbossart commentedon Apr 2, 2019
@keyonjie I don't think we should try this. We need to verify all the boot flows immediately, not rely on some sort of retry. In other implementations such as Edison where everything was built-in, the firmware was embedded in the kernel and that's an acceptable restriction to me.
keyonjie commentedon Apr 3, 2019
OK, then let's close this item.
plbossart commentedon Apr 3, 2019
no, let's try with the firmware embedded in the kernel and close when it's verified.
xiulipan commentedon Apr 4, 2019
@plbossart
Then it may not be easy to try with the CI. It will need the firmware inside the kernel build folder. And the kernel config set to include the binaries.
Maybe I can come up with some scripts to test it once a week. I will upload the scripts and the def-config to kconfig repo once I have done the test.
KVM: x86: Allocate new rmap and large page tracking when moving memslot
Merge pull request thesofproject#139 from valx90/vghita/intro-lab-fixes
x86: Fix early boot crash on gcc-10, third try
x86: Fix early boot crash on gcc-10, third try
caseorum commentedon Sep 19, 2020
Anecdotally, I can confirm success with both built-in FW/tplg and in the initramfs on bdw-rt5677 (samus).
Kernel 5.9.0-rc5+ eb5f95f
FW/tplg latest release v1.5.1
paulstelian97 commentedon Sep 21, 2020
NXP side (also anecdotal), we had used built in (with in-kernel-image firmware) as well (a while ago actually). A bit hacky but that's how we did it for a while. Had to do that because built-in SOF somehow loaded before the networked rootfs...
keyonjie commentedon Sep 21, 2020
Thanks for trying this out @caseorum and @paulstelian97. @lyakh FYI.
dbaluta commentedon Sep 21, 2020
I wonder if there's a de facto solution for having builtin modules which load the firmware from rootfs (to avoid building the firmware inside the kernel image).
When we tried this solution loading the firmware always failed because the rootfs wasn't available at that time.
lyakh commentedon Sep 21, 2020
@dbaluta As mentioned in https://www.kernel.org/doc/html/latest/driver-api/firmware/direct-fs-lookup.html#firmware-and-initramfs
paulstelian97 commentedon Sep 21, 2020
Problem with that is that a weird cyclic dependency happens that prevents the rootfs from ever mounting (nfsroot comes after sof for some reason?).
Also AFAICT we at NXP do not use any initramfs at all.
Merge pull request thesofproject#139 from ojeda/fix-depmod
plbossart commentedon Jun 10, 2021
let's close this, there are existing solutions and no real new development needed.
marc-hb commentedon Jun 22, 2021
Some references.
This problem is not specific to audio and there are security aspects:
http://lkml.iu.edu/hypermail/linux/kernel/1508.1/03428.html
Note not every device has the simple concept of "one rootfs".
ChromeOS had a generic workaround for a long time:
https://chromium-review.googlesource.com/q/system_running
... which has been NACKed upstream.
selftests/bpf: Bump internal send_signal/send_signal_tracepoint timeout
wifi: mt7601u: fix an integer underflow
ext2/dax: Fix ext2_setsize when len is page aligned
ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()
Merge branch 'bpf-arm64-add-fsession-support'