All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: jonathan@jonmasters.org
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: bi_recs
Date: Fri, 01 Oct 2004 09:21:50 +1000	[thread overview]
Message-ID: <1096586504.3124.20.camel@gaston> (raw)
In-Reply-To: <35fb2e59040930160254f00fce@mail.gmail.com>

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.

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 rewrote prom_init (the interface to OF) 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.

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.

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.

Ben.

  reply	other threads:[~2004-09-30 23:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-30 23:02 bi_recs Jon Masters
2004-09-30 23:21 ` Benjamin Herrenschmidt [this message]
2004-09-30 23:53   ` bi_recs Jon Masters
2004-10-01  3:11     ` bi_recs Kumar Gala
2004-10-01  3:40       ` bi_recs Benjamin Herrenschmidt
2004-10-01 11:14         ` bi_recs Jon Masters
2004-10-01 14:53           ` [PATCH] for linuxppc-2.4 tree: adds Memec 2VP7 / 2VP4 board support Andrei Konovalov
2004-10-01 21:54           ` bi_recs Jon Masters
2004-10-02  4:35             ` bi_recs Benjamin Herrenschmidt
2004-10-02 12:59               ` bi_recs Jon Masters
2004-10-01 22:06       ` bi_recs Tom Rini
2004-10-04  6:07         ` bi_recs Pantelis Antoniou
2004-10-04 12:09           ` bi_recs Mark Chambers
2004-10-04 12:45           ` bi_recs Jon Masters
2004-10-04 16:43             ` bi_recs Dan Malek
2004-10-04 21:53               ` bi_recs Tom Rini
2004-10-04 20:20             ` bi_recs Wolfgang Denk
2004-10-04 14:29           ` bi_recs Tom Rini
2004-10-04 14:41             ` bi_recs Matt Porter
2004-10-04 15:00               ` bi_recs Kumar Gala
2004-10-04 15:06               ` bi_recs Jon Masters
2004-10-04 15:47                 ` bi_recs Kumar Gala
2004-10-04 20:18           ` bi_recs Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1096586504.3124.20.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=jonathan@jonmasters.org \
    --cc=linuxppc-embedded@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.