coreboot January 2014

coreboot@coreboot.org

54 participants
116 discussions

2508-A65 X60s
by The Gluglug 13 Jan '14

13 Jan '14

Is it an X60s? Apparently so, but flashrom does not seem to support it. sudo ./flashrom -p internal -V Internal programmer initialization failed (see [1], no modifications made to flashrom). I changed the entries accordingly for either Macronix or SST. Lenovo site says X60s, DMI (according to flashrom) says it's a T43p. (testing now with external programmer) [1] flashrom v0.9.7-r on Linux 3.2.0-38-generic-pae (i686) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.1.8, GCC 4.6.3, little endian Command line (3 args): ./flashrom -p internal -V Calibrating delay loop... OS timer resolution is 2 usecs, 1021M loops per second, 10 myus = 12 us, 100 myus = 109 us, 1000 myus = 1076 us, 10000 myus = 9577 us, 8 myus = 9 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: "LENOVO" DMI string system-product-name: "2508A65" DMI string system-version: "ThinkPad T43p" DMI string baseboard-manufacturer: "LENOVO" DMI string baseboard-product-name: "2508A65" DMI string baseboard-version: "Not Available" DMI string chassis-type: "Notebook" Laptop detected via DMI.

2 3

Seeking for reviewers: X201 (enable S3 & al) and X230
by Vladimir 'φ-coder/phcoder' Serbinenko 12 Jan '14

12 Jan '14

Hello, all. I've just uploaded 2 patchsets: X201 which fixes all known issues including S3 resume but except Gnome battery reporting. Top for x201 is at http://review.coreboot.org/#/c/4632/ and few separate patches with theme "x201" (X201-specific) and "thinkpad" (having benefits for X60/T60 as well). X230 top is at http://review.coreboot.org/#/c/4679/

1 0

Re: [coreboot] [RFC] Short license headers
by Anthony Martin 11 Jan '14

11 Jan '14

David Hendricks <david.hendricks(a)gmail.com> once said: > IANAL, but from what I understand it's usually a good idea to avoid mucking > with legalese as to avoid unintended consequences of how licenses are > enforced, particularly with regard to international treaties pertaining to > IP and copyrighted works. The Go project uses short license headers so it must have already been vetted by Google's team of lawyers. > Also, there are a few distinct free software licenses used in coreboot so > I'd hate to add to the confusion. Keeping the licenses in their canonical > form and applying them to ever file ensures that coreboot gets all the > proper legal protections. Here's an example of how code with a different license is handled in the Go project: https://code.google.com/p/go/source/browse/src/pkg/math/acosh.go Cheers, Anthony

1 0

#186: 3com 3c905tx / gpxe boot problem
by coreboot 11 Jan '14

11 Jan '14

#186: 3com 3c905tx / gpxe boot problem -----------------------------------+---------------------------------- Reporter: jeroenkrabbendam@… | Owner: stepan@… Type: defect | Status: new Priority: minor | Milestone: Component: coreboot | Keywords: gpxe Dependencies: | Patch Status: there is no patch -----------------------------------+---------------------------------- Although (or: just because) novice in the field, I encountered some problems with netbooting with coreboot. Mobo's tried: Asus P2B, VTech with bios id ITE8671-2A69KV3IC-00. All mobo's boot '''harddisk''' fine with Asus P2B / Gigabyte GA-6BX{CE} respectively. NIC ROM is started, and loads the kernel by tftp. This is vvvveeeerrrryyy slow! Although loading, the kernel is never able to start itself. Same kernel on HDU is no problem at all (GRUB2) Note: the gpxe-image is on the nic, coreboot payload is seabios. -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/186> coreboot <http://www.coreboot.org/>

1 1

Re: [coreboot] [RFC] Short license headers
by mrnuke 11 Jan '14

11 Jan '14

On 01/10/2014 10:03 PM, David Hendricks wrote: > Thanks for bringing this up. I was kind of on the fence about approving > your Cubieboard changes because of some of the license headers, but > shrugged it off thinking that the intent was obvious enough. > > IANAL, but from what I understand it's usually a good idea to avoid > mucking with legalese as to avoid unintended consequences of how > licenses are enforced, particularly with regard to international > treaties pertaining to IP and copyrighted works. > > Also, there are a few distinct free software licenses used in coreboot > so I'd hate to add to the confusion. Keeping the licenses in their > canonical form and applying them to ever file ensures that coreboot gets > all the proper legal protections. > Linux and a few other projects already use short headers. > Maybe someone more familiar with software licensing can shed some light > on the subject. >

1 0

Re: [coreboot] [RFC] MMC support in coreboot
by mrnuke 11 Jan '14

11 Jan '14

On 01/10/2014 05:05 PM, Gabe Black wrote: > It really depends on how that blob built into the SOC works. On the > Tegra chips and on the SOC in the Beaglebone, the amount that's loaded > depends on a data structure bundled in with the firmware. On the > Beaglebone I told it to load enough of CBFS that it could get the ROM > stage out of SRAM without having to talk to the boot media again. > Anything beyond that, though, would require talking to the media. On > Exynos the blob on the SOC loads another fixed size Samsung provided > blob from the boot media which then loads the actual firmware. There it > depends on how that blob works. Sometimes the blob loads a fixed size > chunk, and sometimes it loads a variably sized blob which is described > in a small header. I think the blobs we have in the coreboot repository > are one of each, fixed size for the 5250 and variably sized for the 5420. > Gabe, that's the perfect example. We have a different way for each chip because "it really depends on how that blob built into the SOC works". Is that really the case? Every time there's a new ARM SoC we have to reinvent CBFS loading. That sounds wrong. Ron was talking about a unified approach. I think it's time we start doing that now, before it gets messy. Re Exynos, the SPI code imposes an alignment of 4 bytes. It's cleverly hidden, but that is a little block device logic nonetheless. Alex

2 1

[RFC] MMC support in coreboot
by mrnuke 11 Jan '14

11 Jan '14

It's essential for some ARM SoCs. Allwinner chips like the MMC as their first boot source, and people are very happy with having their firmware and linux on micro SD. It makes the system unbrickable. For coreboot, this presents a whole new set of challenges. First off, MMC, NAND and friends are block devices. Unlike SPI, which is easily integrateable as an alternate CBFS driver, block devices are a whole new beast. First, there's the potential of code reuse, or excessive duplication, depending on how you look at it. uboot has a 1500+ LOC driver for MMC/SD handling. Beynod that, low-level operations are passed to device-specific drivers. I'm not happy with the details of the uboot code, and have tried to adapt it for coreboot [1]. The result is a complete mess. This is part of a larger effort to bring Allwinner support to coreboot[2]. We need block device and MMC/SD support (at least for Allwinner at the moment), and we need to do it coreboot style. That means high quality, readable code, and most of all modular. We need an API on which to build things. I'm not happy with the uboot model here: it's not clear what belongs where. So, how do we handle block devices, then MMC/SD, and potentially NAND? I can adapt the existing code to a specification, but I am disqualified to write that spec, as I have been brainwashed by working with the uboot code[2]. It works, but we need a coreboot-centric approach. Any takers? Alex [1] http://review.coreboot.org/4631 [2] https://github.com/mrnuke/coreboot cubie_mmc branch

4 4

three errors found while compiling FILO (1 fix + 1 workaround)
by Andrew Engelbrecht 10 Jan '14

10 Jan '14

i ran into three issues when trying to build FILO in the coreboot git repo, using make menuconfig and make. i found work-arounds for two of them. here are the issues: TL;DR: 1.) include/arch doesn't exist (work-around by symlinking) 2.) conflicting types error 3.) invalid git command when building from HEAD. (patch provided) $ make ... MAKE FILO STABLE Found Libpayload /home/sudoman/src/3rd-party/fsf/coreboot-src/payloads/external/FILO/filo/build/libpayload/lib/libpayload.a. CC build/i386/context.o In file included from /home/sudoman/src/3rd-party/fsf/coreboot-src/payloads/external/FILO/filo/build/libpayload/include/libpayload.h:49:0, from /home/sudoman/src/3rd-party/fsf/coreboot-src/payloads/external/FILO/filo/i386/context.c:24: /home/sudoman/src/3rd-party/fsf/coreboot-src/payloads/external/FILO/filo/build/libpayload/include/stddef.h:2:24: fatal error: arch/types.h: No such file or directory #include <arch/types.h> ^ compilation terminated. make[2]: *** [/home/sudoman/src/3rd-party/fsf/coreboot-src/payloads/external/FILO/filo/build/i386/context.o] Error 1 make[1]: *** [filo] Error 2 make: *** [filo] Error 2 $ cd payloads/external/FILO/filo/build/libpayload/include/ $ ln -s x86/arch/ $ make ... MAKE FILO STABLE Found Libpayload /home/sudoman/src/3rd-party/fsf/coreboot-src/payloads/external/FILO/filo/build/libpayload/lib/libpayload.a. CC build/i386/context.o In file included from /home/sudoman/src/3rd-party/fsf/coreboot-src/payloads/external/FILO/filo/i386/context.c:25:0: include/lib.h:28:6: error: conflicting types for ‘hexdump’ void hexdump(const void *p, unsigned int len); ^ In file included from /home/sudoman/src/3rd-party/fsf/coreboot-src/payloads/external/FILO/filo/i386/context.c:24:0: /home/sudoman/src/3rd-party/fsf/coreboot-src/payloads/external/FILO/filo/build/libpayload/include/libpayload.h:297:6: note: previous declaration of ‘hexdump’ was here void hexdump(void *memory, int length); ^ make[2]: *** [/home/sudoman/src/3rd-party/fsf/coreboot-src/payloads/external/FILO/filo/build/i386/context.o] Error 1 make[1]: *** [filo] Error 2 make: *** [filo] Error 2 If I set FILO to build from HEAD through make menuconfig, i get this error: ... GIT FILO HEAD Switched to branch 'master' Your branch is up-to-date with 'origin/master'. Already up-to-date. fatal: it does not make sense to create 'HEAD' manually make[1]: *** [checkout] Error 128 make: *** [filo] Error 2 I modified the FILO/Makefile.inc file, to make this work: diff --git a/payloads/external/FILO/Makefile.inc b/payloads/external/FILO/Makefile.inc index 311b3c8..9e62d6c 100644 --- a/payloads/external/FILO/Makefile.inc +++ b/payloads/external/FILO/Makefile.inc @@ -14,9 +14,10 @@ checkout: cd filo && \ git checkout master && \ git pull; \ - test -n $(TAG-y) && \ + if [ -n "$(TAG-y)" ] ; then \ git branch -f $(NAME-y) $(TAG-y) && \ - git checkout $(NAME-y) + git checkout $(NAME-y); \ + fi config: libpayload echo " CONFIG FILO $(NAME-y)" ---- the patch is also attached to this email. after running make again, I got the "conflicting types" error again. I tried building FILO out of the coreboot tree, by following the instructions on the coreboot wiki fairly closely, but got the same/similar errors. ---- here is my .config: CONFIG_LOCALVERSION="" CONFIG_CBFS_PREFIX="fallback" CONFIG_COMPILER_GCC=y CONFIG_COMPRESS_RAMSTAGE=y CONFIG_INCLUDE_CONFIG_FILE=y CONFIG_VENDOR_ASUS=y CONFIG_BOARD_SPECIFIC_OPTIONS=y CONFIG_MAINBOARD_DIR="asus/f2a85-m" CONFIG_MAINBOARD_PART_NUMBER="F2A85-M" CONFIG_IRQ_SLOT_COUNT=11 CONFIG_MAINBOARD_VENDOR="ASUS" CONFIG_APIC_ID_OFFSET=0x0 CONFIG_HW_MEM_HOLE_SIZEK=0x200000 CONFIG_MAX_CPUS=4 CONFIG_MAX_PHYSICAL_CPUS=1 CONFIG_RAMTOP=0x1000000 CONFIG_HEAP_SIZE=0xc0000 CONFIG_RAMBASE=0x200000 CONFIG_VGA_BIOS_ID="1002,9993" CONFIG_DRIVERS_PS2_KEYBOARD=y CONFIG_DCACHE_RAM_BASE=0x30000 CONFIG_DCACHE_RAM_SIZE=0x10000 CONFIG_SERIAL_CPU_INIT=y CONFIG_ACPI_SSDTX_NUM=0 CONFIG_HUDSON_LEGACY_FREE=y CONFIG_BOARD_ASUS_F2A85_M=y CONFIG_BOARD_ASUS_F2A85_M_DDR3_VOLT_150=y CONFIG_BOARD_ASUS_F2A85_M_DDR3_VOLT_VAL=0x0 CONFIG_MMCONF_BASE_ADDRESS=0xF8000000 CONFIG_ID_SECTION_OFFSET=0x80 CONFIG_XIP_ROM_SIZE=0x100000 CONFIG_UDELAY_LAPIC_FIXED_FSB=200 CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="ASUS" CONFIG_MAINBOARD_VERSION="1.0" CONFIG_CPU_ADDR_BITS=48 CONFIG_LOGICAL_CPUS=y CONFIG_IOAPIC=y CONFIG_SMP=y CONFIG_TTYS0_BAUD=115200 CONFIG_TTYS0_BASE=0x3f8 CONFIG_TTYS0_LCS=3 CONFIG_DEFAULT_CONSOLE_LOGLEVEL=8 CONFIG_CONSOLE_SERIAL8250=y CONFIG_BOARD_ROMSIZE_KB_8192=y CONFIG_COREBOOT_ROMSIZE_KB_2048=y CONFIG_COREBOOT_ROMSIZE_KB=2048 CONFIG_ROM_SIZE=0x200000 CONFIG_MAINBOARD_SERIAL_NUMBER="123456789" CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="F2A85" CONFIG_ARCH_X86=y CONFIG_X86_ARCH_OPTIONS=y CONFIG_STACK_SIZE=0x1000 CONFIG_MAX_REBOOT_CNT=3 CONFIG_NUM_IPI_STARTS=2 CONFIG_X86_BOOTBLOCK_SIMPLE=y CONFIG_BOOTBLOCK_SOURCE="bootblock_simple.c" CONFIG_PC80_SYSTEM=y CONFIG_BOOTBLOCK_SOUTHBRIDGE_INIT="southbridge/amd/agesa/hudson/bootblock.c" CONFIG_IOAPIC_INTERRUPTS_ON_FSB=y CONFIG_HPET_ADDRESS=0xfed00000 CONFIG_HAVE_ARCH_MEMSET=y CONFIG_HAVE_ARCH_MEMCPY=y CONFIG_HAVE_ARCH_MEMMOVE=y CONFIG_CPU_SOCKET_TYPE=0x10 CONFIG_CBB=0x0 CONFIG_CDB=0x18 CONFIG_DIMM_SUPPORT=0x0104 CONFIG_LIFT_BSP_APIC_ID=y CONFIG_CPU_AMD_AGESA=y CONFIG_HAVE_INIT_TIMER=y CONFIG_HIGH_SCRATCH_MEMORY_SIZE=0xA1000 CONFIG_CPU_AMD_AGESA_FAMILY15_TN=y CONFIG_SMM_TSEG_SIZE=0 CONFIG_UDELAY_LAPIC=y CONFIG_LAPIC_MONOTONIC_TIMER=y CONFIG_TSC_SYNC_LFENCE=y CONFIG_X86_AMD_FIXED_MTRRS=y CONFIG_CACHE_AS_RAM=y CONFIG_AP_SIPI_VECTOR=0xfffff000 CONFIG_CPU_MICROCODE_CBFS_NONE=y CONFIG_SB_HT_CHAIN_UNITID_OFFSET_ONLY=y CONFIG_VIDEO_MB=0 CONFIG_AMDMCT=y CONFIG_MMCONF_BUS_NUMBER=64 CONFIG_NORTHBRIDGE_AMD_AGESA=y CONFIG_NORTHBRIDGE_AMD_AGESA_FAMILY15_TN=y CONFIG_CBFS_SIZE=0x200000 CONFIG_MAX_PIRQ_LINKS=4 CONFIG_EHCI_BAR=0xfef00000 CONFIG_EHCI_DEBUG_OFFSET=0xe0 CONFIG_S3_DATA_POS=0xFFFF0000 CONFIG_S3_DATA_SIZE=32768 CONFIG_SOUTHBRIDGE_AMD_AGESA_HUDSON=y CONFIG_HUDSON_XHCI_ENABLE=y CONFIG_HUDSON_SATA_IDE=y CONFIG_HUDSON_SATA_MODE=0x0 CONFIG_AMD_SB_SPI_TX_LEN=4 CONFIG_SPI_FLASH=y CONFIG_SUPERIO_ITE_IT8712F=y CONFIG_VGA_ROM_RUN=y CONFIG_ON_DEVICE_ROM_RUN=y CONFIG_PCI_OPTION_ROM_RUN_REALMODE=y CONFIG_PCI=y CONFIG_PCIX_PLUGIN_SUPPORT=y CONFIG_PCIEXP_PLUGIN_SUPPORT=y CONFIG_AGP_PLUGIN_SUPPORT=y CONFIG_CARDBUS_PLUGIN_SUPPORT=y CONFIG_PCI_BUS_SEGN_BITS=0 CONFIG_PXE_ROM=y CONFIG_PXE_ROM_FILE="../ipxe/src/bin/10ec8168.rom" CONFIG_PXE_ROM_ID="10ec,8168" CONFIG_SUBSYSTEM_VENDOR_ID=0x0000 CONFIG_SUBSYSTEM_DEVICE_ID=0x0000 CONFIG_RTL8168_ROM_DISABLE=y CONFIG_SPI_FLASH_EON=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_SST=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_MMCONF_SUPPORT=y CONFIG_EARLY_CONSOLE=y CONFIG_SQUELCH_EARLY_SMP=y CONFIG_CONSOLE_SERIAL=y CONFIG_CONSOLE_SERIAL_COM1=y CONFIG_CONSOLE_SERIAL_115200=y CONFIG_HAVE_USBDEBUG=y CONFIG_HAVE_USBDEBUG_OPTIONS=y CONFIG_DEFAULT_CONSOLE_LOGLEVEL_8=y CONFIG_IO_POST=y CONFIG_IO_POST_PORT=0x80 CONFIG_HAVE_UART_IO_MAPPED=y CONFIG_HAVE_ACPI_RESUME=y CONFIG_HAVE_HARD_RESET=y CONFIG_HAVE_MONOTONIC_TIMER=y CONFIG_HAVE_OPTION_TABLE=y CONFIG_PCI_IO_CFG_EXT=y CONFIG_CACHE_ROM_SIZE=0x200000 CONFIG_GFXUMA=y CONFIG_HAVE_ACPI_TABLES=y CONFIG_HAVE_MP_TABLE=y CONFIG_HAVE_PIRQ_TABLE=y CONFIG_MULTIBOOT=y CONFIG_GENERATE_ACPI_TABLES=y CONFIG_GENERATE_MP_TABLE=y CONFIG_GENERATE_PIRQ_TABLE=y CONFIG_GENERATE_SMBIOS_TABLES=y CONFIG_PAYLOAD_FILO=y CONFIG_FILO_MASTER=y CONFIG_PAYLOAD_FILE="payloads/external/FILO/filo/build/filo.elf" CONFIG_COMPRESSED_PAYLOAD_LZMA=y CONFIG_WARNINGS_ARE_ERRORS=y

2 2

Re: [coreboot] Strange Coreboot behaviors while building IVB Cougar Canyon Coreboot based upon intel.com/fsp IVB FSP
by Marc Jones 10 Jan '14

10 Jan '14

Is the descriptor binary in the second 4MB flash. The split flash is a little confusing, but handy as you can make changes to coreboot and not the descriptor and me. Do you get post codes? Marc On Fri, Jan 10, 2014 at 7:26 AM, Stojsavljevic, Zoran < zoran.stojsavljevic(a)intel.com> wrote: > Hello, > > After long time, I am returning to this domain, in attempt to build valid > Coreboot using git clone from Coreboot.org . > > I have two instances I cloned, one is v4.0-4966, another one is latest > (cloned today) v4.0-5223 ... > > Here is what I have while building v4.0-4966 (.config attached to the > email as CONFIG_4966): > > coreboot.rom: 8192 kB, bootblocksize 864, romsize 8388608, offset 0x400000 > alignment: 64 bytes > > Name Offset Type Size > cmos_layout.bin 0x400000 cmos_layout 1164 > pci8086,0166.rom 0x4004c0 optionrom 65536 > cpu_microcode_blob.bin 0x410500 microcode 32832 <<===== YES, > microcode integrated > fallback/romstage 0x4185c0 stage 31082 > fallback/coreboot_ram 0x41ff80 stage 75924 > fallback/payload 0x432880 payload 55177 > config 0x440080 raw 4322 > (empty) 0x4411c0 null 3403224 > fsp.bin 0x77ffc0 (unknown) 393216 > (empty) 0x7e0000 null 130072 > > Needless to say, for some reason reset vector does not start (I see no > serial outputs from FSP even)! > > Here is what I have while building v4.0-5223 (.config attached to the > email as CONFIG_5223): > > coreboot.rom: 8192 kB, bootblocksize 992, romsize 8388608, offset 0x400000 > alignment: 64 bytes > > Name Offset Type Size > cmos_layout.bin 0x400000 cmos_layout 1164 > pci8086,0166.rom 0x4004c0 optionrom 65536 > fallback/romstage 0x410500 stage 31583 > fallback/coreboot_ram 0x4180c0 stage 75182 > fallback/payload 0x42a6c0 payload 55156 > config 0x437e80 raw 4419 > (empty) 0x439000 null 3370904 > cpu_microcode_blob.bin 0x76ffc0 microcode 0 <<===== NO > microcode!!! > (empty) 0x770000 null 65432 > fsp.bin 0x77ffc0 (unknown) 393216 > (empty) 0x7e0000 null 129944 > > The same: reset vector does not go! > > Strange. Any clues? > > Thank you, > Zoran > _______ > Most of The Time you should be "intel inside" to be capable to think "out > of the box". > > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- http://se-eng.com

1 0

Re: [coreboot] Strange Coreboot behaviors while building IVB Cougar Canyon Coreboot based upon intel.com/fsp IVB FSP
by mrnuke 10 Jan '14

10 Jan '14

On 01/10/2014 08:26 AM, Stojsavljevic, Zoran wrote: > Name Offset Type Size > cpu_microcode_blob.bin 0x410500 microcode 32832 <<===== YES, microcode integrated > > Name Offset Type Size > cpu_microcode_blob.bin 0x76ffc0 microcode 0 <<===== NO microcode!!! > > Strange. Any clues? > You might want to bisect that and see which commit empties out the microcode.

1 0

← Newer
1
...
5
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2014