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: Wed, 10 Apr 2002 08:16:54 -0700 [thread overview]
Message-ID: <20020410151654.GC26754@opus.bloom.county> (raw)
In-Reply-To: <0204091952.AA24042@ivan.Harhan.ORG>
On Tue, Apr 09, 2002 at 12:52:40PM -0700, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel•crashing.org> wrote:
>
> > 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.
>
> But the point is that these two ports as they are right now aren't suitable for
> CONFIG_GENERIC_PPC32 because of #ifdefs in them. An #ifdef-ectomy would mean
> splitting the Sandpoint port into two ports, X2 and X3 with different _machine
> codes, selected at run time.
> I don't know what to do for the Spruce. Does that
> board have a spec saying what the baud clock is supposed to be? If there is,
> assume the value from the spec and fix the boards that don't meet the spec. If
> there is no right value and both values are equally legit, that's a screwed-up
> board that standard OSes like Debian Linux/PPC don't need to support, so don't
> bother putting it in the generic kernel.
Again, I think the Spruce thing is a red herring since I think it's only
the Spruce that David Gibson has which needs or needed a different
speed. I suspect I'll end up looking in the archives and settling this
once and for all before Spruce moves up to linuxppc_2_4.
> > > 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
>
> Ahh, the arch/ppc/boot morass is a fly in the ointment again...
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'.
> Well, you know
> my solution: remove the fly. When you have just vmlinux, early_serial_setup()
> is the ideal solution as that's precisely what it's designed for. It's doing
> things the right way, the way they were meant to be done.
Except when you compile serial as a module like Paul pointed out. Maybe
this will be better in 2.5 tho w/ the new serial driver Russel King has
(http://www.arm.linux.org.uk/cvs/).
> You were just talking about making make zImage spit out a pile of zImages for
> different boards by compiling the wrapper many times in different
> configurations. Just instantiate the wrapper's ns16550 driver per board.
That's what we do now, and would do, with the 'current' <asm/serial.h>
which gets the right file for the right board, in a 1-board config. It
also 'just works' when the ports are at the legacy location, from what I
recall. (or legacy + 0x00800000 or something).
--
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-10 15:16 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 ` Tom Rini [this message]
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=20020410151654.GC26754@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