lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <trinity-78347fc1-fe38-4035-a681-ff72fd4411cf-1732719843709@trinity-msg-rest-gmx-gmx-live-5cd5dd5458-pz7pz>
Date: Wed, 27 Nov 2024 15:04:03 +0000
From: frank-w@...lic-files.de
To: angelogioacchino.delregno@...labora.com, robh+dt@...nel.org,
 matthias.bgg@...il.com
Cc: krzk+dt@...nel.org, conor+dt@...nel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org,
 devicetree@...r.kernel.org, daniel@...rotopia.org, linux@...web.de,
 leith@...e.nz
Subject: Aw: Re: Aw: Re: Aw: [PATCH v3 1/2] arm64: dts: mt7986: add dtbs
 with applied overlays for bpi-r3

Hi,

&gt; Gesendet: Mittwoch, 27. November 2024 um 14:23
&gt; Von: "AngeloGioacchino Del Regno" <angelogioacchino.delregno@...labora.com>
&gt; An: frank-w@...lic-files.de, robh+dt@...nel.org, matthias.bgg@...il.com
&gt; CC: krzk+dt@...nel.org, conor+dt@...nel.org, linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org, devicetree@...r.kernel.org, daniel@...rotopia.org, linux@...web.de, leith@...e.nz
&gt; Betreff: Re: Aw: Re: Aw: [PATCH v3 1/2] arm64: dts: mt7986: add dtbs with applied overlays for bpi-r3
&gt;
&gt; Il 06/11/24 19:49, frank-w@...lic-files.de ha scritto:
&gt; &gt; Hi
&gt; &gt;
&gt; &gt; any new state on this??
&gt; &gt;
&gt; &gt; https://patchwork.kernel.org/project/linux-mediatek/patch/20240608080530.9436-2-linux@fw-web.de/
&gt; &gt;
&gt; &gt; regards Frank
&gt;
&gt; I had a look at this one - and this is the situation:
&gt;
&gt;   1. Your bootloader supports loading DTBO, so you can indeed use DTBOs
&gt;   2. Validation of the DTSO can still be done during kernel build without adding
&gt;      all of those possible X+Y+Z pre-joined DTBs
&gt;   3. What if your hardware had more than 20 possible configurations?
&gt;      Would you write 20 different Makefile entries? "sd+nand+nor",
&gt;      "sd+nand-withoutnor", "emmc+nand+nor", "emmc+nand-withoutnor",
&gt;      "emmc+sd+nor", "emmc+sd-withoutnor", "ufs+emmc", "ufs+emmc+sd",
&gt;      "ufs+sd+nor", "ufs+emmc-withoutnor", "ufs+sd-withoutnor", ......
&gt;
&gt; Looks messy and unfeasible.

right, if we add all possible combinations...that was my point on first round of this patch after robs suggestion. So you have same opinion :)

imho rob is afraid that dtso are not checked during build-time and this is noticed at runtime where it can be checked earlier.

maybe we can find a way in the middle (i tried it in this patch doing the full dtb only for the core functionality, not adding e.g. sata).

&gt; However, this is not a *global* no: I'm happy that your bootloader does support
&gt; loading DTBOs and, as far as I remember, even uses straps to vary the DTB(o) to
&gt; actually load - which is something proper and great... so it's a *no* for you,
&gt; but more than just a no, this is "why are you treating your proper bootflow
&gt; like it was a broken one?!?!" :-)

i still use the dtbos in a fit i created and build off-tree where i add the possible combinations like here as config options and add additional configs for e.g. sata to be combined by bootloader.

currently we use a "full dtb" in uboot where we can probe for emmc vs. sdcard (mmc partprobe) and the spi-device (nand/nor via "sf probe"). We can read the bootstrap pins defining the device from which board was booted, but this is only the half way for hw-detection.

&gt; If anyone finds themselves in a situation in which there's no way to update a
&gt; bootloader (and that unfortunately happens more often than anyone would like
&gt; to see...) and in which the only way to apply DTBOs is to pre-overlay them
&gt; during the kernel build, then that's fine and I would (if nice and clean)
&gt; accept that.
&gt;
&gt; But again, you're not in this kind of situation - and you're lucky that you're
&gt; dealing with a fully open device with a proper bootloader and bootflow: don't
&gt; ruin it like that!

the patch does not break ability to use the dtbos, it only adds second way to create fuill dtbs from them, that of course should not be done extensively....4 full dtbs are enough in my PoV and should not be exceeded.

&gt; Instead, if necessary, update the userspace tools that you're using to deal with
&gt; multiple DTBOs during system upgrades: that's the right thing to do at this point.

i simply replace/add the fit image which contains base dtb and all dtbo with config options ;)

&gt; Cheers,
&gt; Angelo

so i would resend the sata-patch alone when rc1 is out, right?

regards Frank</angelogioacchino.delregno@...labora.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ