From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by ozlabs.org (Postfix) with ESMTP id 41E882BDB5 for ; Fri, 1 Oct 2004 09:53:23 +1000 (EST) Received: by mproxy.gmail.com with SMTP id 76so4590697rnk for ; Thu, 30 Sep 2004 16:53:17 -0700 (PDT) Message-ID: <35fb2e59040930165327f2dd59@mail.gmail.com> Date: Fri, 1 Oct 2004 00:53:17 +0100 From: Jon Masters To: Benjamin Herrenschmidt In-Reply-To: <1096586504.3124.20.camel@gaston> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII References: <35fb2e59040930160254f00fce@mail.gmail.com> <1096586504.3124.20.camel@gaston> Cc: linuxppc-embedded@ozlabs.org Subject: Re: bi_recs Reply-To: jonathan@jonmasters.org List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, 01 Oct 2004 09:21:50 +1000, Benjamin Herrenschmidt wrote: > > > On Fri, 2004-10-01 at 09:02, Jon Masters wrote: > > Hi all, > > > > Would someone (Tom, Matt, Cort, Paul or Dan?) please tell me what the > > status is of bi_recs? > > > > I first discussed the idea of this at the FOSDEM and not much has come > > of it - but I would be happy to work on getting flexible system > > configuration to the kernel on ppc without OF as this will then allow > > a stock kernel without any need for builtin notions of memory layout. > > Am I missing something that's already been implemented? > > bi_recs were supposed to evolve in that direction but that never happened. Right. That needs fixing. > On the other hand, on ppc64, I took a different approach and decided that > an OF tree would be mandatory, but you don't need OF to have one. I thought about this too when Jonathan Corbett was talking about sysfs ages ago. I thought I might have come up with something - but as usual it seems that you got there first ;-). > I rewrote prom_init (the interface to OF) (I know the ppc32 code but have not looked at the ppc64 code - in fact tonight on the train I was looking at a FIXME in the ftr_fixup code and a few other bits I plan to look at). > so that instead of tapping kenrel > globals directly and generating struct device_node, it generates a flattened > version of the device-tree and passes that to the kernel. That means that > if you can provide a "blob" with such a tree in it, you can bypass prom_init. I thought about that as an approach. Great - you do it already how I thought. > The tree doesn't need to be complete (like it doesn't need to contain all > the PCI devices) and generating such a flattened tree from userland, from > a text file for example, should be easy, or generate one from whatever > infos your bootloader provides. That's what I thought. I'm motivated by horrible *ugly* broken Xilinx hacks (EDK MHS) which try to bastardise a HAL on to Linux that really doesn't want to be there - they should have instead been able to pass their autogenerated output to the kernel at boot time rather than have it compiled in as they do now. > But on the other hand, I've given up a long time ago trying to enforce any > kind of sane model on ppc32 because the embedded folks only care about having > a quick ugly broken hack to work with their board, thus the explosion of > various incompatible boot_info structures that we have nowadays. Yes indeed. It's ugly and needs fixing so I'll take a look at it - I just don't want to do this if everyone here already knows of a better solution which will work. Then Xilinx et al can generate memory maps and we can head towards having a single kernel binary bootable on multiple different ppc boards. Cheers, Jon.