[coreboot] New on blogs.coreboot.org: Announcing coreboot 4.6
A new post titled "Announcing coreboot 4.6" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2017/05/08/announcing-coreboot-4-6/ We are happy to announce the April 2017 release of coreboot, version 4.6. The 4.6 release covers commit e74f5eaa to commit db508565 Since the last release in October 2016, the coreboot project had 1708 commits by 121 authors. The release tarballs and gpg signatures are available in the usual place at https://www.coreboot.org/downloads There is a pgp signed 4.6 tag in the git repository, and a branch will be created as needed. Changes: Past, ongoing, and future CBMEM console development and the Linux Kernel Our cbmem debug console was updated with some nice features. The cbmem console now persists between reboots and is able to be used on some platforms via late init. Also there is a new Linux kernel driver which removes the need for the old cbmem tool to read from the cbmem area. You can find the patch here https://patchwork.kernel.org/patch/9641997/ and it can be enabled via GOOGLE_MEMCONSOLE_COREBOOT kconfig option in your kernel – Note that this name may change going forward. Critical bugs in TPM 1.2 support coreboot currently has issues with the TPM 1.2 LPC driver implementation. This leads to a misbehavior in SeaBIOS where the TPM gets temporarily deactivated. We plan to publish the bugfix release 4.6.1 when we have these issues sorted out. Native graphics and ram init improvements The native graphics was reworked a while ago and should finally support Windows. Numerous bug fixes and EDID support is also now available. Finally, the native ram initialization for sandybridge/ivybridge platforms got patched and supports more RAM modules. New and fresh payloads SeaBIOS, FiLO, and iPXE were all recently updated to the latest versions. Https downloads are the default for all payloads now. We provide the libpayload project which is used for writing own payloads from scratch. The library is MOSTLY licensed under BSD and recently received new functionality in order to prepare for the upcoming replacement for the old nvramcui payload. This new payload is called cbui and is based on the nuklear graphics library including keyboard and mouse support. The cbui payload is currently expected to be merged into the main coreboot tree before the next release. The upstream repository is here: https://github.com/siro20/coreboot/tree/cbui/payloads/cbui UEFI support: A long road to go coreboot can be used with the Tianocore EDK2 UEFI implementation which is open source and available at Github. Sadly it is not currently integrated into the coreboot build. This has several reasons: EDK2 only supports GCC 4.8 profile. coreboot is now running on GCC 6.3.0. Incompatibilities with code inside the EDK2 which has not been updated. We started to make progress with the integration into our sources and the hope is that by the end of the summer, we finally support the EDK2 payload out-of-the-box. See the current patch state at http://review.coreboot.org/#/c/15057/ Fighting blobs and proprietary HW components coreboot’s ultimate goal would be to replace any closed source firmware stack with free software components. Unfortunately this is not always possible due to signed binaries such as the Intel ME firmware, the AMD PSP and microcode. Recently, a way was discovered to let the Intel ME run in a functional error state and reduce it from 1.5/5MB to 80KB. It’s not perfect but it works from Nehalem up to Skylake based Intel systems. The tool is now integrated into the coreboot build system. The upstream repository is https://github.com/corna/me_cleaner Another ongoing improvement is the new utility blobtool. It is currently used for generating the flash descriptor and GbE configuration data on older mainboard which are known to be free software. It can easily be extended for different binaries with well-defined specifications. Did you say Ada? coreboot now supports Ada, and a lot work was done integrating Ada into our toolchain. At the moment only the support for formal verification is missing and will be soon added. At that point, we can prove the absence of runtime errors in our Ada code. In short, everybody can start developing Ada code for our project. The existing Ada code which can be used from now on is another native graphics initialization which will replace in the long term the current implementation. The native graphics code supports all Intel platforms up to skylake. We offer support for HDMI, VGA, DVI and DP external interfaces as well and is ready to be integrated into our mainboard implementations. Toolchain updates A new coreboot toolchain is out. The major toolchain change was going from GCC version 5.3.0 to 6.3.0. There were also minor version updates to GMP, MPFR, Binutils, GDB, IASL, and Clang. Deprecation policy for boards Starting with this release there will be a policy for deprecating unmaintained boards. See the end of this announcement
[coreboot] New on blogs.coreboot.org: Results of the coreboot "Mailing List vs Blog" poll
A new post titled "Results of the coreboot "Mailing List vs Blog" poll" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2017/03/04/results-of-the-coreboot-mailing-list-vs-blog-poll/ A little while back, there were a few requests to switch from the mailing list format to a web-based forum for our official communication channel. The coreboot leadership wanted to see what the actual preferences of the coreboot community was, so I posted a poll. The poll was publicized in IRC and on the mailing list itself, so should have been communicated to the people who would be most directly affected by any change. Poll results Here are the overall results from all responses: All_responses We had a total of 60 valid responses, and I think the overall results pretty clearly indicate that the coreboot project should NOT move away from the mailing list. One suggestion was to split the communication into the mailing list for Developers, and a forum for non-developers. To see what the various groups thought, I made a few more charts: Developer preferences: Developer Responses So not unexpectedly, the coreboot developers even more overwhelmingly prefer the mailing list to the general results Non-developer preferences: Non-developer Responses So even within the non-developer group, there was a definite preference for the mailing list format. Finally, I broke the Non-developer group down into the group that said they were coreboot users, as opposed to those that mainly read the mailing list. coreboot users (non-developers): coreboot Users (Non-Developers) That group had the highest percentage of people who preferred the forum, but it was still well under 40%. Suggestions We also asked people what we should do to improve the mailing list. Here’s a summary of the suggestions: Show people how to set up their (or a different) email client to make reading the mailing list easier. Have people be more polite. Add a FAQ showing previously asked question and answers. A netiquette should be established like on the Linux kernel mailing list. Several suggestions to improve the coreboot mailing list archive at https://www.coreboot.org/pipermail/coreboot/ Fix the archive so that long threads aren’t spread into different sections by months. Add a search function to the archive Create monthly archives that can be downloaded (This exists.) Update from Pipermail to a more modern archiver like Hyperkitty – https://pypi.python.org/pypi/HyperKitty Since it doesn’t look like we’re going to switch to a forum, I’m not going to list the suggestions that people had for that. Follow-up Over the upcoming weeks, we’ll look at our options, and discuss our options and plans in the bi-weekly coreboot community meetings. -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: coreboot is joining the Software Freedom Conservancy
A new post titled "coreboot is joining the Software Freedom Conservancy" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2017/02/22/coreboot-is-joining-the-software-freedom-conservancy/ The coreboot project applied to join the Software Freedom Conservancy and has been approved for membership by their board. There is still some work to be done in hammering out the governance details, but we hope to have everything completed by April. Joining the SFC as coreboot’s fiscal sponsor will allow us to go forward with fundraising, and that all donations to the coreboot project from the United States will be tax-deductible. Up to this point, coreboot hasn’t had any official way to accept donations or payments. This has meant that the project was mainly supported financially by members of the coreboot leadership, which has put some limitations on what we were able to do. Another of the things that joining the SFC means is that we will be formalizing and fully documenting the coreboot leadership structure. This is one of the Conservancy’s requirements, and something that they will help the project with. The Conservancy offers a number of other services to its members. We encourage everyone to take a look at the SFC, and to consider joining as individual supporters. -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: Announcing coreboot 4.5
A new post titled "Announcing coreboot 4.5" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/10/21/announcing-coreboot-4-5/ We are happy to announce the release of coreboot 4.5 The 4.5 release covers commit 80a3df260767 to commit 0bc12abc2b26. This release is the first since the project switched from doing quarterly releases to doing biannual releases. The next release will be in April of 2017. Since the last release in April, the coreboot project has had 1889 commits by 119 authors. The release tarballs and gpg signatures are available in the usual place at https://www.coreboot.org/releases/ There is a 4.5 tag in the git repository, and a branch will be created as needed. Areas with significant updates: Toolchain (29 commits) Updated mpfr version from 3.1.3 to 3.1.4 Updated gcc version from 5.2.0 to 5.3.0 Updated binutils version from 2.25 to 2.26.1 & Fix aarch64 build problem Updated gdb version from 7.9.1 to 7.11 Updated iasl version from 20160318 to 20160831 Updated python version from 3.4.3 to 3.5.1 Updated expat version from 2.1.0 to 2.1.1 Updated llvm / clang version from 3.7.1 to 3.8.0 Updated make version from 4.1 to 4.2.1 Build system (32 commits) Updates for cbfstool / fmap changes Order per-region files to optimize placement success Add support for the ADA language and toolchain. Utilities (103 commits) Lint – Update checkpatch.pl, add tools to find non-ascii & unprintable chars and to verify a single newline at the end of files cbfstool – Update for Linux payloads, Honor FSP modules addresses, fix elf parsing Sconfig – Add 10 bit addressing mode for i2c devices, add generic device type, support strings, pass in devicetree filename General code cleanup (197 commits) Cleaning up code formatting and whitespace Fix spelling & capitalization Removing commented out code Transition away from device_t TPM (55 commits) Add support for Trusted Platform Module 2.0 SPI & refactored I2C TPM driver Drivers (54 commits) Add ACPI support in several drivers coreboot_tables – Extend serial port description Elog – refactor, add debug info I2C – add generic driver, SPI – Add new chip support, major refactoring, don’t assume SPI flash boot device Lib (33 commits) Add real-time-clock functions Add RW boot device construct reg_script updates: add to bootblock, add xor support, add display support Timestamp fixes & updates Vendorcode AMD (14 commits) – Cleanup, add libagesa.a builds, remove unused code. Google (22 commits) – VBoot2 updates and cleanup Intel (86 commits) – Add Intel FSP 2.0, update Broadwell DE support Payloads (37 commits) Subpayload support got extend and is enabled by default. nvramcui: refactor, update build SeaBIOS: Update stable version to 1.9.3, add bootorder file iPXE: Update stable version to the last commit of July 2016 Fix broken linux boot sequence Mainboard changes Added 13 mainboards, plus a few mainboard variants not included here: ADI RCC-DFF networking board (adi/rcc-dff) – intel/rangeley SoC AMD Evaluation Board DB-FT3B-LC (amd/db-ft3b-lc) – amd/00730F01 (Family 16h Models 30h-3Fh (Mullins)) CPU AMD f2950 / TONK 1201/2 Board (amd/f2950) – amd/geode_lx CPU Apple iMAC 5.2 (apple/imac52) – intel/i945 CPU Unibap Development Kit ODE E21XX – amd/00730F01 (Family 16h Models 30h-3Fh (Mullins)) CPU elmex/pcm205400 – amd/Family_14 CPU elmex/pcm205401 – amd/Family_14 CPU Lenovo N21 chromebook (google/enguarde) – intel/baytrail SoC google/gale – Qualcomm IPQ40XX SoC AOpen Chromebox (google/ninja) – intel/baytrail SoC google/reef – intel/apollolake SoC Acer Chromebox CXI2 (google/rikku) – intel/Broadwell SoC google/rotor – marvell/MVMAP2315 SoC Removed 5 mainboards: These were all development boards not available to the public. google/bolt – intel/haswell – removed in commit 139314b google/rush – nvidia/tegra132 – removed in commit e67cd9e google/rush_ryu – nvidia/tegra132 – removed in commit 0c63415 google/slippy – intel/haswell – removed in commit bc24b85 intel/amenia – intel/apollolake – removed in commit c2586db Existing boards with significant updates asus/kgpe-d16 – amd/socket_G34 – Add TPM support, enable secondary serial port emulation/spike-riscv: RISC-V -clean up, use generic bootblock, look for CBFS in RAM, reimplement SBI google/gru – rockchip/RK3399 SoC (76 commits) – Board bringup google/oak – mediatek/mt8173 SoC- Add Elm variant, update memory, configure display, initialize touchscreen gpio intel/galilleo- intel/quark SoC (14 commits) – Board bringup, add galileo gen1 support, switch to FSP2.0 intel/minnowmax – intel/fsp_baytrail SoC – Enable all PCIe ports, Program GPIO for power LED lenovo/x60 – intel/socket_mPGA478 – init GPIOs before dock check, add hda verb table siemens/mc_bdx1 – intel/fsp_broadwell_de SoC – Add external RTC, Set up MAC addresses, Update IRQs siemens/mc_tcu3 – intel/fsp_baytrail SoC – cleanup & LCD panel updates Changes in chips Moved 3
[coreboot] New on blogs.coreboot.org: [GSoC] Multiple status registers, block protection and OTP support, wrap-up (1/2)
A new post titled "[GSoC] Multiple status registers, block protection and OTP support, wrap-up (1/2)" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/08/26/gsoc-sr-wp-otp-wrap-up-12/ Hello! GSoC 2016 coding period has come to an end and mentor’s evaluating students this week. It has been an enriching 13 weeks of reading datasheets, designing structures, coding, learning and hanging out over IRC! I’d like to take this opportunity to present my work and details on how to use it. Firstly, to offer context to the work, here is a list of public mails and blog posts. These should give an idea as to how the discussions and work evolved. A lot of the discussions have happened over IRC, but #flashrom does not keep any logs. From the mailing list, this and this And of course my blog posts The patch sets that I sent to the mailing list can be found at – Multiple status register and access protection infrastructure OTP/Security registers infrastructure Dummy chips You can also find these over at flashrom’s patchwork. The mailing list is where the review happens (although a better alternative, IMHO, is Gerrit which coreboot uses). The patches aren’t currently merged and are under review. In any case, you are most welcome to join review (which will likely be very helpful for me). If you’d like to look at something more on the bleeding edge, then I invite you to my GitHub. Now, moving on how to use the work. The most exhaustive documentation on how to use it is the code itself :P, but in the following list I attempt to list scenarios – For SPI chips that have multiple status registers, flashrom’s verbose output will print the status register bits and there values. Most bits are named, i.e., the datasheet refers to the bit by an abbreviation, for instance, WEL for Write Enable Latch, WIP for Work In Progress, BP for Block Protect, LB for Lock Bit and so on. The verbose output will print these names, both in abbreviated and long forms, for most chips (and these abbreviations tend to be generic across many manufacturers). However, the process for adding new chips that leverage this, and adding new bits, is a fairly easy task (I would invite you to have a look at the code for more details). The verbose output also prints the write protection mode for status register(s) in effect (software protected, hardware protected, power cycle lock down and so on). In case you want to disable or enable (a particular type) write protection for status register, you can use the --wp-disable or --wp-enable[=MODE] respectively (where MODE is either of software, hardware, power cycle or permanent – you are encouraged to have a look at the man page for more details) In case you want to protect a particular range of an SPI chip from writes or erases, you will need to alter the BP, TB or SEC bits. Currently, there is a CLI that will enable you to accomplish all that. First, you’ll want to look at the list of ranges your SPI chip supports – run flashrom with --wp-list. Take note of the start address and the length of the memory range you want to protect. Then again run flashrom with --wp-set-range start=0xfff000,len=4 (0xfff000 and 4 are for representational purpose only). By now the memory range is protected, but you can additionally enable status register write protection by following what the foregoing point described. For SPI chips that support OTP, you can read, write and erase OTP regions (of course for supported chips :P). For OTP operations, you have at your disposal --print-otp-status, --read-otp [,reg=], --write-otp file=[,reg=], --erase-otp [reg=] and --lock-otp [reg=]. You can read the OTP memory to a file, or you can write to the OTP region from a file, very much like reading and writing from/to SPI chip. For more details, I would again like to point you to the man page. Since this is a work-in-progress, the CLI may change (and is very likely). Currently around 10% of SPI chips use this new infrastructure. Models of a few manufacturers (and especially exotic ones like Atmel) are yet to be fully incorporated. You are most welcome to add support for new chips or update the existing ones to support new infrastructure. I would like to sincerely thank my mentors Stefan and David for their support and help. I am indebted to them for this opportunity and I hope that we continue to share this relationship in the future while I continue to explore and contribute to flashrom. It has been a pleasure getting to know each of them. I’d also like to thank Urja for pitching in from time to time It was fun hanging out over IRC and helping folks asking questions there. And I am looking forward to it for years to come. In the next and final part of this post, I will highlight how we intend to improve upon this work in the future, where it will be headed and what more we have in store, so please stay tuned. Phew, this was a long one, and rightly so as it attempts to summarise a
[coreboot] New on blogs.coreboot.org: [GSOC] Panic Room, Recap
A new post titled "[GSOC] Panic Room, Recap" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/08/23/gsoc-panic-room-recap/ Hello everyone, in the following post I’m going to recap all that I’ve managed to accomplish during the GSoC of this year. As a disclaimer: I plan to maintain these patches until they are fit to be mainlined or rejected altogether in case of design flaws. libpayload: replace cbfs_media api with region_device api This patchset should be complete, I tested it quite thoroughly by using the API to update the bayou payload (separate patch). I'm still waiting on a review on this one so I suspect there will be some cause for nitpicks. bayou: Adapt to the coreboot-v4 era Changed the design of the payload to make it integrate better with the current infrastructure of coreboot. The majority of the changes have been documented in the appropriate wiki entry. The patchset is complete and working. console/serialice: Add SerialICE The patchset was started and the initial work was done by Patrick Rudolph. I picked it up from there, fixed the problems that it had and tried to get it in shape. It currently works as expected, waiting on more review/feedback. serialice: update QEMU to version 2.5 serialice: adapt serialice to work with QEMU stable-2.5 In its current state this patchset produces a working build, all the functionality seems to be intact and SerialICE produces the same output as with the old implementation. There could be some unforeseen problems with the changes in the QEMU infrastructure and it could use a cleanup. [WIP] src: replace device_t type with pnp/pci_defn_t This is one of the latest commits that I've worked on, it's still a work in progress but I plan to remove all the the improper uses of device_t and replace it with the appropriate type. It's probably gonna take a while and I suspect the patch is going to be massive. If anyone has any suggestion on how to handle this transition feel free to tell me. tint: Fix tint and add Kconfig option The payload works as intended. Only nit is that maintaining a separate patch to apply to the tint code is tricky/messy. lib/selfboot: Replace rdev_mmap_full() The code worked, even though it's been a while since I rebased the change to check for conflicts. Should be an easy fix anyway. payloads: add support lz4 compression selfboot: add sequential lz4 payload decompression The functionality works as expected. coreinfo: Add support to read timestamps cbmem: share additional time stamps IDs Code works as intended, the only thing missing are the commas that should split the timestamps in groups of 3 digits. I couldn't port that part since it relied on a recursive function that no longer worked. elfwriter: Fix multi-phdrs ELFs parsing cbfstool: Require "-m ARCH" to extract payloads and stages cbfstool: Extract payload in ELF One of the oldest patchset that I wrote, took a while to get it right but it seems to be working wonderfully. region: Add writeat and eraseat support Below are a bunch of minor patches that I’ve written to fix the bugs that I’ve encountered while working on the patches above or browsing the source tree: i945.h: fix #include path emulation/qemu-i440fx: add cmos.default file nvramcui: refactor code pc80/mc146818rtc.h: Replace leftover macro token lenovo/x60: add GPIOs initialisation before dock check serialice: update lint filters payloads: add Kconfig option for bayou libpayload: split "Drivers" config section in Kconfig bayou: delete pbuilder utility filo: Specify libpayload path cbfstool: Allow to easily build the individual tools If you have any question regarding these patches you can find me on IRC (avengerf12). I wanna conclude this post by expressing my gratitude towards the coreboot’s GSoC admins and mentors for the wonderful opportunity that they have given me and to the coreboot community for all the help and suggestions. Sincerely, Antonello -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] Better RISC-V support, wrap-up
A new post titled "[GSoC] Better RISC-V support, wrap-up" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/08/23/gsoc-better-risc-v-support-wrap-up/ In less than an hour, Google Summer of Code 2016 will be over (at least for us students). In this blog post, I will describe how you can use coreboot on RISC-V. You can find the complete list of commits that I made during GSoC with this gerrit query. The details Compiling spike, the RISC-V instruction-set-level simulator Spike, also known as riscv-isa-sim, is the reference implementation of RISC-V, and the only RISC-V platform that is currently known to work with coreboot (QEMU is nominally also supported, but the corresponding coreboot code has not been updated in a while). First, you need to build and install libfesvr: Clone the libfesvr git repository run ./configure --prefix="$HOME" && make && make install Then, you can compile and install spike: Clone the spike git repository. Apply the patch in this pull request to make console output possible. Open riscv/processor.cc in a text editor and find processor_t::get_csr. Add a line that reads case CSR_MTIME: return 0;. run ./configure --prefix="$HOME" --with-fesvr="$HOME" && make && make install Compiling coreboot for RISC-V Clone the coreboot git repository, if you haven’t already Apply Iru Cai’s patch that updates the toolchain to GCC 6.1. You will currently have to fix a merge conflict when you apply this patch, but it’s an easy one. Run make crossgcc-riscv Run make menuconfig to configure coreboot. Select Emulation and SPIKE usb riscv in the Mainboard menu. Run make Run util/riscvtools/make-spike-elf.sh build/coreboot.rom build/coreboot.elf Start coreboot by running spike build/coreboot.elf. You should see a few pages of output, ending in Payload not loaded. Compiling and running Linux Clone the riscv-linux git repository and check out the priv-1.9 branch Apply this patch that allows linux to be started in machine-mode. Download a copy linux 4.6.x from kernel.org, and unpack it. I’ll assume version 4.6.2 is used. cd into linux-4.6.2/arch and symlink the arch/riscv directory from riscv-linux Back in linux-4.6.2, run make O=build ARCH=riscv defconfig; cd into the newly created build directory. Run make ARCH=riscv menuconfig. In the “General Setup” menu of the linux menuconfig, enter path/to/coreboot/util/crossgcc/xgcc/bin/riscv64-elf- as the cross-compiler tool prefix. Run make ARCH=riscv vmlinux to compile linux. Open vmlinux in a hex editor, such as hexer. Change the 8-byte number at 0x18 to 00 00 00 90 00 00 00 00; Add 00 00 00 90 00 00 00 00 to the numbers at 0x58 and 0x90, to load linux at physical addresses within RAM. It’s unfortunate that I have to recommend this step, but I did not come up with a better fix yet. Next, you need to add vmlinux to coreboot: Return to the coreboot directory. Apply the remaining coreboot patches that are tagged riscv. In the Payload menu, select An ELF executable payload. Instead of payload.elf, select the vmlinux file. Run make and util/riscvtools/make-spike-elf.sh build/coreboot.rom build/coreboot.elf again. Run spike build/coreboot.elf. You should now see a Linux boot, at least partially. Future work Even though my GSoC is over, coreboot’s support for RISC-V can still be improved, and I intend to fix at least some of the following things: As you can see above, running coreboot and linux on RISC-V currently isn’t straight-forward, but involves a few manual steps. There are other RISC-V platforms that I’d like to see coreboot on, such as lowRISC. Linux does not completely boot, i.e. into userspace. There are still some bugs to be ironed out. Automatic testing could be used to detect regressions. I only tested coreboot on RISC-V with Linux; support for other operating systems or payloads is welcome. Acknowledgements I’d like to thank Ron Minnich and Furquan Shaikh for being good mentors, and everyone in the coreboot community for being helpful and friendly. -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSOC] Panic Room, week #8, *
A new post titled "[GSOC] Panic Room, week #8,*" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/08/22/gsoc-panic-room-week-8-onward/ What have you worked on during the past few weeks? I tried to finish one of the optional goals of my proposal: a way to access a payload (possibly a recovery) after the hardware initialisation is complete but the OS has still not taken over. To define it in more practical terms, I wanted to replace the running payload at the press of a predefined button. I started by looking into the SMM (System Management Mode) and in particular the SMI (System Management Interrupts) handlers defined by each target board in the coreboot tree. That was the easy part, it took just a bit of probing my board (Lenovo x60) and a serial cable to retrieve some of the SMI button codes (I planned on using the ThinkAdvantage button, code 0x19). I added it to the appropriate smihandler.c file, defined the behaviour and that was about it. The more difficult part was actually implementing a way to make it possible to boot a new payload while in SMM. SMM can be considered a separate “module” from romstage, etc, this consequently means that it does not have access to all of the same functions. In particular it cannot access the load_payload() and run_payload() functions defined inside prog_loaders.c, which, as the name implies, are necessary in order to use a payload. In order to solve the problem I came up with two designs: The first design is quite simple, but in my opinion a bit messy. It involves including all of the missing source files into the SMM module at compile time, a.k.a adding more entries inside the Makefile.inc scattered around the source tree. I went down this route for a while until I stumbled on a function that needed to use a malloc(), this was expected so I included the definition of that function. It then asked to have access to the heap (_eheap) in order to allocate the memory requested, the problem is that the heap is not defined inside SMM. I grepped through the source code and found very little about what I was supposed to do in order to define it, so I had to let it go. (To add a little bit of context, this was yesterday and if you take a look at this post’s date you’ll realise that there is only 1 day left of GSoC, panic!) The second approach consists of leaving SMM mostly as it is now, and instead find a way to communicate with ramstage, in order to boot the desired payload. The thought process was that, if cannot call a function directly from SMM, I would have to use the functions already in place in ramstage, unfortunately those functions are called only once, after the initialisation is done. This is where the CMOS memory comes in, I modified the payload loading process and instead of using an hard-coded path defined at compile-time, I made it check for a string inside CMOS and use that as the payload path. This method, however, also presented some problems: – It seems that currently cmos.defaults is completely ignored and the CMOS string values are not initialised as intended (at least on my board), therefore the payload path resulted always blank. – There needs to be quite a bite of space in the CMOS to keep the path there. The usual path (fallback/payload), occupies around 160 contiguous bits of the 1024 available ones, which also need to share space with other important configuration bits such as RTC, etc. In order to circumvent these limitations it would be possible to replace the string path in the CMOS with an enumeration of the possible paths, this however would need to be defined, maintained and shared both in the CMOS and the rest of coreboot. However, same as above, I ran out of time. That about sums it up for the past few weeks. Thank you for reading and have a nice week. -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: flashrom's transition to git
A new post titled "flashrom's transition to git" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/08/08/flashroms-transition-to-git/ Sorry to interrupt the stream of GSoC posts! Some of you may have wondered why there were no flashrom commits at all since the 0.9.9 release in March (i.e. about 5 Months). There wasn’t much direct flashrom development going on on the vanilla branch of flashrom apart from Hatim’s GSoC efforts of course. Instead I’ve been working on moving our repository to git. I have created some client- and server-side hooks + other infrastructure (with the help of Patrick) that will be used in the future to host the vanilla flashrom repository. This part was actually only the smaller part of time I spent on flashrom in the last months (which was not as much as I would have wished for, obviously). More on this and future development later on the flashrom mailing list… The remaining time I’ve been working on a script that rewrites history. Not all of history, only the flashrom repository’s history.The new git repo will include not only the commits from the trunk branch of the well-known subversion repository but also the fameless flashrom-related commits of the original coreboot v1 (then LinuxBIOS) repository where flashrom was conceived initially. This comprises about 30 commits from 2002 to fall 2003. The first commit message (by Ron Minnich) was “Trying to make this general purpose user-land flash burner” on 2002-01-29. Thanks to git-svn (which I’ve been using for almost all my flashrom development from the start) I already got all of flashrom’s subversion repository in a local git database. Prepending that other tree was quite easy with git: Suppose you have currently checked out the tree you want to append to the old tree in a branch called flashrom-cbv1/master then the following will replace the initial commit of the current branch with the other tree (faster than svn can show a single commit message): git replace $(git rev-list --max-parents=0 HEAD) flashrom-cbv1/master So that was relatively easy… But there were some problems. Most importantly git stores an author and a committer for each commit. These were not set correctly in my tree but was derived from the svn committer’s user name (e.g. stefanct). To correct this one can either use an author file that maps the svn committers to names+email addresses like git uses, or one can use the git filter-branch command to change existing commits. This also allows to derive more precise information… my final script is parsing the commit message for signed-off-by lines and uses that to set the author to something else than the svn committer. This will dramatically change the perception of flashrom as it changes the number of commits by the regulars as well as the number of total contributors as decoded e.g. by github or openhub quite a bit, cf. https://www.openhub.net/p/flashrom/contributors If you look at the very old commit logs of flashrom in the subversion tree you will notice many that well… offer some room for improvement. For example all of the commits converted from the coreboot v2 tree start with “Original v2 revision:” followed by the coreboot svn revision number – not that helpful or pretty. The quality of the actual contents vary a lot. Many don’t have a sign-off, many are just bad commit messages like “flasrom update from Stefan, resovle issue 21” but some are actually wrong as they describe another commit or something that might have happened in the same commit (of the coreboot tree) that did not touch flashrom but got committed with changes to flashrom. But even newer commits of flashrom are far from perfect and could be improved, some even automatically. Perfectionistic as I tend to be I could not abstain from seizing the opportunity to correct these problems. So I began to work on a commit filter script to be used with git filter-branch that improved things quite a bit. Due to my lack of awk-knowledge I resorted to use sed, lots of greps and even pcregrep and perl in some circumstances to parse and change the commit messages. Eventually I came up with a script that not only fixes lots of typos automatically, sets the git author and committer correctly and also preserves the knowledge about cb v1, v2 and flashrom svn revisions but also fixes many individual commit messages “manually” by rewriting and/or deleting parts of them. All in all this script has over 1000 lines of shell script and runs for about 500 seconds/8 minutes when rewriting the whole flashrom history. Sorry that it took so long but the result is quite nice IMHO. Take a look at https://www.flashrom.org/git/flashrom.git/ and please notify me of any obvious mistakes my script made if you spot them! Since this was quite some effort and the script contains some maybe not obvious tricks for this kind of task, I have attached the current version to this post: svn2git.sh -- coreboot mailing list:
[coreboot] New on blogs.coreboot.org: [GSoC] Better RISC-V Support, week #10
A new post titled "[GSoC] Better RISC-V Support, week #10" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/08/02/gsoc-better-risc-v-support-week-10/ This past week, I worked on the virtual memory initialization code of coreboot on RISC-V. The first part of this was to update encoding.h a file that defines constants such as bit masks which are necessary for interacting with RISC-V’s Control and Status Registers. As a result, I also had to change a few files that relied on outdated constants. Then I wrote some code to walk the page table structures, and fixed one or two bugs in the page table setup code. Unfortunately my patches aren’t as finished as I would like them to be. When I tested my changes with a Linux payload (which I had to edit the ELF headers of, because Linux uses virtual addresses, while cbfstool and the SELF loader use physical addresses), I stumbled upon another strange error: I get a store access fault in the instruction of the trap handler that saves the first register, even if I initialize the stack pointer to a value that’s within the RAM. When the trap handler runs again to handle this store access fault, it runs without any problems. This fault is especially confusing, because machine mode should always be able to access RAM through its physical addresses. What’s next? During the next week, I’ll be traveling and won’t be able to work on coreboot. When I return, I will rework my patches so they can be merged, and hopefully understand the aforementioned access fault problem. Properly set-up page tables should bring me a step closer to running Linux on coreboot/RISC-V (without bbl in the middle). If time permits, I will start porting coreboot to the Nexys 4 DDR devboard. -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSOC] Panic Room, week #7
A new post titled "[GSOC] Panic Room, week #7" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/07/30/gsoc-panic-room-week-7/ What have you procrastinated on this past week? As usual, I’m glad you asked. During the past week I worked every day(/night) on the porting of the region_device API (commit) as I probably mentioned last week. The port is now complete and it should be bug-free (?). It’s been tested pretty thoroughly since I immediately used it to adapt Bayou from the old LAR/coreboot-v3 paradigm to the new CBFS/coreboot-v4 one. A bunch of bugs cropped up with the new API during the transition (debugging the API wasn’t fun at all) but they have been solved and unless for some corner-cases that I missed it should just work. The second part of the week, as you might have guessed read, has been devoted to fixing Bayou (commit). This has been quite fun, almost everything was broken or relied on some old function that has since been dropped from libpayload. It now works quite well and supports all of the original features. The only problem now are with the other payloads since they aren’t all able to exit cleanly and give back control to bayou (i.e. coreinfo reboots before returning, tint halts, etc). If you want to know more details take a look at the commit message. Apart from this two items I wrote a couple of patches concerned with libpayload and a patch that adds support for sequential lz4 decompression during the boot process (Thank you, Julius Werner, for pointing that out). I also just finished updating the wiki entry for Bayou, so if someone wants to test it out… What’s next? With less than a month left of my GSOC time I plan to dedicate solely to maintain the patches that I currently have and work on the coreboot/serialice integration (so as to finally do something pertinent to the original proposal). Have a nice weekend! P.S. I had to drop the idea of working on the FILO (flashupdate) project since it relies on a series of patches that have not been finished yet (libflashrom). It will be a project for another time perhaps. P.S.S. I think I lost count of a few weeks here and there… -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] Multiple status registers, block protection and OTP support, week #6, 7, 8 and 9
A new post titled "[GSoC] Multiple status registers, block protection and OTP support, week #6, 7, 8 and 9" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/07/24/gsoc-multiple-status-registers-block-protection-and-otp-support-week-6-7-8-and-9/ Hello! I have been away for some time now, so this is going to be a longer post. I hope you have missed hearing from me In this post I will talk about my work in the weeks post-midterm evaluations. After a discussion with my mentors in the midterm evaluations week, we decided to shift focus towards the first three phases of my GSoC proposal for the remainder of the duration. Work on the final phase will be done after GSoC along with the more long-term goals that have come up as I have been making progress. I submitted patches (finally ;)) to the mailing list. The set of patches adds multiple status register, and block protection infrastructure. I have also added a command-line interface to expose the new functionality. Although I am not sure that the exact wording of the CLI is most optimum, but I did not spend a lot of time on that because IMO it is a rather subjective issue and altering it is not a difficult task. The set of patches also adds support for new infrastructure to around 90 existing chips. I am still waiting to receive feedback and review on them. (My mentors had been slightly busier then.) I am also investigating adding support for access protection to non-SPI chips. This isn’t on the highest priority (more like a long-term goal), but once the SPI infrastructure gets merged, I will begin writing code for that. Based on the initial prototypes I built (here, here and here), we had decided to use pointers to new structs instead of fully embedding them in struct flashchip. This decision really started to show when I was adding support for existing chips – with only 25 unique struct definitions we were able to support those 90 chips! One of the problems I faced was that I needed to test the new infrastructure, but doing so on a physical chip would be cumbersome. So that problem was solved by adding a dummy chip to use with flashrom’s dummy programmer. (At that time the code was the dummy chip was messy and something I would be ashamed to put up publicly, but now I have improved upon it! :P) Currently I am working on finalising the OTP/security register(s) patches – more specifically, adding support to existing chips, code cleanup and documentation. I will be able to send them to the mailing list in a few days. In my research on Eon, GigaDevice and Winbond chips, 2 distinct models for OTP were observed – the GigaDevice and Winbond model with security register(s), and the Eon model with a security sector. The Security Register(s) model has 3 separate opcodes for read, program and erase – 0x48, 0x42 and 0x44 respectively. A chips can have multiple security registers (most commonly 3, but as high as 4) with each register being anywhere between 128 bytes to 1024 bytes in size (most commonly 512 bytes and then 256 bytes). Usually chips have a lock bit (LB1, LB2, …) in the status register that correspond to respective security registers. These one-time programmable bits are changed using the standard WRSR instruction. Some chips have a single lock bit that controls OTP status for all security registers. The Security Sector model has a separate sector which can be operated in the OTP mode. OTP mode is entered with opcode 0x3A and exited by sending WRDI (0x04) instruction. While in the OTP mode, the sector behaves just like any other sector – normal read, program and erase instructions apply. The SRP/SRWD bit is served as OTP bit while in OTP mode. Issuing the WRSR command (irrespective of the data sent along with it) will cause the one-time programmable OTP bit to be set. One of the recurrent issues (for the lack of a better word, I don’t think of it to be an issue really ;)) is that many chips I have based my research on, are not originally supported by flashrom (perhaps unfortunate siblings of the same family that didn’t find support in flashrom earlier xD). I don’t call it an issue per se because after I have submitted my patches flashrom will end up supporting even more chips, but since I have to write more code it might take slightly longer to submit the patches. There is a third model which is dominantly followed by Spansion chips and a couple of AMIC chips (some AMIC chips follow one of the earlier models – it’s like AMIC couldn’t decide which one to stick to or they probably had different teams working on it! :P). Similar to the security sector design, these chips also have a separate OTP sector but instead of storing configuration in the register, a byte within the sector is allocated for storing the configuration data. I have planned to support this model in the next revision of patches, after the upcoming ones get reviewed and merged. Thanks for your time, it was nice to get back in touch with you!
[coreboot] New on blogs.coreboot.org: [GSoC] Better RISC-V support, week #6/7/8/9
A new post titled "[GSoC] Better RISC-V support, week #6/7/8/9" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/07/24/gsoc-better-risc-v-support-week-6789/ Since I haven’t posted an update of my coreboot-on-RISC-V work in a while, this will be a slightly longer post. Week 6 In week 6, I started documenting how to build and boot coreboot on RISC-V, in the coreboot wiki. It is now a bit outdated, because we’re moving away from using bbl to boot Linux. Week 7 I wrote some patches: I removed code that used the old Host-Target Interface (HTIF), because it’s deprecated. I submitted an improved version of my workaround for the bug that causes Spike to only execute 5000 instructions in some cases. I informed the coreboot resource management subsystem about the position of the RAM in physical address space, so that the program loader wouldn’t refuse to load segments into RAM. I submitted two patches to fix compiler errors with the new toolchain. Meanwhile, there were some good news in the RISC-V world: The RISC-V project released version 1.9 of the RISC-V Privileged Architecture Specification Around the same time, lowRISC released version 0.3 of their RISC-V implementation for the Nexys 4 DDR devboard Week 8 I submitted a few more patches and started to explore the Nexys4 board. The precompiled bitstream and kernel from the lowRISC version 0.3 tutorial worked without any problems, and after a few days and some help from the lowRISC mailing list, I was able to recompile the lowRISC bitstream. This week I discussed the choice of boot medium with the lowRISC developers, and they agreed that a memory-mapped flash would be useful. Once it is implemented, I can start porting coreboot to lowRISC on the Nexys 4 DDR board. Luckily the Nexys4 already has large enough flash to use for this purpose. My mentors and I agreed that the switch from machine mode to supervisor mode should be left completely to the payload. What’s next? I will continue to work on running coreboot on the Spike emulator. Currently I’m facing the following problems and tasks: Linux, when compiled to an ELF file (vmlinux) specifies that it wants to be loaded at the physical address 0x0 and at the virtual address 0x8000. Since coreboot’s ELF loading code only looks at the physical address, it refuses to load Linux, since RAM starts at 0x8000 on RISC-V. Low level platform information (most importantly the memory layout) is passed to the firmware (coreboot in this case) as a configuration string, which is dynamically generated by the emulator, in the case of Spike. I still need to implemented a parser for this format, so coreboot can know how much memory is available. The RISC-V Privileged Architecture Specification 1.9 specifies that there shall be a page at the top of the virtual address space where the operating system can call a few functions exposed by the firmware (this is the Supervisor Binary Interface). -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSOC] Panic Room, week #4/5/6
A new post titled "[GSOC] Panic Room, week #4/5/6" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/07/21/gsoc-panic-room-week-456/ What have you been up to these past few weeks? My facetious alter ego, I must admit I sinned, I strayed oh so much from my original timeline. (Quite obvious if you read the previous posts) Since my last post I mainly kept focusing on the region_device API, I attempted to go through with my week #3 plan to continue the phasing out of rdev_mmap_full() from the selfload code (described in previous post). I think I overestimated what I could accomplish regarding that project, I tried to modify the current lzma API used inside to coreboot to make it possible to easily load each chunk of data from memory/chip and decompress it gradually. Theoretically it shouldn’t be too difficult, in practice the decompression code is particularly nasty and it seems it is a customised version of the LZMA SDK code. I, not so quickly, realised that I didn’t have the time to delve into that, so I momentarily dropped the idea. (It could be a nice project to do after the GSOC ends.) I also spent a chunk of my time in porting the time stamps reading functionality from the cbmem utility into the coreinfo payload (commit). It is now possible to read how much time the coreboot boot sequence takes without having a working OS environment. I needed to measure if there had been any boot time improvements after the rdev_mmap_full commit. (Still haven’t got around to doing that though…) What are you working on now then? I’m currently working on porting the region_device API from coreboot to libpayload, meanwhile replacing all the functionality that was provided by its predecessor: cbfs_media. Today I finished (in before my code has to be reworked completely ) replacing the old api inside libpayload and started converting the only payload that used cbfs_media: depthcharge, the payload used to boot ChromeOS. Hopefully it will be a painless process. What’s next? So, after I finish these current patch (possibly for the weekend), I need to re-focus my attention on my actual timeline. I plan to test the current FILO master branch to check for possible problems and show-stoppers before an eventual new release in the (near?) future. It would be quite helpful in that the current stable is not stable at all, it doesn’t even compile and neither does the master tag (unless you apply this patch which is still pending approval). It would also be the first release that includes the new flashupdate command and would allow for some interesting things to be done (i.e. path to the recovery from a bad coreboot flash/configuration). Furthermore I would like to get the SerialICE firmware-side code to be merged into the main coreboot codebase (commit), so I plan to work out the current problems with the time that I still have at my disposal. (Uh, sounds a bit cliche’ by now) See you next week time! (Just to be on the safe side ) -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] Better RISC-V support, week #4/5
A new post titled "[GSoC] Better RISC-V support, week #4/5" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/06/27/gsoc-better-risc-v-support-week-45/ Week 4 In week 4, I tracking down why coreboot halted after about one line of output. It turned out to be a spike bug, that I wrote up in this bug report, and affect any program that doesn’t have a tohost symbol. As a workaround, I extended my script that turns coreboot.rom into a ELF to also include this symbol. After some more patches I could run coreboot in spike and get the familiar “Payload not loaded” line. Week 5 I was now clearly moving towards being able to run linux on spike/coreboot. But there was a problem: The RISC-V linux port requires a working implementation of the Supervisor Binary Interface (SBI), which is a collection of functions that the supervisor (i.e. the linux kernel) can call in the system firmware. Coreboot has an implementation of the SBI, but it’s probably outdated by now. To get an up-to-date SBI implementation, I decided to use bbl as a payload. When I built bbl with coreboot’s RISC-V toolchain, I noticed that it depends on a libc being installed in two ways: The autoconf-generated configure script checks that the C compiler can compile and link a program, which only succeeds if it finds a linker script (riscv.ld) and a crt0.o in the right place. bbl relies on the libc headers to declare some common functions and types (it doesn’t use any of the implementations in the libc, though). The coreboot toolchain script doesn’t, however, install a libc, because coreboot doesn’t need one. I tweaked the bbl source code until it didn’t need the libc headers, changed the implementation of mcall_console_putchar to use my 8250 UART, got the payload section of bbl (where linux is stored before it’s loaded) out of the way of the CBFS by moving it to 0x8100 (bbl/bbl.lds is the relevant file for this change), and could finally observe Linux booting in spike, on top of coreboot and bbl. It stops with a kernel panic, though, because it doesn’t have a root filesystem. Plans for this week This week I will document my work on the Spike wiki page in the coreboot wiki, so others can run coreboot on spike, too. -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSOC] Panic Room, week #3
A new post titled "[GSOC] Panic Room, week #3" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/06/21/gsoc-panic-room-week-3/ What happened during the past week ? After many iteration of patches and bug hunting I finished writing and testing the code that added to cbfstool allows to convert between SELF and ELF. The code has been now merged. One of the most problematic things has been to get GRUB to work after the conversion to ELF whereas all of the other payloads were working wonderfully. It turned out it is the only payload (that I tested) that used more than two segments to describe the memory image of the program. This also uncovered a bug contained inside the elf_writer code that was probably never triggered given that the majority of payloads only contain one segment (commit). I also received the replacement mobo for my Lenovo X60 target, so I can get back on track with the SerialICE part of the project. What are your plans for next week? I am currently investigating a bug in the serial communication between QEMU and the target while using the most recent version of the patch that integrates SerialICE into coreboot. I am also looking into some work related to selfboot.c and the region api; the objective is to avoid loading the payload all at once while it is being executed and allow for the various parts of the payload to be loaded when needed. Hopefully I’ll manage to finish all of this before next week. (Sometimes I definitely feel too optimistic) What?! Didn’t you have any mishaps© this week? It’s indeed quite fascinating how my equipment keeps breaking… this week was my Raspberry Pi’s turn. It won’t boot anymore. Fortunately I have a Bus Pirate and a BeagleBone Black to use for SPI flashing, so it’s all good. See you next week! -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] Multiple status registers, block protection and OTP support, week #3 and #4
A new post titled "[GSoC] Multiple status registers, block protection and OTP support, week #3 and #4" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/06/22/gsoc-multiple-status-registers-block-protection-and-otp-support-week-3-and-4/ The most important accomplishment during these weeks was developing a generic algorithm which would generate the block protect range table for a given flash chip. This algorithm can be applied to a majority of chips. The previous solution that I had developed was to have range tables stored in a struct and a pointer to it would be in struct flashchips for chips that share the range definition. This array of struct range would be indexed by block protect (BP) bitfield, so essesntially we could get the protected range for a chip given the bitfield in O(1) time. While it looked neat, it was only marginally an improvement over existing solution in ChromiumOS. I really wanted to try to have a more elegant and robust solution. So after getting back some feedback from my mentor David, I decided to investigated further. I started with around 80 datasheets from AMIC, Eon, GigaDevice, Macronix, Winbond and others with objective to find whether a generic pattern could be observed such that given a chip and its properties can we compute its BP ranges. After a few attempts, I settled on a model that fits all GigaDevice and Winbond chips, and to some AMIC and Eon chips, which together account for around 50% of the chips I investigated. Having the layout of the status register as a member of struct flashchip came in very handy. For the algorithm itself and its demo, please have a look at this mail in the discussion thread on the mailing list. Once this was in place, I went through another iteration to allow the code to automatically handle presence (or absence) of SEC/TB/CMP bits. One could wonder that since this model generates range tables automatically for only about half of the chips, what about the remaining ones? As I like to put it slightly dramatically, the “grand” design is very flexible. The struct wp has function pointers that can be assigned chip specific functions, but if they are unassigned then the code falls back to using the generic functions. Quite a few chips that are not included in the 50% collection above, have ranges that can be computed with slight modification after the generic pattern has been applied, allowing maximum re-use of code. This idea is also part of the mail and demo linked above. The investigation and subsequent pattern deduction took a fair amount of effort. Although I was very happy with the results, nonetheless they were at a slight tangent to what I had planned. The last week had not been as productive as I would have it. So as it stands, I am slightly amiss from the pre-midterm timeline I had proposed. However, I have taken corrective measures, and will ensure that post-midterm timeline is not affected. Currently I am finalising the OTP support model. The functionality for reading/writing multiple status registers and block protection are in place. Later this week I will work on CLI to expose this functionality and wire up existing flashrom code to make use of the new infrastructure. Following that, I will be testing the new infrastructure on a few GigaDevice chips that I have. I have also ordered some chips from a few other manufacturers so hopefully they should arrive in time by then. Thanks for your time. In case you have any feedback, I’d love to hear. See you later! -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] Better RISC-V support, week #3
A new post titled "[GSoC] Better RISC-V support, week #3" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/06/13/gsoc-better-risc-v-support-week-3/ Last week, after updating GCC (by applying Iru Cai’s patch) and commenting out uses of outdated instructions and CSRs (most notably eret and the HTIF CSRs), I noticed that coreboot crashed when it tried to access any global variables. This was because the coreboot build system thought coreboot would live near the start of the address space. I found spike-riscv/memlayout.ld, and adjusted the starting offset. But then I got a linker error: build/bootblock/arch/riscv/rom_media.o: In function `boot_device_ro': [...]/src/arch/riscv/rom_media.c:26:(.text.boot_device_ro+0x0): relocation truncated to fit: _RISCV_HI20 against `.LANCHOR0' I played around with the start address and noticed that addresses below 0x7800 worked, but if I chose an address that was too close to 0x8000, it broke. This is, in fact, because pointers to global variables were determined with an instruction sequence like lui a0, 0xN; addi a0, a0, 0xNNN. On 32-bit RISC-V, the LUI instruction loads its argument into the upper 20 bits of a register, and ADDI adds a 12-bit number. On a 64-bit RISC-V system, lui a0, 0x8 loads 0x8000 into a0, because the number is sign extended. After disassembling some .o files of coreboot and the RISC-V proxy kernel, I finally noticed that I had to use the -mcmodel=medany compiler option, which makes data accesses pc-relative. Now that coreboot finally ran and could access its data section, I finished debugging the UART block that I promised last week. Coreboot can now print stuff, but it stops running pretty soon. Plans for this week This week I will debug why coreboot hangs, and will hopefully get it to boot until the “Payload not found” line again, which worked with an older version of Spike. Also, Ron Minnich will be giving a talk about coreboot on RISC-V at the coreboot convention in San Francisco, in a few hours. -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSOC] Panic Room, week #2
A new post titled "[GSOC] Panic Room, week #2" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/06/11/gsoc-panic-room-week-2/ How was your last week? Let’s say that it was a bit unexpected. I spent the majority of it trying to wrap my head around the ELF (Executable Linkable Format) specification. I used this new acquired knowledge to improve the utility cbfstool and allow it to extract payloads contained inside a CBFS directly into ELF instead of SELF (commit). In order to achieve this cbfstool has to do a few things: Extract the payload from the coreboot image Parse the segment table contained inside the SELF payload in order to find out how many and which segments are present. Using the elf_writer API generate a compliant ELF header Take the content from each segment and copy it to the correspondent ELF section header and configure it accordingly Once the section table is filled out, use elf_writer to generate the program header table and write out the final ELF The final results would allow to, for example, easily move payloads from a CBFS to another one without having to re-build the payload, coreboot rom or mess with the build system configuration. Right now the implementation it’s not complete yet but it works quite well with a good chunk of the payloads commonly used with coreboot such as SeaBIOS, coreinfo, nvramcui and others. The major hurdles right now are to get the GRUB payload to work and add a way to handle the extraction of a compressed payload. Wait a minute! Weren’t you working on SerialICE? You are quite the inquisitive type, aren’t you? Yes, my main goal is still to continue integrating SerialICE and coreboot. Unfortunately there have been a few showstoppers this week, first my only test clip broke and now my target, Lenovo x60, stopped working and I am no longer able to flash its BIOS chip. I already ordered a replacement but it’ll probably take a bit more than a week to arrive. In the meantime my mentor (adurbin) kindly pointed out the task above to keep me busy while waiting. What are your plans for the next week? I plan to finish implementing the functionality described above and test all the remaining payloads. Hopefully I will also be able to start looking at some of the other tasks that have been suggested to me by my mentors. That’s it for today, see you next week! -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] Multiple status register support, week #1 and #2
A new post titled "[GSoC] Multiple status register support, week #1 and #2" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/06/07/gsoc-multiple-status-register-support-week-1-and-2/ Hi, I am Hatim Kanchwala (hatim on IRC) from India. I am the GSoC student working with flashrom this year. Stefan Tauner (stefanct) and David Hendricks (dhendrix) will be mentoring me this summer (thanks a lot for the opportunity). The pre-midterm phase of my project comprises three sub-projects – multiple status registers, block protection and OTP support. Each of these projects deals with SPI flashchips. As of writing this post, flashrom supports around 300 SPI flashchips. Around 10% of these chips have multiple status registers – most have two but there is one with three. Almost all of these chips have some sort of block protection in place. Around 40% of these chips have some sort of OTP or security registers. A combination of BP (Block Protect, first status register) and SRP bits (usually first, but sometimes second status register as well) in the status register determine the range and type of protection in effect. A few chips have a TB bit (Top/Bottom) in addition to BP bits. Some chips also use a CMP bit (Complement Protect, second or third status register) to add more flexibility to range of protection available. A few exotic chips have a WPS bit (Write Protect Scheme, second or third status register) that define which scheme of access protection is in effect. Chips with security registers have corresponding LB bits (Lock Bits, second status register) which are one-time programmable and, when set, render the corresponding security register read-only. Chips with a separate OTP sector(s) have opcodes to enter/exit OTP mode and, within this mode, the usual read, page program and sector erase opcodes can be used. Previously, flashrom could only read/write the first status register. For writes, all block protect bits were unset (this configuration corresponds to block protection), if the type of protection allowed it. Once unset, flashrom couldn’t revert the BP bit configuration. The ChromiumOS fork of flashrom has some support for locking/unlocking block access protection in place. A lot of the work is done around the Winbond chips, but they are moving towards generalising it. For chips with OTP support, flashrom simply printed a warning, and there was no differentiation between the several OTP models. In these two weeks I sifted through around 5-6 dozen datasheets and developed models for multiple status registers, block protection and OTP/security registers. I discussed with mentors and the community over mailing list the infrastructural changes arising out of implementing these models and, the use cases corresponding to the models. To substantiate these ideas, I wrote separate prototype code. In the process, Stefan introduced me to a powerful tool, Coccinelle. This tool will make applying changes to the monstrously large struct flashchips easier while being safe. As a byproduct of studying existing flashrom infrastructure, I had the opportunity to explore the history of flashrom through git log. I read how and when flashrom evolved from its humble beginnings in coreboot/util to flash_and_burn to flash_rom to finally flashrom today! My broad targets for the coming week(s) will be to finish up with the pending half a dozen or so datasheets, polish the models and start transforming the prototype code into merge-worthy code. Following the infrastructure changes, I will update existing chips to make use of the new infrastructure, add support for a bunch of new chips and finally test on actual hardware. Thanks. See you later! -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] Better RISC-V support, week #2
A new post titled "[GSoC] Better RISC-V support, week #2" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/06/06/gsoc-better-risc-v-support-week-2/ Last week, I updated my copy of spike (to commit 2fe8a17a), and familiarized myself with the differences between the old and the new version: The Host-Target Interface (HTIF) isn’t accessed through the mtohost and mfromhost CSRs anymore. Instead, you have to define two ELF symbols (tohost and fromhost). Usually this is done by declaring two global variables with these names, but since the coreboot build system doesn’t natively produce an ELF file, it would get a little tricky. Spike doesn’t implement a classic UART. The memory layout is different. The default entry point is now at 0x1000, where spike puts a small ROM, which jumps to the start of the emulated RAM, at 0x8000. One way to run coreboot is to load it at 0x8000, but then it can’t catch exceptions: The exception vector is at 0x1010. Within spike’s boot ROM, there’s also a text-based “platform tree”, which describes the installed peripherals. “Why does coreboot need a serial console?”, you may ask. Coreboot uses it to log everything it does (at a configurable level of detail), and that’s quite useful for debugging and development. Instead of working around the problems with HTIF, I decided to implement a minimal, 8250-compatible UART. I’m not done yet, but the goal is to use coreboot’s existing 8250 driver. Plans for this week This week, I will rewrite the bootblock and CBFS code to work with RISC-V’s new memory layout, and make sure that the spike UART works with coreboot’s 8250 UART driver. Booting Linux probably still takes some time. -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSOC] Panic Room, week #1
A new post titled "[GSOC] Panic Room, week #1" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/06/02/gsoc-panic-room-week-1/ Who are you? Hello everyone, I’m Antonello Dettori (avengerf12 on IRC) and I’m the student currently working on improving SerialICE. What are you working on? I’m glad you asked. As I said just a bunch of lines before I’m working on SerialICE, which is one of the main tools used in reverse engineering an OEM BIOS and therefore in understanding the initialisation process that coreboot will have to perform in order to properly run on a target. The original idea of my proposal was to work towards: Incorporating the functionality of SerialICE into coreboot. Allowing for a way to flash a coreboot-running target without a working OS environment. The situation has changed a bit in the few months after the proposal was written and part of the goals have already been worked on by some of the wonderful contributors in the coreboot community. I still have plenty of work to do and my mentors already pointed out some of the areas of the project with which I could spend my time. How was your first week? Oh boy, you had to go there, didn’t you? I’ve been kind of a late bloomer regarding this project since only from this week I came to truly appreciate all of the work that goes into making coreboot and SerialICE tick. I’m therefore still knee-deep in the learning process, but don’t worry, progress is being made on this front. Unfortunately, this also means that I don’t have any actual code to reach my goals yet. What will you do during the next week? I will, hopefully, manage to wrap up my learning “session” with SerialICE and get to finally write some actual (possibly useful) code. In particular I hope to fix the problem regarding the conflicts in managing the cache and its related registers that occur when coreboot initialises the target but SerialICE is used as the romstage. That’s pretty much it for now, see you next week! -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] Better RISC-V support, week #1
A new post titled "[GSoC] Better RISC-V support, week #1" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/06/01/gsoc-better-risc-v-support-week-1/ Hi, I’m Jonathan Neuschäfer (jn__ on IRC) and my GSoC project for this year is to improve coreboot’s support for RISC-V platforms. RISC-V is a new instruction set architecture (ISA) that can be implemented without paying license fees and is relatively simple. Coreboot has already been ported to RISC-V in 2014, and has since received a bunch of patches, but since the RISC-V Privileged ISA Specification (which defines things like interrupt handling and virtual memory) is still in flux, it has become unbootable again. My first first goal last week was to run coreboot in SPIKE, the official RISC-V emulator, and get some console output. I checked out commit 419f1b5f3 (current master) of the riscv-tools repository and built SPIKE from there. After I patched a few outdated instructions and worked around the fact that the RISC-V binutils port currently included in coreboot targets a newer version of the RISC-V Privileged Spec by hardcoding some Control and Status Register numbers, I finally got coreboot booting until the point where it would jump into a payload, had I specified one. All patches can be found under the riscv topic on gerrit. Plans for this week This week I will update my SPIKE to a version that supports the upcoming Privileged Spec 1.9, which will be released in the next couple weeks. This has the advantage that I don’t need to patch instructions because GCC encodes them differently than SPIKE decodes them. Additionally, I’ll try to get Linux to boot in SPIKE, under coreboot. -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: Announcing coreboot 4.4
A new post titled "Announcing coreboot 4.4" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/05/02/announcing-coreboot-4-4/ We are happy to announce the release of coreboot 4.4. This is our fourth quarterly release. Since the last release, we’ve had 850 commits by 90 authors added 59000 lines to the codebase. The release tarballs are available at https://www.coreboot.org/releases/ There is a 4.4 tag and branch in the git repository. Log of commit 3141eac900 to commit 588ccaa9a7 Major areas that received significant changes in for this release: Build system (30 commits) – Add postcar stage, ‘timeless’ builds, extend site-local, test toolchain by version string, update dependencies, catch ACPI errors, l add additional macros. Toolchain updates (40+ patches) – Update IASL to v20160318 , LLVM to v3.7.1, add GNU make, add nds32le GCC compiler Lint tools (30 patches) – Update existing lint utilities, add lint tests for executable bit, make sure site-local isn’t committed, add test to break all lint tests. Payloads (60 commits) – Fixes for libpayload, coreinfo and nvramcui, add new payloads, see below. Maintainers file – (8 patches) – continue adding maintainers for various areas. Documentation for adding Intel FSP-based platforms (20 commits) Mainboards Added 9 mainboards asus/kcma-d8 emulation/qemu-power8 google/auron_paine google/gru intel/amenia intel/apollolake_rvp intel/camelbackmountain_fsp intel/galileo lenovo/t420 Removed 1 mainboard google/veyron_speedy Existing boards with significant updates asus/kgpe-d16 google/oak google/chell intel/kunimitsu Changes in chips Added 1 new architecture power8 Added 1 processor qemu-power8 Added 5 socs intel/apollolake intel/fsp_broadwell_de intel/quark marvell/armada38x rockchip/rk3399 Existing chip areas with many changes cpuamd/mct_ddr3 drivers/intel/fsp2_0 northbridge/intel/sandybridge/raminit soc/intel/apollolake soc/intel/fsp_baytrail soc/intel/skylake soc/mediatek/mt8173 Added 1 new vendorcode directory siemens Submodules Added 1 submodule chromeec Updated 3 submodules 3rdparty/arm-trusted-firmware (329 commits) 3rdparty/vboot (28 commits) util/nvidia/cbootimage (13 commits) Other Added 4 payloads depthcharge: For ChromeOS verified boot iPXE: For network booting Memtest86+: Updated with fixes for correctly testing coreboot with payloads U-Boot (Experimental): Alternate payload for booting an OS Added 6 utilities archive – Concatenates files into a single blob with an indexed header chromeos – Download and extract blobs from a ChromeOS image futility – vboot Firmware utility intelmetool – Shows information about the Intel ME on a platform. marvell/doimage_mv – No usage notes post – Simple utility to test post cards coreboot statistics Total Commits: 850 Total authors: 90 New authors: 28 Total Reviewers: 40 Total Submitters: 17 Total lines added: 74054 Total lines removed: -15056 Total difference: 58998 -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: coreboot changelog March 2 - March 15
A new post titled "coreboot changelog March 2 - March 15" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/03/22/coreboot-changelog-march-2-march-15/ This changelog covers 187 commits in the two week period between March 2, 2016 and March 15, 2016. (c77e0419 – 80547369) Once again this time, we had many changes in the payloads area. We added a memtest86+ git repository, and set it up as a secondary payload within the coreboot build process. SeaBIOS updated the stable version from 1.9.0 to 1.9.1 and has a new option to build from any specified commit instead of just master or stable branches. Google’s depthcharge payload was added for ChromeOS builds, and the coreinfo payload started getting some updates – removing obsolete pieces, fixing the makefile, and correcting issues with cbfs. The MediaTek MT8173 ARM based SOC and the Google OAK board using it received a significant number of patches, adding trusted firmware support, and initialization routines for memory, USB, audio, TPM, GPIOs, I2c and RTC. Several other groups of patches were to perform cleanup for various chipsets. One series unified and fixed up the UDELAY settings, many of which were incorrectly specifying TSC delays which weren’t supported by those platforms. Other sets removed code #includes of C files, merged the MRC cache implementations into a single common version, and combined Sandybridge & Ivybridge LVDS implementations. The FSP version of Intel’s Bay Trail was updated to mirror the non-FSP implementation, enabling LPE and LPSS in ACPI mode. The plan with Bay Trail is to make the two versions as similar as possible, then work to combine the directories and use common code for both. Intel has started adding support for their Xeon D (Broadwell DE) processor. So far only the vendorcode has been merged. The coreboot code is another 4700 lines of chipset code and 800 lines of mainboard code, so that’s taking some time to get reviewed. The patches bringing up the Quark and Apollo Lake Intel chips continued, with Quark getting minor updates and Apollo Lake continuing to add core functionality like memory init and the various calls into the FSP. Additional work was done on Skylake as well, updating the FSP parameter table, adding a Voltage Regulator mailbox command, and adding clock gating for the 8254 timer. Utilities only got a few changes this time. The cbmem utility got a fix a regression and correctly scale the timestamp values and an option to change the SPI ROM chip sizes was added to ifdtool. Cbfstool got a couple of fixes as well, making sure the structure sizes are the same whether compiled for 32-bit or 64 bit platforms, and zeroing out unused Linux parameters. AMD’s native memory initialization got some more cleanup and several fixes, restoring DQS delay values on a failed loop, and making sure that both read and write training pass before proceeding to the next training phase instead of continuing when either one passed. SMBIOS changes included a patch to add SMBIOS type 17 (Memory) fields to the Sandy Bridge / Ivy Bridge platforms, and another patch to fix the length calculated for those fields for every platform. A third patch added the names of several different DIMM vendors. The X86 bootblock renamed several symbols for clarification, removed some unused code, and marked the reset vector as executable so it would show up in objdump. We had a slew of patches from new authors merged in the past two weeks. Welcome to all new authors and thank you to everyone. Antonello Dettori had 3 patches merged, allowing SeaBIOS to be build from any revision, and cleaning up early serial on the roda rk9 and amd thatcher platforms. Bayi Cheng wrote a patch adding NOR flash DMA read routines for the Mediatek MT8173. Georg Wicherski updated and added Google’s auron paine board. Huki Huang modified the ChromeOS wifi regulatory domain to use the region key from VPD. Jan Tatje updated the Intel Firmware Descriptor tool (iftdool) to allow the SPI rom sizes to be updated. Jitao Shi added the parade ps8640 MIPI-to-eDP video format converter driver. Jonathan Neuschäfer had an astounding 7 patches merged in his first couple of weeks submitting to coreboot. He fixed a syntax error in buildgcc, and updating several areas in coreinfo. Jun Gao did I2C work on Mediatek MT8173 and on Google’s Oak board, Lance Zhao had a pair of patches for Intel’s Apollo Lake reference board, setting up the devicetree, and adding memory training configuration. Medha Garima added runtime SD card detection to Intel’s Kunimitsu board. Milton Chiang had a patch updating the infracfg register map for the Mediatek MT8173. Peter Kao wrote a pair of patches adding DRAM initialization to the Mediatek MT8173 and Google’s Oak board. PH Hsu set up 4GB mode on Mediatek MT8173 and Google’s Oak board. coreboot statistics - Total commits: 187 - Total authors: 44 - New authors: 13 - Total lines added: 15724 - Total lines removed: -1750 -
[coreboot] New on blogs.coreboot.org: GSoC 2016
A new post titled "GSoC 2016" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/03/07/gsoc-2016/ The coreboot project is proud to announce that it has been selected as one of the 2016 Google Summer of Code (GSoC) mentor organizations. GSoC is a program designed to encourage university students age 18 and older to participate in open source projects. This is done by paying students to partner with experienced mentors from the selected open source projects to work on a specific project chosen by the student. This helps the mentor organization by encouraging participation and getting tasks done while helping the student get involved in open source, add projects to their resume, and learn from experienced open-source participants. Student applications begin next Monday, March 14th, 2016, and close on Friday, March 25th. Accepted student projects will be announced on April 22nd. Any students who are interested in applying for a coreboot, flashrom, or SerialICE GSoC project should look at the GSoC student terms page, and at both coreboot’s GSoC page and the coreboot / Flashrom / SerialICE projects page. Projects are not limited to what is currently listed here. Students typically select from these, but if you have other ideas of projects in our space, we’d love to hear about them. As noted above, coreboot acts as an umbrella organization for other firmware related open-source projects, currently supporting Flashrom and SerialICE. If there are other firmware related projects who would like to be included under the coreboot project for GSoC, please contact the project administrators, Patrick Georgi or Martin Roth. Finally, if you are a developer who would like to volunteer as a mentor, please contact us. First year volunteers will generally be teamed up with experienced mentors, so don’t worry about not having previous experience. If you’re interested, you can read more about mentoring expectations in the GSoC mentoring Guide. -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: coreboot changelog Feb 17 - March 1
A new post titled "coreboot changelog Feb 17 - March 1" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/03/06/coreboot-changelog-feb-17-march-1/ This changelog covers 105 commits in the two week period between February 17, 2016 and March 1, 2016. (6a622311 – 163506a8) We’ve entered a lower volume period for patches being submitted, so for a while, blog posts will be every two weeks instead of every week. Once we get above 100 patches a week, blog posts will be weekly again. Payloads got some attention during this period, adding a way to include additional modules into the GRUB2 build. An option was added to build and include coreinfo as a ‘secondary’ payload, allowing it to be run from another payload. We also added U-Boot as a coreboot payload. This is currently still just in development, and needs additional work before it will act as a generic payload for all platforms. We added LZ4 compression to the build with runtime decompression for cbfs. LZ4’s speed should be roughly the same as LZMA, trading a smaller compressed size for slightly slower decompressoin. LZ4’s main advantage is that it requires much less memory to do the decompression, allowing for compression of stages that couldn’t previously be compressed. The suite of board-status scripts got several updates, fixing timestamp handling for the sanitized path names, handling when the script is run as super-user in a better way, and adding a script that will set up a Ubuntu Live-image to allow users to more easily run the board-status script. In the build tools and utilities, we had some fixes for the toolchain builder, updating the GDB builds for x86_64 and MIPS. A couple of scripts were also added. One utility downloads and extracts binary blobs from Chrome OS recovery images, and the other new script allow easier testing of POST cards. Intel based boards and chipsets received a large percentage of the patches for the past two weeks: The Galileo board and Quark chip had several pieces new added, along with additional documentation for those changes. Major pieces done were to set up the basic registers, in the ACPI FADT, setting up the memory map, and enabling the UART. We received the final set of patches to finish out the changes combining many of the the Intel GPIO initialization routines into a single common set of functions. The autoport script was updated to use the common GPIO functions. Sandy Bridge / Ivy Bridge memory initialization also continued to receive updates, adding support for XMP profiles in the SPD, updating logging, and fixing some bugs. Intel’s Skylake chipset and boards were updated to enable Hardware P-state control (HWP) based on Intel’s Speed Shift Technology (SST). Another change to Skylake platforms increased stolen memory for graphics to 64MB. Intel Bay Trail got a couple of updates, adding a fix for issues with displayport on the FSP version, and adding IOSF access support to the reg_script module. Intel Apollo Lake had several more foundational pieces added to the codebase. Many more patches for Apollo Lake are expected in the next couple of weeks. On the non-X86 side, the instructions for running the Arm7 Qemu board were updated, and the memory map was corrected. RISC-V got a couple of patches, adding additional debugging, and fixing some inline asm code. The coreboot project would like to recognize another pair of developers who have hit major milestones in the past two weeks: Lee Leahy just reached his 100th commit merged into coreboot.org. Lee is a developer with Intel who has been working on coreboot for about a year and a half. He has worked on many of the recent intel chipsets, and is currently adding support and documentation for the Intel Galileo board and Quark chips in a way that each step of the process can be tested and verified. While this takes significantly more effort than the typical method of porting, it should result in a better platform. Tobias Diedrich has just had his 50th patch merged. Tobias has been contributing patches to coreboot for over five years, and his patches have spanned a number of boards and chipsets. Finally, please welcome our newest authors: – Andrew Waterman contributed the pair of RISC-V patches. – Joe Pillow added the Chrome OS recovery image script. coreboot statistics - Total commits: 105 - Total authors: 25 - Total lines added: 13396 - Total lines removed: -3127 - Total difference: 10269 Added 1 mainboard: emulation/qemu-power8 Added 1 processor: qemu-power8 Submodule updates: - 3rdparty/arm-trusted-firmware (329 commits) - 3rdparty/vboot (2 commits) === Top Authors - Number of commits === Leroy P Leahy20 (19.048%) Aaron Durbin 11 (10.476%) Patrick Rudolph 8 (7.619%) Patrick Georgi8 (7.619%) Martin Roth 8 (7.619%) Stefan Reinauer 5 (4.762%) Vladimir Serbinenko 5 (4.762%) Denis 'GNUtoo' Carikli4 (3.810%)
[coreboot] New on blogs.coreboot.org: coreboot changelog Feb 10 - Feb 16
A new post titled "coreboot changelog Feb 10 - Feb 16" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/02/18/coreboot-changelog-feb-10-feb-16/ This changelog covers 77 commits in the week between February 10, 2016 and February 16, 2016. (318ef96a – 0188b139) Many of the big changes this week surrounded native initialization of the Sandybridge/Ivybridge platforms. We got patches to change platforms which had been previously based on Intel’s MRC blob to build with either the MRC or coreboot’s native memory initialization. We also got patches combining the Intel GPIO initialization for various chipsets into a single common set of functions. Continuing the series from the past several weeks, we merged patches for the Intel Apollo Lake, Skylake, and Quark platforms. Apollo Lake got a skeleton for its initial mainboard, and added code to support GPIO init. Quark added FSP initialization and MTRR support. The more mature Skylake SoC received some minor fixes for graphics and to finalize SMM inside coreboot. Another of the Intel FSP platforms, the FSP version of the Intel Bay Trail codebase was updated to support version 5 of the Bay Trail FSP, which should be released to the Intel website shortly. On the ARM side, we got several small fixes, and a patch to verify consistency of the page table descriptors. This sounds like it will help prevent ‘interesting’ debug sessions due to conflicting memory types for the same memory area. The build system and toolchain received fixes for issues downloading git submodules, for the gitconfig make target, and for building under paths that have an ‘@’ character in their name. A couple of changes were added to make Kconfig’s strict mode slightly less strict and more user friendly. Two new lint tools were added this week, one to make sure that the site-local directory doesn’t get pushed and committed, and another that checks over the Kconfig files for various issues. Other changes this week included a change to allow bootblock code to use CAR_GLOBAL variables, and continued work updating and adding license headers throughout the coreboot codebase. Finally, I’d like to recognize two contributors this week: Damien Zammit (damo22) reached his 50th commit merged into coreboot last week. His contributions have included the addition of two complete platforms, the Intel D510MO board with the Intel Pineview Atom processor, and the Gigabyte GA-G41M-ES2L board with the Intel x4x northbridge and Intel i82801gx southbridge. Damien joined coreboot in July of 2013, but has recently become very active. Vladimir Serbinenko (phcoder) just broke 550 patches merged with his work moving Sandybridge/Ivybridge MRC platforms to native init mentioned earlier. Vladimir joined coreboot just under 3 years ago, and has been a fantastic contributor to the community. Thanks to both of you, and to all the rest of the coreboot contributors. coreboot statistics - Total commits: 77 - Total authors: 16 - Total Commits: 77 - Total lines added: 6494 - Total lines removed: -1569 - Total difference: 4925 Added 1 mainboard: intel/apollolake_rvp === Top Authors - Number of commits === Patrick Georgi 12 (15.584%) Vladimir Serbinenko 12 (15.584%) Aaron Durbin 9 (11.688%) Julius Werner 7 (9.091%) Andrey Petrov 6 (7.792%) Duncan Laurie 5 (6.494%) Martin Roth 5 (6.494%) Leroy P Leahy 4 (5.195%) Alexandru Gagniuc 3 (3.896%) Patrick Rudolph 3 (3.896%) Yves Roth 3 (3.896%) Stefan Reinauer 3 (3.896%) === Top Authors - Lines added === Ruilin Hao 2528 (38.928%) Andrey Petrov 817 (12.581%) Vladimir Serbinenko 681 (10.487%) Yves Roth 678 (10.440%) Leroy P Leahy 451 (6.945%) Patrick Rudolph 355 (5.467%) Alexandru Gagniuc 242 (3.727%) Aaron Durbin213 (3.280%) Patrick Georgi 194 (2.987%) Julius Werner 131 (2.017%) === Top Authors - Lines removed === Vladimir Serbinenko 892 (56.851%) Aaron Durbin247 (15.743%) Julius Werner 244 (15.551%) Patrick Georgi 68 (4.334%) Yves Roth64 (4.079%) Martin Roth 13 (0.829%) Duncan Laurie12 (0.765%) Patrick Rudolph 11 (0.701%) Andrey Petrov 7 (0.446%) Ruilin Hao4 (0.255%) === Top Reviewers - Number of patches reviewed === Martin Roth 31 (40.260%) Aaron Durbin 16 (20.779%) Patrick Georgi 13 (16.883%) Paul Menzel 13 (16.883%) Alexandru Gagniuc12 (15.584%) Stefan Reinauer 11 (14.286%) FEI WANG 3 (3.896%) York Yang 2 (2.597%) Andrey Petrov 2
[coreboot] New on blogs.coreboot.org: coreboot changelog Feb 3 - Feb 9
A new post titled "coreboot changelog Feb 3 - Feb 9" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/02/11/coreboot-changelog-feb-3-feb-9/ This changelog covers 107 commits in the week between February 3, 2016 and February 9, 2016. (2cc2ff6f – c285b30b) This week, it looks like the biggest set of changes were the changes directly supporting chrome verified boot, adding options for the GBB flags and supporting VBNV (vboot non-volatile storage) in cmos, flash, and the EC. The verified boot (vboot) submodule included by coreboot was also updated, bringing in another 26 patches. These changes included a variety of work committed to the chromium vboot repo over the past several months. Another submodule was added this week to bring the Chrome EC codebase into the coreboot tree. There were several additional commits to update the build to use the new submodule. The Intel Skylake and associated boards continued to get updates including more GPIO fixes, disabling the PM timer in ACPI, and unconditionally setting up the BAR for the SPI controller. Intel continued adding documentation in the Documentation/Intel directory. This is mostly targeting the newly added Galileo mainboard, the newly added Quark X1000 Soc, and version 1.1 of the Intel FSP. The AMD Family 10h / Family 15h directory and mainboard got some more patches, updating the RDIMM memory training code to work around some failures. The other main feature added was a CMOS option to enable/disable core boost. There were a number of ACPI ASL changes this week. Several were bugfixes, some were to get rid of unused variables causing warning, and others worked around different warnings generated by new versions of the IASL ACPI compiler. These will help the effort to upgrade the IASL ACPI compiler to the latest version. The native memory initialization code for the Intel Sandybridge/Ivybridge platforms had a fix for using two DIMMs per channel, and there were a few changes working towards switching the MRC based Sandybridge/Ivybridge implementations over to using native graphics and memory initialization. The goal is that the boards that currently use the Intel MRC should be able to build with either path. More of these changes will be merged in the coming weeks. The toolchain builder, buildgcc, had several changes to clean up and reorganize the makefiles, and to add a toolchain build for the nds32le architecture in support of the chrome EC builds. coreboot’s site-local directory was extended to use a Kconfig file and adds a make target which gets run at the end of the rest of the build. Documentation on how to use this should be completed and released next week. Miscellaneous other fixes include a new lint test ensuring assembly is in AT syntax, an update to the QT version for the ‘xconfig’ Kconfig front end, adding PS/2 Aux presence detect to the nuvoton nct5572d SuperIO, and adding a new ARM SoC, Marvell’s Armada 38x. Thank you to everyone who contributes to the coreboot community. New issues that we saw this week – The toolchain build seems to be broken for some people as of commit 8e68aff51 – “buildgcc: enable multilib for gcc” – There were issues with make gitconfig on a newly cloned repo caused by commit ec0b586 – “3rdparty/chromeec: Add Chrome EC firmware sources”. – Commit ec0b586 – “3rdparty/chromeec: Add Chrome EC firmware sources” also causes issues pulling down the blobs submodule. New bugs filed this week – board-status allows invalid uploads – Windows doesn’t like ToString() calls in ACPI – [Haswell/Broadwell] LPC power optimizer RCBA instructions break eDP display with Intel VBIOS – cbmem utility fails on newer linux kernels “Failed to mmap /dev/mem: Resource temporarily unavailable” – Provide and use enums for SerialIoI2cVoltage coreboot statistics for the past week - Total commits: 107 - New authors: 3 - Total authors: 24 - Reviewers on submitted patches: 11 - Total lines added: 13759 - Total lines removed: -1974 - Total difference: 11785 Added 2 mainboards: asus/kcma-d8 & intel/galileo Added 1 mainboard variant: lenovo/X220i Added 2 SoCs: intel/quark & marvell/armada38x === Top Authors - Number of commits === Leroy P Leahy15 (14.019%) Patrick Georgi 15 (14.019%) Aaron Durbin 14 (13.084%) Vladimir Serbinenko 10 (9.346%) Timothy Pearson 8 (7.477%) Duncan Laurie 7 (6.542%) Martin Roth 6 (5.607%) Stefan Reinauer 6 (5.607%) Ruilin Hao5 (4.673%) Total Authors: 25 === Top Authors - Lines added === Timothy Pearson3956 (28.752%) Ruilin Hao 2964 (21.542%) Leroy P Leahy 2780 (20.205%) Duncan Laurie 1091 (7.929%) Zheng Bao 463 (3.365%) Dhaval Sharma 450 (3.271%) Patrick Georgi 397 (2.885%) Aaron Durbin397 (2.885%) Lee Leahy 346
[coreboot] New on blogs.coreboot.org: coreboot changelog Jan 27 – Feb 2
A new post titled "coreboot changelog Jan 27 – Feb 2" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/02/03/coreboot-changelog-jan-27-feb-2/ This changelog covers 131 commits in the week between January 27, 2016 and February 2, 2016. (dd4b66e2 – 95909924) The biggest news of the past week was getting the 4.3 release done. The 4.4 release should come towards the end of April. Of particular note to anyone submitting patches, we added 2 new code checkers this week, one to verify that the executable bit isn’t set on source files, and one to verify that the standard coreboot license header is used on files using the GPL 2 or 2+ licenses. These checks will be run automatically when you commit code if you have the git commit hook in place, and will also be run on the build server. coreboot again had numerous patches surrounding the build system, tools, and utilities. The flood of cbfstool related patches finally slowed a bit, but we still had some cleanup, both in the tool and in the cbfs sections of the Makefiles. In the toolchain area, we updated LLVM to version 3.7.1, and added GNU Make to the toolchain. The addition of make was to address some upcoming patches that needed the newer version, as well as to support platforms that don’t install GNU make by default. The kconfig_lint tool had various updates to get rid of warnings that we don’t care about, to add documentation, and to add a couple of additional checks. Next week will see a few more fixes, and it will be put in place as a stable lint tool. We had significant updates to a number of mainboards and the related chipsets in the past week as well. Intel had a large number of changes for their Braswell SoC and its reference board, Strago, merged this week. These included fixes for GPIOs, clocks, SD cards, and thermal support, as well as FSP integration updates. The Asus kgpe-d16 mainboard, along with the AMD Fam10h-Fam15h processor directory and the SB700 soutbridge had numerous patches to improve stability, fix IRQ routing and APIC identification, and improve ACPI. The winbond w83667hg-a was added to the coreboot codebase for the board as well. The Intel d510mo board had some improvements related to native graphics initialization, GPIOs and ACPI. The gigabyte ga-g41m-es2l and the Intel x4x northbridge code had some general cleanup and improvements to cbmem and memory initialization. We also saw the introduction of the initial framework for the new Intel Apollo Lake SoC. We’ll be seeing many more patches related to Apollo Lake in the coming weeks. Other changes of note included code to initialize the PS/2 aux port, a way to access memory address 0 without GCC “optimizing” it into a crash, and the addition of some documentation from Intel about developing new FSP based boards and chipsets. Finally, the Intel sklrvp Skylake reference board was dropped in favor of using the kunimitsu board. coreboot statistics for the past week - Total commits: 131 - New authors: 8 - Total authors: 30 - Total lines added: 3833 - Total lines removed: -3652 - Delta: 181 === Top Authors - Number of commits === Timothy Pearson 22 (16.794%) Martin Roth 21 (16.031%) Patrick Georgi 15 (11.450%) Damien Zammit13 (9.924%) Hannah Williams 12 (9.160%) Leroy P Leahy 5 (3.817%) Stefan Reinauer 5 (3.817%) Divagar Mohandass 4 (3.053%) Vladimir Serbinenko 3 (2.290%) Alexandru Gagniuc 3 (2.290%) Total Authors: 31 === Top Authors - Lines added === Damien Zammit 725 (18.915%) Timothy Pearson 701 (18.289%) Leroy P Leahy 646 (16.854%) Subrata Banik 427 (11.140%) Martin Roth 262 (6.835%) Aaron Durbin204 (5.322%) Patrick Georgi 179 (4.670%) Alexandru Gagniuc 140 (3.652%) shkim 107 (2.792%) Nico Huber 91 (2.374%) === Top Authors - Lines removed === Martin Roth1688 (46.221%) Hannah Williams 661 (18.100%) Divagar Mohandass 315 (8.625%) Damien Zammit 307 (8.406%) Timothy Pearson 212 (5.805%) Patrick Georgi 104 (2.848%) Nico Huber 102 (2.793%) Leroy P Leahy95 (2.601%) Stefan Reinauer 43 (1.177%) Lee Leahy23 (0.630%) === Top Reviewers - Number of patches reviewed === Martin Roth 71 (54.198%) Stefan Reinauer 20 (15.267%) Patrick Georgi 18 (13.740%) Paul Menzel 16 (12.214%) Alexandru Gagniuc14 (10.687%) Aaron Durbin 10 (7.634%) Felix Held8 (6.107%) Timothy Pearson 7 (5.344%) Nico Huber4 (3.053%) Alexander Couzens 3 (2.290%) Total Reviewers: 15 === Top Submitters - Number of
[coreboot] New on blogs.coreboot.org: Announcing coreboot 4.3
A new post titled "Announcing coreboot 4.3" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/01/29/announcing-coreboot-4-3/ Dear coreboot community, today marks the release of coreboot 4.3, the third release on our time based release schedule. Since the last release, 1030 commits by 114 authors added a net total of 17500 lines to the source code. Thank you to all who contributed! The release tarballs are available at http://www.coreboot.org/releases/. There’s also a 4.3 tag and branch in the git repository. Besides the usual addition of new mainboards (14) and chipsets (various), a big theme of the development since 4.2 was cleaning up the code: 20 mainboards were removed that aren’t on the market for years (and even hard to get on Ebay). For several parts of the tree, we established tighter controls, making errors out of what were warnings (and cleaning up the code to match) and provided better tests for various aspects of the tree, and in general tried to establish a more consistent structure across the code base. Besides that, we had various improvements across the tree, each important when using the hardware, but to numerous for individual shout outs. Martin compiled a list that’s best posted verbatim. Thanks Martin! Log of commit 529fd81f640fa514ea4c443dd561086e7c582a64 to commit 1bf5e6409678d04fd15f9625460078853118521c for a total of 1030 commits: Mainboards Added 14 mainboards – asus/kfsn4-dre_k8: Native init Dual AMD K8 CPUs & Nvidia CK804 southbridge – esd/atom15: Bay Trail SOC mainboard using Intel’s FSP – gigabyte/ga-g41m-es2l: Intel Core 2 / Native init x4x NB / I82801GX SB – google/guado: Intel Broadwell chromebox (Asus Chromebox CN62) – google/oak: Mediatek MT8173 SoC chromebook – google/tidus: Intel Broadwell chromebox (Lenovo ThinkCentre Chromebox) – google/veyron_emile: Rockchip RK3288 SoC board – intel/d510mo: Native init Intel Pineview with Intel I82801GX southbridge – intel/littleplains: Intel Atom c2000 (Rangeley) SoC board – intel/stargo2: Intel Ivy Bridge / Cave Creek usint Intel’s FSP – lenovo/r400: Intel Core 2 / Native init GM45 NB / Intel I82801IX SB – lenovo/t500: Intel Core 2 / Native init GM45 NB / Intel I82801IX SB – purism/librem13: Intel Broadwell Laptop using Intel MRC – sunw/ultra40m2: Native init Dual AMD K8 Processors & Nvidia MCP55 SB Removed 20 mainboards – arima/hdama – digitallogic/adl855pc – ibm/e325, e326 – intel/sklrvp – iwill/dk8s2, dk8x – newisys/khepri – tyan/s2735, s2850, s2875, s2880, s2881 & s2882 – tyan/s2885, s2891, s2892, s2895, s4880 & s4882 Improvements to mainboards – amd/bettong: fixes to Interrupts, Memory config, S4, EMMC, UARTS – asus/kgpe-d16: IOMMU and memory fixes, Add CMOS options, Enable GART – intel/strago: GPIO, DDR, & SD config, FSP updates, Clock fixes – ACPI fixes across various platforms – Many individual fixes to other mainboards Continued updates for the Intel Skylake platform – google/chell, glados, & lars: FSP & Memory updates, Add Fan & NHLT support – intel/kunimitsu: FSP & GPIO updates, Add Fan & NHLT (audio) support Build system – Update build to use FMAP based firmware layout with multiple cbfs sections – Enable Kconfig strict mode – Kconfig warnings are no longer allowed. – Enable ACPI warnings are errors in IASL – warnings are no longer allowed. – Tighten checking on toolchains and give feedback to users if there are issues – Updates to get the ADA compiler to work correctly for coreboot – Various improvements to Makefiles and build scripts – Cleanup of CBFS file handling Utilities – cleanups and improvements to many of the utilities – cbfstool: Many fixes and extensions to integrate with FMAP – Add amdfwtool to combine AMD firmware blobs instead of using shell scripts. – Toolchain updates: new versions of GMP & MPFR. Add ADA. – Updates for building on NetBSD & OS X Payloads – SeaBIOS: Update stable release to 1.9.0 – coreinfo: fix date, hide cursor, use crosscompiler to build – libpayload: updates for cbfs, XHCI and DesignWare HCD controllers ARM – Added 1 soc: mediatek/mt8173 – Various fixes for ARM64 platforms X86 – Added 2 northbridges: intel/pineview & x4x – Removed 1 northbridge: intel/i440lx – Added 1 southbridge: intel/fsp_i89xx – Removed 2 southbridge(s): intel/esb6300 & i82801cx – Rename amd/model_10xxx to family_10h-family_15h. – ACPI: fix warnings, Add functions for IVRS, DMAR I/O-APIC and HPET entries – Work in many areas fixing issues compiling in 64-bit – Numerous other fixes across the tree Areas with significant work on updates and fixes – cpu/amd/model_fxx – intel/fsp1_x: Fix timestanps & postcodes, add native CAR & microcode – nb/amd/amdfam10: Add S3, voltage & ACPI, speed fixes & MANY other changes – nb/amd/amdmct: Add S3, mem voltage, Fix performance & MANY other changes – nb/intel/sandybridge: Add IOMMU & ACPI DMAR support, Memory cleanup – soc/intel/braswell: FSP & ACPI updates, GPIO & clock Fixes – soc/intel/fsp_baytrail: GPIO, microcode and Interrupt
[coreboot] New on blogs.coreboot.org: coreboot changelog Jan 5 - Jan 24
A new post titled "coreboot changelog Jan 5 - Jan 24" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/01/20/coreboot-changelog-jan-5-jan-24/ This changelog covers the 180 commits between January 5, 2016 and January 19, 2016. (af91b8b0 – 967881d0) We’re preparing for the coreboot 4.3 release, expected to happen sometime in the next week, so there has been a lot of activity surrounding Intel’s Skylake chips, both in the mainboards and SOC directories. The Skylake and braswell platforms are finally being build-tested by jenkins, which will help keep the platforms working. The changes in cbfstool are continuing to roll in, although this should be wrapping up before long as the merger of cbfs with FMAP is completed. The effort to standardize coreboot’s license headers across all files is just starting, and will be going on for a few weeks as we verify that all source files have the correct headers. We’ve added and improved the lint checkers for these so expect failures from jenkins if files with non-compliant headers are pushed. A fair amount of work was done in the build system in the past couple of weeks. This removed the warnings about cross compilers not existing unless that architecture is currently being built, fixed some dependency issues, and fixed several other minor issues. A make target to check that the coreboot toolchain was also added. We had a slight toolchain change, going to MPFR version 3.1.3 to fix some issues seen on the upcoming Power8 processor. Additional changes added NetBSD support for various utilities, and update the intel/gm45 and intel/pineview northbridges. Added 1 mainboard: ——- – google/guado coreboot statistics ——- – Total commits: 180 – New authors: 13 – Total authors: 45 – Total reviwewrs: 19 – Total lines added: 9168 – Total lines removed: -2130 – Total difference: 7038 === Authors – Number of commits === Martin Roth 56 (31.111%) David Wu 15 (8.333%) Aaron Durbin 12 (6.667%) Duncan Laurie 9 (5.000%) Subrata Banik 8 (4.444%) Rizwan Qureshi 7 (3.889%) Nico Huber 6 (3.333%) Patrick Georgi 6 (3.333%) Timothy Pearson 5 (2.778%) Barnali Sarkar 5 (2.778%) Total Authors: 45 === Authors – Lines added === Martin Roth 2359 (25.731%) Matt DeVillier 2243 (24.466%) Aaron Durbin 1988 (21.684%) Rizwan Qureshi 606 (6.610%) Subrata Banik 292 (3.185%) Barnali Sarkar 178 (1.942%) robbie zhang 158 (1.723%) Nico Huber 144 (1.571%) Andrey Korolyov 133 (1.451%) David Wu 128 (1.396%) === Authors – Lines removed === Martin Roth 1038 (48.732%) Barnali Sarkar 173 (8.122%) Aaron Durbin 144 (6.761%) Nico Huber 108 (5.070%) Patrick Georgi 98 (4.601%) Shaunak Saha 81 (3.803%) Paul Menzel 69 (3.239%) Patrick Rudolph 68 (3.192%) Subrata Banik 64 (3.005%) Duncan Laurie 61 (2.864%) === Reviewers – Number of patches reviewed === Martin Roth 91 (50.556%) Stefan Reinauer 43 (23.889%) Patrick Georgi 43 (23.889%) Paul Menzel 23 (12.778%) Alexandru Gagniuc 13 (7.222%) Nico Huber 7 (3.889%) York Yang 3 (1.667%) Werner Zeh 3 (1.667%) Aaron Durbin 3 (1.667%) Total Reviewers: 19 === Submitters – Number of patches submitted === Martin Roth 89 (49.444%) Patrick Georgi 73 (40.556%) Aaron Durbin 9 (5.000%) Stefan Reinauer 4 (2.222%) Vladimir Serbinenko 3 (1.667%) Werner Zeh 1 (0.556%) Nico Huber 1 (0.556%) Total Submitters: 7 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: coreboot changelog
A new post titled "coreboot changelog" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/11/23/coreboot-changelog-6/ The week leading up to November 15th has seen 132 commits (8bd1c36..3ca4116). The leading themes were the removal of support for old mainboards, and the integration of more non-AGESA AMD support code for Family 10h to 15h that spans everything from fixes to memory configuration to workarounds to problems in the SATA controller, to new feature development, enabling CC6 power-state support and everything in-between. Other chipset level contributions provided bug fixes to the drivers supporting Intel’s Skylake and AMD’s newer chipsets and mainboards (Kabini, Merlin Falcon, Mullins). Rockchip RK3288 now properly configures displays whether they’re connected through HDMI or DVI. ARM/ARM64 saw some cleanup in its transition between stages to accommodate more processor configurations on ARM64 SoCs (that sometimes come with smaller 32bit cores for supporting purposes). Also new is the Intel i8900 southbridge support that can be used with Sandy Bridge and Ivy Bridge, with an Intel reference board, the stargo2, and the SUNW Ultra40m2 board support. The USB device mode driver for DesignWare’s USB2 controller (DWC2) in libpayload became more robust. The other notable field of work in libpayload is work with PDcurses’ upstream to synchronize their development and our copy. In terms of the ongoing efforts to clean up old cruft across the entire tree, references to the getpir utility were dropped, after the tool was removed nearly two years ago. We also removed empty mainboard driver files that used to be required by the build system, even if the mainboard needed no special handling in its ramstage. To help keep the quality bar high, automated testing now also covers intelvbttool. Another forward-looking addition is a clang-format specification of our coding style. It isn’t complete yet, but the hope is that we can eventually use it to simplify adhering to a consistent style and then enforce it. The script to help organizing the commit log for release notes was pushed into util/release. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: coreboot changelog
A new post titled "coreboot changelog" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/11/10/coreboot-changelog-5/ This changelog covers the week up to November 8th, spanning 63 commits (f6dc544..8bd1c36). Last week’s code submissions gave us a lot of improvements pretty much everywhere, but the most user-visible change is probably the addition of ACPI S3 support to asrock/e350m1. Speaking of ACPI, support for the DMAR tables used to report Intel IOMMU (VT-d) information to the operating system was significantly improved and is enabled on Sandy Bridge and Ivy Bridge. Another user visible change is the rework of the fallback mechanism in our bootblock, making its CMOS-backed state handling more robust. cbmem also saw some changes in that all its entries are now listed separately in cbtables (and util/cbmem uses that new structure) to cut down on what coreboot exposes as interface. On the architectures side, ARM64 dropped its sec(urity) mon(itor) code in favor of using ARM Ltd’s Open Source arm-trusted-firmware, which we already import in 3rdparty. The integration of commits to support AMD Fam15h CPUs with a non-AGESA implementation that integrates better with coreboot saw some progress. The AMD Binary PI side saw a number of bug fixes, too. Boards based on Intel’s Skylake architecture also saw more development. In addition to these targetted developments, there was also the usual set of bug fixes across the entire tree, providing some cleanups to the code and configuration system, some portability fixes for Windows and Mac OS X, deduplication of ACPI table generation on i945, and the removal of a Super IO that wasn’t used by any board (and thus isn’t even build tested). The USB device mode driver in libpayload for the DesignWare USB2 controller works better under debugging, while the XHCI USB3 host controller driver gained a workaround for Intel XHCI controllers. Finally, the board-status scripts that parse boot success reports into the list of supported motherboards on the wiki were modified to point out more clearly that the list on the wiki describes the current status. This became necessary because some users assumed that it’s outdated. Since the i440bx mainboards that were at the top of the list may have contributed to that impression, desktop boards were moved down in favor of notebooks and server boards where most of the current development happens. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: coreboot changelog
A new post titled "coreboot changelog" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/11/05/coreboot-changelog-4/ This changelog covers 2 weeks up to November 1st, during which coreboot-4.2 was released. In that timeframe, the repository saw 214 commits spanning d98471c..f6dc544. Before we get to the stuff that the tech media gets excited about, the first thing to report about is a bunch of efforts to improve the reliability of our tree and the automated testing we conduct. abuild, the utility for automatically building the default configuration of every board in the tree, learned to deal with mainboard directories that cover multiple variants of a board. This brings back build test coverage for google/veyron. Various programs in the util/ hierarchy of the tree are now automatically tested by our build test infrastructure, and the related code saw some refactoring to make testing more tools really simple. During that development, some Makefiles below util/ were also cleaned up. Another area of clean ups was the conversion of `#ifdef` statements to using the `IS_ENABLED` macro. This ensures that even unused code paths are syntactically validated before the optimizer drops them, leading to the same binary output with better build test coverage. In preparation of future improvements, we gained a lint tool for Kconfig files. It will be hooked up to the build system once the tree is clean, until then it provides a way to see what’s still missing. Check out `util/lint/kconfig_lint` if you’re curious. As a proof of concept, util/fuzz-tests now provides an environment to test the jpeg decoder we ship for splash screens using [afl-fuzz](http://lcamtuf.coredump.cx/afl/). The same approach can be applied to other coreboot components to find potential crash bugs (or worse). Finally, several chip drivers were removed because they had no user in the tree anymore and thus saw no testing at all. Some of them will likely come back together with new mainboards that use them. In addition to the code development to improve code quality, `util/scripts/maintainers.go` provides a way to query the MAINTAINERS database that we’re building, as one piece of a larger effort to improve code quality through formal submodule maintainership. Another formal clean-up was the tree-wide removal of the last paragraph of the GPL license header in files, the one denoting where to obtain the license text. First, we ship it in the tree, second, it’s probably easier to get with a quick search engine request than by writing a letter to a US post address that may or may not be current. Rockchip’s RK3288 gained support for additional power/clock states and a more robust EDID handling. The ongoing effort to support booting in long mode (64 bit) on AMD64 progressed by the integration of changes to make SMM handling and AMD chipset drivers 64bit clean. Some ACPI for older Intel chipsets was consolidated and is now used for multiple chipset generations. The Intel GMA driver has also seen improvements, allowing brightness levels for laptop panels to be configured per board, and to disable the graphics chip entirely. In terms of drivers, the aspeed driver provides native VGA text, and there were improvements to superio and i2c chip drivers, supporting more of their features. Sandybridge now initializes CPUs serially for robustness reasons, and Intel FSP supports loading microcode from coreboot. cbfstool now extracts stages and rmodules as ELF files, including relocation information for the former, so that roundtrips of add-stage/extract/add-stage become possible. It now also compiles more reliably on Cygwin. libpayload saw the additional of a graphics library to layout images on a framebuffer using framebuffer independent coordinates, and some bug fixes to its USB drivers. In addition to all those cleanups and little new features, coreboot also provides support for a couple new boards, in particular two Intel Skylake based boards by Google (google/chell and google/lars) as well as Asus KFSN4-DRE with K8 CPUs and Asus KGPE-D16 with more recent AMD CPUs (Fam10h and Fam15h). All related chipsets also saw significant improvements, of which the still ongoing effort to provide non-AGESA implementations for the Fam15h CPU, as well as a ton (metric, in case you’re curious) of bugfixes and feature developments (for example Suspend to RAM) for all AMD CPUs starting with K8 is particularly notable. Besides those changes, and minor (but valuable) contributions to improve the code style, there’s a bucket list of improvements across the entire tree: more robust SMM entry on i945, fixes to our SMBIOS table generation, changes to the resource allocator to become more robust and IOMMU friendly and to measure the time it takes, and improvements to the robustness of our build process. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: coreboot changelog
A new post titled "coreboot changelog" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/10/22/coreboot-changelog-3/ This report covers commits b66d673..d98471c, the week up to Sunday, 2015-10-18 This week has an interesting distribution in its commits: A few very large and impactful commits (and commit sets), but otherwise lots of tiny little things. The last months typically saw more cohesive changes each week, affecting a small number of subsystems or drivers – but not this week. The biggest item in terms of code size was the reintroduction of Intel’s Rangeley SoC and related mainboard, which were found to still be requested by users after all. The biggest item in terms of impact was probably the improvement of our automated build testing by adding our lint tests and build tests for various utilities to our build infrastructure, reporting any errors (and preventing them from creeping into the master branch). We don’t test all tools yet, but adding the others should be painless now. libpayload also gained a new test configuration so both libcurses implementations are now covered. The vboot verstage concept was ported to x86 and added to FSP 1.1, allowing a separate verification stage to check romstage before executing it (from a potentially unsafe location). AMD microcode can now be loaded from CBFS, and using their standard format instead of a custom layout that was used by coreboot until now. Apart from these, changes happened all across the tree: SMBIOS tables report memory vendors; ACPI was cleaned up to work better with new ACPI compiler versions; there’s better reporting for MTRR configurations, and related macros have more sensible names; the ARMv7 code avoids miscompilation with gcc-5.2, which is significant because that’s our standard compiler version; Intel GMA ACPI saw improvements; there were tons of style fixes in preparation to deal with the addition of lint tests to the automated tests; cbfstool can now add files after files of the same name were removed from an image; the coreinfo payload has the sense to reboot after it’s done; the cbmem utility is more robust, and several more cleanups and bugfixes. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: 2015-08-28 Librem 13: Weekly BIOS Update
A new post titled "2015-08-28 Librem 13: Weekly BIOS Update" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/09/02/2015-08-28-librem-13-weekly-bios-update/ Author: larry.mob...@puri.sm This post gives some details on the Librem 15 rev2 prototype. One challenge with developing BIOS is finding parts that can be reused; coreboot makes heavy reuse of certain pieces of code. Very Similar Starting with the chips on the back of the mainboard, the 15 prototype uses the same ene KB3930QF-A1 as the Librem 13, and it is configured to read from an external Macronix MX25L512 SPI flash for firmware. The 15 has this SPI chip on the front side of the board between the DIMMs and the USB3 ports. The 15 prototype uses a Realtek ALC269 codec via the AC’97. The Librem 13 should have a very similar codec. On the front (the side visible just by removing the back laptop case), the 15 prototype uses an MX25L6406E SPI flash for the BIOS. The Librem 13 prototype uses a GD25Q64B, but other than the Intel Firmware Descriptor fields for JEDEC ID etc, these chips are interchangeable. Both CPUs are Broadwell-U. They use the same FSP. They both have the LPC bus exposed on pads. These similarities help us by reducing the amount of variation between the board subdirs in coreboot and can use the same development rig. Acceptance Test Matrix We’ve put together the following tests to validate coreboot builds: Cold boot: memory controller works. Cold boot: all installed DRAM is online. Cold boot: graphics controller works. Cold boot: SATA controller succeeds. Cold boot: EC controller responds ok to init code. Cold boot: LCD backlight turns on. Cold boot: linux boots ok in text mode. Cold boot: linux boots ok in framebuffer (boot splash) mode. Cold boot: X initializes the LCD at full native resolution. Cold boot: X enables hardware acceleration. Boot time: Cold boot to grub succeeds in less than a set timeout. Boot time: Reboot from linux back to linux succeeds in less than a set timeout. Boot time: Power down succeeds in less than a set timeout. SeaBIOS test: keyboard works. Grub test: keyboard works. Grub test: text mode and framebuffer graphics work. Cold boot to USB linux succeeds. (We plan to use SeaBIOS for boot device selection, barring major bugs.) Reboot to USB linux succeeds. EC test: fan spins. EC test: holding power for >5 seconds forces a power down. ACPI test: lid switch works. ACPI test: power button event received ok. ACPI test: AC power on/off event received ok. ACPI+EC+battery test: battery percentage works. Media keys on keyboard work in linux. Device tests: internal mic, internal speakers, webcam, webcam mic, wifi, bluetooth, hard drive, SSD, SD card, each USB port, headphone jack. prime95 (one instance bound to each hyperthread) for a fixed time to test CPU thermal management. glxgears for a fixed time to test GPU thermal management. During prime95 test, CPU digital thermal sensor should give reasonable results. Linux suspend ok. LCD backlight adjustable in linux. Linux kernel boot messages should not contain too many errors. The effort to write Free Software implementations for all binary blobs will continue in parallel. Secondary items would include further tweaks to PCI IRQ routing, additional ACPI tables, and optimizing battery life/power use. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: coreboot changelog – Weeks of 2015-08-10 and 2015-08-17
A new post titled "coreboot changelog – Weeks of 2015-08-10 and 2015-08-17" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/08/29/coreboot-changelog-weeks-of-2015-08-10-and-2015-08-17/ this report covers commits 1cbef1c to 410f9ad The vast majority of changes in these two weeks were upstreamed from Chrome OS and cover work on the Intel Skylake chipset and two mainboards based on it. QEmu and Getac P470 saw a couple of improvements. On AMD, there were some bugfixes to Fam10h concerning VGA memory and SMM initialization. The latter was in response to the Memory Sinkhole vulnerability, although it is as yet unclear if it even affects AMD. Finally, an important memory structure used on pre-AGESA AMD code is now also usable outside Cache-as-RAM. There was more progress on fixing 64bit issues across the codebase. Our reference compiler was updated to gcc 5.2. This became necessary to support an update to the RISC-V specification. Our other tools also saw a couple of improvements: ifdtool now works for descriptors on Skylake and newer platforms. cbfstool saw some refactorings that allow us to extend the format. cbmem now emits the accumulated boot time. In our configuration system, the Kconfig definitions were cleaned up, so that boards dont define symbols that their code never uses, that Chrome OS capable boards define MAINBOARD_HAS_CHROMEOS (which defines the capability) instead of CHROMEOS (which defines that this mode should be used) and that dependencies between Kconfig options become more consistent. There is a pending commit on gerrit to enforce clean dependencies by making errors out of kconfigs warnings, that the latter changes prepare for. On the build system side, it is now possible to build SeaBIOS as part of our build system even with an enabled ccache. The payload config and revision can also be stored in CBFS for better reproducibility. Finally, its possible to override the location from where the vboot source code for Chrome OS-style verified boot is taken from. In libpayload, the non-accelerated memmove implementation now also works with size == 0 (instead of trying to move 4GB), and there were a couple of bug fixes to the DWC2 (some ARM) and XHCI (USB3) controller drivers, including support for the newer XHCI 1.1 specification. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] coreboot for ARM64 Qemu – Week #9 #10
A new post titled "[GSoC] coreboot for ARM64 Qemu – Week #9 #10" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/08/25/gsoc-coreboot-for-arm64-qemu-week-9-10/ In the last post I talked about using aarch64-linux-gnu-gdb and debugging in qemu. In these two weeks I was intensely involved in stepping through gdb, disassembly and in-turn debugging the qemu port. I summarise the major highlights below. Firstly, the correct instruction to invoke qemu is as follows ./aarch64-softmmu/qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine type=virt -nographic -smp 1 -m 2048 -bios ~/coreboot/build coreboot.rom -s -S After invoking gdb, I moved onto tracing the execution of the instructions step by step to determine where and how the code fails. A compendium of the code execution is as follows gdb) target remote :1234 Remote debugging using :1234 (gdb) set disassemble-next-line on (gdb) stepi 0x0980 in ?? () = 0x0980: 02 00 00 14 b 0x988 (gdb) 0x0988 in ?? () = 0x0988: 1a 00 80 d2 mov x26, #0x0 // #0 (gdb) 0x098c in ?? () = 0x098c: 02 00 00 14 b 0x994 (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0x0750 in ?? () = 0x0750: 3f 08 00 71 cmp w1, #0x2 The detailed version can be seen here. The first sign of error can be seen here, where the instruction is 0 and the address is way off. 0x64672d3337303031 in ?? () = 0x64672d3337303031: 00 00 00 00 .inst 0x ; undefined To find insights as to why this is happening, I resorted to tracing in gdb. This can be done by adding the following in the qemu invoke command. This creates a log file in /tmp which can be read to determine suitable information. -d out_asm,in_asm,exec,cpu,int,guest_errors -D /tmp/qemu.log Looking at the disassembly, it can be seen that execution of instructions till 0x784 is correct and it goes bonkers immediately after it. Looking at the trace, this is where the code hangs IN: 0x0784: d65f03c0 ret The ret goes to somewhere bad. So the stack has been blown or it has executed into an area it should have prior to this. Next, I did a objdump on the bootblock.debug file. Relating to the code at this address, it could be determined that the code fails at ret in 00010758 raw_write_sctlr: Next up was determining where the stack gets blown or corrupt. For this, while stepping through each instruction, I looked at the stack pointer. The output here shows the details. Everything seems to function correctly till 0x07a0 (0x07a0: f3 7b 40 a9 ldp x19, x30, [sp] ), then next is 0x07a4: ff 43 00 91 add sp, sp, #0x10 . This is where saved pc goes corrupt. This code gets called in the raw_write_sctlr_current (using objdump) From the trace, we have the following information : The ret goes bad at 00010758 raw_write_sctlr: 0x0908: 97fffe06 bl #-0x7e8 (addr 0x120) 0x0120: 3800a017 sturb w23, [x0, #10] 0x0124: 001c00d5 unallocated (Unallocated) Taking exception 1 [Undefined Instruction] from EL1 with ESR 0x200 Which is here: 00010908 arm64_c_environment: 10908: 97fffe06 bl 10120 loop3_csw+0x1b 1090c: aa0003f8 mov x24, x0 This finally gave some leads in the qemu debug. There seems be some misalignment in smp_processor_id. While tracing in gdb, we have 0x0908 in ?? () = 0x0908: 06 fe ff 97 bl 0x120 (which is actually bl smp_processor_id (from src/arch/arm64/stage_entry.S)) Under arm64_c_environment (in objdump) we have; 10908: 97fffe06 bl 10120 loop3_csw+0x1b Also in the trace we have IN: 0x0908: 97fffe06 bl #-0x7e8 (addr 0x120) Now loop3_csw is defined at (from objdump) 00010105 loop3_csw: So this + 0x1b = 10120 Thus it wants to branch and link to 0x120 but smp_processor_id is at 121. smp_processor_id is at (from objdump) 00010121 smp_processor_id: This gives us where the code is failing. Next up is finding out the reason for this misalignment and rectifying it. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: 2015-08-21 Librem 13: Weekly Progress Update
A new post titled "2015-08-21 Librem 13: Weekly Progress Update" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/08/24/2015-08-21-librem-13-weekly-progress-update/ This post covers the Librem 13 engineering considerations around writing to the SPI flash chip, and how that affects coreboot development. This builds on last weeks notes on the low level I/O for debugging coreboot builds. As always, email questions or comments to: larry.mob...@puri.sm. The BIOS flash on the Librem 13 is an 8 MiB chip in a SOP-8 package. The EC firmware is located on a separate 64 KiB chip. This link can be used to locate the chips on your mainboard: the BIOS flash is halfway down, near the CPU heatpipe. The EC flash is at the bottom just below the DDR3L module. Even without any patches specifically for the Librem 13, flashrom can flawlessly read its BIOS flash because it supports the PCH. Unless you write outside the BIOS region, you will not encounter any problems using flashrom to update your BIOS. Please dont update the Intel Firmware Descriptor or ME region just yet–all the IFD bits are marked read/write and flashrom is happy to execute a write to that region. The issue arises because the ME writes asynchronously to the ME region. A collision of flashrom and ME writes will corrupt the ME region and may brick the laptop. Purism intends to provide an unlocked ME that respects your freedom, so look for an update on the purism blog. In-System Programming The BIOS Flash The BIOS can be written and verified using a SOP-8 clip after closing the two sides of jumper J1 to assert the PCH RSMRST# pin. Warning: reflashing the BIOS risks bricking the laptop until in-system programming and/or soldering a new BIOS chip restores the BIOS to a good state. EC Flash The KB3930 datasheet, section 3.1 Hardware Trap, gives the method for programming the EC flash: Disconnect the battery and the A/C power so that the EC is fully powered down. Pull GPIO23/TP_ISP (pin 42) to GND. Note the internal 40K-ohm pull-up resistor. Connect the A/C power supply to the board. The EC is now powered up. TP_ISP sets CS#, SPI_CLK, MISO, and MOSI lines High-Z. Connect a SOP-8 clip and flash programmer and flash the EC firmware. It should be noted fine-pitch soldering is required to connect to pin 42 on the EC. The KB3930 also supports firmware updates via software. In the interest of all users privacy and security, here is a listing of the 8051 opcodes for the current Librem 13 EC firmware. EC Firmware Listing Notes This listing is still incomplete. Here are some notes: KB3930-specific Special Function Registers (SFR), SFR bits, and interrupt vectors are labelled like in the datasheet. Besides the jump tables and switch tables, there is some 8051 code not listed as code. It appears to be unreachable, though in time the execution path to reach these sections may be found. No A5 opcode. Some 8051 implementations add this opcode, but the KB3930 uses a vanilla 8051 architecture. This is not Free Software. Users should have the ability to verify their shipped firmware against this listing but Purisms goal is to provide a Free Software implementation of the EC firmware. Conclusions This post covers the steps for coreboot development and recovery. Fortunately, the EC firmware is not shared with the BIOS or ME blob, which makes flashroms job easier. BIOS development is hard. One of the major challenges facing BIOS developers is a lack of accurate, comprehensive documentation for all the hardware coreboot interacts with. The elephant in the room, for an Intel-based laptop, is the Management Engine. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: CCCamp 2015
A new post titled "CCCamp 2015" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/08/21/cccamp-2015/ We had an table on the cccamp 2015 in Mildenberg. The cccamp (chaos communication camp) is one of Europe big hacker events every 4 years where several hackers come together and do camping. Everybody could relax a little bit and talk to each other in a nice background. The camp infrastructure contained own wifi, dect, gsm network and a 10 GBit uplink in the middle of nowhere. You could give your tent a 1 Gbit uplink to the internet ;). Our table was in the BER village, named to the never finished airport near Berlin, Germany. Several people from the coreboot community showed up (CareBear, felix, mue, paulk-collins, tnias, zaolin, []) and we shared a lot of ideas to each other. In that way we flashed several laptops, replaced some WSON chips with SOIC-8s. Also weve found another bug in the sandybridge ram init, a fix is waiting for merge on gerrit #11248. paulk-collins came by to talk about a EC open source firmware for the ENE KBxxx embedded controllers. One of the MAME hackers visited us to get ideas how to port a Dell notebook (ENE KBxxx based EC). Felix did some work on ME as well other hackers joined him. Tnias and zaolin started the idea of a raspberry pi doing all the flashing including detection of the device. This could let us drink more Mate while other do the flashing themself. In the end a thunderstorm reached our tent and we had to evacuate it. Hopefully everybody can come to Bonn this year. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] End user flash tool - week #13 - summary
A new post titled "[GSoC] End user flash tool - week #13 - summary" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/08/21/gsoc-end-user-flash-tool-week-13-summary/ Hello! During week 13 I worked on: writing project documentation: bug fixing code cleanup changing debug messages to information popups DOCUMENTATION All functions and variables are now documented in javadoc style, I also attached some comments in code, documentation can be generated with doxygen. Besides documenting code I prepared documentation for functional tests which I executed. It contains described test cases and test results. NEW WORKING CONFIGURATIONS To make automatic building of coreboot image feature more useful it is necessary to add more data about working configurations. Every added configuration also needs to be tested to check if tool correctly recognizes hardware on target system and builds working coreboot image. I can do this for my hardware, so of course I did, I can also add some fake configurations for testing purposes, but I cant do this for hardware which I do not have. Here is description of application, building process and information about data I need to add a working configuration: link. I will be grateful for every configuration which you will sent! GUI IMPROVEMENTS Tool is targeted mostly for users which are not familiar with coreboot and flashrom details and also dont know how to proceed with building a working coreboot image. Taking it into consideration I changed most debug/error messages to appear in a form of a popup with description what action is needed from application user to proceed or what went wrong. SUMMARY End user flash tool is my first experience with coreboot and flashrom. Both of them are not easy projects, especially for someone who does not have great experience with firmware programming, because most code involves serious low level implementations, but in End user flash tool project I have been working always few layers above it because my work involved GUI programming, system programming, integration of external tools like bios_extract or cbfs_tool and adding few features to libflashrom. By doing it I learned a bit how these tools are working internally. I am now also more familiar with coreboot itself. All of this work gave me good basics and smooth entry to the coreboot world. As all of it is interesting and working for such project is very satisfying I want to dive in more and also maintain and extend the tool. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] End user flash tool – week #10 #11#12
A new post titled "[GSoC] End user flash tool – week #10 #11#12" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/08/16/gsoc-end-user-flash-tool-week-10-1112/ Hello! During weeks 10, 11 and 12 I worked on: functions for gathering hardware specific data automating process of building coreboot image GUI improvements GATHERING HARDWARE SPECIFIC DATA As I mentioned in my last post, if coreboot image should be built automatically then application needs to collect hardware specific data. During last weeks I added functions responsible for: dumping VGABIOS from memory: Some systems (like Lenovo T60 with ATI graphics) require adding VGABIOS dumped from memory to coreboot image, because factory BIOS patches it at runtime, so in certain cases using option rom extracted from factory BIOS may not work getting EDID data: to know what type of display panel is used in system getting motherboard model name: this is mandatory to recognize if we can install coreboot in system or if we have known working configuration AUTOMATING PROCESS OF BUILDING COREBOOT IMAGE It is now possible to build and flash coreboot image by clicking few application buttons without taking care which options are correct for system. Of course this is not possible for all hardware configurations, for now this is very limited, but with time database of known good configurations will grow and more users will be able to flash coreboot in such easy way. Process of automated image building: Check if working configuration for system is known. Check if configuration requires additional option rom. If necessary, add option rom extracted from factory bios or extracted from running system memory. Build image. GUI IMPROVEMENTS I decided to change a look of ROM options tab. Previously just raw output of cbfs_tool with rom contents info was redirected to GUI log window. Now it is visible in a form of table, what in my opinion is more readable. LAST WEEK AND FURTHER PLANS GSoC pencils down date is coming up on Friday, so only few days are left. I want to use this time for: writing project documentation looking for bugs and fix them code cleanup adding new working configurations and testing them (I need your help with it) change debug messages to information popups What after GSoC? I would like to still contribute, there is place for many improvements and possible extensions. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] End user flash tool – week #7 #8 #9
A new post titled "[GSoC] End user flash tool – week #7 #8 #9" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/08/13/gsoc-end-user-flash-tool-week-7-8-9/ Hello! During weeks 7, 8 and 9 I worked on: functions for gathering hardware specific data extending libflashrom GUI improvements testing GATHERING HARDWARE SPECIFIC DATA Main purpose of End user flash tool project is to provide an easy way to flash coreboot ROM. To achieve that there is a need to collect hardware specific data such as: lspci -nn output: information about all PCI buses and devices in the system, it is possible to recognize a graphic card, its vendor and device codes dump of factory BIOS: it is important to make a copy of factory BIOS in case something will go wrong, but not only in this case, very often there is a need to use a VGABIOS extracted from factory BIOS if particular graphic card or display panel is present in our system, it is the best to make dump two times and then check if files are the same (for example by comparing hashes) EXTENDING LIBFLASHROM Sometimes when flashrom probes for all known chips there are multiple chips found. I needed to implement a function which will return all such chips to GUI. Now in this case it is possible to just select which chip is correct by clicking a proper one in dialog box. GUI IMPROVEMENTS I decided to change a bit visual design of the app. There is a new (but most important for the project) tab Auto. In this tab it is possible to gather hardware specific data, which will be then used in a process of automatic building of coreboot image and flashing. I also decided to move programmer selection combobox from Flash tab to main application window and add edit text field for parameters. LOOKING FOR TESTERS GSoC end comes very soon, application is almost done, so this is time for some testing! I would be very grateful if some of you could help me with it. It would be the best if you have Lenovo T60. First there is a need to collect some hardware specific data and then it would be possible to check if application creates working coreboot image basing on this data. So it is not only about testing, but also about making white list of hardware configurations bigger to let more users flash their hardware with coreboot in easy way! Please contact me on: IRC #flashrom #coreboot: lukaszdm e-mail: lukasz.dmitrow...@gmail.com Thanks in advance! -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: 2015-08-14 Librem 13: Weekly Progress Update
A new post titled "2015-08-14 Librem 13: Weekly Progress Update" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/08/14/2015-08-14-librem-13-weekly-progress-update/ A question coreboot developers are commonly asked is this: can you port coreboot to my board? For my first coreboot post Id like to show some of the steps required to port coreboot to the Librem 13. In particular, this post is a good example of some of the challenges involved in such a port. This post is also the first weekly progress update for the Librem 13. Please email me with questions or comments: larry.mob...@puri.sm. LPC Bus The Librem 13 has convenient test points for the LPC bus. This allows a bed-of-nails test setup to quickly diagnose problems during manufacturing. But it has the added bonus of facilitating coreboot development. The earliest coreboot stages are the most important to get right. Debugging using port 0x80 writes on the Librem 13 is possible because port 0x80 writes are configured as LPC writes, which can be traced by connecting to the LPC pins. AndIts Gone BIOS development is hard. I applied a little too much force on the SPI flash chip and tore the solder pads off the board. I attached the LPC connection to a test setup and didnt check using a multimeter before applying power. LAD2 was shorted to LAD3. This immediately bricked the laptop without even releasing any smoke. Remembering to double check for shorts is a tedious but important lesson. The LPC bus wires go under the board. Dont Cross The Streams! Why It Matters Imagine a laptop where the LPC bus is only available by soldering directly to the pins of the EC. Yes, they exist! That level of fine soldering is a significant barrier for future coreboot hackers. (The Librem 13s external USB ports are all USB 3, which makes an EHCI debug port harder, but the LPC bus is a good substitute.) Porting coreboot to a new laptop takes a lot of time and work. Even a good laptop design like the Librem 13 where the LPC pads are available still has a non-trivial level of engineering work to get to a Free Software BIOS. Next week, Ill document the engineering considerations around writing to the SPI flash chip, and how that affects coreboot development. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New comment published at coreboot
A new comment http://blogs.coreboot.org/blog/2015/08/09/the-truth-about-purism-behind-the-coreboot-scenes/comment-page-1/#comment-1655080 has been published. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: coreboot changelog - Weeks of 2015-07-27 and 2015-08-03
A new post titled "coreboot changelog - Weeks of 2015-07-27 and 2015-08-03" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/08/12/coreboot-changelog-weeks-of-2015-07-27-and-2015-08-03/ This covers commits ef0158ec up to commit 1cbef1c Development is typically slower during the summer and 2015 is no exception, so the report switches to a biweekly installment for a while. The last two weeks have seen improvements in our development tools: coreboot upstream can now build Chrome OS boards with Chrome OS features (verified boot, interaction with Chrome EC, flash based error logging) enabled, and the projects builders at http://qa.coreboot.org/ are now routinely building these configurations alongside the regular default configs for all boards. The builders now run ‘make what-jenkins does’ (see coreboot/Makefile.inc) instead of a hard-coded set of commands, which provides the community the capability to adapt the test build without admin intervention. When adding the .config used for building an image into said image, it’s now minimized which gives visibility to the relevant changes to the config compared to the board’s defaults. Kconfig features a strict mode, which acts as a ‘warnings-as-errors’ equivalent and fails the build if kconfig would emit any warning. Since we still have a couple of those in the tree, it’s not enabled yet. For users of cscope or ctags, we now have new make targets to create tree-wide indexes (make ctags-project cscope-project). Reproducible builds got a boost by fixes to the build.h generator script, which can finally emit stable timestamps based on the git revision, instead of the local time. External payload integration was coalesced within payloads/external, with more work in progress. The integrated SeaBIOS build can now also be used when building with ccache. libpayload gained robustness in different developer environments, being smarter about looking for compilers, configs and include files in all the right places. On the Free Software side, more microcode blobs were moved to the 3rdparty/blobs repository and one false positive that libreboot’s blob detector tripped over was eliminated, and with a little more progress, it should soon be possible to build from a fully blob-free coreboot tree. Before you get your hopes up, please note that the result may not be very useful on a lot of boards, so more care must be taken. The effort to make coreboot capable of booting in 64bit mode on x86-64 is still ongoing and saw the integration of more commits. coreboot should have an easier time again when building on Cygwin and BSD systems. Skylake was the chipset with the largest amount of work in the 2 weeks, but there was also the addition of a coreboot port for RISC-V’s Spike ISA Simulator, contributions to the AMD Bettong mainboard and its chipset drivers, as well as fixes and cleanups to AMD K8 and Intel i945. In terms of style, a bunch of extraneous whitespaces, indenting errors and FSF addresses were also dealt with. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] coreboot for ARM64 Qemu – Week #8
A new post titled "[GSoC] coreboot for ARM64 Qemu – Week #8" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/08/09/gsoc-coreboot-for-arm64-qemu-week-8/ As I had discussed in my last blog post, currently I am onto the debug of the qemu boot. I was intending to use Valgrind tools to detect various memory managements bugs and use that information for my debug. But sadly the information provided by Valgrind was not of much use since it didnt deal with the execution stream of the coreboot code in qemu. I ultimately had to turn to gdb and use it for further debug. This was an initial hiccup, since, as in my last post, building aarch64-linux-gnu-gdb on MacOSX was not straightforward, since there was no direct replacement for the gdb-multiarch. I was able to get this done. I discuss some of the basic steps of how to set it up below. First, we need a couple to packages to build gdb. They are listed below: expat guile texinfo Next, download the aarch64-gdb from here. Now, you need to configure CC to gcc (GNU gcc and not the innate symlink to clang). Then proceed to, $ ./configure --target=aarch64-linux-gnu $ make $ make install If this completes successfully, you would have aarch64-gdb installed on your system correctly. The important thing to remember is to use GNU gcc (=4.9) and not the innate MacOS gcc. To run gdb you must $ aarch64-linux-gnu-gdb The output looks like this : GNU gdb (GDB) 7.9 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-apple-darwin13.3.0 --target=aarch64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word". Now I had gdb working. Then I did started the debug by giving a -s -S while invoking qemu. After this, I need to connect to gdb remotely using (gdb) target remote : 1234 Some of the debug information I received was this : (gdb) target remote :1234 Remote debugging using :1234 0x0200 in ?? () (gdb) run The remote target does not support run. Try help target or continue. (gdb) continue Continuing. ^C Program received signal SIGINT, Interrupt. 0x0200 in ?? () On trying single-step execution on gdb, I received : (gdb) step Cannot find bounds of current function An error like this usually seen when we overflow a buffer and corrupt the stack, the proper return address is destroyed. When the debugger tries to figure out which function the address is in, it fails, because the address is not in any of the functions in the program. On running the simple where on gdb I get [where displays the current line and function and the stack of calls that got you there] (gdb) where #0 0x0200 in ?? () After some unscrambling of the source code using information from gdb, we were pointed to some issues under the stage_entry in src/arch/arm64/stage_entry.S. I am onto re-setting those and continuing the debug further now. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: The truth about Purism: Behind the (coreboot) scenes
A new post titled "The truth about Purism: Behind the (coreboot) scenes" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/08/09/the-truth-about-purism-behind-the-coreboot-scenes/ Since the last time I talked about Purisms stab at a coreboot laptop, a lot happened, including the launch of the non-libre Librem 15, alongside with plans for a 13 version. My last post seems to have sparked quite some controversy on the subject, placing me on the CC field of many emails between not-so-happy supporters and Todd Weaver. Ive avoided writing on this subject again, because I didnt have anything good to say about Purism. However, considering the amount of new emails being generated lately, I think I should follow up on why the Librem 15 failed on the freedom front, and why another Purism laptop is just as likely to fail. The road so far A lot has happened since my last post, including a lot of media coverage on the issue. Now I can use acronyms like FSP, ME, and EC, without having to worry about losing 90% of my audience. Its great that there is now a lot of non-technical coverage on the issue, something that non-corebooters can easily digest. However, some things also happened behind the scenes, which Id now like to talk about. Trying to meet Todd in person After my initial post, a large number of emails flew back and forth between angry backers, Crowdsupply, and Purism, with me on the CC field. From this, Ive had the chance to communicate with Todd Weaver directly, and express to him my concerns on why the Librem was about to fail. I also offered to set up a meeting with Stefan and Ron. Ive talked to Stefan, and he seemed excited to speak with Todd and help put coreboot on the Librem. Ron shared the following over the email thread: Todd, I think the overall concern with librem and your statements is the seeming lack of realization that you're walking over very well trod ground, and there are lessons learned, and we might as well pass them on. I for one seeing you making the same mistakes that have been frequently made over 15 years, and there's benefit to learning what we've learned. That was back in March. The meeting hasnt yet happened. The discussion died down when I asked Todd to produce the current source code for the upcoming librem. After almost a month from my initial inquiry, on May 11, Todd wrote: We will be releasing the source code once we get coreboot working on our rev1 which will be shipping within the next few weeks. The Librem 15 launched Fast forward a few months later, after the email exchanges died down, I get a tip that the Librem 15 has shipped with AMI UEFI firmware. While I do not have a Librem 15 in my possesion, this has been confirmed by PC World. Although I hate having been right about this, I love saying this: I told you so. Todd claims he has coreboot developers working on Librem A new wave of angry emails ensued just recently. I once again had the chance to communicate with Todd directly. He claimed to have three coreboot developers working for Purism, but they wanted to remain anonymous. He did, however, provide the name on one of the developers, whom I shall not mention for privacy reasons. Of course, I was curious to see what that person worked on: [coreboot]$ git log |grep Author |grep -i first name -c 0 [coreboot]$ git log |grep Author |grep -i last name -c 0 [coreboot]$ Ive informed Todd that this developer is not a coreboot contributor, and for the purpose of our discussion, does not count as a coreboot developer. Ive asked Todd to produce git hashes of patches contributed by one or both of the other two developers. He has not done so. Purism attacks Minifree (formerly Gluglug) Just this morning, a tweet was brought to my attention, which, to me, seems like a direct attack on Minifree from Purism. The tweet compared an old heavy IBM Thinkpad, with the Librem 15, showing the picture of a T60 Thinkpad running libreboot. This is also one of the pictures Gluglug (now Minifree) used on its product page when they were selling the T60 model. For those of you unaware, Minifree (formerly Gluglug) sells laptop systems which are completely free, from the OS down to the firmware, and which are endorsed by the FSF through their Respects Your Freedom certification. The Minifree laptops are what we, as the community have been working to achieve since the inception of LinuxBIOS more than fifteen years ago, and the reason I have stuck with the project for over half a decade despite all the difficulties and roadblocks. To attack Minifree is to insult all of our hard work over the years, and to me, it indicates that Purism really doesnt give a damn about your freedom, but they really like your support and money. I know I promised I would also talk about why another Purism laptop is just as likely to fail as the Librem 15, but Ive ranted enough for one post. Ill describe that into more detail next time. Todd, you owe us an apology! --
[coreboot] New comment published at coreboot
A new comment http://blogs.coreboot.org/blog/2015/07/22/coreboot-changelog-week-of-2015-07-13/comment-page-1/#comment-1655076 has been published. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: coreboot conference in Europe, October 2015
A new post titled "coreboot conference in Europe, October 2015" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/08/04/coreboot-conference-in-europe-october-2015/ Dear coreboot developers, users and interested parties, we are currently trying to organize a coreboot conference and developer meeting in October 2015 in Germany. This is not intended to be a pure developer meeting, we also hope to reach out to manufacturers of processors, chipsets, mainboards and servers/laptops/tablets/desktops with an interest in coreboot and the possibilities it offers. My plan (which is not final yet) is to have the Federal Office for Information Security (BSI) in Germany host the conference in Bonn, Germany. As a national cyber security authority, the goal of the BSI is to promote IT security in Germany. For this reason, the BSI has funded coreboot development in the past for security reasons. The preliminary plans are to coordinate the exact date of the conference to be before or after Embedded Linux Conference Europe, scheduled for October 5-7 in Dublin, Ireland. Planned duration is 3-4 days. This means we can either use the time window from Thursday Oct 1 to Sunday Oct 4, or from Thursday Oct 8 to Monday Oct 12. The former has the advantage of having cheaper hotel rooms available in Bonn, while the latter has the advantage of avoiding Oct 3, a national holiday in Germany (all shops closed). ATTENTION vendors/manufacturers: If your main interest is forging business relationships and/or strategic coordination and you want to skip the technical workshops and soldering, well try make sure there is one outreach day of talks, presentations and discussions on a regular business day. Please indicate that with (strategic) next to your name in the doodle linked below. If you wonder about how to reach Bonn, there are three options available by plane: The closest is Cologne Airport (CGN), 30 minutes by bus to Bonn main station. Next is Düsseldorf Airport (DUS), 1 hour by train to Bonn main station. The airport with most international destinations is Frankfurt Airport (FRA), 2.5 hours by train to Bonn main station. Theres the option to travel by train as well. Bonn is reachable by high-speed train (ICE), and other high-speed train stations are reasonably close (30 minutes). What Im looking for right now is a rough show of hands whod like to attend so I can book a conference venue. Id also like feedback on which weekend would be preferable for you. If you have any questions, please feel free to ask me directly c-d.hailfinger.devel.2...@gmx.net or our mailing list coreboot@coreboot.org. Please enter your participation abilities in the doodle below: http://doodle.com/bw52xs4fc7pxte6d Regards, Carl-Daniel Hailfinger -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] EC/H8S firmware week #7|#8
A new post titled "[GSoC] EC/H8S firmware week #7|#8" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/07/29/gsoc-ech8s-firmware-week-78/ Week #7 was is little bit frustrating, because of no real progress, only more unfinished things which arent working. Week #8 was a lot better. 1. Sniffing the communication between the 2 embedded controllers H8S and PMH4. Ive tried to build an protocol analyser with the msp430, but the data output was somehow strange. For testing purpose I used my H8S firmware to produce testing data. But the msp430 decoded only wrong data. Im using IRQs on the clock to do the magic and writing it to a buffer before transmitting it via UART. Maybe the msp430 is too slow for that? Possible. Set a GPIO to high when the IRQ routing start and to low when it ends. Visualize the clock signal and connect the IRQ measure pin to an oscilloscope. The msp430 is far too slow. Im using memory dereference in the IRQ routine, which takes a lot of time. Maybe the msp430 is fast enough, when using asm routine and registers to buffer the 3 byte transmission. But a logic analyser would definitely work. So I borrowed two logic analyser. An OLS (Openbench Logic Sniffer) and a Saleae Logic16. There isnt so much data on the lines. Every 50 ms there is a short transmission of 3 byte. But I dont want to decode the data by hand. So it needs a decoder for the logic analyser. sigrok looks like the best start point and both analyser are supported. Ive started with the Openbench Logic Sniffer, but unfortunately it doesnt have enough RAM to buffer the input long enough. Maybe the external trigger input can be used. But before doing additional things I would like to test with the Logic16. The Logic16 doesnt support any triggers but it can stream all data over USB even with multiple MHz. Good enough to capture all data. I found out that the best samplerate is 2 MHz. Otherwise the LE signal isnt captured, because its a lot shorter than a clock change. In the end I created a decoder with libsigrokdecode. sigrok-cli -i boots_and_shutdown_later_because_too_hot.sr channels 0-3 -P ec_xp:clk=2:data="" | uniq -c 67 0x01 0x07 0xc8 3 0x01 0x04 0xc8 4 0x01 0x10 0x48 1120 0x01 0x17 0x48 67 0x01 0x07 0xc8 0x01 0x07 0xc8 is called when only power is plugged in, like a watchdog(every 500ms) 0x01 0x17 0x48 is called when the device is powered on, like a watchdog (every 50ms) 0x01 0x04 0xc8 around the time power button pressed 0x01 0x10 0x48 around the time power button pressed 2. Flash back the OEM H8S firmare The OEM H8S firmware is included in the bios updates. cabextract and strings is enough for extracting it out of the update. Look for SREC lines. Put the SREC lines into a separate file and flash them back via UART bootloader and the renesas flash tool. The display powers up and its booting again with OEM BIOS. I could imagine they are using a similar update method like the UART bootloader. First transfer a flasher application into RAM and afterwards communicate with the flasher to transfer the new firmware, but the communication works over LPC instead of UART. 3. Progress on the bootloader Ive implemented the ADC converter to enable the speaker amp and the display backlight brightness. Written down LPC registers and just enable the Interface in order to get GateA20 working. Still unclear how far this works. 4. How to break into the bootloader? The idea of the bootloader is providing a brick free environment for further development. The bootloader loads the application which adds full support for everything. It should be possible to stop the loading application and flash a new application into the EC flash. When starting development on the x60 or x201 I want to use I2C line as debug interface. I2C chips have a big footstep and are easy to access. But there must be a way to abort the loading. I will use the function key in combination with the leds. Remove the battery and power plug. Press the function key Put the power plug in Wait until leds blinking release the function key within 5 seconds after the leds starting to blink to enter the bootloader. The H8S will become I2C slave on a specific address. What next? Add new PMH4 commands to the H8S solder additional pins to MAINOFF PWRSW_H8 A20 KBRC use the logic analyser to put the communication in relation with these signals UART shell I2C master client solder LPC pins to analyse firmware update process test T40 board with new PMH4 commands and look if all power rails are on -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: coreboot changelog - Week of 2015-07-20
A new post titled "coreboot changelog - Week of 2015-07-20" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/07/29/coreboot-changelog-week-of-2015-07-20/ This covers commits 406effd5 up to commit ef0158ec Apart from adding the google/glados board, this week’s activity concentrated on bug fixes in chipsets and mainboards, spanning AMD K8 and Hudson, Intel Sandy Bridge, Braswell and Skylake, Nvidia Tegra, Rockchip RK3288 and RISC-V. Most of the changes are too small individually and too spread out across the code base for a shout-out (or this report becomes just a fancy kind of “git log”), but two changes stand out: Native RAM init on Sandybridge gained support for multiple DIMMs on the same channel, further improving the reverse engineered code base for that chipset. To improve Skylake support, our 8250mem serial port driver now also supports Skylakes 32bit UART access mode. This may also be useful when reducing code duplication in our serial console drivers (such as on ARM SoCs). -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] coreboot for ARM64 Qemu – Week #7
A new post titled "[GSoC] coreboot for ARM64 Qemu – Week #7" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/07/28/gsoc-coreboot-for-arm64-qemu-week-7/ This was a tough week. After having passed the coreboot building stage, I thought my work whould be easier now. But I had another thing coming. As I had mentioned in my last post, I didnt have any output while booting on qemu. So, the first aim was to get qemu monitor working. After some debug, I was able to get qemu monitor working to print onto my terminal (stdio) This gave me then following : qemu: fatal: Trying to execute code outside RAM or ROM at 0x0800 R00=0950 R01= R02=4400 R03= R04= R05= R06= R07= R08= R09= R10= R11= R12= R13= R14=40010010 R15=0800 PSR=41db -Z A und32 s00= s01= d00= s02= s03= d01= s04= s05= d02= s06= s07= d03= s08= s09= d04= s10= s11= d05= s12= s13= d06= s14= s15= d07= s16= s17= d08= s18= s19= d09= s20= s21= d10= s22= s23= d11= s24= s25= d12= s26= s27= d13= s28= s29= d14= s30= s31= d15= s32= s33= d16= s34= s35= d17= s36= s37= d18= s38= s39= d19= s40=00 Abort trap: 6 I did some searching, this meant that the bootloader could not be loaded. And realised maybe the ROM qemu is being allotted is not sufficient. The execute outside ram or rom is usually a jump to somewhere that qemu does not recognize as ROM/RAM. Since we expect CONFIG_BOOTBLOCK_BASE is 0x1 CONFIG_ROMSTAGE_BASE is 0x2 CONFIG_SYS_SDRAM_BASE is 0x100 i.e ROM to start at 64k. So I ran qemu by giving a -m 2048M (for testing) and got over this fatal qemu error, but still wasnt able to get coreboot to boot (no output on serial). This meant, some more debugging was needed. I started to debug this using gdb. I created a gdb stub in the qemu boot (by using -s -S), but running gdb to connect to it gave me : (gdb) target remote localhost:1234 Remote debugging using localhost:1234 warning: Architecture rejected target-supplied description 0x4008 in ?? () Which probably meant I will have to have to build a cross gdb (aarch64-linux-gnu-gdb) and use that. For this, on linux we could have something called gdb-multiarch, but this is not available for macOSX. I then turned to using Valgrind. There are Valgrind tools available that can help detect many memory management bugs. This is what I got on valgrind, ==2070== Memcheck, a memory error detector ==2070== Copyright (C) 2002-2013, and GNU GPLd, by Julian Seward et al. ==2070== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==2070== Command: aarch64-softmmu/qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine type=virt -nographic -m 2048 -kernel /Users/naman/gsoc/coreboot2.0/coreboot/build/coreboot.rom ==2070== 2070 aarch64-softmmu/qemu-system-aarch64: 2070 dSYM directory is missing; consider using dsymutil=yes UNKNOWN __pthread_sigmask is unsupported. This warning will not be repeated. 2070 WARNING: unhandled syscall: unix:330 2070 You may be able to write your own handler. 2070 Read the file README_MISSING_SYSCALL_OR_IOCTL. 2070 Nevertheless we consider this a bug. Please report 2070 it at http://valgrind.org/support/bug_reports.html. ==2070== Warning: set address range perms: large range [0x1053c5040, 0x1253c5040) (undefined) ==2070== Warning: set address range perms: large range [0x239e56040, 0x255e55cc0) (undefined) ==2070== Warning: set address range perms: large range [0x255e56000, 0x2d5e56000) (defined) 2070 set address range perms means that the permissions changed on a particularly large block of memory. That can happen because when a very large memory allocation or deallocation occurs a mmap or umap call. Which meant we are leaking some memory, but we need to find where. I read some documentations and believe something called a massif tool (in valgrind) could be used. I am now looking at how to find where this memory gets eaten. On the target now is getting some answers on valgrind if possible. But if I dont get sufficient leads, I would have to switch to gdb (aarch64 on macOSX) and continue my debugging. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: coreboot changelog - Week of 2015-07-13
A new post titled "coreboot changelog - Week of 2015-07-13" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/07/22/coreboot-changelog-week-of-2015-07-13/ This covers commits 6cb3a59 (which is the 4.1 tag) up to commit 406effd5 This week brought the addition of one new chipset and four new mainboards: Welcome the Intel Skylake SoC, and the new mainboards google/cyan, intel/kunimitsu, intel/sklrvp, and intel/strago, which are Braswell or Skylake based. As for tools, the script that generated the 4.1 release was added to the tree. To aid with debugging build issues, buildgcc shows the URLs it uses to download the sources to the toolchain. The standard git hook now uses a customized version of Linux’s checkpatch.pl utility for better coding style compliance tests. The cbmem utility gained OpenBSD compatibility when reading timestamps. The USB host drivers in libpayload saw improvements both for USB3, supporting SuperSpeed hubs and showing more robustness in the presence of strangely behaving USB devices, and for DWC2 controllers, which now support LowSpeed devices behind HighSpeed hubs. coreboot also passes more information to libpayload on where to find the flash part as well as the parameters of the CBFS that was used during boot. The CBFS format is seeing new development: The default alignment for files is now hardcoded to 64 bytes, which was already the default. There are no known instances where this value was changed, and it simplifies development going forward. The change is forward compatible in that old users can still read new CBFS images. New users run into problems if they work on a CBFS image with a different alignment configuration. Furthermore there were discussions on how to extend the CBFS format compatibility. So far this led to numerous refactorings in cbfstool to simplify further development. Finally, there were a whole lot of bug fixes: ARM64, the code for Nvidia’s Tegra210 chipset and the google/foster and google/smaug boards saw lots of development, from making them boot again to various hardware enablement. AMD’s RS780 chipset was effectively disabled due to a typo in the build system. There’s an ongoing effort to bring AMD K8/Fam10h into shape again, which also positively affected HD Audio configuration. CBMEM timestamps are more complete than ever. There was also the usual bunch of cleanups that get rid of unused Kconfig symbols and configuration options, deal with wrong indentation, and replace magic numbers with meaningful names. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] End user flash tool – week #6
A new post titled "[GSoC] End user flash tool – week #6" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/07/22/gsoc-end-user-flash-tool-week-6/ Hello again! During week 6 I worked on two things: functional tests of libflashrom on T60 GUI improvements filtering and searching list of supported hardware TESTING LIBFLASHROM For testing I used Lenovo T60 with Macronix chip and Raspberry Pi. I connected to the chip with SOIC clip and attached it to Raspberry SPI. I needed to disassemble my laptop almost completely because on T60 BIOS chip is blocked by a magnesium frame which must be removed. It is important for me to have easier access to the chip without disassembling everything every time so I removed a part of frame that covered the chip. Tested functions: fl_flash_probe: function returns proper flash context if we provide a specific chip as its argument, if we probe for all known chips and there are multiple chips found (like in Lenovo T60 with Macronix chip) correct error code is returned (I also needed implement a way to output multiple flash chips to GUI and then select a proper one, I will describe it my next post). fl_image_read: correct data is loaded to buffer fl_flash_erase: chip has been properly erased fl_image_verify: verification succeeded fl_image_write: data has been correctly written on the chip filtering and searching supported hardware It is possible now to find a specific chip, board or chipset on the list by selecting filtering options like vendor, size or test status. You can also search by entering a name of a particular hardware (or part of a name). I plan to extend this screen and provide more filtering options whenI will finish implementing higher priority features like automating a process of creating a working coreboot image and checking hardware compatibility. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] EC/H8S firmware week #6
A new post titled "[GSoC] EC/H8S firmware week #6" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/07/13/gsoc-ech8s-firmware-week-6/ This week I looked at the communication between the EC H8S and the PMH4. The PMH4 (likely power management hub) is an ASIC which takes care of the power control. It controls who gets power and who not. It doesnt do any high level work, more like a big logic gatter. The PMH4 has inputs from several power good pins from different power rails and chips. On the output side it controls some power rails. It can also reset the H8S. The PMH4 also knows over some pins in which power state (ACPI S0,S4,S5) the board is. It doesnt do any high level work. Its more like a big logic gatter. There are no ADC on any power lines. The PMH4 is connected to the H8S via 4 Pins. ~OE LE DATA CLK. I connected a buspirate in SPI sniffer mode to debug the protocol. But the output looked a little bit strange. There was no data from the PMH4 to H8S (MISO) and the data comes in burst. To get more knowledge on the protocol I used a digital oscilloscope. pmh4 oscilloscope The protocol doesnt look like SPI. LE gets low after every transmission, ~OE is just high, clock and data just transfer the data. Sometimes when the H8S gets an interupt the Clock pause for some time and continues with the data afterwards. The clock is around ~400kHz. I confirmed the protocol via the oscilloscope, but still I dont get any sign from the board. No fan, nothing else. There must be more than this single transmisison. Maybe the board is to much damaged. My modified board was already broken when I got it. There is a loose connection related to the cardbus. Maybe this is my problem I dont know. Ive two board with two connectors for the PMH4 here. Why not using the OEM one as starter help for the other one? t42 gives some starting help I think the PMH4 does what it should do. The H8S has an digital-analog-converter pin connected to the video brightness. But I havent implemented it yet. But I dont think the device booted, because neither the CPU nor the chipset produce any heat. Ok, maybe it does, I only used my finger as thermometer. A thermal camera would help here. Ill borrow a thermal camera for that. There are lot of pins which I ignore atm. E.g. A20 pin. Is there something to do in a specific time serie? Whats next? build a small protocol sniffer for the PMH4 XP using a msp430 or stellaris arm make progress on the bootloader find a way to flash back the OEM H8S firmware find a way to flash my bootloader via OEM flash tools My requirements to the bootloader are UART flashing via XMODEM a simple UART shell I2C as recovery and shell as well I2C pins are a lot easier to find and modify than the H8S UART. Im not yet sure if the H8S should be the master or the slave and on what address he should use? Multiple? UART tx is working. Rx is a task to do. PMH4 / PMH7 / Thinker communication On newer board the PMH interfaces changed (= x60, t60, ). They merge the LPC interface and the XP interface into an protocol over SPI. And the new PMH is used as GPIO expander as well. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] coreboot for ARM64 Qemu – Week #6
A new post titled "[GSoC] coreboot for ARM64 Qemu – Week #6" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/07/13/gsoc-coreboot-for-arm64-qemu-week-6/ This week I worked on completing the build and sorting all complications imposed by it. As I talked in the last post, I was facing some issues regarding setting up smp for this port. I solved this issue by adding an assembly file which declared smp_processor_id and then defined it by setting the right registers. I had to do some background reading on arm64 details. This provided me with the information I needed. Next up, was another hitch. During the build, mmu_enable() and arch_secondary_cpu_init() function calls are happening for all stages but the definitions for these functions are getting compiled only for ramstage. So this gave recurrent errors since the compiler couldnt find these definitions. While attempting to sort this, I stumbled across something on the chromium tree. There was a patch which dealt with some of the issues, similar to mine. I had to cherry pick and apply this change. After debugging and sorting through some more errors, I was finally able to get it to build successfully. coreboot.rom: 4096 kB, bootblocksize 37008, romsize 4194304, offset 0x90c0 alignment: 64 bytes, architecture: arm64 Name Offset Type Size fallback/romstage 0x90c0 stage 12108 fallback/ramstage 0xc080 stage 17768 config 0x10640 raw 2034 revision 0x10e80 raw 577 (empty) 0x11100 null 4124312 HOSTCC cbfstool/rmodtool.o HOSTCC cbfstool/rmodule.o HOSTCC cbfstool/rmodtool (link) The complete build can be found here. I attempted to boot off on qemu after this, $qemu-system-aarch64 -machine type=virt -nographic -bios ~/coreboot/build/coreboot.rom This did not give any output, which meant probably I had to make some changes in the uart set up. I attempted to debug this by adding few printks early in bootblock once the console_init is done. This process ongoing, I hope to get through. Another aspect in question is the bootblock initialisation. The src/arch/arm64/armv8/bootblock_simple.c calls for an appropriate bootblock_cpu_init(). This is another thing I will be working on in the coming days. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] EC/H8S firmware week #5
A new post titled "[GSoC] EC/H8S firmware week #5" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/07/06/gsoc-ech8s-firmware-week-5/ The T40 is flashing leds! The toolchain is still a little bit tricky. Im using the debian package gcc-h8300-hms, written a small linker script and took the startup assembly routine from Johann Gysins led radiator. Now I can flash leds. But what about booting the board? I would say its enough to put (!MAINOFF) = high FAN ON = high pulse high on (!PWRSW_H8) But its not enough. Also the FAN isnt starting to rotate. Ill try to debug every pin this week and solder some debug pins for the 2nd EC (PMHx) to the my modified T40 as well as to an unmodified T42p. The H8S is talking to the PMHx via SPI, while the H8S is the master and is doing bit banging SPI in software, because it doesnt have a hardware unit for that. Ill also use these pins for testing my SPI implementation. Ill try to reuse an open source SPI implementation. I also asked me if its a good idea to port coreboot for the T40 before continuing any efforts to the EC, but its a little bit harder, because the T40 uses a LPC/FWH flash in a TSOP40 case. Another option is changing the hardware to a board which is already supported by coreboot like a x60/t60 or x201. But its much more harder to access the 8 pins for flashing the EC on these boards. Before switching to another board, the powersequencing must work and I need a robust recovery way, because when you kill the EC by flashing a new firmware, you dont get a second chance, unless you solder a lot. Chrome EC fix this problem by splitting the EC firmware into 2 parts. One read-only part and one read-writeable part. Only the second part gets updated and the read-only part can at least boots the device. Before starting the H8S port for Chrome EC I want to have a bootloader. Because it would improve developing speed. I think implement this is much faster than doing the full Chrome EC support and most of the bootloader code can be re-used for Chrome EC. Im also not perfectly sure Chrome EC is the best solution. Its special use-case is EC, which is perfect. But neither the documentation (I think there is more than one page) nor the bugtracker is public. Thus it makes difficult to use. Im also not sure if Chrome EC would apply my H8S port into their repository. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] coreboot for ARM64 Qemu – Week #4 and #5
A new post titled "[GSoC] coreboot for ARM64 Qemu – Week #4 and #5" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/07/01/gsoc-coreboot-for-arm64-qemu-week-4-and-5/
From this week I started dealing with the core aspects of aarch64 design. I continued with the process of building the armv8, along with handling the required patching-up, interfacing, hook-ups. In my last post, I had talked about the toolchain building error (in binutils) for arm64 which I was facing on OSX. I had to remove the enable-gold flag from the binutils. After making this small update, the build_BINUTILS looked like this, and I was able to get the toolchain working.
build_BINUTILS() {
if [ $TARGETARCH == "x86_64-elf" ]; then
ADDITIONALTARGET=",i386-elf"
fi
CC="$CC" ../binutils-${BINUTILS_VERSION}/configure --prefix=$TARGETDIR \
--target=${TARGETARCH} --enable-targets=${TARGETARCH}${ADDITIONALTARGET} \
--disable-werror --disable-nls --enable-lto \
--enable-plugins --enable-multilibs CFLAGS="$HOSTCFLAGS" || touch .failed
$MAKE $JOBS || touch .failed
$MAKE install DESTDIR=$DESTDIR || touch .failed
}
The work had just began after fixing the toolchain. On attempting to building, the faced error I got was :
toolchain.inc:137: *** building bootblock without the required toolchain. Stop.
This was due to certain wrongly configured CONFIG options in the Kconfig. After this stage the initial bring-up of arm64 looked stable. Moving forward, I was met with an error in src/arch/arm64/c_entry.c
src/arch/arm64/c_entry.c: In function arm64_init': src/arch/arm64/c_entry.c:52:2: error: implicit declaration of function cpu_set_bsp [-Werror=implicit-function-declaration] cpu_set_bsp();
The inclusion of necessary files and structures were correct, and I kept getting this error. Furquan ultimately pointed to change 257370 following which, I could get past this. After this, I had to solve another BSD/OSX issue about date in genbuild_h.sh to get my build progressing.
Subsequently, some architectural decisions had to be made for the armv8. In the initial version, I had been banking on cbfs_media based structure in media.c, for creating functions for read, write and map. But the older formulation (in cbfs_core.c and cbfs_core.h) is changed now. In order to keep up, and to maintain uniformity, we decided to handle this as it is handled in armv7, i.e by creating a mapping to the qemu memory mapped space. Another point of discussion for stage loading. It is being brought up similar to armv7 for now. This might change in the future. Also the organisation for UART was finalised. plo11.c is included, as in src/drivers/uart/Makefile.inc. by setting the DRIVERS_UART_PL011 in armv8 Kconfig.
Next hitch was dealing with SMP. In my proposal, I had suggested that incorporating smp into the emulation could be a long term goal. But since smp is a part of core arm64 logic, this cannot be completely ignored at this stage. I am met with this
coreboot/src/arch/arm64/stage_entry.S:94: undefined reference to `smp_processor_id
build/arch/arm64/c_entry.romstage.o: In function `seed_stack':
A cpu file which adds smp_processor_id() is needed at this moment, which I am currently working on. Next weeks plan is to get past these (and meet new unforeseen issues ) and boot off on qemu.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] EC/H8S firmware week #3|4
A new post titled "[GSoC] EC/H8S firmware week #3|4" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/06/27/gsoc-ech8s-firmware-week-34/ In the last 2 weeks I managed to flash the H8S on the T40 using the OEM Renesas Flash Tool including their flash application. Flashing works in 2 steps, first upload a flash application into the H8S. Second this flash application will receive the firmware (via serial) and write it into the flash. Thanks to Renesas this application is available in source code. I would like to write an own flasher later. But I wasnt able to create a proper application yet. I could write the led programm in assembly, but having a working c compile is needed anyway. I built a toolchain with gcc 4.9.2. The toolchain buildscript is very simple and can be found on github. I stopped my building efforts for now (building one based on gcc 4.4.6). Theres also a debian package for h8300 (based on gcc 3.4.6) which may be a good alternative. Before continuing in building toolchains and my led application, Im reading me into linkerscipts and take a look how the compiler is working (e.g. what must a crt0 do?). At the moment I know how the application should be compiled, where the reset vectors are and where the entrypoint. But putting these things together into a binary image is my task now. The dev board I mentioned in my last post was stuck by the german post for the last 2 weeks, because there were on strike. The board is now in the custom office and Ill collect in the next days, which will takes severals hours in Berlin. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] End user flash tool - week #4 #5
A new post titled "[GSoC] End user flash tool - week #4 #5" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/06/29/gsoc-end-user-flash-tool-week-4-5/ Hello! During week #4 and #5 I worked on several cases: Integration of cbfs_tool features. Improving my libflashrom querying functions / integrating already existing patches. Extending and improving GUI. Integration of cbfs_tool features cbfs_tool is bigger project than bios_extract, so I took a little more to integrate it than during bios_extract integration as I needed to do some investigation how it works. I imported code related to creating rom file adding components like stage, payload, option rom, bootsplash etc. printing rom content deleting components. The same like in case of libflashrom and bios_extracted I created a static library and linked it with flash tool. IMPROVING LIBFLASHROM querying functions / integrating patches After posting my draft patch for initial review on flashrom mailing list I got great feedback which helped me a lot. Urja Rannikko and Stefan Tauner pointed my mistakes and proposed improvements and moreover Anton Kochkov shared his libflashrom changes where he worked on similiar issues. This community is really helpful. Thanks! So, I did improvements in querying functions. Currently we have: const char** fl_supported_programmers(void); const char* fl_version(void); fl_flashchip_info *fl_supported_flash_chips(void); fl_board_info *fl_supported_boards(void); fl_chipset_info *fl_supported_chipsets(void); int fl_supported_info_free(void *p); Unnecessary functions which return number of supported hardware of certain type have been removed. Now we can call functions to allocate the table and get a pointer to it. Of course I will create a patch and post it for second review. I had a problem as my SOIC clip did not arrived on time, I was not able to test operations related functions on my T60. Actually it was my fault because I have not noticed a comment on internet auction that it may go from China. I have been waiting for 3 weeks for its arrival. Now I already have it so my main focus this week is to test libflashrom on real hardware. extending / improving gui I extended a GUI part with some dialogs, comboboxes and edit text fields to allow user to manipulate with rom contents like adding payload, bootsplash or removing such components. Of course this is not a main purpose of my project. The main focus is to create a tool which will allow user to dont care about that which options are correct and I will be going in this direction in July where my effort will be to automate a process of creating and flashing a coreboot image as much as possible. So currently this is a kind of advanced mode. I implemented it for several reasons: after integration of bios_extract, cbfs_tool and libflashrom it was not big effort to do it implementing and testing it helped me to better understand integrated code and its features there are also advanced users who may want to do some manual changes Tasks for current week: test flashing with libflashrom on my T60 GUI improvements proposed by Stefan Tauner(searching, sorting and filtering in supported hardware screen) code cleanup -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New post published at blog.coreboot.org on June 23, 2015 at 4:33 am
A new post [GSoC] coreboot for ARM64 Qemu – Week #3 - http://blogs.coreboot.org/blog/2015/06/23/gsoc-coreboot-for-arm64-qemu-week-3/ has been published on June 23, 2015 at 4:33 am. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New post published at blog.coreboot.org on June 19, 2015 at 6:59 am
A new post [GSoC] Thinking about Logging - http://blogs.coreboot.org/blog/2015/06/19/gsoc-thinking-about-logging/ has been published on June 19, 2015 at 6:59 am. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New post published at blog.coreboot.org on June 18, 2015 at 6:29 pm
A new post [GSoC] End user flash tool – week #3 - http://blogs.coreboot.org/blog/2015/06/18/gsoc-end-user-flash-tool-week-3/ has been published on June 18, 2015 at 6:29 pm. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New post published at blog.coreboot.org on June 15, 2015 at 5:55 pm
A new post [GSoC] coreboot for ARM64 Qemu - Week #2 - http://blogs.coreboot.org/blog/2015/06/15/gsoc-coreboot-for-arm64-qemu-week-2/ has been published on June 15, 2015 at 5:55 pm. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New post published at blog.coreboot.org on June 12, 2015 at 8:45 am
A new post [GSoC] End user flash tool – week #2 - http://blogs.coreboot.org/blog/2015/06/12/gsoc-end-user-flash-tool-week-2/ has been published on June 12, 2015 at 8:45 am. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New post published at blog.coreboot.org on June 10, 2015 at 9:58 pm
A new post [GSoC] EC/H8S firmware week #2 - http://blogs.coreboot.org/blog/2015/06/10/gsoc-ech8s-firmware-week-2/ has been published on June 10, 2015 at 9:58 pm. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New post published at blog.coreboot.org on June 1, 2015 at 9:46 pm
A new post [GSoC] End user flash tool - http://blogs.coreboot.org/blog/2015/06/01/gsoc-end-user-flash-tool/ has been published on June 1, 2015 at 9:46 pm. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New post published at blog.coreboot.org on June 3, 2015 at 4:18 am
A new post [GSoC] coreboot for ARM64 Qemu - Week 1 - http://blogs.coreboot.org/blog/2015/06/03/gsoc-coreboot-for-arm64-qemu-week-1/ has been published on June 3, 2015 at 4:18 am. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New post published at blog.coreboot.org on May 28, 2015 at 11:17 pm
A new post Progress GSoC week #1 - http://blogs.coreboot.org/blog/2015/05/28/progress-gsoc-week-1/ has been published on May 28, 2015 at 11:17 pm. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New post published at blog.coreboot.org on May 19, 2015 at 6:45 am
A new post [GSoC-2015] Introduction – End user flash tool - http://blogs.coreboot.org/blog/2015/05/19/gsoc-2015-introduction-end-user-flash-tool/ has been published on May 19, 2015 at 6:45 am. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New post published at blog.coreboot.org on May 19, 2015 at 4:43 am
A new post [GSoC-2015] Introduction - Qemu Support for ARM64 - http://blogs.coreboot.org/blog/2015/05/19/gsoc-2015-introduction-qemu-support-for-arm64/ has been published on May 19, 2015 at 4:43 am. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New post published at blog.coreboot.org on May 19, 2015 at 3:53 am
A new post GSoC 2015 Introduction - Nicky Sielicki - http://blogs.coreboot.org/blog/2015/05/19/gsoc-2015-introduction-nicky-sielicki/ has been published on May 19, 2015 at 3:53 am. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New post published at blog.coreboot.org on May 19, 2015 at 4:00 pm
A new post GSoC 2015 H8S EC firmware - http://blogs.coreboot.org/blog/2015/05/19/gsoc-2015-h8s-ec-firmware/ has been published on May 19, 2015 at 4:00 pm. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New post published at blog.coreboot.org on May 11, 2015 at 8:58 pm
A new post On coreboot leadership... - http://blogs.coreboot.org/blog/2015/05/11/on-coreboot-leadership/ has been published on May 11, 2015 at 8:58 pm. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
