coreboot July 2010

coreboot@coreboot.org

57 participants
142 discussions

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

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

flashrom patch: add support for Abit AB-BM6 board
by Tim ter Laak 14 Sep '10

14 Sep '10

Hello all, This patch adds support for the Abit AB-BM6 mainboard to flashrom. The biggest part is a generic function to lower a GPIO line on the PIIX4E southbridge, copied and adapted from its ich_gpio_raise() counterpart (mostly lower instead of raise, followed names from the PIIX4E datasheet). The board specific function then uses this to lower GPO 26. Signed-off-by: Tim ter Laak <timl(a)scintilla.utwente.nl> --- The patch was made from the flashrom subdir, because svn diff from the top-level coreboot dir (as per the directions in the Development Guidelines on the wiki) didn't seem to work for me. Probably because flashrom is fetched externally when checking out coreboot? Anyway, I hope this is okay. If you really prefer a diff from the top-level dir just let me know, and I'll regenerate it with gnu diff. Kind regards, Tim. Index: board_enable.c =================================================================== --- board_enable.c (revision 3559) +++ board_enable.c (working copy) @@ -349,6 +349,58 @@ } /** + * Set the specified GPIO on the specified PIIX4 southbridge to low. + * + * @param name The name of this board. + * @param piix_vendor PCI vendor ID of the specified PIIX4 southbridge. (0x8086) + * @param piix_device PCI device ID of the specified PIIX4 southbridge, function Power Management (0x7113 for PIIX4E) + * @param pmbase_reg PMBASE register offset in the bridge. (0x40 for PIIX4E) + * @param pmbase_mask PMBASE bitmask (0xFFC0) + * @param gporeg Offset of GPOREG register in I/O space, relative to GPIOBASE. (0x34) + * @param gpio_bit The bit (GPIO) which shall be set to low. + * @return If the write-enable was successful return 0, otherwise return -1. + */ +static int piix4_gpio_lower(const char *name, uint16_t piix_vendor, + uint16_t piix_device, uint8_t pmbase_reg, + uint8_t gporeg, uint32_t pmbase_mask, + unsigned int gpio_bit) +{ + struct pci_dev *dev; + uint16_t pmbar; + uint32_t reg32; + + dev = pci_dev_find(piix_vendor, piix_device); /* Intel PIIX4 ACPI function */ + if (!dev) { + fprintf(stderr, "\nERROR: PIIX4 dev %4x:%4x not found.\n", + piix_vendor, piix_device); + return -1; + } + + /* Use PMBASE register to find the I/O space for GPIO. */ + pmbar = pci_read_word(dev, pmbase_reg) & pmbase_mask; + + /* Set specified GPIO to high. */ + reg32 = INL(pmbar + gporeg); + OUTB(0x00, 0xEB); /* dummy write to unused port as delay */ + + reg32 &= ~(1 << gpio_bit); + OUTL(reg32, pmbar + gporeg); + OUTB(0x00, 0xEB); /* another delay */ + + return 0; +} + +/** + * Suited for Abit AB-BM6. + */ +static int piix4_gpio26_lower(const char *name) +{ + return piix4_gpio_lower(name, 0x8086, 0x7113, 0x40, 0x34, 0xffc0, 26); +} + + + +/** * Suited for Acorp 6A815EPD. */ static int board_acorp_6a815epd(const char *name) @@ -672,6 +724,8 @@ NULL, NULL, "GIGABYTE GA-7VT600", board_biostar_p4m80_m4}, {0x1106, 0x3149, 0x1462, 0x7094, 0x10ec, 0x8167, 0x1462, 0x094c, NULL, NULL, "MSI K8T Neo2", w83627thf_gpio4_4_raise_2e}, + {0x8086, 0x7190, 0x0000, 0x0000, 0x8086, 0x7110, 0x0000, 0x0000, + "abit", "ab-bm6", "Abit AB-BM6", piix4_gpio26_lower}, {0, 0, 0, 0, 0, 0, 0, 0, NULL, NULL} /* Keep this */ };

5 13

[PATCH] Istanbul support
by Arne Georg Gleditsch 13 Sep '10

13 Sep '10

Hi, The following patch implements Opteron Fam 10 rev D (aka Istanbul) support for coreboot. I have not updated MAX_CPUS for all fam10 mainboards, but it might make sense to multiply those by 1.5. Signed-off-by: Arne Georg Gleditsch <arne.gleditsch(a)numascale.com> -- Arne.

9 43

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