[PATCH] My GT-64260 enhancements
trini at kernel.crashing.org
Tue Mar 19 01:54:07 EST 2002
On Sun, Mar 17, 2002 at 12:10:43PM -0800, Michael Sokolov wrote:
> Dan Malek <dan at embeddededge.com> wrote:
> > So, I don't see the problem. A default is specified and you can change it,
> > just like lots of other configurations.
> The problem is that there is a
> define_int CONFIG_SERIAL_CONSOLE_BAUD 115200
The other problem is you're looking at the wrong tree for this, which
I'll get into further down. But in the galileo tree, it's:
if [ "$CONFIG_MOT_MVP" = "y" ]; then
define_bool CONFIG_GT64260 y
define_int CONFIG_SERIAL_CONSOLE_BAUD 115200
if [ "$CONFIG_USE_PPCBOOT" != "y" ]; then
int 'Serial Console Baudrate' CONFIG_SERIAL_CONSOLE_BAUD 115200
So the MVP uses 115200, and possibly even DINK does, and anyone else
gets to pick or assumes 9600.
> Having "$CONFIG_GT64260" = "y" imply support for CONFIG_SERIAL_TEXT_DEBUG is
> also discriminatory and undemocratic. Should we also imply the same then for
> "$CONFIG_CPC700" = "y" -o "$CONFIG_CPC710" = "y" -o "$CONFIG_UNINORTH" = "y",
No, because right now the CPC700 and CPC710 systems don't know how to
setup a serial port for early debugging via ppc_md.progress().
> I mean I don't mind if defaults are changed globally, it's just the
> discriminatory treatment of GT-64260 that I violently object to.
Can you be more specific?
> Oh, and having
> a separate BK tree and mailing list for it too isn't something I'm fond of.
Why? The GT-64260 stuff is under heavy development, and between
gt-64260 problems and board problems (and possible processor issues)
having a seperate tree in which to try and hammer things out between the
folks working on it seems useful.
Tom Rini (TR1265)
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-dev