News from the coreboot land
Menzel, Paul
What happened in the coreboot based firmware world since last year? How to get started? In September, coreboot 4.10 will have been released, and the Open Source Firmware Conference took place. Take this opportunity to present the latest news and changes in the coreboot based firmware world. AMD devices are available with coreboot, and after Google and Puri.sm more vendors like System76 ship their devices with coreboot. While at it, give a quick introduction how to get started.
 Welcome to the talk news from the Corbett land. At this year's all system go. First question, who of you uses Corbett already? Okay. That's, I think we're three hands, so not four. So it could be more people. So those of you who have been in the talk before, that was like heaven because the speaker said on this STM device, if you set a pin, reset a jumper, then the boot lock is disabled and all your code is executed and you have the full control of the device. And this proprietary firmware and today's devices, this is very hard for consumer devices. And yeah, that's why I think Corbett is quite important. Just a few words to myself. Yeah, I studied math here in Berlin and I like free software and I'm active in Corbett since 2005. But yeah, I'm mainly a user but also support the community a little bit. All right. So what happened? A long time ago in July this year, the commit which you see there was tagged as release for dot time. And yeah, it was actually like two months late. I'd say the Corbett project tries to release, do a release every six months. But it's just like a checkpoint in the commit history. It doesn't give any guarantees, let's say. Of course, some things are tested beforehand but it's just a commit which is named with a number. Some stats. So there are actually quite a lot of authors, commit authors, like almost 200. There were a lot of changes and yeah, also quite a lot of new contributors. Yeah, 11,000 lines of course, codes were added and 5,000 lines of comments. Because of the time I just will be touching some small topics and the first one is the C environment boot block. There was an old way to build a Corbett for devices and that was related to how the older processors were laid out. That there were not a lot of second level cache, for example, and level one cache. And that GCC also was not able to build the boot block. And that's why in the early 2000, Eric Biederman wrote a separate compiler for Corbett which built the boot block in the beginning. And then people said okay, with new processors and GCC evolved, we actually want to use GCC because ROM and CCC had several disadvantages. Some constructs were not supported and GCC is much more well tested of course. And so Alexandru Ganyuk, he started to change the environment by allowing the boot block to run a C environment where the boot block gets built with the rest with GCC. So that's a modern way to boot. And so it's a big task to convert the current boards maybe to this new method. And for example, for ARM which came to Corbett much later as a support, that was already possible. So that's mainly a big task for x86. So yeah, just it won't be as technical as in the talk before, but you just see some, that you know where to look if you're interested. So there's this more or less assembler thing, code which sets up the device in the beginning so it can run in the boot block. So it jumps to boot block pre-C entry after it sets up the processor this way. Then these include files and for example, for QEMU where it's not a hard problem to set up RAM, it then calls boot block C entry. So as I said, several boards were converted and these were mainly interships. And yeah, that's so much. And that's a big task now because I will come to it later. It's a hard requirement for the future. Regarding what there were a lot of new boards also added, Google does a lot of Chromebook developments and releases new versions for this, of course, but there's also now a quite current server board supported. I think this is Haswell. The SuperMicro X10 SLM plus F and also because it's kind of similar after this, oh sorry, after the 410 release, the SuperMicro X11 was released, which is a Kavillik server board. So of course, it's now again a hard decision because AMD released Epic and so on. So nobody wants Intel anymore, but you don't get call boot with Epic. So as always, it's a complicated world. Yeah, for System on Chips, AMD Picasso was added, which is going to be used in Chromebooks and also an ARM Qualcomm processor. And I just wanted to go into AMD a little bit as with the inter-management engine. They also have a platform security processor, which is an auxiliary processor. I think it's an ARM chip. And yeah, it's actually quite powerful and before the actual processor is taken out of Reset, it does a lot of things. And I think it's been there for like seven or eight years. But now it also happens that for future AMD systems, this platform security processor will for example also initialize the memory, which is kind of a new thing. It has a little bit to do with how AMD probably positions itself in the future also with ARM devices and so on, so that they take the devices more part. But that also is quite new. So that the RAM initialization is not run on the main processor. So that's kind of new. And that also gives some, the core project now also has to think about how to adapt to this because you don't run, you don't start from flash, but you start from DRAM for example. So some components have to be adapted. And yeah, and that's also quite of hard. I mean, I come to this in the block section later, but RAM initialization is quite complex. So it's on the one hand only the vendor more or less knows how to do it, but on the other hand also to fix bugs and so on. In the spirit of free software, actually the core project actually wants to have also the code for how to initialize the RAM. So yeah, it's a new problem because now we more or less would also need to somehow write the firmware for the PSP, but of course it's signed and so on. Yeah, so that's for that. We will see how it works. But I come to this later. There were also some devices removed because certain requirements which we set for boards or standards were not met. And that's a GO LX. I think it's now 15 years old or so. It was an old AMD processor which actually had its own kind architecture, but I think it could emulate x86. So it was quite interesting and it was also supported by Coboot and quite popular in routers and embedded boards. One example is the PC engines, Alex boards, which were used for routers, for example. This year we had three Google Summer of Code projects. So thank you, Google, for that. So a lot of co-varity. So Coboot is integrated in co-varity and the static analyzer from some US university or so, it's our company. And they, yeah, so one project tried to fix all these co-varity bugs. Then the QEMU ARM64 support to create that was one project. And the GITRA is a program from the NSA, I think, which is kind of like IDA Pro, this assembler project, and one student worked on adding support first for Coboot images, of course, but it's on the one hand not so interesting because we have a lot of source for that, but also to add a little bit support that you can load UEFI images, I think, and then be able more or less to reverse engineer this. So the next release for 11 is planned for October, but as I said, the only reason important stuff is more or less just the tech and afterwards a certain criteria or dedication which were announced at least six months earlier are applied. So these are the new criterias. As I said, all boards have to support the environment boot block and the car global migration, and so car is cash as run and the variable builds which are stored in there needs to be moved to the next stages. So you can, for example, use timestamps which you measure in the ROM stage can also be moved or seen in the ROM stage and later on you can read them out. So maybe I forgot to say, for example, for C environment boot block this of course gives a little bit, gives a lot of advantages. For example, all this stuff which Google does with verified boot, they have their own verified boot implementation VBoot too and so they measure certain, they make hash sums of certain parts and to verify that this stuff hasn't been altered. And this is, for example, just possible for C environment boot block and so all boards which support this would automatically profit from the other infrastructure. So that's quite nice but the downside is, for example, the current server board which is also already seven, eight years old but which is the most powerful x86 boards currently available in core boot without any blobs. Besides microcode, that's the ASUS KGP D16 and this in the current situation will be dropped. So also what happened there is now more or less an established conference for firmware development. It's the open source firmware conference and it took place this year in California at the Google and Facebook campus near San Francisco and San Jose, so Sunny Valley I think, or Sunny Vale. And last year it happened in Bonn so it was in Europe and then hope next year it will be again in Europe. And yeah, it's quite established now because for the Deppin Visa, Zauleen, his nickname, from nine elements he is quite communicative and motivated and he gets a lot of projects together and so that's quite cool to have also like officer projects come together and to talk about road maps and goals and for example core boot, Linux boot, Tyana core, open BMC, U boot, PT boot which is a boot program for power PCs and for example the firmware update project was also there which is Richard Hughes which on current laptops or devices lets you update your UFI firmware with the UEFI capsule technique just from the Linux user space which is a cool thing. They were all there and they cooperate now. And the talks were recorded but not published yet so I'm looking forward to them because I wasn't able to go to the ES. Yeah, on the main list it was announced that for this server board if people are interested to keep support that the community can raise funds and the three-ambit company which is in Poland would be willing to maintain this port. So some ongoing work which is happening, there's a new media tech chip which is also something to look for because they get more powerful and get even more viable alternatives for x86 which is always good to have. Then some person started to work on a core boot port for power PC 64 which currently uses host boot, gboot and PT boot and these are currently used for example of course on servers but they are also now workstation boards from Raptor engineering. The tailors and blackbird you might have heard of it so it's a desktop workstation board which you can get and currently on power also you heard that the ISA is now put under free license and the power foundation, open power foundation is now part of the Linux foundation so it's actually quite open now and also good alternative and hopefully it would put some pressure on the x86 people. Risk 5 is still also supported, some people work on this so they are quite disappointed that there is also now a system management mode in risk 5 and the integration of the AMD PSP processor is quite a challenge. So with binary blobs let's say I come to it later. The result of the open firmware conference is that now people also work on the FW and firmware update utility integration. This is not directly related to core boot but to firmware in general KX is now able to boot Microsoft Windows. There is a G-sum of code project which is very nice. It is clearly Linux and they work on booting quickly. They got a kernel now and on the Linux Plumbers conference they talked about 300 milliseconds kernel execution time which is nice to have. Of course they also need a fast firmware because even if your Linux system boots in one second and your firmware on my Dell boots in 10 seconds then that's not good. So I hope that there will get a lot of stuff upstream and all people will profit from it and there is also now a firmware project which is called ORBOOT which is firmware implementation and Rust and they have a goal that they don't allow any binary blobs. So to the end I want to talk about some ongoing issues like blobs. So it causes a lot of hassle and actually work which actually would be better to put into working code instead of thinking about glue codes or wonder why this blob doesn't do as what you expect. And so there is a lot of time kind of wasted I think. A lot of stuff gets a little bit better because now the binaries which are published are better documented and the ABI is not broken that often and so on. But it also causes some licensing issues. So if the platform initialization code binary calls back into core boot is it a violation, is it not? So current status it's not but it's issues you actually don't want to deal with. So we will see how this will develop. Yeah, there is, for example, early on AMD they contributed documentation for Epic and so on. The BIOS kernel developer guides they have not been published to my knowledge are not as complete so you cannot actually implement a free firmware. Changes of course are hard to review if you don't have the documentation and you cannot write code. And then of course there is normal community issues that are in all other projects also also the problems which you have in the Linux kernel. Like a lot of developers are not employed in companies and work on new products and they often cannot share that they work on the new products because of NDA they cannot release it. And so they implement something and then when they are allowed to push it upstream the community has a lot of sometimes a lot of complaints and want to something to be rewritten. So a lot of often we would like to have these company developers engage with the public community more often and write to the mailing list for example to discuss certain architectural decisions. But that's also sometimes the same with Linux drivers. So yeah I'm at the end just as a quick note because today was a climate strike and so on and also Leonard's talk with the home directory and the problems with suspend to run. I advocate again I don't like suspend to run if firmware would be possible if your system would cold boot in like one second nobody would need to suspend to run and you would find other solutions to preserve the state you wouldn't have to worry about what is in the in the run and you would use the normal mechanisms you would reduce complexity. Yeah and the cold boot is always still needed like on this laptop with the P store mechanism where you can store crash dumps and you if I very able for example if I just found out that it was enabled and then it was all these variables was written and I was wondering why my system now the firmware took 25 seconds instead of 10 seconds to boot and it was because all these variables were there and then is a buck in the del firmware that it reads all these variables without any need. Okay so that's the end thank you for your attention and if you have any questions go ahead. You mentioned the boot on arm systems a bit can you expand a little bit on what sort of devices you've been targeting has it been single board computers has been servers there's really nothing in the middle. I think both so mainly the Chromebooks which are like laptop devices so embedded stuff but I think there was this KVM thing. Thunder X2 or Thunder X1? I think two. But there were some problems with KVM because of the arm trusted firmware releases and they didn't maintain it so I think they removed the board now but there was support and I think Facebook even sponsored the nine elements company to do the support but you can come afterwards and I can look it up. Do you know why support for the Alex board was removed? Because nobody worked on I need to look up which special requirement was there but it was I think also had to do with car migration so you actually couldn't see the timestamps from the boot block and I have to look it up what requirement it was but nobody maintained it. But that's of course also a valid question I mean the firmware still worked right and you can still check it out and build it but of course you don't have all the new features but at certain point I think it's a valid question if there are no maintainers if you can remove these boards and you can of course still boot the old firmware right. But sorry I don't know the specific reason I can look up the comment and tell you. Okay thank you Paul. Thank you.
 Welcome to the talk news from the Corbett land.  At this year's all system go.  First question, who of you uses Corbett already?  Okay.  That's, I think we're three hands, so not four.  So it could be more people.  So those of you who have been in the talk before, that was like heaven because the speaker  said on this STM device, if you set a pin, reset a jumper, then the boot lock is disabled  and all your code is executed and you have the full control of the device.  And this proprietary firmware and today's devices, this is very hard for consumer devices.  And yeah, that's why I think Corbett is quite important.  Just a few words to myself.  Yeah, I studied math here in Berlin and I like free software and I'm active in Corbett  since 2005.  But yeah, I'm mainly a user but also support the community a little bit.  All right.  So what happened?  A long time ago in July this year, the commit which you see there was tagged as release  for dot time.  And yeah, it was actually like two months late.  I'd say the Corbett project tries to release, do a release every six months.  But it's just like a checkpoint in the commit history.  It doesn't give any guarantees, let's say.  Of course, some things are tested beforehand but it's just a commit which is named with  a number.  Some stats.  So there are actually quite a lot of authors, commit authors, like almost 200.  There were a lot of changes and yeah, also quite a lot of new contributors.  Yeah, 11,000 lines of course, codes were added and 5,000 lines of comments.  Because of the time I just will be touching some small topics and the first one is the  C environment boot block.  There was an old way to build a Corbett for devices and that was related to how the older  processors were laid out.  That there were not a lot of second level cache, for example, and level one cache.  And that GCC also was not able to build the boot block.  And that's why in the early 2000, Eric Biederman wrote a separate compiler for Corbett which  built the boot block in the beginning.  And then people said okay, with new processors and GCC evolved, we actually want to use GCC  because ROM and CCC had several disadvantages.  Some constructs were not supported and GCC is much more well tested of course.  And so Alexandru Ganyuk, he started to change the environment by allowing the boot block  to run a C environment where the boot block gets built with the rest with GCC.  So that's a modern way to boot.  And so it's a big task to convert the current boards maybe to this new method.  And for example, for ARM which came to Corbett much later as a support, that was already  possible.  So that's mainly a big task for x86.  So yeah, just it won't be as technical as in the talk before, but you just see some,  that you know where to look if you're interested.  So there's this more or less assembler thing, code which sets up the device in the beginning  so it can run in the boot block.  So it jumps to boot block pre-C entry after it sets up the processor this way.  Then these include files and for example, for QEMU where it's not a hard problem to  set up RAM, it then calls boot block C entry.  So as I said, several boards were converted and these were mainly interships.  And yeah, that's so much.  And that's a big task now because I will come to it later.  It's a hard requirement for the future.  Regarding what there were a lot of new boards also added, Google does a lot of Chromebook  developments and releases new versions for this, of course, but there's also now a quite  current server board supported.  I think this is Haswell.  The SuperMicro X10 SLM plus F and also because it's kind of similar after this, oh sorry,  after the 410 release, the SuperMicro X11 was released, which is a Kavillik server board.  So of course, it's now again a hard decision because AMD released Epic and so on.  So nobody wants Intel anymore, but you don't get call boot with Epic.  So as always, it's a complicated world.  Yeah, for System on Chips, AMD Picasso was added, which is going to be used in Chromebooks  and also an ARM Qualcomm processor.  And I just wanted to go into AMD a little bit as with the inter-management engine.  They also have a platform security processor, which is an auxiliary processor.  I think it's an ARM chip.  And yeah, it's actually quite powerful and before the actual processor is taken out of  Reset, it does a lot of things.  And I think it's been there for like seven or eight years.  But now it also happens that for future AMD systems, this platform security processor  will for example also initialize the memory, which is kind of a new thing.  It has a little bit to do with how AMD probably positions itself in the future also with ARM  devices and so on, so that they take the devices more part.  But that also is quite new.  So that the RAM initialization is not run on the main processor.  So that's kind of new.  And that also gives some, the core project now also has to think about how to adapt to  this because you don't run, you don't start from flash, but you start from DRAM for example.  So some components have to be adapted.  And yeah, and that's also quite of hard.  I mean, I come to this in the block section later, but RAM initialization is quite complex.  So it's on the one hand only the vendor more or less knows how to do it, but on the other  hand also to fix bugs and so on.  In the spirit of free software, actually the core project actually wants to have also the  code for how to initialize the RAM.  So yeah, it's a new problem because now we more or less would also need to somehow write  the firmware for the PSP, but of course it's signed and so on.  Yeah, so that's for that.  We will see how it works.  But I come to this later.  There were also some devices removed because certain requirements which we set for boards  or standards were not met.  And that's a GO LX.  I think it's now 15 years old or so.  It was an old AMD processor which actually had its own kind architecture, but I think  it could emulate x86.  So it was quite interesting and it was also supported by Coboot and quite popular in routers  and embedded boards.  One example is the PC engines, Alex boards, which were used for routers, for example.  This year we had three Google Summer of Code projects.  So thank you, Google, for that.  So a lot of co-varity.  So Coboot is integrated in co-varity and the static analyzer from some US university or  so, it's our company.  And they, yeah, so one project tried to fix all these co-varity bugs.  Then the QEMU ARM64 support to create that was one project.  And the GITRA is a program from the NSA, I think, which is kind of like IDA Pro, this  assembler project, and one student worked on adding support first for Coboot images, of  course, but it's on the one hand not so interesting because we have a lot of source for that,  but also to add a little bit support that you can load UEFI images, I think, and then  be able more or less to reverse engineer this.  So the next release for 11 is planned for October, but as I said, the only reason important  stuff is more or less just the tech and afterwards a certain criteria or dedication which were  announced at least six months earlier are applied.  So these are the new criterias.  As I said, all boards have to support the environment boot block and the car global migration,  and so car is cash as run and the variable builds which are stored in there needs to  be moved to the next stages.  So you can, for example, use timestamps which you measure in the ROM stage can also be moved  or seen in the ROM stage and later on you can read them out.  So maybe I forgot to say, for example, for C environment boot block this of course gives  a little bit, gives a lot of advantages.  For example, all this stuff which Google does with verified boot, they have their own verified  boot implementation VBoot too and so they measure certain, they make hash sums of certain  parts and to verify that this stuff hasn't been altered.  And this is, for example, just possible for C environment boot block and so all boards  which support this would automatically profit from the other infrastructure.  So that's quite nice but the downside is, for example, the current server board which  is also already seven, eight years old but which is the most powerful x86 boards currently  available in core boot without any blobs.  Besides microcode, that's the ASUS KGP D16 and this in the current situation will be  dropped.  So also what happened there is now more or less an established conference for firmware  development.  It's the open source firmware conference and it took place this year in California at the  Google and Facebook campus near San Francisco and San Jose, so Sunny Valley I think, or Sunny  Vale.  And last year it happened in Bonn so it was in Europe and then hope next year it will be  again in Europe.  And yeah, it's quite established now because for the Deppin Visa, Zauleen, his nickname,  from nine elements he is quite communicative and motivated and he gets a lot of projects  together and so that's quite cool to have also like officer projects come together and  to talk about road maps and goals and for example core boot, Linux boot, Tyana core,  open BMC, U boot, PT boot which is a boot program for power PCs and for example the  firmware update project was also there which is Richard Hughes which on current laptops  or devices lets you update your UFI firmware with the UEFI capsule technique just from  the Linux user space which is a cool thing.  They were all there and they cooperate now.  And the talks were recorded but not published yet so I'm looking forward to them because  I wasn't able to go to the ES.  Yeah, on the main list it was announced that for this server board if people are interested  to keep support that the community can raise funds and the three-ambit company which is  in Poland would be willing to maintain this port.  So some ongoing work which is happening, there's a new media tech chip which is also something  to look for because they get more powerful and get even more viable alternatives for  x86 which is always good to have.  Then some person started to work on a core boot port for power PC 64 which currently  uses host boot, gboot and PT boot and these are currently used for example of course on  servers but they are also now workstation boards from Raptor engineering.  The tailors and blackbird you might have heard of it so it's a desktop workstation board  which you can get and currently on power also you heard that the ISA is now put under free  license and the power foundation, open power foundation is now part of the Linux foundation  so it's actually quite open now and also good alternative and hopefully it would put some  pressure on the x86 people.  Risk 5 is still also supported, some people work on this so they are quite disappointed  that there is also now a system management mode in risk 5 and the integration of the  AMD PSP processor is quite a challenge.  So with binary blobs let's say I come to it later.  The result of the open firmware conference is that now people also work on the FW and  firmware update utility integration.  This is not directly related to core boot but to firmware in general KX is now able to  boot Microsoft Windows.  There is a G-sum of code project which is very nice.  It is clearly Linux and they work on booting quickly.  They got a kernel now and on the Linux Plumbers conference they talked about 300 milliseconds  kernel execution time which is nice to have.  Of course they also need a fast firmware because even if your Linux system boots in  one second and your firmware on my Dell boots in 10 seconds then that's not good.  So I hope that there will get a lot of stuff upstream and all people will profit from it  and there is also now a firmware project which is called ORBOOT which is firmware implementation  and Rust and they have a goal that they don't allow any binary blobs.  So to the end I want to talk about some ongoing issues like blobs.  So it causes a lot of hassle and actually work which actually would be better to put  into working code instead of thinking about glue codes or wonder why this blob doesn't  do as what you expect.  And so there is a lot of time kind of wasted I think.  A lot of stuff gets a little bit better because now the binaries which are published are better  documented and the ABI is not broken that often and so on.  But it also causes some licensing issues.  So if the platform initialization code binary calls back into core boot is it a violation,  is it not?  So current status it's not but it's issues you actually don't want to deal with.  So we will see how this will develop.  Yeah, there is, for example, early on AMD they contributed documentation for Epic and  so on.  The BIOS kernel developer guides they have not been published to my knowledge are not  as complete so you cannot actually implement a free firmware.  Changes of course are hard to review if you don't have the documentation and you cannot  write code.  And then of course there is normal community issues that are in all other projects also  also the problems which you have in the Linux kernel.  Like a lot of developers are not employed in companies and work on new products and  they often cannot share that they work on the new products because of NDA they cannot  release it.  And so they implement something and then when they are allowed to push it upstream the community  has a lot of sometimes a lot of complaints and want to something to be rewritten.  So a lot of often we would like to have these company developers engage with the public  community more often and write to the mailing list for example to discuss certain architectural  decisions.  But that's also sometimes the same with Linux drivers.  So yeah I'm at the end just as a quick note because today was a climate strike and so  on and also Leonard's talk with the home directory and the problems with suspend to run.  I advocate again I don't like suspend to run if firmware would be possible if your system  would cold boot in like one second nobody would need to suspend to run and you would  find other solutions to preserve the state you wouldn't have to worry about what is in  the in the run and you would use the normal mechanisms you would reduce complexity.  Yeah and the cold boot is always still needed like on this laptop with the P store mechanism  where you can store crash dumps and you if I very able for example if I just found out  that it was enabled and then it was all these variables was written and I was wondering  why my system now the firmware took 25 seconds instead of 10 seconds to boot and it was because  all these variables were there and then is a buck in the del firmware that it reads all  these variables without any need.  Okay so that's the end thank you for your attention and if you have any questions go  ahead.  You mentioned the boot on arm systems a bit can you expand a little bit on what sort of  devices you've been targeting has it been single board computers has been servers there's  really nothing in the middle.  I think both so mainly the Chromebooks which are like laptop devices so embedded stuff  but I think there was this KVM thing.  Thunder X2 or Thunder X1?  I think two.  But there were some problems with KVM because of the arm trusted firmware releases and they  didn't maintain it so I think they removed the board now but there was support and I  think Facebook even sponsored the nine elements company to do the support but you can come  afterwards and I can look it up.  Do you know why support for the Alex board was removed?  Because nobody worked on I need to look up which special requirement was there but it  was I think also had to do with car migration so you actually couldn't see the timestamps  from the boot block and I have to look it up what requirement it was but nobody maintained  it.  But that's of course also a valid question I mean the firmware still worked right and  you can still check it out and build it but of course you don't have all the new features  but at certain point I think it's a valid question if there are no maintainers if you  can remove these boards and you can of course still boot the old firmware right.  But sorry I don't know the specific reason I can look up the comment and tell you.  Okay thank you Paul.  Thank you.
News_from_the_coreboot_land_4HeIkcrEWkc_0_131.png News_from_the_coreboot_land_4HeIkcrEWkc_132_203.png News_from_the_coreboot_land_4HeIkcrEWkc_204_659.png News_from_the_coreboot_land_4HeIkcrEWkc_660_767.png News_from_the_coreboot_land_4HeIkcrEWkc_768_1151.png News_from_the_coreboot_land_4HeIkcrEWkc_1152_1535.png News_from_the_coreboot_land_4HeIkcrEWkc_1536_1967.png News_from_the_coreboot_land_4HeIkcrEWkc_1968_2303.png News_from_the_coreboot_land_4HeIkcrEWkc_2304_2687.png News_from_the_coreboot_land_4HeIkcrEWkc_2688_3071.png News_from_the_coreboot_land_4HeIkcrEWkc_3072_3683.png News_from_the_coreboot_land_4HeIkcrEWkc_3684_6791.png News_from_the_coreboot_land_4HeIkcrEWkc_6792_7679.png News_from_the_coreboot_land_4HeIkcrEWkc_7680_7739.png News_from_the_coreboot_land_4HeIkcrEWkc_7740_8063.png News_from_the_coreboot_land_4HeIkcrEWkc_8064_8507.png News_from_the_coreboot_land_4HeIkcrEWkc_8508_10379.png News_from_the_coreboot_land_4HeIkcrEWkc_10380_14939.png News_from_the_coreboot_land_4HeIkcrEWkc_14940_17207.png News_from_the_coreboot_land_4HeIkcrEWkc_17208_20099.png News_from_the_coreboot_land_4HeIkcrEWkc_20100_23087.png News_from_the_coreboot_land_4HeIkcrEWkc_23088_23663.png News_from_the_coreboot_land_4HeIkcrEWkc_23664_26003.png News_from_the_coreboot_land_4HeIkcrEWkc_26004_26051.png News_from_the_coreboot_land_4HeIkcrEWkc_26052_26099.png News_from_the_coreboot_land_4HeIkcrEWkc_26100_26351.png News_from_the_coreboot_land_4HeIkcrEWkc_26352_27899.png News_from_the_coreboot_land_4HeIkcrEWkc_27900_29591.png News_from_the_coreboot_land_4HeIkcrEWkc_29592_30299.png News_from_the_coreboot_land_4HeIkcrEWkc_30300_31823.png News_from_the_coreboot_land_4HeIkcrEWkc_31824_33407.png News_from_the_coreboot_land_4HeIkcrEWkc_33408_36623.png News_from_the_coreboot_land_4HeIkcrEWkc_36624_36995.png News_from_the_coreboot_land_4HeIkcrEWkc_36996_37145.png
Welcome to the talk news from the Corbett land. At this year's all system go. First question, who of you uses Corbett already? Okay. That's, I think we're three hands, so not four. So it could be more people. So those of you who have been in the talk before, that was like heaven because the speaker said on this STM device, if you set a pin, reset a jumper, then the boot lock is disabled and all your code is executed and you have the full control of the device. And this proprietary firmware and today's devices, this is very hard for consumer devices. And yeah, that's why I think Corbett is quite important. Just a few words to myself. Yeah, I studied math here in Berlin and I like free software and I'm active in Corbett since 2005. But yeah, I'm mainly a user but also support the community a little bit. All right. So what happened? A long time ago in July this year, the commit which you see there was tagged as release for dot time. And yeah, it was actually like two months late. I'd say the Corbett project tries to release, do a release every six months. But it's just like a checkpoint in the commit history. It doesn't give any guarantees, let's say. Of course, some things are tested beforehand but it's just a commit which is named with a number. Some stats. So there are actually quite a lot of authors, commit authors, like almost 200. There were a lot of changes and yeah, also quite a lot of new contributors. Yeah, 11,000 lines of course, codes were added and 5,000 lines of comments. Because of the time I just will be touching some small topics and the first one is the C environment boot block. There was an old way to build a Corbett for devices and that was related to how the older processors were laid out. That there were not a lot of second level cache, for example, and level one cache. And that GCC also was not able to build the boot block. And that's why in the early 2000, Eric Biederman wrote a separate compiler for Corbett which built the boot block in the beginning. And then people said okay, with new processors and GCC evolved, we actually want to use GCC because ROM and CCC had several disadvantages. Some constructs were not supported and GCC is much more well tested of course. And so Alexandru Ganyuk, he started to change the environment by allowing the boot block to run a C environment where the boot block gets built with the rest with GCC. So that's a modern way to boot. And so it's a big task to convert the current boards maybe to this new method. And for example, for ARM which came to Corbett much later as a support, that was already possible. So that's mainly a big task for x86. So yeah, just it won't be as technical as in the talk before, but you just see some, that you know where to look if you're interested. So there's this more or less assembler thing, code which sets up the device in the beginning so it can run in the boot block. So it jumps to boot block pre-C entry after it sets up the processor this way. Then these include files and for example, for QEMU where it's not a hard problem to set up RAM, it then calls boot block C entry. So as I said, several boards were converted and these were mainly interships. And yeah, that's so much. And that's a big task now because I will come to it later. It's a hard requirement for the future. Regarding what there were a lot of new boards also added, Google does a lot of Chromebook developments and releases new versions for this, of course, but there's also now a quite current server board supported. I think this is Haswell. The SuperMicro X10 SLM plus F and also because it's kind of similar after this, oh sorry, after the 410 release, the SuperMicro X11 was released, which is a Kavillik server board. So of course, it's now again a hard decision because AMD released Epic and so on. So nobody wants Intel anymore, but you don't get call boot with Epic. So as always, it's a complicated world. Yeah, for System on Chips, AMD Picasso was added, which is going to be used in Chromebooks and also an ARM Qualcomm processor. And I just wanted to go into AMD a little bit as with the inter-management engine. They also have a platform security processor, which is an auxiliary processor. I think it's an ARM chip. And yeah, it's actually quite powerful and before the actual processor is taken out of Reset, it does a lot of things. And I think it's been there for like seven or eight years. But now it also happens that for future AMD systems, this platform security processor will for example also initialize the memory, which is kind of a new thing. It has a little bit to do with how AMD probably positions itself in the future also with ARM devices and so on, so that they take the devices more part. But that also is quite new. So that the RAM initialization is not run on the main processor. So that's kind of new. And that also gives some, the core project now also has to think about how to adapt to this because you don't run, you don't start from flash, but you start from DRAM for example. So some components have to be adapted. And yeah, and that's also quite of hard. I mean, I come to this in the block section later, but RAM initialization is quite complex. So it's on the one hand only the vendor more or less knows how to do it, but on the other hand also to fix bugs and so on. In the spirit of free software, actually the core project actually wants to have also the code for how to initialize the RAM. So yeah, it's a new problem because now we more or less would also need to somehow write the firmware for the PSP, but of course it's signed and so on. Yeah, so that's for that. We will see how it works. But I come to this later. There were also some devices removed because certain requirements which we set for boards or standards were not met. And that's a GO LX. I think it's now 15 years old or so. It was an old AMD processor which actually had its own kind architecture, but I think it could emulate x86. So it was quite interesting and it was also supported by Coboot and quite popular in routers and embedded boards. One example is the PC engines, Alex boards, which were used for routers, for example. This year we had three Google Summer of Code projects. So thank you, Google, for that. So a lot of co-varity. So Coboot is integrated in co-varity and the static analyzer from some US university or so, it's our company. And they, yeah, so one project tried to fix all these co-varity bugs. Then the QEMU ARM64 support to create that was one project. And the GITRA is a program from the NSA, I think, which is kind of like IDA Pro, this assembler project, and one student worked on adding support first for Coboot images, of course, but it's on the one hand not so interesting because we have a lot of source for that, but also to add a little bit support that you can load UEFI images, I think, and then be able more or less to reverse engineer this. So the next release for 11 is planned for October, but as I said, the only reason important stuff is more or less just the tech and afterwards a certain criteria or dedication which were announced at least six months earlier are applied. So these are the new criterias. As I said, all boards have to support the environment boot block and the car global migration, and so car is cash as run and the variable builds which are stored in there needs to be moved to the next stages. So you can, for example, use timestamps which you measure in the ROM stage can also be moved or seen in the ROM stage and later on you can read them out. So maybe I forgot to say, for example, for C environment boot block this of course gives a little bit, gives a lot of advantages. For example, all this stuff which Google does with verified boot, they have their own verified boot implementation VBoot too and so they measure certain, they make hash sums of certain parts and to verify that this stuff hasn't been altered. And this is, for example, just possible for C environment boot block and so all boards which support this would automatically profit from the other infrastructure. So that's quite nice but the downside is, for example, the current server board which is also already seven, eight years old but which is the most powerful x86 boards currently available in core boot without any blobs. Besides microcode, that's the ASUS KGP D16 and this in the current situation will be dropped. So also what happened there is now more or less an established conference for firmware development. It's the open source firmware conference and it took place this year in California at the Google and Facebook campus near San Francisco and San Jose, so Sunny Valley I think, or Sunny Vale. And last year it happened in Bonn so it was in Europe and then hope next year it will be again in Europe. And yeah, it's quite established now because for the Deppin Visa, Zauleen, his nickname, from nine elements he is quite communicative and motivated and he gets a lot of projects together and so that's quite cool to have also like officer projects come together and to talk about road maps and goals and for example core boot, Linux boot, Tyana core, open BMC, U boot, PT boot which is a boot program for power PCs and for example the firmware update project was also there which is Richard Hughes which on current laptops or devices lets you update your UFI firmware with the UEFI capsule technique just from the Linux user space which is a cool thing. They were all there and they cooperate now. And the talks were recorded but not published yet so I'm looking forward to them because I wasn't able to go to the ES. Yeah, on the main list it was announced that for this server board if people are interested to keep support that the community can raise funds and the three-ambit company which is in Poland would be willing to maintain this port. So some ongoing work which is happening, there's a new media tech chip which is also something to look for because they get more powerful and get even more viable alternatives for x86 which is always good to have. Then some person started to work on a core boot port for power PC 64 which currently uses host boot, gboot and PT boot and these are currently used for example of course on servers but they are also now workstation boards from Raptor engineering. The tailors and blackbird you might have heard of it so it's a desktop workstation board which you can get and currently on power also you heard that the ISA is now put under free license and the power foundation, open power foundation is now part of the Linux foundation so it's actually quite open now and also good alternative and hopefully it would put some pressure on the x86 people. Risk 5 is still also supported, some people work on this so they are quite disappointed that there is also now a system management mode in risk 5 and the integration of the AMD PSP processor is quite a challenge. So with binary blobs let's say I come to it later. The result of the open firmware conference is that now people also work on the FW and firmware update utility integration. This is not directly related to core boot but to firmware in general KX is now able to boot Microsoft Windows. There is a G-sum of code project which is very nice. It is clearly Linux and they work on booting quickly. They got a kernel now and on the Linux Plumbers conference they talked about 300 milliseconds kernel execution time which is nice to have. Of course they also need a fast firmware because even if your Linux system boots in one second and your firmware on my Dell boots in 10 seconds then that's not good. So I hope that there will get a lot of stuff upstream and all people will profit from it and there is also now a firmware project which is called ORBOOT which is firmware implementation and Rust and they have a goal that they don't allow any binary blobs. So to the end I want to talk about some ongoing issues like blobs. So it causes a lot of hassle and actually work which actually would be better to put into working code instead of thinking about glue codes or wonder why this blob doesn't do as what you expect. And so there is a lot of time kind of wasted I think. A lot of stuff gets a little bit better because now the binaries which are published are better documented and the ABI is not broken that often and so on. But it also causes some licensing issues. So if the platform initialization code binary calls back into core boot is it a violation, is it not? So current status it's not but it's issues you actually don't want to deal with. So we will see how this will develop. Yeah, there is, for example, early on AMD they contributed documentation for Epic and so on. The BIOS kernel developer guides they have not been published to my knowledge are not as complete so you cannot actually implement a free firmware. Changes of course are hard to review if you don't have the documentation and you cannot write code. And then of course there is normal community issues that are in all other projects also also the problems which you have in the Linux kernel. Like a lot of developers are not employed in companies and work on new products and they often cannot share that they work on the new products because of NDA they cannot release it. And so they implement something and then when they are allowed to push it upstream the community has a lot of sometimes a lot of complaints and want to something to be rewritten. So a lot of often we would like to have these company developers engage with the public community more often and write to the mailing list for example to discuss certain architectural decisions. But that's also sometimes the same with Linux drivers. So yeah I'm at the end just as a quick note because today was a climate strike and so on and also Leonard's talk with the home directory and the problems with suspend to run. I advocate again I don't like suspend to run if firmware would be possible if your system would cold boot in like one second nobody would need to suspend to run and you would find other solutions to preserve the state you wouldn't have to worry about what is in the in the run and you would use the normal mechanisms you would reduce complexity. Yeah and the cold boot is always still needed like on this laptop with the P store mechanism where you can store crash dumps and you if I very able for example if I just found out that it was enabled and then it was all these variables was written and I was wondering why my system now the firmware took 25 seconds instead of 10 seconds to boot and it was because all these variables were there and then is a buck in the del firmware that it reads all these variables without any need. Okay so that's the end thank you for your attention and if you have any questions go ahead. You mentioned the boot on arm systems a bit can you expand a little bit on what sort of devices you've been targeting has it been single board computers has been servers there's really nothing in the middle. I think both so mainly the Chromebooks which are like laptop devices so embedded stuff but I think there was this KVM thing. Thunder X2 or Thunder X1? I think two. But there were some problems with KVM because of the arm trusted firmware releases and they didn't maintain it so I think they removed the board now but there was support and I think Facebook even sponsored the nine elements company to do the support but you can come afterwards and I can look it up. Do you know why support for the Alex board was removed? Because nobody worked on I need to look up which special requirement was there but it was I think also had to do with car migration so you actually couldn't see the timestamps from the boot block and I have to look it up what requirement it was but nobody maintained it. But that's of course also a valid question I mean the firmware still worked right and you can still check it out and build it but of course you don't have all the new features but at certain point I think it's a valid question if there are no maintainers if you can remove these boards and you can of course still boot the old firmware right. But sorry I don't know the specific reason I can look up the comment and tell you. Okay thank you Paul. Thank you.
be more people. So those of you who have been in in the commit history. It doesn't give any just will be touching some small topics and the after this, oh sorry, after the 410 release, the decision because AMD released Epic and so on. So think about how to adapt to this because you Google does with verified boot, they have their firmware conference and it took place this year I think, or Sunny Vale. And last year it happened I'm at the end just as a quick note because today like laptop devices so embedded stuff but I think