07:53 <Tyaku> Hello, Did someone know if there is a documentation about "variables suffix" that permits to change permissions in U-Boot ? Because we want to block the access to some variables, we don't know the best way. I have tested the callbacks, it works but I would like to test the other methods jsut to compare. I found in U-Boot code that they put things like ":mo" at the end of some variables and I think it is

07:53 <Tyaku> used as "permission configurator".

09:24 <marex> Tyaku: README , line 1200 , CFG_ENV_FLAGS_LIST_STATIC

14:12 <Tyaku> I see the env flags, and try it with ethaddr variable. But there is something strange: If I modify from uboot ethaddr: yes i have a message that indicate it can only be written one time. But from fw_setenv: it's open-bar AND we can set anything, even something that doesn't looks like a mac address, (the format verification is not applied)

14:13 <Tyaku> Is there any setting / compilation flah to use, to make sure fw_setenv use the callbacks ?

14:25 <xypron> Tyaku: /README also has a section "Vendor Parameter Protection"

14:27 <Tyaku> Yes I found it after marex response, but

14:27 <Tyaku> I has effect on U-Boot CLI, but not on fw_setenv command.

14:30 <Tyaku> It*

14:37 <Tartarus> It's quite likely a gap in the implementation

14:54 <Tyaku> Tartarus: Is it wanted ?

14:54 <Tartarus> Yes, it would be appreciated

14:55 <Tartarus> And updating the docs from the top-level README to rst and something under doc/ so that it's more visible too

14:55 <Tartarus> If you have time and are so inclined

14:56 <Tyaku> I'm not sure to understand: Is it normal/wanted that the flags to configure access permission to variables are only read from U-Boot CLI and not from fw_setenv ? It's also possible that there is a bug in my side, that's why I ask

15:00 <Tartarus> This particular feature is not well used, so you likely need to dig in to the fw_setenv code to config what is/isn't doing what you expect

16:05 <kcxt> Tartarus: sjg1: are there bindings/schema for binmans devicetree?

16:07 <kcxt> hm, found the generated docs from binman/etype, i guess that's all

19:12 <marex> Tartarus: well that is plain wrong, and that particular feature is actually extensively used :)

19:12 <Tartarus> Ah, Ok, thanks :)

19:13 <marex> Tyaku: do you have WRITEABLE ENV enabled too ?

19:13 <marex> if so, U-Boot only imports subset of env vars from external env, everything else comes from built in env

19:23 <kcxt> phew, started to get my head around binman... the main problem is that it's literally impossible to know if we should build an mbn or not without the user telling us at build time (e.g. with a make flag)

19:23 <kcxt> one idea is to create the u-boot.mbn file but have it contain some text explaining that the board is unsupported and how to add it if they wish

19:24 <kcxt> for many devices (e.g. phones) the mbn stuff is totally unused since we build an Android boot image instead

19:26 <kcxt> my wip stuff is here if anyone wants to take a look, i also need to figure out how to get that qcom-binman.dts file to build, since we use OF_UPSTREAM the arch/arm/dts dir is totally ignored

19:26 <kcxt> https://git.codelinaro.org/linaro/qcomlt/u-boot/-/commit/c52ebf6ca4823b4de68ecff955ef1803cda6fc12

19:27 <Tartarus> kcxt: re dts + OF_UPSTREAM that should be solvable, see TI K3 (am6* j7*, et al) ?

19:35 <kcxt> thx i'll take a look