From peter at stuge.se Thu May 1 00:00:13 2008 From: peter at stuge.se (Peter Stuge) Date: Thu, 1 May 2008 00:00:13 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <032401c8aaf8$f4920240$0023040a@chimp> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <79a45e0eb2a61094b7bf4cd9e4574846@imap.1and1.com> <032401c8aaf8$f4920240$0023040a@chimp> Message-ID: <20080430220013.24779.qmail@stuge.se> On Wed, Apr 30, 2008 at 01:32:40PM -0600, Myles Watson wrote: > The loader needs to be customized for each board, or we need to > pass some information like RAM map from coreboot before that will > work. Maybe libpayload can help there? //Peter From uwe at hermann-uwe.de Thu May 1 00:08:59 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 1 May 2008 00:08:59 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <20080430210124.GB31307@greenwood> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <20080430160732.GC21304@cosmic.amd.com> <030a01c8aadd$7cc99860$0023040a@chimp> <20080430161852.GD21304@cosmic.amd.com> <2831fecf0804301021t2e3651c6t3bacaf8b0d9fbe4d@mail.gmail.com> <20080430210124.GB31307@greenwood> Message-ID: <20080430220859.GA5955@greenwood> On Wed, Apr 30, 2008 at 11:01:24PM +0200, Uwe Hermann wrote: > > +$(LEGACYBIOS_SRC_DIR)/out/rom.bin: $(LEGACYBIOS_STAMP_DIR)/.unpacked > > + @ echo "Building legacybios..." > > + @ echo $(LEGACYBIOS_SRC_DIR) > > + @ make -C $(LEGACYBIOS_SRC_DIR) > $(LEGACYBIOS_BUILD_LOG) 2>&1 > > Doesn't work for me. > > Adding 'AVOIDCOMBINE=1' as per legacybios README helps, but there are > still build failures on my box (x86, Linux): > > src/romlayout.S: Assembler messages: > src/romlayout.S:427: Error: attempt to .org/.space backwards? (-1) > src/romlayout.S:490: Fatal error: can't write out/romlayout16.o: Bad value > make[1]: *** [out/romlayout16.o] Error 1 > > Any ideas? OK, this is a solved problem. The 0.2.0 version works with gcc 4.1 but not with 4.2 or 4.3. However, the current git version _does_ work fine with all of them, (well, with gcc >= 4.1 at least). I think we should move to not wget the tarball but rather get specific git versions to make grabbing fixes from git easier (if no release happens early enough for our purposes). http://linuxtogo.org/cgi-bin/gitweb.cgi http://linuxtogo.org/cgi-bin/gitweb.cgi?p=kevin/legacybios.git;a=summary Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From mylesgw at gmail.com Thu May 1 00:23:47 2008 From: mylesgw at gmail.com (Myles Watson) Date: Wed, 30 Apr 2008 16:23:47 -0600 Subject: [coreboot] ADLO for buildrom In-Reply-To: <20080430220859.GA5955@greenwood> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com><20080430160732.GC21304@cosmic.amd.com><030a01c8aadd$7cc99860$0023040a@chimp><20080430161852.GD21304@cosmic.amd.com><2831fecf0804301021t2e3651c6t3bacaf8b0d9fbe4d@mail.gmail.com><20080430210124.GB31307@greenwood> <20080430220859.GA5955@greenwood> Message-ID: <033001c8ab10$dc732820$0023040a@chimp> > -----Original Message----- > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] > On Behalf Of Uwe Hermann > Sent: Wednesday, April 30, 2008 4:09 PM > To: Myles Watson; Jordan Crouse > Cc: Coreboot > Subject: Re: [coreboot] ADLO for buildrom > > On Wed, Apr 30, 2008 at 11:01:24PM +0200, Uwe Hermann wrote: > > > +$(LEGACYBIOS_SRC_DIR)/out/rom.bin: $(LEGACYBIOS_STAMP_DIR)/.unpacked > > > + @ echo "Building legacybios..." > > > + @ echo $(LEGACYBIOS_SRC_DIR) > > > + @ make -C $(LEGACYBIOS_SRC_DIR) > $(LEGACYBIOS_BUILD_LOG) 2>&1 > > > > Doesn't work for me. > > > > Adding 'AVOIDCOMBINE=1' as per legacybios README helps, but there are > > still build failures on my box (x86, Linux): > > > > src/romlayout.S: Assembler messages: > > src/romlayout.S:427: Error: attempt to .org/.space backwards? (-1) > > src/romlayout.S:490: Fatal error: can't write out/romlayout16.o: Bad > value > > make[1]: *** [out/romlayout16.o] Error 1 > > > > Any ideas? > > OK, this is a solved problem. > > The 0.2.0 version works with gcc 4.1 but not with 4.2 or 4.3. > However, the current git version _does_ work fine with all of them, > (well, with gcc >= 4.1 at least). > > I think we should move to not wget the tarball but rather get specific git > versions to make grabbing fixes from git easier (if no release happens > early enough for our purposes). > I'd rather not live on the edge. Since it's a one-developer project we should be able to talk him into releases when there's a major change and it's stabilized, but if it's important to you we can change it. Myles From mylesgw at gmail.com Thu May 1 00:24:47 2008 From: mylesgw at gmail.com (Myles Watson) Date: Wed, 30 Apr 2008 16:24:47 -0600 Subject: [coreboot] ADLO for buildrom In-Reply-To: <20080430210124.GB31307@greenwood> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <20080430160732.GC21304@cosmic.amd.com> <030a01c8aadd$7cc99860$0023040a@chimp> <20080430161852.GD21304@cosmic.amd.com> <2831fecf0804301021t2e3651c6t3bacaf8b0d9fbe4d@mail.gmail.com> <20080430210124.GB31307@greenwood> Message-ID: <033101c8ab11$008b6bf0$0023040a@chimp> > -----Original Message----- > From: Uwe Hermann [mailto:uwe at hermann-uwe.de] > Sent: Wednesday, April 30, 2008 3:01 PM > To: Myles Watson > Cc: Jordan Crouse; Coreboot > Subject: Re: [coreboot] ADLO for buildrom > > On Wed, Apr 30, 2008 at 11:21:48AM -0600, Myles Watson wrote: > > Here are two patches. One adds a lightened ADLO to payloads/adlo. > > The other adds ADLO to buildrom. > > > > The only non-specific change is an error if there is no payload > > selected, since it causes the build to fail. > > > > Signed-off-by: Myles Watson > > Great work, thanks! Quick review below: Sure. Thanks for the comments. > > > Index: adlo/elf/elf-header-065kb.payload > > Index: adlo/elf/elf-header-068kb.payload > > Not sure I like storing blobs in svn. How were they generated? By hand with a hex editor. If > possible we should store the "source" or some scripts which generates > them on-the-fly in svn? This won't hold up a commit though, can be > done later. Hm, seems they're hand-crafted, but I'd still like a > small script which "crafts" them better than storing blobs nobody > can read or understand. I'd love a script that crafts them. Using readelf -a and trial and error gets old. > > Also, v2's ADLO has three of those, what's the difference to these? There used to be a 64K payload for the 16-bit BIOS and a 128K payload for the 32-bit BIOS that added other features like ACPI. Now the 32-bit BIOS fits into 64K, so no need for the 128-bit ELF headers. The reason there are two is that I hope to be able to use kexec to load ADLO so that the kernel can initialize all the hardware on the motherboard correctly. Kexec can't handle ELFs that have data that isn't page-aligned. The 68K payload has that 4K-aligned loader. > > > > Index: adlo/loader.s > > =================================================================== > > --- adlo/loader.s (revision 0) > > +++ adlo/loader.s (revision 0) > > @@ -0,0 +1,467 @@ > > +;***************************************************** > > +; $Id: loader.s,v 1.1 2002/11/25 02:07:53 rminnich Exp $ > > +;***************************************************** > > Hm, who wrote this code originally and what license applies? > > Juding from > > http://tracker.coreboot.org/trac/coreboot/log/trunk/LinuxBIOSv1/util/ADLO? > rev=702 > > http://tracker.coreboot.org/trac/coreboot/browser/trunk/LinuxBIOSv1/util/A > DLO/README.1st?rev=702 > > http://tracker.coreboot.org/trac/coreboot/browser/trunk/LinuxBIOSv1/util/A > DLO/CAST?rev=702 > it seems the code was checked in by Ron, but actually implemented by > Adam Sulmicki with the help of others: > > "Most of the analysis, design and implementation of the project was > done by > me, Adam Sulmicki." > > Is this correct? Good question. I haven't been around this project that long. Ron? I'm hoping we'll replace it very soon, though. > > There's a copy of the GPLv2 in the original ADLO directory, so I think we > can safely assume the code to be GPLv2, right? I would assume that too. > > > Index: adlo/align.patch > > =================================================================== > > --- adlo/align.patch (revision 0) > > +++ adlo/align.patch (revision 0) > > @@ -0,0 +1,105 @@ > > +--- loader.s 2008-02-13 12:12:04.000000000 -0700 > > ++++ loader_4K.s 2008-04-11 15:57:01.000000000 -0600 > > +@@ -2,7 +2,7 @@ > > + ; $Id: loader.s,v 1.1 2002/11/25 02:07:53 rminnich Exp $ > > + ;***************************************************** > > + USE32 > > +-; code it is loaded into memory at 0x7C00 > > ++; code it is loaded into memory at 0x7000 > > Why? Please explain. Is this board-specific or payload-specific? > Can it be a variable, selectable in a config file later? > Surely in buildrom, but also for manual builds... This is part of what should go away. The BIOS has to get loaded at the correct address for callbacks to work. This loader needs to get loaded somewhere else, then copy its payload to the right spot. I'd love for the loading part to get taken over by Coreboot. Then we could just set up the CMOS values separately and not depend on being loaded into a hard-coded location in RAM. > > > > Index: packages/adlo/adlo.mk > > =================================================================== > > --- packages/adlo/adlo.mk (revision 0) > > +++ packages/adlo/adlo.mk (revision 0) > [...] > > +ifeq ($(CONFIG_VERBOSE),y) > > +ADLO_FETCH_LOG=/dev/stdout > > +ADLO_BUILD_LOG=/dev/stdout > > +else > > +ADLO_BUILD_LOG=$(ADLO_LOG_DIR)/build.log > > +ADLO_FETCH_LOG=$(ADLO_LOG_DIR)/fetch.log > > +endif > > Unrelated, but this stuff is pretty generic in all buildrom "packages", > might be worth to move to a generic *.inc file later... I agree. > > > +# Make sure we have the tools we need to accomplish this > > +HAVE_AS86:=$(call find-tool,as86) > > + > > +ifeq ($(HAVE_AS86),n) > > +$(error To build ADLO, you need to install as86, available in dev86) > > +endif > > This is needed for ADLO but not legacybios? Can we also change ADLO > to not require it, or is that impossible? I hope someone will do it soon. It would take me some time, since I'm not really familiar with assembly, but it really isn't too much code. > > > > +ADLO_CONFIG=$(PACKAGE_DIR)/adlo/conf/defconfig > > There's no such file in your patch, unless I'm missing something. Yep. I'll remove that line. > > > +ADLO_TARBALL=adlo-svn-$(ADLO_TAG).tar.gz > > + > > +$(SOURCE_DIR)/$(ADLO_TARBALL): | $(ADLO_LOG_DIR) > > + @ mkdir -p $(SOURCE_DIR)/adlo > > + @ $(BIN_DIR)/fetchsvn.sh $(ADLO_URL) $(SOURCE_DIR)/adlo \ > > + $(ADLO_TAG) $(SOURCE_DIR)/$(ADLO_TARBALL) \ > > + > $(ADLO_FETCH_LOG) 2>&1 > > + > > +$(ADLO_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(ADLO_TARBALL) | > $(ADLO_STAMP_DIR) $(ADLO_LOG_DIR) $(ADLO_DIR) > > + @ echo "Unpacking adlo..." > > Let's use "ADLO" in strings everywhere, as that seems to be the > "official" name. Sure. Once we replace the loader there will be nothing left of the original but the name, but the name's fine. > > > + @ tar -C $(ADLO_DIR) -zxf $(SOURCE_DIR)/$(ADLO_TARBALL) > > + @ ln -s $(LEGACYBIOS_SRC_DIR)/out/ $(ADLO_DIR)/svn/legacybios > > + @ touch $@ > > + > > + > > +$(ADLO_SRC_DIR)/adlo.elf: $(ADLO_STAMP_DIR)/.unpacked > $(LEGACYBIOS_SRC_DIR)/out/rom.bin > > + @ echo "Building adlo..." > > See above. > > > > + @ make -C $(ADLO_SRC_DIR) > $(ADLO_BUILD_LOG) 2>&1 > > + > > +$(ADLO_STAMP_DIR)/.copied: $(ADLO_SRC_DIR)/adlo.elf > > + @ mkdir -p $(shell dirname $(PAYLOAD_ELF)) > > + @ cp $(ADLO_SRC_DIR)/adlo.elf $(PAYLOAD_ELF) > > + @ touch $@ > > + > > +$(ADLO_STAMP_DIR) $(ADLO_LOG_DIR): > > + @ mkdir -p $@ > > + > > +adlo: $(ADLO_STAMP_DIR)/.copied > > + > > +adlo-clean: > > + @ echo "Cleaning adlo..." > > Ditto. > > > > + @ rm -f $(ADLO_STAMP_DIR)/.copied > > +ifneq ($(wildcard $(ADLO_SRC_DIR)/Makefile),) > > + @ $(MAKE) -C $(ADLO_SRC_DIR) clean > /dev/null 2>&1 > > +endif > > + > > +adlo-distclean: > > + @ rm -rf $(ADLO_DIR)/* > > + > > Index: packages/legacybios/legacybios.mk > > =================================================================== > > --- packages/legacybios/legacybios.mk (revision 0) > > +++ packages/legacybios/legacybios.mk (revision 0) > [...] > > +LEGACYBIOS_TARBALL=legacybios-$(LEGACYBIOS_TAG).tar.gz > > +LEGACYBIOS_SOURCE=legacybios-$(LEGACYBIOS_TAG).tar.gz > > Why are both needed? > > > > + > > +ifeq ($(shell if [ -f $(PACKAGE_DIR)/legacybios/conf/customconfig-- > $(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) > > + LEGACYBIOS_CONFIG = customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)- > $(COREBOOT_BOARD) > > +endif > > + > > +$(SOURCE_DIR)/$(LEGACYBIOS_TARBALL): > > + @ mkdir -p $(SOURCE_DIR) > > + @ wget $(WGET_Q) -P $(SOURCE_DIR) > $(LEGACYBIOS_URL)/$(LEGACYBIOS_SOURCE) --output- > document=$(SOURCE_DIR)/$(LEGACYBIOS_TARBALL) > > Not too important, but I'd use -O instead of --output-document, it's > shorter and the rest of the code also uses -O. I'll change it. > > > +$(LEGACYBIOS_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LEGACYBIOS_TARBALL) > | $(LEGACYBIOS_STAMP_DIR) $(LEGACYBIOS_DIR) $(LEGACYBIOS_LOG_DIR) > > + @ echo "Unpacking legacybios..." > > + @ tar -C $(LEGACYBIOS_DIR) -zxf $(SOURCE_DIR)/$(LEGACYBIOS_TARBALL) > > + @ touch $@ > > + > > +$(LEGACYBIOS_SRC_DIR)/out/rom.bin: $(LEGACYBIOS_STAMP_DIR)/.unpacked > > + @ echo "Building legacybios..." > > + @ echo $(LEGACYBIOS_SRC_DIR) > > + @ make -C $(LEGACYBIOS_SRC_DIR) > $(LEGACYBIOS_BUILD_LOG) 2>&1 > > Doesn't work for me. > > Adding 'AVOIDCOMBINE=1' as per legacybios README helps, but there are > still build failures on my box (x86, Linux): > > src/romlayout.S: Assembler messages: > src/romlayout.S:427: Error: attempt to .org/.space backwards? (-1) > src/romlayout.S:490: Fatal error: can't write out/romlayout16.o: Bad value > make[1]: *** [out/romlayout16.o] Error 1 > > Any ideas? > > > > +$(LEGACYBIOS_STAMP_DIR) $(LEGACYBIOS_LOG_DIR): > > + @ mkdir -p $@ > > + > > +legacybios: $(LEGACYBIOS_SRC_DIR)/out/rom.bin > > + > > +legacybios-clean: > > + @ echo "Cleaning legacybios..." > > + @ rm -f $(LEGACYBIOS_STAMP_DIR)/.copied > > +ifneq ($(wildcard $(LEGACYBIOS_SRC_DIR)/Makefile),) > > + @ $(MAKE) -C $(LEGACYBIOS_SRC_DIR) clean > /dev/null 2>&1 > > +endif > > + > > +legacybios-distclean: > > + @ rm -rf $(LEGACYBIOS_DIR)/* > > + > > > Index: config/payloads/Config.in > > =================================================================== > > --- config/payloads/Config.in (revision 170) > > +++ config/payloads/Config.in (working copy) > > @@ -9,6 +9,9 @@ > > help > > Buildrom can build a number of different payloads for the ROM > > > > +config PAYLOAD_ADLO > > + bool "ADLO (Bochs BIOS with a wrapper for Coreboot)" > > Maybe something like > > bool "ADLO (x86 legacy BIOS on top of coreboot)" > > Or just "ADLO" and add more info the kconfig help. ADLO is fine. There wasn't help for any of the other payloads, so I didn't add it for this one. New patch attached. Thanks, Myles > > > HTH, Uwe. > -- > http://www.hermann-uwe.de | http://www.holsham-traders.de > http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: buildrom.adlo.diff Type: application/octet-stream Size: 5740 bytes Desc: not available URL: From uwe at hermann-uwe.de Thu May 1 01:27:26 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 1 May 2008 01:27:26 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <033001c8ab10$dc732820$0023040a@chimp> References: <20080430220859.GA5955@greenwood> <033001c8ab10$dc732820$0023040a@chimp> Message-ID: <20080430232726.GA9643@greenwood> On Wed, Apr 30, 2008 at 04:23:47PM -0600, Myles Watson wrote: > > I think we should move to not wget the tarball but rather get specific git > > versions to make grabbing fixes from git easier (if no release happens > > early enough for our purposes). > > > > I'd rather not live on the edge. Since it's a one-developer project we > should be able to talk him into releases when there's a major change and > it's stabilized, but if it's important to you we can change it. Yes please, I'd really like to get the code via git. We don't _have_ to use HEAD or always update to the latest git version, but we have the _chance_ to easily update to a newer version, no matter if there's a tarball or not. I'm fine using the git version which corresponds to a released tarball in the normal case, but for now (in order to get the fixes for gcc 4.2/4.3) I'd say we use the currently latest git. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From jordan.crouse at amd.com Thu May 1 01:32:23 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 30 Apr 2008 17:32:23 -0600 Subject: [coreboot] ADLO for buildrom In-Reply-To: <20080430232726.GA9643@greenwood> References: <20080430220859.GA5955@greenwood> <033001c8ab10$dc732820$0023040a@chimp> <20080430232726.GA9643@greenwood> Message-ID: <20080430233223.GJ21304@cosmic.amd.com> On 01/05/08 01:27 +0200, Uwe Hermann wrote: > On Wed, Apr 30, 2008 at 04:23:47PM -0600, Myles Watson wrote: > > > I think we should move to not wget the tarball but rather get specific git > > > versions to make grabbing fixes from git easier (if no release happens > > > early enough for our purposes). > > > > > > > I'd rather not live on the edge. Since it's a one-developer project we > > should be able to talk him into releases when there's a major change and > > it's stabilized, but if it's important to you we can change it. > > Yes please, I'd really like to get the code via git. We don't _have_ to > use HEAD or always update to the latest git version, but we have the > _chance_ to easily update to a newer version, no matter if there's a > tarball or not. > > I'm fine using the git version which corresponds to a released tarball > in the normal case, but for now (in order to get the fixes for gcc 4.2/4.3) > I'd say we use the currently latest git. I just want to say - fear the git fetcher in buildrom. There be dragons. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From stepan at coresystems.de Thu May 1 01:41:50 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 01 May 2008 01:41:50 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <030a01c8aadd$7cc99860$0023040a@chimp> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <20080430160732.GC21304@cosmic.amd.com> <030a01c8aadd$7cc99860$0023040a@chimp> Message-ID: <481903BE.8010605@coresystems.de> Myles Watson wrote: > >> -----Original Message----- >> From: Jordan Crouse [mailto:jordan.crouse at amd.com] >> Sent: Wednesday, April 30, 2008 10:08 AM >> To: Myles Watson >> Cc: Coreboot >> Subject: Re: ADLO for buildrom >> >> I don't know what the history of the ADLO code is - any reason why we >> can't >> give it a home in payloads/ on SVN instead of living in the buildrom >> code? >> > > I don't think so. The old code was in v2's tree under utils/ > > I didn't think it was too big of a deal, since it's only one assembly file, > a make file, and two elf headers. I admit it looks like a lot with all the > documentation. > > I'm happy to have it live wherever's best. Who has to set that up? > > Thanks, > Myles > > > For v3 we should really integrate the one assembly file rewritten in C as part of coreboot. It's a loader, just it doesnt load elf or self, but a rombios.bin... From uwe at hermann-uwe.de Thu May 1 01:37:41 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 1 May 2008 01:37:41 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <033101c8ab11$008b6bf0$0023040a@chimp> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <20080430160732.GC21304@cosmic.amd.com> <030a01c8aadd$7cc99860$0023040a@chimp> <20080430161852.GD21304@cosmic.amd.com> <2831fecf0804301021t2e3651c6t3bacaf8b0d9fbe4d@mail.gmail.com> <20080430210124.GB31307@greenwood> <033101c8ab11$008b6bf0$0023040a@chimp> Message-ID: <20080430233740.GB9643@greenwood> On Wed, Apr 30, 2008 at 04:24:47PM -0600, Myles Watson wrote: > > > Index: adlo/elf/elf-header-065kb.payload > > > Index: adlo/elf/elf-header-068kb.payload > > > > Not sure I like storing blobs in svn. How were they generated? > > By hand with a hex editor. > > If > > possible we should store the "source" or some scripts which generates > > them on-the-fly in svn? This won't hold up a commit though, can be > > done later. Hm, seems they're hand-crafted, but I'd still like a > > small script which "crafts" them better than storing blobs nobody > > can read or understand. > > I'd love a script that crafts them. Using readelf -a and trial and error > gets old. Yep, we should put this on a TODO list (trac). > > Also, v2's ADLO has three of those, what's the difference to these? > > There used to be a 64K payload for the 16-bit BIOS and a 128K payload for > the 32-bit BIOS that added other features like ACPI. Now the 32-bit BIOS > fits into 64K, so no need for the 128-bit ELF headers. The reason there are > two is that I hope to be able to use kexec to load ADLO so that the kernel > can initialize all the hardware on the motherboard correctly. Kexec can't > handle ELFs that have data that isn't page-aligned. The 68K payload has > that 4K-aligned loader. OK, fine. Would it hurt to use the aligned version for non-kexec too? Any drawbacks? > > > Index: adlo/loader.s > > > =================================================================== > > > --- adlo/loader.s (revision 0) > > > +++ adlo/loader.s (revision 0) > > > @@ -0,0 +1,467 @@ > > > +;***************************************************** > > > +; $Id: loader.s,v 1.1 2002/11/25 02:07:53 rminnich Exp $ > > > +;***************************************************** > > > > Hm, who wrote this code originally and what license applies? > > > > Juding from > > > > http://tracker.coreboot.org/trac/coreboot/log/trunk/LinuxBIOSv1/util/ADLO? > > rev=702 > > > > http://tracker.coreboot.org/trac/coreboot/browser/trunk/LinuxBIOSv1/util/A > > DLO/README.1st?rev=702 > > > > http://tracker.coreboot.org/trac/coreboot/browser/trunk/LinuxBIOSv1/util/A > > DLO/CAST?rev=702 > > it seems the code was checked in by Ron, but actually implemented by > > Adam Sulmicki with the help of others: > > > > "Most of the analysis, design and implementation of the project was > > done by > > me, Adam Sulmicki." > > > > Is this correct? > > Good question. I haven't been around this project that long. Ron? > > I'm hoping we'll replace it very soon, though. OK, then it probably doesn't matter much. If and how can the loader be integrated upstream? That's probably the best place to store it, correct? > > > +-; code it is loaded into memory at 0x7C00 > > > ++; code it is loaded into memory at 0x7000 > > > > Why? Please explain. Is this board-specific or payload-specific? > > Can it be a variable, selectable in a config file later? > > Surely in buildrom, but also for manual builds... > > This is part of what should go away. The BIOS has to get loaded at the > correct address for callbacks to work. This loader needs to get loaded > somewhere else, then copy its payload to the right spot. I'd love for the > loading part to get taken over by Coreboot. Then we could just set up the > CMOS values separately and not depend on being loaded into a hard-coded > location in RAM. Can you elaborate? What would coreboot need to do exactly (in addition what we already to for other payloads)? Is any of that board-specific? What do you mean with CMOS values here? Where are they used in ADLO? Not yet, but you plan to do later? > > This is needed for ADLO but not legacybios? Can we also change ADLO > > to not require it, or is that impossible? > > I hope someone will do it soon. It would take me some time, since I'm not > really familiar with assembly, but it really isn't too much code. OK, sounds good. So there's not _real_ reason to continue using it. > > Let's use "ADLO" in strings everywhere, as that seems to be the > > "official" name. > > Sure. Once we replace the loader there will be nothing left of the original > but the name, but the name's fine. Hm, if it's completely gone later, I think we should also eliminate the ADLO name (but not just yet). It's just coreboot+legacybios then, correct? So we'll probably call it legacybios (or BOCHS BIOS?). We'll see... > > > Index: packages/legacybios/legacybios.mk > > > =================================================================== > > > --- packages/legacybios/legacybios.mk (revision 0) > > > +++ packages/legacybios/legacybios.mk (revision 0) > > [...] > > > +LEGACYBIOS_TARBALL=legacybios-$(LEGACYBIOS_TAG).tar.gz > > > +LEGACYBIOS_SOURCE=legacybios-$(LEGACYBIOS_TAG).tar.gz > > > > Why are both needed? Is this required? Testing the code now in QEMU and hardware, will report back. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From stepan at coresystems.de Thu May 1 01:44:37 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 01 May 2008 01:44:37 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <20080430181838.GF21304@cosmic.amd.com> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <20080430160732.GC21304@cosmic.amd.com> <030a01c8aadd$7cc99860$0023040a@chimp> <20080430161852.GD21304@cosmic.amd.com> <2831fecf0804301021t2e3651c6t3bacaf8b0d9fbe4d@mail.gmail.com> <20080430181838.GF21304@cosmic.amd.com> Message-ID: <48190465.9060107@coresystems.de> Jordan Crouse wrote: > On 30/04/08 11:21 -0600, Myles Watson wrote: > >> On Wed, Apr 30, 2008 at 10:18 AM, Jordan Crouse wrote: >> >>> On 30/04/08 10:16 -0600, Myles Watson wrote: >>> > >>> > >>> > > -----Original Message----- >>> > > From: Jordan Crouse [mailto:jordan.crouse at amd.com] >>> > > Sent: Wednesday, April 30, 2008 10:08 AM >>> > > To: Myles Watson >>> > > Cc: Coreboot >>> > > Subject: Re: ADLO for buildrom >>> > > >>> > > I don't know what the history of the ADLO code is - any reason why we >>> > > can't >>> > > give it a home in payloads/ on SVN instead of living in the buildrom >>> > > code? >>> > >>> > I don't think so. The old code was in v2's tree under utils/ >>> > >>> > I didn't think it was too big of a deal, since it's only one assembly file, >>> > a make file, and two elf headers. I admit it looks like a lot with all the >>> > documentation. >>> > >>> > I'm happy to have it live wherever's best. Who has to set that up? >>> >>> Its all set up - just push - I recommend payloads/adlo. >>> >> Here are two patches. One adds a lightened ADLO to payloads/adlo. >> The other adds ADLO to buildrom. >> >> The only non-specific change is an error if there is no payload >> selected, since it causes the build to fail. >> >> Signed-off-by: Myles Watson >> > > Acked-by: Jordan Crouse x 2 > If you're going to add it to payloads/ please remove it from utils/ - we don't need several copies floating around. From stepan at coresystems.de Thu May 1 01:47:17 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 01 May 2008 01:47:17 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <032301c8aaf8$cceca010$0023040a@chimp> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com><20080430160732.GC21304@cosmic.amd.com><030a01c8aadd$7cc99860$0023040a@chimp><20080430161852.GD21304@cosmic.amd.com><2831fecf0804301021t2e3651c6t3bacaf8b0d9fbe4d@mail.gmail.com><20080430181838.GF21304@cosmic.amd.com> <20080430183225.GA2806@greenwood> <032301c8aaf8$cceca010$0023040a@chimp> Message-ID: <48190505.7040200@coresystems.de> Myles Watson wrote: > There is very little duplicated here. The ADLO in coreboot relies on > building the BOCHS bios from source with dev86, but the payloads/adlo uses > the new legacybios version. The only thing that is exactly the same is one > of the elf headers. please also note we have a gsoc student working on legacy bios integration again this summer. maybe we should stop the plenty discussion here and leave things as they are until that project is done? Does legacybios from Kevin O'Connor boot Vista? From stepan at coresystems.de Thu May 1 01:48:26 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 01 May 2008 01:48:26 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <032401c8aaf8$f4920240$0023040a@chimp> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <79a45e0eb2a61094b7bf4cd9e4574846@imap.1and1.com> <032401c8aaf8$f4920240$0023040a@chimp> Message-ID: <4819054A.3010502@coresystems.de> Myles Watson wrote: >> On Wed, 30 Apr 2008 09:58:56 -0600, "Myles Watson" >> wrote: >> >>> It boots Windows XP in QEMU. >>> >> Sweet:-) >> >> What about booting XP on real hardware? >> > > The loader needs to be customized for each board, or we need to pass some > information like RAM map from coreboot before that will work. > Which is why it really should, no, it has to be built into coreboot itself. coreboot already has all the knowledge required for this. Duplicating efforts that we did in C in another assembler chunk is plain b0rked. From stepan at coresystems.de Thu May 1 01:51:04 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 01 May 2008 01:51:04 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <20080430194926.GA31307@greenwood> References: <20080430183225.GA2806@greenwood> <032301c8aaf8$cceca010$0023040a@chimp> <20080430194926.GA31307@greenwood> Message-ID: <481905E8.7050604@coresystems.de> Uwe Hermann wrote: > On Wed, Apr 30, 2008 at 01:31:33PM -0600, Myles Watson wrote: > >> There is very little duplicated here. The ADLO in coreboot relies on >> building the BOCHS bios from source with dev86, but the payloads/adlo uses >> the new legacybios version. The only thing that is exactly the same is one >> of the elf headers. >> > > Can you elaborate? I think I never heard of legacybios so far. What's > the purpose and history and relation to ADLO of that? Does it _replace_ > ADLO completely or enhance it or... ? Also, from a quick glance it > doesn't seem to be written specifically for coreboot, what's the > original purpose (just curious)? > > Do you have a comparison between ADLO as in v2 svn vs. legacybios? > > Please please please do not make 5 trees in 5 places with different copies of ADLO and its legacy bios. This is not the way to go. 1. if it needs to be moved to payloads/ lets move it. 2. if we should switch to legacybios from Kevin O'Connor let's do this too, or lets leave a choice. > Also note that legacybios is GPLv3, not sure if that's a problem > for us. Do we link GPLv2 code against that? It's not linked in at any point. It's loaded. Just like the linux kernel loads ELF files. At least for v3 we can say for sure. From jakllsch at kollasch.net Thu May 1 01:54:17 2008 From: jakllsch at kollasch.net (Jonathan A. Kollasch) Date: Wed, 30 Apr 2008 23:54:17 +0000 Subject: [coreboot] [PATCH] MS7135 fixes and updates In-Reply-To: <20080430170956.GA9751@localdomain> References: <20080430152113.GG2542@tazenda.kollasch.net> <38e01fded9f7969fdcffcd8b0661b2be@imap.1and1.com> <20080430170956.GA9751@localdomain> Message-ID: <20080430235417.GI2542@tazenda.kollasch.net> On Wed, Apr 30, 2008 at 01:09:56PM -0400, Ward Vandewege wrote: > On Wed, Apr 30, 2008 at 01:03:21PM -0400, Joe wrote: > > > > > > > > On Wed, 30 Apr 2008 15:21:13 +0000, "Jonathan A. Kollasch" > > wrote: > > > Fix various issues on MSI MS7135 board. > > > > > > - enable floppy drive controller so that some legacy VGA ROMs will work > > > > Little confused by this. Why does the floppy drive controller have to be > > enabled for VGA?? > > I think this might be a 'feature' of the proprietary VGA ROM... Who knows > why - there's no source... Yeah, I found that a RV370 board I have was working when the superio address was wrong, because the floppy controller was in the power-on-reset state of enabled. When I corrected the superio address, and the FDC got disabled as instructed, the VGA BIOS did weird things I don't exactly recall and didn't work. I then tried enabling the FDC again and found that this made the VGA BIOS work again. I have no idea why it wants to touch the floppy controller, but I have to let it or it won't work. Jonathan Kollasch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From stepan at coresystems.de Thu May 1 01:58:50 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 01 May 2008 01:58:50 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <032801c8aafc$e3a808e0$0023040a@chimp> References: <20080430183225.GA2806@greenwood> <032301c8aaf8$cceca010$0023040a@chimp> <20080430194926.GA31307@greenwood> <032801c8aafc$e3a808e0$0023040a@chimp> Message-ID: <481907BA.7070505@coresystems.de> Myles Watson wrote: > Legacybios is the Bochs BIOS ported to compile on gcc instead of with the > dev86 tools. Kevin's intent (I'm paraphrasing) was to make it easy to > update the BIOS so that more developers would be able to fix/improve it. He > hoped that the ability to boot operating systems with BIOS callbacks would > make Coreboot more popular as well. > Is it tested and reliable in depth anywhere close to Qemu/Bochs BIOS? Or are we exchanging a fragile piece of code with a fragile and untested one? The latest legacybios (0.2.0) was very bochs/qemu dependent, ie. it expected ram size reported in cmos instead of reading lbtable. We should definitely have a #define COMPILE_FOR_COREBOOT in either legacybios or bochs/qemu bios. I am all for using legacybios with coreboot, and we should not only use it for ADLO but also for our vga init code (which implements half a legacy bios, too) And for loading blocks from SCSI controllers with int13. Lets clean this up once and forever. I am copying Zhang Rui on this mail. He is the guy who is going to work on booting from SCSI (or, more generically int13 callback based boot devices) for our GSoC project. > ADLO in v2 is based on a very old version of Bochs' BIOS that has many > timing problems (e.g., small loops that were supposed to wait until the CD > spun up.) The new Bochs BIOS as compiled with dev86 is 128K, while Kevin's > version is 64K. After compression with lzma this makes it very attractive > for a fallback payload to be able to boot from a rescue CD. > ADLO itself is just the assembler loader. It is not at all based on any legacy bios. Last years GSoC used ADLO with the latest BOCHS bios to boot more flavours of windows From rminnich at gmail.com Thu May 1 02:06:50 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 30 Apr 2008 17:06:50 -0700 Subject: [coreboot] ADLO for buildrom In-Reply-To: <033101c8ab11$008b6bf0$0023040a@chimp> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <20080430160732.GC21304@cosmic.amd.com> <030a01c8aadd$7cc99860$0023040a@chimp> <20080430161852.GD21304@cosmic.amd.com> <2831fecf0804301021t2e3651c6t3bacaf8b0d9fbe4d@mail.gmail.com> <20080430210124.GB31307@greenwood> <033101c8ab11$008b6bf0$0023040a@chimp> Message-ID: <13426df10804301706t1cf6b4a8j4d7f8ebaf375db6d@mail.gmail.com> On Wed, Apr 30, 2008 at 3:24 PM, Myles Watson wrote: >> "Most of the analysis, design and implementation of the project was >> done by >> me, Adam Sulmicki." >> >> Is this correct? > > Good question. I haven't been around this project that long. Ron? Adam did all the work at U. MD. I guess I committed it? Memory fails. ron From uwe at hermann-uwe.de Thu May 1 02:11:23 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 1 May 2008 02:11:23 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <4819054A.3010502@coresystems.de> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <79a45e0eb2a61094b7bf4cd9e4574846@imap.1and1.com> <032401c8aaf8$f4920240$0023040a@chimp> <4819054A.3010502@coresystems.de> Message-ID: <20080501001123.GC9643@greenwood> On Thu, May 01, 2008 at 01:48:26AM +0200, Stefan Reinauer wrote: > Myles Watson wrote: > >> On Wed, 30 Apr 2008 09:58:56 -0600, "Myles Watson" > >> wrote: > >> > >>> It boots Windows XP in QEMU. > >>> > >> Sweet:-) > >> > >> What about booting XP on real hardware? > >> > > > > The loader needs to be customized for each board, or we need to pass some > > information like RAM map from coreboot before that will work. > > > > Which is why it really should, no, it has to be built into coreboot > itself. coreboot already has all the knowledge required for this. > Duplicating efforts that we did in C in another assembler chunk is plain > b0rked. Full ACK, if this could be a snippet of C code in coreboot that would be fantastic! Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From stepan at coresystems.de Thu May 1 02:16:49 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 01 May 2008 02:16:49 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <20080501001123.GC9643@greenwood> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <79a45e0eb2a61094b7bf4cd9e4574846@imap.1and1.com> <032401c8aaf8$f4920240$0023040a@chimp> <4819054A.3010502@coresystems.de> <20080501001123.GC9643@greenwood> Message-ID: <48190BF1.4020904@coresystems.de> Uwe Hermann wrote: > On Thu, May 01, 2008 at 01:48:26AM +0200, Stefan Reinauer wrote: > >> Myles Watson wrote: >> >>>> On Wed, 30 Apr 2008 09:58:56 -0600, "Myles Watson" >>>> wrote: >>>> >>>> >>>>> It boots Windows XP in QEMU. >>>>> >>>>> >>>> Sweet:-) >>>> >>>> What about booting XP on real hardware? >>>> >>>> >>> The loader needs to be customized for each board, or we need to pass some >>> information like RAM map from coreboot before that will work. >>> >>> >> Which is why it really should, no, it has to be built into coreboot >> itself. coreboot already has all the knowledge required for this. >> Duplicating efforts that we did in C in another assembler chunk is plain >> b0rked. >> > > Full ACK, if this could be a snippet of C code in coreboot that would be > fantastic! > The main question is who holds the know how on how to enable/disable write protection and shadowing of the e and f segment. And: Whether we need to care at all. Can't we just leave that space writable and rely on the OS not trying to overwrite the machine's BIOS? I would be surprised if any OS really tried that. From bari at onelabs.com Thu May 1 02:20:06 2008 From: bari at onelabs.com (bari) Date: Wed, 30 Apr 2008 19:20:06 -0500 Subject: [coreboot] ADLO for buildrom In-Reply-To: <13426df10804301706t1cf6b4a8j4d7f8ebaf375db6d@mail.gmail.com> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <20080430160732.GC21304@cosmic.amd.com> <030a01c8aadd$7cc99860$0023040a@chimp> <20080430161852.GD21304@cosmic.amd.com> <2831fecf0804301021t2e3651c6t3bacaf8b0d9fbe4d@mail.gmail.com> <20080430210124.GB31307@greenwood> <033101c8ab11$008b6bf0$0023040a@chimp> <13426df10804301706t1cf6b4a8j4d7f8ebaf375db6d@mail.gmail.com> Message-ID: <48190CB6.1030104@onelabs.com> ADLO committed Ronald G. Minnich Sun, 24 Nov 2002 http://www.mail-archive.com/linuxbios at clustermatic.org/msg01136.html Hey, what's 5.5 years? ron minnich wrote: > On Wed, Apr 30, 2008 at 3:24 PM, Myles Watson wrote: > > >>> "Most of the analysis, design and implementation of the project was >>> done by >>> me, Adam Sulmicki." >>> >>> Is this correct? >>> >> Good question. I haven't been around this project that long. Ron? >> > > Adam did all the work at U. MD. I guess I committed it? Memory fails. > > ron > > From uwe at hermann-uwe.de Thu May 1 02:22:25 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 1 May 2008 02:22:25 +0200 Subject: [coreboot] [PATCH] MS7135 fixes and updates In-Reply-To: <20080430152113.GG2542@tazenda.kollasch.net> References: <20080430152113.GG2542@tazenda.kollasch.net> Message-ID: <20080501002225.GD9643@greenwood> On Wed, Apr 30, 2008 at 03:21:13PM +0000, Jonathan A. Kollasch wrote: > Fix various issues on MSI MS7135 board. > > - w83627thf is strapped to 0x4e, not 0x2e > - there's no device 9 on PCI-E x1 bus, it should be device 0 > - add mptable entries for AGR slot, based on info in user manual > - enable floppy drive controller so that some legacy VGA ROMs will work > > Signed-off-by: Jonathan A. Kollasch Acked-by: Uwe Hermann > - device pnp 2e.6 off end # non-existant or undocumented > - device pnp 2e.7 off end # Game, MIDI, GPIO 1, GPIO 5 > - device pnp 2e.8 off end # GPIO 2 > - device pnp 2e.9 off end # GPIO 3, GPIO 4 > - device pnp 2e.a off end # ACPI > - device pnp 2e.b on # env monitor > + device pnp 4e.6 off end # unknown LDN 6 is undocumented in the datasheet, might even not exist. Did you test if removing the line has problematic effects? Or do you have a reason to believe there's something on that LDN? Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From jakllsch at kollasch.net Thu May 1 03:09:01 2008 From: jakllsch at kollasch.net (Jonathan A. Kollasch) Date: Thu, 1 May 2008 01:09:01 +0000 Subject: [coreboot] [PATCH] MS7135 fixes and updates In-Reply-To: <20080501002225.GD9643@greenwood> References: <20080430152113.GG2542@tazenda.kollasch.net> <20080501002225.GD9643@greenwood> Message-ID: <20080501010901.GJ2542@tazenda.kollasch.net> On Thu, May 01, 2008 at 02:22:25AM +0200, Uwe Hermann wrote: > On Wed, Apr 30, 2008 at 03:21:13PM +0000, Jonathan A. Kollasch wrote: > > Fix various issues on MSI MS7135 board. > > > > - w83627thf is strapped to 0x4e, not 0x2e > > - there's no device 9 on PCI-E x1 bus, it should be device 0 > > - add mptable entries for AGR slot, based on info in user manual > > - enable floppy drive controller so that some legacy VGA ROMs will work > > > > Signed-off-by: Jonathan A. Kollasch > > Acked-by: Uwe Hermann > > > > - device pnp 2e.6 off end # non-existant or undocumented > > - device pnp 2e.7 off end # Game, MIDI, GPIO 1, GPIO 5 > > - device pnp 2e.8 off end # GPIO 2 > > - device pnp 2e.9 off end # GPIO 3, GPIO 4 > > - device pnp 2e.a off end # ACPI > > - device pnp 2e.b on # env monitor > > > > + device pnp 4e.6 off end # unknown > > LDN 6 is undocumented in the datasheet, might even not exist. > Did you test if removing the line has problematic effects? Or do you > have a reason to believe there's something on that LDN? I don't think I've really tested it. Does having a LDN unlisted in Config.lb mean it doesn't get touched? If that's the case that LDN should just be omitted there. It probably is unimplemented. (It is implemented in the W83627EHG, apparently. But i have a THG on this board.) Jonathan Kollasch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From kevin at koconnor.net Thu May 1 03:53:43 2008 From: kevin at koconnor.net (Kevin O'Connor) Date: Wed, 30 Apr 2008 21:53:43 -0400 Subject: [coreboot] ADLO for buildrom In-Reply-To: <481907BA.7070505@coresystems.de> References: <20080430183225.GA2806@greenwood> <032301c8aaf8$cceca010$0023040a@chimp> <20080430194926.GA31307@greenwood> <032801c8aafc$e3a808e0$0023040a@chimp> <481907BA.7070505@coresystems.de> Message-ID: <20080501015343.GA9771@morn.localdomain> On Thu, May 01, 2008 at 01:58:50AM +0200, Stefan Reinauer wrote: > Myles Watson wrote: > > > Legacybios is the Bochs BIOS ported to compile on gcc instead of with the > > dev86 tools. Kevin's intent (I'm paraphrasing) was to make it easy to > > update the BIOS so that more developers would be able to fix/improve it. He > > hoped that the ability to boot operating systems with BIOS callbacks would > > make Coreboot more popular as well. Thanks Myles, that is a good summary. > Is it tested and reliable in depth anywhere close to Qemu/Bochs BIOS? Or > are we exchanging a fragile piece of code with a fragile and untested one? What I have tested: booting linux, freedos, netbsd from floppy, cdrom, and hard drives from qemu. I have reports of Windows XP working as well. > The latest legacybios (0.2.0) was very bochs/qemu dependent, ie. it > expected ram size reported in cmos instead of reading lbtable. We should > definitely have a > #define COMPILE_FOR_COREBOOT in either legacybios or bochs/qemu bios. The legacybios code is currently just a port of bochs bios to gcc. I know of no additional hardware restrictions that it imposes. I'm working on going through all the external hardware dependencies that bochs bios/legacybios impose - I plan to send an email when I have the list completed. Unfortunately, my home machine "blew up" some time back, and the headache of getting a replacement machine has set me back about a month. :-( -Kevin From kevin at koconnor.net Thu May 1 03:56:02 2008 From: kevin at koconnor.net (Kevin O'Connor) Date: Wed, 30 Apr 2008 21:56:02 -0400 Subject: [coreboot] ADLO for buildrom In-Reply-To: <48190505.7040200@coresystems.de> References: <20080430183225.GA2806@greenwood> <032301c8aaf8$cceca010$0023040a@chimp> <48190505.7040200@coresystems.de> Message-ID: <20080501015602.GB9771@morn.localdomain> On Thu, May 01, 2008 at 01:47:17AM +0200, Stefan Reinauer wrote: > Does legacybios from Kevin O'Connor boot Vista? I don't have any reports either way. I don't own Vista so can't test for myself. I do hope to get a copy to test with. If Bochs Bios can boot Vista I would think legacybios could as well, and vice-versa. -Kevin From kevin at koconnor.net Thu May 1 04:14:57 2008 From: kevin at koconnor.net (Kevin O'Connor) Date: Wed, 30 Apr 2008 22:14:57 -0400 Subject: [coreboot] ADLO for buildrom In-Reply-To: <20080430232726.GA9643@greenwood> References: <20080430220859.GA5955@greenwood> <033001c8ab10$dc732820$0023040a@chimp> <20080430232726.GA9643@greenwood> Message-ID: <20080501021457.GC9771@morn.localdomain> On Thu, May 01, 2008 at 01:27:26AM +0200, Uwe Hermann wrote: > On Wed, Apr 30, 2008 at 04:23:47PM -0600, Myles Watson wrote: > > I'd rather not live on the edge. Since it's a one-developer project we > > should be able to talk him into releases when there's a major change and > > it's stabilized, but if it's important to you we can change it. > > Yes please, I'd really like to get the code via git. We don't _have_ to > use HEAD or always update to the latest git version, but we have the > _chance_ to easily update to a newer version, no matter if there's a > tarball or not. > > I'm fine using the git version which corresponds to a released tarball > in the normal case, but for now (in order to get the fixes for gcc 4.2/4.3) > I'd say we use the currently latest git. I tagged 'rel-0.2.2' today. I also uploaded tar files and compiled binaries to: http://linuxtogo.org/~kevin/legacybios/ -Kevin From kevin at koconnor.net Thu May 1 04:25:18 2008 From: kevin at koconnor.net (Kevin O'Connor) Date: Wed, 30 Apr 2008 22:25:18 -0400 Subject: [coreboot] ADLO for buildrom In-Reply-To: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> Message-ID: <20080501022518.GD9771@morn.localdomain> On Wed, Apr 30, 2008 at 09:58:56AM -0600, Myles Watson wrote: > This patch adds ADLO to buildrom using the gcc ported BOCHS BIOS. It > boots Windows XP in QEMU. Thanks Myles! >It still needs as86 to be installed because > I didn't port the loader yet. Porting the loader from as86 style assembler to gas should be pretty simple. (In fact, I wonder if just telling gas to use intel syntax would make it work.) However, ultimately I think the logic should just be ported to C code. >Other things like making the loader > understand the coreboot information to get the RAM map would be nice > too. I think we're going to need to teach legacybios about coreboot (and maybe add some new things to coreboot). I'd prefer not require a special shim between the code just to pass the handful of parameters around. Thanks again, -Kevin From malateshkamat at gmail.com Thu May 1 09:38:18 2008 From: malateshkamat at gmail.com (malatesh kamatad) Date: Thu, 1 May 2008 13:08:18 +0530 Subject: [coreboot] problem while flashing on Pm49fl004B Message-ID: Hi all. While working on LinuxBios i erased bios content in the origional flashrom chip while doing this my system become strucked at that time when i rebooted the system but system not booted. this is hapened while building the coreboot for MSI board by using the AsRock board ..at the same time my harddisk is also damaged right now i dont have backup file(origional bios ),but in my office i dont have other AsRock motherboard for taking the bios content from that ,but i downloaded the bios content for AsRock board from the website and then i tried to flash that content to the erased flashrom chip but flashing is not happening ..... is there any idea to get my bios back please inform me im in big troble ................ With regards Malatesh kamatad -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.marek at assembler.cz Thu May 1 12:34:08 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Thu, 01 May 2008 12:34:08 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <48190BF1.4020904@coresystems.de> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <79a45e0eb2a61094b7bf4cd9e4574846@imap.1and1.com> <032401c8aaf8$f4920240$0023040a@chimp> <4819054A.3010502@coresystems.de> <20080501001123.GC9643@greenwood> <48190BF1.4020904@coresystems.de> Message-ID: <48199CA0.7060702@assembler.cz> > The main question is who holds the know how on how to enable/disable > write protection and shadowing of the e and f segment. Well this is chipset specific (memory controller). > And: Whether we need to care at all. Can't we just leave that space > writable and rely on the OS not trying to overwrite the machine's BIOS? > I would be surprised if any OS really tried that. This is what I did exactly with the K8T890/VT8237. The chipset has the shadow ram prot bits even if the memory controller is in K8. But hey wrong setup of this caused DMA from HDD to fail if the physical memory target for DMA was in "shadow" memory range. To sum it up. Coreboot should handle this. ADLO/LegacyBIOS whatever should not touch this. We can unprotect the shadows regions in coreboot. All we need is just sane memory map. Rudolf From r.marek at assembler.cz Thu May 1 12:37:28 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Thu, 01 May 2008 12:37:28 +0200 Subject: [coreboot] [PATCH] MS7135 fixes and updates In-Reply-To: <20080501010901.GJ2542@tazenda.kollasch.net> References: <20080430152113.GG2542@tazenda.kollasch.net> <20080501002225.GD9643@greenwood> <20080501010901.GJ2542@tazenda.kollasch.net> Message-ID: <48199D68.7090303@assembler.cz> Just a side note, if the superIO is similar to W83627EHG then you could use virtual LDNs for the different functionality in same LDN which are sharing same enable byte. (I did it for the W83627EHG). http://www.coreboot.org/SuperIO_port_guide Maybe this page is not linked from anywhere? Rudolf From stepan at coresystems.de Thu May 1 12:39:29 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 01 May 2008 12:39:29 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <48199CA0.7060702@assembler.cz> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <79a45e0eb2a61094b7bf4cd9e4574846@imap.1and1.com> <032401c8aaf8$f4920240$0023040a@chimp> <4819054A.3010502@coresystems.de> <20080501001123.GC9643@greenwood> <48190BF1.4020904@coresystems.de> <48199CA0.7060702@assembler.cz> Message-ID: <48199DE1.4030707@coresystems.de> Rudolf Marek wrote: >> The main question is who holds the know how on how to enable/disable >> write protection and shadowing of the e and f segment. > > Well this is chipset specific (memory controller). Exactly. Which is why I think it should not be part of a payload but part of coreboot. >> And: Whether we need to care at all. Can't we just leave that space >> writable and rely on the OS not trying to overwrite the machine's BIOS? >> I would be surprised if any OS really tried that. > > This is what I did exactly with the K8T890/VT8237. The chipset has the > shadow ram prot bits even if the memory controller is in K8. But hey > wrong setup of this caused DMA from HDD to fail if the physical memory > target for DMA was in "shadow" memory range. Ouch. Ok, then there is nasty stuff happening. > To sum it up. Coreboot should handle this. ADLO/LegacyBIOS whatever > should not touch this. We can unprotect the shadows regions in > coreboot. All we need is just sane memory map. Absolutely. From rms at gnu.org Thu May 1 12:11:14 2008 From: rms at gnu.org (Richard M Stallman) Date: Thu, 01 May 2008 06:11:14 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <4818A556.6060900@gnu.org> (message from arc on Wed, 30 Apr 2008 18:59:02 +0200) References: <4818A556.6060900@gnu.org> Message-ID: You have no hope of influencing a large company through channels like this one. You are talking with a low-level person who has no authority to change anything, and whose job is only to try to convince you to accept what Intel is doing. What you got is therefore only the statement Intel uses to justify not cooperating with us. It could be that the Coreboot developers can find statements which are misleading or false, and publish an article which would put pressure on Intel. Some of the points are simply distractions or illogical. For instance: BIOS is a part of the reliability and performance promise of the hardware. Is that true? If so, so what? That is no reason not to let us run our own BIOS. Chipset specifications at the level being discussed are commonly considered proprietary by all silicon vendors, not just Intel. In other words, "Everyone spits on your freedom". Even if it were true, so what? However, it is false: some computer models do work with free BIOS. Intel compares badly with them. This is one of the statements that maybe could be criticized in a published response. The open source firmware work that Intel *is* sponsoring could lead to a solution where proprietary low-level chipset initialization code from silicon vendors is made compatible with open source higher-level platform initialization and pre-boot management. As they say, this is not a complete free BIOS, just part of one. If the "proprietary low-level chipset initialization code" is in ROM on the chips that it initializes, then it is tolerable. (It might as well be circuits on that chip.) Otherwise, it is insufficient unless made complete. From peter at stuge.se Thu May 1 13:10:29 2008 From: peter at stuge.se (Peter Stuge) Date: Thu, 1 May 2008 13:10:29 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <48199CA0.7060702@assembler.cz> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <79a45e0eb2a61094b7bf4cd9e4574846@imap.1and1.com> <032401c8aaf8$f4920240$0023040a@chimp> <4819054A.3010502@coresystems.de> <20080501001123.GC9643@greenwood> <48190BF1.4020904@coresystems.de> <48199CA0.7060702@assembler.cz> Message-ID: <20080501111029.21318.qmail@stuge.se> On Thu, May 01, 2008 at 12:34:08PM +0200, Rudolf Marek wrote: > To sum it up. Coreboot should handle this. ADLO/LegacyBIOS whatever > should not touch this. We can unprotect the shadows regions in > coreboot. All we need is just sane memory map. Is this designing in a callback from payload to coreboot? Or would the shadowing be oneshot before the new biosloader runs? //Peter From r.marek at assembler.cz Thu May 1 13:12:24 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Thu, 01 May 2008 13:12:24 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <20080501111029.21318.qmail@stuge.se> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <79a45e0eb2a61094b7bf4cd9e4574846@imap.1and1.com> <032401c8aaf8$f4920240$0023040a@chimp> <4819054A.3010502@coresystems.de> <20080501001123.GC9643@greenwood> <48190BF1.4020904@coresystems.de> <48199CA0.7060702@assembler.cz> <20080501111029.21318.qmail@stuge.se> Message-ID: <4819A598.1090703@assembler.cz> > Or would the shadowing be oneshot before the new biosloader runs? Definitely one shot. Like the rest of chipset initialization. No need to mess with legacy shadows. Rudolf From stepan at coresystems.de Thu May 1 13:27:13 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 01 May 2008 13:27:13 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <20080501111029.21318.qmail@stuge.se> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <79a45e0eb2a61094b7bf4cd9e4574846@imap.1and1.com> <032401c8aaf8$f4920240$0023040a@chimp> <4819054A.3010502@coresystems.de> <20080501001123.GC9643@greenwood> <48190BF1.4020904@coresystems.de> <48199CA0.7060702@assembler.cz> <20080501111029.21318.qmail@stuge.se> Message-ID: <4819A911.3000809@coresystems.de> Peter Stuge wrote: > On Thu, May 01, 2008 at 12:34:08PM +0200, Rudolf Marek wrote: > >> To sum it up. Coreboot should handle this. ADLO/LegacyBIOS whatever >> should not touch this. We can unprotect the shadows regions in >> coreboot. All we need is just sane memory map. >> > > Is this designing in a callback from payload to coreboot? > To avoid this is the reason why the bios.bin _loader_ must be part of coreboot. The alternative would be to pass a register write sequence description in lbtable. But this is pretty close to a virtual machine already, so we're almost re-inventing ACPI there. Not good. > Or would the shadowing be oneshot before the new biosloader runs? > The registers have to be changed _after_ bios.bin is copied to the E and F segment. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From r.marek at assembler.cz Thu May 1 13:34:25 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Thu, 01 May 2008 13:34:25 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <4819A911.3000809@coresystems.de> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <79a45e0eb2a61094b7bf4cd9e4574846@imap.1and1.com> <032401c8aaf8$f4920240$0023040a@chimp> <4819054A.3010502@coresystems.de> <20080501001123.GC9643@greenwood> <48190BF1.4020904@coresystems.de> <48199CA0.7060702@assembler.cz> <20080501111029.21318.qmail@stuge.se> <4819A911.3000809@coresystems.de> Message-ID: <4819AAC1.4080001@assembler.cz> Just a side note. The ACPI tables needs to be writable by OS, because OS will store there waking vector. If you will protect the F segment where are the ACPI tables stores, suspend to RAM design/implementation would be complicated. I really would go the way I suggested. Leave unprotected, OS should not overwrite parts of memory which are reserved/not reported. Rudolf From joe at settoplinux.org Thu May 1 14:23:44 2008 From: joe at settoplinux.org (Joe) Date: Thu, 01 May 2008 08:23:44 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: References: <4818A556.6060900@gnu.org> Message-ID: On Thu, 01 May 2008 06:11:14 -0400, Richard M Stallman wrote: > You have no hope of influencing a large company through channels like > this one. You are talking with a low-level person who has no > authority to change anything, and whose job is only to try to convince > you to accept what Intel is doing. > > What you got is therefore only the statement Intel uses to justify > not cooperating with us. > > It could be that the Coreboot developers can find statements which are > misleading or false, and publish an article which would put pressure > on Intel. > > Some of the points are simply distractions or illogical. For > instance: > > BIOS is a part of the reliability and performance promise of the > hardware. > > Is that true? If so, so what? That is no reason not to let us run > our own BIOS. > > Chipset specifications at the level being discussed are > commonly considered proprietary by all silicon vendors, not just > Intel. > > In other words, "Everyone spits on your freedom". Even if it were > true, so what? > > However, it is false: some computer models do work with free BIOS. > Intel compares badly with them. This is one of the statements that > maybe could be criticized in a published response. > > The open source firmware work that Intel *is* sponsoring could > lead to a solution where proprietary low-level chipset > initialization code from silicon vendors is made compatible with > open source higher-level platform initialization and pre-boot > management. > > As they say, this is not a complete free BIOS, just part of one. > > If the "proprietary low-level chipset initialization code" is in ROM > on the chips that it initializes, then it is tolerable. (It might as > well be circuits on that chip.) Otherwise, it is insufficient unless > made complete. > > I couldn't agree with you more Richard, but on the other hand it is nice to think someday Intel will wake up and realize the world is changing around them :-) -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org From peter at stuge.se Thu May 1 14:30:33 2008 From: peter at stuge.se (Peter Stuge) Date: Thu, 1 May 2008 14:30:33 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <4819A911.3000809@coresystems.de> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <79a45e0eb2a61094b7bf4cd9e4574846@imap.1and1.com> <032401c8aaf8$f4920240$0023040a@chimp> <4819054A.3010502@coresystems.de> <20080501001123.GC9643@greenwood> <48190BF1.4020904@coresystems.de> <48199CA0.7060702@assembler.cz> <20080501111029.21318.qmail@stuge.se> <4819A911.3000809@coresystems.de> Message-ID: <20080501123034.13452.qmail@stuge.se> On Thu, May 01, 2008 at 01:27:13PM +0200, Stefan Reinauer wrote: > >>To sum it up. Coreboot should handle this. > > > >Is this designing in a callback from payload to coreboot? > > To avoid this is the reason why the bios.bin _loader_ must be part > of coreboot. Yep. Sounds great. > The alternative would be to pass a register write sequence > description in lbtable. .. Not good. Agree. > >Or would the shadowing be oneshot before the new biosloader runs? > > The registers have to be changed _after_ bios.bin is copied to the > E and F segment. Doh. Yes. Oneshot _in_ the new biosloader, before bios.bin runs. Should bios.bin run in x86emu or vm86 by the way? //Peter From stepan at coresystems.de Thu May 1 14:40:59 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 01 May 2008 14:40:59 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <20080501123034.13452.qmail@stuge.se> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <79a45e0eb2a61094b7bf4cd9e4574846@imap.1and1.com> <032401c8aaf8$f4920240$0023040a@chimp> <4819054A.3010502@coresystems.de> <20080501001123.GC9643@greenwood> <48190BF1.4020904@coresystems.de> <48199CA0.7060702@assembler.cz> <20080501111029.21318.qmail@stuge.se> <4819A911.3000809@coresystems.de> <20080501123034.13452.qmail@stuge.se> Message-ID: <4819BA5B.9010402@coresystems.de> >>> Or would the shadowing be oneshot before the new biosloader runs? >>> >> The registers have to be changed _after_ bios.bin is copied to the >> E and F segment. >> > > Doh. Yes. Oneshot _in_ the new biosloader, before bios.bin runs. > > Should bios.bin run in x86emu or vm86 by the way? > No x86emu here. Otherwise your OS will start up in x86emu, too... Might be an option for Carl-Daniel's upcoming MIPS port. ;-) -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From peter at stuge.se Thu May 1 14:42:55 2008 From: peter at stuge.se (Peter Stuge) Date: Thu, 1 May 2008 14:42:55 +0200 Subject: [coreboot] Interested vendors [was: [Fwd: Re: Contact Intel]] In-Reply-To: <4818A556.6060900@gnu.org> References: <4818A556.6060900@gnu.org> Message-ID: <20080501124255.17921.qmail@stuge.se> On Wed, Apr 30, 2008 at 06:59:02PM +0200, arc wrote: > Is there a vendor that showed some interest in the free bios project? Indeed there are. AMD is actively supporting coreboot with documentation and code. They presented some nice slides at the coreboot meeting in Denver last month: http://www.coreboot.org/images/6/60/Coreboot_summit_08.pdf VIA releases documentation under NDA, allowing GPL code to be written from it. Some developers have signed. VIA are pretty slow though, it regularly takes several weeks for them to send the requested documentation even when agreements are in place. SiS have contributed code to coreboot. PC Engines have assisted with technical information needed to port coreboot to their boards. Kontron just recently contributed code to make flashrom work with some of their products. US-based Silicon Mechanics offers a particular Opteron rack server preinstalled with coreboot. Stefan Reinauer's company coresystems GmbH and my company Konsult Stuge both offer professional coreboot services. My company also offers the Gigabyte GA-M57SLI-S4 mainboard modified with a second, 2Mbyte large, flash chip and a BIOS switch, preinstalled with coreboot for sale to businesses worldwide and end users in certain european countries. (Restrictions due to EU environmental legislation.) There are several other vendors who have either helped further the project or have offers on products and services related to it: http://www.coreboot.org/Sponsors http://www.coreboot.org/Products > Is there something I could do to push vendors to help? I think that only a solid business case fitting the vendor's existing model of operation is convincing enough. //Peter From rminnich at gmail.com Thu May 1 17:12:52 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 1 May 2008 08:12:52 -0700 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: References: <4818A556.6060900@gnu.org> Message-ID: <13426df10805010812kc25ad20w78560fe0e43a762a@mail.gmail.com> On Thu, May 1, 2008 at 5:23 AM, Joe wrote: > I couldn't agree with you more Richard, but on the other hand it is nice to > think someday Intel will wake up and realize the world is changing around > them :-) > that's a form letter that we have seen before. It's a "canned response". So, they have thought enough about the issue to have a standard corporately-approved position letter all ready to go when folks ask this question. And, we all know it's baloney. What I find amusing about their "third party BIOS" comment is that *every* BIOS is a third party BIOS, and many if not all of them are based on reverse engineering done years ago. The least of the worries was chipset specs; the chipset specs were mostly open. Ah well. They're either going to win, and BIOSes will remain proprietary; or, we'll win, and the x86 BIOS world will be as open as the ARM, MIPS, PPC, and others are. One thing I've noticed -- no matter how long the odds may seem, it's always a mistake to bet against free/open source. So far, every time Intel has worked against free and open source, they've lost -- and they've tried many times in the last 30 years. ron From uwe at hermann-uwe.de Thu May 1 17:23:54 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 1 May 2008 17:23:54 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <20080501015343.GA9771@morn.localdomain> References: <20080430183225.GA2806@greenwood> <032301c8aaf8$cceca010$0023040a@chimp> <20080430194926.GA31307@greenwood> <032801c8aafc$e3a808e0$0023040a@chimp> <481907BA.7070505@coresystems.de> <20080501015343.GA9771@morn.localdomain> Message-ID: <20080501152354.GA4810@greenwood> On Wed, Apr 30, 2008 at 09:53:43PM -0400, Kevin O'Connor wrote: > On Thu, May 01, 2008 at 01:58:50AM +0200, Stefan Reinauer wrote: > > Myles Watson wrote: > > > > > Legacybios is the Bochs BIOS ported to compile on gcc instead of with the > > > dev86 tools. Kevin's intent (I'm paraphrasing) was to make it easy to > > > update the BIOS so that more developers would be able to fix/improve it. He What's the long-term plan? Will legacybios replace the current BOCHS BIOS in bochs also? > > > hoped that the ability to boot operating systems with BIOS callbacks would > > > make Coreboot more popular as well. Definately! > Thanks Myles, that is a good summary. > > Is it tested and reliable in depth anywhere close to Qemu/Bochs BIOS? Or > > are we exchanging a fragile piece of code with a fragile and untested one? > > What I have tested: booting linux, freedos, netbsd from floppy, cdrom, > and hard drives from qemu. I have reports of Windows XP working as > well. Testing should not be a problem, I think we can test lots of stuff in QEMU soonish. The really interesting issues will pop up when testing on actual hardware, though. I'll do that over the next few days with various payloads / OSes. > I'm working on going through all the external hardware dependencies > that bochs bios/legacybios impose - I plan to send an email when I > have the list completed. Great, thanks! Let us know if you need more info or some testing on coreboot-enabled hardware, many developers here may be able to help. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From mylesgw at gmail.com Thu May 1 17:34:13 2008 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 1 May 2008 09:34:13 -0600 Subject: [coreboot] ADLO for buildrom In-Reply-To: <481903BE.8010605@coresystems.de> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <20080430160732.GC21304@cosmic.amd.com> <030a01c8aadd$7cc99860$0023040a@chimp> <481903BE.8010605@coresystems.de> Message-ID: <037701c8aba0$cf9f2690$0023040a@chimp> > -----Original Message----- > From: Stefan Reinauer [mailto:stepan at coresystems.de] > Sent: Wednesday, April 30, 2008 5:42 PM > To: Myles Watson > Cc: 'Jordan Crouse'; 'Coreboot' > Subject: Re: [coreboot] ADLO for buildrom > > Myles Watson wrote: > > > >> -----Original Message----- > >> From: Jordan Crouse [mailto:jordan.crouse at amd.com] > >> Sent: Wednesday, April 30, 2008 10:08 AM > >> To: Myles Watson > >> Cc: Coreboot > >> Subject: Re: ADLO for buildrom > >> > >> I don't know what the history of the ADLO code is - any reason why we > >> can't > >> give it a home in payloads/ on SVN instead of living in the buildrom > >> code? > >> > > > > I don't think so. The old code was in v2's tree under utils/ > > > > I didn't think it was too big of a deal, since it's only one assembly > file, > > a make file, and two elf headers. I admit it looks like a lot with all > the > > documentation. > > > > I'm happy to have it live wherever's best. Who has to set that up? > > > > Thanks, > > Myles > > > > > > > > > For v3 we should really integrate the one assembly file rewritten in C > as part of coreboot. It's a loader, just it doesnt load elf or self, but > a rombios.bin... I'd rather have it compiled and linked into an ELF, loaded in the normal way. I don't think there needs to be a special pathway for this one payload. Thanks, Myles From mylesgw at gmail.com Thu May 1 17:36:32 2008 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 1 May 2008 09:36:32 -0600 Subject: [coreboot] ADLO for buildrom In-Reply-To: <48190505.7040200@coresystems.de> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com><20080430160732.GC21304@cosmic.amd.com><030a01c8aadd$7cc99860$0023040a@chimp><20080430161852.GD21304@cosmic.amd.com><2831fecf0804301021t2e3651c6t3bacaf8b0d9fbe4d@mail.gmail.com><20080430181838.GF21304@cosmic.amd.com> <20080430183225.GA2806@greenwood> <032301c8aaf8$cceca010$0023040a@chimp> <48190505.7040200@coresystems.de> Message-ID: <037801c8aba1$22371a20$0023040a@chimp> > -----Original Message----- > From: Stefan Reinauer [mailto:stepan at coresystems.de] > Sent: Wednesday, April 30, 2008 5:47 PM > To: Myles Watson > Cc: 'Uwe Hermann'; 'Jordan Crouse'; 'Coreboot' > Subject: Re: [coreboot] ADLO for buildrom > > Myles Watson wrote: > > There is very little duplicated here. The ADLO in coreboot relies on > > building the BOCHS bios from source with dev86, but the payloads/adlo > uses > > the new legacybios version. The only thing that is exactly the same is > one > > of the elf headers. > > please also note we have a gsoc student working on legacy bios > integration again this summer. maybe we should stop the plenty > discussion here and leave things as they are until that project is done? It's not soon enough for me. It works now in QEMU, even though there is a lot to be improved. I'd like to put it into buildrom so that it is easy to hack on. > > Does legacybios from Kevin O'Connor boot Vista? It probably does in QEMU, but not the 64-bit version. The last I heard that was the status of the Bochs BIOS. Thanks, Myles From mylesgw at gmail.com Thu May 1 17:37:59 2008 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 1 May 2008 09:37:59 -0600 Subject: [coreboot] ADLO for buildrom In-Reply-To: <4819054A.3010502@coresystems.de> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <79a45e0eb2a61094b7bf4cd9e4574846@imap.1and1.com> <032401c8aaf8$f4920240$0023040a@chimp> <4819054A.3010502@coresystems.de> Message-ID: <037901c8aba1$55f47e70$0023040a@chimp> > -----Original Message----- > From: Stefan Reinauer [mailto:stepan at coresystems.de] > Sent: Wednesday, April 30, 2008 5:48 PM > To: Myles Watson > Cc: joe at settoplinux.org; 'Coreboot' > Subject: Re: [coreboot] ADLO for buildrom > > Myles Watson wrote: > >> On Wed, 30 Apr 2008 09:58:56 -0600, "Myles Watson" > >> wrote: > >> > >>> It boots Windows XP in QEMU. > >>> > >> Sweet:-) > >> > >> What about booting XP on real hardware? > >> > > > > The loader needs to be customized for each board, or we need to pass > some > > information like RAM map from coreboot before that will work. > > > > Which is why it really should, no, it has to be built into coreboot > itself. coreboot already has all the knowledge required for this. > Duplicating efforts that we did in C in another assembler chunk is plain > b0rked. I was hoping that we could pass it the same information we pass the Linux kernel. The e820 maps etc. I haven't looked into it too much, but ACPI tables for that information would be fine for me too. Myles From mylesgw at gmail.com Thu May 1 17:32:27 2008 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 1 May 2008 09:32:27 -0600 Subject: [coreboot] ADLO for buildrom In-Reply-To: <20080430233740.GB9643@greenwood> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <20080430160732.GC21304@cosmic.amd.com> <030a01c8aadd$7cc99860$0023040a@chimp> <20080430161852.GD21304@cosmic.amd.com> <2831fecf0804301021t2e3651c6t3bacaf8b0d9fbe4d@mail.gmail.com> <20080430210124.GB31307@greenwood> <033101c8ab11$008b6bf0$0023040a@chimp> <20080430233740.GB9643@greenwood> Message-ID: <037601c8aba0$90536280$0023040a@chimp> > OK, fine. Would it hurt to use the aligned version for non-kexec too? > Any drawbacks? The only drawback is size. It adds 3K of zeroes if you don't compress it. > > OK, then it probably doesn't matter much. If and how can the loader be > integrated upstream? That's probably the best place to store it, correct? I don't think the loader should be integrated upstream. If we can get Bochs and QEMU to adopt the gcc port of the BIOS, it will have more testers and be more stable. They don't want the loader. > > > > +-; code it is loaded into memory at 0x7C00 > > > > ++; code it is loaded into memory at 0x7000 > > > > > > Why? Please explain. Is this board-specific or payload-specific? > > > Can it be a variable, selectable in a config file later? > > > Surely in buildrom, but also for manual builds... > > > > This is part of what should go away. The BIOS has to get loaded at the > > correct address for callbacks to work. This loader needs to get loaded > > somewhere else, then copy its payload to the right spot. I'd love for > the > > loading part to get taken over by Coreboot. Then we could just set up > the > > CMOS values separately and not depend on being loaded into a hard-coded > > location in RAM. > > Can you elaborate? What would coreboot need to do exactly (in addition > what we already to for other payloads)? Is any of that board-specific? > > What do you mean with CMOS values here? Where are they used in ADLO? > Not yet, but you plan to do later? They are the way the Bochs BIOS knows what device to boot from, what the memory map is, etc. > > > > This is needed for ADLO but not legacybios? Can we also change ADLO > > > to not require it, or is that impossible? > > > > I hope someone will do it soon. It would take me some time, since I'm > not > > really familiar with assembly, but it really isn't too much code. > > OK, sounds good. So there's not _real_ reason to continue using it. > > > > > Let's use "ADLO" in strings everywhere, as that seems to be the > > > "official" name. > > > > Sure. Once we replace the loader there will be nothing left of the > original > > but the name, but the name's fine. > > Hm, if it's completely gone later, I think we should also eliminate > the ADLO name (but not just yet). > > It's just coreboot+legacybios then, correct? So we'll probably call > it legacybios (or BOCHS BIOS?). We'll see... > > > > > > Index: packages/legacybios/legacybios.mk > > > > =================================================================== > > > > --- packages/legacybios/legacybios.mk (revision 0) > > > > +++ packages/legacybios/legacybios.mk (revision 0) > > > [...] > > > > +LEGACYBIOS_TARBALL=legacybios-$(LEGACYBIOS_TAG).tar.gz > > > > +LEGACYBIOS_SOURCE=legacybios-$(LEGACYBIOS_TAG).tar.gz > > > > > > Why are both needed? > > Is this required? I took one out of the last patch > > Testing the code now in QEMU and hardware, will report back. Great. Thanks, Myles From stepan at coresystems.de Thu May 1 17:39:05 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 01 May 2008 17:39:05 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <037701c8aba0$cf9f2690$0023040a@chimp> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <20080430160732.GC21304@cosmic.amd.com> <030a01c8aadd$7cc99860$0023040a@chimp> <481903BE.8010605@coresystems.de> <037701c8aba0$cf9f2690$0023040a@chimp> Message-ID: <4819E419.7050504@coresystems.de> Myles Watson wrote: >> For v3 we should really integrate the one assembly file rewritten in C >> as part of coreboot. It's a loader, just it doesnt load elf or self, but >> a rombios.bin... >> > > I'd rather have it compiled and linked into an ELF, loaded in the normal > way. I don't think there needs to be a special pathway for this one > payload. It is not a special pathway. It's just the normal lar loader, loading to a defined address. We don't need the indirection of a loader of the loader for that...? From stepan at coresystems.de Thu May 1 17:42:31 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 01 May 2008 17:42:31 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <037801c8aba1$22371a20$0023040a@chimp> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com><20080430160732.GC21304@cosmic.amd.com><030a01c8aadd$7cc99860$0023040a@chimp><20080430161852.GD21304@cosmic.amd.com><2831fecf0804301021t2e3651c6t3bacaf8b0d9fbe4d@mail.gmail.com><20080430181838.GF21304@cosmic.amd.com> <20080430183225.GA2806@greenwood> <032301c8aaf8$cceca010$0023040a@chimp> <48190505.7040200@coresystems.de> <037801c8aba1$22371a20$0023040a@chimp> Message-ID: <4819E4E7.7030701@coresystems.de> Myles Watson wrote: > It's not soon enough for me. It works now in QEMU, even though there is a > lot to be improved. I'd like to put it into buildrom so that it is easy to > hack on. > "It"? ADLO has been in our CVS/SVN repo since 2002. It should not be hard to hack on it... > >> Does legacybios from Kevin O'Connor boot Vista? >> > > It probably does in QEMU, but not the 64-bit version. The last I heard that > was the status of the Bochs BIOS. When I booted vista, i could interestingly only boot the 64bit version in qemu but even that needed a bunch of patches. I suggest we wait until legacybios becomes the standard bios of qemu before we try to replace a well tested implementation with it. From stepan at coresystems.de Thu May 1 17:44:00 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 01 May 2008 17:44:00 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <037901c8aba1$55f47e70$0023040a@chimp> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <79a45e0eb2a61094b7bf4cd9e4574846@imap.1and1.com> <032401c8aaf8$f4920240$0023040a@chimp> <4819054A.3010502@coresystems.de> <037901c8aba1$55f47e70$0023040a@chimp> Message-ID: <4819E540.50308@coresystems.de> Myles Watson wrote: > I was hoping that we could pass it the same information we pass the Linux > kernel. The e820 maps etc. I haven't looked into it too much, but ACPI > tables for that information would be fine for me too. > But there the cat bites its tail. legacybios is the one that produces e820. And so far it produces pirq and acpi, too. It just doesnt make sense like this on real hardware. bochs bios is sure not much better. > From joe at settoplinux.org Thu May 1 17:44:37 2008 From: joe at settoplinux.org (Joe) Date: Thu, 01 May 2008 11:44:37 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <13426df10805010812kc25ad20w78560fe0e43a762a@mail.gmail.com> References: <4818A556.6060900@gnu.org> <13426df10805010812kc25ad20w78560fe0e43a762a@mail.gmail.com> Message-ID: <2bf69daa60a7558afc8e488c223c83a8@imap.1and1.com> On Thu, 1 May 2008 08:12:52 -0700, "ron minnich" wrote: > On Thu, May 1, 2008 at 5:23 AM, Joe wrote: > >> I couldn't agree with you more Richard, but on the other hand it is > nice to >> think someday Intel will wake up and realize the world is changing > around >> them :-) >> > > > that's a form letter that we have seen before. It's a "canned > response". So, they have thought enough about the issue to have a > standard corporately-approved position letter all ready to go when > folks ask this question. And, we all know it's baloney. > I thought I had seen that one before. They sent me that when I contacted them about their Intel ACSF bios (Applied Computing System Firmware Library). > > What I find amusing about their "third party BIOS" comment is that > *every* BIOS is a third party BIOS, and many if not all of them are > based on reverse engineering done years ago. The least of the worries > was chipset specs; the chipset specs were mostly open. > > Ah well. They're either going to win, and BIOSes will remain > proprietary; or, we'll win, and the x86 BIOS world will be as open as > the ARM, MIPS, PPC, and others are. One thing I've noticed -- no > matter how long the odds may seem, it's always a mistake to bet > against free/open source. So far, every time Intel has worked against > free and open source, they've lost -- and they've tried many times in > the last 30 years. > I think our only hope of getting Intel involved with coreboot, is through the guys at http://www.linuxfirmwarekit.org -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org From mylesgw at gmail.com Thu May 1 17:44:36 2008 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 1 May 2008 09:44:36 -0600 Subject: [coreboot] ADLO for buildrom In-Reply-To: <4819E419.7050504@coresystems.de> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <20080430160732.GC21304@cosmic.amd.com> <030a01c8aadd$7cc99860$0023040a@chimp> <481903BE.8010605@coresystems.de> <037701c8aba0$cf9f2690$0023040a@chimp> <4819E419.7050504@coresystems.de> Message-ID: <037a01c8aba2$432a33b0$0023040a@chimp> > -----Original Message----- > From: Stefan Reinauer [mailto:stepan at coresystems.de] > Sent: Thursday, May 01, 2008 9:39 AM > To: Myles Watson > Cc: 'Jordan Crouse'; 'Coreboot' > Subject: Re: [coreboot] ADLO for buildrom > > Myles Watson wrote: > >> For v3 we should really integrate the one assembly file rewritten in C > >> as part of coreboot. It's a loader, just it doesnt load elf or self, > but > >> a rombios.bin... > >> > > > > I'd rather have it compiled and linked into an ELF, loaded in the normal > > way. I don't think there needs to be a special pathway for this one > > payload. > > It is not a special pathway. It's just the normal lar loader, loading to > a defined address. > > We don't need the indirection of a loader of the loader for that...? I think we're in agreement. I'm talking about how it gets into the lar, and I think you're saying how it gets loaded into memory. We should either make an ELF and have lar put it in, or do the same thing that the Geode VSA does. You're right, it should just get loaded into memory like any other binary. Myles From mylesgw at gmail.com Thu May 1 17:46:42 2008 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 1 May 2008 09:46:42 -0600 Subject: [coreboot] ADLO for buildrom In-Reply-To: <4819E540.50308@coresystems.de> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <79a45e0eb2a61094b7bf4cd9e4574846@imap.1and1.com> <032401c8aaf8$f4920240$0023040a@chimp> <4819054A.3010502@coresystems.de> <037901c8aba1$55f47e70$0023040a@chimp> <4819E540.50308@coresystems.de> Message-ID: <037b01c8aba2$8dcbbb50$0023040a@chimp> > -----Original Message----- > From: Stefan Reinauer [mailto:stepan at coresystems.de] > Sent: Thursday, May 01, 2008 9:44 AM > To: Myles Watson > Cc: joe at settoplinux.org; 'Coreboot' > Subject: Re: [coreboot] ADLO for buildrom > > Myles Watson wrote: > > I was hoping that we could pass it the same information we pass the > Linux > > kernel. The e820 maps etc. I haven't looked into it too much, but ACPI > > tables for that information would be fine for me too. > > > > But there the cat bites its tail. legacybios is the one that produces > e820. And so far it produces pirq and acpi, too. It just doesnt make > sense like this on real hardware. > bochs bios is sure not much better. > So how does the kernel get an e820 map when you load it from filo? That was the pathway I meant. Thanks, Myles From mylesgw at gmail.com Thu May 1 17:59:15 2008 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 1 May 2008 09:59:15 -0600 Subject: [coreboot] ADLO for buildrom In-Reply-To: <20080501022518.GD9771@morn.localdomain> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <20080501022518.GD9771@morn.localdomain> Message-ID: <037c01c8aba4$4e9a4b20$0023040a@chimp> > -----Original Message----- > From: Kevin O'Connor [mailto:kevin at koconnor.net] > Sent: Wednesday, April 30, 2008 8:25 PM > To: Myles Watson > Cc: Coreboot > Subject: Re: [coreboot] ADLO for buildrom > > On Wed, Apr 30, 2008 at 09:58:56AM -0600, Myles Watson wrote: > > This patch adds ADLO to buildrom using the gcc ported BOCHS BIOS. It > > boots Windows XP in QEMU. > > Thanks Myles! > > >It still needs as86 to be installed because > > I didn't port the loader yet. > > Porting the loader from as86 style assembler to gas should be pretty > simple. (In fact, I wonder if just telling gas to use intel syntax > would make it work.) > > However, ultimately I think the logic should just be ported to C code. Yes. > >Other things like making the loader > > understand the coreboot information to get the RAM map would be nice > > too. > > I think we're going to need to teach legacybios about coreboot (and > maybe add some new things to coreboot). I'd prefer not require a > special shim between the code just to pass the handful of parameters > around. I just want to keep the BIOS useful for QEMU and Bochs, because I think more users = more solid. Thanks, Myles From mylesgw at gmail.com Thu May 1 18:00:54 2008 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 1 May 2008 10:00:54 -0600 Subject: [coreboot] ADLO for buildrom In-Reply-To: <4819E4E7.7030701@coresystems.de> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com><20080430160732.GC21304@cosmic.amd.com><030a01c8aadd$7cc99860$0023040a@chimp><20080430161852.GD21304@cosmic.amd.com><2831fecf0804301021t2e3651c6t3bacaf8b0d9fbe4d@mail.gmail.com><20080430181838.GF21304@cosmic.amd.com> <20080430183225.GA2806@greenwood> <032301c8aaf8$cceca010$0023040a@chimp> <48190505.7040200@coresystems.de> <037801c8aba1$22371a20$0023040a@chimp> <4819E4E7.7030701@coresystems.de> Message-ID: <037d01c8aba4$89be5e80$0023040a@chimp> > -----Original Message----- > From: Stefan Reinauer [mailto:stepan at coresystems.de] > Sent: Thursday, May 01, 2008 9:43 AM > To: Myles Watson > Cc: 'Jordan Crouse'; 'Coreboot' > Subject: Re: [coreboot] ADLO for buildrom > > Myles Watson wrote: > > It's not soon enough for me. It works now in QEMU, even though there is > a > > lot to be improved. I'd like to put it into buildrom so that it is easy > to > > hack on. > > > "It"? > > ADLO has been in our CVS/SVN repo since 2002. It should not be hard to > hack on it... The first thing I would do is remove all of the BIOS code since it's old and relies on the old toolchain. I thought it would be easier to add a couple of small files to payloads/ then to get approval to blow away the code in utils/ even though it is unused and outdated. I never know what's going to be an easy/hard sell. > > > >> Does legacybios from Kevin O'Connor boot Vista? > >> > > > > It probably does in QEMU, but not the 64-bit version. The last I heard > that > > was the status of the Bochs BIOS. > When I booted vista, i could interestingly only boot the 64bit version > in qemu but even that needed a bunch of patches. That's great that it boots 64-bit Vista, patches and all! > I suggest we wait until legacybios becomes the standard bios of qemu > before we try to replace a well tested implementation with it. The Bochs BIOS project is having a hard time finding anyone to review their patches because of the tool chain, but there is little impetus for them to switch to Kevin's port. We could be that impetus. Very few people have been using ADLO from Coreboot. When I fixed the delays and the ATA handling so that it worked in hardware, the response was "get it patched upstream." I've done that, but no one has cared enough to pull down the new version into our tree. I think the only part that needs to live in our tree is the wrapper that passes information from Coreboot to the Bochs BIOS (however that's done.) We win by using a payload that is not special purpose just for us. Thanks, Myles From rminnich at gmail.com Thu May 1 18:02:39 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 1 May 2008 09:02:39 -0700 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <2bf69daa60a7558afc8e488c223c83a8@imap.1and1.com> References: <4818A556.6060900@gnu.org> <13426df10805010812kc25ad20w78560fe0e43a762a@mail.gmail.com> <2bf69daa60a7558afc8e488c223c83a8@imap.1and1.com> Message-ID: <13426df10805010902o73c8265fo4a25221f389c8719@mail.gmail.com> On Thu, May 1, 2008 at 8:44 AM, Joe wrote: > I think our only hope of getting Intel involved with coreboot, is through > the guys at http://www.linuxfirmwarekit.org > excellent idea. There are lots of people at intel (they talk to me from time to time) who want to see intel and coreboot work together. ron From lemenkov at gmail.com Thu May 1 18:09:40 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Thu, 1 May 2008 20:09:40 +0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <13426df10805010902o73c8265fo4a25221f389c8719@mail.gmail.com> References: <4818A556.6060900@gnu.org> <13426df10805010812kc25ad20w78560fe0e43a762a@mail.gmail.com> <2bf69daa60a7558afc8e488c223c83a8@imap.1and1.com> <13426df10805010902o73c8265fo4a25221f389c8719@mail.gmail.com> Message-ID: 2008/5/1 ron minnich : > On Thu, May 1, 2008 at 8:44 AM, Joe wrote: > > > I think our only hope of getting Intel involved with coreboot, is through > > the guys at http://www.linuxfirmwarekit.org > > > excellent idea. > > There are lots of people at intel (they talk to me from time to time) > who want to see intel and coreboot work together. Can't believe. Intel spends a lot of efforts to promote their own EFI - why they will to help their competitors? -- With best regards! From rminnich at gmail.com Thu May 1 18:11:12 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 1 May 2008 09:11:12 -0700 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: References: <4818A556.6060900@gnu.org> <13426df10805010812kc25ad20w78560fe0e43a762a@mail.gmail.com> <2bf69daa60a7558afc8e488c223c83a8@imap.1and1.com> <13426df10805010902o73c8265fo4a25221f389c8719@mail.gmail.com> Message-ID: <13426df10805010911y14f18e05wfea2658ab45bc41b@mail.gmail.com> On Thu, May 1, 2008 at 9:09 AM, Peter Lemenkov wrote: > Can't believe. Intel spends a lot of efforts to promote their own EFI > - why they will to help their competitors? > intel is not a monolith. It's too big for that. And not everyone at Intel likes EFI. ron From stepan at coresystems.de Thu May 1 18:14:14 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 01 May 2008 18:14:14 +0200 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: References: <4818A556.6060900@gnu.org> <13426df10805010812kc25ad20w78560fe0e43a762a@mail.gmail.com> <2bf69daa60a7558afc8e488c223c83a8@imap.1and1.com> <13426df10805010902o73c8265fo4a25221f389c8719@mail.gmail.com> Message-ID: <4819EC56.4070503@coresystems.de> Peter Lemenkov wrote: > 2008/5/1 ron minnich : > >> On Thu, May 1, 2008 at 8:44 AM, Joe wrote: >> >> > I think our only hope of getting Intel involved with coreboot, is through >> > the guys at http://www.linuxfirmwarekit.org >> > >> excellent idea. >> >> There are lots of people at intel (they talk to me from time to time) >> who want to see intel and coreboot work together. >> > > Can't believe. Intel spends a lot of efforts to promote their own EFI > - why they will to help their competitors? > Maybe for the same reasons IBM and SUN are doing Linux, despite the fact that they had their own OSes. From stepan at coresystems.de Thu May 1 18:14:45 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 01 May 2008 18:14:45 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <037b01c8aba2$8dcbbb50$0023040a@chimp> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <79a45e0eb2a61094b7bf4cd9e4574846@imap.1and1.com> <032401c8aaf8$f4920240$0023040a@chimp> <4819054A.3010502@coresystems.de> <037901c8aba1$55f47e70$0023040a@chimp> <4819E540.50308@coresystems.de> <037b01c8aba2$8dcbbb50$0023040a@chimp> Message-ID: <4819EC75.307@coresystems.de> Myles Watson wrote: > >> -----Original Message----- >> From: Stefan Reinauer [mailto:stepan at coresystems.de] >> Sent: Thursday, May 01, 2008 9:44 AM >> To: Myles Watson >> Cc: joe at settoplinux.org; 'Coreboot' >> Subject: Re: [coreboot] ADLO for buildrom >> >> Myles Watson wrote: >> >>> I was hoping that we could pass it the same information we pass the >>> >> Linux >> >>> kernel. The e820 maps etc. I haven't looked into it too much, but ACPI >>> tables for that information would be fine for me too. >>> >>> >> But there the cat bites its tail. legacybios is the one that produces >> e820. And so far it produces pirq and acpi, too. It just doesnt make >> sense like this on real hardware. >> bochs bios is sure not much better. >> >> > So how does the kernel get an e820 map when you load it from filo? That was > the pathway I meant. > filo makes one from the coreboot table. From mylesgw at gmail.com Thu May 1 18:16:25 2008 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 1 May 2008 10:16:25 -0600 Subject: [coreboot] ADLO for buildrom In-Reply-To: <4819EC75.307@coresystems.de> References: <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <79a45e0eb2a61094b7bf4cd9e4574846@imap.1and1.com> <032401c8aaf8$f4920240$0023040a@chimp> <4819054A.3010502@coresystems.de> <037901c8aba1$55f47e70$0023040a@chimp> <4819E540.50308@coresystems.de> <037b01c8aba2$8dcbbb50$0023040a@chimp> <4819EC75.307@coresystems.de> Message-ID: <037e01c8aba6$b487f930$0023040a@chimp> > -----Original Message----- > From: Stefan Reinauer [mailto:stepan at coresystems.de] > Sent: Thursday, May 01, 2008 10:15 AM > To: Myles Watson > Cc: joe at settoplinux.org; 'Coreboot' > Subject: Re: [coreboot] ADLO for buildrom > > Myles Watson wrote: > > > >> -----Original Message----- > >> From: Stefan Reinauer [mailto:stepan at coresystems.de] > >> Sent: Thursday, May 01, 2008 9:44 AM > >> To: Myles Watson > >> Cc: joe at settoplinux.org; 'Coreboot' > >> Subject: Re: [coreboot] ADLO for buildrom > >> > >> Myles Watson wrote: > >> > >>> I was hoping that we could pass it the same information we pass the > >>> > >> Linux > >> > >>> kernel. The e820 maps etc. I haven't looked into it too much, but > ACPI > >>> tables for that information would be fine for me too. > >>> > >>> > >> But there the cat bites its tail. legacybios is the one that produces > >> e820. And so far it produces pirq and acpi, too. It just doesnt make > >> sense like this on real hardware. > >> bochs bios is sure not much better. > >> > >> > > So how does the kernel get an e820 map when you load it from filo? That > was > > the pathway I meant. > > > filo makes one from the coreboot table. Great. That's what I think ADLO should do too. Myles From patrick at georgi-clan.de Thu May 1 18:36:37 2008 From: patrick at georgi-clan.de (Patrick Georgi) Date: Thu, 1 May 2008 18:36:37 +0200 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <4819EC56.4070503@coresystems.de> References: <4818A556.6060900@gnu.org> <13426df10805010812kc25ad20w78560fe0e43a762a@mail.gmail.com> <2bf69daa60a7558afc8e488c223c83a8@imap.1and1.com> <13426df10805010902o73c8265fo4a25221f389c8719@mail.gmail.com> <4819EC56.4070503@coresystems.de> Message-ID: <20080501183637.4b8dcaf4@tetris.streichelzoo.local> Am Thu, 01 May 2008 18:14:14 +0200 schrieb Stefan Reinauer : > Maybe for the same reasons IBM and SUN are doing Linux, despite the > fact that they had their own OSes. still have, both of them.. (and both of them happily give you linux, but propose "the real thing" for "real deployments") Regards, Patrick From mylesgw at gmail.com Thu May 1 18:39:59 2008 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 1 May 2008 10:39:59 -0600 Subject: [coreboot] ADLO for buildrom In-Reply-To: <20080430233223.GJ21304@cosmic.amd.com> References: <20080430220859.GA5955@greenwood> <033001c8ab10$dc732820$0023040a@chimp> <20080430232726.GA9643@greenwood> <20080430233223.GJ21304@cosmic.amd.com> Message-ID: <2831fecf0805010939s1f138ecepf310562807d9c6d5@mail.gmail.com> > > I'm fine using the git version which corresponds to a released tarball > > in the normal case, but for now (in order to get the fixes for gcc 4.2/4.3) > > I'd say we use the currently latest git. This patch updates the legacybios version to 2.2 (the latest) and thus avoids git. > I just want to say - fear the git fetcher in buildrom. There be > dragons. > > Jordan This patch addresses most concerns not related to the loader. I hope that it will be rewritten soon. The payloads.adlo.diff patch is the same as the last. I'm including it for completeness. I think that committing this into the repository is worth the 20K. It has already generated more discussion than ADLO has for a long time. The ease of using it with buildrom should speed testing and bug fixing. Signed-off-by: Myles Watson Thanks, Myles -------------- next part -------------- A non-text attachment was scrubbed... Name: buildrom.adlo.diff Type: text/x-patch Size: 5744 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: payloads.adlo.diff Type: text/x-patch Size: 18539 bytes Desc: not available URL: From peter at stuge.se Thu May 1 20:27:40 2008 From: peter at stuge.se (Peter Stuge) Date: Thu, 1 May 2008 20:27:40 +0200 Subject: [coreboot] ADLO for buildrom In-Reply-To: <037e01c8aba6$b487f930$0023040a@chimp> <037701c8aba0$cf9f2690$0023040a@chimp> References: <037901c8aba1$55f47e70$0023040a@chimp> <4819E540.50308@coresystems.de> <037b01c8aba2$8dcbbb50$0023040a@chimp> <4819EC75.307@coresystems.de> <037e01c8aba6$b487f930$0023040a@chimp> <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <20080430160732.GC21304@cosmic.amd.com> <030a01c8aadd$7cc99860$0023040a@chimp> <481903BE.8010605@coresystems.de> <037701c8aba0$cf9f2690$0023040a@chimp> Message-ID: <20080501182740.2809.qmail@stuge.se> On Thu, May 01, 2008 at 09:34:13AM -0600, Myles Watson wrote: > I'd rather have it compiled and linked into an ELF, loaded in the > normal way. On Thu, May 01, 2008 at 10:16:25AM -0600, Myles Watson wrote: > > > So how does the kernel get an e820 map when you load it from > > > filo? That was the pathway I meant. > > > > filo makes one from the coreboot table. > > Great. That's what I think ADLO should do too. It could use libpayload, right? //Peter From jordan.crouse at amd.com Thu May 1 21:00:21 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Thu, 1 May 2008 13:00:21 -0600 Subject: [coreboot] ADLO for buildrom In-Reply-To: <20080501182740.2809.qmail@stuge.se> References: <4819E540.50308@coresystems.de> <037b01c8aba2$8dcbbb50$0023040a@chimp> <4819EC75.307@coresystems.de> <037e01c8aba6$b487f930$0023040a@chimp> <2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com> <20080430160732.GC21304@cosmic.amd.com> <030a01c8aadd$7cc99860$0023040a@chimp> <481903BE.8010605@coresystems.de> <037701c8aba0$cf9f2690$0023040a@chimp> <20080501182740.2809.qmail@stuge.se> Message-ID: <20080501190021.GB31251@cosmic.amd.com> On 01/05/08 20:27 +0200, Peter Stuge wrote: > On Thu, May 01, 2008 at 09:34:13AM -0600, Myles Watson wrote: > > I'd rather have it compiled and linked into an ELF, loaded in the > > normal way. > > > On Thu, May 01, 2008 at 10:16:25AM -0600, Myles Watson wrote: > > > > So how does the kernel get an e820 map when you load it from > > > > filo? That was the pathway I meant. > > > > > > filo makes one from the coreboot table. > > > > Great. That's what I think ADLO should do too. > > It could use libpayload, right? Is the e820 table generation generic and useful enough that it belongs in the library? I was going to suggest that before, but then I thought better of it. Even if not, it can still use libpayload to walk the coreboot tables. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From mylesgw at gmail.com Thu May 1 21:51:40 2008 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 1 May 2008 13:51:40 -0600 Subject: [coreboot] ADLO for buildrom In-Reply-To: <20080501182740.2809.qmail@stuge.se> References: <037901c8aba1$55f47e70$0023040a@chimp><4819E540.50308@coresystems.de><037b01c8aba2$8dcbbb50$0023040a@chimp><4819EC75.307@coresystems.de><037e01c8aba6$b487f930$0023040a@chimp><2831fecf0804300858i27d76410q837a1401afa8587c@mail.gmail.com><20080430160732.GC21304@cosmic.amd.com><030a01c8aadd$7cc99860$0023040a@chimp><481903BE.8010605@coresystems.de><037701c8aba0$cf9f2690$0023040a@chimp> <20080501182740.2809.qmail@stuge.se> Message-ID: <038b01c8abc4$c65a1030$0023040a@chimp> > -----Original Message----- > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] > On Behalf Of Peter Stuge > Sent: Thursday, May 01, 2008 12:28 PM > To: 'Coreboot' > Subject: Re: [coreboot] ADLO for buildrom > > On Thu, May 01, 2008 at 09:34:13AM -0600, Myles Watson wrote: > > I'd rather have it compiled and linked into an ELF, loaded in the > > normal way. > > > On Thu, May 01, 2008 at 10:16:25AM -0600, Myles Watson wrote: > > > > So how does the kernel get an e820 map when you load it from > > > > filo? That was the pathway I meant. > > > > > > filo makes one from the coreboot table. > > > > Great. That's what I think ADLO should do too. > > It could use libpayload, right? Sorry I didn't reply earlier to this comment. I don't know very much about libpayload. That would be fine with me if it works. Thanks, Myles From c-d.hailfinger.devel.2006 at gmx.net Thu May 1 22:00:50 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 01 May 2008 22:00:50 +0200 Subject: [coreboot] ICH7 SPI support for flashrom In-Reply-To: <48182B30.6050407@m31engineering.it> References: <48182B30.6050407@m31engineering.it> Message-ID: <481A2172.9040105@gmx.net> Hi Luca, On 30.04.2008 10:17, Luca Burelli wrote: > Hello list, > I have tried flashrom on an ICH7-based board with a SPI Flash > connected. On this kind of platform, after recognizing the ICH7 SPI > interface, it seems like it's still using FWH commands to probe the > Flash device. > Yes, that's expected because ICH7 also supports parallel flash. > From the current SVN logs, it looks like this is a work in progress, > and that "hailfinger" was the most active on this topic, but the last > commit was around a month ago. Is someone still working on this? What is > the current status of this support? > I'm currently very busy with my diploma thesis. There is some work to add ICH9 SPI support to flashrom and depending on which of the two SPI interfaces in ICH9 is implemented, adding support for ICH7 is either easy or a complete new "driver". If you understand SPI well and take a look at the existing IT8716F SPI driver, you should be a able to write a ICH7 SPI driver in a week of development. The public ICH7 flash docs are pretty good, at least compared to what other vendors have. Then again, there are many things you have to guess while writing the driver because the docs are not explaining every detail. Regards, Carl-Daniel From jakllsch at kollasch.net Thu May 1 22:30:14 2008 From: jakllsch at kollasch.net (Jonathan A. Kollasch) Date: Thu, 1 May 2008 20:30:14 +0000 Subject: [coreboot] [PATCH] MS7135 fixes and updates In-Reply-To: <48199D68.7090303@assembler.cz> References: <20080430152113.GG2542@tazenda.kollasch.net> <20080501002225.GD9643@greenwood> <20080501010901.GJ2542@tazenda.kollasch.net> <48199D68.7090303@assembler.cz> Message-ID: <20080501203014.GL2542@tazenda.kollasch.net> On Thu, May 01, 2008 at 12:37:28PM +0200, Rudolf Marek wrote: > Just a side note, if the superIO is similar to W83627EHG then you could use > virtual LDNs for the different functionality in same LDN which are sharing > same enable byte. (I did it for the W83627EHG). > > http://www.coreboot.org/SuperIO_port_guide Huh, but I don't think this is the case here. > > Maybe this page is not linked from anywhere? That's what it looks like: http://www.coreboot.org/Special:Whatlinkshere/SuperIO_port_guide Jonathan Kollasch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From mylesgw at gmail.com Thu May 1 22:41:27 2008 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 1 May 2008 14:41:27 -0600 Subject: [coreboot] Buildrom lzma patch and update QEMU Config-lab.lb Message-ID: <2831fecf0805011341n1b83e7bbl14fa57d32458bfad@mail.gmail.com> These patches go together and make it so that checking the "USE_LZMA" option in buildrom doesn't break builds. It assumes that all Config.lb files don't use compression, and all Config-lab.lb files do. The qemu-lab.lzma.diff patch makes that change. Signed-off-by: Myles Watson Thanks, Myles -------------- next part -------------- A non-text attachment was scrubbed... Name: qemu-lab.lzma.diff Type: text/x-patch Size: 417 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lzma.v2.buildrom.diff Type: text/x-patch Size: 8335 bytes Desc: not available URL: From c-d.hailfinger.devel.2006 at gmx.net Thu May 1 22:46:10 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 01 May 2008 22:46:10 +0200 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: References: <4818A556.6060900@gnu.org> Message-ID: <481A2C12.6020605@gmx.net> Hi Richard, I normally do not reply to threads started by someone (arc at gnu.org) who is unwilling to state his/her real name and announces that he has blacklisted the e-mail address of the founder of coreboot. Then again, this reply is directed to you, Richard, because you made some very good points and I wish to supply you with quotable statements to justify a free firmware/BIOS. On 01.05.2008 12:11, Richard M Stallman wrote: > It could be that the Coreboot developers can find statements which are > misleading or false, and publish an article which would put pressure > on Intel. > > Some of the points are simply distractions or illogical. For > instance: > > BIOS is a part of the reliability and performance promise of the > hardware. > > Is that true? If so, so what? That is no reason not to let us run > our own BIOS. > Yes, it is true. The BIOS is responsible to fix up (work around) all the soft-fixable bugs in the hardware so the OS won't see them. Initialization of the various buses and memory has to be done correctly and in an efficient way. Setting up things the wrong way or without efficiency/performance considerations has serious effects on benchmarks and reliablity. However, that's exactly the reason why we MUST have a free/open BIOS/firmware. - It allows us to get the best possible performance. AMD has stated that the coreboot Hypertransport setup is the most efficient one available. (I can probably dig up who made that statement.) - We get the ablity to fix hardware bugs even at times when the vendor doesn't care anymore (and that happens faster than most people like). - We also can add new features for old mainboards as long as the hardware can do it. The IDE LBA48 hard drive support in proprietary BIOS versions was one such example. Vendors simply didn't care about older boards and didn't release BIOS updates which could have added LBA48 support for IDE hard drives with sizes over 127 GB (a pure software thing) and people were forced to upgrade to newer boards. With coreboot, people would have recompiled a new BIOS version for their board, using the generic LBA48 support without any problems. > If the "proprietary low-level chipset initialization code" is in ROM > on the chips that it initializes, then it is tolerable. (It might as > well be circuits on that chip.) Otherwise, it is insufficient unless > made complete. > None of the current mainstream x86 board manufacturers uses real ROMs anymore. There are simply too many bugs in the hardware and firmware to be able to afford a no-upgrade solution. Besides that, EEPROMs are very cheap nowadays and the firmware for the board and the separate firmware for the onboard NIC can be stored in the same EEPROM which saves board space. Regards, Carl-Daniel From mylesgw at gmail.com Thu May 1 23:01:44 2008 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 1 May 2008 15:01:44 -0600 Subject: [coreboot] Buildrom lzma patch and update QEMU Config-lab.lb In-Reply-To: <2831fecf0805011341n1b83e7bbl14fa57d32458bfad@mail.gmail.com> References: <2831fecf0805011341n1b83e7bbl14fa57d32458bfad@mail.gmail.com> Message-ID: <03a201c8abce$9088b470$0023040a@chimp> > -----Original Message----- > From: Myles Watson [mailto:mylesgw at gmail.com] > Sent: Thursday, May 01, 2008 2:41 PM > To: Coreboot > Subject: Buildrom lzma patch and update QEMU Config-lab.lb > > These patches go together and make it so that checking the "USE_LZMA" > option in buildrom doesn't break builds. > > It assumes that all Config.lb files don't use compression, and all > Config-lab.lb files do. > > The qemu-lab.lzma.diff patch makes that change. I'll also bump up the revision of v2 that buildrom uses for QEMU to make the change effective. Myles > Signed-off-by: Myles Watson > > Thanks, > Myles From rminnich at gmail.com Fri May 2 03:25:07 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 1 May 2008 18:25:07 -0700 Subject: [coreboot] grub2 folks Message-ID: <13426df10805011825j32a15e0aldec5869215185178@mail.gmail.com> work with a customer-owned LB system today that is using LAB made me realize -- a very useful thing to have would be a grub2 that ran under linux, parsed the standard grub.cfg, and kexec'ed. Really, really needed. Not because LAB is inflexible, but because most sysadmins are. ron From c-d.hailfinger.devel.2006 at gmx.net Fri May 2 05:23:45 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 02 May 2008 05:23:45 +0200 Subject: [coreboot] v3 interaction problems with recent gcc? Message-ID: <481A8941.5020705@gmx.net> Hi, please be careful with any recent gcc if you expect it to compile v3/lib/lar.c the way it is intended to. We are likely to be affected by US-CERT Vulnerability Note VU#162289: C compilers may silently discard some wraparound checks. More info here: http://lwn.net/Articles/278137/ http://www.kb.cert.org/vuls/id/162289 Basically, it turned out that a long-time recommended C secure programming practice depended on undefined behaviour and nobody figured this out for years. Now that compilers optimize away undefined code all those wraparound checks explode. Most of the proposed fixes to existing code so far have been ugly (casting pointers to unsigned long) or advocate changing the code structure (calling an extra function to check for wraparound). v3/lib/lar.c:find_file() has the following for loop: > char *walk; > [...] > for (walk = archive->start; > (walk < (char *)(archive->start + archive->len - sizeof(struct > lar_header))) && > (walk >= (char *)archive->start); walk += 16) { AFAICS the check (walk >= (char *)archive->start) can be optimized away. Pointers to other possible affected code would be appreciated. Statements about the correctness of that for loop would be appreciated as well. Regards, Carl-Daniel From hansolofalcon at worldnet.att.net Fri May 2 05:29:07 2008 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Thu, 1 May 2008 23:29:07 -0400 Subject: [coreboot] Presenting at a LUG Message-ID: <006901c8ac04$af2344f0$6401a8c0@who8> Hello! Would anyone who's a member of the list, be interested in presenting at a LUG? I am a member of the NYLUG outfit, and I am interested in, call it being the one to welcome an associate of the list to the group. Although I suspect an officer of the group would want to do that. NYLUG incidentally is the New York Linux User's Group. It meets on the last Wednesday of each month. Physical demonstrations are very welcome at each presentation. Please note that I do not speak for the group, I am only a member of it. -- Gregg C Levine hansolofalcon at worldnet.att.net "The Force will be with you always." Obi-Wan Kenobi ? From hbkeultjes at earthlink.net Fri May 2 14:25:46 2008 From: hbkeultjes at earthlink.net (Henry keultjes) Date: Fri, 02 May 2008 08:25:46 -0400 Subject: [coreboot] Presenting at a LUG In-Reply-To: <006901c8ac04$af2344f0$6401a8c0@who8> References: <006901c8ac04$af2344f0$6401a8c0@who8> Message-ID: <481B084A.2080604@earthlink.net> The North Central Ohio Linux User Group (NCOLUG) based in Mansfield would likewise be interested in a Linux BIOS presentation. Mansfield is about half-way between Cleveland and Columbus. We would probably do this jointly with the Ohio IT Alliance and would most likely use http://www.ncsc.edu Kehoe Center OSU Mansfield as the venue. Henry Keultjes Gregg C Levine wrote: > Hello! > Would anyone who's a member of the list, be interested in presenting at a > LUG? > > I am a member of the NYLUG outfit, and I am interested in, call it being the > one to welcome an associate of the list to the group. Although I suspect an > officer of the group would want to do that. > > NYLUG incidentally is the New York Linux User's Group. It meets on the last > Wednesday of each month. > > Physical demonstrations are very welcome at each presentation. > > Please note that I do not speak for the group, I am only a member of it. > -- > Gregg C Levine hansolofalcon at worldnet.att.net > "The Force will be with you always." Obi-Wan Kenobi > > > > > > From sync.jma at gmail.com Fri May 2 14:55:50 2008 From: sync.jma at gmail.com (Jun Ma) Date: Fri, 2 May 2008 20:55:50 +0800 Subject: [coreboot] questions about "QEMU Build Tutorial" Message-ID: http://www.coreboot.org/QEMU_Build_Tutorial My test versions: coreboot v2- revision 3275 filo - v0.5- revision 45 qemu- v0.9.1 I followed steps described in that wiki page, and I got: " 1 init_drive: Probing for hda 2 init_drive: LBA mode, sectors=409600 3 init_drive: LBA48 mode, sectors=409600 4 init_drive: Init device params... ok 5 hda: LBA48 209MB: QEMU HARDDISK 6 init_controller: MASTER CHECK: master yes 7 init_controller: /*slave */ -- drive is 0 8 open_pc_partition: pc partition magic number not found " Have I missed anything? Seems 'qemu-create img' not produce the correct image? here is my xxd result: $ head disk.img | xxd | vi - " 1 0000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 2 0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 3 0000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 4 0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 5 0000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 6 0000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 7 0000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 8 0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 9 0000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 10 0000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 11 00000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 12 00000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 13 00000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 14 00000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 15 00000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 16 00000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 17 0000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 18 0000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 19 0000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 20 0000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 21 0000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 22 0000150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 23 0000160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 24 0000170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 25 0000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 26 0000190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 27 00001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 28 00001b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 29 00001c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 30 00001d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ " -- FIXME if it is wrong. From mylesgw at gmail.com Fri May 2 15:57:00 2008 From: mylesgw at gmail.com (Myles Watson) Date: Fri, 2 May 2008 07:57:00 -0600 Subject: [coreboot] buildrom payload.conf patch Message-ID: <2831fecf0805020657g25795017ue9701b326ce531a9@mail.gmail.com> This patch consolidates the payload .conf files to eliminate redundancy. A couple of them were not consolidated because it appeared that they will be more specialized in the future. follow the patch with: svn rm config/payloads/etherboot.conf svn rm config/payloads/memtest.conf svn rm config/payloads/tint.conf svn rm config/payloads/grub2.conf svn rm config/payloads/gpxe.conf svn rm config/payloads/coreinfo.conf svn rm config/payloads/filo.conf since they are no longer needed. file by file changes: Makefile: Eliminated a payload copy to simplify build. Added empty targets for custom and custom-clean. packages/coreboot-v3/coreboot-v3.mk: Same payload copy change as Makefile. packages/ofw/ofw.mk: Moved the SVN information here from ofw.conf because it is here for every other payload. config/payloads/ofw.conf: The only thing keeping this file here is a comment about crc32sum. config/payloads/payloads.conf: Change the way PAYLOAD and PAYLOAD-y are set. Both are needed for lab since lab is the name of the payload, but isn't an actual payload. config/payloads/lab.conf: Removed redundant PAYLOAD assignment. config/payloads/openbios.conf: Include the generic and leave this file for possible fcode-utils dependency. config/payloads/kernel.conf: Removed redundant PAYLOAD and PAYLOAD-y assignment. config/payloads/Config.in: Removed extra menu for Custom Payload with only one option in it. config/payloads/custom.conf: Simplified this file since there was no CUSTOM_PAYLOAD variable set anywhere. Included Makefile.generic so that lzma compression would just work. Signed-off-by: Myles Watson Thanks, Myles -------------- next part -------------- A non-text attachment was scrubbed... Name: consolidate_confs.diff Type: text/x-patch Size: 7062 bytes Desc: not available URL: From mylesgw at gmail.com Fri May 2 16:04:42 2008 From: mylesgw at gmail.com (Myles Watson) Date: Fri, 2 May 2008 08:04:42 -0600 Subject: [coreboot] buildrom payload.conf patch In-Reply-To: <2831fecf0805020657g25795017ue9701b326ce531a9@mail.gmail.com> References: <2831fecf0805020657g25795017ue9701b326ce531a9@mail.gmail.com> Message-ID: <2831fecf0805020704t6e387392w5b78fda08e91b3eb@mail.gmail.com> On Fri, May 2, 2008 at 7:57 AM, Myles Watson wrote: > This patch consolidates the payload .conf files to eliminate redundancy. A > couple of them were not consolidated because it appeared that they will be > more specialized in the future. > > follow the patch with: > svn rm config/payloads/etherboot.conf > svn rm config/payloads/memtest.conf > svn rm config/payloads/tint.conf > svn rm config/payloads/grub2.conf > svn rm config/payloads/gpxe.conf > svn rm config/payloads/coreinfo.conf > svn rm config/payloads/filo.conf > > since they are no longer needed. > > file by file changes: > > Makefile: > Eliminated a payload copy to simplify build. > Added empty targets for custom and custom-clean. > > packages/coreboot-v3/coreboot-v3.mk: > Same payload copy change as Makefile. > > packages/ofw/ofw.mk: > Moved the SVN information here from ofw.conf because it is here for every > other payload. > > config/payloads/ofw.conf: > The only thing keeping this file here is a comment about crc32sum. > > config/payloads/payloads.conf: > Change the way PAYLOAD and PAYLOAD-y are set. Both are needed for lab since > lab is the name of the payload, but isn't an actual payload. > > config/payloads/lab.conf: > Removed redundant PAYLOAD assignment. > > config/payloads/openbios.conf: > Include the generic and leave this file for possible fcode-utils dependency. > > config/payloads/kernel.conf: > Removed redundant PAYLOAD and PAYLOAD-y assignment. > > config/payloads/Config.in: > Removed extra menu for Custom Payload with only one option in it. > > config/payloads/custom.conf: > Simplified this file since there was no CUSTOM_PAYLOAD variable set anywhere. > Included Makefile.generic so that lzma compression would just work. I forgot to svn add the two new files. New patch attached. config/payloads/generic.conf: The commonalities from all the other .conf files config/payloads/libpayload-dep.conf: A .conf file for payloads that would have been generic, but they add a dependency on libpayload (tint, coreinfo). > Signed-off-by: Myles Watson > > Thanks, > Myles > -------------- next part -------------- A non-text attachment was scrubbed... Name: consolidate_confs.diff Type: text/x-patch Size: 7984 bytes Desc: not available URL: From mylesgw at gmail.com Fri May 2 17:12:46 2008 From: mylesgw at gmail.com (Myles Watson) Date: Fri, 2 May 2008 09:12:46 -0600 Subject: [coreboot] questions about "QEMU Build Tutorial" In-Reply-To: References: Message-ID: <03bf01c8ac66$fad7d6b0$0023040a@chimp> > http://www.coreboot.org/QEMU_Build_Tutorial > > My test versions: > coreboot v2- revision 3275 > filo - v0.5- revision 45 > qemu- v0.9.1 > > > I followed steps described in that wiki page, and I got: > " > > 1 init_drive: Probing for hda > 2 init_drive: LBA mode, sectors=409600 > 3 init_drive: LBA48 mode, sectors=409600 > 4 init_drive: Init device params... ok > 5 hda: LBA48 209MB: QEMU HARDDISK > 6 init_controller: MASTER CHECK: master yes > 7 init_controller: /*slave */ -- drive is 0 > 8 open_pc_partition: pc partition magic number not found > > " > Have I missed anything? Seems 'qemu-create img' not produce the correct > image? > here is my xxd result: > > $ head disk.img | xxd | vi - > > " > 1 0000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > 2 0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ I don't know how this tutorial is supposed to work. Disk.img is supposed to be the whole hard drive, and you're treating it like a partition with mkfs.ext2. Here is something that should work: 1. Create the raw image like it says in the tutorial 2. Boot QEMU with a rescue disk from your favorite OS 3. Run fdisk and create a single partition on the drive that takes up the whole drive 4. Quit and write the partition to disk 5. Run mkfs.ext2fs on that partition 6. Exit QEMU You now have a partitioned disk with an ext2 fs. You could have put in a second partition for swap while you were there, but lets keep this simple. Now you have a hard drive image with a partition and you need to mount that partition to copy the files you want. Use mount -o loop,skip=32256 disk.img /mnt/rootfs (Thanks to http://wiki.archlinux.org/index.php/Qemu) and continue the tutorial. To restate: The problem is that when you run mkfs.ext2 on the disk.img, you're formatting it as if it were a partition, not a drive, and you don't have a valid partition table. There are many other ways to get this done, I think this is the easiest. If you can't get it to work you might also try: 1. Stealing the first 32256 bytes (63 * 512B sectors) from a known good image of the same size and concatenating it to the front of a partition like you made in the tutorial (- 63 sectors) Hope that helps, Myles PS The page I referenced above has other advanced tips too. From jordan.crouse at amd.com Fri May 2 17:19:26 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Fri, 2 May 2008 09:19:26 -0600 Subject: [coreboot] buildrom payload.conf patch In-Reply-To: <2831fecf0805020657g25795017ue9701b326ce531a9@mail.gmail.com> References: <2831fecf0805020657g25795017ue9701b326ce531a9@mail.gmail.com> Message-ID: <20080502151926.GL31251@cosmic.amd.com> On 02/05/08 07:57 -0600, Myles Watson wrote: > This patch consolidates the payload .conf files to eliminate redundancy. A > couple of them were not consolidated because it appeared that they will be > more specialized in the future. > follow the patch with: > svn rm config/payloads/etherboot.conf > svn rm config/payloads/memtest.conf > svn rm config/payloads/tint.conf > svn rm config/payloads/grub2.conf > svn rm config/payloads/gpxe.conf > svn rm config/payloads/coreinfo.conf > svn rm config/payloads/filo.conf > > since they are no longer needed. > file by file changes: > > Makefile: > Eliminated a payload copy to simplify build. > Added empty targets for custom and custom-clean. > > packages/coreboot-v3/coreboot-v3.mk: > Same payload copy change as Makefile. > > packages/ofw/ofw.mk: > Moved the SVN information here from ofw.conf because it is here for every > other payload. > > config/payloads/ofw.conf: > The only thing keeping this file here is a comment about crc32sum. > > config/payloads/payloads.conf: > Change the way PAYLOAD and PAYLOAD-y are set. Both are needed for lab since > lab is the name of the payload, but isn't an actual payload. > > config/payloads/lab.conf: > Removed redundant PAYLOAD assignment. > > config/payloads/openbios.conf: > Include the generic and leave this file for possible fcode-utils dependency. > > config/payloads/kernel.conf: > Removed redundant PAYLOAD and PAYLOAD-y assignment. > config/payloads/Config.in: > Removed extra menu for Custom Payload with only one option in it. > config/payloads/custom.conf: > Simplified this file since there was no CUSTOM_PAYLOAD variable set anywhere. > Included Makefile.generic so that lzma compression would just work. > > Signed-off-by: Myles Watson Acked-by: Jordan Crouse > Thanks, > Myles > Index: Makefile > =================================================================== > --- Makefile (revision 174) > +++ Makefile (working copy) > @@ -89,7 +89,7 @@ > > rom: $(HOSTTOOLS-y) payload $(COREBOOT-y) > @ cp $(CBV3_OUTPUT) $(TARGET_ROM_FILE) > - @ $(STAGING_DIR)/bin/lar $(LAR_PAYLOAD_FLAGS-y) $(TARGET_ROM_FILE) $(CBV3_PAYLOAD_TARGET):normal/payload > + @ $(STAGING_DIR)/bin/lar $(LAR_PAYLOAD_FLAGS-y) $(TARGET_ROM_FILE) $(PAYLOAD_TARGET):normal/payload > ifeq ($(CONFIG_VSA_LEGACY),y) > @ $(STAGING_DIR)/bin/lar $(LAR_PAYLOAD_FLAGS-y) $(TARGET_ROM_FILE) $(SOURCE_DIR)/amd_vsa_lx_1.01.bin:blob/vsa > endif > @@ -102,6 +102,10 @@ > @ $(STAGING_DIR)/bin/lar -z $(TARGET_ROM_FILE) > endif > > +# These empty dependencies are for the custom payload. > +custom: > +custom-clean: > + > payload: $(DEPENDS-y) $(PAYLOAD_TARGET) > > extract: $(PKG_extract) > Index: packages/coreboot-v3/coreboot-v3.mk > =================================================================== > --- packages/coreboot-v3/coreboot-v3.mk (revision 174) > +++ packages/coreboot-v3/coreboot-v3.mk (working copy) > @@ -37,11 +37,6 @@ > > CBV3_PATCHES ?= > > -CBV3_PAYLOAD_TARGET=$(CBV3_DIR)/payload.elf > - > -$(CBV3_PAYLOAD_TARGET): $(PAYLOAD_TARGET) > - @ cp $< $@ > - > $(SOURCE_DIR)/$(CBV3_TARBALL): > @ mkdir -p $(SOURCE_DIR)/coreboot-v3 > @ $(BIN_DIR)/fetchsvn.sh $(CBV3_URL) \ > @@ -72,7 +67,7 @@ > endif > @ touch $@ > > -$(CBV3_OUTPUT): $(CBV3_STAMP_DIR)/.configured $(CBV3_PAYLOAD_TARGET) > +$(CBV3_OUTPUT): $(CBV3_STAMP_DIR)/.configured $(PAYLOAD_TARGET) > @ echo "Building coreboot v3..." > @ $(MAKE) -C $(CBV3_SRC_DIR) $(CBV3_ROM_SIZE) > $(CBV3_BUILD_LOG) 2>&1 > > Index: packages/ofw/ofw.mk > =================================================================== > --- packages/ofw/ofw.mk (revision 174) > +++ packages/ofw/ofw.mk (working copy) > @@ -1,5 +1,8 @@ > # Build the OpenFirmware payload > > +OFW_SVN_URL=svn://openbios.org/openfirmware > +OFW_SVN_TAG=720 > + > OFW_DIR=$(BUILD_DIR)/ofw > OFW_SRC_DIR=$(OFW_DIR)/svn > OFW_BUILD_DIR=$(OFW_SRC_DIR)/cpu/x86/pc/biosload/build > Index: config/payloads/ofw.conf > =================================================================== > --- config/payloads/ofw.conf (revision 174) > +++ config/payloads/ofw.conf (working copy) > @@ -1,15 +1,5 @@ > # Configuration options for the OpenFirmware payload > > -# Common configuration options > +include $(CONFIG_DIR)/payloads/generic.conf > > -PAYLOAD_BUILD=scripts/Makefile.generic > - > -OFW_SVN_URL=svn://openbios.org/openfirmware > -OFW_SVN_TAG=720 > - > -PAYLOAD_ELF=$(OUTPUT_DIR)/ofw-payload.elf > -# LZMA isn't allowed for OFW, so no need to define a COMPRESSSED target > - > -PAYLOAD-y=ofw > #HOSTTOOLS-y=crc32sum > -PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/ofw/ofw.mk > Index: config/payloads/payloads.conf > =================================================================== > --- config/payloads/payloads.conf (revision 174) > +++ config/payloads/payloads.conf (working copy) > @@ -15,19 +15,31 @@ > > ### Include the correct payload configuration > > -PCONF-y= > +PAYLOAD-y= > +PAYLOAD-$(CONFIG_PAYLOAD_LAB) = lab > +PAYLOAD-$(CONFIG_PAYLOAD_ETHERBOOT) = etherboot > +PAYLOAD-$(CONFIG_PAYLOAD_GPXE) = gpxe > +PAYLOAD-$(CONFIG_PAYLOAD_FILO) = filo > +PAYLOAD-$(CONFIG_PAYLOAD_OFW) = ofw > +PAYLOAD-$(CONFIG_PAYLOAD_OPENBIOS) = openbios > +PAYLOAD-$(CONFIG_PAYLOAD_MEMTEST) = memtest > +PAYLOAD-$(CONFIG_PAYLOAD_KERNEL) = kernel > +PAYLOAD-$(CONFIG_PAYLOAD_CUSTOM) = custom > +PAYLOAD-$(CONFIG_PAYLOAD_COREINFO) = coreinfo > +PAYLOAD-$(CONFIG_PAYLOAD_TINT) = tint > +PAYLOAD-$(CONFIG_PAYLOAD_GRUB2) = grub2 > + > +# This is for custom configuration strings > +PAYLOAD=PAYLOAD-y > + > +PCONF-y= generic.conf > +PCONF-$(CONFIG_PAYLOAD_COREINFO) = libpayload-dep.conf > +PCONF-$(CONFIG_PAYLOAD_CUSTOM) = custom.conf > +PCONF-$(CONFIG_PAYLOAD_KERNEL) = kernel.conf > PCONF-$(CONFIG_PAYLOAD_LAB) = lab.conf > -PCONF-$(CONFIG_PAYLOAD_ETHERBOOT) = etherboot.conf > -PCONF-$(CONFIG_PAYLOAD_GPXE) = gpxe.conf > -PCONF-$(CONFIG_PAYLOAD_FILO) = filo.conf > PCONF-$(CONFIG_PAYLOAD_OFW) = ofw.conf > PCONF-$(CONFIG_PAYLOAD_OPENBIOS) = openbios.conf > -PCONF-$(CONFIG_PAYLOAD_MEMTEST) = memtest.conf > -PCONF-$(CONFIG_PAYLOAD_KERNEL) = kernel.conf > -PCONF-$(CONFIG_PAYLOAD_CUSTOM) = custom.conf > -PCONF-$(CONFIG_PAYLOAD_COREINFO) = coreinfo.conf > -PCONF-$(CONFIG_PAYLOAD_TINT) = tint.conf > -PCONF-$(CONFIG_PAYLOAD_GRUB2) = grub2.conf > +PCONF-$(CONFIG_PAYLOAD_TINT) = libpayload-dep.conf > > DEPENDS-y= > include $(CONFIG_DIR)/payloads/$(PCONF-y) > Index: config/payloads/lab.conf > =================================================================== > --- config/payloads/lab.conf (revision 174) > +++ config/payloads/lab.conf (working copy) > @@ -30,8 +30,6 @@ > PAYLOAD-$(CONFIG_BOOTMENU) += bootmenu > PAYLOAD-$(CONFIG_OLPCFLASH) += olpcflash > > -PAYLOAD=lab > - > HOSTTOOLS-y = mkelfimage unifdef > PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/mkelfimage/mkelfimage.mk > PAYLOAD_AND_DEP_MK+=$(PACKAGE_DIR)/uclibc/uclibc.mk > Index: config/payloads/openbios.conf > =================================================================== > --- config/payloads/openbios.conf (revision 174) > +++ config/payloads/openbios.conf (working copy) > @@ -1,17 +1,7 @@ > # Configuration options for the OpenBIOS payload > > -# Common configuration options > +include $(CONFIG_DIR)/payloads/generic.conf > > -PAYLOAD_BUILD=scripts/Makefile.generic > - > -PAYLOAD_ELF=$(OUTPUT_DIR)/openbios-payload.elf > -PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/openbios-payload.elf.lzma > - > -PAYLOAD-y=openbios > -PAYLOAD=openbios > - > # TODO: Build fcode-utils or expect user to install them? > # HOSTTOOLS-y=fcode-utils > > -PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/openbios/openbios.mk > - > Index: config/payloads/kernel.conf > =================================================================== > --- config/payloads/kernel.conf (revision 174) > +++ config/payloads/kernel.conf (working copy) > @@ -15,8 +15,5 @@ > PAYLOAD_ELF=$(OUTPUT_DIR)/kernel-payload.elf > PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/kernel-payload.elf.lzma > > -PAYLOAD-y= kernel > -PAYLOAD=kernel > - > HOSTTOOLS-y = mkelfimage > PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/mkelfimage/mkelfimage.mk > Index: config/payloads/Config.in > =================================================================== > --- config/payloads/Config.in (revision 174) > +++ config/payloads/Config.in (working copy) > @@ -77,17 +87,14 @@ > > endchoice > > -menu "Custom Payload" > -depends on PAYLOAD_CUSTOM > config CUSTOM_PAYLOAD > string "Custom payload filename" > + depends on PAYLOAD_CUSTOM > default "" > help > Specify a filename for the custom ELF payload you wish to attach > to the ROM. You can also specify the custom payload with the > CUSTOM_PAYLOAD environment variable. > - > -endmenu > > menu "Kernel Configuration" > depends on PAYLOAD_KERNEL > Index: config/payloads/custom.conf > =================================================================== > --- config/payloads/custom.conf (revision 174) > +++ config/payloads/custom.conf (working copy) > @@ -1,9 +1,6 @@ > -# Common configuration options > +# Include Makefile.generic for lzma compression > > -PAYLOAD_BUILD= > +PAYLOAD_BUILD=scripts/Makefile.generic > > -ifneq ($(CUSTOM_PAYLOAD),) > -PAYLOAD_ELF=$(CUSTOM_PAYLOAD) > -else > PAYLOAD_ELF=$(subst ",,$(CONFIG_CUSTOM_PAYLOAD)) > -endif > +PAYLOAD_COMPRESSED=$(PAYLOAD_ELF).lzma > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From svn at coreboot.org Fri May 2 18:18:01 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Fri, 2 May 2008 18:18:01 +0200 Subject: [coreboot] r175 - in buildrom-devel: . config/payloads packages/coreboot-v3 packages/ofw Message-ID: Author: myles Date: 2008-05-02 18:18:00 +0200 (Fri, 02 May 2008) New Revision: 175 Added: buildrom-devel/config/payloads/generic.conf buildrom-devel/config/payloads/libpayload-dep.conf Removed: buildrom-devel/config/payloads/coreinfo.conf buildrom-devel/config/payloads/etherboot.conf buildrom-devel/config/payloads/filo.conf buildrom-devel/config/payloads/gpxe.conf buildrom-devel/config/payloads/grub2.conf buildrom-devel/config/payloads/memtest.conf buildrom-devel/config/payloads/tint.conf Modified: buildrom-devel/Makefile buildrom-devel/config/payloads/Config.in buildrom-devel/config/payloads/custom.conf buildrom-devel/config/payloads/kernel.conf buildrom-devel/config/payloads/lab.conf buildrom-devel/config/payloads/ofw.conf buildrom-devel/config/payloads/openbios.conf buildrom-devel/config/payloads/payloads.conf buildrom-devel/packages/coreboot-v3/coreboot-v3.mk buildrom-devel/packages/ofw/ofw.mk Log: This patch consolidates the payload .conf files to eliminate redundancy. A couple of them were not consolidated because it appeared that they will be more specialized in the future. follow the patch with: svn rm config/payloads/etherboot.conf svn rm config/payloads/memtest.conf svn rm config/payloads/tint.conf svn rm config/payloads/grub2.conf svn rm config/payloads/gpxe.conf svn rm config/payloads/coreinfo.conf svn rm config/payloads/filo.conf since they are no longer needed. file by file changes: Makefile: Eliminated a payload copy to simplify build. Added empty targets for custom and custom-clean. packages/coreboot-v3/coreboot-v3.mk: Same payload copy change as Makefile. packages/ofw/ofw.mk: Moved the SVN information here from ofw.conf because it is here for every other payload. config/payloads/ofw.conf: The only thing keeping this file here is a comment about crc32sum. config/payloads/payloads.conf: Change the way PAYLOAD and PAYLOAD-y are set. Both are needed for lab since lab is the name of the payload, but isn't an actual payload. config/payloads/lab.conf: Removed redundant PAYLOAD assignment. config/payloads/openbios.conf: Include the generic and leave this file for possible fcode-utils dependency. config/payloads/kernel.conf: Removed redundant PAYLOAD and PAYLOAD-y assignment. config/payloads/Config.in: Removed extra menu for Custom Payload with only one option in it. config/payloads/custom.conf: Simplified this file since there was no CUSTOM_PAYLOAD variable set anywhere. Included Makefile.generic so that lzma compression would just work. config/payloads/generic.conf: The commonalities from all the other .conf files config/payloads/libpayload-dep.conf: A .conf file for payloads that would have been generic, but they add a dependency on libpayload (tint, coreinfo). Signed-off-by: Myles Watson Modified: buildrom-devel/Makefile =================================================================== --- buildrom-devel/Makefile 2008-04-30 21:38:00 UTC (rev 174) +++ buildrom-devel/Makefile 2008-05-02 16:18:00 UTC (rev 175) @@ -89,7 +89,7 @@ rom: $(HOSTTOOLS-y) payload $(COREBOOT-y) @ cp $(CBV3_OUTPUT) $(TARGET_ROM_FILE) - @ $(STAGING_DIR)/bin/lar $(LAR_PAYLOAD_FLAGS-y) $(TARGET_ROM_FILE) $(CBV3_PAYLOAD_TARGET):normal/payload + @ $(STAGING_DIR)/bin/lar $(LAR_PAYLOAD_FLAGS-y) $(TARGET_ROM_FILE) $(PAYLOAD_TARGET):normal/payload ifeq ($(CONFIG_VSA_LEGACY),y) @ $(STAGING_DIR)/bin/lar $(LAR_PAYLOAD_FLAGS-y) $(TARGET_ROM_FILE) $(SOURCE_DIR)/amd_vsa_lx_1.01.bin:blob/vsa endif @@ -102,6 +102,10 @@ @ $(STAGING_DIR)/bin/lar -z $(TARGET_ROM_FILE) endif +# These empty dependencies are for the custom payload. +custom: +custom-clean: + payload: $(DEPENDS-y) $(PAYLOAD_TARGET) extract: $(PKG_extract) Modified: buildrom-devel/config/payloads/Config.in =================================================================== --- buildrom-devel/config/payloads/Config.in 2008-04-30 21:38:00 UTC (rev 174) +++ buildrom-devel/config/payloads/Config.in 2008-05-02 16:18:00 UTC (rev 175) @@ -77,17 +77,14 @@ endchoice -menu "Custom Payload" -depends on PAYLOAD_CUSTOM config CUSTOM_PAYLOAD string "Custom payload filename" + depends on PAYLOAD_CUSTOM default "" help Specify a filename for the custom ELF payload you wish to attach to the ROM. You can also specify the custom payload with the CUSTOM_PAYLOAD environment variable. - -endmenu menu "Kernel Configuration" depends on PAYLOAD_KERNEL Deleted: buildrom-devel/config/payloads/coreinfo.conf =================================================================== --- buildrom-devel/config/payloads/coreinfo.conf 2008-04-30 21:38:00 UTC (rev 174) +++ buildrom-devel/config/payloads/coreinfo.conf 2008-05-02 16:18:00 UTC (rev 175) @@ -1,15 +0,0 @@ -# Configuration file for the coreinfo payload - -# Common configuration options - -PAYLOAD_BUILD=scripts/Makefile.generic - -PAYLOAD_ELF=$(OUTPUT_DIR)/coreinfo-payload.elf -PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/coreinfo-payload.elf.lzma - -PAYLOAD-y=coreinfo -PAYLOAD=coreinfo - -# Add libpayload as a dependency -PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/coreinfo/coreinfo.mk $(PACKAGE_DIR)/libpayload/libpayload.mk -DEPENDS-y=libpayload Modified: buildrom-devel/config/payloads/custom.conf =================================================================== --- buildrom-devel/config/payloads/custom.conf 2008-04-30 21:38:00 UTC (rev 174) +++ buildrom-devel/config/payloads/custom.conf 2008-05-02 16:18:00 UTC (rev 175) @@ -1,9 +1,6 @@ -# Common configuration options +# Include Makefile.generic for lzma compression -PAYLOAD_BUILD= +PAYLOAD_BUILD=scripts/Makefile.generic -ifneq ($(CUSTOM_PAYLOAD),) -PAYLOAD_ELF=$(CUSTOM_PAYLOAD) -else PAYLOAD_ELF=$(subst ",,$(CONFIG_CUSTOM_PAYLOAD)) -endif +PAYLOAD_COMPRESSED=$(PAYLOAD_ELF).lzma Deleted: buildrom-devel/config/payloads/etherboot.conf =================================================================== --- buildrom-devel/config/payloads/etherboot.conf 2008-04-30 21:38:00 UTC (rev 174) +++ buildrom-devel/config/payloads/etherboot.conf 2008-05-02 16:18:00 UTC (rev 175) @@ -1,11 +0,0 @@ -# Configuration file for the etherboot payload - -# Common configuration options - -PAYLOAD_BUILD=scripts/Makefile.generic - -PAYLOAD_ELF=$(OUTPUT_DIR)/etherboot-payload.elf -PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/etherboot-payload.elf.lzma - -PAYLOAD-y=etherboot -PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/etherboot/etherboot.mk Deleted: buildrom-devel/config/payloads/filo.conf =================================================================== --- buildrom-devel/config/payloads/filo.conf 2008-04-30 21:38:00 UTC (rev 174) +++ buildrom-devel/config/payloads/filo.conf 2008-05-02 16:18:00 UTC (rev 175) @@ -1,14 +0,0 @@ -# Configuration file for the etherboot payload - -# Common configuration options - -PAYLOAD_BUILD=scripts/Makefile.generic - -PAYLOAD_ELF=$(OUTPUT_DIR)/filo-payload.elf -PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/filo-payload.elf.lzma - -PAYLOAD-y=filo -PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/filo/filo.mk - -PAYLOAD=filo - Added: buildrom-devel/config/payloads/generic.conf =================================================================== --- buildrom-devel/config/payloads/generic.conf (rev 0) +++ buildrom-devel/config/payloads/generic.conf 2008-05-02 16:18:00 UTC (rev 175) @@ -0,0 +1,8 @@ +# Configuration file for most payloads without dependencies + +PAYLOAD_BUILD=scripts/Makefile.generic + +PAYLOAD_ELF=$(OUTPUT_DIR)/$(PAYLOAD-y)-payload.elf +PAYLOAD_COMPRESSED=$(PAYLOAD_ELF).lzma + +PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/$(PAYLOAD-y)/$(PAYLOAD-y).mk Deleted: buildrom-devel/config/payloads/gpxe.conf =================================================================== --- buildrom-devel/config/payloads/gpxe.conf 2008-04-30 21:38:00 UTC (rev 174) +++ buildrom-devel/config/payloads/gpxe.conf 2008-05-02 16:18:00 UTC (rev 175) @@ -1,13 +0,0 @@ -# Configuration file for the GPXE payload - -# Common configuration options - -PAYLOAD_BUILD=scripts/Makefile.generic - -PAYLOAD_ELF=$(OUTPUT_DIR)/gpxe-payload.elf -PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/gpxe-payload.elf.lzma - -PAYLOAD=gpxe -PAYLOAD-y=gpxe - -PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/gpxe/gpxe.mk Deleted: buildrom-devel/config/payloads/grub2.conf =================================================================== --- buildrom-devel/config/payloads/grub2.conf 2008-04-30 21:38:00 UTC (rev 174) +++ buildrom-devel/config/payloads/grub2.conf 2008-05-02 16:18:00 UTC (rev 175) @@ -1,13 +0,0 @@ -# Configuration file for the GRUB2 payload - -# Common configuration options - -PAYLOAD_BUILD=scripts/Makefile.generic - -PAYLOAD_ELF=$(OUTPUT_DIR)/grub2-payload.elf -PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/grub2-payload.elf.lzma - -PAYLOAD-y=grub2 -PAYLOAD=grub2 - -PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/grub2/grub2.mk Modified: buildrom-devel/config/payloads/kernel.conf =================================================================== --- buildrom-devel/config/payloads/kernel.conf 2008-04-30 21:38:00 UTC (rev 174) +++ buildrom-devel/config/payloads/kernel.conf 2008-05-02 16:18:00 UTC (rev 175) @@ -15,8 +15,5 @@ PAYLOAD_ELF=$(OUTPUT_DIR)/kernel-payload.elf PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/kernel-payload.elf.lzma -PAYLOAD-y= kernel -PAYLOAD=kernel - HOSTTOOLS-y = mkelfimage PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/mkelfimage/mkelfimage.mk Modified: buildrom-devel/config/payloads/lab.conf =================================================================== --- buildrom-devel/config/payloads/lab.conf 2008-04-30 21:38:00 UTC (rev 174) +++ buildrom-devel/config/payloads/lab.conf 2008-05-02 16:18:00 UTC (rev 175) @@ -30,8 +30,6 @@ PAYLOAD-$(CONFIG_BOOTMENU) += bootmenu PAYLOAD-$(CONFIG_OLPCFLASH) += olpcflash -PAYLOAD=lab - HOSTTOOLS-y = mkelfimage unifdef PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/mkelfimage/mkelfimage.mk PAYLOAD_AND_DEP_MK+=$(PACKAGE_DIR)/uclibc/uclibc.mk Added: buildrom-devel/config/payloads/libpayload-dep.conf =================================================================== --- buildrom-devel/config/payloads/libpayload-dep.conf (rev 0) +++ buildrom-devel/config/payloads/libpayload-dep.conf 2008-05-02 16:18:00 UTC (rev 175) @@ -0,0 +1,7 @@ +# Configuration file for the coreinfo payload + +include $(CONFIG_DIR)/payloads/generic.conf + +# Add libpayload as a dependency +PAYLOAD_AND_DEP_MK+= $(PACKAGE_DIR)/libpayload/libpayload.mk +DEPENDS-y=libpayload Deleted: buildrom-devel/config/payloads/memtest.conf =================================================================== --- buildrom-devel/config/payloads/memtest.conf 2008-04-30 21:38:00 UTC (rev 174) +++ buildrom-devel/config/payloads/memtest.conf 2008-05-02 16:18:00 UTC (rev 175) @@ -1,12 +0,0 @@ -# Configuration file for the memtest payload - -# Common configuration options - -PAYLOAD_BUILD=scripts/Makefile.generic - -PAYLOAD_ELF=$(OUTPUT_DIR)/memtest-payload.elf -PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/memtest-payload.elf.lzma - -PAYLOAD-y=memtest - -PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/memtest/memtest.mk Modified: buildrom-devel/config/payloads/ofw.conf =================================================================== --- buildrom-devel/config/payloads/ofw.conf 2008-04-30 21:38:00 UTC (rev 174) +++ buildrom-devel/config/payloads/ofw.conf 2008-05-02 16:18:00 UTC (rev 175) @@ -1,15 +1,5 @@ # Configuration options for the OpenFirmware payload -# Common configuration options +include $(CONFIG_DIR)/payloads/generic.conf -PAYLOAD_BUILD=scripts/Makefile.generic - -OFW_SVN_URL=svn://openbios.org/openfirmware -OFW_SVN_TAG=720 - -PAYLOAD_ELF=$(OUTPUT_DIR)/ofw-payload.elf -# LZMA isn't allowed for OFW, so no need to define a COMPRESSSED target - -PAYLOAD-y=ofw #HOSTTOOLS-y=crc32sum -PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/ofw/ofw.mk Modified: buildrom-devel/config/payloads/openbios.conf =================================================================== --- buildrom-devel/config/payloads/openbios.conf 2008-04-30 21:38:00 UTC (rev 174) +++ buildrom-devel/config/payloads/openbios.conf 2008-05-02 16:18:00 UTC (rev 175) @@ -1,17 +1,7 @@ # Configuration options for the OpenBIOS payload -# Common configuration options +include $(CONFIG_DIR)/payloads/generic.conf -PAYLOAD_BUILD=scripts/Makefile.generic - -PAYLOAD_ELF=$(OUTPUT_DIR)/openbios-payload.elf -PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/openbios-payload.elf.lzma - -PAYLOAD-y=openbios -PAYLOAD=openbios - # TODO: Build fcode-utils or expect user to install them? # HOSTTOOLS-y=fcode-utils -PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/openbios/openbios.mk - Modified: buildrom-devel/config/payloads/payloads.conf =================================================================== --- buildrom-devel/config/payloads/payloads.conf 2008-04-30 21:38:00 UTC (rev 174) +++ buildrom-devel/config/payloads/payloads.conf 2008-05-02 16:18:00 UTC (rev 175) @@ -15,19 +15,31 @@ ### Include the correct payload configuration -PCONF-y= +PAYLOAD-y= +PAYLOAD-$(CONFIG_PAYLOAD_LAB) = lab +PAYLOAD-$(CONFIG_PAYLOAD_ETHERBOOT) = etherboot +PAYLOAD-$(CONFIG_PAYLOAD_GPXE) = gpxe +PAYLOAD-$(CONFIG_PAYLOAD_FILO) = filo +PAYLOAD-$(CONFIG_PAYLOAD_OFW) = ofw +PAYLOAD-$(CONFIG_PAYLOAD_OPENBIOS) = openbios +PAYLOAD-$(CONFIG_PAYLOAD_MEMTEST) = memtest +PAYLOAD-$(CONFIG_PAYLOAD_KERNEL) = kernel +PAYLOAD-$(CONFIG_PAYLOAD_CUSTOM) = custom +PAYLOAD-$(CONFIG_PAYLOAD_COREINFO) = coreinfo +PAYLOAD-$(CONFIG_PAYLOAD_TINT) = tint +PAYLOAD-$(CONFIG_PAYLOAD_GRUB2) = grub2 + +# This is for custom configuration strings +PAYLOAD=PAYLOAD-y + +PCONF-y= generic.conf +PCONF-$(CONFIG_PAYLOAD_COREINFO) = libpayload-dep.conf +PCONF-$(CONFIG_PAYLOAD_CUSTOM) = custom.conf +PCONF-$(CONFIG_PAYLOAD_KERNEL) = kernel.conf PCONF-$(CONFIG_PAYLOAD_LAB) = lab.conf -PCONF-$(CONFIG_PAYLOAD_ETHERBOOT) = etherboot.conf -PCONF-$(CONFIG_PAYLOAD_GPXE) = gpxe.conf -PCONF-$(CONFIG_PAYLOAD_FILO) = filo.conf PCONF-$(CONFIG_PAYLOAD_OFW) = ofw.conf PCONF-$(CONFIG_PAYLOAD_OPENBIOS) = openbios.conf -PCONF-$(CONFIG_PAYLOAD_MEMTEST) = memtest.conf -PCONF-$(CONFIG_PAYLOAD_KERNEL) = kernel.conf -PCONF-$(CONFIG_PAYLOAD_CUSTOM) = custom.conf -PCONF-$(CONFIG_PAYLOAD_COREINFO) = coreinfo.conf -PCONF-$(CONFIG_PAYLOAD_TINT) = tint.conf -PCONF-$(CONFIG_PAYLOAD_GRUB2) = grub2.conf +PCONF-$(CONFIG_PAYLOAD_TINT) = libpayload-dep.conf DEPENDS-y= include $(CONFIG_DIR)/payloads/$(PCONF-y) Deleted: buildrom-devel/config/payloads/tint.conf =================================================================== --- buildrom-devel/config/payloads/tint.conf 2008-04-30 21:38:00 UTC (rev 174) +++ buildrom-devel/config/payloads/tint.conf 2008-05-02 16:18:00 UTC (rev 175) @@ -1,16 +0,0 @@ -# Configuration file for the tint payload - -# Common configuration options - -PAYLOAD_BUILD=scripts/Makefile.generic - -PAYLOAD_ELF=$(OUTPUT_DIR)/tint-payload.elf -PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/tint-payload.elf.lzma - -PAYLOAD-y=tint -PAYLOAD=tint - -PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/libpayload/libpayload.mk $(PACKAGE_DIR)/tint/tint.mk - -# Add libpayload as a dependency -DEPENDS-y=libpayload Modified: buildrom-devel/packages/coreboot-v3/coreboot-v3.mk =================================================================== --- buildrom-devel/packages/coreboot-v3/coreboot-v3.mk 2008-04-30 21:38:00 UTC (rev 174) +++ buildrom-devel/packages/coreboot-v3/coreboot-v3.mk 2008-05-02 16:18:00 UTC (rev 175) @@ -37,11 +37,6 @@ CBV3_PATCHES ?= -CBV3_PAYLOAD_TARGET=$(CBV3_DIR)/payload.elf - -$(CBV3_PAYLOAD_TARGET): $(PAYLOAD_TARGET) - @ cp $< $@ - $(SOURCE_DIR)/$(CBV3_TARBALL): @ mkdir -p $(SOURCE_DIR)/coreboot-v3 @ $(BIN_DIR)/fetchsvn.sh $(CBV3_URL) \ @@ -72,7 +67,7 @@ endif @ touch $@ -$(CBV3_OUTPUT): $(CBV3_STAMP_DIR)/.configured $(CBV3_PAYLOAD_TARGET) +$(CBV3_OUTPUT): $(CBV3_STAMP_DIR)/.configured $(PAYLOAD_TARGET) @ echo "Building coreboot v3..." @ $(MAKE) -C $(CBV3_SRC_DIR) $(CBV3_ROM_SIZE) > $(CBV3_BUILD_LOG) 2>&1 Modified: buildrom-devel/packages/ofw/ofw.mk =================================================================== --- buildrom-devel/packages/ofw/ofw.mk 2008-04-30 21:38:00 UTC (rev 174) +++ buildrom-devel/packages/ofw/ofw.mk 2008-05-02 16:18:00 UTC (rev 175) @@ -1,5 +1,8 @@ # Build the OpenFirmware payload +OFW_SVN_URL=svn://openbios.org/openfirmware +OFW_SVN_TAG=720 + OFW_DIR=$(BUILD_DIR)/ofw OFW_SRC_DIR=$(OFW_DIR)/svn OFW_BUILD_DIR=$(OFW_SRC_DIR)/cpu/x86/pc/biosload/build From mylesgw at gmail.com Fri May 2 18:19:39 2008 From: mylesgw at gmail.com (Myles Watson) Date: Fri, 2 May 2008 10:19:39 -0600 Subject: [coreboot] buildrom payload.conf patch In-Reply-To: <20080502151926.GL31251@cosmic.amd.com> References: <2831fecf0805020657g25795017ue9701b326ce531a9@mail.gmail.com> <20080502151926.GL31251@cosmic.amd.com> Message-ID: <2831fecf0805020919v27cbaab3n66e0fb975bf69c27@mail.gmail.com> On Fri, May 2, 2008 at 9:19 AM, Jordan Crouse wrote: > > On 02/05/08 07:57 -0600, Myles Watson wrote: > > This patch consolidates the payload .conf files to eliminate redundancy. A > > couple of them were not consolidated because it appeared that they will be > > more specialized in the future. > > > follow the patch with: > > svn rm config/payloads/etherboot.conf > > svn rm config/payloads/memtest.conf > > svn rm config/payloads/tint.conf > > svn rm config/payloads/grub2.conf > > svn rm config/payloads/gpxe.conf > > svn rm config/payloads/coreinfo.conf > > svn rm config/payloads/filo.conf > > > > since they are no longer needed. > > > file by file changes: > > > > Makefile: > > Eliminated a payload copy to simplify build. > > Added empty targets for custom and custom-clean. > > > > packages/coreboot-v3/coreboot-v3.mk: > > Same payload copy change as Makefile. > > > > packages/ofw/ofw.mk: > > Moved the SVN information here from ofw.conf because it is here for every > > other payload. > > > > config/payloads/ofw.conf: > > The only thing keeping this file here is a comment about crc32sum. > > > > config/payloads/payloads.conf: > > Change the way PAYLOAD and PAYLOAD-y are set. Both are needed for lab since > > lab is the name of the payload, but isn't an actual payload. > > > > config/payloads/lab.conf: > > Removed redundant PAYLOAD assignment. > > > > config/payloads/openbios.conf: > > Include the generic and leave this file for possible fcode-utils dependency. > > > > config/payloads/kernel.conf: > > Removed redundant PAYLOAD and PAYLOAD-y assignment. > > > config/payloads/Config.in: > > Removed extra menu for Custom Payload with only one option in it. > > > config/payloads/custom.conf: > > Simplified this file since there was no CUSTOM_PAYLOAD variable set anywhere. > > Included Makefile.generic so that lzma compression would just work. > > > > Signed-off-by: Myles Watson > > Acked-by: Jordan Crouse Rev. 175. Sorry I forgot to put the Acked-by line in the commit message. Thanks, Myles From sync.jma at gmail.com Fri May 2 18:21:52 2008 From: sync.jma at gmail.com (Jun Ma) Date: Sat, 3 May 2008 00:21:52 +0800 Subject: [coreboot] questions about "QEMU Build Tutorial" In-Reply-To: <03bf01c8ac66$fad7d6b0$0023040a@chimp> References: <03bf01c8ac66$fad7d6b0$0023040a@chimp> Message-ID: On Fri, May 2, 2008 at 11:12 PM, Myles Watson wrote: > > > http://www.coreboot.org/QEMU_Build_Tutorial > > > I don't know how this tutorial is supposed to work. Disk.img is supposed to > be the whole hard drive, and you're treating it like a partition with > mkfs.ext2. Here is something that should work: > > 1. Create the raw image like it says in the tutorial > 2. Boot QEMU with a rescue disk from your favorite OS > 3. Run fdisk and create a single partition on the drive that takes up the > whole drive > 4. Quit and write the partition to disk > 5. Run mkfs.ext2fs on that partition > 6. Exit QEMU > > You now have a partitioned disk with an ext2 fs. You could have put in a > second partition for swap while you were there, but lets keep this simple. > > Now you have a hard drive image with a partition and you need to mount that > partition to copy the files you want. > > Use > > mount -o loop,skip=32256 disk.img /mnt/rootfs > > (Thanks to http://wiki.archlinux.org/index.php/Qemu) > > and continue the tutorial. > > To restate: The problem is that when you run mkfs.ext2 on the disk.img, > you're formatting it as if it were a partition, not a drive, and you don't > have a valid partition table. > > There are many other ways to get this done, I think this is the easiest. If > you can't get it to work you might also try: > > 1. Stealing the first 32256 bytes (63 * 512B sectors) from a known good > image of the same size and concatenating it to the front of a partition like > you made in the tutorial (- 63 sectors) > > Hope that helps, Thanks, Myles. This wiki maybe need update, :) I supposed that wiki page to be the official coreboot guide. I just installed debian-4.0r2 using qemu-0.9.1(and bochs pc-bios), it works fine. Another try will be taken for coreboot tomorrow, I would like to write a new doc about "QEMU Build Tutorial". > > PS The page I referenced above has other advanced tips too. > > Nice page, thanks! -- FIXME if it is wrong. From peter at stuge.se Fri May 2 18:29:45 2008 From: peter at stuge.se (Peter Stuge) Date: Fri, 2 May 2008 18:29:45 +0200 Subject: [coreboot] flashrom: Add tested field to flashchips table. Message-ID: <20080502162945.12596.qmail@stuge.se> Patch attached. If/when this is acked and committed I think it would be nice to mark lots of chips tested before the release. I suggest that we self-ack any patches that only change chip test status from TEST_UNTESTED. //Peter -------------- next part -------------- flashrom: Add a tested field to the flash chip table. At the moment three values exist, TEST_UNTESTED, TEST_OK and TEST_NOTWORKING. For all values other than TEST_OK the user is instructed to email a report to the coreboot mailing list so that the table can be updated. All chips are TEST_UNTESTED. Signed-off-by: Peter Stuge Index: flashrom.2.chiptested/flash.h =================================================================== --- flashrom.2.chiptested/flash.h (revision 3272) +++ flashrom.2.chiptested/flash.h (working copy) @@ -45,6 +45,11 @@ int total_size; int page_size; + /* Indicate if flashrom has been tested with this flash chip and if + * everything worked correctly. + */ + uint8_t tested; + int (*probe) (struct flashchip *flash); int (*erase) (struct flashchip *flash); int (*write) (struct flashchip *flash, uint8_t *buf); @@ -55,6 +60,10 @@ volatile uint8_t *virtual_registers; }; +#define TEST_UNTESTED 0 +#define TEST_OK 1 +#define TEST_NOTWORKING 2 + extern struct flashchip flashchips[]; /* Index: flashrom.2.chiptested/flashchips.c =================================================================== --- flashrom.2.chiptested/flashchips.c (revision 3272) +++ flashrom.2.chiptested/flashchips.c (working copy) @@ -32,111 +32,111 @@ * the output of 'flashrom -L' is alphabetically sorted. */ struct flashchip flashchips[] = { - /******************************************************************************************************************************************************************************************************/ - /* Vendor Chip Vendor ID Chip ID TODO TODO Probe function Erase function Write function Read function */ - /******************************************************************************************************************************************************************************************************/ - {"AMD", "Am29F016D", AMD_ID, AM_29F016D, 2048, 64 * 1024, probe_29f040b, erase_29f040b, write_29f040b}, - {"AMD", "Am29F040B", AMD_ID, AM_29F040B, 512, 64 * 1024, probe_29f040b, erase_29f040b, write_29f040b}, - {"AMD", "Am29LV040B", AMD_ID, AM_29LV040B, 512, 64 * 1024, probe_29f040b, erase_29f040b, write_29f040b}, - {"ASD", "AE49F2008", ASD_ID, ASD_AE49F2008, 256, 128, probe_jedec, erase_chip_jedec, write_jedec}, - {"Atmel", "AT29C020", ATMEL_ID, AT_29C020, 256, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"Atmel", "AT29C040A", ATMEL_ID, AT_29C040A, 512, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"Atmel", "AT49F002(N)", ATMEL_ID, AT_49F002N, 256, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"Atmel", "AT49F002(N)T", ATMEL_ID, AT_49F002NT, 256, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"EMST", "F49B002UA", EMST_ID, EMST_F49B002UA, 256, 4096, probe_jedec, erase_chip_jedec, write_49f002}, - {"EON", "EN29F002(A)(N)B", EON_ID, EN_29F002B, 256, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"EON", "EN29F002(A)(N)T", EON_ID, EN_29F002T, 256, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"Fujitsu", "MBM29F400TC", FUJITSU_ID, MBM29F400TC_STRANGE, 512, 64 * 1024, probe_m29f400bt, erase_m29f400bt, write_coreboot_m29f400bt}, - {"Intel", "82802AB", INTEL_ID, 173, 512, 64 * 1024, probe_82802ab, erase_82802ab, write_82802ab}, - {"Intel", "82802AC", INTEL_ID, 172, 1024, 64 * 1024, probe_82802ab, erase_82802ab, write_82802ab}, - {"Macronix", "MX25L3205", MX_ID, MX_25L3205, 4096, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Macronix", "MX25L4005", MX_ID, MX_25L4005, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Macronix", "MX25L8005", MX_ID, MX_25L8005, 1024, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Macronix", "MX29F002", MX_ID, MX_29F002, 256, 64 * 1024, probe_29f002, erase_29f002, write_29f002}, + /**********************************************************************************************************************************************************************************************************************/ + /* Vendor Chip Vendor ID Chip ID TODO TODO Tested Probe function Erase function Write function Read function */ + /**********************************************************************************************************************************************************************************************************************/ + {"AMD", "Am29F016D", AMD_ID, AM_29F016D, 2048, 64 * 1024, TEST_UNTESTED, probe_29f040b, erase_29f040b, write_29f040b}, + {"AMD", "Am29F040B", AMD_ID, AM_29F040B, 512, 64 * 1024, TEST_UNTESTED, probe_29f040b, erase_29f040b, write_29f040b}, + {"AMD", "Am29LV040B", AMD_ID, AM_29LV040B, 512, 64 * 1024, TEST_UNTESTED, probe_29f040b, erase_29f040b, write_29f040b}, + {"ASD", "AE49F2008", ASD_ID, ASD_AE49F2008, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Atmel", "AT29C020", ATMEL_ID, AT_29C020, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Atmel", "AT29C040A", ATMEL_ID, AT_29C040A, 512, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Atmel", "AT49F002(N)", ATMEL_ID, AT_49F002N, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Atmel", "AT49F002(N)T", ATMEL_ID, AT_49F002NT, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"EMST", "F49B002UA", EMST_ID, EMST_F49B002UA, 256, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"EON", "EN29F002(A)(N)B", EON_ID, EN_29F002B, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"EON", "EN29F002(A)(N)T", EON_ID, EN_29F002T, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Fujitsu", "MBM29F400TC", FUJITSU_ID, MBM29F400TC_STRANGE, 512, 64 * 1024, TEST_UNTESTED, probe_m29f400bt, erase_m29f400bt, write_coreboot_m29f400bt}, + {"Intel", "82802AB", INTEL_ID, 173, 512, 64 * 1024, TEST_UNTESTED, probe_82802ab, erase_82802ab, write_82802ab}, + {"Intel", "82802AC", INTEL_ID, 172, 1024, 64 * 1024, TEST_UNTESTED, probe_82802ab, erase_82802ab, write_82802ab}, + {"Macronix", "MX25L3205", MX_ID, MX_25L3205, 4096, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Macronix", "MX25L4005", MX_ID, MX_25L4005, 512, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Macronix", "MX25L8005", MX_ID, MX_25L8005, 1024, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Macronix", "MX29F002", MX_ID, MX_29F002, 256, 64 * 1024, TEST_UNTESTED, probe_29f002, erase_29f002, write_29f002}, #ifndef DISABLE_DOC - {"M-Systems", "MD-2802", MSYSTEMS_ID, MSYSTEMS_MD2802, 8, 8 * 1024, probe_md2802, erase_md2802, write_md2802, read_md2802}, + {"M-Systems", "MD-2802", MSYSTEMS_ID, MSYSTEMS_MD2802, 8, 8 * 1024, TEST_UNTESTED, probe_md2802, erase_md2802, write_md2802, read_md2802}, #endif - {"PMC", "Pm25LV010", PMC_ID, PMC_25LV010, 128, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"PMC", "Pm25LV016B", PMC_ID, PMC_25LV016B, 2048, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"PMC", "Pm25LV020", PMC_ID, PMC_25LV020, 256, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"PMC", "Pm25LV040", PMC_ID, PMC_25LV040, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"PMC", "Pm25LV080B", PMC_ID, PMC_25LV080B, 1024, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"PMC", "Pm25LV512", PMC_ID, PMC_25LV512, 64, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"PMC", "Pm49FL002", PMC_ID_NOPREFIX,PMC_49FL002, 256, 16 * 1024, probe_jedec, erase_chip_jedec, write_49fl004}, - {"PMC", "Pm49FL004", PMC_ID_NOPREFIX,PMC_49FL004, 512, 64 * 1024, probe_jedec, erase_chip_jedec, write_49fl004}, - {"Sharp", "LHF00L04", SHARP_ID, SHARP_LHF00L04, 1024, 64 * 1024, probe_lhf00l04, erase_lhf00l04, write_lhf00l04}, - {"Spansion", "S25FL016A", SPANSION_ID, SPANSION_S25FL016A, 2048, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"SST", "SST25VF016B", SST_ID, SST_25VF016B, 2048, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"SST", "SST25VF040B", SST_ID, SST_25VF040B, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"SST", "SST28SF040A", SST_ID, SST_28SF040, 512, 256, probe_28sf040, erase_28sf040, write_28sf040}, - {"SST", "SST29EE020A", SST_ID, SST_29EE020A, 256, 128, probe_jedec, erase_chip_jedec, write_jedec}, - {"SST", "SST39SF010A", SST_ID, SST_39SF010, 128, 4096, probe_jedec, erase_chip_jedec, write_39sf020}, - {"SST", "SST39SF020A", SST_ID, SST_39SF020, 256, 4096, probe_jedec, erase_chip_jedec, write_39sf020}, - {"SST", "SST39SF040", SST_ID, SST_39SF040, 512, 4096, probe_jedec, erase_chip_jedec, write_39sf020}, - {"SST", "SST39VF020", SST_ID, SST_39VF020, 256, 4096, probe_jedec, erase_chip_jedec, write_39sf020}, + {"PMC", "Pm25LV010", PMC_ID, PMC_25LV010, 128, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"PMC", "Pm25LV016B", PMC_ID, PMC_25LV016B, 2048, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"PMC", "Pm25LV020", PMC_ID, PMC_25LV020, 256, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"PMC", "Pm25LV040", PMC_ID, PMC_25LV040, 512, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"PMC", "Pm25LV080B", PMC_ID, PMC_25LV080B, 1024, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"PMC", "Pm25LV512", PMC_ID, PMC_25LV512, 64, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"PMC", "Pm49FL002", PMC_ID_NOPREFIX,PMC_49FL002, 256, 16 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49fl004}, + {"PMC", "Pm49FL004", PMC_ID_NOPREFIX,PMC_49FL004, 512, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49fl004}, + {"Sharp", "LHF00L04", SHARP_ID, SHARP_LHF00L04, 1024, 64 * 1024, TEST_UNTESTED, probe_lhf00l04, erase_lhf00l04, write_lhf00l04}, + {"Spansion", "S25FL016A", SPANSION_ID, SPANSION_S25FL016A, 2048, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"SST", "SST25VF016B", SST_ID, SST_25VF016B, 2048, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"SST", "SST25VF040B", SST_ID, SST_25VF040B, 512, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"SST", "SST28SF040A", SST_ID, SST_28SF040, 512, 256, TEST_UNTESTED, probe_28sf040, erase_28sf040, write_28sf040}, + {"SST", "SST29EE020A", SST_ID, SST_29EE020A, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"SST", "SST39SF010A", SST_ID, SST_39SF010, 128, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"SST", "SST39SF020A", SST_ID, SST_39SF020, 256, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"SST", "SST39SF040", SST_ID, SST_39SF040, 512, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"SST", "SST39VF020", SST_ID, SST_39VF020, 256, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, // assume similar to 004B, ignoring data sheet - {"SST", "SST49LF002A/B", SST_ID, SST_49LF002A, 256, 16 * 1024, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, - {"SST", "SST49LF003A/B", SST_ID, SST_49LF003A, 384, 64 * 1024, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, - {"SST", "SST49LF004A/B", SST_ID, SST_49LF004A, 512, 64 * 1024, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, - {"SST", "SST49LF004C", SST_ID, SST_49LF004C, 512, 4 * 1024, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, - {"SST", "SST49LF008A", SST_ID, SST_49LF008A, 1024, 64 * 1024, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, - {"SST", "SST49LF008C", SST_ID, SST_49LF008C, 1024, 4 * 1024, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, - {"SST", "SST49LF016C", SST_ID, SST_49LF016C, 2048, 4 * 1024, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, - {"SST", "SST49LF020A", SST_ID, SST_49LF020A, 256, 16 * 1024, probe_jedec, erase_49lf040, write_49lf040}, - {"SST", "SST49LF040", SST_ID, SST_49LF040, 512, 4096, probe_jedec, erase_49lf040, write_49lf040}, - {"SST", "SST49LF040B", SST_ID, SST_49LF040B, 512, 64 * 1024, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, - {"SST", "SST49LF080A", SST_ID, SST_49LF080A, 1024, 4096, probe_jedec, erase_49lf040, write_49lf040}, - {"SST", "SST49LF160C", SST_ID, SST_49LF160C, 2048, 4 * 1024, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, - {"ST", "M25P05-A", ST_ID, ST_M25P05A, 64, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P10-A", ST_ID, ST_M25P10A, 128, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P128", ST_ID, ST_M25P128, 16384, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P16", ST_ID, ST_M25P16, 2048, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P20", ST_ID, ST_M25P20, 256, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P32", ST_ID, ST_M25P32, 4096, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P40", ST_ID, ST_M25P40, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P64", ST_ID, ST_M25P64, 8192, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P80", ST_ID, ST_M25P80, 1024, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M29F002B", ST_ID, ST_M29F002B, 256, 64 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"ST", "M29F002T/NT", ST_ID, ST_M29F002T, 256, 64 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"ST", "M29F040B", ST_ID, ST_M29F040B, 512, 64 * 1024, probe_29f040b, erase_29f040b, write_29f040b}, - {"ST", "M29F400BT", ST_ID, ST_M29F400BT, 512, 64 * 1024, probe_m29f400bt, erase_m29f400bt, write_coreboot_m29f400bt}, - {"ST", "M29W010B", ST_ID, ST_M29W010B, 128, 16 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"ST", "M29W040B", ST_ID, ST_M29W040B, 512, 64 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"ST", "M50FLW040A", ST_ID, ST_M50FLW040A, 512, 64 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"ST", "M50FLW040B", ST_ID, ST_M50FLW040B, 512, 64 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"ST", "M50FLW080A", ST_ID, ST_M50FLW080A, 1024, 64 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"ST", "M50FLW080B", ST_ID, ST_M50FLW080B, 1024, 64 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"ST", "M50FW016", ST_ID, ST_M50FW016, 2048, 64 * 1024, probe_82802ab, erase_82802ab, write_82802ab}, - {"ST", "M50FW040", ST_ID, ST_M50FW040, 512, 64 * 1024, probe_82802ab, erase_82802ab, write_82802ab}, - {"ST", "M50FW080", ST_ID, ST_M50FW080, 1024, 64 * 1024, probe_82802ab, erase_82802ab, write_82802ab}, - {"ST", "M50LPW116", ST_ID, ST_M50LPW116, 2048, 64 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"SyncMOS", "S29C31004T", SYNCMOS_ID, S29C31004T, 512, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"SyncMOS", "S29C51001T", SYNCMOS_ID, S29C51001T, 128, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"SyncMOS", "S29C51002T", SYNCMOS_ID, S29C51002T, 256, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"SyncMOS", "S29C51004T", SYNCMOS_ID, S29C51004T, 512, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"Winbond", "W25x10", WINBOND_NEX_ID, W_25X10, 128, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Winbond", "W25x20", WINBOND_NEX_ID, W_25X20, 256, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Winbond", "W25x40", WINBOND_NEX_ID, W_25X40, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Winbond", "W25x80", WINBOND_NEX_ID, W_25X80, 1024, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Winbond", "W29C011", WINBOND_ID, W_29C011, 128, 128, probe_jedec, erase_chip_jedec, write_jedec}, - {"Winbond", "W29C020C", WINBOND_ID, W_29C020C, 256, 128, probe_jedec, erase_chip_jedec, write_jedec}, - {"Winbond", "W29C040P", WINBOND_ID, W_29C040P, 512, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"Winbond", "W29EE011", WINBOND_ID, W_29C011, 128, 128, probe_w29ee011, erase_chip_jedec, write_jedec}, - {"Winbond", "W39V040A", WINBOND_ID, W_39V040A, 512, 64*1024, probe_jedec, erase_chip_jedec, write_39sf020}, - {"Winbond", "W39V040B", WINBOND_ID, W_39V040B, 512, 64*1024, probe_jedec, erase_chip_jedec, write_39sf020}, - {"Winbond", "W39V040FA", WINBOND_ID, W_39V040FA, 512, 64*1024, probe_jedec, erase_chip_jedec, write_39sf020}, - {"Winbond", "W39V080A", WINBOND_ID, W_39V080A, 1024, 64*1024, probe_jedec, erase_chip_jedec, write_39sf020}, - {"Winbond", "W49F002U", WINBOND_ID, W_49F002U, 256, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"Winbond", "W49V002A", WINBOND_ID, W_49V002A, 256, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"Winbond", "W49V002FA", WINBOND_ID, W_49V002FA, 256, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"Winbond", "W39V080FA", WINBOND_ID, W_39V080FA, 1024, 64*1024, probe_winbond_fwhub, erase_winbond_fwhub, write_winbond_fwhub}, - {"Winbond", "W39V080FA (dual mode)",WINBOND_ID, W_39V080FA_DM, 512, 64*1024, probe_winbond_fwhub, erase_winbond_fwhub, write_winbond_fwhub}, + {"SST", "SST49LF002A/B", SST_ID, SST_49LF002A, 256, 16 * 1024, TEST_UNTESTED, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, + {"SST", "SST49LF003A/B", SST_ID, SST_49LF003A, 384, 64 * 1024, TEST_UNTESTED, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, + {"SST", "SST49LF004A/B", SST_ID, SST_49LF004A, 512, 64 * 1024, TEST_UNTESTED, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, + {"SST", "SST49LF004C", SST_ID, SST_49LF004C, 512, 4 * 1024, TEST_UNTESTED, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, + {"SST", "SST49LF008A", SST_ID, SST_49LF008A, 1024, 64 * 1024, TEST_UNTESTED, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, + {"SST", "SST49LF008C", SST_ID, SST_49LF008C, 1024, 4 * 1024, TEST_UNTESTED, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, + {"SST", "SST49LF016C", SST_ID, SST_49LF016C, 2048, 4 * 1024, TEST_UNTESTED, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, + {"SST", "SST49LF020A", SST_ID, SST_49LF020A, 256, 16 * 1024, TEST_UNTESTED, probe_jedec, erase_49lf040, write_49lf040}, + {"SST", "SST49LF040", SST_ID, SST_49LF040, 512, 4096, TEST_UNTESTED, probe_jedec, erase_49lf040, write_49lf040}, + {"SST", "SST49LF040B", SST_ID, SST_49LF040B, 512, 64 * 1024, TEST_UNTESTED, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, + {"SST", "SST49LF080A", SST_ID, SST_49LF080A, 1024, 4096, TEST_UNTESTED, probe_jedec, erase_49lf040, write_49lf040}, + {"SST", "SST49LF160C", SST_ID, SST_49LF160C, 2048, 4 * 1024, TEST_UNTESTED, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, + {"ST", "M25P05-A", ST_ID, ST_M25P05A, 64, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P10-A", ST_ID, ST_M25P10A, 128, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P128", ST_ID, ST_M25P128, 16384, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P16", ST_ID, ST_M25P16, 2048, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P20", ST_ID, ST_M25P20, 256, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P32", ST_ID, ST_M25P32, 4096, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P40", ST_ID, ST_M25P40, 512, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P64", ST_ID, ST_M25P64, 8192, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P80", ST_ID, ST_M25P80, 1024, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M29F002B", ST_ID, ST_M29F002B, 256, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"ST", "M29F002T/NT", ST_ID, ST_M29F002T, 256, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"ST", "M29F040B", ST_ID, ST_M29F040B, 512, 64 * 1024, TEST_UNTESTED, probe_29f040b, erase_29f040b, write_29f040b}, + {"ST", "M29F400BT", ST_ID, ST_M29F400BT, 512, 64 * 1024, TEST_UNTESTED, probe_m29f400bt, erase_m29f400bt, write_coreboot_m29f400bt}, + {"ST", "M29W010B", ST_ID, ST_M29W010B, 128, 16 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"ST", "M29W040B", ST_ID, ST_M29W040B, 512, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"ST", "M50FLW040A", ST_ID, ST_M50FLW040A, 512, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"ST", "M50FLW040B", ST_ID, ST_M50FLW040B, 512, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"ST", "M50FLW080A", ST_ID, ST_M50FLW080A, 1024, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"ST", "M50FLW080B", ST_ID, ST_M50FLW080B, 1024, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"ST", "M50FW016", ST_ID, ST_M50FW016, 2048, 64 * 1024, TEST_UNTESTED, probe_82802ab, erase_82802ab, write_82802ab}, + {"ST", "M50FW040", ST_ID, ST_M50FW040, 512, 64 * 1024, TEST_UNTESTED, probe_82802ab, erase_82802ab, write_82802ab}, + {"ST", "M50FW080", ST_ID, ST_M50FW080, 1024, 64 * 1024, TEST_UNTESTED, probe_82802ab, erase_82802ab, write_82802ab}, + {"ST", "M50LPW116", ST_ID, ST_M50LPW116, 2048, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"SyncMOS", "S29C31004T", SYNCMOS_ID, S29C31004T, 512, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"SyncMOS", "S29C51001T", SYNCMOS_ID, S29C51001T, 128, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"SyncMOS", "S29C51002T", SYNCMOS_ID, S29C51002T, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"SyncMOS", "S29C51004T", SYNCMOS_ID, S29C51004T, 512, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"Winbond", "W25x10", WINBOND_NEX_ID, W_25X10, 128, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Winbond", "W25x20", WINBOND_NEX_ID, W_25X20, 256, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Winbond", "W25x40", WINBOND_NEX_ID, W_25X40, 512, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Winbond", "W25x80", WINBOND_NEX_ID, W_25X80, 1024, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Winbond", "W29C011", WINBOND_ID, W_29C011, 128, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Winbond", "W29C020C", WINBOND_ID, W_29C020C, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Winbond", "W29C040P", WINBOND_ID, W_29C040P, 512, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Winbond", "W29EE011", WINBOND_ID, W_29C011, 128, 128, TEST_UNTESTED, probe_w29ee011, erase_chip_jedec, write_jedec}, + {"Winbond", "W39V040A", WINBOND_ID, W_39V040A, 512, 64*1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"Winbond", "W39V040B", WINBOND_ID, W_39V040B, 512, 64*1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"Winbond", "W39V040FA", WINBOND_ID, W_39V040FA, 512, 64*1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"Winbond", "W39V080A", WINBOND_ID, W_39V080A, 1024, 64*1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"Winbond", "W49F002U", WINBOND_ID, W_49F002U, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"Winbond", "W49V002A", WINBOND_ID, W_49V002A, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"Winbond", "W49V002FA", WINBOND_ID, W_49V002FA, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"Winbond", "W39V080FA", WINBOND_ID, W_39V080FA, 1024, 64*1024, TEST_UNTESTED, probe_winbond_fwhub, erase_winbond_fwhub, write_winbond_fwhub}, + {"Winbond", "W39V080FA (dual mode)",WINBOND_ID, W_39V080FA_DM, 512, 64*1024, TEST_UNTESTED, probe_winbond_fwhub, erase_winbond_fwhub, write_winbond_fwhub}, - {"EON", "unknown SPI chip", EON_ID_NOPREFIX,GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, - {"Macronix", "unknown SPI chip", MX_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, - {"PMC", "unknown SPI chip", PMC_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, - {"SST", "unknown SPI chip", SST_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, - {"ST", "unknown SPI chip", ST_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, + {"EON", "unknown SPI chip", EON_ID_NOPREFIX,GENERIC_DEVICE_ID, 0, 0, TEST_UNTESTED, probe_spi, NULL, NULL}, + {"Macronix", "unknown SPI chip", MX_ID, GENERIC_DEVICE_ID, 0, 0, TEST_UNTESTED, probe_spi, NULL, NULL}, + {"PMC", "unknown SPI chip", PMC_ID, GENERIC_DEVICE_ID, 0, 0, TEST_UNTESTED, probe_spi, NULL, NULL}, + {"SST", "unknown SPI chip", SST_ID, GENERIC_DEVICE_ID, 0, 0, TEST_UNTESTED, probe_spi, NULL, NULL}, + {"ST", "unknown SPI chip", ST_ID, GENERIC_DEVICE_ID, 0, 0, TEST_UNTESTED, probe_spi, NULL, NULL}, {NULL,} }; Index: flashrom.2.chiptested/flashrom.c =================================================================== --- flashrom.2.chiptested/flashrom.c (revision 3272) +++ flashrom.2.chiptested/flashrom.c (working copy) @@ -407,6 +407,23 @@ } printf("Flash part is %s (%d KB).\n", flash->name, flash->total_size); + if (TEST_OK != flash->tested) { + printf("--\n"); + switch (flash->tested) { + case TEST_UNTESTED: + printf("This flash part is marked as UNTESTED.\n"); + break; + case TEST_NOTWORKING: + printf("This flash part is marked as NOT WORKING!\n"); + break; + default: + printf("This flash part has unknown test status %d.\n", flash->tested); + break; + } + printf("Please email coreboot at coreboot.org and report whether flashrom works correctly\n"); + printf("with this flash part. Thank you for your help!\n"); + printf("--\n"); + } if (!(read_it | write_it | verify_it | erase_it)) { printf("No operations were specified.\n"); From mylesgw at gmail.com Fri May 2 18:29:49 2008 From: mylesgw at gmail.com (Myles Watson) Date: Fri, 2 May 2008 10:29:49 -0600 Subject: [coreboot] questions about "QEMU Build Tutorial" In-Reply-To: References: <03bf01c8ac66$fad7d6b0$0023040a@chimp> Message-ID: <03c401c8ac71$bef617a0$0023040a@chimp> > Thanks, Myles. This wiki maybe need update, :) I supposed that wiki > page to be the official coreboot guide. > I just installed debian-4.0r2 using qemu-0.9.1(and bochs pc-bios), it > works fine. I'm glad something is working for you. It's easy for tutorials to get out of date. > Another try will be taken for coreboot tomorrow, I would like to write > a new doc about "QEMU Build Tutorial". Your contributions are welcome! Thanks, Myles From c-d.hailfinger.devel.2006 at gmx.net Fri May 2 18:34:34 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 02 May 2008 18:34:34 +0200 Subject: [coreboot] flashrom: Add tested field to flashchips table. In-Reply-To: <20080502162945.12596.qmail@stuge.se> References: <20080502162945.12596.qmail@stuge.se> Message-ID: <481B429A.5060201@gmx.net> On 02.05.2008 18:29, Peter Stuge wrote: > Patch attached. > > If/when this is acked and committed I think it would be nice to mark > lots of chips tested before the release. I suggest that we self-ack > any patches that only change chip test status from TEST_UNTESTED. > > > //Peter > Two minor comments: - People should have a separate address to turn to for any flashrom success reports. Subscribing to a list just for that purpose is user-hostile. - We need separate test status for probe/read/erase/verify. If the issues above are addressed, the patch is Acked-by: Carl-Daniel Hailfinger Regards, Carl-Daniel From joe at settoplinux.org Fri May 2 19:23:52 2008 From: joe at settoplinux.org (Joe) Date: Fri, 02 May 2008 13:23:52 -0400 Subject: [coreboot] flashrom: Add tested field to flashchips table. In-Reply-To: <481B429A.5060201@gmx.net> References: <20080502162945.12596.qmail@stuge.se> <481B429A.5060201@gmx.net> Message-ID: <0c12c15a72c9c97bbffb0245b70ee200@imap.1and1.com> On Fri, 02 May 2008 18:34:34 +0200, Carl-Daniel Hailfinger wrote: > On 02.05.2008 18:29, Peter Stuge wrote: >> Patch attached. >> >> If/when this is acked and committed I think it would be nice to mark >> lots of chips tested before the release. I suggest that we self-ack >> any patches that only change chip test status from TEST_UNTESTED. >> >> >> //Peter >> > > Two minor comments: > - People should have a separate address to turn to for any flashrom > success reports. Subscribing to a list just for that purpose is > user-hostile. > - We need separate test status for probe/read/erase/verify. > > If the issues above are addressed, the patch is > Acked-by: Carl-Daniel Hailfinger > Why not just put a link in the manpage pointing to http://www.coreboot.org/Flashrom#Supported_devices to show which chips have been tested? This why it is not redundent, right? -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org From uwe at hermann-uwe.de Fri May 2 19:28:06 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 2 May 2008 19:28:06 +0200 Subject: [coreboot] problem while flashing on Pm49fl004B In-Reply-To: References: Message-ID: <20080502172806.GA5856@greenwood> Hi, On Thu, May 01, 2008 at 01:08:18PM +0530, malatesh kamatad wrote: > While working on LinuxBios i erased bios content in the > origional flashrom chip while doing this my system become strucked at > that time when i rebooted the system but system not booted. > this is hapened while building the coreboot for MSI board by using the > AsRock board ..at the same time my harddisk is also damaged right now i dont > have backup file(origional bios ),but in my office i dont have other AsRock > motherboard for taking the bios content from that ,but i downloaded the bios > content for AsRock board from the website and then i tried to flash that > content to the erased flashrom chip but flashing is not happening ..... is > there any idea to get my bios back please inform me im in big troble You'll have to find a board with socketed BIOS in which you can enter your empty/dead ROM chip and flash the vendor BIOS from the web onto it. Alternatively, you can use an external ROM programmer if you have one, or buy a replacement chip _with_ the original BIOS on it from shops like e.g. http://bios-chip.de/, or others. See also http://www.coreboot.org/FAQ#Where_can_I_buy_BIOS_chips_.28empty_or_pre-flashed.29.3F HTH, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From peter at stuge.se Fri May 2 19:50:30 2008 From: peter at stuge.se (Peter Stuge) Date: Fri, 2 May 2008 19:50:30 +0200 Subject: [coreboot] flashrom: Add tested bitmap to flashchips table. In-Reply-To: <0c12c15a72c9c97bbffb0245b70ee200@imap.1and1.com> <481B429A.5060201@gmx.net> References: <20080502162945.12596.qmail@stuge.se> <481B429A.5060201@gmx.net> <0c12c15a72c9c97bbffb0245b70ee200@imap.1and1.com> <20080502162945.12596.qmail@stuge.se> <481B429A.5060201@gmx.net> Message-ID: <20080502175030.5882.qmail@stuge.se> On Fri, May 02, 2008 at 06:34:34PM +0200, Carl-Daniel Hailfinger wrote: > Two minor comments: > - People should have a separate address to turn to for any flashrom > success reports. Subscribing to a list just for that purpose is > user-hostile. Changed to flashrom at coreboot.org now. How we handle that adress I don't know. > - We need separate test status for probe/read/erase/verify. Good idea. I've changed the patch. > If the issues above are addressed, the patch is > Acked-by: Carl-Daniel Hailfinger Thanks! I'll hold off committing the attached patch for one more round of comments though. On Fri, May 02, 2008 at 01:23:52PM -0400, Joe wrote: > Why not just put a link in the manpage pointing to > http://www.coreboot.org/Flashrom#Supported_devices > to show which chips have been tested? A good idea, but unfortunately the wiki does not know what version of the program the user is running. If the user has an old version, bugs may have been fixed since the release to make more chips work, which is what the wiki would say, but they will still not work in the user's version. :\ //Peter -------------- next part -------------- flashrom: Add a tested bitmap field to the flash chip table. Two bits indicate OK and BAD for each operation PROBE READ ERASE WRITE. All 8 bits are in use now. No bits set means nothing has been tested. For chips with at least one operation that is not tested or not working, the user is asked to email a report to a special email adress so that the table can be updated. All chips are TEST_UNTESTED for now. Signed-off-by: Peter Stuge Index: flashrom.2.chiptested/flash.h =================================================================== --- flashrom.2.chiptested/flash.h (revision 3276) +++ flashrom.2.chiptested/flash.h (working copy) @@ -45,6 +45,11 @@ int total_size; int page_size; + /* Indicate if flashrom has been tested with this flash chip and if + * everything worked correctly. + */ + uint8_t tested; + int (*probe) (struct flashchip *flash); int (*erase) (struct flashchip *flash); int (*write) (struct flashchip *flash, uint8_t *buf); @@ -55,6 +60,20 @@ volatile uint8_t *virtual_registers; }; +#define TEST_UNTESTED 0 + +#define TEST_OK_PROBE (1<<0) +#define TEST_OK_READ (1<<1) +#define TEST_OK_ERASE (1<<2) +#define TEST_OK_WRITE (1<<3) +#define TEST_OK_MASK 0x0f + +#define TEST_BAD_PROBE (1<<4) +#define TEST_BAD_READ (1<<5) +#define TEST_BAD_ERASE (1<<6) +#define TEST_BAD_WRITE (1<<7) +#define TEST_BAD_MASK 0xf0 + extern struct flashchip flashchips[]; /* Index: flashrom.2.chiptested/flashchips.c =================================================================== --- flashrom.2.chiptested/flashchips.c (revision 3276) +++ flashrom.2.chiptested/flashchips.c (working copy) @@ -32,111 +32,111 @@ * the output of 'flashrom -L' is alphabetically sorted. */ struct flashchip flashchips[] = { - /******************************************************************************************************************************************************************************************************/ - /* Vendor Chip Vendor ID Chip ID TODO TODO Probe function Erase function Write function Read function */ - /******************************************************************************************************************************************************************************************************/ - {"AMD", "Am29F016D", AMD_ID, AM_29F016D, 2048, 64 * 1024, probe_29f040b, erase_29f040b, write_29f040b}, - {"AMD", "Am29F040B", AMD_ID, AM_29F040B, 512, 64 * 1024, probe_29f040b, erase_29f040b, write_29f040b}, - {"AMD", "Am29LV040B", AMD_ID, AM_29LV040B, 512, 64 * 1024, probe_29f040b, erase_29f040b, write_29f040b}, - {"ASD", "AE49F2008", ASD_ID, ASD_AE49F2008, 256, 128, probe_jedec, erase_chip_jedec, write_jedec}, - {"Atmel", "AT29C020", ATMEL_ID, AT_29C020, 256, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"Atmel", "AT29C040A", ATMEL_ID, AT_29C040A, 512, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"Atmel", "AT49F002(N)", ATMEL_ID, AT_49F002N, 256, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"Atmel", "AT49F002(N)T", ATMEL_ID, AT_49F002NT, 256, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"EMST", "F49B002UA", EMST_ID, EMST_F49B002UA, 256, 4096, probe_jedec, erase_chip_jedec, write_49f002}, - {"EON", "EN29F002(A)(N)B", EON_ID, EN_29F002B, 256, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"EON", "EN29F002(A)(N)T", EON_ID, EN_29F002T, 256, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"Fujitsu", "MBM29F400TC", FUJITSU_ID, MBM29F400TC_STRANGE, 512, 64 * 1024, probe_m29f400bt, erase_m29f400bt, write_coreboot_m29f400bt}, - {"Intel", "82802AB", INTEL_ID, 173, 512, 64 * 1024, probe_82802ab, erase_82802ab, write_82802ab}, - {"Intel", "82802AC", INTEL_ID, 172, 1024, 64 * 1024, probe_82802ab, erase_82802ab, write_82802ab}, - {"Macronix", "MX25L3205", MX_ID, MX_25L3205, 4096, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Macronix", "MX25L4005", MX_ID, MX_25L4005, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Macronix", "MX25L8005", MX_ID, MX_25L8005, 1024, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Macronix", "MX29F002", MX_ID, MX_29F002, 256, 64 * 1024, probe_29f002, erase_29f002, write_29f002}, + /**********************************************************************************************************************************************************************************************************************/ + /* Vendor Chip Vendor ID Chip ID TODO TODO Test status Probe function Erase function Write function Read function */ + /**********************************************************************************************************************************************************************************************************************/ + {"AMD", "Am29F016D", AMD_ID, AM_29F016D, 2048, 64 * 1024, TEST_UNTESTED, probe_29f040b, erase_29f040b, write_29f040b}, + {"AMD", "Am29F040B", AMD_ID, AM_29F040B, 512, 64 * 1024, TEST_UNTESTED, probe_29f040b, erase_29f040b, write_29f040b}, + {"AMD", "Am29LV040B", AMD_ID, AM_29LV040B, 512, 64 * 1024, TEST_UNTESTED, probe_29f040b, erase_29f040b, write_29f040b}, + {"ASD", "AE49F2008", ASD_ID, ASD_AE49F2008, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Atmel", "AT29C020", ATMEL_ID, AT_29C020, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Atmel", "AT29C040A", ATMEL_ID, AT_29C040A, 512, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Atmel", "AT49F002(N)", ATMEL_ID, AT_49F002N, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Atmel", "AT49F002(N)T", ATMEL_ID, AT_49F002NT, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"EMST", "F49B002UA", EMST_ID, EMST_F49B002UA, 256, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"EON", "EN29F002(A)(N)B", EON_ID, EN_29F002B, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"EON", "EN29F002(A)(N)T", EON_ID, EN_29F002T, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Fujitsu", "MBM29F400TC", FUJITSU_ID, MBM29F400TC_STRANGE, 512, 64 * 1024, TEST_UNTESTED, probe_m29f400bt, erase_m29f400bt, write_coreboot_m29f400bt}, + {"Intel", "82802AB", INTEL_ID, 173, 512, 64 * 1024, TEST_UNTESTED, probe_82802ab, erase_82802ab, write_82802ab}, + {"Intel", "82802AC", INTEL_ID, 172, 1024, 64 * 1024, TEST_UNTESTED, probe_82802ab, erase_82802ab, write_82802ab}, + {"Macronix", "MX25L3205", MX_ID, MX_25L3205, 4096, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Macronix", "MX25L4005", MX_ID, MX_25L4005, 512, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Macronix", "MX25L8005", MX_ID, MX_25L8005, 1024, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Macronix", "MX29F002", MX_ID, MX_29F002, 256, 64 * 1024, TEST_UNTESTED, probe_29f002, erase_29f002, write_29f002}, #ifndef DISABLE_DOC - {"M-Systems", "MD-2802", MSYSTEMS_ID, MSYSTEMS_MD2802, 8, 8 * 1024, probe_md2802, erase_md2802, write_md2802, read_md2802}, + {"M-Systems", "MD-2802", MSYSTEMS_ID, MSYSTEMS_MD2802, 8, 8 * 1024, TEST_UNTESTED, probe_md2802, erase_md2802, write_md2802, read_md2802}, #endif - {"PMC", "Pm25LV010", PMC_ID, PMC_25LV010, 128, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"PMC", "Pm25LV016B", PMC_ID, PMC_25LV016B, 2048, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"PMC", "Pm25LV020", PMC_ID, PMC_25LV020, 256, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"PMC", "Pm25LV040", PMC_ID, PMC_25LV040, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"PMC", "Pm25LV080B", PMC_ID, PMC_25LV080B, 1024, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"PMC", "Pm25LV512", PMC_ID, PMC_25LV512, 64, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"PMC", "Pm49FL002", PMC_ID_NOPREFIX,PMC_49FL002, 256, 16 * 1024, probe_jedec, erase_chip_jedec, write_49fl004}, - {"PMC", "Pm49FL004", PMC_ID_NOPREFIX,PMC_49FL004, 512, 64 * 1024, probe_jedec, erase_chip_jedec, write_49fl004}, - {"Sharp", "LHF00L04", SHARP_ID, SHARP_LHF00L04, 1024, 64 * 1024, probe_lhf00l04, erase_lhf00l04, write_lhf00l04}, - {"Spansion", "S25FL016A", SPANSION_ID, SPANSION_S25FL016A, 2048, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"SST", "SST25VF016B", SST_ID, SST_25VF016B, 2048, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"SST", "SST25VF040B", SST_ID, SST_25VF040B, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"SST", "SST28SF040A", SST_ID, SST_28SF040, 512, 256, probe_28sf040, erase_28sf040, write_28sf040}, - {"SST", "SST29EE020A", SST_ID, SST_29EE020A, 256, 128, probe_jedec, erase_chip_jedec, write_jedec}, - {"SST", "SST39SF010A", SST_ID, SST_39SF010, 128, 4096, probe_jedec, erase_chip_jedec, write_39sf020}, - {"SST", "SST39SF020A", SST_ID, SST_39SF020, 256, 4096, probe_jedec, erase_chip_jedec, write_39sf020}, - {"SST", "SST39SF040", SST_ID, SST_39SF040, 512, 4096, probe_jedec, erase_chip_jedec, write_39sf020}, - {"SST", "SST39VF020", SST_ID, SST_39VF020, 256, 4096, probe_jedec, erase_chip_jedec, write_39sf020}, + {"PMC", "Pm25LV010", PMC_ID, PMC_25LV010, 128, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"PMC", "Pm25LV016B", PMC_ID, PMC_25LV016B, 2048, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"PMC", "Pm25LV020", PMC_ID, PMC_25LV020, 256, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"PMC", "Pm25LV040", PMC_ID, PMC_25LV040, 512, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"PMC", "Pm25LV080B", PMC_ID, PMC_25LV080B, 1024, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"PMC", "Pm25LV512", PMC_ID, PMC_25LV512, 64, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"PMC", "Pm49FL002", PMC_ID_NOPREFIX,PMC_49FL002, 256, 16 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49fl004}, + {"PMC", "Pm49FL004", PMC_ID_NOPREFIX,PMC_49FL004, 512, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49fl004}, + {"Sharp", "LHF00L04", SHARP_ID, SHARP_LHF00L04, 1024, 64 * 1024, TEST_UNTESTED, probe_lhf00l04, erase_lhf00l04, write_lhf00l04}, + {"Spansion", "S25FL016A", SPANSION_ID, SPANSION_S25FL016A, 2048, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"SST", "SST25VF016B", SST_ID, SST_25VF016B, 2048, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"SST", "SST25VF040B", SST_ID, SST_25VF040B, 512, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"SST", "SST28SF040A", SST_ID, SST_28SF040, 512, 256, TEST_UNTESTED, probe_28sf040, erase_28sf040, write_28sf040}, + {"SST", "SST29EE020A", SST_ID, SST_29EE020A, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"SST", "SST39SF010A", SST_ID, SST_39SF010, 128, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"SST", "SST39SF020A", SST_ID, SST_39SF020, 256, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"SST", "SST39SF040", SST_ID, SST_39SF040, 512, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"SST", "SST39VF020", SST_ID, SST_39VF020, 256, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, // assume similar to 004B, ignoring data sheet - {"SST", "SST49LF002A/B", SST_ID, SST_49LF002A, 256, 16 * 1024, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, - {"SST", "SST49LF003A/B", SST_ID, SST_49LF003A, 384, 64 * 1024, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, - {"SST", "SST49LF004A/B", SST_ID, SST_49LF004A, 512, 64 * 1024, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, - {"SST", "SST49LF004C", SST_ID, SST_49LF004C, 512, 4 * 1024, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, - {"SST", "SST49LF008A", SST_ID, SST_49LF008A, 1024, 64 * 1024, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, - {"SST", "SST49LF008C", SST_ID, SST_49LF008C, 1024, 4 * 1024, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, - {"SST", "SST49LF016C", SST_ID, SST_49LF016C, 2048, 4 * 1024, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, - {"SST", "SST49LF020A", SST_ID, SST_49LF020A, 256, 16 * 1024, probe_jedec, erase_49lf040, write_49lf040}, - {"SST", "SST49LF040", SST_ID, SST_49LF040, 512, 4096, probe_jedec, erase_49lf040, write_49lf040}, - {"SST", "SST49LF040B", SST_ID, SST_49LF040B, 512, 64 * 1024, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, - {"SST", "SST49LF080A", SST_ID, SST_49LF080A, 1024, 4096, probe_jedec, erase_49lf040, write_49lf040}, - {"SST", "SST49LF160C", SST_ID, SST_49LF160C, 2048, 4 * 1024, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, - {"ST", "M25P05-A", ST_ID, ST_M25P05A, 64, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P10-A", ST_ID, ST_M25P10A, 128, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P128", ST_ID, ST_M25P128, 16384, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P16", ST_ID, ST_M25P16, 2048, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P20", ST_ID, ST_M25P20, 256, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P32", ST_ID, ST_M25P32, 4096, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P40", ST_ID, ST_M25P40, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P64", ST_ID, ST_M25P64, 8192, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P80", ST_ID, ST_M25P80, 1024, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M29F002B", ST_ID, ST_M29F002B, 256, 64 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"ST", "M29F002T/NT", ST_ID, ST_M29F002T, 256, 64 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"ST", "M29F040B", ST_ID, ST_M29F040B, 512, 64 * 1024, probe_29f040b, erase_29f040b, write_29f040b}, - {"ST", "M29F400BT", ST_ID, ST_M29F400BT, 512, 64 * 1024, probe_m29f400bt, erase_m29f400bt, write_coreboot_m29f400bt}, - {"ST", "M29W010B", ST_ID, ST_M29W010B, 128, 16 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"ST", "M29W040B", ST_ID, ST_M29W040B, 512, 64 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"ST", "M50FLW040A", ST_ID, ST_M50FLW040A, 512, 64 * 1024, probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x}, - {"ST", "M50FLW040B", ST_ID, ST_M50FLW040B, 512, 64 * 1024, probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x}, - {"ST", "M50FLW080A", ST_ID, ST_M50FLW080A, 1024, 64 * 1024, probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x}, - {"ST", "M50FLW080B", ST_ID, ST_M50FLW080B, 1024, 64 * 1024, probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x}, - {"ST", "M50FW016", ST_ID, ST_M50FW016, 2048, 64 * 1024, probe_82802ab, erase_82802ab, write_82802ab}, - {"ST", "M50FW040", ST_ID, ST_M50FW040, 512, 64 * 1024, probe_82802ab, erase_82802ab, write_82802ab}, - {"ST", "M50FW080", ST_ID, ST_M50FW080, 1024, 64 * 1024, probe_82802ab, erase_82802ab, write_82802ab}, - {"ST", "M50LPW116", ST_ID, ST_M50LPW116, 2048, 64 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"SyncMOS", "S29C31004T", SYNCMOS_ID, S29C31004T, 512, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"SyncMOS", "S29C51001T", SYNCMOS_ID, S29C51001T, 128, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"SyncMOS", "S29C51002T", SYNCMOS_ID, S29C51002T, 256, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"SyncMOS", "S29C51004T", SYNCMOS_ID, S29C51004T, 512, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"Winbond", "W25x10", WINBOND_NEX_ID, W_25X10, 128, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Winbond", "W25x20", WINBOND_NEX_ID, W_25X20, 256, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Winbond", "W25x40", WINBOND_NEX_ID, W_25X40, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Winbond", "W25x80", WINBOND_NEX_ID, W_25X80, 1024, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Winbond", "W29C011", WINBOND_ID, W_29C011, 128, 128, probe_jedec, erase_chip_jedec, write_jedec}, - {"Winbond", "W29C020C", WINBOND_ID, W_29C020C, 256, 128, probe_jedec, erase_chip_jedec, write_jedec}, - {"Winbond", "W29C040P", WINBOND_ID, W_29C040P, 512, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"Winbond", "W29EE011", WINBOND_ID, W_29C011, 128, 128, probe_w29ee011, erase_chip_jedec, write_jedec}, - {"Winbond", "W39V040A", WINBOND_ID, W_39V040A, 512, 64*1024, probe_jedec, erase_chip_jedec, write_39sf020}, - {"Winbond", "W39V040B", WINBOND_ID, W_39V040B, 512, 64*1024, probe_jedec, erase_chip_jedec, write_39sf020}, - {"Winbond", "W39V040FA", WINBOND_ID, W_39V040FA, 512, 64*1024, probe_jedec, erase_chip_jedec, write_39sf020}, - {"Winbond", "W39V080A", WINBOND_ID, W_39V080A, 1024, 64*1024, probe_jedec, erase_chip_jedec, write_39sf020}, - {"Winbond", "W49F002U", WINBOND_ID, W_49F002U, 256, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"Winbond", "W49V002A", WINBOND_ID, W_49V002A, 256, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"Winbond", "W49V002FA", WINBOND_ID, W_49V002FA, 256, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"Winbond", "W39V080FA", WINBOND_ID, W_39V080FA, 1024, 64*1024, probe_winbond_fwhub, erase_winbond_fwhub, write_winbond_fwhub}, - {"Winbond", "W39V080FA (dual mode)",WINBOND_ID, W_39V080FA_DM, 512, 64*1024, probe_winbond_fwhub, erase_winbond_fwhub, write_winbond_fwhub}, + {"SST", "SST49LF002A/B", SST_ID, SST_49LF002A, 256, 16 * 1024, TEST_UNTESTED, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, + {"SST", "SST49LF003A/B", SST_ID, SST_49LF003A, 384, 64 * 1024, TEST_UNTESTED, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, + {"SST", "SST49LF004A/B", SST_ID, SST_49LF004A, 512, 64 * 1024, TEST_UNTESTED, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, + {"SST", "SST49LF004C", SST_ID, SST_49LF004C, 512, 4 * 1024, TEST_UNTESTED, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, + {"SST", "SST49LF008A", SST_ID, SST_49LF008A, 1024, 64 * 1024, TEST_UNTESTED, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, + {"SST", "SST49LF008C", SST_ID, SST_49LF008C, 1024, 4 * 1024, TEST_UNTESTED, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, + {"SST", "SST49LF016C", SST_ID, SST_49LF016C, 2048, 4 * 1024, TEST_UNTESTED, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, + {"SST", "SST49LF020A", SST_ID, SST_49LF020A, 256, 16 * 1024, TEST_UNTESTED, probe_jedec, erase_49lf040, write_49lf040}, + {"SST", "SST49LF040", SST_ID, SST_49LF040, 512, 4096, TEST_UNTESTED, probe_jedec, erase_49lf040, write_49lf040}, + {"SST", "SST49LF040B", SST_ID, SST_49LF040B, 512, 64 * 1024, TEST_UNTESTED, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, + {"SST", "SST49LF080A", SST_ID, SST_49LF080A, 1024, 4096, TEST_UNTESTED, probe_jedec, erase_49lf040, write_49lf040}, + {"SST", "SST49LF160C", SST_ID, SST_49LF160C, 2048, 4 * 1024, TEST_UNTESTED, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, + {"ST", "M25P05-A", ST_ID, ST_M25P05A, 64, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P10-A", ST_ID, ST_M25P10A, 128, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P128", ST_ID, ST_M25P128, 16384, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P16", ST_ID, ST_M25P16, 2048, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P20", ST_ID, ST_M25P20, 256, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P32", ST_ID, ST_M25P32, 4096, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P40", ST_ID, ST_M25P40, 512, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P64", ST_ID, ST_M25P64, 8192, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P80", ST_ID, ST_M25P80, 1024, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M29F002B", ST_ID, ST_M29F002B, 256, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"ST", "M29F002T/NT", ST_ID, ST_M29F002T, 256, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"ST", "M29F040B", ST_ID, ST_M29F040B, 512, 64 * 1024, TEST_UNTESTED, probe_29f040b, erase_29f040b, write_29f040b}, + {"ST", "M29F400BT", ST_ID, ST_M29F400BT, 512, 64 * 1024, TEST_UNTESTED, probe_m29f400bt, erase_m29f400bt, write_coreboot_m29f400bt}, + {"ST", "M29W010B", ST_ID, ST_M29W010B, 128, 16 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"ST", "M29W040B", ST_ID, ST_M29W040B, 512, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"ST", "M50FLW040A", ST_ID, ST_M50FLW040A, 512, 64 * 1024, TEST_UNTESTED, probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x}, + {"ST", "M50FLW040B", ST_ID, ST_M50FLW040B, 512, 64 * 1024, TEST_UNTESTED, probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x}, + {"ST", "M50FLW080A", ST_ID, ST_M50FLW080A, 1024, 64 * 1024, TEST_UNTESTED, probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x}, + {"ST", "M50FLW080B", ST_ID, ST_M50FLW080B, 1024, 64 * 1024, TEST_UNTESTED, probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x}, + {"ST", "M50FW016", ST_ID, ST_M50FW016, 2048, 64 * 1024, TEST_UNTESTED, probe_82802ab, erase_82802ab, write_82802ab}, + {"ST", "M50FW040", ST_ID, ST_M50FW040, 512, 64 * 1024, TEST_UNTESTED, probe_82802ab, erase_82802ab, write_82802ab}, + {"ST", "M50FW080", ST_ID, ST_M50FW080, 1024, 64 * 1024, TEST_UNTESTED, probe_82802ab, erase_82802ab, write_82802ab}, + {"ST", "M50LPW116", ST_ID, ST_M50LPW116, 2048, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"SyncMOS", "S29C31004T", SYNCMOS_ID, S29C31004T, 512, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"SyncMOS", "S29C51001T", SYNCMOS_ID, S29C51001T, 128, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"SyncMOS", "S29C51002T", SYNCMOS_ID, S29C51002T, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"SyncMOS", "S29C51004T", SYNCMOS_ID, S29C51004T, 512, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"Winbond", "W25x10", WINBOND_NEX_ID, W_25X10, 128, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Winbond", "W25x20", WINBOND_NEX_ID, W_25X20, 256, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Winbond", "W25x40", WINBOND_NEX_ID, W_25X40, 512, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Winbond", "W25x80", WINBOND_NEX_ID, W_25X80, 1024, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Winbond", "W29C011", WINBOND_ID, W_29C011, 128, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Winbond", "W29C020C", WINBOND_ID, W_29C020C, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Winbond", "W29C040P", WINBOND_ID, W_29C040P, 512, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Winbond", "W29EE011", WINBOND_ID, W_29C011, 128, 128, TEST_UNTESTED, probe_w29ee011, erase_chip_jedec, write_jedec}, + {"Winbond", "W39V040A", WINBOND_ID, W_39V040A, 512, 64*1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"Winbond", "W39V040B", WINBOND_ID, W_39V040B, 512, 64*1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"Winbond", "W39V040FA", WINBOND_ID, W_39V040FA, 512, 64*1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"Winbond", "W39V080A", WINBOND_ID, W_39V080A, 1024, 64*1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"Winbond", "W49F002U", WINBOND_ID, W_49F002U, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"Winbond", "W49V002A", WINBOND_ID, W_49V002A, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"Winbond", "W49V002FA", WINBOND_ID, W_49V002FA, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"Winbond", "W39V080FA", WINBOND_ID, W_39V080FA, 1024, 64*1024, TEST_UNTESTED, probe_winbond_fwhub, erase_winbond_fwhub, write_winbond_fwhub}, + {"Winbond", "W39V080FA (dual mode)",WINBOND_ID, W_39V080FA_DM, 512, 64*1024, TEST_UNTESTED, probe_winbond_fwhub, erase_winbond_fwhub, write_winbond_fwhub}, - {"EON", "unknown SPI chip", EON_ID_NOPREFIX,GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, - {"Macronix", "unknown SPI chip", MX_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, - {"PMC", "unknown SPI chip", PMC_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, - {"SST", "unknown SPI chip", SST_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, - {"ST", "unknown SPI chip", ST_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, + {"EON", "unknown SPI chip", EON_ID_NOPREFIX,GENERIC_DEVICE_ID, 0, 0, TEST_UNTESTED, probe_spi, NULL, NULL}, + {"Macronix", "unknown SPI chip", MX_ID, GENERIC_DEVICE_ID, 0, 0, TEST_UNTESTED, probe_spi, NULL, NULL}, + {"PMC", "unknown SPI chip", PMC_ID, GENERIC_DEVICE_ID, 0, 0, TEST_UNTESTED, probe_spi, NULL, NULL}, + {"SST", "unknown SPI chip", SST_ID, GENERIC_DEVICE_ID, 0, 0, TEST_UNTESTED, probe_spi, NULL, NULL}, + {"ST", "unknown SPI chip", ST_ID, GENERIC_DEVICE_ID, 0, 0, TEST_UNTESTED, probe_spi, NULL, NULL}, {NULL,} }; Index: flashrom.2.chiptested/flashrom.c =================================================================== --- flashrom.2.chiptested/flashrom.c (revision 3276) +++ flashrom.2.chiptested/flashrom.c (working copy) @@ -412,6 +412,36 @@ } printf("Flash part is %s (%d KB).\n", flash->name, flash->total_size); + if (TEST_OK_MASK != (flash->tested & TEST_OK_MASK)) { + printf("--\n"); + if (flash->tested & TEST_BAD_MASK) { + printf("This flash part has status NOT WORKING for operations:"); + if (flash->tested & TEST_BAD_PROBE) + printf(" PROBE"); + if (flash->tested & TEST_BAD_READ) + printf(" READ"); + if (flash->tested & TEST_BAD_ERASE) + printf(" ERASE"); + if (flash->tested & TEST_BAD_WRITE) + printf(" WRITE"); + printf("\n"); + } else { + printf("This flash part has status UNTESTED for operations:"); + if (!(flash->tested & TEST_OK_PROBE)) + printf(" PROBE"); + if (!(flash->tested & TEST_OK_READ)) + printf(" READ"); + if (!(flash->tested & TEST_OK_ERASE)) + printf(" ERASE"); + if (!(flash->tested & TEST_OK_WRITE)) + printf(" WRITE"); + printf("\n"); + } + printf("Please email a report to flashrom at coreboot.org if any of the above operations\n"); + printf("work correctly for you with this flash part. Please also mention which chipset\n"); + printf("the program found. Thank you for your help!\n"); + printf("--\n"); + } if (!(read_it | write_it | verify_it | erase_it)) { printf("No operations were specified.\n"); From peter at stuge.se Fri May 2 20:12:59 2008 From: peter at stuge.se (Peter Stuge) Date: Fri, 2 May 2008 20:12:59 +0200 Subject: [coreboot] flashrom: Move options -s -e to -S -E and -E to -e. Message-ID: <20080502181259.15991.qmail@stuge.se> NOTE! This will break all scripts that erase flash chips automatically. But better now than post 1.0. //Peter -------------- next part -------------- flashrom: Change start/end -s and -e to -S and -E, and change erase -E to -e. Signed-off-by: Peter Stuge Index: flashrom.5.swapopts/flashrom.8 =================================================================== --- flashrom.5.swapopts/flashrom.8 (revision 3276) +++ flashrom.5.swapopts/flashrom.8 (working copy) @@ -2,7 +2,7 @@ .SH NAME flashrom \- a universal BIOS/ROM/flash programming utility .SH SYNOPSIS -.B flashrom \fR[\fB\-rwvEVfLhR\fR] [\fB\-c\fR chipname] [\fB\-s\fR exclude_start] [\fB\-e\fR exclude_end] +.B flashrom \fR[\fB\-rwveVfLhR\fR] [\fB\-c\fR chipname] [\fB\-S\fR exclude_start] [\fB\-E\fR exclude_end] [\fB-m\fR vendor:part] [\fB-l\fR file.layout] [\fB-i\fR image_name] [file] .SH DESCRIPTION .B flashrom @@ -25,7 +25,7 @@ .B "\-v, \-\-verify" Verify the flash ROM contents against the given file. .TP -.B "\-E, \-\-erase" +.B "\-e, \-\-erase" Erase the flash ROM device. .TP .B "\-V, \-\-verbose" @@ -34,10 +34,10 @@ .B "\-c, \-\-chip" Probe only for specified flash ROM chip. .TP -.B "\-s, \-\-estart" +.B "\-S, \-\-estart" Exclude start position (obsolete). .TP -.B "\-e, \-\-eend" +.B "\-E, \-\-eend" Exclude end postion (obsolete). .TP .B "\-m, \-\-mainboard" <[vendor:]part> Index: flashrom.5.swapopts/flashrom.c =================================================================== --- flashrom.5.swapopts/flashrom.c (revision 3276) +++ flashrom.5.swapopts/flashrom.c (working copy) @@ -213,17 +213,17 @@ void usage(const char *name) { - printf("usage: %s [-rwvEVfLhR] [-c chipname] [-s exclude_start]\n", name); - printf(" [-e exclude_end] [-m [vendor:]part] [-l file.layout] [-i imagename] [file]\n"); + printf("usage: %s [-rwveVfLhR] [-c chipname] [-S exclude_start]\n", name); + printf(" [-E exclude_end] [-m [vendor:]part] [-l file.layout] [-i imagename] [file]\n"); printf (" -r | --read: read flash and save into file\n" " -w | --write: write file into flash\n" " -v | --verify: verify flash against file\n" - " -E | --erase: erase flash device\n" + " -e | --erase: erase flash device\n" " -V | --verbose: more verbose output\n" " -c | --chip : probe only for specified flash chip\n" - " -s | --estart : exclude start position\n" - " -e | --eend : exclude end postion\n" + " -S | --estart : exclude start position\n" + " -E | --eend : exclude end postion\n" " -m | --mainboard <[vendor:]part>: override mainboard settings\n" " -f | --force: force write without checking image\n" " -l | --layout : read rom layout from file\n" @@ -255,11 +255,11 @@ static struct option long_options[] = { {"read", 0, 0, 'r'}, {"write", 0, 0, 'w'}, - {"erase", 0, 0, 'E'}, + {"erase", 0, 0, 'e'}, {"verify", 0, 0, 'v'}, {"chip", 1, 0, 'c'}, - {"estart", 1, 0, 's'}, - {"eend", 1, 0, 'e'}, + {"estart", 1, 0, 'S'}, + {"eend", 1, 0, 'E'}, {"mainboard", 1, 0, 'm'}, {"verbose", 0, 0, 'V'}, {"force", 0, 0, 'f'}, @@ -285,7 +285,7 @@ } setbuf(stdout, NULL); - while ((opt = getopt_long(argc, argv, "rRwvVEfc:s:e:m:l:i:Lh", + while ((opt = getopt_long(argc, argv, "rRwvVefc:S:E:m:l:i:Lh", long_options, &option_index)) != EOF) { switch (opt) { case 'r': @@ -303,14 +303,14 @@ case 'V': verbose = 1; break; - case 'E': + case 'e': erase_it = 1; break; - case 's': + case 'S': tempstr = strdup(optarg); sscanf(tempstr, "%x", &exclude_start_position); break; - case 'e': + case 'E': tempstr = strdup(optarg); sscanf(tempstr, "%x", &exclude_end_position); break; Index: flashrom.5.swapopts/README =================================================================== --- flashrom.5.swapopts/README (revision 3276) +++ flashrom.5.swapopts/README (working copy) @@ -22,17 +22,17 @@ Usage ----- - $ flashrom [-rwvEVfh] [-c chipname] [-s exclude_start] [-e exclude_end] + $ flashrom [-rwveVfh] [-c chipname] [-S exclude_start] [-E exclude_end] [-m [vendor:]part] [-l file.layout] [-i imagename] [file] -r | --read: read flash and save into file -w | --write: write file into flash (default when file is specified) -v | --verify: verify flash against file - -E | --erase: erase flash device + -e | --erase: erase flash device -V | --verbose: more verbose output -c | --chip : probe only for specified flash chip - -s | --estart : exclude start position - -e | --eend : exclude end postion + -S | --estart : exclude start position + -E | --eend : exclude end postion -m | --mainboard <[vendor:]part>: override mainboard settings -f | --force: force write without checking image -l | --layout : read rom layout from file @@ -90,7 +90,7 @@ Currently overlapping sections are not supported. -ROM layouts should replace the -s and -e option since they are more +ROM layouts should replace the -S and -E option since they are more flexible and they should lead to a ROM update file format with the ROM layout and the ROM image in one file (cpio, zip or something?). From r.marek at assembler.cz Fri May 2 22:15:17 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Fri, 02 May 2008 22:15:17 +0200 Subject: [coreboot] [PATCH] MS7135 fixes and updates In-Reply-To: <20080501203014.GL2542@tazenda.kollasch.net> References: <20080430152113.GG2542@tazenda.kollasch.net> <20080501002225.GD9643@greenwood> <20080501010901.GJ2542@tazenda.kollasch.net> <48199D68.7090303@assembler.cz> <20080501203014.GL2542@tazenda.kollasch.net> Message-ID: <481B7655.9060601@assembler.cz> Jonathan A. Kollasch napsal(a): > On Thu, May 01, 2008 at 12:37:28PM +0200, Rudolf Marek wrote: >> Just a side note, if the superIO is similar to W83627EHG then you could use >> virtual LDNs for the different functionality in same LDN which are sharing >> same enable byte. (I did it for the W83627EHG). >> >> http://www.coreboot.org/SuperIO_port_guide > > Huh, but I don't think this is the case here. In logical device 7 and 9 yes. If you want to enable at least something, you need to use virtual LDNs. >> Maybe this page is not linked from anywhere? > > That's what it looks like: > http://www.coreboot.org/Special:Whatlinkshere/SuperIO_port_guide Hmm I added it at least to devel info. Rudolf From rms at gnu.org Fri May 2 23:12:21 2008 From: rms at gnu.org (Richard M Stallman) Date: Fri, 02 May 2008 17:12:21 -0400 Subject: [coreboot] Interested vendors [was: [Fwd: Re: Contact Intel]] In-Reply-To: <20080501124255.17921.qmail@stuge.se> (message from Peter Stuge on Thu, 1 May 2008 14:42:55 +0200) References: <4818A556.6060900@gnu.org> <20080501124255.17921.qmail@stuge.se> Message-ID: Does coreboot have a web page with this list of vendors and how they cooperate? Or even a partial list? That could be used to put pressure on Intel and others when they claim that everyone acts like them. From rms at gnu.org Fri May 2 23:12:29 2008 From: rms at gnu.org (Richard M Stallman) Date: Fri, 02 May 2008 17:12:29 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <13426df10805010812kc25ad20w78560fe0e43a762a@mail.gmail.com> (rminnich@gmail.com) References: <4818A556.6060900@gnu.org> <13426df10805010812kc25ad20w78560fe0e43a762a@mail.gmail.com> Message-ID: What I find amusing about their "third party BIOS" comment is that *every* BIOS is a third party BIOS, and many if not all of them are based on reverse engineering done years ago. The least of the worries was chipset specs; the chipset specs were mostly open. Would you like me to refer a friendly journalist your way? From rms at gnu.org Fri May 2 23:12:37 2008 From: rms at gnu.org (Richard M Stallman) Date: Fri, 02 May 2008 17:12:37 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: (lemenkov@gmail.com) References: <4818A556.6060900@gnu.org> <13426df10805010812kc25ad20w78560fe0e43a762a@mail.gmail.com> <2bf69daa60a7558afc8e488c223c83a8@imap.1and1.com> <13426df10805010902o73c8265fo4a25221f389c8719@mail.gmail.com> Message-ID: Can't believe. Intel spends a lot of efforts to promote their own EFI - why they will to help their competitors? The technical difference between traditional BIOS and EFI is not crucial for the ethics. What matters ethically is whether the program, as used, is free. If an EFI implementation works with 100% free software, except for subroutines in rom on the chips that they initialize, it would be just as good as any other implementation of a BIOS. From rms at gnu.org Fri May 2 23:12:38 2008 From: rms at gnu.org (Richard M Stallman) Date: Fri, 02 May 2008 17:12:38 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <4819EC56.4070503@coresystems.de> (message from Stefan Reinauer on Thu, 01 May 2008 18:14:14 +0200) References: <4818A556.6060900@gnu.org> <13426df10805010812kc25ad20w78560fe0e43a762a@mail.gmail.com> <2bf69daa60a7558afc8e488c223c83a8@imap.1and1.com> <13426df10805010902o73c8265fo4a25221f389c8719@mail.gmail.com> <4819EC56.4070503@coresystems.de> Message-ID: Maybe for the same reasons IBM and SUN are doing Linux, despite the fact that they had their own OSes. What they are doing is the GNU/Linux system, not Linux by itself. See http://www.gnu.org/gnu/gnu-linux-faq.html for more explanation. From rms at gnu.org Fri May 2 23:13:12 2008 From: rms at gnu.org (Richard M Stallman) Date: Fri, 02 May 2008 17:13:12 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <481A2C12.6020605@gmx.net> (message from Carl-Daniel Hailfinger on Thu, 01 May 2008 22:46:10 +0200) References: <4818A556.6060900@gnu.org> <481A2C12.6020605@gmx.net> Message-ID: > If the "proprietary low-level chipset initialization code" is in ROM > on the chips that it initializes, then it is tolerable. (It might as > well be circuits on that chip.) Otherwise, it is insufficient unless > made complete. > None of the current mainstream x86 board manufacturers uses real ROMs anymore. We may be partly miscommunicating, talking about different questions. I'm talking about where we should draw the line of what's acceptable. What is done in any particular product is a different question. Both questions are important, but they are different. If memory is physically writable, but is never updated once users get the product, that is more or less equivalent to ROM in my view. Thus, an EEPROM in a chip (or in a device) that contains the code to initialize the chip (or device) is tolerable if people treat it as a ROM. ISTR that it was necessary for free BIOSes to run some initialization code for the video card which is stored on the video card. Is that correct? Is this still necessary? If so, it is an example of what I am talking about. From stepan at coresystems.de Fri May 2 23:24:42 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 02 May 2008 23:24:42 +0200 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: References: <4818A556.6060900@gnu.org> <13426df10805010812kc25ad20w78560fe0e43a762a@mail.gmail.com> <2bf69daa60a7558afc8e488c223c83a8@imap.1and1.com> <13426df10805010902o73c8265fo4a25221f389c8719@mail.gmail.com> <4819EC56.4070503@coresystems.de> Message-ID: <481B869A.5060507@coresystems.de> Richard M Stallman wrote: > Maybe for the same reasons IBM and SUN are doing Linux, despite the fact > that they had their own OSes. > > What they are doing is the GNU/Linux system, not Linux by itself. > > See http://www.gnu.org/gnu/gnu-linux-faq.html for more explanation. > > Thanks for lecturing me, Richard. I think your opinion on this is widely known. I hope you got the point anyways. From c-d.hailfinger.devel.2006 at gmx.net Sat May 3 00:18:12 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 03 May 2008 00:18:12 +0200 Subject: [coreboot] flashrom: Move options -s -e to -S -E and -E to -e. In-Reply-To: <20080502181259.15991.qmail@stuge.se> References: <20080502181259.15991.qmail@stuge.se> Message-ID: <481B9324.90509@gmx.net> On 02.05.2008 20:12, Peter Stuge wrote: > NOTE! This will break all scripts that erase flash chips > automatically. > > But better now than post 1.0. > > > //Peter > > flashrom: Change start/end -s and -e to -S and -E, and change erase -E to -e. > > Signed-off-by: Peter Stuge > Can we please change verify to -V and verbose to -v? That's the mistake I still make after hundreds of invocations of flashrom. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Sat May 3 03:40:17 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 03 May 2008 03:40:17 +0200 Subject: [coreboot] flashrom: Add tested bitmap to flashchips table. In-Reply-To: <20080502175030.5882.qmail@stuge.se> References: <20080502162945.12596.qmail@stuge.se> <481B429A.5060201@gmx.net> <0c12c15a72c9c97bbffb0245b70ee200@imap.1and1.com> <20080502162945.12596.qmail@stuge.se> <481B429A.5060201@gmx.net> <20080502175030.5882.qmail@stuge.se> Message-ID: <481BC281.1060009@gmx.net> On 02.05.2008 19:50, Peter Stuge wrote: > On Fri, May 02, 2008 at 06:34:34PM +0200, Carl-Daniel Hailfinger wrote: > >> Two minor comments: >> - People should have a separate address to turn to for any flashrom >> success reports. Subscribing to a list just for that purpose is >> user-hostile. >> > > Changed to flashrom at coreboot.org now. How we handle that adress I > don't know. > Thanks. As long as Stefan can create a mailbox with that name, we don't have to decide immediately how to handle this. >> - We need separate test status for probe/read/erase/verify. >> > > Good idea. I've changed the patch. > Great. >> If the issues above are addressed, the patch is >> Acked-by: Carl-Daniel Hailfinger >> > > Thanks! I'll hold off committing the attached patch for one more > round of comments though. > > > On Fri, May 02, 2008 at 01:23:52PM -0400, Joe wrote: > >> Why not just put a link in the manpage pointing to >> http://www.coreboot.org/Flashrom#Supported_devices >> to show which chips have been tested? >> > > A good idea, but unfortunately the wiki does not know what version of > the program the user is running. If the user has an old version, bugs > may have been fixed since the release to make more chips work, which > is what the wiki would say, but they will still not work in the > user's version. :\ > Indeed. > flashrom: Add a tested bitmap field to the flash chip table. > > Two bits indicate OK and BAD for each operation PROBE READ ERASE WRITE. > All 8 bits are in use now. No bits set means nothing has been tested. > For chips with at least one operation that is not tested or not working, the > user is asked to email a report to a special email adress so that the table > can be updated. > > All chips are TEST_UNTESTED for now. > > Signed-off-by: Peter Stuge > > > Index: flashrom.2.chiptested/flash.h > =================================================================== > --- flashrom.2.chiptested/flash.h (revision 3276) > +++ flashrom.2.chiptested/flash.h (working copy) > @@ -45,6 +45,11 @@ > int total_size; > int page_size; > > + /* Indicate if flashrom has been tested with this flash chip and if > + * everything worked correctly. > + */ > + uint8_t tested; > Due to alignment of the subsequent struct member, we'll waste 24 bits here. We might as well make this a 32bit variable. It's not needed right now, though. > + > int (*probe) (struct flashchip *flash); > int (*erase) (struct flashchip *flash); > int (*write) (struct flashchip *flash, uint8_t *buf); > @@ -55,6 +60,20 @@ > volatile uint8_t *virtual_registers; > }; > > +#define TEST_UNTESTED 0 > + > +#define TEST_OK_PROBE (1<<0) > +#define TEST_OK_READ (1<<1) > +#define TEST_OK_ERASE (1<<2) > +#define TEST_OK_WRITE (1<<3) > +#define TEST_OK_MASK 0x0f > + > +#define TEST_BAD_PROBE (1<<4) > +#define TEST_BAD_READ (1<<5) > +#define TEST_BAD_ERASE (1<<6) > +#define TEST_BAD_WRITE (1<<7) > +#define TEST_BAD_MASK 0xf0 > + > extern struct flashchip flashchips[]; > > /* > Index: flashrom.2.chiptested/flashrom.c > =================================================================== > --- flashrom.2.chiptested/flashrom.c (revision 3276) > +++ flashrom.2.chiptested/flashrom.c (working copy) > @@ -412,6 +412,36 @@ > } > > printf("Flash part is %s (%d KB).\n", flash->name, flash->total_size); > + if (TEST_OK_MASK != (flash->tested & TEST_OK_MASK)) { > + printf("--\n"); > The printf above may be dangerous if it is interpreted as a signature separator by some e-mail program... > + if (flash->tested & TEST_BAD_MASK) { > + printf("This flash part has status NOT WORKING for operations:"); > + if (flash->tested & TEST_BAD_PROBE) > + printf(" PROBE"); > + if (flash->tested & TEST_BAD_READ) > + printf(" READ"); > + if (flash->tested & TEST_BAD_ERASE) > + printf(" ERASE"); > + if (flash->tested & TEST_BAD_WRITE) > + printf(" WRITE"); > + printf("\n"); > + } else { > + printf("This flash part has status UNTESTED for operations:"); > + if (!(flash->tested & TEST_OK_PROBE)) > + printf(" PROBE"); > + if (!(flash->tested & TEST_OK_READ)) > + printf(" READ"); > + if (!(flash->tested & TEST_OK_ERASE)) > + printf(" ERASE"); > + if (!(flash->tested & TEST_OK_WRITE)) > + printf(" WRITE"); > + printf("\n"); > + } > + printf("Please email a report to flashrom at coreboot.org if any of the above operations\n"); > + printf("work correctly for you with this flash part. Please also mention which chipset\n"); > + printf("the program found. Thank you for your help!\n"); > Maybe add: "In doubt, mail the whole output of flashrom." That also begs the question whether we want to echo the flashrom parameters by default. > + printf("--\n"); > + } > > if (!(read_it | write_it | verify_it | erase_it)) { > printf("No operations were specified.\n"); > > This is an almost ackable form. As long as you answer the questions above (you don't have to follow the suggestions), this is Acked-by: Carl-Daniel Hailfinger Regards, Carl-Daniel From mart.raudsepp at artecdesign.ee Sat May 3 03:58:05 2008 From: mart.raudsepp at artecdesign.ee (Mart Raudsepp) Date: Sat, 03 May 2008 04:58:05 +0300 Subject: [coreboot] [PATCH] artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines Message-ID: <1209779885.13448.16.camel@martr-gentoo.artec> ?artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines This makes the network adapter work fully, and reduces problems on high traffic (e.g kernel oopses on fsck run over USB 2.0 HDD) Many thanks for Peter Stuge for a lot of IRQ related help. Signed-off-by: Mart Raudsepp --- mainboard/artecgroup/dbe62/irq_tables.h | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/mainboard/artecgroup/dbe62/irq_tables.h b/mainboard/artecgroup/dbe62/irq_tables.h index d8d64a6..0d1a4bb 100644 --- a/mainboard/artecgroup/dbe62/irq_tables.h +++ b/mainboard/artecgroup/dbe62/irq_tables.h @@ -23,10 +23,10 @@ #define IRQ_SLOT_COUNT 3 /* Platform IRQs */ -#define PIRQA 10 -#define PIRQB 11 -#define PIRQC 10 -#define PIRQD 11 +#define PIRQA 11 +#define PIRQB 10 +#define PIRQC 9 +#define PIRQD 5 /* Map */ #define M_PIRQA (1 << PIRQA) /* Bitmap of supported IRQs */ @@ -60,6 +60,6 @@ const struct irq_routing_table intel_irq_routing_table = { /* chipset */ {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0}, /* ethernet */ - {0x00, (0x0D << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, + {0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, } }; -- 1.5.5.1 From peter at stuge.se Sat May 3 03:59:34 2008 From: peter at stuge.se (Peter Stuge) Date: Sat, 3 May 2008 03:59:34 +0200 Subject: [coreboot] [PATCH] artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines In-Reply-To: <1209779885.13448.16.camel@martr-gentoo.artec> References: <1209779885.13448.16.camel@martr-gentoo.artec> Message-ID: <20080503015934.22789.qmail@stuge.se> On Sat, May 03, 2008 at 04:58:05AM +0300, Mart Raudsepp wrote: > ???artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines > > This makes the network adapter work fully, and reduces problems on high traffic (e.g kernel oopses on fsck run over USB 2.0 HDD) > Many thanks for Peter Stuge for a lot of IRQ related help. > > Signed-off-by: Mart Raudsepp Acked-by: Peter Stuge > --- > mainboard/artecgroup/dbe62/irq_tables.h | 10 +++++----- > 1 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/mainboard/artecgroup/dbe62/irq_tables.h b/mainboard/artecgroup/dbe62/irq_tables.h > index d8d64a6..0d1a4bb 100644 > --- a/mainboard/artecgroup/dbe62/irq_tables.h > +++ b/mainboard/artecgroup/dbe62/irq_tables.h > @@ -23,10 +23,10 @@ > #define IRQ_SLOT_COUNT 3 > > /* Platform IRQs */ > -#define PIRQA 10 > -#define PIRQB 11 > -#define PIRQC 10 > -#define PIRQD 11 > +#define PIRQA 11 > +#define PIRQB 10 > +#define PIRQC 9 > +#define PIRQD 5 > > /* Map */ > #define M_PIRQA (1 << PIRQA) /* Bitmap of supported IRQs */ > @@ -60,6 +60,6 @@ const struct irq_routing_table intel_irq_routing_table = { > /* chipset */ > {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0}, > /* ethernet */ > - {0x00, (0x0D << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, > + {0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, > } > }; From svn at coreboot.org Sat May 3 04:03:34 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Sat, 3 May 2008 04:03:34 +0200 Subject: [coreboot] r673 - coreboot-v3/mainboard/artecgroup/dbe62 Message-ID: Author: mraudsepp Date: 2008-05-03 04:03:33 +0200 (Sat, 03 May 2008) New Revision: 673 Modified: coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.h Log: artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines This makes the network adapter work fully, and reduces problems on high traffic (e.g kernel oopses on fsck run over USB 2.0 HDD) Many thanks for Peter Stuge for a lot of IRQ related help. Signed-off-by: Mart Raudsepp Acked-by: Peter Stuge Modified: coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.h =================================================================== --- coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.h 2008-04-30 04:14:52 UTC (rev 672) +++ coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.h 2008-05-03 02:03:33 UTC (rev 673) @@ -23,10 +23,10 @@ #define IRQ_SLOT_COUNT 3 /* Platform IRQs */ -#define PIRQA 10 -#define PIRQB 11 -#define PIRQC 10 -#define PIRQD 11 +#define PIRQA 11 +#define PIRQB 10 +#define PIRQC 9 +#define PIRQD 5 /* Map */ #define M_PIRQA (1 << PIRQA) /* Bitmap of supported IRQs */ @@ -60,6 +60,6 @@ /* chipset */ {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0}, /* ethernet */ - {0x00, (0x0D << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, + {0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, } }; From mart.raudsepp at artecdesign.ee Sat May 3 04:31:58 2008 From: mart.raudsepp at artecdesign.ee (Mart Raudsepp) Date: Sat, 03 May 2008 05:31:58 +0300 Subject: [coreboot] DBE62 status Message-ID: <1209781918.13448.41.camel@martr-gentoo.artec> Hello, Now that ethernet works for me and I can ssh in (having no VGA BIOS and no visible access otherwise other than serial console which I didn't bother to get to work on my full USB HDD system for logins), here are some of the remaining issues with DBE62 that I have noticed: ?* lxfb and Xorg does not work, probably no video memory setup: lxfb 0000:00:01.1: failed to map frame buffer or controller registers lxfb: probe of 0000:00:01.1 failed with error -12 * The two USB ports on the right side don't power up * NAND is set up on the wrong chip select (should be CS1, currently hardcoded to CS0 in southbridge/cs5536/cs5536.c) * PLL initialization should trust bootstraps For the PLL initialization I intend to send a patch soon after some testing and registry comparisons that sets MANUALCONF in raminit.c back to 0 NAND setup needs some refactoring and allowing selection of the chip select(s) in dts. There I am not sure if we should bother supporting multiple NAND flashes or not. Theoretically I believe it to be possible, but I don't know of any such boards and just know that linux 553x_nand mtd driver seems to be capable of handling that scenario. In the case of supporting only one, there could just be an additional variable in dts that tells which chip select is used for NAND (how it is wired up on the board). Otherwise I guess the new dts array support would come into play? I have no ideas about the USB ports at the moment. Will try to find time to compare dmesg logs, registers and such things, maybe also some setup problems. Same about video memory, but that seems easy enough that I might actually succeed. There were some discussions about merging the DBE61 and DBE62 code, and that might be a good course of action going forward. The differences between these boards as I remember are a) different ethernet adapter - not much concerning firmware, might have a slightly different IRQ routing, but perhaps not, no working raminit for DBE61 doesn't allow to easily find out. b) different GeodeLink speed (PCI clock) - DBE61 has 33MHz, DBE62 66MHz c) different memory chips - need different fake SPDs d) LPC vs FWH boot ROM interface e) dedicated serial port pins brought out (at least CTS, RTS, RX, TX) - another UART, allowing always enabled serial console output without sacrificing DDC Given that, does it seem like a good or bad idea to merge them? There isn't all that much code in mainboard folders, but DBE61 code at the moment could probably use a mostly full code pull from DBE62 code, so a good time to decide on that, it seems. Regards, Mart Raudsepp Artec Design LLC From mart.raudsepp at artecdesign.ee Sat May 3 05:40:51 2008 From: mart.raudsepp at artecdesign.ee (Mart Raudsepp) Date: Sat, 03 May 2008 06:40:51 +0300 Subject: [coreboot] DBE62 status In-Reply-To: <1209781918.13448.41.camel@martr-gentoo.artec> References: <1209781918.13448.41.camel@martr-gentoo.artec> Message-ID: <1209786051.13448.56.camel@martr-gentoo.artec> ?hel kenal p?eval, L, 2008-05-03 kell 05:31, kirjutas Mart Raudsepp: > ?* lxfb and Xorg does not work, probably no video memory setup: > lxfb 0000:00:01.1: failed to map frame buffer or controller registers > lxfb: probe of 0000:00:01.1 failed with error -12 Attached is a trivial patch to set up the video memory, but I still get no picture. Probably other setup problems causing trouble still. With video memory set up I get problems starting with no visual effect on loading lxfb module to a nice kernel oops loop on Xorg start. Patch itself is probably good, I'm just not sure where the 8MB comes from and I don't know yet what this reserved memory is used for (just framebuffer, or other functions too, etc). This also reminds me that I didn't notice a way in the current menuconfig to disable the muxed first UART to allow VGA DDC to work. That I believe should be configurable from Kconfig, but I might have overlooked something. Got reminded because i've had trouble without DDC on vm86 based xorg-server with geode driver before. One difference with our working v2 code regarding video is that the video IRQ isn't shared, as they are given out more separately via Config/Options.lb. Not sure if that could matter, but that's one thing. dmesg additions on "modprobe lxfb" after video memory patch: PCI: Guessed IRQ 11 for device 0000:00:01.1 PCI: Sharing IRQ 11 with 0000:00:01.2 PCI: Sharing IRQ 11 with 0000:00:0f.1 lxfb 0000:00:01.1: 8192 KB of video memory at 0xfd000000 fb0: Geode LX frame buffer device Start of kernel spew I found from my serial console quite some time later on after starting X and sitting in a freeze (there are some 50 pages more, probably got into a loop on pdflush problems - not pasted here - more textual content in the end): Oops: 0000 [#1] PREEMPT Modules linked in: lxfb fb cfbcopyarea cfbimgblt cfbfillrect geode_aes crypto_blkcipher crypto_algapi via_velocity Pid: 3162, comm: X Not tainted (2.6.25-gentoo-r1 #4) EIP: 0060:[] EFLAGS: 00010282 CPU: 0 EIP is at do_mpage_readpage+0x15/0x3e1 EAX: 00000000 EBX: 0000013c ECX: 00000001 EDX: c10252c0 ESI: 00000000 EDI: c10252c0 EBP: ce609d6c ESP: ce609d10 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 Process X (pid: 3162, ti=ce608000 task=cf02a070 task.ti=ce608000) Stack: ce609d4c 00000000 ce609d30 00000001 c10252c0 00000000 00000001 00000000 ce609d38 c025e210 ce609d4c c025fbcd c03c7a38 cecc1534 cec0b430 ce609d64 c028b8b4 00000000 cecc1534 cecc1534 0000013c 00000000 c10252c0 ce609dc0 Call Trace: [] ? d_rehash+0x16/0x42 [] ? d_splice_alias+0xd0/0xd9 [] ? ext3_lookup+0x7b/0xa2 [] ? mpage_readpage+0x34/0x48 [] ? ext3_get_block+0x0/0xb8 [] ? path_put+0x0/0x23 [] ? __link_path_walk+0xc68/0xc7f [] ? find_lock_page+0x26/0x9c [] ? ext3_readpage+0xf/0x11 [] ? filemap_fault+0x310/0x351 [] ? path_walk+0x8d/0x96 [] ? __do_fault+0x4f/0x304 [] ? handle_mm_fault+0x235/0x4f2 [] ? do_page_fault+0x238/0x5e2 [] ? unix_stream_connect+0x362/0x38e [] ? sys_connect+0x54/0x71 [] ? sock_map_fd+0x45/0x4f [] ? sys_socketcall+0x6f/0x168 [] ? do_page_fault+0x0/0x5e2 [] ? error_code+0x6a/0x70 ======================= Code: 58 85 d2 74 0a b8 01 00 00 00 e8 da f9 ff ff 89 d8 8b 5d fc c9 c3 55 89 e5 57 56 53 83 ec 50 89 45 b8 89 55 b4 89 4d b0 8b 42 10 <8b> 0 EIP: [] do_mpage_readpage+0x15/0x3e1 SS:ESP 0068:ce609d10 ---[ end trace c55b15462a99792c ]--- Eeek! page_mapcount(page) went negative! (-1807219968) page pfn = 1280 page->flags = 98393bc4 page->count = 2000000 page->mapping = 00000000 vma->vm_ops = generic_file_vm_ops+0x0/0x18 vma->vm_ops->nopage = 0x0 vma->vm_ops->fault = filemap_fault+0x0/0x351 vma->vm_file->f_op->mmap = generic_file_mmap+0x0/0x3f ------------[ cut here ]------------ kernel BUG at mm/rmap.c:669! invalid opcode: 0000 [#2] PREEMPT Feels very much like more setup work is necessary. I think getting the other USB ports to give power (e.g light up an optical mouse) might be a good start. Regards, Mart Raudsepp -------------- next part -------------- A non-text attachment was scrubbed... Name: dbe62_video_mem.patch Type: text/x-patch Size: 649 bytes Desc: not available URL: From peter at stuge.se Sat May 3 05:47:37 2008 From: peter at stuge.se (Peter Stuge) Date: Sat, 3 May 2008 05:47:37 +0200 Subject: [coreboot] DBE62 status In-Reply-To: <1209786051.13448.56.camel@martr-gentoo.artec> References: <1209781918.13448.41.camel@martr-gentoo.artec> <1209786051.13448.56.camel@martr-gentoo.artec> Message-ID: <20080503034737.16401.qmail@stuge.se> On Sat, May 03, 2008 at 06:40:51AM +0300, Mart Raudsepp wrote: > commit 65e61701b50e7af00ad0771bd2c1f2d08a6bb3a6 > Author: Mart Raudsepp > Date: Sat May 3 06:21:47 2008 +0300 > > artecgroup/dbe62: Set up video memory > > Signed-off-by: Mart Raudsepp Acked-by: Peter Stuge > diff --git a/mainboard/artecgroup/dbe62/dts b/mainboard/artecgroup/dbe62/dts > index 9e58d6c..0425482 100644 > --- a/mainboard/artecgroup/dbe62/dts > +++ b/mainboard/artecgroup/dbe62/dts > @@ -27,6 +27,8 @@ > }; > domain at 0 { > /config/("northbridge/amd/geodelx/domain"); > + /* Video RAM has to be in 2MB chunks. */ > + geode_video_mb = "8"; > pci at 1,0 { > /config/("northbridge/amd/geodelx/pci"); > }; From svn at coreboot.org Sat May 3 05:49:31 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Sat, 3 May 2008 05:49:31 +0200 Subject: [coreboot] r674 - coreboot-v3/mainboard/artecgroup/dbe62 Message-ID: Author: mraudsepp Date: 2008-05-03 05:49:30 +0200 (Sat, 03 May 2008) New Revision: 674 Modified: coreboot-v3/mainboard/artecgroup/dbe62/dts Log: artecgroup/dbe62: Set up video memory Signed-off-by: Mart Raudsepp Acked-by: Peter Stuge Modified: coreboot-v3/mainboard/artecgroup/dbe62/dts =================================================================== --- coreboot-v3/mainboard/artecgroup/dbe62/dts 2008-05-03 02:03:33 UTC (rev 673) +++ coreboot-v3/mainboard/artecgroup/dbe62/dts 2008-05-03 03:49:30 UTC (rev 674) @@ -27,6 +27,8 @@ }; domain at 0 { /config/("northbridge/amd/geodelx/domain"); + /* Video RAM has to be in 2MB chunks. */ + geode_video_mb = "8"; pci at 1,0 { /config/("northbridge/amd/geodelx/pci"); }; From rminnich at gmail.com Sat May 3 06:14:42 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 2 May 2008 21:14:42 -0700 Subject: [coreboot] DBE62 status In-Reply-To: <20080503034737.16401.qmail@stuge.se> References: <1209781918.13448.41.camel@martr-gentoo.artec> <1209786051.13448.56.camel@martr-gentoo.artec> <20080503034737.16401.qmail@stuge.se> Message-ID: <13426df10805022114t2106f37cw8c36c1322a3606c1@mail.gmail.com> I'll look at this more next week. I am having one more go at the interrupt mess on the alix1c, as that will also affect the dbe62. ron From rminnich at gmail.com Sat May 3 06:34:11 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 2 May 2008 21:34:11 -0700 Subject: [coreboot] [PATCH] artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines In-Reply-To: <20080503015934.22789.qmail@stuge.se> References: <1209779885.13448.16.camel@martr-gentoo.artec> <20080503015934.22789.qmail@stuge.se> Message-ID: <13426df10805022134o7f607847yc5cd59cefbb9a873@mail.gmail.com> On Fri, May 2, 2008 at 6:59 PM, Peter Stuge wrote: > On Sat, May 03, 2008 at 04:58:05AM +0300, Mart Raudsepp wrote: > > ???artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines > > > > > This makes the network adapter work fully, and reduces problems on high traffic (e.g kernel oopses on fsck run over USB 2.0 HDD) > > Many thanks for Peter Stuge for a lot of IRQ related help. > > > > Signed-off-by: Mart Raudsepp > > Acked-by: Peter Stuge Enthusiastically-Acked-by:Ronald G. Minnich From svn at coreboot.org Sat May 3 06:34:38 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Sat, 3 May 2008 06:34:38 +0200 Subject: [coreboot] r3277 - trunk/util/flashrom Message-ID: Author: stuge Date: 2008-05-03 06:34:37 +0200 (Sat, 03 May 2008) New Revision: 3277 Modified: trunk/util/flashrom/flash.h trunk/util/flashrom/flashchips.c trunk/util/flashrom/flashrom.c Log: flashrom: Add a tested bitmap field to the flash chip table. Two bits indicate OK and BAD for each operation PROBE READ ERASE WRITE. 8 bits out of 32 are in use now. No bits set means nothing has been tested. For chips with at least one operation that is not tested or not working, the user is asked to email a report to a special email adress so that the table can be updated. All chips are TEST_UNTESTED for now. Signed-off-by: Peter Stuge Acked-by: Carl-Daniel Hailfinger Modified: trunk/util/flashrom/flash.h =================================================================== --- trunk/util/flashrom/flash.h 2008-04-30 18:29:35 UTC (rev 3276) +++ trunk/util/flashrom/flash.h 2008-05-03 04:34:37 UTC (rev 3277) @@ -45,6 +45,11 @@ int total_size; int page_size; + /* Indicate if flashrom has been tested with this flash chip and if + * everything worked correctly. + */ + uint32_t tested; + int (*probe) (struct flashchip *flash); int (*erase) (struct flashchip *flash); int (*write) (struct flashchip *flash, uint8_t *buf); @@ -55,6 +60,20 @@ volatile uint8_t *virtual_registers; }; +#define TEST_UNTESTED 0 + +#define TEST_OK_PROBE (1<<0) +#define TEST_OK_READ (1<<1) +#define TEST_OK_ERASE (1<<2) +#define TEST_OK_WRITE (1<<3) +#define TEST_OK_MASK 0x0f + +#define TEST_BAD_PROBE (1<<4) +#define TEST_BAD_READ (1<<5) +#define TEST_BAD_ERASE (1<<6) +#define TEST_BAD_WRITE (1<<7) +#define TEST_BAD_MASK 0xf0 + extern struct flashchip flashchips[]; /* Modified: trunk/util/flashrom/flashchips.c =================================================================== --- trunk/util/flashrom/flashchips.c 2008-04-30 18:29:35 UTC (rev 3276) +++ trunk/util/flashrom/flashchips.c 2008-05-03 04:34:37 UTC (rev 3277) @@ -32,111 +32,111 @@ * the output of 'flashrom -L' is alphabetically sorted. */ struct flashchip flashchips[] = { - /******************************************************************************************************************************************************************************************************/ - /* Vendor Chip Vendor ID Chip ID TODO TODO Probe function Erase function Write function Read function */ - /******************************************************************************************************************************************************************************************************/ - {"AMD", "Am29F016D", AMD_ID, AM_29F016D, 2048, 64 * 1024, probe_29f040b, erase_29f040b, write_29f040b}, - {"AMD", "Am29F040B", AMD_ID, AM_29F040B, 512, 64 * 1024, probe_29f040b, erase_29f040b, write_29f040b}, - {"AMD", "Am29LV040B", AMD_ID, AM_29LV040B, 512, 64 * 1024, probe_29f040b, erase_29f040b, write_29f040b}, - {"ASD", "AE49F2008", ASD_ID, ASD_AE49F2008, 256, 128, probe_jedec, erase_chip_jedec, write_jedec}, - {"Atmel", "AT29C020", ATMEL_ID, AT_29C020, 256, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"Atmel", "AT29C040A", ATMEL_ID, AT_29C040A, 512, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"Atmel", "AT49F002(N)", ATMEL_ID, AT_49F002N, 256, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"Atmel", "AT49F002(N)T", ATMEL_ID, AT_49F002NT, 256, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"EMST", "F49B002UA", EMST_ID, EMST_F49B002UA, 256, 4096, probe_jedec, erase_chip_jedec, write_49f002}, - {"EON", "EN29F002(A)(N)B", EON_ID, EN_29F002B, 256, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"EON", "EN29F002(A)(N)T", EON_ID, EN_29F002T, 256, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"Fujitsu", "MBM29F400TC", FUJITSU_ID, MBM29F400TC_STRANGE, 512, 64 * 1024, probe_m29f400bt, erase_m29f400bt, write_coreboot_m29f400bt}, - {"Intel", "82802AB", INTEL_ID, 173, 512, 64 * 1024, probe_82802ab, erase_82802ab, write_82802ab}, - {"Intel", "82802AC", INTEL_ID, 172, 1024, 64 * 1024, probe_82802ab, erase_82802ab, write_82802ab}, - {"Macronix", "MX25L3205", MX_ID, MX_25L3205, 4096, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Macronix", "MX25L4005", MX_ID, MX_25L4005, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Macronix", "MX25L8005", MX_ID, MX_25L8005, 1024, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Macronix", "MX29F002", MX_ID, MX_29F002, 256, 64 * 1024, probe_29f002, erase_29f002, write_29f002}, + /**********************************************************************************************************************************************************************************************************************/ + /* Vendor Chip Vendor ID Chip ID TODO TODO Test status Probe function Erase function Write function Read function */ + /**********************************************************************************************************************************************************************************************************************/ + {"AMD", "Am29F016D", AMD_ID, AM_29F016D, 2048, 64 * 1024, TEST_UNTESTED, probe_29f040b, erase_29f040b, write_29f040b}, + {"AMD", "Am29F040B", AMD_ID, AM_29F040B, 512, 64 * 1024, TEST_UNTESTED, probe_29f040b, erase_29f040b, write_29f040b}, + {"AMD", "Am29LV040B", AMD_ID, AM_29LV040B, 512, 64 * 1024, TEST_UNTESTED, probe_29f040b, erase_29f040b, write_29f040b}, + {"ASD", "AE49F2008", ASD_ID, ASD_AE49F2008, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Atmel", "AT29C020", ATMEL_ID, AT_29C020, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Atmel", "AT29C040A", ATMEL_ID, AT_29C040A, 512, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Atmel", "AT49F002(N)", ATMEL_ID, AT_49F002N, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Atmel", "AT49F002(N)T", ATMEL_ID, AT_49F002NT, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"EMST", "F49B002UA", EMST_ID, EMST_F49B002UA, 256, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"EON", "EN29F002(A)(N)B", EON_ID, EN_29F002B, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"EON", "EN29F002(A)(N)T", EON_ID, EN_29F002T, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Fujitsu", "MBM29F400TC", FUJITSU_ID, MBM29F400TC_STRANGE, 512, 64 * 1024, TEST_UNTESTED, probe_m29f400bt, erase_m29f400bt, write_coreboot_m29f400bt}, + {"Intel", "82802AB", INTEL_ID, 173, 512, 64 * 1024, TEST_UNTESTED, probe_82802ab, erase_82802ab, write_82802ab}, + {"Intel", "82802AC", INTEL_ID, 172, 1024, 64 * 1024, TEST_UNTESTED, probe_82802ab, erase_82802ab, write_82802ab}, + {"Macronix", "MX25L3205", MX_ID, MX_25L3205, 4096, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Macronix", "MX25L4005", MX_ID, MX_25L4005, 512, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Macronix", "MX25L8005", MX_ID, MX_25L8005, 1024, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Macronix", "MX29F002", MX_ID, MX_29F002, 256, 64 * 1024, TEST_UNTESTED, probe_29f002, erase_29f002, write_29f002}, #ifndef DISABLE_DOC - {"M-Systems", "MD-2802", MSYSTEMS_ID, MSYSTEMS_MD2802, 8, 8 * 1024, probe_md2802, erase_md2802, write_md2802, read_md2802}, + {"M-Systems", "MD-2802", MSYSTEMS_ID, MSYSTEMS_MD2802, 8, 8 * 1024, TEST_UNTESTED, probe_md2802, erase_md2802, write_md2802, read_md2802}, #endif - {"PMC", "Pm25LV010", PMC_ID, PMC_25LV010, 128, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"PMC", "Pm25LV016B", PMC_ID, PMC_25LV016B, 2048, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"PMC", "Pm25LV020", PMC_ID, PMC_25LV020, 256, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"PMC", "Pm25LV040", PMC_ID, PMC_25LV040, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"PMC", "Pm25LV080B", PMC_ID, PMC_25LV080B, 1024, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"PMC", "Pm25LV512", PMC_ID, PMC_25LV512, 64, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"PMC", "Pm49FL002", PMC_ID_NOPREFIX,PMC_49FL002, 256, 16 * 1024, probe_jedec, erase_chip_jedec, write_49fl004}, - {"PMC", "Pm49FL004", PMC_ID_NOPREFIX,PMC_49FL004, 512, 64 * 1024, probe_jedec, erase_chip_jedec, write_49fl004}, - {"Sharp", "LHF00L04", SHARP_ID, SHARP_LHF00L04, 1024, 64 * 1024, probe_lhf00l04, erase_lhf00l04, write_lhf00l04}, - {"Spansion", "S25FL016A", SPANSION_ID, SPANSION_S25FL016A, 2048, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"SST", "SST25VF016B", SST_ID, SST_25VF016B, 2048, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"SST", "SST25VF040B", SST_ID, SST_25VF040B, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"SST", "SST28SF040A", SST_ID, SST_28SF040, 512, 256, probe_28sf040, erase_28sf040, write_28sf040}, - {"SST", "SST29EE020A", SST_ID, SST_29EE020A, 256, 128, probe_jedec, erase_chip_jedec, write_jedec}, - {"SST", "SST39SF010A", SST_ID, SST_39SF010, 128, 4096, probe_jedec, erase_chip_jedec, write_39sf020}, - {"SST", "SST39SF020A", SST_ID, SST_39SF020, 256, 4096, probe_jedec, erase_chip_jedec, write_39sf020}, - {"SST", "SST39SF040", SST_ID, SST_39SF040, 512, 4096, probe_jedec, erase_chip_jedec, write_39sf020}, - {"SST", "SST39VF020", SST_ID, SST_39VF020, 256, 4096, probe_jedec, erase_chip_jedec, write_39sf020}, + {"PMC", "Pm25LV010", PMC_ID, PMC_25LV010, 128, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"PMC", "Pm25LV016B", PMC_ID, PMC_25LV016B, 2048, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"PMC", "Pm25LV020", PMC_ID, PMC_25LV020, 256, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"PMC", "Pm25LV040", PMC_ID, PMC_25LV040, 512, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"PMC", "Pm25LV080B", PMC_ID, PMC_25LV080B, 1024, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"PMC", "Pm25LV512", PMC_ID, PMC_25LV512, 64, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"PMC", "Pm49FL002", PMC_ID_NOPREFIX,PMC_49FL002, 256, 16 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49fl004}, + {"PMC", "Pm49FL004", PMC_ID_NOPREFIX,PMC_49FL004, 512, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49fl004}, + {"Sharp", "LHF00L04", SHARP_ID, SHARP_LHF00L04, 1024, 64 * 1024, TEST_UNTESTED, probe_lhf00l04, erase_lhf00l04, write_lhf00l04}, + {"Spansion", "S25FL016A", SPANSION_ID, SPANSION_S25FL016A, 2048, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"SST", "SST25VF016B", SST_ID, SST_25VF016B, 2048, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"SST", "SST25VF040B", SST_ID, SST_25VF040B, 512, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"SST", "SST28SF040A", SST_ID, SST_28SF040, 512, 256, TEST_UNTESTED, probe_28sf040, erase_28sf040, write_28sf040}, + {"SST", "SST29EE020A", SST_ID, SST_29EE020A, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"SST", "SST39SF010A", SST_ID, SST_39SF010, 128, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"SST", "SST39SF020A", SST_ID, SST_39SF020, 256, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"SST", "SST39SF040", SST_ID, SST_39SF040, 512, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"SST", "SST39VF020", SST_ID, SST_39VF020, 256, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, // assume similar to 004B, ignoring data sheet - {"SST", "SST49LF002A/B", SST_ID, SST_49LF002A, 256, 16 * 1024, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, - {"SST", "SST49LF003A/B", SST_ID, SST_49LF003A, 384, 64 * 1024, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, - {"SST", "SST49LF004A/B", SST_ID, SST_49LF004A, 512, 64 * 1024, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, - {"SST", "SST49LF004C", SST_ID, SST_49LF004C, 512, 4 * 1024, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, - {"SST", "SST49LF008A", SST_ID, SST_49LF008A, 1024, 64 * 1024, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, - {"SST", "SST49LF008C", SST_ID, SST_49LF008C, 1024, 4 * 1024, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, - {"SST", "SST49LF016C", SST_ID, SST_49LF016C, 2048, 4 * 1024, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, - {"SST", "SST49LF020A", SST_ID, SST_49LF020A, 256, 16 * 1024, probe_jedec, erase_49lf040, write_49lf040}, - {"SST", "SST49LF040", SST_ID, SST_49LF040, 512, 4096, probe_jedec, erase_49lf040, write_49lf040}, - {"SST", "SST49LF040B", SST_ID, SST_49LF040B, 512, 64 * 1024, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, - {"SST", "SST49LF080A", SST_ID, SST_49LF080A, 1024, 4096, probe_jedec, erase_49lf040, write_49lf040}, - {"SST", "SST49LF160C", SST_ID, SST_49LF160C, 2048, 4 * 1024, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, - {"ST", "M25P05-A", ST_ID, ST_M25P05A, 64, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P10-A", ST_ID, ST_M25P10A, 128, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P128", ST_ID, ST_M25P128, 16384, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P16", ST_ID, ST_M25P16, 2048, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P20", ST_ID, ST_M25P20, 256, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P32", ST_ID, ST_M25P32, 4096, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P40", ST_ID, ST_M25P40, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P64", ST_ID, ST_M25P64, 8192, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M25P80", ST_ID, ST_M25P80, 1024, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"ST", "M29F002B", ST_ID, ST_M29F002B, 256, 64 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"ST", "M29F002T/NT", ST_ID, ST_M29F002T, 256, 64 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"ST", "M29F040B", ST_ID, ST_M29F040B, 512, 64 * 1024, probe_29f040b, erase_29f040b, write_29f040b}, - {"ST", "M29F400BT", ST_ID, ST_M29F400BT, 512, 64 * 1024, probe_m29f400bt, erase_m29f400bt, write_coreboot_m29f400bt}, - {"ST", "M29W010B", ST_ID, ST_M29W010B, 128, 16 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"ST", "M29W040B", ST_ID, ST_M29W040B, 512, 64 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"ST", "M50FLW040A", ST_ID, ST_M50FLW040A, 512, 64 * 1024, probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x}, - {"ST", "M50FLW040B", ST_ID, ST_M50FLW040B, 512, 64 * 1024, probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x}, - {"ST", "M50FLW080A", ST_ID, ST_M50FLW080A, 1024, 64 * 1024, probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x}, - {"ST", "M50FLW080B", ST_ID, ST_M50FLW080B, 1024, 64 * 1024, probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x}, - {"ST", "M50FW016", ST_ID, ST_M50FW016, 2048, 64 * 1024, probe_82802ab, erase_82802ab, write_82802ab}, - {"ST", "M50FW040", ST_ID, ST_M50FW040, 512, 64 * 1024, probe_82802ab, erase_82802ab, write_82802ab}, - {"ST", "M50FW080", ST_ID, ST_M50FW080, 1024, 64 * 1024, probe_82802ab, erase_82802ab, write_82802ab}, - {"ST", "M50LPW116", ST_ID, ST_M50LPW116, 2048, 64 * 1024, probe_jedec, erase_chip_jedec, write_jedec}, - {"SyncMOS", "S29C31004T", SYNCMOS_ID, S29C31004T, 512, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"SyncMOS", "S29C51001T", SYNCMOS_ID, S29C51001T, 128, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"SyncMOS", "S29C51002T", SYNCMOS_ID, S29C51002T, 256, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"SyncMOS", "S29C51004T", SYNCMOS_ID, S29C51004T, 512, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"Winbond", "W25x10", WINBOND_NEX_ID, W_25X10, 128, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Winbond", "W25x20", WINBOND_NEX_ID, W_25X20, 256, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Winbond", "W25x40", WINBOND_NEX_ID, W_25X40, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Winbond", "W25x80", WINBOND_NEX_ID, W_25X80, 1024, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, - {"Winbond", "W29C011", WINBOND_ID, W_29C011, 128, 128, probe_jedec, erase_chip_jedec, write_jedec}, - {"Winbond", "W29C020C", WINBOND_ID, W_29C020C, 256, 128, probe_jedec, erase_chip_jedec, write_jedec}, - {"Winbond", "W29C040P", WINBOND_ID, W_29C040P, 512, 256, probe_jedec, erase_chip_jedec, write_jedec}, - {"Winbond", "W29EE011", WINBOND_ID, W_29C011, 128, 128, probe_w29ee011, erase_chip_jedec, write_jedec}, - {"Winbond", "W39V040A", WINBOND_ID, W_39V040A, 512, 64*1024, probe_jedec, erase_chip_jedec, write_39sf020}, - {"Winbond", "W39V040B", WINBOND_ID, W_39V040B, 512, 64*1024, probe_jedec, erase_chip_jedec, write_39sf020}, - {"Winbond", "W39V040FA", WINBOND_ID, W_39V040FA, 512, 64*1024, probe_jedec, erase_chip_jedec, write_39sf020}, - {"Winbond", "W39V080A", WINBOND_ID, W_39V080A, 1024, 64*1024, probe_jedec, erase_chip_jedec, write_39sf020}, - {"Winbond", "W49F002U", WINBOND_ID, W_49F002U, 256, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"Winbond", "W49V002A", WINBOND_ID, W_49V002A, 256, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"Winbond", "W49V002FA", WINBOND_ID, W_49V002FA, 256, 128, probe_jedec, erase_chip_jedec, write_49f002}, - {"Winbond", "W39V080FA", WINBOND_ID, W_39V080FA, 1024, 64*1024, probe_winbond_fwhub, erase_winbond_fwhub, write_winbond_fwhub}, - {"Winbond", "W39V080FA (dual mode)",WINBOND_ID, W_39V080FA_DM, 512, 64*1024, probe_winbond_fwhub, erase_winbond_fwhub, write_winbond_fwhub}, + {"SST", "SST49LF002A/B", SST_ID, SST_49LF002A, 256, 16 * 1024, TEST_UNTESTED, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, + {"SST", "SST49LF003A/B", SST_ID, SST_49LF003A, 384, 64 * 1024, TEST_UNTESTED, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, + {"SST", "SST49LF004A/B", SST_ID, SST_49LF004A, 512, 64 * 1024, TEST_UNTESTED, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, + {"SST", "SST49LF004C", SST_ID, SST_49LF004C, 512, 4 * 1024, TEST_UNTESTED, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, + {"SST", "SST49LF008A", SST_ID, SST_49LF008A, 1024, 64 * 1024, TEST_UNTESTED, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, + {"SST", "SST49LF008C", SST_ID, SST_49LF008C, 1024, 4 * 1024, TEST_UNTESTED, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, + {"SST", "SST49LF016C", SST_ID, SST_49LF016C, 2048, 4 * 1024, TEST_UNTESTED, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, + {"SST", "SST49LF020A", SST_ID, SST_49LF020A, 256, 16 * 1024, TEST_UNTESTED, probe_jedec, erase_49lf040, write_49lf040}, + {"SST", "SST49LF040", SST_ID, SST_49LF040, 512, 4096, TEST_UNTESTED, probe_jedec, erase_49lf040, write_49lf040}, + {"SST", "SST49LF040B", SST_ID, SST_49LF040B, 512, 64 * 1024, TEST_UNTESTED, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, + {"SST", "SST49LF080A", SST_ID, SST_49LF080A, 1024, 4096, TEST_UNTESTED, probe_jedec, erase_49lf040, write_49lf040}, + {"SST", "SST49LF160C", SST_ID, SST_49LF160C, 2048, 4 * 1024, TEST_UNTESTED, probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, + {"ST", "M25P05-A", ST_ID, ST_M25P05A, 64, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P10-A", ST_ID, ST_M25P10A, 128, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P128", ST_ID, ST_M25P128, 16384, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P16", ST_ID, ST_M25P16, 2048, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P20", ST_ID, ST_M25P20, 256, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P32", ST_ID, ST_M25P32, 4096, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P40", ST_ID, ST_M25P40, 512, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P64", ST_ID, ST_M25P64, 8192, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M25P80", ST_ID, ST_M25P80, 1024, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"ST", "M29F002B", ST_ID, ST_M29F002B, 256, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"ST", "M29F002T/NT", ST_ID, ST_M29F002T, 256, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"ST", "M29F040B", ST_ID, ST_M29F040B, 512, 64 * 1024, TEST_UNTESTED, probe_29f040b, erase_29f040b, write_29f040b}, + {"ST", "M29F400BT", ST_ID, ST_M29F400BT, 512, 64 * 1024, TEST_UNTESTED, probe_m29f400bt, erase_m29f400bt, write_coreboot_m29f400bt}, + {"ST", "M29W010B", ST_ID, ST_M29W010B, 128, 16 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"ST", "M29W040B", ST_ID, ST_M29W040B, 512, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"ST", "M50FLW040A", ST_ID, ST_M50FLW040A, 512, 64 * 1024, TEST_UNTESTED, probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x}, + {"ST", "M50FLW040B", ST_ID, ST_M50FLW040B, 512, 64 * 1024, TEST_UNTESTED, probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x}, + {"ST", "M50FLW080A", ST_ID, ST_M50FLW080A, 1024, 64 * 1024, TEST_UNTESTED, probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x}, + {"ST", "M50FLW080B", ST_ID, ST_M50FLW080B, 1024, 64 * 1024, TEST_UNTESTED, probe_stm50flw0x0x, erase_stm50flw0x0x, write_stm50flw0x0x}, + {"ST", "M50FW016", ST_ID, ST_M50FW016, 2048, 64 * 1024, TEST_UNTESTED, probe_82802ab, erase_82802ab, write_82802ab}, + {"ST", "M50FW040", ST_ID, ST_M50FW040, 512, 64 * 1024, TEST_UNTESTED, probe_82802ab, erase_82802ab, write_82802ab}, + {"ST", "M50FW080", ST_ID, ST_M50FW080, 1024, 64 * 1024, TEST_UNTESTED, probe_82802ab, erase_82802ab, write_82802ab}, + {"ST", "M50LPW116", ST_ID, ST_M50LPW116, 2048, 64 * 1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"SyncMOS", "S29C31004T", SYNCMOS_ID, S29C31004T, 512, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"SyncMOS", "S29C51001T", SYNCMOS_ID, S29C51001T, 128, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"SyncMOS", "S29C51002T", SYNCMOS_ID, S29C51002T, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"SyncMOS", "S29C51004T", SYNCMOS_ID, S29C51004T, 512, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"Winbond", "W25x10", WINBOND_NEX_ID, W_25X10, 128, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Winbond", "W25x20", WINBOND_NEX_ID, W_25X20, 256, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Winbond", "W25x40", WINBOND_NEX_ID, W_25X40, 512, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Winbond", "W25x80", WINBOND_NEX_ID, W_25X80, 1024, 256, TEST_UNTESTED, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Winbond", "W29C011", WINBOND_ID, W_29C011, 128, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Winbond", "W29C020C", WINBOND_ID, W_29C020C, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Winbond", "W29C040P", WINBOND_ID, W_29C040P, 512, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, + {"Winbond", "W29EE011", WINBOND_ID, W_29C011, 128, 128, TEST_UNTESTED, probe_w29ee011, erase_chip_jedec, write_jedec}, + {"Winbond", "W39V040A", WINBOND_ID, W_39V040A, 512, 64*1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"Winbond", "W39V040B", WINBOND_ID, W_39V040B, 512, 64*1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"Winbond", "W39V040FA", WINBOND_ID, W_39V040FA, 512, 64*1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"Winbond", "W39V080A", WINBOND_ID, W_39V080A, 1024, 64*1024, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"Winbond", "W49F002U", WINBOND_ID, W_49F002U, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"Winbond", "W49V002A", WINBOND_ID, W_49V002A, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"Winbond", "W49V002FA", WINBOND_ID, W_49V002FA, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, + {"Winbond", "W39V080FA", WINBOND_ID, W_39V080FA, 1024, 64*1024, TEST_UNTESTED, probe_winbond_fwhub, erase_winbond_fwhub, write_winbond_fwhub}, + {"Winbond", "W39V080FA (dual mode)",WINBOND_ID, W_39V080FA_DM, 512, 64*1024, TEST_UNTESTED, probe_winbond_fwhub, erase_winbond_fwhub, write_winbond_fwhub}, - {"EON", "unknown SPI chip", EON_ID_NOPREFIX,GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, - {"Macronix", "unknown SPI chip", MX_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, - {"PMC", "unknown SPI chip", PMC_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, - {"SST", "unknown SPI chip", SST_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, - {"ST", "unknown SPI chip", ST_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, + {"EON", "unknown SPI chip", EON_ID_NOPREFIX,GENERIC_DEVICE_ID, 0, 0, TEST_UNTESTED, probe_spi, NULL, NULL}, + {"Macronix", "unknown SPI chip", MX_ID, GENERIC_DEVICE_ID, 0, 0, TEST_UNTESTED, probe_spi, NULL, NULL}, + {"PMC", "unknown SPI chip", PMC_ID, GENERIC_DEVICE_ID, 0, 0, TEST_UNTESTED, probe_spi, NULL, NULL}, + {"SST", "unknown SPI chip", SST_ID, GENERIC_DEVICE_ID, 0, 0, TEST_UNTESTED, probe_spi, NULL, NULL}, + {"ST", "unknown SPI chip", ST_ID, GENERIC_DEVICE_ID, 0, 0, TEST_UNTESTED, probe_spi, NULL, NULL}, {NULL,} }; Modified: trunk/util/flashrom/flashrom.c =================================================================== --- trunk/util/flashrom/flashrom.c 2008-04-30 18:29:35 UTC (rev 3276) +++ trunk/util/flashrom/flashrom.c 2008-05-03 04:34:37 UTC (rev 3277) @@ -412,6 +412,36 @@ } printf("Flash part is %s (%d KB).\n", flash->name, flash->total_size); + if (TEST_OK_MASK != (flash->tested & TEST_OK_MASK)) { + printf("===\n"); + if (flash->tested & TEST_BAD_MASK) { + printf("This flash part has status NOT WORKING for operations:"); + if (flash->tested & TEST_BAD_PROBE) + printf(" PROBE"); + if (flash->tested & TEST_BAD_READ) + printf(" READ"); + if (flash->tested & TEST_BAD_ERASE) + printf(" ERASE"); + if (flash->tested & TEST_BAD_WRITE) + printf(" WRITE"); + printf("\n"); + } else { + printf("This flash part has status UNTESTED for operations:"); + if (!(flash->tested & TEST_OK_PROBE)) + printf(" PROBE"); + if (!(flash->tested & TEST_OK_READ)) + printf(" READ"); + if (!(flash->tested & TEST_OK_ERASE)) + printf(" ERASE"); + if (!(flash->tested & TEST_OK_WRITE)) + printf(" WRITE"); + printf("\n"); + } + printf("Please email a report to flashrom at coreboot.org if any of the above operations\n"); + printf("work correctly for you with this flash part. Please include the full output\n"); + printf("from the program, including chipset found. Thank you for your help!\n"); + printf("===\n"); + } if (!(read_it | write_it | verify_it | erase_it)) { printf("No operations were specified.\n"); From peter at stuge.se Sat May 3 06:36:09 2008 From: peter at stuge.se (Peter Stuge) Date: Sat, 3 May 2008 06:36:09 +0200 Subject: [coreboot] flashrom: Add tested bitmap to flashchips table. In-Reply-To: <481BC281.1060009@gmx.net> References: <20080502162945.12596.qmail@stuge.se> <481B429A.5060201@gmx.net> <0c12c15a72c9c97bbffb0245b70ee200@imap.1and1.com> <20080502162945.12596.qmail@stuge.se> <481B429A.5060201@gmx.net> <20080502175030.5882.qmail@stuge.se> <481BC281.1060009@gmx.net> Message-ID: <20080503043609.29010.qmail@stuge.se> Thanks for your comments! On Sat, May 03, 2008 at 03:40:17AM +0200, Carl-Daniel Hailfinger wrote: > > + /* Indicate if flashrom has been tested with this flash chip and if > > + * everything worked correctly. > > + */ > > + uint8_t tested; > > > > Due to alignment of the subsequent struct member, we'll waste 24 bits > here. We might as well make this a 32bit variable. It's not needed > right now, though. It felt a bit cramped with no free bits so I changed it to uint32_t. > > + if (TEST_OK_MASK != (flash->tested & TEST_OK_MASK)) { > > + printf("--\n"); > > > > The printf above may be dangerous if it is interpreted as a > signature separator by some e-mail program... Changed to === > Maybe add: "In doubt, mail the whole output of flashrom." I changed the wording a bit. > That also begs the question whether we want to echo the flashrom > parameters by default. Maybe, but I don't know if that would be useful? > Acked-by: Carl-Daniel Hailfinger Thanks! r3277. //Peter From dhendrix at google.com Sat May 3 06:38:10 2008 From: dhendrix at google.com (David Hendricks) Date: Fri, 2 May 2008 21:38:10 -0700 Subject: [coreboot] Presenting at a LUG In-Reply-To: <006901c8ac04$af2344f0$6401a8c0@who8> References: <006901c8ac04$af2344f0$6401a8c0@who8> Message-ID: +1 It looks we may have lured Ron in to doing a presentation from Google's Mountain View, CA campus. Though it's not finalized yet, I would like to preemptively invite anyone near a Google office to join via videoconferencing. Please contact me directly if you and your LUG (if applicable) are interested. On Thu, May 1, 2008 at 8:29 PM, Gregg C Levine < hansolofalcon at worldnet.att.net> wrote: > Hello! > Would anyone who's a member of the list, be interested in presenting at a > LUG? > > I am a member of the NYLUG outfit, and I am interested in, call it being > the > one to welcome an associate of the list to the group. Although I suspect > an > officer of the group would want to do that. > > NYLUG incidentally is the New York Linux User's Group. It meets on the > last > Wednesday of each month. > > Physical demonstrations are very welcome at each presentation. > > Please note that I do not speak for the group, I am only a member of it. > -- > Gregg C Levine hansolofalcon at worldnet.att.net > "The Force will be with you always." Obi-Wan Kenobi > > > > > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Sat May 3 06:42:47 2008 From: peter at stuge.se (Peter Stuge) Date: Sat, 3 May 2008 06:42:47 +0200 Subject: [coreboot] alix1c PATA In-Reply-To: <13426df10805022114t2106f37cw8c36c1322a3606c1@mail.gmail.com> References: <1209781918.13448.41.camel@martr-gentoo.artec> <1209786051.13448.56.camel@martr-gentoo.artec> <20080503034737.16401.qmail@stuge.se> <13426df10805022114t2106f37cw8c36c1322a3606c1@mail.gmail.com> Message-ID: <20080503044247.30728.qmail@stuge.se> On Fri, May 02, 2008 at 09:14:42PM -0700, ron minnich wrote: > I am having one more go at the interrupt mess on the alix1c I've just booted my 1c with v3, 2.6.25 and lxfb but the 5536 PATA driver does not want to play so it does not mount root. Is there a special trick? Does v3 disable PATA? (It is enabled by default from reset.) //Peter From rminnich at gmail.com Sat May 3 06:46:41 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 2 May 2008 21:46:41 -0700 Subject: [coreboot] [PATCH] artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines In-Reply-To: <13426df10805022134o7f607847yc5cd59cefbb9a873@mail.gmail.com> References: <1209779885.13448.16.camel@martr-gentoo.artec> <20080503015934.22789.qmail@stuge.se> <13426df10805022134o7f607847yc5cd59cefbb9a873@mail.gmail.com> Message-ID: <13426df10805022146s7b5d9e38v264870a629811ed8@mail.gmail.com> (I'm hoping someone will do this :-) One issue I'm having is that the hfcpci card (or driver) can't tolerate shared interrupts. But we have shared interrupts on the various cs5536 boards, since we put USB interrupt info in the table. To allow us to have non-shared interrupts for all devices, we need to get the USB interrupts out of the PIR table. They are not really routed via the standard IRQ router anyway -- they are internal -- and don't need to share interrupt #s with the other devices that are actually routed via the interrupt routing hardware. Put simply, having the USB f.3,4,5 devices in the PIR table works, but is really a bit of a mistake. OK, where do we put the IRQ info for the USB devices? In the DTS for the cs5536. SO in DTS for the cs5536 we need three more properties, usbf3 usbf4 usbf5 with reasonable settings for them. Then in the chipset init code, we need to see if these are set and, if so, set the IRQ line in the f.3, f.4, and f.5 devices. If this is confusing I can explain in more detail, but later, I'm tired, and the ISDN card just locked up again. How can such a simple driver have so many failure modes? Oh, wait, it's not simple, sigh. but, short form: on the cs5536, USB interrupts should not be described in the PIR table, but via settings derived from dts. They should be initialized in cs5536 setup code, no in the PIR setup code. That will allow us to have non-shared interrupts on the various PCI slots on, e.g., alix1c, and allow broken drivers like hfcpci to work. ron From rminnich at gmail.com Sat May 3 06:49:03 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 2 May 2008 21:49:03 -0700 Subject: [coreboot] alix1c PATA In-Reply-To: <20080503044247.30728.qmail@stuge.se> References: <1209781918.13448.41.camel@martr-gentoo.artec> <1209786051.13448.56.camel@martr-gentoo.artec> <20080503034737.16401.qmail@stuge.se> <13426df10805022114t2106f37cw8c36c1322a3606c1@mail.gmail.com> <20080503044247.30728.qmail@stuge.se> Message-ID: <13426df10805022149l4fb1db57kf4187e49776da68b@mail.gmail.com> On Fri, May 2, 2008 at 9:42 PM, Peter Stuge wrote: > On Fri, May 02, 2008 at 09:14:42PM -0700, ron minnich wrote: > > I am having one more go at the interrupt mess on the alix1c > > I've just booted my 1c with v3, 2.6.25 and lxfb but the 5536 PATA > driver does not want to play so it does not mount root. > > Is there a special trick? Does v3 disable PATA? > (It is enabled by default from reset.) > > I'm afraid you are in new territory. I have only booted the CF. v3 might disable pata if it enables the CF -- they are the same wires IIRC. We may need a config option for this so it can be part o the dialog. Oh wait it shouldn't matter -- you moved the jumper right? Isn't it all jumper based? can you try with a cf root just to see if that works at all? ron From rminnich at gmail.com Sat May 3 07:51:59 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 2 May 2008 22:51:59 -0700 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts Message-ID: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> This is not signed off, as it does not work. It sets up the interrupts correctly, or at least as defined in the dts: 00:0f.3 Multimedia audio controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio (rev 0) Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- From c-d.hailfinger.devel.2006 at gmx.net Sat May 3 11:46:21 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 03 May 2008 11:46:21 +0200 Subject: [coreboot] flashrom: Add tested bitmap to flashchips table. In-Reply-To: <20080503043609.29010.qmail@stuge.se> References: <20080502162945.12596.qmail@stuge.se> <481B429A.5060201@gmx.net> <0c12c15a72c9c97bbffb0245b70ee200@imap.1and1.com> <20080502162945.12596.qmail@stuge.se> <481B429A.5060201@gmx.net> <20080502175030.5882.qmail@stuge.se> <481BC281.1060009@gmx.net> <20080503043609.29010.qmail@stuge.se> Message-ID: <481C346D.6040508@gmx.net> On 03.05.2008 06:36, Peter Stuge wrote: > Thanks for your comments! > Thanks for taking them into account! > On Sat, May 03, 2008 at 03:40:17AM +0200, Carl-Daniel Hailfinger wrote: > >>> + /* Indicate if flashrom has been tested with this flash chip and if >>> + * everything worked correctly. >>> + */ >>> + uint8_t tested; >>> >>> >> Due to alignment of the subsequent struct member, we'll waste 24 bits >> here. We might as well make this a 32bit variable. It's not needed >> right now, though. >> > > It felt a bit cramped with no free bits so I changed it to uint32_t. > > > >>> + if (TEST_OK_MASK != (flash->tested & TEST_OK_MASK)) { >>> + printf("--\n"); >>> >>> >> The printf above may be dangerous if it is interpreted as a >> signature separator by some e-mail program... >> > > Changed to === > > > >> Maybe add: "In doubt, mail the whole output of flashrom." >> > > I changed the wording a bit. > > > >> That also begs the question whether we want to echo the flashrom >> parameters by default. >> > > Maybe, but I don't know if that would be useful? > Just that if the user reports "It works" without further info, we know immediately what works. >> Acked-by: Carl-Daniel Hailfinger >> > > Thanks! r3277. > Thanks! Regards, Carl-Daniel From peter at stuge.se Sat May 3 11:48:33 2008 From: peter at stuge.se (Peter Stuge) Date: Sat, 3 May 2008 11:48:33 +0200 Subject: [coreboot] alix1c PATA In-Reply-To: <13426df10805022149l4fb1db57kf4187e49776da68b@mail.gmail.com> References: <1209781918.13448.41.camel@martr-gentoo.artec> <1209786051.13448.56.camel@martr-gentoo.artec> <20080503034737.16401.qmail@stuge.se> <13426df10805022114t2106f37cw8c36c1322a3606c1@mail.gmail.com> <20080503044247.30728.qmail@stuge.se> <13426df10805022149l4fb1db57kf4187e49776da68b@mail.gmail.com> Message-ID: <20080503094833.13328.qmail@stuge.se> On Fri, May 02, 2008 at 09:49:03PM -0700, ron minnich wrote: > > Is there a special trick? Does v3 disable PATA? > > (It is enabled by default from reset.) > > I'm afraid you are in new territory. I have only booted the CF. I'm trying to boot CF too. FILO loads the kernel fine. > Oh wait it shouldn't matter -- you moved the jumper right? > Isn't it all jumper based? Jumper still on "ON=CF master" > can you try with a cf root just to see if that works at all? ========== mainboard_pre_payload: done ========================================= FILO version 0.5 (stuge at n410c) Thu Jan 24 04:17:59 CET 2008 boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200 hda: LBA 1025MB: SanDisk SDCFX3-1024 Mounted ext2fs Found Linux version 2.6.25 (stuge at n410c) #1 PREEMPT Sat May 3 06:26:40 CEST 2008 bzImage. Loading kernel... ok Jumping to entry point... Linux version 2.6.25 (stuge at n410c) (gcc version 4.2.2 (Gentoo 4.2.2 p1.0)) #1 PREEMPT Sat May 3 06:26:40 CEST 2008 BIOS-provided physical RAM map: BIOS-e820: 0000000000000b70 - 00000000000a0000 (usable) BIOS-e820: 0000000000100000 - 000000000f7e0000 (usable) 247MB LOWMEM available. Scan SMP from c0000000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f0000 for 65536 bytes. Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 63456 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0 -> 63456 DMI not present or invalid. Allocating PCI resources starting at 10000000 (gap: 0f7e0000:f0820000) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 62961 Kernel command line: root=/dev/hda1 console=tty0 console=ttyS0,115200 No local APIC present or hardware disabled Initializing CPU#0 PID hash table entries: 1024 (order: 10, 4096 bytes) Detected 498.059 MHz processor. Console: colour dummy device 80x25 console [tty0] enabled console [ttyS0] enabled Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 247868k/253824k available (2140k kernel code, 5460k reserved, 779k data, 160k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffba000 - 0xfffff000 ( 276 kB) vmalloc : 0xd0000000 - 0xfffb8000 ( 767 MB) lowmem : 0xc0000000 - 0xcf7e0000 ( 247 MB) .init : 0xc03dc000 - 0xc0404000 ( 160 kB) .data : 0xc0317170 - 0xc03d9fb8 ( 779 kB) .text : 0xc0100000 - 0xc0317170 (2140 kB) Checking if this processor honours the WP bit even in supervisor mode...Ok. SLUB: Genslabs=12, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Calibrating delay using timer specific routine.. 997.14 BogoMIPS (lpj=498573) Mount-cache hash table entries: 512 CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line) CPU: L2 Cache: 128K (32 bytes/line) Compat vDSO mapped to ffffe000. CPU: AMD Geode(TM) Integrated Processor by AMD PCS stepping 02 Checking 'hlt' instruction... OK. Freeing SMP alternatives: 0k freed net_namespace: 152 bytes NET: Registered protocol family 16 PCI: Using configuration type 1 Setting up standard PCI resources SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Probing PCI hardware PCI: Using IRQ router default [1022/2090] at 0000:00:0f.0 Bluetooth: Core ver 2.11 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered NTFS driver 2.1.29 [Flags: R/O]. io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) PCI: Guessed IRQ 11 for device 0000:00:01.1 PCI: Sharing IRQ 11 with 0000:00:01.2 lxfb 0000:00:01.1: 8192 KB of video memory at 0xfd000000 fbcon: Geode LX (fb0) is primary device Console: switching to colour frame buffer device 80x30 fb0: Geode LX frame buffer device Generic RTC Driver v1.07 AMD Geode RNG detected Linux agpgart interface v0.103 [drm] Initialized drm 1.1.0 20060810 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP] parport0: irq 7 detected loop: module loaded via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker PCI: Guessed IRQ 10 for device 0000:00:0d.0 PCI: Sharing IRQ 10 with 0000:00:0f.3 eth0: VIA Rhine III (Management Adapter) at 0xfe019000, 00:0d:b9:0d:0a:e4, IRQ 10. eth0: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000. tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky usbcore: registered new interface driver cdc_ether usbcore: registered new interface driver MOSCHIP usb-ethernet driver Driver 'sd' needs updating - please use bus_type methods Driver 'sr' needs updating - please use bus_type methods pata_cs5536: disabled by BIOS usbmon: debugfs is not available PCI: Guessed IRQ 9 for device 0000:00:0f.5 PCI: Sharing IRQ 9 with 0000:00:0f.4 ehci_hcd 0000:00:0f.5: EHCI Host Controller ehci_hcd 0000:00:0f.5: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:0f.5: irq 9, io mem 0xfe017000 ehci_hcd 0000:00:0f.5: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 4 ports detected PCI: Guessed IRQ 9 for device 0000:00:0f.4 PCI: Sharing IRQ 9 with 0000:00:0f.5 ohci_hcd 0000:00:0f.4: OHCI Host Controller ohci_hcd 0000:00:0f.4: new USB bus registered, assigned bus number 2 ohci_hcd 0000:00:0f.4: irq 9, io mem 0xfe016000 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 4 ports detected usbcore: registered new interface driver usblp Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usbcore: registered new interface driver usbserial drivers/usb/serial/usb-serial.c: USB Serial Driver core drivers/usb/serial/usb-serial.c: USB Serial support registered for pl2303 usbcore: registered new interface driver pl2303 drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver i8042.c: Can't read CTR while initializing i8042. i8042: probe of i8042 failed with error -5 mice: PS/2 mouse device common for all mice WDT driver for the Winbond(TM) W83627HF/THF/HG Super I/O chip initialising. w83627hf/thf/hg WDT: initialized. timeout=60 sec (nowayout=0) Bluetooth: HCI USB driver ver 2.9 usbcore: registered new interface driver hci_usb PCI: Guessed IRQ 11 for device 0000:00:01.2 PCI: Sharing IRQ 11 with 0000:00:01.1 geode-aes: GEODE AES engine enabled. usbcore: registered new interface driver usbhid drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver Advanced Linux Sound Architecture Driver Version 1.0.16rc2 (Thu Jan 31 16:40:16 2008 UTC). PCI: Guessed IRQ 10 for device 0000:00:0f.3 PCI: Sharing IRQ 10 with 0000:00:0d.0 usbcore: registered new interface driver snd-usb-audio ALSA device list: #0: CS5535 Audio cs5535audio at 0x1880, irq 10 NET: Registered protocol family 1 NET: Registered protocol family 17 Bluetooth: L2CAP ver 2.9 Bluetooth: L2CAP socket layer initialized Bluetooth: SCO (Voice Link) ver 0.5 Bluetooth: SCO socket layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM ver 1.8 802.1Q VLAN Support v1.8 Ben Greear All bugs added by David S. Miller Using IPI Shortcut mode VFS: Cannot open root device "hda1" or unknown-block(0,0) Please append a correct "root=" boot option; here are the available partitions: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) No mention of the PATA. Linux doesn't see the CF. :\ //Peter From jordan at chalmers.se Sat May 3 14:43:30 2008 From: jordan at chalmers.se (Ulf Jordan) Date: Sat, 3 May 2008 14:43:30 +0200 (CEST) Subject: [coreboot] alix1c PATA In-Reply-To: <20080503094833.13328.qmail@stuge.se> References: <1209781918.13448.41.camel@martr-gentoo.artec> <1209786051.13448.56.camel@martr-gentoo.artec> <20080503034737.16401.qmail@stuge.se> <13426df10805022114t2106f37cw8c36c1322a3606c1@mail.gmail.com> <20080503044247.30728.qmail@stuge.se> <13426df10805022149l4fb1db57kf4187e49776da68b@mail.gmail.com> <20080503094833.13328.qmail@stuge.se> Message-ID: On Sat, 3 May 2008, Peter Stuge wrote: > On Fri, May 02, 2008 at 09:49:03PM -0700, ron minnich wrote: >>> Is there a special trick? Does v3 disable PATA? >>> (It is enabled by default from reset.) >> >> I'm afraid you are in new territory. I have only booted the CF. > > I'm trying to boot CF too. FILO loads the kernel fine. > > >> Oh wait it shouldn't matter -- you moved the jumper right? >> Isn't it all jumper based? > > Jumper still on "ON=CF master" > > >> can you try with a cf root just to see if that works at all? > > ========== mainboard_pre_payload: done ========================================= > FILO version 0.5 (stuge at n410c) Thu Jan 24 04:17:59 CET 2008 > boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200 > hda: LBA 1025MB: SanDisk SDCFX3-1024 > Mounted ext2fs > Found Linux version 2.6.25 (stuge at n410c) #1 PREEMPT Sat May 3 06:26:40 CEST 2008 bzImage. > Loading kernel... ok > Jumping to entry point... > Linux version 2.6.25 (stuge at n410c) (gcc version 4.2.2 (Gentoo 4.2.2 p1.0)) #1 PREEMPT Sat May 3 06:26:40 CEST 2008 [...] > Driver 'sd' needs updating - please use bus_type methods > Driver 'sr' needs updating - please use bus_type methods > pata_cs5536: disabled by BIOS Hmm, I wonder if this is something coreboot has disabled or not enabled? drivers/ata/pata_cs5536.c:244 tests a bit in the IDE config register of CS5536. /ulf From svn at coreboot.org Sat May 3 16:44:59 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Sat, 3 May 2008 16:44:59 +0200 Subject: [coreboot] r46 - in trunk/filo-0.5: . main Message-ID: Author: stepan Date: 2008-05-03 16:44:59 +0200 (Sat, 03 May 2008) New Revision: 46 Modified: trunk/filo-0.5/main/pci.c trunk/filo-0.5/makerules Log: catch oddly configured pci bridges... Modified: trunk/filo-0.5/main/pci.c =================================================================== --- trunk/filo-0.5/main/pci.c 2008-03-28 14:25:16 UTC (rev 45) +++ trunk/filo-0.5/main/pci.c 2008-05-03 14:44:59 UTC (rev 46) @@ -16,6 +16,7 @@ is_multi = 0; for (fn = 0; fn==0 || (is_multi && fn<8); fn++) { addr = PCI_ADDR(bus, devnum, fn); + // debug("PCI: %02x:%02x.%x\n", bus,devnum, fn); vid = pci_read16(addr, PCI_VENDOR_ID); if (vid==0xffff || vid==0) continue; @@ -36,8 +37,12 @@ #if !PCI_BRUTE_SCAN htype &= 0x7f; if (htype==PCI_HEADER_TYPE_BRIDGE - || htype==PCI_HEADER_TYPE_CARDBUS) + || htype==PCI_HEADER_TYPE_CARDBUS) { + if (pci_read8(addr, PCI_SECONDARY_BUS)) pci_scan_bus(pci_read8(addr, PCI_SECONDARY_BUS)); + else + debug("WARNING: %02x:%02x.%x has a secondary bus of 0\n", bus, devnum, fn); + } #endif } } Modified: trunk/filo-0.5/makerules =================================================================== --- trunk/filo-0.5/makerules 2008-03-28 14:25:16 UTC (rev 45) +++ trunk/filo-0.5/makerules 2008-05-03 14:44:59 UTC (rev 46) @@ -7,7 +7,7 @@ CPPFLAGS = -nostdinc -imacros $(TOPDIR)/config.h -I$(TOPDIR)/include -I$(GCCINCDIR) -MD # grub part needs no-strict-aliasing! CFLAGS = -Wall -Os -fomit-frame-pointer -fno-common -ffreestanding \ - -fno-strict-aliasing -Wno-pointer-sign -Wno-unused + -fno-strict-aliasing -Wno-unused ASFLAGS = -D__ASSEMBLY__ RANLIB = ranlib From svn at coreboot.org Sat May 3 16:48:04 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Sat, 3 May 2008 16:48:04 +0200 Subject: [coreboot] r47 - trunk/filo-0.5/i386 Message-ID: Author: stepan Date: 2008-05-03 16:48:04 +0200 (Sat, 03 May 2008) New Revision: 47 Modified: trunk/filo-0.5/i386/sys_info.c Log: those are error messages, not debug Modified: trunk/filo-0.5/i386/sys_info.c =================================================================== --- trunk/filo-0.5/i386/sys_info.c 2008-05-03 14:44:59 UTC (rev 46) +++ trunk/filo-0.5/i386/sys_info.c 2008-05-03 14:48:04 UTC (rev 47) @@ -34,7 +34,7 @@ info->memrange[0].base = 0; info->memrange[0].size = 640*1024; info->memrange[1].base = 1024*1024; - info->memrange[1].size = 32*1024*1024 + info->memrange[1].size = 64*1024*1024 - info->memrange[1].base; } From svn at coreboot.org Sat May 3 17:03:46 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Sat, 3 May 2008 17:03:46 +0200 Subject: [coreboot] r48 - in trunk/filo-0.5: . drivers drivers/flash fs i386 include main Message-ID: Author: stepan Date: 2008-05-03 17:03:45 +0200 (Sat, 03 May 2008) New Revision: 48 Added: trunk/filo-0.5/drivers/flash/ trunk/filo-0.5/drivers/flash/Makefile trunk/filo-0.5/drivers/flash/lxflash.c trunk/filo-0.5/drivers/flash/lxflash.h trunk/filo-0.5/fs/fsys_aboot.c trunk/filo-0.5/i386/artecboot.c trunk/filo-0.5/include/artecboot.h Modified: trunk/filo-0.5/Makefile trunk/filo-0.5/defconfig trunk/filo-0.5/fs/Makefile trunk/filo-0.5/fs/blockdev.c trunk/filo-0.5/fs/filesys.h trunk/filo-0.5/fs/vfs.c trunk/filo-0.5/i386/Makefile trunk/filo-0.5/i386/defconfig trunk/filo-0.5/i386/linux_load.c trunk/filo-0.5/include/fs.h trunk/filo-0.5/include/lib.h trunk/filo-0.5/main/console.c trunk/filo-0.5/main/filo.c Log: trying to merge most of ARTECs tree. Modified: trunk/filo-0.5/Makefile =================================================================== --- trunk/filo-0.5/Makefile 2008-05-03 14:48:04 UTC (rev 47) +++ trunk/filo-0.5/Makefile 2008-05-03 15:03:45 UTC (rev 48) @@ -13,7 +13,8 @@ endif PROGRAM_NAME = FILO -PROGRAM_VERSION = 0.5 +PROGRAM_VERSION = 0.5.5 + BUILD_INFO = ($(shell whoami)@$(shell hostname)) $(shell LANG=C date) # for now: @@ -21,7 +22,7 @@ LIBGCC = $(shell $(CC) -print-libgcc-file-name) -SUBDIRS = main main/grub fs drivers drivers/usb $(ARCH) +SUBDIRS = main main/grub fs drivers drivers/usb drivers/flash $(ARCH) OBJS = $(addsuffix /builtin.o,$(SUBDIRS)) @@ -60,7 +61,7 @@ +$(MAKE) -C $(patsubst _clean_%,%,$@) clean clean: $(SUBDIRS_CLEAN) - rm -f filo.elf filo config.h filo.iso null.o builtin.o + rm -f filo.elf filo config.h filo.iso distclean: clean rm -f Config Config.bak include/arch Modified: trunk/filo-0.5/defconfig =================================================================== --- trunk/filo-0.5/defconfig 2008-05-03 14:48:04 UTC (rev 47) +++ trunk/filo-0.5/defconfig 2008-05-03 15:03:45 UTC (rev 48) @@ -18,6 +18,7 @@ #AUTOBOOT_FILE = "mem at 0xfff80000" #AUTOBOOT_FILE = "hde1 at 0" #AUTOBOOT_FILE = "uda1:/vmlinuz.elf" +#AUTOBOOT_FILE = "flashb at 0x00400000,0x154a00 console=tty0 console=ttyS0,115200" # Time in second before booting AUTOBOOT_FILE AUTOBOOT_DELAY = 2 @@ -45,6 +46,9 @@ # Driver for USB Storage USB_DISK = 1 +# Driver for NAND flash storage +#FLASH_DISK = 1 + # VGA text console VGA_CONSOLE = 1 PC_KEYBOARD = 1 @@ -99,4 +103,7 @@ #DEBUG_IDE = 1 #DEBUG_USB = 1 #DEBUG_ELTORITO = 1 +#DEBUG_FLASH = 1 +#DEBUG_ARTECBOOT = 1 + Added: trunk/filo-0.5/drivers/flash/Makefile =================================================================== --- trunk/filo-0.5/drivers/flash/Makefile (rev 0) +++ trunk/filo-0.5/drivers/flash/Makefile 2008-05-03 15:03:45 UTC (rev 48) @@ -0,0 +1,7 @@ +TOPDIR = ../.. +-include $(TOPDIR)/Config + +OBJS-1 := +OBJS-$(FLASH_DISK) += lxflash.o + +include $(TOPDIR)/makerules Added: trunk/filo-0.5/drivers/flash/lxflash.c =================================================================== --- trunk/filo-0.5/drivers/flash/lxflash.c (rev 0) +++ trunk/filo-0.5/drivers/flash/lxflash.c 2008-05-03 15:03:45 UTC (rev 48) @@ -0,0 +1,824 @@ +/******************************************************************************* + * + * Geode LX CS5536 flash driver + * + * Copyright 2006 Andrei Birjukov and + * Artec Design LLC http://www.artecdesign.ee + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + * + ******************************************************************************/ + +#include +#include +#include +#include "lxflash.h" + +#define DEBUG_THIS DEBUG_FLASH +#include + +//////////////////////////////////////////////////////////////////////////////// +// driver globals + +static FLASH_INFO g_flashInfo; // flash info structure +static uint32_t g_deviceID = 0; // flash memory ID +static uint32_t g_chipID = 0; // chip ID +static uint16_t g_baseAddr = 0; // port mapped controller IO base address + +static uint8_t g_eccTest[MAX_ECC_SIZE]; // used to retrieve/store ECC +static uint8_t g_eccCalc[MAX_ECC_SIZE]; + +static uint32_t g_currentPage = (uint32_t)-1; +static uint8_t g_pageBuf[MAX_PAGE_SIZE]; +static uint8_t *g_pBBT=NULL; + +//////////////////////////////////////////////////////////////////////////////// +// ECC structs and routines + +/* + * Pre-calculated 256-way 1 byte column parity + */ +static const uint8_t nand_ecc_precalc_table[] = { + 0x00, 0x55, 0x56, 0x03, 0x59, 0x0c, 0x0f, 0x5a, 0x5a, 0x0f, 0x0c, 0x59, 0x03, 0x56, 0x55, 0x00, + 0x65, 0x30, 0x33, 0x66, 0x3c, 0x69, 0x6a, 0x3f, 0x3f, 0x6a, 0x69, 0x3c, 0x66, 0x33, 0x30, 0x65, + 0x66, 0x33, 0x30, 0x65, 0x3f, 0x6a, 0x69, 0x3c, 0x3c, 0x69, 0x6a, 0x3f, 0x65, 0x30, 0x33, 0x66, + 0x03, 0x56, 0x55, 0x00, 0x5a, 0x0f, 0x0c, 0x59, 0x59, 0x0c, 0x0f, 0x5a, 0x00, 0x55, 0x56, 0x03, + 0x69, 0x3c, 0x3f, 0x6a, 0x30, 0x65, 0x66, 0x33, 0x33, 0x66, 0x65, 0x30, 0x6a, 0x3f, 0x3c, 0x69, + 0x0c, 0x59, 0x5a, 0x0f, 0x55, 0x00, 0x03, 0x56, 0x56, 0x03, 0x00, 0x55, 0x0f, 0x5a, 0x59, 0x0c, + 0x0f, 0x5a, 0x59, 0x0c, 0x56, 0x03, 0x00, 0x55, 0x55, 0x00, 0x03, 0x56, 0x0c, 0x59, 0x5a, 0x0f, + 0x6a, 0x3f, 0x3c, 0x69, 0x33, 0x66, 0x65, 0x30, 0x30, 0x65, 0x66, 0x33, 0x69, 0x3c, 0x3f, 0x6a, + 0x6a, 0x3f, 0x3c, 0x69, 0x33, 0x66, 0x65, 0x30, 0x30, 0x65, 0x66, 0x33, 0x69, 0x3c, 0x3f, 0x6a, + 0x0f, 0x5a, 0x59, 0x0c, 0x56, 0x03, 0x00, 0x55, 0x55, 0x00, 0x03, 0x56, 0x0c, 0x59, 0x5a, 0x0f, + 0x0c, 0x59, 0x5a, 0x0f, 0x55, 0x00, 0x03, 0x56, 0x56, 0x03, 0x00, 0x55, 0x0f, 0x5a, 0x59, 0x0c, + 0x69, 0x3c, 0x3f, 0x6a, 0x30, 0x65, 0x66, 0x33, 0x33, 0x66, 0x65, 0x30, 0x6a, 0x3f, 0x3c, 0x69, + 0x03, 0x56, 0x55, 0x00, 0x5a, 0x0f, 0x0c, 0x59, 0x59, 0x0c, 0x0f, 0x5a, 0x00, 0x55, 0x56, 0x03, + 0x66, 0x33, 0x30, 0x65, 0x3f, 0x6a, 0x69, 0x3c, 0x3c, 0x69, 0x6a, 0x3f, 0x65, 0x30, 0x33, 0x66, + 0x65, 0x30, 0x33, 0x66, 0x3c, 0x69, 0x6a, 0x3f, 0x3f, 0x6a, 0x69, 0x3c, 0x66, 0x33, 0x30, 0x65, + 0x00, 0x55, 0x56, 0x03, 0x59, 0x0c, 0x0f, 0x5a, 0x5a, 0x0f, 0x0c, 0x59, 0x03, 0x56, 0x55, 0x00 +}; + + +/** + * nand_trans_result - [GENERIC] create non-inverted ECC + * @reg2: line parity reg 2 + * @reg3: line parity reg 3 + * @ecc_code: ecc + * + * Creates non-inverted ECC code from line parity + */ +static void NAND_transResult(uint8_t reg2, uint8_t reg3, + uint8_t *ecc_code) +{ + uint8_t a, b, i, tmp1, tmp2; + + /* Initialize variables */ + a = b = 0x80; + tmp1 = tmp2 = 0; + + /* Calculate first ECC byte */ + for (i = 0; i < 4; i++) { + if (reg3 & a) /* LP15,13,11,9 --> ecc_code[0] */ + tmp1 |= b; + b >>= 1; + if (reg2 & a) /* LP14,12,10,8 --> ecc_code[0] */ + tmp1 |= b; + b >>= 1; + a >>= 1; + } + + /* Calculate second ECC byte */ + b = 0x80; + for (i = 0; i < 4; i++) { + if (reg3 & a) /* LP7,5,3,1 --> ecc_code[1] */ + tmp2 |= b; + b >>= 1; + if (reg2 & a) /* LP6,4,2,0 --> ecc_code[1] */ + tmp2 |= b; + b >>= 1; + a >>= 1; + } + + /* Store two of the ECC bytes */ + ecc_code[0] = tmp1; + ecc_code[1] = tmp2; +} + +/** + * nand_calculate_ecc - [NAND Interface] Calculate 3 byte ECC code for 256 byte block + * @dat: raw data + * @ecc_code: buffer for ECC + */ +int NAND_calculateECC(const uint8_t *dat, uint8_t *ecc_code) +{ + uint8_t idx, reg1, reg2, reg3; + int j; + + /* Initialize variables */ + reg1 = reg2 = reg3 = 0; + ecc_code[0] = ecc_code[1] = ecc_code[2] = 0; + + /* Build up column parity */ + for(j = 0; j < 256; j++) { + + /* Get CP0 - CP5 from table */ + idx = nand_ecc_precalc_table[dat[j]]; + reg1 ^= (idx & 0x3f); + + /* All bit XOR = 1 ? */ + if (idx & 0x40) { + reg3 ^= (uint8_t) j; + reg2 ^= ~((uint8_t) j); + } + } + + /* Create non-inverted ECC code from line parity */ + NAND_transResult(reg2, reg3, ecc_code); + + /* Calculate final ECC code */ + ecc_code[0] = ~ecc_code[0]; + ecc_code[1] = ~ecc_code[1]; + ecc_code[2] = ((~reg1) << 2) | 0x03; + return 0; +} + +/** + * nand_correct_data - [NAND Interface] Detect and correct bit error(s) + * @dat: raw data read from the chip + * @read_ecc: ECC from the chip + * @calc_ecc: the ECC calculated from raw data + * + * Detect and correct a 1 bit error for 256 byte block + */ +int NAND_correctData(uint8_t *dat, uint8_t *read_ecc, uint8_t *calc_ecc) +{ + uint8_t a, b, c, d1, d2, d3, add, bit, i; + + /* Do error detection */ + d1 = calc_ecc[0] ^ read_ecc[0]; + d2 = calc_ecc[1] ^ read_ecc[1]; + d3 = calc_ecc[2] ^ read_ecc[2]; + + if ((d1 | d2 | d3) == 0) { + /* No errors */ + return 0; + } + else { + a = (d1 ^ (d1 >> 1)) & 0x55; + b = (d2 ^ (d2 >> 1)) & 0x55; + c = (d3 ^ (d3 >> 1)) & 0x54; + + /* Found and will correct single bit error in the data */ + if ((a == 0x55) && (b == 0x55) && (c == 0x54)) { + c = 0x80; + add = 0; + a = 0x80; + for (i=0; i<4; i++) { + if (d1 & c) + add |= a; + c >>= 2; + a >>= 1; + } + c = 0x80; + for (i=0; i<4; i++) { + if (d2 & c) + add |= a; + c >>= 2; + a >>= 1; + } + bit = 0; + b = 0x04; + c = 0x80; + for (i=0; i<3; i++) { + if (d3 & c) + bit |= b; + c >>= 2; + b >>= 1; + } + b = 0x01; + a = dat[add]; + a ^= (b << bit); + dat[add] = a; + return 1; + } + else { + i = 0; + while (d1) { + if (d1 & 0x01) + ++i; + d1 >>= 1; + } + while (d2) { + if (d2 & 0x01) + ++i; + d2 >>= 1; + } + while (d3) { + if (d3 & 0x01) + ++i; + d3 >>= 1; + } + if (i == 1) { + /* ECC Code Error Correction */ + read_ecc[0] = calc_ecc[0]; + read_ecc[1] = calc_ecc[1]; + read_ecc[2] = calc_ecc[2]; + return 2; + } + else { + /* Uncorrectable Error */ + return -1; + } + } + } + + /* Should never happen */ + return -1; +} + +//////////////////////////////////////////////////////////////////////////////// +// NAND flash helper functions go here, ported from Windows CE FMD + +//////////////////////////////////////////////////////////////////////////////// +// +// NAND_checkStatus() +// +// Retrieve the status of the Chip. This function accept a loop number, which +// is used to do the loop if chip is not ready. +// +// dwLoops: +// +// 0: no loop +// 0xffffffff: loop forever + +uint8_t NAND_checkStatus(uint32_t dwLoops) +{ + int bStop = (dwLoops != (uint32_t) -1); + uint8_t ucStatus; + int i; + + // There is a 200ns delay (Twb) between the time that the !write-enable line + // (!WE) is asserted and the time the ready (R/!B) line is de-asserted. Generate a + // delay before querrying the status. + for (i=0; i<10; i++) + inb(g_baseAddr + IO_NAND_STS); + + while(TRUE) + { + ucStatus = inb(g_baseAddr + IO_NAND_STS); + + if(((ucStatus & CS_NAND_STS_FLASH_RDY) && // status ready + !(ucStatus & CS_NAND_CTLR_BUSY)) || // controller not busy + (bStop && !dwLoops)) // non-infinite loop and + + break; // we already pay our due + + dwLoops --; + } + + return ucStatus; +} + +//////////////////////////////////////////////////////////////////////////////// +// NAND command helpers + +static __inline void NAND_enableHwECC(int enable) +{ + if(enable) outb(0x07, g_baseAddr + IO_NAND_ECC_CTL); + else outb(0x02, g_baseAddr + IO_NAND_ECC_CTL); +} + +static void NAND_readHwECC(uint8_t *pData) +{ + // read ECC data from status register + pData[0] = inb(g_baseAddr + IO_NAND_ECC_MSB); + pData[1] = inb(g_baseAddr + IO_NAND_ECC_LSB); + pData[2] = inb(g_baseAddr + IO_NAND_ECC_COL); +} + +static __inline void NAND_writeIO(uint8_t b) +{ + outb(b, g_baseAddr + IO_NAND_IO); +} + +static __inline void NAND_writeCTL(uint8_t b) +{ + outb(b, g_baseAddr + IO_NAND_CTL); +} + +static __inline uint8_t NAND_readDataByte() +{ + return inb(g_baseAddr + IO_NAND_DATA); +} + +static void NAND_readData(uint8_t *pData, int nSize) +{ + int i, nDwords = nSize/4; // number of double words + int nBytes = nSize % 4; // leftover stuff + + if(nSize > 528) return; // oversized buffer? + + // read from port mapped registers, + for(i=0; i 528) return; // oversized buffer? + + // write byte by byte, pedestrian way + for(i=0; i> 8) & 0xff); + pa3 = (uint8_t) ((dwPageID >> 16) & 0xff); + // just one column address byte + ca1 = VALIDADDR; + } + // for 2048-byte page size, we need to add some stuff + else if(g_flashInfo.dataBytesPerPage == PAGE_SIZE_2048) + { + // three page address bytes + pa1 = (uint8_t) (dwPageID & 0xff); + pa2 = (uint8_t) ((dwPageID >> 8) & 0xff); + pa3 = (uint8_t) ((dwPageID >> 16) & 0xff); + // two column address bytes + ca1 = 0x0000; + ca2 = 0x0008; // point to the 2048-th byte + } + // unsupported page size + else return TRUE; + + // For our NAND flash, we don't have to issue two read command. We just need + // to issue one read command and do contiquous read + + NAND_writeCTL(0x00); // enable chip + NAND_checkStatus((uint32_t) -1); // check ready + + // Check the first page. + NAND_writeCTL(CS_NAND_CTL_CLE); // latch command + + if(g_flashInfo.dataBytesPerPage == PAGE_SIZE_2048) + NAND_writeIO(CMD_READ); // send read command + else NAND_writeIO(CMD_READ2); // send read command 2 + NAND_writeCTL(CS_NAND_CTL_ALE); // latch address + NAND_writeIO(ca1); // send Column Address 1 + + if(g_flashInfo.dataBytesPerPage == PAGE_SIZE_2048) + NAND_writeIO(ca2); // send Column Address 2 + + NAND_writeIO(pa1); // send Page Address 1 + NAND_writeIO(pa2); // send Page Address 2 + NAND_writeIO(pa3); // send Page Address 3 + NAND_writeCTL(0x00); // select chip + + if(g_flashInfo.dataBytesPerPage == PAGE_SIZE_2048) + { + NAND_writeCTL(CS_NAND_CTL_CLE); // latch command + NAND_writeIO(CMD_READ_2K); // send read command + NAND_writeCTL(0x00); // select chip + } + + NAND_checkStatus((uint32_t) -1); // check ready + + bData = NAND_readDataByte(); // read out the bad block marker + if(bData != 0xff) // no bits may be zeroed + { + debug("bad block found at address 0x%x\n", blockID); + NAND_writeCTL(CS_NAND_CTL_CE); // disable chip + return TRUE; + } + + NAND_writeCTL(CS_NAND_CTL_CE); // disable chip + return FALSE; +} + +//////////////////////////////////////////////////////////////////////////////// +// + +__inline int IsECCWritten(uint8_t *pECC) +{ + // FIXME: check only 6 first bytes + static uint8_t abNoECC[] = {0xff,0xff,0xff,0xff,0xff,0xff}; + return (memcmp(pECC, abNoECC, sizeof(abNoECC)) != 0); +} + +//////////////////////////////////////////////////////////////////////////////// +// + +int NAND_initChip(int chipNum) +{ + msr_t msr; + + memset(&g_flashInfo, 0, sizeof(g_flashInfo)); + + g_chipID = chipNum; + + /////////////////////////////////////////////////////////////////////////////////// + // init the MSR_DIVIL_BALL_OPTS register, enable flash mode + + msr = rdmsr(MSR_DIVIL_BALL_OPTS); + msr.lo &= ~PIN_OPT_IDE; + wrmsr(MSR_DIVIL_BALL_OPTS, msr); + msr = rdmsr(MSR_DIVIL_BALL_OPTS); + debug("MSR_DIVIL_BALL_OPTS = 0x%08x 0x%08x\n", msr.hi, msr.lo); + + /////////////////////////////////////////////////////////////////////////////////// + // init the MSR_DIVIL_LBAR_FLSHx register, I/O mapped mode, set base address + + msr.hi = SET_FLSH_HIGH; + msr.lo = SET_FLSH_LOW; + wrmsr(MSR_DIVIL_LBAR_FLSH0 + g_chipID, msr); + g_baseAddr = SET_FLSH_LOW; // set the IO base address + + // read the register back + msr = rdmsr(MSR_DIVIL_LBAR_FLSH0 + g_chipID); + debug("MSR_DIVIL_LBAR_FLSH%d = 0x%08x 0x%08x\n", (int)g_chipID, msr.hi, msr.lo); + + /////////////////////////////////////////////////////////////////////////////////// + // init the MSR_NANDF_DATA NAND timing register + + msr.hi = 0; + msr.lo = SET_NANDF_DATA_LOW; + wrmsr(MSR_NANDF_DATA, msr); + + msr = rdmsr(MSR_NANDF_DATA); + debug("MSR_NANDF_DATA = 0x%08x 0x%08x\n", msr.hi, msr.lo); + + /////////////////////////////////////////////////////////////////////////////////// + // init the MSR_NANDF_CTL NAND timing register + + msr.hi = 0; + msr.lo = SET_NANDF_CTL_LOW; + wrmsr(MSR_NANDF_CTL, msr); + + msr = rdmsr(MSR_NANDF_CTL); + debug("MSR_NANDF_CTL = 0x%08x 0x%08x\n", msr.hi, msr.lo); + + // read out flash chip ID + g_deviceID = NAND_readFlashID(); + + switch(g_deviceID) // allow only known flash chips + { + case SAMSUNG_NAND_64MB: + case SST_NAND_64MB: + + g_flashInfo.numBlocks = 4096; + g_flashInfo.pagesPerBlock = 32; + g_flashInfo.dataBytesPerPage = 512; + g_flashInfo.flashType = FLASH_NAND; + + break; + + case SST_NAND_512MB: + + g_flashInfo.numBlocks = 4096; + g_flashInfo.pagesPerBlock = 64; + g_flashInfo.dataBytesPerPage = 2048; + g_flashInfo.flashType = FLASH_NAND; + + break; + + default: + printf("Unsupported flash chip ID: %x\n", g_deviceID); + return -1; + } + + g_flashInfo.bytesPerBlock = g_flashInfo.dataBytesPerPage * g_flashInfo.pagesPerBlock; + + if(!g_pBBT) g_pBBT = malloc(g_flashInfo.numBlocks); + if(!g_pBBT) + { + printf("Could not allocate bad block table\n"); + return -1; + } + + debug("bad block table allocated, size %d\n", g_flashInfo.numBlocks); + memset(g_pBBT, BLOCK_UNKNOWN, g_flashInfo.numBlocks); + + printf("Geode LX flash driver initialized, device ID 0x%x\n", g_deviceID); + debug("FlashChip = 0x%x\n", g_chipID); + debug("NumBlocks = 0x%x\n", g_flashInfo.numBlocks); + debug("PagesPerBlock = 0x%x\n", g_flashInfo.pagesPerBlock); + debug("BytesPerPage = 0x%x\n", g_flashInfo.dataBytesPerPage); + debug("FlashType = %s\n", g_flashInfo.flashType == FLASH_NAND ? "NAND" : "NOR"); + return 0; +} + +//////////////////////////////////////////////////////////////////////////////// +// +// NAND_readPage +// +// Read the content of the sector. +// +// startSectorAddr: Starting page address +// pSectorBuff : Buffer for the data portion + +int NAND_readPage(uint32_t pageAddr, uint8_t *pPageBuff) +{ + if (!pPageBuff) + { + debug("Invalid parameters!\n"); + return ERROR_BAD_PARAMS; + } + + // sanity check + if (pageAddr < (g_flashInfo.numBlocks * g_flashInfo.pagesPerBlock)) + { + uint8_t bData = 0, bBadBlock = 0, bReserved = 0; + + uint8_t addr1 = (uint8_t)(pageAddr & 0xff); + uint8_t addr2 = (uint8_t)((pageAddr >> 8) & 0xff); + uint8_t addr3 = (uint8_t)((pageAddr >> 16) & 0xff); + + uint16_t eccSize = 0; // total ECC size + uint32_t pageSize = 0; + + NAND_writeCTL(0x00); // enable chip + NAND_checkStatus((uint32_t)-1); // check ready + + NAND_writeCTL(CS_NAND_CTL_CLE); // latch command + NAND_writeIO(CMD_READ); // send read command + NAND_writeCTL(CS_NAND_CTL_ALE); // latch address + NAND_writeIO(0x00); // send Column Address 1 + + if(g_flashInfo.dataBytesPerPage == PAGE_SIZE_2048) + NAND_writeIO(0x00); // send Column Address 2 + + NAND_writeIO(addr1); // send Page Address 1 + NAND_writeIO(addr2); // send Page Address 2 + NAND_writeIO(addr3); // send Page Address 3 + NAND_writeCTL(0x00); // select chip + + if(g_flashInfo.dataBytesPerPage == PAGE_SIZE_2048) + { + NAND_writeCTL(CS_NAND_CTL_CLE); // latch command + NAND_writeIO(CMD_READ_2K); // send read command + NAND_writeCTL(0x00); // select chip + } + + NAND_checkStatus((uint32_t) -1); // check ready + + while(pageSize < g_flashInfo.dataBytesPerPage) + { + // read out the first half of page data + NAND_enableHwECC(1); // enable HW ECC calculation + NAND_readData(&pPageBuff[pageSize], READ_BLOCK_SIZE); + NAND_readHwECC(&g_eccCalc[pageSize / READ_BLOCK_SIZE * 3]); + // update counters too + pageSize += READ_BLOCK_SIZE; + eccSize += 3; + } + + debug("read %d bytes from page address %x\n", pageSize, pageAddr); + NAND_enableHwECC(0); // disable HW ECC + + // Now read the spare area data + + if(g_flashInfo.dataBytesPerPage == PAGE_SIZE_512) + { + // Read the ECC info according to Linux MTD format, first part + NAND_readData(g_eccTest, 4); + + bBadBlock = NAND_readDataByte(); // bad block byte + bReserved = NAND_readDataByte(); // reserved byte + // Read the ECC info according to Linux MTD format, second part + NAND_readData(&g_eccTest[4], 2); + + // calculate the first part of ECC, use software method + //NAND_calculateECC(&pPageBuff[0], &g_eccCalc[0]); + // calculate the second part of ECC, use software method + //NAND_calculateECC(&pPageBuff[256], &g_eccCalc[3]); + } + else if(g_flashInfo.dataBytesPerPage == PAGE_SIZE_2048) + { + int i; + for(i=0; i<40; i++) NAND_readDataByte(); // skip stuff + // Read the ECC info according to Linux MTD format (2048 byte page) + NAND_readData(g_eccTest, eccSize); + } + + // test the data integrity; if the data is invalid, attempt to fix it using ECC + if(memcmp(g_eccCalc, g_eccTest, eccSize)) + { + int nRet = 0; + + // If the ECC is all 0xff, then it probably hasn't been written out yet + // because the data hasn't been written, so ignore the invalid ECC. + if(!IsECCWritten(g_eccTest)) + { + debug("No ECC detected at page 0x%x\n", pageAddr); + NAND_writeCTL(CS_NAND_CTL_CE); // disable chip + return ERROR_NO_ECC; + } + + debug("Page data (page 0x%x) is invalid. Attempting ECC to fix it.\n", pageAddr); + nRet = NAND_correctData(&pPageBuff[0], &g_eccTest[0], &g_eccCalc[0]); + if(nRet == -1) + { + debug("ERROR - page data (page 0x%x, first part) Unable to correct invalid data!\n", pageAddr); + NAND_writeCTL(CS_NAND_CTL_CE); // disable chip + return ERROR_ECC_ERROR1; + } + else if(nRet == 0) debug("No errors detected (page 0x%x, first part)\n", pageAddr); + else debug("Invalid data (page 0x%x, first part) was corrected using ECC!\n", pageAddr); + + // now do the second part + nRet = NAND_correctData(&pPageBuff[256], &g_eccTest[3], &g_eccCalc[3]); + if(nRet == -1) + { + debug("ERROR - page data (page 0x%x, second part) Unable to correct invalid data!\n", pageAddr); + NAND_writeCTL(CS_NAND_CTL_CE); // disable chip + return ERROR_ECC_ERROR2; + } + else if(nRet == 0) debug("No errors detected (page 0x%x, second part)\n", pageAddr); + else debug("Invalid data (page 0x%x, second part) was corrected using ECC!\n", pageAddr); + } + } + else + { + debug("Page address [%d] is too large\n", pageAddr); + return ERROR_BAD_ADDRESS; + } + + NAND_writeCTL(CS_NAND_CTL_CE); // disable chip + return ERROR_SUCCESS; +} + +//////////////////////////////////////////////////////////////////////////////// +// FILO interface functions + +int flash_probe(int drive) +{ + debug("drive %d\n", drive); + return NAND_initChip(drive); +} + +//////////////////////////////////////////////////////////////////////////////// + +int flash_read(int drive, sector_t sector, void *buffer) +{ + int block, nRet; + uint32_t pageAddress = sector * DEV_SECTOR_SIZE / g_flashInfo.dataBytesPerPage; + uint32_t pageOffset = sector * DEV_SECTOR_SIZE % g_flashInfo.dataBytesPerPage; + + // sanity check + if(!g_pBBT || !g_flashInfo.pagesPerBlock) + { + debug("error: NAND not initialized\n"); + return -1; + } + + // check that the page ID is valid + if(pageAddress >= (g_flashInfo.numBlocks * g_flashInfo.pagesPerBlock)) + { + debug("error: sector offset %x out of range\n", sector); + return -2; + } + + // get block address + block = pageAddress / g_flashInfo.pagesPerBlock; + + debug("drive %d, sector %d -> page %d + %d, buffer 0x%08x\n", + drive, (unsigned int)sector, pageAddress, pageOffset, (unsigned int)buffer); + + // get the block status first + if(g_pBBT[block] == BLOCK_UNKNOWN) + { + debug("checking block 0x%x status for BBT\n", block); + g_pBBT[block] = NAND_isBlockBad(block) ? BLOCK_BAD : BLOCK_GOOD; + } + + // return failure immediately if the block is bad + if(g_pBBT[block] == BLOCK_BAD) + { + debug("error: block %x is bad\n", block); + return -3; + } + + // check if we have just read that page + if(g_currentPage == pageAddress) + { + // should use cache instead + memcpy(buffer, g_pageBuf + pageOffset, DEV_SECTOR_SIZE); + return ERROR_SUCCESS; + } + + // otherwise proceed with normal reading + nRet = NAND_readPage(pageAddress, g_pageBuf); + memcpy(buffer, g_pageBuf + pageOffset, DEV_SECTOR_SIZE); + + return nRet; +} Added: trunk/filo-0.5/drivers/flash/lxflash.h =================================================================== --- trunk/filo-0.5/drivers/flash/lxflash.h (rev 0) +++ trunk/filo-0.5/drivers/flash/lxflash.h 2008-05-03 15:03:45 UTC (rev 48) @@ -0,0 +1,155 @@ +#ifndef LXFLASH_H +#define LXFLASH_H + +#define TRUE 1 // hmm that's quite obvious :) +#define FALSE 0 + +typedef struct msr_struct +{ + unsigned lo; + unsigned hi; +} msr_t; + +static inline msr_t rdmsr(unsigned index) +{ + msr_t result; + __asm__ __volatile__ ( + "rdmsr" + : "=a" (result.lo), "=d" (result.hi) + : "c" (index) + ); + return result; +} + +static inline void wrmsr(unsigned index, msr_t msr) +{ + __asm__ __volatile__ ( + "wrmsr" + : /* No outputs */ + : "c" (index), "a" (msr.lo), "d" (msr.hi) + ); +} + +typedef struct _FLASH_INFO +{ + unsigned long numBlocks; + unsigned long bytesPerBlock; + unsigned short pagesPerBlock; + unsigned short dataBytesPerPage; + unsigned short flashType; +} FLASH_INFO; + +// NAND flash controller MSR registers + +#define MSR_DIVIL_LBAR_FLSH0 0x51400010 // Flash Chip Select 0 +#define MSR_DIVIL_LBAR_FLSH1 0x51400011 // Flash Chip Select 1 +#define MSR_DIVIL_LBAR_FLSH2 0x51400012 // Flash Chip Select 2 +#define MSR_DIVIL_LBAR_FLSH3 0x51400013 // Flash Chip Select 3 + +#define MSR_DIVIL_BALL_OPTS 0x51400015 +#define PIN_OPT_IDE (1UL<<0) // 0 for flash, 1 for IDE + +#define MSR_NANDF_DATA 0x5140001B +#define MSR_NANDF_CTL 0x5140001C + +// Intended value for LBAR_FLSHx: enabled, PIO, NAND, @0xC000 + +#define SET_FLSH_HIGH 0x0000FFF3 +#define SET_FLSH_LOW 0x0000C000 +#define SET_NANDF_DATA_LOW 0x01200120 +#define SET_NANDF_CTL_LOW 0x00000120 + +// ThinCan defaults + +#define PAGE_SIZE_512 512 +#define PAGE_SIZE_2048 2048 +#define MAX_PAGE_SIZE 2048 +#define MAX_ECC_SIZE 24 +#define READ_BLOCK_SIZE 256 + +// VALIDADDR is 5 << 8 +// +// Explain: 5 means the 6th byte in spare area (517 byte in the page) +// Shift 8 bit to the left to form the correct address for 16bit port +// +#define VALIDADDR 0x05 +#define OEMADDR 0x04 // 5th byte in spare area + +// NAND Flash Command. This appears to be generic across all NAND flash chips + +#define CMD_READ 0x00 // Read +#define CMD_READ1 0x01 // Read1 +#define CMD_READ2 0x50 // Read2 +#define CMD_READID 0x90 // ReadID +#define CMD_READID2 0x91 // Read extended ID +#define CMD_WRITE 0x80 // Write phase 1 +#define CMD_WRITE2 0x10 // Write phase 2 +#define CMD_ERASE 0x60 // Erase phase 1 +#define CMD_ERASE2 0xd0 // Erase phase 2 +#define CMD_STATUS 0x70 // Status read +#define CMD_RESET 0xff // Reset +#define CMD_READ_2K 0x30 // Second cycle read cmd for 2KB flash + +// Registers within the NAND flash controller BAR -- memory mapped + +#define MM_NAND_DATA 0x00 // 0 to 0x7ff, in fact +#define MM_NAND_CTL 0x800 // Any even address 0x800-0x80e +#define MM_NAND_IO 0x801 // Any odd address 0x801-0x80f +#define MM_NAND_STS 0x810 +#define MM_NAND_ECC_LSB 0x811 +#define MM_NAND_ECC_MSB 0x812 +#define MM_NAND_ECC_COL 0x813 +#define MM_NAND_LAC 0x814 +#define MM_NAND_ECC_CTL 0x815 + +// Registers within the NAND flash controller BAR -- I/O mapped + +#define IO_NAND_DATA 0x00 // 0 to 3, in fact +#define IO_NAND_CTL 0x04 +#define IO_NAND_IO 0x05 +#define IO_NAND_STS 0x06 +#define IO_NAND_ECC_CTL 0x08 +#define IO_NAND_ECC_LSB 0x09 +#define IO_NAND_ECC_MSB 0x0a +#define IO_NAND_ECC_COL 0x0b +#define IO_NAND_LAC 0x0c + +#define CS_NAND_CTL_DIST_EN (1<<4) // Enable NAND Distract interrupt +#define CS_NAND_CTL_RDY_INT_MASK (1<<3) // Enable RDY/BUSY# interrupt +#define CS_NAND_CTL_ALE (1<<2) +#define CS_NAND_CTL_CLE (1<<1) +#define CS_NAND_CTL_CE (1<<0) // Keep low; 1 to reset + +#define CS_NAND_STS_FLASH_RDY (1<<3) +#define CS_NAND_CTLR_BUSY (1<<2) +#define CS_NAND_CMD_COMP (1<<1) +#define CS_NAND_DIST_ST (1<<0) + +#define CS_NAND_ECC_PARITY (1<<2) +#define CS_NAND_ECC_CLRECC (1<<1) +#define CS_NAND_ECC_ENECC (1<<0) + +// Status bit pattern, read from chip register + +#define STATUS_READY 0x40 // Ready +#define STATUS_ERROR 0x01 // Error + +#define FLASH_NOR 0 +#define FLASH_NAND 1 + +#define SAMSUNG_NAND_64MB 0xc0a576ec +#define SST_NAND_64MB 0x76207620 +#define SST_NAND_512MB 0x9580dc20 + +#define ERROR_SUCCESS 0 +#define ERROR_BAD_PARAMS -1 +#define ERROR_ECC_ERROR1 1 +#define ERROR_ECC_ERROR2 2 +#define ERROR_BAD_ADDRESS 3 +#define ERROR_NO_ECC 4 + +#define BLOCK_UNKNOWN 0 +#define BLOCK_BAD 2 +#define BLOCK_GOOD 1 + +#endif Modified: trunk/filo-0.5/fs/Makefile =================================================================== --- trunk/filo-0.5/fs/Makefile 2008-05-03 14:48:04 UTC (rev 47) +++ trunk/filo-0.5/fs/Makefile 2008-05-03 15:03:45 UTC (rev 48) @@ -14,5 +14,6 @@ OBJS-$(FSYS_CRAMFS) += mini_inflate.o OBJS-$(FSYS_SQUASHFS) += fsys_squashfs.o OBJS-$(FSYS_SQUASHFS) += squashfs_zlib.o +OBJS-$(ARTEC_BOOT) += fsys_aboot.o include $(TOPDIR)/makerules Modified: trunk/filo-0.5/fs/blockdev.c =================================================================== --- trunk/filo-0.5/fs/blockdev.c 2008-05-03 14:48:04 UTC (rev 47) +++ trunk/filo-0.5/fs/blockdev.c 2008-05-03 15:03:45 UTC (rev 48) @@ -5,8 +5,9 @@ #define DEBUG_THIS DEBUG_BLOCKDEV #include -#define NUM_CACHE 64 -static unsigned char buf_cache[NUM_CACHE][512]; +#define NUM_CACHE 64 + +static unsigned char buf_cache[NUM_CACHE][DEV_SECTOR_SIZE]; static unsigned long cache_sect[NUM_CACHE]; static char dev_name[256]; @@ -44,7 +45,7 @@ unsigned char start_sect[4]; /* unaligned little endian */ unsigned char nr_sects[4]; /* ditto */ } *p; - unsigned char buf[512]; + unsigned char buf[DEV_SECTOR_SIZE]; /* PC partition probe */ if (!devread(0, 0, sizeof(buf), buf)) { @@ -53,7 +54,7 @@ } if (!has_pc_part_magic(buf)) { debug("pc partition magic number not found\n"); - //debug_hexdump(buf, 512); + //debug_hexdump(buf, DEV_SECTOR_SIZE); return PARTITION_UNKNOWN; } p = (struct pc_partition *) (buf + 0x1be); @@ -151,6 +152,16 @@ } *drive = *name - 'a'; name++; + } + else if (memcmp(name, "flash", 5) == 0) { + *type = DISK_FLASH; + name += 5; + if (*name < 'a' || *name > 'z') { + printf("Invalid flash chip\n"); + return 0; + } + *drive = *name - 'a'; + name++; } else if (memcmp(name, "mem", 3) == 0) { *type = DISK_MEM; name += 3; @@ -198,13 +209,13 @@ } /* Do simple sanity check first */ - if (offset & 0x1ff) { - printf("Device offset must be multiple of 512\n"); + if (offset & DEV_SECTOR_MASK) { + printf("Device offset must be multiple of %d\n", DEV_SECTOR_SIZE); return 0; } - if (length & 0x1ff) { - printf("WARNING: length is rounded up to multiple of 512\n"); - length = (length + 0x1ff) & ~0x1ff; + if (length & DEV_SECTOR_MASK) { + printf("WARNING: length is rounded up to multiple of %d\n", DEV_SECTOR_SIZE); + length = (length + DEV_SECTOR_MASK) & ~DEV_SECTOR_MASK; } switch (type) { @@ -226,11 +237,24 @@ disk_size = (uint32_t) -1; /* FIXME */ break; #endif - case DISK_MEM: - disk_size = 1 << (32 - 9); /* 4GB/512-byte */ + +#ifdef FLASH_DISK + case DISK_FLASH: + if(flash_probe(drive) != 0) + { + debug("failed to open flash\n"); + return 0; + } + disk_size = (uint32_t) -1; /* FIXME */ + break; +#endif + + case DISK_MEM: + disk_size = 1 << (32 - DEV_SECTOR_BITS); /* 4GB/512-byte */ break; - default: - printf("Unknown device type %d\n", type); + + default: + printf("Unknown device type %d\n", type); return 0; } @@ -265,21 +289,21 @@ } if (offset) { - if (offset >= (uint64_t) part_length << 9) { + if (offset >= (uint64_t) part_length << DEV_SECTOR_BITS) { printf("Device offset is too high\n"); return 0; } - part_start += offset >> 9; - part_length -= offset >> 9; + part_start += offset >> DEV_SECTOR_BITS; + part_length -= offset >> DEV_SECTOR_BITS; debug("after offset: start %lu, length %lu\n", part_start, part_length); } if (length) { - if (length > (uint64_t) part_length << 9) { + if (length > (uint64_t) part_length << DEV_SECTOR_BITS) { printf("Specified length exceeds the size of device\n"); return 0; } - part_length = length >> 9; + part_length = length >> DEV_SECTOR_BITS; debug("after length: length %lu\n", part_length); using_devsize = 0; } @@ -297,7 +321,7 @@ /* If reading memory, just return the memory as the buffer */ if (dev_type == DISK_MEM) { - unsigned long phys = sector << 9; + unsigned long phys = sector << DEV_SECTOR_BITS; //debug("mem: %#lx\n", phys); return phys_to_virt(phys); } @@ -315,11 +339,19 @@ break; #endif #ifdef USB_DISK - case DISK_USB: - if (usb_read(dev_drive, sector, buf) != 0) - goto readerr; - break; + case DISK_USB: + if (usb_read(dev_drive, sector, buf) != 0) + goto readerr; + break; #endif + +#ifdef FLASH_DISK + case DISK_FLASH: + if (flash_read(dev_drive, sector, buf) != 0) + return 0; + break; +#endif + default: printf("read_sector: device not open\n"); return 0; Modified: trunk/filo-0.5/fs/filesys.h =================================================================== --- trunk/filo-0.5/fs/filesys.h 2008-05-03 14:48:04 UTC (rev 47) +++ trunk/filo-0.5/fs/filesys.h 2008-05-03 15:03:45 UTC (rev 48) @@ -182,6 +182,12 @@ int squashfs_dir (char *dirname); #endif +#ifdef ARTEC_BOOT +int aboot_mount (void); +int aboot_read (char *buf, int len); +int aboot_dir (char *dirname); +#endif + /* This is not a flag actually, but used as if it were a flag. */ #define PC_SLICE_TYPE_HIDDEN_FLAG 0x10 Added: trunk/filo-0.5/fs/fsys_aboot.c =================================================================== --- trunk/filo-0.5/fs/fsys_aboot.c (rev 0) +++ trunk/filo-0.5/fs/fsys_aboot.c 2008-05-03 15:03:45 UTC (rev 48) @@ -0,0 +1,184 @@ +#ifdef ARTEC_BOOT + +/******************************************************************************* + * + * FILO Artecboot Virtual File System + * + * Copyright 2006 Andrei Birjukov and + * Artec Design LLC http://www.artecdesign.ee + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + * + ******************************************************************************/ + +#include +#include +#include + +#include "artecboot.h" +#include "shared.h" +#include "filesys.h" + +#define DEBUG_THIS DEBUG_ARTECBOOT +#include + +static ARTECBOOT_HEADER bootHdr; +static uint32_t fileStart = 0; + +// device read helper, calls the block device read function +// returns number of bytes parsed fthe stream + +int aboot_devread(char* pData, int nSize) +{ + char sectorBuf[DEV_SECTOR_SIZE]; + uint32_t len, total=0; + int failCount = 128; + + uint32_t sector = (fileStart + filepos) >> DEV_SECTOR_BITS; + uint32_t byteOffset = (fileStart + filepos) & DEV_SECTOR_MASK; + + debug("file start %x, sector %x, offset %d\n", fileStart, sector, byteOffset); + + if (sector + ((nSize + DEV_SECTOR_MASK) >> DEV_SECTOR_BITS) > part_length) + { + printf("Error: read outside of device device/partition\n"); + debug("sector=%lu, partition size=%lu, read length=%lu\n", + (unsigned long)sector, (unsigned long)part_length, (unsigned long)nSize); + return 0; + } + + while (nSize > 0) + { + if (!devread(sector, 0, DEV_SECTOR_SIZE, sectorBuf)) + { + debug("sector 0x%x read failed\n", sector); + // do not abort immediately, try some more + if((failCount --) == 0) return 0; + + sector ++; // try the next sector + total += DEV_SECTOR_SIZE; + continue; + } + + len = SECTOR_SIZE - byteOffset; + if (len > nSize) + len = nSize; + memcpy(pData, sectorBuf + byteOffset, len); + + sector ++; + byteOffset = 0; + + nSize -= len; + pData += len; + total += len; + } + + // return number of bytes read from the stream + return total; +} + +int aboot_mount(void) +{ + debug("Mounting Artecboot VFS...\n"); + // clear the boot header + memset(&bootHdr, 0, sizeof(bootHdr)); + + fileStart = 0; + filepos = 0; + + // now read out the boot header + if(aboot_devread((char*)&bootHdr, sizeof(ARTECBOOT_HEADER)) < sizeof(ARTECBOOT_HEADER)) + { + debug("Boot error: failed reading the boot image header\n"); + return 0; + } + + // check whether the flash data is valid at all + if(bootHdr.magicHeader != ARTECBOOT_HEADER_MAGIC) + { + debug("No Artecboot signature found, aborting\n"); + return 0; + } + + // check the version number + if(bootHdr.bootVersion > CURRENT_VERSION) + { + debug("Boot error: incompatible version number: %x\n", bootHdr.bootVersion); + return 0; + } + + // align the partition length to the sector size + part_length = ((bootHdr.imageSize - 1) >> DEV_SECTOR_BITS) + 1; + return 1; +} + +int aboot_read(char *buf, int len) +{ + int read; + // sanity check + if(bootHdr.magicHeader != ARTECBOOT_HEADER_MAGIC) return 0; + debug("reading %d bytes to %x...\n", len, (unsigned int)buf); + + read = aboot_devread(buf, len); + filepos += read; // advance current position + + debug("read %d bytes, pos %x\n", read, filepos); + + // returned length may be greater than requested size because of skipped bad blocks + if(read >= len) return len; + return 0; +} + +int aboot_dir(char *dirname) +{ + int nRet = 0; + // sanity check + if(bootHdr.magicHeader != ARTECBOOT_HEADER_MAGIC) return 0; + + // we can only recognize certain hardcoded filenames + if(!strcmp(dirname, ABOOT_FILE_HEADER)) + { + filepos = 0; + fileStart = 0; + filemax = sizeof(ARTECBOOT_HEADER); + nRet = 1; + } + else if(!strcmp(dirname, ABOOT_FILE_KERNEL)) + { + filepos = 0; + fileStart = bootHdr.kernelStart; + filemax = bootHdr.kernelSize; + nRet = 1; + } + else if(!strcmp(dirname, ABOOT_FILE_INITRD)) + { + filepos = 0; + fileStart = bootHdr.initrdStart; + filemax = bootHdr.initrdSize; + nRet = 1; + } + else + { + // unknown file + filepos = 0; + filemax = 0; + nRet = 0; + } + + debug("open file: %s, size %d, dev start %x\n", dirname, filemax, fileStart); + return nRet; +} + +#endif Modified: trunk/filo-0.5/fs/vfs.c =================================================================== --- trunk/filo-0.5/fs/vfs.c 2008-05-03 14:48:04 UTC (rev 47) +++ trunk/filo-0.5/fs/vfs.c 2008-05-03 15:03:45 UTC (rev 48) @@ -25,33 +25,37 @@ struct fsys_entry fsys_table[] = { # ifdef FSYS_FAT - {"fat", fat_mount, fat_read, fat_dir, 0, 0}, + {"FAT filesystem", fat_mount, fat_read, fat_dir, 0, 0}, # endif # ifdef FSYS_EXT2FS - {"ext2fs", ext2fs_mount, ext2fs_read, ext2fs_dir, 0, 0}, + {"EXT2 filesystem", ext2fs_mount, ext2fs_read, ext2fs_dir, 0, 0}, # endif # ifdef FSYS_MINIX - {"minix", minix_mount, minix_read, minix_dir, 0, 0}, + {"MINIX filesystem", minix_mount, minix_read, minix_dir, 0, 0}, # endif # ifdef FSYS_REISERFS - {"reiserfs", reiserfs_mount, reiserfs_read, reiserfs_dir, 0, + {"REISERFS filesystem", reiserfs_mount, reiserfs_read, reiserfs_dir, 0, reiserfs_embed}, # endif # ifdef FSYS_JFS - {"jfs", jfs_mount, jfs_read, jfs_dir, 0, jfs_embed}, + {"JFS filesystem", jfs_mount, jfs_read, jfs_dir, 0, jfs_embed}, # endif # ifdef FSYS_XFS - {"xfs", xfs_mount, xfs_read, xfs_dir, 0, 0}, + {"XFS filesystem", xfs_mount, xfs_read, xfs_dir, 0, 0}, # endif # ifdef FSYS_ISO9660 - {"iso9660", iso9660_mount, iso9660_read, iso9660_dir, 0, 0}, + {"ISO9660 filesystem", iso9660_mount, iso9660_read, iso9660_dir, 0, 0}, # endif # ifdef FSYS_CRAMFS - {"cramfs", cramfs_mount, cramfs_read, cramfs_dir, 0, 0}, + {"CRAM filesystem", cramfs_mount, cramfs_read, cramfs_dir, 0, 0}, # endif # ifdef FSYS_SQUASHFS - {"squashfs", squashfs_mount, squashfs_read, squashfs_dir, 0, 0}, + {"SQUASH filesystem", squashfs_mount, squashfs_read, squashfs_dir, 0, 0}, # endif +# ifdef ARTEC_BOOT + {"Artecboot Virtual Filesystem", aboot_mount, aboot_read, aboot_dir, 0, 0}, +# endif + }; /* NULLFS is used to read images from raw device */ @@ -172,11 +176,14 @@ if (len < 0 || len > filemax-filepos) len = filemax - filepos; errnum = 0; - return fsys->read_func(buf, len); + + debug("reading %d bytes, offset 0x%x\n", len, filepos); + return fsys->read_func(buf, len); } int file_seek(unsigned long offset) { + debug("seeking to 0x%x\n", offset); filepos = offset; return filepos; } @@ -186,6 +193,13 @@ return filemax; } +void file_set_size(unsigned long size) +{ + debug("updating file size to %d bytes\n", size); + filemax = size; + using_devsize = 0; +} + void file_close(void) { } Modified: trunk/filo-0.5/i386/Makefile =================================================================== --- trunk/filo-0.5/i386/Makefile 2008-05-03 14:48:04 UTC (rev 47) +++ trunk/filo-0.5/i386/Makefile 2008-05-03 15:03:45 UTC (rev 48) @@ -4,5 +4,6 @@ OBJS-1 := context.o switch.o segment.o timer.o sys_info.o OBJS-$(LINUX_LOADER) += linux_load.o OBJS-$(MULTIBOOT_IMAGE) += multiboot.o +OBJS-$(ARTEC_BOOT) += artecboot.o include $(TOPDIR)/makerules Added: trunk/filo-0.5/i386/artecboot.c =================================================================== --- trunk/filo-0.5/i386/artecboot.c (rev 0) +++ trunk/filo-0.5/i386/artecboot.c 2008-05-03 15:03:45 UTC (rev 48) @@ -0,0 +1,154 @@ +/******************************************************************************* + * + * FILO Artecboot loader, enables multiboot through custom header + * + * Copyright 2006 Andrei Birjukov and + * Artec Design LLC http://www.artecdesign.ee + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + * + ******************************************************************************/ + +#include +#include +#include +#include "artecboot.h" +#include "../fs/filesys.h" + +#define DEBUG_THIS DEBUG_ARTECBOOT +#include + +static ARTECBOOT_HEADER bootHdr; + +int artecboot_load(struct sys_info *info, const char *file, const char *cmdline) +{ + int i; + + printf("Starting the Artecboot loader...\n"); + // clear the boot header + memset(&bootHdr, 0, sizeof(bootHdr)); + + // try opening the boot parameter file + if (!file_open(file)) + { + printf("Boot error: failed to open image file: %s\n", file); + return LOADER_NOT_SUPPORT; + } + + file_seek(0); // seek to the beginning of the parameter file + + // now read out the boot header + if(file_read(&bootHdr, sizeof(ARTECBOOT_HEADER)) != sizeof(ARTECBOOT_HEADER)) + { + printf("Boot error: failed reading the boot image header\n"); + return LOADER_NOT_SUPPORT; + } + + // check whether the parameter data is valid at all + if(bootHdr.magicHeader != ARTECBOOT_HEADER_MAGIC) + { + debug("No Artecboot signature found, aborting\n"); + return LOADER_NOT_SUPPORT; + } + + // check the version number + if(bootHdr.bootVersion > CURRENT_VERSION) + { + printf("Boot error: incompatible version number: %x\n", bootHdr.bootVersion); + return LOADER_NOT_SUPPORT; + } + + // shall we replace the command line? + if(bootHdr.bitFlags & FLAG_CMDLINE) + { + // check the command line and wipe out all junk + for(i=0; bootHdr.cmdLine[i] != 0; i++) + switch(bootHdr.cmdLine[i]) + { + case '\n': + case '\r': + bootHdr.cmdLine[i] = ' '; + break; + default: + // do nothing + break; + } + } + else if(cmdline) + strncpy(bootHdr.cmdLine, cmdline, sizeof(bootHdr.cmdLine)); + + // proceed basing on the specified OS type + switch(bootHdr.osType) + { + case OS_LINUX: + if(bootHdr.bitFlags & FLAG_INITRD) + { + char initrdParam[100]; + if(bootHdr.bitFlags & FLAG_FILESYSTEM) + { + // we are using a real filesystem, so format the initrd file as usually + sprintf(initrdParam, " initrd=%s", bootHdr.initrdFile); + } + else + { + // we are using a 'fake' filesystem, so use the image offset + sprintf(initrdParam, " initrd=flashb at 0x%x,0x%x", + bootHdr.initrdStart, bootHdr.initrdSize); + } + + debug("adding initrd parameter: %s\n", initrdParam); + strncat(bootHdr.cmdLine, initrdParam, sizeof(bootHdr.cmdLine)); + } + + printf("Starting Linux loader...\n"); + + // if using a real filesystem, load the kernel image from a specified file + if(bootHdr.bitFlags & FLAG_FILESYSTEM) + linux_load(info, bootHdr.kernelFile, bootHdr.cmdLine); + // if using a 'fake' filesystem, consider reading from the same image + else + { + part_start = bootHdr.kernelStart >> DEV_SECTOR_BITS; + part_length = ((bootHdr.kernelSize-1) >> DEV_SECTOR_BITS) + 1; + filemax = bootHdr.kernelSize; + linux_load(info, file, bootHdr.cmdLine); + } + + break; + + case OS_WINCE: + + printf("Starting Windows CE loader...\n"); + // if using a real filesystem, load the kernel image from a specified file + if(bootHdr.bitFlags & FLAG_FILESYSTEM) + wince_load(info, bootHdr.kernelFile, bootHdr.cmdLine); + // if using a 'fake' filesystem, consider reading from the same image + else + { + part_start = bootHdr.kernelStart >> DEV_SECTOR_BITS; + part_length = ((bootHdr.kernelSize-1) >> DEV_SECTOR_BITS) + 1; + filemax = bootHdr.kernelSize; + wince_load(info, file, bootHdr.cmdLine); + } + + break; + + default: + printf("Boot error: unknown OS type, aborting: %d\n", bootHdr.osType); + return LOADER_NOT_SUPPORT; + } + + return 0; +} Modified: trunk/filo-0.5/i386/defconfig =================================================================== --- trunk/filo-0.5/i386/defconfig 2008-05-03 14:48:04 UTC (rev 47) +++ trunk/filo-0.5/i386/defconfig 2008-05-03 15:03:45 UTC (rev 48) @@ -3,6 +3,13 @@ # Loader for standard Linux kernel image, a.k.a. /vmlinuz LINUX_LOADER = 1 +# Loader for Windows CE image +# Leave disabled for now. Not supported. +#WINCE_LOADER = 1 + +# Artecboot loader support +#ARTEC_BOOT = 1 + # Boot FILO from Multiboot loader (eg. GRUB) #MULTIBOOT_IMAGE = 1 Modified: trunk/filo-0.5/i386/linux_load.c =================================================================== --- trunk/filo-0.5/i386/linux_load.c 2008-05-03 14:48:04 UTC (rev 47) +++ trunk/filo-0.5/i386/linux_load.c 2008-05-03 15:03:45 UTC (rev 48) @@ -164,11 +164,11 @@ uint32_t kern_addr; if (file_read(hdr, sizeof *hdr) != sizeof *hdr) { - debug("Can't read Linux header\n"); + printf("Can't read Linux header\n"); return 0; } if (hdr->boot_sector_magic != 0xaa55) { - debug("Not a Linux kernel image\n"); + printf("Not a Linux kernel image\n"); return 0; } @@ -178,7 +178,7 @@ * Perform a simple (incomplete) sanity check. */ if (hdr->setup_sects >= 16 || file_size() - (hdr->setup_sects<<9) >= 512<<10) { - debug("This looks like a bootdisk image but not like Linux...\n"); + printf("This looks like a bootdisk image but not like Linux...\n"); return 0; } Added: trunk/filo-0.5/include/artecboot.h =================================================================== --- trunk/filo-0.5/include/artecboot.h (rev 0) +++ trunk/filo-0.5/include/artecboot.h 2008-05-03 15:03:45 UTC (rev 48) @@ -0,0 +1,34 @@ +// Artecboot header, gives information to loader + +#define ARTECBOOT_HEADER_MAGIC 0x10ADFACE +#define CURRENT_VERSION 0x0102 + +#define OS_UNKNOWN 0x00 +#define OS_LINUX 0x01 +#define OS_WINCE 0x02 + +#define FLAG_INITRD 0x0001 // if set, the loader will provide initrd to kernel +#define FLAG_FILESYSTEM 0x0002 // if set, the loader will use specified file names +#define FLAG_CMDLINE 0x0004 // if set, the loader will pass the new command line + +typedef struct __attribute__ ((packed)) +{ + unsigned long magicHeader; + unsigned short bootVersion; + unsigned short headerSize; // also kernel image start + unsigned long imageSize; // NB! since 1.02 is the total image/partition size + unsigned long bitFlags; + unsigned short osType; + char cmdLine[256]; + unsigned long kernelStart; // used with Artecboot VFS / NULLFS + unsigned long kernelSize; // used with Artecboot VFS / NULLFS + unsigned long initrdStart; // used with Artecboot VFS / NULLFS + unsigned long initrdSize; // used with Artecboot VFS / NULLFS + char kernelFile[100]; // valid only with FLAG_FILESYSTEM + char initrdFile[100]; // valid only with FLAG_FILESYSTEM + +} ARTECBOOT_HEADER; + +#define ABOOT_FILE_KERNEL "/kernel" +#define ABOOT_FILE_INITRD "/initrd" +#define ABOOT_FILE_HEADER "/header" Modified: trunk/filo-0.5/include/fs.h =================================================================== --- trunk/filo-0.5/include/fs.h 2008-05-03 14:48:04 UTC (rev 47) +++ trunk/filo-0.5/include/fs.h 2008-05-03 15:03:45 UTC (rev 48) @@ -5,6 +5,10 @@ typedef uint64_t sector_t; +#define DEV_SECTOR_BITS 9 +#define DEV_SECTOR_SIZE (1<<9) +#define DEV_SECTOR_MASK (DEV_SECTOR_SIZE-1) + #ifdef IDE_DISK int ide_probe(int drive); int ide_read(int drive, sector_t sector, void *buffer); @@ -15,20 +19,29 @@ int usb_read(int drive, sector_t sector, void *buffer); #endif +#ifdef FLASH_DISK +int flash_probe(int drive); +int flash_read(int drive, sector_t sector, void *buffer); +#endif + #define DISK_IDE 1 #define DISK_MEM 2 #define DISK_USB 3 +#define DISK_FLASH 4 int devopen(const char *name, int *reopen); int devread(unsigned long sector, unsigned long byte_offset, unsigned long byte_len, void *buf); +void dev_set_partition(unsigned long start, unsigned long size); +void dev_get_partition(unsigned long *start, unsigned long *size); int file_open(const char *filename); int file_read(void *buf, unsigned long len); int file_seek(unsigned long offset); unsigned long file_size(void); +void file_set_size(unsigned long size); -#define PARTITION_UNKNOWN 0xbad6a7 +#define PARTITION_UNKNOWN 0xbad6a7 #ifdef ELTORITO int open_eltorito_image(int part, unsigned long *start, unsigned long *length); Modified: trunk/filo-0.5/include/lib.h =================================================================== --- trunk/filo-0.5/include/lib.h 2008-05-03 14:48:04 UTC (rev 47) +++ trunk/filo-0.5/include/lib.h 2008-05-03 15:03:45 UTC (rev 48) @@ -58,6 +58,8 @@ char *strncpy(char *to, const char *from, int count); char * strcpy (char *dest, const char *src); char * strstr (const char *s1, const char *s2); +int strncat (char *s1, const char *s2, int n); +int sprintf(char * buf, const char *fmt, ...); unsigned long long simple_strtoull(const char *cp,char **endp,unsigned int base); unsigned long long strtoull_with_suffix(const char *cp,char **endp,unsigned int base); @@ -83,4 +85,16 @@ #define linux_load(x,y,z) LOADER_NOT_SUPPORT /* nop */ #endif +#if WINCE_LOADER +int wince_load(struct sys_info *, const char *filename, const char *cmdline); +#else +#define wince_load(x,y,z) LOADER_NOT_SUPPORT /* nop */ +#endif + +#if ARTEC_BOOT +int artecboot_load(struct sys_info *, const char *filename, const char *cmdline); +#else +#define artecboot_load(x,y,z) LOADER_NOT_SUPPORT /* nop */ +#endif + #endif /* LIB_H */ Modified: trunk/filo-0.5/main/console.c =================================================================== --- trunk/filo-0.5/main/console.c 2008-05-03 14:48:04 UTC (rev 47) +++ trunk/filo-0.5/main/console.c 2008-05-03 15:03:45 UTC (rev 48) @@ -1,10 +1,13 @@ #include #include +void video_cls(); + void console_init(void) { #ifdef VGA_CONSOLE - vga_init(); + vga_init(); + video_cls(); #endif #ifdef SERIAL_CONSOLE serial_init(); Modified: trunk/filo-0.5/main/filo.c =================================================================== --- trunk/filo-0.5/main/filo.c 2008-05-03 14:48:04 UTC (rev 47) +++ trunk/filo-0.5/main/filo.c 2008-05-03 15:03:45 UTC (rev 48) @@ -49,8 +49,10 @@ param++; } + if (artecboot_load(&sys_info, file, param) == LOADER_NOT_SUPPORT) if (elf_load(&sys_info, file, param) == LOADER_NOT_SUPPORT) if (linux_load(&sys_info, file, param) == LOADER_NOT_SUPPORT) + if (wince_load(&sys_info, file, param) == LOADER_NOT_SUPPORT) printf("Unsupported image format\n"); free(file); } From ward at gnu.org Sat May 3 17:21:23 2008 From: ward at gnu.org (Ward Vandewege) Date: Sat, 3 May 2008 11:21:23 -0400 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> References: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> Message-ID: <20080503152123.GA14700@localdomain> On Fri, May 02, 2008 at 10:51:59PM -0700, ron minnich wrote: > So if I push a USB part in, then I get no interrupts. > > If I leave the USB interrupts in the irq_table, I get interrupts. > > What piece am I missing here? I assume I'm not wiring something up in > the x,y,z unrestricted interrupt register. I think it's more difficult than that. We talked about this during the summit (there's a similar problem with the alix.2c3 and eth2/usb interrupts), and Marc said that in addition to a change like this patch, we need to make the change in the VSA... I'm not sure how that would work. Ideally this stuff would be board-specific; can we adjust the cs5536 internal interrupts in the VSA somehwo during coreboot build? Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From sync.jma at gmail.com Sat May 3 17:54:40 2008 From: sync.jma at gmail.com (Jun Ma) Date: Sat, 3 May 2008 23:54:40 +0800 Subject: [coreboot] questions about "QEMU Build Tutorial" In-Reply-To: <03c401c8ac71$bef617a0$0023040a@chimp> References: <03bf01c8ac66$fad7d6b0$0023040a@chimp> <03c401c8ac71$bef617a0$0023040a@chimp> Message-ID: On Sat, May 3, 2008 at 12:29 AM, Myles Watson wrote: > > Your contributions are welcome! > "You must have cookies enabled to log in to coreboot. If you don't have an account and wish to contribute contact Stefan Reinauer or Ronald Minnich. NOTE: You don't need an account to read the information on this site. So don't ask for an account unless you have something to contribute." Here is a instruction with ugly format, hope I have not miss important things. ==START== My test env: debian etch with kernel 2.6.25. src prepare: coreboot v2 - svn://coreboot.org/repos/trunk/coreboot-v2 qemu-0.9.1.tar.gz/kqemu - http://fabrice.bellard.free.fr/qemu/ filo-0.5 - svn co svn://coreboot.org/filo/trunk/filo-0.5 linux src - http://www.kernel.org linux rescue cd. - for partitions. build tools: qemu: New linux distributions use gcc4.x as default, but qemu needs gcc-3.x, so maybe you need to install gcc3.4 (for debian users, 'sudo apt-get install gcc-3.4') $ cd qemu-0.9.1 $ ./configure --cc=gcc-3.4 --target-list=i386-softmmu && make $ sudo make install Ok, qemu is done. you can use "qemu -h" for more helps. Let us create a qemu hard disk image first. BTW, kqemu will bring you better performance, please google for installing. $ qemu-img create -f raw test.img 200M Use your favourite rescue CD to do partion issues.(I choose rhel here because both Debian etch/lenny CDs could not enter the rescue mode in qemu-0.9.1.:<. anyone who knows the reason please tell me, thanks. ) $ qemu -cdrom ~/iso/rhel5_rescue.iso -boot d -hda test.img -L ~/work/qemu-0.9.1/pc-bios/ -m 512 Run fdisk and create a single partition on the drive that takes up the whole drive Quit and write the partition to disk Run mkfs.ext2fs on that partition Exit QEMU Allright, we start to build rootfs for qemu image. $ sudo mount -o loop,offset=32256 test.img /mnt/rootfs Create a boot directory and copy your Linux kernel (vmlinuz) and initramfs (initrd) to it: $ sudo mkdir /mnt/rootfs/boot $ sudo mkdir /mnt/rootfs/boot/filo $ sudo cp vmlinuz /mnt/rootfs/boot/vmlinuz $ sudo cp initrd /mnt/rootfs/boot/initrd $ sudo vi /mnt/rootfs/boot/filo/menu.lst # For booting GNU/Linux title GNU/Linux root (hd0,0) kernel /boot/vmlinuz root=/dev/hda1 initrd /boot/initrd # Add other files as you wish. $ sudo cp -R /* /mnt/rootfs Alternatively, with Debian you can use the debootstrap command to create a basic root filesystem: $ sudo debootstrap --arch i386 etch /mnt/rootfs http://ftp.debian.org/debian/ If you are using a debootstrap filesystem, open the file /mnt/rootfs/etc/inittab and change runlevel to level 1: id:1:initdefault: cd out of /mnt/rootfs and umount it: $ sudo umount /mnt/rootfs filo: $ cd filo-0.5 First invocation of make creates the default Config file. $ make Edit this file as you like. vi Config change MENULST_FILE to "hda1:/boot/filo/menu.lst", since we only have one single partition. change AUTOBOOT_FILE to "hda1:/boot/vmlinuz root=/dev/hda1 console=ttyS0,115200" Run make again to create filo.elf, the ELF FILO image. $ make coreboot: change payload to path/to/filo.elf $ vi coreboot-v2/targets/emulation/qemu-x86/Config.lb $ cd coreboot-v2/targets $ ./buildtarget emulation/qemu-x86 $ cd emulation/qemu-x86/qemu-x86/ $ sudo make Here we got coreboot.rom which use filo as bootloader. $ cp coreboot.rom ~/bios.bin $ cp $path/to/qemu-0.9.1/pc-bios/vgabios-cirrus.bin ~/ Here we go! Boot test.img using coreboot. $ qemu -L ~ -hda test.img ==END== -- FIXME if it is wrong. From c-d.hailfinger.devel.2006 at gmx.net Sat May 3 18:25:20 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 03 May 2008 18:25:20 +0200 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> References: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> Message-ID: <481C91F0.7000300@gmx.net> Hi Ron, I merged two mails from you with similar topic to answer them in one swoop. On 03.05.2008 07:51, ron minnich wrote: > This is not signed off, as it does not work. > > It sets up the interrupts correctly, or at least as defined in the dts: > > 00:0f.3 Multimedia audio controller: Advanced Micro Devices [AMD] > CS5536 [Geode companion] Audio (rev 0) > Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio > Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- > ParErr+ Stepping- SERR- FastB2B- > Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium > >> TAbort- SERR- > > Interrupt: pin B routed to IRQ 10 > Region 0: I/O ports at 1880 [size=128] > > 00:0f.4 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode > companion] OHC (rev 02) (prog-if 10 ) > Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium > >> TAbort- SERR- > > Latency: 0 > Interrupt: pin D routed to IRQ 5 > Region 0: Memory at fe016000 (32-bit, non-prefetchable) [size=4K] > Capabilities: [40] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > PME(D0+,D1-,D2-,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > > 00:0f.5 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode > companion] EHC (rev 02) (prog-if 20 ) > Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC > Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium > >> TAbort- SERR- > > Interrupt: pin D routed to IRQ 5 > Region 0: Memory at fe017000 (32-bit, non-prefetchable) [size=4K] > Capabilities: [40] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > PME(D0+,D1-,D2-,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > > > But they appear not to be wired internally: > pbx ~ # cat /proc/interrupts > CPU0 > 0: 48248 XT-PIC-XT timer > 2: 0 XT-PIC-XT cascade > 4: 2333 XT-PIC-XT serial > 5: 0 XT-PIC-XT ohci_hcd:usb1 > 7: 4 XT-PIC-XT > 8: 0 XT-PIC-XT rtc > 10: 21 XT-PIC-XT eth0 > 14: 13886 XT-PIC-XT ide0 > NMI: 0 Non-maskable interrupts > TRM: 0 Thermal event interrupts > SPU: 0 Spurious interrupts > ERR: 4 > > So if I push a USB part in, then I get no interrupts. > > If I leave the USB interrupts in the irq_table, I get interrupts. > > What piece am I missing here? I assume I'm not wiring something up in > the x,y,z unrestricted interrupt register. > > Further, what interrupts are safe to use? We keep reusing 10, 11, 5, > etc. Any reason not to use (e.g.) 6 or 13 or 12? > Is there a Geode rule I need to know? > > thanks > > ron > On 03.05.2008 06:46, ron minnich wrote: > (I'm hoping someone will do this :-) > > One issue I'm having is that the hfcpci card (or driver) can't > tolerate shared interrupts. > But we have shared interrupts on the various cs5536 boards, since we > put USB interrupt info in the table. > > To allow us to have non-shared interrupts for all devices, we need to > get the USB interrupts out of the PIR table. They are not really > routed via the standard IRQ router anyway -- they are internal -- and > don't need to share interrupt #s with the other devices that are > actually routed via the interrupt routing hardware. > > Put simply, having the USB f.3,4,5 devices in the PIR table works, but > is really a bit of a mistake. > So an abstract model of the hardware would be: - standard IRQ router, settings from PIR table - CS5536-internal virtual IRQ router, settings outside PIR table. > OK, where do we put the IRQ info for the USB devices? In the DTS for > the cs5536. > > SO in DTS for the cs5536 we need three more properties, > usbf3 > usbf4 > usbf5 > > with reasonable settings for them. Then in the chipset init code, we > need to see if these are set and, if so, set the IRQ line in the f.3, > f.4, and f.5 devices. > > If this is confusing I can explain in more detail, but later, I'm > tired, and the ISDN card just locked up again. How can such a simple > driver have so many failure modes? Oh, wait, it's not simple, sigh. > > but, short form: on the cs5536, USB interrupts should not be described > in the PIR table, but via settings derived from dts. They should be > initialized in cs5536 setup code, no in the PIR setup code. That will > allow us to have non-shared interrupts on the various PCI slots on, > e.g., alix1c, and allow broken drivers like hfcpci to work. > Sorry, but I have to disagree with the design. Your proposed change scatters interrupt settings and routing info into totally different types of files. Either interrupt settings are something we want to have in the DTS (and that would mean we have to keep the PIR table in the dts as well) or they are kept in separate tables in irq_tables.h. > Index: southbridge/amd/cs5536/cs5536.c > =================================================================== > --- southbridge/amd/cs5536/cs5536.c (revision 674) > +++ southbridge/amd/cs5536/cs5536.c (working copy) > @@ -410,6 +410,28 @@ > #define PADEN_SET (1 << 7) > > /** > + * Depending on settings in the config struct, manage audio setup. > + * > + * @param sb Southbridge config structure. > + */ > +static void audio_init(struct southbridge_amd_cs5536_dts_config *sb) > +{ > + u32 *bar; > + struct msr msr; > + struct device *dev; > + > + if (!sb->audio_enable) > + return; > + > + dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, > + PCI_DEVICE_ID_AMD_CS5536_AUDIO, 0); > I see dev_pci_find_device crop up more and more often in v3 and it scares me. Is the device tree code really that bad that we can't avoid dev_pci_find_device? Or did I misunderstand the benefits of the device tree? > + if (dev) { > + pci_write_config8(dev, PCI_INTERRUPT_LINE, sb->audio_irq); > + } > +} > + > + > +/** > * Depending on settings in the config struct, manage USB setup. > * > * @param sb Southbridge config structure. > @@ -438,9 +460,21 @@ > > /* EECP=50h, IST=01h, ASPC=1 */ > *(bar + HCCPARAMS) = 0x00005012; > + > + /* set interrupt line */ > + pci_write_config8(dev, PCI_INTERRUPT_LINE, sb->ehci_irq); > + > } > > dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, > + PCI_DEVICE_ID_AMD_CS5536_OHCI, 0); > Same dev_find_pci_device objection here. > + if (dev) { > + /* set interrupt line */ > + pci_write_config8(dev, PCI_INTERRUPT_LINE, sb->ohci_irq); > + } > + > + > + dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, > PCI_DEVICE_ID_AMD_CS5536_OTG, 0); > Same dev_find_pci_device objection here. > if (dev) { > bar = (u32 *) pci_read_config32(dev, PCI_BASE_ADDRESS_0); > @@ -649,6 +683,8 @@ > > enable_USB_port4(sb); > > + audio_init(sb); > + > /* disable unwanted virtual PCI devices */ > for (i = 0; 0 != sb->unwanted_vpci[i]; i++) { > hide_vpci(sb->unwanted_vpci[i]); I see v3 as a big promise of clean design, readable code and easy porting and I fiercely try to keep it that way. This motivates me to work on secret projects which will transform the current v3 code to fulfill its design destiny. Expect code sometime in July. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Sat May 3 18:50:46 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 03 May 2008 18:50:46 +0200 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: References: <4818A556.6060900@gnu.org> <481A2C12.6020605@gmx.net> Message-ID: <481C97E6.6060507@gmx.net> On 02.05.2008 23:13, Richard M Stallman wrote: > > If the "proprietary low-level chipset initialization code" is in ROM > > on the chips that it initializes, then it is tolerable. (It might as > > well be circuits on that chip.) Otherwise, it is insufficient unless > > made complete. > > > > None of the current mainstream x86 board manufacturers uses real ROMs > anymore. > > We may be partly miscommunicating, talking about different questions. > I'm talking about where we should draw the line of what's acceptable. > What is done in any particular product is a different question. Both > questions are important, but they are different. > Understood. > If memory is physically writable, but is never updated once users get > the product, that is more or less equivalent to ROM in my view. Thus, > an EEPROM in a chip (or in a device) that contains the code to > initialize the chip (or device) is tolerable if people treat it as a > ROM. > The x86 world is difficult. We have network cards where the firmware EEPROM is updatable, but the vendor will never offer an update. That would qualify as ROM in your definition. However, another network card with exactly the same chips and the same firmware, but a different model number, may get firmware updates from the vendor. That would _not_ qualify as ROM in your definition, at least as I understand it. The technical side of the ROM equivalence question does not allow for such distinctions. It gets even worse once you look at CD/DVD burners and hard disks. Depending on the model number (not the product itself), a vendor may offer updates for such storage devices or not. CD/DVD burners very often offer firmware updates, but it is extremely uncommon for hard disk vendors to do that. Firmware blobs which are loaded into devices, but where the blob never changes even for different versions of the driver, would be tolerable according to your definition (please correct me if I'm wrong). > ISTR that it was necessary for free BIOSes to run some initialization > code for the video card which is stored on the video card. Is that > correct? Yes and no. It depends on the model of the video card. > Is this still necessary? There is free/open source code which can initialize some graphics chipsets without having to run non-free code stored in the ROM of a video card. This depends a lot on vendor cooperation and since the code for each grapics card is different, you lose a lot of flexibility by avoiding the execution of on-card routines. > If so, it is an example of what I am talking about. > As I explained above, free software politics based on "ROM equivalence" in the firmware category do not make sense from a technical point of view. Please note that any laptop where the manufacturer refuses to provide BIOS updates would be tolerable according to you because "memory is physically writable, but is never updated once users get the product". Regards, Carl-Daniel From luca.burelli at m31engineering.it Sat May 3 20:09:01 2008 From: luca.burelli at m31engineering.it (Luca Burelli) Date: Sat, 03 May 2008 20:09:01 +0200 Subject: [coreboot] ICH7 SPI support for flashrom In-Reply-To: <481A2172.9040105@gmx.net> References: <48182B30.6050407@m31engineering.it> <481A2172.9040105@gmx.net> Message-ID: <481CAA3D.9060309@m31engineering.it> Carl-Daniel, Thanks a lot for the pointers and good work on your thesis. I will delve a bit on the details and report back my progress. Regards, Luca Carl-Daniel Hailfinger ha scritto: > Hi Luca, > > On 30.04.2008 10:17, Luca Burelli wrote: >> Hello list, >> I have tried flashrom on an ICH7-based board with a SPI Flash >> connected. On this kind of platform, after recognizing the ICH7 SPI >> interface, it seems like it's still using FWH commands to probe the >> Flash device. >> > > Yes, that's expected because ICH7 also supports parallel flash. > >> From the current SVN logs, it looks like this is a work in progress, >> and that "hailfinger" was the most active on this topic, but the last >> commit was around a month ago. Is someone still working on this? What is >> the current status of this support? >> > > I'm currently very busy with my diploma thesis. There is some work to > add ICH9 SPI support to flashrom and depending on which of the two SPI > interfaces in ICH9 is implemented, adding support for ICH7 is either > easy or a complete new "driver". If you understand SPI well and take a > look at the existing IT8716F SPI driver, you should be a able to write a > ICH7 SPI driver in a week of development. The public ICH7 flash docs are > pretty good, at least compared to what other vendors have. Then again, > there are many things you have to guess while writing the driver because > the docs are not explaining every detail. > > Regards, > Carl-Daniel From rminnich at gmail.com Sat May 3 20:41:16 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 3 May 2008 11:41:16 -0700 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <481C91F0.7000300@gmx.net> References: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> <481C91F0.7000300@gmx.net> Message-ID: <13426df10805031141u6b6ed6f4i50e23cb9e57f7728@mail.gmail.com> On Sat, May 3, 2008 at 9:25 AM, Carl-Daniel Hailfinger wrote: > Sorry, but I have to disagree with the design. Your proposed change > scatters interrupt settings and routing info into totally different > types of files. Either interrupt settings are something we want to have > in the DTS (and that would mean we have to keep the PIR table in the dts > as well) or they are kept in separate tables in irq_tables.h. good point. The geode is a very odd beast, however, and does not follow the rules. The USB is not really connected via the IRQ router. You can specify USB IRQs in the PIR table and get working boards, but you are restricting the USB interrupts to one of four choices and that is really not necessary or required. It would be better if we do not restrict ourselves unnecessarily. Which really means the PIR table must die! die! die! die! > > + dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, > > + PCI_DEVICE_ID_AMD_CS5536_AUDIO, 0); > > > > I see dev_pci_find_device crop up more and more often in v3 and it > scares me. Is the device tree code really that bad that we can't avoid > dev_pci_find_device? Or did I misunderstand the benefits of the device tree? I don't see the problem. This strikes me as a fairly cheap and safe way to ensure that the device you think is there is there. Given vendor's propensity for undocumented chipset changes, I think this is safe. I could blindly trust the bus:dev.fn I put in the tree, however; I had not even thought of this. Good point again but ... look at the cs5536 code and the dts. Much of cs5536 init code involves things not in the dts, as there is no reason to put it in the dts. Why burden people with all this specification when a simple find_device can resolve it? > I see v3 as a big promise of clean design, readable code and easy > porting and I fiercely try to keep it that way. This motivates me to > work on secret projects which will transform the current v3 code to > fulfill its design destiny. Expect code sometime in July. Well, I trust you to create a great design, but still, a 'secret project' sounds a little worrisome. We used to get these from one vendor, just submitted with no comments, and they were not really usable. I think if you're doing a redesign you should do what I try to do -- bring it to the list and take the comments. I will probably drop this patch I guess. But I suspect there are some deep-rooted IRQ problems in the LX port, even down into the VSA, and that's why we're having MFGPT and other issues. The Geode is just not quite right yet, and interrupts are a part of the problem. The DBE62 does not really set up IRQs for USB, and that may be related to why there is a power issue. Mart, note that alix1c sets up USB in the PIR table and dbe62 does not. How are you getting USB to work at all? thanks ron From rms at gnu.org Sat May 3 23:00:43 2008 From: rms at gnu.org (Richard M Stallman) Date: Sat, 03 May 2008 17:00:43 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <481B869A.5060507@coresystems.de> (message from Stefan Reinauer on Fri, 02 May 2008 23:24:42 +0200) References: <4818A556.6060900@gnu.org> <13426df10805010812kc25ad20w78560fe0e43a762a@mail.gmail.com> <2bf69daa60a7558afc8e488c223c83a8@imap.1and1.com> <13426df10805010902o73c8265fo4a25221f389c8719@mail.gmail.com> <4819EC56.4070503@coresystems.de> <481B869A.5060507@coresystems.de> Message-ID: Thanks for lecturing me, Richard. I think your opinion on this is widely known. I hope you got the point anyways. The facts about the system are widely misreported. Most people who have heard of the GNU/Linux system have never heard it called anything but "Linux", and this leads them to suppose it was started by Linus Torvalds. I know that denying the GNU Project credit for its work was not the main intention of your message. It was just something you did on the side. It still isn't right. From stepan at coresystems.de Sun May 4 00:19:42 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 04 May 2008 00:19:42 +0200 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <481C91F0.7000300@gmx.net> References: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> <481C91F0.7000300@gmx.net> Message-ID: <481CE4FE.4030604@coresystems.de> Carl-Daniel Hailfinger wrote: > I see v3 as a big promise of clean design, readable code and easy > porting and I fiercely try to keep it that way. This motivates me to > work on secret projects which will transform the current v3 code to > fulfill its design destiny. Expect code sometime in July. > > Please don't. As you wrote yourself a few days ago to another developer (no exact quote): Release early and often, so we can correct your design in case it doesn't fit the standards. There are (mostly legal) circumstances that make it hard or impossible to release code early, but I don't see any of those apply in your case. Stefan From rminnich at gmail.com Sun May 4 00:26:11 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 3 May 2008 15:26:11 -0700 Subject: [coreboot] Presenting at a LUG In-Reply-To: References: <006901c8ac04$af2344f0$6401a8c0@who8> Message-ID: <13426df10805031526y7a361b17s7c2ed4af5910b8b3@mail.gmail.com> I actually have several possible talks, including a 90-slide talk on "how to do a coreboot port". I can talk for hours, and bore you all to death. So it can be very general, or about the experience of coreboot, or about doing a port for v3, ... take your pick. thanks ron From peter at stuge.se Sun May 4 00:28:06 2008 From: peter at stuge.se (Peter Stuge) Date: Sun, 4 May 2008 00:28:06 +0200 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <13426df10805031141u6b6ed6f4i50e23cb9e57f7728@mail.gmail.com> References: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> <481C91F0.7000300@gmx.net> <13426df10805031141u6b6ed6f4i50e23cb9e57f7728@mail.gmail.com> Message-ID: <20080503222806.6468.qmail@stuge.se> On Sat, May 03, 2008 at 11:41:16AM -0700, ron minnich wrote: > The geode is a very odd beast Yes. > It would be better if we do not restrict ourselves unnecessarily. I don't think we'll go all the way on this anytime soon. :\ > Which really means the PIR table must die! die! die! die! I would like to specify all about interrupts in the dts. I still don't know what we need in the syntax.. > > dev_pci_find_device? > > I don't see the problem. The point is that the device tree model should allow code to be associated with the right device, so that no find_device() calls are needed. > deep-rooted IRQ problems in the LX port, even down into the VSA, VSA is very much involved at least in setting up interrupts so I suspect anything about interrupts on Geode has to at least be seen by VSA so it can update the neccessary MSRs. Until the Geode architecture is supported in Linux we have to deal with the PCI emulation. Maybe time to look into OpenVSA a bit more? //Peter From rminnich at gmail.com Sun May 4 00:34:21 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 3 May 2008 15:34:21 -0700 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <20080503222806.6468.qmail@stuge.se> References: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> <481C91F0.7000300@gmx.net> <13426df10805031141u6b6ed6f4i50e23cb9e57f7728@mail.gmail.com> <20080503222806.6468.qmail@stuge.se> Message-ID: <13426df10805031534q6f11abc0jef1861365165e84f@mail.gmail.com> On Sat, May 3, 2008 at 3:28 PM, Peter Stuge wrote: > > > dev_pci_find_device? > > > > > I don't see the problem. > > The point is that the device tree model should allow code to be > associated with the right device, so that no find_device() calls > are needed. Well, I welcome the patches. Until I have time for this, or someone else does, it'sgoing to have to stay that way :-) I agree that we ought to be able to make this work. > Until the Geode architecture is supported in Linux we have to deal > with the PCI emulation. Maybe time to look into OpenVSA a bit more? I think it's time to move to openvsa. I am not comfortable depending on this binary blob. I think there's a problem but have no way to even attempt to diagnose it. Peter, if you could, OpenVSA might be a good thing for you to focus on for a little bit. Rather than all of us working on the same thing, I think we need to divide and conquer. I think I will have to fix this crappy ISDN driver, if only to show that it's not a coreboot problem. It would be nice to get Geode rock solid in the next 6 weeks, in time for July 14. We are very, very close. Thanks ron From duwe at lst.de Sun May 4 00:36:18 2008 From: duwe at lst.de (Torsten Duwe) Date: Sun, 4 May 2008 00:36:18 +0200 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: References: <4818A556.6060900@gnu.org> Message-ID: <200805040036.18350.duwe@lst.de> On Thursday 01 May 2008, Richard M Stallman wrote: > Some of the points are simply distractions or illogical. For > instance: > > BIOS is a part of the reliability and performance promise of the > hardware. > > Is that true? If so, so what? That is no reason not to let us run > our own BIOS. Well, sort of. From my experience, which very likely most on this list can share, BIOS is used to cover up defects in the hardware. Thus, it's a PR question, not a technical one. > Chipset specifications at the level being discussed are > commonly considered proprietary by all silicon vendors, not just > Intel. As Peter has already mentioned, that's a lie^W^Woutdated. Additionally to Peter's points, the new "gallium" driver for mesa is being developed for a pure software pipeline and, as the only hardware implementation,... TADAAA: intel onboard graphics i915. > However, it is false: some computer models do work with free BIOS. > Intel compares badly with them. This is one of the statements that > maybe could be criticized in a published response. > > The open source firmware work that Intel *is* sponsoring could > lead to a solution where proprietary low-level chipset > initialization code from silicon vendors is made compatible with > open source higher-level platform initialization and pre-boot > management. > > As they say, this is not a complete free BIOS, just part of one. As things look like today, it's a layer _on_top_ of what's currently known as BIOS. Besides, did they lift the royalties clause on UEFI yet? (http://www.uefi.org/specs/agreement : "...implementation ... requires a license") Torsten From c-d.hailfinger.devel.2006 at gmx.net Sun May 4 01:34:56 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 04 May 2008 01:34:56 +0200 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <13426df10805031534q6f11abc0jef1861365165e84f@mail.gmail.com> References: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> <481C91F0.7000300@gmx.net> <13426df10805031141u6b6ed6f4i50e23cb9e57f7728@mail.gmail.com> <20080503222806.6468.qmail@stuge.se> <13426df10805031534q6f11abc0jef1861365165e84f@mail.gmail.com> Message-ID: <481CF6A0.6000805@gmx.net> On 04.05.2008 00:34, ron minnich wrote: > It would be nice to get Geode rock solid in the next 6 weeks, in > time for July 14. > > We are very, very close. > May I ask about the meaning of July 14 and at the same time suggest we have v3 Geode rock solid at the end of May so I can showcase it at LinuxTag? Regards, Carl-Daniel From rminnich at gmail.com Sun May 4 01:58:11 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 3 May 2008 16:58:11 -0700 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <481CF6A0.6000805@gmx.net> References: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> <481C91F0.7000300@gmx.net> <13426df10805031141u6b6ed6f4i50e23cb9e57f7728@mail.gmail.com> <20080503222806.6468.qmail@stuge.se> <13426df10805031534q6f11abc0jef1861365165e84f@mail.gmail.com> <481CF6A0.6000805@gmx.net> Message-ID: <13426df10805031658t4f2d4948id7c2365f7478a869@mail.gmail.com> On Sat, May 3, 2008 at 4:34 PM, Carl-Daniel Hailfinger > May I ask about the meaning of July 14 bastille day, when people stormed the ramparts and released 7 prisoners. http://en.wikipedia.org/wiki/Bastille_Day >and at the same time suggest we > have v3 Geode rock solid at the end of May so I can showcase it at LinuxTag? > I love that idea, but at the rate we're going it will be tough. I think it'd be wonderful to have the booth full of dbe62s and alix?c? and so on. But we need to resolve MFGPT and one or two other issues. I think your goal is really a good one, however. ron From peter at stuge.se Sun May 4 03:11:02 2008 From: peter at stuge.se (Peter Stuge) Date: Sun, 4 May 2008 03:11:02 +0200 Subject: [coreboot] [PATCH] artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines In-Reply-To: <13426df10805022146s7b5d9e38v264870a629811ed8@mail.gmail.com> References: <1209779885.13448.16.camel@martr-gentoo.artec> <20080503015934.22789.qmail@stuge.se> <13426df10805022134o7f607847yc5cd59cefbb9a873@mail.gmail.com> <13426df10805022146s7b5d9e38v264870a629811ed8@mail.gmail.com> Message-ID: <20080504011102.28620.qmail@stuge.se> On Fri, May 02, 2008 at 09:46:41PM -0700, ron minnich wrote: > get the USB interrupts out of the PIR table. They are not really > routed via the standard IRQ router anyway -- they are internal -- > and don't need to share interrupt #s with the other devices that > are actually routed via the interrupt routing hardware. Are you sure? From the OS point of view they still need a 4-bit interrupt number, since they are supposed to be PCI devices. No? > Put simply, having the USB f.3,4,5 devices in the PIR table works, > but is really a bit of a mistake. USB is on the GLIU in 5536 and not on any external PCI bus. But it still appears to be a PCI device, and it needs an interrupt. > but, short form: on the cs5536, USB interrupts should not be described > in the PIR table, but via settings derived from dts. They should be > initialized in cs5536 setup code, no in the PIR setup code. That will > allow us to have non-shared interrupts on the various PCI slots on, > e.g., alix1c, and allow broken drivers like hfcpci to work. Yep. Is good. //Peter From peter at stuge.se Sun May 4 03:17:57 2008 From: peter at stuge.se (Peter Stuge) Date: Sun, 4 May 2008 03:17:57 +0200 Subject: [coreboot] [PATCH] artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines In-Reply-To: <20080504011102.28620.qmail@stuge.se> References: <1209779885.13448.16.camel@martr-gentoo.artec> <20080503015934.22789.qmail@stuge.se> <13426df10805022134o7f607847yc5cd59cefbb9a873@mail.gmail.com> <13426df10805022146s7b5d9e38v264870a629811ed8@mail.gmail.com> <20080504011102.28620.qmail@stuge.se> Message-ID: <20080504011757.30000.qmail@stuge.se> On Sun, May 04, 2008 at 03:11:02AM +0200, Peter Stuge wrote: > USB is on the GLIU in 5536 and not on any external PCI bus. > But it still appears to be a PCI device, and it needs an interrupt. 32663C_lx_gx_pciconfig.pdf page 46-49 seems to suggest that USB is always on INTD# IRQ11. This could be hardwired in LX/5536; GL packets from USB will always trigger IRQ11. Or worse they will always trigger PCI_INTD# meaning a well-designed board with 4 PCI slots, or a badly designed board with less slots will always need to share somewhere. //Peter From c-d.hailfinger.devel.2006 at gmx.net Sun May 4 03:35:49 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 04 May 2008 03:35:49 +0200 Subject: [coreboot] [PATCH] artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines In-Reply-To: <20080504011102.28620.qmail@stuge.se> References: <1209779885.13448.16.camel@martr-gentoo.artec> <20080503015934.22789.qmail@stuge.se> <13426df10805022134o7f607847yc5cd59cefbb9a873@mail.gmail.com> <13426df10805022146s7b5d9e38v264870a629811ed8@mail.gmail.com> <20080504011102.28620.qmail@stuge.se> Message-ID: <481D12F5.2040709@gmx.net> On 04.05.2008 03:11, Peter Stuge wrote: > On Fri, May 02, 2008 at 09:46:41PM -0700, ron minnich wrote: > >> get the USB interrupts out of the PIR table. They are not really >> routed via the standard IRQ router anyway -- they are internal -- >> and don't need to share interrupt #s with the other devices that >> are actually routed via the interrupt routing hardware. >> > > Are you sure? From the OS point of view they still need a 4-bit > interrupt number, since they are supposed to be PCI devices. No? > > >> Put simply, having the USB f.3,4,5 devices in the PIR table works, >> but is really a bit of a mistake. >> > > USB is on the GLIU in 5536 and not on any external PCI bus. > > But it still appears to be a PCI device, and it needs an interrupt. > > > >> but, short form: on the cs5536, USB interrupts should not be described >> in the PIR table, but via settings derived from dts. They should be >> initialized in cs5536 setup code, no in the PIR setup code. That will >> allow us to have non-shared interrupts on the various PCI slots on, >> e.g., alix1c, and allow broken drivers like hfcpci to work. >> > > Yep. Is good. > Can we store the USB interrupts settings in a separate struct/table in irq_tables.h? That would allow us to keep all interrupt stuff together in one file and avoid the problems we had with v2 where settings were scattered all over the tree in lots of different files. Regards, Carl-Daniel From peter at stuge.se Sun May 4 03:41:00 2008 From: peter at stuge.se (Peter Stuge) Date: Sun, 4 May 2008 03:41:00 +0200 Subject: [coreboot] [PATCH] artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines In-Reply-To: <481D12F5.2040709@gmx.net> References: <1209779885.13448.16.camel@martr-gentoo.artec> <20080503015934.22789.qmail@stuge.se> <13426df10805022134o7f607847yc5cd59cefbb9a873@mail.gmail.com> <13426df10805022146s7b5d9e38v264870a629811ed8@mail.gmail.com> <20080504011102.28620.qmail@stuge.se> <481D12F5.2040709@gmx.net> Message-ID: <20080504014100.3541.qmail@stuge.se> On Sun, May 04, 2008 at 03:35:49AM +0200, Carl-Daniel Hailfinger wrote: > >> but, short form: on the cs5536, USB interrupts should not be described > >> in the PIR table, > > Can we store the USB interrupts settings in a separate struct/table > in irq_tables.h? That would allow us to keep all interrupt stuff > together in one file Thinking a bit more about this I'm not sure I agree anymore Ron. Since the devices should look like PCI devices maybe they should be in the PIR table, and 5536 code shall instead know to handle some devices specially? //Peter From peter at stuge.se Sun May 4 03:48:32 2008 From: peter at stuge.se (Peter Stuge) Date: Sun, 4 May 2008 03:48:32 +0200 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <13426df10805031534q6f11abc0jef1861365165e84f@mail.gmail.com> References: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> <481C91F0.7000300@gmx.net> <13426df10805031141u6b6ed6f4i50e23cb9e57f7728@mail.gmail.com> <20080503222806.6468.qmail@stuge.se> <13426df10805031534q6f11abc0jef1861365165e84f@mail.gmail.com> Message-ID: <20080504014832.6182.qmail@stuge.se> On Sat, May 03, 2008 at 03:34:21PM -0700, ron minnich wrote: > > Maybe time to look into OpenVSA a bit more? > > Peter, if you could, OpenVSA might be a good thing for you to focus > on for a little bit. Surely you jest. You know how I feel about VSA.. I was just trying to inspire someone else. > Rather than all of us working on the same thing, I think we need to > divide and conquer. Also a good point. > It would be nice to get Geode rock solid in the next 6 weeks, in > time for July 14. I would also like to show off v3 in Berlin. I will bring my alix boards and the epia cn, maybe Bari has it too good by then. :) I'll bring an m57sli or two. I'll need to buy or borrow a screen for it all.. > We are very, very close. Dunno.. //Peter From peter at stuge.se Sun May 4 03:49:37 2008 From: peter at stuge.se (Peter Stuge) Date: Sun, 4 May 2008 03:49:37 +0200 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <13426df10805031658t4f2d4948id7c2365f7478a869@mail.gmail.com> References: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> <481C91F0.7000300@gmx.net> <13426df10805031141u6b6ed6f4i50e23cb9e57f7728@mail.gmail.com> <20080503222806.6468.qmail@stuge.se> <13426df10805031534q6f11abc0jef1861365165e84f@mail.gmail.com> <481CF6A0.6000805@gmx.net> <13426df10805031658t4f2d4948id7c2365f7478a869@mail.gmail.com> Message-ID: <20080504014937.6508.qmail@stuge.se> On Sat, May 03, 2008 at 04:58:11PM -0700, ron minnich wrote: > But we need to resolve MFGPT and one or two other issues. MFGPTs are in the DD (Diverse Device) while USB is a separate module on a differet GLIU port. I doubt the problems are related. //Peter From rminnich at gmail.com Sun May 4 08:17:55 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 3 May 2008 23:17:55 -0700 Subject: [coreboot] [PATCH] artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines In-Reply-To: <20080504014100.3541.qmail@stuge.se> References: <1209779885.13448.16.camel@martr-gentoo.artec> <20080503015934.22789.qmail@stuge.se> <13426df10805022134o7f607847yc5cd59cefbb9a873@mail.gmail.com> <13426df10805022146s7b5d9e38v264870a629811ed8@mail.gmail.com> <20080504011102.28620.qmail@stuge.se> <481D12F5.2040709@gmx.net> <20080504014100.3541.qmail@stuge.se> Message-ID: <13426df10805032317g1d0c6dbak96daa5ebc2188611@mail.gmail.com> On Sat, May 3, 2008 at 6:41 PM, Peter Stuge wrote: > On Sun, May 04, 2008 at 03:35:49AM +0200, Carl-Daniel Hailfinger wrote: > > >> but, short form: on the cs5536, USB interrupts should not be described > > >> in the PIR table, > > > > > Can we store the USB interrupts settings in a separate struct/table > > in irq_tables.h? That would allow us to keep all interrupt stuff > > together in one file > > Thinking a bit more about this I'm not sure I agree anymore Ron. > > Since the devices should look like PCI devices maybe they should be > in the PIR table, and 5536 code shall instead know to handle some > devices specially? > thanks for looking up the IRQs in the manual. The real problem is the broken ISDN driver. I think I'll focus on that code -- it's awful -- and see where I can get. Everything else "just works". I am fixing the wrong problem with this IRQ messing around. I have reverted my local changes and will focus on real, not imaginary problems. One remaining real problem is MFGPT, which doesn't work on v2 either. thanks ron From rminnich at gmail.com Sun May 4 08:19:26 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 3 May 2008 23:19:26 -0700 Subject: [coreboot] [PATCH] artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines In-Reply-To: <481D12F5.2040709@gmx.net> References: <1209779885.13448.16.camel@martr-gentoo.artec> <20080503015934.22789.qmail@stuge.se> <13426df10805022134o7f607847yc5cd59cefbb9a873@mail.gmail.com> <13426df10805022146s7b5d9e38v264870a629811ed8@mail.gmail.com> <20080504011102.28620.qmail@stuge.se> <481D12F5.2040709@gmx.net> Message-ID: <13426df10805032319uac2ba2dj5a573a5681215a2d@mail.gmail.com> On Sat, May 3, 2008 at 6:35 PM, Carl-Daniel Hailfinger wrote: > Can we store the USB interrupts settings in a separate struct/table in > irq_tables.h? That would allow us to keep all interrupt stuff together > in one file and avoid the problems we had with v2 where settings were > scattered all over the tree in lots of different files. > no, your earlier suggestion was better: store this stuff in dts, generate irq table at run time. This has to get done, I just have not had time. If someone else gets it first, no harm done :-) thanks! ron From rms at gnu.org Sun May 4 11:37:44 2008 From: rms at gnu.org (Richard M Stallman) Date: Sun, 04 May 2008 05:37:44 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <481C97E6.6060507@gmx.net> (message from Carl-Daniel Hailfinger on Sat, 03 May 2008 18:50:46 +0200) References: <4818A556.6060900@gnu.org> <481A2C12.6020605@gmx.net> <481C97E6.6060507@gmx.net> Message-ID: Drawing an ethical line thru a gray area is generally not straightforward. Often it is not possible to find a unique best place to draw it, and sometimes we should treat certain areas as in-betweens. However, another network card with exactly the same chips and the same firmware, but a different model number, may get firmware updates from the vendor. That would _not_ qualify as ROM in your definition, at least as I understand it. The technical side of the ROM equivalence question does not allow for such distinctions. This is a gray area. I think we can treat it as barely acceptable if we do not install firmware upgrades. But only barely, so we should move to free firmware if possible. Firmware blobs which are loaded into devices, but where the blob never changes even for different versions of the driver, would be tolerable according to your definition (please correct me if I'm wrong). If "loaded into devices" means "loaded by your CPU from your disk", that is never acceptable, because (1) the non-free software is in your file system and (2) you (always) do install it into the device. As I explained above, free software politics based on "ROM equivalence" in the firmware category do not make sense from a technical point of view. I think it does make sense, when interpreted as described above. Please note that any laptop where the manufacturer refuses to provide BIOS updates would be tolerable according to you because "memory is physically writable, but is never updated once users get the product". Even if the manufacturer does offer BIOS updates, I think we can treat it as barely acceptable if we do not install them. But only barely, so we should move to free BIOS if possible. From c-d.hailfinger.devel.2006 at gmx.net Sun May 4 11:57:25 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 04 May 2008 11:57:25 +0200 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <20080504014832.6182.qmail@stuge.se> References: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> <481C91F0.7000300@gmx.net> <13426df10805031141u6b6ed6f4i50e23cb9e57f7728@mail.gmail.com> <20080503222806.6468.qmail@stuge.se> <13426df10805031534q6f11abc0jef1861365165e84f@mail.gmail.com> <20080504014832.6182.qmail@stuge.se> Message-ID: <481D8885.9020605@gmx.net> On 04.05.2008 03:48, Peter Stuge wrote: > On Sat, May 03, 2008 at 03:34:21PM -0700, ron minnich wrote: > >> It would be nice to get Geode rock solid in the next 6 weeks, in >> time for July 14. >> > > I would also like to show off v3 in Berlin. I will bring my alix > boards and the epia cn, maybe Bari has it too good by then. :) > I'll bring an m57sli or two. I'll need to buy or borrow a screen > for it all.. > Depending on how much space we get, displaying more than two systems could pose real challenges. >> We are very, very close. >> > > Dunno.. > I'd even say we have arrived. With the right payload configuration, these systems work fine (unless you want to use those pesky ISDN cards with horrible drivers). To be honest, I'd say we sidestep the ISDN issue completely by using any other miniPCI card for demos. Regards, Carl-Daniel From peter at stuge.se Sun May 4 12:34:42 2008 From: peter at stuge.se (Peter Stuge) Date: Sun, 4 May 2008 12:34:42 +0200 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <481D8885.9020605@gmx.net> References: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> <481C91F0.7000300@gmx.net> <13426df10805031141u6b6ed6f4i50e23cb9e57f7728@mail.gmail.com> <20080503222806.6468.qmail@stuge.se> <13426df10805031534q6f11abc0jef1861365165e84f@mail.gmail.com> <20080504014832.6182.qmail@stuge.se> <481D8885.9020605@gmx.net> Message-ID: <20080504103442.1440.qmail@stuge.se> On Sun, May 04, 2008 at 11:57:25AM +0200, Carl-Daniel Hailfinger wrote: > > I would also like to show off v3 in Berlin. > > Depending on how much space we get, displaying more than two > systems could pose real challenges. IIRC orgas are talked about one half infopoint. That is an area about 1m wide and 60cm deep. I'd say up to six mainboards can fit if they are small enough. My only problem is with displays - there is neither room nor logistics for more than a single screen, and it's a little boring to only see output from one board at a time. :\ I'll try to bring a 4-1 monitor switch so we can at least switch around easily. Last year we had serial output from lots of boards on the screen at the same time, we can do that again but it's more fun to have VGA tint on power on. ;) I'll bring a PS/2 keyboard. > >> We are very, very close. > > > > Dunno.. > > I'd even say we have arrived. Strongly disagree. > With the right payload configuration, Nono, "arrived" means there are zero reservations. I spent a good hour creating a v3 that did nothing at all on my alix1c. Turned out to be a VSA blob formatting problem. It still can not use the CF. Neither buildrom nor v3 actually include VSA blob and payload.elf when I run make. I forget where the zerofill option was, but that wasn't done either. Oh and stuffing everything into build/ feels so unusual. I go looking for lar in all the wrong places (util) but that's just me. > these systems work fine (unless you want to use those pesky ISDN > cards with horrible drivers). To be honest, I'd say we sidestep > the ISDN issue completely by using any other miniPCI card for > demos. Yes definately. But please keep in mind that the product is not done until it has been so polished that users mistake it for a mirror. ;) Btw, what is a fun miniPCI-card? All I have is the POST card and two wifi cards. Or a fun PCI card for that matter, for alix1c. //Peter From joe at settoplinux.org Sun May 4 13:52:39 2008 From: joe at settoplinux.org (Joe) Date: Sun, 4 May 2008 07:52:39 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: References: <4818A556.6060900@gnu.org> <481A2C12.6020605@gmx.net> <481C97E6.6060507@gmx.net> Message-ID: <9C40CD7F8BD746069B755FEC47F204E3@smitty2m> Richard, at this point I think your just beating a dead horse. I think we all got the point and we should just move forward towards accomplishing our goals. Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org From Ken.Fuchs at bench.com Sat May 3 00:56:24 2008 From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com) Date: Fri, 2 May 2008 17:56:24 -0500 Subject: [coreboot] [RFC] Porting coreboot to Intel Atom (Silverthorne) & SCH US15W (Poulsbo) chipset Message-ID: Intel Atom: http://en.wikipedia.org/wiki/Silverthorne_(CPU) http://download.intel.com/design/chipsets/embedded/prodbrf/319544.pdf http://download.intel.com/design/chipsets/embedded/datashts/319535.pdf Intel SCH US15W (combined northbridge, southbridge and graphics): http://download.intel.com/design/chipsets/embedded/prodbrf/319545.pdf http://download.intel.com/design/chipsets/embedded/datashts/319537.pdf Intel's "reference design" for these two is called the "Menlow" platform. For more Intel codename definitions concerning Mobile Internet Devices (MID), see: http://softwareblogs.intel.com/2008/04/01/atom-101-deciphering-the-intel -codewords-around-mids/ Comments: Assuming that technical documentation is available for Atom/Poulsbo, is it feasible to port coreboot (aka LinuxBIOS) to Atom/Poulsbo? Given that this port will support both a new processor and a new single support chip (as opposed to a northbridge and southbridge chipset), what kind of development effort might be required? Is anyone else interested in such a port? Any suggestions and comments are welcome. Sincerely, Ken Fuchs From arc at gnu.org Sun May 4 10:07:56 2008 From: arc at gnu.org (arc) Date: Sun, 04 May 2008 10:07:56 +0200 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <200805040007.48773.duwe@lst.de> References: <4818A556.6060900@gnu.org> <481A2C12.6020605@gmx.net> <200805040007.48773.duwe@lst.de> Message-ID: <481D6EDC.9020509@gnu.org> Torsten Duwe wrote: > On Thursday 01 May 2008, Carl-Daniel Hailfinger wrote: >> Hi Richard, >> >> I normally do not reply to threads started by someone (arc at gnu.org) who >> is unwilling to state his/her real name and announces that he has >> blacklisted the e-mail address of the founder of coreboot. > > "arc" whatever it may be, is not anti-Ron, he (or she, or it...) is > anti-gmail, which is something I can fully understand. But obviously I also > agree with you that someone with a real opinion should have a real name, too. > > Torsten > > I didn't reply before because I didn't fully understand that statement. :) We are on the internet and I have the right to express my opinion without revealing my name and surname. I have the right to maintain my privacy if I wish and I have the right to express my opinion too, if I wish. This is freedom of speech and it's a shame that people like you who are part of such a project don't understand this. :( I didn't want to offend or ignore anybody, trust me. As you can read on my personal website: www.chi3.org I am an italian free software and free culture activist. I was part of the Winston Smith Project too: http://pws.winstonsmith.info/ Since 2001 I'm active in Italy to defend free software and spread digital freedom. Some days ago I found on the FSF website a call for help the free bios project and so I decided to write to Intel via the form on their website. As Richard said, this is not the best way to push them so I wrote to you because I REALLY want to help you. I even ordered an OLPC because of the free bios in it. We are really fighting for the same cause my friends. I wrote to the coreboot list to ask how can I help you, how can I make some pressure or whatever. I don't know how to write code but I still want to help so if you had some suggestions for me I will accept them. Thank you very much for all your wonderful work and sorry if I caused some confusion. -- arc -- GPG Key ID: B03DD073 Chi3 - www.chi3.org gNewSense - www.gnewsense.org GNU IceCat: www.gnu.org/software/gnuzilla NO EMAIL from gmail accounts, >1Mb, html, ms-office files From duwe at lst.de Sun May 4 14:45:07 2008 From: duwe at lst.de (Torsten Duwe) Date: Sun, 4 May 2008 14:45:07 +0200 Subject: [coreboot] Off-Topic: Pseudonyms (Was: [Fwd: Re: Contact Intel]) In-Reply-To: <481D6EDC.9020509@gnu.org> References: <4818A556.6060900@gnu.org> <200805040007.48773.duwe@lst.de> <481D6EDC.9020509@gnu.org> Message-ID: <200805041445.08017.duwe@lst.de> On Sunday 04 May 2008, arc wrote: > We are on the internet and I have the right to express my opinion > without revealing my name and surname. Sure. In these cases, a pseudonym has proven to be handy quite often. As you might see, an assumed gender is helpful when referring to your statements. > This is freedom of speech and it's a shame that people like you who are > part of such a project don't understand this. You are surely free to express your opinions, but a recognisable person, be it real or virtual, helps to account statements and gives them more weight. This is only a hint, do as you like. > I didn't want to offend or ignore anybody, trust me. > As you can read on my personal website: www.chi3.org Good example. Here you are "arc", there you are "chi3". A cross-reference would be nice, like "Chi3" , plus that link in the .sig. Again, just a suggestion. My Italian is not very good, but I assume your suggested gender is male? > As Richard said, this is not the best way to push them so I wrote to you > because I REALLY want to help you. Thank you, help is always welcome. > Thank you very much for all your wonderful work and sorry if I caused > some confusion. You prefer to block mail from google, some people prefer real names. Let's not let that get into our (common) way. Torsten From ward at gnu.org Sun May 4 16:15:39 2008 From: ward at gnu.org (Ward Vandewege) Date: Sun, 4 May 2008 10:15:39 -0400 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <20080504103442.1440.qmail@stuge.se> References: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> <481C91F0.7000300@gmx.net> <13426df10805031141u6b6ed6f4i50e23cb9e57f7728@mail.gmail.com> <20080503222806.6468.qmail@stuge.se> <13426df10805031534q6f11abc0jef1861365165e84f@mail.gmail.com> <20080504014832.6182.qmail@stuge.se> <481D8885.9020605@gmx.net> <20080504103442.1440.qmail@stuge.se> Message-ID: <20080504141538.GA13334@localdomain> On Sun, May 04, 2008 at 12:34:42PM +0200, Peter Stuge wrote: > > >> We are very, very close. > > > > > > Dunno.. > > > > I'd even say we have arrived. > > Strongly disagree. Let's just say more work needs to be done. Polishing is really really really important. We want to be better than the proprietary alternative - and that means that all parts of a supported board need to work, and work properly. > > With the right payload configuration, > > Nono, "arrived" means there are zero reservations. Agreed. > I spent a good hour creating a v3 that did nothing at all on my > alix1c. Turned out to be a VSA blob formatting problem. It still > can not use the CF. I'm not seeing all these issues? > Neither buildrom nor v3 actually include VSA blob and payload.elf > when I run make. I forget where the zerofill option was, but that > wasn't done either. .... I don't know what the problem is you are seeing, but buildrom (v3) works just fine for me. It generates an alix.1c image with filo payload and VSA blob, which boots perfectly from CF (with the dongle). All built on Ubuntu Gutsy 32 bit. Config and generated image at http://ward.vandewege.net/coreboot/alix.1c-v3-working/ Toolchain issues? Your CF boots under the proprietary bios right? Are there multiple alix.1c revisions? > Oh and stuffing everything into build/ feels so unusual. I go > looking for lar in all the wrong places (util) but that's just me. I'm with you there :) It's weird and a bit annoying. > > these systems work fine (unless you want to use those pesky ISDN > > cards with horrible drivers). To be honest, I'd say we sidestep > > the ISDN issue completely by using any other miniPCI card for > > demos. > > Yes definately. But please keep in mind that the product is not done > until it has been so polished that users mistake it for a mirror. ;) 100% agreed. By that reasoning, I don't think we have a single board that is truly 'finished'. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From joe at settoplinux.org Sun May 4 16:17:03 2008 From: joe at settoplinux.org (Joe) Date: Sun, 4 May 2008 10:17:03 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <481D6EDC.9020509@gnu.org> References: <4818A556.6060900@gnu.org> <481A2C12.6020605@gmx.net> <200805040007.48773.duwe@lst.de> <481D6EDC.9020509@gnu.org> Message-ID: Ok, let's beat the dead horse a few more times..... I think we are all on the same page about open source software or we wouldn't be here. I think all the frustrations are not being directed towards the correct direction. Please, could we move on and get back to what really is important here..... which is.... remember coreboot? I would rather spend my time writing some code than having to sort through my email with all this petty stuff. If you have an issue with a vender, please direct your concerns to them..... enough said. Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org From ward at gnu.org Sun May 4 16:49:22 2008 From: ward at gnu.org (Ward Vandewege) Date: Sun, 4 May 2008 10:49:22 -0400 Subject: [coreboot] [PATCH] artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines In-Reply-To: <20080504011757.30000.qmail@stuge.se> References: <1209779885.13448.16.camel@martr-gentoo.artec> <20080503015934.22789.qmail@stuge.se> <13426df10805022134o7f607847yc5cd59cefbb9a873@mail.gmail.com> <13426df10805022146s7b5d9e38v264870a629811ed8@mail.gmail.com> <20080504011102.28620.qmail@stuge.se> <20080504011757.30000.qmail@stuge.se> Message-ID: <20080504144922.GA18347@localdomain> On Sun, May 04, 2008 at 03:17:57AM +0200, Peter Stuge wrote: > On Sun, May 04, 2008 at 03:11:02AM +0200, Peter Stuge wrote: > > USB is on the GLIU in 5536 and not on any external PCI bus. > > But it still appears to be a PCI device, and it needs an interrupt. > > 32663C_lx_gx_pciconfig.pdf page 46-49 seems to suggest that USB is > always on INTD# IRQ11. This could be hardwired in LX/5536; It's not hardwired. Tinybios on the PCEngines boards puts USB (which is wired to INTD#) on interrupt 15. > GL packets > from USB will always trigger IRQ11. I _think_ this is set by the VSA blob. But what do I know :) > Or worse they will always trigger > PCI_INTD# meaning a well-designed board with 4 PCI slots, or a badly > designed board with less slots will always need to share somewhere. I don't think so. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From c-d.hailfinger.devel.2006 at gmx.net Sun May 4 17:10:07 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 04 May 2008 17:10:07 +0200 Subject: [coreboot] [RFC] Porting coreboot to Intel Atom (Silverthorne) & SCH US15W (Poulsbo) chipset In-Reply-To: References: Message-ID: <481DD1CF.8090101@gmx.net> Hi Ken, On 03.05.2008 00:56, Ken.Fuchs at bench.com wrote: > Intel Atom: > > http://en.wikipedia.org/wiki/Silverthorne_(CPU) > > http://download.intel.com/design/chipsets/embedded/prodbrf/319544.pdf > > http://download.intel.com/design/chipsets/embedded/datashts/319535.pdf > > Intel SCH US15W (combined northbridge, southbridge and graphics): > > http://download.intel.com/design/chipsets/embedded/prodbrf/319545.pdf > > http://download.intel.com/design/chipsets/embedded/datashts/319537.pdf > > Intel's "reference design" for these two is called the > "Menlow" platform. For more Intel codename definitions > concerning Mobile Internet Devices (MID), see: > > http://softwareblogs.intel.com/2008/04/01/atom-101-deciphering-the-intel > -codewords-around-mids/ > > Comments: > > Assuming that technical documentation is available for > Atom/Poulsbo, is it feasible to port coreboot (aka > LinuxBIOS) to Atom/Poulsbo? > Yes, if real technical documentation is available. The northbridge datasheet you posted mentions nothing about RAM init, so while we could bring up the processor and possibly a serial console, RAM init will be impossible unless you find actual RAM init documentation. Intel has such documentation, but they only give it to you if you have a very good business case (and even then it could take a year until you get the docs). > Given that this port will support both a new processor > and a new single support chip (as opposed to a northbridge > and southbridge chipset), what kind of development effort > might be required? > To be honest, I fear that doing the whole package (if you have all the needed docs) can take you roughly six months or more, depending on your firmware experience. > Is anyone else interested in such a port? > We (coreboot developers) are certainly interested in such a port and the EEEPC guys are interested in Intel mobile stuff as well. > Any suggestions and comments are welcome. > My first suggestion would be to investigate if you can find a matching platform from AMD. While Intel docs are difficult to get and sometimes even wrong, AMD provides fast access to good documentation and they even employ a few excellent engineers who work on coreboot and contribute all of their code (they contributed Barcelona processor support at the time it became available commercially). That's why I recommend AMD. Besides that, saying "we chose AMD because of coreboot" helps those nice AMD guys to justify and strengthen the development effort they invest into coreboot and everyone benefits. Regards, Carl-Daniel From svn at coreboot.org Sun May 4 17:23:21 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Sun, 4 May 2008 17:23:21 +0200 Subject: [coreboot] r176 - buildrom-devel Message-ID: Author: ward Date: 2008-05-04 17:23:20 +0200 (Sun, 04 May 2008) New Revision: 176 Modified: buildrom-devel/Makefile Log: Fix openvsa as payload - we were not including it in the LAR yet. This is a trivial patch. Signed-off-by: Ward Vandewege Acked-by: Ward Vandewege Modified: buildrom-devel/Makefile =================================================================== --- buildrom-devel/Makefile 2008-05-02 16:18:00 UTC (rev 175) +++ buildrom-devel/Makefile 2008-05-04 15:23:20 UTC (rev 176) @@ -94,7 +94,7 @@ @ $(STAGING_DIR)/bin/lar $(LAR_PAYLOAD_FLAGS-y) $(TARGET_ROM_FILE) $(SOURCE_DIR)/amd_vsa_lx_1.01.bin:blob/vsa endif ifeq ($(CONFIG_VSA_OPENVSA),y) - @ echo "Adding OpenVSA: TODO FIXME - let's actually implement this?" + @ $(STAGING_DIR)/bin/lar $(LAR_PAYLOAD_FLAGS-y) $(TARGET_ROM_FILE) $(OPENVSA_SRC_DIR)/vsa_lx.bin:blob/vsa endif @ for file in `ls $(ROM_DIR)`; do \ $(STAGING_DIR)/bin/lar $(LAR_PAYLOAD_FLAGS-y) $(TARGET_ROM_FILE) $(ROM_DIR)/$$file:$$file; \ From c-d.hailfinger.devel.2006 at gmx.net Sun May 4 17:27:27 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 04 May 2008 17:27:27 +0200 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <20080504103442.1440.qmail@stuge.se> References: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> <481C91F0.7000300@gmx.net> <13426df10805031141u6b6ed6f4i50e23cb9e57f7728@mail.gmail.com> <20080503222806.6468.qmail@stuge.se> <13426df10805031534q6f11abc0jef1861365165e84f@mail.gmail.com> <20080504014832.6182.qmail@stuge.se> <481D8885.9020605@gmx.net> <20080504103442.1440.qmail@stuge.se> Message-ID: <481DD5DF.30103@gmx.net> On 04.05.2008 12:34, Peter Stuge wrote: > On Sun, May 04, 2008 at 11:57:25AM +0200, Carl-Daniel Hailfinger wrote: > >>> I would also like to show off v3 in Berlin. >>> >> Depending on how much space we get, displaying more than two >> systems could pose real challenges. >> > > IIRC orgas are talked about one half infopoint. That is an area about > 1m wide and 60cm deep. I'd say up to six mainboards can fit if they > are small enough. My only problem is with displays - there is neither > room nor logistics for more than a single screen, and it's a little > boring to only see output from one board at a time. :\ > > I'll try to bring a 4-1 monitor switch so we can at least switch > around easily. Last year we had serial output from lots of boards on > the screen at the same time, we can do that again but it's more fun > to have VGA tint on power on. ;) > > I'll bring a PS/2 keyboard. > Great! I'll bring a USB keyboard. http://www.coreboot.org/LinuxTag_2008 has the info I collected so far. >>>> We are very, very close. >>>> >>> Dunno.. >>> >> I'd even say we have arrived. >> > > Strongly disagree. > > > >> With the right payload configuration, >> > > Nono, "arrived" means there are zero reservations. > For me, "arrived" means v3 is as good as v2. > I spent a good hour creating a v3 that did nothing at all on my > alix1c. Turned out to be a VSA blob formatting problem. It still > can not use the CF. > Can you explain what you mean with "VSA blob formatting problem"? > Neither buildrom nor v3 actually include VSA blob and payload.elf > when I run make. I forget where the zerofill option was, but that > wasn't done either. > Buildrom should include the VSA AFAIK. > Oh and stuffing everything into build/ feels so unusual. I go > looking for lar in all the wrong places (util) but that's just me. > > > >> these systems work fine (unless you want to use those pesky ISDN >> cards with horrible drivers). To be honest, I'd say we sidestep >> the ISDN issue completely by using any other miniPCI card for >> demos. >> > > Yes definately. But please keep in mind that the product is not done > until it has been so polished that users mistake it for a mirror. ;) > Right. The MFGPT issues definitely need to be solved. > Btw, what is a fun miniPCI-card? All I have is the POST card and two > wifi cards. > Video+Audio capture cards would be a very unusual but rewarding choice: Commell MP-878AS or similar. > Or a fun PCI card for that matter, for alix1c. > A DVB-T receiver card could fit, but I have no idea where you can get decent reception indoors. Regards, Carl-Daniel From svn at coreboot.org Sun May 4 17:45:13 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Sun, 4 May 2008 17:45:13 +0200 Subject: [coreboot] r177 - buildrom-devel Message-ID: Author: ward Date: 2008-05-04 17:45:12 +0200 (Sun, 04 May 2008) New Revision: 177 Modified: buildrom-devel/Makefile Log: Add openvsa to the DEPENDS-y list if it is used, to make sure that a distclean clears out the work/openvsa subdirectory. This is a trivial patch. Signed-off-by: Ward Vandewege Acked-by: Ward Vandewege Modified: buildrom-devel/Makefile =================================================================== --- buildrom-devel/Makefile 2008-05-04 15:23:20 UTC (rev 176) +++ buildrom-devel/Makefile 2008-05-04 15:45:12 UTC (rev 177) @@ -59,6 +59,12 @@ COREBOOT-$(CONFIG_COREBOOT_V2) = coreboot COREBOOT-$(CONFIG_COREBOOT_V3) = coreboot-v3 roms +# Add openvsa as a dependency if it is configured to be used; this makes sure +# that make distclean will clear out work/openvsa (see below) +ifeq ($(CONFIG_VSA_OPENVSA),y) + DEPENDS-y+=openvsa +endif + # Construct the list of packages we will be building PKGLIST = $(COREBOOT-y) $(DEPENDS-y) $(PAYLOAD-y) $(HOSTTOOLS-y) From svn at coreboot.org Sun May 4 17:53:44 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Sun, 4 May 2008 17:53:44 +0200 Subject: [coreboot] r178 - buildrom-devel/packages/geodevsa Message-ID: Author: ward Date: 2008-05-04 17:53:43 +0200 (Sun, 04 May 2008) New Revision: 178 Modified: buildrom-devel/packages/geodevsa/geodevsa.mk Log: Fix the padding issues Peter saw trying to build a v2 geode payload. This was my fault, an erroneous @ sneaked in here during r164. This is a trivial patch. Signed-off-by: Ward Vandewege Acked-by: Ward Vandewege Modified: buildrom-devel/packages/geodevsa/geodevsa.mk =================================================================== --- buildrom-devel/packages/geodevsa/geodevsa.mk 2008-05-04 15:45:12 UTC (rev 177) +++ buildrom-devel/packages/geodevsa/geodevsa.mk 2008-05-04 15:53:43 UTC (rev 178) @@ -31,7 +31,7 @@ $(GEODE_PADDED_VSA): $(GEODE_COMPRESSED_VSA) @ cp $< $@ @ (size=`stat -c %s $<`; count=`expr $(GEODE_VSA_SIZE) - $$size`; \ - @ dd if=/dev/zero bs=1 count=$$count >> $@ 2> /dev/null) + dd if=/dev/zero bs=1 count=$$count >> $@ 2> /dev/null) geodevsa: $(VSA_BUILD_TARGET) From ward at gnu.org Sun May 4 17:56:36 2008 From: ward at gnu.org (Ward Vandewege) Date: Sun, 4 May 2008 11:56:36 -0400 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <20080504103442.1440.qmail@stuge.se> References: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> <481C91F0.7000300@gmx.net> <13426df10805031141u6b6ed6f4i50e23cb9e57f7728@mail.gmail.com> <20080503222806.6468.qmail@stuge.se> <13426df10805031534q6f11abc0jef1861365165e84f@mail.gmail.com> <20080504014832.6182.qmail@stuge.se> <481D8885.9020605@gmx.net> <20080504103442.1440.qmail@stuge.se> Message-ID: <20080504155636.GA11038@localdomain> On Sun, May 04, 2008 at 12:34:42PM +0200, Peter Stuge wrote: > > With the right payload configuration, > > Nono, "arrived" means there are zero reservations. > > I spent a good hour creating a v3 that did nothing at all on my > alix1c. Turned out to be a VSA blob formatting problem. It still > can not use the CF. > > Neither buildrom nor v3 actually include VSA blob and payload.elf > when I run make. I forget where the zerofill option was, but that > wasn't done either. If you were trying to build v2 for the alix.1c using buildrom, that was broken - mea culpa. I fixed it in buildrom r178. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From mart.raudsepp at artecdesign.ee Sun May 4 17:58:27 2008 From: mart.raudsepp at artecdesign.ee (Mart Raudsepp) Date: Sun, 4 May 2008 18:58:27 +0300 (EEST) Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts Message-ID: <41632.84.50.57.154.1209916707.squirrel@www.artecdesign.ee> > The DBE62 does not really set up IRQs for USB, and that may be related > to why there is a power issue. Mart, note that alix1c sets up USB in > the PIR table and dbe62 does not. How are you getting USB to work at > all? I don't see anything on USB in alix1c code that isn't in DBE62 code. /* Chipset slots -- f.3 wires to B, and f.4 and f.5 wires to D. */ {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0}, Here it reads out that USB is at INTD#, and {L_PIRQD, M_PIRQD} sets it up, and I predict usb ohc and ehc intterupts are at IRQ9, as PIRQD is set to 9 there. DBE62 has had the same code since the start of when you copied the code over from v2. Just now after my patches it sets IRQ5 for them, as also reported by /proc/interrupts in linux. If I change PIRQD to some other value, it changes accordingly in /proc/interrupts as well. What was it about IRQ11 from the datasheet? Must it be set to IRQ11 to work properly or just set up to INTD# as done in both cases (fourth tuple being INTD) with the IRQ number not mattering? The first tuple for chipset/cs5536 line affects video, NAND flash and AEG engine on my observance (shared by these three), and either second or third affected audio. Mart Raudsepp Artec Design LLC From c-d.hailfinger.devel.2006 at gmx.net Sun May 4 18:45:30 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 04 May 2008 18:45:30 +0200 Subject: [coreboot] MFGPT issues: possible solution? Message-ID: <481DE82A.802@gmx.net> Hi, if you had problems with the Geode MFGPT timers in the past, can you please try Linux 2.6.25 or later and see if that fixes the issue? Regards, Carl-Daniel From rminnich at gmail.com Sun May 4 19:09:06 2008 From: rminnich at gmail.com (ron minnich) Date: Sun, 4 May 2008 10:09:06 -0700 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <41632.84.50.57.154.1209916707.squirrel@www.artecdesign.ee> References: <41632.84.50.57.154.1209916707.squirrel@www.artecdesign.ee> Message-ID: <13426df10805041009q760bb7a3rf960829e3c04da01@mail.gmail.com> On Sun, May 4, 2008 at 8:58 AM, Mart Raudsepp wrote: > > The DBE62 does not really set up IRQs for USB, and that may be related > > to why there is a power issue. Mart, note that alix1c sets up USB in > > the PIR table and dbe62 does not. How are you getting USB to work at > > all? > > I don't see anything on USB in alix1c code that isn't in DBE62 code. Mart, you're right, I misread the table. Now tell me how you're booting usb again :-) Thanks ron From tsylla at gmail.com Sun May 4 19:18:27 2008 From: tsylla at gmail.com (Tom Sylla) Date: Sun, 04 May 2008 13:18:27 -0400 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <13426df10805031534q6f11abc0jef1861365165e84f@mail.gmail.com> References: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> <481C91F0.7000300@gmx.net> <13426df10805031141u6b6ed6f4i50e23cb9e57f7728@mail.gmail.com> <20080503222806.6468.qmail@stuge.se> <13426df10805031534q6f11abc0jef1861365165e84f@mail.gmail.com> Message-ID: <481DEFE3.5050106@gmail.com> ron minnich wrote: > I think it's time to move to openvsa. I am not comfortable depending > on this binary blob. I think there's a problem but have no way to even > attempt to diagnose it. Peter, if you could, OpenVSA might be a good > thing for you to focus on for a little bit. Rather than all of us > working on the same thing, I think we need to divide and conquer. Well, it is not really a binary blob. You have the source for it. You could rebuild it if you wanted to for some reason, you just need MASM. OpenVSA is the right goal, but it is no more "open" than the VSA you are using now, except that the hurdle of compilation is lower. The hurdle of getting it working and well tested is much higher, however. From peter at stuge.se Sun May 4 19:25:04 2008 From: peter at stuge.se (Peter Stuge) Date: Sun, 4 May 2008 19:25:04 +0200 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <481DEFE3.5050106@gmail.com> References: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> <481C91F0.7000300@gmx.net> <13426df10805031141u6b6ed6f4i50e23cb9e57f7728@mail.gmail.com> <20080503222806.6468.qmail@stuge.se> <13426df10805031534q6f11abc0jef1861365165e84f@mail.gmail.com> <481DEFE3.5050106@gmail.com> Message-ID: <20080504172504.30846.qmail@stuge.se> On Sun, May 04, 2008 at 01:18:27PM -0400, Tom Sylla wrote: > MASM .. > OpenVSA > The hurdle of getting it working and well tested is much higher Neither is much fun. //Peter From vogel at ct.metrocast.net Sun May 4 19:42:15 2008 From: vogel at ct.metrocast.net (Robert Vogel) Date: Sun, 4 May 2008 13:42:15 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] References: <4818A556.6060900@gnu.org> <481A2C12.6020605@gmx.net> <481C97E6.6060507@gmx.net> Message-ID: <007501c8ae0e$3e596400$0200a8c0@JUNKNAME> ----- Original Message ----- From: "Richard M Stallman" To: "Carl-Daniel Hailfinger" Cc: ; Sent: Sunday, May 04, 2008 5:37 AM Subject: Re: [coreboot] [Fwd: Re: Contact Intel] > Drawing an ethical line thru a gray area is generally not > straightforward. Often it is not possible to find a unique best place > to draw it, and sometimes we should treat certain areas as > in-betweens. > > However, another network card > with exactly the same chips and the same firmware, but a different > model > number, may get firmware updates from the vendor. That would _not_ > qualify as ROM in your definition, at least as I understand it. > The technical side of the ROM equivalence question does not allow for > such distinctions. > > This is a gray area. I think we can treat it as barely acceptable if > we do not install firmware upgrades. But only barely, so we should > move to free firmware if possible. > It isn't only software or firmware that's of concern. There should be no compromise: everything should be transparent and therefor auditable. (You doubt the importance of this for voting machines ?) See http://it.slashdot.org/article.pl?sid=08/05/01/1233244 (snip) From peter at stuge.se Sun May 4 19:59:05 2008 From: peter at stuge.se (Peter Stuge) Date: Sun, 4 May 2008 19:59:05 +0200 Subject: [coreboot] Non-coding project help In-Reply-To: <481D6EDC.9020509@gnu.org> References: <4818A556.6060900@gnu.org> <481A2C12.6020605@gmx.net> <200805040007.48773.duwe@lst.de> <481D6EDC.9020509@gnu.org> Message-ID: <20080504175905.10947.qmail@stuge.se> On Sun, May 04, 2008 at 10:07:56AM +0200, arc wrote: > I wrote to you because I REALLY want to help you. Great! Are you subscribed to the mailing list? I'll stop sending you copies in that case. > I even ordered an OLPC because of the free bios in it. Very admirable. :) It does have free boot firmware, but note that it isn't coreboot anymore. They moved on to a completely custom firmware since they don't really need any of the flexibility coreboot offers. > I wrote to the coreboot list to ask how can I help you, how can I > make some pressure or whatever. > > I don't know how to write code but I still want to help so if you > had some suggestions for me I will accept them. We could use help also with other tasks than writing code I am sure. What are you good at? We could use a technical writer to make stellar documentation and tutorials. Are you knowledgeable in the low level technologies that coreboot deals with? If not, are you interested in learning about it? There are many opportunities and areas and we would be happy to help you. I guess what I'm saying is that we don't have a action list with non-coding tasks ready and that your ideas are welcome. //Peter From rms at gnu.org Sun May 4 22:07:40 2008 From: rms at gnu.org (Richard M Stallman) Date: Sun, 04 May 2008 16:07:40 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <200805040036.18350.duwe@lst.de> (message from Torsten Duwe on Sun, 4 May 2008 00:36:18 +0200) References: <4818A556.6060900@gnu.org> <200805040036.18350.duwe@lst.de> Message-ID: Well, sort of. From my experience, which very likely most on this list can share, BIOS is used to cover up defects in the hardware. Thus, it's a PR question, not a technical one. If that is true, maybe they are making much ado about little. Suppose there is a problem in the machine that would only affect users that make changes in the BIOS. That won't be very bad publicity. From svn at coreboot.org Sun May 4 22:08:34 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Sun, 4 May 2008 22:08:34 +0200 Subject: [coreboot] r675 - coreboot-v3/mainboard/pcengines/alix1c Message-ID: Author: ward Date: 2008-05-04 22:08:31 +0200 (Sun, 04 May 2008) New Revision: 675 Modified: coreboot-v3/mainboard/pcengines/alix1c/irq_tables.h Log: 00:0f.3 is the audio device, not usb. Also some whitespace cleaning. All of this is applies to comments only. This is a trivial patch. Signed-off-by: Ward Vandewege Acked-by: Ward Vandewege Modified: coreboot-v3/mainboard/pcengines/alix1c/irq_tables.h =================================================================== --- coreboot-v3/mainboard/pcengines/alix1c/irq_tables.h 2008-05-03 03:49:30 UTC (rev 674) +++ coreboot-v3/mainboard/pcengines/alix1c/irq_tables.h 2008-05-04 20:08:31 UTC (rev 675) @@ -61,11 +61,11 @@ * ------------------------------------------------- * AES 00:01.2 0a 01 A A * 3VPCI 00:0c.0 0a 01 A A - * eth0 00:0d.0 0b 01 A B - * mpci 00:0e.0 0a 01 A A - * usb 00:0f.3 0b 02 B B - * usb 00:0f.4 0b 04 D D - * usb 00:0f.5 0b 04 D D + * eth0 00:0d.0 0b 01 A B + * minipci 00:0e.0 0a 01 A A + * audio 00:0f.3 0b 02 B B + * usb (ohci) 00:0f.4 0b 04 D D + * usb (ehci) 00:0f.5 0b 04 D D * * The only swizzled interrupt is eth0, where INTA is wired to interrupt controller line B. */ From tsylla at gmail.com Sun May 4 22:14:07 2008 From: tsylla at gmail.com (Tom Sylla) Date: Sun, 04 May 2008 16:14:07 -0400 Subject: [coreboot] [PATCH] artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines In-Reply-To: <20080504011757.30000.qmail@stuge.se> References: <1209779885.13448.16.camel@martr-gentoo.artec> <20080503015934.22789.qmail@stuge.se> <13426df10805022134o7f607847yc5cd59cefbb9a873@mail.gmail.com> <13426df10805022146s7b5d9e38v264870a629811ed8@mail.gmail.com> <20080504011102.28620.qmail@stuge.se> <20080504011757.30000.qmail@stuge.se> Message-ID: <481E190F.50407@gmail.com> Peter Stuge wrote: > 32663C_lx_gx_pciconfig.pdf page 46-49 seems to suggest that USB is > always on INTD# IRQ11. This could be hardwired in LX/5536; GL packets > from USB will always trigger IRQ11. Or worse they will always trigger > PCI_INTD# meaning a well-designed board with 4 PCI slots, or a badly > designed board with less slots will always need to share somewhere. Just to clear up a few confusions in this thread: Nothing is hard-wired, not even the INTD for USB. All of the interrupt routing in 5536 is configured in the IRQ mapper in the MDD. See section 5.8 of the 5536 datasheet. USB is just input 2 to the unrestricted Y mapper. Lots of other southbridges have similar second-level PIC mappers (XPICs, etc) for their on-board devices. The "linkage" to INTD is done in VSA: http://dev.laptop.org/git?p=geode-vsa;a=blob;f=sysmgr/topology.c;h=71d1fe421ef06cc5a28143e6f98aab457bc75d54;hb=10f157122acaae414431c88a2403ed692453c960#l230 (note the Int Line value in that code is a flag for later: http://dev.laptop.org/git?p=geode-vsa;a=blob;f=legacy/cs5536.c;h=0bcf5f61e600f9be99249b9aecedf51a9ba7cac5;hb=10f157122acaae414431c88a2403ed692453c960#l207 ) As said later in this thread, USB needs to be a well-behaved PCI device and needs a Int Pin and Int Line. When the PCI config space for LX/5536 was defined, we had to pick a pin for the internal devices. VSA (config space) has to have something defined. That was INTD for USB (similarly INTB for audio). USB just gets stuck with whatever Int Line goes with INTD. Tom From joe at settoplinux.org Mon May 5 00:00:53 2008 From: joe at settoplinux.org (Joe) Date: Sun, 04 May 2008 18:00:53 -0400 Subject: [coreboot] =?utf-8?q?Does_the_Intel_3100_reboot=3F?= Message-ID: Ed this question is kind of for you but maybe anyone else can answer. I have had a few requests to get "reboot" or "shutdown -r now" working on the RCA RM4100. Linux goes to reboot it just fine but after the reset the memory starts to initialize and then it just hangs. I wondering if this code works on the 3100 for reboots? if (memory_initialized()) { asm volatile ("jmp __cpu_reset"); } If so I am a little confused by it. It is saying if memory_initialized() is true (anything but 0); do the next part. But if you look at the function memory_initialized(): static inline int memory_initialized(void) { u32 drc; drc = pci_read_config32(NB_DEV, DRC); return (drc & (1<<29)); } With the bit shift it is always going to be true (anything but 0). So, why the if statement? Am I making any sense? -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org From c-d.hailfinger.devel.2006 at gmx.net Mon May 5 00:03:33 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 05 May 2008 00:03:33 +0200 Subject: [coreboot] Does the Intel 3100 reboot? In-Reply-To: References: Message-ID: <481E32B5.9060700@gmx.net> On 05.05.2008 00:00, Joe wrote: > Ed this question is kind of for you but maybe anyone else can answer. I > have had a few requests to get "reboot" or "shutdown -r now" working on the > RCA RM4100. Linux goes to reboot it just fine but after the reset the > memory starts to initialize and then it just hangs. I wondering if this > code works on the 3100 for reboots? > > if (memory_initialized()) { > asm volatile ("jmp __cpu_reset"); > } > > If so I am a little confused by it. It is saying if memory_initialized() is > true (anything but 0); do the next part. But if you look at the function > memory_initialized(): > > static inline int memory_initialized(void) > { > u32 drc; > drc = pci_read_config32(NB_DEV, DRC); > return (drc & (1<<29)); > } > > With the bit shift it is always going to be true (anything but 0). So, why > the if statement? > It's only true if bit 29 of DRC is set. Regards, Carl-Daniel From joe at settoplinux.org Mon May 5 00:06:54 2008 From: joe at settoplinux.org (Joe) Date: Sun, 04 May 2008 18:06:54 -0400 Subject: [coreboot] =?utf-8?q?Does_the_Intel_3100_reboot=3F?= In-Reply-To: <481E32B5.9060700@gmx.net> References: <481E32B5.9060700@gmx.net> Message-ID: <182074836ac41aa8936b472c213f4935@imap.1and1.com> On Mon, 05 May 2008 00:03:33 +0200, Carl-Daniel Hailfinger wrote: > On 05.05.2008 00:00, Joe wrote: >> Ed this question is kind of for you but maybe anyone else can answer. I >> have had a few requests to get "reboot" or "shutdown -r now" working on > the >> RCA RM4100. Linux goes to reboot it just fine but after the reset the >> memory starts to initialize and then it just hangs. I wondering if this >> code works on the 3100 for reboots? >> >> if (memory_initialized()) { >> asm volatile ("jmp __cpu_reset"); >> } >> >> If so I am a little confused by it. It is saying if memory_initialized() > is >> true (anything but 0); do the next part. But if you look at the function >> memory_initialized(): >> >> static inline int memory_initialized(void) >> { >> u32 drc; >> drc = pci_read_config32(NB_DEV, DRC); >> return (drc & (1<<29)); >> } >> >> With the bit shift it is always going to be true (anything but 0). So, > why >> the if statement? >> > > It's only true if bit 29 of DRC is set. > My bad. Those & and | operators always get me... But does it allow the system to reboot? -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org From peter at stuge.se Mon May 5 02:06:31 2008 From: peter at stuge.se (Peter Stuge) Date: Mon, 5 May 2008 02:06:31 +0200 Subject: [coreboot] LX/5536 interrupts In-Reply-To: <20080504144922.GA18347@localdomain> References: <1209779885.13448.16.camel@martr-gentoo.artec> <20080503015934.22789.qmail@stuge.se> <13426df10805022134o7f607847yc5cd59cefbb9a873@mail.gmail.com> <13426df10805022146s7b5d9e38v264870a629811ed8@mail.gmail.com> <20080504011102.28620.qmail@stuge.se> <20080504011757.30000.qmail@stuge.se> <20080504144922.GA18347@localdomain> Message-ID: <20080505000631.12839.qmail@stuge.se> On Sun, May 04, 2008 at 10:49:22AM -0400, Ward Vandewege wrote: > > 32663C_lx_gx_pciconfig.pdf page 46-49 seems to suggest that USB > > is always on INTD# IRQ11. This could be hardwired in LX/5536; > > It's not hardwired. You are correct. I was reading the LX and 5536 databooks while Tom sent the last message so he has already covered some of this. Architecture overviews describe 5536 connected to the LX via PCI but the LX has no PCI interrupt balls so that must only be a logical description. 5536 is connected to the LX via the companion connection GLD on one of the two GLIUs in the LX. The 5536 has GPIO interrupts, which are used for the external PCI bus interrupt signals. That makes sense since the PCI_INTx signals connect to 5536 GPIO balls. But what about the virtual PCI devices? > > GL packets from USB will always trigger IRQ11. > > I _think_ this is set by the VSA blob. But what do I know :) I should have written that as a question. Anyway, you knew. (And interrupts are not neccessarily connected with any other GL activity from the USB module.) > > Or worse they will always trigger PCI_INTD# meaning a > > well-designed board with 4 PCI slots, or a badly designed board > > with less slots will always need to share somewhere. > > I don't think so. The 5536 databook does not mention interrupts at all in the USB module chapters, it's all in the interrupt controller chapters. Ron got his way, he had it coming. Reading geode-vsa shows that you're spot on, Ward. Hardwarewise, the USB module generates interrupts on what is called "Unrestricted Y Input 2" on the PIC. That input maps to one interrupt group between 1 and 15 per the PIC specific MSR at addr+20h bits 11:8. The interrupt is OR:ed with any other interrupts mapped to the same group. The group number corresponds to the classic 8259 IRQ number. Interrupt group 10 generates IRQ 10. "Unrestricted" because the input can be mapped to any IRQ 1-15. MFGPT and GPIO interrupts are on the Unrestricted Z inputs. Reset value for all interrupt group MSRs is 0, ie. disabled. Simple enough. Enter PCI emulation cr^W: VSA allows writes to PCI register 0x3c bits 7:0 (interrupt line) but not bits 15:8 (interrupt pin) for all virtual devices. Since virtual devices are internal and not actually connected to any PCI interrupt pin (the external signals on GPIO balls) that makes sense. sysmgr/pci_wr.c:Virtual_PCI_Write_Handler() handles writes to all PCI registers for virtual devices but the PIC specific MSR that controls the interrupt group mapping is not touched in this code path. sysmgr/topology.c has a struct for each virtual device that lists all implemented registers. All devices have register 0x3c and it's value is initialized to the interrupt pin (1..4) in bits 15:8 and somewhat surprisingly the Unrestricted Y Input number (1..15) rather than the interrupt line (1..15) in bits 7:0. Both USB devices have 0x00000402. legacy/cs5536.c:CS5536_Early_Init() goes through all 5536 functions and for those with non-zero bits 15:0 in register 0x3c the value is copied to the global Y_Sources array and cleared to 0 in the struct. Then a PCI trap is registered for writes to southbridge F0 register 0x5c-0x5d. (5530 PCI Interrupt Steering) When someone writes to 0x5c, legacy/cs5536.c:PCI_Interrupt_Steering() is called. On the first write the specified GPIO balls are set up to handle PCI_INTx signals, as mentioned the other day. On all writes it calls SYS_MAP_IRQ() with the value saved in Y_Sources for each IRQ in the specified interrupt steering map (ie. each IRQ assigned to a PCI_INTx pin/ball by this write to 0x5c) and now the Y2->IG mapping for the USB module (and all others) is finally written to the PIC specific MSR. VSA thus forces virtual PCI devices to only ever generate the same interrupts as external PCI devices. Which of the four PCI_INTx IRQs a device uses is determined by bits 15:8 of the 0x3C value in the corresponding PCI_HEADER_ENTRY struct in sysmgr/topology.c at VSA blob compile time. Dig out your hex editor if you want to change it. Whatever is written to 0x3c for virtual devices has no effect on which IRQ is generated. The register value is purely for show. //Peter From aaron.lwe at gmail.com Mon May 5 05:37:06 2008 From: aaron.lwe at gmail.com (aaron lwe) Date: Mon, 5 May 2008 11:37:06 +0800 Subject: [coreboot] QEMU Keyboard problems in v2 Message-ID: Hi, I have the same problem when using ADLO as the payload with qemu. I found qemu in coreboot-v2 didn't init keyboard while v3 did in setup_onboard of vga.c. And the ADLO code in bochs/bios/rombios.c defined COREBOOT which caused function keyboard_init did noting. Adding init_pc_keyboard(0x60, 0x64, &conf) for qemu in coreboot-v2 worked for me. From rms at gnu.org Mon May 5 08:04:43 2008 From: rms at gnu.org (Richard M Stallman) Date: Mon, 05 May 2008 02:04:43 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <007501c8ae0e$3e596400$0200a8c0@JUNKNAME> (vogel@ct.metrocast.net) References: <4818A556.6060900@gnu.org> <481A2C12.6020605@gmx.net> <481C97E6.6060507@gmx.net> <007501c8ae0e$3e596400$0200a8c0@JUNKNAME> Message-ID: It isn't only software or firmware that's of concern. There should be no compromise: everything should be transparent and therefor auditable. (You doubt the importance of this for voting machines ?) See http://it.slashdot.org/article.pl?sid=08/05/01/1233244 Voting machines are a very special case because you cannot trust the election authority to run them honestly. Using free software in these machines is not sufficient. I do not trust computers for voting. Ballots should be on paper so that a recount is possible. From rgreen at zeomega.com Mon May 5 08:40:18 2008 From: rgreen at zeomega.com (Ralph Green) Date: Mon, 05 May 2008 01:40:18 -0500 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: References: <4818A556.6060900@gnu.org> <481A2C12.6020605@gmx.net> <481C97E6.6060507@gmx.net> <007501c8ae0e$3e596400$0200a8c0@JUNKNAME> Message-ID: <481EABD2.4080907@zeomega.com> Howdy, I don't think I am seeing the whole thread here, so I may be commenting back to the wrong person. I have run local elections several times as the presiding election judge. In Texas, that is what they call the person who runs the election at the precinct level. I also do not trust most of the electronic voting systems. There are some good auditable ones out there, and I keep talking about those whenever I can. There are real benefits to the electronic systems and as long as we can keep transparency and auditability, then I say they are a good thing. It is kind of like the BIOS to me. It is not that I don't trust Award or Phoenix, but I like to option of an open honest BIOS and I think it will keep the others a little more honest. I have been looking for a good motherboard to try coreboot on and I look forward to using it. And for something off-topic, I tried the gNewSense 2.0 on two systems this weekend and it failed to install where Ubuntu went on fine. I am trying to figure out what was missing so I can file a bug report. Good day, Ralph Green, Jr. Richard M Stallman wrote: > It isn't only software or firmware that's of concern. There should be no > compromise: everything should be transparent and therefor auditable. (You > doubt the importance of this for voting machines ?) See > http://it.slashdot.org/article.pl?sid=08/05/01/1233244 > > Voting machines are a very special case because you cannot > trust the election authority to run them honestly. > Using free software in these machines is not sufficient. > > I do not trust computers for voting. Ballots should be on paper so > that a recount is possible. > From claus.gindhart at kontron.com Mon May 5 16:16:02 2008 From: claus.gindhart at kontron.com (Claus Gindhart) Date: Mon, 5 May 2008 16:16:02 +0200 Subject: [coreboot] Erase sst_fwhub blockwise, not the whole chip at once Message-ID: <200805051616.02962.claus.gindhart@kontron.com> Instead of wiping out the whole sst_fwhub chip at once, the device is erased and programmed block by block. Additionally, blocks, which already contain the desired data, are skipped. Signed-off-by: Claus Gindhart --- Mit freundlichen Gr??en / Best regards Claus Gindhart SW R&D Kontron Modular Computers phone :++49 (0)8341-803-374 mailto:claus.gindhart at kontron.com http://www.kontron.com Kontron Modular Computers GmbH Geschaeftsfuehrer / Managing Directors: Ulrich Gehrmann, Thomas Sabisch Sitz der Gesellschaft / Registered Office: Kaufbeuren, Rechtsform / Legal: GmbH Amtsgericht / Local District Court Kempten, HRB Nr. / Trade Register No. 6195 The information contained in this document is CONFIDENTIAL and property of Kontron. Any unauthorized review, use, disclosure or distribution is prohibited without express written consent of Kontron. If you are not the intended recipient, please contact the sender and destroy all copies of the original message and enclosed attachments. Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen und ist Eigentum von Kontron. Die Verwendung und Weitergabe von jeglichen Inhalten ist ohne ausdr?ckliche schriftliche Genehmigung von Kontron strikt untersagt. Wenn Sie diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten diese Mail und enthaltene Dokumente. -------------- next part -------------- A non-text attachment was scrubbed... Name: sst_fwhub_blockerase.patch Type: text/x-diff Size: 1860 bytes Desc: not available URL: From tiagomnm at gmail.com Mon May 5 16:39:36 2008 From: tiagomnm at gmail.com (Tiago Marques) Date: Mon, 5 May 2008 15:39:36 +0100 Subject: [coreboot] Fwd: Interested vendors [was: [Fwd: Re: Contact Intel]] In-Reply-To: References: <4818A556.6060900@gnu.org> <20080501124255.17921.qmail@stuge.se> Message-ID: ditto On 5/2/08, Richard M Stallman wrote: > Does coreboot have a web page with this list of vendors > and how they cooperate? Or even a partial list? > That could be used to put pressure on Intel and others > when they claim that everyone acts like them. > > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > From claus.gindhart at kontron.com Mon May 5 16:47:29 2008 From: claus.gindhart at kontron.com (Claus Gindhart) Date: Mon, 5 May 2008 16:47:29 +0200 Subject: [coreboot] Fix ambiguity, if a board is equipped with more than one chip Message-ID: <200805051647.29834.claus.gindhart@kontron.com> Currently there is an ongoing technology migration from FWH to SPI chips. For this reason some boards have multiple chips of different technologies onboard. Flashrom will probe for up to 3 chips; if more than one chip is detected, it will stop, and will prompt the user to choose one by the -c option, e.g. [root at localhost src]# ./flashrom ... Warning: Multiple flash chips detected SST49LF008A M25P16 at ICH9 Please fix this ambiguity by providing the -c | --chip command line option Signed-off-by: Claus Gindhart --- Mit freundlichen Gr??en / Best regards Claus Gindhart SW R&D Kontron Modular Computers phone :++49 (0)8341-803-374 mailto:claus.gindhart at kontron.com http://www.kontron.com Kontron Modular Computers GmbH Geschaeftsfuehrer / Managing Directors: Ulrich Gehrmann, Thomas Sabisch Sitz der Gesellschaft / Registered Office: Kaufbeuren, Rechtsform / Legal: GmbH Amtsgericht / Local District Court Kempten, HRB Nr. / Trade Register No. 6195 The information contained in this document is CONFIDENTIAL and property of Kontron. Any unauthorized review, use, disclosure or distribution is prohibited without express written consent of Kontron. If you are not the intended recipient, please contact the sender and destroy all copies of the original message and enclosed attachments. Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen und ist Eigentum von Kontron. Die Verwendung und Weitergabe von jeglichen Inhalten ist ohne ausdr?ckliche schriftliche Genehmigung von Kontron strikt untersagt. Wenn Sie diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten diese Mail und enthaltene Dokumente. -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_chip_ambiguity.patch Type: text/x-diff Size: 2930 bytes Desc: not available URL: From peter at stuge.se Mon May 5 16:47:08 2008 From: peter at stuge.se (Peter Stuge) Date: Mon, 5 May 2008 16:47:08 +0200 Subject: [coreboot] Erase sst_fwhub blockwise, and 1.0 call for input In-Reply-To: <200805051616.02962.claus.gindhart@kontron.com> References: <200805051616.02962.claus.gindhart@kontron.com> Message-ID: <20080505144708.681.qmail@stuge.se> On Mon, May 05, 2008 at 04:16:02PM +0200, Claus Gindhart wrote: > Instead of wiping out the whole sst_fwhub chip at once, the device > is erased and programmed block by block. > Additionally, blocks, which already contain the desired data, are > skipped. Hm, do we need/want to make these changes in every flash chip driver? I will investigate refactoring this logic into the calling layer instead. This will be a test of the block size info in flashchips.c. Please don't commit this just yet. No 1.0 so far. :( I'd appreciate many patches to the TESTED_ flags, still have some texts to go through (though I've changed some) and I'd like comments on the swapopts patch, as well as the fake chip entry vs. force-read command and the suggestion to always make the user confirm that the chipset probe is correct. (Not with -f though.) //Peter From eswierk at arastra.com Mon May 5 16:54:32 2008 From: eswierk at arastra.com (Ed Swierk) Date: Mon, 5 May 2008 07:54:32 -0700 Subject: [coreboot] Does the Intel 3100 reboot? In-Reply-To: <182074836ac41aa8936b472c213f4935@imap.1and1.com> References: <481E32B5.9060700@gmx.net> <182074836ac41aa8936b472c213f4935@imap.1and1.com> Message-ID: On Sun, May 4, 2008 at 3:06 PM, Joe wrote: > My bad. Those & and | operators always get me... > But does it allow the system to reboot? Yes, rebooting works on the Intel 3100 development board. Can you increase the log level to 9 and see exactly where your board is hanging? --Ed From peter at stuge.se Mon May 5 16:57:45 2008 From: peter at stuge.se (Peter Stuge) Date: Mon, 5 May 2008 16:57:45 +0200 Subject: [coreboot] Fix ambiguity, if a board is equipped with more than one chip In-Reply-To: <200805051647.29834.claus.gindhart@kontron.com> References: <200805051647.29834.claus.gindhart@kontron.com> Message-ID: <20080505145745.4992.qmail@stuge.se> Dear Claus, please confirm that you're subscribed to the list. On Mon, May 05, 2008 at 04:47:29PM +0200, Claus Gindhart wrote: > Flashrom will probe for up to 3 chips; if more than one chip is > detected, it will stop, and will prompt the user to choose one by > the -c option Thanks! I will rework the patch a little and resend later today. Remember to add yourself or your employer as copyright holder in your patches, not just add nice new features. That is important too. :) //Peter From c-d.hailfinger.devel.2006 at gmx.net Mon May 5 17:07:45 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 05 May 2008 17:07:45 +0200 Subject: [coreboot] Fix ambiguity, if a board is equipped with more than one chip In-Reply-To: <200805051647.29834.claus.gindhart@kontron.com> References: <200805051647.29834.claus.gindhart@kontron.com> Message-ID: <481F22C1.2050006@gmx.net> Hi Claus, thanks for the patch. Comments below. On 05.05.2008 16:47, Claus Gindhart wrote: > Currently there is an ongoing technology migration from FWH to SPI chips. For > this reason some boards have multiple chips of different technologies > onboard. Flashrom will probe for up to 3 chips; if more than one chip is > detected, it will stop, and will prompt the user to choose one by the -c > option, e.g. > Can we support probing for an arbitrary number of chips instead? By using an array flash[] instead of flash, flash2 and flash3 this could be done in a loop without limits on the number of detected chips. > [root at localhost src]# ./flashrom > ... > Warning: Multiple flash chips detected > SST49LF008A > M25P16 at ICH9 > Please fix this ambiguity by providing the > -c | --chip > command line option > What happens if there are multiple flash chips of the same technology? I have seen data sheets from Intel which suggest it is possible to have at least 4 FWH chips on a board (we don't support that right now). > Signed-off-by: Claus Gindhart > > Index: flashrom.c > =================================================================== > --- flashrom.c (revision 3275) > +++ flashrom.c (working copy) > @@ -3,7 +3,7 @@ > * > * Copyright (C) 2000 Silicon Integrated System Corporation > * Copyright (C) 2004 Tyan Corp > - * Copyright (C) 2005-2007 coresystems GmbH > + * Copyright (C) 2005-2007 coresystems GmbH > * > * This program is free software; you can redistribute it and/or modify > * it under the terms of the GNU General Public License as published by > @@ -127,7 +127,7 @@ > flash_baseaddr = (0xffffffff - size + 1); > #endif > > - /* If getpagesize() > size -> > + /* If getpagesize() > size -> > * "Can't mmap memory using /dev/mem: Invalid argument" > * This should never happen as we don't support any flash chips > * smaller than 4k or 8k (yet). > @@ -246,7 +246,13 @@ > uint8_t *buf; > unsigned long size; > FILE *image; > + > + /* The flash chip to be supported */ > struct flashchip *flash; > + > + /* Alternative flash chips, if more than one are found */ > + struct flashchip *flash2, *flash3; > + > struct flashchip *flash[]=malloc(sizeof(struct flashchip *)); > int opt; > int option_index = 0; > int read_it = 0, write_it = 0, erase_it = 0, verify_it = 0; > @@ -405,12 +411,35 @@ > > board_flash_enable(lb_vendor, lb_part); > > - if ((flash = probe_flash(flashchips)) == NULL) { > + /* Probe for maximum 3 types of onboard flashes */ > + flash = probe_flash(flashchips); > + if (flash == NULL) { > printf("No EEPROM/flash device found.\n"); > // FIXME: flash writes stay enabled! > exit(1); > + } else { > + flash2 = probe_flash(flash+1); > + if (flash2 != NULL) { > + flash3 = probe_flash(flash2+1); > + } > } > Please rewrite the chunk above as a loop together with realloc(). > > + /* If more than 1 flash chip is detected, we cannot continue */ > + if (flash2) > This check would have to be changed as well. Maybe introduce a separate flash chip counter? > + { > + printf("Warning: Multiple flash chips detected\n"); > + printf("%s\n",flash->name); > + printf("%s\n",flash2->name); > + if (flash3) printf("%s\n",flash3->name); > Use a loop here as well. > + > + printf( > + "Please fix this ambiguity by providing the\n" > + " -c | --chip \n" > + "command line option\n"); > + // FIXME: flash writes stay enabled! > You can drop that FIXME for now. It's in the wrong place and we also have seen that it can be harmful to restore flash writability to the state it had before running flashrom. > + exit(1); > + } > + > printf("Flash part is %s (%d KB).\n", flash->name, flash->total_size); > Could you move that info printing into the loop above? That would help users a lot when they try to identify the chip. > > if (!(read_it | write_it | verify_it | erase_it)) { > @@ -476,7 +505,7 @@ > } > > /* exclude range stuff. Nice idea, but at the moment it is only > - * supported in hardware by the pm49fl004 chips. > + * supported in hardware by the pm49fl004 chips. > * Instead of implementing this for all chips I suggest advancing > * it to the rom layout feature below and drop exclude range > * completely once all flash chips can do rom layouts. stepan > @@ -496,7 +525,7 @@ > exclude_end_page = exclude_end_position / flash->page_size; > // //////////////////////////////////////////////////////////// > > - // This should be moved into each flash part's code to do it > + // This should be moved into each flash part's code to do it > // cleanly. This does the job. > handle_romentries(buf, (uint8_t *) flash->virtual_memory); > > Overall, I really like what the patch does. I think one more iteration will be enough to get it merged. Regards, Carl-Daniel From jordan.crouse at amd.com Mon May 5 17:24:56 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 5 May 2008 09:24:56 -0600 Subject: [coreboot] alix1c PATA In-Reply-To: <13426df10805022149l4fb1db57kf4187e49776da68b@mail.gmail.com> References: <1209781918.13448.41.camel@martr-gentoo.artec> <1209786051.13448.56.camel@martr-gentoo.artec> <20080503034737.16401.qmail@stuge.se> <13426df10805022114t2106f37cw8c36c1322a3606c1@mail.gmail.com> <20080503044247.30728.qmail@stuge.se> <13426df10805022149l4fb1db57kf4187e49776da68b@mail.gmail.com> Message-ID: <20080505152456.GC8621@cosmic.amd.com> On 02/05/08 21:49 -0700, ron minnich wrote: > On Fri, May 2, 2008 at 9:42 PM, Peter Stuge wrote: > > On Fri, May 02, 2008 at 09:14:42PM -0700, ron minnich wrote: > > > I am having one more go at the interrupt mess on the alix1c > > > > I've just booted my 1c with v3, 2.6.25 and lxfb but the 5536 PATA > > driver does not want to play so it does not mount root. > > > > Is there a special trick? Does v3 disable PATA? > > (It is enabled by default from reset.) > > > > > > I'm afraid you are in new territory. I have only booted the CF. v3 > might disable pata if it enables the CF -- they are the same wires > IIRC. CF uses PATA. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From jordan.crouse at amd.com Mon May 5 17:26:39 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 5 May 2008 09:26:39 -0600 Subject: [coreboot] alix1c PATA In-Reply-To: References: <1209781918.13448.41.camel@martr-gentoo.artec> <1209786051.13448.56.camel@martr-gentoo.artec> <20080503034737.16401.qmail@stuge.se> <13426df10805022114t2106f37cw8c36c1322a3606c1@mail.gmail.com> <20080503044247.30728.qmail@stuge.se> <13426df10805022149l4fb1db57kf4187e49776da68b@mail.gmail.com> <20080503094833.13328.qmail@stuge.se> Message-ID: <20080505152639.GD8621@cosmic.amd.com> On 03/05/08 14:43 +0200, Ulf Jordan wrote: > > Driver 'sd' needs updating - please use bus_type methods > > Driver 'sr' needs updating - please use bus_type methods > > pata_cs5536: disabled by BIOS > > Hmm, I wonder if this is something coreboot has disabled or not enabled? > drivers/ata/pata_cs5536.c:244 tests a bit in the IDE config register of > CS5536. Can you try the legacy driver (ide/pci/amd74xx.c)? It sounds like the libata port brought over something distasteful. I've been using the old CS5536 driver for a very long time no with no problems. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From peter at stuge.se Mon May 5 17:49:03 2008 From: peter at stuge.se (Peter Stuge) Date: Mon, 5 May 2008 17:49:03 +0200 Subject: [coreboot] flashrom: Probe for up to 3 flash chips. [was: Fix ambiguity, if a board is equipped with more than one chip] In-Reply-To: <481F22C1.2050006@gmx.net> References: <200805051647.29834.claus.gindhart@kontron.com> <481F22C1.2050006@gmx.net> Message-ID: <20080505154903.20256.qmail@stuge.se> On Mon, May 05, 2008 at 05:07:45PM +0200, Carl-Daniel Hailfinger wrote: > Can we support probing for an arbitrary number of chips instead? I think that is overly ambitious. flashrom assumes that flash chips are top-aligned at 4GB so there will not be very many flash chips actually connected in a way that flashrom understands today. > By using an array flash[] instead of flash, flash2 and flash3 this > could be done in a loop without limits on the number of detected > chips. I thought [] too, but I set a fixed size. It's simple and cheap to increase the size should there be need, and the code will deal. > What happens if there are multiple flash chips of the same > technology? If same name, then same size and at same address => larger problem. > Overall, I really like what the patch does. Yes, me too. Claus, can you please test the attached patch and send an Acked-by line it if it works, then I'll commit. Thanks! //Peter -------------- next part -------------- flashrom: Probe for up to 3 flash chips. Currently there is an ongoing technology migration from LPC/FWH to SPI chips. For this reason some boards have multiple chips of different technologies onboard. This patch makes flashrom probe for up to 3 chips and if more than one chip is found, flashrom exits, asking the user to specify -c. [root at localhost src]# ./flashrom ... Multiple flash chips were detected: SST49LF008A M25P16 at ICH9 Please specify which chip to use with the -c option. Signed-off-by: Claus Gindhart Signed-off-by: Peter Stuge Index: flashrom.multichip/flashrom.c =================================================================== --- flashrom.multichip/flashrom.c (revision 3277) +++ flashrom.multichip/flashrom.c (working copy) @@ -246,11 +246,12 @@ uint8_t *buf; unsigned long size; FILE *image; - struct flashchip *flash; + /* Probe for up to three flash chips. */ + struct flashchip *flash, *flashes[3]; int opt; int option_index = 0; int read_it = 0, write_it = 0, erase_it = 0, verify_it = 0; - int ret = 0; + int ret = 0, i; static struct option long_options[] = { {"read", 0, 0, 'r'}, @@ -405,12 +406,27 @@ board_flash_enable(lb_vendor, lb_part); - if ((flash = probe_flash(flashchips)) == NULL) { + for (i = 0; i < ARRAY_SIZE(flashes); i++) { + flashes[i] = probe_flash(i ? flashes[i - 1] + 1 : flashchips); + if (!flashes[i]) + for (i++; i < ARRAY_SIZE(flashes); i++) + flashes[i] = NULL; + } + + if (flashes[1]) { + printf("Multiple flash chips were detected:"); + for (i = 0; i < ARRAY_SIZE(flashes) && flashes[i]; i++) + printf(" %s", flashes[i]->name); + printf("\nPlease specify which chip to use with the -c option.\n"); + exit(1); + } else if (!flashes[0]) { printf("No EEPROM/flash device found.\n"); // FIXME: flash writes stay enabled! exit(1); } + flash = flashes[0]; + printf("Flash part is %s (%d KB).\n", flash->name, flash->total_size); if (TEST_OK_MASK != (flash->tested & TEST_OK_MASK)) { printf("===\n"); From c-d.hailfinger.devel.2006 at gmx.net Mon May 5 18:00:13 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 05 May 2008 18:00:13 +0200 Subject: [coreboot] flashrom: Probe for up to 3 flash chips. [was: Fix ambiguity, if a board is equipped with more than one chip] In-Reply-To: <20080505154903.20256.qmail@stuge.se> References: <200805051647.29834.claus.gindhart@kontron.com> <481F22C1.2050006@gmx.net> <20080505154903.20256.qmail@stuge.se> Message-ID: <481F2F0D.5050303@gmx.net> On 05.05.2008 17:49, Peter Stuge wrote: > On Mon, May 05, 2008 at 05:07:45PM +0200, Carl-Daniel Hailfinger wrote: > >> Can we support probing for an arbitrary number of chips instead? >> > > I think that is overly ambitious. > > flashrom assumes that flash chips are top-aligned at 4GB so there > will not be very many flash chips actually connected in a way that > flashrom understands today. > Yes, but it would be more future-proof(TM). >> By using an array flash[] instead of flash, flash2 and flash3 this >> could be done in a loop without limits on the number of detected >> chips. >> > > I thought [] too, but I set a fixed size. It's simple and cheap to > increase the size should there be need, and the code will deal. > OK. >> What happens if there are multiple flash chips of the same >> technology? >> > > If same name, then same size and at same address => larger problem. > Same name, same size, different address... unsupported by flashrom right now, but we could change that. Easily, even. The only problem is finding hardware to test. >> Overall, I really like what the patch does. >> > > Yes, me too. > > > Claus, can you please test the attached patch and send an Acked-by > line it if it works, then I'll commit. > > Thanks! > > > //Peter > > Index: flashrom.multichip/flashrom.c > =================================================================== > --- flashrom.multichip/flashrom.c (revision 3277) > +++ flashrom.multichip/flashrom.c (working copy) > @@ -246,11 +246,12 @@ > uint8_t *buf; > unsigned long size; > FILE *image; > - struct flashchip *flash; > + /* Probe for up to three flash chips. */ > + struct flashchip *flash, *flashes[3]; > int opt; > int option_index = 0; > int read_it = 0, write_it = 0, erase_it = 0, verify_it = 0; > - int ret = 0; > + int ret = 0, i; > > static struct option long_options[] = { > {"read", 0, 0, 'r'}, > @@ -405,12 +406,27 @@ > > board_flash_enable(lb_vendor, lb_part); > > - if ((flash = probe_flash(flashchips)) == NULL) { > + for (i = 0; i < ARRAY_SIZE(flashes); i++) { > + flashes[i] = probe_flash(i ? flashes[i - 1] + 1 : flashchips); > + if (!flashes[i]) > + for (i++; i < ARRAY_SIZE(flashes); i++) > + flashes[i] = NULL; > This for loop could be replaced by an early memset, making the code clearer. > + } > + > + if (flashes[1]) { > + printf("Multiple flash chips were detected:"); > + for (i = 0; i < ARRAY_SIZE(flashes) && flashes[i]; i++) > + printf(" %s", flashes[i]->name); > + printf("\nPlease specify which chip to use with the -c option.\n"); > + exit(1); > + } else if (!flashes[0]) { > printf("No EEPROM/flash device found.\n"); > // FIXME: flash writes stay enabled! > exit(1); > } > > + flash = flashes[0]; > + > printf("Flash part is %s (%d KB).\n", flash->name, flash->total_size); > Move that statement into the loop above, please. > if (TEST_OK_MASK != (flash->tested & TEST_OK_MASK)) { > printf("===\n"); Otherwise, this is Acked-by: Carl-Daniel Hailfinger Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Mon May 5 18:06:53 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 05 May 2008 18:06:53 +0200 Subject: [coreboot] flashrom: Probe for up to 3 flash chips. [was: Fix ambiguity, if a board is equipped with more than one chip] In-Reply-To: <481F2F0D.5050303@gmx.net> References: <200805051647.29834.claus.gindhart@kontron.com> <481F22C1.2050006@gmx.net> <20080505154903.20256.qmail@stuge.se> <481F2F0D.5050303@gmx.net> Message-ID: <481F309D.4000003@gmx.net> On 05.05.2008 18:00, Carl-Daniel Hailfinger wrote: > On 05.05.2008 17:49, Peter Stuge wrote: > >> >> Index: flashrom.multichip/flashrom.c >> =================================================================== >> --- flashrom.multichip/flashrom.c (revision 3277) >> +++ flashrom.multichip/flashrom.c (working copy) >> @@ -246,11 +246,12 @@ >> uint8_t *buf; >> unsigned long size; >> FILE *image; >> - struct flashchip *flash; >> + /* Probe for up to three flash chips. */ >> + struct flashchip *flash, *flashes[3]; >> int opt; >> int option_index = 0; >> int read_it = 0, write_it = 0, erase_it = 0, verify_it = 0; >> - int ret = 0; >> + int ret = 0, i; >> >> static struct option long_options[] = { >> {"read", 0, 0, 'r'}, >> @@ -405,12 +406,27 @@ >> >> board_flash_enable(lb_vendor, lb_part); >> >> - if ((flash = probe_flash(flashchips)) == NULL) { >> + for (i = 0; i < ARRAY_SIZE(flashes); i++) { >> + flashes[i] = probe_flash(i ? flashes[i - 1] + 1 : flashchips); >> + if (!flashes[i]) >> Missing break. This loop runs ARRAY_SIZE(flashchips) times even if the first probe failed. >> + for (i++; i < ARRAY_SIZE(flashes); i++) >> + flashes[i] = NULL; >> >> > > This for loop could be replaced by an early memset, making the code clearer. > > >> + } >> + >> + if (flashes[1]) { >> + printf("Multiple flash chips were detected:"); >> + for (i = 0; i < ARRAY_SIZE(flashes) && flashes[i]; i++) >> + printf(" %s", flashes[i]->name); >> + printf("\nPlease specify which chip to use with the -c option.\n"); >> + exit(1); >> + } else if (!flashes[0]) { >> printf("No EEPROM/flash device found.\n"); >> // FIXME: flash writes stay enabled! >> exit(1); >> } >> >> + flash = flashes[0]; >> + >> printf("Flash part is %s (%d KB).\n", flash->name, flash->total_size); >> >> > > Move that statement into the loop above, please. > > >> if (TEST_OK_MASK != (flash->tested & TEST_OK_MASK)) { >> printf("===\n"); >> > > > Otherwise, this is > Acked-by: Carl-Daniel Hailfinger > > > Regards, > Carl-Daniel From peter at stuge.se Mon May 5 18:29:38 2008 From: peter at stuge.se (Peter Stuge) Date: Mon, 5 May 2008 18:29:38 +0200 Subject: [coreboot] flashrom: Probe for up to 3 flash chips. [was: Fix ambiguity, if a board is equipped with more than one chip] In-Reply-To: <481F309D.4000003@gmx.net> <481F2F0D.5050303@gmx.net> References: <200805051647.29834.claus.gindhart@kontron.com> <481F22C1.2050006@gmx.net> <20080505154903.20256.qmail@stuge.se> <481F2F0D.5050303@gmx.net> <481F309D.4000003@gmx.net> <200805051647.29834.claus.gindhart@kontron.com> <481F22C1.2050006@gmx.net> <20080505154903.20256.qmail@stuge.se> <481F2F0D.5050303@gmx.net> Message-ID: <20080505162938.32740.qmail@stuge.se> On Mon, May 05, 2008 at 06:00:13PM +0200, Carl-Daniel Hailfinger wrote: > > flashrom assumes that flash chips are top-aligned at 4GB so there > > will not be very many flash chips actually connected in a way that > > flashrom understands today. > > Yes, but it would be more future-proof(TM). That future will require many other changes, so I prefer keeping it simple for now. > >> What happens if there are multiple flash chips of the same > >> technology? > > > > If same name, then same size and at same address => larger problem. > > Same name, same size, different address... unsupported by flashrom > right now, but we could change that. When we do, let's revisit the "unlimited" flash chip count. > > - if ((flash = probe_flash(flashchips)) == NULL) { > > + for (i = 0; i < ARRAY_SIZE(flashes); i++) { > > + flashes[i] = probe_flash(i ? flashes[i - 1] + 1 : flashchips); > > + if (!flashes[i]) > > + for (i++; i < ARRAY_SIZE(flashes); i++) > > + flashes[i] = NULL; > > > > This for loop could be replaced by an early memset, making the code clearer. Sure. Matter of taste. > > printf("Flash part is %s (%d KB).\n", flash->name, flash->total_size); > > Move that statement into the loop above, please. No need since the probe() function always prints the name of the found flash chip. > Otherwise, this is > Acked-by: Carl-Daniel Hailfinger Thanks, but I'm still waiting for Claus to test that it works on his hardware. On Mon, May 05, 2008 at 06:06:53PM +0200, Carl-Daniel Hailfinger wrote: > >> + for (i = 0; i < ARRAY_SIZE(flashes); i++) { > >> + flashes[i] = probe_flash(i ? flashes[i - 1] + 1 : flashchips); > >> + if (!flashes[i]) > >> > > Missing break. This loop runs ARRAY_SIZE(flashchips) times even if the > first probe failed. > > >> + for (i++; i < ARRAY_SIZE(flashes); i++) > >> + flashes[i] = NULL; The same counter is used to clear remaining entries so that the outer loop also is finished after the first failed probe. //Peter From peter at stuge.se Mon May 5 18:32:19 2008 From: peter at stuge.se (Peter Stuge) Date: Mon, 5 May 2008 18:32:19 +0200 Subject: [coreboot] alix1c PATA In-Reply-To: <20080505152639.GD8621@cosmic.amd.com> References: <1209781918.13448.41.camel@martr-gentoo.artec> <1209786051.13448.56.camel@martr-gentoo.artec> <20080503034737.16401.qmail@stuge.se> <13426df10805022114t2106f37cw8c36c1322a3606c1@mail.gmail.com> <20080503044247.30728.qmail@stuge.se> <13426df10805022149l4fb1db57kf4187e49776da68b@mail.gmail.com> <20080503094833.13328.qmail@stuge.se> <20080505152639.GD8621@cosmic.amd.com> Message-ID: <20080505163219.1052.qmail@stuge.se> On Mon, May 05, 2008 at 09:26:39AM -0600, Jordan Crouse wrote: > > > pata_cs5536: disabled by BIOS > > > > Hmm, I wonder if this is something coreboot has disabled or not > > enabled? > > drivers/ata/pata_cs5536.c:244 tests a bit in the IDE config > > register of CS5536. > > Can you try the legacy driver (ide/pci/amd74xx.c)? Will try later. > It sounds like the libata port brought over something distasteful. > I've been using the old CS5536 driver for a very long time no with > no problems. Regardless, no bit should indicate that PATA is disabled. Particularly surprising since IDE is enabled from reset. //Peter From jordan.crouse at amd.com Mon May 5 18:50:47 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 5 May 2008 10:50:47 -0600 Subject: [coreboot] alix1c PATA In-Reply-To: <20080505163219.1052.qmail@stuge.se> References: <1209781918.13448.41.camel@martr-gentoo.artec> <1209786051.13448.56.camel@martr-gentoo.artec> <20080503034737.16401.qmail@stuge.se> <13426df10805022114t2106f37cw8c36c1322a3606c1@mail.gmail.com> <20080503044247.30728.qmail@stuge.se> <13426df10805022149l4fb1db57kf4187e49776da68b@mail.gmail.com> <20080503094833.13328.qmail@stuge.se> <20080505152639.GD8621@cosmic.amd.com> <20080505163219.1052.qmail@stuge.se> Message-ID: <20080505165047.GB19792@cosmic.amd.com> On 05/05/08 18:32 +0200, Peter Stuge wrote: > On Mon, May 05, 2008 at 09:26:39AM -0600, Jordan Crouse wrote: > > > > pata_cs5536: disabled by BIOS > > > > > > Hmm, I wonder if this is something coreboot has disabled or not > > > enabled? > > > drivers/ata/pata_cs5536.c:244 tests a bit in the IDE config > > > register of CS5536. > > > > Can you try the legacy driver (ide/pci/amd74xx.c)? > > Will try later. > > > > It sounds like the libata port brought over something distasteful. > > I've been using the old CS5536 driver for a very long time no with > > no problems. > > Regardless, no bit should indicate that PATA is disabled. > > Particularly surprising since IDE is enabled from reset. The enable bits for the AMD74XX controller (which the 5536 uses) are in PCI config byte 0x40. bit 1 is the enable bit for port 0 and bit 0 is the enable bit for port 1. I have just tried both db800 and norwich in v2 with the legacy AMD5536 driver and both worked (well, db800 puked, but for other reasons). Here's the boot log: AMD5536: IDE controller (0x1022:0x209a rev 0x01) at PCI slot 0000:00:0f.2 AMD5536: not 100% native mode: will probe irqs later AMD5536: 0000:00:0f.2 (rev 01) UDMA100 controller ide0: BM-DMA at 0x1ca0-0x1ca7, BIOS settings: hda:pio, hdb:pio AMD5536: IDE port disabled The last line is the secondary bus being disabled. I looked at the libata driver, and it seems to be doing the right thing - reading 0x40 and checking bit 1. So I checked the code: in v2, src/southbridge/amd/cs5536/cs5536_ide.c handles the honors. So long story short - this is possibly something that just never got brought over to v3? Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From rminnich at gmail.com Mon May 5 19:01:11 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 5 May 2008 10:01:11 -0700 Subject: [coreboot] alix1c PATA In-Reply-To: <20080505165047.GB19792@cosmic.amd.com> References: <1209781918.13448.41.camel@martr-gentoo.artec> <20080503034737.16401.qmail@stuge.se> <13426df10805022114t2106f37cw8c36c1322a3606c1@mail.gmail.com> <20080503044247.30728.qmail@stuge.se> <13426df10805022149l4fb1db57kf4187e49776da68b@mail.gmail.com> <20080503094833.13328.qmail@stuge.se> <20080505152639.GD8621@cosmic.amd.com> <20080505163219.1052.qmail@stuge.se> <20080505165047.GB19792@cosmic.amd.com> Message-ID: <13426df10805051001h35254d0ah24c97156f8d61a5d@mail.gmail.com> You mean this I suppose? #define IDE_CFG 0x40 #define CHANEN (1L << 1) #define PWB (1L << 14) #define CABLE (1L << 16) #define IDE_DTC 0x48 #define IDE_CAST 0x4C #define IDE_ETC 0x50 static void ide_init(struct device *dev) { uint32_t ide_cfg; printk_spew("cs5536_ide: %s\n", __FUNCTION__); /* GPIO and IRQ setup are handled in the main chipset code. */ // Enable the channel and Post Write Buffer // NOTE: Only 32-bit writes to the data buffer are allowed when PWB is set ide_cfg = pci_read_config32(dev, IDE_CFG); ide_cfg |= CHANEN | PWB; pci_write_config8(dev, IDE_CFG, ide_cfg); } That code is there in v3. It depends on this: if (sb->enable_ide) ide_init(dev); but that's there too: mainboard/artecgroup/dbe62/dts: enable_ide = "1"; mainboard/pcengines/alix1c/dts: enable_ide = "1"; I'm not near a board. Do you see this message: printk(BIOS_DEBUG, "cs5536_ide: %s\n", __func__); ron From jordan.crouse at amd.com Mon May 5 18:54:05 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 5 May 2008 10:54:05 -0600 Subject: [coreboot] alix1c PATA In-Reply-To: <20080505165047.GB19792@cosmic.amd.com> References: <1209786051.13448.56.camel@martr-gentoo.artec> <20080503034737.16401.qmail@stuge.se> <13426df10805022114t2106f37cw8c36c1322a3606c1@mail.gmail.com> <20080503044247.30728.qmail@stuge.se> <13426df10805022149l4fb1db57kf4187e49776da68b@mail.gmail.com> <20080503094833.13328.qmail@stuge.se> <20080505152639.GD8621@cosmic.amd.com> <20080505163219.1052.qmail@stuge.se> <20080505165047.GB19792@cosmic.amd.com> Message-ID: <20080505165405.GA9450@cosmic.amd.com> On 05/05/08 10:50 -0600, Jordan Crouse wrote: > On 05/05/08 18:32 +0200, Peter Stuge wrote: > > On Mon, May 05, 2008 at 09:26:39AM -0600, Jordan Crouse wrote: > > > > > pata_cs5536: disabled by BIOS > > > > > > > > Hmm, I wonder if this is something coreboot has disabled or not > > > > enabled? > > > > drivers/ata/pata_cs5536.c:244 tests a bit in the IDE config > > > > register of CS5536. > > > > > > Can you try the legacy driver (ide/pci/amd74xx.c)? > > > > Will try later. > > > > > > > It sounds like the libata port brought over something distasteful. > > > I've been using the old CS5536 driver for a very long time no with > > > no problems. > > > > Regardless, no bit should indicate that PATA is disabled. > > > > Particularly surprising since IDE is enabled from reset. > > The enable bits for the AMD74XX controller (which the 5536 uses) are > in PCI config byte 0x40. bit 1 is the enable bit for port 0 and bit 0 > is the enable bit for port 1. > > I have just tried both db800 and norwich in v2 with the legacy AMD5536 driver > and both worked (well, db800 puked, but for other reasons). Here's the > boot log: > > AMD5536: IDE controller (0x1022:0x209a rev 0x01) at PCI slot 0000:00:0f.2 > AMD5536: not 100% native mode: will probe irqs later > AMD5536: 0000:00:0f.2 (rev 01) UDMA100 controller > ide0: BM-DMA at 0x1ca0-0x1ca7, BIOS settings: hda:pio, hdb:pio > AMD5536: IDE port disabled > > The last line is the secondary bus being disabled. > > I looked at the libata driver, and it seems to be doing the right thing - > reading 0x40 and checking bit 1. > > So I checked the code: in v2, src/southbridge/amd/cs5536/cs5536_ide.c > handles the honors. > > So long story short - this is possibly something that just never got > brought over to v3? Followup - the code is in v3, but is gated by sb->enable_ide, which defaults to 0. I presume thats where your problem lies. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From c-d.hailfinger.devel.2006 at gmx.net Mon May 5 19:10:07 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 05 May 2008 19:10:07 +0200 Subject: [coreboot] flashrom: Probe for up to 3 flash chips. [was: Fix ambiguity, if a board is equipped with more than one chip] In-Reply-To: <20080505162938.32740.qmail@stuge.se> References: <200805051647.29834.claus.gindhart@kontron.com> <481F22C1.2050006@gmx.net> <20080505154903.20256.qmail@stuge.se> <481F2F0D.5050303@gmx.net> <481F309D.4000003@gmx.net> <200805051647.29834.claus.gindhart@kontron.com> <481F22C1.2050006@gmx.net> <20080505154903.20256.qmail@stuge.se> <481F2F0D.5050303@gmx.net> <20080505162938.32740.qmail@stuge.se> Message-ID: <481F3F6F.8040009@gmx.net> On 05.05.2008 18:29, Peter Stuge wrote: > On Mon, May 05, 2008 at 06:00:13PM +0200, Carl-Daniel Hailfinger wrote: > > >>> printf("Flash part is %s (%d KB).\n", flash->name, flash->total_size); >>> >> Move that statement into the loop above, please. >> > > No need since the probe() function always prints the name of the > found flash chip. > Either the statement is redundant and we remove it completely, or we move it inside the loop. IMO requiring the user to look up flash chip size from a model number is not the way to go. >> Otherwise, this is >> Acked-by: Carl-Daniel Hailfinger >> > > Thanks, but I'm still waiting for Claus to test that it works on his > hardware. > > > On Mon, May 05, 2008 at 06:06:53PM +0200, Carl-Daniel Hailfinger wrote: > >>>> + for (i = 0; i < ARRAY_SIZE(flashes); i++) { >>>> + flashes[i] = probe_flash(i ? flashes[i - 1] + 1 : flashchips); >>>> + if (!flashes[i]) >>>> >>>> >> Missing break. This loop runs ARRAY_SIZE(flashchips) times even if the >> first probe failed. >> >> >>>> + for (i++; i < ARRAY_SIZE(flashes); i++) >>>> + flashes[i] = NULL; >>>> > > The same counter is used to clear remaining entries so that the outer > loop also is finished after the first failed probe. > I see. Regards, Carl-Daniel From Marc.Jones at amd.com Mon May 5 19:10:03 2008 From: Marc.Jones at amd.com (Marc Jones) Date: Mon, 05 May 2008 11:10:03 -0600 Subject: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts In-Reply-To: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> References: <13426df10805022251n10200c45r507b93865f76dbd1@mail.gmail.com> Message-ID: <481F3F6B.8080003@amd.com> ron minnich wrote: > Further, what interrupts are safe to use? We keep reusing 10, 11, 5, > etc. Any reason not to use (e.g.) 6 or 13 or 12? > Is there a Geode rule I need to know? This is not a Geode rule but you should take care when trying to share PCI interrupts (level) with legacy (edge) devices. 6 - floppy 13 - FPU 12 - ps/2 mouse Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From mylesgw at gmail.com Mon May 5 19:14:03 2008 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 5 May 2008 11:14:03 -0600 Subject: [coreboot] QEMU Keyboard problems in v2 In-Reply-To: References: Message-ID: <000f01c8aed3$6bda24d0$0023040a@chimp> > Hi, > > I have the same problem when using ADLO as the payload with qemu. > I found qemu in coreboot-v2 didn't init keyboard while v3 did in > setup_onboard of vga.c. > And the ADLO code in bochs/bios/rombios.c defined COREBOOT which > caused function keyboard_init did noting. > > Adding init_pc_keyboard(0x60, 0x64, &conf) for qemu in coreboot-v2 > worked for me. Aaron, Where did you add it? Is there a reason why we don't commit the change? It seems like Coreboot-v2 used to initialize the keyboard correctly, otherwise ADLO wouldn't have disabled the keyboard init when compiled for Coreboot. I wonder why Jordan gets it to work unpatched. Thanks, Myles From Marc.Jones at amd.com Mon May 5 19:06:05 2008 From: Marc.Jones at amd.com (Marc Jones) Date: Mon, 05 May 2008 11:06:05 -0600 Subject: [coreboot] [PATCH] artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines In-Reply-To: <13426df10805022146s7b5d9e38v264870a629811ed8@mail.gmail.com> References: <1209779885.13448.16.camel@martr-gentoo.artec> <20080503015934.22789.qmail@stuge.se> <13426df10805022134o7f607847yc5cd59cefbb9a873@mail.gmail.com> <13426df10805022146s7b5d9e38v264870a629811ed8@mail.gmail.com> Message-ID: <481F3E7D.5050106@amd.com> ron minnich wrote: > (I'm hoping someone will do this :-) > > One issue I'm having is that the hfcpci card (or driver) can't > tolerate shared interrupts. > But we have shared interrupts on the various cs5536 boards, since we > put USB interrupt info in the table. > > To allow us to have non-shared interrupts for all devices, we need to > get the USB interrupts out of the PIR table. They are not really > routed via the standard IRQ router anyway -- they are internal -- and > don't need to share interrupt #s with the other devices that are > actually routed via the interrupt routing hardware. > > Put simply, having the USB f.3,4,5 devices in the PIR table works, but > is really a bit of a mistake. > > OK, where do we put the IRQ info for the USB devices? In the DTS for > the cs5536. > > SO in DTS for the cs5536 we need three more properties, > usbf3 > usbf4 > usbf5 > > with reasonable settings for them. Then in the chipset init code, we > need to see if these are set and, if so, set the IRQ line in the f.3, > f.4, and f.5 devices. > > If this is confusing I can explain in more detail, but later, I'm > tired, and the ISDN card just locked up again. How can such a simple > driver have so many failure modes? Oh, wait, it's not simple, sigh. > > but, short form: on the cs5536, USB interrupts should not be described > in the PIR table, but via settings derived from dts. They should be > initialized in cs5536 setup code, no in the PIR setup code. That will > allow us to have non-shared interrupts on the various PCI slots on, > e.g., alix1c, and allow broken drivers like hfcpci to work. > > ron > Ron, I understand that you are addressing a problem but I have to disagree that the 5536 USB controllers shouldn't be in the PIR table. Even if you change the internal devices IRQs you should still put them in the table. As for changing the IRQs. In PCI there is no interrupt contention. The interrupts are level triggered. You should be able to put them all on a single IRQ. It is easier to debug device driver issues if they are on separate IRQs but that should be the only advantage. If IRQs are not being serviced correctly and fast enough that is a Linux driver issue. For your specific problems; Do you have a USB device plugged in? If not there should be little to no activity from USB. How can that be the problem? Since you do have a problem with that mainboard and card, I think that any changes you make should be only for that mainboard. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From rminnich at gmail.com Mon May 5 19:17:34 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 5 May 2008 10:17:34 -0700 Subject: [coreboot] [PATCH] artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines In-Reply-To: <481F3E7D.5050106@amd.com> References: <1209779885.13448.16.camel@martr-gentoo.artec> <20080503015934.22789.qmail@stuge.se> <13426df10805022134o7f607847yc5cd59cefbb9a873@mail.gmail.com> <13426df10805022146s7b5d9e38v264870a629811ed8@mail.gmail.com> <481F3E7D.5050106@amd.com> Message-ID: <13426df10805051017m49d585adj23297ad3a7f63beb@mail.gmail.com> On Mon, May 5, 2008 at 10:06 AM, Marc Jones wrote: > > I understand that you are addressing a problem but I have to disagree that > the 5536 USB controllers shouldn't be in the PIR table. Even if you change > the internal devices IRQs you should still put them in the table. I think you are right as usual. I'm wrong. > For your specific problems; Do you have a USB device plugged in? If not > there should be little to no activity from USB. How can that be the problem? > Since you do have a problem with that mainboard and card, I think that any > changes you make should be only for that mainboard. agree. The real issue anyway is that ISDN driver, I just can't stand to look at it :-) But I have to. ron From rminnich at gmail.com Mon May 5 19:18:40 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 5 May 2008 10:18:40 -0700 Subject: [coreboot] alix1c PATA In-Reply-To: <20080505165405.GA9450@cosmic.amd.com> References: <1209786051.13448.56.camel@martr-gentoo.artec> <13426df10805022114t2106f37cw8c36c1322a3606c1@mail.gmail.com> <20080503044247.30728.qmail@stuge.se> <13426df10805022149l4fb1db57kf4187e49776da68b@mail.gmail.com> <20080503094833.13328.qmail@stuge.se> <20080505152639.GD8621@cosmic.amd.com> <20080505163219.1052.qmail@stuge.se> <20080505165047.GB19792@cosmic.amd.com> <20080505165405.GA9450@cosmic.amd.com> Message-ID: <13426df10805051018k44f3f795o102567f72c76f3c5@mail.gmail.com> On Mon, May 5, 2008 at 9:54 AM, Jordan Crouse wrote: > Followup - the code is in v3, but is gated by sb->enable_ide, which > defaults to 0. I presume thats where your problem lies. > defaults to 0 but is overridden to 1 on the 1c:mainboard/pcengines/alix1c/dts: enable_ide = "1"; ron From paulepanter at users.sourceforge.net Mon May 5 19:41:47 2008 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Mon, 05 May 2008 19:41:47 +0200 Subject: [coreboot] Fwd: Interested vendors [was: [Fwd: Re: Contact Intel]] In-Reply-To: References: <4818A556.6060900@gnu.org> <20080501124255.17921.qmail@stuge.se> Message-ID: <1210009307.3572.3.camel@mattotaupa.wohnung.familie-menzel.net> Dear everybody, Am Montag, den 05.05.2008, 15:39 +0100 schrieb Tiago Marques: > ditto > > > On 5/2/08, Richard M Stallman wrote: > > Does coreboot have a web page with this list of vendors > > and how they cooperate? Or even a partial list? Please take a look again at Peter?s message [1]: [2], [3]. Thanks, Paul [1] http://www.coreboot.org/pipermail/coreboot/2008-May/034082.html [2] http://www.coreboot.org/Sponsors [3] http://www.coreboot.org/Products -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From tiagomnm at gmail.com Mon May 5 20:39:02 2008 From: tiagomnm at gmail.com (Tiago Marques) Date: Mon, 5 May 2008 19:39:02 +0100 Subject: [coreboot] Fwd: Interested vendors [was: [Fwd: Re: Contact Intel]] In-Reply-To: <1210009307.3572.3.camel@mattotaupa.wohnung.familie-menzel.net> References: <4818A556.6060900@gnu.org> <20080501124255.17921.qmail@stuge.se> <1210009307.3572.3.camel@mattotaupa.wohnung.familie-menzel.net> Message-ID: Among development sponsors there is only Google, shouldn't AMD, for instance, be there also? Best regards, Tiago Marques On 5/5/08, Paul Menzel wrote: > Dear everybody, > > > Am Montag, den 05.05.2008, 15:39 +0100 schrieb Tiago Marques: > > > ditto > > > > > > On 5/2/08, Richard M Stallman wrote: > > > Does coreboot have a web page with this list of vendors > > > and how they cooperate? Or even a partial list? > > > Please take a look again at Peter's message [1]: [2], [3]. > > > Thanks, > > Paul > > > [1] http://www.coreboot.org/pipermail/coreboot/2008-May/034082.html > [2] http://www.coreboot.org/Sponsors > [3] http://www.coreboot.org/Products > > From svn at coreboot.org Mon May 5 21:29:06 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Mon, 5 May 2008 21:29:06 +0200 Subject: [coreboot] r179 - buildrom-devel/packages/coreboot-v2 Message-ID: Author: jcrouse Date: 2008-05-05 21:29:04 +0200 (Mon, 05 May 2008) New Revision: 179 Modified: buildrom-devel/packages/coreboot-v2/coreboot.inc Log: Add a missing @ to quiet coreboot-v2 clean. Trivial. Signed-off-by: Jordan Crouse Acked-by: Jordan Crouse Modified: buildrom-devel/packages/coreboot-v2/coreboot.inc =================================================================== --- buildrom-devel/packages/coreboot-v2/coreboot.inc 2008-05-04 15:53:43 UTC (rev 178) +++ buildrom-devel/packages/coreboot-v2/coreboot.inc 2008-05-05 19:29:04 UTC (rev 179) @@ -150,7 +150,7 @@ @ rm -f $(CBV2_STAMP_DIR)/.configured @ rm -f $(CBV2_PAYLOAD_TARGET) ifneq ($(wildcard $(CBV2_BUILD_DIR)/Makefile),) - $(MAKE) -C $(CBV2_BUILD_DIR) clean > /dev/null 2>&1; + @ $(MAKE) -C $(CBV2_BUILD_DIR) clean > /dev/null 2>&1; endif @ rm -f $(CBV2_OUTPUT) From svn at coreboot.org Mon May 5 22:50:58 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Mon, 5 May 2008 22:50:58 +0200 Subject: [coreboot] r3278 - trunk/coreboot-v2/targets/supermicro/h8dmr Message-ID: Author: ward Date: 2008-05-05 22:50:58 +0200 (Mon, 05 May 2008) New Revision: 3278 Modified: trunk/coreboot-v2/targets/supermicro/h8dmr/Config.lb Log: This patch changes the payload path for Config.lb; this board is supported by buildrom and this bit was forgotten during r3092. This is a trivial patch. Signed-off-by: Ward Vandewege Acked-by: Ward Vandewege Modified: trunk/coreboot-v2/targets/supermicro/h8dmr/Config.lb =================================================================== --- trunk/coreboot-v2/targets/supermicro/h8dmr/Config.lb 2008-05-03 04:34:37 UTC (rev 3277) +++ trunk/coreboot-v2/targets/supermicro/h8dmr/Config.lb 2008-05-05 20:50:58 UTC (rev 3278) @@ -39,27 +39,11 @@ # option ROM_IMAGE_SIZE=0x15800 option XIP_ROM_SIZE=0x40000 option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" -# payload ../../../payloads/tg3--ide_disk.zelf -# payload ../../../payloads/filo.elf -# payload ../../../payloads/filo_mem.elf -# payload ../../../payloads/filo.zelf -# payload ../../../payloads/tg3--filo_hda2.zelf -# payload ../../../payloads/tg3.zelf -# payload ../../../../payloads/tg3_vga.zelf -# payload ../../../../payloads/tg3--filo_hda2_vga.zelf -# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf -# payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf - payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf -# payload ../../../payloads/tg3_com2.zelf -# payload ../../../payloads/e1000--filo.zelf -# payload ../../../payloads/tg3--e1000--filo.zelf -# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf -# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf -# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf + payload ../payload.elf end romimage "fallback" - option USE_FAILOVER_IMAGE=0 + option USE_FAILOVER_IMAGE=0 option USE_FALLBACK_IMAGE=1 # option ROM_IMAGE_SIZE=0x13800 # option ROM_IMAGE_SIZE=0x19800 @@ -67,28 +51,7 @@ # option ROM_IMAGE_SIZE=0x15800 option XIP_ROM_SIZE=0x40000 option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" -# payload ../../../payloads/tg3--ide_disk.zelf -# payload ../../../payloads/filo.elf -# payload ../../../payloads/filo_mem.elf -# payload ../../../payloads/filo.zelf -# payload ../../../payloads/tg3--filo_hda2.zelf -# payload ../../../payloads/tg3.zelf -# payload ../../../../payloads/tg3_vga.zelf -# payload ../../../../payloads/memtest -# payload ../../../../payloads/e1000_vga.zelf -# payload ../../../../payloads/tg3--filo_hda2_vga.zelf -# payload ../../../../payloads/filo_hda.zelf -# payload ../../../../payloads/adlo.elf -# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf -# payload ../../../../payloads/forcedeth_mcp55_filo_hda2.zelf - payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf -# payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf -# payload ../../../payloads/tg3_com2.zelf -# payload ../../../payloads/e1000--filo.zelf -# payload ../../../payloads/tg3--e1000--filo.zelf -# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf -# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf -# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf + payload ../payload.elf end romimage "failover" From svn at coreboot.org Mon May 5 22:54:02 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Mon, 5 May 2008 22:54:02 +0200 Subject: [coreboot] r180 - buildrom-devel/config/platforms Message-ID: Author: ward Date: 2008-05-05 22:54:01 +0200 (Mon, 05 May 2008) New Revision: 180 Modified: buildrom-devel/config/platforms/supermicro-h8dmr.conf Log: Bump up revision number for the supermicro H8DMR build so that it uses r3278 which has a Config.lb that's fixed for buildrom. This is a trivial patch. Signed-off-by: Ward Vandewege Acked-by: Ward Vandewege Modified: buildrom-devel/config/platforms/supermicro-h8dmr.conf =================================================================== --- buildrom-devel/config/platforms/supermicro-h8dmr.conf 2008-05-05 19:29:04 UTC (rev 179) +++ buildrom-devel/config/platforms/supermicro-h8dmr.conf 2008-05-05 20:54:01 UTC (rev 180) @@ -41,7 +41,7 @@ CBV2_CONFIG=Config.lb CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=h8dmr -CBV2_TAG=3092 +CBV2_TAG=3278 # FILO configuration From jordan.crouse at amd.com Mon May 5 23:54:48 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 5 May 2008 15:54:48 -0600 Subject: [coreboot] buildrom: cleanup package includes (updated) Message-ID: <20080505215447.GE9450@cosmic.amd.com> Attached is an updated version of the patch I sent before that streamined the .mk files that are included in buildrom. This version is updated with the latest and greatest from Myles and everybody. Tested with all payloads + coreinfo, and hd8mr + kernel (I'm going to test the other platforms with kernel, but I didn't want to wait around for them to finish building). Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: patsubst-new.patch Type: text/x-diff Size: 20992 bytes Desc: not available URL: From jordan.crouse at amd.com Mon May 5 23:57:00 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 5 May 2008 15:57:00 -0600 Subject: [coreboot] buildrom: Fix a parser error in coreboot.inc Message-ID: <20080505215700.GF9450@cosmic.amd.com> This fixes a parse error and adds informative messages when option ROMs are built in to coreboot. This only happens with the ga-2761gxdk, which is why we haven't seen this before. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-ga_2761gxdk.patch Type: text/x-diff Size: 1585 bytes Desc: not available URL: From rms at gnu.org Tue May 6 00:06:43 2008 From: rms at gnu.org (Richard M Stallman) Date: Mon, 05 May 2008 18:06:43 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <481EABD2.4080907@zeomega.com> (message from Ralph Green on Mon, 05 May 2008 01:40:18 -0500) References: <4818A556.6060900@gnu.org> <481A2C12.6020605@gmx.net> <481C97E6.6060507@gmx.net> <007501c8ae0e$3e596400$0200a8c0@JUNKNAME> <481EABD2.4080907@zeomega.com> Message-ID: You as an election judge may be honest, but not all of them are. At least one election in Mexico was stolen by computer manipulation by the central election commission. It appears that Bush stole the 2004 election through fiddling with the electro-optical vote counting machines. I've seen evidence that other elections in the US were stolen thru voting machine manipulation. Whatever the technology, we cannot rely on the election authorities to be honest. So we must reject technology that forces us to rely on this. From rminnich at gmail.com Tue May 6 00:36:17 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 5 May 2008 15:36:17 -0700 Subject: [coreboot] LX/5536 interrupts In-Reply-To: <20080505000631.12839.qmail@stuge.se> References: <1209779885.13448.16.camel@martr-gentoo.artec> <20080503015934.22789.qmail@stuge.se> <13426df10805022134o7f607847yc5cd59cefbb9a873@mail.gmail.com> <13426df10805022146s7b5d9e38v264870a629811ed8@mail.gmail.com> <20080504011102.28620.qmail@stuge.se> <20080504011757.30000.qmail@stuge.se> <20080504144922.GA18347@localdomain> <20080505000631.12839.qmail@stuge.se> Message-ID: <13426df10805051536r4e28efa5ndb348b86a6870527@mail.gmail.com> Peter, I owe you a beer next time we meet. That's some might nice detective work ... ron From mylesgw at gmail.com Tue May 6 01:01:55 2008 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 5 May 2008 17:01:55 -0600 Subject: [coreboot] buildrom: Fix a parser error in coreboot.inc In-Reply-To: <20080505215700.GF9450@cosmic.amd.com> References: <20080505215700.GF9450@cosmic.amd.com> Message-ID: <004301c8af04$041ae2e0$0023040a@chimp> > -----Original Message----- > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] > On Behalf Of Jordan Crouse > Sent: Monday, May 05, 2008 3:57 PM > To: coreboot at coreboot.org > Subject: [coreboot] buildrom: Fix a parser error in coreboot.inc > > This fixes a parse error and adds informative messages when option ROMs > are built in to coreboot. This only happens with the ga-2761gxdk, > which is why we haven't seen this before. Acked-by: Myles Watson Thanks, Myles From mylesgw at gmail.com Tue May 6 01:02:06 2008 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 5 May 2008 17:02:06 -0600 Subject: [coreboot] buildrom: cleanup package includes (updated) In-Reply-To: <20080505215447.GE9450@cosmic.amd.com> References: <20080505215447.GE9450@cosmic.amd.com> Message-ID: <004401c8af04$0ac742a0$0023040a@chimp> > -----Original Message----- > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] > On Behalf Of Jordan Crouse > Sent: Monday, May 05, 2008 3:55 PM > To: coreboot at coreboot.org > Subject: [coreboot] buildrom: cleanup package includes (updated) > > Attached is an updated version of the patch I sent before that > streamined the .mk files that are included in buildrom. This version > is updated with the latest and greatest from Myles and everybody. > > Tested with all payloads + coreinfo, and hd8mr + kernel (I'm going to > test the other platforms with kernel, but I didn't want to wait around > for them to finish building). Acked-by: Myles Watson Thanks, Myles From jordan.crouse at amd.com Tue May 6 01:29:48 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 5 May 2008 17:29:48 -0600 Subject: [coreboot] buildrom: cleanup package includes (updated) In-Reply-To: <004401c8af04$0ac742a0$0023040a@chimp> References: <20080505215447.GE9450@cosmic.amd.com> <004401c8af04$0ac742a0$0023040a@chimp> Message-ID: <20080505232948.GG9450@cosmic.amd.com> On 05/05/08 17:02 -0600, Myles Watson wrote: > > > > -----Original Message----- > > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] > > On Behalf Of Jordan Crouse > > Sent: Monday, May 05, 2008 3:55 PM > > To: coreboot at coreboot.org > > Subject: [coreboot] buildrom: cleanup package includes (updated) > > > > Attached is an updated version of the patch I sent before that > > streamined the .mk files that are included in buildrom. This version > > is updated with the latest and greatest from Myles and everybody. > > > > Tested with all payloads + coreinfo, and hd8mr + kernel (I'm going to > > test the other platforms with kernel, but I didn't want to wait around > > for them to finish building). > > Acked-by: Myles Watson Thanks - I am going to wait on this until tomorrow. Coreboot-v2 + kernel failed on 13 of 17 targets (and only 3 failures are due to missing .mk files). I don't know if this is becuase of my patch, my test harness, or something else. Either way, it is best that I hold off until I can debug it more fully. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From jordan.crouse at amd.com Tue May 6 01:57:39 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 5 May 2008 17:57:39 -0600 Subject: [coreboot] buildrom: cleanup package includes (updated) In-Reply-To: <20080505232948.GG9450@cosmic.amd.com> References: <20080505215447.GE9450@cosmic.amd.com> <004401c8af04$0ac742a0$0023040a@chimp> <20080505232948.GG9450@cosmic.amd.com> Message-ID: <20080505235739.GH9450@cosmic.amd.com> On 05/05/08 17:29 -0600, Jordan Crouse wrote: > On 05/05/08 17:02 -0600, Myles Watson wrote: > > > > > > > -----Original Message----- > > > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] > > > On Behalf Of Jordan Crouse > > > Sent: Monday, May 05, 2008 3:55 PM > > > To: coreboot at coreboot.org > > > Subject: [coreboot] buildrom: cleanup package includes (updated) > > > > > > Attached is an updated version of the patch I sent before that > > > streamined the .mk files that are included in buildrom. This version > > > is updated with the latest and greatest from Myles and everybody. > > > > > > Tested with all payloads + coreinfo, and hd8mr + kernel (I'm going to > > > test the other platforms with kernel, but I didn't want to wait around > > > for them to finish building). > > > > Acked-by: Myles Watson > > Thanks - I am going to wait on this until tomorrow. Coreboot-v2 + kernel > failed on 13 of 17 targets (and only 3 failures are due to missing .mk files). > I don't know if this is becuase of my patch, my test harness, or something > else. Either way, it is best that I hold off until I can debug it more > fully. I had a second to build one of the failing platforms at random (s2882), and the error ended up being that the kernel was too big for the ROM. I'm going to go ahead and re-run the entire test with verboseness turned on over night to get a clear picture of which platforms need love. Jordan --- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From kevin at koconnor.net Tue May 6 03:36:26 2008 From: kevin at koconnor.net (Kevin O'Connor) Date: Mon, 5 May 2008 21:36:26 -0400 Subject: [coreboot] legacy bios support and coreboot Message-ID: <20080506013626.GA25706@morn.localdomain> Hi, As has been discussed a couple of times on this list, I have been working on a project to port the "bochs bios" to gcc. The code is available via git at: http://git.linuxtogo.org/ This email is to go through some of the details of what the "legacybios" code provides and how it works. Note that the code in "legacybios" really is a port of "bochs bios", so the two code bases have nearly identical coverage. There are three major parts of the "legacybios" code: * 16bit software interrupt handlers * 16bit hardware interrupt handlers * "post" code The 16bit software interrupt handlers can be thought of as a code library. They provide a series of standard 'functions' that boot loaders and operating systems may call. Granted, the calling convention of the bios is a bit odd - instead of using 'call' insns one uses 'int' insns, parameters are generally passed in registers, and everything runs in 16bit mode. Fortunately, there is plenty of documentation describing what these calls do - implementing the library itself is not technically challenging. The 16bit hardware interrupts are like the 16bit software interrupt handlers, except they get called by hardware instead of software. The "legacybios" code only implements enough hardware interrupts to make the standard software interrupt handlers work properly. Finally, the "post" code is used to initialize the system and start the boot process. This "post" code is compiled in 32bit mode. It is possible to enter the bios in 16bit mode (by jumping to 0xf000:0xfff0), however all this will do is transition the cpu to 32bit mode and then call the 32bit "post" code. The "post" stage does the following tasks: * minimal hardware detection and init * option rom scan and execution * pci init * various bios table creation * transition to 16bit mode and raise int19 to start boot process I suspect the hardware detection and initialization does not have much overlap with coreboot. The most important part of this section is the IDE initialization and disk scan. (Some other code, for example keyboard init, may be redundant when used with coreboot.) The option rom scan and execution allows the bios code to call out to additional system roms. The "post" stage runs in 32bit mode, but the option roms are called in 16bit mode - the "legacybios" code simply transitions to/from 16bit mode to make these calls. The option rom code is executed natively on the processor. The "pci init" code looks to be redundant with what coreboot already provides. The code in "legacybios" seems to be intel northbride/soutbridge specific. The "legacybios" code provides the following memory tables: * bda, ebda, and 0xf0000 segment * e820 memory map * PIR * mptable * smbios * acpi tables (rsdp, rsdt, fadt, facs, dsdt, madt) Some old DOS programs make assumptions about specific memory locations in the first 1Meg of ram. The "legacybios" code fills in these areas to make these old programs happy - in short they are the "bios data area" at 0x00000 - 0x00500, the "extended bios data area" at 0x9fc00 - 0xa0000, and some hardcoded locations in the 0xf0000 bios segment itself. The bios working storage areas (in bda and ebda) and the 16bit interrupt vector table is also setup (part of the bda). The e820 map is populated by assuming a linear memory layout. The maximum memory is passed into the bios (via a cmos variable, see below), and the resulting e820 map is then generated. The PIR table is simply hard coded at compile time. The mptable code attempts to auto-detect the number of cpus in the system (by raising a "broadcast SIPI"). The rest of the table is then filled with hardcoded information. The smbios and acpi tables use the passed in memory size, the detected cpu count, and info from the "cpuid" insn - the rest is hardcoded. It is not clear to me how much of the acpi/mptable/smbios code is reusable on real hardware. It is possible that most of the info in these tables is irrelevant, and the "legacybios" code may therefore be a good starting point. However, it may also be simpler to have coreboot just pass these tables in. Hardware assumptions that "legacybios" makes: * code loaded into 0xf0000, and execution jumps to it (16bit or 32bit) * cmos settings * ioports (debug port) * hardware specific code (ram shadowing, apm) As mentioned earlier, the bios needs to be loaded into memory starting at 0xf0000 and its init code needs to be run. The rom code is 64K in size (compressed with lzma it is currently 23K). Certain settings are passed into the bios via cmos variables - qemu and bochs emulators use this to select certain settings. The main variables needed are: memory size, floppy drive type, and boot order. The system also uses variables for harddrive geometry and "equipment list flags", but I believe the code can be extended to autodetect these settings. Both qemu and bochs implement a debug port (0x0403) that allows the bios to send debug messages to the console. This will not, of course, work on real hardware. It should be possible to send the debug messages to a serial port. The remainder of the ioports used by "legacybios" look to be standard hardware. Some of the hardware accesses made by the "legacybios" code appear to be specific to hardware in the emulator. The code attempts to enable ram shadowing of the memory segment at 0xf00000 - it does this so that it can put acpi/mptable/smbios tables into that area. After it is complete, it attempts to disable writes to that region. The code sequence looks to be specific to intel north/southbridges. It isn't necessary to disable writes to 0xf0000 (though it would be nice), but it is necessary to have the ability to alter that memory. Also, there are stubs in "legacybios" for apm support - should one want to implement this on real hardware the appropriate power saving code would need to be implemented. Comments? -Kevin From mylesgw at gmail.com Tue May 6 03:39:01 2008 From: mylesgw at gmail.com (Myles Watson) Date: Mon, 5 May 2008 19:39:01 -0600 Subject: [coreboot] buildrom: cleanup package includes (updated) In-Reply-To: <20080505235739.GH9450@cosmic.amd.com> References: <20080505215447.GE9450@cosmic.amd.com> <004401c8af04$0ac742a0$0023040a@chimp> <20080505232948.GG9450@cosmic.amd.com> <20080505235739.GH9450@cosmic.amd.com> Message-ID: <000001c8af19$f6bfd770$1a02a8c0@chimp> > -----Original Message----- > From: Jordan Crouse [mailto:jordan.crouse at amd.com] > Sent: Monday, May 05, 2008 5:58 PM > To: Myles Watson > Cc: coreboot at coreboot.org > Subject: Re: buildrom: cleanup package includes (updated) > > On 05/05/08 17:29 -0600, Jordan Crouse wrote: > > On 05/05/08 17:02 -0600, Myles Watson wrote: > > > > > > > > > > -----Original Message----- > > > > From: coreboot-bounces at coreboot.org [mailto:coreboot- > bounces at coreboot.org] > > > > On Behalf Of Jordan Crouse > > > > Sent: Monday, May 05, 2008 3:55 PM > > > > To: coreboot at coreboot.org > > > > Subject: [coreboot] buildrom: cleanup package includes (updated) > > > > > > > > Attached is an updated version of the patch I sent before that > > > > streamined the .mk files that are included in buildrom. This > version > > > > is updated with the latest and greatest from Myles and everybody. > > > > > > > > Tested with all payloads + coreinfo, and hd8mr + kernel (I'm going > to > > > > test the other platforms with kernel, but I didn't want to wait > around > > > > for them to finish building). > > > > > > Acked-by: Myles Watson > > > > Thanks - I am going to wait on this until tomorrow. Coreboot-v2 + > kernel > > failed on 13 of 17 targets (and only 3 failures are due to missing .mk > files). > > I don't know if this is becuase of my patch, my test harness, or > something > > else. Either way, it is best that I hold off until I can debug it more > > fully. > > I had a second to build one of the failing platforms at random (s2882), > and > the error ended up being that the kernel was too big for the ROM. I'm > going > to go ahead and re-run the entire test with verboseness turned on over > night to get a clear picture of which platforms need love. > Several of the platforms have kernels that have never fit for me. I always figured the problem was my broken toolchain. I only test that changes don't break things that were working. Myles From aaron.lwe at gmail.com Tue May 6 03:40:49 2008 From: aaron.lwe at gmail.com (aaron lwe) Date: Tue, 6 May 2008 09:40:49 +0800 Subject: [coreboot] QEMU Keyboard problems in v2 In-Reply-To: <000f01c8aed3$6bda24d0$0023040a@chimp> References: <000f01c8aed3$6bda24d0$0023040a@chimp> Message-ID: > Where did you add it? I attached a patch, it adds pc keyboard init function for qemu in case payloads assume coreboot has done the job. Signed-off-by: Aaron Lwe > it seems like Coreboot-v2 used to initialize the keyboard correctly, otherwise > ADLO wouldn't have disabled the keyboard init when compiled for Coreboot. yes, ADLO assumes coreboot has inited keyboard so it omits that. > I wonder why Jordan gets it to work unpatched. maybe the payload he uses inits the keyboard? Thanks, -------------- next part -------------- A non-text attachment was scrubbed... Name: qemu-keyboard.patch Type: application/octet-stream Size: 410 bytes Desc: not available URL: From c-d.hailfinger.devel.2006 at gmx.net Tue May 6 04:14:41 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 06 May 2008 04:14:41 +0200 Subject: [coreboot] legacy bios support and coreboot In-Reply-To: <20080506013626.GA25706@morn.localdomain> References: <20080506013626.GA25706@morn.localdomain> Message-ID: <481FBF11.1080406@gmx.net> Hi Kevin, great writeup! Any chance you can add that to the coreboot wiki? On 06.05.2008 03:36, Kevin O'Connor wrote: > [...] > Some of the hardware accesses made by the "legacybios" code appear to > be specific to hardware in the emulator. The code attempts to enable > ram shadowing of the memory segment at 0xf00000 - it does this so that > One zero too many? > it can put acpi/mptable/smbios tables into that area. After it is > complete, it attempts to disable writes to that region. The code > sequence looks to be specific to intel north/southbridges. It isn't > necessary to disable writes to 0xf0000 (though it would be nice), but > it is necessary to have the ability to alter that memory. Also, there > are stubs in "legacybios" for apm support - should one want to > implement this on real hardware the appropriate power saving code > would need to be implemented. > Regards, Carl-Daniel From ward at gnu.org Tue May 6 05:35:21 2008 From: ward at gnu.org (Ward Vandewege) Date: Mon, 5 May 2008 23:35:21 -0400 Subject: [coreboot] buildrom: cleanup package includes (updated) In-Reply-To: <000001c8af19$f6bfd770$1a02a8c0@chimp> References: <20080505215447.GE9450@cosmic.amd.com> <004401c8af04$0ac742a0$0023040a@chimp> <20080505232948.GG9450@cosmic.amd.com> <20080505235739.GH9450@cosmic.amd.com> <000001c8af19$f6bfd770$1a02a8c0@chimp> Message-ID: <20080506033521.GA9604@localdomain> On Mon, May 05, 2008 at 07:39:01PM -0600, Myles Watson wrote: > Several of the platforms have kernels that have never fit for me. I've never gotten a pure kernel payload working - but I never really investigated, LAB was more interesting. Time to get that fixed I think. So; given that we have tight space constraints, is the idea for a kernel payload to have non-essential modules on disk to be loaded later? In that case we can probably start with the LAB kernel configs. That's actually probably the fastest (only?) way to make the kernel fit. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From rminnich at gmail.com Tue May 6 05:42:58 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 5 May 2008 20:42:58 -0700 Subject: [coreboot] buildrom: cleanup package includes (updated) In-Reply-To: <20080506033521.GA9604@localdomain> References: <20080505215447.GE9450@cosmic.amd.com> <004401c8af04$0ac742a0$0023040a@chimp> <20080505232948.GG9450@cosmic.amd.com> <20080505235739.GH9450@cosmic.amd.com> <000001c8af19$f6bfd770$1a02a8c0@chimp> <20080506033521.GA9604@localdomain> Message-ID: <13426df10805052042q47dc9348ya3c5dea7a11acb66@mail.gmail.com> On Mon, May 5, 2008 at 8:35 PM, Ward Vandewege wrote: > So; given that we have tight space constraints, is the idea for a kernel > payload to have non-essential modules on disk to be loaded later? yes. Just enough to boot from disk or net. I did pure kernel payloads with network drivers only. I even once experimented with modifying linux main() to put the bootstrap code right into the kernel -- this saves a ton of space, actually. thanks ron From rminnich at gmail.com Tue May 6 06:42:58 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 5 May 2008 21:42:58 -0700 Subject: [coreboot] bug in cs5536 ide enable. Is this also in 8111 ... Message-ID: <13426df10805052142n60aaa4nf4c8f7fa3d1da1c4@mail.gmail.com> #define IDE_CFG 0x40 #define CHANEN (1L << 1) #define PWB (1L << 14) #define CABLE (1L << 16) #define IDE_DTC 0x48 #define IDE_CAST 0x4C #define IDE_ETC 0x50 static void ide_init(struct device *dev) { uint32_t ide_cfg; printk_spew("cs5536_ide: %s\n", __FUNCTION__); /* GPIO and IRQ setup are handled in the main chipset code. */ // Enable the channel and Post Write Buffer // NOTE: Only 32-bit writes to the data buffer are allowed when PWB is set ide_cfg = pci_read_config32(dev, IDE_CFG); ide_cfg |= CHANEN | PWB; pci_write_config8(dev, IDE_CFG, ide_cfg); } Note the pci_read_config32 followed by the pci_write_config8. HMM, why did this ever work? Anyway, I changed the write_config8 to write_config32 and it is still no good on the alix1c on v3. If someone wants to try this fix on v2, go for it: Index: southbridge/amd/cs5536/cs5536.c =================================================================== --- southbridge/amd/cs5536/cs5536.c (revision 676) +++ southbridge/amd/cs5536/cs5536.c (working copy) @@ -597,7 +597,7 @@ // NOTE: Only 32-bit writes to the data buffer are allowed when PWB is set ide_cfg = pci_read_config32(dev, IDE_CFG); ide_cfg |= CHANEN | PWB; - pci_write_config8(dev, IDE_CFG, ide_cfg); + pci_write_config32(dev, IDE_CFG, ide_cfg); } you need to translate for the v2 filename. off to rest, if somebody gets somewhere with this, let me know. ron From rminnich at gmail.com Tue May 6 07:54:37 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 5 May 2008 22:54:37 -0700 Subject: [coreboot] patch: two bugs in the cs5536 ide code Message-ID: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> I know some people will get upset by the find_pci_device, but: This patch fixes a long-standing problem in the cs5536 driver, that is probably also in v2. The ide_init is called with the sb device but needs the IDE device, which is different. It also did a write_config8,not write_config32; this bug has been in there since the code was written for v2. I don't know how or why it ever worked, since PWB is 1<<14. Works fine with 2.6.24. 2.6.15 hangs on boot, but I don't think it was ever IDE. POST on the 2.6.25 boot hang is 00. Signed-off-by: Ronald G. Minnich -------------- next part -------------- A non-text attachment was scrubbed... Name: cs5536.diff Type: text/x-diff Size: 1475 bytes Desc: not available URL: From claus.gindhart at kontron.com Tue May 6 07:58:20 2008 From: claus.gindhart at kontron.com (Claus Gindhart) Date: Tue, 6 May 2008 07:58:20 +0200 Subject: [coreboot] Fix ambiguity, if a board is equipped with more than one chip In-Reply-To: <20080505145745.4992.qmail@stuge.se> References: <200805051647.29834.claus.gindhart@kontron.com> <20080505145745.4992.qmail@stuge.se> Message-ID: <200805060758.20326.claus.gindhart@kontron.com> Hi Peter, yes, i am subscribed to the coreboot list. Please be aware, that Carl-Daniel Hailfinger already provided some senseful proposals to my patch and take them into account, when working on it. By the way: In my application, i replace the flashrom.c by my own frontend, because i need a somehow different user interface. My submission work is mainly concentrated on low-level HW-functions. I only submitted this patch, because without this patch i couldnt do any tests with the original flashrom. So, i am happy about your proposal, because flashrom.c is not in my focus. -- Mit freundlichen Gr??en / Best regards Claus Gindhart SW R&D Kontron Modular Computers phone :++49 (0)8341-803-374 mailto:claus.gindhart at kontron.com http://www.kontron.com On Monday 05 May 2008, Peter Stuge wrote: > Dear Claus, please confirm that you're subscribed to the list. > > On Mon, May 05, 2008 at 04:47:29PM +0200, Claus Gindhart wrote: > > Flashrom will probe for up to 3 chips; if more than one chip is > > detected, it will stop, and will prompt the user to choose one by > > the -c option > > Thanks! > > I will rework the patch a little and resend later today. > > Remember to add yourself or your employer as copyright holder in your > patches, not just add nice new features. That is important too. :) > > > //Peter Kontron Modular Computers GmbH Geschaeftsfuehrer / Managing Directors: Ulrich Gehrmann, Thomas Sabisch Sitz der Gesellschaft / Registered Office: Kaufbeuren, Rechtsform / Legal: GmbH Amtsgericht / Local District Court Kempten, HRB Nr. / Trade Register No. 6195 The information contained in this document is CONFIDENTIAL and property of Kontron. Any unauthorized review, use, disclosure or distribution is prohibited without express written consent of Kontron. If you are not the intended recipient, please contact the sender and destroy all copies of the original message and enclosed attachments. Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen und ist Eigentum von Kontron. Die Verwendung und Weitergabe von jeglichen Inhalten ist ohne ausdr?ckliche schriftliche Genehmigung von Kontron strikt untersagt. Wenn Sie diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten diese Mail und enthaltene Dokumente. From rminnich at gmail.com Tue May 6 08:03:04 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 5 May 2008 23:03:04 -0700 Subject: [coreboot] more on the cs5536 and 2.6.25 Message-ID: <13426df10805052303x4456a4bdhd6aabf6c59e98213@mail.gmail.com> I think 2.6.25 is hanging on the probe of ide port1. This is 2.6.24 AMD5536: IDE controller (0x1022:0x209a rev 0x01) at PCI slot 0000:00:0f.2 AMD5536: not 100% native mode: will probe irqs later AMD5536: 0000:00:0f.2 (rev 01) UDMA100 controller ide0: BM-DMA at 0x1ca0-0x1ca7, BIOS settings: hda:pio, hdb:pio AMD5536: IDE port disabled hda: CF 1GB, ATA DISK drive hda: MWDMA2 mode selected ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: max request size: 128KiB hda: 2030112 sectors (1039 MB) w/1KiB Cache, CHS=2014/16/63 hda: hda1 and 2.6.25 AMD5536: 0000:00:0f.2 (rev 01) UDMA100 controller AMD5536: IDE controller (0x1022:0x209a rev 0x01) at PCI slot 0000:00:0f.2 AMD5536: not 100% native mode: will probe irqs later AMD5536: IDE port disabled ide0: BM-DMA at 0x1ca0-0x1ca7, BIOS settings: hda:PIO, hdb:PIO and on one boot it did this: Probing IDE interface ide1... I think it's going after ide1, even though it is not there. Not sure yet. Something is pretty wrong here, and it broke from 2.6.24 to 2.6.25. ron From claus.gindhart at kontron.com Tue May 6 09:01:07 2008 From: claus.gindhart at kontron.com (Claus Gindhart) Date: Tue, 6 May 2008 09:01:07 +0200 Subject: [coreboot] flashrom: Probe for up to 3 flash chips. [was: Fix ambiguity, if a board is equipped with more than one chip] References: <200805051647.29834.claus.gindhart@kontron.com> <481F22C1.2050006@gmx.net> <20080505154903.20256.qmail@stuge.se> Message-ID: Kontron Modular Computers GmbH Geschaeftsfuehrer / Managing Directors: Ulrich Gehrmann, Thomas Sabisch Sitz der Gesellschaft / Registered Office: Kaufbeuren, Rechtsform / Legal: GmbH Amtsgericht / Local District Court Kempten, HRB Nr. / Trade Register No. 6195 The information contained in this document is CONFIDENTIAL and property of Kontron. Any unauthorized review, use, disclosure or distribution is prohibited without express written consent of Kontron. If you are not the intended recipient, please contact the sender and destroy all copies of the original message and enclosed attachments. Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen und ist Eigentum von Kontron. Die Verwendung und Weitergabe von jeglichen Inhalten ist ohne ausdr?ckliche schriftliche Genehmigung von Kontron strikt untersagt. Wenn Sie diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten diese Mail und enthaltene Dokumente. -----Urspr?ngliche Nachricht----- Von: Peter Stuge [mailto:peter at stuge.se] Gesendet: Mo 5/5/2008 17:49 An: coreboot at coreboot.org Cc: Claus Gindhart Betreff: Re: [coreboot] flashrom: Probe for up to 3 flash chips. [was: Fix ambiguity, if a board is equipped with more than one chip] On Mon, May 05, 2008 at 05:07:45PM +0200, Carl-Daniel Hailfinger wrote: > Can we support probing for an arbitrary number of chips instead? I think that is overly ambitious. flashrom assumes that flash chips are top-aligned at 4GB so there will not be very many flash chips actually connected in a way that flashrom understands today. > By using an array flash[] instead of flash, flash2 and flash3 this > could be done in a loop without limits on the number of detected > chips. I thought [] too, but I set a fixed size. It's simple and cheap to increase the size should there be need, and the code will deal. > What happens if there are multiple flash chips of the same > technology? If same name, then same size and at same address => larger problem. > Overall, I really like what the patch does. Yes, me too. Claus, can you please test the attached patch and send an Acked-by line it if it works, then I'll commit. Thanks! //Peter Hi Peter, i've tested the patch, it worked; i've acked-by the attached patch. This was my screen output ------------8-<---------- Multiple flash chips were detected: SST49LF008A M25P16 at ICH9 Please specify which chip to use with the -c option. ----------8-<---------- About the question "Multiple flash chips of the same technology": In my opinion, this is a problem, which has to be solved in a different way, even in regards, how this could be presented to the user. One possible approach could be the following: If we have multiple chips of the same type, all will be detected by the same probe-function. If we know, that this technology can support up to n identical chips, we could add n lines to flashchips.c, with the device names "chipxxx#1" "chipxxx#2" ... "chipxxx#n" It's up to the probe function then, to handle this; the flashrom.c would need to be changed. But for the moment i would recommend to wait, until such a board appears on somebody's desk. -- Mit freundlichen Gr??en / Best regards Claus Gindhart SW R&D Kontron Modular Computers phone :++49 (0)8341-803-374 mailto:claus.gindhart at kontron.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fr.multichip.patch Type: text/x-patch Size: 2200 bytes Desc: fr.multichip.patch URL: From joe at settoplinux.org Tue May 6 13:05:58 2008 From: joe at settoplinux.org (Joe) Date: Tue, 06 May 2008 07:05:58 -0400 Subject: [coreboot] =?utf-8?q?Does_the_Intel_3100_reboot=3F?= In-Reply-To: References: <481E32B5.9060700@gmx.net> <182074836ac41aa8936b472c213f4935@imap.1and1.com> Message-ID: On Mon, 5 May 2008 07:54:32 -0700, "Ed Swierk" wrote: > On Sun, May 4, 2008 at 3:06 PM, Joe wrote: >> My bad. Those & and | operators always get me... >> But does it allow the system to reboot? > > Yes, rebooting works on the Intel 3100 development board. Can you > increase the log level to 9 and see exactly where your board is > hanging? > I don't have a bootlog off hand, but when rebooting it just starts to loop after the northbridge dump in raminit.c. I think because it is just a soft reset the cpu needs a reset? That's why I was wondering if your code works. It should work fine for the RM4100, the DRC bit 29 is the same. I will give it a try and report back. I think, to keep things simplified I am just going to put the memory_initialized() function in raminit.c, and call it from auto.c. -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org From c-d.hailfinger.devel.2006 at gmx.net Tue May 6 14:15:44 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 06 May 2008 14:15:44 +0200 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> Message-ID: <48204BF0.1060407@gmx.net> On 06.05.2008 07:54, ron minnich wrote: > I know some people will get upset by the find_pci_device, but: > Indeed. Since we don't use the struct device passed in to ide_init, why don't we give Geode IDE its own struct device_operations and store the IDE config there? > This patch fixes a long-standing problem in the cs5536 driver, that is > probably also in v2. > > The ide_init is called with the sb device but needs the IDE device, > which is different. > It also did a write_config8,not write_config32; this bug has been in there since > the code was written for v2. I don't know how or why it ever worked, > since PWB is 1<<14. > > Works fine with 2.6.24. 2.6.15 hangs on boot, but I don't think it was > ^^^^^^ 2.6.25? > ever IDE. POST on the 2.6.25 boot hang is 00. > I have problems parsing the sentence above: "... I don't think it was ever IDE." > > Signed-off-by: Ronald G. Minnich > > Index: southbridge/amd/cs5536/cs5536.c > =================================================================== > --- southbridge/amd/cs5536/cs5536.c (revision 676) > +++ southbridge/amd/cs5536/cs5536.c (working copy) > @@ -589,15 +589,18 @@ > static void ide_init(struct device *dev) > { > u32 ide_cfg; > + struct device *ide_dev; > > printk(BIOS_DEBUG, "cs5536_ide: %s\n", __func__); > /* GPIO and IRQ setup are handled in the main chipset code. */ > + ide_dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, > + PCI_DEVICE_ID_AMD_CS5536_B0_IDE, 0); > > // Enable the channel and Post Write Buffer > // NOTE: Only 32-bit writes to the data buffer are allowed when PWB is set > - ide_cfg = pci_read_config32(dev, IDE_CFG); > + ide_cfg = pci_read_config32(ide_dev, IDE_CFG); > ide_cfg |= CHANEN | PWB; > - pci_write_config8(dev, IDE_CFG, ide_cfg); > + pci_write_config32(ide_dev, IDE_CFG, ide_cfg); > } > > > You know my preference for killing dev_find_pci_device, but that can come later if it is too difficult. Acked-by: Carl-Daniel Hailfinger Regards, Carl-Daniel From uwe at hermann-uwe.de Tue May 6 14:42:20 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 6 May 2008 14:42:20 +0200 Subject: [coreboot] buildrom: cleanup package includes (updated) In-Reply-To: <20080505232948.GG9450@cosmic.amd.com> References: <20080505215447.GE9450@cosmic.amd.com> <004401c8af04$0ac742a0$0023040a@chimp> <20080505232948.GG9450@cosmic.amd.com> Message-ID: <20080506124220.GB1099@greenwood> On Mon, May 05, 2008 at 05:29:48PM -0600, Jordan Crouse wrote: > On 05/05/08 17:02 -0600, Myles Watson wrote: > > > > > > > -----Original Message----- > > > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] > > > On Behalf Of Jordan Crouse > > > Sent: Monday, May 05, 2008 3:55 PM > > > To: coreboot at coreboot.org > > > Subject: [coreboot] buildrom: cleanup package includes (updated) > > > > > > Attached is an updated version of the patch I sent before that > > > streamined the .mk files that are included in buildrom. This version > > > is updated with the latest and greatest from Myles and everybody. > > > > > > Tested with all payloads + coreinfo, and hd8mr + kernel (I'm going to > > > test the other platforms with kernel, but I didn't want to wait around > > > for them to finish building). > > > > Acked-by: Myles Watson > > Thanks - I am going to wait on this until tomorrow. Coreboot-v2 + kernel > failed on 13 of 17 targets (and only 3 failures are due to missing .mk files). > I don't know if this is becuase of my patch, my test harness, or something > else. Either way, it is best that I hold off until I can debug it more > fully. Do you have a testing script for this? If yes, it would be nice to commit that so everbody can run the tests when changing code or adding new targets/payloads... Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From uwe at hermann-uwe.de Tue May 6 15:07:43 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 6 May 2008 15:07:43 +0200 Subject: [coreboot] [PATCH] filo: Add missing Artec license headers Message-ID: <20080506130743.GC1099@greenwood> See patch. I assume the *.h files and Makefile were also written by Andrei Birjukov as is the rest of the new code, please correct me if that's wrong. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: filo_license_headers_artec.patch Type: text/x-diff Size: 3742 bytes Desc: not available URL: From c-d.hailfinger.devel.2006 at gmx.net Tue May 6 15:16:55 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 06 May 2008 15:16:55 +0200 Subject: [coreboot] [PATCH] [RFC] v3: CS5536 cleanup Message-ID: <48205A47.5060403@gmx.net> Clean up Geode companion chip CS5536 code and improve VPCI hiding debug message. This also eliminates a few dev_find_pci_device(). I'm not happy with the new code yet. hide_vpci() should have a variant which takes a struct device *. Signed-off-by: Carl-Daniel Hailfinger Index: LinuxBIOSv3-cs5536cleanup/southbridge/amd/cs5536/cs5536.c =================================================================== --- LinuxBIOSv3-cs5536cleanup/southbridge/amd/cs5536/cs5536.c (Revision 676) +++ LinuxBIOSv3-cs5536cleanup/southbridge/amd/cs5536/cs5536.c (Arbeitskopie) @@ -175,8 +175,7 @@ static void enable_ide_nand_flash_header(void) { /* Tell VSA to use FLASH PCI header. Not IDE header. */ - outl(0x80007A40, 0xCF8); - outl(0xDEADBEEF, 0xCFC); + hide_vpci(0x800079C4); } #define RTC_CENTURY 0x32 @@ -240,16 +239,13 @@ * * @param sb Southbridge config structure. */ -static void uarts_init(struct southbridge_amd_cs5536_dts_config *sb) +static void uarts_init(struct southbridge_amd_cs5536_dts_config *sb, + struct device *dev) { struct msr msr; u16 addr = 0; u32 gpio_addr; - struct device *dev; - dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, - PCI_DEVICE_ID_AMD_CS5536_ISA, 0); - gpio_addr = pci_read_config32(dev, PCI_BASE_ADDRESS_1); gpio_addr &= ~1; /* Clear I/O bit */ printk(BIOS_DEBUG, "GPIO_ADDR: %08X\n", gpio_addr); @@ -418,7 +414,7 @@ { u32 *bar; struct msr msr; - struct device *dev; + struct device *dev, *otg_dev; dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CS5536_EHCI, 0); @@ -440,9 +436,9 @@ *(bar + HCCPARAMS) = 0x00005012; } - dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, + otg_dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CS5536_OTG, 0); - if (dev) { + if (otg_dev) { bar = (u32 *) pci_read_config32(dev, PCI_BASE_ADDRESS_0); *(bar + UOCMUX) &= PUEN_SET; @@ -472,9 +468,7 @@ *(bar + UDCDEVCTL) |= UDC_SD_SET; } - dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, - PCI_DEVICE_ID_AMD_CS5536_OTG, 0); - if (dev) { + if (otg_dev) { bar = (u32 *)pci_read_config32(dev, PCI_BASE_ADDRESS_0); *(bar + UOCCTL) |= PADEN_SET; *(bar + UOCCAP) |= APU_SET; @@ -482,15 +476,8 @@ } /* Disable virtual PCI UDC and OTG headers. */ - dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, - PCI_DEVICE_ID_AMD_CS5536_UDC, 0); - if (dev) - pci_write_config32(dev, 0x7C, 0xDEADBEEF); - - dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, - PCI_DEVICE_ID_AMD_CS5536_OTG, 0); - if (dev) - pci_write_config32(dev, 0x7C, 0xDEADBEEF); + hide_vpci(0x80007e00); /* UDC */ + hide_vpci(0x80007f00); /* OTG */ } /** @@ -603,9 +590,19 @@ static void hide_vpci(u32 vpci_devid) { - /* Hide unwanted virtual PCI device. */ - printk(BIOS_DEBUG, "Hiding VPCI device: 0x%08X\n", - vpci_devid); + /* Hide unwanted virtual PCI device. + * bits 0 -> 1 zero + * bits 2 -> 7 target dword within the target function + * (zero if we're disabling entire pci devices) + * bits 8 -> 10 target function of the device + * bits 11 -> 15 target pci device + * bits 16 -> 23 pci bus + * bits 24 -> 30 reserved and set to zero + * bit 31 triggers the config cycle + */ + printk(BIOS_DEBUG, "Hiding VPCI device: 0x%08X (%02x:%02x.%01x)\n", + vpci_devid, (vpci_devid >> 16) & 0xff, + (vpci_devid >> 11) & 0x1f, (vpci_devid >> 8) & 0x7); outl(vpci_devid + 0x7C, 0xCF8); outl(0xDEADBEEF, 0xCFC); } @@ -630,7 +627,7 @@ setup_i8259(); lpc_init(sb); - uarts_init(sb); + uarts_init(sb, dev); if (sb->enable_gpio_int_route) { printk(BIOS_SPEW, "cs5536: call vr_write\n"); From svn at coreboot.org Tue May 6 15:26:33 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Tue, 6 May 2008 15:26:33 +0200 Subject: [coreboot] r3279 - trunk/coreboot-v2/src/mainboard/msi/ms7135 Message-ID: Author: uwe Date: 2008-05-06 15:26:32 +0200 (Tue, 06 May 2008) New Revision: 3279 Modified: trunk/coreboot-v2/src/mainboard/msi/ms7135/Config.lb trunk/coreboot-v2/src/mainboard/msi/ms7135/cache_as_ram_auto.c trunk/coreboot-v2/src/mainboard/msi/ms7135/mptable.c Log: Fix various issues on MSI MS-7135 board. - W83627THF is strapped to 0x4e, not 0x2e - there's no device 9 on PCI-E x1 bus, it should be device 0 - add mptable entries for AGR slot, based on info in user manual - enable floppy drive controller so that some legacy VGA ROMs will work Signed-off-by: Jonathan A. Kollasch Acked-by: Uwe Hermann Modified: trunk/coreboot-v2/src/mainboard/msi/ms7135/Config.lb =================================================================== --- trunk/coreboot-v2/src/mainboard/msi/ms7135/Config.lb 2008-05-05 20:50:58 UTC (rev 3278) +++ trunk/coreboot-v2/src/mainboard/msi/ms7135/Config.lb 2008-05-06 13:26:32 UTC (rev 3279) @@ -242,35 +242,34 @@ device pci 0.0 on end # HT device pci 1.0 on # LPC chip superio/winbond/w83627thf # Super I/O - device pnp 2e.0 off # Floppy + device pnp 4e.0 on # Floppy io 0x60 = 0x3f0 irq 0x70 = 6 drq 0x74 = 2 end - device pnp 2e.1 on # Parallel port + device pnp 4e.1 on # Parallel port io 0x60 = 0x378 - irq 0x70 = 0 + irq 0x70 = 7 end - device pnp 2e.2 on # Com1 + device pnp 4e.2 on # Com1 io 0x60 = 0x3f8 irq 0x70 = 4 end - device pnp 2e.3 on # Com2 + device pnp 4e.3 on # Com2 io 0x60 = 0x2f8 irq 0x70 = 3 end - device pnp 2e.5 on # PS/2 keyboard + device pnp 4e.5 on # PS/2 keyboard io 0x60 = 0x60 io 0x62 = 0x64 irq 0x70 = 1 irq 0x72 = 12 end - device pnp 2e.6 off end # non-existant or undocumented - device pnp 2e.7 off end # Game, MIDI, GPIO 1, GPIO 5 - device pnp 2e.8 off end # GPIO 2 - device pnp 2e.9 off end # GPIO 3, GPIO 4 - device pnp 2e.a off end # ACPI - device pnp 2e.b on # env monitor + device pnp 4e.7 off end # Game, MIDI, GPIO 1, GPIO 5 + device pnp 4e.8 off end # GPIO 2 + device pnp 4e.9 off end # GPIO 3, GPIO 4 + device pnp 4e.a off end # ACPI + device pnp 4e.b on # Hardware monitor io 0x60 = 0x290 irq 0x70 = 0 end Modified: trunk/coreboot-v2/src/mainboard/msi/ms7135/cache_as_ram_auto.c =================================================================== --- trunk/coreboot-v2/src/mainboard/msi/ms7135/cache_as_ram_auto.c 2008-05-05 20:50:58 UTC (rev 3278) +++ trunk/coreboot-v2/src/mainboard/msi/ms7135/cache_as_ram_auto.c 2008-05-06 13:26:32 UTC (rev 3279) @@ -25,7 +25,7 @@ #define ASSEMBLY 1 #define __ROMCC__ -#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) +#define SERIAL_DEV PNP_DEV(0x4e, W83627HF_SP1) /* Used by raminit. */ #define QRANK_DIMM_SUPPORT 1 Modified: trunk/coreboot-v2/src/mainboard/msi/ms7135/mptable.c =================================================================== --- trunk/coreboot-v2/src/mainboard/msi/ms7135/mptable.c 2008-05-05 20:50:58 UTC (rev 3278) +++ trunk/coreboot-v2/src/mainboard/msi/ms7135/mptable.c 2008-05-06 13:26:32 UTC (rev 3279) @@ -163,6 +163,10 @@ PCI_INT(0, sbdn+10, 0, 22); + /* "AGR" slot */ + PCI_INT(1, 0, 0, 16); + PCI_INT(1, 0, 1, 17); + /* legacy PCI */ PCI_INT(1, 7, 0, 17); PCI_INT(1, 7, 1, 18); @@ -184,8 +188,8 @@ PCI_INT(2, 0, 0, 19); /* XXX guesses */ PCI_INT(2, 0, 1, 16); - PCI_INT(2, 9, 2, 17); - PCI_INT(2, 9, 3, 18); + PCI_INT(2, 0, 2, 17); + PCI_INT(2, 0, 3, 18); /* PCI-E x16 port */ /* XXX fix me ? */ PCI_INT(3, 0, 0, 18); From uwe at hermann-uwe.de Tue May 6 15:28:09 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 6 May 2008 15:28:09 +0200 Subject: [coreboot] [PATCH] MS7135 fixes and updates In-Reply-To: <481B7655.9060601@assembler.cz> References: <20080430152113.GG2542@tazenda.kollasch.net> <20080501002225.GD9643@greenwood> <20080501010901.GJ2542@tazenda.kollasch.net> <48199D68.7090303@assembler.cz> <20080501203014.GL2542@tazenda.kollasch.net> <481B7655.9060601@assembler.cz> Message-ID: <20080506132809.GD1099@greenwood> On Fri, May 02, 2008 at 10:15:17PM +0200, Rudolf Marek wrote: > Jonathan A. Kollasch napsal(a): > > On Thu, May 01, 2008 at 12:37:28PM +0200, Rudolf Marek wrote: > >> Just a side note, if the superIO is similar to W83627EHG then you could use > >> virtual LDNs for the different functionality in same LDN which are sharing > >> same enable byte. (I did it for the W83627EHG). > >> > >> http://www.coreboot.org/SuperIO_port_guide > > > > Huh, but I don't think this is the case here. > > In logical device 7 and 9 yes. If you want to enable at least something, you > need to use virtual LDNs. Committed current patch in r3279 for now, as it fixes a few issues. Please post another patch for additional fixes and improvements. Note that I dropped LDN 6, it's not available in *THF either, I checked the datasheet. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From uwe at hermann-uwe.de Tue May 6 15:30:34 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 6 May 2008 15:30:34 +0200 Subject: [coreboot] [PATCH] MS7135 fixes and updates In-Reply-To: <48199D68.7090303@assembler.cz> References: <20080430152113.GG2542@tazenda.kollasch.net> <20080501002225.GD9643@greenwood> <20080501010901.GJ2542@tazenda.kollasch.net> <48199D68.7090303@assembler.cz> Message-ID: <20080506133033.GE1099@greenwood> On Thu, May 01, 2008 at 12:37:28PM +0200, Rudolf Marek wrote: > Just a side note, if the superIO is similar to W83627EHG then you could > use virtual LDNs for the different functionality in same LDN which are > sharing same enable byte. (I did it for the W83627EHG). > > http://www.coreboot.org/SuperIO_port_guide Can you merge that page somewhere into http://www.coreboot.org/Developer_Manual#Serial_output_and_the_Super_I.2FO please (if you agree to license the content under the GPLv2-or-later, as the rest of the manual)? That's the correct place for that type of info, IMHO. I'll drop the SuperIO_port_guide then afterwards. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From jordan.crouse at amd.com Tue May 6 16:25:12 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 6 May 2008 08:25:12 -0600 Subject: [coreboot] buildrom: cleanup package includes (updated) In-Reply-To: <20080506124220.GB1099@greenwood> References: <20080505215447.GE9450@cosmic.amd.com> <004401c8af04$0ac742a0$0023040a@chimp> <20080505232948.GG9450@cosmic.amd.com> <20080506124220.GB1099@greenwood> Message-ID: <20080506142512.GI9450@cosmic.amd.com> On 06/05/08 14:42 +0200, Uwe Hermann wrote: > On Mon, May 05, 2008 at 05:29:48PM -0600, Jordan Crouse wrote: > > On 05/05/08 17:02 -0600, Myles Watson wrote: > > > > > > > > > > -----Original Message----- > > > > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] > > > > On Behalf Of Jordan Crouse > > > > Sent: Monday, May 05, 2008 3:55 PM > > > > To: coreboot at coreboot.org > > > > Subject: [coreboot] buildrom: cleanup package includes (updated) > > > > > > > > Attached is an updated version of the patch I sent before that > > > > streamined the .mk files that are included in buildrom. This version > > > > is updated with the latest and greatest from Myles and everybody. > > > > > > > > Tested with all payloads + coreinfo, and hd8mr + kernel (I'm going to > > > > test the other platforms with kernel, but I didn't want to wait around > > > > for them to finish building). > > > > > > Acked-by: Myles Watson > > > > Thanks - I am going to wait on this until tomorrow. Coreboot-v2 + kernel > > failed on 13 of 17 targets (and only 3 failures are due to missing .mk files). > > I don't know if this is becuase of my patch, my test harness, or something > > else. Either way, it is best that I hold off until I can debug it more > > fully. > > Do you have a testing script for this? If yes, it would be nice to commit that > so everbody can run the tests when changing code or adding new > targets/payloads... I'm still working on a testing script. I'm not sure how useful it might end up being, but I will commit it when I am happier with how it works. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From Manuel.Reimer at gmx.de Tue May 6 16:28:12 2008 From: Manuel.Reimer at gmx.de (Manuel Reimer) Date: Tue, 06 May 2008 16:28:12 +0200 Subject: [coreboot] Will coreboot run on ASRock ALiveNF5-eSATA2+ R3.0? Message-ID: <20080506142812.56660@gmx.net> Hi, I own the mainboard ASRock ALiveNF5-eSATA2+ R3.0. I would like to test/use coreboot on this board. I have a second PC and a nullmodem cable, I have Linux knowledge and I have a *very* basic knowledge of the C programming language. I don't have a second BIOS chip (would buy one if there is a chance to use the board with coreboot) and I don't have a device for flashing BIOS chips (would be nice if it's possible to replace the chip while the system runs to flash the new chip directly on the mainboard). More information about the board: http://www.asrock.com/mb/overview.asp?Model=ALiveNF5-eSATA2%2B%20R3.0 Thanks in advance Manuel Reimer Long output of superiotool and lspci follows superiotool r3254 Probing for ALi Super I/O at 0x3f0... Failed. Returned data: id=0xffff, rev=0xff Probing for ALi Super I/O at 0x370... Failed. Returned data: id=0xffff, rev=0xff Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0x0400, id=0x6388 Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0xffff, id=0xffff Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x2e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x2e... Failed. Returned data: id=0x8863, rev=0xf Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for NSC Super I/O at 0x2e... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x4e... Failed. Returned data: port=0xff, port+1=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x164e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x164e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x3f0... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x3f0... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x370... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x370... Failed. Returned data: id=0xff, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e... Found Winbond W83627EHF/EF/EHG/EG (id=0x88, rev=0x63) at 0x2e Register dump: idx 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f val 88 63 ff 00 04 00 00 ff 50 04 00 00 02 41 00 ff def 88 MM ff 00 MM 00 MM RR 50 04 00 RR 00 21 00 00 LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 f2 f4 f5 val 01 03 f0 06 02 0e 00 ff 00 00 def 01 03 f0 06 02 8e 00 ff 00 00 LDN 0x01 (Parallel port) idx 30 60 61 70 74 f0 val 01 03 78 07 03 3b def 01 03 78 07 04 3f LDN 0x02 (COM1) idx 30 60 61 70 f0 val 01 03 f8 04 00 def 01 03 f8 04 00 LDN 0x03 (COM2) idx 30 60 61 70 f0 f1 val 00 00 00 00 00 00 def 01 02 f8 03 00 00 LDN 0x05 (Keyboard) idx 30 60 61 62 63 70 72 f0 val 01 00 60 00 64 01 0c 82 def 01 00 60 00 64 01 0c 83 LDN 0x06 (Serial flash interface) idx 30 62 63 val 00 ff ff def 00 00 00 LDN 0x07 (GPIO 1, GPIO 6, game port, MIDI port) idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 f7 val 00 02 00 00 00 00 ff ff ff ff ff ff ff 00 def 00 02 01 03 30 09 ff 00 00 00 ff 00 00 00 LDN 0x08 (WDTO#, PLED) idx 30 f5 f6 f7 val 00 ff 00 ff def 00 00 00 00 LDN 0x09 (GPIO 2, GPIO 3, GPIO 4, GPIO 5, SUSLED) idx 30 e0 e1 e2 e3 e4 e5 f0 f1 f2 f3 f4 f5 f6 f7 val 06 ff ff ff ff ff ff fe 3a 00 40 f3 ff 00 00 def 00 ff 00 00 ff 00 00 ff 00 00 00 ff 00 00 00 LDN 0x0a (ACPI) idx 30 70 e0 e1 e2 e3 e4 e5 e6 e7 e8 f2 f3 f4 f6 f7 val 00 00 01 00 00 01 00 00 0c 00 09 7c 00 00 00 00 def 00 00 01 00 ff 08 00 RR 00 00 RR 7c 00 00 00 00 LDN 0x0b (Hardware monitor) idx 30 60 61 70 f0 f1 val 01 02 90 00 c1 3f def 00 00 00 00 c1 00 Probing for Winbond Super I/O (init=0x88) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff 00:00.0 RAM memory [0500]: nVidia Corporation MCP65 Memory Controller [10de:0444] (rev a3) Subsystem: ASRock Incorporation Unknown device [1849:0444] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [b8] Subsystem: ASRock Incorporation Unknown device [1849:0449] Capabilities: [8c] HyperTransport: MSI Mapping 00: de 10 49 04 07 00 b0 00 a1 01 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 02 02 20 c0 c0 80 22 20: 70 f9 70 f9 f0 ff 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 b8 00 00 00 00 00 00 00 00 00 02 02 40: 00 00 73 07 01 00 02 00 07 00 00 00 00 00 48 00 50: 00 00 00 00 00 00 00 00 ff 1f ff 1f 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 0a 00 00 3c 00 80 00 00 00 00 00 08 00 00 a8 90: 00 00 e0 fe 00 00 00 00 00 00 00 00 00 00 00 00 a0: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 ff ff 00 00 0d 8c 00 00 49 18 49 04 c0: 49 18 49 04 07 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:09.0 IDE interface [0101]: nVidia Corporation MCP65 IDE [10de:0448] (rev a1) (prog-if 8a [Master SecP PriP]) Subsystem: ASRock Incorporation Unknown device [1849:0448] Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Subsystem: ASRock Incorporation Unknown device [1849:045b] Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [60] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x2, ASPM L0s L1, Port 3 Link: Latency L0s <512ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x1 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 0, PowerLimit 0.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd On, Power- Root: Correctable- Non-Fatal- Fatal- PME- 00: de 10 5b 04 07 00 10 00 a1 00 04 06 10 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 b1 b1 00 00 20: 60 f9 60 f9 f1 ff 01 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 02 00 40: 0d 48 00 00 49 18 5b 04 01 50 02 f8 00 00 00 00 50: 05 60 82 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 08 80 00 a8 00 00 e0 fe 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 10 00 41 01 01 80 00 00 1f 28 00 00 21 3c 11 03 90: 00 00 11 30 00 00 00 00 c0 01 48 01 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:0c.0 PCI bridge [0604]: nVidia Corporation MCP65 PCI Express bridge [10de:045a] (rev a1) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Subsystem: ASRock Incorporation Unknown device [1849:045a] Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [60] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 2 Link: Latency L0s <512ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x2 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 0, PowerLimit 0.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq+ Slot: AttnInd Off, PwrInd On, Power- Root: Correctable- Non-Fatal- Fatal- PME- 00: de 10 5a 04 07 00 10 00 a1 00 04 06 10 00 01 00 10: 00 00 00 00 00 00 00 00 00 03 04 00 d1 d1 00 00 20: 80 f9 f0 f9 01 ce f1 cf 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 02 00 40: 0d 48 00 00 49 18 5a 04 01 50 02 f8 00 00 00 00 50: 05 60 82 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 08 80 00 a8 00 00 e0 fe 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 10 00 41 01 01 80 00 00 1f 28 00 00 11 3c 11 02 90: 00 00 21 10 00 00 00 00 e0 11 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:0d.0 PCI bridge [0604]: nVidia Corporation MCP65 PCI Express bridge [10de:0458] (rev a1) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Subsystem: ASRock Incorporation Unknown device [1849:0458] Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [60] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0 Link: Latency L0s <512ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x16 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 0, PowerLimit 0.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd On, Power- Root: Correctable- Non-Fatal- Fatal- PME- 00: de 10 58 04 07 00 10 00 a1 00 04 06 10 00 01 00 10: 00 00 00 00 00 00 00 00 00 05 05 00 e1 e1 00 00 20: 00 fa b0 fe 01 d0 f1 df 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 1a 00 40: 0d 48 00 00 49 18 58 04 01 50 02 f8 00 00 00 00 50: 05 60 82 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 08 80 00 a8 00 00 e0 fe 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 10 00 41 01 01 80 00 00 1f 28 00 00 01 3d 11 00 90: 00 00 01 31 00 00 00 00 c0 01 48 01 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:0e.0 PCI bridge [0604]: nVidia Corporation MCP65 PCI Express bridge [10de:0459] (rev a1) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Subsystem: ASRock Incorporation Unknown device [1849:0459] Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [60] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 1 Link: Latency L0s <512ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x8 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 0, PowerLimit 0.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd On, Power- Root: Correctable- Non-Fatal- Fatal- PME- 00: de 10 59 04 04 00 10 00 a1 00 04 06 10 00 01 00 10: 00 00 00 00 00 00 00 00 00 06 06 00 f1 01 00 00 20: f0 ff 00 00 f1 ff 01 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 02 00 40: 0d 48 00 00 49 18 59 04 01 50 02 f8 00 00 00 00 50: 05 60 82 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 08 80 00 a8 00 00 e0 fe 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 10 00 41 01 01 80 00 00 1f 28 00 00 11 3c 11 01 90: 00 00 81 10 00 00 00 00 c0 01 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR+ TAbort- SERR- TAbort- SERR- Author: myles Date: 2008-05-06 17:02:22 +0200 (Tue, 06 May 2008) New Revision: 3280 Modified: trunk/coreboot-v2/src/mainboard/emulation/qemu-x86/mainboard.c Log: This patch adds pc keyboard init function call for qemu in v2 since some payloads assume Coreboot initializes it. Coreboot v3 already does it. Signed-off-by: Aaron Lwe Acked-by: Myles Watson Modified: trunk/coreboot-v2/src/mainboard/emulation/qemu-x86/mainboard.c =================================================================== --- trunk/coreboot-v2/src/mainboard/emulation/qemu-x86/mainboard.c 2008-05-06 13:26:32 UTC (rev 3279) +++ trunk/coreboot-v2/src/mainboard/emulation/qemu-x86/mainboard.c 2008-05-06 15:02:22 UTC (rev 3280) @@ -17,6 +17,8 @@ do_vgabios(); vga_enable_console(); + + init_pc_keyboard(0x60, 0x64, 0); } static struct device_operations vga_operations = { From mylesgw at gmail.com Tue May 6 17:03:23 2008 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 6 May 2008 09:03:23 -0600 Subject: [coreboot] QEMU Keyboard problems in v2 In-Reply-To: References: <000f01c8aed3$6bda24d0$0023040a@chimp> Message-ID: <002301c8af8a$54f3a360$1a02a8c0@chimp> > -----Original Message----- > From: aaron lwe [mailto:aaron.lwe at gmail.com] > Sent: Monday, May 05, 2008 7:41 PM > To: Myles Watson > Cc: Coreboot > Subject: QEMU Keyboard problems in v2 > > > Where did you add it? > I attached a patch, it adds pc keyboard init function for qemu in case > payloads assume coreboot has done the job. > Signed-off-by: Aaron Lwe Thanks Aaron, It works for me. Acked-by: Myles Watson Rev 3280. > > it seems like Coreboot-v2 used to initialize the keyboard correctly, > otherwise > > ADLO wouldn't have disabled the keyboard init when compiled for > Coreboot. > yes, ADLO assumes coreboot has inited keyboard so it omits that. > > > I wonder why Jordan gets it to work unpatched. > maybe the payload he uses inits the keyboard? I checked his log and it doesn't have the "Keyboard init" line. I don't know why it works for him. Thanks, Myles From mylesgw at gmail.com Tue May 6 17:08:52 2008 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 6 May 2008 09:08:52 -0600 Subject: [coreboot] Buildrom lzma patch and update QEMU Config-lab.lb In-Reply-To: <2831fecf0805011341n1b83e7bbl14fa57d32458bfad@mail.gmail.com> References: <2831fecf0805011341n1b83e7bbl14fa57d32458bfad@mail.gmail.com> Message-ID: <2831fecf0805060808h68c396d8ue20c686c08f9d8da@mail.gmail.com> On Thu, May 1, 2008 at 2:41 PM, Myles Watson wrote: > These patches go together and make it so that checking the "USE_LZMA" > option in buildrom doesn't break builds. > > It assumes that all Config.lb files don't use compression, and all > Config-lab.lb files do. Ping. > The qemu-lab.lzma.diff patch makes that change. > > Signed-off-by: Myles Watson > > Thanks, > Myles > From jordan.crouse at amd.com Tue May 6 17:14:10 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 6 May 2008 09:14:10 -0600 Subject: [coreboot] Buildrom lzma patch and update QEMU Config-lab.lb In-Reply-To: <2831fecf0805060808h68c396d8ue20c686c08f9d8da@mail.gmail.com> References: <2831fecf0805011341n1b83e7bbl14fa57d32458bfad@mail.gmail.com> <2831fecf0805060808h68c396d8ue20c686c08f9d8da@mail.gmail.com> Message-ID: <20080506151410.GJ9450@cosmic.amd.com> On 06/05/08 09:08 -0600, Myles Watson wrote: > On Thu, May 1, 2008 at 2:41 PM, Myles Watson wrote: > > These patches go together and make it so that checking the "USE_LZMA" > > option in buildrom doesn't break builds. > > > > It assumes that all Config.lb files don't use compression, and all > > Config-lab.lb files do. > > Ping. Oops - my bad. Acked-by: Jordan Crouse Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From svn at coreboot.org Tue May 6 17:17:45 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Tue, 6 May 2008 17:17:45 +0200 Subject: [coreboot] r3281 - trunk/coreboot-v2/targets/emulation/qemu-x86 Message-ID: Author: myles Date: 2008-05-06 17:17:43 +0200 (Tue, 06 May 2008) New Revision: 3281 Modified: trunk/coreboot-v2/targets/emulation/qemu-x86/Config-lab.lb Log: This patch changes Config-lab.lb for qemu to use lzma like the other targets. Signed-off-by: Myles Watson Acked-by: Jordan Crouse Modified: trunk/coreboot-v2/targets/emulation/qemu-x86/Config-lab.lb =================================================================== --- trunk/coreboot-v2/targets/emulation/qemu-x86/Config-lab.lb 2008-05-06 15:02:22 UTC (rev 3280) +++ trunk/coreboot-v2/targets/emulation/qemu-x86/Config-lab.lb 2008-05-06 15:17:43 UTC (rev 3281) @@ -4,8 +4,8 @@ mainboard emulation/qemu-x86 option ROM_SIZE=2048*1024 -option CONFIG_COMPRESSED_PAYLOAD_LZMA=0 -option CONFIG_PRECOMPRESSED_PAYLOAD=0 +option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 +option CONFIG_PRECOMPRESSED_PAYLOAD=1 option CC="gcc -m32" From svn at coreboot.org Tue May 6 17:30:33 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Tue, 6 May 2008 17:30:33 +0200 Subject: [coreboot] r181 - in buildrom-devel: . config/payloads config/platforms packages/coreboot-v2 Message-ID: Author: myles Date: 2008-05-06 17:30:32 +0200 (Tue, 06 May 2008) New Revision: 181 Modified: buildrom-devel/Config.in buildrom-devel/config/payloads/Config.in buildrom-devel/config/platforms/alix1c.conf buildrom-devel/config/platforms/asus_a8v-e_se.conf buildrom-devel/config/platforms/db800.conf buildrom-devel/config/platforms/dbe61.conf buildrom-devel/config/platforms/ga-2761gxdk.conf buildrom-devel/config/platforms/m57sli.conf buildrom-devel/config/platforms/msm800sev.conf buildrom-devel/config/platforms/norwich.conf buildrom-devel/config/platforms/qemu.conf buildrom-devel/config/platforms/serengeti_cheetah.conf buildrom-devel/config/platforms/supermicro-h8dmr.conf buildrom-devel/config/platforms/tyan-s2881.conf buildrom-devel/config/platforms/tyan-s2882.conf buildrom-devel/config/platforms/tyan-s2891.conf buildrom-devel/config/platforms/tyan-s2892.conf buildrom-devel/config/platforms/tyan-s2895.conf buildrom-devel/packages/coreboot-v2/coreboot.inc buildrom-devel/packages/coreboot-v2/generic.mk Log: This makes it so that checking the "USE_LZMA" option in buildrom doesn't break builds. It moves the USE_LZMA option to the payload menu, since it only affects the payload. It assumes that all Config.lb files don't use compression, and all Config-lab.lb files do. It also updates qemu.conf to use 3281 which has the correct Config-lab.lb. Signed-off-by: Myles Watson Acked-by: Jordan Crouse Modified: buildrom-devel/Config.in =================================================================== --- buildrom-devel/Config.in 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/Config.in 2008-05-06 15:30:32 UTC (rev 181) @@ -99,19 +99,6 @@ help Specify the ROM size here in KB. -config USE_LZMA - bool "Enable LZMA compression" - depends on !(PAYLOAD_OFW && COREBOOT_V2) - depends on !(PAYLOAD_FILO && COREBOOT_V2) - depends on !(PAYLOAD_ETHERBOOT && COREBOOT_V2) - default y - help - Precompress the payload with LZMA when using coreboot v2. This doesn't - work for FILO, OFW, or ETHERBOOT. - - When using COREBOOT_V3, parse the elf and have lar compress the files. - This works with all ELF payloads. - config CB_USE_BUILD bool "Specify a coreboot build dir" depends on ADVANCED Modified: buildrom-devel/config/payloads/Config.in =================================================================== --- buildrom-devel/config/payloads/Config.in 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/config/payloads/Config.in 2008-05-06 15:30:32 UTC (rev 181) @@ -3,6 +3,16 @@ menu "Payload Configuration" +config USE_LZMA + bool "Enable LZMA compression" + default y + help + Precompress the payload with LZMA when using coreboot v2. This changes + the Config.lb file used. + + When using COREBOOT_V3, parse the elf and have lar compress the files. + This works with all ELF payloads. + choice prompt "Desired payload" default PAYLOAD_KERNEL Modified: buildrom-devel/config/platforms/alix1c.conf =================================================================== --- buildrom-devel/config/platforms/alix1c.conf 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/config/platforms/alix1c.conf 2008-05-06 15:30:32 UTC (rev 181) @@ -27,8 +27,6 @@ COREBOOT_VENDOR=pcengines COREBOOT_BOARD=alix1c -CBV2_CONFIG=Config.lb -CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=alix1c CBV2_TAG=3079 Modified: buildrom-devel/config/platforms/asus_a8v-e_se.conf =================================================================== --- buildrom-devel/config/platforms/asus_a8v-e_se.conf 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/config/platforms/asus_a8v-e_se.conf 2008-05-06 15:30:32 UTC (rev 181) @@ -41,8 +41,6 @@ COREBOOT_VENDOR=asus COREBOOT_BOARD=a8v-e_se -CBV2_CONFIG=Config.lb -CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=asus_a8v-e_se CBV2_TAG=3241 Modified: buildrom-devel/config/platforms/db800.conf =================================================================== --- buildrom-devel/config/platforms/db800.conf 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/config/platforms/db800.conf 2008-05-06 15:30:32 UTC (rev 181) @@ -30,8 +30,6 @@ COREBOOT_VENDOR=amd COREBOOT_BOARD=db800 -CBV2_CONFIG=Config.lb -CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=db800 CBV2_TAG=3090 Modified: buildrom-devel/config/platforms/dbe61.conf =================================================================== --- buildrom-devel/config/platforms/dbe61.conf 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/config/platforms/dbe61.conf 2008-05-06 15:30:32 UTC (rev 181) @@ -29,8 +29,6 @@ COREBOOT_VENDOR=artecgroup COREBOOT_BOARD=dbe61 -CBV2_CONFIG=Config.lb -CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=dbe61 CBV2_TAG=3090 Modified: buildrom-devel/config/platforms/ga-2761gxdk.conf =================================================================== --- buildrom-devel/config/platforms/ga-2761gxdk.conf 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/config/platforms/ga-2761gxdk.conf 2008-05-06 15:30:32 UTC (rev 181) @@ -34,8 +34,6 @@ COREBOOT_VENDOR=gigabyte COREBOOT_BOARD=ga_2761gxdk -CBV2_CONFIG=Config.lb -CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=ga_2761gxdk CBV2_TAG=3092 Modified: buildrom-devel/config/platforms/m57sli.conf =================================================================== --- buildrom-devel/config/platforms/m57sli.conf 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/config/platforms/m57sli.conf 2008-05-06 15:30:32 UTC (rev 181) @@ -38,8 +38,6 @@ COREBOOT_VENDOR=gigabyte COREBOOT_BOARD=m57sli -CBV2_CONFIG=Config.lb -CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=m57sli CBV2_TAG=3118 Modified: buildrom-devel/config/platforms/msm800sev.conf =================================================================== --- buildrom-devel/config/platforms/msm800sev.conf 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/config/platforms/msm800sev.conf 2008-05-06 15:30:32 UTC (rev 181) @@ -28,8 +28,6 @@ COREBOOT_VENDOR=digitallogic COREBOOT_BOARD=msm800sev -CBV2_CONFIG=Config.lb -CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=msm800sev CBV2_TAG=3079 Modified: buildrom-devel/config/platforms/norwich.conf =================================================================== --- buildrom-devel/config/platforms/norwich.conf 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/config/platforms/norwich.conf 2008-05-06 15:30:32 UTC (rev 181) @@ -28,8 +28,6 @@ COREBOOT_VENDOR=amd COREBOOT_BOARD=norwich -CBV2_CONFIG=Config.lb -CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=norwich CBV2_TAG=3090 Modified: buildrom-devel/config/platforms/qemu.conf =================================================================== --- buildrom-devel/config/platforms/qemu.conf 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/config/platforms/qemu.conf 2008-05-06 15:30:32 UTC (rev 181) @@ -24,9 +24,7 @@ ETHERBOOT_ARCH=i386 # coreboot-v2 configuration -CBV2_TAG=3241 -CBV2_CONFIG=Config.lb -CBV2_PAYLOAD_FILE_EXT=elf +CBV2_TAG=3281 CBV2_TDIR=qemu-x86 # coreboot v3 configuration Modified: buildrom-devel/config/platforms/serengeti_cheetah.conf =================================================================== --- buildrom-devel/config/platforms/serengeti_cheetah.conf 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/config/platforms/serengeti_cheetah.conf 2008-05-06 15:30:32 UTC (rev 181) @@ -43,8 +43,6 @@ # coreboot configuration COREBOOT_VENDOR=amd -CBV2_CONFIG=Config.lb -CBV2_PAYLOAD_FILE_EXT=elf CBV3_TAG=HEAD Modified: buildrom-devel/config/platforms/supermicro-h8dmr.conf =================================================================== --- buildrom-devel/config/platforms/supermicro-h8dmr.conf 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/config/platforms/supermicro-h8dmr.conf 2008-05-06 15:30:32 UTC (rev 181) @@ -38,8 +38,6 @@ COREBOOT_VENDOR=supermicro COREBOOT_BOARD=h8dmr -CBV2_CONFIG=Config.lb -CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=h8dmr CBV2_TAG=3278 Modified: buildrom-devel/config/platforms/tyan-s2881.conf =================================================================== --- buildrom-devel/config/platforms/tyan-s2881.conf 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/config/platforms/tyan-s2881.conf 2008-05-06 15:30:32 UTC (rev 181) @@ -38,8 +38,6 @@ COREBOOT_VENDOR=tyan COREBOOT_BOARD=s2881 -CBV2_CONFIG=Config.lb -CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=s2881 CBV2_TAG=3131 Modified: buildrom-devel/config/platforms/tyan-s2882.conf =================================================================== --- buildrom-devel/config/platforms/tyan-s2882.conf 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/config/platforms/tyan-s2882.conf 2008-05-06 15:30:32 UTC (rev 181) @@ -38,8 +38,6 @@ COREBOOT_VENDOR=tyan COREBOOT_BOARD=s2882 -CBV2_CONFIG=Config.lb -CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=s2882 CBV2_TAG=3114 Modified: buildrom-devel/config/platforms/tyan-s2891.conf =================================================================== --- buildrom-devel/config/platforms/tyan-s2891.conf 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/config/platforms/tyan-s2891.conf 2008-05-06 15:30:32 UTC (rev 181) @@ -38,8 +38,6 @@ COREBOOT_VENDOR=tyan COREBOOT_BOARD=s2891 -CBV2_CONFIG=Config.lb -CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=s2891 CBV2_TAG=3259 Modified: buildrom-devel/config/platforms/tyan-s2892.conf =================================================================== --- buildrom-devel/config/platforms/tyan-s2892.conf 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/config/platforms/tyan-s2892.conf 2008-05-06 15:30:32 UTC (rev 181) @@ -36,8 +36,6 @@ COREBOOT_VENDOR=tyan COREBOOT_BOARD=s2892 -CBV2_CONFIG=Config.lb -CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=s2892 CBV2_TAG=3259 Modified: buildrom-devel/config/platforms/tyan-s2895.conf =================================================================== --- buildrom-devel/config/platforms/tyan-s2895.conf 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/config/platforms/tyan-s2895.conf 2008-05-06 15:30:32 UTC (rev 181) @@ -36,8 +36,6 @@ COREBOOT_VENDOR=tyan COREBOOT_BOARD=s2895 -CBV2_CONFIG=Config.lb -CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=s2895 CBV2_TAG=3259 Modified: buildrom-devel/packages/coreboot-v2/coreboot.inc =================================================================== --- buildrom-devel/packages/coreboot-v2/coreboot.inc 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/packages/coreboot-v2/coreboot.inc 2008-05-06 15:30:32 UTC (rev 181) @@ -1,5 +1,13 @@ # This is the common code included by all the targets +ifeq ($(CONFIG_USE_LZMA),y) + CBV2_CONFIG=Config-lab.lb + CBV2_PAYLOAD_FILE_EXT=elf.lzma +else + CBV2_CONFIG=Config.lb + CBV2_PAYLOAD_FILE_EXT=elf +endif + ifeq ($(CONFIG_CB_CUSTOM_REV),y) $(warning Using custom rev $(CONFIG_CB_REVISION)) CBV2_TAG=$(CONFIG_CB_REVISION) Modified: buildrom-devel/packages/coreboot-v2/generic.mk =================================================================== --- buildrom-devel/packages/coreboot-v2/generic.mk 2008-05-05 20:54:01 UTC (rev 180) +++ buildrom-devel/packages/coreboot-v2/generic.mk 2008-05-06 15:30:32 UTC (rev 181) @@ -1,20 +1,5 @@ # This is the Generic coreboot target -ifeq ($(CONFIG_PAYLOAD_OFW),y) - CBV2_CONFIG=Config-lab.lb - CBV2_PAYLOAD_FILE_EXT=elf.lzma -endif - -ifeq ($(CONFIG_PAYLOAD_KERNEL),y) - CBV2_CONFIG=Config-lab.lb - CBV2_PAYLOAD_FILE_EXT=elf.lzma -endif - -ifeq ($(CONFIG_PAYLOAD_LAB),y) - CBV2_CONFIG=Config-lab.lb - CBV2_PAYLOAD_FILE_EXT=elf.lzma -endif - include $(PACKAGE_DIR)/coreboot-v2/coreboot.inc coreboot: generic-coreboot From mylesgw at gmail.com Tue May 6 17:31:53 2008 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 6 May 2008 09:31:53 -0600 Subject: [coreboot] Buildrom lzma patch and update QEMU Config-lab.lb In-Reply-To: <20080506151410.GJ9450@cosmic.amd.com> References: <2831fecf0805011341n1b83e7bbl14fa57d32458bfad@mail.gmail.com> <2831fecf0805060808h68c396d8ue20c686c08f9d8da@mail.gmail.com> <20080506151410.GJ9450@cosmic.amd.com> Message-ID: <2831fecf0805060831p48929c8rb11ec1150f4ed2a3@mail.gmail.com> On Tue, May 6, 2008 at 9:14 AM, Jordan Crouse wrote: > On 06/05/08 09:08 -0600, Myles Watson wrote: > > On Thu, May 1, 2008 at 2:41 PM, Myles Watson wrote: > > > These patches go together and make it so that checking the "USE_LZMA" > > > option in buildrom doesn't break builds. > > > > > > It assumes that all Config.lb files don't use compression, and all > > > Config-lab.lb files do. > > > Acked-by: Jordan Crouse V2 Rev 3281. Buildrom Rev 181. Thanks, Myles Thanks From jordan.crouse at amd.com Tue May 6 17:37:50 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 6 May 2008 09:37:50 -0600 Subject: [coreboot] buildrom: cleanup package includes (updated) In-Reply-To: <000001c8af19$f6bfd770$1a02a8c0@chimp> References: <20080505215447.GE9450@cosmic.amd.com> <004401c8af04$0ac742a0$0023040a@chimp> <20080505232948.GG9450@cosmic.amd.com> <20080505235739.GH9450@cosmic.amd.com> <000001c8af19$f6bfd770$1a02a8c0@chimp> Message-ID: <20080506153750.GK9450@cosmic.amd.com> On 05/05/08 19:39 -0600, Myles Watson wrote: > > > > -----Original Message----- > > From: Jordan Crouse [mailto:jordan.crouse at amd.com] > > Sent: Monday, May 05, 2008 5:58 PM > > To: Myles Watson > > Cc: coreboot at coreboot.org > > Subject: Re: buildrom: cleanup package includes (updated) > > > > On 05/05/08 17:29 -0600, Jordan Crouse wrote: > > > On 05/05/08 17:02 -0600, Myles Watson wrote: > > > > > > > > > > > > > -----Original Message----- > > > > > From: coreboot-bounces at coreboot.org [mailto:coreboot- > > bounces at coreboot.org] > > > > > On Behalf Of Jordan Crouse > > > > > Sent: Monday, May 05, 2008 3:55 PM > > > > > To: coreboot at coreboot.org > > > > > Subject: [coreboot] buildrom: cleanup package includes (updated) > > > > > > > > > > Attached is an updated version of the patch I sent before that > > > > > streamined the .mk files that are included in buildrom. This > > version > > > > > is updated with the latest and greatest from Myles and everybody. > > > > > > > > > > Tested with all payloads + coreinfo, and hd8mr + kernel (I'm going > > to > > > > > test the other platforms with kernel, but I didn't want to wait > > around > > > > > for them to finish building). > > > > > > > > Acked-by: Myles Watson > > > > > > Thanks - I am going to wait on this until tomorrow. Coreboot-v2 + > > kernel > > > failed on 13 of 17 targets (and only 3 failures are due to missing .mk > > files). > > > I don't know if this is becuase of my patch, my test harness, or > > something > > > else. Either way, it is best that I hold off until I can debug it more > > > fully. > > > > I had a second to build one of the failing platforms at random (s2882), > > and > > the error ended up being that the kernel was too big for the ROM. I'm > > going > > to go ahead and re-run the entire test with verboseness turned on over > > night to get a clear picture of which platforms need love. > > > > Several of the platforms have kernels that have never fit for me. I always > figured the problem was my broken toolchain. I only test that changes don't > break things that were working. Its a good thing I waited - I had a misspelling in coreboot-v2.mk (PLAFORM_GEODE). I fixed that, and the Geode platforms still failed, but at least this time they failed because of size. So, for the record, the following platforms have kernel configs that are too big (or don't have an accomodating Config.lb): dbe61 db800 ga-m57sli-s4 serengeti-cheetah norwich msm800sev alix1c s2892 s2881 s2882 The following platforms have no kernel.mk: a8v-e-se s-c-fam10 ga-2761gxdk And the following platforms build a kernel successfully: h8dmr qemu s2891 s2895 All platforms successfully built FILO and coreinfo. I haven't yet added any of the other payloads to the test. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From rminnich at gmail.com Tue May 6 17:37:34 2008 From: rminnich at gmail.com (ron minnich) Date: Tue, 6 May 2008 08:37:34 -0700 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <48204BF0.1060407@gmx.net> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> Message-ID: <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> On Tue, May 6, 2008 at 5:15 AM, Carl-Daniel Hailfinger > Indeed. Since we don't use the struct device passed in to ide_init, why > don't we give Geode IDE its own struct device_operations and store the > IDE config there? That's a great question. The reason is that the cs5536 is one chip. On v2, we treated it as more than one. For my goal of easing non-experts into the code, I decided to try making it one chip and one dts. This is an experiment that may, in the end, prove wrong. I still think one dts per chip is the right way to go, but do we need more than one level of dts? I really think this all should be in one file, it got much simpler that way. > I have problems parsing the sentence above: "... I don't think it was > ever IDE." I should not write when that tired. Let's try again. Works on 2.6.24. hangs on 2.6.25, I thought for a second it was NOT ide, but it is clear that 2.6.25 is hanging on probing ide1 -- or it sure looks that way. And, again, the post code of 00 is weird; I keep thinking there are vsa issues here. It just doesn't act like Linux hangs I see on other boards. > You know my preference for killing dev_find_pci_device, but that can > come later if it is too difficult. > I have no disagreement as long as, in so doing, we reduce code overall and increase comprehensability. > Acked-by: Carl-Daniel Hailfinger many thanks! ron From svn at coreboot.org Tue May 6 17:37:56 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Tue, 6 May 2008 17:37:56 +0200 Subject: [coreboot] r182 - in buildrom-devel: . config/payloads config/platforms packages/coreboot-v2 packages/geodevsa packages/kernel packages/roms Message-ID: Author: jcrouse Date: 2008-05-06 17:37:55 +0200 (Tue, 06 May 2008) New Revision: 182 Added: buildrom-devel/packages/coreboot-v2/coreboot-v2.mk buildrom-devel/packages/kernel/kernel.mk Removed: buildrom-devel/packages/roms/rom-geode.inc Modified: buildrom-devel/Makefile buildrom-devel/config/payloads/generic.conf buildrom-devel/config/payloads/kernel.conf buildrom-devel/config/payloads/lab.conf buildrom-devel/config/payloads/libpayload-dep.conf buildrom-devel/config/payloads/payloads.conf buildrom-devel/config/platforms/alix1c.conf buildrom-devel/config/platforms/alix2c3.conf buildrom-devel/config/platforms/asus_a8v-e_se.conf buildrom-devel/config/platforms/db800.conf buildrom-devel/config/platforms/dbe61.conf buildrom-devel/config/platforms/ga-2761gxdk.conf buildrom-devel/config/platforms/m57sli.conf buildrom-devel/config/platforms/msm800sev.conf buildrom-devel/config/platforms/norwich.conf buildrom-devel/config/platforms/platforms.conf buildrom-devel/config/platforms/qemu.conf buildrom-devel/config/platforms/serengeti_cheetah.conf buildrom-devel/config/platforms/supermicro-h8dmr.conf buildrom-devel/config/platforms/tyan-s2881.conf buildrom-devel/config/platforms/tyan-s2882.conf buildrom-devel/config/platforms/tyan-s2891.conf buildrom-devel/config/platforms/tyan-s2892.conf buildrom-devel/config/platforms/tyan-s2895.conf buildrom-devel/packages/geodevsa/geodevsa.mk buildrom-devel/packages/roms/roms.mk Log: buildrom: Consolidate and streamline how packages are included and managed. Signed-off-by: Jordan Crouse Acked-by: Myles Watson Modified: buildrom-devel/Makefile =================================================================== --- buildrom-devel/Makefile 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/Makefile 2008-05-06 15:37:55 UTC (rev 182) @@ -40,7 +40,8 @@ else WGET_Q = "-q" endif - + +DEPENDS-y= include $(CONFIG_DIR)/platforms/platforms.conf include $(CONFIG_DIR)/payloads/payloads.conf @@ -57,7 +58,7 @@ # elsewhere, but what the heck - its easy. COREBOOT-$(CONFIG_COREBOOT_V2) = coreboot -COREBOOT-$(CONFIG_COREBOOT_V3) = coreboot-v3 roms +COREBOOT-$(CONFIG_COREBOOT_V3) = coreboot-v3 # Add openvsa as a dependency if it is configured to be used; this makes sure # that make distclean will clear out work/openvsa (see below) @@ -88,23 +89,17 @@ LAR_PAYLOAD_FLAGS-y=-a -e LAR_PAYLOAD_FLAGS-$(CONFIG_USE_LZMA) += -C lzma -ifeq ($(or $(CONFIG_VSA_LEGACY), $(CONFIG_VSA_OPENVSA)),) -else -OPTIONROM_TARGETS+=geodevsa -endif - rom: $(HOSTTOOLS-y) payload $(COREBOOT-y) + @ mkdir -p $(shell dirname $(TARGET_ROM_FILE)) @ cp $(CBV3_OUTPUT) $(TARGET_ROM_FILE) @ $(STAGING_DIR)/bin/lar $(LAR_PAYLOAD_FLAGS-y) $(TARGET_ROM_FILE) $(PAYLOAD_TARGET):normal/payload -ifeq ($(CONFIG_VSA_LEGACY),y) - @ $(STAGING_DIR)/bin/lar $(LAR_PAYLOAD_FLAGS-y) $(TARGET_ROM_FILE) $(SOURCE_DIR)/amd_vsa_lx_1.01.bin:blob/vsa -endif -ifeq ($(CONFIG_VSA_OPENVSA),y) - @ $(STAGING_DIR)/bin/lar $(LAR_PAYLOAD_FLAGS-y) $(TARGET_ROM_FILE) $(OPENVSA_SRC_DIR)/vsa_lx.bin:blob/vsa -endif - @ for file in `ls $(ROM_DIR)`; do \ - $(STAGING_DIR)/bin/lar $(LAR_PAYLOAD_FLAGS-y) $(TARGET_ROM_FILE) $(ROM_DIR)/$$file:$$file; \ - done + @ if [ -d $(ROM_DIR) ]; then \ + for file in `find $(ROM_DIR) -type f`; do \ + b=`echo $$file | sed -e s:^$(ROM_DIR)\/*::`; \ + $(STAGING_DIR)/bin/lar $(LAR_PAYLOAD_FLAGS-y) \ + $(TARGET_ROM_FILE) $$file:$$b; \ + done; \ + fi @ $(STAGING_DIR)/bin/lar -z $(TARGET_ROM_FILE) endif @@ -129,28 +124,20 @@ include $(PAYLOAD_BUILD) endif -# The following code gets all the make targets, but filters out the kernel -# targets which are implicitly set by the platform configuration +INCMK=$(foreach mk,$(DEPENDS-y) $(PAYLOAD-y) $(HOSTTOOLS-y),$(PACKAGE_DIR)/$(mk)/$(mk).mk) -ifneq ($(PAYLOAD_AND_DEP_MK),) -include $(PAYLOAD_AND_DEP_MK) -endif - -include $(PACKAGE_DIR)/nrv2b/nrv2b.mk -include $(PACKAGE_DIR)/lzma/lzma.mk -include $(PACKAGE_DIR)/geodevsa/geodevsa.mk -include $(PACKAGE_DIR)/roms/roms.mk - -include $(KERNEL_MK) - ifeq ($(CONFIG_COREBOOT_V2),y) -include $(CBV2_MK) +INCMK += $(PACKAGE_DIR)/coreboot-v2/coreboot-v2.mk else -include $(PACKAGE_DIR)/coreboot-v3/coreboot-v3.mk +INCMK += $(PACKAGE_DIR)/coreboot-v3/coreboot-v3.mk endif +ifneq ($(INCMK),) +include $(INCMK) endif +endif + super-distclean: @ make -C $(KCONFIG_DIR) clean @ rm -rf $(BUILD_DIR) Modified: buildrom-devel/config/payloads/generic.conf =================================================================== --- buildrom-devel/config/payloads/generic.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/payloads/generic.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -4,5 +4,3 @@ PAYLOAD_ELF=$(OUTPUT_DIR)/$(PAYLOAD-y)-payload.elf PAYLOAD_COMPRESSED=$(PAYLOAD_ELF).lzma - -PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/$(PAYLOAD-y)/$(PAYLOAD-y).mk Modified: buildrom-devel/config/payloads/kernel.conf =================================================================== --- buildrom-devel/config/payloads/kernel.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/payloads/kernel.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -15,5 +15,4 @@ PAYLOAD_ELF=$(OUTPUT_DIR)/kernel-payload.elf PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/kernel-payload.elf.lzma -HOSTTOOLS-y = mkelfimage -PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/mkelfimage/mkelfimage.mk +HOSTTOOLS-y += mkelfimage unifdef Modified: buildrom-devel/config/payloads/lab.conf =================================================================== --- buildrom-devel/config/payloads/lab.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/payloads/lab.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -30,20 +30,4 @@ PAYLOAD-$(CONFIG_BOOTMENU) += bootmenu PAYLOAD-$(CONFIG_OLPCFLASH) += olpcflash -HOSTTOOLS-y = mkelfimage unifdef -PAYLOAD_AND_DEP_MK=$(PACKAGE_DIR)/mkelfimage/mkelfimage.mk -PAYLOAD_AND_DEP_MK+=$(PACKAGE_DIR)/uclibc/uclibc.mk -PAYLOAD_AND_DEP_MK+=$(PACKAGE_DIR)/unifdef/unifdef.mk - -ifeq ($(CONFIG_KBL),y) - PAYLOAD_AND_DEP_MK+=$(PACKAGE_DIR)/kexec-boot-loader/kexec-boot-loader.mk -endif -ifeq ($(CONFIG_BUSYBOX),y) - PAYLOAD_AND_DEP_MK+=$(PACKAGE_DIR)/busybox/busybox.mk -endif -ifeq ($(CONFIG_BOOTMENU),y) - PAYLOAD_AND_DEP_MK+=$(PACKAGE_DIR)/bootmenu/bootmenu.mk -endif -ifeq ($(CONFIG_OLPCFLASH),y) - PAYLOAD_AND_DEP_MK+=$(PACKAGE_DIR)/olpcflash/olpcflash.mk -endif +HOSTTOOLS-y += mkelfimage unifdef Modified: buildrom-devel/config/payloads/libpayload-dep.conf =================================================================== --- buildrom-devel/config/payloads/libpayload-dep.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/payloads/libpayload-dep.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -3,5 +3,4 @@ include $(CONFIG_DIR)/payloads/generic.conf # Add libpayload as a dependency -PAYLOAD_AND_DEP_MK+= $(PACKAGE_DIR)/libpayload/libpayload.mk DEPENDS-y=libpayload Modified: buildrom-devel/config/payloads/payloads.conf =================================================================== --- buildrom-devel/config/payloads/payloads.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/payloads/payloads.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -41,7 +41,6 @@ PCONF-$(CONFIG_PAYLOAD_OPENBIOS) = openbios.conf PCONF-$(CONFIG_PAYLOAD_TINT) = libpayload-dep.conf -DEPENDS-y= include $(CONFIG_DIR)/payloads/$(PCONF-y) # Add LZMA if it is enabled and we are using v2 Modified: buildrom-devel/config/platforms/alix1c.conf =================================================================== --- buildrom-devel/config/platforms/alix1c.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/platforms/alix1c.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -9,11 +9,6 @@ TARGET_ARCH=i586 CFLAGS_platform = -# Targets - -KERNEL_MK=$(PACKAGE_DIR)/kernel/alix1c.mk -CBV2_MK=$(PACKAGE_DIR)/coreboot-v2/geodelx.mk - # kernel configuration (for LAB) KERNEL_VERSION=2.6.20.2 Modified: buildrom-devel/config/platforms/alix2c3.conf =================================================================== --- buildrom-devel/config/platforms/alix2c3.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/platforms/alix2c3.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -9,10 +9,6 @@ TARGET_ARCH=i586 CFLAGS_platform = -# Targets - -KERNEL_MK=$(PACKAGE_DIR)/kernel/alix2c3.mk - # kernel configuration (for LAB) KERNEL_VERSION=2.6.20.2 Modified: buildrom-devel/config/platforms/asus_a8v-e_se.conf =================================================================== --- buildrom-devel/config/platforms/asus_a8v-e_se.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/platforms/asus_a8v-e_se.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -14,12 +14,6 @@ CFLAGS_platform = endif -# Targets - -# TODO -# KERNEL_MK=$(PACKAGE_DIR)/kernel/asus_a8v-e_se.mk -CBV2_MK=$(PACKAGE_DIR)/coreboot-v2/generic.mk - # kernel configuration (for LAB) # TODO Modified: buildrom-devel/config/platforms/db800.conf =================================================================== --- buildrom-devel/config/platforms/db800.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/platforms/db800.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -10,12 +10,6 @@ TARGET_ARCH=i586 CFLAGS_platform = -# Targets -# Use the same settings as the Norwich platform - -KERNEL_MK=$(PACKAGE_DIR)/kernel/norwich.mk -CBV2_MK=$(PACKAGE_DIR)/coreboot-v2/geodelx.mk - # kernel configuration (for LAB) # Use the same settings as the Norwich platform Modified: buildrom-devel/config/platforms/dbe61.conf =================================================================== --- buildrom-devel/config/platforms/dbe61.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/platforms/dbe61.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -11,11 +11,6 @@ TARGET_ARCH=i586 CFLAGS_platform = -# Targets - -KERNEL_MK=$(PACKAGE_DIR)/kernel/norwich.mk -CBV2_MK=$(PACKAGE_DIR)/coreboot-v2/geodelx.mk - # kernel configuration (for LAB) KERNEL_VERSION=2.6.20.2 Modified: buildrom-devel/config/platforms/ga-2761gxdk.conf =================================================================== --- buildrom-devel/config/platforms/ga-2761gxdk.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/platforms/ga-2761gxdk.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -14,12 +14,6 @@ CFLAGS_platform = endif -# Targets - -# Disable for now - I don't know the right kernel for this platform -#KERNEL_MK=$(PACKAGE_DIR)/kernel/ -CBV2_MK=$(PACKAGE_DIR)/coreboot-v2/ga-2761gxdk.mk - # kernel configuration (for LAB) # Disable for now - I don't know the right kernel for this platform Modified: buildrom-devel/config/platforms/m57sli.conf =================================================================== --- buildrom-devel/config/platforms/m57sli.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/platforms/m57sli.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -14,11 +14,6 @@ CFLAGS_platform = endif -# Targets - -KERNEL_MK=$(PACKAGE_DIR)/kernel/m57sli.mk -CBV2_MK=$(PACKAGE_DIR)/coreboot-v2/generic.mk - # kernel configuration (for LAB) KERNEL_VERSION=2.6.22.2 Modified: buildrom-devel/config/platforms/msm800sev.conf =================================================================== --- buildrom-devel/config/platforms/msm800sev.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/platforms/msm800sev.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -10,11 +10,6 @@ TARGET_ARCH=i586 CFLAGS_platform = -# Targets - -KERNEL_MK=$(PACKAGE_DIR)/kernel/msm800sev.mk -CBV2_MK=$(PACKAGE_DIR)/coreboot-v2/geodelx.mk - # kernel configuration (for LAB) KERNEL_VERSION=2.6.20.2 Modified: buildrom-devel/config/platforms/norwich.conf =================================================================== --- buildrom-devel/config/platforms/norwich.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/platforms/norwich.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -10,11 +10,6 @@ TARGET_ARCH=i586 CFLAGS_platform = -# Targets - -KERNEL_MK=$(PACKAGE_DIR)/kernel/norwich.mk -CBV2_MK=$(PACKAGE_DIR)/coreboot-v2/geodelx.mk - # kernel configuration (for LAB) KERNEL_VERSION=2.6.20.2 Modified: buildrom-devel/config/platforms/platforms.conf =================================================================== --- buildrom-devel/config/platforms/platforms.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/platforms/platforms.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -1,8 +1,6 @@ # This will include the correct configuration for the # selected platform -CBV2_MK=$(PACKAGE_DIR)/coreboot-v2/generic.mk - ##Include the correct platform configuration PLATFORM-y= @@ -26,3 +24,9 @@ PLATFORM-$(CONFIG_PLATFORM_QEMU-X86) = qemu.conf include $(CONFIG_DIR)/platforms/$(PLATFORM-y) + +# Platform specific dependencies +DEPENDS-$(CONFIG_PLATFORM_GEODE) += geodevsa + +# For those platforms that have option roms, add the following line +#DEPENDS-$(MYPLATFORM) += roms Modified: buildrom-devel/config/platforms/qemu.conf =================================================================== --- buildrom-devel/config/platforms/qemu.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/platforms/qemu.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -9,11 +9,6 @@ TARGET_ARCH=i686 CFLAGS_platform = -# Targets - -KERNEL_MK=$(PACKAGE_DIR)/kernel/qemu.mk -CBV2_MK=$(PACKAGE_DIR)/coreboot-v2/generic.mk - # kernel configuration (for LAB) KERNEL_VERSION=2.6.22.2 Modified: buildrom-devel/config/platforms/serengeti_cheetah.conf =================================================================== --- buildrom-devel/config/platforms/serengeti_cheetah.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/platforms/serengeti_cheetah.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -15,11 +15,6 @@ CFLAGS_platform = endif -# Targets - -KERNEL_MK=$(PACKAGE_DIR)/kernel/serengeti_cheetah.mk -CBV2_MK=$(PACKAGE_DIR)/coreboot-v2/serengeti_cheetah.mk - # kernel configuration (for LAB) ifeq ($(CONFIG_TARGET_64BIT),y) Modified: buildrom-devel/config/platforms/supermicro-h8dmr.conf =================================================================== --- buildrom-devel/config/platforms/supermicro-h8dmr.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/platforms/supermicro-h8dmr.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -14,11 +14,6 @@ CFLAGS_platform = endif -# Targets - -KERNEL_MK=$(PACKAGE_DIR)/kernel/supermicro-h8dmr.mk -CBV2_MK=$(PACKAGE_DIR)/coreboot-v2/generic.mk - # kernel configuration (for LAB) KERNEL_VERSION=2.6.22.2 Modified: buildrom-devel/config/platforms/tyan-s2881.conf =================================================================== --- buildrom-devel/config/platforms/tyan-s2881.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/platforms/tyan-s2881.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -14,11 +14,6 @@ CFLAGS_platform = endif -# Targets - -KERNEL_MK=$(PACKAGE_DIR)/kernel/tyan-s2881.mk -CBV2_MK=$(PACKAGE_DIR)/coreboot-v2/generic.mk - # kernel configuration (for LAB) KERNEL_VERSION=2.6.22.2 Modified: buildrom-devel/config/platforms/tyan-s2882.conf =================================================================== --- buildrom-devel/config/platforms/tyan-s2882.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/platforms/tyan-s2882.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -14,11 +14,6 @@ CFLAGS_platform = endif -# Targets - -KERNEL_MK=$(PACKAGE_DIR)/kernel/tyan-s2882.mk -CBV2_MK=$(PACKAGE_DIR)/coreboot-v2/generic.mk - # kernel configuration (for LAB) KERNEL_VERSION=2.6.22.2 Modified: buildrom-devel/config/platforms/tyan-s2891.conf =================================================================== --- buildrom-devel/config/platforms/tyan-s2891.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/platforms/tyan-s2891.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -14,11 +14,6 @@ CFLAGS_platform = endif -# Targets - -KERNEL_MK=$(PACKAGE_DIR)/kernel/tyan-s2891.mk -CBV2_MK=$(PACKAGE_DIR)/coreboot-v2/generic.mk - # kernel configuration (for LAB) KERNEL_VERSION=2.6.22.2 Modified: buildrom-devel/config/platforms/tyan-s2892.conf =================================================================== --- buildrom-devel/config/platforms/tyan-s2892.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/platforms/tyan-s2892.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -14,11 +14,6 @@ CFLAGS_platform = endif -# Targets - -KERNEL_MK=$(PACKAGE_DIR)/kernel/tiny-2.6.22.mk -CBV2_MK=$(PACKAGE_DIR)/coreboot-v2/generic.mk - # kernel configuration (for LAB) KERNEL_VERSION=2.6.22.2 Modified: buildrom-devel/config/platforms/tyan-s2895.conf =================================================================== --- buildrom-devel/config/platforms/tyan-s2895.conf 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/config/platforms/tyan-s2895.conf 2008-05-06 15:37:55 UTC (rev 182) @@ -14,11 +14,6 @@ CFLAGS_platform = endif -# Targets - -KERNEL_MK=$(PACKAGE_DIR)/kernel/tiny-2.6.22.mk -CBV2_MK=$(PACKAGE_DIR)/coreboot-v2/generic.mk - # kernel configuration (for LAB) KERNEL_VERSION=2.6.22.2 Added: buildrom-devel/packages/coreboot-v2/coreboot-v2.mk =================================================================== --- buildrom-devel/packages/coreboot-v2/coreboot-v2.mk (rev 0) +++ buildrom-devel/packages/coreboot-v2/coreboot-v2.mk 2008-05-06 15:37:55 UTC (rev 182) @@ -0,0 +1,15 @@ +# "toplevel" coreboot-v2.mk - this is where we decide +# which of the platform specific files to actually +# include + +# Most platforms use the generic target +CBV2MK-y=$(PACKAGE_DIR)/coreboot-v2/generic.mk + +# All Geode LX targets use the same .mk file +CBV2MK-$(CONFIG_PLATFORM_GEODE) = $(PACKAGE_DIR)/coreboot-v2/geodelx.mk + +CBV2MK-$(CONFIG_PLATFORM_GA_2761GXDK) = $(PACKAGE_DIR)/coreboot-v2/ga-2761gxdk.mk +CBV2MK-$(CONFIG_PLATFORM_SERENGETI_CHEETAH) = $(PACKAGE_DIR)/coreboot-v2/serengeti_cheetah.mk +CBV2MK-$(CONFIG_PLATFORM_CHEETAH_FAM10) = $(PACKAGE_DIR)/coreboot-v2/serengeti_cheetah.mk + +include $(CBV2MK-y) Modified: buildrom-devel/packages/geodevsa/geodevsa.mk =================================================================== --- buildrom-devel/packages/geodevsa/geodevsa.mk 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/packages/geodevsa/geodevsa.mk 2008-05-06 15:37:55 UTC (rev 182) @@ -12,6 +12,10 @@ VSA_BUILD_TARGET = $(GEODE_UNCOMPRESSED_VSA) endif +ifeq ($(CONFIG_COREBOOT_V3),y) +VSA_ROM_FILE = $(ROM_DIR)/blob/vsa +endif + VSA_CLEAN_TARGET= VSA_DISTCLEAN_TARGET= @@ -31,13 +35,19 @@ $(GEODE_PADDED_VSA): $(GEODE_COMPRESSED_VSA) @ cp $< $@ @ (size=`stat -c %s $<`; count=`expr $(GEODE_VSA_SIZE) - $$size`; \ - dd if=/dev/zero bs=1 count=$$count >> $@ 2> /dev/null) + dd if=/dev/zero bs=1 count=$$count >> $@ 2> /dev/null) -geodevsa: $(VSA_BUILD_TARGET) +ifeq ($(CONFIG_COREBOOT_V3),y) +$(VSA_ROM_FILE): $(VSA_BUILD_TARGET) + mkdir -p $(shell dirname $(VSA_ROM_FILE)) + cp $(VSA_BUILD_TARGET) $(VSA_ROM_FILE) +endif +geodevsa: $(VSA_BUILD_TARGET) $(VSA_ROM_FILE) + geodevsa-clean: $(VSA_CLEAN_TARGET) @ rm -f $(GEODE_UNCOMPRESSED_VSA) $(GEODE_COMPRESSED_VSA) - @ rm -f $(GEODE_PADDED_VSA) + @ rm -f $(GEODE_PADDED_VSA) $(VSA_ROM_FILE) geodevsa-distclean: $(VSA_DISTCLEAN_TARGET) - @ rm -rf $(OUTPUT_DIR)/vsa + @ rm -rf $(OUTPUT_DIR)/vsa $(VSA_ROM_FILE) Added: buildrom-devel/packages/kernel/kernel.mk =================================================================== --- buildrom-devel/packages/kernel/kernel.mk (rev 0) +++ buildrom-devel/packages/kernel/kernel.mk 2008-05-06 15:37:55 UTC (rev 182) @@ -0,0 +1,31 @@ +# "toplevel" kernel.mk - this is where we decide +# which of the platform specific files to actually +# include + +KERNELMK-y= +KERNELMK-$(CONFIG_PLATFORM_NORWICH) = $(PACKAGE_DIR)/kernel/norwich.mk +KERNELMK-$(CONFIG_PLATFORM_MSM800SEV) = $(PACKAGE_DIR)/kernel/msm800sev.mk +KERNELMK-$(CONFIG_PLATFORM_ALIX1C) = $(PACKAGE_DIR)/kernel/alix1c.mk +KERNELMK-$(CONFIG_PLATFORM_ALIX2C3) = $(PACKAGE_DIR)/kernel/alix2c3.mk +KERNELMK-$(CONFIG_PLATFORM_DB800) = $(PACKAGE_DIR)/kernel/norwich.mk +KERNELMK-$(CONFIG_PLATFORM_DBE61) = $(PACKAGE_DIR)/kernel/norwich.mk +KERNELMK-$(CONFIG_PLATFORM_GA_M57SLI_S4) = $(PACKAGE_DIR)/kernel/m57sli.mk +KERNELMK-$(CONFIG_PLATFORM_TYAN_S2881) = $(PACKAGE_DIR)/kernel/tyan-s2881.mk +KERNELMK-$(CONFIG_PLATFORM_TYAN_S2882) = $(PACKAGE_DIR)/kernel/tyan-s2882.mk +KERNELMK-$(CONFIG_PLATFORM_TYAN_S2891) = $(PACKAGE_DIR)/kernel/tyan-s2891.mk +KERNELMK-$(CONFIG_PLATFORM_TYAN_S2892) = $(PACKAGE_DIR)/kernel/tiny-2.6.22.mk +KERNELMK-$(CONFIG_PLATFORM_TYAN_S2895) = $(PACKAGE_DIR)/kernel/tiny-2.6.22.mk +KERNELMK-$(CONFIG_PLATFORM_SUPERMICRO_H8DMR) = $(PACKAGE_DIR)/kernel/supermicro-h8dmr.mk +KERNELMK-$(CONFIG_PLATFORM_SERENGETI_CHEETAH) = $(PACKAGE_DIR)/kernel/serengeti_cheetah.mk +KERNELMK-$(CONFIG_PLATFORM_QEMU-X86) = $(PACKAGE_DIR)/kernel/qemu.mk + +# buildrom platforms that don't have a kernel .mk +#KERNELMK-$(CONFIG_PLATFORM_ASUS_A8V_E_SE) = +#KERNELMK-$(CONFIG_PLATFORM_CHEETAH_FAM10) = +#KERNELMK-$(CONFIG_PLATFORM_GA_2761GXDK) = + +ifeq ($(KERNELMK-y),) +$(error "You do not have a kernel .mk file defined for this platform") +endif + +include $(KERNELMK-y) Deleted: buildrom-devel/packages/roms/rom-geode.inc =================================================================== --- buildrom-devel/packages/roms/rom-geode.inc 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/packages/roms/rom-geode.inc 2008-05-06 15:37:55 UTC (rev 182) @@ -1,17 +0,0 @@ -# This is the geode specific optionrom target -# download VSA - -VSA_URL=http://www.amd.com/files/connectivitysolutions/geode/geode_lx/ -GEODE_VSA=lx_vsa.36k.bin - -$(SOURCE_DIR)/$(GEODE_VSA): - @ echo "Fetching the VSA code..." - @ wget $(wGET_Q) -P $(SOURCE_DIR) $(VSA_URL)/$(GEODE_VSA).gz -O $@ - -# Copy the file to the ROM_DIR - it should have the same name that it -# will have in the LAR - -$(ROM_DIR)/vsa: $(SOURCE_DIR)/$(GEODE_VSA): - @ cp $< $@ - -OPTIONROM_TARGETS += $(ROM_DIR)/vsa Modified: buildrom-devel/packages/roms/roms.mk =================================================================== --- buildrom-devel/packages/roms/roms.mk 2008-05-06 15:30:32 UTC (rev 181) +++ buildrom-devel/packages/roms/roms.mk 2008-05-06 15:37:55 UTC (rev 182) @@ -4,7 +4,6 @@ OPTIONROM_TARGETS?= OPTIONROM-y = -OPTIONROM-$(CONFIG_PLATFORM_NORWICH) += rom-geode.inc ifneq ($(OPTIONROMS-y),) include $(OPTIONROM-y) From c-d.hailfinger.devel.2006 at gmx.net Tue May 6 17:38:39 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 06 May 2008 17:38:39 +0200 Subject: [coreboot] winflashrom Message-ID: <48207B7F.4090207@gmx.net> Hi, I just found this interesting link on how to access arbitrary pci devices under windows the official way: http://support.microsoft.com/?scid=kb%3Ben-us%3B178660&x=10&y=12 Maybe it helps for winflashrom. IIRC the problem of doing the PCI accesses the "right way" is still unsolved. Regards, Carl-Daniel From svn at coreboot.org Tue May 6 17:39:08 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Tue, 6 May 2008 17:39:08 +0200 Subject: [coreboot] r183 - buildrom-devel/packages/coreboot-v2 Message-ID: Author: jcrouse Date: 2008-05-06 17:39:08 +0200 (Tue, 06 May 2008) New Revision: 183 Modified: buildrom-devel/packages/coreboot-v2/coreboot.inc buildrom-devel/packages/coreboot-v2/optionroms.inc Log: buildrom: Fix a parser error and add some informating messages for optionroms Signed-off-by: Jordan Crouse Acked-by: Myles Watson Modified: buildrom-devel/packages/coreboot-v2/coreboot.inc =================================================================== --- buildrom-devel/packages/coreboot-v2/coreboot.inc 2008-05-06 15:37:55 UTC (rev 182) +++ buildrom-devel/packages/coreboot-v2/coreboot.inc 2008-05-06 15:39:08 UTC (rev 183) @@ -86,7 +86,7 @@ include $(PACKAGE_DIR)/coreboot-v2/optionroms.inc # Add it to the front of the list so it is prepended to the coreboot output -CBV2_COMPONENTS=$(SOURCE_DIR)/$(OPTIONROM_ID).rom $(CBV2_COMPONENTS) +CBV2_COMPONENTS := $(SOURCE_DIR)/$(OPTIONROM_ID).rom $(CBV2_COMPONENTS) endif $(CBV2_PAYLOAD_TARGET): $(PAYLOAD_TARGET) Modified: buildrom-devel/packages/coreboot-v2/optionroms.inc =================================================================== --- buildrom-devel/packages/coreboot-v2/optionroms.inc 2008-05-06 15:37:55 UTC (rev 182) +++ buildrom-devel/packages/coreboot-v2/optionroms.inc 2008-05-06 15:39:08 UTC (rev 183) @@ -4,9 +4,11 @@ OPTIONROMURL=http://coreboot.org/data/optionroms/ $(OUTPUT_DIR)/$(OPTIONROM_ID).license: + @ echo "Fetching $(OPTIONROM_ID).license..." @ mkdir -p $(OUTPUT_DIR) @ wget $(WGET_Q) -P $(OUTPUT_DIR) $(OPTIONROMURL)/$(OPTIONROM_ID).license -O $@ $(SOURCE_DIR)/$(OPTIONROM_ID).rom: $(OUTPUT_DIR)/$(OPTIONROM_ID).license + @ echo "Fetching $(OPTIONROM_ID).rom..." @ mkdir -p $(SOURCE_DIR) @ wget $(WGET_Q) -P $(SOURCE_DIR) $(OPTIONROMURL)/$(OPTIONROM_ID).rom -O $@ From jordan.crouse at amd.com Tue May 6 17:41:25 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 6 May 2008 09:41:25 -0600 Subject: [coreboot] buildrom: Fix a parser error in coreboot.inc In-Reply-To: <004301c8af04$041ae2e0$0023040a@chimp> References: <20080505215700.GF9450@cosmic.amd.com> <004301c8af04$041ae2e0$0023040a@chimp> Message-ID: <20080506154125.GM9450@cosmic.amd.com> On 05/05/08 17:01 -0600, Myles Watson wrote: > > > > -----Original Message----- > > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] > > On Behalf Of Jordan Crouse > > Sent: Monday, May 05, 2008 3:57 PM > > To: coreboot at coreboot.org > > Subject: [coreboot] buildrom: Fix a parser error in coreboot.inc > > > > This fixes a parse error and adds informative messages when option ROMs > > are built in to coreboot. This only happens with the ga-2761gxdk, > > which is why we haven't seen this before. > > Acked-by: Myles Watson r183. Thanks. -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From jordan.crouse at amd.com Tue May 6 17:40:42 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 6 May 2008 09:40:42 -0600 Subject: [coreboot] buildrom: cleanup package includes (updated) In-Reply-To: <004401c8af04$0ac742a0$0023040a@chimp> References: <20080505215447.GE9450@cosmic.amd.com> <004401c8af04$0ac742a0$0023040a@chimp> Message-ID: <20080506154042.GL9450@cosmic.amd.com> On 05/05/08 17:02 -0600, Myles Watson wrote: > > > > -----Original Message----- > > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] > > On Behalf Of Jordan Crouse > > Sent: Monday, May 05, 2008 3:55 PM > > To: coreboot at coreboot.org > > Subject: [coreboot] buildrom: cleanup package includes (updated) > > > > Attached is an updated version of the patch I sent before that > > streamined the .mk files that are included in buildrom. This version > > is updated with the latest and greatest from Myles and everybody. > > > > Tested with all payloads + coreinfo, and hd8mr + kernel (I'm going to > > test the other platforms with kernel, but I didn't want to wait around > > for them to finish building). > > Acked-by: Myles Watson r182 - patch as posted + corrected mispelling of PLATFORM_GEODE > Thanks, > Myles > > -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From svn at coreboot.org Tue May 6 17:40:25 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Tue, 6 May 2008 17:40:25 +0200 Subject: [coreboot] r184 - buildrom-devel/packages/libpayload Message-ID: Author: jcrouse Date: 2008-05-06 17:40:24 +0200 (Tue, 06 May 2008) New Revision: 184 Modified: buildrom-devel/packages/libpayload/libpayload.mk Log: buildrom: Bump the revision for libpayload Trivial & self-acked. Signed-off-by: Jordan Crouse Acked-by: Jordan Crouse Modified: buildrom-devel/packages/libpayload/libpayload.mk =================================================================== --- buildrom-devel/packages/libpayload/libpayload.mk 2008-05-06 15:39:08 UTC (rev 183) +++ buildrom-devel/packages/libpayload/libpayload.mk 2008-05-06 15:40:24 UTC (rev 184) @@ -1,5 +1,5 @@ LIBPAYLOAD_URL=svn://coreboot.org/repos/trunk/payloads/libpayload -LIBPAYLOAD_TAG=3238 +LIBPAYLOAD_TAG=3272 LIBPAYLOAD_DIR=$(BUILD_DIR)/libpayload LIBPAYLOAD_SRC_DIR=$(LIBPAYLOAD_DIR)/svn From svn at coreboot.org Tue May 6 17:42:02 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Tue, 6 May 2008 17:42:02 +0200 Subject: [coreboot] r185 - buildrom-devel/packages/etherboot Message-ID: Author: myles Date: 2008-05-06 17:42:02 +0200 (Tue, 06 May 2008) New Revision: 185 Modified: buildrom-devel/packages/etherboot/etherboot.mk Log: This is a trivial patch which passes the ETHERBOOT_ARCH to make clean so that it works on x86_64 platforms. Signed-off-by: Myles Watson Acked-by: Myles Watson Modified: buildrom-devel/packages/etherboot/etherboot.mk =================================================================== --- buildrom-devel/packages/etherboot/etherboot.mk 2008-05-06 15:40:24 UTC (rev 184) +++ buildrom-devel/packages/etherboot/etherboot.mk 2008-05-06 15:42:02 UTC (rev 185) @@ -59,7 +59,7 @@ @ echo "Cleaning etherboot..." @ rm -f $(ETHERBOOT_STAMP_DIR)/.configured ifneq ($(wildcard $(ETHERBOOT_SRC_DIR)/Makefile),) - @ $(MAKE) -C $(ETHERBOOT_SRC_DIR) clean > /dev/null 2>&1 + @ $(MAKE) -C $(ETHERBOOT_SRC_DIR) ARCH=$(ETHERBOOT_ARCH) clean > /dev/null 2>&1 endif etherboot-distclean: From svn at coreboot.org Tue May 6 17:43:17 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Tue, 6 May 2008 17:43:17 +0200 Subject: [coreboot] r186 - buildrom-devel/config/platforms Message-ID: Author: jcrouse Date: 2008-05-06 17:43:16 +0200 (Tue, 06 May 2008) New Revision: 186 Modified: buildrom-devel/config/platforms/Config.in Log: buildrom: Serengeti-Cheetah doesn't work with v3 Limit s-c and s-c-fam10 to coreboot-v2 only. Trivial. Signed-off-by: Jordan Crouse Acked-by: Jordan Crouse Modified: buildrom-devel/config/platforms/Config.in =================================================================== --- buildrom-devel/config/platforms/Config.in 2008-05-06 15:42:02 UTC (rev 185) +++ buildrom-devel/config/platforms/Config.in 2008-05-06 15:43:16 UTC (rev 186) @@ -147,6 +147,7 @@ config PLATFORM_SERENGETI_CHEETAH bool "AMD Serengeti-Cheetah" depends on VENDOR_AMD + depends on COREBOOT_V2 select PLATFORM select PLATFORM_SUPPORT_64BIT @@ -160,6 +161,7 @@ config PLATFORM_CHEETAH_FAM10 bool "AMD Serengeti-Cheetah with fam10 processor" depends on VENDOR_AMD + depends on COREBOOT_V2 select PLATFORM select PLATFORM_SUPPORT_64BIT endchoice From mylesgw at gmail.com Tue May 6 17:50:05 2008 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 6 May 2008 09:50:05 -0600 Subject: [coreboot] buildrom: cleanup package includes (updated) In-Reply-To: <20080506153750.GK9450@cosmic.amd.com> References: <20080505215447.GE9450@cosmic.amd.com> <004401c8af04$0ac742a0$0023040a@chimp> <20080505232948.GG9450@cosmic.amd.com> <20080505235739.GH9450@cosmic.amd.com> <000001c8af19$f6bfd770$1a02a8c0@chimp> <20080506153750.GK9450@cosmic.amd.com> Message-ID: <002f01c8af90$db18dbd0$1a02a8c0@chimp> > > Its a good thing I waited - I had a misspelling in coreboot-v2.mk > (PLAFORM_GEODE). I fixed that, and the Geode platforms still failed, > but at least this time they failed because of size. > > So, for the record, the following platforms have kernel configs that are > too big (or don't have an accomodating Config.lb): > > dbe61 > db800 > ga-m57sli-s4 > serengeti-cheetah > norwich > msm800sev > alix1c > s2892 > s2881 > s2882 The Tyan boards should all work with 64-bit. That kernel is quite a bit smaller. Thanks, Myles > The following platforms have no kernel.mk: > > a8v-e-se > s-c-fam10 > ga-2761gxdk > > And the following platforms build a kernel successfully: > > h8dmr > qemu > s2891 > s2895 > > All platforms successfully built FILO and coreinfo. I haven't yet added > any of the other payloads to the test. > > Jordan From jordan.crouse at amd.com Tue May 6 18:03:26 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 6 May 2008 10:03:26 -0600 Subject: [coreboot] buildrom: cleanup package includes (updated) In-Reply-To: <002f01c8af90$db18dbd0$1a02a8c0@chimp> References: <20080505215447.GE9450@cosmic.amd.com> <004401c8af04$0ac742a0$0023040a@chimp> <20080505232948.GG9450@cosmic.amd.com> <20080505235739.GH9450@cosmic.amd.com> <000001c8af19$f6bfd770$1a02a8c0@chimp> <20080506153750.GK9450@cosmic.amd.com> <002f01c8af90$db18dbd0$1a02a8c0@chimp> Message-ID: <20080506160326.GN9450@cosmic.amd.com> On 06/05/08 09:50 -0600, Myles Watson wrote: > > > > Its a good thing I waited - I had a misspelling in coreboot-v2.mk > > (PLAFORM_GEODE). I fixed that, and the Geode platforms still failed, > > but at least this time they failed because of size. > > > > So, for the record, the following platforms have kernel configs that are > > too big (or don't have an accomodating Config.lb): > > > > dbe61 > > db800 > > ga-m57sli-s4 > > serengeti-cheetah > > norwich > > msm800sev > > alix1c > > s2892 > > s2881 > > s2882 > > The Tyan boards should all work with 64-bit. That kernel is quite a bit > smaller. Ahh - good point. I did all these with 32 bit builds. Thats an important data point. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From mylesgw at gmail.com Tue May 6 18:07:50 2008 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 6 May 2008 10:07:50 -0600 Subject: [coreboot] questions about "QEMU Build Tutorial" In-Reply-To: References: <03bf01c8ac66$fad7d6b0$0023040a@chimp> <03c401c8ac71$bef617a0$0023040a@chimp> Message-ID: <003b01c8af93$55a79b00$1a02a8c0@chimp> > On Sat, May 3, 2008 at 12:29 AM, Myles Watson wrote: > > > > Your contributions are welcome! > > > > "You must have cookies enabled to log in to coreboot. If you don't > have an account and wish to contribute contact Stefan Reinauer or > Ronald Minnich. NOTE: You don't need an account to read the > information on this site. So don't ask for an account unless you have > something to contribute." I'll put it up on the Wiki if you'd like, but I since you "have something to contribute", you could also ask for an account. Did you get this all to work like you wanted? Thanks, Myles > Here is a instruction with ugly format, hope I have not miss important > things. > > ==START== > My test env: debian etch with kernel 2.6.25. > > src prepare: > coreboot v2 - svn://coreboot.org/repos/trunk/coreboot-v2 > qemu-0.9.1.tar.gz/kqemu - http://fabrice.bellard.free.fr/qemu/ > filo-0.5 - svn co svn://coreboot.org/filo/trunk/filo-0.5 > linux src - http://www.kernel.org > linux rescue cd. - for partitions. > > build tools: > qemu: > New linux distributions use gcc4.x as default, but qemu needs > gcc-3.x, so maybe you need to install gcc3.4 (for debian users, 'sudo > apt-get install gcc-3.4') > $ cd qemu-0.9.1 > $ ./configure --cc=gcc-3.4 --target-list=i386-softmmu && make > $ sudo make install > > Ok, qemu is done. you can use "qemu -h" for more helps. Let us > create a qemu hard disk image first. BTW, kqemu will bring you better > performance, please google for installing. > > $ qemu-img create -f raw test.img 200M > Use your favourite rescue CD to do partion issues.(I choose > rhel here because both Debian etch/lenny CDs could not enter the > rescue mode in qemu-0.9.1.:<. anyone who knows the reason please tell > me, thanks. ) > $ qemu -cdrom ~/iso/rhel5_rescue.iso -boot d -hda test.img -L > ~/work/qemu-0.9.1/pc-bios/ -m 512 > Run fdisk and create a single partition on the drive that > takes up the whole drive > Quit and write the partition to disk > Run mkfs.ext2fs on that partition > Exit QEMU > > Allright, we start to build rootfs for qemu image. > $ sudo mount -o loop,offset=32256 test.img /mnt/rootfs > > Create a boot directory and copy your Linux kernel (vmlinuz) > and initramfs (initrd) to it: > > $ sudo mkdir /mnt/rootfs/boot > $ sudo mkdir /mnt/rootfs/boot/filo > $ sudo cp vmlinuz /mnt/rootfs/boot/vmlinuz > $ sudo cp initrd /mnt/rootfs/boot/initrd > $ sudo vi /mnt/rootfs/boot/filo/menu.lst > # For booting GNU/Linux > title GNU/Linux > root (hd0,0) > kernel /boot/vmlinuz root=/dev/hda1 > initrd /boot/initrd > > > # Add other files as you wish. > $ sudo cp -R /* /mnt/rootfs > > Alternatively, with Debian you can use the debootstrap command > to create a basic root filesystem: > $ sudo debootstrap --arch i386 etch /mnt/rootfs > http://ftp.debian.org/debian/ > > If you are using a debootstrap filesystem, open the file > /mnt/rootfs/etc/inittab and change runlevel to level 1: > id:1:initdefault: > > cd out of /mnt/rootfs and umount it: > $ sudo umount /mnt/rootfs > > > filo: > $ cd filo-0.5 > First invocation of make creates the default Config file. > $ make > Edit this file as you like. > vi Config > change MENULST_FILE to "hda1:/boot/filo/menu.lst", since we > only have one single partition. > change AUTOBOOT_FILE to "hda1:/boot/vmlinuz root=/dev/hda1 > console=ttyS0,115200" > > Run make again to create filo.elf, the ELF FILO image. > $ make > > coreboot: > change payload to path/to/filo.elf > $ vi coreboot-v2/targets/emulation/qemu-x86/Config.lb > > $ cd coreboot-v2/targets > $ ./buildtarget emulation/qemu-x86 > $ cd emulation/qemu-x86/qemu-x86/ > $ sudo make > Here we got coreboot.rom which use filo as bootloader. > > $ cp coreboot.rom ~/bios.bin > $ cp $path/to/qemu-0.9.1/pc-bios/vgabios-cirrus.bin ~/ > > > Here we go! > Boot test.img using coreboot. > $ qemu -L ~ -hda test.img > > > ==END== > > > -- > FIXME if it is wrong. From vogel at ct.metrocast.net Tue May 6 18:00:07 2008 From: vogel at ct.metrocast.net (Robert Vogel) Date: Tue, 6 May 2008 12:00:07 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] References: <4818A556.6060900@gnu.org> <481A2C12.6020605@gmx.net> <481C97E6.6060507@gmx.net> <007501c8ae0e$3e596400$0200a8c0@JUNKNAME><481EABD2.4080907@zeomega.com> Message-ID: <001701c8af93$d48e2d80$0200a8c0@JUNKNAME> ----- Original Message ----- From: "Richard M Stallman" To: "Ralph Green" Cc: Sent: Monday, May 05, 2008 6:06 PM Subject: Re: [coreboot] [Fwd: Re: Contact Intel] > You as an election judge may be honest, but not all of them are. At > least one election in Mexico was stolen by computer manipulation by > the central election commission. It appears that Bush stole the 2004 > election through fiddling with the electro-optical vote counting > machines. I've seen evidence that other elections in the US were > stolen thru voting machine manipulation. > > Whatever the technology, we cannot rely on the election authorities to > be honest. So we must reject technology that forces us to rely on this. > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot The point is: It is not enough that the software and the BIOS are free, the graphics, the motherboard, chips, and the entire package need to be free, open, and auditable. It is important for voting machines (http://www.seconnecticut.com/elections.htm), but even for personal use it is a concern. From Marc.Jones at amd.com Tue May 6 18:27:16 2008 From: Marc.Jones at amd.com (Marc Jones) Date: Tue, 06 May 2008 10:27:16 -0600 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> Message-ID: <482086E4.9080208@amd.com> ron minnich wrote: > I know some people will get upset by the find_pci_device, but: > This patch fixes a long-standing problem in the cs5536 driver, that is > probably also in v2. > > The ide_init is called with the sb device but needs the IDE device, > which is different. You are going to run into this problem on almost every chipset. Integrated PCI devices is normal (IDE, SMB, SATA, USB, LPC, audio, etc). > It also did a write_config8,not write_config32; this bug has been in there since > the code was written for v2. I don't know how or why it ever worked, > since PWB is 1<<14. > Yup, bug. I will post a v2 patch. PWB should be set for better performance so it shouldn't cause complete breakage. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From Marc.Jones at amd.com Tue May 6 18:40:02 2008 From: Marc.Jones at amd.com (Marc Jones) Date: Tue, 06 May 2008 10:40:02 -0600 Subject: [coreboot] patch: two bugs in the cs5536 ide code - v2 patch In-Reply-To: <482086E4.9080208@amd.com> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <482086E4.9080208@amd.com> Message-ID: <482089E2.4000000@amd.com> Marc Jones wrote: > ron minnich wrote: >> I know some people will get upset by the find_pci_device, but: >> This patch fixes a long-standing problem in the cs5536 driver, that is >> probably also in v2. .. >> It also did a write_config8,not write_config32; this bug has been in >> there since >> the code was written for v2. I don't know how or why it ever worked, >> since PWB is 1<<14. >> > > Yup, bug. I will post a v2 patch. > > PWB should be set for better performance so it shouldn't cause complete > breakage. > -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 5536_ide.patch URL: From rminnich at gmail.com Tue May 6 18:46:31 2008 From: rminnich at gmail.com (ron minnich) Date: Tue, 6 May 2008 09:46:31 -0700 Subject: [coreboot] patch: two bugs in the cs5536 ide code - v2 patch In-Reply-To: <482089E2.4000000@amd.com> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <482086E4.9080208@amd.com> <482089E2.4000000@amd.com> Message-ID: <13426df10805060946u38faf94uc3f96f5cca6ec41a@mail.gmail.com> On Tue, May 6, 2008 at 9:40 AM, Marc Jones wrote: > PWB was not getting set since it is 1<<14 and it was only doing a > pci_write_config8. > > Signed-off-by: Marc Jones > Acked-by: Ronald G. Minnich From svn at coreboot.org Tue May 6 18:56:49 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Tue, 6 May 2008 18:56:49 +0200 Subject: [coreboot] r3282 - trunk/coreboot-v2/src/southbridge/amd/cs5536 Message-ID: Author: mjones Date: 2008-05-06 18:56:47 +0200 (Tue, 06 May 2008) New Revision: 3282 Modified: trunk/coreboot-v2/src/southbridge/amd/cs5536/cs5536_ide.c Log: cs5536 IDE PWB flag was not getting set since it is 1<<14 and it was only doing a pci_write_config8. Signed-off-by: Marc Jones Acked-by: Ronald G. Minnich Modified: trunk/coreboot-v2/src/southbridge/amd/cs5536/cs5536_ide.c =================================================================== --- trunk/coreboot-v2/src/southbridge/amd/cs5536/cs5536_ide.c 2008-05-06 15:17:43 UTC (rev 3281) +++ trunk/coreboot-v2/src/southbridge/amd/cs5536/cs5536_ide.c 2008-05-06 16:56:47 UTC (rev 3282) @@ -43,7 +43,7 @@ // NOTE: Only 32-bit writes to the data buffer are allowed when PWB is set ide_cfg = pci_read_config32(dev, IDE_CFG); ide_cfg |= CHANEN | PWB; - pci_write_config8(dev, IDE_CFG, ide_cfg); + pci_write_config32(dev, IDE_CFG, ide_cfg); } static void ide_enable(struct device *dev) From vidwer at gmail.com Tue May 6 21:34:45 2008 From: vidwer at gmail.com (Idwer Vollering) Date: Tue, 6 May 2008 21:34:45 +0200 Subject: [coreboot] winflashrom In-Reply-To: <48207B7F.4090207@gmx.net> References: <48207B7F.4090207@gmx.net> Message-ID: 2008/5/6, Carl-Daniel Hailfinger : > > Hi, > > I just found this interesting link on how to access arbitrary pci > devices under windows the official way: > http://support.microsoft.com/?scid=kb%3Ben-us%3B178660&x=10&y=12 This seems to be rather outdated IMO: http://support.microsoft.com/?scid=kb%3Ben-us%3B178660&x=10&y=12#appliesto I guess that what you are looking for is: http://msdn.microsoft.com/en-us/library/ms794193.aspx (Windows Driver Kit Introduction). Maybe it helps for winflashrom. IIRC the problem of doing the PCI > accesses the "right way" is still unsolved. I think it is better to work on a livecd/pxe-image, like: http://lists.us.dell.com/pipermail/firmware-tools-devel/2007-August/000165.html http://lists.us.dell.com/pipermail/firmware-tools-devel/2007-August/000166.html http://linux.dell.com/wiki/index.php/Tech/libsmbios_livecd http://linux.dell.com/wiki/index.php/Oss/Firmware_Tools http://www.dellcommunity.com/supportforums/board/message?board.id=sw_linux&message.id=11072 Regards, > Carl-Daniel > > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Tue May 6 21:43:42 2008 From: peter at stuge.se (Peter Stuge) Date: Tue, 6 May 2008 21:43:42 +0200 Subject: [coreboot] winflashrom In-Reply-To: References: <48207B7F.4090207@gmx.net> Message-ID: <20080506194342.27206.qmail@stuge.se> On Tue, May 06, 2008 at 09:34:45PM +0200, Idwer Vollering wrote: > I think it is better to work on a livecd/pxe-image, like: I have to disagree. Windows is usable over the network. A livecd goes against the very thing that motivated the start of LinuxBIOS in 99. Talk to any sysadmin. They do not like firmware updates on CDs. //Peter From jordan.crouse at amd.com Tue May 6 22:10:56 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 6 May 2008 14:10:56 -0600 Subject: [coreboot] Outstanding patches In-Reply-To: <20080506201008.GA21256@cosmic.amd.com> References: <20080506201008.GA21256@cosmic.amd.com> Message-ID: <20080506201056.GB21256@cosmic.amd.com> > libpayload LAR patch: > I will repost this one with changes from Peter As promised. -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: lar.patch Type: text/x-diff Size: 15334 bytes Desc: not available URL: From jordan.crouse at amd.com Tue May 6 22:10:08 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 6 May 2008 14:10:08 -0600 Subject: [coreboot] Outstanding patches Message-ID: <20080506201008.GA21256@cosmic.amd.com> I have a number of outstanding patches that need to be ACKed or NAKed. Please review if you have the time: coreinfo submenu patch: http://www.coreboot.org/pipermail/coreboot/2008-April/033837.html libpayload LAR patch: I will repost this one with changes from Peter LAR browser for coreinfo: http://www.coreboot.org/pipermail/coreboot/2008-April/033904.html This has been acked, but depends on the previous two patches Update current time and date on the screen (coreinfo): http://www.coreboot.org/pipermail/coreboot/2008-April/033905.html This has been acked, but depends on the submenu patch Thanks, Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From Marc.Karasek at Sun.COM Tue May 6 22:26:10 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Tue, 06 May 2008 16:26:10 -0400 Subject: [coreboot] SimNOW V2 LAB problem Message-ID: <4820BEE2.9070309@sun.com> All, I finally got some cycles to look at why I was getting a "trap divied error" when trying to run coreboot v2 + LAB on the SimNOW Cheetah BSD. It looks like linuxrc in busybox is the culprit. It gets to the point in kernel init where it tries to run the linuxrc "program" and that is where it crashes, everything is Ok up to that point. Has anyone else seen a similar issue? Marc -- ********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 ********************* From mylesgw at gmail.com Tue May 6 22:49:47 2008 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 6 May 2008 14:49:47 -0600 Subject: [coreboot] Outstanding patches In-Reply-To: <20080506201008.GA21256@cosmic.amd.com> References: <20080506201008.GA21256@cosmic.amd.com> Message-ID: <006001c8afba$b92f45c0$1a02a8c0@chimp> > I have a number of outstanding patches that need to be ACKed or > NAKed. Please review if you have the time: > > coreinfo submenu patch: > http://www.coreboot.org/pipermail/coreboot/2008-April/033837.html > coreinfo: Add "a submenu" Here's a start for this one. Thanks, Myles > We were in the risk of running out of space in the option menu at > the bottom of the screen - this turns the function keys into > "categories" and then list specific items as part of the category. > > Signed-off-by: Jordan Crouse > Index: coreinfo/coreinfo.c > =================================================================== > --- coreinfo.orig/coreinfo.c 2008-04-24 18:02:23.000000000 -0600 > +++ coreinfo/coreinfo.c 2008-04-25 10:08:02.000000000 -0600 > @@ -28,24 +28,46 @@ > extern struct coreinfo_module nvram_module; > extern struct coreinfo_module bootlog_module; > > -struct coreinfo_module *modules[] = { > +struct coreinfo_module *system_modules[] = { > #ifdef CONFIG_MODULE_CPUINFO > &cpuinfo_module, > #endif > #ifdef CONFIG_MODULE_PCI > &pci_module, > #endif > -#ifdef CONFIG_MODULE_COREBOOT > - &coreboot_module, > -#endif > #ifdef CONFIG_MODULE_NVRAM > &nvram_module, > #endif > +}; > + > +struct coreinfo_module *coreboot_modules[] = { > +#ifdef CONFIG_MODULE_COREBOOT > + &coreboot_module, > +#endif > #ifdef CONFIG_MODULE_BOOTLOG > &bootlog_module, > #endif > }; What happens if I configure it not to have either of these two modules? It hangs for me. Maybe because you took out the check below? Maybe there needs to be a new check for empty categories or an ifdef that gets rid of categories that have no subcategories. It works fine for me when I'm not trying to break it. :) > > +struct coreinfo_cat { > + char name[15]; > + int cur; > + int count; > + struct coreinfo_module **modules; > +} categories[] = { > + { > + .name = "System", > + .modules = system_modules, > + .count = ARRAY_SIZE(system_modules), > + }, > + { > + .name = "Coreboot", > + .modules = coreboot_modules, > + .count = ARRAY_SIZE(coreboot_modules), > + } > +}; > + > + > static WINDOW *modwin; > static int curwin; > > @@ -62,6 +84,26 @@ > waddch(win, '\304'); > } > > +static void print_submenu(struct coreinfo_cat *cat) > +{ > + int i, j; > + char menu[80]; > + char *ptr = menu; > + > + wmove(stdscr, 22, 0); > + > + for (j = 0; j < SCREEN_X; j++) > + waddch(stdscr, ' '); > + > + if (!cat->count) > + return; > + > + for (i = 0; i < cat->count; i++) > + ptr += sprintf(ptr, "[%c: %s] ", 'A' + i, cat->modules[i]->name); > + > + mvprintw(22, 0, menu); > +} > + > static void print_menu(void) > { > int i, j; > @@ -73,11 +115,10 @@ > for (j = 0; j < SCREEN_X; j++) > waddch(stdscr, ' '); > > - for (i = 0; i < ARRAY_SIZE(modules); i++) > - ptr += sprintf(ptr, "F%d: %s ", i + 1, modules[i]->name); > + for (i = 0; i < ARRAY_SIZE(categories); i++) > + ptr += sprintf(ptr, "F%d: %s ", i + 1, categories[i].name); > > - if (ARRAY_SIZE(modules) != 0) > - mvprintw(23, 0, menu); > + mvprintw(23, 0, menu); This check? > > #ifdef CONFIG_SHOW_DATE_TIME > mvprintw(23, 59, "%02d/%02d/20%02d - %02d:%02d:%02d", > @@ -117,6 +158,8 @@ > > ptr += sprintf(ptr, "[ %s ]", str); > > + > + > for (i = ((SCREEN_X - len) / 2) + len; i < SCREEN_X; i++) > ptr += sprintf(ptr, "="); > > @@ -124,16 +167,35 @@ > } > #endif > > -static void redraw_module(void) > +static void redraw_module(struct coreinfo_cat *cat) > { > - if (ARRAY_SIZE(modules) == 0) > + if (cat->count == 0) > return; > > wclear(modwin); > - modules[curwin]->redraw(modwin); > + cat->modules[cat->cur]->redraw(modwin); > refresh(); > } > > +static void handle_category_key(struct coreinfo_cat *cat, int key) > +{ > + if (key >= 'a' && key <= 'z') { > + int index = key - 'a'; > + > + if (index < cat->count) { > + > + cat->cur = index; > + redraw_module(cat); > + return; > + } > + } > + > + if (cat->count && cat->modules[cat->cur]->handle) { > + if (cat->modules[cat->cur]->handle(key)) > + redraw_module(cat); > + } > +} > + > static void loop(void) > { > int key; > @@ -141,9 +203,8 @@ > center(0, "coreinfo v0.1"); > > print_menu(); > - if (ARRAY_SIZE(modules) != 0) > - modules[curwin]->redraw(modwin); > - refresh(); > + print_submenu(&categories[curwin]); > + redraw_module(&categories[curwin]); Or this check? > > while (1) { > key = getch(); > @@ -154,18 +215,18 @@ > if (key >= KEY_F(1) && key <= KEY_F(9)) { > unsigned char ch = key - KEY_F(1); > > - if (ch <= ARRAY_SIZE(modules)) { > - if (ch == ARRAY_SIZE(modules)) > + if (ch <= ARRAY_SIZE(categories)) { > + if (ch == ARRAY_SIZE(categories)) > continue; > curwin = ch; > - redraw_module(); > + print_submenu(&categories[curwin]); > + redraw_module(&categories[curwin]); > continue; > } > } > > - if (ARRAY_SIZE(modules) != 0 && modules[curwin]->handle) > - if (modules[curwin]->handle(key)) > - redraw_module(); > + > + handle_category_key(&categories[curwin], key); > } > } > > @@ -182,7 +243,7 @@ > init_pair(2, COLOR_BLACK, COLOR_WHITE); > init_pair(3, COLOR_WHITE, COLOR_WHITE); > > - modwin = newwin(23, 80, 1, 0); > + modwin = newwin(22, 80, 1, 0); > > wattrset(stdscr, COLOR_PAIR(1) | A_BOLD); > wattrset(modwin, COLOR_PAIR(2)); > @@ -196,8 +257,11 @@ > > refresh(); > > - for (i = 0; i < ARRAY_SIZE(modules); i++) > - modules[i]->init(); > + for (i = 0; i < ARRAY_SIZE(categories); i++) { > + for(j = 0; j < categories[i].count; j++) > + categories[i].modules[j]->init(); > + > + } > > loop(); > From rminnich at gmail.com Tue May 6 22:58:06 2008 From: rminnich at gmail.com (ron minnich) Date: Tue, 6 May 2008 13:58:06 -0700 Subject: [coreboot] an example of bad magic. Message-ID: <13426df10805061358m2251b5d6i78d4bfc98597d8c0@mail.gmail.com> just as a cautionary tale for the goal of moving everything to the dts: I am working with some basic infiniband tools. As part of their goal of making it all portable and easy to build, they use the libtool support tools. So, for a simple command line like this: /bin/sh ./libtool --mode=link --tag=CC gcc -g -O2 -o src/vendstat src_vendstat-vendstat.o src_vendstat-ibdiag_common.o -lopensm -losmvendor -losmcomp -libmad -libmad -libumad -libcommon gcc -g -O2 -o src/vendstat src_vendstat-vendstat.o src_vendstat-ibdiag_common.o -lopensm -losmvendor -losmcomp -libmad -libumad -libcommon They need the libtool script, which is wc libtool 7363 26779 212348 libtool 7363 lines. Geez, how long is the program? The program is part of a set of diagnostic tools, and the bulk of them are about 200 lines long. So, for a 200-line, 5330 character program, we have a 332 character command line and, if that were not enough, a 7363-line, near quarter million character script. This is a good example of the conservation of complexity. It is always possible, in the name of hiding details, to create a monstrously complex system that no one can understand. Just FYI. ron From mylesgw at gmail.com Tue May 6 22:59:43 2008 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 6 May 2008 14:59:43 -0600 Subject: [coreboot] Outstanding patches In-Reply-To: <006001c8afba$b92f45c0$1a02a8c0@chimp> References: <20080506201008.GA21256@cosmic.amd.com> <006001c8afba$b92f45c0$1a02a8c0@chimp> Message-ID: <2831fecf0805061359y26f72f55uf65a4ab619cfe@mail.gmail.com> On Tue, May 6, 2008 at 2:49 PM, Myles Watson wrote: > > I have a number of outstanding patches that need to be ACKed or > > NAKed. Please review if you have the time: > > > > coreinfo submenu patch: > > http://www.coreboot.org/pipermail/coreboot/2008-April/033837.html > > coreinfo: Add "a submenu" > > Here's a start for this one. I forgot to say that if you configure it without a couple of menus, it refuses to build because of unused variable warnings. I'm not sure that -Werror is the right thing to do when it's in buildrom, even though I don't like warnings. Thanks, Myles From jordan.crouse at amd.com Tue May 6 23:05:11 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 6 May 2008 15:05:11 -0600 Subject: [coreboot] Outstanding patches In-Reply-To: <2831fecf0805061359y26f72f55uf65a4ab619cfe@mail.gmail.com> References: <20080506201008.GA21256@cosmic.amd.com> <006001c8afba$b92f45c0$1a02a8c0@chimp> <2831fecf0805061359y26f72f55uf65a4ab619cfe@mail.gmail.com> Message-ID: <20080506210511.GC21256@cosmic.amd.com> On 06/05/08 14:59 -0600, Myles Watson wrote: > On Tue, May 6, 2008 at 2:49 PM, Myles Watson wrote: > > > I have a number of outstanding patches that need to be ACKed or > > > NAKed. Please review if you have the time: > > > > > > coreinfo submenu patch: > > > http://www.coreboot.org/pipermail/coreboot/2008-April/033837.html > > > coreinfo: Add "a submenu" > > > > Here's a start for this one. > > I forgot to say that if you configure it without a couple of menus, > it refuses to build because of unused variable warnings. I'm not sure > that -Werror is the right thing to do when it's in buildrom, even > though I don't like warnings. Unused functions are bad though - can you point me to the config you used? Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From jordan.crouse at amd.com Tue May 6 23:08:55 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 6 May 2008 15:08:55 -0600 Subject: [coreboot] Outstanding patches In-Reply-To: <006001c8afba$b92f45c0$1a02a8c0@chimp> References: <20080506201008.GA21256@cosmic.amd.com> <006001c8afba$b92f45c0$1a02a8c0@chimp> Message-ID: <20080506210855.GD21256@cosmic.amd.com> On 06/05/08 14:49 -0600, Myles Watson wrote: > > I have a number of outstanding patches that need to be ACKed or > > NAKed. Please review if you have the time: > > > > coreinfo submenu patch: > > http://www.coreboot.org/pipermail/coreboot/2008-April/033837.html > > coreinfo: Add "a submenu" > > Here's a start for this one. > > Thanks, > Myles > > > We were in the risk of running out of space in the option menu at > > the bottom of the screen - this turns the function keys into > > "categories" and then list specific items as part of the category. > > > > Signed-off-by: Jordan Crouse > > Index: coreinfo/coreinfo.c > > =================================================================== > > --- coreinfo.orig/coreinfo.c 2008-04-24 18:02:23.000000000 -0600 > > +++ coreinfo/coreinfo.c 2008-04-25 10:08:02.000000000 -0600 > > @@ -28,24 +28,46 @@ > > extern struct coreinfo_module nvram_module; > > extern struct coreinfo_module bootlog_module; > > > > -struct coreinfo_module *modules[] = { > > +struct coreinfo_module *system_modules[] = { > > #ifdef CONFIG_MODULE_CPUINFO > > &cpuinfo_module, > > #endif > > #ifdef CONFIG_MODULE_PCI > > &pci_module, > > #endif > > -#ifdef CONFIG_MODULE_COREBOOT > > - &coreboot_module, > > -#endif > > #ifdef CONFIG_MODULE_NVRAM > > &nvram_module, > > #endif > > +}; > > + > > +struct coreinfo_module *coreboot_modules[] = { > > +#ifdef CONFIG_MODULE_COREBOOT > > + &coreboot_module, > > +#endif > > #ifdef CONFIG_MODULE_BOOTLOG > > &bootlog_module, > > #endif > > }; > > What happens if I configure it not to have either of these two modules? It > hangs for me. Maybe because you took out the check below? Maybe there > needs to be a new check for empty categories or an ifdef that gets rid of > categories that have no subcategories. Yep - we are missing the check. I'll add them back in. Thanks. Jordan From mylesgw at gmail.com Tue May 6 23:17:35 2008 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 6 May 2008 15:17:35 -0600 Subject: [coreboot] Outstanding patches In-Reply-To: <20080506210511.GC21256@cosmic.amd.com> References: <20080506201008.GA21256@cosmic.amd.com> <006001c8afba$b92f45c0$1a02a8c0@chimp> <2831fecf0805061359y26f72f55uf65a4ab619cfe@mail.gmail.com> <20080506210511.GC21256@cosmic.amd.com> Message-ID: <006601c8afbe$9bc70e60$1a02a8c0@chimp> > -----Original Message----- > From: Jordan Crouse [mailto:jordan.crouse at amd.com] > Sent: Tuesday, May 06, 2008 3:05 PM > To: Myles Watson > Cc: coreboot at coreboot.org > Subject: Re: Outstanding patches > > On 06/05/08 14:59 -0600, Myles Watson wrote: > > On Tue, May 6, 2008 at 2:49 PM, Myles Watson wrote: > > > > I have a number of outstanding patches that need to be ACKed or > > > > NAKed. Please review if you have the time: > > > > > > > > coreinfo submenu patch: > > > > http://www.coreboot.org/pipermail/coreboot/2008-April/033837.html > > > > coreinfo: Add "a submenu" > > > > > > Here's a start for this one. > > > > I forgot to say that if you configure it without a couple of menus, > > it refuses to build because of unused variable warnings. I'm not sure > > that -Werror is the right thing to do when it's in buildrom, even > > though I don't like warnings. > > Unused functions are bad though - can you point me to the config you used? I blew it away to test the lar patch... I will try to recreate it, but it was a rdtsc function that wasn't being used, if that helps. Thanks, Myles From mylesgw at gmail.com Tue May 6 23:19:18 2008 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 6 May 2008 15:19:18 -0600 Subject: [coreboot] SimNOW V2 LAB problem In-Reply-To: <4820BEE2.9070309@sun.com> References: <4820BEE2.9070309@sun.com> Message-ID: <006701c8afbe$d89e9e20$1a02a8c0@chimp> > -----Original Message----- > From: coreboot-bounces+mylesgw=gmail.com at coreboot.org [mailto:coreboot- > bounces+mylesgw=gmail.com at coreboot.org] On Behalf Of Marc Karasek > Sent: Tuesday, May 06, 2008 2:26 PM > To: coreboot at coreboot.org > Subject: [coreboot] SimNOW V2 LAB problem > > All, > > I finally got some cycles to look at why I was getting a "trap divied > error" when trying to run coreboot v2 + LAB on the SimNOW Cheetah BSD. > It looks like linuxrc in busybox is the culprit. It gets to the point > in kernel init where it tries to run the linuxrc "program" and that is > where it crashes, everything is Ok up to that point. > > Has anyone else seen a similar issue? I have the same issue when I build on my FC 6 and later systems, but the same code works fine on FC 5. Thanks, Myles From jordan.crouse at amd.com Tue May 6 23:21:04 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 6 May 2008 15:21:04 -0600 Subject: [coreboot] Outstanding patches In-Reply-To: <006601c8afbe$9bc70e60$1a02a8c0@chimp> References: <20080506201008.GA21256@cosmic.amd.com> <006001c8afba$b92f45c0$1a02a8c0@chimp> <2831fecf0805061359y26f72f55uf65a4ab619cfe@mail.gmail.com> <20080506210511.GC21256@cosmic.amd.com> <006601c8afbe$9bc70e60$1a02a8c0@chimp> Message-ID: <20080506212104.GE21256@cosmic.amd.com> On 06/05/08 15:17 -0600, Myles Watson wrote: > > > > -----Original Message----- > > From: Jordan Crouse [mailto:jordan.crouse at amd.com] > > Sent: Tuesday, May 06, 2008 3:05 PM > > To: Myles Watson > > Cc: coreboot at coreboot.org > > Subject: Re: Outstanding patches > > > > On 06/05/08 14:59 -0600, Myles Watson wrote: > > > On Tue, May 6, 2008 at 2:49 PM, Myles Watson wrote: > > > > > I have a number of outstanding patches that need to be ACKed or > > > > > NAKed. Please review if you have the time: > > > > > > > > > > coreinfo submenu patch: > > > > > http://www.coreboot.org/pipermail/coreboot/2008-April/033837.html > > > > > coreinfo: Add "a submenu" > > > > > > > > Here's a start for this one. > > > > > > I forgot to say that if you configure it without a couple of menus, > > > it refuses to build because of unused variable warnings. I'm not sure > > > that -Werror is the right thing to do when it's in buildrom, even > > > though I don't like warnings. > > > > Unused functions are bad though - can you point me to the config you used? > > I blew it away to test the lar patch... > > I will try to recreate it, but it was a rdtsc function that wasn't being > used, if that helps. Ah, yes - somebody else talked about that too. I'll fix that. Thanks. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From Marc.Karasek at Sun.COM Tue May 6 23:20:16 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Tue, 06 May 2008 17:20:16 -0400 Subject: [coreboot] Multiple emails Message-ID: <4820CB90.5030806@sun.com> Is anyone else seeing multiple email messages from the list? -- ********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 ********************* From jordan.crouse at amd.com Tue May 6 23:24:34 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 6 May 2008 15:24:34 -0600 Subject: [coreboot] SimNOW V2 LAB problem In-Reply-To: <006701c8afbe$d89e9e20$1a02a8c0@chimp> References: <4820BEE2.9070309@sun.com> <006701c8afbe$d89e9e20$1a02a8c0@chimp> Message-ID: <20080506212434.GF21256@cosmic.amd.com> On 06/05/08 15:19 -0600, Myles Watson wrote: > > > > -----Original Message----- > > From: coreboot-bounces+mylesgw=gmail.com at coreboot.org [mailto:coreboot- > > bounces+mylesgw=gmail.com at coreboot.org] On Behalf Of Marc Karasek > > Sent: Tuesday, May 06, 2008 2:26 PM > > To: coreboot at coreboot.org > > Subject: [coreboot] SimNOW V2 LAB problem > > > > All, > > > > I finally got some cycles to look at why I was getting a "trap divied > > error" when trying to run coreboot v2 + LAB on the SimNOW Cheetah BSD. > > It looks like linuxrc in busybox is the culprit. It gets to the point > > in kernel init where it tries to run the linuxrc "program" and that is > > where it crashes, everything is Ok up to that point. > > > > Has anyone else seen a similar issue? > > I have the same issue when I build on my FC 6 and later systems, but the > same code works fine on FC 5. Sounds like possible uclibc breakage? Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From Marc.Karasek at Sun.COM Tue May 6 23:21:51 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Tue, 06 May 2008 17:21:51 -0400 Subject: [coreboot] SimNOW V2 LAB problem In-Reply-To: <006701c8afbe$d89e9e20$1a02a8c0@chimp> References: <4820BEE2.9070309@sun.com> <006701c8afbe$d89e9e20$1a02a8c0@chimp> Message-ID: <4820CBEF.4050107@sun.com> Crap, another compiler/tools problem. I hate these.. what version of gcc/binutils did you use under FC5? ********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 ********************* Myles Watson wrote: > >> -----Original Message----- >> From: coreboot-bounces+mylesgw=gmail.com at coreboot.org [mailto:coreboot- >> bounces+mylesgw=gmail.com at coreboot.org] On Behalf Of Marc Karasek >> Sent: Tuesday, May 06, 2008 2:26 PM >> To: coreboot at coreboot.org >> Subject: [coreboot] SimNOW V2 LAB problem >> >> All, >> >> I finally got some cycles to look at why I was getting a "trap divied >> error" when trying to run coreboot v2 + LAB on the SimNOW Cheetah BSD. >> It looks like linuxrc in busybox is the culprit. It gets to the point >> in kernel init where it tries to run the linuxrc "program" and that is >> where it crashes, everything is Ok up to that point. >> >> Has anyone else seen a similar issue? >> > > I have the same issue when I build on my FC 6 and later systems, but the > same code works fine on FC 5. > > Thanks, > Myles > > > From jordan.crouse at amd.com Tue May 6 23:33:21 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 6 May 2008 15:33:21 -0600 Subject: [coreboot] Outstanding patches In-Reply-To: <2831fecf0805061359y26f72f55uf65a4ab619cfe@mail.gmail.com> References: <20080506201008.GA21256@cosmic.amd.com> <006001c8afba$b92f45c0$1a02a8c0@chimp> <2831fecf0805061359y26f72f55uf65a4ab619cfe@mail.gmail.com> Message-ID: <20080506213321.GG21256@cosmic.amd.com> On 06/05/08 14:59 -0600, Myles Watson wrote: > On Tue, May 6, 2008 at 2:49 PM, Myles Watson wrote: > > > I have a number of outstanding patches that need to be ACKed or > > > NAKed. Please review if you have the time: > > > > > > coreinfo submenu patch: > > > http://www.coreboot.org/pipermail/coreboot/2008-April/033837.html > > > coreinfo: Add "a submenu" > > > > Here's a start for this one. > > I forgot to say that if you configure it without a couple of menus, > it refuses to build because of unused variable warnings. I'm not sure > that -Werror is the right thing to do when it's in buildrom, even > though I don't like warnings. Okay, this one was easy enough - the #include in cpuinfo_module.c just had to be moved inside of the #ifdef CONFIG_CPUINFO_MODULE define. It is trivial. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From svn at coreboot.org Tue May 6 23:32:53 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Tue, 6 May 2008 23:32:53 +0200 Subject: [coreboot] r3283 - trunk/payloads/coreinfo Message-ID: Author: jcrouse Date: 2008-05-06 23:32:52 +0200 (Tue, 06 May 2008) New Revision: 3283 Modified: trunk/payloads/coreinfo/coreinfo.c trunk/payloads/coreinfo/cpuinfo_module.c Log: coreinfo: Move the rdtsc.h include into the #ifdef CONFIG_MODULE_CPUINFO rdtsc.h shouldn't be included unless we really need it (and use it). Trivial. Signed-off-by: Jordan Crouse Acked-by: Jordan Crouse Modified: trunk/payloads/coreinfo/coreinfo.c =================================================================== --- trunk/payloads/coreinfo/coreinfo.c 2008-05-06 16:56:47 UTC (rev 3282) +++ trunk/payloads/coreinfo/coreinfo.c 2008-05-06 21:32:52 UTC (rev 3283) @@ -28,24 +28,46 @@ extern struct coreinfo_module nvram_module; extern struct coreinfo_module bootlog_module; -struct coreinfo_module *modules[] = { +struct coreinfo_module *system_modules[] = { #ifdef CONFIG_MODULE_CPUINFO &cpuinfo_module, #endif #ifdef CONFIG_MODULE_PCI &pci_module, #endif +#ifdef CONFIG_MODULE_NVRAM + &nvram_module, +#endif +}; + +struct coreinfo_module *coreboot_modules[] = { #ifdef CONFIG_MODULE_COREBOOT &coreboot_module, #endif -#ifdef CONFIG_MODULE_NVRAM - &nvram_module, -#endif #ifdef CONFIG_MODULE_BOOTLOG &bootlog_module, #endif }; +struct coreinfo_cat { + char name[15]; + int cur; + int count; + struct coreinfo_module **modules; +} categories[] = { + { + .name = "System", + .modules = system_modules, + .count = ARRAY_SIZE(system_modules), + }, + { + .name = "Coreboot", + .modules = coreboot_modules, + .count = ARRAY_SIZE(coreboot_modules), + } +}; + + static WINDOW *modwin; static int curwin; @@ -62,6 +84,26 @@ waddch(win, '\304'); } +static void print_submenu(struct coreinfo_cat *cat) +{ + int i, j; + char menu[80]; + char *ptr = menu; + + wmove(stdscr, 22, 0); + + for (j = 0; j < SCREEN_X; j++) + waddch(stdscr, ' '); + + if (!cat->count) + return; + + for (i = 0; i < cat->count; i++) + ptr += sprintf(ptr, "[%c: %s] ", 'A' + i, cat->modules[i]->name); + + mvprintw(22, 0, menu); +} + static void print_menu(void) { int i, j; @@ -73,12 +115,15 @@ for (j = 0; j < SCREEN_X; j++) waddch(stdscr, ' '); - for (i = 0; i < ARRAY_SIZE(modules); i++) - ptr += sprintf(ptr, "F%d: %s ", i + 1, modules[i]->name); + for (i = 0; i < ARRAY_SIZE(categories); i++) { + if (categories[i].count == 0) + continue; - if (ARRAY_SIZE(modules) != 0) - mvprintw(23, 0, menu); + ptr += sprintf(ptr, "F%d: %s ", i + 1, categories[i].name); + } + mvprintw(23, 0, menu); + #ifdef CONFIG_SHOW_DATE_TIME mvprintw(23, 59, "%02d/%02d/20%02d - %02d:%02d:%02d", bcd2dec(nvram_read(NVRAM_RTC_MONTH)), @@ -117,6 +162,8 @@ ptr += sprintf(ptr, "[ %s ]", str); + + for (i = ((SCREEN_X - len) / 2) + len; i < SCREEN_X; i++) ptr += sprintf(ptr, "="); @@ -124,16 +171,35 @@ } #endif -static void redraw_module(void) +static void redraw_module(struct coreinfo_cat *cat) { - if (ARRAY_SIZE(modules) == 0) + if (cat->count == 0) return; wclear(modwin); - modules[curwin]->redraw(modwin); + cat->modules[cat->cur]->redraw(modwin); refresh(); } +static void handle_category_key(struct coreinfo_cat *cat, int key) +{ + if (key >= 'a' && key <= 'z') { + int index = key - 'a'; + + if (index < cat->count) { + + cat->cur = index; + redraw_module(cat); + return; + } + } + + if (cat->count && cat->modules[cat->cur]->handle) { + if (cat->modules[cat->cur]->handle(key)) + redraw_module(cat); + } +} + static void loop(void) { int key; @@ -141,9 +207,8 @@ center(0, "coreinfo v0.1"); print_menu(); - if (ARRAY_SIZE(modules) != 0) - modules[curwin]->redraw(modwin); - refresh(); + print_submenu(&categories[curwin]); + redraw_module(&categories[curwin]); while (1) { key = getch(); @@ -154,18 +219,21 @@ if (key >= KEY_F(1) && key <= KEY_F(9)) { unsigned char ch = key - KEY_F(1); - if (ch <= ARRAY_SIZE(modules)) { - if (ch == ARRAY_SIZE(modules)) + if (ch <= ARRAY_SIZE(categories)) { + if (ch == ARRAY_SIZE(categories)) continue; + if (categories[ch].count == 0) + continue; + curwin = ch; - redraw_module(); + print_submenu(&categories[curwin]); + redraw_module(&categories[curwin]); continue; } } - if (ARRAY_SIZE(modules) != 0 && modules[curwin]->handle) - if (modules[curwin]->handle(key)) - redraw_module(); + + handle_category_key(&categories[curwin], key); } } @@ -182,7 +250,7 @@ init_pair(2, COLOR_BLACK, COLOR_WHITE); init_pair(3, COLOR_WHITE, COLOR_WHITE); - modwin = newwin(23, 80, 1, 0); + modwin = newwin(22, 80, 1, 0); wattrset(stdscr, COLOR_PAIR(1) | A_BOLD); wattrset(modwin, COLOR_PAIR(2)); @@ -196,9 +264,12 @@ refresh(); - for (i = 0; i < ARRAY_SIZE(modules); i++) - modules[i]->init(); + for (i = 0; i < ARRAY_SIZE(categories); i++) { + for(j = 0; j < categories[i].count; j++) + categories[i].modules[j]->init(); + } + loop(); return 0; Modified: trunk/payloads/coreinfo/cpuinfo_module.c =================================================================== --- trunk/payloads/coreinfo/cpuinfo_module.c 2008-05-06 16:56:47 UTC (rev 3282) +++ trunk/payloads/coreinfo/cpuinfo_module.c 2008-05-06 21:32:52 UTC (rev 3283) @@ -21,9 +21,9 @@ */ #include "coreinfo.h" -#include #ifdef CONFIG_MODULE_CPUINFO +#include #define VENDOR_INTEL 0x756e6547 #define VENDOR_AMD 0x68747541 From mylesgw at gmail.com Tue May 6 23:37:37 2008 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 6 May 2008 15:37:37 -0600 Subject: [coreboot] SimNOW V2 LAB problem In-Reply-To: <4820CBEF.4050107@sun.com> References: <4820BEE2.9070309@sun.com> <006701c8afbe$d89e9e20$1a02a8c0@chimp> <4820CBEF.4050107@sun.com> Message-ID: <006801c8afc1$67ecf2f0$1a02a8c0@chimp> > -----Original Message----- > From: Marc.Karasek at Sun.COM [mailto:Marc.Karasek at Sun.COM] > Sent: Tuesday, May 06, 2008 3:22 PM > To: Myles Watson > Cc: coreboot at coreboot.org > Subject: Re: [coreboot] SimNOW V2 LAB problem > > Crap, another compiler/tools problem. I hate these.. what version of > gcc/binutils did you use under FC5? gcc 4.1.1 for x86_64 release 51.fc5 binutils 2.16.91.0.6 for x86_64 release 5 I wouldn't have upgraded, but I couldn't build a working version of qemu with those tools. Now I have two broken systems :( Thanks, Myles From jordan.crouse at amd.com Tue May 6 23:39:54 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 6 May 2008 15:39:54 -0600 Subject: [coreboot] Outstanding patches In-Reply-To: <006001c8afba$b92f45c0$1a02a8c0@chimp> References: <20080506201008.GA21256@cosmic.amd.com> <006001c8afba$b92f45c0$1a02a8c0@chimp> Message-ID: <20080506213954.GH21256@cosmic.amd.com> On 06/05/08 14:49 -0600, Myles Watson wrote: > > I have a number of outstanding patches that need to be ACKed or > > NAKed. Please review if you have the time: > > > > coreinfo submenu patch: > > http://www.coreboot.org/pipermail/coreboot/2008-April/033837.html > > coreinfo: Add "a submenu" > > Here's a start for this one. > > Thanks, > Myles > > > We were in the risk of running out of space in the option menu at > > the bottom of the screen - this turns the function keys into > > "categories" and then list specific items as part of the category. > > > > Signed-off-by: Jordan Crouse > > Index: coreinfo/coreinfo.c > > =================================================================== > > --- coreinfo.orig/coreinfo.c 2008-04-24 18:02:23.000000000 -0600 > > +++ coreinfo/coreinfo.c 2008-04-25 10:08:02.000000000 -0600 > > @@ -28,24 +28,46 @@ > > extern struct coreinfo_module nvram_module; > > extern struct coreinfo_module bootlog_module; > > > > -struct coreinfo_module *modules[] = { > > +struct coreinfo_module *system_modules[] = { > > #ifdef CONFIG_MODULE_CPUINFO > > &cpuinfo_module, > > #endif > > #ifdef CONFIG_MODULE_PCI > > &pci_module, > > #endif > > -#ifdef CONFIG_MODULE_COREBOOT > > - &coreboot_module, > > -#endif > > #ifdef CONFIG_MODULE_NVRAM > > &nvram_module, > > #endif > > +}; > > + > > +struct coreinfo_module *coreboot_modules[] = { > > +#ifdef CONFIG_MODULE_COREBOOT > > + &coreboot_module, > > +#endif > > #ifdef CONFIG_MODULE_BOOTLOG > > &bootlog_module, > > #endif > > }; > > What happens if I configure it not to have either of these two modules? It > hangs for me. Maybe because you took out the check below? Maybe there > needs to be a new check for empty categories or an ifdef that gets rid of > categories that have no subcategories. New patch attached that checks for empty categories. Tested on qemu. Jordan -------------- next part -------------- A non-text attachment was scrubbed... Name: submenu.patch Type: text/x-diff Size: 4735 bytes Desc: not available URL: From mylesgw at gmail.com Tue May 6 23:44:45 2008 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 6 May 2008 15:44:45 -0600 Subject: [coreboot] Outstanding patches In-Reply-To: <20080506213954.GH21256@cosmic.amd.com> References: <20080506201008.GA21256@cosmic.amd.com> <006001c8afba$b92f45c0$1a02a8c0@chimp> <20080506213954.GH21256@cosmic.amd.com> Message-ID: <006c01c8afc2$66cf5880$1a02a8c0@chimp> > > What happens if I configure it not to have either of these two modules? > It > > hangs for me. Maybe because you took out the check below? Maybe there > > needs to be a new check for empty categories or an ifdef that gets rid > of > > categories that have no subcategories. > > New patch attached that checks for empty categories. Tested on qemu. > Acked-by: Myles Watson From Marc.Karasek at Sun.COM Tue May 6 23:43:02 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Tue, 06 May 2008 17:43:02 -0400 Subject: [coreboot] SimNOW V2 LAB problem In-Reply-To: <006801c8afc1$67ecf2f0$1a02a8c0@chimp> References: <4820BEE2.9070309@sun.com> <006701c8afbe$d89e9e20$1a02a8c0@chimp> <4820CBEF.4050107@sun.com> <006801c8afc1$67ecf2f0$1a02a8c0@chimp> Message-ID: <4820D0E6.5070600@sun.com> I am going to try to compile with a newer version of busybox. Since the latest is 1.10.1 & buildrom uses 1.1.3. That is quite a lot of revisions... ********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 ********************* Myles Watson wrote: > >> -----Original Message----- >> From: Marc.Karasek at Sun.COM [mailto:Marc.Karasek at Sun.COM] >> Sent: Tuesday, May 06, 2008 3:22 PM >> To: Myles Watson >> Cc: coreboot at coreboot.org >> Subject: Re: [coreboot] SimNOW V2 LAB problem >> >> Crap, another compiler/tools problem. I hate these.. what version of >> gcc/binutils did you use under FC5? >> > > gcc 4.1.1 for x86_64 release 51.fc5 > binutils 2.16.91.0.6 for x86_64 release 5 > > I wouldn't have upgraded, but I couldn't build a working version of qemu > with those tools. Now I have two broken systems :( > > Thanks, > Myles > > > > > From mylesgw at gmail.com Tue May 6 23:47:47 2008 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 6 May 2008 15:47:47 -0600 Subject: [coreboot] Outstanding patches In-Reply-To: <20080506201056.GB21256@cosmic.amd.com> References: <20080506201008.GA21256@cosmic.amd.com> <20080506201056.GB21256@cosmic.amd.com> Message-ID: <2831fecf0805061447i40eb4681x99c21ed56aaef47f@mail.gmail.com> On Tue, May 6, 2008 at 2:10 PM, Jordan Crouse wrote: > > libpayload LAR patch: > > I will repost this one with changes from Peter > > As promised. There's a typo in this one: lal_header -> lar_header Besides that it looks fine. I'm not sure how many copies of lar.h we want floating around. Is there a way we could consolidate? Thanks, Myles From Marc.Karasek at Sun.COM Tue May 6 23:46:36 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Tue, 06 May 2008 17:46:36 -0400 Subject: [coreboot] Buildrom -- updating busybox... Message-ID: <4820D1BC.2060001@sun.com> Jordan, Why would just changing the revision of busybox to 1.10.1 seem to break buildrom? It builds the busybox binary but then tries to put the files in initrd-rootfs and that directory has not been created as part of the build process yet. Can you point me in the right direction so I can fix this... Marc -- ********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 ********************* From svn at coreboot.org Wed May 7 00:00:56 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Wed, 7 May 2008 00:00:56 +0200 Subject: [coreboot] r3284 - trunk/payloads/coreinfo Message-ID: Author: jcrouse Date: 2008-05-07 00:00:55 +0200 (Wed, 07 May 2008) New Revision: 3284 Modified: trunk/payloads/coreinfo/coreinfo.c Log: The previous commit had more in it then I wanted - so I am reverting this and re-commiting so that the history and comments are correct. Signed-off-by: Jordan Crouse Acked-by: Jordan Crouse Modified: trunk/payloads/coreinfo/coreinfo.c =================================================================== --- trunk/payloads/coreinfo/coreinfo.c 2008-05-06 21:32:52 UTC (rev 3283) +++ trunk/payloads/coreinfo/coreinfo.c 2008-05-06 22:00:55 UTC (rev 3284) @@ -28,46 +28,24 @@ extern struct coreinfo_module nvram_module; extern struct coreinfo_module bootlog_module; -struct coreinfo_module *system_modules[] = { +struct coreinfo_module *modules[] = { #ifdef CONFIG_MODULE_CPUINFO &cpuinfo_module, #endif #ifdef CONFIG_MODULE_PCI &pci_module, #endif -#ifdef CONFIG_MODULE_NVRAM - &nvram_module, -#endif -}; - -struct coreinfo_module *coreboot_modules[] = { #ifdef CONFIG_MODULE_COREBOOT &coreboot_module, #endif +#ifdef CONFIG_MODULE_NVRAM + &nvram_module, +#endif #ifdef CONFIG_MODULE_BOOTLOG &bootlog_module, #endif }; -struct coreinfo_cat { - char name[15]; - int cur; - int count; - struct coreinfo_module **modules; -} categories[] = { - { - .name = "System", - .modules = system_modules, - .count = ARRAY_SIZE(system_modules), - }, - { - .name = "Coreboot", - .modules = coreboot_modules, - .count = ARRAY_SIZE(coreboot_modules), - } -}; - - static WINDOW *modwin; static int curwin; @@ -84,26 +62,6 @@ waddch(win, '\304'); } -static void print_submenu(struct coreinfo_cat *cat) -{ - int i, j; - char menu[80]; - char *ptr = menu; - - wmove(stdscr, 22, 0); - - for (j = 0; j < SCREEN_X; j++) - waddch(stdscr, ' '); - - if (!cat->count) - return; - - for (i = 0; i < cat->count; i++) - ptr += sprintf(ptr, "[%c: %s] ", 'A' + i, cat->modules[i]->name); - - mvprintw(22, 0, menu); -} - static void print_menu(void) { int i, j; @@ -115,15 +73,12 @@ for (j = 0; j < SCREEN_X; j++) waddch(stdscr, ' '); - for (i = 0; i < ARRAY_SIZE(categories); i++) { - if (categories[i].count == 0) - continue; + for (i = 0; i < ARRAY_SIZE(modules); i++) + ptr += sprintf(ptr, "F%d: %s ", i + 1, modules[i]->name); - ptr += sprintf(ptr, "F%d: %s ", i + 1, categories[i].name); - } + if (ARRAY_SIZE(modules) != 0) + mvprintw(23, 0, menu); - mvprintw(23, 0, menu); - #ifdef CONFIG_SHOW_DATE_TIME mvprintw(23, 59, "%02d/%02d/20%02d - %02d:%02d:%02d", bcd2dec(nvram_read(NVRAM_RTC_MONTH)), @@ -162,8 +117,6 @@ ptr += sprintf(ptr, "[ %s ]", str); - - for (i = ((SCREEN_X - len) / 2) + len; i < SCREEN_X; i++) ptr += sprintf(ptr, "="); @@ -171,35 +124,16 @@ } #endif -static void redraw_module(struct coreinfo_cat *cat) +static void redraw_module(void) { - if (cat->count == 0) + if (ARRAY_SIZE(modules) == 0) return; wclear(modwin); - cat->modules[cat->cur]->redraw(modwin); + modules[curwin]->redraw(modwin); refresh(); } -static void handle_category_key(struct coreinfo_cat *cat, int key) -{ - if (key >= 'a' && key <= 'z') { - int index = key - 'a'; - - if (index < cat->count) { - - cat->cur = index; - redraw_module(cat); - return; - } - } - - if (cat->count && cat->modules[cat->cur]->handle) { - if (cat->modules[cat->cur]->handle(key)) - redraw_module(cat); - } -} - static void loop(void) { int key; @@ -207,8 +141,9 @@ center(0, "coreinfo v0.1"); print_menu(); - print_submenu(&categories[curwin]); - redraw_module(&categories[curwin]); + if (ARRAY_SIZE(modules) != 0) + modules[curwin]->redraw(modwin); + refresh(); while (1) { key = getch(); @@ -219,21 +154,18 @@ if (key >= KEY_F(1) && key <= KEY_F(9)) { unsigned char ch = key - KEY_F(1); - if (ch <= ARRAY_SIZE(categories)) { - if (ch == ARRAY_SIZE(categories)) + if (ch <= ARRAY_SIZE(modules)) { + if (ch == ARRAY_SIZE(modules)) continue; - if (categories[ch].count == 0) - continue; - curwin = ch; - print_submenu(&categories[curwin]); - redraw_module(&categories[curwin]); + redraw_module(); continue; } } - - handle_category_key(&categories[curwin], key); + if (ARRAY_SIZE(modules) != 0 && modules[curwin]->handle) + if (modules[curwin]->handle(key)) + redraw_module(); } } @@ -250,7 +182,7 @@ init_pair(2, COLOR_BLACK, COLOR_WHITE); init_pair(3, COLOR_WHITE, COLOR_WHITE); - modwin = newwin(22, 80, 1, 0); + modwin = newwin(23, 80, 1, 0); wattrset(stdscr, COLOR_PAIR(1) | A_BOLD); wattrset(modwin, COLOR_PAIR(2)); @@ -264,12 +196,9 @@ refresh(); - for (i = 0; i < ARRAY_SIZE(categories); i++) { - for(j = 0; j < categories[i].count; j++) - categories[i].modules[j]->init(); + for (i = 0; i < ARRAY_SIZE(modules); i++) + modules[i]->init(); - } - loop(); return 0; From svn at coreboot.org Wed May 7 00:03:16 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Wed, 7 May 2008 00:03:16 +0200 Subject: [coreboot] r3285 - trunk/payloads/coreinfo Message-ID: Author: jcrouse Date: 2008-05-07 00:03:16 +0200 (Wed, 07 May 2008) New Revision: 3285 Modified: trunk/payloads/coreinfo/coreinfo.c Log: We were in the risk of running out of space in the option menu at the bottom of the screen - this turns the function keys into categories and then list specific items as part of the category. Signed-off-by: Jordan Crouse Acked-by: Myles Watson Modified: trunk/payloads/coreinfo/coreinfo.c =================================================================== --- trunk/payloads/coreinfo/coreinfo.c 2008-05-06 22:00:55 UTC (rev 3284) +++ trunk/payloads/coreinfo/coreinfo.c 2008-05-06 22:03:16 UTC (rev 3285) @@ -28,24 +28,46 @@ extern struct coreinfo_module nvram_module; extern struct coreinfo_module bootlog_module; -struct coreinfo_module *modules[] = { +struct coreinfo_module *system_modules[] = { #ifdef CONFIG_MODULE_CPUINFO &cpuinfo_module, #endif #ifdef CONFIG_MODULE_PCI &pci_module, #endif +#ifdef CONFIG_MODULE_NVRAM + &nvram_module, +#endif +}; + +struct coreinfo_module *coreboot_modules[] = { #ifdef CONFIG_MODULE_COREBOOT &coreboot_module, #endif -#ifdef CONFIG_MODULE_NVRAM - &nvram_module, -#endif #ifdef CONFIG_MODULE_BOOTLOG &bootlog_module, #endif }; +struct coreinfo_cat { + char name[15]; + int cur; + int count; + struct coreinfo_module **modules; +} categories[] = { + { + .name = "System", + .modules = system_modules, + .count = ARRAY_SIZE(system_modules), + }, + { + .name = "Coreboot", + .modules = coreboot_modules, + .count = ARRAY_SIZE(coreboot_modules), + } +}; + + static WINDOW *modwin; static int curwin; @@ -62,6 +84,26 @@ waddch(win, '\304'); } +static void print_submenu(struct coreinfo_cat *cat) +{ + int i, j; + char menu[80]; + char *ptr = menu; + + wmove(stdscr, 22, 0); + + for (j = 0; j < SCREEN_X; j++) + waddch(stdscr, ' '); + + if (!cat->count) + return; + + for (i = 0; i < cat->count; i++) + ptr += sprintf(ptr, "[%c: %s] ", 'A' + i, cat->modules[i]->name); + + mvprintw(22, 0, menu); +} + static void print_menu(void) { int i, j; @@ -73,12 +115,15 @@ for (j = 0; j < SCREEN_X; j++) waddch(stdscr, ' '); - for (i = 0; i < ARRAY_SIZE(modules); i++) - ptr += sprintf(ptr, "F%d: %s ", i + 1, modules[i]->name); + for (i = 0; i < ARRAY_SIZE(categories); i++) { + if (categories[i].count == 0) + continue; - if (ARRAY_SIZE(modules) != 0) - mvprintw(23, 0, menu); + ptr += sprintf(ptr, "F%d: %s ", i + 1, categories[i].name); + } + mvprintw(23, 0, menu); + #ifdef CONFIG_SHOW_DATE_TIME mvprintw(23, 59, "%02d/%02d/20%02d - %02d:%02d:%02d", bcd2dec(nvram_read(NVRAM_RTC_MONTH)), @@ -117,6 +162,8 @@ ptr += sprintf(ptr, "[ %s ]", str); + + for (i = ((SCREEN_X - len) / 2) + len; i < SCREEN_X; i++) ptr += sprintf(ptr, "="); @@ -124,16 +171,35 @@ } #endif -static void redraw_module(void) +static void redraw_module(struct coreinfo_cat *cat) { - if (ARRAY_SIZE(modules) == 0) + if (cat->count == 0) return; wclear(modwin); - modules[curwin]->redraw(modwin); + cat->modules[cat->cur]->redraw(modwin); refresh(); } +static void handle_category_key(struct coreinfo_cat *cat, int key) +{ + if (key >= 'a' && key <= 'z') { + int index = key - 'a'; + + if (index < cat->count) { + + cat->cur = index; + redraw_module(cat); + return; + } + } + + if (cat->count && cat->modules[cat->cur]->handle) { + if (cat->modules[cat->cur]->handle(key)) + redraw_module(cat); + } +} + static void loop(void) { int key; @@ -141,9 +207,8 @@ center(0, "coreinfo v0.1"); print_menu(); - if (ARRAY_SIZE(modules) != 0) - modules[curwin]->redraw(modwin); - refresh(); + print_submenu(&categories[curwin]); + redraw_module(&categories[curwin]); while (1) { key = getch(); @@ -154,18 +219,21 @@ if (key >= KEY_F(1) && key <= KEY_F(9)) { unsigned char ch = key - KEY_F(1); - if (ch <= ARRAY_SIZE(modules)) { - if (ch == ARRAY_SIZE(modules)) + if (ch <= ARRAY_SIZE(categories)) { + if (ch == ARRAY_SIZE(categories)) continue; + if (categories[ch].count == 0) + continue; + curwin = ch; - redraw_module(); + print_submenu(&categories[curwin]); + redraw_module(&categories[curwin]); continue; } } - if (ARRAY_SIZE(modules) != 0 && modules[curwin]->handle) - if (modules[curwin]->handle(key)) - redraw_module(); + + handle_category_key(&categories[curwin], key); } } @@ -182,7 +250,7 @@ init_pair(2, COLOR_BLACK, COLOR_WHITE); init_pair(3, COLOR_WHITE, COLOR_WHITE); - modwin = newwin(23, 80, 1, 0); + modwin = newwin(22, 80, 1, 0); wattrset(stdscr, COLOR_PAIR(1) | A_BOLD); wattrset(modwin, COLOR_PAIR(2)); @@ -196,9 +264,12 @@ refresh(); - for (i = 0; i < ARRAY_SIZE(modules); i++) - modules[i]->init(); + for (i = 0; i < ARRAY_SIZE(categories); i++) { + for(j = 0; j < categories[i].count; j++) + categories[i].modules[j]->init(); + } + loop(); return 0; From mylesgw at gmail.com Wed May 7 00:03:49 2008 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 6 May 2008 16:03:49 -0600 Subject: [coreboot] Buildrom -- updating busybox... In-Reply-To: <4820D1BC.2060001@sun.com> References: <4820D1BC.2060001@sun.com> Message-ID: <007001c8afc5$10f3f260$1a02a8c0@chimp> > -----Original Message----- > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] > On Behalf Of Marc Karasek > Sent: Tuesday, May 06, 2008 3:47 PM > To: Jordan Crouse; coreboot at coreboot.org > Subject: [coreboot] Buildrom -- updating busybox... > > Jordan, > > Why would just changing the revision of busybox to 1.10.1 seem to break > buildrom? It builds the busybox binary but then tries to put the files > in initrd-rootfs and that directory has not been created as part of the > build process yet. Did you do a make busybox-clean after changing the version? You might want to rm -f work/busybox. There's also the possibility that the config file won't work. You can create a custom config with make busybox-config. Myles > Can you point me in the right direction so I can fix this... > > Marc > > -- > ********************* > Marc Karasek > MTS > Sun Microsystems > mailto:marc.karasek at sun.com > ph:770.360.6415 > ********************* > > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From jordan.crouse at amd.com Wed May 7 00:06:00 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 6 May 2008 16:06:00 -0600 Subject: [coreboot] r3283 - trunk/payloads/coreinfo In-Reply-To: <20080506213312.0F9A99F8059@mail17-dub.bigfish.com> References: <20080506213312.0F9A99F8059@mail17-dub.bigfish.com> Message-ID: <20080506220600.GA28199@cosmic.amd.com> Oops - I hosed that one. coreinfo.c wasn't supposed to be in there, obviously. I am going to to revert it, and then recommit the code under the correct comments. Sorry for the churn. Jordan On 06/05/08 23:32 +0200, svn at coreboot.org wrote: > Author: jcrouse > Date: 2008-05-06 23:32:52 +0200 (Tue, 06 May 2008) > New Revision: 3283 > > Modified: > trunk/payloads/coreinfo/coreinfo.c > trunk/payloads/coreinfo/cpuinfo_module.c > Log: > coreinfo: Move the rdtsc.h include into the #ifdef CONFIG_MODULE_CPUINFO > > rdtsc.h shouldn't be included unless we really need it (and use it). > Trivial. > > Signed-off-by: Jordan Crouse > Acked-by: Jordan Crouse > > > Modified: trunk/payloads/coreinfo/coreinfo.c > =================================================================== > --- trunk/payloads/coreinfo/coreinfo.c 2008-05-06 16:56:47 UTC (rev 3282) > +++ trunk/payloads/coreinfo/coreinfo.c 2008-05-06 21:32:52 UTC (rev 3283) > @@ -28,24 +28,46 @@ > extern struct coreinfo_module nvram_module; > extern struct coreinfo_module bootlog_module; > > -struct coreinfo_module *modules[] = { > +struct coreinfo_module *system_modules[] = { > #ifdef CONFIG_MODULE_CPUINFO > &cpuinfo_module, > #endif > #ifdef CONFIG_MODULE_PCI > &pci_module, > #endif > +#ifdef CONFIG_MODULE_NVRAM > + &nvram_module, > +#endif > +}; > + > +struct coreinfo_module *coreboot_modules[] = { > #ifdef CONFIG_MODULE_COREBOOT > &coreboot_module, > #endif > -#ifdef CONFIG_MODULE_NVRAM > - &nvram_module, > -#endif > #ifdef CONFIG_MODULE_BOOTLOG > &bootlog_module, > #endif > }; > > +struct coreinfo_cat { > + char name[15]; > + int cur; > + int count; > + struct coreinfo_module **modules; > +} categories[] = { > + { > + .name = "System", > + .modules = system_modules, > + .count = ARRAY_SIZE(system_modules), > + }, > + { > + .name = "Coreboot", > + .modules = coreboot_modules, > + .count = ARRAY_SIZE(coreboot_modules), > + } > +}; > + > + > static WINDOW *modwin; > static int curwin; > > @@ -62,6 +84,26 @@ > waddch(win, '\304'); > } > > +static void print_submenu(struct coreinfo_cat *cat) > +{ > + int i, j; > + char menu[80]; > + char *ptr = menu; > + > + wmove(stdscr, 22, 0); > + > + for (j = 0; j < SCREEN_X; j++) > + waddch(stdscr, ' '); > + > + if (!cat->count) > + return; > + > + for (i = 0; i < cat->count; i++) > + ptr += sprintf(ptr, "[%c: %s] ", 'A' + i, cat->modules[i]->name); > + > + mvprintw(22, 0, menu); > +} > + > static void print_menu(void) > { > int i, j; > @@ -73,12 +115,15 @@ > for (j = 0; j < SCREEN_X; j++) > waddch(stdscr, ' '); > > - for (i = 0; i < ARRAY_SIZE(modules); i++) > - ptr += sprintf(ptr, "F%d: %s ", i + 1, modules[i]->name); > + for (i = 0; i < ARRAY_SIZE(categories); i++) { > + if (categories[i].count == 0) > + continue; > > - if (ARRAY_SIZE(modules) != 0) > - mvprintw(23, 0, menu); > + ptr += sprintf(ptr, "F%d: %s ", i + 1, categories[i].name); > + } > > + mvprintw(23, 0, menu); > + > #ifdef CONFIG_SHOW_DATE_TIME > mvprintw(23, 59, "%02d/%02d/20%02d - %02d:%02d:%02d", > bcd2dec(nvram_read(NVRAM_RTC_MONTH)), > @@ -117,6 +162,8 @@ > > ptr += sprintf(ptr, "[ %s ]", str); > > + > + > for (i = ((SCREEN_X - len) / 2) + len; i < SCREEN_X; i++) > ptr += sprintf(ptr, "="); > > @@ -124,16 +171,35 @@ > } > #endif > > -static void redraw_module(void) > +static void redraw_module(struct coreinfo_cat *cat) > { > - if (ARRAY_SIZE(modules) == 0) > + if (cat->count == 0) > return; > > wclear(modwin); > - modules[curwin]->redraw(modwin); > + cat->modules[cat->cur]->redraw(modwin); > refresh(); > } > > +static void handle_category_key(struct coreinfo_cat *cat, int key) > +{ > + if (key >= 'a' && key <= 'z') { > + int index = key - 'a'; > + > + if (index < cat->count) { > + > + cat->cur = index; > + redraw_module(cat); > + return; > + } > + } > + > + if (cat->count && cat->modules[cat->cur]->handle) { > + if (cat->modules[cat->cur]->handle(key)) > + redraw_module(cat); > + } > +} > + > static void loop(void) > { > int key; > @@ -141,9 +207,8 @@ > center(0, "coreinfo v0.1"); > > print_menu(); > - if (ARRAY_SIZE(modules) != 0) > - modules[curwin]->redraw(modwin); > - refresh(); > + print_submenu(&categories[curwin]); > + redraw_module(&categories[curwin]); > > while (1) { > key = getch(); > @@ -154,18 +219,21 @@ > if (key >= KEY_F(1) && key <= KEY_F(9)) { > unsigned char ch = key - KEY_F(1); > > - if (ch <= ARRAY_SIZE(modules)) { > - if (ch == ARRAY_SIZE(modules)) > + if (ch <= ARRAY_SIZE(categories)) { > + if (ch == ARRAY_SIZE(categories)) > continue; > + if (categories[ch].count == 0) > + continue; > + > curwin = ch; > - redraw_module(); > + print_submenu(&categories[curwin]); > + redraw_module(&categories[curwin]); > continue; > } > } > > - if (ARRAY_SIZE(modules) != 0 && modules[curwin]->handle) > - if (modules[curwin]->handle(key)) > - redraw_module(); > + > + handle_category_key(&categories[curwin], key); > } > } > > @@ -182,7 +250,7 @@ > init_pair(2, COLOR_BLACK, COLOR_WHITE); > init_pair(3, COLOR_WHITE, COLOR_WHITE); > > - modwin = newwin(23, 80, 1, 0); > + modwin = newwin(22, 80, 1, 0); > > wattrset(stdscr, COLOR_PAIR(1) | A_BOLD); > wattrset(modwin, COLOR_PAIR(2)); > @@ -196,9 +264,12 @@ > > refresh(); > > - for (i = 0; i < ARRAY_SIZE(modules); i++) > - modules[i]->init(); > + for (i = 0; i < ARRAY_SIZE(categories); i++) { > + for(j = 0; j < categories[i].count; j++) > + categories[i].modules[j]->init(); > > + } > + > loop(); > > return 0; > > Modified: trunk/payloads/coreinfo/cpuinfo_module.c > =================================================================== > --- trunk/payloads/coreinfo/cpuinfo_module.c 2008-05-06 16:56:47 UTC (rev 3282) > +++ trunk/payloads/coreinfo/cpuinfo_module.c 2008-05-06 21:32:52 UTC (rev 3283) > @@ -21,9 +21,9 @@ > */ > > #include "coreinfo.h" > -#include > > #ifdef CONFIG_MODULE_CPUINFO > +#include > > #define VENDOR_INTEL 0x756e6547 > #define VENDOR_AMD 0x68747541 > > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From svn at coreboot.org Wed May 7 00:15:32 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Wed, 7 May 2008 00:15:32 +0200 Subject: [coreboot] r3286 - trunk/payloads/coreinfo Message-ID: Author: jcrouse Date: 2008-05-07 00:15:31 +0200 (Wed, 07 May 2008) New Revision: 3286 Modified: trunk/payloads/coreinfo/coreinfo.c Log: coreinfo: Show the current time and date in the menu Signed-off-by: Jordan Crouse Acked-by: Peter Stuge Modified: trunk/payloads/coreinfo/coreinfo.c =================================================================== --- trunk/payloads/coreinfo/coreinfo.c 2008-05-06 22:03:16 UTC (rev 3285) +++ trunk/payloads/coreinfo/coreinfo.c 2008-05-06 22:15:31 UTC (rev 3286) @@ -104,6 +104,22 @@ mvprintw(22, 0, menu); } +#ifdef CONFIG_SHOW_DATE_TIME +static void print_time_and_date(void) +{ + struct tm tm; + + while(nvram_updating()) + mdelay(10); + + rtc_read_clock(&tm); + + mvprintw(23, 57, "%02d/%02d/%04d - %02d:%02d:%02d", + tm.tm_mon, tm.tm_mday, 1900+tm.tm_year, tm.tm_hour, + tm.tm_min, tm.tm_sec); +} +#endif + static void print_menu(void) { int i, j; @@ -125,13 +141,7 @@ mvprintw(23, 0, menu); #ifdef CONFIG_SHOW_DATE_TIME - mvprintw(23, 59, "%02d/%02d/20%02d - %02d:%02d:%02d", - bcd2dec(nvram_read(NVRAM_RTC_MONTH)), - bcd2dec(nvram_read(NVRAM_RTC_DAY)), - bcd2dec(nvram_read(NVRAM_RTC_YEAR)), - bcd2dec(nvram_read(NVRAM_RTC_HOURS)), - bcd2dec(nvram_read(NVRAM_RTC_MINUTES)), - bcd2dec(nvram_read(NVRAM_RTC_SECONDS))); + print_time_and_date(); #endif } @@ -210,7 +220,14 @@ print_submenu(&categories[curwin]); redraw_module(&categories[curwin]); + halfdelay(10); + while (1) { +#ifdef CONFIG_SHOW_DATE_TIME + print_time_and_date(); + refresh(); +#endif + key = getch(); if (key == ERR) From jordan.crouse at amd.com Wed May 7 00:17:52 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 6 May 2008 16:17:52 -0600 Subject: [coreboot] coreinfo: Update the current time and date on the screen In-Reply-To: <20080425233733.27253.qmail@stuge.se> References: <20080425232734.GH19092@cosmic.amd.com> <20080425233733.27253.qmail@stuge.se> Message-ID: <20080506221752.GA29476@cosmic.amd.com> On 26/04/08 01:37 +0200, Peter Stuge wrote: > On Fri, Apr 25, 2008 at 05:27:34PM -0600, Jordan Crouse wrote: > > coreinfo: Show the current time and date in the menu > > > > Signed-off-by: Jordan Crouse > > Acked-by: Peter Stuge r3286. Thanks. > I think this will make gtod() popular, so please include a warning > notice somewhere, that the clock is not reliable. > > > > Index: coreinfo/coreinfo.c > > =================================================================== > > --- coreinfo.orig/coreinfo.c 2008-04-25 10:17:41.000000000 -0600 > > +++ coreinfo/coreinfo.c 2008-04-25 11:40:49.000000000 -0600 > > @@ -108,6 +108,22 @@ > > mvprintw(SCREEN_Y - 2, 0, menu); > > } > > > > +#ifdef CONFIG_SHOW_DATE_TIME > > +static void print_time_and_date(void) > > +{ > > + struct tm tm; > > + > > + while(nvram_updating()) > > + mdelay(10); > > + > > + rtc_read_clock(&tm); > > + > > + mvprintw(23, 57, "%02d/%02d/%04d - %02d:%02d:%02d", > > + tm.tm_mon, tm.tm_mday, 1900+tm.tm_year, tm.tm_hour, > > + tm.tm_min, tm.tm_sec); > > +} > > +#endif > > + > > static void print_menu(void) > > { > > int i, j; > > @@ -125,13 +141,7 @@ > > mvprintw(SCREEN_Y - 1, 0, menu); > > > > #ifdef CONFIG_SHOW_DATE_TIME > > - mvprintw(SCREEN_Y - 1, 59, "%02d/%02d/20%02d - %02d:%02d:%02d", > > - bcd2dec(nvram_read(NVRAM_RTC_MONTH)), > > - bcd2dec(nvram_read(NVRAM_RTC_DAY)), > > - bcd2dec(nvram_read(NVRAM_RTC_YEAR)), > > - bcd2dec(nvram_read(NVRAM_RTC_HOURS)), > > - bcd2dec(nvram_read(NVRAM_RTC_MINUTES)), > > - bcd2dec(nvram_read(NVRAM_RTC_SECONDS))); > > + print_time_and_date(); > > #endif > > } > > > > @@ -210,7 +220,14 @@ > > print_submenu(&categories[curwin]); > > redraw_module(&categories[curwin]); > > > > + halfdelay(10); > > + > > while (1) { > > +#ifdef CONFIG_SHOW_DATE_TIME > > + print_time_and_date(); > > + refresh(); > > +#endif > > + > > key = getch(); > > > > if (key == ERR) > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From segher at kernel.crashing.org Wed May 7 00:26:10 2008 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Wed, 7 May 2008 00:26:10 +0200 Subject: [coreboot] an example of bad magic. In-Reply-To: <13426df10805061358m2251b5d6i78d4bfc98597d8c0@mail.gmail.com> References: <13426df10805061358m2251b5d6i78d4bfc98597d8c0@mail.gmail.com> Message-ID: <7a8fa52359e257128c19dbd683d56c02@kernel.crashing.org> > just as a cautionary tale for the goal of moving everything to the > dts: "Everything"? A device tree should describe the hardware, and nothing more, ideally. Moving other config stuff in there is typically a Bad Bad Idea. There can be exceptions, of course. > This is a good example of the conservation of complexity. It is always > possible, in the name of hiding details, to create a monstrously > complex system that no one can understand. The device tree is supposed to *expose* the hardware details, and it should reduce complexity. If it doesn't for you, something is going wrong. Segher From joe at settoplinux.org Wed May 7 00:34:25 2008 From: joe at settoplinux.org (Joe) Date: Tue, 6 May 2008 18:34:25 -0400 Subject: [coreboot] Multiple emails In-Reply-To: <4820CB90.5030806@sun.com> References: <4820CB90.5030806@sun.com> Message-ID: Yeh, I get them when someone replies to an email I sent. I get 1 from coreboot and 1 from the sender, ah the mysteries of email... Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org > -----Original Message----- > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] > On Behalf Of Marc Karasek > Sent: Tuesday, May 06, 2008 5:20 PM > To: coreboot at coreboot.org > Subject: [coreboot] Multiple emails > > Is anyone else seeing multiple email messages from the list? > > -- > ********************* > Marc Karasek > MTS > Sun Microsystems > mailto:marc.karasek at sun.com > ph:770.360.6415 > ********************* > > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From joe at settoplinux.org Wed May 7 00:37:12 2008 From: joe at settoplinux.org (Joe) Date: Tue, 6 May 2008 18:37:12 -0400 Subject: [coreboot] an example of bad magic. In-Reply-To: <13426df10805061358m2251b5d6i78d4bfc98597d8c0@mail.gmail.com> References: <13426df10805061358m2251b5d6i78d4bfc98597d8c0@mail.gmail.com> Message-ID: <0483A1BC914341D3A01FEAE5E126F859@smitty2m> I saw a demonstration of infiniband at one of the Linuxworld expos, and it just seemed over all far too complicated than it needed to be. That's my 2 cents. Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org > -----Original Message----- > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] > On Behalf Of ron minnich > Sent: Tuesday, May 06, 2008 4:58 PM > To: Coreboot > Subject: [coreboot] an example of bad magic. > > just as a cautionary tale for the goal of moving everything to the > dts: I am working with some basic infiniband tools. As part of their > goal of making it all portable and easy to build, they use the libtool > support tools. So, for a simple command line like this: > > /bin/sh ./libtool --mode=link --tag=CC gcc -g -O2 -o src/vendstat > src_vendstat-vendstat.o src_vendstat-ibdiag_common.o -lopensm > -losmvendor -losmcomp -libmad -libmad -libumad -libcommon > gcc -g -O2 -o src/vendstat src_vendstat-vendstat.o > src_vendstat-ibdiag_common.o -lopensm -losmvendor -losmcomp -libmad > -libumad -libcommon > > They need the libtool script, which is > wc libtool > 7363 26779 212348 libtool > > 7363 lines. Geez, how long is the program? > > The program is part of a set of diagnostic tools, and the bulk of them > are about 200 lines long. So, for a 200-line, 5330 character program, > we have a 332 character command line and, if that were not enough, a > 7363-line, near quarter million character script. > > This is a good example of the conservation of complexity. It is always > possible, in the name of hiding details, to create a monstrously > complex system that no one can understand. > > Just FYI. > > ron > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From rminnich at gmail.com Wed May 7 01:06:15 2008 From: rminnich at gmail.com (ron minnich) Date: Tue, 6 May 2008 16:06:15 -0700 Subject: [coreboot] an example of bad magic. In-Reply-To: <0483A1BC914341D3A01FEAE5E126F859@smitty2m> References: <13426df10805061358m2251b5d6i78d4bfc98597d8c0@mail.gmail.com> <0483A1BC914341D3A01FEAE5E126F859@smitty2m> Message-ID: <13426df10805061606v6ec4ea44q6f2f29e39e2790ce@mail.gmail.com> On Tue, May 6, 2008 at 3:37 PM, Joe wrote: > I saw a demonstration of infiniband at one of the Linuxworld expos, and it > just seemed over all far too complicated than it needed to be. That's my 2 > cents. sorry if I implied this was any kind of infiniband issue. It's not. It's a larger issue. The point is that libtool is 7300+ lines of impenetrable shell script, aimed at 'isolating' users from variations in systems. But by being so complicated, it merely replaces a small amount of complexity -- requiring users in some cases to set LIB= -- by a huge amount of complexity. It's an example of what can go wrong when people set out to make life easier with magic. I'm a bit concerned at recent posts, because there is some flavor of this confusing magic in v2, and i don't want to see it come in again in v3. For example, I think it's ok to have (e.g.) 71 lines of code in stage1.c for the artec, if that saves us huge amounts of complexity in the dts spec, the dtc compiler, and the device tree code. Sometimes it is ok to expose a small amount of complexity if it avoids a huge amount of hidden complexity. Other times, of course, if we can come up with good design that removes complexity completely, that's a good thing. that's not to say that getting rid of that 71 lines is not a bad idea; but it *might become* a bad idea if it results in 710 lines of really obscure code. Thanks ron From rms at gnu.org Wed May 7 01:06:55 2008 From: rms at gnu.org (Richard M Stallman) Date: Tue, 06 May 2008 19:06:55 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <001701c8af93$d48e2d80$0200a8c0@JUNKNAME> (vogel@ct.metrocast.net) Message-ID: Would you like me to encourage a friendly journalist to contact you to write about Intel's refusal to cooperate? From rms at gnu.org Wed May 7 01:06:53 2008 From: rms at gnu.org (Richard M Stallman) Date: Tue, 06 May 2008 19:06:53 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <001701c8af93$d48e2d80$0200a8c0@JUNKNAME> (vogel@ct.metrocast.net) References: <4818A556.6060900@gnu.org> <481A2C12.6020605@gmx.net> <481C97E6.6060507@gmx.net> <007501c8ae0e$3e596400$0200a8c0@JUNKNAME><481EABD2.4080907@zeomega.com> <001701c8af93$d48e2d80$0200a8c0@JUNKNAME> Message-ID: The point is: It is not enough that the software and the BIOS are free, the graphics, the motherboard, chips, and the entire package need to be free, open, and auditable. For elections, this is not sufficient, because how to you know the election authority didn't substitute a modified version of the free program for the actual election. From peter at stuge.se Wed May 7 01:14:49 2008 From: peter at stuge.se (Peter Stuge) Date: Wed, 7 May 2008 01:14:49 +0200 Subject: [coreboot] an example of bad magic. In-Reply-To: <13426df10805061606v6ec4ea44q6f2f29e39e2790ce@mail.gmail.com> References: <13426df10805061358m2251b5d6i78d4bfc98597d8c0@mail.gmail.com> <0483A1BC914341D3A01FEAE5E126F859@smitty2m> <13426df10805061606v6ec4ea44q6f2f29e39e2790ce@mail.gmail.com> Message-ID: <20080506231449.27103.qmail@stuge.se> On Tue, May 06, 2008 at 04:06:15PM -0700, ron minnich wrote: > that's not to say that getting rid of that 71 lines is not a bad > idea; but it *might become* a bad idea if it results in 710 lines > of really obscure code. Excellent point. //Peter From c-d.hailfinger.devel.2006 at gmx.net Wed May 7 01:32:45 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 07 May 2008 01:32:45 +0200 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: References: Message-ID: <4820EA9D.6040204@gmx.net> On 07.05.2008 01:06, Richard M Stallman wrote: > Would you like me to encourage a friendly journalist to contact you to write about Intel's refusal to cooperate? > The preferred way would be to focus any article on praising the companies supporting coreboot. We had a detailed list somewhere, we could dig it up and mail it to you. Usually, shaming companies into contributing doesn't work, but giving the good ones lots of good publicity strengthens the positions of coreboot supporters in those companies. Besides that, while the tech media like to bash "evil" companies every so often, writing about cool gadgets with cool features is what lures readers to them. I'd suggest we wait with contacting any journalist until we can offer all the information needed for an article in one neat package. Regards, Carl-Daniel From corey.osgood at gmail.com Wed May 7 01:34:01 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 6 May 2008 19:34:01 -0400 Subject: [coreboot] Multiple emails In-Reply-To: References: <4820CB90.5030806@sun.com> Message-ID: That's an option in whatever the list manager is here (can't remember the name of it). If you go to your subscription options, there's an option to disable that, towards the bottom. Gmail filters those out tho, and I kind of like them. -Corey On Tue, May 6, 2008 at 6:34 PM, Joe wrote: > Yeh, I get them when someone replies to an email I sent. I get 1 from > coreboot and 1 from the sender, ah the mysteries of email... > > Thanks, > Joseph Smith > Set-Top-Linux > www.settoplinux.org > > -----Original Message----- > > From: coreboot-bounces at coreboot.org [mailto: > coreboot-bounces at coreboot.org] > > On Behalf Of Marc Karasek > > Sent: Tuesday, May 06, 2008 5:20 PM > > To: coreboot at coreboot.org > > Subject: [coreboot] Multiple emails > > > > Is anyone else seeing multiple email messages from the list? > > > > -- > > ********************* > > Marc Karasek > > MTS > > Sun Microsystems > > mailto:marc.karasek at sun.com > > ph:770.360.6415 > > ********************* > > > > > > -- > > coreboot mailing list > > coreboot at coreboot.org > > http://www.coreboot.org/mailman/listinfo/coreboot > > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey.osgood at gmail.com Wed May 7 01:36:43 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 6 May 2008 19:36:43 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <4820EA9D.6040204@gmx.net> References: <4820EA9D.6040204@gmx.net> Message-ID: On Tue, May 6, 2008 at 7:32 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006 at gmx.net> wrote: > On 07.05.2008 01:06, Richard M Stallman wrote: > > Would you like me to encourage a friendly journalist to contact you to > write about Intel's refusal to cooperate? > > > > The preferred way would be to focus any article on praising the > companies supporting coreboot. We had a detailed list somewhere, we > could dig it up and mail it to you. Usually, shaming companies into > contributing doesn't work, but giving the good ones lots of good > publicity strengthens the positions of coreboot supporters in those > companies. Also, Intel could be doing a lot less to help us, and linux in general. Truncated datasheets are better then no datasheets. -Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordan.crouse at amd.com Wed May 7 01:59:32 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 6 May 2008 17:59:32 -0600 Subject: [coreboot] more on the cs5536 and 2.6.25 In-Reply-To: <13426df10805052303x4456a4bdhd6aabf6c59e98213@mail.gmail.com> References: <13426df10805052303x4456a4bdhd6aabf6c59e98213@mail.gmail.com> Message-ID: <20080506235932.GA20516@cosmic.amd.com> On 05/05/08 23:03 -0700, ron minnich wrote: > I think 2.6.25 is hanging on the probe of ide port1. > > This is 2.6.24 > > AMD5536: IDE controller (0x1022:0x209a rev 0x01) at PCI slot 0000:00:0f.2 > AMD5536: not 100% native mode: will probe irqs later > AMD5536: 0000:00:0f.2 (rev 01) UDMA100 controller > ide0: BM-DMA at 0x1ca0-0x1ca7, BIOS settings: hda:pio, hdb:pio > AMD5536: IDE port disabled > hda: CF 1GB, ATA DISK drive > hda: MWDMA2 mode selected > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > hda: max request size: 128KiB > hda: 2030112 sectors (1039 MB) w/1KiB Cache, CHS=2014/16/63 > hda: hda1 > > and 2.6.25 > > AMD5536: 0000:00:0f.2 (rev 01) UDMA100 controller > AMD5536: IDE controller (0x1022:0x209a rev 0x01) at PCI slot 0000:00:0f.2 > AMD5536: not 100% native mode: will probe irqs later > AMD5536: IDE port disabled > ide0: BM-DMA at 0x1ca0-0x1ca7, BIOS settings: hda:PIO, hdb:PIO > > and on one boot it did this: > Probing IDE interface ide1... > > I think it's going after ide1, even though it is not there. Not sure > yet. Something is pretty wrong here, and it broke from 2.6.24 to > 2.6.25. Of course its looking for ide1, but as soon as it sees the missing bit in the PCI config space its going to give up. I haven't been able to reproduce hangs with the legacy IDE driver running with v2 and 2.6.25 on norwich - everything is running fine: AMD5536: 0000:00:0f.2 (rev 01) UDMA100 controller AMD5536: IDE controller (0x1022:0x209a rev 0x01) at PCI slot 0000:00:0f.2 AMD5536: not 100% native mode: will probe irqs later AMD5536: IDE port disabled ide0: BM-DMA at 0x1ca0-0x1ca7, BIOS settings: hda:PIO, hdb:PIO Probing IDE interface ide0... hda: TOSHIBA THNCF512MDG, CFA DISK drive hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4 hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4 ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... pata_cs5536 is not healthy, however: PCI: Unable to reserve I/O region #1:8 at 1f0 for device 0000:00:0f.2 pata_cs5536 0000:00:0f.2: failed to request/iomap BARs for port 0 (errno=-16) pata_cs5536 0000:00:0f.2: no available native port Again, this is with v2, so your mileage will vary, but as far as the amd74xx driver is concerned, I don't think we're seeing a huge kernel regression. I'm going to take some swings at the pata_cs5536 driver and see if we can't make it better. Jordan PS: In my config, at least, following the IDE setup is the USB setup - possibly you are hanging _there_ and just not seeing any intermediate kernel messages. -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From joe at settoplinux.org Wed May 7 02:21:47 2008 From: joe at settoplinux.org (Joe) Date: Tue, 6 May 2008 20:21:47 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <4820EA9D.6040204@gmx.net> References: <4820EA9D.6040204@gmx.net> Message-ID: <1EEE12BD90C44A59A82FE7237DA622F9@smitty2m> I agree with Carl-Daniel here, we should focus on the positive not the negative. Publishing anything about Intel's stubbornness would probably come back to bite us in the ass one day. Karma, what you give, will always come back. It may not be tomorrow but someday it will come back. Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org > -----Original Message----- > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] > On Behalf Of Carl-Daniel Hailfinger > Sent: Tuesday, May 06, 2008 7:33 PM > To: rms at gnu.org > Cc: coreboot at coreboot.org > Subject: Re: [coreboot] [Fwd: Re: Contact Intel] > > On 07.05.2008 01:06, Richard M Stallman wrote: > > Would you like me to encourage a friendly journalist to contact you to > write about Intel's refusal to cooperate? > > > > The preferred way would be to focus any article on praising the > companies supporting coreboot. We had a detailed list somewhere, we > could dig it up and mail it to you. Usually, shaming companies into > contributing doesn't work, but giving the good ones lots of good > publicity strengthens the positions of coreboot supporters in those > companies. > Besides that, while the tech media like to bash "evil" companies every > so often, writing about cool gadgets with cool features is what lures > readers to them. > > I'd suggest we wait with contacting any journalist until we can offer > all the information needed for an article in one neat package. > > Regards, > Carl-Daniel > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From c-d.hailfinger.devel.2006 at gmx.net Wed May 7 02:42:24 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 07 May 2008 02:42:24 +0200 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> Message-ID: <4820FAF0.2040207@gmx.net> On 06.05.2008 17:37, ron minnich wrote: > On Tue, May 6, 2008 at 5:15 AM, Carl-Daniel Hailfinger > >> Indeed. Since we don't use the struct device passed in to ide_init, why >> don't we give Geode IDE its own struct device_operations and store the >> IDE config there? >> > > That's a great question. The reason is that the cs5536 is one chip. On > v2, we treated it as more than one. For my goal of easing non-experts > into the code, I decided to try making it one chip and one dts. This > is an experiment that may, in the end, prove wrong. > > I still think one dts per chip is the right way to go, but do we need > more than one level of dts? I really think this all should be in one > file, it got much simpler that way. > My dream is to have templates for such chips so we can refer to the template unless we need some very special handling. That would mean multi-level includes in the dts AFAICS, but I'm not totally happy about that. >> I have problems parsing the sentence above: "... I don't think it was >> ever IDE." >> > > I should not write when that tired. > > Let's try again. > > Works on 2.6.24. hangs on 2.6.25, I thought for a second it was NOT > ide, but it is clear that 2.6.25 is hanging on probing ide1 -- or it > sure looks that way. And, again, the post code of 00 is weird; I keep > thinking there are vsa issues here. It just doesn't act like Linux > hangs I see on other boards. > The phenomenon is weird, the text is well-written. >> You know my preference for killing dev_find_pci_device, but that can >> come later if it is too difficult. >> > > I have no disagreement as long as, in so doing, we reduce code overall > and increase comprehensability. > See below for my take at this. Move CS5536 IDE configuration into a separate dts and its own PCI device. Signed-off-by: Carl-Daniel Hailfinger Build-tested on db800, norwich, dbe62, alix.1c, alix.2c3. Breaks build for dbe61. Index: LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/ide =================================================================== --- LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/ide (revision 0) +++ LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/ide (revision 0) @@ -0,0 +1,26 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2007 Ronald G. Minnich + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +{ + device_operations = "cs5536_ide"; + + /* IDE: enable CS5536 IDE. There may be a different IDE controller on board */ + enable_ide = "0"; +}; Index: LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/cs5536.c =================================================================== --- LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/cs5536.c (revision 676) +++ LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/cs5536.c (working copy) @@ -590,6 +590,11 @@ { u32 ide_cfg; + struct southbridge_amd_cs5536_ide_config *ide = + (struct southbridge_amd_cs5536_ide_config *)dev->device_configuration; + if (!ide->enable_ide) + return; + printk(BIOS_DEBUG, "cs5536_ide: %s\n", __func__); /* GPIO and IRQ setup are handled in the main chipset code. */ @@ -654,9 +659,6 @@ hide_vpci(sb->unwanted_vpci[i]); } - if (sb->enable_ide) - ide_init(dev); - cs5536_setup_power_button(sb); printk(BIOS_SPEW, "cs5536: %s() Exit\n", __FUNCTION__); @@ -688,3 +690,17 @@ .phase6_init = southbridge_init, }; +struct device_operations cs5536_ide = { + .id = {.type = DEVICE_ID_PCI, + .u = {.pci = {.vendor = PCI_VENDOR_ID_AMD, + .device = PCI_DEVICE_ID_AMD_CS5536_B0_IDE}}}, + .constructor = default_device_constructor, +#warning FIXME: what has to go in phase3_scan? + .phase3_scan = 0, + .phase4_read_resources = pci_dev_read_resources, + .phase4_set_resources = pci_dev_set_resources, + .phase5_enable_resources = pci_dev_enable_resources, + .phase6_init = ide_init, + .ops_pci = &pci_dev_ops_pci, +}; + Index: LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/dts =================================================================== --- LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/dts (revision 676) +++ LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/dts (working copy) @@ -36,9 +36,6 @@ /* 0:IDE 1:FLASH, if you are using NAND flash instead of IDE drive. */ enable_ide_nand_flash = "0"; - /* IDE: enable CS5536 IDE. There may be a different IDE controller on board */ - enable_ide = "0"; - /* Enable USB Port 4 (0:host 1:device). */ enable_USBP4_device = "0"; Index: LinuxBIOSv3-hierarchical_dts/mainboard/amd/norwich/dts =================================================================== --- LinuxBIOSv3-hierarchical_dts/mainboard/amd/norwich/dts (revision 676) +++ LinuxBIOSv3-hierarchical_dts/mainboard/amd/norwich/dts (working copy) @@ -34,7 +34,6 @@ }; pci at 15,0 { /config/("southbridge/amd/cs5536/dts"); - enable_ide = "1"; /* Interrupt enables for LPC bus. * Each bit is an IRQ 0-15. */ lpc_serirq_enable = "0x00001002"; @@ -50,5 +49,9 @@ com1_address = "0x3f8"; com1_irq = "4"; }; + pci at 15,2 { + /config/("southbridge/amd/cs5536/ide"); + enable_ide = "1"; + }; }; }; Index: LinuxBIOSv3-hierarchical_dts/mainboard/amd/db800/dts =================================================================== --- LinuxBIOSv3-hierarchical_dts/mainboard/amd/db800/dts (revision 676) +++ LinuxBIOSv3-hierarchical_dts/mainboard/amd/db800/dts (working copy) @@ -34,7 +34,6 @@ }; pci at 15,0 { /config/("southbridge/amd/cs5536/dts"); - enable_ide = "1"; /* Interrupt enables for LPC bus. * Each bit is an IRQ 0-15. */ lpc_serirq_enable = "0x000010da"; @@ -47,6 +46,10 @@ enable_gpio_int_route = "0x0D0C0700"; enable_USBP4_device = "1"; }; + pci at 15,2 { + /config/("southbridge/amd/cs5536/ide"); + enable_ide = "1"; + }; ioport at 46 { /config/("superio/winbond/w83627hf/dts"); com1enable = "1"; Index: LinuxBIOSv3-hierarchical_dts/mainboard/artecgroup/dbe62/dts =================================================================== --- LinuxBIOSv3-hierarchical_dts/mainboard/artecgroup/dbe62/dts (revision 676) +++ LinuxBIOSv3-hierarchical_dts/mainboard/artecgroup/dbe62/dts (working copy) @@ -34,7 +34,6 @@ }; pci at 15,0 { /config/("southbridge/amd/cs5536/dts"); - enable_ide = "1"; /* Interrupt enables for LPC bus. * Each bit is an IRQ 0-15. */ lpc_serirq_enable = "0x00001002"; @@ -54,5 +53,9 @@ /* Set com2 IRQ to be what is usually COM1 */ com2_irq = "4"; }; + pci at 15,2 { + /config/("southbridge/amd/cs5536/ide"); + enable_ide = "1"; + }; }; }; Index: LinuxBIOSv3-hierarchical_dts/mainboard/pcengines/alix1c/dts =================================================================== --- LinuxBIOSv3-hierarchical_dts/mainboard/pcengines/alix1c/dts (revision 676) +++ LinuxBIOSv3-hierarchical_dts/mainboard/pcengines/alix1c/dts (working copy) @@ -34,7 +34,6 @@ }; pci at 15,0 { /config/("southbridge/amd/cs5536/dts"); - enable_ide = "1"; /* Interrupt enables for LPC bus. * Each bit is an IRQ 0-15. */ lpc_serirq_enable = "0x000010da"; @@ -46,6 +45,10 @@ * See virtual PIC spec. */ enable_gpio_int_route = "0x0D0C0700"; }; + pci at 15,2 { + /config/("southbridge/amd/cs5536/ide"); + enable_ide = "1"; + }; ioport at 46 { /config/("superio/winbond/w83627hf/dts"); com1enable = "1"; Index: LinuxBIOSv3-hierarchical_dts/mainboard/pcengines/alix2c3/dts =================================================================== --- LinuxBIOSv3-hierarchical_dts/mainboard/pcengines/alix2c3/dts (revision 676) +++ LinuxBIOSv3-hierarchical_dts/mainboard/pcengines/alix2c3/dts (working copy) @@ -32,7 +32,6 @@ }; pci at 15,0 { /config/("southbridge/amd/cs5536/dts"); - enable_ide = "1"; /* Interrupt enables for LPC bus. * Each bit is an IRQ 0-15. */ lpc_serirq_enable = "0x000010da"; @@ -50,5 +49,9 @@ /* this board does not really have vga; disable it (pci device 00:01.1) */ unwanted_vpci = < 80000900 0 >; }; + pci at 15,2 { + /config/("southbridge/amd/cs5536/ide"); + enable_ide = "1"; + }; }; }; From c-d.hailfinger.devel.2006 at gmx.net Wed May 7 02:46:28 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 07 May 2008 02:46:28 +0200 Subject: [coreboot] [Flashrom] success reports Message-ID: <4820FBE4.9070700@gmx.net> Hi Peter, Harald Gutmann tested two SPI chips for IDENTIFY, ERASE, WRITE, VERIFY. http://paste.debian.net/2299/ http://paste.debian.net/2294/ Please update flashrom sources. Thanks! Regards, Carl-Daniel From sync.jma at gmail.com Wed May 7 03:47:50 2008 From: sync.jma at gmail.com (Jun Ma) Date: Wed, 7 May 2008 09:47:50 +0800 Subject: [coreboot] questions about "QEMU Build Tutorial" In-Reply-To: <003b01c8af93$55a79b00$1a02a8c0@chimp> References: <03bf01c8ac66$fad7d6b0$0023040a@chimp> <03c401c8ac71$bef617a0$0023040a@chimp> <003b01c8af93$55a79b00$1a02a8c0@chimp> Message-ID: On Wed, May 7, 2008 at 12:07 AM, Myles Watson wrote: > > I'll put it up on the Wiki if you'd like, but I since you "have something to > contribute", you could also ask for an account. > Thanks, Myles. I will ask the maintainer for the account. :) > Did you get this all to work like you wanted? > Yes, this guide is exactly what I want. but there still has few troubles, for example: 'Enter, b, e' and other bash-like edit commands not works in filo.(I thought it might be my config err or filo's bug on keyboard event handling, I could use 'a' to boot the vmlinuz...), I have not read the code yet. > Thanks, > > Myles > > From peter at stuge.se Wed May 7 03:55:13 2008 From: peter at stuge.se (Peter Stuge) Date: Wed, 7 May 2008 03:55:13 +0200 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <4820FAF0.2040207@gmx.net> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> <4820FAF0.2040207@gmx.net> Message-ID: <20080507015513.32577.qmail@stuge.se> On Wed, May 07, 2008 at 02:42:24AM +0200, Carl-Daniel Hailfinger wrote: > +++ LinuxBIOSv3-hierarchical_dts/mainboard/amd/norwich/dts (working copy) > @@ -34,7 +34,6 @@ > }; > pci at 15,0 { > /config/("southbridge/amd/cs5536/dts"); > - enable_ide = "1"; > /* Interrupt enables for LPC bus. > * Each bit is an IRQ 0-15. */ > lpc_serirq_enable = "0x00001002"; > @@ -50,5 +49,9 @@ > com1_address = "0x3f8"; > com1_irq = "4"; > }; > + pci at 15,2 { > + /config/("southbridge/amd/cs5536/ide"); > + enable_ide = "1"; > + }; > }; > }; This makes more sense, but.. What was the reason for introducing multiple dts files for a single chip again? Only the C struct name limitations? *scratches forehead* I kind of want the single dts per chip back.. //Peter From aaron.lwe at gmail.com Wed May 7 04:50:11 2008 From: aaron.lwe at gmail.com (aaron lwe) Date: Wed, 7 May 2008 10:50:11 +0800 Subject: [coreboot] legacy bios support and coreboot Message-ID: Hi kevin, Great job! Some comments below. > > I suspect the hardware detection and initialization does not have much > overlap with coreboot. The most important part of this section is the > IDE initialization and disk scan. (Some other code, for example > keyboard init, may be redundant when used with coreboot.) yes > > The option rom scan and execution allows the bios code to call out to > additional system roms. The "post" stage runs in 32bit mode, but the > option roms are called in 16bit mode - the "legacybios" code simply > transitions to/from 16bit mode to make these calls. The option rom > code is executed natively on the processor. I think this is redundant with coreboot, since coreboot will also run pci rom, eg. vga bios. > > The "pci init" code looks to be redundant with what coreboot already > provides. The code in "legacybios" seems to be intel > northbride/soutbridge specific. yes, these code could be omitted when used with coreboot. > Some old DOS programs make assumptions about specific memory locations > in the first 1Meg of ram. The "legacybios" code fills in these areas > to make these old programs happy - in short they are the "bios data > area" at 0x00000 - 0x00500, the "extended bios data area" at 0x9fc00 - > 0xa0000, and some hardcoded locations in the 0xf0000 bios segment > itself. The bios working storage areas (in bda and ebda) and the > 16bit interrupt vector table is also setup (part of the bda). I think this is necessary. > It is not clear to me how much of the acpi/mptable/smbios code is > reusable on real hardware. It is possible that most of the info in > these tables is irrelevant, and the "legacybios" code may therefore be > a good starting point. However, it may also be simpler to have > coreboot just pass these tables in. I don't think the acpi/mptable is reusable on real hardware, so have coreboot pass these tables in is better since coreboot developer should have a better understanding about the mainboard he/she is developing. > Some of the hardware accesses made by the "legacybios" code appear to > be specific to hardware in the emulator. The code attempts to enable > ram shadowing of the memory segment at 0xf00000 - it does this so that > it can put acpi/mptable/smbios tables into that area. After it is > complete, it attempts to disable writes to that region. The code > sequence looks to be specific to intel north/southbridges. It isn't > necessary to disable writes to 0xf0000 (though it would be nice), but > it is necessary to have the ability to alter that memory. This shadowing job should be left to coreboot, if someone is going to use legacybios, he should take care of this shadowing job in ram init code. I've written a loader for coreboot-v2 to load legacybios, it works well when used with qemu, I've booted freebsd with it. But on real hardware, via epia-cn, it hangs with a blank screen, the debug port value is 0x31, I'll take some time to see what's going wrong. I add a header for legacybios to become a payload, this is done by a utility createpayload. I've attached the loader and the utility. Signed-off-by: Aaron Lwe Thanks, -------------- next part -------------- A non-text attachment was scrubbed... Name: legacybiosloader.patch Type: application/octet-stream Size: 7988 bytes Desc: not available URL: From rminnich at gmail.com Wed May 7 05:50:46 2008 From: rminnich at gmail.com (ron minnich) Date: Tue, 6 May 2008 20:50:46 -0700 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <20080507015513.32577.qmail@stuge.se> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> <4820FAF0.2040207@gmx.net> <20080507015513.32577.qmail@stuge.se> Message-ID: <13426df10805062050x1fd7330dr588d2524ab2d8caf@mail.gmail.com> On Tue, May 6, 2008 at 6:55 PM, Peter Stuge wrote: > This makes more sense, but.. > > What was the reason for introducing multiple dts files for a single > chip again? > > Only the C struct name limitations? > > *scratches forehead* I kind of want the single dts per chip back.. > yep, me too. that's a concern. Also, I worry about people having to deal with the nasty little thicket of tons of little file, all (mostly) alike. And we've got a vendor/devid. At what point are we asking people to describe the bus/dev/fn too much? ron From rminnich at gmail.com Wed May 7 05:53:51 2008 From: rminnich at gmail.com (ron minnich) Date: Tue, 6 May 2008 20:53:51 -0700 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <20080507015513.32577.qmail@stuge.se> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> <4820FAF0.2040207@gmx.net> <20080507015513.32577.qmail@stuge.se> Message-ID: <13426df10805062053k29f7a80axb98f77061c5b1ccb@mail.gmail.com> one last comment: Stepan once received a complaint that linuxbios was "too greppy". Is this patch pushing us back that direction? This is a question. I don't know. ron From mart.raudsepp at artecdesign.ee Wed May 7 10:04:03 2008 From: mart.raudsepp at artecdesign.ee (Mart Raudsepp) Date: Wed, 07 May 2008 11:04:03 +0300 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <4820FAF0.2040207@gmx.net> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> <4820FAF0.2040207@gmx.net> Message-ID: <1210147443.5011.5.camel@martr-gentoo.artec> ?hel kenal p?eval, K, 2008-05-07 kell 02:42, kirjutas Carl-Daniel Hailfinger: > See below for my take at this. > > Move CS5536 IDE configuration into a separate dts and its own PCI device. > > Signed-off-by: Carl-Daniel Hailfinger > > Build-tested on db800, norwich, dbe62, alix.1c, alix.2c3. > Breaks build for dbe61. I think it's fine that it breaks build for dbe61 and I think that dbe61 code should be brought up to mostly the state that dbe62 is in anyway. > Index: LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/dts > =================================================================== > --- LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/dts (revision 676) > +++ LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/dts (working copy) > @@ -36,9 +36,6 @@ > /* 0:IDE 1:FLASH, if you are using NAND flash instead of IDE drive. */ > enable_ide_nand_flash = "0"; > > - /* IDE: enable CS5536 IDE. There may be a different IDE controller on board */ > - enable_ide = "0"; > - > /* Enable USB Port 4 (0:host 1:device). */ > enable_USBP4_device = "0"; ... > Index: LinuxBIOSv3-hierarchical_dts/mainboard/artecgroup/dbe62/dts > =================================================================== > --- LinuxBIOSv3-hierarchical_dts/mainboard/artecgroup/dbe62/dts (revision 676) > +++ LinuxBIOSv3-hierarchical_dts/mainboard/artecgroup/dbe62/dts (working copy) > @@ -34,7 +34,6 @@ > }; > pci at 15,0 { > /config/("southbridge/amd/cs5536/dts"); > - enable_ide = "1"; > /* Interrupt enables for LPC bus. > * Each bit is an IRQ 0-15. */ > lpc_serirq_enable = "0x00001002"; > @@ -54,5 +53,9 @@ > /* Set com2 IRQ to be what is usually COM1 */ > com2_irq = "4"; > }; > + pci at 15,2 { > + /config/("southbridge/amd/cs5536/ide"); > + enable_ide = "1"; > + }; > }; > }; Just removing enable_ide as in southbridge/cs5536 would be better in my opinion. DBE62 uses NAND not any IDE, so I was actually intending to send a patch that sets enable_ide to 0, but now I saw this. Those things said, not qualified for acking Mart Raudsepp Artec Design LLC From stepan at coresystems.de Wed May 7 12:22:56 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 07 May 2008 12:22:56 +0200 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: References: <4820EA9D.6040204@gmx.net> Message-ID: <48218300.4060901@coresystems.de> Corey Osgood wrote: > On Tue, May 6, 2008 at 7:32 PM, Carl-Daniel Hailfinger > > wrote: > > On 07.05.2008 01:06, Richard M Stallman wrote: > > Would you like me to encourage a friendly journalist to contact > you to write about Intel's refusal to cooperate? > > > > The preferred way would be to focus any article on praising the > companies supporting coreboot. We had a detailed list somewhere, we > could dig it up and mail it to you. Usually, shaming companies into > contributing doesn't work, but giving the good ones lots of good > publicity strengthens the positions of coreboot supporters in those > companies. > > > Also, Intel could be doing a lot less to help us, and linux in > general. Truncated datasheets are better then no datasheets. > > -Corey I think we really should avoid the bashing at all. It is going to make a nice hype and some technocrates will probably buy their hardware from AMD instead of Intel, but this isn't changing the world. It isn't even showing up in serious numbers. So here's a story. I removed all the names to keep it neutral. I remember it suddenly got harder talking to a very friendly CPU vendor after they bought a graphics chip vendor, because one guy started running around with a halo, telling that people should not buy from that very graphics chip vendor, in a half-reflected way, similar to those my ancestor countrymen suggested not to buy from certain groups of people. Sorry, in my opinion this is absolutely the wrong direction. It just creates hate, and makes talking to people harder. I know that Intel is watching coreboot very well, and they had themselves and their products inspired from us, feature-wise. Also, there are many people working for Intel that love free and open source software, and they think their corporate decisions toward certain areas of software, where intel is still closed should be improved. And they see very well that a bootloader that has 235MB checked out size, is not a suitable solution for many of their customers. I think what we need to do is get in contact with those people and convince them to help us, not pointing fingers at corporations. Us expecting corporations to be good or bad, doesn't work out. Corporations have no soul, so they will never be. _People_ can do good, though, and we need to find those that can help us and that we can convince that we are doing the right thing. Stefan From stepan at coresystems.de Wed May 7 12:29:14 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 07 May 2008 12:29:14 +0200 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> Message-ID: <4821847A.4040609@coresystems.de> ron minnich wrote: > I know some people will get upset by the find_pci_device, but: > This patch fixes a long-standing problem in the cs5536 driver, that is > probably also in v2. > > The ide_init is called with the sb device but needs the IDE device, > which is different. > Then that is the error that needs to be fixed. ide_init needs to be called with the IDE device. > Signed-off-by: Ronald G. Minnich > I veto. The above is against the concept of constructors we have in v3 or drivers we have in v2. If we start searching for device X in code attached to device Y, we could as well just make a long linear piece of code searching for all devices and stop walking over the device tree. Stefan From c-d.hailfinger.devel.2006 at gmx.net Wed May 7 13:43:09 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 07 May 2008 13:43:09 +0200 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <4821847A.4040609@coresystems.de> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <4821847A.4040609@coresystems.de> Message-ID: <482195CD.1010402@gmx.net> On 07.05.2008 12:29, Stefan Reinauer wrote: > ron minnich wrote: > >> I know some people will get upset by the find_pci_device, but: >> This patch fixes a long-standing problem in the cs5536 driver, that is >> probably also in v2. >> >> The ide_init is called with the sb device but needs the IDE device, >> which is different. >> >> > Then that is the error that needs to be fixed. ide_init needs to be > called with the IDE device. > > >> Signed-off-by: Ronald G. Minnich >> >> > > I veto. The above is against the concept of constructors we have in v3 > or drivers we have in v2. If we start searching for device X in code > attached to device Y, we could as well just make a long linear piece of > code searching for all devices and stop walking over the device tree. > See my counter-proposal patch in this thread from a few hours ago. It should address your worries. Regards, Carl-Daniel From peter at stuge.se Wed May 7 14:00:12 2008 From: peter at stuge.se (Peter Stuge) Date: Wed, 7 May 2008 14:00:12 +0200 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <13426df10805062053k29f7a80axb98f77061c5b1ccb@mail.gmail.com> <13426df10805062050x1fd7330dr588d2524ab2d8caf@mail.gmail.com> References: <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> <4820FAF0.2040207@gmx.net> <20080507015513.32577.qmail@stuge.se> <13426df10805062053k29f7a80axb98f77061c5b1ccb@mail.gmail.com> <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> <4820FAF0.2040207@gmx.net> <20080507015513.32577.qmail@stuge.se> <13426df10805062050x1fd7330dr588d2524ab2d8caf@mail.gmail.com> Message-ID: <20080507120012.8560.qmail@stuge.se> On Tue, May 06, 2008 at 08:50:46PM -0700, ron minnich wrote: > > What was the reason for introducing multiple dts files for a single > > chip again? > > > > Only the C struct name limitations? > > > > *scratches forehead* I kind of want the single dts per chip back.. > > yep, me too. that's a concern. What needs to change so we can just combine the split out dts files into one? > Also, I worry about people having to deal with the nasty little > thicket of tons of little file, all (mostly) alike. Yes, there is no point to that. > And we've got a vendor/devid. At what point are we asking people > to describe the bus/dev/fn too much? I don't think this should be a concern. The device tree is based on physical components and I think that is the only clean design since that's how the hardware we try to abstract is constructed. I understand your worry, but keep in mind that "people" should only have to describe the hardware once, when the chip dts is created. On Tue, May 06, 2008 at 08:53:51PM -0700, ron minnich wrote: > "too greppy". Is this patch pushing us back that direction? In the sense that more and more files now have less and less data bits, yes definately. I would love to solve this issue by moving (back?) to composite devices in dts files. Yes, this means a little more "magic" in dtc, but hopefully we can still keep a simple (1:1?) device:struct relationship. //Peter From c-d.hailfinger.devel.2006 at gmx.net Wed May 7 14:03:28 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 07 May 2008 14:03:28 +0200 Subject: [coreboot] LinuxTag 2008 Message-ID: <48219A90.1060703@gmx.net> Hi all, http://www.coreboot.org/LinuxTag_2008 has been updated with the latest information. We'll have two workshops there and I'll appreciate anybody who helps us at the booth. Regards, Carl-Daniek From peter at stuge.se Wed May 7 14:11:13 2008 From: peter at stuge.se (Peter Stuge) Date: Wed, 7 May 2008 14:11:13 +0200 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> Message-ID: <20080507121113.11509.qmail@stuge.se> On Tue, May 06, 2008 at 08:37:34AM -0700, ron minnich wrote: > the cs5536 is one chip. On v2, we treated it as more than one. For > my goal of easing non-experts into the code, I decided to try > making it one chip and one dts. .. > I still think one dts per chip is the right way to go, but do we > need more than one level of dts? One level as in a single file - yes I think so. One level as in one level of {} within that file - no I don't think so. Whatever we do in dtc that depends on the file name right now should instead depend on something else. Maybe device path+id? Or we create a new namespace for chip "friendlynames" that are used to build code? Case in point, looking at alix1c/dts: /{ mainboard-vendor = "PC Engines"; mainboard-name = "ALIX1.C"; cpus { }; apic at 0 { /config/("northbridge/amd/geodelx/apic"); }; domain at 0 { /config/("northbridge/amd/geodelx/domain"); I'd like everything up to this point to be "inherited" from one geodelx dts. /* Video RAM has to be in 2MB chunks. */ geode_video_mb = "8"; pci at 1,0 { /config/("northbridge/amd/geodelx/pci"); }; Oh, and the above 1,0 device as well. pci at 15,0 { /config/("southbridge/amd/cs5536/dts"); enable_ide = "1"; This would stay pretty much as is, except maybe the enable_ide should be a generic enable variable instead, and be in pci at 15,4 or whatever. Is 15 really determined by the mainboard by the way - it should _not_ be in the mainboard dts otherwise. All the above may be a little premature. I was hoping we would have "feedback" on the dts scheme from a larger K8 system available before we made any more changes, but it seems the time is now. Maybe I should just not be afraid to change it back and forth a few times? //Peter From uwe at hermann-uwe.de Wed May 7 15:27:03 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 7 May 2008 15:27:03 +0200 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <13426df10805062050x1fd7330dr588d2524ab2d8caf@mail.gmail.com> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> <4820FAF0.2040207@gmx.net> <20080507015513.32577.qmail@stuge.se> <13426df10805062050x1fd7330dr588d2524ab2d8caf@mail.gmail.com> Message-ID: <20080507132703.GA17343@greenwood> On Tue, May 06, 2008 at 08:50:46PM -0700, ron minnich wrote: > On Tue, May 6, 2008 at 6:55 PM, Peter Stuge wrote: > > > This makes more sense, but.. > > > > What was the reason for introducing multiple dts files for a single > > chip again? > > > > Only the C struct name limitations? > > > > *scratches forehead* I kind of want the single dts per chip back.. > > > > yep, me too. that's a concern. Also, I worry about people having to > deal with the nasty little thicket of tons of little file, all > (mostly) alike. Full ACK. One dts per chip, one per board. Many small files is not the way to go, we worked hard in the past to reduce this cluttering, and rightly so. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From remenic at gmail.com Wed May 7 15:28:53 2008 From: remenic at gmail.com (Richard Stellingwerff) Date: Wed, 7 May 2008 15:28:53 +0200 Subject: [coreboot] Unable to flash Pm49FL004 Message-ID: <3aef9cce0805070628r27ac0af1yf4a7b28765f40472@mail.gmail.com> Hi all, I finally got myself a PLCC extractor so I can start getting coreboot to work on my Jetway J7F4K1G2E-PB board. However, I'm already running into a problem trying to write the original bios on the Pm49FL004. Extracting the BIOS from the original ROM works fine, but trying to write it into the new chip (after hot-swapping them) results in this: # flashrom -wv backup.bin Calibrating delay loop... OK. No coreboot table found. Found chipset "VIA VT8237", enabling flash write... OK. Pm49FL004 found at physical address 0xfff80000. Flash part is Pm49FL004 (512 KB). === This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE Please email a report to flashrom at coreboot.org if any of the above operations work correctly for you with this flash part. Please include the full output from the program, including chipset found. Thank you for your help! === Flash image seems to be a legacy BIOS. Disabling checks. Programming page: 0007 at address: 0x00070000 Verifying flash... FAILED! Reading from the Pm49FL004 returns all FF's (checked with hexedit). I compiled flashrom myself from SVN a few minutes ago. Anyone know what I can do? Kind regards, Richard Stellingwerff. From rminnich at gmail.com Wed May 7 15:54:14 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 7 May 2008 06:54:14 -0700 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <20080507121113.11509.qmail@stuge.se> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> <20080507121113.11509.qmail@stuge.se> Message-ID: <13426df10805070654h584dcec0t11dc68c463c27a40@mail.gmail.com> On Wed, May 7, 2008 at 5:11 AM, Peter Stuge wrote: > Is 15 really determined by the mainboard by the way - it should _not_ > be in the mainboard dts otherwise. on most boards it is. But, at the time time, the 15.2 for IDE is determined entirely by the chip. I should not have to say that ide is f.2 -- it's not really a seperate part. So how do we do this? ron From rminnich at gmail.com Wed May 7 15:55:04 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 7 May 2008 06:55:04 -0700 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <1210147443.5011.5.camel@martr-gentoo.artec> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> <4820FAF0.2040207@gmx.net> <1210147443.5011.5.camel@martr-gentoo.artec> Message-ID: <13426df10805070655p138328d1j4fea2a22510b89ab@mail.gmail.com> On Wed, May 7, 2008 at 1:04 AM, Mart Raudsepp > Just removing enable_ide as in southbridge/cs5536 would be better in my > opinion. DBE62 uses NAND not any IDE, so I was actually intending to > send a patch that sets enable_ide to 0, but now I saw this. why is that an issue? The default value is 0. ron From Marc.Karasek at Sun.COM Wed May 7 16:01:43 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Wed, 07 May 2008 10:01:43 -0400 Subject: [coreboot] Multiple emails In-Reply-To: References: <4820CB90.5030806@sun.com> Message-ID: <4821B647.3040207@sun.com> No I am seeing like 4 emails all dups of each other for each posting... ********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 ********************* Joe wrote: > Yeh, I get them when someone replies to an email I sent. I get 1 from > coreboot and 1 from the sender, ah the mysteries of email... > > Thanks, > Joseph Smith > Set-Top-Linux > www.settoplinux.org > >> -----Original Message----- >> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] >> On Behalf Of Marc Karasek >> Sent: Tuesday, May 06, 2008 5:20 PM >> To: coreboot at coreboot.org >> Subject: [coreboot] Multiple emails >> >> Is anyone else seeing multiple email messages from the list? >> >> -- >> ********************* >> Marc Karasek >> MTS >> Sun Microsystems >> mailto:marc.karasek at sun.com >> ph:770.360.6415 >> ********************* >> >> >> -- >> coreboot mailing list >> coreboot at coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot >> > > From rminnich at gmail.com Wed May 7 16:22:07 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 7 May 2008 07:22:07 -0700 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <4820FAF0.2040207@gmx.net> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> <4820FAF0.2040207@gmx.net> Message-ID: <13426df10805070722s353852ebq20853c59b3c0034b@mail.gmail.com> OK, if stepan Acks this patch of Carl-Daniel, I think I will ack it too. So, conditional on stepan, Acked-by: Ronald G. Minnich overall, it's the best idea I've seen. ron From peter at stuge.se Wed May 7 16:26:22 2008 From: peter at stuge.se (Peter Stuge) Date: Wed, 7 May 2008 16:26:22 +0200 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <13426df10805070722s353852ebq20853c59b3c0034b@mail.gmail.com> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> <4820FAF0.2040207@gmx.net> <13426df10805070722s353852ebq20853c59b3c0034b@mail.gmail.com> Message-ID: <20080507142622.20021.qmail@stuge.se> On Wed, May 07, 2008 at 07:22:07AM -0700, ron minnich wrote: > OK, if stepan Acks this patch of Carl-Daniel, I think I will ack it too. > > So, conditional on stepan, > Acked-by: Ronald G. Minnich > > overall, it's the best idea I've seen. Short-term, yes, but I think we need to figure this out. //Peter From Marc.Karasek at Sun.COM Wed May 7 17:07:28 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Wed, 07 May 2008 11:07:28 -0400 Subject: [coreboot] Multiple emails In-Reply-To: <4821B647.3040207@sun.com> References: <4820CB90.5030806@sun.com> <4821B647.3040207@sun.com> Message-ID: <4821C5B0.4020703@sun.com> Correction 2 emails for each posting. I have checked my status in the mailinglist and it shows me as only having one subscription. Very strange.............. ********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 ********************* Marc Karasek wrote: > No I am seeing like 4 emails all dups of each other for each posting... > > ********************* > Marc Karasek > MTS > Sun Microsystems > mailto:marc.karasek at sun.com > ph:770.360.6415 > ********************* > > > > Joe wrote: > >> Yeh, I get them when someone replies to an email I sent. I get 1 from >> coreboot and 1 from the sender, ah the mysteries of email... >> >> Thanks, >> Joseph Smith >> Set-Top-Linux >> www.settoplinux.org >> >> >>> -----Original Message----- >>> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] >>> On Behalf Of Marc Karasek >>> Sent: Tuesday, May 06, 2008 5:20 PM >>> To: coreboot at coreboot.org >>> Subject: [coreboot] Multiple emails >>> >>> Is anyone else seeing multiple email messages from the list? >>> >>> -- >>> ********************* >>> Marc Karasek >>> MTS >>> Sun Microsystems >>> mailto:marc.karasek at sun.com >>> ph:770.360.6415 >>> ********************* >>> >>> >>> -- >>> coreboot mailing list >>> coreboot at coreboot.org >>> http://www.coreboot.org/mailman/listinfo/coreboot >>> >>> >> >> > > From mylesgw at gmail.com Wed May 7 17:10:01 2008 From: mylesgw at gmail.com (Myles Watson) Date: Wed, 7 May 2008 09:10:01 -0600 Subject: [coreboot] Outstanding patches In-Reply-To: <20080506201056.GB21256@cosmic.amd.com> References: <20080506201008.GA21256@cosmic.amd.com> <20080506201056.GB21256@cosmic.amd.com> Message-ID: <2831fecf0805070810u3b0f4b0fyfa8e9e6d17c65d9f@mail.gmail.com> On Tue, May 6, 2008 at 2:10 PM, Jordan Crouse wrote: > > libpayload LAR patch: > > I will repost this one with changes from Peter > > As promised. With the typo correction. The lar browser is nice! Acked-by: Myles Watson Thanks, Myles From rminnich at gmail.com Wed May 7 17:17:25 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 7 May 2008 08:17:25 -0700 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <20080507142622.20021.qmail@stuge.se> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> <4820FAF0.2040207@gmx.net> <13426df10805070722s353852ebq20853c59b3c0034b@mail.gmail.com> <20080507142622.20021.qmail@stuge.se> Message-ID: <13426df10805070817x301c0c80je7fedb2676c54dbd@mail.gmail.com> On Wed, May 7, 2008 at 7:26 AM, Peter Stuge wrote: > Short-term, yes, but I think we need to figure this out. Agree. But I'm a big believer in breadboards. See PIke's comments on this sort of thing -- I agree with him. We can design all we want, but, until we write code, it's not clear we got it right. Speaking of which -- what did we do w.r.t. SELF? ron From viswesh_vichu at yahoo.com Wed May 7 17:44:28 2008 From: viswesh_vichu at yahoo.com (Viswesh S) Date: Wed, 7 May 2008 08:44:28 -0700 (PDT) Subject: [coreboot] AMDk8 - HT routing Message-ID: <701354.82433.qm@web31608.mail.mud.yahoo.com> Hi, I am looking into the Linux bios code for AMD 64 boards. In the setup_coherent_ht_domain function, we have functions setup_smp() and setup_smp2(). In the setup_smp2(), say the link1 is coherent and connected, we write the routing table for it, but then we veriify the connection for Node7 and then try to set the routing table registers for the link between 7 and 1. //* print_linkn("(0,1) link=", byte); setup_row_direct(0,1, byte); // setup_temp_row(0, 1); verify_connection(7); /* We found 2 nodes so far */ val = pci_read_config32(NODE_HT(7), 0x6c); byte = (val>>2) & 0x3; /*get default link on node7 to node0*/ print_linkn("(1,0) link=", byte); setup_row_local(7,1); setup_remote_row_direct(1, 0, byte); *// What is the logic reason behind checking the node7 here. In the case of my board, there is no Node7 itself and will the pci_write(outb instruction) cause any unknown behaviour, as the node is not present. Thanks, Viswesh Bollywood, fun, friendship, sports and more. You name it, we have it on http://in.promos.yahoo.com/groups/bestofyahoo/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.jones at amd.com Wed May 7 18:08:13 2008 From: marc.jones at amd.com (Marc Jones) Date: Wed, 07 May 2008 10:08:13 -0600 Subject: [coreboot] AMDk8 - HT routing In-Reply-To: <701354.82433.qm@web31608.mail.mud.yahoo.com> References: <701354.82433.qm@web31608.mail.mud.yahoo.com> Message-ID: <4821D3ED.5030305@amd.com> Viswesh S wrote: > Hi, > > I am looking into the Linux bios code for AMD 64 boards. > > In the setup_coherent_ht_domain function, we have functions > setup_smp() and setup_smp2(). > > In the setup_smp2(), say the link1 is coherent and connected, we write > the routing table for it, but then we veriify the connection for Node7 > and then try to set the routing table registers for the link between 7 > and 1. > > //* > print_linkn("(0,1) link=", byte); > setup_row_direct(0,1, byte); // > setup_temp_row(0, 1); > > verify_connection(7); > /* We found 2 nodes so far */ > val = pci_read_config32(NODE_HT(7), 0x6c); > byte = (val>>2) & 0x3; /*get default link on node7 to node0*/ > print_linkn("(1,0) link=", byte); > setup_row_local(7,1); > setup_remote_row_direct(1, 0, byte); > *// > > What is the logic reason behind checking the node7 here. > > In the case of my board, there is no Node7 itself and will the > pci_write(outb instruction) cause any unknown behaviour, as the node > is not present. > > Thanks, > > Viswesh > > ------------------------------------------------------------------------ > Explore your hobbies and interests. Click here to begin. > Hi Viswesh, All AP nodes are node7 until they have been found and initialized by the BSP. The BSP looks at each active link and then sets the nodeids. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From viswesh_vichu at yahoo.com Wed May 7 18:12:50 2008 From: viswesh_vichu at yahoo.com (Viswesh S) Date: Wed, 7 May 2008 09:12:50 -0700 (PDT) Subject: [coreboot] AMDk8 - HT routing Message-ID: <466534.53980.qm@web31603.mail.mud.yahoo.com> Hi, But when you read the registers of Node7, as the device is not there, what value will it return, if we try to read any register, say 0x6c for getting the default link. val = pci_read_config32(NODE_HT(7), 0x6c); // What value does get return, as node7 is not there. byte = (val>>2) & 0x3; /*get default link on node7 to node0*/ Viswesh ----- Original Message ---- From: Marc Jones To: Viswesh S Cc: coreboot at coreboot.org Sent: Wednesday, 7 May, 2008 9:38:13 PM Subject: Re: [coreboot] AMDk8 - HT routing Viswesh S wrote: > Hi, > > I am looking into the Linux bios code for AMD 64 boards. > > In the setup_coherent_ht_domain function, we have functions > setup_smp() and setup_smp2(). > > In the setup_smp2(), say the link1 is coherent and connected, we write > the routing table for it, but then we veriify the connection for Node7 > and then try to set the routing table registers for the link between 7 > and 1. > > //* > print_linkn("(0,1) link=", byte); > setup_row_direct(0,1, byte); // > setup_temp_row(0, 1); > > verify_connection(7); > /* We found 2 nodes so far */ > val = pci_read_config32(NODE_HT(7), 0x6c); > byte = (val>>2) & 0x3; /*get default link on node7 to node0*/ > print_linkn("(1,0) link=", byte); > setup_row_local(7,1); > setup_remote_row_direct(1, 0, byte); > *// > > What is the logic reason behind checking the node7 here. > > In the case of my board, there is no Node7 itself and will the > pci_write(outb instruction) cause any unknown behaviour, as the node > is not present. > > Thanks, > > Viswesh > > ------------------------------------------------------------------------ > Explore your hobbies and interests. Click here to begin. > Hi Viswesh, All AP nodes are node7 until they have been found and initialized by the BSP. The BSP looks at each active link and then sets the nodeids. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mart.raudsepp at artecdesign.ee Wed May 7 18:20:38 2008 From: mart.raudsepp at artecdesign.ee (Mart Raudsepp) Date: Wed, 7 May 2008 19:20:38 +0300 (EEST) Subject: [coreboot] patch: two bugs in the cs5536 ide code Message-ID: <34246.62.65.221.151.1210177238.squirrel@www.artecdesign.ee> > On Wed, May 7, 2008 at 1:04 AM, Mart Raudsepp >> Just removing enable_ide as in southbridge/cs5536 would be better in my >> opinion. DBE62 uses NAND not any IDE, so I was actually intending to >> send a patch that sets enable_ide to 0, but now I saw this. > > why is that an issue? The default value is 0. > > ron DBE62's own dts currently sets it to 1. Carl-Daniel's patch (original at least) moves that to a separate block - I'm just saying that instead it should be dropped, as it should be really 0, so the default will kick in and no unwanted IDE setup would happen. Mart Raudsepp From joe at settoplinux.org Wed May 7 18:39:46 2008 From: joe at settoplinux.org (Joe) Date: Wed, 07 May 2008 12:39:46 -0400 Subject: [coreboot] Multiple emails In-Reply-To: <4821C5B0.4020703@sun.com> References: <4820CB90.5030806@sun.com> <4821B647.3040207@sun.com> <4821C5B0.4020703@sun.com> Message-ID: <0b7156ad7e093dfd09e064c9e80c0d15@imap.1and1.com> I have this set to "off" but still double emails... Avoid duplicate copies of messages? When you are listed explicitly in the To: or Cc: headers of a list message, you can opt to not receive another copy from the mailing list. Select Yes to avoid receiving copies from the mailing list; select No to receive copies. If the list has member personalized messages enabled, and you elect to receive copies, every copy will have a X-Mailman-Copy: yes header added to it. -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org On Wed, 07 May 2008 11:07:28 -0400, Marc Karasek wrote: > Correction 2 emails for each posting. I have checked my status in the > mailinglist and it shows me as only having one subscription. > > Very strange.............. > > ********************* > Marc Karasek > MTS > Sun Microsystems > mailto:marc.karasek at sun.com > ph:770.360.6415 > ********************* > > > > Marc Karasek wrote: >> No I am seeing like 4 emails all dups of each other for each posting... >> >> ********************* >> Marc Karasek >> MTS >> Sun Microsystems >> mailto:marc.karasek at sun.com >> ph:770.360.6415 >> ********************* >> >> >> >> Joe wrote: >> >>> Yeh, I get them when someone replies to an email I sent. I get 1 from >>> coreboot and 1 from the sender, ah the mysteries of email... >>> >>> Thanks, >>> Joseph Smith >>> Set-Top-Linux >>> www.settoplinux.org >>> >>> >>>> -----Original Message----- >>>> From: coreboot-bounces at coreboot.org > [mailto:coreboot-bounces at coreboot.org] >>>> On Behalf Of Marc Karasek >>>> Sent: Tuesday, May 06, 2008 5:20 PM >>>> To: coreboot at coreboot.org >>>> Subject: [coreboot] Multiple emails >>>> >>>> Is anyone else seeing multiple email messages from the list? >>>> From corey.osgood at gmail.com Wed May 7 19:15:58 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Wed, 7 May 2008 13:15:58 -0400 Subject: [coreboot] Unable to flash Pm49FL004 In-Reply-To: <3aef9cce0805070628r27ac0af1yf4a7b28765f40472@mail.gmail.com> References: <3aef9cce0805070628r27ac0af1yf4a7b28765f40472@mail.gmail.com> Message-ID: Check in the factory BIOS that BIOS write protect is set to off. If there is no such option, then you might have to do some work to turn the BIOS write protection off. Check the flashrom board enables for other vt8237r-based boards (epia cn, etc) for hints. -Corey On Wed, May 7, 2008 at 9:28 AM, Richard Stellingwerff wrote: > Hi all, > > I finally got myself a PLCC extractor so I can start getting coreboot > to work on my Jetway J7F4K1G2E-PB board. However, I'm already running > into a problem trying to write the original bios on the Pm49FL004. > Extracting the BIOS from the original ROM works fine, but trying to > write it into the new chip (after hot-swapping them) results in this: > > # flashrom -wv backup.bin > Calibrating delay loop... OK. > No coreboot table found. > Found chipset "VIA VT8237", enabling flash write... OK. > Pm49FL004 found at physical address 0xfff80000. > Flash part is Pm49FL004 (512 KB). > === > This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE > Please email a report to flashrom at coreboot.org if any of the above > operations > work correctly for you with this flash part. Please include the full > output > from the program, including chipset found. Thank you for your help! > === > Flash image seems to be a legacy BIOS. Disabling checks. > Programming page: 0007 at address: 0x00070000 > Verifying flash... FAILED! > > Reading from the Pm49FL004 returns all FF's (checked with hexedit). > > I compiled flashrom myself from SVN a few minutes ago. > > Anyone know what I can do? > > Kind regards, > Richard Stellingwerff. > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rms at gnu.org Wed May 7 19:35:05 2008 From: rms at gnu.org (Richard M Stallman) Date: Wed, 07 May 2008 13:35:05 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <1EEE12BD90C44A59A82FE7237DA622F9@smitty2m> (joe@settoplinux.org) References: <4820EA9D.6040204@gmx.net> <1EEE12BD90C44A59A82FE7237DA622F9@smitty2m> Message-ID: I agree with Carl-Daniel here, we should focus on the positive not the negative. Publishing anything about Intel's stubbornness would probably come back to bite us in the ass one day. Karma, what you give, will always come back. It may not be tomorrow but someday it will come back. Being good is not the same as being nice; if there is anything valid about the concept of karma, resisting Intel would give you good karma. Anyway, I will cooperate with whatever you decide. If and when you want me to write to a journalist, please let me know. From mylesgw at gmail.com Wed May 7 21:15:17 2008 From: mylesgw at gmail.com (Myles Watson) Date: Wed, 7 May 2008 13:15:17 -0600 Subject: [coreboot] Fix custom configuration strings Message-ID: <2831fecf0805071215u60a0b020m6621ebf6427bd188@mail.gmail.com> This patch fixes a typo in config/payloads/payloads.conf so that the value of PAYLOAD-y gets put into custom config strings, not the string PAYLOAD-y. It borders on trivial. Thanks, Myles Signed-off-by: Myles Watson -------------- next part -------------- A non-text attachment was scrubbed... Name: buildrom_payload.diff Type: text/x-patch Size: 431 bytes Desc: not available URL: From jordan.crouse at amd.com Wed May 7 21:22:36 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 7 May 2008 13:22:36 -0600 Subject: [coreboot] Fix custom configuration strings In-Reply-To: <2831fecf0805071215u60a0b020m6621ebf6427bd188@mail.gmail.com> References: <2831fecf0805071215u60a0b020m6621ebf6427bd188@mail.gmail.com> Message-ID: <20080507192236.GB2564@cosmic.amd.com> On 07/05/08 13:15 -0600, Myles Watson wrote: > This patch fixes a typo in config/payloads/payloads.conf so that the > value of PAYLOAD-y gets put into custom config strings, not the string > PAYLOAD-y. It borders on trivial. > > Thanks, > Myles > > Signed-off-by: Myles Watson Acked-by: Jordan Crouse This did qualify as trivial. > Index: config/payloads/payloads.conf > =================================================================== > --- config/payloads/payloads.conf (revision 186) > +++ config/payloads/payloads.conf (working copy) > @@ -30,7 +30,7 @@ > PAYLOAD-$(CONFIG_PAYLOAD_GRUB2) = grub2 > > # This is for custom configuration strings > -PAYLOAD=PAYLOAD-y > +PAYLOAD:=$(PAYLOAD-y) > > PCONF-y= generic.conf > PCONF-$(CONFIG_PAYLOAD_COREINFO) = libpayload-dep.conf > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From svn at coreboot.org Wed May 7 21:21:19 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Wed, 7 May 2008 21:21:19 +0200 Subject: [coreboot] r3287 - trunk/coreboot-v2/util/lbtdump Message-ID: Author: eswierk Date: 2008-05-07 21:21:18 +0200 (Wed, 07 May 2008) New Revision: 3287 Modified: trunk/coreboot-v2/util/lbtdump/lbtdump.c Log: Fix a typo in lbtdump output (trivial). Signed-off-by: Ed Swierk Acked-by: Ed Swierk Modified: trunk/coreboot-v2/util/lbtdump/lbtdump.c =================================================================== --- trunk/coreboot-v2/util/lbtdump/lbtdump.c 2008-05-06 22:15:31 UTC (rev 3286) +++ trunk/coreboot-v2/util/lbtdump/lbtdump.c 2008-05-07 19:21:18 UTC (rev 3287) @@ -72,7 +72,7 @@ struct lb_record *recs = (struct lb_record *)(((char*)base) + addr + sizeof(*head)); if (memcmp(head->signature, "LBIO", 4) != 0) continue; - fprintf(stdout, "Found canidate at: %08lx-%08lx\n", + fprintf(stdout, "Found candidate at: %08lx-%08lx\n", addr, addr + head->table_bytes); if (head->header_bytes != sizeof(*head)) { fprintf(stderr, "Header bytes of %d are incorrect\n", From svn at coreboot.org Wed May 7 21:24:04 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Wed, 7 May 2008 21:24:04 +0200 Subject: [coreboot] r187 - buildrom-devel/config/payloads Message-ID: Author: myles Date: 2008-05-07 21:24:04 +0200 (Wed, 07 May 2008) New Revision: 187 Modified: buildrom-devel/config/payloads/payloads.conf Log: This is a trivial patch which fixes a typo from a recent checkin. It assigns the value of PAYLOAD-y to PAYLOAD for custom configuration strings. Signed-off-by: Myles Watson Acked-by: Jordan Crouse Modified: buildrom-devel/config/payloads/payloads.conf =================================================================== --- buildrom-devel/config/payloads/payloads.conf 2008-05-06 15:43:16 UTC (rev 186) +++ buildrom-devel/config/payloads/payloads.conf 2008-05-07 19:24:04 UTC (rev 187) @@ -30,7 +30,7 @@ PAYLOAD-$(CONFIG_PAYLOAD_GRUB2) = grub2 # This is for custom configuration strings -PAYLOAD=PAYLOAD-y +PAYLOAD:=$(PAYLOAD-y) PCONF-y= generic.conf PCONF-$(CONFIG_PAYLOAD_COREINFO) = libpayload-dep.conf From mylesgw at gmail.com Wed May 7 21:25:24 2008 From: mylesgw at gmail.com (Myles Watson) Date: Wed, 7 May 2008 13:25:24 -0600 Subject: [coreboot] Fix custom configuration strings In-Reply-To: <20080507192236.GB2564@cosmic.amd.com> References: <2831fecf0805071215u60a0b020m6621ebf6427bd188@mail.gmail.com> <20080507192236.GB2564@cosmic.amd.com> Message-ID: <2831fecf0805071225w4f761b40x31dc1aa76fc4a829@mail.gmail.com> On Wed, May 7, 2008 at 1:22 PM, Jordan Crouse wrote: > > On 07/05/08 13:15 -0600, Myles Watson wrote: > > This patch fixes a typo in config/payloads/payloads.conf so that the > > value of PAYLOAD-y gets put into custom config strings, not the string > > PAYLOAD-y. It borders on trivial. > > > > Thanks, > > Myles > > > > Signed-off-by: Myles Watson > Acked-by: Jordan Crouse Rev 187 > This did qualify as trivial. Thanks, Myles From Ken.Fuchs at bench.com Wed May 7 21:54:43 2008 From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com) Date: Wed, 7 May 2008 14:54:43 -0500 Subject: [coreboot] [RFC] Porting coreboot to Intel Atom (Silverthorne) & SCH US15W (Poulsbo) chipset In-Reply-To: <481DD1CF.8090101@gmx.net> Message-ID: > Ken Fuchs wrote: > > Any suggestions and comments are welcome. > > Thanks Carl-Daniel for your opinions on porting coreboot to the Atom/Poulsbo, but I'd like to address your suggestion of AMD as alternative first. Carl-Daniel Hailfinger wrote: > My first suggestion would be to investigate if you can find a matching > platform from AMD. While Intel docs are difficult to get and sometimes > even wrong, AMD provides fast access to good documentation > and they even > employ a few excellent engineers who work on coreboot and > contribute all > of their code (they contributed Barcelona processor support > at the time > it became available commercially). > That's why I recommend AMD. > Besides that, saying "we chose AMD because of coreboot" helps > those nice > AMD guys to justify and strengthen the development effort they invest > into coreboot and everyone benefits. I really do like this suggestion for the reasons mentioned. I have also found that AMD is much easier to work with than Intel. When AMD sees a business opportunity they turn the information facet on full for you. With Intel, you seem to have to ask for each individual piece of information, leaving you wonder when the next drop (of information) will fall. Thanks for the great suggestion, but AMD doesn't seem to have a low power embedded "platform" like the Silverthorne/Poulsbo combo which uses only 5W maximum total at the highest clock for these parts. I understand that the Poulsbo is 2.7 W at all speeds and Atom ranges from 1.6 W to a maximum of 2.3 W based on clock speed of the part. One of the hardware engineers on our project claims that AMD doesn't have any processor using less than 30 W, but I couldn't believe that. I searched for an AMD processor with low wattage requirements, but the best I could find was this Sempron at 25 W (for just the processor). http://products.amd.com/en-us/NotebookCPUDetail.aspx?id=14 AMD must have processors with lower wattage requirements, right? Maybe some as yet unreleased product? Sincerely, Ken Fuchs From eswierk at arastra.com Wed May 7 21:55:24 2008 From: eswierk at arastra.com (Ed Swierk) Date: Wed, 7 May 2008 12:55:24 -0700 Subject: [coreboot] [PATCH] Implement GPIO configuration options for Intel 3100 southbridge Message-ID: When I originally ported the GPIO configuration routines for the Intel 3100 southbridge from esb6300_lpc.c, I left out the code that lets you specify per-mainboard GPIO settings. This patch implements those configuration routines, so you can put something like register "gpio[23]" = "I3100_GPIO_USE_AS_GPIO | I3100_GPIO_SEL_OUTPUT | I3100_GPIO_LVL_LOW" in Config.lb to set GPIO 23 as an output, driving the signal low. Signed-off-by: Ed Swierk -------------- next part -------------- A non-text attachment was scrubbed... Name: intel-3100-gpio-config.patch Type: text/x-patch Size: 3839 bytes Desc: not available URL: From peter at stuge.se Wed May 7 22:01:08 2008 From: peter at stuge.se (Peter Stuge) Date: Wed, 7 May 2008 22:01:08 +0200 Subject: [coreboot] [RFC] Porting coreboot to Intel Atom (Silverthorne) & SCH US15W (Poulsbo) chipset In-Reply-To: References: <481DD1CF.8090101@gmx.net> Message-ID: <20080507200108.19995.qmail@stuge.se> On Wed, May 07, 2008 at 02:54:43PM -0500, Ken.Fuchs at bench.com wrote: > One of the hardware engineers on our project claims that AMD doesn't > have any processor using less than 30 W, but I couldn't believe that. > I searched for an AMD processor with low wattage requirements, but the > best I could find was this Sempron at 25 W (for just the processor). > > http://products.amd.com/en-us/NotebookCPUDetail.aspx?id=14 > > AMD must have processors with lower wattage requirements, right? I don't know what frequency you want, but I suppose the Geode LX could contend regarding power consumption? //Peter From Marc.Jones at amd.com Wed May 7 22:11:03 2008 From: Marc.Jones at amd.com (Marc Jones) Date: Wed, 07 May 2008 14:11:03 -0600 Subject: [coreboot] [RFC] Porting coreboot to Intel Atom (Silverthorne) & SCH US15W (Poulsbo) chipset In-Reply-To: <20080507200108.19995.qmail@stuge.se> References: <481DD1CF.8090101@gmx.net> <20080507200108.19995.qmail@stuge.se> Message-ID: <48220CD7.70208@amd.com> Peter Stuge wrote: > On Wed, May 07, 2008 at 02:54:43PM -0500, Ken.Fuchs at bench.com wrote: >> One of the hardware engineers on our project claims that AMD doesn't >> have any processor using less than 30 W, but I couldn't believe that. >> I searched for an AMD processor with low wattage requirements, but the >> best I could find was this Sempron at 25 W (for just the processor). >> >> http://products.amd.com/en-us/NotebookCPUDetail.aspx?id=14 >> >> AMD must have processors with lower wattage requirements, right? > > I don't know what frequency you want, but I suppose the Geode LX > could contend regarding power consumption? Peter is correct. Depending on the performance envelope, Geode LX might fit your needs. Check out the embedded website. http://www.amd.com/embedded Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From jordan.crouse at amd.com Wed May 7 22:25:06 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 7 May 2008 14:25:06 -0600 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <13426df10805070817x301c0c80je7fedb2676c54dbd@mail.gmail.com> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> <4820FAF0.2040207@gmx.net> <13426df10805070722s353852ebq20853c59b3c0034b@mail.gmail.com> <20080507142622.20021.qmail@stuge.se> <13426df10805070817x301c0c80je7fedb2676c54dbd@mail.gmail.com> Message-ID: <20080507202506.GC2564@cosmic.amd.com> On 07/05/08 08:17 -0700, ron minnich wrote: > On Wed, May 7, 2008 at 7:26 AM, Peter Stuge wrote: > > > Short-term, yes, but I think we need to figure this out. > > > Agree. But I'm a big believer in breadboards. See PIke's comments on > this sort of thing -- I agree with him. > > We can design all we want, but, until we write code, it's not clear we > got it right. > > Speaking of which -- what did we do w.r.t. SELF? Still open for debate. I'm going to start coding it up for libpayload so I can get moving on the chooser, but I dare not touch coreboot until we get a consensus. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From svn at coreboot.org Wed May 7 22:34:03 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Wed, 7 May 2008 22:34:03 +0200 Subject: [coreboot] r3288 - in trunk/payloads/libpayload: include include/arch libc Message-ID: Author: jcrouse Date: 2008-05-07 22:34:02 +0200 (Wed, 07 May 2008) New Revision: 3288 Added: trunk/payloads/libpayload/include/arch/endian.h trunk/payloads/libpayload/include/lar.h trunk/payloads/libpayload/libc/lar.c Modified: trunk/payloads/libpayload/include/libpayload.h trunk/payloads/libpayload/libc/Makefile.inc Log: libpayload: Add LAR walking support Add suport for walking LARs. These try to emulate the f* functions from POSIX, though they are obviously different in their behavior. Signed-off-by: Jordan Crouse Acked-by: Myles Watson Added: trunk/payloads/libpayload/include/arch/endian.h =================================================================== --- trunk/payloads/libpayload/include/arch/endian.h (rev 0) +++ trunk/payloads/libpayload/include/arch/endian.h 2008-05-07 20:34:02 UTC (rev 3288) @@ -0,0 +1,46 @@ +/* + * This file is part of the libpayload project. + * + * Copyright (C) 2008 Advanced Micro Devices, Inc. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifndef _ARCH_ENDIAN_H +#define _ARCH_ENDIAN_H + +static u32 ntohl(u32 in) +{ + return ((in & 0xFF) << 24) | ((in & 0xFF00) << 8) | + ((in & 0xFF0000) >> 8) | ((in & 0xFF000000) >> 24); +} + +static u64 ntohll(u64 in) +{ + u32 h = in >> 32; + u32 l = in & 0xFFFFFFFF; + + return (((u64) ntohl(l) << 32) | ((u64) ntohl(h))); +} +#endif Added: trunk/payloads/libpayload/include/lar.h =================================================================== --- trunk/payloads/libpayload/include/lar.h (rev 0) +++ trunk/payloads/libpayload/include/lar.h 2008-05-07 20:34:02 UTC (rev 3288) @@ -0,0 +1,94 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2006 coresystems GmbH + * (Written by Stefan Reinauer for coresystems GmbH) + * + * This file is dual-licensed. You can choose between: + * - The GNU GPL, version 2, as published by the Free Software Foundation + * - The revised BSD license (without advertising clause) + * + * --------------------------------------------------------------------------- + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA + * --------------------------------------------------------------------------- + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * --------------------------------------------------------------------------- + */ + +#ifndef LAR_H +#define LAR_H + +#include + +#define LAR_MAGIC "LARCHIVE" +#define LAR_MAX_PATHLEN 1024 + +struct lar_header { + char magic[8]; + u32 len; + u32 reallen; + u32 checksum; + u32 compchecksum; + u32 offset; + /* Compression: + * 0 = no compression + * 1 = lzma + * 2 = nrv2b + * 3 = zeroes + */ + u32 compression; + u64 entry; + u64 loadaddress; +}; + +enum compalgo { + ALGO_NONE = 0, + ALGO_LZMA = 1, + ALGO_NRV2B = 2, + ALGO_ZEROES = 3, + /* invalid should always be the last entry. */ + ALGO_INVALID +}; + +struct mem_file { + void *start; + int len; + u32 reallen; + u32 compression; + void *entry; + void *loadaddress; +}; + +#endif /* LAR_H */ Modified: trunk/payloads/libpayload/include/libpayload.h =================================================================== --- trunk/payloads/libpayload/include/libpayload.h 2008-05-07 19:21:18 UTC (rev 3287) +++ trunk/payloads/libpayload/include/libpayload.h 2008-05-07 20:34:02 UTC (rev 3288) @@ -36,6 +36,7 @@ #include #include #include +#include #define MIN(a,b) ((a) < (b) ? (a) : (b)) #define MAX(a,b) ((a) > (b) ? (a) : (b)) @@ -207,6 +208,55 @@ int gettimeofday(struct timeval *tv, void *tz); +/* libc/lar.c */ + +struct LAR { + void * start; + int cindex; + int count; + int alloc; + int eof; + void **headers; +}; + +struct larent { + u8 name[LAR_MAX_PATHLEN]; +}; + +struct larstat { + u32 len; + u32 reallen; + u32 checksum; + u32 compchecksum; + u32 offset; + u32 compression; + u64 entry; + u64 loadaddress; +}; + +struct LFILE { + struct LAR *lar; + struct lar_header *header; + u32 size; + void *start; + u32 offset; +}; + +struct LAR *openlar(void *addr); +int closelar(struct LAR *lar); +struct larent *readlar(struct LAR *lar); +void rewindlar(struct LAR *lar); +int larstat(struct LAR *lar, const char *path, struct larstat *buf); +struct LFILE * lfopen(struct LAR *lar, const char *filename); +int lfread(void *ptr, size_t size, size_t nmemb, struct LFILE *stream); + +#define SEEK_SET 0 +#define SEEK_CUR 1 +#define SEEK_END 2 + +int lfseek(struct LFILE *stream, long offset, int whence); +int lfclose(struct LFILE *file); + /* i386/coreboot.c */ int get_coreboot_info(struct sysinfo_t *info); Modified: trunk/payloads/libpayload/libc/Makefile.inc =================================================================== --- trunk/payloads/libpayload/libc/Makefile.inc 2008-05-07 19:21:18 UTC (rev 3287) +++ trunk/payloads/libpayload/libc/Makefile.inc 2008-05-07 20:34:02 UTC (rev 3288) @@ -29,4 +29,4 @@ TARGETS-y += libc/malloc.o libc/printf.o libc/console.o libc/string.o TARGETS-y += libc/memory.o libc/ctype.o libc/ipchecksum.o libc/lib.o -TARGETS-y += libc/rand.o libc/time.o +TARGETS-y += libc/rand.o libc/time.o libc/lar.o Added: trunk/payloads/libpayload/libc/lar.c =================================================================== --- trunk/payloads/libpayload/libc/lar.c (rev 0) +++ trunk/payloads/libpayload/libc/lar.c 2008-05-07 20:34:02 UTC (rev 3288) @@ -0,0 +1,301 @@ +/* + * This file is part of the libpayload project. + * + * Copyright (C) 2008 Advanced Micro Devices, Inc. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +#include + +#define ROM_RESET_VECTOR 0xFFFFFFF0 + +static void * next_header(void * cur) +{ + struct lar_header *header = (struct lar_header *) cur; + int offset = ((ntohl(header->offset) + ntohl(header->len)) + 15) & + 0xFFFFFFF0; + + return (void *) (cur + offset); +} + +static struct lar_header *lar_get_header(struct LAR *lar, int index) +{ + int i; + + if (index < lar->count) + return (struct lar_header *) lar->headers[index]; + + if (lar->eof && index >= lar->eof) + return NULL; + + for(i = lar->count; i <= index; i++) { + void *next = (i == 0) ? + lar->start : next_header(lar->headers[i - 1]); + + if (strncmp((const char *) next, LAR_MAGIC, 8)) { + lar->eof = lar->count; + return NULL; + } + + if (lar->count == lar->alloc) { + void *tmp = realloc(lar->headers, + (lar->alloc + 16) * sizeof(void *)); + + if (tmp == NULL) + return NULL; + + lar->headers = tmp; + lar->alloc += 16; + } + + lar->headers[lar->count++] = next; + } + + return (struct lar_header *) lar->headers[index]; +} + + +/** + * Open a LAR stream + * + * @param addr The address in memory where the LAR is located. + * Use NULL to specify the boot LAR + * @return a pointer to the LAR stream + */ + +struct LAR *openlar(void *addr) +{ + struct LAR *lar; + + /* If the address is null, then figure out the start of the + boot LAR */ + + if (addr == NULL) { + u32 size = *((u32 *) (ROM_RESET_VECTOR + 4)); + addr = (void *) ((ROM_RESET_VECTOR + 16) - size); + } + + /* Check the magic to make sure this is a LAR */ + if (strncmp((const char *) addr, LAR_MAGIC, strlen(LAR_MAGIC))) + return NULL; + + lar = calloc(sizeof(struct LAR), 1); + + if (!lar) + return NULL; + + lar->start = addr; + + /* Preallocate 16 slots in the cache - this saves wear and + * tear on the heap */ + + lar->headers = malloc(16 * sizeof(void *)); + lar->alloc = 16; + lar->count = lar->eof = 0; + lar->cindex = 0; + + return lar; +} + +/** + * Close a LAR stream + * + * @param lar A pointer to the LAR stream + * @return Return 0 on success, -1 on error + */ + +int closelar(struct LAR *lar) +{ + if (!lar) + return 0; + + if (lar->headers) + free(lar->headers); + + free(lar); + + return 0; +} + +/** + * Read an entry from the LAR + * + * @param lar A pointer to the LAR stream + * @return A pointer to a larent structure + representing the next file in the LAR + */ + +struct larent *readlar(struct LAR *lar) +{ + static struct larent _larent; + struct lar_header *header; + int nlen; + + if (!lar) + return NULL; + + header = lar_get_header(lar, lar->cindex); + + if (header == NULL) + return NULL; + + nlen = ntohl(header->offset) - sizeof(*header); + + if (nlen > LAR_MAX_PATHLEN - 1) + nlen = LAR_MAX_PATHLEN - 1; + + memcpy((void *) _larent.name, ((char *) header + sizeof(*header)), + nlen); + + _larent.name[nlen] = 0; + + lar->cindex++; + + return (struct larent *) &_larent; +} + +void rewindlar(struct LAR *lar) +{ + if (lar != NULL) + lar->cindex = 0; +} + +static struct lar_header *get_header_by_name(struct LAR *lar, const char *name) +{ + struct lar_header *header; + int i; + + for(i = 0; ; i++) { + header = lar_get_header(lar, i); + + if (header == NULL) + return NULL; + + if (!strcmp(name, ((char *) header + sizeof(*header)))) + return header; + } +} + +int larstat(struct LAR *lar, const char *path, struct larstat *buf) +{ + struct lar_header *header = get_header_by_name(lar, path); + + if (header == NULL || buf == NULL) + return -1; + + buf->len = ntohl(header->len); + buf->reallen = ntohl(header->reallen); + buf->checksum = ntohl(header->checksum); + buf->compchecksum = ntohl(header->compchecksum); + buf->compression = ntohl(header->compression); + buf->entry = ntohll(header->entry); + buf->loadaddress = ntohll(header->loadaddress); + buf->offset = ((u32) header - (u32) lar->start) + ntohl(header->offset); + + return 0; +} + +struct LFILE * lfopen(struct LAR *lar, const char *filename) +{ + struct LFILE *file; + struct lar_header *header = get_header_by_name(lar, filename); + + if (header == NULL) + return NULL; + + /* FIXME: What other validations do we want to do on the file here? */ + + file = malloc(sizeof(struct LFILE)); + + if (file == NULL) + return NULL; + + file->lar = lar; + file->header = header; + file->size = ntohl(header->len); + file->start = ((u8 *) header + ntohl(header->offset)); + file->offset = 0; + + return file; +} + +void *lfmap(struct LFILE *file, int offset) +{ + if (file == NULL) + return (void *) -1; + + if (offset > file->size) + return (void *) -1; + + return (void *) (file->start + offset); +}; + +int lfread(void *ptr, size_t size, size_t nmemb, struct LFILE *stream) +{ + size_t tsize, actual; + size_t remain = stream->size - stream->offset; + + if (!stream || !remain) + return 0; + + tsize = (size * nmemb); + actual = (tsize > remain) ? remain : tsize; + + memcpy(ptr, (void *) (stream->start + stream->offset), actual); + stream->offset += actual; + + return actual; +} + +int lfseek(struct LFILE *file, long offset, int whence) +{ + int o = file->offset; + + switch(whence) { + case SEEK_SET: + o = offset; + break; + case SEEK_CUR: + o += offset; + break; + + case SEEK_END: + return -1; + } + + if (o < 0 || o > file->size) + return -1; + + file->offset = o; + return file->offset; +} + +int lfclose(struct LFILE *file) +{ + if (file) + free(file); + return 0; +} From jordan.crouse at amd.com Wed May 7 22:36:43 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 7 May 2008 14:36:43 -0600 Subject: [coreboot] Outstanding patches In-Reply-To: <2831fecf0805070810u3b0f4b0fyfa8e9e6d17c65d9f@mail.gmail.com> References: <20080506201008.GA21256@cosmic.amd.com> <20080506201056.GB21256@cosmic.amd.com> <2831fecf0805070810u3b0f4b0fyfa8e9e6d17c65d9f@mail.gmail.com> Message-ID: <20080507203643.GE2564@cosmic.amd.com> On 07/05/08 09:10 -0600, Myles Watson wrote: > On Tue, May 6, 2008 at 2:10 PM, Jordan Crouse wrote: > > > libpayload LAR patch: > > > I will repost this one with changes from Peter > > > > As promised. > > With the typo correction. > > The lar browser is nice! > > Acked-by: Myles Watson r3288. Thanks. -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From svn at coreboot.org Wed May 7 22:43:15 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Wed, 7 May 2008 22:43:15 +0200 Subject: [coreboot] r3289 - trunk/payloads/coreinfo Message-ID: Author: jcrouse Date: 2008-05-07 22:43:15 +0200 (Wed, 07 May 2008) New Revision: 3289 Added: trunk/payloads/coreinfo/lar_module.c Modified: trunk/payloads/coreinfo/Kconfig trunk/payloads/coreinfo/Makefile trunk/payloads/coreinfo/coreinfo.c Log: coreinfo: Add a module for browsing the boot LAR Signed-off-by: Jordan Crouse Acked-by: Peter Stuge Modified: trunk/payloads/coreinfo/Kconfig =================================================================== --- trunk/payloads/coreinfo/Kconfig 2008-05-07 20:34:02 UTC (rev 3288) +++ trunk/payloads/coreinfo/Kconfig 2008-05-07 20:43:15 UTC (rev 3289) @@ -68,5 +68,9 @@ bool "Enable the coreboot bootlog module" default y +config MODULE_LAR + bool "Enable the coreboot LAR module" + default y + endmenu Modified: trunk/payloads/coreinfo/Makefile =================================================================== --- trunk/payloads/coreinfo/Makefile 2008-05-07 20:34:02 UTC (rev 3288) +++ trunk/payloads/coreinfo/Makefile 2008-05-07 20:43:15 UTC (rev 3289) @@ -51,7 +51,7 @@ INCLUDES = -Ibuild CFLAGS := -Wall -Werror -Os $(INCLUDES) OBJECTS = cpuinfo_module.o cpuid.S.o pci_module.o coreboot_module.o \ - nvram_module.o bootlog_module.o coreinfo.o + nvram_module.o bootlog_module.o lar_module.o coreinfo.o OBJS = $(patsubst %,$(obj)/%,$(OBJECTS)) TARGET = $(obj)/coreinfo.elf Modified: trunk/payloads/coreinfo/coreinfo.c =================================================================== --- trunk/payloads/coreinfo/coreinfo.c 2008-05-07 20:34:02 UTC (rev 3288) +++ trunk/payloads/coreinfo/coreinfo.c 2008-05-07 20:43:15 UTC (rev 3289) @@ -27,6 +27,7 @@ extern struct coreinfo_module coreboot_module; extern struct coreinfo_module nvram_module; extern struct coreinfo_module bootlog_module; +extern struct coreinfo_module lar_module; struct coreinfo_module *system_modules[] = { #ifdef CONFIG_MODULE_CPUINFO @@ -47,6 +48,9 @@ #ifdef CONFIG_MODULE_BOOTLOG &bootlog_module, #endif +#ifdef CONFIG_MODULE_LAR + &lar_module +#endif }; struct coreinfo_cat { @@ -90,7 +94,7 @@ char menu[80]; char *ptr = menu; - wmove(stdscr, 22, 0); + wmove(stdscr, SCREEN_Y - 2, 0); for (j = 0; j < SCREEN_X; j++) waddch(stdscr, ' '); @@ -101,7 +105,7 @@ for (i = 0; i < cat->count; i++) ptr += sprintf(ptr, "[%c: %s] ", 'A' + i, cat->modules[i]->name); - mvprintw(22, 0, menu); + mvprintw(SCREEN_Y - 2, 0, menu); } #ifdef CONFIG_SHOW_DATE_TIME @@ -126,7 +130,7 @@ char menu[80]; char *ptr = menu; - wmove(stdscr, 23, 0); + wmove(stdscr, SCREEN_Y - 1, 0); for (j = 0; j < SCREEN_X; j++) waddch(stdscr, ' '); @@ -267,12 +271,12 @@ init_pair(2, COLOR_BLACK, COLOR_WHITE); init_pair(3, COLOR_WHITE, COLOR_WHITE); - modwin = newwin(22, 80, 1, 0); + modwin = newwin(SCREEN_Y-2, SCREEN_X, 1, 0); wattrset(stdscr, COLOR_PAIR(1) | A_BOLD); wattrset(modwin, COLOR_PAIR(2)); - for (i = 0; i < 23; i++) { + for (i = 0; i < SCREEN_Y - 1; i++) { wmove(modwin, i - 1, 0); for (j = 0; j < SCREEN_X; j++) Added: trunk/payloads/coreinfo/lar_module.c =================================================================== --- trunk/payloads/coreinfo/lar_module.c (rev 0) +++ trunk/payloads/coreinfo/lar_module.c 2008-05-07 20:43:15 UTC (rev 3289) @@ -0,0 +1,163 @@ +/* + * This file is part of the coreinfo project. + * + * Copyright (C) 2008 Advanced Micro Devices, Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include "coreinfo.h" + +#ifdef CONFIG_MODULE_LAR + +static struct LAR *lar; +static int lcount; +static char **lnames; + +static int lar_module_init(void) +{ + int index = 0; + struct larent *larent; + + lar = openlar(NULL); + + if (lar == NULL) + return 0; + + while((larent = readlar(lar))) + lcount++; + + lnames = malloc(lcount * sizeof(char *)); + + if (lnames == NULL) + return 0; + + rewindlar(lar); + + while((larent = readlar(lar))) + lnames[index++] = strdup((const char *) larent->name); + + return 0; +} + +static int selected; + +static int lar_module_redraw(WINDOW *win) +{ + int i; + int row = 2; + struct larstat stat; + + print_module_title(win, "LAR Listing"); + + if (lar == 0) { + mvwprintw(win, 11, 61/2, "Bad or missing LAR"); + return 0; + } + + /* Draw a line down the middle */ + + for(i = 2; i < 20; i++) { + wmove(win, i, 30); + waddch(win, '\263'); + } + + /* Draw the names down the left side */ + + for(i = 0; i < lcount; i++) { + if (i == selected) + wattrset(win, COLOR_PAIR(3) | A_BOLD); + else + wattrset(win, COLOR_PAIR(2)); + + mvwprintw(win, 2 + i, 1, "%.25s", lnames[i]); + } + + /* Get the information for the LAR */ + + if (larstat(lar, lnames[selected], &stat)) { + printf("larstat failed\n"); + return 0; + } + + wattrset(win, COLOR_PAIR(2)); + + mvwprintw(win, row++, 32, "Offset: 0x%x", stat.offset); + + if (stat.compression) { + switch(stat.compression) { + case ALGO_LZMA: + mvwprintw(win, row++, 32, "Compression: LZMA"); + break; + case ALGO_NRV2B: + mvwprintw(win, row++, 32, "Compression: NRV2B"); + break; + case ALGO_ZEROES: + mvwprintw(win, row++, 32, "Compression: zeroes"); + break; + } + + mvwprintw(win, row++, 32, "Compressed length: %d", stat.len); + mvwprintw(win, row++, 32, "Compressed checksum: 0x%x", stat.compchecksum); + } + + mvwprintw(win, row++, 32, "Length: %d", stat.reallen); + mvwprintw(win, row++, 32, "Checksum: 0x%x", stat.checksum); + mvwprintw(win, row++, 32, "Load Address: 0x%llx", stat.loadaddress); + mvwprintw(win, row++, 32, "Entry Point: 0x%llx", stat.entry); + + return 0; +} + +static int lar_module_handle(int key) +{ + int ret = 0; + + if (lar == NULL) + return 0; + + switch (key) { + case KEY_DOWN: + if (selected + 1 < lcount) { + selected++; + ret = 1; + } + break; + case KEY_UP: + if (selected > 0) { + selected--; + ret = 1; + } + break; + } + + return ret; +} + +struct coreinfo_module lar_module = { + .name = "LAR", + .init = lar_module_init, + .redraw = lar_module_redraw, + .handle = lar_module_handle +}; +#else + +struct coreinfo_module lar_module = { +}; + +#endif + + + + From jordan.crouse at amd.com Wed May 7 22:46:29 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 7 May 2008 14:46:29 -0600 Subject: [coreboot] coreinfo: Add a module for browsing the boot LAR In-Reply-To: <20080425233612.26796.qmail@stuge.se> References: <20080425232524.GG19092@cosmic.amd.com> <20080425233612.26796.qmail@stuge.se> Message-ID: <20080507204629.GF2564@cosmic.amd.com> On 26/04/08 01:36 +0200, Peter Stuge wrote: > On Fri, Apr 25, 2008 at 05:25:24PM -0600, Jordan Crouse wrote: > > coreinfo: Add a module for browsing the boot LAR > > > > Signed-off-by: Jordan Crouse > > Acked-by: Peter Stuge r3289. Thanks. My coreinfo queue is empty. :) Jordan From remenic at gmail.com Wed May 7 22:45:40 2008 From: remenic at gmail.com (Richard Stellingwerff) Date: Wed, 7 May 2008 22:45:40 +0200 Subject: [coreboot] Unable to flash Pm49FL004 In-Reply-To: References: <3aef9cce0805070628r27ac0af1yf4a7b28765f40472@mail.gmail.com> Message-ID: <3aef9cce0805071345r340d42bdr2a3678c478a4e84f@mail.gmail.com> Okay I feel like an idiot right now. Flash write protect was indeed enabled in the BIOS. It works great now that I've disabled it. Thanks :) Kind regards, Richard. On Wed, May 7, 2008 at 7:15 PM, Corey Osgood wrote: > Check in the factory BIOS that BIOS write protect is set to off. If there is > no such option, then you might have to do some work to turn the BIOS write > protection off. Check the flashrom board enables for other vt8237r-based > boards (epia cn, etc) for hints. > > -Corey > > > > On Wed, May 7, 2008 at 9:28 AM, Richard Stellingwerff > wrote: > > > > > > > > Hi all, > > > > I finally got myself a PLCC extractor so I can start getting coreboot > > to work on my Jetway J7F4K1G2E-PB board. However, I'm already running > > into a problem trying to write the original bios on the Pm49FL004. > > Extracting the BIOS from the original ROM works fine, but trying to > > write it into the new chip (after hot-swapping them) results in this: > > > > # flashrom -wv backup.bin > > Calibrating delay loop... OK. > > No coreboot table found. > > Found chipset "VIA VT8237", enabling flash write... OK. > > Pm49FL004 found at physical address 0xfff80000. > > Flash part is Pm49FL004 (512 KB). > > === > > This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE > > Please email a report to flashrom at coreboot.org if any of the above > operations > > work correctly for you with this flash part. Please include the full > output > > from the program, including chipset found. Thank you for your help! > > === > > Flash image seems to be a legacy BIOS. Disabling checks. > > Programming page: 0007 at address: 0x00070000 > > Verifying flash... FAILED! > > > > Reading from the Pm49FL004 returns all FF's (checked with hexedit). > > > > I compiled flashrom myself from SVN a few minutes ago. > > > > Anyone know what I can do? > > > > Kind regards, > > Richard Stellingwerff. > > > > -- > > coreboot mailing list > > coreboot at coreboot.org > > http://www.coreboot.org/mailman/listinfo/coreboot > > > > From svn at coreboot.org Wed May 7 22:54:49 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Wed, 7 May 2008 22:54:49 +0200 Subject: [coreboot] r188 - buildrom-devel/packages/busybox Message-ID: Author: myles Date: 2008-05-07 22:54:48 +0200 (Wed, 07 May 2008) New Revision: 188 Modified: buildrom-devel/packages/busybox/busybox.mk Log: This is a trivial patch which puts back a -P wget option that got deleted in Rev 171. Signed-off-by: Myles Watson Acked-by: Myles Watson Modified: buildrom-devel/packages/busybox/busybox.mk =================================================================== --- buildrom-devel/packages/busybox/busybox.mk 2008-05-07 19:24:04 UTC (rev 187) +++ buildrom-devel/packages/busybox/busybox.mk 2008-05-07 20:54:48 UTC (rev 188) @@ -26,7 +26,7 @@ $(SOURCE_DIR)/$(BUSYBOX_SOURCE): @ echo "Downloading busybox..." @ mkdir -p $(SOURCE_DIR) - @ wget $(WGET_Q) $(SOURCE_DIR) $(BUSYBOX_URL)/$(BUSYBOX_SOURCE) + @ wget $(WGET_Q) -P $(SOURCE_DIR) $(BUSYBOX_URL)/$(BUSYBOX_SOURCE) $(BUSYBOX_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(BUSYBOX_SOURCE) | $(BUSYBOX_STAMP_DIR) $(BUSYBOX_DIR) @ echo "Unpacking busybox..." From jordan.crouse at amd.com Wed May 7 22:59:32 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 7 May 2008 14:59:32 -0600 Subject: [coreboot] buildrom: Bump the revision for coreinfo & libpayload Message-ID: <20080507205932.GA8122@cosmic.amd.com> Bump the coreinfo & libpayload revisions - with this, we should be up to goodness. This also adjusts the default coreinfo config accordingly depending on the version of coreboot being used - this is so that v3 users can see the bootlog and LAR browsers in action. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: update-coreinfo-libpayload.patch Type: text/x-diff Size: 2978 bytes Desc: not available URL: From Marc.Jones at amd.com Wed May 7 23:09:52 2008 From: Marc.Jones at amd.com (Marc Jones) Date: Wed, 7 May 2008 15:09:52 -0600 Subject: [coreboot] AMDk8 - HT routing In-Reply-To: <466534.53980.qm@web31603.mail.mud.yahoo.com> References: <466534.53980.qm@web31603.mail.mud.yahoo.com> Message-ID: <48221AA0.8050904@amd.com> Viswesh S wrote: > Hi, > > > > But when you read the registers of Node7, as the device is not there, > what value will it return, if we try to read any register, say 0x6c for > getting the default link. > > > > val = pci_read_config32(NODE_HT(7), 0x6c); // What value does get > return, as node7 is not there. > byte = (val>>2) & 0x3; /*get default link on node7 to node0*/ > > > > Viswesh > > Viswesh, All AP nodes are node7 until re-numbered in the initialization process. Your node1 is node7 until it is told to be node1. A device that isn't attached (no ht link) should never be written to. Marc > > ----- Original Message ---- > From: Marc Jones > To: Viswesh S > Cc: coreboot at coreboot.org > Sent: Wednesday, 7 May, 2008 9:38:13 PM > Subject: Re: [coreboot] AMDk8 - HT routing > > Viswesh S wrote: > > Hi, > > > > I am looking into the Linux bios code for AMD 64 boards. > > > > In the setup_coherent_ht_domain function, we have functions > > setup_smp() and setup_smp2(). > > > > In the setup_smp2(), say the link1 is coherent and connected, we write > > the routing table for it, but then we veriify the connection for Node7 > > and then try to set the routing table registers for the link between 7 > > and 1. > > > > //* > > print_linkn("(0,1) link=", byte); > > setup_row_direct(0,1, byte); // > > setup_temp_row(0, 1); > > > > verify_connection(7); > > /* We found 2 nodes so far */ > > val = pci_read_config32(NODE_HT(7), 0x6c); > > byte = (val>>2) & 0x3; /*get default link on node7 to node0*/ > > print_linkn("(1,0) link=", byte); > > setup_row_local(7,1); > > setup_remote_row_direct(1, 0, byte); > > *// > > > > What is the logic reason behind checking the node7 here. > > > > In the case of my board, there is no Node7 itself and will the > > pci_write(outb instruction) cause any unknown behaviour, as the node > > is not present. > > > > Thanks, > > > > Viswesh > > > > ------------------------------------------------------------------------ > > Explore your hobbies and interests. Click here to begin. > > > > > Hi Viswesh, > > All AP nodes are node7 until they have been found and initialized by the > BSP. The BSP looks at each active link and then sets the nodeids. > > Marc > > > -- > Marc Jones > Senior Firmware Engineer > (970) 226-9684 Office > mailto:Marc.Jones at amd.com > http://www.amd.com/embeddedprocessors > > > > > ------------------------------------------------------------------------ > Best Jokes, Best Friends, Best Food. Get all this and more on Best of > Yahoo! Groups. > -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From mylesgw at gmail.com Wed May 7 23:11:40 2008 From: mylesgw at gmail.com (Myles Watson) Date: Wed, 7 May 2008 15:11:40 -0600 Subject: [coreboot] buildrom: Bump the revision for coreinfo & libpayload In-Reply-To: <20080507205932.GA8122@cosmic.amd.com> References: <20080507205932.GA8122@cosmic.amd.com> Message-ID: <00dd01c8b086$f2345000$1a02a8c0@chimp> > -----Original Message----- > From: coreboot-bounces+mylesgw=gmail.com at coreboot.org [mailto:coreboot- > bounces+mylesgw=gmail.com at coreboot.org] On Behalf Of Jordan Crouse > Sent: Wednesday, May 07, 2008 3:00 PM > To: coreboot at coreboot.org > Subject: [coreboot] buildrom: Bump the revision for coreinfo & libpayload > > Bump the coreinfo & libpayload revisions - with this, we should be up > to goodness. This also adjusts the default coreinfo config accordingly > depending on the version of coreboot being used - this is so that v3 users > can see the bootlog and LAR browsers in action. It looks like you forgot to move defconfig -> defconfig-coreboot. If you add an svn mv ... Acked-by: Myles Watson From svn at coreboot.org Wed May 7 23:27:50 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Wed, 7 May 2008 23:27:50 +0200 Subject: [coreboot] r189 - in buildrom-devel/packages: coreinfo coreinfo/conf libpayload Message-ID: Author: jcrouse Date: 2008-05-07 23:27:49 +0200 (Wed, 07 May 2008) New Revision: 189 Added: buildrom-devel/packages/coreinfo/conf/defconfig-coreboot buildrom-devel/packages/coreinfo/conf/defconfig-coreboot-v3 Removed: buildrom-devel/packages/coreinfo/conf/defconfig Modified: buildrom-devel/packages/coreinfo/coreinfo.mk buildrom-devel/packages/libpayload/libpayload.mk Log: buildrom: Bump the revision for coreinfo & libpayload Bump the coreinfo & libpayload revisions to take advantage of new goodness. Also update the default configuration, and provide two different configurations for coreboot-v2 and coreboot-v3, the latter showing off our new bootlog and LAR browsers. Signed-off-by: Jordan Crouse Acked-by: Myles Watson Deleted: buildrom-devel/packages/coreinfo/conf/defconfig =================================================================== --- buildrom-devel/packages/coreinfo/conf/defconfig 2008-05-07 20:54:48 UTC (rev 188) +++ buildrom-devel/packages/coreinfo/conf/defconfig 2008-05-07 21:27:49 UTC (rev 189) @@ -1,18 +0,0 @@ -# -# Automatically generated make config: don't edit -# coreinfo version: 0.1.0 -# Wed Apr 9 15:45:52 2008 -# - -# -# General settings -# -CONFIG_SHOW_DATE_TIME=y - -# -# Modules -# -CONFIG_MODULE_COREBOOT=y -CONFIG_MODULE_CPUINFO=y -CONFIG_MODULE_PCI=y -CONFIG_MODULE_NVRAM=y Copied: buildrom-devel/packages/coreinfo/conf/defconfig-coreboot (from rev 188, buildrom-devel/packages/coreinfo/conf/defconfig) =================================================================== --- buildrom-devel/packages/coreinfo/conf/defconfig-coreboot (rev 0) +++ buildrom-devel/packages/coreinfo/conf/defconfig-coreboot 2008-05-07 21:27:49 UTC (rev 189) @@ -0,0 +1,20 @@ +# +# Automatically generated make config: don't edit +# coreinfo version: 0.1.0 +# Wed Apr 9 15:45:52 2008 +# + +# +# General settings +# +CONFIG_SHOW_DATE_TIME=y + +# +# Modules +# +CONFIG_MODULE_COREBOOT=y +CONFIG_MODULE_CPUINFO=y +CONFIG_MODULE_PCI=y +CONFIG_MODULE_NVRAM=y +# CONFIG_MODULE_BOOTLOG is not set +# CONFIG_MODULE_LAR is not set Added: buildrom-devel/packages/coreinfo/conf/defconfig-coreboot-v3 =================================================================== --- buildrom-devel/packages/coreinfo/conf/defconfig-coreboot-v3 (rev 0) +++ buildrom-devel/packages/coreinfo/conf/defconfig-coreboot-v3 2008-05-07 21:27:49 UTC (rev 189) @@ -0,0 +1,20 @@ +# +# Automatically generated make config: don't edit +# coreinfo version: 0.1.0 +# Wed May 7 14:47:11 2008 +# + +# +# General settings +# +CONFIG_SHOW_DATE_TIME=y + +# +# Modules +# +CONFIG_MODULE_COREBOOT=y +CONFIG_MODULE_CPUINFO=y +CONFIG_MODULE_PCI=y +CONFIG_MODULE_NVRAM=y +CONFIG_MODULE_BOOTLOG=y +CONFIG_MODULE_LAR=y Modified: buildrom-devel/packages/coreinfo/coreinfo.mk =================================================================== --- buildrom-devel/packages/coreinfo/coreinfo.mk 2008-05-07 20:54:48 UTC (rev 188) +++ buildrom-devel/packages/coreinfo/coreinfo.mk 2008-05-07 21:27:49 UTC (rev 189) @@ -1,5 +1,5 @@ COREINFO_URL=svn://coreboot.org/repos/trunk/payloads/coreinfo -COREINFO_TAG=3228 +COREINFO_TAG=3289 COREINFO_DIR=$(BUILD_DIR)/coreinfo COREINFO_SRC_DIR=$(COREINFO_DIR)/svn @@ -14,7 +14,11 @@ COREINFO_FETCH_LOG=$(COREINFO_LOG_DIR)/fetch.log endif -COREINFO_CONFIG=$(PACKAGE_DIR)/coreinfo/conf/defconfig +ifeq ($(CONFIG_COREBOOT_V3),y) +COREINFO_CONFIG=$(PACKAGE_DIR)/coreinfo/conf/defconfig-coreboot-v3 +else +COREINFO_CONFIG=$(PACKAGE_DIR)/coreinfo/conf/defconfig-coreboot +endif COREINFO_TARBALL=coreinfo-svn-$(COREINFO_TAG).tar.gz Modified: buildrom-devel/packages/libpayload/libpayload.mk =================================================================== --- buildrom-devel/packages/libpayload/libpayload.mk 2008-05-07 20:54:48 UTC (rev 188) +++ buildrom-devel/packages/libpayload/libpayload.mk 2008-05-07 21:27:49 UTC (rev 189) @@ -1,5 +1,5 @@ LIBPAYLOAD_URL=svn://coreboot.org/repos/trunk/payloads/libpayload -LIBPAYLOAD_TAG=3272 +LIBPAYLOAD_TAG=3289 LIBPAYLOAD_DIR=$(BUILD_DIR)/libpayload LIBPAYLOAD_SRC_DIR=$(LIBPAYLOAD_DIR)/svn From mart.raudsepp at artecdesign.ee Wed May 7 23:28:21 2008 From: mart.raudsepp at artecdesign.ee (Mart Raudsepp) Date: Thu, 8 May 2008 00:28:21 +0300 (EEST) Subject: [coreboot] [PATCH] artecgroup/dbe61: Sync irq_tables with dbe62 code to fix compilation and have a chance of working properly. Message-ID: <50843.62.65.221.151.1210195701.squirrel@www.artecdesign.ee> Hello, Here's a patch that fixes DBE61 target compilation by making irq_tables.h take the v3 approach. It might actually work on hardware regarding interrupt setup, but we need to get the raminit to work properly to see... so this is in the name of compilation fix and common sense that as all the IRQ routing is the same in DBE61 and DBE62, that the routing settings in dbe62 code should be fine for dbe61 as well. Compilable target makes poking at raminit easier ;) Regards, Mart Raudsepp Artec Design LLC -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-artecgroup-dbe61-Sync-irq_tables-with-dbe62-code-to.patch Type: application/octet-stream Size: 6110 bytes Desc: not available URL: From joe at settoplinux.org Wed May 7 23:28:21 2008 From: joe at settoplinux.org (Joe) Date: Wed, 07 May 2008 17:28:21 -0400 Subject: [coreboot] [PATCH] Implement GPIO configuration options for Intel 3100 southbridge In-Reply-To: References: Message-ID: <33013914cf0ec2a592a8a9404c6f07c3@imap.1and1.com> On Wed, 7 May 2008 12:55:24 -0700, "Ed Swierk" wrote: > When I originally ported the GPIO configuration routines for the Intel > 3100 southbridge from esb6300_lpc.c, I left out the code that lets you > specify per-mainboard GPIO settings. This patch implements those > configuration routines, so you can put something like > > register "gpio[23]" = "I3100_GPIO_USE_AS_GPIO | > I3100_GPIO_SEL_OUTPUT | I3100_GPIO_LVL_LOW" > > in Config.lb to set GPIO 23 as an output, driving the signal low. > > Signed-off-by: Ed Swierk The gpio settings very from board to board. Why not leave this up to the mainboard? See how I have the RCA RM4100 setup in gpio.c -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org From eswierk at arastra.com Wed May 7 23:44:27 2008 From: eswierk at arastra.com (Ed Swierk) Date: Wed, 7 May 2008 14:44:27 -0700 Subject: [coreboot] [PATCH] Implement GPIO configuration options for Intel 3100 southbridge In-Reply-To: <33013914cf0ec2a592a8a9404c6f07c3@imap.1and1.com> References: <33013914cf0ec2a592a8a9404c6f07c3@imap.1and1.com> Message-ID: On Wed, May 7, 2008 at 2:28 PM, Joe wrote: > The gpio settings very from board to board. Why not leave this up to the > mainboard? Some settings are board-specific but others are required by the chipset. For example the Intel 3100 datasheet says software is required to drive a handful of GPIOs in a particular way. As long as the chipset code has to deal with GPIOs, it may as well try to abstract away some of the boilerplate code and magic values, making it easier to port to a new mainboard. And the code already exists, so why not use it? --Ed From c-d.hailfinger.devel.2006 at gmx.net Wed May 7 23:48:54 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 07 May 2008 23:48:54 +0200 Subject: [coreboot] [PATCH] Implement GPIO configuration options for Intel 3100 southbridge In-Reply-To: References: Message-ID: <482223C6.1090608@gmx.net> On 07.05.2008 21:55, Ed Swierk wrote: > When I originally ported the GPIO configuration routines for the Intel > 3100 southbridge from esb6300_lpc.c, I left out the code that lets you > specify per-mainboard GPIO settings. This patch implements those > configuration routines, so you can put something like > > register "gpio[23]" = "I3100_GPIO_USE_AS_GPIO | > I3100_GPIO_SEL_OUTPUT | I3100_GPIO_LVL_LOW" > > in Config.lb to set GPIO 23 as an output, driving the signal low. > > Signed-off-by: Ed Swierk > I don't have the datasheets handy, but the code looks OK. Acked-by: Carl-Daniel Hailfinger Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Wed May 7 23:50:48 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 07 May 2008 23:50:48 +0200 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <20080507202506.GC2564@cosmic.amd.com> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> <4820FAF0.2040207@gmx.net> <13426df10805070722s353852ebq20853c59b3c0034b@mail.gmail.com> <20080507142622.20021.qmail@stuge.se> <13426df10805070817x301c0c80je7fedb2676c54dbd@mail.gmail.com> <20080507202506.GC2564@cosmic.amd.com> Message-ID: <48222438.3080503@gmx.net> On 07.05.2008 22:25, Jordan Crouse wrote: > On 07/05/08 08:17 -0700, ron minnich wrote: > >> On Wed, May 7, 2008 at 7:26 AM, Peter Stuge wrote: >> >> >>> Short-term, yes, but I think we need to figure this out. >>> >> Agree. But I'm a big believer in breadboards. See PIke's comments on >> this sort of thing -- I agree with him. >> >> We can design all we want, but, until we write code, it's not clear we >> got it right. >> >> Speaking of which -- what did we do w.r.t. SELF? >> > > Still open for debate. I'm going to start coding it up for libpayload > so I can get moving on the chooser, but I dare not touch coreboot until > we get a consensus. > I have some 60-odd mails about SELF in my "ToDo" folder, but at least this week I will be swamped with organizing LinuxTag and writing more text for my thesis. I hope to answer most of these mails in a batch sometime next week. Regards, Carl-Daniel From svn at coreboot.org Wed May 7 23:57:13 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Wed, 7 May 2008 23:57:13 +0200 Subject: [coreboot] r3290 - trunk/coreboot-v2/src/southbridge/intel/i3100 Message-ID: Author: eswierk Date: 2008-05-07 23:57:12 +0200 (Wed, 07 May 2008) New Revision: 3290 Modified: trunk/coreboot-v2/src/southbridge/intel/i3100/i3100_lpc.c Log: Implement GPIO configuration routines for the Intel 3100 southbridge, allowing you to specify per-mainboard GPIO settings. Signed-off-by: Ed Swierk Acked-by: Carl-Daniel Hailfinger Modified: trunk/coreboot-v2/src/southbridge/intel/i3100/i3100_lpc.c =================================================================== --- trunk/coreboot-v2/src/southbridge/intel/i3100/i3100_lpc.c 2008-05-07 20:43:15 UTC (rev 3289) +++ trunk/coreboot-v2/src/southbridge/intel/i3100/i3100_lpc.c 2008-05-07 21:57:12 UTC (rev 3290) @@ -111,10 +111,32 @@ device_t dev, struct resource *res, config_t *config) { u32 gpio_use_sel, gpio_use_sel2; + int i; - gpio_use_sel = 0x1b0ce7c3; - gpio_use_sel2 = 0x00000107; - outl(gpio_use_sel, res->base + 0x00); + gpio_use_sel = inl(res->base + 0x00) | 0x0000c603; + gpio_use_sel2 = inl(res->base + 0x30) | 0x00000100; + for (i = 0; i < 64; i++) { + int val; + switch (config->gpio[i] & I3100_GPIO_USE_MASK) { + case I3100_GPIO_USE_AS_NATIVE: + val = 0; + break; + case I3100_GPIO_USE_AS_GPIO: + val = 1; + break; + default: + continue; + } + /* The caller is responsible for not playing with unimplemented bits */ + if (i < 32) { + gpio_use_sel &= ~(1 << i); + gpio_use_sel |= (val << i); + } else { + gpio_use_sel2 &= ~(1 << (i - 32)); + gpio_use_sel2 |= (val << (i - 32)); + } + } + outl(gpio_use_sel, res->base + 0x00); outl(gpio_use_sel2, res->base + 0x30); } @@ -122,10 +144,32 @@ device_t dev, struct resource *res, config_t *config) { u32 gpio_io_sel, gpio_io_sel2; + int i; - gpio_io_sel = 0xed00ffff; - gpio_io_sel2 = 0x00000307; - outl(gpio_io_sel, res->base + 0x04); + gpio_io_sel = inl(res->base + 0x04); + gpio_io_sel2 = inl(res->base + 0x34); + for (i = 0; i < 64; i++) { + int val; + switch (config->gpio[i] & I3100_GPIO_SEL_MASK) { + case I3100_GPIO_SEL_OUTPUT: + val = 0; + break; + case I3100_GPIO_SEL_INPUT: + val = 1; + break; + default: + continue; + } + /* The caller is responsible for not playing with unimplemented bits */ + if (i < 32) { + gpio_io_sel &= ~(1 << i); + gpio_io_sel |= (val << i); + } else { + gpio_io_sel2 &= ~(1 << (i - 32)); + gpio_io_sel2 |= (val << (i - 32)); + } + } + outl(gpio_io_sel, res->base + 0x04); outl(gpio_io_sel2, res->base + 0x34); } @@ -134,22 +178,68 @@ { u32 gpio_lvl, gpio_lvl2; u32 gpio_blink; + int i; - gpio_lvl = 0x00030000; - gpio_blink = 0x00000000; - gpio_lvl2 = 0x00000300; - outl(gpio_lvl, res->base + 0x0c); + gpio_lvl = inl(res->base + 0x0c); + gpio_blink = inl(res->base + 0x18); + gpio_lvl2 = inl(res->base + 0x38); + for (i = 0; i < 64; i++) { + int val, blink; + switch (config->gpio[i] & I3100_GPIO_LVL_MASK) { + case I3100_GPIO_LVL_LOW: + val = 0; + blink = 0; + break; + case I3100_GPIO_LVL_HIGH: + val = 1; + blink = 0; + break; + case I3100_GPIO_LVL_BLINK: + val = 1; + blink = 1; + break; + default: + continue; + } + /* The caller is responsible for not playing with unimplemented bits */ + if (i < 32) { + gpio_lvl &= ~(1 << i); + gpio_blink &= ~(1 << i); + gpio_lvl |= (val << i); + gpio_blink |= (blink << i); + } else { + gpio_lvl2 &= ~(1 << (i - 32)); + gpio_lvl2 |= (val << (i - 32)); + } + } + outl(gpio_lvl, res->base + 0x0c); outl(gpio_blink, res->base + 0x18); - outl(gpio_lvl2, res->base + 0x38); + outl(gpio_lvl2, res->base + 0x38); } static void set_i3100_gpio_inv( device_t dev, struct resource *res, config_t *config) { u32 gpio_inv; + int i; - gpio_inv = 0x00006000; - outl(gpio_inv, res->base + 0x2c); + gpio_inv = inl(res->base + 0x2c); + for (i = 0; i < 32; i++) { + int val; + switch (config->gpio[i] & I3100_GPIO_INV_MASK) { + case I3100_GPIO_INV_OFF: + val = 0; + break; + case I3100_GPIO_INV_ON: + val = 1; + break; + default: + continue; + } + gpio_inv &= ~(1 << i); + gpio_inv |= (val << i); + } + outl(gpio_inv, res->base + 0x2c); } static void i3100_pirq_init(device_t dev) From eswierk at arastra.com Wed May 7 23:57:51 2008 From: eswierk at arastra.com (Ed Swierk) Date: Wed, 7 May 2008 14:57:51 -0700 Subject: [coreboot] [PATCH] Implement GPIO configuration options for Intel 3100 southbridge In-Reply-To: <482223C6.1090608@gmx.net> References: <482223C6.1090608@gmx.net> Message-ID: On Wed, May 7, 2008 at 2:48 PM, Carl-Daniel Hailfinger wrote: > I don't have the datasheets handy, but the code looks OK. > > Acked-by: Carl-Daniel Hailfinger Thanks, r3290. --Ed From c-d.hailfinger.devel.2006 at gmx.net Thu May 8 00:20:53 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 08 May 2008 00:20:53 +0200 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <13426df10805070722s353852ebq20853c59b3c0034b@mail.gmail.com> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> <4820FAF0.2040207@gmx.net> <13426df10805070722s353852ebq20853c59b3c0034b@mail.gmail.com> Message-ID: <48222B45.7050604@gmx.net> Stefan? Can you take a look at my variant of the patch? Regards, Carl-Daniel On 07.05.2008 16:22, ron minnich wrote: > OK, if stepan Acks this patch of Carl-Daniel, I think I will ack it too. > > So, conditional on stepan, > Acked-by: Ronald G. Minnich > > overall, it's the best idea I've seen. > > ron From michlmann at gmx.de Wed May 7 22:51:29 2008 From: michlmann at gmx.de (Michael Rauscher) Date: Wed, 7 May 2008 20:51:29 +0000 (UTC) Subject: [coreboot] Epia ME6000 VGA Message-ID: Hi, I ran into problems to enable VGA in coreboot on the ME6000. The log: coreboot-2.0.0.0Fallback So 4. Mai 10:09:40 CEST 2008 starting... Enabling mainboard devices Enabling shadow ram vt8623 init starting Detecting Memory Number of Banks 04 Number of Rows 0d Priamry DRAM width08 No Columns 0a MA type e0 Bank 0 (*16 Mb) 10 No Physical Banks 02 Total Memory (*16 Mb) 20 CAS Supported 2 2.5 Cycle time at CL X (nS)60 Cycle time at CL X-0.5 (nS)75 Cycle time at CL X-1 (nS)00 Starting at CAS 2.5 We can do CAS 2 tRP 48 tRCD 48 tRAS 2a Low Bond 00 High Bondcd Setting DQS delay88vt8623 done 00:06 11 23 31 06 00 30 22 00 00 00 06 00 00 00 00 10:08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00 20:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 40:00 18 88 80 82 44 00 00 18 99 88 80 82 44 00 00 50:c8 de cf 88 e0 07 00 00 e0 00 10 20 20 20 00 00 60:02 ff 00 30 d6 32 01 20 42 2d 43 58 84 55 00 00 70:82 48 00 01 01 08 50 00 01 00 00 00 00 00 02 12 80:0f 61 00 00 80 00 00 00 02 00 00 00 00 00 00 00 90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0:02 c0 20 00 07 02 00 1f 04 00 00 00 2f 02 04 00 b0:00 00 00 00 80 00 00 00 68 00 00 00 00 00 00 00 c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0:00 dd 00 01 00 00 01 00 40 00 00 00 00 00 00 00 f0:00 00 00 00 00 00 12 13 00 00 00 00 00 00 00 00 AGP Doing MTRR init. Copying coreboot to RAM. Jumping to coreboot. coreboot-2.0.0.0Fallback So 4. Mai 10:09:40 CEST 2008 booting... clocks_per_usec: 877 Enumerating buses... APIC_CLUSTER: 0 enabled Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0001 enabled PCI: pci_scan_bus for bus 00 PCI: 00:00.0 [1106/3123] enabled PCI: 00:01.0 [1106/b091] enabled PCI: 00:0d.0 [1106/3044] enabled In vt8235_enable 1106 3038. PCI: 00:10.0 [1106/3038] enabled In vt8235_enable 1106 3038. PCI: 00:10.1 [1106/3038] enabled In vt8235_enable 1106 3038. PCI: 00:10.2 [1106/3038] enabled In vt8235_enable ffff ffff. Disabling static device: PCI: 00:10.3 In vt8235_enable 1106 3177. Initialising Devices Keyboard init... PCI: 00:11.0 [1106/3177] enabled In vt8235_enable 1106 0571. PCI: 00:11.1 [1106/0571] enabled In vt8235_enable 1106 3059. PCI: 00:11.5 [1106/3059] enabled In vt8235_enable 1106 3068. PCI: 00:11.6 [1106/3068] disabled In vt8235_enable 1106 3065. PCI: 00:12.0 [1106/3065] enabled PCI: 00:14.0 [1131/7146] enabled PCI: pci_scan_bus for bus 01 PCI: 01:00.0 [1106/3122] enabled PCI: pci_scan_bus returning with max=001 vt1211 enabling PNP devices. PNP: 002e.0 enabled vt1211 enabling PNP devices. PNP: 002e.1 enabled vt1211 enabling PNP devices. PNP: 002e.2 enabled vt1211 enabling PNP devices. PNP: 002e.3 enabled vt1211 enabling PNP devices. PNP: 002e.b enabled PCI: pci_scan_bus returning with max=001 PCI: pci_scan_bus for bus 00 PCI: 00:00.0 [1106/3123] enabled PCI: 00:01.0 [1106/b091] enabled PCI: 00:0d.0 [1106/3044] enabled PCI: 00:10.0 [1106/3038] enabled PCI: 00:10.1 [1106/3038] enabled PCI: 00:10.2 [1106/3038] enabled PCI: 00:10.3 [1106/3104] enabled PCI: 00:11.0 [1106/3177] enabled PCI: 00:11.1 [1106/0571] enabled PCI: 00:11.5 [1106/3059] enabled Error! malloc: free_mem_ptr >= free_mem_end_ptr The whole thing is stored in a 39SF040 (512 KB), so I've set the rom_address to 0xfff8000: device pci 0.0 on # PCI chip drivers/pci/onboard device pci 0.0 on end register "rom_address" = "0xfff80000" #512k image end end (I've also tried to create a 256 KB image (prepended with 256 KB of 0s) with fffc0000 - same effect). The following options are used: option CONFIG_CONSOLE_VGA=1 option CONFIG_PCI_ROM_RUN=0 option ROM_SIZE=458752 The fallback size is set to the same value as the ROM_SIZE (458752) as I use a fallback-only image. The interesting things are: 1. It doesn't matter if I use OptionsRom or the legacy VGA-BIOS 2. Without VGA BIOS (configuration adapted) it works. Any suggestions? Thanks in advance Michael From stepan at coresystems.de Thu May 8 00:38:29 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 08 May 2008 00:38:29 +0200 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <4820FAF0.2040207@gmx.net> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> <4820FAF0.2040207@gmx.net> Message-ID: <48222F65.4070008@coresystems.de> Carl-Daniel Hailfinger wrote: > > See below for my take at this. > > Move CS5536 IDE configuration into a separate dts and its own PCI device. > Carl-Daniel, is this the patch you mentioned? > Signed-off-by: Carl-Daniel Hailfinger > > Build-tested on db800, norwich, dbe62, alix.1c, alix.2c3. > Breaks build for dbe61. > Why is that? Please fix this before committing. Without breaks, this patch is Acked-by: Stefan Reinauer > Index: LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/cs5536.c > =================================================================== > --- LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/cs5536.c (revision 676) > +++ LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/cs5536.c (working copy) > @@ -590,6 +590,11 @@ > { > u32 ide_cfg; > > + struct southbridge_amd_cs5536_ide_config *ide = > + (struct southbridge_amd_cs5536_ide_config *)dev->device_configuration; > + if (!ide->enable_ide) > + return; > + > printk(BIOS_DEBUG, "cs5536_ide: %s\n", __func__); > /* GPIO and IRQ setup are handled in the main chipset code. */ > > @@ -654,9 +659,6 @@ > hide_vpci(sb->unwanted_vpci[i]); > } > > - if (sb->enable_ide) > - ide_init(dev); > - > cs5536_setup_power_button(sb); > > printk(BIOS_SPEW, "cs5536: %s() Exit\n", __FUNCTION__); > @@ -688,3 +690,17 @@ > .phase6_init = southbridge_init, > }; > > +struct device_operations cs5536_ide = { > + .id = {.type = DEVICE_ID_PCI, > + .u = {.pci = {.vendor = PCI_VENDOR_ID_AMD, > + .device = PCI_DEVICE_ID_AMD_CS5536_B0_IDE}}}, > + .constructor = default_device_constructor, > +#warning FIXME: what has to go in phase3_scan? > + .phase3_scan = 0, > + .phase4_read_resources = pci_dev_read_resources, > + .phase4_set_resources = pci_dev_set_resources, > + .phase5_enable_resources = pci_dev_enable_resources, > + .phase6_init = ide_init, > + .ops_pci = &pci_dev_ops_pci, > +}; > + In v2 I liked that every hardware driver for every pci device was in a single, small file. Packing all of it in one large cs5536.c is a bit ugly. But that is not within the scope of this patch I guess. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From c-d.hailfinger.devel.2006 at gmx.net Thu May 8 01:03:25 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 08 May 2008 01:03:25 +0200 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <48222F65.4070008@coresystems.de> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> <4820FAF0.2040207@gmx.net> <48222F65.4070008@coresystems.de> Message-ID: <4822353D.1010609@gmx.net> On 08.05.2008 00:38, Stefan Reinauer wrote: > Carl-Daniel Hailfinger wrote: >> >> See below for my take at this. >> >> Move CS5536 IDE configuration into a separate dts and its own PCI >> device. >> > Carl-Daniel, is this the patch you mentioned? Yes. >> Signed-off-by: Carl-Daniel Hailfinger >> >> >> Build-tested on db800, norwich, dbe62, alix.1c, alix.2c3. >> Breaks build for dbe61. >> > > Why is that? Please fix this before committing. Will do. I'll also integrate the fixes Mart Raudsepp suggested for dbe61 and dbe62. > Without breaks, this patch is Acked-by: Stefan Reinauer > Thanks! Regards, Carl-Daniel > >> Index: LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/cs5536.c >> =================================================================== >> --- LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/cs5536.c >> (revision 676) >> +++ LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/cs5536.c >> (working copy) >> @@ -590,6 +590,11 @@ >> { >> u32 ide_cfg; >> >> + struct southbridge_amd_cs5536_ide_config *ide = >> + (struct southbridge_amd_cs5536_ide_config >> *)dev->device_configuration; >> + if (!ide->enable_ide) >> + return; >> + >> printk(BIOS_DEBUG, "cs5536_ide: %s\n", __func__); >> /* GPIO and IRQ setup are handled in the main chipset code. */ >> >> @@ -654,9 +659,6 @@ >> hide_vpci(sb->unwanted_vpci[i]); >> } >> >> - if (sb->enable_ide) >> - ide_init(dev); >> - >> cs5536_setup_power_button(sb); >> >> printk(BIOS_SPEW, "cs5536: %s() Exit\n", __FUNCTION__); >> @@ -688,3 +690,17 @@ >> .phase6_init = southbridge_init, >> }; >> >> +struct device_operations cs5536_ide = { >> + .id = {.type = DEVICE_ID_PCI, >> + .u = {.pci = {.vendor = PCI_VENDOR_ID_AMD, >> + .device = PCI_DEVICE_ID_AMD_CS5536_B0_IDE}}}, >> + .constructor = default_device_constructor, >> +#warning FIXME: what has to go in phase3_scan? >> + .phase3_scan = 0, >> + .phase4_read_resources = pci_dev_read_resources, >> + .phase4_set_resources = pci_dev_set_resources, >> + .phase5_enable_resources = pci_dev_enable_resources, >> + .phase6_init = ide_init, >> + .ops_pci = &pci_dev_ops_pci, >> +}; >> + > > In v2 I liked that every hardware driver for every pci device was in a > single, small file. Packing all of it in one large cs5536.c is a bit > ugly. But that is not within the scope of this patch I guess. > > -- http://www.hailfinger.org/ From svn at coreboot.org Thu May 8 01:21:57 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Thu, 8 May 2008 01:21:57 +0200 Subject: [coreboot] r677 - in coreboot-v3: mainboard/amd/db800 mainboard/amd/norwich mainboard/artecgroup/dbe61 mainboard/artecgroup/dbe62 mainboard/pcengines/alix1c mainboard/pcengines/alix2c3 southbridge/amd/cs5536 Message-ID: Author: hailfinger Date: 2008-05-08 01:21:55 +0200 (Thu, 08 May 2008) New Revision: 677 Added: coreboot-v3/southbridge/amd/cs5536/ide Modified: coreboot-v3/mainboard/amd/db800/dts coreboot-v3/mainboard/amd/norwich/dts coreboot-v3/mainboard/artecgroup/dbe61/dts coreboot-v3/mainboard/artecgroup/dbe62/dts coreboot-v3/mainboard/pcengines/alix1c/dts coreboot-v3/mainboard/pcengines/alix2c3/dts coreboot-v3/southbridge/amd/cs5536/cs5536.c coreboot-v3/southbridge/amd/cs5536/dts Log: Move CS5536 IDE configuration into a separate dts and its own PCI device. Fix dbe62 IDE/NAND selection. Build-tested on db800, norwich, dbe62, alix.1c, alix.2c3. No additional breakage for dbe61. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Ronald G. Minnich Acked-by: Stefan Reinauer Modified: coreboot-v3/mainboard/amd/db800/dts =================================================================== --- coreboot-v3/mainboard/amd/db800/dts 2008-05-05 13:59:01 UTC (rev 676) +++ coreboot-v3/mainboard/amd/db800/dts 2008-05-07 23:21:55 UTC (rev 677) @@ -34,7 +34,6 @@ }; pci at 15,0 { /config/("southbridge/amd/cs5536/dts"); - enable_ide = "1"; /* Interrupt enables for LPC bus. * Each bit is an IRQ 0-15. */ lpc_serirq_enable = "0x000010da"; @@ -47,6 +46,10 @@ enable_gpio_int_route = "0x0D0C0700"; enable_USBP4_device = "1"; }; + pci at 15,2 { + /config/("southbridge/amd/cs5536/ide"); + enable_ide = "1"; + }; ioport at 46 { /config/("superio/winbond/w83627hf/dts"); com1enable = "1"; Modified: coreboot-v3/mainboard/amd/norwich/dts =================================================================== --- coreboot-v3/mainboard/amd/norwich/dts 2008-05-05 13:59:01 UTC (rev 676) +++ coreboot-v3/mainboard/amd/norwich/dts 2008-05-07 23:21:55 UTC (rev 677) @@ -34,7 +34,6 @@ }; pci at 15,0 { /config/("southbridge/amd/cs5536/dts"); - enable_ide = "1"; /* Interrupt enables for LPC bus. * Each bit is an IRQ 0-15. */ lpc_serirq_enable = "0x00001002"; @@ -50,5 +49,9 @@ com1_address = "0x3f8"; com1_irq = "4"; }; + pci at 15,2 { + /config/("southbridge/amd/cs5536/ide"); + enable_ide = "1"; + }; }; }; Modified: coreboot-v3/mainboard/artecgroup/dbe61/dts =================================================================== --- coreboot-v3/mainboard/artecgroup/dbe61/dts 2008-05-05 13:59:01 UTC (rev 676) +++ coreboot-v3/mainboard/artecgroup/dbe61/dts 2008-05-07 23:21:55 UTC (rev 677) @@ -105,5 +105,8 @@ com2_address = "0x3f8"; com2_irq = "4"; }; + pci at 15,2 { + /config/("southbridge/amd/cs5536/ide"); + }; }; }; Modified: coreboot-v3/mainboard/artecgroup/dbe62/dts =================================================================== --- coreboot-v3/mainboard/artecgroup/dbe62/dts 2008-05-05 13:59:01 UTC (rev 676) +++ coreboot-v3/mainboard/artecgroup/dbe62/dts 2008-05-07 23:21:55 UTC (rev 677) @@ -34,7 +34,6 @@ }; pci at 15,0 { /config/("southbridge/amd/cs5536/dts"); - enable_ide = "1"; /* Interrupt enables for LPC bus. * Each bit is an IRQ 0-15. */ lpc_serirq_enable = "0x00001002"; @@ -54,5 +53,8 @@ /* Set com2 IRQ to be what is usually COM1 */ com2_irq = "4"; }; + pci at 15,2 { + /config/("southbridge/amd/cs5536/ide"); + }; }; }; Modified: coreboot-v3/mainboard/pcengines/alix1c/dts =================================================================== --- coreboot-v3/mainboard/pcengines/alix1c/dts 2008-05-05 13:59:01 UTC (rev 676) +++ coreboot-v3/mainboard/pcengines/alix1c/dts 2008-05-07 23:21:55 UTC (rev 677) @@ -34,7 +34,6 @@ }; pci at 15,0 { /config/("southbridge/amd/cs5536/dts"); - enable_ide = "1"; /* Interrupt enables for LPC bus. * Each bit is an IRQ 0-15. */ lpc_serirq_enable = "0x000010da"; @@ -46,6 +45,10 @@ * See virtual PIC spec. */ enable_gpio_int_route = "0x0D0C0700"; }; + pci at 15,2 { + /config/("southbridge/amd/cs5536/ide"); + enable_ide = "1"; + }; ioport at 46 { /config/("superio/winbond/w83627hf/dts"); com1enable = "1"; Modified: coreboot-v3/mainboard/pcengines/alix2c3/dts =================================================================== --- coreboot-v3/mainboard/pcengines/alix2c3/dts 2008-05-05 13:59:01 UTC (rev 676) +++ coreboot-v3/mainboard/pcengines/alix2c3/dts 2008-05-07 23:21:55 UTC (rev 677) @@ -32,7 +32,6 @@ }; pci at 15,0 { /config/("southbridge/amd/cs5536/dts"); - enable_ide = "1"; /* Interrupt enables for LPC bus. * Each bit is an IRQ 0-15. */ lpc_serirq_enable = "0x000010da"; @@ -50,5 +49,9 @@ /* this board does not really have vga; disable it (pci device 00:01.1) */ unwanted_vpci = < 80000900 0 >; }; + pci at 15,2 { + /config/("southbridge/amd/cs5536/ide"); + enable_ide = "1"; + }; }; }; Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.c =================================================================== --- coreboot-v3/southbridge/amd/cs5536/cs5536.c 2008-05-05 13:59:01 UTC (rev 676) +++ coreboot-v3/southbridge/amd/cs5536/cs5536.c 2008-05-07 23:21:55 UTC (rev 677) @@ -590,6 +590,11 @@ { u32 ide_cfg; + struct southbridge_amd_cs5536_ide_config *ide = + (struct southbridge_amd_cs5536_ide_config *)dev->device_configuration; + if (!ide->enable_ide) + return; + printk(BIOS_DEBUG, "cs5536_ide: %s\n", __func__); /* GPIO and IRQ setup are handled in the main chipset code. */ @@ -654,9 +659,6 @@ hide_vpci(sb->unwanted_vpci[i]); } - if (sb->enable_ide) - ide_init(dev); - cs5536_setup_power_button(sb); printk(BIOS_SPEW, "cs5536: %s() Exit\n", __FUNCTION__); @@ -688,3 +690,17 @@ .phase6_init = southbridge_init, }; +struct device_operations cs5536_ide = { + .id = {.type = DEVICE_ID_PCI, + .u = {.pci = {.vendor = PCI_VENDOR_ID_AMD, + .device = PCI_DEVICE_ID_AMD_CS5536_B0_IDE}}}, + .constructor = default_device_constructor, +#warning FIXME: what has to go in phase3_scan? + .phase3_scan = 0, + .phase4_read_resources = pci_dev_read_resources, + .phase4_set_resources = pci_dev_set_resources, + .phase5_enable_resources = pci_dev_enable_resources, + .phase6_init = ide_init, + .ops_pci = &pci_dev_ops_pci, +}; + Modified: coreboot-v3/southbridge/amd/cs5536/dts =================================================================== --- coreboot-v3/southbridge/amd/cs5536/dts 2008-05-05 13:59:01 UTC (rev 676) +++ coreboot-v3/southbridge/amd/cs5536/dts 2008-05-07 23:21:55 UTC (rev 677) @@ -36,9 +36,6 @@ /* 0:IDE 1:FLASH, if you are using NAND flash instead of IDE drive. */ enable_ide_nand_flash = "0"; - /* IDE: enable CS5536 IDE. There may be a different IDE controller on board */ - enable_ide = "0"; - /* Enable USB Port 4 (0:host 1:device). */ enable_USBP4_device = "0"; Added: coreboot-v3/southbridge/amd/cs5536/ide =================================================================== --- coreboot-v3/southbridge/amd/cs5536/ide (rev 0) +++ coreboot-v3/southbridge/amd/cs5536/ide 2008-05-07 23:21:55 UTC (rev 677) @@ -0,0 +1,26 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2007 Ronald G. Minnich + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +{ + device_operations = "cs5536_ide"; + + /* IDE: enable CS5536 IDE. There may be a different IDE controller on board */ + enable_ide = "0"; +}; From c-d.hailfinger.devel.2006 at gmx.net Thu May 8 01:22:45 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 08 May 2008 01:22:45 +0200 Subject: [coreboot] patch: two bugs in the cs5536 ide code In-Reply-To: <4822353D.1010609@gmx.net> References: <13426df10805052254p414e8466w9c626b427ceae0d7@mail.gmail.com> <48204BF0.1060407@gmx.net> <13426df10805060837q7e923efdm37f03136c906ebbd@mail.gmail.com> <4820FAF0.2040207@gmx.net> <48222F65.4070008@coresystems.de> <4822353D.1010609@gmx.net> Message-ID: <482239C5.40807@gmx.net> On 08.05.2008 01:03, Carl-Daniel Hailfinger wrote: > On 08.05.2008 00:38, Stefan Reinauer wrote: > >> Carl-Daniel Hailfinger wrote: >> >>> See below for my take at this. >>> >>> Move CS5536 IDE configuration into a separate dts and its own PCI >>> device. >>> >>> >> Carl-Daniel, is this the patch you mentioned? >> > > Yes. > > >>> Signed-off-by: Carl-Daniel Hailfinger >>> >>> >>> Build-tested on db800, norwich, dbe62, alix.1c, alix.2c3. >>> Breaks build for dbe61. >>> >>> >> Why is that? Please fix this before committing. >> > > Will do. I'll also integrate the fixes Mart Raudsepp suggested for dbe61 > and dbe62. > Done. Please note that the dbe61 is now back to the preexisting age-old breakage, but the new breakage has been fixed. The dbe61 code has too many v2 leftovers to compile. >> Without breaks, this patch is Acked-by: Stefan Reinauer >> >> > > Thanks! > Committed in r677. Regards, Carl-Daniel > Regards, > Carl-Daniel > >>> Index: LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/cs5536.c >>> =================================================================== >>> --- LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/cs5536.c >>> (revision 676) >>> +++ LinuxBIOSv3-hierarchical_dts/southbridge/amd/cs5536/cs5536.c >>> (working copy) >>> @@ -590,6 +590,11 @@ >>> { >>> u32 ide_cfg; >>> >>> + struct southbridge_amd_cs5536_ide_config *ide = >>> + (struct southbridge_amd_cs5536_ide_config >>> *)dev->device_configuration; >>> + if (!ide->enable_ide) >>> + return; >>> + >>> printk(BIOS_DEBUG, "cs5536_ide: %s\n", __func__); >>> /* GPIO and IRQ setup are handled in the main chipset code. */ >>> >>> @@ -654,9 +659,6 @@ >>> hide_vpci(sb->unwanted_vpci[i]); >>> } >>> >>> - if (sb->enable_ide) >>> - ide_init(dev); >>> - >>> cs5536_setup_power_button(sb); >>> >>> printk(BIOS_SPEW, "cs5536: %s() Exit\n", __FUNCTION__); >>> @@ -688,3 +690,17 @@ >>> .phase6_init = southbridge_init, >>> }; >>> >>> +struct device_operations cs5536_ide = { >>> + .id = {.type = DEVICE_ID_PCI, >>> + .u = {.pci = {.vendor = PCI_VENDOR_ID_AMD, >>> + .device = PCI_DEVICE_ID_AMD_CS5536_B0_IDE}}}, >>> + .constructor = default_device_constructor, >>> +#warning FIXME: what has to go in phase3_scan? >>> + .phase3_scan = 0, >>> + .phase4_read_resources = pci_dev_read_resources, >>> + .phase4_set_resources = pci_dev_set_resources, >>> + .phase5_enable_resources = pci_dev_enable_resources, >>> + .phase6_init = ide_init, >>> + .ops_pci = &pci_dev_ops_pci, >>> +}; >>> + >>> >> In v2 I liked that every hardware driver for every pci device was in a >> single, small file. Packing all of it in one large cs5536.c is a bit >> ugly. But that is not within the scope of this patch I guess. >> That will come as a separate cleanup, but probably not from me in the next 3 weeks. From c-d.hailfinger.devel.2006 at gmx.net Thu May 8 01:29:04 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 08 May 2008 01:29:04 +0200 Subject: [coreboot] bug in cs5536 ide enable. Is this also in 8111 ... In-Reply-To: <13426df10805052142n60aaa4nf4c8f7fa3d1da1c4@mail.gmail.com> References: <13426df10805052142n60aaa4nf4c8f7fa3d1da1c4@mail.gmail.com> Message-ID: <48223B40.1070907@gmx.net> Ron, can you commit that one? Together with r677 it should work fine. On 06.05.2008 06:42, ron minnich wrote: > #define IDE_CFG 0x40 > #define CHANEN (1L << 1) > #define PWB (1L << 14) > #define CABLE (1L << 16) > #define IDE_DTC 0x48 > #define IDE_CAST 0x4C > #define IDE_ETC 0x50 > > static void ide_init(struct device *dev) > { > uint32_t ide_cfg; > > printk_spew("cs5536_ide: %s\n", __FUNCTION__); > /* GPIO and IRQ setup are handled in the main chipset code. */ > > // Enable the channel and Post Write Buffer > // NOTE: Only 32-bit writes to the data buffer are allowed > when PWB is set > ide_cfg = pci_read_config32(dev, IDE_CFG); > ide_cfg |= CHANEN | PWB; > pci_write_config8(dev, IDE_CFG, ide_cfg); > } > > Note the pci_read_config32 followed by the pci_write_config8. > > HMM, why did this ever work? Anyway, I changed the write_config8 to > write_config32 and it is still no good on the alix1c on v3. If someone > wants to try this fix on v2, go for it: > > Index: southbridge/amd/cs5536/cs5536.c > =================================================================== > --- southbridge/amd/cs5536/cs5536.c (revision 676) > +++ southbridge/amd/cs5536/cs5536.c (working copy) > @@ -597,7 +597,7 @@ > // NOTE: Only 32-bit writes to the data buffer are allowed > when PWB is set > ide_cfg = pci_read_config32(dev, IDE_CFG); > ide_cfg |= CHANEN | PWB; > - pci_write_config8(dev, IDE_CFG, ide_cfg); > + pci_write_config32(dev, IDE_CFG, ide_cfg); > } > > you need to translate for the v2 filename. > > > off to rest, if somebody gets somewhere with this, let me know. > This is still needed. Acked-by: Carl-Daniel Hailfinger Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Thu May 8 02:12:59 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 08 May 2008 02:12:59 +0200 Subject: [coreboot] [PATCH] [RFC] v3: CS5536 cleanup In-Reply-To: <48205A47.5060403@gmx.net> References: <48205A47.5060403@gmx.net> Message-ID: <4822458B.4030506@gmx.net> Hi Ron, can you review this? - Clean up Geode companion chip CS5536 code. - Improve VPCI hiding debug message and add doxygen comments. - Eliminate a few redundant dev_find_pci_device() calls. This should be an equivalence transformation. Build tested on norwich, db800, alix.1c, alix.2c3, dbe62. No new breakage on dbe61. Signed-off-by: Carl-Daniel Hailfinger Index: LinuxBIOSv3-cs5536cleanup/southbridge/amd/cs5536/cs5536.c =================================================================== --- LinuxBIOSv3-cs5536cleanup/southbridge/amd/cs5536/cs5536.c (Revision 677) +++ LinuxBIOSv3-cs5536cleanup/southbridge/amd/cs5536/cs5536.c (Arbeitskopie) @@ -89,6 +89,28 @@ }; /** + * Hide unwanted virtual PCI device. + * + * @param vpci_devid The bus location of the device to be hidden. + * bits 0 -> 1 zero + * bits 2 -> 7 target dword within the target function + * (zero if we're disabling entire pci devices) + * bits 8 -> 10 target function of the device + * bits 11 -> 15 target pci device + * bits 16 -> 23 pci bus + * bits 24 -> 30 reserved and set to zero + * bit 31 triggers the config cycle + */ +static void hide_vpci(u32 vpci_devid) +{ + printk(BIOS_DEBUG, "Hiding VPCI device: 0x%08X (%02x:%02x.%01x)\n", + vpci_devid, (vpci_devid >> 16) & 0xff, + (vpci_devid >> 11) & 0x1f, (vpci_devid >> 8) & 0x7); + outl(vpci_devid + 0x7C, 0xCF8); + outl(0xDEADBEEF, 0xCFC); +} + +/** * Power button setup. * * Setup GPIO24, it is the external signal for CS5536 vsb_work_aux which @@ -175,8 +197,7 @@ static void enable_ide_nand_flash_header(void) { /* Tell VSA to use FLASH PCI header. Not IDE header. */ - outl(0x80007A40, 0xCF8); - outl(0xDEADBEEF, 0xCFC); + hide_vpci(0x800079C4); } #define RTC_CENTURY 0x32 @@ -240,16 +261,13 @@ * * @param sb Southbridge config structure. */ -static void uarts_init(struct southbridge_amd_cs5536_dts_config *sb) +static void uarts_init(struct southbridge_amd_cs5536_dts_config *sb, + struct device *dev) { struct msr msr; u16 addr = 0; u32 gpio_addr; - struct device *dev; - dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, - PCI_DEVICE_ID_AMD_CS5536_ISA, 0); - gpio_addr = pci_read_config32(dev, PCI_BASE_ADDRESS_1); gpio_addr &= ~1; /* Clear I/O bit */ printk(BIOS_DEBUG, "GPIO_ADDR: %08X\n", gpio_addr); @@ -418,11 +436,11 @@ { u32 *bar; struct msr msr; - struct device *dev; + struct device *ehci_dev, *otg_dev, *udc_dev; - dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, + ehci_dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CS5536_EHCI, 0); - if (dev) { + if (ehci_dev) { /* Serial short detect enable */ msr = rdmsr(USB2_SB_GLD_MSR_CONF); msr.hi |= USB2_UPPER_SSDEN_SET; @@ -431,7 +449,7 @@ /* Write to clear diag register. */ wrmsr(USB2_SB_GLD_MSR_DIAG, rdmsr(USB2_SB_GLD_MSR_DIAG)); - bar = (u32 *) pci_read_config32(dev, PCI_BASE_ADDRESS_0); + bar = (u32 *) pci_read_config32(ehci_dev, PCI_BASE_ADDRESS_0); /* Make HCCPARAMS writable. */ *(bar + IPREG04) |= USB_HCCPW_SET; @@ -440,10 +458,10 @@ *(bar + HCCPARAMS) = 0x00005012; } - dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, + otg_dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CS5536_OTG, 0); - if (dev) { - bar = (u32 *) pci_read_config32(dev, PCI_BASE_ADDRESS_0); + if (otg_dev) { + bar = (u32 *) pci_read_config32(otg_dev, PCI_BASE_ADDRESS_0); *(bar + UOCMUX) &= PUEN_SET; @@ -458,6 +476,8 @@ *(bar + UOCCAP) |= sb->enable_USBP4_overcurrent; } + udc_dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, + PCI_DEVICE_ID_AMD_CS5536_UDC, 0); /* PBz#6466: If the UOC(OTG) device, port 4, is configured as a * device, then perform the following sequence: * - Set SD bit in DEVCTRL udc register @@ -465,32 +485,24 @@ * - Set APU bit in uoc register */ if (sb->enable_USBP4_device) { - dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, - PCI_DEVICE_ID_AMD_CS5536_UDC, 0); - if (dev) { - bar = (u32 *)pci_read_config32(dev, PCI_BASE_ADDRESS_0); + if (udc_dev) { + bar = (u32 *)pci_read_config32(udc_dev, PCI_BASE_ADDRESS_0); *(bar + UDCDEVCTL) |= UDC_SD_SET; } - dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, - PCI_DEVICE_ID_AMD_CS5536_OTG, 0); - if (dev) { - bar = (u32 *)pci_read_config32(dev, PCI_BASE_ADDRESS_0); + if (otg_dev) { + bar = (u32 *)pci_read_config32(otg_dev, PCI_BASE_ADDRESS_0); *(bar + UOCCTL) |= PADEN_SET; *(bar + UOCCAP) |= APU_SET; } } /* Disable virtual PCI UDC and OTG headers. */ - dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, - PCI_DEVICE_ID_AMD_CS5536_UDC, 0); - if (dev) - pci_write_config32(dev, 0x7C, 0xDEADBEEF); + if (udc_dev) + pci_write_config32(udc_dev, 0x7C, 0xDEADBEEF); - dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, - PCI_DEVICE_ID_AMD_CS5536_OTG, 0); - if (dev) - pci_write_config32(dev, 0x7C, 0xDEADBEEF); + if (otg_dev) + pci_write_config32(otg_dev, 0x7C, 0xDEADBEEF); } /** @@ -605,16 +617,6 @@ pci_write_config8(dev, IDE_CFG, ide_cfg); } - -static void hide_vpci(u32 vpci_devid) -{ - /* Hide unwanted virtual PCI device. */ - printk(BIOS_DEBUG, "Hiding VPCI device: 0x%08X\n", - vpci_devid); - outl(vpci_devid + 0x7C, 0xCF8); - outl(0xDEADBEEF, 0xCFC); -} - /** * TODO. * @@ -635,7 +637,7 @@ setup_i8259(); lpc_init(sb); - uarts_init(sb); + uarts_init(sb, dev); if (sb->enable_gpio_int_route) { printk(BIOS_SPEW, "cs5536: call vr_write\n"); From kevin at koconnor.net Thu May 8 02:19:14 2008 From: kevin at koconnor.net (Kevin O'Connor) Date: Wed, 7 May 2008 20:19:14 -0400 Subject: [coreboot] legacy bios support and coreboot In-Reply-To: <481FBF11.1080406@gmx.net> References: <20080506013626.GA25706@morn.localdomain> <481FBF11.1080406@gmx.net> Message-ID: <20080508001914.GA1617@morn.localdomain> On Tue, May 06, 2008 at 04:14:41AM +0200, Carl-Daniel Hailfinger wrote: > Hi Kevin, > > great writeup! Any chance you can add that to the coreboot wiki? > Thanks - I agree this should go a wiki. > On 06.05.2008 03:36, Kevin O'Connor wrote: > > [...] > > Some of the hardware accesses made by the "legacybios" code appear to > > be specific to hardware in the emulator. The code attempts to enable > > ram shadowing of the memory segment at 0xf00000 - it does this so that > > > > One zero too many? Yes, that should read 0xf0000. -Kevin From kevin at koconnor.net Thu May 8 02:25:32 2008 From: kevin at koconnor.net (Kevin O'Connor) Date: Wed, 7 May 2008 20:25:32 -0400 Subject: [coreboot] legacy bios support and coreboot In-Reply-To: References: Message-ID: <20080508002532.GB1617@morn.localdomain> Hi Aaron, On Wed, May 07, 2008 at 10:50:11AM +0800, aaron lwe wrote: > > The option rom scan and execution allows the bios code to call out to > > additional system roms. The "post" stage runs in 32bit mode, but the > > option roms are called in 16bit mode - the "legacybios" code simply > > transitions to/from 16bit mode to make these calls. The option rom > > code is executed natively on the processor. > > I think this is redundant with coreboot, since coreboot will also run > pci rom, eg. vga bios. I think coreboot only runs the vga bios and only in a simulator. I think it would be difficult to run some option roms (eg, scsi) from within an emulator. That said, I think it would be great to configure which roms got run, which got emulated, and which got skipped entirely. [...] > > Some of the hardware accesses made by the "legacybios" code appear to > > be specific to hardware in the emulator. The code attempts to enable > > ram shadowing of the memory segment at 0xf00000 - it does this so that > > it can put acpi/mptable/smbios tables into that area. After it is > > complete, it attempts to disable writes to that region. The code > > sequence looks to be specific to intel north/southbridges. It isn't > > necessary to disable writes to 0xf0000 (though it would be nice), but > > it is necessary to have the ability to alter that memory. > > This shadowing job should be left to coreboot, if someone is going to > use legacybios, he should take care of this shadowing job in ram init > code. That's fine, but it means the launched OS will be able to overwrite the 0xf0000 segment. It would be nice to write protect it, but it is not a huge issue. > I've written a loader for coreboot-v2 to load legacybios, it works > well when used with qemu, I've booted freebsd with it. But on real > hardware, via epia-cn, it hangs with a blank screen, the debug port > value is 0x31, I'll take some time to see what's going wrong. Changing the legacybios code to forward debug output to a serial port will definitely help here. > I add a header for legacybios to become a payload, this is done by a > utility createpayload. > I've attached the loader and the utility. > Signed-off-by: Aaron Lwe Thanks - I'll take a look. -Kevin From c-d.hailfinger.devel.2006 at gmx.net Thu May 8 02:26:51 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 08 May 2008 02:26:51 +0200 Subject: [coreboot] legacy bios support and coreboot In-Reply-To: <20080508001914.GA1617@morn.localdomain> References: <20080506013626.GA25706@morn.localdomain> <481FBF11.1080406@gmx.net> <20080508001914.GA1617@morn.localdomain> Message-ID: <482248CB.8080407@gmx.net> On 08.05.2008 02:19, Kevin O'Connor wrote: > On Tue, May 06, 2008 at 04:14:41AM +0200, Carl-Daniel Hailfinger wrote: > >> Hi Kevin, >> >> great writeup! Any chance you can add that to the coreboot wiki? >> > > Thanks - I agree this should go a wiki. > Do you have a coreboot wiki account? If not, there are two choices: * You ask Stefan or Ron for a wiki account * You tell me where the writeup should appear in the wiki. >> On 06.05.2008 03:36, Kevin O'Connor wrote: >> >>> [...] >>> Some of the hardware accesses made by the "legacybios" code appear to >>> be specific to hardware in the emulator. The code attempts to enable >>> ram shadowing of the memory segment at 0xf00000 - it does this so that >>> >>> >> One zero too many? >> > > Yes, that should read 0xf0000. > Thanks for confirming. Regards, Carl-Daniel From svn at coreboot.org Thu May 8 02:31:45 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Thu, 8 May 2008 02:31:45 +0200 Subject: [coreboot] r3291 - trunk/util/flashrom Message-ID: Author: stuge Date: 2008-05-08 02:31:44 +0200 (Thu, 08 May 2008) New Revision: 3291 Modified: trunk/util/flashrom/flashrom.c Log: flashrom: Probe for up to 3 flash chips. Currently there is an ongoing technology migration from LPC/FWH to SPI chips. For this reason some boards have multiple chips of different technologies onboard. This patch makes flashrom probe for up to 3 chips and if more than one chip is found flashrom exits, asking the user to specify -c. [root at localhost src]# ./flashrom ... Multiple flash chips were detected: SST49LF008A M25P16 at ICH9 Please specify which chip to use with the -c option. [root at localhost src]# Signed-off-by: Claus Gindhart Signed-off-by: Peter Stuge Acked-by: Claus Gindhart Modified: trunk/util/flashrom/flashrom.c =================================================================== --- trunk/util/flashrom/flashrom.c 2008-05-07 21:57:12 UTC (rev 3290) +++ trunk/util/flashrom/flashrom.c 2008-05-08 00:31:44 UTC (rev 3291) @@ -246,11 +246,12 @@ uint8_t *buf; unsigned long size; FILE *image; - struct flashchip *flash; + /* Probe for up to three flash chips. */ + struct flashchip *flash, *flashes[3]; int opt; int option_index = 0; int read_it = 0, write_it = 0, erase_it = 0, verify_it = 0; - int ret = 0; + int ret = 0, i; static struct option long_options[] = { {"read", 0, 0, 'r'}, @@ -405,12 +406,27 @@ board_flash_enable(lb_vendor, lb_part); - if ((flash = probe_flash(flashchips)) == NULL) { + for (i = 0; i < ARRAY_SIZE(flashes); i++) { + flashes[i] = probe_flash(i ? flashes[i - 1] + 1 : flashchips); + if (!flashes[i]) + for (i++; i < ARRAY_SIZE(flashes); i++) + flashes[i] = NULL; + } + + if (flashes[1]) { + printf("Multiple flash chips were detected:"); + for (i = 0; i < ARRAY_SIZE(flashes) && flashes[i]; i++) + printf(" %s", flashes[i]->name); + printf("\nPlease specify which chip to use with the -c option.\n"); + exit(1); + } else if (!flashes[0]) { printf("No EEPROM/flash device found.\n"); // FIXME: flash writes stay enabled! exit(1); } + flash = flashes[0]; + printf("Flash part is %s (%d KB).\n", flash->name, flash->total_size); if (TEST_OK_MASK != (flash->tested & TEST_OK_MASK)) { printf("===\n"); From peter at stuge.se Thu May 8 02:32:16 2008 From: peter at stuge.se (Peter Stuge) Date: Thu, 8 May 2008 02:32:16 +0200 Subject: [coreboot] flashrom: Probe for up to 3 flash chips. [was: Fix ambiguity, if a board is equipped with more than one chip] In-Reply-To: References: <200805051647.29834.claus.gindhart@kontron.com> <481F22C1.2050006@gmx.net> <20080505154903.20256.qmail@stuge.se> Message-ID: <20080508003216.23825.qmail@stuge.se> On Tue, May 06, 2008 at 09:01:07AM +0200, Claus Gindhart wrote: > i've tested the patch, it worked; i've acked-by the attached patch. Thanks! rev 3291. //Peter From rminnich at gmail.com Thu May 8 02:51:08 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 7 May 2008 17:51:08 -0700 Subject: [coreboot] [PATCH] [RFC] v3: CS5536 cleanup In-Reply-To: <4822458B.4030506@gmx.net> References: <48205A47.5060403@gmx.net> <4822458B.4030506@gmx.net> Message-ID: <13426df10805071751p7adb40c8s759875e09ccee15@mail.gmail.com> will test tonight or tomorrow night. Am on short trip. ron From kevin at koconnor.net Thu May 8 03:34:38 2008 From: kevin at koconnor.net (Kevin O'Connor) Date: Wed, 7 May 2008 21:34:38 -0400 Subject: [coreboot] legacy bios support and coreboot In-Reply-To: <20080508002532.GB1617@morn.localdomain> References: <20080508002532.GB1617@morn.localdomain> Message-ID: <20080508013438.GC1617@morn.localdomain> On Wed, May 07, 2008 at 08:25:32PM -0400, Kevin O'Connor wrote: > On Wed, May 07, 2008 at 10:50:11AM +0800, aaron lwe wrote: > > I've written a loader for coreboot-v2 to load legacybios, it works > > well when used with qemu, I've booted freebsd with it. But on real > > hardware, via epia-cn, it hangs with a blank screen, the debug port > > value is 0x31, I'll take some time to see what's going wrong. > > Changing the legacybios code to forward debug output to a serial port > will definitely help here. FYI, the latest legacybios git repo has the serial debug option. To enable, modify src/config.h and turn on CONFIG_DEBUG_SERIAL. I've only tested this with qemu. -Kevin From joe at settoplinux.org Thu May 8 03:44:22 2008 From: joe at settoplinux.org (Joe) Date: Wed, 7 May 2008 21:44:22 -0400 Subject: [coreboot] [PATCH] Implement GPIO configuration options forIntel 3100 southbridge In-Reply-To: References: <33013914cf0ec2a592a8a9404c6f07c3@imap.1and1.com> Message-ID: > -----Original Message----- > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] > On Behalf Of Ed Swierk > Sent: Wednesday, May 07, 2008 5:44 PM > To: coreboot at coreboot.org > Subject: Re: [coreboot] [PATCH] Implement GPIO configuration options > forIntel 3100 southbridge > > On Wed, May 7, 2008 at 2:28 PM, Joe wrote: > > The gpio settings very from board to board. Why not leave this up to > the > > mainboard? > > Some settings are board-specific but others are required by the > chipset. For example the Intel 3100 datasheet says software is > required to drive a handful of GPIOs in a particular way. > > As long as the chipset code has to deal with GPIOs, it may as well try > to abstract away some of the boilerplate code and magic values, making > it easier to port to a new mainboard. > > And the code already exists, so why not use it? > I guess it is just a matter of how you want to set it up. Either way works fine. Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org From aaron.lwe at gmail.com Thu May 8 03:54:18 2008 From: aaron.lwe at gmail.com (aaron lwe) Date: Thu, 8 May 2008 09:54:18 +0800 Subject: [coreboot] legacy bios support and coreboot In-Reply-To: <20080508002532.GB1617@morn.localdomain> References: <20080508002532.GB1617@morn.localdomain> Message-ID: > I think coreboot only runs the vga bios and only in a simulator. I > think it would be difficult to run some option roms (eg, scsi) from > within an emulator. That said, I think it would be great to configure > which roms got run, which got emulated, and which got skipped > entirely. Cool. BTW, for via epia-cn, vgabios is not run by emulator, but by switching back to real mode and call the rom code. I think this is the same way legacybios did. Maybe we can have a config option to let coreboot know when we are using legacybios we can omit runnning pci roms and let legacybios takes care, but when using other payloads, the pci rom code should still be run by emulator or vm86. > That's fine, but it means the launched OS will be able to overwrite > the 0xf0000 segment. It would be nice to write protect it, but it is > not a huge issue. yes, the problem is legacybios cannot know all the chipsets' specific register settings for shadow ram, so it would be impossible unless we pass some info from coreboot to legacybios. > Changing the legacybios code to forward debug output to a serial port > will definitely help here. thanks and I've added serial code and now able to see the output. It seems that legacybios cannot detect the ide disk... It said: ata0 master: unknown device. Maybe the ata code is ok for qemu emulated dirves but not for real hardware. I'll take a look at it. Thanks From corey.osgood at gmail.com Thu May 8 04:01:03 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Wed, 7 May 2008 22:01:03 -0400 Subject: [coreboot] Unable to flash Pm49FL004 In-Reply-To: <3aef9cce0805071345r340d42bdr2a3678c478a4e84f@mail.gmail.com> References: <3aef9cce0805070628r27ac0af1yf4a7b28765f40472@mail.gmail.com> <3aef9cce0805071345r340d42bdr2a3678c478a4e84f@mail.gmail.com> Message-ID: Don't feel too stupid, I made the same mistake ;) -Corey On Wed, May 7, 2008 at 4:45 PM, Richard Stellingwerff wrote: > Okay I feel like an idiot right now. Flash write protect was indeed > enabled in the BIOS. It works great now that I've disabled it. Thanks > :) > > Kind regards, > Richard. > > On Wed, May 7, 2008 at 7:15 PM, Corey Osgood > wrote: > > Check in the factory BIOS that BIOS write protect is set to off. If > there is > > no such option, then you might have to do some work to turn the BIOS > write > > protection off. Check the flashrom board enables for other > vt8237r-based > > boards (epia cn, etc) for hints. > > > > -Corey > > > > > > > > On Wed, May 7, 2008 at 9:28 AM, Richard Stellingwerff > > > wrote: > > > > > > > > > > > > Hi all, > > > > > > I finally got myself a PLCC extractor so I can start getting coreboot > > > to work on my Jetway J7F4K1G2E-PB board. However, I'm already running > > > into a problem trying to write the original bios on the Pm49FL004. > > > Extracting the BIOS from the original ROM works fine, but trying to > > > write it into the new chip (after hot-swapping them) results in this: > > > > > > # flashrom -wv backup.bin > > > Calibrating delay loop... OK. > > > No coreboot table found. > > > Found chipset "VIA VT8237", enabling flash write... OK. > > > Pm49FL004 found at physical address 0xfff80000. > > > Flash part is Pm49FL004 (512 KB). > > > === > > > This flash part has status UNTESTED for operations: PROBE READ ERASE > WRITE > > > Please email a report to flashrom at coreboot.org if any of the above > > operations > > > work correctly for you with this flash part. Please include the full > > output > > > from the program, including chipset found. Thank you for your help! > > > === > > > Flash image seems to be a legacy BIOS. Disabling checks. > > > Programming page: 0007 at address: 0x00070000 > > > Verifying flash... FAILED! > > > > > > Reading from the Pm49FL004 returns all FF's (checked with hexedit). > > > > > > I compiled flashrom myself from SVN a few minutes ago. > > > > > > Anyone know what I can do? > > > > > > Kind regards, > > > Richard Stellingwerff. > > > > > > -- > > > coreboot mailing list > > > coreboot at coreboot.org > > > http://www.coreboot.org/mailman/listinfo/coreboot > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bari at onelabs.com Thu May 8 04:02:53 2008 From: bari at onelabs.com (bari) Date: Wed, 07 May 2008 21:02:53 -0500 Subject: [coreboot] legacy bios support and coreboot In-Reply-To: References: <20080508002532.GB1617@morn.localdomain> Message-ID: <48225F4D.30900@onelabs.com> aaron lwe wrote: > Cool. BTW, for via epia-cn, vgabios is not run by emulator, but by > switching back to real mode and call the rom code. I think this is the > same way legacybios did. Maybe we can have a config option to let > coreboot know when we are using legacybios we can omit runnning pci > roms and let legacybios takes care, but when using other payloads, the > pci rom code should still be run by emulator or vm86. > > Do you have a working version of coreboot for the epia-cn? -Bari From c-d.hailfinger.devel.2006 at gmx.net Thu May 8 04:09:52 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 08 May 2008 04:09:52 +0200 Subject: [coreboot] v3 IRQ table strangeness Message-ID: <482260F0.1020604@gmx.net> Hi, is it intentional that irq_tables.h in all v3 AMD GeodeLX/CS5536 targets lists the "NatSemi CS5535 ISA Bridge" at 00:0f.0 as interrupt router? By the way, the dbe61 patch Mart sent tonight changes that for dbe61 to the "CS5536 GeodeLink PCI South Bridge" at 00:12.0 as interrupt router. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Thu May 8 04:11:04 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 08 May 2008 04:11:04 +0200 Subject: [coreboot] [PATCH] artecgroup/dbe61: Sync irq_tables with dbe62 code to fix compilation and have a chance of working properly. In-Reply-To: <50843.62.65.221.151.1210195701.squirrel@www.artecdesign.ee> References: <50843.62.65.221.151.1210195701.squirrel@www.artecdesign.ee> Message-ID: <48226138.1050604@gmx.net> Hi, On 07.05.2008 23:28, Mart Raudsepp wrote: > Here's a patch that fixes DBE61 target compilation by making irq_tables.h > take the v3 approach. It might actually work on hardware regarding > interrupt setup, but we need to get the raminit to work properly to see... > so this is in the name of compilation fix and common sense that as all the > IRQ routing is the same in DBE61 and DBE62, that the routing settings in > dbe62 code should be fine for dbe61 as well. > Well, if the IRQ routing is the same in DBE61 and DBE62, why do the tables differ after your patch? Regards, Carl-Daniel From aaron.lwe at gmail.com Thu May 8 04:32:48 2008 From: aaron.lwe at gmail.com (aaron lwe) Date: Thu, 8 May 2008 10:32:48 +0800 Subject: [coreboot] legacy bios support and coreboot In-Reply-To: <48225F4D.30900@onelabs.com> References: <20080508002532.GB1617@morn.localdomain> <48225F4D.30900@onelabs.com> Message-ID: > Do you have a working version of coreboot for the epia-cn? I attached the auto.c for epia-cn, the northbridge cn700 and southbridge vt8237r code are all available at svn src tree. note that for cn700 dram enable, the value for enable dll should be 0x120000, default ocd calibration should be 0x121c20 and exit calibration mode should be 0x120020. These values worked for me. If you still have problem with dram init, you should also change the values of D0F2 to be the same with your factory bios'. The serial code is from vt8235. I cannot make sata work with filo(not sure what's the problem), so I disabled sata in auto.c. Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: auto.c Type: text/x-csrc Size: 3488 bytes Desc: not available URL: From bari at onelabs.com Thu May 8 04:54:08 2008 From: bari at onelabs.com (bari) Date: Wed, 07 May 2008 21:54:08 -0500 Subject: [coreboot] legacy bios support and coreboot In-Reply-To: References: <20080508002532.GB1617@morn.localdomain> <48225F4D.30900@onelabs.com> Message-ID: <48226B50.3050908@onelabs.com> aaron lwe wrote: >> Do you have a working version of coreboot for the epia-cn? >> > > I attached the auto.c for epia-cn, the northbridge cn700 and > southbridge vt8237r code are all available at svn src tree. note that > for cn700 dram enable, the value for enable dll should be 0x120000, > default ocd calibration should be 0x121c20 and exit calibration mode > should be 0x120020. These values worked for me. If you still have > problem with dram init, you should also change the values of D0F2 to > be the same with your factory bios'. > > The serial code is from vt8235. > > I cannot make sata work with filo(not sure what's the problem), so I > disabled sata in auto.c. > > Thanks > I'm having problems with FILO on the same board. I don't have IDE working yet either. I'll try your patch and compare results. -Bari From rminnich at gmail.com Thu May 8 05:50:41 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 7 May 2008 20:50:41 -0700 Subject: [coreboot] v3 IRQ table strangeness In-Reply-To: <482260F0.1020604@gmx.net> References: <482260F0.1020604@gmx.net> Message-ID: <13426df10805072050p1317b302yba1a4c30077f9960@mail.gmail.com> On Wed, May 7, 2008 at 7:09 PM, Carl-Daniel Hailfinger wrote: > Hi, > > is it intentional that irq_tables.h in all v3 AMD GeodeLX/CS5536 targets > lists the "NatSemi CS5535 ISA Bridge" at 00:0f.0 as interrupt router? > > By the way, the dbe61 patch Mart sent tonight changes that for dbe61 to > the "CS5536 GeodeLink PCI South Bridge" at 00:12.0 as interrupt router. > we can change it, the old name is historical ron From mart.raudsepp at artecdesign.ee Thu May 8 07:39:36 2008 From: mart.raudsepp at artecdesign.ee (Mart Raudsepp) Date: Thu, 8 May 2008 08:39:36 +0300 (EEST) Subject: [coreboot] [PATCH] artecgroup/dbe61: Sync irq_tables with dbe62 code to fix compilation and have a chance of working properly. Message-ID: <46135.62.65.221.151.1210225176.squirrel@www.artecdesign.ee> > Hi, > > On 07.05.2008 23:28, Mart Raudsepp wrote: >> Here's a patch that fixes DBE61 target compilation by making >> irq_tables.h >> take the v3 approach. It might actually work on hardware regarding >> interrupt setup, but we need to get the raminit to work properly to >> see... >> so this is in the name of compilation fix and common sense that as all >> the >> IRQ routing is the same in DBE61 and DBE62, that the routing settings in >> dbe62 code should be fine for dbe61 as well. >> > > Well, if the IRQ routing is the same in DBE61 and DBE62, why do the > tables differ after your patch? They differ in the interrupt router and IRQs devoted fields only, as told in the proposed commit message on top of the attachment together with the reason. And the vendor/device are AMD instead of NSC I believe. The interrupt line routing tuples are the same and it makes it compile and not worse. What does "IRQs devoted exclusively to PCI usage" value affect? Mart Raudsepp From bari at onelabs.com Thu May 8 08:08:35 2008 From: bari at onelabs.com (bari) Date: Thu, 08 May 2008 01:08:35 -0500 Subject: [coreboot] legacy bios support and coreboot In-Reply-To: References: <20080508002532.GB1617@morn.localdomain> <48225F4D.30900@onelabs.com> Message-ID: <482298E3.6070308@onelabs.com> Your auto.c includes: #include "southbridge/via/vt8237r/vt8237r_early_serial.c" this is not in the current tree. Please send a copy of this file. Regards, Bari aaron lwe wrote: >> Do you have a working version of coreboot for the epia-cn? >> > > I attached the auto.c for epia-cn, the northbridge cn700 and > southbridge vt8237r code are all available at svn src tree. note that > for cn700 dram enable, the value for enable dll should be 0x120000, > default ocd calibration should be 0x121c20 and exit calibration mode > should be 0x120020. These values worked for me. If you still have > problem with dram init, you should also change the values of D0F2 to > be the same with your factory bios'. > > The serial code is from vt8235. > > I cannot make sata work with filo(not sure what's the problem), so I > disabled sata in auto.c. > > Thanks > From aaron.lwe at gmail.com Thu May 8 08:17:17 2008 From: aaron.lwe at gmail.com (aaron lwe) Date: Thu, 8 May 2008 14:17:17 +0800 Subject: [coreboot] legacy bios support and coreboot In-Reply-To: <482298E3.6070308@onelabs.com> References: <20080508002532.GB1617@morn.localdomain> <48225F4D.30900@onelabs.com> <482298E3.6070308@onelabs.com> Message-ID: > Your auto.c includes: > #include "southbridge/via/vt8237r/vt8237r_early_serial.c" > > this is not in the current tree. Please send a copy of this file. vt8237r_early_serial.c is identical with vt8235_early_serial.c -Aaron From corey.osgood at gmail.com Thu May 8 08:18:44 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Thu, 8 May 2008 02:18:44 -0400 Subject: [coreboot] legacy bios support and coreboot In-Reply-To: <482298E3.6070308@onelabs.com> References: <20080508002532.GB1617@morn.localdomain> <48225F4D.30900@onelabs.com> <482298E3.6070308@onelabs.com> Message-ID: Can I get a copy of both of your trees, and I'll try to get it working again? I've got the next couple days off, and I should be working on my project car, but I supposed I can take a break for a little coreboot. My last rendition before I lost everything had both IDE and SATA working, and before that I had them working individually, but not both at once. -Corey On Thu, May 8, 2008 at 2:08 AM, bari wrote: > Your auto.c includes: > #include "southbridge/via/vt8237r/vt8237r_early_serial.c" > > this is not in the current tree. Please send a copy of this file. > > Regards, > > Bari > > aaron lwe wrote: > >> Do you have a working version of coreboot for the epia-cn? > >> > > > > I attached the auto.c for epia-cn, the northbridge cn700 and > > southbridge vt8237r code are all available at svn src tree. note that > > for cn700 dram enable, the value for enable dll should be 0x120000, > > default ocd calibration should be 0x121c20 and exit calibration mode > > should be 0x120020. These values worked for me. If you still have > > problem with dram init, you should also change the values of D0F2 to > > be the same with your factory bios'. > > > > The serial code is from vt8235. > > > > I cannot make sata work with filo(not sure what's the problem), so I > > disabled sata in auto.c. > > > > Thanks > > > > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From viswesh_vichu at yahoo.com Thu May 8 08:45:20 2008 From: viswesh_vichu at yahoo.com (Viswesh S) Date: Wed, 7 May 2008 23:45:20 -0700 (PDT) Subject: [coreboot] AMDk8 - HT routing Message-ID: <438049.12941.qm@web31604.mail.mud.yahoo.com> Hi, I understand that before the node ids are being assigned, each AP node is considered as Node7. We will just go through the sequence of code in setup_smp2() in coherent_ht.c. From the link type register 0x98, in Node0, it is seen that link1 is coherent and connected. setup_row_local(0, 0); /* it will update the broadcast RT*/ // value is 0x50101 in F0 register 0x40 val = get_row(0,0); byte = (val>>16) & 0xfe; // byte = 0xf4 if(byte<0x2) { /* no coherent connection so get out.*/ nodes = 1; return nodes; } /* Setup and check a temporary connection to node 1 */ #if TRY_HIGH_FIRST == 1 byte = get_linkn_last(byte); /* Max Link to node1 */ #else // TRY_HIGH_FIRST = 0 here byte = get_linkn_first(byte); /*Min Link to node1 --- according to AMD*/ #endif // byte = 1 print_linkn("(0,1) link=", byte); setup_row_direct(0,1, byte); // ( We are modifying the routing register 0x44, which is for the connection between Node0 and Node1. So here itself we consider Node1 itself and node7, though we copy the value from register 0x44 to 0x5c in the next function. setup_temp_row(0, 1); // As mentioned, we copy the value from 0x44 to 0x5c, ie setting up of routing register for connection between node0 and node7 --> which is actually AP verify_connection(7); // Here is where I get confused.See verify the connection tries to read the 0x0 register from Node7, which doesnt exist at all.ie in our case node0 has device address 0x18 and hence node7 will have 0x18+7 = 0x1f and such a device doesnt exist at all if you do lspci. 00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) 00:01.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01) 00:02.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) 00:02.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01) 00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07) 00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05) 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03) 00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b) 01:00.1 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b) 01:06.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) So then what value do we read..The same question arises for the next function also - /* We found 2 nodes so far */ val = pci_read_config32(NODE_HT(7), 0x6c); // Here also the same issues arises byte = (val>>2) & 0x3; /*get default link on node7 to node0*/ print_linkn("(1,0) link=", byte); setup_row_local(7,1); setup_remote_row_direct(1, 0, byte); Viswesh Bring your gang together. Do your thing. Find your favourite Yahoo! group at http://in.promos.yahoo.com/groups/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rms at gnu.org Thu May 8 10:44:05 2008 From: rms at gnu.org (Richard M Stallman) Date: Thu, 08 May 2008 04:44:05 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: <48218300.4060901@coresystems.de> (message from Stefan Reinauer on Wed, 07 May 2008 12:22:56 +0200) References: <4820EA9D.6040204@gmx.net> <48218300.4060901@coresystems.de> Message-ID: I remember it suddenly got harder talking to a very friendly CPU vendor after they bought a graphics chip vendor, because one guy started running around with a halo, telling that people should not buy from that very graphics chip vendor, in a half-reflected way, similar to those my ancestor countrymen suggested not to buy from certain groups of people. As far as I know, I am the only person who protested a graphics chip vendor, so this must be intended to refer to me. Which means it is inaccurate. Omitting my name doesn't make that ok. Whether or not you agree with my approach, calling it "half-reflected" is sheer name-calling based on ignorance. To equate boycotting a company with racism is worse than ignorance. It is absurd. From yinghailu at gmail.com Thu May 8 10:59:11 2008 From: yinghailu at gmail.com (yhlu) Date: Thu, 8 May 2008 01:59:11 -0700 Subject: [coreboot] AMDk8 - HT routing In-Reply-To: <438049.12941.qm@web31604.mail.mud.yahoo.com> References: <438049.12941.qm@web31604.mail.mud.yahoo.com> Message-ID: <2ea3fae10805080159w53d294d0qc20f9c1e1442d1fd@mail.gmail.com> On Wed, May 7, 2008 at 11:45 PM, Viswesh S wrote: > > Hi, > > I understand that before the node ids are being assigned, each AP node is > considered as Node7. We will just go through the sequence of code in > setup_smp2() in coherent_ht.c. > > From the link type register 0x98, in Node0, it is seen that link1 is > coherent and connected. > > > setup_row_local(0, 0); /* it will update the broadcast RT*/ // value is > 0x50101 in F0 register 0x40 > > val = get_row(0,0); > byte = (val>>16) & 0xfe; // byte = 0xf4 > if(byte<0x2) { /* no coherent connection so get out.*/ > nodes = 1; > return nodes; > } > /* Setup and check a temporary connection to node 1 */ > #if TRY_HIGH_FIRST == 1 > byte = get_linkn_last(byte); /* Max Link to node1 */ > #else // TRY_HIGH_FIRST = 0 here > byte = get_linkn_first(byte); /*Min Link to node1 --- according to AMD*/ > #endif // byte = 1 > > > print_linkn("(0,1) link=", byte); > setup_row_direct(0,1, byte); // ( We are modifying the routing register > 0x44, which is for the connection between Node0 and Node1. So here itself we > consider Node1 itself and node7, though we copy the value from register 0x44 > to 0x5c in the next function. > > setup_temp_row(0, 1); // As mentioned, we copy the value from 0x44 to > 0x5c, ie setting up of routing register for connection between node0 and > node7 --> which is actually AP > > verify_connection(7); // Here is where I get confused.See verify the > connection tries to read the 0x0 register from Node7, which doesnt exist at > all.ie in our case node0 has device address 0x18 and hence node7 will have > 0x18+7 = 0x1f and such a device doesnt exist at all if you do lspci. > > 00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev > 12) > 00:01.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01) > 00:02.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev > 12) > 00:02.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01) > 00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07) > 00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05) > 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03) > 00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05) > 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > HyperTransport Technology Configuration > 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Address Map > 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM > Controller > 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Miscellaneous Control > 00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > HyperTransport Technology Configuration > 00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Address Map > 00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM > Controller > 00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Miscellaneous Control > 01:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b) > 01:00.1 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b) > 01:06.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) > > So then what value do we read..The same question arises for the next > function also - > /* We found 2 nodes so far */ > val = pci_read_config32(NODE_HT(7), 0x6c); // Here also the same issues > arises > byte = (val>>2) & 0x3; /*get default link on node7 to node0*/ > print_linkn("(1,0) link=", byte); > setup_row_local(7,1); > setup_remote_row_direct(1, 0, byte); > before enable_routing(), that node is still node 7. after enable_routing, the node will start to use routing table in it, and core0 in that node will start to fetch code from reset vector and start to run... YH From joe at settoplinux.org Thu May 8 14:04:36 2008 From: joe at settoplinux.org (Joe) Date: Thu, 8 May 2008 08:04:36 -0400 Subject: [coreboot] [Fwd: Re: Contact Intel] In-Reply-To: References: <4820EA9D.6040204@gmx.net><48218300.4060901@coresystems.de> Message-ID: <7195D9A0337945FFB0641E8A1BD86012@smitty2m> Come on Richard, enough is enough. No one is talking about racism here. You are taking this way too far. You have too much time on your hands. Can we just move on, please. Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org > -----Original Message----- > From: coreboot-bounces+joe=settoplinux.org at coreboot.org [mailto:coreboot- > bounces+joe=settoplinux.org at coreboot.org] On Behalf Of Richard M Stallman > Sent: Thursday, May 08, 2008 4:44 AM > To: Stefan Reinauer > Cc: corey.osgood at gmail.com; c-d.hailfinger.devel.2006 at gmx.net; > coreboot at coreboot.org > Subject: Re: [coreboot] [Fwd: Re: Contact Intel] > >> I remember it suddenly got harder talking to a very friendly CPU >> vendor after they bought a graphics chip vendor, because one guy started >> running around with a halo, telling that people should not buy from >> that very graphics chip vendor, in a half-reflected way, similar to those >> my ancestor countrymen suggested not to buy from certain groups of >> people. > > As far as I know, I am the only person who protested a graphics chip > vendor, so this must be intended to refer to me. Which means it is > inaccurate. Omitting my name doesn't make that ok. > > Whether or not you agree with my approach, calling it "half-reflected" > is sheer name-calling based on ignorance. > > To equate boycotting a company with racism is worse than ignorance. > It is absurd. > > > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From svn at coreboot.org Thu May 8 15:50:24 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Thu, 8 May 2008 15:50:24 +0200 Subject: [coreboot] r3292 - trunk/util/superiotool Message-ID: Author: uwe Date: 2008-05-08 15:50:23 +0200 (Thu, 08 May 2008) New Revision: 3292 Modified: trunk/util/superiotool/ite.c trunk/util/superiotool/superiotool.h Log: Don't split up register list in two blocks, otherwise "Register dump:" will be printed twice in the output (trivial). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/util/superiotool/ite.c =================================================================== --- trunk/util/superiotool/ite.c 2008-05-08 00:31:44 UTC (rev 3291) +++ trunk/util/superiotool/ite.c 2008-05-08 13:50:23 UTC (rev 3292) @@ -332,20 +332,19 @@ 0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39, 0x3a,0x3b,0x3c,0x3d,0x3e,0x3f,0x40,0x41,0x42,0x43, 0x44,0x45,0x48,0x50,0x51,0x52,0x53,0x54,0x56,0x57, - 0x59,0x5c,EOT}, + 0x59,0x5c, + 0x5d,0x5e,0x5f,0x60,0x61,0x62,0x63,0x64,0x65,0x68, + 0x69,0x6a,0x6b,0x6c,0x6d,0x70,0x71,0x72,0x73,0x74, + 0x75,0x84,0x85,0x86,0x87,0x88,0x89,0x8c,0x8d,0x8e, + 0x8f,0x90,0x91,0x92,0x93,0x94,0x95,0x98,0x99,0x9a, + 0x9b,0x9c,0x9d,EOT}, {0x18,0x00,0x00,0x00,0x00,0x00,0x80,0x09,0x00,NANA, NANA,NANA,0x07,0x50,NANA,NANA,NANA,NANA,NANA,NANA, NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA, NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA, NANA,NANA,RSVD,0x00,0x00,0x7f,0x7f,0x7f,0x00,0x00, - 0x00,0x00,EOT}}, - {NOLDN, NULL, - {0x5d,0x5e,0x5f,0x60,0x61,0x62,0x63,0x64,0x65,0x68, - 0x69,0x6a,0x6b,0x6c,0x6d,0x70,0x71,0x72,0x73,0x74, - 0x75,0x84,0x85,0x86,0x87,0x88,0x89,0x8c,0x8d,0x8e, - 0x8f,0x90,0x91,0x92,0x93,0x94,0x95,0x98,0x99,0x9a, - 0x9b,0x9c,0x9d,EOT}, - {0x00,0x00,0x00,0x7f,0x7f,0x7f,0x00,0x00,0x7f,0x7f, + 0x00,0x00, + 0x00,0x00,0x00,0x7f,0x7f,0x7f,0x00,0x00,0x7f,0x7f, 0x7f,0x7f,0x00,0x00,0x7f,0x7f,0x7f,0x7f,0x00,0x00, 0x7f,NANA,NANA,NANA,NANA,0x00,0x00,0x02,0x00,0x99, 0x99,0x7f,0x7f,0x7f,0x00,0x00,0x7f,0x7f,0x7f,0x7f, Modified: trunk/util/superiotool/superiotool.h =================================================================== --- trunk/util/superiotool/superiotool.h 2008-05-08 00:31:44 UTC (rev 3291) +++ trunk/util/superiotool/superiotool.h 2008-05-08 13:50:23 UTC (rev 3292) @@ -53,7 +53,7 @@ #define MISC -5 /* Needs special comment in output */ #define MAXLDN 0x10 /* Biggest LDN */ #define LDNSIZE (MAXLDN + 3) /* Biggest LDN + 0 + NOLDN + EOT */ -#define MAXNUMIDX 70 /* Maximum number of indexes */ +#define MAXNUMIDX 170 /* Maximum number of indexes */ #define IDXSIZE (MAXNUMIDX + 1) #define MAXNUMPORTS (6 + 1) /* Maximum number of Super I/O ports */ From mylesgw at gmail.com Thu May 8 15:51:25 2008 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 8 May 2008 07:51:25 -0600 Subject: [coreboot] legacy bios support and coreboot In-Reply-To: References: <20080508002532.GB1617@morn.localdomain> Message-ID: <010b01c8b112$9c065ed0$1a02a8c0@chimp> > > Changing the legacybios code to forward debug output to a serial port > > will definitely help here. > > thanks and I've added serial code and now able to see the output. It > seems that legacybios cannot detect the ide disk... It said: ata0 > master: unknown device. Maybe the ata code is ok for qemu emulated > dirves but not for real hardware. I'll take a look at it. I think this is a board-specific problem. The IDE code works on my Tyan boards. Thanks, Myles From c-d.hailfinger.devel.2006 at gmx.net Thu May 8 15:54:58 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 08 May 2008 15:54:58 +0200 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead Message-ID: <48230632.7070401@gmx.net> Hi, since the Geode/CS553x platform emulates PCI headers for chipset/processor devices, we have the ability to switch off that emulation and hide those virtual PCI headers. Right now we do this in a fairly uncoordinated fashion: I counted at least three different open-coded code sequences with the same effect. My current plan is: - encapsulate all those code sequences into calls of one or two functions - switch all calls from hide_vpci(some_value_calculated_by_hand) to hide_vpci_dev(struct device *) - replace the central array of hand-calculated values with a per-PCI-device "hidden" property. This should result in an overall improvement of code readability and a reduction of code size. As a nice side benefit the dts is a lot easier to manipulate. Questions? Comments? Regards, Carl-Daniel -- http://www.hailfinger.org/ From mylesgw at gmail.com Thu May 8 15:56:58 2008 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 8 May 2008 07:56:58 -0600 Subject: [coreboot] legacy bios support and coreboot In-Reply-To: References: Message-ID: <010c01c8b113$624c6d50$1a02a8c0@chimp> > I've written a loader for coreboot-v2 to load legacybios, it works > well when used with qemu, I've booted freebsd with it. But on real > hardware, via epia-cn, it hangs with a blank screen, the debug port > value is 0x31, I'll take some time to see what's going wrong. > > I add a header for legacybios to become a payload, this is done by a > utility createpayload. > I've attached the loader and the utility. > Signed-off-by: Aaron Lwe It seems like it would be fairly easy to make this compile as a normal ELF payload, and thus be able to use it with v3 as well. Have you thought about the pros and cons? Thanks, Myles From stepan at coresystems.de Thu May 8 16:04:19 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 08 May 2008 16:04:19 +0200 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <48230632.7070401@gmx.net> References: <48230632.7070401@gmx.net> Message-ID: <48230863.7040604@coresystems.de> Carl-Daniel Hailfinger wrote: > Hi, > > since the Geode/CS553x platform emulates PCI headers for > chipset/processor devices, we have the ability to switch off that > emulation and hide those virtual PCI headers. Right now we do this in a > fairly uncoordinated fashion: I counted at least three different > open-coded code sequences with the same effect. > > My current plan is: > - encapsulate all those code sequences into calls of one or two functions > - switch all calls from hide_vpci(some_value_calculated_by_hand) to > hide_vpci_dev(struct device *) > - replace the central array of hand-calculated values with a > per-PCI-device "hidden" property. > > This should result in an overall improvement of code readability and a > reduction of code size. As a nice side benefit the dts is a lot easier > to manipulate. > I like this idea a lot. Maybe we could use the already existing "enabled" property for that? Usually if a device is not "enabled", coreboot would not assign resources to it. Instead, if the device driver knows how to disable the device, it could completely disable it. I think the i82801xx driver in v2 attempts a similar thing. Stefan From c-d.hailfinger.devel.2006 at gmx.net Thu May 8 16:12:12 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 08 May 2008 16:12:12 +0200 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <48230863.7040604@coresystems.de> References: <48230632.7070401@gmx.net> <48230863.7040604@coresystems.de> Message-ID: <48230A3C.2010707@gmx.net> On 08.05.2008 16:04, Stefan Reinauer wrote: > Carl-Daniel Hailfinger wrote: > >> Hi, >> >> since the Geode/CS553x platform emulates PCI headers for >> chipset/processor devices, we have the ability to switch off that >> emulation and hide those virtual PCI headers. Right now we do this in a >> fairly uncoordinated fashion: I counted at least three different >> open-coded code sequences with the same effect. >> >> My current plan is: >> - encapsulate all those code sequences into calls of one or two functions >> - switch all calls from hide_vpci(some_value_calculated_by_hand) to >> hide_vpci_dev(struct device *) >> - replace the central array of hand-calculated values with a >> per-PCI-device "hidden" property. >> >> This should result in an overall improvement of code readability and a >> reduction of code size. As a nice side benefit the dts is a lot easier >> to manipulate. >> >> > I like this idea a lot. > > Maybe we could use the already existing "enabled" property for that? > Usually if a device is not "enabled", coreboot would not assign > resources to it. Instead, if the device driver knows how to disable the > device, it could completely disable it. I think the i82801xx driver in > v2 attempts a similar thing. > Interesting proposal. If I understand you correctly, enabled=0 would mean - disabled on all chipsets - hidden on those chipsets where hiding is supported. There are two problems I have with that approach, though: - I don't understand PCI well enough to know how a device is disabled. Does disabling the device mean disabling the resources as well? Does it mean the device won't respond to config cycles outside a special "enable cycle" anymore? - With automatic hiding, we lose the ability to leave a device untouched. Do we need an enum(disabled, hidden, enabled, untouched) for a full representation of possible states? Regards, Carl-Daniel From rminnich at gmail.com Thu May 8 16:13:52 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 8 May 2008 07:13:52 -0700 Subject: [coreboot] ARM joins UEFI Message-ID: <13426df10805080713k6d19b633w583488c32557365b@mail.gmail.com> A friend writes: http://www.industrial-europe.com/207501172 This second article is almost funny in that it contradicts the direction that UEFI takes. http://www.industrial-europe.com/207600269 amazing. Put an OS in the BIOS FLASH part. Now who would ever have thought of such a ridiculous idea. ron From rminnich at gmail.com Thu May 8 16:17:37 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 8 May 2008 07:17:37 -0700 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <48230A3C.2010707@gmx.net> References: <48230632.7070401@gmx.net> <48230863.7040604@coresystems.de> <48230A3C.2010707@gmx.net> Message-ID: <13426df10805080717w5a57f6efu380a8807f4e6e55a@mail.gmail.com> you need an enum or you need a new variable. Hiding and enabled are different. not enable does not imply not visible. So it's 2 bits on way or another :-) I like the idea. I like the way you guys are pushing for really using the device tree. thanks ron From rminnich at gmail.com Thu May 8 16:17:37 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 8 May 2008 07:17:37 -0700 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <48230A3C.2010707@gmx.net> References: <48230632.7070401@gmx.net> <48230863.7040604@coresystems.de> <48230A3C.2010707@gmx.net> Message-ID: <13426df10805080717w5a57f6efu380a8807f4e6e55a@mail.gmail.com> you need an enum or you need a new variable. Hiding and enabled are different. not enable does not imply not visible. So it's 2 bits on way or another :-) I like the idea. I like the way you guys are pushing for really using the device tree. thanks ron From stepan at coresystems.de Thu May 8 16:22:35 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 08 May 2008 16:22:35 +0200 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <13426df10805080717w5a57f6efu380a8807f4e6e55a@mail.gmail.com> References: <48230632.7070401@gmx.net> <48230863.7040604@coresystems.de> <48230A3C.2010707@gmx.net> <13426df10805080717w5a57f6efu380a8807f4e6e55a@mail.gmail.com> Message-ID: <48230CAB.6070308@coresystems.de> ron minnich wrote: > you need an enum or you need a new variable. Hiding and enabled are different. > > Why would you not hide a non-enabled device? > not enable does not imply not visible. So it's 2 bits on way or another :-) > In Linux it is, isn't it? I thought to remember it won't show devices with no BARs set up.. From c-d.hailfinger.devel.2006 at gmx.net Thu May 8 16:24:17 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 08 May 2008 16:24:17 +0200 Subject: [coreboot] ARM joins UEFI In-Reply-To: <13426df10805080713k6d19b633w583488c32557365b@mail.gmail.com> References: <13426df10805080713k6d19b633w583488c32557365b@mail.gmail.com> Message-ID: <48230D11.1050901@gmx.net> On 08.05.2008 16:13, ron minnich wrote: > http://www.industrial-europe.com/207600269 > > amazing. Put an OS in the BIOS FLASH part. Now who would ever have > thought of such a ridiculous idea. > Heh. Note how they don't talk about total boot time or the time until the payload has finished execution. They just talk about the time needed until control is passed to the payload and mention "milliseconds" (note how they don't specify how many). We should advertise the same way, it's simply more impressive. "Coreboot only spends a few milliseconds after poweron doing the absolutely neccessary setup. Your operating system of choice can run directly after that directly from flash with no additional delays. Coreboot has been offering that ability for over ten years." Regards, Carl-Daniel From stepan at coresystems.de Thu May 8 16:29:16 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 08 May 2008 16:29:16 +0200 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <48230A3C.2010707@gmx.net> References: <48230632.7070401@gmx.net> <48230863.7040604@coresystems.de> <48230A3C.2010707@gmx.net> Message-ID: <48230E3C.1000209@coresystems.de> Carl-Daniel Hailfinger wrote: > Interesting proposal. If I understand you correctly, enabled=0 would mean > - disabled on all chipsets > - hidden on those chipsets where hiding is supported. > > There are two problems I have with that approach, though: > - I don't understand PCI well enough to know how a device is disabled. > On a high level: Disabling the device means we disable its memory and io space. Hiding the device means we disable its config space. So with any of the three resource types disabled, the device is not really usable. They're just decoded differently. > Does disabling the device mean disabling the resources as well? Does it > mean the device won't respond to config cycles outside a special "enable > cycle" anymore? > absolutely. If you have a special disable function, you will also need a special enable function. But that won't happen, as you don't re-enable a device that you disabled on purpose. > - With automatic hiding, we lose the ability to leave a device > untouched. Do we need an enum(disabled, hidden, enabled, untouched) for > a full representation of possible states? > hidden implies disabled, since when you disable the config space of the device, the BARs are gone, too. untouched is not an option we provided at any time before, but basically it implies disabled, too. From svn at coreboot.org Thu May 8 16:37:18 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Thu, 8 May 2008 16:37:18 +0200 Subject: [coreboot] r3293 - trunk/util/superiotool Message-ID: Author: uwe Date: 2008-05-08 16:37:12 +0200 (Thu, 08 May 2008) New Revision: 3293 Modified: trunk/util/superiotool/ite.c Log: Add support for dumping ITE IT8718F EC registers (trivial). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/util/superiotool/ite.c =================================================================== --- trunk/util/superiotool/ite.c 2008-05-08 13:50:23 UTC (rev 3292) +++ trunk/util/superiotool/ite.c 2008-05-08 14:37:12 UTC (rev 3293) @@ -350,6 +350,35 @@ 0x99,0x7f,0x7f,0x7f,0x00,0x00,0x7f,0x7f,0x7f,0x7f, 0x00,0x00,0x7f,EOT}}, {EOT}}}, + {0x8718, "IT8718F", { + {NOLDN, NULL, + {0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09, + 0x0a,0x0b,0x0c,0x0d,0x0e,0x0f,0x10,0x11,0x12,0x13, + 0x14,0x15,0x16,0x17,0x18,0x19,0x1a,0x1b,0x1c,0x1d, + 0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28,0x29, + 0x2a,0x2b,0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37, + 0x38,0x39,0x3a,0x3b,0x3c,0x3d,0x3e,0x3f,0x40,0x41, + 0x42,0x43,0x44,0x45,0x50,0x51,0x52,0x53,0x54,0x56, + 0x57,0x58,0x59,0x5b,0x5c,0x5d,0x5e,0x5f,0x60,0x61, + 0x62,0x63,0x64,0x65,0x68,0x69,0x6a,0x6b,0x6c,0x6d, + 0x70,0x71,0x72,0x73,0x74,0x75,0x80,0x81,0x82,0x83, + 0x88,0x89,0x8a,0x8b,0x8c,0x8d,0x8e,0x8f,0x90,0x91, + 0x92,0x94,0x95,0x96,0xa0,0xa1,0xa2,0xa3,0xa4,0xa5, + 0xa6,EOT}, + {0x18,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x80, + 0x40,0x09,0x00,NANA,NANA,NANA,NANA,NANA,NANA,0x07, + 0x50,MISC,MISC,MISC,NANA,NANA,NANA,NANA,NANA,NANA, + NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA, + NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA, + NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA, + NANA,NANA,NANA,NANA,0x00,0x00,0x7f,0x7f,0x7f,0x00, + 0x00,0x90,0x00,0x12,0x00,0x00,0x00,0x00,0x7f,0x7f, + 0x7f,0x00,0x00,0x7f,0x7f,0x7f,0x7f,0x00,0x00,0x7f, + 0x7f,0x7f,0x7f,0x00,0x00,0x7f,NANA,NANA,NANA,NANA, + 0x00,0x00,0x00,0x00,0x00,0x00,0x02,0x00,0xff,0x00, + 0x00,0xff,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, + 0x00,EOT}}, + {EOT}}}, {EOT} }; From rminnich at gmail.com Thu May 8 16:46:17 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 8 May 2008 07:46:17 -0700 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <48230CAB.6070308@coresystems.de> References: <48230632.7070401@gmx.net> <48230863.7040604@coresystems.de> <48230A3C.2010707@gmx.net> <13426df10805080717w5a57f6efu380a8807f4e6e55a@mail.gmail.com> <48230CAB.6070308@coresystems.de> Message-ID: <13426df10805080746l62b75b06ge77b4de83ae7b48@mail.gmail.com> On Thu, May 8, 2008 at 7:22 AM, Stefan Reinauer wrote: > Why would you not hide a non-enabled device? in some cases we actually have to allocate the BARs and so on and leave it disabled -- we don't know if the OS wants it, but if the OS wants it, it has to work. This is one of the less intuitive bits of the device bringup process. > In Linux it is, isn't it? I thought to remember it won't show devices > with no BARs set up.. yep, we actually have to set up the BARs even if it is not enabled in the tree. We can't leave the OS in a situtation where it can't use the device. thanks ron From rminnich at gmail.com Thu May 8 16:50:19 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 8 May 2008 07:50:19 -0700 Subject: [coreboot] bug in cs5536 ide enable. Is this also in 8111 ... In-Reply-To: <48223B40.1070907@gmx.net> References: <13426df10805052142n60aaa4nf4c8f7fa3d1da1c4@mail.gmail.com> <48223B40.1070907@gmx.net> Message-ID: <13426df10805080750v24cad763n3779cf158493d982@mail.gmail.com> Here's the patch after your latest nice cleanup :-) Index: southbridge/amd/cs5536/cs5536.c =================================================================== --- southbridge/amd/cs5536/cs5536.c (revision 677) +++ southbridge/amd/cs5536/cs5536.c (working copy) @@ -602,7 +602,7 @@ // NOTE: Only 32-bit writes to the data buffer are allowed when PWB is set ide_cfg = pci_read_config32(dev, IDE_CFG); ide_cfg |= CHANEN | PWB; - pci_write_config8(dev, IDE_CFG, ide_cfg); + pci_write_config32(dev, IDE_CFG, ide_cfg); } Signed-off-by: Ronald G. Minnich NO find_device. Tested on alix1c :-) ron From svn at coreboot.org Thu May 8 16:51:41 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Thu, 8 May 2008 16:51:41 +0200 Subject: [coreboot] r678 - coreboot-v3/southbridge/amd/cs5536 Message-ID: Author: rminnich Date: 2008-05-08 16:51:40 +0200 (Thu, 08 May 2008) New Revision: 678 Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.c Log: Changed erroneous write config 8 to write config 32 Signed-off-by: Ronald G. Minnich Acked-by: Carl-Daniel Hailfinger Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.c =================================================================== --- coreboot-v3/southbridge/amd/cs5536/cs5536.c 2008-05-07 23:21:55 UTC (rev 677) +++ coreboot-v3/southbridge/amd/cs5536/cs5536.c 2008-05-08 14:51:40 UTC (rev 678) @@ -602,7 +602,7 @@ // NOTE: Only 32-bit writes to the data buffer are allowed when PWB is set ide_cfg = pci_read_config32(dev, IDE_CFG); ide_cfg |= CHANEN | PWB; - pci_write_config8(dev, IDE_CFG, ide_cfg); + pci_write_config32(dev, IDE_CFG, ide_cfg); } From stepan at coresystems.de Thu May 8 16:51:57 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 08 May 2008 16:51:57 +0200 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <13426df10805080746l62b75b06ge77b4de83ae7b48@mail.gmail.com> References: <48230632.7070401@gmx.net> <48230863.7040604@coresystems.de> <48230A3C.2010707@gmx.net> <13426df10805080717w5a57f6efu380a8807f4e6e55a@mail.gmail.com> <48230CAB.6070308@coresystems.de> <13426df10805080746l62b75b06ge77b4de83ae7b48@mail.gmail.com> Message-ID: <4823138D.6090105@coresystems.de> ron minnich wrote: > On Thu, May 8, 2008 at 7:22 AM, Stefan Reinauer wrote: > > >> Why would you not hide a non-enabled device? >> > > in some cases we actually have to allocate the BARs and so on and > leave it disabled -- we don't know if the OS wants it, but if the OS > wants it, it has to work. This is one of the less intuitive bits of > the device bringup process. > Which device is that? >> In Linux it is, isn't it? I thought to remember it won't show devices >> with no BARs set up.. >> > > yep, we actually have to set up the BARs even if it is not enabled in > the tree. We can't leave the OS in a situtation where it can't use the > device. > > What does pci xx.x off end do then? From uwe at hermann-uwe.de Thu May 8 16:52:14 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 8 May 2008 16:52:14 +0200 Subject: [coreboot] legacy bios support and coreboot In-Reply-To: References: Message-ID: <20080508145214.GA17951@greenwood> On Wed, May 07, 2008 at 10:50:11AM +0800, aaron lwe wrote: > I add a header for legacybios to become a payload, this is done by a > utility createpayload. > I've attached the loader and the utility. > Signed-off-by: Aaron Lwe Nice, I'll look over it and test later, but in any case, please repost the patch with proper GPL license+copyright headers in all new files you add. E.g.: /* * This file is part of the coreboot project. * * Copyright (C) 2008 Aaron Lwe * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 * USA */ Also, not sure what the proper place for this is. We have multiple options: - extra payload - patch in v2 and in v3 - maybe others (?) Thanks, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From rminnich at gmail.com Thu May 8 16:52:15 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 8 May 2008 07:52:15 -0700 Subject: [coreboot] bug in cs5536 ide enable. Is this also in 8111 ... In-Reply-To: <13426df10805080750v24cad763n3779cf158493d982@mail.gmail.com> References: <13426df10805052142n60aaa4nf4c8f7fa3d1da1c4@mail.gmail.com> <48223B40.1070907@gmx.net> <13426df10805080750v24cad763n3779cf158493d982@mail.gmail.com> Message-ID: <13426df10805080752i3ecfc3faif2ab234bf4867df8@mail.gmail.com> Committed revision 678. From stepan at coresystems.de Thu May 8 16:52:42 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 08 May 2008 16:52:42 +0200 Subject: [coreboot] bug in cs5536 ide enable. Is this also in 8111 ... In-Reply-To: <13426df10805080750v24cad763n3779cf158493d982@mail.gmail.com> References: <13426df10805052142n60aaa4nf4c8f7fa3d1da1c4@mail.gmail.com> <48223B40.1070907@gmx.net> <13426df10805080750v24cad763n3779cf158493d982@mail.gmail.com> Message-ID: <482313BA.9030808@coresystems.de> ron minnich wrote: > Here's the patch after your latest nice cleanup :-) > > Index: southbridge/amd/cs5536/cs5536.c > =================================================================== > --- southbridge/amd/cs5536/cs5536.c (revision 677) > +++ southbridge/amd/cs5536/cs5536.c (working copy) > @@ -602,7 +602,7 @@ > // NOTE: Only 32-bit writes to the data buffer are allowed > when PWB is set > ide_cfg = pci_read_config32(dev, IDE_CFG); > ide_cfg |= CHANEN | PWB; > - pci_write_config8(dev, IDE_CFG, ide_cfg); > + pci_write_config32(dev, IDE_CFG, ide_cfg); > } > > > Signed-off-by: Ronald G. Minnich > Acked-by: Stefan Reinauer From uwe at hermann-uwe.de Thu May 8 16:56:47 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 8 May 2008 16:56:47 +0200 Subject: [coreboot] r3293 - trunk/util/superiotool In-Reply-To: References: Message-ID: <20080508145647.GB17951@greenwood> On Thu, May 08, 2008 at 04:37:18PM +0200, svn at coreboot.org wrote: > Add support for dumping ITE IT8718F EC registers (trivial). For reference here's a dump from actual hardware (GIGABYTE 8I945GZME-RH): $ superiotool -de superiotool r3292 Found ITE IT8718F (id=0x8718, rev=0x1) at 0x2e Register dump: idx 07 20 21 22 23 24 2b val 04 87 18 01 10 00 00 def NA 87 18 01 00 00 00 LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 val 01 03 f0 06 02 00 80 def 00 03 f0 06 02 00 00 LDN 0x01 (COM1) idx 30 60 61 70 f0 f1 f2 f3 val 01 03 f8 04 00 50 00 7f def 00 03 f8 04 00 50 00 7f LDN 0x02 (COM2) idx 30 60 61 70 f0 f1 f2 f3 val 01 02 f8 03 00 50 00 7f def 00 02 f8 03 00 50 00 7f LDN 0x03 (Parallel port) idx 30 60 61 62 63 70 74 f0 val 01 03 78 00 00 07 04 08 def 00 03 78 07 78 07 03 03 LDN 0x04 (Environment controller) idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 val 01 02 90 00 00 00 80 00 0a 00 c0 00 ff def 00 02 90 02 30 09 00 00 00 00 00 NA NA LDN 0x05 (Keyboard) idx 30 60 61 62 63 70 71 f0 val 01 00 60 00 64 01 02 68 def 01 00 60 00 64 01 02 00 LDN 0x06 (Mouse) idx 30 70 71 f0 val 01 0c 02 00 def 00 0c 02 00 LDN 0x07 (GPIO) idx 25 26 27 28 29 2a 2c 60 61 62 63 64 65 70 71 72 73 74 b0 b1 b2 b3 b4 b5 b8 b9 ba bb bc bd c0 c1 c2 c3 c4 c8 c9 ca cb cc e0 e1 e2 e3 e4 e5 e6 e7 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff val 00 02 00 40 00 00 1c 00 00 08 00 00 00 00 01 00 38 00 00 00 00 00 00 00 00 02 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 26 00 00 00 00 00 53 00 00 00 def 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 20 38 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 40 00 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 NA 00 00 00 LDN 0x0a (Consumer IR) idx 30 60 61 70 f0 val 00 03 10 0b 06 def 00 03 10 0b 00 Environment controller (0x0295) Register dump: idx 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 20 21 22 23 24 25 26 27 28 29 2a 2b 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 50 51 52 53 54 56 57 58 59 5b 5c 5d 5e 5f 60 61 62 63 64 65 68 69 6a 6b 6c 6d 70 71 72 73 74 75 80 81 82 83 88 89 8a 8b 8c 8d 8e 8f 90 91 92 94 95 96 a0 a1 a2 a3 a4 a5 a6 val 11 10 88 00 37 ff 00 37 ff 87 40 09 07 17 cd ff ff ff ff 73 d7 82 7f 7f 02 01 ff ff ff ff 55 73 cf ff be 02 50 ff ff ca fe 1b ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 7f 7f 7f 7f 7f 7f ff 1c 7f 7f 7f de de 90 de 12 00 00 00 00 00 14 41 23 90 03 7f 7f 7f 00 00 7f 00 14 41 23 90 03 00 00 00 00 00 00 00 00 00 00 02 00 ff 00 00 ff 00 00 00 00 00 00 00 00 00 def 18 00 00 00 00 00 00 00 00 80 40 09 00 NA NA NA NA NA NA 07 50 MM MM MM NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA 00 00 7f 7f 7f 00 00 90 00 12 00 00 00 00 7f 7f 7f 00 00 7f 7f 7f 7f 00 00 7f 7f 7f 7f 00 00 7f NA NA NA NA 00 00 00 00 00 00 02 00 ff 00 00 ff 00 00 00 00 00 00 00 00 00 Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From c-d.hailfinger.devel.2006 at gmx.net Thu May 8 16:58:58 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 08 May 2008 16:58:58 +0200 Subject: [coreboot] bug in cs5536 ide enable. Is this also in 8111 ... In-Reply-To: <13426df10805080752i3ecfc3faif2ab234bf4867df8@mail.gmail.com> References: <13426df10805052142n60aaa4nf4c8f7fa3d1da1c4@mail.gmail.com> <48223B40.1070907@gmx.net> <13426df10805080750v24cad763n3779cf158493d982@mail.gmail.com> <13426df10805080752i3ecfc3faif2ab234bf4867df8@mail.gmail.com> Message-ID: <48231532.20208@gmx.net> On 08.05.2008 16:52, ron minnich wrote: > Committed revision 678. > Thanks for tracking this down! Regards, Carl-Daniel From rminnich at gmail.com Thu May 8 17:02:53 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 8 May 2008 08:02:53 -0700 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <4823138D.6090105@coresystems.de> References: <48230632.7070401@gmx.net> <48230863.7040604@coresystems.de> <48230A3C.2010707@gmx.net> <13426df10805080717w5a57f6efu380a8807f4e6e55a@mail.gmail.com> <48230CAB.6070308@coresystems.de> <13426df10805080746l62b75b06ge77b4de83ae7b48@mail.gmail.com> <4823138D.6090105@coresystems.de> Message-ID: <13426df10805080802q4520a8ebj22067b815ef8268b@mail.gmail.com> On Thu, May 8, 2008 at 7:51 AM, Stefan Reinauer wrote: > Which device is that? Almost all of them. Consider a bridge. > What does pci xx.x off end do then? in v2, it means that in the init function, the CMD register is un-enabled (I think; I have not looked at this code for a bit and it always confuses me). Look in pci_probe_dev for example: device is unconditionally enabled, so we can scan it. IIRC one case that drove this was multiple VGA cards -- you want to set up the BARs etc. for all but you really don't know what the OS will do -- maybe nothing -- but you want them there if it will do something. There really is a difference between un-enabled (or disabled) and hidden; as you pointed out, hidden means no config space, or "will not show up in lspci". ron From stepan at coresystems.de Thu May 8 17:14:30 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 08 May 2008 17:14:30 +0200 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <13426df10805080802q4520a8ebj22067b815ef8268b@mail.gmail.com> References: <48230632.7070401@gmx.net> <48230863.7040604@coresystems.de> <48230A3C.2010707@gmx.net> <13426df10805080717w5a57f6efu380a8807f4e6e55a@mail.gmail.com> <48230CAB.6070308@coresystems.de> <13426df10805080746l62b75b06ge77b4de83ae7b48@mail.gmail.com> <4823138D.6090105@coresystems.de> <13426df10805080802q4520a8ebj22067b815ef8268b@mail.gmail.com> Message-ID: <482318D6.4060908@coresystems.de> ron minnich wrote: > On Thu, May 8, 2008 at 7:51 AM, Stefan Reinauer wrote: > > > > > in some cases we actually have to allocate the BARs and so on and > > > leave it disabled -- we don't know if the OS wants it, but if the OS > > > wants it, it has to work. This is one of the less intuitive bits of > > > the device bringup process. >> Which device is that? >> > > Almost all of them. Consider a bridge. > > I still think a bridge that gets disabled in Config.lb or the dts should not be set up. Otherwise it might be bridging, which would really not be what we want if we disable the device. I can't find any bridge in v2 from a quick scan that would stay un-enabled. If we don't know whether the OS wants the device, we enable it, not leave it or disable it. We disable or hide the device, if that functionality is not there on the _board_, ie. because it is not wired. If we start thinking about what the OS wants in this context, we have to call this ACPI and make distinctions between OSes in the DTS. ;-) >> What does pci xx.x off end do then? >> > in v2, it means that in the init function, the CMD register is > un-enabled (I think; I have not looked at this code for a bit and it > always confuses me). > > Look in pci_probe_dev for example: device is unconditionally enabled, > so we can scan it. > > IIRC one case that drove this was multiple VGA cards -- you want to > set up the BARs etc. for all but you really don't know what the OS > will do -- maybe nothing -- but you want them there if it will do > something. > Unless the bios disables one of the devices, in which case the OS should find nothing. > There really is a difference between un-enabled (or disabled) and > hidden; as you pointed out, hidden means no config space, or "will not > show up in lspci". > So disabled devices do show up in lspci? From rminnich at gmail.com Thu May 8 17:37:40 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 8 May 2008 08:37:40 -0700 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <482318D6.4060908@coresystems.de> References: <48230632.7070401@gmx.net> <48230863.7040604@coresystems.de> <48230A3C.2010707@gmx.net> <13426df10805080717w5a57f6efu380a8807f4e6e55a@mail.gmail.com> <48230CAB.6070308@coresystems.de> <13426df10805080746l62b75b06ge77b4de83ae7b48@mail.gmail.com> <4823138D.6090105@coresystems.de> <13426df10805080802q4520a8ebj22067b815ef8268b@mail.gmail.com> <482318D6.4060908@coresystems.de> Message-ID: <13426df10805080837tea33775n9bd53cd2da457a4f@mail.gmail.com> On Thu, May 8, 2008 at 8:14 AM, Stefan Reinauer wrote: >> There really is a difference between un-enabled (or disabled) and >> hidden; as you pointed out, hidden means no config space, or "will not >> show up in lspci". >> > So disabled devices do show up in lspci? > That's what my memory tells me, now I have to find an example :-) ron From c-d.hailfinger.devel.2006 at gmx.net Thu May 8 17:52:48 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 08 May 2008 17:52:48 +0200 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <13426df10805080837tea33775n9bd53cd2da457a4f@mail.gmail.com> References: <48230632.7070401@gmx.net> <48230863.7040604@coresystems.de> <48230A3C.2010707@gmx.net> <13426df10805080717w5a57f6efu380a8807f4e6e55a@mail.gmail.com> <48230CAB.6070308@coresystems.de> <13426df10805080746l62b75b06ge77b4de83ae7b48@mail.gmail.com> <4823138D.6090105@coresystems.de> <13426df10805080802q4520a8ebj22067b815ef8268b@mail.gmail.com> <482318D6.4060908@coresystems.de> <13426df10805080837tea33775n9bd53cd2da457a4f@mail.gmail.com> Message-ID: <482321D0.9050409@gmx.net> On 08.05.2008 17:37, ron minnich wrote: > On Thu, May 8, 2008 at 8:14 AM, Stefan Reinauer wrote: > > >>> There really is a difference between un-enabled (or disabled) and >>> hidden; as you pointed out, hidden means no config space, or "will not >>> show up in lspci". >>> >>> >> So disabled devices do show up in lspci? >> > > That's what my memory tells me, now I have to find an example :-) > IIRC this happens at least on the M57SLI. Regards, Carl-Daniel From uwe at hermann-uwe.de Thu May 8 17:58:55 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 8 May 2008 17:58:55 +0200 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <13426df10805080837tea33775n9bd53cd2da457a4f@mail.gmail.com> References: <48230632.7070401@gmx.net> <48230863.7040604@coresystems.de> <48230A3C.2010707@gmx.net> <13426df10805080717w5a57f6efu380a8807f4e6e55a@mail.gmail.com> <48230CAB.6070308@coresystems.de> <13426df10805080746l62b75b06ge77b4de83ae7b48@mail.gmail.com> <4823138D.6090105@coresystems.de> <13426df10805080802q4520a8ebj22067b815ef8268b@mail.gmail.com> <482318D6.4060908@coresystems.de> <13426df10805080837tea33775n9bd53cd2da457a4f@mail.gmail.com> Message-ID: <20080508155855.GC17951@greenwood> On Thu, May 08, 2008 at 08:37:40AM -0700, ron minnich wrote: > On Thu, May 8, 2008 at 8:14 AM, Stefan Reinauer wrote: > > >> There really is a difference between un-enabled (or disabled) and > >> hidden; as you pointed out, hidden means no config space, or "will not > >> show up in lspci". > >> > > So disabled devices do show up in lspci? > > > > That's what my memory tells me, now I have to find an example :-) I guess this depends a bit (not sure on _what_ it depends). I've seen devices show up even if disabled via Config.lb IIRC, but I've also seen a box where I can say 'off' in Config.lb (e.g. for an AC'97 modem) and it will not show up in lspci... Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From stepan at coresystems.de Thu May 8 18:00:26 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 08 May 2008 18:00:26 +0200 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <482321D0.9050409@gmx.net> References: <48230632.7070401@gmx.net> <48230863.7040604@coresystems.de> <48230A3C.2010707@gmx.net> <13426df10805080717w5a57f6efu380a8807f4e6e55a@mail.gmail.com> <48230CAB.6070308@coresystems.de> <13426df10805080746l62b75b06ge77b4de83ae7b48@mail.gmail.com> <4823138D.6090105@coresystems.de> <13426df10805080802q4520a8ebj22067b815ef8268b@mail.gmail.com> <482318D6.4060908@coresystems.de> <13426df10805080837tea33775n9bd53cd2da457a4f@mail.gmail.com> <482321D0.9050409@gmx.net> Message-ID: <4823239A.8040909@coresystems.de> Carl-Daniel Hailfinger wrote: > On 08.05.2008 17:37, ron minnich wrote: > >> On Thu, May 8, 2008 at 8:14 AM, Stefan Reinauer wrote: >> >> >> >>>> There really is a difference between un-enabled (or disabled) and >>>> hidden; as you pointed out, hidden means no config space, or "will not >>>> show up in lspci". >>>> >>>> >>>> >>> So disabled devices do show up in lspci? >>> >>> >> That's what my memory tells me, now I have to find an example :-) >> >> > > IIRC this happens at least on the M57SLI. Can you verify? From c-d.hailfinger.devel.2006 at gmx.net Thu May 8 18:06:01 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 08 May 2008 18:06:01 +0200 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <482318D6.4060908@coresystems.de> References: <48230632.7070401@gmx.net> <48230863.7040604@coresystems.de> <48230A3C.2010707@gmx.net> <13426df10805080717w5a57f6efu380a8807f4e6e55a@mail.gmail.com> <48230CAB.6070308@coresystems.de> <13426df10805080746l62b75b06ge77b4de83ae7b48@mail.gmail.com> <4823138D.6090105@coresystems.de> <13426df10805080802q4520a8ebj22067b815ef8268b@mail.gmail.com> <482318D6.4060908@coresystems.de> Message-ID: <482324E9.5030607@gmx.net> On 08.05.2008 17:14, Stefan Reinauer wrote: > ron minnich wrote: > >> On Thu, May 8, 2008 at 7:51 AM, Stefan Reinauer wrote: >> >> >> >>>> in some cases we actually have to allocate the BARs and so on and >>>> leave it disabled -- we don't know if the OS wants it, but if the OS >>>> wants it, it has to work. This is one of the less intuitive bits of >>>> the device bringup process. >>>> >>> Which device is that? >>> >>> >> Almost all of them. Consider a bridge. >> >> >> > I still think a bridge that gets disabled in Config.lb or the dts should > not be set up. Otherwise it might be bridging, which would really not be > what we want if we disable the device. > Are devices behind a disabled bridge completely invisible or do their PCI headers show up? > I can't find any bridge in v2 from a quick scan that would stay un-enabled. > > If we don't know whether the OS wants the device, we enable it, not > leave it or disable it. > > We disable or hide the device, if that functionality is not there on the > _board_, ie. because it is not wired. > Commerical BIOS sometimes have the ability to disable/hide otherwise functional onboard devices, which is useful if the machine is severely resource constrained in the IRQ area and/or the user doesn't want the OS to drive the device. > If we start thinking about what the OS wants in this context, we have to > call this ACPI and make distinctions between OSes in the DTS. ;-) > Mind bleach! Now! >>> What does pci xx.x off end do then? >>> >>> >> in v2, it means that in the init function, the CMD register is >> un-enabled (I think; I have not looked at this code for a bit and it >> always confuses me). >> >> Look in pci_probe_dev for example: device is unconditionally enabled, >> so we can scan it. >> >> IIRC one case that drove this was multiple VGA cards -- you want to >> set up the BARs etc. for all but you really don't know what the OS >> will do -- maybe nothing -- but you want them there if it will do >> something. >> >> > Unless the bios disables one of the devices, in which case the OS should > find nothing. > What about devices which cause periodic interrupts once they are enabled? Enabling them has the undesirable effect of causing unhandled interrupts which irritate Linux a lot. >> There really is a difference between un-enabled (or disabled) and >> hidden; as you pointed out, hidden means no config space, or "will not >> show up in lspci". >> >> > So disabled devices do show up in lspci? > I could try to dig up a lspci from a mail someone sent last year, but if Uwe has seen this on one of his machines, I'd be glad if he could track it down. Regards, Carl-Daniel From Marc.Karasek at Sun.COM Thu May 8 18:08:42 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Thu, 08 May 2008 12:08:42 -0400 Subject: [coreboot] Buildrom In-Reply-To: <20080507203125.GD2564@cosmic.amd.com> References: <4821DA74.6050401@sun.com> <20080507185023.GA2564@cosmic.amd.com> <482202B1.4010901@sun.com> <20080507203125.GD2564@cosmic.amd.com> Message-ID: <4823258A.1030809@sun.com> Jordan, I thnk I may have found a possible answer to this issue. In digging further I noticed that the file produced under buildrom is not a real file (it is only 496 bytes). So it is the linking that is the problem. Buildrom uses uClibc 0.9.29 (correct?). I also noticed that you were using -nostdlib option to link with the uClibc libraries. In doing some investigating, it looks like this is no longer supported. Since 0.9.22 uclibc has pulled the toolchain wrapper that made this possible. They now want you to produce a full uclibc toolchain if you want to use uclibc libs. So the questions are: 1) Do we need to add to buildrom so it will produce the toolchain and then compile busybox? 2) Go back to an earlier version of uclibc 0.9.22? 3) Or just use glibc? For reference: What happened to the old toolchain wrapper? It is possible in some limited cases to re-use an existing glibc toolchain and subvert it into building uClibc binaries by using gcc commands such as "-nostdlib" and "-nostdinc". In fact, this used to be the recommended method for compiling programs with uClibc, and we made this easy to do by providing a uClibc toolchain wrapper, which attempted to automagically subvert an existing glibc toolchain. This toolchain wrapper was removed from uClibc 0.9.22, and it will not be coming back. This is because it proved impossible to completely subvert an existing toolchain in many cases, and therefore proved to be a real maintainence burder. As uClibc became more capable, the many problems with re-using an existing glibc toolchain led us to conclude that the only safe and sane way to build uClibc binaries was to use a uClibc toolchain. Some discussion on the reasoning behind this decision can be found here: http://www.uclibc.org/lists/uclibc/2003-October/007315.html in the uClibc mailing list archives. ********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 ********************* Jordan Crouse wrote: > On 07/05/08 15:27 -0400, Marc Karasek wrote: > >> Jordan, >> >> It gets even wierder.. If I compile BB in the work dir it comes out >> dynamic, if I use buildrom it comes out static... >> > > Hmm - you might be dealing with some strange kconfig issues here. Copy > packages/busybox/conf/defconfig to work/busybox/busybox-1.10.1/.config and > run 'make oldconfig' to make sure your config is up to date. Then check > the resulting .config to make sure that CONFIG_STATIC isn't set. > > Jordan > > >> Jordan Crouse wrote: >> >>> On 07/05/08 12:36 -0400, Marc Karasek wrote: >>> >>> >>>> Jordan, >>>> >>>> I need some help on an error message. >>>> >>>> I am trying to move to busybox 1.10.1 to see if this fixes the SimNOW >>>> problem with linuxrc. (All I did to change it to 1.10.1 was to modify >>>> the busybox.mk file to point to the new tar.bz2 file and removed the >>>> patches. Busybox builds fine but it errors out right after. I also >>>> added a check in scripts/Makefile.lab for the initrd-rootfs dir. It >>>> seems that if the dir is not there, then the cp from the skeleton to this >>>> dir fails. It creates the dir if it is not there, and does nothing if it >>>> is there. >>>> >>>> When it gets to the point after compiling busybox and is creating the >>>> initrd-rootfs. It errors out from the python mklibs.py with >>>> E: Dynamic Linker not found, aborting message. I am not a python >>>> expert, I have looked at the mklibs.py file and tried to see what it was >>>> doing. It looks like it is trying to get a list of execs from the >>>> staging directory. >>>> >>>> >>> mklibs.py strips out all the unused symbols from shared libraries, which >>> is useful for LAB since you can get the benefit of a shared library >>> without >>> carrying around symbols you don't need. >>> >>> The code tries to figure out the link interpreter automatically by >>> running readelf --program-headers on each binary and looking for >>> "Requesting program interpeter". If it doesn't find it, then it >>> freaks out. I am assuming that its not finding it in your case because >>> the newer busybox binary is constructed differently. I would have to >>> look at the binary in more detail to figure out why. In the meantime, >>> you can disable that line in buildrom at the expense of more bytes in >>> your shared libraries. >>> >>> Jordan >>> >>> >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From c-d.hailfinger.devel.2006 at gmx.net Thu May 8 18:15:58 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 08 May 2008 18:15:58 +0200 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <48230E3C.1000209@coresystems.de> References: <48230632.7070401@gmx.net> <48230863.7040604@coresystems.de> <48230A3C.2010707@gmx.net> <48230E3C.1000209@coresystems.de> Message-ID: <4823273E.9030800@gmx.net> On 08.05.2008 16:29, Stefan Reinauer wrote: > Carl-Daniel Hailfinger wrote: > >> Interesting proposal. If I understand you correctly, enabled=0 would mean >> - disabled on all chipsets >> - hidden on those chipsets where hiding is supported. >> >> There are two problems I have with that approach, though: >> - I don't understand PCI well enough to know how a device is disabled. >> >> > On a high level: > Thanks for the explanations! > Disabling the device means we disable its memory and io space. > But it can still do DMA and issue IRQs, right? Also, does disabling memory and IO space set a special "disabled" flag or do we simply set each resource with a size of zero? > Hiding the device means we disable its config space. > > So with any of the three resource types disabled, the device is not > really usable. They're just decoded differently. > not usable != disabled. >> Does disabling the device mean disabling the resources as well? Does it >> mean the device won't respond to config cycles outside a special "enable >> cycle" anymore? >> >> > absolutely. If you have a special disable function, you will also need a > special enable function. But that won't happen, as you don't re-enable a > device that you disabled on purpose. > Do we need special per-device functions for en-/disabling or is this doable with a generic PCI function? >> - With automatic hiding, we lose the ability to leave a device >> untouched. Do we need an enum(disabled, hidden, enabled, untouched) for >> a full representation of possible states? >> >> > hidden implies disabled, since when you disable the config space of the > device, the BARs are gone, too. > Well, if you can hide a device, can it issue IRQs or perform DMA on its own initiative? > untouched is not an option we provided at any time before, but basically > it implies disabled, too. > I still think untouched could be useful. For one, it would allow us to minimize setup during early porting and we could do the rest of the setup from a network-loaded payload. That's not neccessary if you have a ROM emulator, but a big plus for those developers without one. Regards, Carl-Daniel From rminnich at gmail.com Thu May 8 18:26:27 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 8 May 2008 09:26:27 -0700 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <20080508155855.GC17951@greenwood> References: <48230632.7070401@gmx.net> <48230A3C.2010707@gmx.net> <13426df10805080717w5a57f6efu380a8807f4e6e55a@mail.gmail.com> <48230CAB.6070308@coresystems.de> <13426df10805080746l62b75b06ge77b4de83ae7b48@mail.gmail.com> <4823138D.6090105@coresystems.de> <13426df10805080802q4520a8ebj22067b815ef8268b@mail.gmail.com> <482318D6.4060908@coresystems.de> <13426df10805080837tea33775n9bd53cd2da457a4f@mail.gmail.com> <20080508155855.GC17951@greenwood> Message-ID: <13426df10805080926l1760a4bbkec54728e03db37a2@mail.gmail.com> On Thu, May 8, 2008 at 8:58 AM, Uwe Hermann wrote: > I guess this depends a bit (not sure on _what_ it depends). I've seen > devices show up even if disabled via Config.lb IIRC, but I've also seen > a box where I can say 'off' in Config.lb (e.g. for an AC'97 modem) and > it will not show up in lspci... > PC hardware is defined as much by its exceptions as its rules :-) ron From rminnich at gmail.com Thu May 8 18:31:40 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 8 May 2008 09:31:40 -0700 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <4823273E.9030800@gmx.net> References: <48230632.7070401@gmx.net> <48230863.7040604@coresystems.de> <48230A3C.2010707@gmx.net> <48230E3C.1000209@coresystems.de> <4823273E.9030800@gmx.net> Message-ID: <13426df10805080931u3b20166dv204dc4779d506b0c@mail.gmail.com> On Thu, May 8, 2008 at 9:15 AM, Carl-Daniel Hailfinger >> Disabling the device means we disable its memory and io space. >> > > But it can still do DMA and issue IRQs, right? not dma unless bus master is set, and no BIOS should ever set that (but I bet EFI does as it has drivers ...) > > Also, does disabling memory and IO space set a special "disabled" flag > or do we simply set each resource with a size of zero? no, what should happen is you allocate the BARs but don't enable it. Many OSes can re-enable a disabled device, but the can't handle BARs with a value of 0. > >> Hiding the device means we disable its config space. >> >> So with any of the three resource types disabled, the device is not >> really usable. They're just decoded differently. >> > > not usable != disabled. if the device is disabled, the OS can re-enable it. I've actually re-enabled disabled bridges via setpci, for example. If the device is hidden, the OS can do nothing to get to it. >> absolutely. If you have a special disable function, you will also need a >> special enable function. But that won't happen, as you don't re-enable a >> device that you disabled on purpose. >> > > Do we need special per-device functions for en-/disabling or is this > doable with a generic PCI function? Not quite! You can re-enable any disabled device with setpci -- I've done it. But you can't re-enable a hidden device -- pci can't see it. > Well, if you can hide a device, can it issue IRQs or perform DMA on its > own initiative? IRQs -- unclear. That's a little tricky. DMA, no, BUSMASTERing won't be set for one thing. I think if we add to many states we're going to be in PCI hell. Let's be careful. > >> untouched is not an option we provided at any time before, but basically >> it implies disabled, too. >> > > I still think untouched could be useful. For one, it would allow us to > minimize setup during early porting and we could do the rest of the > setup from a network-loaded payload. That's not neccessary if you have a > ROM emulator, but a big plus for those developers without one. > interesting idea but you have to make sure you know the implications of this for bridges, etc. etc. And if you don't allocate BARs, and the system comes up, you may find there is no way to allocate the address space for the BARs -- there may not be room. This happened on more than one occasion with, e.g., Quadrics. ron From joe at settoplinux.org Thu May 8 19:32:11 2008 From: joe at settoplinux.org (Joe) Date: Thu, 08 May 2008 13:32:11 -0400 Subject: [coreboot] GRUB2 Questions Message-ID: Hello, Are there any plans to load GRUB2's grub.cfg from a hard disk. This would make it editable to the end user. I think it is kind of important for a Multiboot Loader. Also is there any status update on GRUB2 booting UHCI? -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org From patrick at georgi-clan.de Thu May 8 19:43:47 2008 From: patrick at georgi-clan.de (Patrick Georgi) Date: Thu, 8 May 2008 19:43:47 +0200 Subject: [coreboot] GRUB2 Questions In-Reply-To: References: Message-ID: <20080508194347.638fdc93@tetris.streichelzoo.local> Am Thu, 08 May 2008 13:32:11 -0400 schrieb Joe : > Are there any plans to load GRUB2's grub.cfg from a hard disk. This > would make it editable to the end user. I think it is kind of > important for a Multiboot Loader. bug #96 on our tracker (assigned to me) is about being able to configure the default location for grub.cfg. I'll work on it, once I got USB storage done. which brings me to.. > Also is there any status update on GRUB2 booting UHCI? GRUB2 read disk size and sectors from (QEmu emulated) usb storage devices for the first time this morning. This was just some test on device initialization, but still. My next step is to make it available from grub2 as normal disk, which might happen before saturday evening. For the time being, that code still profits from qemu's emulation being relaxed in some areas, so it will take some more days to make it ready for general consumption (ie. real hardware). Regards, Patrick From joe at settoplinux.org Thu May 8 20:06:46 2008 From: joe at settoplinux.org (Joe) Date: Thu, 08 May 2008 14:06:46 -0400 Subject: [coreboot] GRUB2 Questions In-Reply-To: <20080508194347.638fdc93@tetris.streichelzoo.local> References: <20080508194347.638fdc93@tetris.streichelzoo.local> Message-ID: <152e465a5586f5c19ef3b2dbde95f7db@imap.1and1.com> On Thu, 8 May 2008 19:43:47 +0200, Patrick Georgi wrote: > Am Thu, 08 May 2008 13:32:11 -0400 > schrieb Joe : >> Are there any plans to load GRUB2's grub.cfg from a hard disk. This >> would make it editable to the end user. I think it is kind of >> important for a Multiboot Loader. > bug #96 on our tracker (assigned to me) is about being able to > configure the default location for grub.cfg. I'll work on it, once I > got USB storage done. which brings me to.. > >> Also is there any status update on GRUB2 booting UHCI? > GRUB2 read disk size and sectors from (QEmu emulated) usb storage > devices for the first time this morning. This was just some test on > device initialization, but still. > My next step is to make it available from grub2 as normal disk, which > might happen before saturday evening. > > For the time being, that code still profits from qemu's emulation being > relaxed in some areas, so it will take some more days to make it ready > for general consumption (ie. real hardware). > > Exellent! Great to hear Patrick:-) Keep up the great work! If there is anything I can do to help out let me know. -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org From Marc.Jones at amd.com Thu May 8 20:16:08 2008 From: Marc.Jones at amd.com (Marc Jones) Date: Thu, 08 May 2008 12:16:08 -0600 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <48230632.7070401@gmx.net> References: <48230632.7070401@gmx.net> Message-ID: <48234368.7060908@amd.com> Carl-Daniel Hailfinger wrote: > My current plan is: > - encapsulate all those code sequences into calls of one or two functions > - switch all calls from hide_vpci(some_value_calculated_by_hand) to > hide_vpci_dev(struct device *) OK. > - replace the central array of hand-calculated values with a > per-PCI-device "hidden" property. > I think that this will add complications that you don't intend. There are two reasons to hide a device. 1. Your platform doesn't use the device and so there is no reason for it to hang about. This option was addressed with the array of device location that you noted, but I don't think that anyone used it. (OLPC doesn't count) 2. There is shared hardware and only one device can be present at a time. An example of this is IDE or flash and 5536 USB configuration. Adding a hidden property could handle the first case but then every device will have a dts to contain a property that isn't used. In the second case, the logic to hide the device is based on other configurations and the hidden property would either be pointless or confuse the issue of if or when the device should be hidden. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From Marc.Karasek at Sun.COM Thu May 8 20:37:41 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Thu, 08 May 2008 14:37:41 -0400 Subject: [coreboot] SimNOW V2 LAB problem In-Reply-To: <006801c8afc1$67ecf2f0$1a02a8c0@chimp> References: <4820BEE2.9070309@sun.com> <006701c8afbe$d89e9e20$1a02a8c0@chimp> <4820CBEF.4050107@sun.com> <006801c8afc1$67ecf2f0$1a02a8c0@chimp> Message-ID: <48234875.6050506@sun.com> Myles, When you build the broken one: 1) Is it a real exec file? Or is the file like 496 bytes? What does file busybox report? 2) What version of uclibc was the FC5 system using? 3) can you do a make in the busybox directory outside of buildrom in work/busybox/busybox-a.b.c/ and look at the output from this, i.e. is the busybox file have a correct size and is dynamic linked, etc.. Marc ********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 ********************* Myles Watson wrote: > >> -----Original Message----- >> From: Marc.Karasek at Sun.COM [mailto:Marc.Karasek at Sun.COM] >> Sent: Tuesday, May 06, 2008 3:22 PM >> To: Myles Watson >> Cc: coreboot at coreboot.org >> Subject: Re: [coreboot] SimNOW V2 LAB problem >> >> Crap, another compiler/tools problem. I hate these.. what version of >> gcc/binutils did you use under FC5? >> > > gcc 4.1.1 for x86_64 release 51.fc5 > binutils 2.16.91.0.6 for x86_64 release 5 > > I wouldn't have upgraded, but I couldn't build a working version of qemu > with those tools. Now I have two broken systems :( > > Thanks, > Myles > > > > > From ward at gnu.org Thu May 8 20:45:39 2008 From: ward at gnu.org (Ward Vandewege) Date: Thu, 8 May 2008 14:45:39 -0400 Subject: [coreboot] [RFC] kill unwanted_vpci, use "hidden" property instead In-Reply-To: <48234368.7060908@amd.com> References: <48230632.7070401@gmx.net> <48234368.7060908@amd.com> Message-ID: <20080508184539.GA26447@localdomain> On Thu, May 08, 2008 at 12:16:08PM -0600, Marc Jones wrote: > Carl-Daniel Hailfinger wrote: > > > My current plan is: > > - encapsulate all those code sequences into calls of one or two functions > > - switch all calls from hide_vpci(some_value_calculated_by_hand) to > > hide_vpci_dev(struct device *) > OK. > > > - replace the central array of hand-calculated values with a > > per-PCI-device "hidden" property. > > > > I think that this will add complications that you don't intend. > > There are two reasons to hide a device. > 1. Your platform doesn't use the device and so there is no reason for it > to hang about. This option was addressed with the array of device > location that you noted, but I don't think that anyone used it. (OLPC > doesn't count) Actually, we use it in v3 on the alix.2c3 to disable the VGA device which has no physical connector present. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From mylesgw at gmail.com Thu May 8 21:55:33 2008 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 8 May 2008 13:55:33 -0600 Subject: [coreboot] SimNOW V2 LAB problem In-Reply-To: <48234875.6050506@sun.com> References: <4820BEE2.9070309@sun.com> <006701c8afbe$d89e9e20$1a02a8c0@chimp> <4820CBEF.4050107@sun.com> <006801c8afc1$67ecf2f0$1a02a8c0@chimp> <48234875.6050506@sun.com> Message-ID: <2831fecf0805081255r27713ce9y99e254429c19afc9@mail.gmail.com> On Thu, May 8, 2008 at 12:37 PM, Marc Karasek wrote: > Myles, > > When you build the broken one: > 1) Is it a real exec file? Or is the file like 496 bytes? What does file > busybox report? initrd-rootfs/bin/busybox is about 200K Did you mean a different file? I think the error woul