coreboot February 2011

coreboot@coreboot.org

52 participants
283 discussions

[commit] r6371 - trunk
by repository service 17 Feb '11

17 Feb '11

Author: stepan Date: Thu Feb 17 21:47:49 2011 New Revision: 6371 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6371 Log: Make Makefile.inc parser loop more generic Signed-off-by: Patrick Georgi <patrick.georgi(a)secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Modified: trunk/Makefile Modified: trunk/Makefile ============================================================================== --- trunk/Makefile Thu Feb 17 01:52:02 2011 (r6370) +++ trunk/Makefile Thu Feb 17 21:47:49 2011 (r6371) @@ -183,38 +183,51 @@ @printf " CC $(subst $(obj)/,,$(@))\n" $(CC) -MMD $(CFLAGS) -c -o $@ $< -ramstage-srcs:=$(obj)/mainboard/$(MAINBOARDDIR)/static.c -romstage-srcs:= -driver-srcs:= -smm-srcs:= -cbfs-files:= - -ramstage-objs:= -romstage-objs:= -driver-objs:= -smm-objs:= -types:=ramstage romstage driver smm +# Add a new class of source/object files to the build system +add-class= \ + $(eval $(1)-srcs:=) \ + $(eval $(1)-objs:=) \ + $(eval classes+=$(1)) + +# Special classes are managed types with special behaviour +# On parse time, for each entry in variable $(1)-y +# a handler $(1)-handler is executed with the arguments: +# * $(1): directory the parser is in +# * $(2): current entry +add-special-class= \ + $(eval $(1):=) \ + $(eval special-classes+=$(1)) + +$(call add-class,ramstage) +$(call add-class,romstage) +$(call add-class,driver) +$(call add-class,smm) + +$(call add-special-class,cbfs-files) +cbfs-files-handler= \ + $(if $(wildcard $(1)$($(2)-file)), \ + $(eval tmp-cbfs-file:= $(wildcard $(1)$($(2)-file))), \ + $(eval tmp-cbfs-file:= $($(2)-file))) \ + $(eval cbfs-files += $(tmp-cbfs-file)|$(2)|$($(2)-type)|$($(2)-position)) \ + $(eval $(2)-name:=) \ + $(eval $(2)-type:=) \ + $(eval $(2)-position:=) + +ramstage-srcs+=$(obj)/mainboard/$(MAINBOARDDIR)/static.c # Clean -y variables, include Makefile.inc # Add paths to files in X-y to X-srcs # Add subdirs-y to subdirs includemakefiles= \ - $(foreach type,$(2), $(eval $(type)-y:=)) \ - $(eval subdirs-y:=) \ - $(eval cbfs-files-y:=) \ + $(foreach class,classes subdirs $(classes) $(special-classes), $(eval $(class)-y:=)) \ $(eval -include $(1)) \ - $(foreach type,$(2), \ - $(eval $(type)-srcs+= \ + $(foreach class,$(classes-y), $(call add-class,$(class))) \ + $(foreach class,$(classes), \ + $(eval $(class)-srcs+= \ $$(subst $(top)/,, \ - $$(abspath $$(addprefix $(dir $(1)),$$($(type)-y)))))) \ - $(foreach file,$(cbfs-files-y), \ - $(if $(wildcard $(dir $(1))$($(file)-file)), \ - $(eval tmp-cbfs-file:= $(wildcard $(dir $(1))$($(file)-file))), \ - $(eval tmp-cbfs-file:= $($(file)-file))) \ - $(eval cbfs-files += $(tmp-cbfs-file)|$(file)|$($(file)-type)|$($(file)-position)) \ - $(eval $(file)-name:=) \ - $(eval $(file)-type:=) \ - $(eval $(file)-position:=)) \ + $$(abspath $$(addprefix $(dir $(1)),$$($(class)-y)))))) \ + $(foreach special,$(special-classes), \ + $(foreach item,$($(special)-y), $(call $(special)-handler,$(dir $(1)),$(item)))) \ $(eval subdirs+=$$(subst $(CURDIR)/,,$$(abspath $$(addprefix $(dir $(1)),$$(subdirs-y))))) # For each path in $(subdirs) call includemakefiles @@ -223,7 +236,7 @@ $(eval cursubdirs:=$(subdirs)) \ $(eval subdirs:=) \ $(foreach dir,$(cursubdirs), \ - $(eval $(call includemakefiles,$(dir)/Makefile.inc,$(types)))) \ + $(eval $(call includemakefiles,$(dir)/Makefile.inc))) \ $(if $(subdirs),$(eval $(call evaluate_subdirs))) # collect all object files eligible for building @@ -231,14 +244,10 @@ $(eval $(call evaluate_subdirs)) src-to-obj=$(addsuffix .$(1).o, $(basename $(patsubst src/%, $(obj)/%, $($(1)-srcs)))) +$(foreach class,$(classes),$(eval $(class)-objs:=$(call src-to-obj,$(class)))) -ramstage-objs:=$(call src-to-obj,ramstage) -romstage-objs:=$(call src-to-obj,romstage) -driver-objs:=$(call src-to-obj,driver) -smm-objs:=$(call src-to-obj,smm) - -allsrcs:=$(foreach var, $(addsuffix -srcs,$(types)), $($(var))) -allobjs:=$(foreach var, $(addsuffix -objs,$(types)), $($(var))) +allsrcs:=$(foreach var, $(addsuffix -srcs,$(classes)), $($(var))) +allobjs:=$(foreach var, $(addsuffix -objs,$(classes)), $($(var))) alldirs:=$(sort $(abspath $(dir $(allobjs)))) define ramstage-objs_asl_template @@ -274,7 +283,7 @@ $(eval $(call create_cc_template,smm,S)) foreach-src=$(foreach file,$($(1)-srcs),$(eval $(call $(1)-objs_$(subst .,,$(suffix $(file)))_template,$(subst src/,,$(basename $(file)))))) -$(eval $(foreach type,$(types),$(call foreach-src,$(type)))) +$(eval $(foreach class,$(classes),$(call foreach-src,$(class)))) DEPENDENCIES = $(ramstage-objs:.o=.d) $(romstage-objs:.o=.d) $(driver-objs:.o=.d) $(smm-objs:.o=.d) -include $(DEPENDENCIES)

1 0

QA contribution
by Danila Sukharev 17 Feb '11

17 Feb '11

Hi there! I'm a QA guy interested in coreboot project. I have two mobos supported by coreboot; also I have some QA and dev skills (but mostly QA). I also have the ability to check the coreboot on some other mobos - I have them in my hands from time to time. How is it possible for me to start contributing the project in such a role? Is there some guide, some list of open tasks, or list of fixes pending review?.. I've looked over the site but have not found clear answer to my question. Thanks, -- Dan

6 14

[PATCH 1/3] Make Makefile.inc parser loop more generic
by Patrick Georgi 17 Feb '11

17 Feb '11

Signed-off-by: Patrick Georgi <patrick.georgi(a)secunet.com> --- Makefile | 77 ++++++++++++++++++++++++++++++++++--------------------------- 1 files changed, 43 insertions(+), 34 deletions(-) diff --git a/Makefile b/Makefile index 43be315..0754b15 100644 --- a/Makefile +++ b/Makefile @@ -183,38 +183,51 @@ $(obj)/%.ramstage.o: $(obj)/%.c $(obj)/config.h @printf " CC $(subst $(obj)/,,$(@))\n" $(CC) -MMD $(CFLAGS) -c -o $@ $< -ramstage-srcs:=$(obj)/mainboard/$(MAINBOARDDIR)/static.c -romstage-srcs:= -driver-srcs:= -smm-srcs:= -cbfs-files:= - -ramstage-objs:= -romstage-objs:= -driver-objs:= -smm-objs:= -types:=ramstage romstage driver smm +# Add a new class of source/object files to the build system +add-class= \ + $(eval $(1)-srcs:=) \ + $(eval $(1)-objs:=) \ + $(eval classes+=$(1)) + +# Special classes are managed types with special behaviour +# On parse time, for each entry in variable $(1)-y +# a handler $(1)-handler is executed with the arguments: +# * $(1): directory the parser is in +# * $(2): current entry +add-special-class= \ + $(eval $(1):=) \ + $(eval special-classes+=$(1)) + +$(call add-class,ramstage) +$(call add-class,romstage) +$(call add-class,driver) +$(call add-class,smm) + +$(call add-special-class,cbfs-files) +cbfs-files-handler= \ + $(if $(wildcard $(1)$($(2)-file)), \ + $(eval tmp-cbfs-file:= $(wildcard $(1)$($(2)-file))), \ + $(eval tmp-cbfs-file:= $($(2)-file))) \ + $(eval cbfs-files += $(tmp-cbfs-file)|$(2)|$($(2)-type)|$($(2)-position)) \ + $(eval $(2)-name:=) \ + $(eval $(2)-type:=) \ + $(eval $(2)-position:=) + +ramstage-srcs+=$(obj)/mainboard/$(MAINBOARDDIR)/static.c # Clean -y variables, include Makefile.inc # Add paths to files in X-y to X-srcs # Add subdirs-y to subdirs includemakefiles= \ - $(foreach type,$(2), $(eval $(type)-y:=)) \ - $(eval subdirs-y:=) \ - $(eval cbfs-files-y:=) \ + $(foreach class,classes subdirs $(classes) $(special-classes), $(eval $(class)-y:=)) \ $(eval -include $(1)) \ - $(foreach type,$(2), \ - $(eval $(type)-srcs+= \ + $(foreach class,$(classes-y), $(call add-class,$(class))) \ + $(foreach class,$(classes), \ + $(eval $(class)-srcs+= \ $$(subst $(top)/,, \ - $$(abspath $$(addprefix $(dir $(1)),$$($(type)-y)))))) \ - $(foreach file,$(cbfs-files-y), \ - $(if $(wildcard $(dir $(1))$($(file)-file)), \ - $(eval tmp-cbfs-file:= $(wildcard $(dir $(1))$($(file)-file))), \ - $(eval tmp-cbfs-file:= $($(file)-file))) \ - $(eval cbfs-files += $(tmp-cbfs-file)|$(file)|$($(file)-type)|$($(file)-position)) \ - $(eval $(file)-name:=) \ - $(eval $(file)-type:=) \ - $(eval $(file)-position:=)) \ + $$(abspath $$(addprefix $(dir $(1)),$$($(class)-y)))))) \ + $(foreach special,$(special-classes), \ + $(foreach item,$($(special)-y), $(call $(special)-handler,$(dir $(1)),$(item)))) \ $(eval subdirs+=$$(subst $(CURDIR)/,,$$(abspath $$(addprefix $(dir $(1)),$$(subdirs-y))))) # For each path in $(subdirs) call includemakefiles @@ -223,7 +236,7 @@ evaluate_subdirs= \ $(eval cursubdirs:=$(subdirs)) \ $(eval subdirs:=) \ $(foreach dir,$(cursubdirs), \ - $(eval $(call includemakefiles,$(dir)/Makefile.inc,$(types)))) \ + $(eval $(call includemakefiles,$(dir)/Makefile.inc))) \ $(if $(subdirs),$(eval $(call evaluate_subdirs))) # collect all object files eligible for building @@ -231,14 +244,10 @@ subdirs:=$(PLATFORM-y) $(BUILD-y) $(eval $(call evaluate_subdirs)) src-to-obj=$(addsuffix .$(1).o, $(basename $(patsubst src/%, $(obj)/%, $($(1)-srcs)))) +$(foreach class,$(classes),$(eval $(class)-objs:=$(call src-to-obj,$(class)))) -ramstage-objs:=$(call src-to-obj,ramstage) -romstage-objs:=$(call src-to-obj,romstage) -driver-objs:=$(call src-to-obj,driver) -smm-objs:=$(call src-to-obj,smm) - -allsrcs:=$(foreach var, $(addsuffix -srcs,$(types)), $($(var))) -allobjs:=$(foreach var, $(addsuffix -objs,$(types)), $($(var))) +allsrcs:=$(foreach var, $(addsuffix -srcs,$(classes)), $($(var))) +allobjs:=$(foreach var, $(addsuffix -objs,$(classes)), $($(var))) alldirs:=$(sort $(abspath $(dir $(allobjs)))) define ramstage-objs_asl_template @@ -274,7 +283,7 @@ $(eval $(call create_cc_template,smm,c)) $(eval $(call create_cc_template,smm,S)) foreach-src=$(foreach file,$($(1)-srcs),$(eval $(call $(1)-objs_$(subst .,,$(suffix $(file)))_template,$(subst src/,,$(basename $(file)))))) -$(eval $(foreach type,$(types),$(call foreach-src,$(type)))) +$(eval $(foreach class,$(classes),$(call foreach-src,$(class)))) DEPENDENCIES = $(ramstage-objs:.o=.d) $(romstage-objs:.o=.d) $(driver-objs:.o=.d) $(smm-objs:.o=.d) -include $(DEPENDENCIES) -- 1.7.1

2 1

[PATCH 2/3] Handle compiler options for source classes more generically
by Patrick Georgi 17 Feb '11

17 Feb '11

Signed-off-by: Patrick Georgi <patrick.georgi(a)secunet.com> --- Makefile | 19 +++++++++++-------- 1 files changed, 11 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 0754b15..a233c13 100644 --- a/Makefile +++ b/Makefile @@ -202,6 +202,11 @@ $(call add-class,ramstage) $(call add-class,romstage) $(call add-class,driver) $(call add-class,smm) +ramstage-S-ccopts:=-DASSEMBLY +romstage-c-ccopts:=-D__PRE_RAM__ +romstage-S-ccopts:=-DASSEMBLY -D__PRE_RAM__ +driver-S-ccopts:=-DASSEMBLY + $(call add-special-class,cbfs-files) cbfs-files-handler= \ @@ -266,21 +271,19 @@ define create_cc_template # $1 obj class (ramstage, romstage, driver, smm) # $2 source suffix (c, S) # $3 additional compiler flags +ifn$(EMPTY)def $(1)-objs_$(2)_template de$(EMPTY)fine $(1)-objs_$(2)_template $(obj)/$$(1).$(1).o: src/$$(1).$(2) $(obj)/config.h @printf " CC $$$$(subst $$$$(obj)/,,$$$$(@))\n" $(CC) $(3) -MMD $$$$(CFLAGS) -c -o $$$$@ $$$$< en$(EMPTY)def +end$(EMPTY)if endef -$(eval $(call create_cc_template,ramstage,c)) -$(eval $(call create_cc_template,ramstage,S,-DASSEMBLY)) -$(eval $(call create_cc_template,romstage,c,-D__PRE_RAM__)) -$(eval $(call create_cc_template,romstage,S,-DASSEMBLY -D__PRE_RAM__)) -$(eval $(call create_cc_template,driver,c)) -$(eval $(call create_cc_template,driver,S,-DASSEMBLY)) -$(eval $(call create_cc_template,smm,c)) -$(eval $(call create_cc_template,smm,S)) +filetypes-of-class=$(subst .,,$(sort $(suffix $($(1)-srcs)))) +$(foreach class,$(classes), \ + $(foreach type,$(call filetypes-of-class,$(class)), \ + $(eval $(call create_cc_template,$(class),$(type),$($(class)-$(type)-ccopts))))) foreach-src=$(foreach file,$($(1)-srcs),$(eval $(call $(1)-objs_$(subst .,,$(suffix $(file)))_template,$(subst src/,,$(basename $(file)))))) $(eval $(foreach class,$(classes),$(call foreach-src,$(class)))) -- 1.7.1

2 1

Code organization question Re: Next target: ASUS TUSI-M
by Keith Hui 17 Feb '11

17 Feb '11

Hi Joseph, Okay, now I probably can use some help, at least in how to organize the code. Below is what I understand up to this point, but feel free to stop and correct me. SIS630 is just one chip. All the chipsets we have so far seems to always have a "northbridge" plus a "southbridge", at least that's how the coreboot source tree is organized. Northbridge has raminit.c for initializing (S)DRAM, a chip.h where some stuff got declared - but not 100% sure what, northbridge.c as a "driver" for ramstage for detecting and enabling PCI resources, as well as building a memory table, and debug.c with functions needed for CONFIG_DEBUG_RAM_SETUP. Southbridge has... bootblock.c for code required to make the whole ROM chip accessible all ACPI stuff (will be a while before I can get to that) one ramstage "driver" for each PCI device the bridge supports eg. IDE, USB, LAN romstage smbus access code for reading SPD Mainboard has... devicetree.cb for describing the board's devices Here are my questions. If the answer can be found in a certain file in the tree, tell me - I'll read it. For this single chip chipset, should I put everything into northbridge, or keep only RAM init and bus scan stuff in src/northbridge, and put IDE/USB/LAN/SMBus/LPC/ISA etc. in src/southrbidge? In this scheme where would VGA fit? SIS630 and my board has onboard VGA that shares memory with main. I have the VGA BIOS extracted. Do I still need to write code to initialize it? If so, where in the coreboot tree? What is the relationship between devicetree.cb, sconfig, parameters available to be included in cmos.layout, northbridge and southbridge drivers? Say I need to have add a setting in cmos.layout to enable/disable the built in LAN, in how many places do I have to declare this setting? My factory bios writes some known values into various superio LDNs during early initialization. Can I declare them in devicetree.cb or I have to write them in C into some early init code? Also, should I declare devices that can be enabled/disabled either in software or by jumper? In declaring devices in devicetree.cb, does "device pci_domain 1..." means PCI bus 1, like the AGP slot on a 440BX? The IDE, USB and LAN devices on SIS chipsets so often share the same PCI IDs and probably the same initialization sequence. There is currently only one other SIS southbridge in the tree (the 966) but its IDE has the same 1039:5513 ID as that on the 630. Any way I can share this code, or I still have to duplicate it? Any chance I can factor it out like Sil3114? In the ramstage driver model, what is the relationships between chip.h, Looking at my factory BIOS disassembly and what coreboot v1 had done, I am going to have to write some known values into known registers, both in the northbridge device, "southbridge device", and superio. Where usually is this done? bootblock_northbridge_init() for tinybootblock, in the mainboard romstage main(), in raminit.c before actually doing RAM init? I figure the first option is the earliest and best opportunity, following factory bios' lead. I had a long chat the other night with Idwer helping him port coreboot to intel 865. Figures it's about time I get some help for myself. Thanks. Keith On Wed, Jan 5, 2011 at 5:55 AM, Joseph Smith <joe(a)settoplinux.org> wrote: > > > On Wed, 5 Jan 2011 00:06:29 -0500, Keith Hui <buurin(a)gmail.com> wrote: >> This is the next board I want to port coreboot to. And the three logs >> are attached. "Sissy" is what I name the machine the board is in, >> after SiS. :D >> >> The flash chip i know for sure is SST 39SF020A. It needs a board >> enable, for which I have figured out 3 of the 5 operations involved, >> thanks to Luc's slides up at Phoronix. >> >> It used a soldered PLCC32 flash chip. I soldered a socket on myself, >> and the chip miraclously survived. But I have not been able to get >> another of the same chip for backup. All my 3 spares are DIP32. >> >> Super I/O is IT8705F, already supported. So it looks like all that's >> needed is porting SiS630 from coreboot v1. I think I would also be the >> first to port a single chip chipset to v4. >> >> Thanks to a previous thread on this list, I got the '630 datasheet, >> but I don't know for sure what is different between it (the 630) and >> my chip (630ET). >> >> Appreciate all the help I can get for this one. > > Sweet! I have a bunch of SIS 630 boards laying around, anything I can do to > help just let me know :-) > > -- > Thanks, > Joseph Smith > Set-Top-Linux > www.settoplinux.org > >

4 3

Will coreboot work on my Shuttle X27?
by Jørn Odberg 17 Feb '11

17 Feb '11

1) This is a Shuttle X27 , dual Intel Atom CPU 330. lshw reports: - Motherboard SFM27 - BIOS Phoenix v6.00 PG - Host bridge: Intel 82945G/GZ/P/PL Memory Controller Hub - Display: Intel 82945G/GZ Integrated - Audio: Intel N10/ICH 7 HD - PCI Bridge: Intel N10/ICH 7 Family PCI Express Port 1 - Network: TRL8111/8168B Pci Express Gigabit - USB: Intel N10/ICH7 Family USB UHCI / N10/ICH 7 Family USB2 EHCI - PCI Bridge: Intel 82801 PCI bridge -ISA bridge: 82801GB/GR (ICH7 Family) LPC Interface Bridge - SMBus N10/ICH 7 Family SMBus Controller See attached lshw.txt 2) See attached lspci-tvnn.txt 3) See attached superiotool-dV.txt 4) See attached flashrom-V.txt Please tell if I need to supply more info. // jorn

2 1

Re: [coreboot] Code organization question Re: Next target: ASUS TUSI-M (Cont'd)
by Keith Hui 17 Feb '11

17 Feb '11

Hit send too soon... My questions continues below... On Wed, Feb 16, 2011 at 11:52 PM, Keith Hui <buurin(a)gmail.com> wrote: > Hi Joseph, > > Okay, now I probably can use some help, at least in how to organize > the code. Below is what I understand up to this point, but feel free > to stop and correct me. > > SIS630 is just one chip. All the chipsets we have so far seems to > always have a "northbridge" plus a "southbridge", at least that's how > the coreboot source tree is organized. Northbridge has raminit.c for > initializing (S)DRAM, a chip.h where some stuff got declared - but not > 100% sure what, northbridge.c as a "driver" for ramstage for detecting > and enabling PCI resources, as well as building a memory table, and > debug.c with functions needed for CONFIG_DEBUG_RAM_SETUP. > > Southbridge has... > bootblock.c for code required to make the whole ROM chip accessible > all ACPI stuff (will be a while before I can get to that) > one ramstage "driver" for each PCI device the bridge supports eg. IDE, USB, LAN > romstage smbus access code for reading SPD > > Mainboard has... devicetree.cb for describing the board's devices chip.h declaring the board's name irq_tables.c that maps interrupt routing and we get it with getpir romstage.c to do early serial port init, board specific init to make SPD accessible, then call northbridge's raminit code and cmos.layout. > > Here are my questions. If the answer can be found in a certain file in > the tree, tell me - I'll read it. > > For this single chip chipset, should I put everything into > northbridge, or keep only RAM init and bus scan stuff in > src/northbridge, and put IDE/USB/LAN/SMBus/LPC/ISA etc. in > src/southrbidge? In this scheme where would VGA fit? > > SIS630 and my board has onboard VGA that shares memory with main. I > have the VGA BIOS extracted. Do I still need to write code to > initialize it? If so, where in the coreboot tree? > > What is the relationship between devicetree.cb, sconfig, parameters > available to be included in cmos.layout, northbridge and southbridge > drivers? Say I need to have add a setting in cmos.layout to > enable/disable the built in LAN, in how many places do I have to > declare this setting? My factory bios writes some known values into > various superio LDNs during early initialization. Can I declare them > in devicetree.cb or I have to write them in C into some early init > code? Also, should I declare devices that can be enabled/disabled > either in software or by jumper? > > In declaring devices in devicetree.cb, does "device pci_domain 1..." > means PCI bus 1, like the AGP slot on a 440BX? > > The IDE, USB and LAN devices on SIS chipsets so often share the same > PCI IDs and probably the same initialization sequence. There is > currently only one other SIS southbridge in the tree (the 966) but its > IDE has the same 1039:5513 ID as that on the 630. Any way I can share > this code, or I still have to duplicate it? Any chance I can factor it > out like Sil3114? > > In the ramstage driver model, what is the relationships between chip.h, the xxx_ops structs, the xxx_config structs, and the various function pointers in them? > > Looking at my factory BIOS disassembly and what coreboot v1 had done, > I am going to have to write some known values into known registers, > both in the northbridge device, "southbridge device", and superio. > Where usually is this done? bootblock_northbridge_init() for > tinybootblock, in the mainboard romstage main(), in raminit.c before > actually doing RAM init? I figure the first option is the earliest and > best opportunity, following factory bios' lead. > > I had a long chat the other night with Idwer helping him port coreboot > to intel 865. Figures it's about time I get some help for myself. > Thanks. Keith > > On Wed, Jan 5, 2011 at 5:55 AM, Joseph Smith <joe(a)settoplinux.org> wrote: >> >> >> On Wed, 5 Jan 2011 00:06:29 -0500, Keith Hui <buurin(a)gmail.com> wrote: >>> This is the next board I want to port coreboot to. And the three logs >>> are attached. "Sissy" is what I name the machine the board is in, >>> after SiS. :D >>> >>> The flash chip i know for sure is SST 39SF020A. It needs a board >>> enable, for which I have figured out 3 of the 5 operations involved, >>> thanks to Luc's slides up at Phoronix. >>> >>> It used a soldered PLCC32 flash chip. I soldered a socket on myself, >>> and the chip miraclously survived. But I have not been able to get >>> another of the same chip for backup. All my 3 spares are DIP32. >>> >>> Super I/O is IT8705F, already supported. So it looks like all that's >>> needed is porting SiS630 from coreboot v1. I think I would also be the >>> first to port a single chip chipset to v4. >>> >>> Thanks to a previous thread on this list, I got the '630 datasheet, >>> but I don't know for sure what is different between it (the 630) and >>> my chip (630ET). >>> >>> Appreciate all the help I can get for this one. >> >> Sweet! I have a bunch of SIS 630 boards laying around, anything I can do to >> help just let me know :-) >> >> -- >> Thanks, >> Joseph Smith >> Set-Top-Linux >> www.settoplinux.org >> >> >

1 0

[superiotool] patch for smsc mec1308
by David Hendricks 17 Feb '11

17 Feb '11

Hi, Attached is a patch to add support for the SMSC MEC1308 embedded controller. Unfortunately, the device ID it conflicts with another SMSC Super IO chip, the FDC37M81x. However, since superiotool does not really support the FDC37M81x in any really useful capacity, I think it's fair to just disable it for now. Signed-off-by: David Hendricks <dhendrix(a)google.com> -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

3 5

[commit] r6370 - trunk/util/superiotool
by repository service 17 Feb '11

17 Feb '11

Author: dhendrix Date: Thu Feb 17 01:52:02 2011 New Revision: 6370 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6370 Log: add mec1308 support to superiotool This patch also disables FDC37M81x since it has a conflicting device ID and is not supported very well anyway. Signed-off-by: David Hendricks <dhendrix(a)google.com> Acked-by: Stefan Reinauer <reinauer(a)google.com> Modified: trunk/util/superiotool/smsc.c Modified: trunk/util/superiotool/smsc.c ============================================================================== --- trunk/util/superiotool/smsc.c Wed Feb 16 18:40:04 2011 (r6369) +++ trunk/util/superiotool/smsc.c Thu Feb 17 01:52:02 2011 (r6370) @@ -358,6 +358,8 @@ {0x30,0x60,0x61,0x70,0xf0,EOT}, {0x00,0x00,0x00,NANA,NANA,EOT}}, {EOT}}}, +#if 0 + /* FIXME: FDC37M81x and MEC1308 have conflicting device IDs */ {0x4d, "FDC37M81x", { {NOLDN, NULL, {0x03,0x20,0x21,0x22,0x23,0x24,0x26,0x27,0x2b,0x2c, @@ -390,6 +392,34 @@ NANA,NANA,NANA,NANA,0x00,0x00,0x00,0x00,RSVD,RSVD, RSVD,RSVD,RSVD,RSVD,EOT}}, {EOT}}}, +#endif + {0x4d, "MEC1308", { + {NOLDN, NULL, + {0x02,0x03,0x07,0x17,0x20,0x21,0x22,0x23,0x24,0x25, + 0x26,0x27,0X28,0X29,0X2a,0X2b,0X2c,0X2d,0X2e,0X2f, + EOT}, + {0x00,RSVD,0x00,RSVD,0x4d,0x00,0x00,0x00,0x04,0x04, + MISC,MISC,MISC,MISC,MISC,MISC,MISC,MISC,MISC,MISC, + EOT}}, + {0x1, "PM1", + {0x30,0x60,0x61,EOT}, + {0x00,0x00,0x00,EOT}}, + {0x4, "COM1", + {0x30,0x60,0x61,0x70,EOT}, + {0x00,0x00,0x00,0x00,EOT}}, + {0x7, "KBD", + {0x30,0x70,0x72,0xF0,EOT}, + {0x00,0x00,0x00,0x00,EOT}}, + {0x8, "EC/ACPI", + {0x30,0x60,0x61,EOT}, + {0x00,0x00,0x62,EOT}}, + {0x9, "Mailbox", + {0x30,0x60,0x61,EOT}, + {0x00,0x00,0x00,EOT}}, + {0x10, "CIRV", + {0x30,0x60,0x61,0x70,0xf0,0xf1,0xf3,0xf4,EOT}, + {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,EOT}}, + {EOT}}}, {0x51, "LPC47B27x", { {NOLDN, NULL, {0x03,0x20,0x21,0x22,0x23,0x24,0x26,0x27,0x28,

1 0

Seeing the output messages
by ali hagigat 16 Feb '11

16 Feb '11

How a program is traced in Coreboot? by serial port? or initialization of internal graphics cards? What about those boards with external graphics cards? When it does printk, to what device the message is actually sent?

4 5

← Newer
1
...
11
12
13
14
15
16
17
...
29
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2011