How to get firmware-imx for imx8mm evk into sdcard image? I'm getting firmware loading errors for sdma-imx7d.bin etc.


Andrey Zhizhikin
 

On Tue, Oct 6, 2020 at 10:44 PM Brian Hutchinson <b.hutchman@...> wrote:

On Tue, Oct 6, 2020 at 01:22 PM, Andrey Zhizhikin wrote:

Hello Brian,

On Tue, Oct 6, 2020 at 9:51 PM Brian Hutchinson <b.hutchman@...> wrote:

... what "distro" 'should' I be using since I have a custom board that's based on imx8mm evk but I don't necessarily want/need wifi, bluetooth, video, touchscreen etc.???

I suggest you go with your own distro then, as you can leverage the
DISTRO_FEATURES in it yourself. You can either take any of 'fsl-'
prefixed distros over 'poky' if you need some NXP proprietary
components (e.g. VPU, GPU, etc), or take any of 'fslc-' prefixed ones
if you want to stay with mainline. Please note - I do not say that
'poky' would not work here! :) It is just a reference distro from
Yocto Project, which targets qemu on the first place, but also works
well for real HW.

This is the way we build our distro (derived from 'fsl-wayland'), and
so far it has proven to be working quite well. I also do sanity build
and run the 'fsl-wayland' off the master on imx8mmevk to make sure
there are no regressions.

When I did NXP released builds I would use fsl-wayland distro but if memory serves me right a core-image-minimal would not boot. Only core-image-base images did and they were quite large.

I do need to create my own distro but kind of would like to start from core-image-minimal and build up rather than take something like fsl-wayland and try to figure out what I don't need. Being new to NXP family this approach "feels" more logical.
I think you're mixing up 2 conceptual points here: distro vs image.
You can have a wayland distro, but only include a handful of packages
and features of it into the image. Distro does not define the content
of the image, image recipe does.

Section 4.3.2. of Yocto Overview Manual gives a very nice overview of
those concepts:
https://www.yoctoproject.org/docs/3.1.2/overview-manual/overview-manual.html#metadata-machine-configuration-and-policy-configuration


Is poky what's causing my pain?

You can see what distro features you have included when you do
'bitbake -e' and search for DISTRO_FEATURES. If you have (and
according to what you say - you do :) ) some pieces you do not need -
you can always either not include them in your custom distro, or use
DISTRO_FEATURES_remove = "<unneeded list>".

I've been doing TI based builds forever and recently switched over to NXP based products so still learning the lay of the land. I finally discovered I don't think I want to be building based off NXP releases from codeaurora and that Freescale is the better base for our products but not 100% clear what distro's are available and which ones I should focus on.

Those distros are located in a meta-freescale-distro layer, you can
peek there to see what's available.

I'll look. Thanks

Regards,

Brian


--
Regards,
Andrey.


Andrey Zhizhikin
 

Hello Brian,

On Tue, Oct 6, 2020 at 10:44 PM Brian Hutchinson <b.hutchman@...> wrote:

On Tue, Oct 6, 2020 at 01:22 PM, Andrey Zhizhikin wrote:

Hello Brian,

On Tue, Oct 6, 2020 at 9:51 PM Brian Hutchinson <b.hutchman@...> wrote:

... what "distro" 'should' I be using since I have a custom board that's based on imx8mm evk but I don't necessarily want/need wifi, bluetooth, video, touchscreen etc.???

I suggest you go with your own distro then, as you can leverage the
DISTRO_FEATURES in it yourself. You can either take any of 'fsl-'
prefixed distros over 'poky' if you need some NXP proprietary
components (e.g. VPU, GPU, etc), or take any of 'fslc-' prefixed ones
if you want to stay with mainline. Please note - I do not say that
'poky' would not work here! :) It is just a reference distro from
Yocto Project, which targets qemu on the first place, but also works
well for real HW.

This is the way we build our distro (derived from 'fsl-wayland'), and
so far it has proven to be working quite well. I also do sanity build
and run the 'fsl-wayland' off the master on imx8mmevk to make sure
there are no regressions.

When I did NXP released builds I would use fsl-wayland distro but if memory serves me right a core-image-minimal would not boot. Only core-image-base images did and they were quite large.
I just did a following build:
$ MACHINE=imx8mmevk DISTRO=fsl-wayland bitbake core-image-minimal

Image produced boots fine on i.MX8M Mini EVK.

Runtime device info:
# cat /etc/os-release
ID=fsl-wayland
NAME="FSL Wayland"
VERSION="3.2-snapshot-20201008 (master)"
VERSION_ID=3.2-snapshot-20201008
PRETTY_NAME="FSL Wayland 3.2-snapshot-20201008 (master)"

# uname -a
Linux imx8mmevk 5.4.24+gbabac008e5cf #1 SMP PREEMPT Sat May 30
07:25:46 UTC 2020 aarch64 GNU/Linux

Please note: with this configuration you would get a kernel from NXP
(versioned 5.4.24). If you would like to utilize the NXP kernel with
latest stable patch level, you should switch
PREFERRED_PROVIDER_virtual/kernel_mx8mm = "linux-imx" to
PREFERRED_PROVIDER_virtual/kernel_mx8mm = "linux-imx-fslc"


.
I do need to create my own distro but kind of would like to start from core-image-minimal and build up rather than take something like fsl-wayland and try to figure out what I don't need. Being new to NXP family this approach "feels" more logical.

Is poky what's causing my pain?

You can see what distro features you have included when you do
'bitbake -e' and search for DISTRO_FEATURES. If you have (and
according to what you say - you do :) ) some pieces you do not need -
you can always either not include them in your custom distro, or use
DISTRO_FEATURES_remove = "<unneeded list>".

I've been doing TI based builds forever and recently switched over to NXP based products so still learning the lay of the land. I finally discovered I don't think I want to be building based off NXP releases from codeaurora and that Freescale is the better base for our products but not 100% clear what distro's are available and which ones I should focus on.

Those distros are located in a meta-freescale-distro layer, you can
peek there to see what's available.

I'll look. Thanks

Regards,

Brian


--
Regards,
Andrey.


Otavio Salvador
 

Hello all,

Em qui., 8 de out. de 2020 às 06:10, Andrey Zhizhikin
<andrey.z@...> escreveu:
Please note: with this configuration you would get a kernel from NXP
(versioned 5.4.24). If you would like to utilize the NXP kernel with
latest stable patch level, you should switch
PREFERRED_PROVIDER_virtual/kernel_mx8mm = "linux-imx" to
PREFERRED_PROVIDER_virtual/kernel_mx8mm = "linux-imx-fslc"
For all i.MX8 the fslc distributions use the NXP BSP by default so
using 'fslc-wayland' should work just fine.

...
You can see what distro features you have included when you do
'bitbake -e' and search for DISTRO_FEATURES. If you have (and
according to what you say - you do :) ) some pieces you do not need -
you can always either not include them in your custom distro, or use
DISTRO_FEATURES_remove = "<unneeded list>".

I've been doing TI based builds forever and recently switched over to NXP based products so still learning the lay of the land. I finally discovered I don't think I want to be building based off NXP releases from codeaurora and that Freescale is the better base for our products but not 100% clear what distro's are available and which ones I should focus on.

Those distros are located in a meta-freescale-distro layer, you can
peek there to see what's available.

I'll look. Thanks
For products we, at O.S. Systems, have been using our OEL[1]
distribution as a baseline where we create the product specific one.

1. https://github.com/OSSystemsEmbeddedLinux/ossystems-embedded-linux-platform

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750


Brian Hutchinson
 



On Wed, Oct 7, 2020 at 5:49 AM Andrey Zhizhikin <andrey.z@...> wrote:
Hello Brian,


Well, this is I guess an expected behavior. firmware packages are
listed in MACHINE_EXTRA_RRECOMMENDS, which is (according to Yocto
Reference manual, link
https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-MACHINE_EXTRA_RRECOMMENDS)
is only considered when packagegroup-base is installed in the image
and does not affect 'core-image-minimal' or 'core-image-full-cmdline'
images.

That is the reason that even if the package is added in the
imx-base.inc (like Otavio suggested in his patch) - you would not
receive it in core-image-minimal and you would have to install it
explicitly.

As for firmware packages themselves, I guess it should be changed from
MACHINE_EXTRA_RRECOMMENDS to MACHINE_EXTRA_RDEPENDS in order to bail
out at the build time rather than figure out that they are not present
on the device at boot time. But this is yet a separate point, which
actually would not solve your original issue as you either need an
image recipe which includes packagegroup-base or you have to
explicitly list them in IMAGE_INSTALL.

> I see there is a firmware-imx-8m package so maybe I should add it.

This package is actually empty, and only serves as a deploy target to
provide Cadence HDMI FW for imx-boot to build a boot container. Even
if you try to install it - you would not receive any FW files on the
target.



Hate to bring up an old thread again but I'm back to trying to pair down my image size and trying to use core-image-minimal and having issues with firmware-imx-sdma-imx7d & sdma-imx7d.bin

If I just build imx-sdma as a kernel module do I even need to worry about sdma-imx7d.bin being in the rootfs?

Regards,

Brian


Brian Hutchinson
 



On Thu, Jul 15, 2021 at 7:49 PM Brian Hutchinson via lists.yoctoproject.org <b.hutchman=gmail.com@...> wrote:


On Wed, Oct 7, 2020 at 5:49 AM Andrey Zhizhikin <andrey.z@...> wrote:
Hello Brian,


Well, this is I guess an expected behavior. firmware packages are
listed in MACHINE_EXTRA_RRECOMMENDS, which is (according to Yocto
Reference manual, link
https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-MACHINE_EXTRA_RRECOMMENDS)
is only considered when packagegroup-base is installed in the image
and does not affect 'core-image-minimal' or 'core-image-full-cmdline'
images.

That is the reason that even if the package is added in the
imx-base.inc (like Otavio suggested in his patch) - you would not
receive it in core-image-minimal and you would have to install it
explicitly.

As for firmware packages themselves, I guess it should be changed from
MACHINE_EXTRA_RRECOMMENDS to MACHINE_EXTRA_RDEPENDS in order to bail
out at the build time rather than figure out that they are not present
on the device at boot time. But this is yet a separate point, which
actually would not solve your original issue as you either need an
image recipe which includes packagegroup-base or you have to
explicitly list them in IMAGE_INSTALL.

> I see there is a firmware-imx-8m package so maybe I should add it.

This package is actually empty, and only serves as a deploy target to
provide Cadence HDMI FW for imx-boot to build a boot container. Even
if you try to install it - you would not receive any FW files on the
target.



Hate to bring up an old thread again but I'm back to trying to pair down my image size and trying to use core-image-minimal and having issues with firmware-imx-sdma-imx7d & sdma-imx7d.bin

If I just build imx-sdma as a kernel module do I even need to worry about sdma-imx7d.bin being in the rootfs?

Anyone? Anyone?
anyone-anyone.jpg