November 2016 - 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

ASUS KCMA-D8 workstation board port offer
by Timothy Pearson Jan. 20, 2017

Jan. 20, 2017

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, After reviewing some of the comments on the ASUS KGPE-D16 being essentially too large of a system and too expensive for many people, and the fact that modern, blob-free systems are not really available in the mid-range arena, Raptor Engineering would like to offer to create a native initalization blob-free port for the ASUS KCMA-D8, which is essentially the KGPE-D16's ATX-compatible "little brother". We would be asking $15,000 for the port, including upstreaming to the master coreboot tree. We already have extensive experience with these Family 10h/15h boards, and would be able to create a port of similar quality to the existing KGPE-D16 source in terms of both code quality and overall functionality. If this is something you might be interested in please let me know. We are able to accept multiple payments from various sources for the same project (within limits), so if this is something your local Linux groups or similar might be interested in we should be able to keep the cost on any one individual or organization to a reasonable level. Thank you for your consideration, - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) http://www.raptorengineeringinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJWQROpAAoJEK+E3vEXDOFbR2cH/3FTqGFH+cU/HVrBUPcoKjii h9OC7SGeXdyoLZvob/YayG+g47Yppkg2um4pAC7dmGl/OXtkGh13hlsrQ8BNiYcz g0kQUdNKYh9dmBC3YnlxU6a7psh473TdyuLILrl7/8WgI8DZnRtjy62Oo5k6XAKW jfYb/bGC8I3tArYrgQDmFxz2dOejuTZit56I+mbWNtvbuQov2BDmrPPMLRuEvG3M QHCAo/Pjaajzl4rmtrgu0GHcxHsgAnJcnrcPkFYeSDKt7QxSTNOB6NqhcnYdh1SY RiA5Z/3enuDs+XNhS+6qMeKOcrEuf+Ccs7sGsgq5tWm20JA+bBoByvrXhHqVUxU= =DKfR -----END PGP SIGNATURE-----

7 16

Re: [coreboot] F2A-85M: Different VGA BIOS needed after CPU Upgrade?
by Daniel Kulesz Jan. 8, 2017

Jan. 8, 2017

Hi John, > It sounds to me as though the PCI id's of the graphics card for the > upgraded CPU may be different (I could be totally wrong about that, so I > defer to others on the list if I'm barking up the wrong tree) and your > coreboot image may need to be updated accordingly. Of course, it could > also be the video BIOS that's the problem as you've suggested. Thank you for the hint. I inspected that, but the PCI-IDs actually look the same: 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7480D] [1002:9993] (A4-5300) and 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Richland [Radeon HD 8670D] (prog-if 00 [VGA controller]) (A10-6700) Looks like the VGA BIOS is really different: # diff vgabios_a4-5300.bin vgabios_a10_6700.bin Binary files vgabios_a4-5300.bin and vgabios_a10_6700.bin differ Guess I will have to to "update" the VGA BIOS then. Cheers, Daniel > > Hi Daniel, > > > Kind Regards, > > John. > > > On 28/06/16 09:24, Daniel Kulesz via coreboot wrote: > > Hi folks, > > > > I upgraded the CPU in my F2A-85M from a A4-5300 (Trinity) to a A10-6700 (Richland). The board had Coreboot installed before with the VGA BIOS extracted from the A4-5300. However, I did not get any video output when trying to boot after the upgrade, so I replaced the flash chip with a backup with the vendor BIOS that works. > > > > Is it likely that the A10-6700 needs a different VGA BIOS or does this this rather look like a different issue? I don't want to experiment too much because the BIOS chips are hardware-wise pretty fragile (even when using the extractor tool). > > > > Cheers, Daniel > >

1 1

Linux 4.7 kernel payload with CoreBoot 4.4
by Trammell Hudson Dec. 12, 2016

Dec. 12, 2016

The Linux 4.7 kernel payload crashes early in the boot process with CoreBoot 4.4. I traced it to these instructions that are finding a safe spot to decompress the rest of the kernel and patched around it with a hard coded location: diff -u --recursive /home/hudson/build/clean/linux-4.7/arch/x86/boot/compressed/head_64.S ./linux-4.7/arch/x86/boot/compressed/head_64.S --- /home/hudson/build/clean/linux-4.7/arch/x86/boot/compressed/head_64.S 2016-07-24 15:23:50.000000000 -0400 +++ ./linux-4.7/arch/x86/boot/compressed/head_64.S 2016-08-05 12:07:11.399854225 -0400 @@ -340,9 +357,15 @@ 1: /* Target address to relocate to for decompression */ +#if 0 movl BP_init_size(%rsi), %ebx subl $_end, %ebx addq %rbp, %rbx +#else + // coreboot does not populate the init_size boot param? + // fake it with a hard coded value + movl $0x97b000, %ebx +#endif /* Set up the stack */ leaq boot_stack_end(%rbx), %rsp It seems that the Linux kernel bzImage is supposed to set this value, rather than coreboot, so my comment is likely incorrect. Dumping linux-4.7/arch/x86/boot/header.o, it looks like init_siez is supposed to be 0xcf5000, so I wonder if %rsi is pointing to the wrong location. In 4.6.4 the computed address was hardcoded: movl $LOAD_PHYSICAL_ADDR, %ebx /* Target address to relocate to for decompression */ addl $z_extract_offset, %ebx 3e: bb 00 00 00 01 mov $0x1000000,%ebx 43: 81 c3 00 00 00 00 add $0x0,%ebx -- Trammell

4 4

FOSDEM 2017
by Carl-Daniel Hailfinger Dec. 10, 2016

Dec. 10, 2016

Hi, FOSDEM 2017 deadlines are soon. Do we want to have a full developer room, a talk or just a stand? Unfortunately I won't be able to attend, so someone else will have to be the formal contact for organizing our stand/devroom/talk. I will help with submitting proposals if this is desired by the person organizing our stand/devroom/... Who is willing to take care of our FOSDEM 2017 presence? https://fosdem.org/2017/news/2016-07-20-call-for-participation/ Deadlines: Developer Rooms: 9 September Main Track Talks: 10 October Stands: 31 October Lightning talks: 25 November Regards, Carl-Daniel

2 1

xHCI support for x86
by Pitrolle Jean-Jacques Dec. 2, 2016

Dec. 2, 2016

Hello *, I try to integrate coreboot *libpayload usb stack* in a custom binary for x86. I already succeed integration of *ehci* for *qemu* and *core 2 duo* platforms. But things seems to be not so easy for *xhci*. When I try to run coreboot master branch (with hash 8bf3f7a) on qemu (version 2.7.0) with following line : % qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -drive if=none,id=usbstick,file=/tmp/qemu_usb.disk -usb -device nec-usb-xhci,id=xhci -device usb-storage,bus=xhci.0,drive=usbstick I get these output lines concerning xHCI controller (nec-usb-xhci) : 8<--- [..] 00:04.0 0194:1033.0 xHCI controller xhci_init: regbase: 0xfe070000 xhci_init: caplen: 0x40 xhci_init: rtsoff: 0x1000 xhci_init: dboff: 0x2000 xhci_init: hciversion: 0.0 xhci_init: Unsupported xHCI version [..] --->8 The same result is reached with qemu-system-i386... Is it the expected result on qemu? I don't have any motherboard supported by coreboot, so I try a custom binary on a *Xeon* processor (processor D-1500). The xHCI version is supported (hciversion: 1.0) but things turn bad when starting xHCI controller i.e xhci->opreg->usbcmd |= USBCMD_RS in *xhci_start* : the program hangs... The registers usbcmd and usbsts before this command seems to have proper values (a usb key is connected.) 8<--- [..] xhci_start - usbcmd:0 - usbsts:11 [..] --->8 This seems to be related to interrupter configuration. When I comment out the two lines in *xhci_reinit* 8<--- [..] xhci->hcrreg->intrrs[0].erstba_lo = virt_to_phys(xhci->ev_ring_table); xhci->hcrreg->intrrs[0].erstba_hi = 0; [..] --->8 xhci_start works as expected i.e not hangs. But the sequence following with *NOOP* to test command ring and event ring mechanism fails. 8<--- [..] NOOP run #0 Transfer TRB (@0x8051700): PTR_L 0x00000000 PTR_H 0x00000000 STATUS 0x00000000 CNTRL 0x00005c00 TL 0x0000 TDS 0x0000 C 0x0000 ISP 0x0000 CH 0x0000 IOC 0x0000 IDT 0x0000 TT 0x0017 DIR 0x0000 Command 23 (@0x8051700) Warning: Timed out waiting for TRB_EV_CMD_CMPL. Command ring is running [..] --->8 As I understand it is mandatory to have the first interrupter configure to manage at least one event ring (4.9.4 Event Ring Management - eXtensible Host Controller Interface Revision 1.1). Does someone succeed with xHCI support for x86 board? Did I miss something concerning xHCI configuration? Thanks. Have a nice day. -- Jean-Jacques PITROLLE Phone: +33 1 30 09 12 70 SYSGO S.A.S

3 3

your preferred method for supplying power to chip for RPi spi flashing?
by Michael Carbone Dec. 1, 2016

Dec. 1, 2016

Hi coreboot list, I have been attempting to use a raspberry pi for spi flashing and when I use the 3.3v pin the raspberry pi doesn't power up as the chip draws too much power through the 3.3v pin for the raspberry pi to also run. I am powering the RPi through micro-USB, either connected to wall outlet or another computer. What is your recommended method for powering the chip and RPi? Looking online [1] some folks recommend using laptop AC adapter + wake-on-lan (and not using the VCC/3.3v pin), but I'm not sure that's a dependable strategy because I don't know if coreboot has WoL functionality for the x230 should I want to reflash the chip [2]. Advice/thoughts appreciated, and let me know if there's a better place to ask this question. FYI this is the chip I am trying to program: [3] Thanks, Michael [1] https://www.bios-mods.com/forum/Thread-REQUEST-Lenovo-Thinkpad-X230-Whiteli… [2] https://www.coreboot.org/Board:lenovo/x230 [3] http://www.zlgmcu.com/mxic/pdf/NOR_Flash_c/MX25L3206E_DS_EN.pdf -- Michael Carbone Qubes OS | https://www.qubes-os.org @QubesOS <https://www.twitter.com/QubesOS> PGP fingerprint: D3D8 BEBF ECE8 91AC 46A7 30DE 63FC 4D26 84A7 33B4

4 3

Re: [coreboot] [RFC] Explicitly use C11/GNU11
by Paul Menzel Nov. 30, 2016

Nov. 30, 2016

Dear Julius, Am Dienstag, den 29.11.2016, 14:20 -0800 schrieb Julius Werner: > > A lot of the GNU extensions are used in our codebase, so if somebody > > feels strongly about moving away from GNU11 to C11, the code needs to > > be cleaned up. But that should be done in a different patch set. > > I'd like to explicitly object to that. There are many GNU extensions > which are simply necessary to write sane, readable and performant code > (e.g. to implement non-double-evaluating MIN()/MAX() macros, to > cleanly control linking into particular sections, to get performant > code generated for IO accessor functions, etc.). The C standard by > itself is simply insufficient to support all systems programming use > cases, and if we forbade GNU extensions we'd have to rewrite > significant parts of coreboot in pure assembly and add weird, hardly > readable workarounds for many code patterns. I don't see how this > would be worth it just to try to get compatibility with compilers > nobody wants to use anyway, or for some theoretical goal of "standards > compliance" with no practical benefit. (Note that many GNU extensions > are implicitly available even without -std=gnuXX, some of them even if > you also enable -Werror=pedantic. But that doesn't not make them GNU > extensions, and there'd be no reason to treat them differently from > ones that require the -std flag. Ditching GNU extensions would mean > that every __attribute__, every __builtin and every extended asm > becomes illegal.) Thank you for the elaborate explanation. I never intended to take on that task, but if I had, you would have convinced me. I hope using GNU11 suits everyone. Thanks, Paul

2 1

Re: [coreboot] Rettungsboot
by ron minnich Nov. 30, 2016

Nov. 30, 2016

OK, then someone just asked me: how long does it take to rewrite that 128 MiB vs. the 512 byte sector on the floppy. :-) On Wed, Nov 30, 2016 at 1:18 PM ron minnich <rminnich(a)gmail.com> wrote: > amusement value: > > The 512 bytes used for MBR is about .04% of the 8" floppy disk that > shipped with the original IBM PC. For 128 MB to be that fraction of a new > disk, the disk would have to be 256 GiB. That's about $40 worth of disk. > > Geez. > > > On Wed, Nov 30, 2016 at 11:00 AM Zoran Stojsavljevic < > zoran.stojsavljevic(a)gmail.com> wrote: > >> > Or do you want to do the full EFI "let's waste 128MB of *every** disk* >> on >> > a special FAT32 partition" madness (which still requires bootloaders to >> > include one specific FS driver they might otherwise not want)? >> >> YES, you do. Accent on: "every disk" . >> >> Zoran >> On Tue, Nov 29, 2016 at 10:53 PM, Julius Werner <jwerner(a)chromium.org> >> wrote: >> >> > To sum it up, I want something that is lean and clean enough so it could >> be added to any bootloader. Even if that boot loader is not of the >> let's build a tiny OS type. >> >> I don't really see how you could reach this goal with anything that >> requires reading a file from the boot media? There are billions of >> different file systems out there... do you want to require your >> "minimal" bootloader to include drivers for all of them? (There are >> bootloaders that don't contain any file system drivers at all, like >> depthcharge.) Or do you want to do the full EFI "let's waste 128MB of >> every disk on a special FAT32 partition" madness (which still requires >> bootloaders to include one specific FS driver they might otherwise not >> want)? >> >> I think if you want to do anything truly minimal and compatible with >> everything, you can't rely on files (and you should try to rely on >> partitions as little as possible, e.g. no full GPT parsing). Which >> probably means putting it in the first sector. And once you have that, >> you can create some fancy text-based format (or Go source file / >> node.js script / whatever the cool kids use these days) to describe >> the target sector, load address etc. of the fallback kernel... but >> you're really just exemplifying the XKCD Igor mentioned because you've >> just reinvented the MBR. (And let's face it... no coreboot bootloader >> has the pull to sufficiently promote adoption of some completely new >> fallback boot descriptor format right now, even if it doesn't require >> a Go compiler in your bootloader.) >> >> So, really, I think what you want is just the MBR. It is the deadest >> simple design possible (just load a sector and jump), it is as >> infinitely flexible as code itself, and it coexists perfectly with all >> partitioning schemes relevant today (MBR and GPT). Yes, it requires a >> software interrupt BIOS interface, but if the recovery kernel code is >> cleverly written you really only need the disk access part (and you >> know your bootloader already has that driver because that's how it >> loaded the MBR in the first place). And yes, on x86 it requires real >> mode (for non-x86 I'd just make up an as equivalent as possible system >> with your software interrupt solution of choice), but that's a small >> price you pay with a few files worth of shim code in exchange for >> automatic compatibility with 35 years worth of existing BIOSes. I'd >> say that's a better deal than any new dead-on-arrival scheme you could >> make up out of thin air. >> >> (If you really can't stand the idea of BIOS interrupts and real mode, >> I think your next best option would be to try to cram an >> as-small-as-possible binary recovery descriptor and the real mode code >> to parse/load/execute it together into the 446 bytes of MBR space you >> have. This way, your new payloads can just find and parse/load/execute >> the descriptor itself without having to provide any BIOS interface, >> but the thing is still compatible with existing legacy BIOSes as >> well.) >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> >>

1 0