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: Tue, 9 Apr 2002 07:59:29 -0700 [thread overview]
Message-ID: <20020409145929.GC710@opus.bloom.county> (raw)
In-Reply-To: <0204081818.AA21305@ivan.Harhan.ORG>
On Mon, Apr 08, 2002 at 11:18:43AM -0700, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel•crashing.org> wrote:
>
> > > The platforms I've initially included in this new model are Adirondack,
> > > EV-64260A, and K2.
> >
> > Just checking, but right now these are only supported with StarMON and
> > not necessarily their shipping ROMs, right? :)
[snip]
> The issue of "shipping ROMs" for the EV-64260A is moot I think.
Yeah.
> > I'm sure it's unintentional, but it looks more like it'd be changing
> > platform_init to x_init,
>
> I'm not sure what you mean by unintentional, it's necessary to change
I ment the '#ifdef-ectomy' comment. Most of the code is actually rather
clean. The Sandpoint is actally a good candidate for some sort of run-time
checks since it's a development board and the X2/X3 (and X3b) do differ in
some ways. I actually think the Spruce thing is a red-herring, but maybe the
Spurce Paul/David Gibson have is different than the one mporter has access to.
> > and serial fixes rather than changing #ifdefs.
>
> I think the way I've handled serial in CONFIG_GENERIC_PPC32 is neat and the
> RTTD.
This works great if you let the firmware deal with the serial port. I
need to play abit more with it I suspect, but using early_serial_setup()
becomes less than ideal, w/o some trickery anyhow, ifyou have to use
arch/ppc/boot/common/ns16550.c
> > Aside from some ugliness added back to the code (see my other email).
>
> I don't see it as ugly, I think it's quite beautiful.
Adding an #ifdef per board?
> > One other problem is that in case anyone forgot, back when we used to
> > always define a new _MACH type, we had actually ran out (or got w/in 3
> > or so) so we might want to think of changing the values in 2.5 to
> > something that can scale better, if we're going to do this.
>
> Perhaps you've missed my comment in processor.h:
Yeap.
> > If you didn't have the option of replacing a firmware, I'd bet you'd end
> > up using it too :)
>
> Ahmm, when you are making a new board there is no firmware to replace,
> you have to write it!
If you don't have the option to replace an existing firmware... but
anyways.
> > But anyhow, it's actually not incompatible with this. I've gone and
> > looked at this abit, and it'd be a matter of re-writing the Makefile a
> > bit (obj-$(...) and XXX_OBJS -> platform.o, rm -f'ed after each zImage,
> > and then a -DMACH_TYPE=_MACH_xxx for one of the files..).
>
> Are you saying you are going to make some kind of loop in
> arch/ppc/boot/simple/Makefile that would spit out 20 zImages on one
> make zImage for CONFIG_GENERIC_PPC32? Fine with me if you want to do that.
Well it'd be no worse than the loop we have right now to spit out
zImages.
> > > This will be
> > > an encouragement to board makers to use standardized firmware like OF,
> > > StarMON, or PPCBoot rather than roll a board-unique one: use something
> > > standard and you can use one of existing zImages, or roll your own and
> > > be prepared to convince people to accept adding yet another zImage.
> >
> > Or use a firmware which can load an ELF image (pmon, yes?) or fake it
>
> But this way you still have to add a new zImage for each new board, even if
> only to carry the knowledge of which board it is. With standardized firmware
> like OF and StarMON it's unnecessary, there is one firmware standard that can
> be implemented on an infinite number of boards, one common interface so one
> zImage can work on all, and a machine ID that it can sense to select the right
> port in vmlinux.
I'll probably soon give up on trying to convince you that this won't
happen and the closest that's ever likely to be seen as a 'standard
firmware' is the ability to deal with a static ELF program. It'd be
_nice_ if everyone use PPCBoot or StarMON or something (remember, not
all OF is created equal, and Apple doesn't have much/any incentive to be
compatible w/ the rest of the OF world).
> > Personally, I think some people spend too much time in the firmware and
> > not enough time actually in linux.
>
> That's probably because some of us are more hardware than software engineers.
<Another Joke>
So you're more one of those hardware people inflicting really wierd
designs on us software people, aren't you? :)
</Another Joke>
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-04-09 14:59 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 ` Tom Rini [this message]
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 ` CONFIG_GENERIC_PPC32 Tom Rini
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=20020409145929.GC710@opus.bloom.county \
--to=trini@kernel$(echo .)crashing.org \
--cc=linuxppc-dev@lists$(echo .)linuxppc.org \
--cc=msokolov@ivan$(echo .)Harhan.ORG \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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