July 2015 - coreboot - mail.coreboot.org

Lenovo T410 Coreboot
by A. Veek Dec. 14, 2018

Dec. 14, 2018

2 1

Re: [coreboot] No VGA output on e350m1 after flashing. what to do?
by Reiner Luett Sept. 12, 2017

Sept. 12, 2017

Hi! On 30.06.2013 19:28, Christian Weinz wrote: > Maybe I didn't include the VGA option in the make menuconfig process. > How can I solve this problem? You need to add the VGA Option ROM (VGA BIOS -> Add VGA BIOS image). I've extracted it from the UEFI, but you also could use these: http://www.coreboot.org/index.php?title=ASRock_E350M1&oldid=11114 at the end of the page or you also may be able to use the default AMD fam14 (Persimmon) vbios. You will need to agree to the click through: http://wwwd.amd.com/support/vbioslic.nsf/userverify?openform http://www.coreboot.org/AMD_DB-FT1_PERSIMMON It's a pity, that bios_extract didn't work for now. You could use the AMI Aptio EFI MMTool with wine: http://win-lite.de/benutzer/fernando/BIOS-Tools/AMI_Aptio_EFI_MMTool_v4.50.… You need to extract OntarioEFIVbios with PCI ID 1002,9802 as Option ROM. Regards, Reiner --

5 6

Re: [coreboot] On Intel Boot Guard
by Alexander Couzens April 15, 2016

April 15, 2016

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

2 2

coreboot ported to the ASUS KGPE-D16 (Libreboot: blobless, fully functional!)
by Timothy Pearson Oct. 17, 2015

Oct. 17, 2015

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

6 10

[Mohon Peak] Memtest86+
by Patrick Agrain Aug. 18, 2015

Aug. 18, 2015

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

1 1

Re: [coreboot] Finding whether the BIOS is coreboot or not
by Stefan Reinauer Aug. 1, 2015

Aug. 1, 2015

* ron minnich <rminnich(a)gmail.com> [150718 18:10]: > Could you also look for LBIO in the e and f segments? Since we moved the coreboot tables out of e and f you won't find anything like that anymore. 1. Use cbmem tool 2. Dump coreboot table with nvramtool 3. dmidecode 4. ACPI table vendor 5. flashrom -r and check the image for CBFS, ID and master header Stefan > On Sat, Jul 18, 2015 at 12:34 AM Patrick Georgi <pgeorgi(a)google.com> wrote: > > 2015-07-18 9:03 GMT+02:00 Kevin Wilson <wkevils(a)gmail.com>: > > Is there a way, from a device running Linux, to which I have access > > to the command line, to know > > whether the BIOS is coreboot or not ? by some utility, or by some sysfs > entry ? > We usually have coreboot related vendor names for ACPI tables (eg. > dsdt table id 'COREBOOT'). Those are visible early on in dmesg, I > think. > Also our cbmem utility (coreboot source tree, util/cbmem) can print a > coreboot specific table's content. > > Neither of these are guaranteed to be around (it would be possible to > cloak things thoroughly), but it's likely that they are on coreboot, > and pretty much non-existent otherwise. > > > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Graham Law, Christine Elizabeth Flores > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] cbfs alignment
by ron minnich Aug. 1, 2015

Aug. 1, 2015

yes, they all *seem* like the ought to end up aligned, but they don't :-( RISCV changed; they can do unaligned loads now. On Fri, Jul 31, 2015 at 3:26 PM Julius Werner <jwerner(a)chromium.org> wrote: > -mno-unaligned-access is ARM32 only, unfortunately. You'd have to > convince GCC developers to generalize it. > > > This statement is true for coreboot tables. CBFS files are aligned to 64 > bytes by default. > > The problem is that the CBFS stage and payload headers themselves > contain inherently misaligned 64-bit values. I guess if the compiler > was really smart it could stack-allocate a struct { u32 a; u64 b; } > __attribute__((packed)) structure at an odd 4-byte boundary, but it > doesn't currently seem to do that (and neither does cbfstool for the > in-ROM structs). > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] No code in SMM handler address (0xa0000)
by Stefan Reinauer Aug. 1, 2015

Aug. 1, 2015

* Yu-Cheng Liu <peter90609(a)gmail.com> [150724 09:13]: > hello, > Here I have some questions in smi.c file (coreboot/src/southbridge/intel/ > i82801ix/smi.c) > > in smm_install function, one statement is to copy handler to SMRAM(0xa0000): > 1.I can't find copy source data ( _binary_smm_start ),where is it write? I > watch (_binary_smm_start) memory address,and it has value in it. The SMM handler is created as a separate binary that is then copied to 0xa0000. This binary is produced by src/cpu/x86/smm/Makefile.inc > > 2.After execute the memcpy statement,there is nothing change in 0xa0000,the > value in 65535 What do you mean by that? After memcpy is done, the SMM region is locked again, so you will see VGA memory shadowed over it, as long as you are not actually in SMM. > In smm_relocate function, the pointer goes in the " if " statement and then > "return" , the relocation code did not copy to 0x38000: > 3.How do I let the program go through and do the job below the " if " > statement? >From when I was playing around with Qemu last, its SMM implementation is not 100% correct. You should probably look at some actual hardware here. Stefan

1 0

Re: [coreboot] cbfs alignment
by Stefan Reinauer Aug. 1, 2015

Aug. 1, 2015

* ron minnich <rminnich(a)gmail.com> [150717 21:45]: > riscv is taking alignment traps reading cbfs. > > The issue is that 64-bit fields are 32-bit aligned, which fails many places. > > Thaminda found this comment: > > * Since coreboot is usually compiled 32bit, gcc will align 64bit > types to 32bit boundaries. If the coreboot table is dumped on a > 64bit system, a uint64_t would be aligned to 64bit boundaries, > breaking the table format. This statement is true for coreboot tables. CBFS files are aligned to 64 bytes by default. You can see if your compiler supports -mno-unaligned-access which will get rid of the problem for you. > We can fix it, with an ugly macro, but ... what's the right move here? 1. The cleanest solution would be to have our read32/write32 functions exist in aligned and unaligned versions and using the latter for accesses to packed data structures. Also the most intrusive, in the code base 2. Enable -mno-unaligned-access. 3. Enable some mechanism in the CPU that will take care of unaligned accesses. That's what we do on ARM 4. Write an exception handler that takes care of the problem for you. Stefan

2 1

Re: [coreboot] How to trigger SMI and implement SMM
by Stefan Reinauer Aug. 1, 2015

Aug. 1, 2015

* Yu-Cheng Liu <peter90609(a)gmail.com> [150721 11:04]: > Hello, > > I purpose to trigger SMI event and do something in SMM mode . > > > > I trace the coreboot source code and found that, during the coreboot > environment setup, the file locate at southbridge/intel/i82801ix/smi.c will be > excute. Is it enough for SMI/SMM operation? That is just the code that installs the SMM handler (well, part of it) > I didn’t see the code under cpu/smm be locate in the ramstage.debug symbol. The SMM handler is a separate module. > What is the different purpose between southbridge/intel/i82801ix/smi.c and /cpu > /x86/smm? The code in southbridge/intel/i82801ix/smi.c is the chipset specific SMI initialization. southbridge/intel/i82801ix/smihandler.c is the chipset specific SMI handler. The code under cpu/x86/smm is generic for the x86 architecture. > How do I trigger the SMI event? Typically hardware triggers an SMI, e.g. on a GPE event, timeout, or such. See southbridge/intel/i82801ix/smihandler.c for a more comprehensive list of southbridge SMI sources. You can also use the APMC SMI command mechanism to manually trigger SMIs, see southbridge_smi_apmc(void) for details. Stefan

1 0