coreboot September 2015

coreboot@coreboot.org

36 participants
50 discussions

by A. Veek

1 year, 9 months

Re: [coreboot] No VGA output on e350m1 after flashing. what to do?

by Reiner Luett

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

3 years

Re: [coreboot] On Intel Boot Guard

by Alexander Couzens

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

4 years, 5 months

Porting Libreboot to the C201 Chromebook (veyron_speedy)

by Paul Kocialkowski

Over the past week or so, I've been working to get Libreboot running on the latest ARM Chromebook: the C201, manufactured by Asus (codename veyron_speedy). The laptop is running with a RK3288 SoC and ships with Google's version of Coreboot preinstalled. It should require no proprietary code nor any proprietary firmware load or microcode update to boot, thus it would be a good fit for Libreboot, as a fully free distribution of Coreboot. In addition to that, the device's embedded controller (that handles aspects of power management as well as the keyboard and a few other things) is a microcontroller that is also running free software: the free embedded controller firmware from Google. Aside from that, it has a soldered Wi-Fi/bluetooth BCM4354 chip (cannot be removed) that has a free driver but requires to load a proprietary firmware on the chip. However, it is easy to work around that issue and not use that chip at all, e.g. using an ath9k_htc dongle on one of the two USB ports. The GPU is a Mali T764, on which Luc has been doing some early work to have free software support for it. It is uncertain[0] how long it will take to have an usable free replacement for it, but now that there is that hardware available, free graphics for Mali T GPUs would mean having a recent laptop running fully free software, down to the firmware level, without losing any major hardware feature, something that has hardly ever been achieved yet. Thus, I believe it is of the utmost importance to back Luc up on this, even if big players like ARM are trying hard to make Lima not happen and to make it difficult for Luc to keep going. Another aspect that I still have to look at in-depth is the ability to use hardware video encoding/decoding. The RK3288 has an auxiliary processor for that task, but it is unclear whether it can be used with free software or not, though the first indications that I've gathered are positive. At this point, I've been able to boot up Debian on the device, and the xfce4 interface is quite usable. It even runs big programs like Iceweasel/Firefox and LibreOffice without inconveniences. However, it cannot run desktop environments that depend on GL acceleration, such as gnome-shell, which is a shame since those would be a good fit for it. The CPU is simply too slow for offering a decent experience with software rendering (llvmpipe). Overall, I truly hope this device creates an incentive to free the last remaining parts that can only work with proprietary software to this day. Its potential would be huge, especially since it's a good fit for travellers. With the security model inherited from Chromium OS, this would be one of the safest laptops to be used by journalists or activists. If Tails was to be ported to it, it would become easy to have a secure and anonymous setup. I have successfully fixed and compiled Coreboot and all the necessary bits and pieces for the C201, so I'll be spending the next few days sending patches, discussing how to integrate it to Libreboot and getting the actual work done. I also plan on documenting all my findings (especially things like how to access UART, how to remove the SPI flash's write protect, how to reflash it externally, etc) on my coding blog, for now. Cheers! References: [0]: http://libv.livejournal.com/27461.html -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/

4 years, 9 months

coreboot ported to the ASUS KGPE-D16 (Libreboot: blobless, fully functional!)

by Timothy Pearson

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

4 years, 11 months

Goodies for Bonn meeting

by Vladimir 'φ-coder/phcoder' Serbinenko

Hello, all. My girlfriend Maria (CC'ed) would like to organize some goodies for coreboot meeting. Already available are black T-shirts: 2 x M, 8 x L, 1 x XL according to my notes, it's no guarantee, I can't double-check now as I'm travelling. Expected price is under €20 for any of items. Capacity is limited, first come first serve, respond to this e-mail to order. What else we can do: - White t-shirt - white cups - colour cups - Fridge magnets - case for iPhone (indicate which one), not sure which ones are available - Beer coaster - mouse pad - baseball cap In addition, if you're ok with waiting about a month + delivery time we can order: - Black t-shirt (other than the sizes mentioned above, or once the stock is out) - Colour t-shirt over €20 We're doing it just for fun and to serve the community, the price is only to cover our costs.

4 years, 11 months

coreboot conference 2015 invitation

by coreboot conference

Dear vendors, developers and interested parties, on behalf of the Federal Office for Information Security (BSI) Germany I would like to invite you to the coreboot conference and developer meeting on October 9-11 2015 in Bonn, Germany. This conference and developer meeting is geared towards manufacturers of hardware (processors, chipsets, mainboards and servers/ laptops/ tablets/ desktops/ appliances) as well as developers of firmware with an interest in coreboot and the possibilities it offers. The Federal Office for Information Security (BSI) in Germany will host the conference in Bonn, Germany. As the national cyber security authority, the goal of the BSI is to promote IT security in Germany. For this reason, the BSI has funded coreboot development in the past for security reasons. The date of the coreboot conference is Friday October 9 to Sunday October 11, 2015. This is scheduled directly after Embedded Linux Conference Europe to make travel arrangements easier for people attending both events. If your main interest is forging business relationships and/or strategic coordination and you want to skip the technical workshops, Friday (and possibly Saturday) will be the outreach day of talks, presentations and discussions. If your main interest is doing development, you can use the separate developer room next to the during all three days of the conference. Call for presentations: We are looking for interesting talks/presentations about coreboot related topics for the first (and possibly second) day of the conference. Please note that those presentations are not intended to be advertisements or company portfolio presentations. Expected duration is between 10 and 45 minutes. Submission: Please send the title, a brief summary, the expected duration and name/organization of the speaker to <coreboot-conference(a)bsi.bund.de> until September 21. We will notify you of acceptance until September 28. If you want us to make sure the slides work fine with the projector at the venue, please submit your final slides in pdf form before Ocober 7. Call for discussion topics and development suggestions: We hope to stimulate discussion and foster new ideas as well as explore ways to improve code, development and deployment. The format for this will be a few minutes (1-5) of presenting your idea/topic followed by discussing it with the audience for approximately 5-20 minutes. While there is no formal deadline for submission, we'd appreciate a submission to <coreboot-conference(a)bsi.bund.de> before October 2 to be able to list the topic on the agenda to allow others to think about the topic in advance. Call for profiles: This is the chance to tell others what you're doing, what you can offer and in what area you'd like to collaborate. If desired, we can attempt to distribute your profile to other conference participants before the conference. Please submit such profiles before September 30 to <coreboot-conference(a)bsi.bund.de> . Call for developers: If you want to do development all day, every day, just come and do it. We have power, networking and some spare hardware (please tell us in advance if you need something on site, we might have it in our lab). Travel information: If you wonder about how to reach Bonn, there are three options available by plane: The closest is Cologne Airport (CGN), 30 minutes by bus to Bonn main station. Next is Dusseldorf Airport (DUS), 1 hour by train to Bonn main station. The airport with most international destinations is Frankfurt Airport (FRA), 1 hour by train to Bonn main station. There’s the option to travel by train as well. Bonn is reachable by high-speed train (ICE), and other high-speed train stations are reasonably close (30 minutes). Conference location: Wissenschaftszentrum Bonn Ahrstrasse 45 53175 Bonn GERMANY Getting there (German only) http://www.stifterverband.info/veranstaltungen/wissenschaftszentrum_bonn/an… An English version of the directions will be available at http://coreboot.org/coreboot_conference_Bonn_2015 Accommodation: Accommodation is not centrally organized, but if desired we can point you to websites listing hotel contact information and/or booking services as well as the local tourist information office. We also have a small allotment of rooms close to the venue reserved for conference participants, just ask us. Spare time activities: If there is enough interest, it might be possible to get a tour of the former top secret bunker of the German Federal Government on Saturday evening. More info at http://regbu.de/Fremdsprachen/GB1.html Besides that, Bonn and Cologne have lots of tourist attractions Food and drinks: More info will be posted to http://coreboot.org/coreboot_conference_Bonn_2015 shortly. Date and time: October 9-11 2015 Friday: 9:00-19:00 Saturday: 9:00-16:00 Sunday: 9:00-19:00 To enable us to estimate the number of attendees (for catering etc.), please notify us ASAP whether you will attend the conference at <coreboot-conference(a)bsi.bund.de>. Thank you! All information is also available at http://coreboot.org/coreboot_conference_Bonn_2015 Sincerely, Carl-Daniel Hailfinger -- Hailfinger, Carl-Daniel _________________________________________ Section C 13 - Operating System and Application Security Federal Office for Information Security (BSI) Godesberger Allee 185-189 53175 Bonn, Germany phone: +49 (0)228 9582-5939 fax: +49 (0)228 9582-5400 e-mail: coreboot-conference(a)bsi.bund.de web: www.bsi.bund.de

4 years, 12 months

Re: [coreboot] cbmem fails with `Failed to mmap /dev/mem: Resource temporarily unavailable`

by Paul Menzel

Dear Aaron, thank you for the quick reply. Am Montag, den 28.09.2015, 09:38 -0500 schrieb Aaron Durbin: > On Sun, Sep 27, 2015 at 2:54 PM, Paul Menzel wrote: > > building a coreboot image for the ASRock E350M1 with the attached > > config, having code coverage enabled, I am unable to run the > > utility `cbmem`. > > > > ``` > > $ sudo util/cbmem/cbmem -V -l > > Looking for coreboot table at 0 1048576 bytes. > > Mapping 1MB of physical memory at 0x0 (requested 0x0). > > Found! > > coreboot table entry 0x11 > > Found forwarding entry. > > Unmapping 1MB of virtual memory at 0xb74b6000. > > Looking for coreboot table at c7f9f000 1048576 bytes. > > Mapping 1MB of physical memory at 0xffffffffc7f9f000 (requested 0xc7f9f000). > > ... failed. Mapping 1052671B of physical memory at 0xffffffffc7f9e000. > > Failed to mmap /dev/mem: Resource temporarily unavailable > > ``` > > > > Linux complains with the messages below. > > > > ``` > > $ dmesg > > […] > > [ 916.233910] x86/PAT: cbmem:2647 conflicting memory types c7f9f000-c809f000 uncached-minus<->write-back > > [ 916.233927] x86/PAT: reserve_memtype failed [mem 0xc7f9f000-0xc809efff], track uncached-minus, req write-back > > […] > > ``` > > > > You are going to need to open the /dev/mem file w/ O_SYNC flags > because the kernel is marking that range of memory as uncacheable. > More info can be found here: > https://www.kernel.org/doc/Documentation/x86/pat.txt I totally missed, that besides selecting code coverage, the Linux kernel was updated to version 4.2 in between. Probably they changed some default. $ uname -a Linux my-asrocke350m1 4.2.0-1-686-pae #1 SMP Debian 4.2.1-1 (2015-09-25) i686 GNU/Linux > # cat /sys/kernel/debug/x86/pat_memtype_list > > would be helpful $ sudo more /sys/kernel/debug/x86/pat_memtype_list PAT memtype list: uncached-minus @ 0xc7fa7000-0xc7fa8000 write-back @ 0xc7fb8000-0xc7fbb000 write-back @ 0xc7fba000-0xc7fbd000 write-combining @ 0xe0040000-0xe0274000 write-combining @ 0xe0274000-0xe0474000 write-combining @ 0xe0474000-0xe0475000 write-combining @ 0xe0478000-0xe0978000 uncached-minus @ 0xf0004000-0xf0005000 uncached-minus @ 0xf0100000-0xf0140000 uncached-minus @ 0xf0140000-0xf0144000 uncached-minus @ 0xf0144000-0xf0148000 uncached-minus @ 0xf0148000-0xf0149000 uncached-minus @ 0xf0149000-0xf014a000 uncached-minus @ 0xf014a000-0xf014b000 uncached-minus @ 0xf014b000-0xf014c000 uncached-minus @ 0xf014b000-0xf014c000 uncached-minus @ 0xf014b000-0xf014c000 uncached-minus @ 0xf014b000-0xf014c000 uncached-minus @ 0xf8088000-0xf8089000 uncached-minus @ 0xfed00000-0xfed01000 uncached-minus @ 0xfed80000-0xfed81000 > along with this: > > $ for i in /sys/firmware/memmap/*; do echo $(cat $i/type $i/start $i/end); done $ for i in /sys/firmware/memmap/*; do echo $(sudo cat $i/type $i/start $i/end); done System RAM 0x0 0x9fbff reserved 0x9fc00 0x9ffff reserved 0xf0000 0xfffff System RAM 0x100000 0xc7f9cfff reserved 0xc7f9d000 0xdfffffff reserved 0xf8000000 0xfbffffff System RAM 0x100000000 0x21effffff Thanks, Paul

4 years, 12 months

ASUS KFSN4-DRE Automated Test Failure

by Raptor Engineering Automated Coreboot Test Stand

The ASUS KFSN4-DRE fails verification as of commit 321402bfced59bd241711ed8ee4a6d8e46f9f081 The following tests failed: BOOT_FAILURE Commits since last successful test: 321402b 3dparty/blobs: Advance to pull in binary microcode 46a7c82 Makefile: Replace the way to test if a string is empty See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html Raptor Engineering also 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

5 years

Output debug log to HSUART1

by Cao Duc Quan

Dear all, I am working on custom board base on BYT-I E3825. The PCBA has two serial debug port connected to HSUART1 and HSUART2. I wonder if there is anyone enable the debug log to HSUART1 ? My configuration for coreboot base on MinnowMax board which uses legacy console so I do not get any output from coreboot (both romstage and ramstage). I think HSUART1 is connected to PCI bus so we should use uart8250mem.c ? I have tried it but no luck. Any help or guideline is highly appreciated. Thanks a lot, -- Quan Cao 0976574864

5 years

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2015