Tom Rini [off-list ref] wrote:
I'd be willing to bet $5 it's from Troy.
OK...
IMHO, 9600 is the defacto
default rate,
YES!!!
but Troy likes 'fast' serial consoles.
But Troy's personal preferences shouldn't affect the public tree, should they?
If 9600 is the default baud rate for all of Linux, why should one port be
different? Who is the maintainer with authority over this? Would s/he accept a
patch to axe that 115200 line out?
Right, And boards other than the EV-64260-BP use the zImage wrapper,
like the Motorola MVP.
[...]
I'm saying that if nothing else the comment is wrong or slightly
misleading, as it's not 'just' for the EV-64260-BP, it's for the
Motorola MVP as well, and possibly other boards in the future which have
to use !(StarMON || PPCBoot).
But right now there is no MVP in 2_4_devel, so for 2_4_devel as it is right now
it's for EV-64260-BP only. If/then someone adds another port that needs the
same ugly hack in the zImage wrapper, they can add -o "$CONFIG_MYBOARD" = "y"
to it. But it still won't be for all GT-64260 boards, like it won't be for my
StarMON-only boards.
Well, (and I do need to check out the _galileo tree) iirc the stuff to
support that option is in one of the generic files. Or generic to the
work currently in there. If that's the case, and you're explicitly not
going to support it in your files (and ports) then add a -a
"$CONFIG_xxx" = "n" .
You still don't get it. I find that logic offensive. It makes me not want to
use the GT-64260 in my designs because your logic implies that if someone uses
the GT-64260 s/he wants to do things your way. Just because there is a generic
file doesn't mean I'm obligated to use it in my ports. I can build a board with
a GT-64260A in an epoxy-filled tamper-resistant module where StarMON sets up
the system environment and the Linux port looks just like the Adirondack one.
You'll never be able to tell that there even is a GT-64260 in that system!
Think of StarMON like OF. That's a good model, as StarMON is indeed a real
competitor to OF. Just like on OF machines the device tree tells you where
system features are located and you don't really know or care what chips
implement these features and what magic the firmware had to do to make it all
work, so with StarMON. You have so much memory, a PCI bus here, a UART there,
etc., and you don't really need to know whether it's a CPC710 or a GT-64260.
I want to design my ports like this: OK, here is my hardware feature set, let's
write the files telling Linux how to make use of it. You are forcing me to
think differently: OK, here are the chips on my board, let's see what generic
files they have for them. But I don't want to do my ports your way, and I find
it offensive that the GT-64260 code you have in the tree now essentially forces
me how to think.
MS
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Michael Sokolov wrote:
But Troy's personal preferences shouldn't affect the public tree, should they?
If 9600 is the default baud rate for all of Linux, why should one port be
different?
I didn't know there was a "default" baud rate for Linux. I think the lowest
I have ever seen is 9600, but I certainly wouldn't call it a default. It
seems every one of the boards I have uses something different,
The debug console serial port rates are either provided by passing some
bootloader information to the kernel or by a kernel command line option.
Either one is locally configurable.
.... Who is the maintainer with authority over this? Would s/he accept a
patch to axe that 115200 line out?
It shouldn't be a hard-coded value. It should at least be the standard Linux
command line option. Bootloaders should simply use the port as it was
configured by the boot rom.
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Dan Malek wrote:
>
> Michael Sokolov wrote:
>
>> But Troy's personal preferences shouldn't affect the public tree, should
>> they? If 9600 is the default baud rate for all of Linux, why
>> should one port be different?
>
>
> I didn't know there was a "default" baud rate for Linux. I think
> the lowest I have ever seen is 9600, but I certainly wouldn't call
> it a default. It seems every one of the boards I have uses
> something different,
>
The default for just about any unix box (and an awful lot of other
things - network switches etc) seems to be 9600 8N1, partly because even
ancient terminals can cope with that (a lot of older ones don't go past
38400 for example). Allowing an override is fine, but leaving the
default at 9600 will follow the 'path of least surprise'.
Cheers,
David
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Sat, Mar 16, 2002 at 11:03:13PM -0800, Michael Sokolov wrote:
Tom Rini [off-list ref] wrote:
quoted
Well, (and I do need to check out the _galileo tree) iirc the stuff to
support that option is in one of the generic files. Or generic to the
work currently in there. If that's the case, and you're explicitly not
going to support it in your files (and ports) then add a -a
"$CONFIG_xxx" = "n" .
You still don't get it. I find that logic offensive. It makes me not want to
use the GT-64260 in my designs because your logic implies that if someone uses
the GT-64260 s/he wants to do things your way.
Yes, it assumes that if you're going to make a GT-64260 based port and
get it into the main tree you're going to use the common files for said
chipset so that all of the boards can be said to have certain things
working and reduce the ammount of coding needed to be done by you.
Like Troy said in an earlier message, it's great that you've got all of
this work done, but if you want to get it into the main tree and not
just keep up your own fork of it, some of your code will have to be
modified. The current stuff has the feature that it can make use of
CONFIG_SERIAL_TEXT_DEBUG on all ports.
Just because there is a generic file doesn't mean I'm obligated to use
it in my ports.
Actually, unless you've got good and preferably technical objections to
it, you are. Once it gets into the main trees, it's not just your board
port, it's everyones board port. And duplication of code isn't
generally a good thing.
If you've done your GT-64260 board without duplicating most of the work
in gt64260_common.c, then we can add in tests for your board(s) or even
just define a CONFIG_STARMON and test for that.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/