From mboxrd@z Thu Jan 1 00:00:00 1970 From: dannenberg at ti.com Date: Tue, 21 May 2019 13:53:54 -0500 Subject: [U-Boot] [RFC 09/11] armv7R: dts: k3: am654: Update for loading SYSFW from MMC In-Reply-To: <1558417218.10391.7.camel@intel.com> References: <20190516205454.22150-1-dannenberg@ti.com> <20190516205454.22150-10-dannenberg@ti.com> <1558417218.10391.7.camel@intel.com> Message-ID: <20190521185354.d4fmfhtehl2xcj3s@jiji> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: u-boot@lists.denx.de Hi TF, On Tue, May 21, 2019 at 05:40:19AM +0000, Chee, Tien Fong wrote: > > + fs_loader0: fs_loader at 0 { > > + u-boot,dm-pre-reloc; > > + compatible =3D "u-boot,fs-loader"; >=20 > Why not using=C2=A0phandlepart =3D <&mmc 1>, this would help to avoid mmc= init > duplication in a few places such as patch [05/11]. >=20 See comment on earlier patch, this path was chosen to allow for flexibility during runtime. When using FS loader as you intended it to get used it works very well (we are actually using it for other purposes on another device). Hence my argument that the approach I chose with the original [1] SYSFW loader series of opening up the SPL loader framework in a "lean & mean" fashion and the FS loader driver as it is today are really things that are complementary and can co-exist when one starts looking under the hood. -- Andreas Dannenberg Texas Instruments Inc [1] https://lists.denx.de/pipermail/u-boot/2019-May/thread.html#368461