From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chee, Tien Fong Date: Mon, 11 Jun 2018 13:55:12 +0000 Subject: [U-Boot] [PATCH v2 3/3] common: Generic loader for file system In-Reply-To: <0ac076b9-9ca7-1e5c-09eb-7f986d1ea8f2@denx.de> References: <1527138244-16058-1-git-send-email-tien.fong.chee@intel.com> <1527138244-16058-4-git-send-email-tien.fong.chee@intel.com> <1528344245.10642.1.camel@intel.com> <1528360598.10642.8.camel@intel.com> <1528364720.10642.15.camel@intel.com> <1528366318.10642.19.camel@intel.com> <0115d042-8f5d-45ff-5605-7343b051db12@denx.de> <1528693318.9950.5.camel@intel.com> <1528717995.9614.6.camel@intel.com> <81b8f03b-a5d3-4883-a3bc-f1f010f187d3@denx.de> <1528720926.9614.10.camel@intel.com> <0ac076b9-9ca7-1e5c-09eb-7f986d1ea8f2@denx.de> Message-ID: <1528725312.9614.17.camel@intel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de On Mon, 2018-06-11 at 15:38 +0200, Marek Vasut wrote: > On 06/11/2018 02:42 PM, Chee, Tien Fong wrote: > > > > On Mon, 2018-06-11 at 13:55 +0200, Marek Vasut wrote: > > > > > > On 06/11/2018 01:53 PM, Chee, Tien Fong wrote: > > > > > > > > > > > > On Mon, 2018-06-11 at 11:39 +0200, Marek Vasut wrote: > > > > > > > > > > > > > > > On 06/11/2018 07:01 AM, Chee, Tien Fong wrote: > > > > > [...] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is a configuration. You do not need (new) a DT > > > > > > > > > compatible > > > > > > > > > for > > > > > > > > > that. > > > > > > > > > So why is the DT compatible even needed in the FW > > > > > > > > > loader > > > > > > > > > at > > > > > > > > > all ? > > > > > > > > > > > > > > > > > I thought DT compatible is used by driver to find the > > > > > > > > fs_loader > > > > > > > > node in > > > > > > > > DTS. May be i am wrong. > > > > > > > There should be no FW loader in the DTS. Why would there > > > > > > > be > > > > > > > one ? > > > > > > > > > > > > >  I added DTS support for user to define storage type and > > > > > > default > > > > > > partition. So you want me to remove the DTS? > > > > > > Removing the DTS, then user can only set storage type and > > > > > > partition > > > > > > through dev instance. So, this design OK for you? > > > > > How does Linux do it ? > > > > > > > > > Linux firmware loading method is different with this > > > > Linux loading firmware with > > > > 1. Firmware search paths - which is hardcoded in root file > > > > system > > > > 2. Built-in firmware - part of kernel binaries > > > > > > > > This patch loading firmware with > > > > 1. Storage type and partition specified in DTS, but storage > > > > type > > > > can > > > > be overridden dev instance and partition through U-boot > > > > variable > > > > environment. > > > > > > > > Or: > > > > > > > > 2. Storage type can be set through dev instance, and partition > > > > through > > > > U-boot variable environment. No DTS is required. > > > And why can we not do as Linux does ? > > > > > Because we don't have root file system, but i have mimicked the > > search > > path in our variable environment, but with both storage type and > > partition. > OK, so user can configure environment variable to inform U-Boot where > to > look for firmware, good (although, this probably fails in early env, > dunno of that's a problem). > Without DTS, then you need to configure env variable, so that SPL and U-boot only know what storage type and partiton to look for firmware. > But why do we need the DT part of things ? I don't think we do need > it > at all. > Leverage the flexibility and benefits of the DT such as changing both storage type and partitions without changing the codes.