On Mon, 04 Oct 2004 09:07:20 +0300, Pantelis Antoniou <panto at intracom.gr> wrote:
> Allow me, to cut in and plug my own thing. Yeah cool. btw, I looked at the ppc64 stuff (having eventually realised I need to be using the bk tree for everything ppc64 rather than 2.6.8.1) and I see what benh is getting at now - so I am figuring out the best way to proceed on that front. None of my boards support 2.6 yet so I either fix that this week or get up and running with 2.4 first. Anyway, I'm working on it in my spare time. > If you follow the u-boot-users list, you'll know that some time > ago there was a similar discussion. I don't, but I will sign up to the list at some point. Currently I use my own firmware as I was too lazy to go figure out the ins and outs of uboot :-). > I just create an argv of all the environment variables of the firmware > and I pass the psysical address of that NULL terminated argv array > to the kernel command line like so... "u-boot-env=0x0f000f00". I think that's an approach which works up to a point. It's nice to have a hierachy of devices like with OF because then we can infer things like order of devices on a bus that need to be shutdown for a suspend. This can be done as a flat list but I the reason ben put me off my original idea of going with tagged records is that OF is clearly the better approach. > I have working patches for u-boot, the kernel parser, a kernel /proc > interface for accessing them and also some patches for busybox That's great. So seriously worth looking at then. > I know this is the Nth time this discussion is taking place bu IMO So we probably need to decide. I think Mark's XML idea also works, but I don't see anything wrong with a flattened OF type tree either since it's ASCII strings also, just layed out in a slightly more involved fashion than having a long list of parameters. I'm going to get this OF thing sorted anyway because it's worth having that option - but I'm indifferent towards what is ultimately decided (as long as something is agreed upon). If we went with a solution such as yours then I would prefer Mark's idea of a structured set of data. This way I can say which PCI bridge device X lives behind in a nicer fashion. Blah. Jon.
