Okay I took a different way, looking at the code and having lots of problems trying to get it to compile and the similarity between the PowerPlus series I compiled a pplus kernel with the default config and the patch above and it booted, yeah, and dumped bits to the console, on an mvme2604.
So I made some changes Kconfig so that MVME5100 and PPLUS were basically the same ( The architecture for the 5100 and pplus are similar, so why was the code separated? arrgh I'm about to be burnt to a crisp, but if we don't get our fingers burnt we never learn) which the patch for is attached. This patch also allows the selection of nvram which I want also and it seems to compile no matter what you select, which it didn't before. And so selecting MVME5100 it booted and dumped bits to the console, yeah.
I'm still playing with the config, so please excuse the "weird" selections in the config which is also attached, but the notable differences between it and the arch/ppc/configs/mvme5100_defconfig are that it has selections for a default console, and input devices ( which isn't needed, I know) and .....
Ta,
dlg
From: David Gardiner <hidden> Date: 2004-09-21 00:11:34
I'm still playing with the config, so please excuse the "weird" selections in the config which is also attached, but the notable differences between it and the arch/ppc/configs/mvme5100_defconfig are that it has selections for a default console, and input devices ( which isn't needed, I know) and .....
That should of been, the config (changed from the pplus config) I attatched has none of the CONSOLE ... bits selected but has CONFIG_SERIAL_TEXT_DEBUG which you need the patch I attached
From: Marius Groeger <hidden> Date: 2004-09-21 09:43:11
On Mon, 20 Sep 2004, Matt Porter wrote:
quoted
Did you disable CONFIG_VT, if it was enabled? Otherwise you need to
pass console=ttyS0
and on recent kernels, you need console=ttyS0,9600 on boards like
this that use 9600 baud. Baud rate used to default to 9600, but
no longer.
So what IS the default then? Until today, I thought you don't necessarily
need a console= argument at all. See Documentation/serial-console.txt:
If no console device is specified, the first device found capable of
acting as a system console will be used. At this time, the system first
looks for a VGA card and then for a serial port. So if you don't have a
VGA card in your system the first serial port will automatically become
the console.
Are you saying that you should always pass console=...?
Regards,
Marius
--
Marius Groeger [off-list ref]
SYSGO AG Embedded and Real-Time Software
Voice: +49 6136 9948 0 FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.imerva.com
On Tue, Sep 21, 2004 at 11:15:20AM +0200, Marius Groeger wrote:
On Mon, 20 Sep 2004, Matt Porter wrote:
quoted
quoted
Did you disable CONFIG_VT, if it was enabled? Otherwise you need to
pass console=ttyS0
and on recent kernels, you need console=ttyS0,9600 on boards like
this that use 9600 baud. Baud rate used to default to 9600, but
no longer.
So what IS the default then? Until today, I thought you don't necessarily
need a console= argument at all. See Documentation/serial-console.txt:
If no console device is specified, the first device found capable of
acting as a system console will be used. At this time, the system first
looks for a VGA card and then for a serial port. So if you don't have a
VGA card in your system the first serial port will automatically become
the console.
Are you saying that you should always pass console=...?
Double checking my facts here, it's not CONFIG_VT per-se, but
CONFIG_VT_CONSOLE. The problem is that VT_CONSOLE will register before
anything else, even if no video hardware is found. Now getting a bit
simplistic, if you don't want VT_CONSOLE, you don't want VT, so...
--
Tom Rini
http://gate.crashing.org/~trini/
On Tue, Sep 21, 2004 at 08:55:41AM +1000, David Gardiner wrote:
Okay I took a different way, looking at the code and having lots of
problems trying to get it to compile and the similarity between the
PowerPlus series I compiled a pplus kernel with the default config and
the patch above and it booted, yeah, and dumped bits to the console, on
an mvme2604.
So I made some changes Kconfig so that MVME5100 and PPLUS were basically
the same ( The architecture for the 5100 and pplus are similar, so why
was the code separated? arrgh I'm about to be burnt to a crisp, but if
we don't get our fingers burnt we never learn) which the patch for is
attached. This patch also allows the selection of nvram which I want
also and it seems to compile no matter what you select, which it didn't
before. And so selecting MVME5100 it booted and dumped bits to the
console, yeah.
I _think_ the answer is simply that the mvme5100 work predated the
CONFIG_PPLUS work. If you can come up with a patch that adds mvme5100
support to CONFIG_PPLUS, we can get rid of the MVME5100-specific stuff.
(And, if you do, please look at Documentation/SubmittingPatches and the
Developers Certificate of Origin).
I'm still playing with the config, so please excuse the "weird"
selections in the config which is also attached, but the notable
differences between it and the arch/ppc/configs/mvme5100_defconfig are
that it has selections for a default console, and input devices ( which
isn't needed, I know) and .....