Hi Keith,
Keith Hui buu...@gmail.com writes:
Option C with GPLv2+ licensing.
A few quick things:
SUPERIO_FINTEK_F81865F_HAS_EARLY_SERIAL seems long-winded for a name.
I prefer to define CONFIG_SUPERIO_HAS_EARLY_SERIAL (or even just
CONFIG_HAS_EARLY_SERIAL) within the superio Kconfig and
On 03/03/2011 09:35 AM, Georgi, Patrick wrote:
The chipset components in Kconfig could be derived from the
devicetree.cb (statically, on config time or before) - this would
simplify board config a bit by reducing duplication.
Early serial could be managed with a new keyword there
(chip
I like this solution too. Just that it requires hacking sconfig, and
I'm not even close to qualified to actually do it. :)
And this requires sconfig to produce some other output for romstage as
well. The hardware tree it produces is currently only used during
ramstage.
While we're on sconfig,
On 03/03/2011 04:49 PM, Keith Hui wrote:
I like this solution too. Just that it requires hacking sconfig, and
I'm not even close to qualified to actually do it. :)
And this requires sconfig to produce some other output for romstage as
well. The hardware tree it produces is currently only
Option C with GPLv2+ licensing.
Alex
Signed-off-by: Alexandru Gagniuc mr.nuke...@gmail.com
Index: src/include/superio/early_serial.h
===
--- src/include/superio/early_serial.h (revision 0)
+++ src/include/superio/early_serial.h
Option C with GPLv2+ licensing.
A few quick things:
SUPERIO_FINTEK_F81865F_HAS_EARLY_SERIAL seems long-winded for a name.
I prefer to define CONFIG_SUPERIO_HAS_EARLY_SERIAL (or even just
CONFIG_HAS_EARLY_SERIAL) within the superio Kconfig and not in
mainboard Kconfig. This I think would be a
On 03/03/2011 01:01 AM, Keith Hui wrote:
Option C with GPLv2+ licensing.
A few quick things:
SUPERIO_FINTEK_F81865F_HAS_EARLY_SERIAL seems long-winded for a name.
I prefer to define CONFIG_SUPERIO_HAS_EARLY_SERIAL (or even just
CONFIG_HAS_EARLY_SERIAL) within the superio Kconfig and not
Am Donnerstag, den 03.03.2011, 01:06 +0200 schrieb Alex G.:
So you have:
select SUPERIO_KEITH875H
select SUPERIO_ALEX666G
select SUPERIO_ALEX666G_HAS_EARLY_SERIAL
Having said that though, isn't early serial support sort of mandatory
anyway?
The point is not to
Hi guys!
I present a proposal for dealing with the annoying:
#include superio/vendor/model/early_serial.c
present in virtually all romstage.c files.
The steps are as follows:
1) Declare a generic prototype: superio_enable_early_serial();
2) Remove #include */early_serial.c from romstage
3) add a
Am Samstag, 26. Februar 2011, 14:17:37 schrieb Alex G.:
3) add a romstage-$(CONFIG_THIS_SUPERIO) += early_serial.c to the
superio's Makefile.inc
This will fail for romcc boards, as for them, romstage must be compiled by a
single romcc invocation.
I planned to work on this by having the build
Alex G. wrote:
Moves the inclusion of the superio early code from romstage.c in
the mainboard directory to Makefile.inc in the superio directory.
Will it work also for boards with more than one superio?
//Peter
--
coreboot mailing list: coreboot@coreboot.org
On 02/26/2011 10:50 PM, Patrick Georgi wrote:
Am Samstag, 26. Februar 2011, 14:17:37 schrieb Alex G.:
3) add a romstage-$(CONFIG_THIS_SUPERIO) += early_serial.c to the
superio's Makefile.inc
This will fail for romcc boards, as for them, romstage must be compiled by a
single romcc invocation.
Am Samstag, 26. Februar 2011, 23:27:47 schrieb Alex G.:
Why bother holding dear to romcc when the obvious solution is to move
those boards to CAR? We introduce more unneeded complexity, and make it
at least just as hard to phase out romcc.
Those boards carry CPUs without CAR.
As for phasing
On 02/26/2011 11:16 PM, Peter Stuge wrote:
Alex G. wrote:
Moves the inclusion of the superio early code from romstage.c in
the mainboard directory to Makefile.inc in the superio directory.
Will it work also for boards with more than one superio?
I'm very tempted (and sure) to say no.
On 02/26/2011 11:43 PM, Patrick Georgi wrote:
Am Samstag, 26. Februar 2011, 23:27:47 schrieb Alex G.:
Why bother holding dear to romcc when the obvious solution is to move
those boards to CAR? We introduce more unneeded complexity, and make it
at least just as hard to phase out romcc.
Those
15 matches
Mail list logo