coreboot July 2016

coreboot@coreboot.org

47 participants
135 discussions

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 15 Jul '16

15 Jul '16

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 2 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1357676: Control flow issues (NO_EFFECT) /src/lib/tpm2_tlcl.c: 30 in tpm_process_command() ________________________________________________________________________________________________________ *** CID 1357676: Control flow issues (NO_EFFECT) /src/lib/tpm2_tlcl.c: 30 in tpm_process_command() 24 size_t out_size, in_size; 25 /* Command/response buffer. */ 26 static uint8_t cr_buffer[TPM_BUFFER_SIZE]; 27 28 out_size = tpm_marshal_command(command, command_body, 29 cr_buffer, sizeof(cr_buffer)); >>> CID 1357676: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "out_size < 0UL". 30 if (out_size < 0) { 31 printk(BIOS_ERR, "command %#x, cr size %zd\n", 32 command, out_size); 33 return NULL; 34 } 35 ** CID 1357675: Integer handling issues (NEGATIVE_RETURNS) /src/lib/tpm2_tlcl.c: 28 in tpm_process_command() ________________________________________________________________________________________________________ *** CID 1357675: Integer handling issues (NEGATIVE_RETURNS) /src/lib/tpm2_tlcl.c: 28 in tpm_process_command() 22 static void *tpm_process_command(TPM_CC command, void *command_body) 23 { 24 size_t out_size, in_size; 25 /* Command/response buffer. */ 26 static uint8_t cr_buffer[TPM_BUFFER_SIZE]; 27 >>> CID 1357675: Integer handling issues (NEGATIVE_RETURNS) >>> Assigning: unsigned variable "out_size" = "tpm_marshal_command". 28 out_size = tpm_marshal_command(command, command_body, 29 cr_buffer, sizeof(cr_buffer)); 30 if (out_size < 0) { 31 printk(BIOS_ERR, "command %#x, cr size %zd\n", 32 command, out_size); 33 return NULL; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/coreboot?tab=overview To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://scan.coverity.com/subscriptions/edit?email=coreboot%40coreboot.org&…

1 0

Re: [coreboot] TXE and Descriptor bin management in Coreboot
by Zoran Stojsavljevic 15 Jul '16

15 Jul '16

Hello Brett, Having overall experience with INTEL, I should say that the Truth is a bit more complicated. ;-) In the simplified view, there are two points when bringing any INTEL CPU from reset, i should say. The first is: HW strap conditions, and these need to be set appropriately, depending upon what the HW config will be. This point I mentioned since I am not sure if XDP port only depends upon TXE, I do not really know with certainty for BYT, but I do know for some other families HW straps also need to be set properly for XDP to be enabled. Maybe there are two requirements for XDP to be enabled, so I am really not sure about this, this is why I am writing this email. So, the question I have here is: does BYT have to have one of the HW straps properly set (maybe it is already set by default design) for XDP to be enabled? The another point why TXE HW/FW engine is mainly used is the following: TXE Firmware, the Trusted eXecution Engine, provide features to prevent BIOS tampering, however information about TXE is considered Intel Confidential and require that you have CNDA account. Usually, FSP + Coreboot (as you have mention already), is built on the top of normal BIOS (last 2M, maybe these days 3M, since FSP and Coreboot are growing) , since normal BIOS includes SW straps (second point), which are also set by default (in BIOS). In this scenario, FIT (formerly FITC) tool is not required (if satisfied with default SW straps, which 99% developers are). Here is INTEL site where there are overall set of BYT documents, but many of them are locked (as well as 514482): [image: Inline image 1] http://www.intel.com/content/www/us/en/embedded/products/bay-trail/software… Hope this helps also, Zoran On Thu, Jul 14, 2016 at 9:51 PM, Testerman, Brett (US COM) < Brett.Testerman(a)cobham.com> wrote: > Mayuri, > > > > Your best bet with all of this is to contact Intel and get a privileged > access account. If that is not possible or practical then you need to do > some reverse engineering. > > > > First of all, go get this document from Intel’s web site: > > > > 514482_ByTti_SoC_SPIFlashProgGuide_Rev1p0.pdf > > > > I don’t have a specific link to it but I know it is publically accessible. > Search on the leading 6 digit number or “SPI Flash Programming Guide”. This > document fully describes the descriptor tables and how to use them. The > FITC tool is the preferred way but you can bit-bang them with the info > provided in that doc. > > > > As for the TXE you will need to get that from Intel – it is not publically > available. But I can say if you are running on the E3800 family (Bay Trail) > then you don’t need it. The chip will boot without it but the XDP port will > be locked out. You can also use the information from the programming guide > to locate a TXE image in a 3rd party boot image and extract it out of > that. I think that is what the idftool does. > > > > The coreboot image will need to be located at the very end of flash > because that is where the hardware reset vector is. The nice thing about > that is once you have set up the descriptors you don’t have to > rebuild/reprogram the entire flash image every time. For example, if your > coreboot image is only 1MB in size then you only need to reprogram the last > 1 megabyte of flash and leave the rest alone. Saves a ton of time. > > > > There has been a lot of talk about this issue on Intel’s embedded > communities forums. Check out this thread: > > https://embedded.communities.intel.com/thread/12354 > > > > Hope this helps! > > > > Brett > > > > > > > > *From:* coreboot [mailto:coreboot-bounces@coreboot.org] *On Behalf Of *Stefan > Reinauer > *Sent:* Wednesday, July 13, 2016 4:30 PM > *To:* Mayuri Tendulkar > *Cc:* Martin Roth; coreboot > *Subject:* Re: [coreboot] TXE and Descriptor bin management in Coreboot > > > > *** Please note that the Sender of this email is from outside the Cobham > NA IT Hub ** * > > * Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com> [160714 00:50]: > > Ok, so do we need to ask Intel if we use Intel baytrail processor? How > we can create this descriptor.bin? > > Please have a look at util/ifdtool and util/ifdfake for our tools > dealing with Intel Firmware Descriptors. The most comprehensive way of > producing the information you need is by using Intel's fitc tool, > however. > > If you are willing to put some development effort into this, we could > use help, merging ifdtool and ifdfake, as well as incorporating more > fitc like capabilities into the tool. > > Stefan > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Query to release the code for new board
by Martin Roth 15 Jul '16

15 Jul '16

Hi Mayuri, coreboot does not share the TXE or descriptor.bin files for the boards. In the instructions from Intel for the BayleyBay CRB, it tells you to build coreboot as a 3MB rom file and to flash that to the top of the ROM chip, so as to not overwrite the TXE & Descriptor on the board. That said, since you own a Minnowboard Turbot, you can get the full UEFI rom file and extract the descriptor & TXE files from there using ifdtool -x. See the build script for the Minnowboard Max: https://review.coreboot.org/gitweb/cgit/board-status.git/tree/intel/minnowm… Martin On Thu, Jul 14, 2016 at 1:23 PM, Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com> wrote: > Hi Team > > > > I would like to know how process of releasing code for new board works in > coreboot community? > > > > For example, when BayleyBay CRB or Minnowboard Max was release, is it only > code changes released, mainly related to Mainboard. > > > > How TXE and Descriptor.bin for these openly available boards are shared with > community? > > > > Regards > > Mayuri > > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or used > for any purpose other than for what it is intended. If you have received > this message in error, please notify the originator immediately. If you are > not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of this > message. Aricent accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including damage from > virus." > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] TXE and Descriptor bin management in Coreboot
by Stefan Reinauer 14 Jul '16

14 Jul '16

* Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com> [160714 00:50]: > Ok, so do we need to ask Intel if we use Intel baytrail processor? How we can create this descriptor.bin? Please have a look at util/ifdtool and util/ifdfake for our tools dealing with Intel Firmware Descriptors. The most comprehensive way of producing the information you need is by using Intel's fitc tool, however. If you are willing to put some development effort into this, we could use help, merging ifdtool and ifdfake, as well as incorporating more fitc like capabilities into the tool. Stefan

2 1

Query to release the code for new board
by Mayuri Tendulkar 14 Jul '16

14 Jul '16

Hi Team I would like to know how process of releasing code for new board works in coreboot community? For example, when BayleyBay CRB or Minnowboard Max was release, is it only code changes released, mainly related to Mainboard. How TXE and Descriptor.bin for these openly available boards are shared with community? Regards Mayuri "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

1 0

Re: [coreboot] TXE and Descriptor bin management in Coreboot
by Mayuri Tendulkar 14 Jul '16

14 Jul '16

Ok, so do we need to ask Intel if we use Intel baytrail processor? How we can create this descriptor.bin? What we observed is if we use descriptor.bin, and not TXE, still system boots up fine. Need to understand the impact of not having TXE. But if we don't use descriptor, it seems system is booting based on current, but display doesn't come up. -----Original Message----- From: Martin Roth [mailto:gaumless@gmail.com] Sent: 13 July 2016 15:36 To: Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com> Cc: coreboot <coreboot(a)coreboot.org> Subject: Re: [coreboot] TXE and Descriptor bin management in Coreboot Hi Mayuri, The descriptor.bin file is relatively specific to each board. This sets the soft-straps, gives information about the ROM chip being used on that particular board, and sets the sizes of the areas on the SPI ROM. As for the TXE/ME/SPS/xxx binary, this would be specific to the CPU/SOC family at the very least. Some chips will work with an ME read off of a different board that has the same chip. As I recall, others chips have specific settings encoded in this binary as well as in the descriptor. This might just be for Xeon class chips, or it might be more widespread at this point Martin On Wed, Jul 13, 2016 at 4:05 PM, Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com> wrote: > Hi Team > > > > I would like to know how we can handle TXE and descriptor bin in Coreboot? > > > > Is there any generic file for Intel processors which can be used > rather than any proprietary bin files? > > > > Regards > > Mayuri > > "DISCLAIMER: This message is proprietary to Aricent and is intended > solely for the use of the individual to whom it is addressed. It may > contain privileged or confidential information and should not be > circulated or used for any purpose other than for what it is intended. > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, you are > notified that you are strictly prohibited from using, copying, > altering, or disclosing the contents of this message. Aricent accepts > no responsibility for loss or damage arising from the use of the > information transmitted by this email including damage from virus." > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

1 0

Re: [coreboot] TXE and Descriptor bin management in Coreboot
by Martin Roth 14 Jul '16

14 Jul '16

Hi Mayuri, The descriptor.bin file is relatively specific to each board. This sets the soft-straps, gives information about the ROM chip being used on that particular board, and sets the sizes of the areas on the SPI ROM. As for the TXE/ME/SPS/xxx binary, this would be specific to the CPU/SOC family at the very least. Some chips will work with an ME read off of a different board that has the same chip. As I recall, others chips have specific settings encoded in this binary as well as in the descriptor. This might just be for Xeon class chips, or it might be more widespread at this point Martin On Wed, Jul 13, 2016 at 4:05 PM, Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com> wrote: > Hi Team > > > > I would like to know how we can handle TXE and descriptor bin in Coreboot? > > > > Is there any generic file for Intel processors which can be used rather than > any proprietary bin files? > > > > Regards > > Mayuri > > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or used > for any purpose other than for what it is intended. If you have received > this message in error, please notify the originator immediately. If you are > not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of this > message. Aricent accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including damage from > virus." > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

TXE and Descriptor bin management in Coreboot
by Mayuri Tendulkar 14 Jul '16

14 Jul '16

Hi Team I would like to know how we can handle TXE and descriptor bin in Coreboot? Is there any generic file for Intel processors which can be used rather than any proprietary bin files? Regards Mayuri "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

1 0

A word on releases
by Stefan Reinauer 13 Jul '16

13 Jul '16

Hi people, we have had a great first year with regular coreboot releases. Exactly 12 months ago, we released coreboot 4.1, the first release after the 4.0 release in 2011 and our "classic" branch in 2014. Since then we have had 4 successful releases, both Patrick and Martin went through the release process, and with this process we were able to move two corporations working with coreboot (Intel and Google) significantly closer to working with upstream coreboot. However, releases take a lot of time, and we were not able to tighten the release process with each release, as we had originally hoped, and so, after I talked with Patrick and Martin, we have decided to move to a slightly slower paced release cycle, creating only two releases per year. In turn, we will try to improve the overall quality of the releases in the future. This switch will mean, that the coreboot 4.5 release will happen in fall 2016, rather than this month. I have written up a few questions that I came across, and some answers to them. If you are using coreboot releases, I would like to hear from you, so that we can continue to improve the release process and tune it towards its users, while we spend the majority of the time on making coreboot better. We're continually improving the release process and raising the quality bar and look for developers interested in helping on that topic. Questions and comments, flames and praise are, as always, welcome! Stefan FAQ --- 1. What kind of releases do we do? The coreboot project is now creating a new release every six months. Before this cycle, we created a new release every quarter, but every second release has basically been unused. 2. Why do we need releases at all? Lots of people work "offline". You check out a given revision of coreboot, and do your work. When you are done, you will have to fix up your patch to still work with the now latest revision, before you can submit it to the upstream tree. Depending on how complex your problem is, or how busy you are with other stuff, a lot of time can pass between the start and the finish line. Releases are a simple mechanism to make sure everybody is on the same page. A way of documenting what has changed between the start of your effort and it's availability to the community. 3. Isn't this just psychological? In the past we have seen groups of people working together on a coreboot port to a new platform, with slightly different trees, being 1 or 2 weeks apart. This can cause all kinds of funny effects, that take away from the efficiency of the development process, and that, lacking up to date documentation, every engineer has to go through again. With over 100 people contributing over 3000 patches per year to our code base, these little changes sum up to a significant amount. 4. Who are these releases for? If you are a developer that wants to put coreboot on your board at home, you probably don't care much, yet, because chances are, we didn't even test your board before making the release. If you are setting up an internal coreboot tree for your fellow coworkers to colaborate with you, and you can't work on coreboot.org directly, please use the latest released version to base your work off, rather than top of tree. This will make it much easier to support your work. 5. What about testing releases? Right now, we are hand testing releases on a few selected machines before every release by boot testing on a given setup. We try to cover as much diversity as we can (e.g. Intel, AMD, ARM, ARM64). However, this part of the release process is less formalized as the coreboot project lacks a large scale test system setup at the moment. Mostly, what the release manager for a release has available at the time is what will be tested. 6. What's with that dropped board thing? Short story: It's not really worth bringing forward all boards all the time, so we're trying to find a reasonable cut-off line. Long story: Coreboot is a fast moving project with a lot (a whole lot) of boards, and even more features. In the very early days (1999 - 2003), most boards wouldn't compile or work shortly after they've been merged, unless someone went ahead and fixed it. When we added abuild to the development process, that didn't happen anymore and so we attempted to move all boards forward to the latest feature set all of the time. Since coreboot itself has no user interface and barely any attack surface, there are barely good reasons to update your firmware very often, especially if work on your board has generally stopped. On the same hand, a lot of design decisions made 10 or 15 years ago can only be overcome with significant effort that is not justified for obsolete hardware. In order to keep the code healthy and clean, we are retiring old boards in release branches. For example, if a board was removed right after the release of 4.4, you can still check out the "4.4" branch and build your board with that branch. If the board is broken on that branch, you can check in fixes to the branch to get it working again. There is no hard cut-off line, but typically boards that have been in the tree for more than 10 years will be retired at some point. 7. What (else) happens before a release? - Stabilization of the tree, review and check-in of critical fixes - Boot testing on a handful boards - Creation of a change log and release notes. This will contain some useful metrics about the last release, including the amount of new code integrated, old code removed, new contributors in the project, significant high level changes, and what needs to be done to unmerged ports to be adapted to these changes. - A new branch is cut, named after the release (e.g. "4.4"). This branch can be used to push critical fixes for a given release, albeit this has not happened very often in the past (Thanks to Patrick Rudolph and Nico Huber for being an exception) - A new tag is created, named after the release (e.g. "4.4") - Announcements on the blog 8. Why don't we have monthly releases? Our release process, while, as Patrick called it, follows a "minimum viable" approach, the testing, reviews and documentation are a lot of manual work going into each release. At this point, it is a fair assumption that it is a 1 week (40+h) effort to create a new release, for someone who has done a coreboot release before. We would like to keep the project overhead (and the frustrations that come with that) adequately low. As right there are only a handful of entities relying on coreboot releases right now, a bi-annual release cycle seems reasonable. 9. What about board status? The board status script (and the attached web page https://www.coreboot.org/Supported_Motherboards ) is currently the best method to determine when a board was last tested and working, other than getting in touch with the original developer. Unfortunately there is currenlty no real documentation about the process, and reports rely on community members willing to test new versions on their boards. 10. Long term plans The longer term plan is to provide infrastructure that will allow the coreboot project to have 100% of the boards tested regularly (e.g. on every commit, but at the minimum for every release). As we gather more metrics for the quality of releases, we will keep increasing the bar for each release.

1 0

Re: [coreboot] ARM Trusted Firmware build issue
by Paul Kocialkowski 13 Jul '16

13 Jul '16

Le mercredi 13 juillet 2016 à 12:47 -0600, Martin Roth a écrit : > Ok, I tested updating the code from '.align x,0' to '.align x'. This > updates the padding from 0x00 to nop instructions, and does work with > GAS 2.26. > > I've submitted a pull request for the arm-trusted-firmware repo: > https://github.com/ARM-software/arm-trusted-firmware/pull/664 The discussion about the bug on the ATF github tracker seemed to indicate that ARM was not willing to solve things this way: https://github.com/ARM-software/tf-issues/issues/401 (I should have mentioned it the email too, instead of just in the GAS bug report, in case you missed it.) I hope your pull request will be enough leverage to make them accept this solution! > Martin > > On Wed, Jul 13, 2016 at 9:14 AM, Paul Kocialkowski <contact(a)paulk.fr> wrote: > > Hi, > > > > Le mercredi 13 juillet 2016 à 08:57 -0600, Martin Roth a écrit : > > > Thanks for posting about this. I've spent some time looking into > > > this as well, but in my usual fashion, I didn't communicate what I > > > found in a responsible fashion. Here's what I posted in a code > > > review: > > > > Looks like I didn't search long enough to find this ;) > > > > > > The current binutils (2.26) is failing to build the current arm-trusted- > > > > firmware. > > > > This wasn't caught because the jenkins builders haven't been updated to > > > > the > > > > latest build tools. I tested the new release of binutils (2.26.1) and > > > > the > > > > update > > > > didn't help my build. There's a patch that should fix the issue - See > > > > this > > > > thread for an explanation of the issue and the patch: > > > > > > > > https://www.mail-archive.com/linaro-toolchain%40lists.linaro.org/msg0568 > > > > 5.ht > > > > ml > > > > > > > > Unfortunately, a different change went into 2.26.1 at that location, so > > > > this > > > > patch > > > > doesn't directly apply. > > > > > > For some reason, I didn't directly test that patch with 2.26 to see if > > > it actually worked - I tried adding it in to 2.26.1, which did not > > > help. I'll test it with 2.26 today, and add the patch into the > > > toolchain build if it works. > > > > From what I understood, that patch only allows the build to work when > > removing > > the extra 0 to .align (so using ".align x" instead of ".align x, 0"). And it > > was > > indeed crafted for an older GAS version. For 2.26, it doesn't apply either > > and a > > similar fix was already included, so the workaround above does work. > > > > But again, we can't easily patch ATF… > > > > > We can't roll the entire toolchain back to binutils 2.25 because of > > > the RISC-V work. > > > > Indeed. > > > > > Is it reasonable to roll back to binutils 2.25 for just the ARM toolchain > > > builds? > > > > Someone should definitely try that, I have no idea whether it's a good idea > > off- > > hand. If anyone does, please speak up :) > > > > I'm running out of time these days, but if nobody else does it, I'll > > probably > > have a go at it this week-end. > > > > > And then I need to update the toolchains on the builders and figure > > > out how to keep them up-to-date so this doesn't happen again. > > > > That would be nice! > > > > > Sorry I didn't post this directly to the mailing list earlier. > > > > No problem, it was fun to dig into it. Also, since the affected devices are > > not > > public, I guess it doesn't really bother anyone. I just happened to look at > > it > > when submitting a crossgcc change, which comes out as unstable because of > > this > > issue, but that's about it. > > > > Cheers, > > > > Paul > > > > > On Wed, Jul 13, 2016 at 2:35 AM, Paul Kocialkowski <contact(a)paulk.fr> > > > wrote: > > > > We spent some time yesterday evening on IRC investigating why the ARM > > > > Trusted > > > > Firmware (ATF) doesn't build with the current toolchain from coreboot's > > > > crossgcc. > > > > > > > > It turns out it is a complex issue on the assembler's side. I have > > > > opened a > > > > bug > > > > upstream about it, with all the details we could find: > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=20364 > > > > > > > > This regression was introduced with binutils 2.26. To get the build > > > > going in > > > > the > > > > short term, we could either downgrade binutils back to 2.25 (if it still > > > > meets > > > > all dependencies from other tools) or patch ATF to replace the ".align > > > > x, 0" > > > > directives to ".align x" in include/common/asm_macros.S (not sure this > > > > is a > > > > possibility). > > > > > > > > Cheers, > > > > > > > > -- Paul Kocialkowski, developer of low-level free software for embedded > > > > devices > > > > > > > > Website: https://www.paulk.fr/ > > > > Coding blog: https://code.paulk.fr/ > > > > Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/ > > > > -- > > > > coreboot mailing list: coreboot(a)coreboot.org > > > > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

← Newer
1
...
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2016