We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Status of AMD platforms in coreboot

00:00

Formal Metadata

Title
Status of AMD platforms in coreboot
Title of Series
Number of Parts
490
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
The presentation is about AMD's involvement in coreboot evolution and development. Gives a high-level overview of the engagement of the silicon vendor in the coreboot project history. The presentation may contain a little bit of technical aspects of firmware and BIOS. However, the intended audience is not only firmware and BIOS developers, but also free and libre hardware enthusiasts too. If anybody is interested in the future of famous platforms like Asus KGPE-D16, Lenovo G505S, PC Engines apu1/apu2, please attend the presentation. The history of AMD cooperation in coreboot projects reaches 2007 where the first contribution appeared for the Geode LX processors. AMD's open-source support continued for many years until now (with some break). This presentation will briefly introduce the history of AMD and coreboot, the evolution of the code, processors, creation of CIMX and AGESA and so on. It will also show the gradual change in the AMD attitude to open-source and introduction of binary platform initialization. Binary blobs, very disliked by the open-source community started to cause problems and raised the needs for workarounds to support basic processor features. Soon after that AMD stopped supporting the coreboot community. Moreover, recent coreboot releases started to enforce certain requirements on the features supported by the silicon code base. Aging platforms kept losing interest and many of them (including fully open ones) are being dropped from the main tree. Nowadays AMD released the newest AGESA with the cooperation of hired coreboot developers, but only for Google and their Chromebooks based on Ryzen processors. These are hard times for open firmware on AMD platforms. If you are curious about what is the present status of AMD boards and hardware (for example famous Asus KGPE-D16, Lenovo G505S, PC Engines apu1/apu2) in coreboot and what future awaits them, this presentation will give you a good overview.
Computer hardwareMachine visionCore dumpBootingComputing platformImplementationPresentation of a groupOpen sourceSoftware frameworkCondition numberComputer animation
Social softwareSoftware developerSoftware maintenanceComputing platformSystem on a chipComputer hardwareInformation securityInformation securityFirmwareBootingCore dumpPatch (Unix)Computer iconHypermediaComputing platformSoftware maintenanceComputer hardwareProcess (computing)Machine visionConnectivity (graph theory)Software developerBus (computing)Condition numberPresentation of a groupChord (peer-to-peer)Multiplication signComputer animation
Source codeComputing platformSoftware maintenanceBinary codeComputing platformSoftware developerConnectivity (graph theory)Ocean currentTerm (mathematics)Computer animation
ArchitectureProcess (computing)SoftwareGeneric programmingSource codeBridging (networking)Computer-integrated manufacturingCodeCoprocessorEquivalence relationIntelSimilarity (geometry)Operations researchCryptographyInformation securityBefehlsprozessorGame controllerComputing platformGame controllerElectric generatorSoftwarePresentation of a groupComputing platformCodeBridging (networking)Process (computing)Core dumpHuman migrationCryptographyInformation securityBefehlsprozessorThermodynamischer ProzessTerm (mathematics)Equivalence relationWorkstation <Musikinstrument>Arithmetic meanMathematicsFood energyComputer architectureSource codeComputer animation
Process (computing)ArchitectureSoftwareGeneric programmingSource codeCodeComputer-integrated manufacturingIntelCoprocessorEquivalence relationInformation securityBefehlsprozessorSimilarity (geometry)Operations researchCryptographyGame controllerComputing platformMikroarchitekturCodeComputer animation
Computer-integrated manufacturingProduct (business)Bridging (networking)CodeFamilyBefehlsprozessorRead-only memoryHypercubeProcess (computing)Source codeDiscrete groupWechselseitige InformationBinary codeEndliche ModelltheorieSource codeProcess (computing)Workstation <Musikinstrument>Set (mathematics)System callGoogolFamilyInterface (computing)MaizeEndliche ModelltheorieComputer clusterPhysical lawPhysical systemOpen sourceGame theoryInsertion lossBlock (periodic table)WhiteboardRight angleNumberPrototypeDreizehnMixed realityIntrusion detection systemDistribution (mathematics)Traffic reportingComputer architectureHypercubeSemiconductor memoryProduct (business)Video gamePower (physics)TwitterTendonType theorySoftware developerProof theoryCategory of beingProjective planeLink (knot theory)Computing platformFunctional (mathematics)Multiplication signMultiplicationTape driveAssociative propertyCASE <Informatik>ImplementationBefehlsprozessorFirmwareRouter (computing)Lenovo GroupThermodynamischer ProzessInteractive televisionClosed setFreewareCodeSystem on a chipDependent and independent variablesRange (statistics)Cache (computing)SoftwareOpen setSocket-SchnittstelleBinary codeDiscrete groupGame controllerValidity (statistics)MotherboardCore dumpBootingComputer animation
Product (business)Source codeImplementationArchitectureBefehlsprozessorUsabilityGamma functionComputing platformSoftware developerWhiteboardCodeRepository (publishing)Table (information)Network topologyInheritance (object-oriented programming)Computer hardwareSoftware maintenanceIntelVideo projectorClosed setVotingTable (information)Software developerAdditionQuicksortForcing (mathematics)BlogDataflowVideo gameCore dumpLevel (video gaming)Network topologyPower (physics)19 (number)DemosceneINTEGRALKey (cryptography)Interface (computing)Server (computing)WhiteboardPhysical systemWorkstation <Musikinstrument>WebsiteProjective planeComputing platformArithmetic progressionHypermediaPoint (geometry)Presentation of a groupSource codeFamilyView (database)Ring (mathematics)ImplementationOpen sourceRule of inferenceComputer architectureLie groupMathematicsGame controllerBitMultiplication signDifferent (Kate Ryan album)CuboidCrash (computing)Library (computing)Software maintenanceIntelThermodynamischer ProzessRow (database)Block (periodic table)Branch (computer science)Software bugAuthorizationPowerPCRepository (publishing)BootingLink (knot theory)Patch (Unix)BefehlsprozessorCodeProduct (business)Inheritance (object-oriented programming)Computer hardwareBuildingDynamic random-access memoryOnline helpMotherboard
DeterminantMathematicsBlogMereologyPatch (Unix)InformationBootingBefehlsprozessorModule (mathematics)Computer animation
Point cloudFacebookOpen source
Transcript: English(auto-generated)
So welcome to my presentation about AMD platform status in Core Boot. How many of you know what Core Boot is? OK, so mostly you know what it is. So just for those who don't know,
it is an open source framework that allows to replace the vendor BIOS with own custom implementation. And my name is Miho. I'm a firmware engineer at 3MDepth. You can find me on those social medias.
Those small icons are hyperlinks, so you can contact me via those medias. And basically, I am a PC Engine's platforms maintainer in Core Boot. I also am responsible for Maxwell SoC support. And I have recently become one of the 36 Core Boot developers,
which are officially privileged to merge patches. And my region of interest is mainly security solutions and other hardware features, enablement, analysis, et cetera.
So I would like to talk first about definitions, like some AMD components present on their processors, just to know the terminology I will use during the presentation. And I will briefly describe the history of AMD and Core Boot cooperation throughout the recent 10 years or so.
And we'll also talk about the current development of newest SoCs and talk about the current status of platform maintainership. So a few terms that you need to know,
just to keep with me with the presentation and what I will be talking about. So first term is AGISA. It's AMD generic encapsulated software architecture, which is a bunch of code or a blob, it depends, which is responsible for the siliconization mainly.
There is also a Cmax. It's an older version of soft bridging initialization code, which was later merged into AGISA, which I will also mention later. FCH, it's a fusion controller hub. So it's kind of a new generation of AMD soft bridges.
It's almost like the same as Intel changed their ICH, IO controller hub, into PCH, which is a platform core hub. So it's like equivalent migration. And PSP, platform security processor. It's an equivalent of Intel ME for on AMD processors.
It is also responsible for some cryptographic operations, security, CPU bring up in some part. And yeah, when it comes to the AGISA, it's also an equivalent to Intel FSP, just to compare. Yeah, and there is a very complicated code name
and microarchitecture naming, code naming. And yeah, I will not dig too much inside this topic. I will just refer to Wikipedia or something like that. So the beginning of AMD cooperation with Corebot
began around 2007, 2008, where AMD contributed the AGISA code that supported some family 10 processors, some geode processors.
So what was this code responsible for? Mainly it was processor memory, the hyper-transport initialization. Hyper-transport is the interface that links, for example, multiple sockets, multiple processor sockets on the main board. There was also the sub-bridge initialization, the C-Max,
which supported few of these chips I have listed here. There were mainly pre-chip solutions, like there were CPU, there was some NOR bridge, and there was the sub-bridge. These are currently not available in the master branch,
but if you look at the older tags of Corebot repository, you can find those. They were done because they were very hard to maintain. This was pretty old architecture, and for example, there were no memory type range registers, and the memory had to be set up
through some non-common way. And there was problems with some cleaner caches RAM setup. Caches RAM is a temporary memory solution on x86 processors. And for example, there was code that initialized,
for example, 500 megabytes of memory just temporarily, and later we will fix it, yeah. There was a bunch of places like that, and the community decided to drop this support, because it was holding back the whole project.
And the example products are, for example, PC Engine's Alex boards. PC Engine's is a Switzerland company, which produces typically network compliance devices, like routers. And for example, this one has a geod processor, Geotalex.
And yeah, this was also one of the problematic chip sets that I mentioned with, for example, the RAM instantiation. Yeah, and later, around 211 till 213,
AGCi V5 emerged. It supported family 14H, starting with family 14H. And yet there was, there still was the Cmax code base, which was responsible for the soft-bridge instantization.
But later, for family 15H, the Cmax has been merged into AGCi, so just made less burden for the developers to integrate. Because Cmax put some kind of requirements, for example, call this function right after power on,
because some soft-bridge registers have to be issued at first. So it was problematic, so it has been merged into AGCi. Yeah, and the Cmax has been merged into AGCi, and the discrete fusion controller hub
has been introduced. So we are basically going out from the free chip solutions, and we have only the CPU and the FCH. And for example, those open source AGCi
was introduced for family 15, the Trinity codename. For example, you can have family 15 support on Lenovo G505 and S.
And for example, on this Asus board, and family 16H, which was codename CABINI, and some of the main boards also supported, like those S-Rock IMB-A180.
This open source fashion maintained until 214, where AMD introduced closed source AG sublobes. Yes, and the community was not happy about this, but there is, I think, a rationale behind that, because with the introduction of the binary pile,
which is a name for the closed source AG subbinaries, AMD introduced integrated FCH, so first SOCs appeared. And of course, the first appearances of PSP also occurred. So they had to close certain things
and just do not reveal interact to our property, et cetera. Yes, and binary pile is supported since family 15, processor models, like I have listed here. Yeah, I will not elaborate on these numbers. These are taken from CPU IDs, yeah?
So when you have a CPU ID, the most unique byte was family number, and later there was the processor model, so it emerged from that. Currently, no AGISA, the old AGISA source I have mentioned till now is not maintained by AMD.
They just left the support of those. Yes, and yeah, as it is a closed source blob, it causes a lot of problems, like for these blobs, there is a broken suspend resume support, or we have issues with temporary memory teardown. For some blobs, it was fixed,
but in close cooperation with giant corporations like Google, for example, there is a Stonerage SoC, which is a family 15 and processor models from 17,
and they got a license to fix that and release a fixed blob for the temporary memory teardown. And yeah, as I have listed here, the products you can find with those are now Chromebooks, the Stonerage.
There are a few ACES or HP Chromebooks you can find out there. Still available to buy, like some recent releases were in the beginning of 2019, I think, and yeah, the most popular product to me
is PC-Inch APU2. It's very simple router platform, shown here, which is family 16H, these processors models, and it has quite some awesome features I would like to also mention.
If you have been attending the talk about range boot, for example, it describes the 2D RTM implementation on AMD and Intel processors. So the prototype of the RTM support was developed on this platform, yeah?
Also, Eurot project is very highly depending on validation on this platform. So Ronmini also prototypes many new features also on this platform. And yeah, PC-Engine has very long story with core boot,
it must be said. Their products, yeah, they're over 10 or 15 years in this open source, and core boot is the only firmware they run on their platform, so it's very respectful. Now it came to the future and the present. Currently, there is a work in progress development
on AGISA v9. It is another closed source implementation, but with more restrictive license, because it is aimed to support only Chromebooks for now, and there seem to be some mainboards, just freshly announced, but currently,
there is no mainboard in core boot yet. And it is aimed to support the family 17, which is Ryzen, Zen, et cetera, these new AMD processors. And yeah, this development is proceeding quite slowly, because the way AMD changed the boot flow
is quite surprising. How many of you know the X86 boot process? Okay, so typically, BIOS is responsible for DRAM initialization, okay? So AMD just broke this rule and said,
said, no, let's let PSP do the DRAM initialization. So now, when CPU comes out of reset, it has already DRAM initialized and MMORPG working, yeah? So it needs a quite significant amount of effort to adapt the core boot build system to support that.
Yeah, if you want to like to hear more details about how the AGISA was integrated, I just can, yeah, I refer to this presentation of Kerry Brown's talk from ISFC 219.
He was talking about the AGISA integration to core boot using Intel FSP 2.0. What it is about? It basically describes how they adapted the FSP interface,
Intel FSP interface to AGISA. And there is a link with some incoming products on Chromebooks, but to me, the current status is unknown, unfortunately. Yeah, a little bit more about the future.
Currently, many, many boards that had some AMD CPUs were being dropped due to new release increments that core boot project put on the code. So yeah, AMD platforms lacked support for many years
due to AMD left the support of the AGISA. There was very little developers that could even maintain some platforms. So the only hope is in PC Engine's company and other like these companies that just support open-source firmware effort.
We were recently struggling to cover as much as possible chipsets to maintain the support. And for example, we fulfilled the recent requirements about C boot block and postcard stage.
You can refer to core boot documentation, what it is about, I will not describe it, no. So the development I took with Kosti Malki in the fall last year, we sit for two months and was just pushing patches constantly every day
just to clean up the code and make those boards still available in the main tree. And there's still much cleanup work to do. Like there is all the AMD code base were mostly copy paste at work. So there is very much of dirty code,
like some MP tables, IRQ tables are mostly copied for example, two or three families in a row. And yeah, the ACPI code is also poor. So it requires some effort to develop some fancy features.
And yeah, for now the AMD platforms can move on thanks to my and Kosti's effort. But it is unknown when these platforms will face a wall which cannot be overcome. Like we have to face closed source blocks for certain platforms and yeah, it makes the work even harder.
Besides the AGISA, there were few native ports also. Like these boards I have listed here. Unfortunately, they were dropped from tree despite they were fully open source. They had no blobs. There were only natively ported by Corbu developers.
Why they have been dropped? First of all, they have been left unmaintained. Some of their port authors just switched to different architectures like for example, this board KGP was created
by Raptor engineering, but currently they are switched to PowerPC and they don't feel like adding more efforts to bring this board back to master branch. Secondly, it will require significant amount of money to bring the port back
because of lack of attention for the past few years. And there's many, many requirements that Corbu put since that time and there's a lot of work to do. Thirdly, there were many bugs left which has been unfixed after the initial ports.
So it is also required to address that because there were many complaints recently on some Linux crashes, for example, on these boards. And yeah, this is a shame where such a library hardware is dropped from the tree, but there is a hope.
3MDAP applied for a funding to bring back those native ports. And why would it even bother with this? First of all, as I said, it's a library hardware. Secondly, for example, the KGP board has IOMMU
and has DRTM capabilities. And in contrary of Intel TXT implementation, the AMD DRTM can be fully open source. So we can have a SRTM, DRTM fully open source on such platforms.
And the future we see for IMD platforms is as follows. 3MDAP, of course, is planning to improve the AMD support through the cooperation and help from PC Engine's company. Possibly, we would like to bring back the other native ports like the ASUS KC-DMA
or the Super Micro. Of course, if there will be a much common effort with the KDP. I think the support for Ryzen CPUs is rather far in the future
because there's a lot of work still to land in the current repository. And this is proceeding slowly because most of the documentation on the family 17H is not public. So it is hard to gain some expertise to review the patches. Only those who have some NDA with AMD
are able to help with the development. And yeah, when it comes to some server platforms for this newest AMD, it is also unlikely. Like I said, it will target mostly Chromebooks in the nearest future, but in the far future, maybe.
These are some references to presentations I have based on. So you can also have a look at these to have some insights about the history of Perbutevo. The development on AMD. And some of the presentation was also based on my own experience.
No questions? Oh, please. Yeah. So, my lab was trying to talk about the Intel NEDC.
But I mean, kind of like the way they did it was they stripped up many NED modules and modules. I think that I see NED modules that would help me with the ability of the CPU to kind of just try to like distribute them.
So the question was whether the PSP can be stripped down like Intel ME. So recently, some patches landed that removed certain blobs for a PSP. Like for example, we left some bootloader only, which is required for CPU bring up,
but removed the PSP OS, for example, recently. It was about in September or October last year. But for the newest ones, I think it will be pretty hard. So there is not much documentation on the newest PSP and I'm not in this newest PSP topic that deep,
but I can say that it will be pretty hard to strip it down. Any other questions? Okay, thank you.