LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@kernel.crashing.org>
To: Michael Sokolov <msokolov@ivan.Harhan.ORG>
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: CONFIG_GENERIC_PPC32
Date: Thu, 11 Apr 2002 08:24:58 -0700	[thread overview]
Message-ID: <20020411152458.GB15663@opus.bloom.county> (raw)
In-Reply-To: <0204110346.AA27237@ivan.Harhan.ORG>


On Wed, Apr 10, 2002 at 08:46:33PM -0700, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > Not quite.  DINK32/PPCBug/PMON/Force firmware (pcore?)/other commerical
> > firmwares which know 0 about Linux and won't ever quite probably is the
> > 'fly in the ointment'.
>
> I disagree. StarMON also knows 0 about Linux, which is how it should be as

Fine, StarMON + ppc-boot-linux.  But this really is splitting hairs.
The problem is firmware (or firmware writers) who know about Linux and
want to boot linux from their firmware (in your case, you wrote another
program, ppc-boot-linux, to know about the linux bits) and those who
don't.

> If I've been able to make Linux/PPC boot so nicely and have one generic
> configuration with my very very no-frills firmware, I claim you've gotta be
> able to do that with other people's modern full-of-frills firmware.

What's the incentive to do something like that when it all just works
tho?

> Or you could make the zImage wrapper grep the ROM region for various strings to
> identify what board/firmware it's running on. Right now you could take your
> "simple" wrappers for different boards and merge them into one that will first
> select the board and then proceed as it does now. The only problem would be
> with board identification. Now my idea of having a board ID somewhere in the
> ROM is nothing earth-shattering, DEC has done 16 years before me, and I think
> just about company does that.

One of the real beautiful parts of the 'simple' wrapper (I wish someone
else would have came up w/ another name for it when I asked, anyhow...)
is that it doesn't care about firmware what so ever.

Hell, it could probably run on StarMON (I suspect it'd just need to have
the ELF header stripped off and loaded into a 'good' location). :)

> some convention across its boards, there nothing across *all* boards. That's
> where the grep idea comes in. I can bet that a board made by Mumbletech model
> ABC will have strings "Mumbletech" and "ABC" somewhere in the ROM. Just look
> for those magic strings and you'll know what you are running on. Past this step
> for everything else there already is a solution.

Which means for N boards (or N board mfrs) you have to add in another
bit to a file, or come up w/ some nice magic to compile all
xxx_detect.c files or something like that.

'simple' doesn't want to know about the firmware, 'simple' wants to get
Linux up and running. :)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2002-04-11 15:24 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-06 20:23 CONFIG_GENERIC_PPC32 Michael Sokolov
2002-04-06 22:06 ` CONFIG_GENERIC_PPC32 Benjamin Herrenschmidt
2002-04-08 15:48 ` CONFIG_GENERIC_PPC32 Tom Rini
2002-04-08 16:03   ` CONFIG_GENERIC_PPC32 Gabriel Paubert
2002-04-08 16:24     ` CONFIG_GENERIC_PPC32 Tom Rini
2002-04-08 16:48       ` CONFIG_GENERIC_PPC32 Gabriel Paubert
2002-04-08 17:23         ` CONFIG_GENERIC_PPC32 Matt Porter
2002-04-08 17:37           ` CONFIG_GENERIC_PPC32 Gabriel Paubert
2002-04-08 18:07             ` CONFIG_GENERIC_PPC32 Matt Porter
2002-04-08 18:41               ` CONFIG_GENERIC_PPC32 Gabriel Paubert
2002-04-08 18:18   ` CONFIG_GENERIC_PPC32 Michael Sokolov
2002-04-08 18:53     ` CONFIG_GENERIC_PPC32 Matt Porter
2002-04-09 14:59     ` CONFIG_GENERIC_PPC32 Tom Rini
2002-04-09 19:52       ` CONFIG_GENERIC_PPC32 Michael Sokolov
2002-04-10  8:27         ` CONFIG_GENERIC_PPC32 Geert Uytterhoeven
2002-04-10 15:17           ` CONFIG_GENERIC_PPC32 Tom Rini
2002-04-11  3:50             ` CONFIG_GENERIC_PPC32 Michael Sokolov
2002-04-11 15:27               ` CONFIG_GENERIC_PPC32 Tom Rini
2002-04-10 10:28         ` Bootloader (Re: CONFIG_GENERIC_PPC32) benh
2002-04-10 13:30           ` Dan Malek
2002-04-10 15:16         ` CONFIG_GENERIC_PPC32 Tom Rini
2002-04-11  3:46           ` CONFIG_GENERIC_PPC32 Michael Sokolov
2002-04-11 15:24             ` Tom Rini [this message]
2002-04-11 16:16               ` CONFIG_GENERIC_PPC32 Michael Sokolov
2002-04-11 15:51                 ` CONFIG_GENERIC_PPC32 Mark A. Greer
2002-04-11 16:59                 ` CONFIG_GENERIC_PPC32 Tom Rini
2002-04-11 17:25                   ` CONFIG_GENERIC_PPC32 Michael Sokolov
2002-04-11 17:42                     ` CONFIG_GENERIC_PPC32 Tom Rini
2002-04-11 17:03                 ` The very common kernel, again... (Was: Re: CONFIG_GENERIC_PPC32) Tom Rini
2002-04-11 17:31                   ` The very common kernel, again Michael Sokolov
2002-04-11 17:46                     ` Tom Rini
2002-04-10 19:08         ` CONFIG_GENERIC_PPC32 Tom Rini
2002-04-10 13:20 ` CONFIG_GENERIC_PPC32 Paul Mackerras
2002-04-10 15:23   ` CONFIG_GENERIC_PPC32 benh
  -- strict thread matches above, loose matches on Subject: below --
2002-04-06 21:39 CONFIG_GENERIC_PPC32 Michael Sokolov
2002-04-06 22:52 ` CONFIG_GENERIC_PPC32 Benjamin Herrenschmidt
2002-04-07  8:34   ` CONFIG_GENERIC_PPC32 Geert Uytterhoeven
2002-04-07  9:04     ` CONFIG_GENERIC_PPC32 Benjamin Herrenschmidt
2002-04-09  8:12     ` CONFIG_GENERIC_PPC32 Michael Schmitz
2002-04-06 22:17 CONFIG_GENERIC_PPC32 Michael Sokolov
2002-04-06 23:29 ` CONFIG_GENERIC_PPC32 Benjamin Herrenschmidt
2002-04-11  3:08 CONFIG_GENERIC_PPC32 Michael Sokolov
2002-04-10 23:42 ` CONFIG_GENERIC_PPC32 Benjamin Herrenschmidt
2002-04-11 17:51 ` CONFIG_GENERIC_PPC32 Mark A. Greer
2002-04-12 12:57 ` CONFIG_GENERIC_PPC32 Paul Mackerras
2002-04-12 11:57   ` CONFIG_GENERIC_PPC32 benh
2002-04-12 19:02   ` CONFIG_GENERIC_PPC32 Michael Sokolov
2002-04-15 15:46     ` CONFIG_GENERIC_PPC32 Tom Rini
2002-04-15 18:08       ` CONFIG_GENERIC_PPC32 Michael Sokolov
2002-04-15 19:54         ` CONFIG_GENERIC_PPC32 Tom Rini
2002-04-11 15:40 CONFIG_GENERIC_PPC32 Michael Sokolov
2002-04-11 15:49 ` CONFIG_GENERIC_PPC32 Geert Uytterhoeven
2002-04-11 16:13 ` CONFIG_GENERIC_PPC32 benh
2002-04-11 16:24 CONFIG_GENERIC_PPC32 Michael Sokolov
2002-04-11 16:50 ` CONFIG_GENERIC_PPC32 benh
2002-04-11 17:15 CONFIG_GENERIC_PPC32 Michael Sokolov
2002-04-11 20:51 CONFIG_GENERIC_PPC32 Michael Sokolov
2002-04-11 19:10 ` CONFIG_GENERIC_PPC32 Mark A. Greer

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=20020411152458.GB15663@opus.bloom.county \
    --to=trini@kernel.crashing.org \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=msokolov@ivan.Harhan.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox