coreboot August 2010

coreboot@coreboot.org

67 participants
267 discussions

Re: [coreboot] [RFC] ACPI for ASUS P2B/P2B-LS (Intel 440BX/82371EB)
by Keith Hui 25 Nov '10

25 Nov '10

Hi all, Based on Idwer's RFC I tried adding ACPI to P2B-LS plus completing the rest of the PIIX4 function 3 initialization. This is a summary of what I did: * I used the DSDT table from the final vendor BIOS. Not provided here for obvious reasons, but I can tell you how to extract it. * I also replicated the content of the PIIX4 function 3 config space after booting with vendor BIOS, as below: 00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02) 00: 86 80 13 71 03 00 80 02 02 00 80 06 00 00 00 00 10: 00 00 00 00 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 00 00 00 00 00 00 00 00 00 00 00 00 40: 01 e4 00 00 00 00 00 20 1e 30 00 01 00 00 00 00 50: 00 58 19 00 c0 c8 3b 02 37 40 40 03 00 00 00 00 60: 90 02 e7 00 00 00 00 10 04 e4 11 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 01 e8 00 00 00 00 00 00 00 00 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 01 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 30 0f 00 00 00 00 00 00 One exception is 0x90-0x91 which has the SMBus host base address. I kept it as 0x0f00. * Idwer is trying to build ACPI 4.0 (!) tables. Since P2B-LS is shipped when ACPI was still at 1.0, that's what I did. For booting XP, even ACPI 2.0 compliance is sufficient. This is a summary of what happens: * I can no longer get POST codes on the PCI bus. POST codes still appear on the ISA bus. Glad I picked a POST card that works on both buses. * Power off does not work. The last POST code to show before complete kernel shutdown and hard drive spinning down is 0xF5. * I don't how how to enter soft suspend in Linux (silly me -_-! ), so I have not tested it. * the sensor appears on ISA bus port 0x290, just like vendor BIOS. * My SB AWE64 ISA card still got initialized and driver loaded, but no sound. In fact ALSA can't even do I/O to the card. That apparently is because PIIX4 needs to be configured to forward certain I/O port ranges to ISA, and some of those port ranges can be further configured. This would require detecting in runtime what ISA cards are installed, what are they, and what I/O port ranges they would use. Where in the source tree should I place such code? Southbridge? The changes I made are described in two attached patches, one to southbridge/intel/i82371eb, one to mainboard/asus/p2bls. My coreboot and linux boot log is also attached. This is also RFC and is not signed off at this point, but comments are welcome. Regards Keith

7 15

mkelfImage & newer kernels
by Troy Telford 06 Oct '10

06 Oct '10

This applies to 2.6.31 & 2.6.32 kernels for certain, but probably other newer kernels as well. I'm a user of mkelfImage; I am currently unable to get an .ebi generated by mkelfImage to boot properly - I can't load it directly, or via a mechanism like kexec. The moment the command (be it etherboot/gpxe, or kexec) tries to load the kernel, the system immediately reboots. If I directly kexec a kernel (minus mkelfImage), the kernel loads correctly, so it appears the problem is in mkelfImage. Unfortunately, I don't know how to fix it, and I _have_ to use mkelfImage to generate .ebi images for my systems. I've tried 2.6.27, 2.6.31, 2.6.32; of those, 2.6.27 (and older kernels, work fine. 2.6.31 & 32 results in an .ebi that causes the system to reboot. Any help!? Thanks, Troy Telford

7 22

#163: Board still requires RAMBASE <1MB
by coreboot 03 Oct '10

03 Oct '10

#163: Board still requires RAMBASE <1MB -------------------------+-------------------------------------------------- Reporter: oxygene | Owner: stepan@… Type: defect | Status: new Priority: minor | Milestone: Component: coreboot | Keywords: Dependencies: | Patchstatus: there is no patch -------------------------+-------------------------------------------------- Some boards have RAMBASE at 0x4000. For some, it's probably a left-over from old times, but others actually require it. Update the former, and fix the latter. Wyse/s50 requires 0x4000, see http://www.coreboot.org/pipermail/coreboot/2010-May/058080.html (and the log file therein) -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/163> coreboot <http://www.coreboot.org/>

5 14

#110: Allow for per-device subsystem IDs
by coreboot 01 Oct '10

01 Oct '10

#110: Allow for per-device subsystem IDs ---------------------------------+------------------------------------------ Reporter: uwe | Owner: somebody Type: enhancement | Status: new Priority: minor | Milestone: Component: coreboot | Version: v3 Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ Currently both v2 and v3 only allow us to use one global set of PCI subsystem IDs, which is too simplistic. In theory (and often in practice) each PCI device has (or can have) its own subsystem ID. We should fix this, at least in v3, possibly also in v2. See also http://www.coreboot.org/pipermail/coreboot/2008-July/036514.html -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/110> coreboot <http://www.coreboot.org/>

1 2

#152: v3 Geode cs5536 UART2 wrongly configured
by coreboot 01 Oct '10

01 Oct '10

#152: v3 Geode cs5536 UART2 wrongly configured -------------------------------------------+-------------------------------- Reporter: edwin_beasant@… | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Going mainstream Component: coreboot | Version: v3 Keywords: serial com2 geode cs5536 | Dependencies: Patchstatus: patch needs review | -------------------------------------------+-------------------------------- The UART2 on the AMD cs5536 is incorrectly configured in two places in v3 code and also in v2. GPIO lines 4 and 3 are swapped and also incorrectly put in IR mode receive (compound fault). This patch corrects the v3 late configuration and the v3 and v2 early (stage1/cache as ram) mis-configuration of UART2 to addres 0x3f8 not the standard 0x2f8 for COM2. -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/152> coreboot <http://www.coreboot.org/>

1 4

#164: Building Coreboot v4 r5555/5554 fails mysteriously on Debian lenny and etch (x86)
by coreboot 29 Sep '10

29 Sep '10

#164: Building Coreboot v4 r5555/5554 fails mysteriously on Debian lenny and etch (x86) ----------------------------+----------------------------------------------- Reporter: juhe@… | Owner: stepan@… Type: defect | Status: new Priority: major | Milestone: Component: coreboot | Keywords: makefile, debian Dependencies: | Patchstatus: there is no patch ----------------------------+----------------------------------------------- I am trying to build Coreboot v4 from SVN with default settings, but I get build failures. The build environment is Debian Linux on x86. Process goes as follows: {{{ - check out coreboot trunk from SVN as per wiki instructions - run "make menuconfig", select QEMU hardware (default), ROM size either 256K or 1M - run "make": }}} {{{ coreboot.r5554$ make HOSTCC util/romcc/romcc (this may take a while) ROMCC mainboard/emulation/qemu-x86/bootblock.inc GEN bootblock/bootblock.c CC mainboard/emulation/qemu-x86/bootblock.s CC mainboard/emulation/qemu-x86/bootblock.o GEN bootblock/ldscript.ld LINK bootblock.elf OBJCOPY coreboot.bootblock HOSTCC cbfstool/common.o [..cut..] HOSTCC util/options/build_opt_tbl OPTION option_table.h GEN build.h ROMCC romstage.inc GEN romstage/crt0.S CC mainboard/emulation/qemu-x86/crt0.s CC mainboard/emulation/qemu-x86/crt0.initobj.o make: *** No rule to make target `/optbuild/lib/uart8250.initobj.o', needed by `build/coreboot.romstage'. Stop. }}} I have tried this on two separate Debian/lenny machines with the same results. Is Debian somehow broken or Coreboot build scripts? Or am I making some mistake? What is this directory /optbuild and why coreboot build is trying to create/access it? I tried to grep "optbuild" from the sources, but it does not seem to exist there. Trying the same on Debian/etch (older release): {{{ % make mkdir: cannot create directory `/optbuild': Permission denied mkdir: cannot create directory `/optbuild': Permission denied mkdir: cannot create directory `/optbuild': Permission denied mkdir: cannot create directory `/optbuild': Permission denied mkdir: cannot create directory `/optbuild': Permission denied mkdir: cannot create directory `/optbuild': Permission denied mkdir: cannot create directory `/optbuild': Permission denied ROMCC mainboard/emulation/qemu-x86/bootblock.inc GEN bootblock/bootblock.c CC mainboard/emulation/qemu-x86/bootblock.s CC mainboard/emulation/qemu-x86/bootblock.o GEN bootblock/ldscript.ld LINK bootblock.elf collect2: ld terminated with signal 11 [Segmentation fault] make: *** [build/bootblock.elf] Error 1 }}} This looks like broken ld in Debian, or something going wrong in the build process. -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/164> coreboot <http://www.coreboot.org/>

1 3

#167: Support for new ION2 (Intel NM10 chipset)
by coreboot 29 Sep '10

29 Sep '10

#167: Support for new ION2 (Intel NM10 chipset) --------------------------------------+------------------------------------- Reporter: niklas.lonn@… | Owner: stepan@… Type: defect | Status: new Priority: major | Milestone: Component: coreboot | Keywords: NM10,ION2,Intel,Asus Dependencies: | Patch Status: there is no patch --------------------------------------+------------------------------------- I have read that the ION platform is not supported because nVidia doesn't release the datasheets in public, however, a new ION2 platform is availabl, having an Intel NM10 north/south-bridge combo with open datashet at: http://www.intel.com/products/Internet_Device/Chipsets/NM10/NM10-technicald… The motherboard of my interest is this one (Probably many others too): http://www.asus.com/product.aspx?P_ID=iIZKMXSj0jZKiebE&templete=2 -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/167> coreboot <http://www.coreboot.org/>

4 6

#161: Improve USB debug port configuration
by coreboot 29 Sep '10

29 Sep '10

#161: Improve USB debug port configuration ----------------------------+----------------------------------------------- Reporter: oxygene | Owner: stepan@… Type: enhancement | Status: new Priority: trivial | Milestone: Component: coreboot | Keywords: Dependencies: | Patchstatus: there is no patch ----------------------------+----------------------------------------------- Right now, the right port number is configured in DBGP_DEFAULT without much documentation anywhere. It's even defined in boards that don't use the value at all. Maybe move it to Kconfig? Document it? Just clean up the copy&pasted useless values? -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/161> coreboot <http://www.coreboot.org/>

1 2

[PATCH]some more bus entry in mptables derived from device tree
by Patrick Georgi 24 Sep '10

24 Sep '10

Hi, attached patch derives coreboot create bus data in the mptable automatically from the device tree for a couple more boards. It's build tested, but not run tested. Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de>

2 2

Re: [coreboot] [PATCH][again] 440BX raminit cleanup
by Keith Hui 21 Sep '10

21 Sep '10

On Tue, May 18, 2010 at 8:41 PM, <coreboot-request(a)coreboot.org> wrote: > Send coreboot mailing list submissions to > coreboot(a)coreboot.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.coreboot.org/mailman/listinfo/coreboot > or, via email, send a message with subject or body 'help' to > coreboot-request(a)coreboot.org > > You can reach the person managing the list at > coreboot-owner(a)coreboot.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of coreboot digest..." > > > Today's Topics: > > 1. Re: [PATCH][again] 440BX raminit cleanup (Stefan Reinauer) > 2. Re: H8QME 128GB RAM not Booting (Myles Watson) > 3. [commit] r5569 - in trunk/src/superio/winbond: w83627ehg > w83627hf (repository service) > 4. Advice how to install Linux to get it working with FILO > (Joop Boonen) > 5. Re: FILO bug disk not seen at ata-0 (Doesn't try to detect on > ATA only SIL3114) (Kevin O'Connor) > 6. ask for support for some hardware (Benediktus Anindito) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 18 May 2010 18:02:26 +0200 > From: Stefan Reinauer <stefan.reinauer(a)coresystems.de> > To: coreboot(a)coreboot.org > Subject: Re: [coreboot] [PATCH][again] 440BX raminit cleanup > Message-ID: <4BF2BA12.8090903(a)coresystems.de> > Content-Type: text/plain; charset=windows-1252 > >> >> A number of cleanups for 440BX raminit code. >> >> Resolves a number of TODOs items within, and clarified a number of other TODOs. >> Change register_values[] from long to u8 (byte). For what we are doing >> this is sufficient and makes it only 1/4 the size. >> Remove a hard-coding of SDRAMC register that is redundant and now >> incorrect, now that SDRAMC is conditioned on SDRAMPWR_4DIMM Kconfig >> and set through register_values[]. >> RPS registers are now set in runtime code; remove it from >> register_values[] table. >> Bring DUMPNORTH() back. The code it refers to is still there. >> Move #define of NB up so the DUMPNORTH() macro can use it. >> >> Signed-off-by: Keith Hui <buurin(a)gmail.com> >> > > -// no dump_pci_device in src/northbridge/intel/i440bx > -// #define DUMPNORTH() dump_pci_device(PCI_DEV(0, 0, 0)) > -#define DUMPNORTH() > +#define DUMPNORTH() dump_pci_device(NB) > > Does this still compile with CONFIG_DEBUG_RAM_SETUP set? > Yes it does. And it runs. Idwer posted a boot log here with this patch applied. > > + * Bits referencing empty rows are ?don?t care?. > > that looks odd... > That is straight from the 440BX datasheet. > > > - /* TODO: Set SDRAMC. */ > - pci_write_config16(NB, SDRAMC, 0x0010); /* SDRAMPWR=1: 4 DIMM config */ > - > > This part is deleted without a replacement. Is it not needed? Is this > set somewhere else? > Set somewhere else. It is now an entry in the register_values[] array. Value is set conditionally at compile time by CONFIG_SDRAMPWR_4DIMM. Thanks Keith

2 1

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 August 2010