From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mitch Bradley Subject: Re: Pinmux with device tree Date: Thu, 19 May 2011 16:31:00 -1000 Message-ID: <4DD5D264.90205@firmworks.com> References: <4DD41F02.4050108@firmworks.com> <20110519171029.GH3085@ponder.secretlab.ca> <4DD576BD.7090307@firmworks.com> <4DD5839C.2020809@firmworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org To: Nicolas Pitre Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org List-Id: devicetree@vger.kernel.org On 5/19/2011 4:23 PM, Nicolas Pitre wrote: > On Thu, 19 May 2011, Mitch Bradley wrote: > >> On 5/19/2011 10:36 AM, Nicolas Pitre wrote: >>> On Thu, 19 May 2011, Mitch Bradley wrote: >>> >>>> So, in my world, space is always an issue. >>> >>> I'm guessing that in such a scenario you have the kernel stored >>> somewhere else, right? You therefore simply have to store the FDT data >>> along with the kernel in that other location, and have your boot >>> firmware load an additional and relatively small file. >> >> There is no stored FDT. The firmware generates the device tree dynamically >> from a combination of static information and dynamic probing. >> >>> >>> It is very important that the DT data be updateable independently from >>> the firmware, just like the kernel is. Ideally, the DT would indeed be >>> exported by the firmware, but that works only in theory. In practice it >>> _will_ contain bugs that might be visible only after kernel development >>> has progressed, and therefore it is primordial to be able to update it >>> easily. Hence in practice it is best if it is not exported/generated by >>> the firmware directly. >> >> >> In our world it works in practice. We control the hardware, firmware, and OS >> releases. In many cases, a firmware update is less expensive than an OS >> release by several orders of magnitude. > > I don't think this can be said for ARM in general though. > This is where all the recent surge of activity around DT comes from. Agreed, but I was pointing out that not everybody has space to burn, so I hope that the ultimate solution doesn't treat space as free. > > > Nicolas >