On 9/4/21 6:09 PM, Tom Rini wrote:
On Sat, Sep 04, 2021 at 06:05:50PM +0200, Marek Vasut wrote:
On 9/4/21 5:17 PM, Tom Rini wrote:
On Sat, Sep 04, 2021 at 05:15:45PM +0200, Marek Vasut wrote:
On 9/4/21 4:10 PM, Tom Rini wrote: [...]
>>> At this point, I think you should rework things to stop making >>> CONFIG_LMB be optional, it should be a def_bool y. >> >> I disagree, see above. > > The only reason "tools-only_defconfig" builds a useless u-boot binary > today is in CI where it would be more work than it's worth to make CI > exclude that from the build list. But if you want to just do that > instead, I'll also accept adding -x tools-only to the azure/gitlab jobs > that build all other architectures, as tools-only is tested in its own > build job, for it's only valid build target.
The tools-only build is also used elsewhere, to build just that, tools.
I've repeatedly explained myself and what I'm looking for in v2 of this series. I will summarize one last time. The "tools-only_defconfig" is for tools, only. Building anything other than the "tools-only" target isn't useful. In U-Boot itself, LMB is required as that is how we prevent a number of CVEs from being trivial to exploit. v2 of this series needs to drop patches 1 and 2 of v1 of this series. It can further do any of:
- Nothing else.
- Add tools-only to the exclude list in the "build everything else" CI job.
- Make CONFIG_LMB be def_bool y.
If tools-only is for tools, only, then why should it enable LMB ? The tools are userspace tools, they do not need LMB, and so LMB can be disabled.
This is the part which is unclear to me.
I don't know why it's unclear to you at this point, sorry.
Well why exactly does a userspace program require LMB enabled ? What does LMB protect in there ? obviously not U-Boot.
I feel like you've lost the thread.
Can you please answer my questions above ?
This is exactly what patch 1/14 is about -- disable LMB for tools build, because it is useless for tools build.