coreboot May 2008

coreboot@coreboot.org

79 participants
387 discussions

r180 - buildrom-devel/config/platforms
by svn＠coreboot.org 05 May '08

05 May '08

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 <ward(a)gnu.org> Acked-by: Ward Vandewege <ward(a)gnu.org> 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

1 0

r3278 - trunk/coreboot-v2/targets/supermicro/h8dmr
by svn＠coreboot.org 05 May '08

05 May '08

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 <ward(a)gnu.org> Acked-by: Ward Vandewege <ward(a)gnu.org> 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"

1 0

r179 - buildrom-devel/packages/coreboot-v2
by svn＠coreboot.org 05 May '08

05 May '08

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 <jordan.crouse(a)amd.com> Acked-by: Jordan Crouse <jordan.crouse(a)amd.com> 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)

1 0

Fwd: Interested vendors [was: [Fwd: Re: Contact Intel]]
by Tiago Marques 05 May '08

05 May '08

ditto On 5/2/08, Richard M Stallman <rms(a)gnu.org> 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(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

2 2

patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts
by ron minnich 05 May '08

05 May '08

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- <TAbort- <MAbort- >SERR- <PERR- 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- <TAbort- <MAbort- >SERR- <PERR- 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- <TAbort- <MAbort- >SERR- <PERR- 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

7 18

Erase sst_fwhub blockwise, not the whole chip at once
by Claus Gindhart 05 May '08

05 May '08

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 <claus.gindhart(a)kontron.com> --- Mit freundlichen Grüßen / Best regards Claus Gindhart SW R&D Kontron Modular Computers phone :++49 (0)8341-803-374 mailto:claus.gindhart@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.

2 1

r675 - coreboot-v3/mainboard/pcengines/alix1c
by svn＠coreboot.org 04 May '08

04 May '08

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 <ward(a)gnu.org> Acked-by: Ward Vandewege <ward(a)gnu.org> 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. */

1 0

Re: [coreboot] [Fwd: Re: Contact Intel]
by arc 04 May '08

04 May '08

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(a)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

4 3

Re: [coreboot] patch: move audio, ehci, ohci IRQs from irq_table to cs5536 dts
by Mart Raudsepp 04 May '08

04 May '08

> 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

2 1

MFGPT issues: possible solution?
by Carl-Daniel Hailfinger 04 May '08

04 May '08

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

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2008