-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
Greetings
Alex Veek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iF4EAREIAAYFAlNxKzsACgkQ53cWmi2XuzOOXAD8CNLPoycJNftQzeHnMQbl8ZG9
4y2SPIHwLota1/Gsfm0BAJzhG2M+MKXDBJgazHjt/HM2DyAeHi6S24sGcwd1W2GN
=sFKM
-----END PGP SIGNATURE-----
Hi Iru,
we aren't still sure which boards use Intel Boot Guard and which doesn't use it. But we expect most board use it,
because it's "recommended" by intel - as we dont recommend it.
Also there isn't yet a test script for Intel Boot Guard.
Can you post a link to that forum post?
I would like to look into a x240 flash image. If you have such board it would be nice
if you can send me a copy of the flash image via private mail.
Cheers,
lynxis
--
Alexander Couzens
mail: lynxis(a)fe80.eu
jabber: lynxis(a)jabber.ccc.de
mobile: +4915123277221
All,
I have successfully ported coreboot to the relatively modern ASUS
KGPE-D16 server board (dual AMD socket G34, 16 DDR3 DIMMs,
https://www.asus.com/us/Commercial_Servers_Workstations/KGPED16/)! This
port uses native Family 10h initialization (_not_ AGESA or CIMX).
The Libreboot folks will be interested to know that this board can run
blob-free and still retain full functionality!
Port specifications:
CPU: Dual AMD G34 Magny-Cours (Family 10h)
RAM: 16 DDR3 DIMM slots with ECC support (tested with x4 4G DDR3-1333
unbuffered DIMMs)
Peripherals:
PCIe slots: all functional
PCI slot: functional
RS-232: functional
PS/2: expected to function, not tested (on SuperIO)
ASpeed VGA device: functional (text mode, see below)
IEEE1394: functional
On-board USB: functional
On-board NICs: functional
ASUS PIKE SAS controller: functional
PCIe ROMs: functional
Power management:
DDR3 voltage set: functional
ACPI/APIC: functional
Suspend/resume: broken
Other:
cbmem console: partial support (log truncated)
cbmem timestamps: functional
nvram: functional
BIOS recovery jumper: functional
ASpeed VGA:
The ASpeed VGA device initialises in text mode via its (new) coreboot
driver, however this initialisation is incomplete, leading to distorted
but quite usable VGA output. When Linux boots and engages the graphical
framebuffer all distortion disappears.
This port was not trivial. Almost every device used was broken and
required debugging/repair, with the notable exception of the SuperIO
chip. The AMD DDR3 controller was severely broken to the point where
large rewrites were needed in order to bring it in line with the BKDG.
Even after the various component drivers were repaired
Due to the labor-intensive nature of the port and the extensive changes
throughout the entire source tree, it is not economically feasible to
merge this port upstream at this time (I estimate upward of 30
independent patches would be required just to get the board booting!).
Raptor Engineering will, however, be continuing to maintain this port
internally, and I am currently looking into adding native Family 15h
support on top of this internal tree. Additionally, while it was not a
priority for the initial port, I will be attempting to enable
suspend/resume functionality as I have time.
If there is sufficient interest from the community in adding this board
to coreboot I would consider merging the changes in exchange for a
one-time contract payment in the vicinity of $35,000 USD. When
considering this offer please bear in mind that this is a fully
functional blobless board with a wide range of peripherals and expansion
options available, and that once these large changes are merged I will
continue to enhance coreboot functionality as before (e.g. with the
KFSN4-DRE and the T400). I would also be willing to add this board to
the test stand as the only fully supported 4-way Opteron board (socket
G34 Magny-Cours CPUs contain two separate CPUs in one package, making
this 2-socket board a 4-way system from a HyperTransport perspective).
Please let me know if you have any questions!
--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645
http://www.raptorengineeringinc.com
Hello,
I try to perform some memory test on the Mohon Peak CRB with memtest86+.
I downloaded memtest86+ v5.01 and compile it. So far, so good.
Following the thread:
http://www.coreboot.org/pipermail/coreboot/2015-January/079143.html
concerning this topic, I modified the given values, so that now:
[root@localhost memtest86+-5.01]# readelf -e memtest1modified
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x10000
Start of program headers: 52 (bytes into file)
Start of section headers: 151580 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 40 (bytes)
Number of section headers: 3
Section header string table index: 2
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk
Inf Al
[ 0] NULL 00000000 000000 000000 00
0 0 0
[ 1] .data PROGBITS 00010000 001000 024008 00 WA
0 0 1
[ 2] .shstrtab STRTAB 00000000 025008 000011 00
0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x010000 0x00010000 0x00010000 0x24008 0x24008 RW
0x200000
Section to Segment mapping:
Segment Sections...
00 .shstrtab
[root@localhost memtest86+-5.01]#
What gives the same scheme as in the previously mentionned thread.
Now the logs of the booting Mohon Peak (from begin of Seabios):
SeaBIOS (version
rel-1.8.0-12-ga1ac886-dirty-20150402_003540-localhost.localdomain)
init usb
EHCI init on dev 00:16.0 (regs=0xdfe89420)
set_address 0x7fd41b80
config_usb: 0x7fd41a50
device rev=0200 cls=09 sub=00 proto=01 size=64
init serial
Found 2 legacy serial ports
init hard drives
init ahci
AHCI controller at 17.0, iobase dfe88000, irq 15
AHCI: cap 0xc720ff03, ports_impl 0x0
AHCI controller at 18.0, iobase dfe88800, irq 0
AHCI: cap 0xc3309f01, ports_impl 0x1
AHCI/0: probing
AHCI/0: link up
AHCI/0: ... finished, status 0x51, ERROR 0x4
Searching bootorder for: /pci@i0cf8/*@18/drive@0/disk@0
AHCI/0: registering: "AHCI/0: ST500DM002-1BD142 ATA-8 Hard-Disk (465
GiBytes)"
Registering bootable: AHCI/0: ST500DM002-1BD142 ATA-8 Hard-Disk (465
GiBytes) (type:2 prio:103 data:f3ef0)
Searching bootorder for: /rom@img/Memtest86+
Registering bootable: Payload [Memtest86+] (type:32 prio:9999 data:ffe23240)
Scan for option roms
Attempting to init PCI bdf 00:00.0 (vd 8086:1f08)
Attempting to init PCI bdf 00:01.0 (vd 8086:1f10)
Attempting to init PCI bdf 00:03.0 (vd 8086:1f12)
Attempting to init PCI bdf 00:0e.0 (vd 8086:1f14)
Attempting to init PCI bdf 00:0f.0 (vd 8086:1f16)
Attempting to init PCI bdf 00:13.0 (vd 8086:1f15)
Attempting to init PCI bdf 00:14.0 (vd 8086:1f41)
Attempting to init PCI bdf 00:14.1 (vd 8086:1f41)
Attempting to init PCI bdf 00:16.0 (vd 8086:1f2c)
Attempting to init PCI bdf 00:17.0 (vd 8086:1f22)
Attempting to init PCI bdf 00:18.0 (vd 8086:1f32)
Attempting to init PCI bdf 00:1f.0 (vd 8086:1f38)
Attempting to init PCI bdf 00:1f.3 (vd 8086:1f3c)
Attempting to init PCI bdf 01:00.0 (vd 1415:c158)
Attempting to init PCI bdf 02:00.0 (vd 10b5:8624)
Attempting to init PCI bdf 03:04.0 (vd 10b5:8624)
Attempting to init PCI bdf 03:05.0 (vd 10b5:8624)
Attempting to init PCI bdf 03:08.0 (vd 10b5:8624)
Attempting to init PCI bdf 05:00.0 (vd 8086:1528)
Attempting to init PCI bdf 05:00.1 (vd 8086:1528)
Press ESC for boot menu.
Select boot device:
1. AHCI/0: ST500DM002-1BD142 ATA-8 Hard-Disk (465 GiBytes)
2. Payload [Memtest86+]
Searching bootorder for: HALT
Mapping hd drive 0x000f3ef0 to 0
drive 0x000f3ef0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
s=976773168
finalize PMM
malloc finalize
Space available for UMB: c1000-ee800, f0000-f3ef0
Returned 258048 bytes of ZoneHigh
e820 map has 8 items:
0: 0000000000000000 - 000000000009f800 = 1 RAM
1: 000000000009f800 - 00000000000a0000 = 2 RESERVED
2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
3: 0000000000100000 - 000000007fd89000 = 1 RAM
4: 000000007fd89000 - 000000007fe00000 = 2 RESERVED
5: 00000000e0000000 - 00000000f0000000 = 2 RESERVED
6: 00000000fee00000 - 00000000fee01000 = 2 RESERVED
7: 0000000100000000 - 0000000180000000 = 1 RAM
Jump to int19
enter handle_19:
NULL
Booting from CBFS...
Run img/Memtest86+
Segment 464c457f 16777216@0xffe23268 -> 256@0x02000300
No support for compression type 10101
enter handle_18:
NULL
Booting from 0000:7c00
GRUB Loading stage2. Output on the SERIAL line..
enter handle_12:
a=00000000 b=00000000 c=00000000 d=00000080 ds=0000 es=0000 ss=0000
si=0000811e di=00028da8 bp=00001ff0 sp=00001ff4 cs=0000 ip=8a82 f=0297
no switch back.
GRUB version 0.5.96 (638K lower / 2093604K upper memory)
+-------------------------------------------------------------------------+
| Boot GNU/Linux
[ll-ttyS1-115K2] |
| Boot GNU/Linux
[xx-ttyS1-115K2] |
| Boot GNU/Linux
[xx-ttyS1-115K2] |
| Boot GNU/Linux
[default] |
| Install GRUB into the hard
disk |
| |
| |
| |
| |
| |
| |
| |
+-------------------------------------------------------------------------+
Use the ^ and v keys to select which entry is highlighted.
Press enter to boot the selected OS, 'e' to edit the
commands before booting, or 'c' for a command-line.
After pressing 'ESC' and select '2', I'm not able to boot memtest86+,
and fall back to the hard drive.
Has anyone already faced this behavior.
Thanks in advance.
Best regards,
Patrick Agrain
Greetings,
I am new to this list.
I am trying to learn how to compile coreboot. My host has these:
---cpu: AMD64 3 cores
---OS: linux (BLFS) linux-3.10.32, ( pure 64-bit ), gcc-4.8.1. IASL (
downloaded as tbb41_201305160ss )
A ) I fetched coreboot fron the git repository
B ) I unpacked the downloaded in /usr/src
C ) I ran 'make menuconfig' and selected 'build with any toolchain'
D ) I then ran 'make' which ended as follows:-
######################
mv build/coreboot.pre1.tmp build/coreboot.pre1
LINK cbfs/fallback/romstage_null.debug
ld.bfd -b elf32-i386 -melf_i386 --gc-sections -nostdlib -nostartfiles -static
-o build/cbfs/fallback/romstage_null.debug -Lbuild --wrap __divdi3 --wrap
__udivdi3 --wrap __moddi3 --wrap __umoddi3 --start-group
build/generated/crt0.romstage.o build/mainboard/emulation/qemu-
i440fx/static.romstage.o build/arch/x86/boot/boot.romstage.o
build/arch/x86/boot/cbmem.romstage.o
build/arch/x86/lib/cbfs_and_run.romstage.o
build/arch/x86/lib/memcpy.romstage.o build/arch/x86/lib/memmove.romstage.o
build/arch/x86/lib/memset.romstage.o build/arch/x86/lib/rom_media.romstage.o
build/console/console.romstage.o build/console/die.romstage.o
build/console/init.romstage.o build/console/post.romstage.o
build/console/printk.romstage.o build/console/vtxprintf.romstage.o
build/cpu/x86/car.romstage.o build/cpu/x86/lapic/boot_cpu.romstage.o
build/device/device_romstage.romstage.o build/device/pci_early.romstage.o
build/drivers/emulation/qemu/qemu_debugcon.romstage.o
build/drivers/pc80/mc146818rtc.romstage.o
build/drivers/pc80/mc146818rtc_early.romstage.o
build/drivers/uart/uart8250io.romstage.o build/drivers/uart/util.romstage.o
build/lib/bootmode.romstage.o build/lib/cbfs.romstage.o
build/lib/cbfs_core.romstage.o build/lib/cbmem_common.romstage.o
build/lib/cbmem_console.romstage.o build/lib/clog2.romstage.o
build/lib/compute_ip_checksum.romstage.o build/lib/dynamic_cbmem.romstage.o
build/lib/gcc.romstage.o build/lib/halt.romstage.o
build/lib/hexdump.romstage.o build/lib/loaders/cbfs_ramstage_loader.romstage.o
build/lib/loaders/load_and_run_ramstage.romstage.o build/lib/lzma.romstage.o
build/lib/lzmadecode.romstage.o build/lib/memchr.romstage.o
build/lib/memcmp.romstage.o build/lib/prog_ops.romstage.o
build/lib/ramtest.romstage.o build/lib/version.romstage.o
build/southbridge/intel/i82371eb/early_pm.romstage.o
build/southbridge/intel/i82371eb/early_smbus.romstage.o /usr/lib/gcc/x86_64-
unknown-linux-gnu/4.8.1/libgcc.a --end-group -T
build/generated/romstage_null.ld
build/lib/gcc.romstage.o: In function `__wrap___udivdi3':
/usr/src/coreboot_GIT170415/src/lib/gcc.c:37: undefined reference to
`__udivdi3'
build/lib/gcc.romstage.o: In function `__wrap___umoddi3':
/usr/src/coreboot_GIT170415/src/lib/gcc.c:39: undefined reference to
`__umoddi3'
make: *** [build/cbfs/fallback/romstage_null.debug] Error 1
rm build/cbfs/fallback/bootblock.elf
#########
I am running on a pure 64-bit host but it seems coreboot is attempting to
link 32-bit binaries. Help to successfuly build coreboot will be
appreciated.
Yours sincerely
Sibu
The ASUS KFSN4-DRE fails verification as of commit 595e7777e7282249b13c3d7f8a45178e76798690
The following tests failed:
BOOT_FAILURE
Commits since last successful test:
595e777 Kconfig whitespace fixes
See attached boot log for details
This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand
Raptor Engineering offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information
Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification
hi,
i am trying to build coreboot according to
https://github.com/bibanon/Coreboot-ThinkPads/wiki/T60p-Build-Coreboot#buil…
make crossgcc worked fine.
after running "make" im getting the following error and the building
process is stopped:
---------
/coreboot/util/cbfstool/cbfs_image.c:451:59: error: comparison between
signed and unsigned integer expressions [-Werror=sign-compare]
assert((char*)CBFS_SUBHEADER(entry) - image->buffer.data ==
^
cc1: all warnings being treated as errors
make: *** [build/util/cbfstool/cbfs_image.o] Fehler 1
---------
any ideas what is causing this error and how to fix it?
thanks in advance
chp
That’s truly amazing! So the FSP + coreboot part only takes a quarter of a second? Intel FSP must be on steroids!!
The total boot time is the sum of components time, so if you fix that problem you will have close to a quarter of second boot time!! Can we see a video clip of that boot?
> 27 apr 2015 kl. 22:42 skrev Duncan Laurie <dlaurie(a)chromium.org>:
>
> On Mon, Apr 27, 2015 at 12:29 PM, Matt DeVillier <matt.devillier(a)gmail.com <mailto:matt.devillier@gmail.com>> wrote:
> On 4/26/2015 3:03 AM, Paul Menzel wrote:
>> Dear coreboot folks,
>>
>>
>> looking at the time stamps of the Intel Haswell device Google Panther,
>> which Matt DeVillier thankfully uploaded to the board status repository
>> [1], it looks odd that it took around a quarter of a second, from after
>> the SeaBIOS payload was decompressed to starting the payload. This is
>> almost half of the whole boot time.
>>
>> […]
>> 90:load payload 233,302 (216)
>> 15:starting LZMA decompress (ignore for x86) 233,415 (113)
>> 16:finished LZMA decompress (ignore for x86) 250,327 (16,912)
>> 99:selfboot jump 493,712 (243,384)
>>
>> Thanks to Aaron Durbin’s analysis of the code path, the finalize in line
>> 138 of `src/southbridge/intel/lynxpoint/smi.c` calls
>> `intel_me_mbp_clear()` in line 589 of
>> `src/southbridge/intel/lynxpoint/me_9.x.c`.
>>
>> $ more src/southbridge/intel/lynxpoint/me_9.x.c # line 589
>> […]
>> #if CONFIG_ME_MBP_CLEAR_LATE
>> /* Wait for ME MBP Cleared indicator */
>> intel_me_mbp_clear(PCH_ME_DEV);
>> #endif
>> […]
>>
>> The issue is even described in the Kconfig option description of
>> `ME_MBP_CLEAR_LATE` and the commit message of commit 3d299c4b (lynxpoint
>> me: add support for mbp clear wait in finalize step) [2] adding this
>> option.
>>
>> $ more src/southbridge/intel/lynxpoint/Kconfig
>> […]
>> config ME_MBP_CLEAR_LATE
>> bool "Defer wait for ME MBP Cleared"
>> default y
>> help
>> If you set this option to y, the Management Engine driver
>> will defer waiting for the MBP Cleared indicator until the
>> finalize step. This can speed up boot time if the ME takes
>> a long time to indicate this status.
>> […]
>>
>> I guess there is no way to get fixed ME BLOBs from Intel. I heard the ME
>> BLOB has been fixed for newer Intel devices.
>
> The ME firmware that ships with Panther is 9.5.13.1706. I've also tested 9.5.41.1904 (what I'm using in the firmware referenced above) and 9.5.45.1922 (which I just came across today) - all display the same behavior in terms of time needed to report MBP cleared. The 9.6 series ME firmware is also for Haswell/Lynxpoint, but I'm unsure if it's compatible with systems shipped with ME 9.5. Since I have an external programmer, I suppose I could always give it a try :) The 10.0 series ME firmware is for Broadwell and is more likely to contain the fix, but less likely to be compatible with Haswell/LP.
>
> -Matt
>
>
>
>
> Unfortunately the wait for ME MBP to clear is even worse on Broadwell, but with ME10 there is a (gross) boot flow to avoid it thanks to some new commands that do not need acknowledgement:
>
> http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=c99681f4f23ddac… <http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=c99681f4f23ddac…>
>
> -duncan
>
>> Thanks,
>>
>> Paul
>>
>>
>> [1] http://review.coreboot.org/gitweb?p=board-status.git;a=commitdiff;h=3926f95… <http://review.coreboot.org/gitweb?p=board-status.git;a=commitdiff;h=3926f95…>
>> [2] http://review.coreboot.org/4375 <http://review.coreboot.org/4375>
>>
>>
>
>
> --
> coreboot mailing list: coreboot(a)coreboot.org <mailto:coreboot@coreboot.org>
> http://www.coreboot.org/mailman/listinfo/coreboot <http://www.coreboot.org/mailman/listinfo/coreboot>
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot