meta-rauc-nxp: added support for the FRDM i.MX 93 development board#184
meta-rauc-nxp: added support for the FRDM i.MX 93 development board#184ronpscg wants to merge 3 commits into
Conversation
ronpscg
changed the title
ronpscg
changed the title
0dccaa0 to
0acf228
Compare
Since the board layout is very similar to one of the products, the layer included, the changes here are very minimalistics: - Updated the README file - Added a recipe for building out of meta-imx which does no build off linux-yocto Signed-off-by: Ron Munitz <ron@thepscg.com>
b187dd0 to
cc8872b
Compare
|
@ronpscg thank you for your contribution with the new distro feature |
|
You're welcome, and most importantly - THANK YOU for putting the project
together (and helping so many people with your embedded wizardry).
Happy to clean it up further and/or separate the layer. My own feedback,
should anyone read is that I don't like the extra work I did/the overkill
to keep things in the same layer. It marks things longer, and not so
straightforward for newcomers, and I think it is somewhat ugly.
On the other hand copy pasting the previous solution is also not so amazing
and could lead to a potential explosion of layers.
The other layer was solid and works for the iMX93 and iMX95 (not tested -
happy to do it if NXP wants to ship their eval board, but I know it from
other projects I have been working on that it keeps the same 32MiB gap
before the first fat partition), and there are actually nicer ways to cover
up for it (dynamic layers, and another layer, or just another layer).
When I think about it there also must be an existing way to make a fat
partition for the boot image, if there isn't perhaps I'll make one for
upstream.
…On Sun, Mar 29, 2026 at 12:37 PM Leon Anavi ***@***.***> wrote:
*leon-anavi* left a comment (rauc/meta-rauc-community#184)
<#184?email_source=notifications&email_token=AU6YI5SD3HGLP7DXH4CDRVD4TD4FBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJUHE3TSMZSGQ3KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJNLQOJPWG33NNVSW45C7N5YGK3S7MNWGSY3L#issuecomment-4149793246>
@ronpscg <https://github.com/ronpscg> thank you for your contribution
with the new distro feature rauc-ab-bootrootfs. Thank you for taking the
time to describe how it works at README.frdm-imx93.rst. Let’s wait a few
days to gather any additional feedback from the community; if none comes
in, I’ll proceed with merging it.
—
Reply to this email directly, view it on GitHub
<#184?email_source=notifications&email_token=AU6YI5QREFEIF3SJL3LRWR34TD4FDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJUHE3TSMZSGQ3KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJNLQOJPWG33NNVSW45C7N5YGK3S7MNWGSY3L#issuecomment-4149793246>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AU6YI5XBK2UYZ2I6DUTPNGL4TD4FDAVCNFSM6AAAAACXC43ZTOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCNBZG44TGMRUGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Ron Munitz
Managing Director, PSCG Holdings LTD
Founder, CEO, Lead Trainer, The PSCG Premium Consulting
<https://www.thepscg.com>
Phone/Whatsapp: +972 54 5529466
|
|
@leon-anavi , what should we do? |
|
|
||
| # linux-imx from meta-imx/meta-imx-bsp does not inherit linux-yocto and does not implement the fragment mechanisms. | ||
| # So we just add it and call merge-config manually, should one choose to use the iMX downstream recipe (rather than the community fsl one) | ||
| do_configure:append() { |
There was a problem hiding this comment.
I guess there's no need to (re)generate the config right after the default do_configure already ran.
Why not just :prepend the merge_config.sh call?
There was a problem hiding this comment.
It is not guaranteed that the .config file exists on the very first time it is built.
We could alternatively just use the freescale community layer. The objective was to get things done in NXP's proposed way and minimally touch the current meta-rauc-community/meta-rauc-nxp project.
I don't mind rewriting into another layer basically, but I do want to keep compatible with meta-nxp and meta-imx-frdm as per the NXP bootstrapping instructions.
|
|
||
| **Note** The implementation could be more elegant if we just used another layer or did not bother about the one boot/2rootfs scheme that is in the overall meta-rauc-community repo. | ||
| However, to keep things simple for comparison, I made the extra effort to have the previous behavior (one boot, 2 rootfs partitions) the default one. | ||
| In the dual boot/rootfs solution (i.e. the ``rauc-ab-bootrootfs`` override), everything is identical except for the partition scheme with the following exceptions: |
There was a problem hiding this comment.
It really makes sense to elaborate on why you chose such a setup and how it is meant to work.
Typically, the bootloader is left out of the A/B setup because it is the instance that selects between A and B.
There was a problem hiding this comment.
OK: important: this is over complicated, pathwise, but I did want to keep things in the NXP project.
You are correct - typically the bootloader will NOT be done with script files, as it is in the other examples. They do not allow for an A/B switch.
A typical use case would be separating the boot materials from the rootfs, especially if the latter is to be encrypted in its entirety.
And then - there would not be a script at all in the fat partition, but rather either:
- A patch to the relevant include/configs/<...>.h and set the variables there
- A default environment file that would be used.
Then, all the RAUC choosing logic would be in the environment that is compiled into U-Boot, and if someone wants to add scripts to be loaded in addition to it - let them do so.
| @@ -0,0 +1,10 @@ | |||
| /dev/mmcblk0p1 | |||
There was a problem hiding this comment.
What's the purpose of this mount ignore list? Please add a comment.
There was a problem hiding this comment.
OK I will after redoing the rest - I guess the main question is if to separate.
The objective of the ignore list (I would generally ignore with a wildcard) is :
- To do the same as in the original project /meta-rauc-nxp
- To avoid the automatic mounting of the partitions by systemd. mmc1 - sdcard. mmc0 -emmc.
…rtitions via the rauc-ab-bootrootfs distro feature The code is written in a way that is completely backward compatible with the rootfs only solution. It would be more elegant to have it in another layer. Please read the extensively detailed README.frdm-imx93.rst file for more details. Signed-off-by: Ron Munitz <ron@thepscg.com>
cc8872b to
c7bcbe0
Compare
Signed-off-by: Ron Munitz <ron@thepscg.com>
6f5f077 to
3fe193e
Compare
3 participants
Since the board layout is very similar to one of the products, the layer included, the changes here are very minimalistics: