Tag: Coreboot

RISC-V/LowRISC update

~ hucktech ~ Leave a comment

The recent RISC-V workshop is over, presentations are online, videos are not yet online:

http://riscv.org/workshop-jan2016.html
http://riscv.org/

RISC-V and coreboot:

Click to access Tues1345%20riscvcoreboot.pdf

RISC-V and UEFI:

Click to access Tues1415%20RISC-V%20and%20UEFI.pdf

There is some post-workshop coverage here:
https://blog.riscv.org/2016/01/3rd-risc-v-workshop-presentations-breakouts/
http://www.lowrisc.org/blog/2016/01/third-risc-v-workshop-day-one/
http://www.lowrisc.org/blog/2016/01/third-risc-v-workshop-day-two/

Why I will be using RISC-V in my next chip


http://www.eetimes.com/document.asp?doc_id=1328620&

LowRISC, a related project to RISC-V is also making progress. From the below EE Times article:

“The LowRISC project at the University of Cambridge is attracting interest as the likely first source of real development hardware. The team which includes members of the Raspberry Pi project hopes to have first silicon this year and plans to make development boards available in 2017, likely for $50-100.”

http://www.lowrisc.org/

http://www.eetimes.com/document.asp?doc_id=1328620&

I missed this news, it is interesting to see Google, HP, and Oracle getting involved with RISC-V.

http://www.eetimes.com/document.asp?doc_id=1328561&

 

Firmware and RISC-V workshop

~ hucktech ~ Leave a comment

At the 3rd RISC-V Workshop, there have been presentations by coreboot and UEFI. The below blog has some notes on these presentations:

http://riscv.org/workshop-jan2016.html
http://www.lowrisc.org/blog/2016/01/third-risc-v-workshop-day-one/

Apparently, someone is porting UEFI to RISC-V. I wonder what company is funding/doing it??

coreboot update

~ hucktech ~ Leave a comment

Patrick Georgi posted an update to the coreboot blog with changes. coreboot has recently started doing more regular status updates via it’s blog. It is nice to have a regular update to coreboot, I wish UEFI and U-Boot had such a fresh news source.

A few excerpts of the changes are listed below, see full blog post for entire report:

The leading themes were the removal of support for old mainboards, and the integration of more non-AGESA AMD support code for Family 10h to 15h that spans everything from fixes to memory configuration to workarounds to problems in the SATA controller, to new feature development, enabling CC6 power-state support and everything in-between.”

Other chipset level contributions provided bug fixes to the drivers supporting Intel’s Skylake and AMD’s newer chipsets and mainboards (Kabini, Merlin Falcon, Mullins).

Also new is the Intel i8900 southbridge support that can be used with Sandy Bridge and Ivy Bridge, with an Intel reference board, the stargo2, and the SUNW Ultra40m2 board support.

Automated testing now also covers intelvbttool.

More information:

coreboot changelog

coreboot update

~ hucktech ~ Leave a comment

Last week Patrick Georgi posted a new entry to the coreboot blog.

There is support for 4 new boards: 2 Google boards, google/chell and google/lars, and 2 Asus boards, KFSN4-DRE and KGPE-D16. There were improvements to cbfstool, libpayload, superio and i2c chip drivers. The project has udpated their automated testing, and related code cleanup. There is a new lint tool for Kconfig files, see util/lint/kconfig_lint. It appears there is some fuzzing infrastructre being setup, including afl support! Some unmaintained, untested driver code was removed, and there is a maintainer-related script to help, see util/scripts/maintainers.go.

“The ongoing effort to support booting in long mode (64 bit) on AMD64 progressed by the integration of changes to make SMM handling and AMD chipset drivers 64bit clean.”

“Sandybridge now initializes CPUs serially for robustness reasons, and Intel FSP supports loading microcode from coreboot.”

“All related chipsets also saw significant improvements, of which the still ongoing effort to provide non-AGESA implementations for the Fam15h CPU, as well as a ton (metric, in case you’re curious) of bugfixes and feature developments (for example Suspend to RAM) for all AMD CPUs starting with K8 is particularly notable.”

Full blog post:

coreboot changelog

coreboot 4.2 released

~ hucktech ~ Leave a comment

Patrick Georgi posted the announcement of coreboot 4.2 to the coreboot blog today. Below is excerpt of announcement, see blog post for full details:

“Halloween 2015 release – just as scary as that sounds”

Since 4.1, 936 commits by 90 authors, increasing the code base by approximately 17000 lines of code, 35 new contributors, more than 34 active developers. […] There was some limited testing to make sure that the code is usable, and it boots on some devices. A structured test plan will only become part of the release procedure of future versions. […]  This is also the first release that will be followed by the removal of old, unused code. There will be a policy on how to announce deprecation and removal of mainboard and chipset code for future releases. Changes since 4.1:

Build system:
– Store a minimized coreboot config file in cbfs instead of the full config
– Store the payload config and revision in CBFS when that info is available
– Add -compression option for cbfs-files-y. Valid entries are now -file, -type, -align, and -compression
– Change Microcode inclusion method from building .h files to pre-built binaries
– Update Builder tests for each commit to test utilities and run lint tools
– Many other small makefile and build changes and fixes
– Remove expert mode as a Kconfig option

Utilities:
– Many fixes and updates to many utilities (158 total commits)
– ifdtool: Update for skylake, handle region masks correctly
– crossgcc: Update to gcc 5.2.0
– kconfig: Add strict mode to fail on kconfig errors and warnings
– vgabios: Significant fixes to remove issues in linking into coreboot code
– Add script to parse MAINTAINERS file
– Add Kconfig lint tool
– Create a common library to share coreboot routines with utilities
– Significant changes and cleanup to cbfstool (81 commits). Major changes:
– Update cbfstool to change the internal location of FSP binaries when adding them
– Decompress stage files on extraction and turn them into ELF binaries
– Header sizes are now variable, containing extended attributes
– Add compression tags to all cbfs headers so all cbfs files can be compressed
– Add and align CBFS components in one pass instead of two
– Add XIP support for X86 to relocate the romstage when it’s added
– Removed locate command as it’s no longer needed
– Add bootblock and cbfs_header file types so the master header knows about them
– Prefer FMAP data to CBFS master header if FMAP data exists
– Add hashes to cbfs file metadata for verification of images

Payloads:
– SeaBIOS: update stable release from 1.7.5 to 1.8.2
– Libpayload had some significant changes (61 commits). Major changes:
– Add support for fmap tables
– Add support for SuperSpeed (3.0) USB hubs
– Updates and bugfixes for DesignWare OTG controller (DWC2)
– Add video_printf to print text with specified foreground and background colors
– Updates to match changes to cbfs/cbfstool
– Add cbgfx, a library to show graphics and text on a display
– Read cbfs offset and size from sysinfo when available

Vendorcode:
– fsp_baytrail: Support Baytrail FSP Gold 4 release
– AMD binary PI: add support for fan control
– Work to get AMD AGESA to compile correctly as 64-bit code
– Add standalone (XIP) verstage support for x86 to verify romstage

Mainboards:
– New Mainboards:
– apple/macbookair4_2 – Sandy/Ivy Bridge with Panther / Cougar point chipset
– asus/kgpe-d16 – AMD Family 10, SB700/SR5650 platform
– emulation/spike-riscv – RISCV virtualized platform
– google/chell – Intel Skylake chrome platform
– google/cyan – Intel Braswell chrome platform
– google/glados – Intel Skylake chrome platform
– google/lars – Intel Skylake chrome platform
– intel/kunimitsu – Intel Skylake chrome platform
– intel/sklrvp – Intel Skylake reference platform
– intel/strago – Intel Braswell chrome platform
– Cleanups of many mainboards – several patches each for:
– amd/bettong
– getac/p470
– google/auron, google/smaug and google/veyron_rialto
– pcengines/apu1
– siemens/mc_tcu3
– Combine the google/veyron_(jerry, mighty, minnie, pinkie, shark and speedy) mainboards into the single google/veyron mainboard directory

Console:
– Add EM100 ‘hyper term’ spi console support in ramstage and smm
– Add console support for verstage

ARM:
– armv7: use asm coded memory operations for 32/16 bit read/write
– Many cleanups to the nvidia tegra chips (40 patches)

RISC-V:
– Add trap handling
– Add virtual Memory setup

X86:
– Remove and re-add Rangeley and Ivy Bridge / panther point FSP platforms
– Update microcode update parser to use stock AMD microcode blobs from CBFS
– ACPI: Align FACS to 64 byte boundary. Fixes FWTS error
– AMD/SB700: Init devices in early boot, restore power state after power failure. Add IDE/SATA asl code
– Add initial support for AMD Socket G34 processors
– Add tick frequency to timestamp table to calculate boot times more accurately
– Unify X86 romstage / ramstage linking to match other platforms
– Start preparing X86 bootblock for non-memory-mapped BIOS media
– cpu/amd/car: Add Suspend to RAM (S3) support
– Native VGA init fixes on several platforms
– Significant updates to FSP 1.1 code for cleanup and cbfstool changes
– SMMhandler: on i945..nehalem, crash if LAPIC overlaps with ASEG to prevent the memory sinkhole smm hack
Drivers:
– Add native text mode support for the Aspeed AST2050
– w83795: Add support for for fan control and voltage monitoring
– Intel GMA ACPI consolidation and improvements
– Set up the 8254 timer before running option ROMs
– Resource allocator: Page align memory mapped PCI resources

Lib:
– Derive fmap name from offset/size
– Several edid fixes
– Updates to cbfs matching changes in cbfstool

Submodules:

3rdparty/blobs:
– AMD Merlin Falcon: Update to CarrizoPI 1.1.0.0 (Binary PI 1.4)
– AMD Steppe Eagle: Update to MullinsPI 1.0.0.A (Binary PI 1.1)
– Update microcode to binary blobs. Remove old .h microcode files

3rdparty/vboot:
– Update the code to determine the write protect line gpio value
– Several updates to futility and image_signing scripts
– Update crossystem to accommodate Android mosys location
– Support reboot requested by secdata
– Add NV flag to default boot legacy OS

More information:

Announcing coreboot 4.2


http://www.coreboot.org/releases/

coreboot changes

~ hucktech ~ Leave a comment

The coreboot blog has a long post, which covers the last five weeks of changes, and there were a lot: 314 commits. Some highlights:

Over one third of the commits covers Intel Skylake development, where boards and chipset code saw misc improvements and tons of clean ups.

There also was a notable effort of unifying common code across the more recent Intel SoCs, removing lots of duplicated code all over the place.

On x86, the romstage is now relocated for its final location in CBFS by cbfstool, obsoleting the old approach that had us link it twice, once to determine its final size and then to the actual location it’s supposed to run from. In the future this same approach may be extended to other files that need to be executed in place such as the FSP binary.

The romstage change eliminated the need for cbfstool’s “locate” command, and so it was removed. cbfstool also saw other extensions, the biggest one a compatible change to the format to allow for per-file attributes in CBFS. These attributes can contain additional information about a file, currently the compression method and uncompressed size of a file. cbfstool and the build system were extended to allow compressing files, libpayload is able to uncompress these files.

On the AMD side, there were various bugfixes both for new (merlin falcon) and old (Fam10) chipsets.

ARM64 and Tegra210 saw various bugfixes and improvements to power use. For the latter, coreboot also learned how to reserve memory for other functions than the main processor.
Rockchip’s RK3288 ARMv7 SoC also saw a number of bug fixes and the code was restructured to use a single mainboard directory for a large number of very similar Google Veyron mainboards based on that SoC.

Our RISCV support now boots on the Spike simulator which (besides supporting a wider variety of emulators) is notable because unlike the QEmu RISCV support, Spike supports RISCV’s revised ABI.
Speaking of emulators, recent versions of qemu-x86 expect the firmware to initialize the LAPIC, which we now do.

The ongoing effort to move CPU microcode into CBFS (and to store these as binaries in 3rdparty/blobs instead of header files in the main sources) saw some progress.

Lots of interesting things were omitted above. Full post:

coreboot changelog, most-of-september edition

PAE-enabled SeaBIOS

~ hucktech ~ Leave a comment

On the SeaBIOS mailing list, Kevin O’Connor recently provided a patch to SeaBIOS to enable it to run in PAE mode. SeaBIOS is the main open source implementation of 16-bit x86 BIOS, used in coreboot, tianocore, and elsewhere. Excerpting Kevin’s posting:

I was curious to see if SeaBIOS could run its 32bit code with PAE paging enabled.  So, I put together some test code, and so far it seems to work.

The reason why PAE is interesting (instead of standard i386 paging) is that it allows for 64bit mappings and because one can set it up with just a single level page directory of 2MB pages.  The single level page directory makes maintaining it much easier.

The SeaBIOS’ malloc code could also be updated to remap pages which would make it possible for it to relocate itself above 4GB and to store data above 4GB.  That’s likely not all that useful, but I think it would be a little amusing for a 16bit bios to fully support 64bit memory.

I haven’t done any performance tests.  It’s unclear what the performance impact of enabling paging on every 32bit entry point would be.

It appears that more work will be done before this patch is contributed to trunk. But it is interesting to see PAE-enabled BIOS!

More Information:
http://www.seabios.org/pipermail/seabios/2015-September/009788.html
http://www.seabios.org/

Linux Luddites podcast on Ron Minnich

~ hucktech ~ Leave a comment

As found on the coreboot blog, episide 49 of Linux Luddites podcast, from last month, has a firmware focus.

With Android’s security woes making even the mainstream press, it’s hardly surprising that they featured in our news this show. But we also found time to bring you stories about Fedora and Ubuntu, FFmpeg, a couple of Kickstarter projects with very different outcomes, and a similarly mixed bag of news for Lenovo. Ron Minnich has long been associated with Open Source firmware, and after the news we spoke to him about the coreboot project. In our interview we found out why Ron is so enthusiastic about Google’s Chromebooks, discovered his hopes for a new RISC ISA from Berkeley, and quizzed him on whether Purism can really deliver on their promise of a modern and truly FOSS mass-market laptop.

https://linuxluddites.com/shows/episode-49/

Linux Luddites interview Ron Minnich

Purism BIOS efforts

~ hucktech ~ Leave a comment

Purism mentioned in a Tweet that they have 3 developers working on Intel Management Engine:

They have one document, from the summer, talking about how they’re trying to free the BIOS:

https://puri.sm/posts/freeing-the-bios-the-memory-init-stage/

And another more recently-updated status page:

https://puri.sm/road-to-fsf-ryf-endorsement-and-beyond/

Purism offers the first high-end privacy and freedom-respecting laptops by manufacturing the motherboard and sourcing daughter cards, where all chips are designed to run free software. Purism laptops are completely free from the bootloader through the kernel (with no mystery code, binary blobs, or firmware blobs), including the operating system and all software. We have yet to free the Intel FSP binary and ME binary from within the coreboot BIOS to move us toward FSF RYF endorsement. We are working diligently to free the BIOS, but our goal is to go further than that: Purism also intends to free the firmware within HDDs and SSDs.

I’m still unclear how this will result. I’m of two minds on this: I love the idea of having a system I can trust, so am happy to see projects like Novena and Purism. On the other hand, Purism is fighting Intel’s security mechanisms, and I’m a little concerned the result will remove some Intel defensive technology that makes the system more easily attackable.

Their current model has a kill switch, which is a nice feature. [I’d also like a case that closes access to the ports when closed, and has a LOCK, with a good quality lock, that can’t be easily picked. That’d be an issue for TSA checkpoints, though.] I might also consider getting ride of Suspend/Resume, a lot of attacks happen there, and systems are fast enough these days to live without this feature.

I wish other OEMs would compete with Purism, it would be nice to have more options than a handful of ancient refurbished Thinkpads and a handful of remaining Novenas. The current Purism model is nearly done with funding, only a few days left:

 

coreboot conference 2015 announced

~ hucktech ~ Leave a comment

What: coreboot conference 2015
When: October 9-11 2015 (after ELC-E)
Where: Bonn, Germany

Carl-Daniel Hailfinger announced the 2015 coreboot conference on the coreboot-announce list today. Excerpted announcement follows, see below URL for full details:

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 as well as (potential) coreboot users. Both professionals and hobbyists are invited. 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.
Call for presentations: We are looking for interesting talks/presentations about coreboot related topics for the first (and possibly second) day of the conference.
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.
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.
Call for developers: If you want to do development all day, every day, just come and do it.

More Info:
http://www.coreboot.org/pipermail/coreboot-announce/2015-September/000021.html
http://coreboot.org/coreboot_conference_Bonn_2015

Firmware patents….

~ hucktech ~ Leave a comment

SPOILER ALERT: This post discusses patents. If you’re an employee at a company, ask your manager if you’re able to read this sort of information…..
.
.
.

I wonder how bad it’s going to get with firmware patents… Searching the patent databases, I find THOUSANDS with ‘firmware’, HUNDREDS with ‘UEFI’, and dozens with ‘coreboot’, and many for ACPI. For example, it appears that Microsoft has patented the ability to securely update firmware:

Microsoft: Secure Firmware Updates
US 20140068585 A1, CN 104603792 A, US 8898654 B2

This is just one example, all of the big OEMs, IHVs, and ISA vendors have patents left and right in this space. 😦

Are vendors able to build UEFI — or even coreboot — systems without lawyers from some of the big companies knocking on their door asking for royalties? Where is the firmware equivalent of the “Open Invention Network”, to help smaller vendors even use basic firmware functionality with lawyers looking to monetize everything? I wonder if the Maker movement or Open Hardware or Free Hardware is going to be able to survive this.

coreboot end-user flash tool

~ hucktech ~ 1 Comment

The coreboot project has a Google Summer of Code (GSoC) going on, a few students have been contributing new features to coreboot over the Summer. One effort is Lukasz Dmitrowski and the GUI “End user flash tool”:

Main purpose of End user flash tool project is to provide an easy way to build and flash coreboot ROM. To achieve it there is a need to collect hardware specific data such as:
* lspci -nn output: information about all PCI buses and devices in the system, it is possible to recognize a graphic card, its vendor and device codes
* dump of factory BIOS: it is important to make a copy of factory BIOS in case something will go wrong, but not only in this case, very often there is a need to use a VGABIOS extracted from factory BIOS if particular graphic card or display panel is present in our system, it is the best to make dump two times and then check if files are the same (for example by comparing hashes)

The GSoC ends next week, and Lukasz needs some testing help, especially if you have a Lenovo T60 laptop:

GSoC ends in next week, application is almost done (but will be improved and extended also after GSoC), so this is time for some testing! I would be very grateful if some of you could help me with it. It would be the best if you have Lenovo T60 and external programmer. First there is a need to collect some hardware specific data and then it would be possible to check if application creates working coreboot image basing on this data. So it is not only about testing, but also about making white list of hardware configurations bigger to let more users flash their hardware with coreboot in easy way!

See the full blog post for contact info for Lukasz:

[GSoC] End user flash tool – week #7 #8 #9

Libreboot ported to modern ARM Chromebook

~ hucktech ~ Leave a comment

Earlier this month, Paul Kocialkowski announced some work of his: getting Libreboot running on an ARM-based Chromebook, the Asus C201 “veyron_speedy”). Paul is a developer on the Replicant project, a free-as-in-freedom Android distribution.

Some quotes from Paul’s announcement:

“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.”

“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.”

“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.”

See the below libreboot mailing list post for full announcement. It’s not perfect, there are some issues with the Mali T764 Mali, and free software support, and some other rough edged, but perhaps these can be worked out over time.

Also, as mentioned in an earlier post, Paul will be at Chaos Communications Camp (CCCamp) 2015 later this week:

“I’ll be at CCCamp 2015 to talk about Replicant (as well as other things that I’m working on, like porting Libreboot to the C201 Chromebook), starting tomorrow.”

Very nice work Paul!!

http://blog.replicant.us/
http://lists.nongnu.org/archive/html/libreboot/2015-08/msg00009.html

Replicant and friends at Chaos Communication Camp 2015

AMD clarifies firmware strategy

~ hucktech ~ 1 Comment

A while ago, I asked on the UEFI development list for someone to clarify AMD’s UEFI strategy. I’m unfortunately, not that strong on AMD64 technology, and was a bit confused by the available documentation as to a few things. Gary Simpson, Firmware Architect at AMD, was kind enough to reply to my questions, with verbose reponses. I’ve slightly edited the message, cleaning up the email intro and simplifying my questions, but did not alter any text responses from AMD. Below, lines beginning with “Q:” are questions from me to AMD, and the bold lines with “A:” are Gary’s replies.

Q: Can anyone explain AMD’s strategy w/r/t UEFI and BIOS, UEFI and coreboot?
A: Here’s some quick background: AMD is a founding Board member (i.e. Promoter) of the UEFI Forum and an active member in most of the work groups.  We are proponents of the UEFI and ACPI interfaces (because they provide standardized firmware API’s, allowing shrink-wrapped OS distributions, without customized drivers, enabling end-user OS flexibility and choice).  Also, despite some birthing pains with individual implementations, UEFI is enormously more secure than legacy BIOS was.  AMD’s evolution from legacy BIOS to UEFI has happened over the last ten years in sync with the schedules of our industry partners (IBV’s, OEM’s) and their code bases.  We’re not seeing any demand for legacy BIOS enablement anymore, so we no longer focus any effort there.  Coreboot is the only remaining legacy code base we enable.  Coreboot enablement is provided by AMD’s embedded group for a market-appropriate subset of our chips.
    By the way, you may be assuming that the traditional competitiveness between companies persists in the UEFI Forum and the spec work groups that it oversees.  But there is actually very little of that (especially compared with a lot of other industry-standards bodies).  The general attitude within UEFI is that the firmware layer should be unified, interoperable, well-specified and secure.  There is no room for competition or company-specific advantage in the firmware layer.  (Then, of course, we all go home to our individual companies and work to create competitive advantage at other layers, such as hardware or higher-level software.)  I just want to make sure you understand the atmosphere of cooperation and common-cause that exists between the various OEM’s, Silicon Vendors, OS Vendors, IBV’s, and others that make up the UEFI Forum.  That cooperative atmosphere pervades the UEFI work groups, as well as the UEFI Board of Directors.

Q: What AMD X64 models use UEFI, what models use BIOS, what models use coreboot?
A: We don’t specify or control this.  Our customers can implement whatever platform firmware solution they choose.  However, the firmware components AMD provides focus primarily on UEFI solutions.  As mentioned, our embedded group also enables coreboot for a selected subset of our chips.  Coreboot is the only legacy code base we still target.  For coreboot, we maintain wrappers and a centralized function dispatcher, but our core code is natively targeted at the various UEFI-style code bases used by our IBV partners, our OEM customers, and Tianocore (e.g. EDKII).

Q: I’m unclear if current/upcoming AMD X64 models are still using BIOS on most or only some of their systems, as well as coreboot -vs- UEFI usage and future plans.
A: Internally, we create Customer Reference Boards (CRB’s) and build platform firmware in-house to support them.  These in-house BIOS’s, which we use to bring-up and validate our new silicon designs, are all UEFI-based.  These are almost always based on our AGESA firmware (see below) combined with a platform code base from one of the IBV’s.  Additionally, AMD’s embedded team ports coreboot to their versions of the CRB’s.

Q: Are there different goals for UEFI/BIOS/coreboot for consumer desktop/laptop models -vs- server models? I’ve heard one person speculate that servers are focusing on BIOS, laptops are focusing on GPUs/DirectX [and perhaps UEFI].
A: AMD’s goal is simply to provide what our customers want and need.  Server manufacturers were, in general, slower to transition from legacy to UEFI,  but we are no longer seeing any demand from them for legacy BIOS.

Q: I’m really unclear how they can get Win8 logos if they’re using BIOS. If they’re getting logos for those systems. Do AMD systems have less Win8 technical restrictions than Intel systems in this regard?
A: In combination with the BIOS Vendors and/or the OEM’s, AMD makes UEFI solutions (supporting Secure Boot, etc.) available for all our chips.  We qualify for our Win8 and Win10 logo certifications the old fashioned way – by passing the tests.  We make sure that all of our CRB’s pass the certifications tests, and we assist our OEM customers as needed to make sure that their production systems pass as well.

Q: What is AMD equivalent of Intel FSP, for closed-source blobs need alongside Tianocore open source?
A: Our deliverable is called AGESA (AMD Generic Encapsulated SW Architecture).  It plugs into the IBV and OEM code bases and does initialization and configuration of the AMD silicon (CPU, GPU, FCH (southbridge), GNB (Graphics North Bridge), etc.).  We private-license AGESA source (for free) to our IBV and OEM partners.  For coreboot, AGESA is currently provided as a binary module.  We did previously publish AGESA open-source in the coreboot repository for a few of our chips over the last several years.  You can have a look at those if you’re interested.

Q: How do I debug UEFI on AMD systems, like I can use Intel WinDbg/GDB-based solution for debugging Tianocore with Tunnel Mountain box?
A: AMD does not have an equivalent to Tunnel Mountain. There aren’t any motherboard manufacturers willing to produce and sell such a board, since our volumes would be smaller than Tunnel Mountain.  We do design and build Customer Reference Boards for each new chip.  The CRB volumes are small and the cost is high, so they mostly go to larger customers.  Even inside AMD, these are usually in short supply.

Q: Are you going to port LUVos (and LUV-live) — including it’s new and bundled various tests, especially CHIPSEC — to your systems? CHIPSEC won’t work on AMD64 systems, only Intel systems, implementations are different.
A: We don’t have any current plans to do this, but your question may cause us to do more investigation in this area.

Q: For AMD’s new ARM Ltd.-based systems, are they going to use UEFI on all of them, or just some? What will be used on others, U-Boot or something else?
A: This is an area where we are feeling our way forward. Different customers will want different things.  We will try to accommodate them all as well as we can.  We plan to offer AGESA for UEFI code bases only, so we won’t support U-Boot directly, but we will enable a UEFI solution that creates a Flattened Device Tree, which should boot any OS’s that normally sit on top of U-Boot.

Q: Are you using Linaro for UEFI bits and making your own ARM firmware, our outsourcing to IBV, if so which?
A: We are working with IBV’s, replicating the traditional firmware-development process from the x86 PC world, but we recognize that traditional ARM-embedded customers may be looking for a free-source stack from us, so we are working to prepare for that possibility as well.

Q: Are you going to help Linaro with their AArch64 port of LUV-live and CHIPSEC, especially including AMD-specific AArch64 implementation issues?
A: No plans yet, but we will investigate.

—- [End of ‘interview’.]

Thanks, Gary, for the detailed answers to my many ignorant questions!  For more information, see the email thread on the edk2-devel mailing list, mainly see Gary’s response on July 31st:
https://lists.01.org/mailman/listinfo/edk2-devel

It is especially good to hear about AGESA being open source! I hope Intel can match that bar, with FSP…

Since the responses from Gary, I’ve done two AMD64-centric blog posts, one on the most recent (?) vulnerability, and one on ASESA.

Recapping Marek’s Jan2015 AMD security vulnerability

AMD AGESA

Some additional questions I should’ve asked but didn’t think of until now:

Q: Has AMD or any AGESA licensee (IBV, OEM) ever hired an security audit of the AGESA sources, and published the results?

Q: Does the AMD’s SimNow, either Public or Partner release, support OVMF (the public release appears to not), or is there any other emulator/simulator accurate enough to facilitate porting of CHIPSEC to AMD64 systems?

Q: Can you clarify use of TrustZone on AMD64 — not ARM Ltd.-based AArch32/AArch64 systems? Does TrustZone even work on non-ARM systems as-is, or was this a new port? Are there any more technical details you can point us to for this?

Again, thanks Gary! For the sake of enterprise security, I hope AMD helps with and AMD64 port of CHIPSEC, or at least helps document the issues that need to be removed and added to and AMD64 port, so the open source community can help with the port.

October coreboot conference in Germany

~ hucktech ~ Leave a comment

There’s a coreboot conference being planned for this October in Bonn, Germany.  Carl-Daniel Hailfinger posted an entry on this in the coreboot blog yesterday. The audience is not only developers, but manufacturers of processors, chipsets, mainboards and servers/laptops/tablets/desktops with an interest in coreboot and the possibilities it offers.

“The preliminary plans are to coordinate the exact date of the conference to be before or after Embedded Linux Conference Europe, scheduled for October 5-7 in Dublin, Ireland. Planned duration is 3-4 days. This means we can either use the time window from Thursday Oct 1 to Sunday Oct 4, or from Thursday Oct 8 to Monday Oct 12.”

The conference needs to know if you’re going to attend, so they can plan the event. Look at the blog post for how to contact them.

Update: coreboot conference in Europe, October 2015


http://doodle.com/bw52xs4fc7pxte6d

AMD AGESA

~ hucktech ~ Leave a comment

I’m learning about AMD firmware solutions, and AGESA is first acronym on the list. According to Wikipedia:

“AMD Generic Encapsulated Software Architecture (AGESA), is a bootstrap protocol by which system devices on AMD64-architecture mainboards are initialized. The AGESA software in the BIOS of such mainboards is responsible for the initialization of the processor cores, memory, and the HyperTransport controller. AGESA documentation was previously available only to AMD partners that had signed an NDA. AGESA source code was open sourced in early 2011 to gain track in coreboot.”

There are two firmware ecosystems, coreboot and UEFI, where the former has a lot of Chrome OEMs, and the latter has a lot of Windows OEMs. UEFI and coreboot work on Intel and AMD (and ARM) systems. AMD makes both x86 and ARM systems, but I’m focusing on their x86 systems here.

For coreboot, Sage Engineering is main coreboot IBVs (Independent BIOS Vendors), AFAICT. Sage currently supports AMD systems, offering coreboot with AGESA.

https://www.se-eng.com/products/sagebios-bsp-for-amd-processors/

“Sage supports many modern x86 platforms from AMD. In early BSP releases,our source code license allowed us to directly modify and include AGESA source code. Later versions include the AGESA binary PI from AMD to initialize the CPU. SageBIOS(TM) Custom BSPs deliver full-featured firmware designed for AMD platforms.”

https://www.se-eng.com/firmware-solutions-for-intel-and-amd-x86-processor-systems/

“AMD was the first […] to support an open source boot solution with its support of the One Laptop Per Child program, which was immersed in the Linux open source community, and the Linux firmware boot solutions that would ultimately become coreboot. Sage Electronic Engineering founder Scott Hoot was heavily involved in that the children’s laptop project, as a firmware designer for AMD, and would soon embrace open source firmware solution as a foundation for his startup company. Sage would have distinct advantages over other open source firmware development companies in that Hoot already had a insight into AMD’s proprietary architecture, which he would cement with a agreements with AMD to help forge the way into expanded open source BIOS and firmware coding. Sage would continue to forge a trail in the community with its support of the coreboot(R) solution and the proprietary hybrid that Sage developed for more rapid deployment, SageBIOS. Open source development as a whole continue to progress with AMD’s AGESA  and Intel’s Firmware Support Package, essentially giving open source firmware designers a better look at the architecture than was previously allowed.”

Over in the UEFI Forum ecosystem, it appears that most of the ‘mainstream’ IBVs also support ARM via AGESA in their products as well. I see support from Insyde Software and AMI, at least.

http://www.insyde.com/press_news/press-releases/insyde-software-provides-framework-support-amd-processors

http://www.ami.com/news/press-releases/?PressReleaseID=135&/American%20Megatrends%20Extends%20Aptio%C2%AE%20Firmware%20Support%20for%20AMD%20AGESA%E2%84%A2/

I’m still not clear if TianoCore can use AGESA directly, or if an IBV is still needed to integrate the two.

More Information:

http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=src/vendorcode/amd
https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/a46a712610c130cdadfe1ebf6bec9ad22e474dac/src/cpu/amd/agesa

Click to access AGESA_Interface_specification_for_Arch2008.pdf

[I just realized that I’ve not written a blog on Intel Firmware Support Package (FSP) yet…. I’ll do one in a few days.]

Jeff Thomas leaves Sage Engineering

~ hucktech ~ Leave a comment

Hmm, I don’t understand what is happening at Sage Engineering, it looks like there are are multiple coreboot people who are looking for a job(?), see below bold sentences (emphasis mine):

http://www.se-eng.com/2015/07/so-long-and-thanks-for-all-the-fish/

I woke up this morning dreaming about different chipsets and boot solutions, though quickly realizing there was no longer a reason. Because today I’m writing my last blog for Sage Electronic Engineering. Along with myself, the change the technical to non-technical writer, there are a lot of fine coreboot engineers now looking for work. I’d like to thank everyone who followed this blog, notably Vincent Zimmer at Intel, as it has meant a lot to me, as well as my company. I’d also like to thank Sage CEO Scott Hoot and VP of Marketing Dennis Batchelor for having me along, as well as the numerous engineers and managers, Drew Jensen and Steve Goodrich come to mind, I’ve bothered with questions along the way. I enjoyed working here very much. Mostly, I’d like to note that I never did get around to writing about owner/engineer  Kimarie Hoot, who certainly deserves an award for both a woman in software and a woman in business. Some publicist I am. Kimarie is much more than a credit to her gender and electronic engineering. I’m not sure what’s going to happen to some very fine engineering here at Sage, especially the SageBIOS for Intel and AMD processors, but I’d like to believe it will be available in some form. Seems like an incredible waste otherwise. Everyone I’ve worked with here has been a credit to x86 embedded development. When they asked me what I knew about BIOS and firmware when I interviewed here, I said, “Well I’ve updated BIOS on my laptop, pretty much know what that does, and I’ve flashed a couple of routers — that’s about it.” Hopefully, I’ve found my way around a bit since then. Anyway, my last stab at humor, and there have been some outstanding failures in this department, comes from the Hitchhiker’s Guide to the Galaxy series. So long, and thanks for all the fish.

What is the safest firmware solution?

~ hucktech ~ Leave a comment

Stephan of the coreboot project is currently having a Twitter conversation with some others. It includes this post:

This makes me wonder, has anyone compared Chrome’s Verified Boot with UEFI’s Secure Boot. With and w/o TPM chip on Intel or TrustZone on ARM. It would be nice if some cyypto-savvy researchers could analyze the crypto used in both implementations and give a comparison, including how these solutions meet the NIST and NSA/CC criteria for securing BIOS.

In terms of code size, coreboot has a much smaller codebase than tianocore, even with the all the additional size that Chrome brings to it’s coreboot dialect. But both Secure Boot and Verified Boot are nearly the same in terms of PKI.

On a related not, I’ll do a future blog post looking into the various boot flavors: Trusted Boot, Secure Boot, Measured Boot, Verified Boot, etc.

Post 4.1 improvements in coreboot

~ hucktech ~ Leave a comment

The other day, coreboot 4.1 was released. The coreboot blog recently summarized some recent new changes and features, covering 4.1 up to current (commit 406effd5). Summarizing new features and support:

* 1 new chipset: Intel Skylake SoC
* 4 mobos: google/cyan, intel/kunimitsu, intel/sklrvp, and intel/strago
* Some build script improvements.
* USB host drivers in libpayload have multiple improvements.
* Changes to the CBFS format.
* Many bugfixes, especialy in ARM64 and Nvidia Tegra210, and Google Foster and Smaug boards.

See the coreboot blog for more details.

coreboot changelog – Week of 2015-07-13

There’s also a “summer of code” for coreboot, with multiple projects, that’ve been happening for weeks now. I’ve not covered those yet, I was going to wait for the end-of-Summer, but if you haven’t looked at the projects, they’re in older entries in the coreboot blog.