Re: [coreboot] ASUS KGPE-D16 Automated Test Failure [master]

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/24/2016 02:40 PM, Raptor Engineering Automated Coreboot Test Stand
wrote:
> The ASUS KGPE-D16 fails verification for branch master as of commit 
> 70385968cea517ed20dc3f3f665d92096acc768c
> 
> The following tests failed:
> BOOT_FAILURE
> 
> Commits since last successful test:
> 7038596 soc/intel/skylake: Bump up bootblock size to 48K
> a6914d2 soc/intel/skylake: align chromium Chrome OS config
> 
> See attached log for details
> 
> This message was automatically generated from Raptor Engineering's ASUS 
> KGPE-D16 test stand
> Want to test on your own equipment?  Check out 
> https://www.raptorengineering.com/content/REACTS/intro.html
> 
> Raptor Engineering also offers coreboot consulting services!  Please visit 
> https://www.raptorengineering.com for more information
> 
> Please contact Timothy Pearson at Raptor Engineering 
>  regarding any issues stemming from this 
> notification
> 

I'm not sure why this is failing.  I'm going to need to take it offline
for analysis.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJXvfj1AAoJEK+E3vEXDOFbs3IH/RoovUUICrdwgMAq5c2Pwm1J
Lnww7acnDgxRKuRHZ8fYhmCSVSdQ1zh0RuFo+fc98r0UyWABUvXrxSYsMWjH7jDm
ovkaX2B6NfqelttLPPXR2Xbuziug72bD94yar0PMQQ7yOaSTTurWCZ3nd9K/lSZc
E8Nr2GYvshc3p/xSsqV6WC1YL1rAW2Pf0VEPyBUyoinA9cvhU1RlO+qHRRwHn2Fc
hsaHhQgREE6M0U8j3rsvilKqhwxg/V/edWYrqtlT7xaQRgmmimisuBdb2qNoDOxX
zd5UCAd7UMopgukyIZpNXwXQj9CLfrzVJ7pXm8I5E1Mo60db32p9uEQUGS6Dn7I=
=LnC2
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] ASUS KGPE-D16 Automated Test Failure [master]

[Raptor Engineering Automated Coreboot Test Stand]

The ASUS KGPE-D16 fails verification for branch master as of commit 
70385968cea517ed20dc3f3f665d92096acc768c

The following tests failed:
BOOT_FAILURE

Commits since last successful test:
7038596 soc/intel/skylake: Bump up bootblock size to 48K
a6914d2 soc/intel/skylake: align chromium Chrome OS config

See attached log for details

This message was automatically generated from Raptor Engineering's ASUS 
KGPE-D16 test stand
Want to test on your own equipment?  Check out 
https://www.raptorengineering.com/content/REACTS/intro.html

Raptor Engineering also offers coreboot consulting services!  Please visit 
https://www.raptorengineering.com for more information

Please contact Timothy Pearson at Raptor Engineering 
 regarding any issues stemming from this 
notification


1472067614-3-automaster.log.bz2
Description: application/bzip2
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] Deciding on style for multi-line comments

[Vadim Bendebury]

I say let's stick with the Linux kernel style, this makes it easier to use
the tools.

And being a much bigger and much more mature codebase, kernel is not a bad
example to follow in general.

--vb

On Wed, Aug 24, 2016 at 12:08 AM, Paul Menzel via coreboot <
coreboot@coreboot.org> wrote:

> Dear coreboot folks,
>
>
> The coding style currently demands the following style of multi-line
> comments [1].
>
> > The preferred style for long (multi-line) comments is:
>
>
> /*
>  * This is the preferred style for multi-line
>  * comments in the Linux kernel source code.
>  * Please use it consistently.
>  *
>  * Description:  A column of asterisks on the left side,
>  * with beginning and ending almost-blank lines.
>  */
>
> This is straight from the Linux Kernel coding style [2].
>
> Certain parts of the code do not follow this style, so the question is
> how to deal with this. There has been some discussion on Gerrit about
> that [3]. But the list is the forum for such discussions, so I am
> bringing it up here.
>
> Julius’ last comment:
>
> > No offense, but that part of the Wiki literally reads:
> >
> > > For files in net/ and drivers/net/ the preferred style for long
> > > (multi-line) comments is a little different.
> >
> > ...so I'm not really sure why we should take something that has
> > obviously been carelessly bulk-copy into there from Linux
> > kernel sources eons ago as more authoritative than living development
> > practice of the last few years.
> >
> > The coreboot wiki is, sorry I have to say it, for the most part
> > pretty awful and outdated. It would probably be a good thing to fix
> > if somebody has the time for it, but until then I don't think we
> > should put too much stake into it (at least in the stuff that hasn't
> > been updated and maintained recently).
>
> I think that the extra blank lines in multi-line comments make them
> stand out better, which I prefer over having more lines on the screen.
>
> Also staying close to the Linux Kernel coding style makes it easier to
> use their tools, and not having to adapt them, and people only have to
> remember one style.
>
> But in the end it’s a matter of taste.
>
> So what should be done? Adapt the coreboot coding syle, or gradually
> change the style in the existing code, but require the style in new
> commits?
>
>
> Thanks,
>
> Paul
>
>
> [1] https://www.coreboot.org/Coding_Style#Commenting
> [2] https://www.kernel.org/doc/Documentation/CodingStyle
> [3] https://review.coreboot.org/16060
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot image signature

[Zoran Stojsavljevic]

Hello John,

Thank you for guiding me. I used last 5 years (while being with INTEL)
mainly HxD (for WIN). Did not used very long hex editors for Linux. Here it
is (your suggestion):
___

[zoran@localhost tools]$ dnf whatprovides hexedit
hexedit-1.2.13-8.fc24.x86_64 : A hexadecimal file viewer and editor
Repo: fedora

[root@localhost tools]$ sudo dnf install hexedit-1.2.13-8.fc24.x86_64
Last metadata expiration check: 4:34:55 ago on Wed Aug 24 09:22:24 2016.
Dependencies resolved.
==
 Package   Arch
Version   RepositorySize
==
Installing:
 hexedit   x86_64
1.2.13-8.fc24 fedora44 k

[snap - deleted unimportant logs]

Installed:
  hexedit.x86_64
1.2.13-8.fc24


Complete!
[root@localhost tools]$ which hexedit
/usr/bin/hexedit
___

Thank you again,
Zoran

On Wed, Aug 24, 2016 at 11:20 AM, John Lewis  wrote:

> Zoran,
>
> I'm a bit confused as to where you are coming from with this - you can
> search for ASCII/hex strings using something as light as hexedit. No need
> to install a more full-blown hex editor especially. I'm not a fan of using
> sledgehammers to crack nuts.
>
> John.
>
> On 24/08/16 09:54, Zoran Stojsavljevic wrote:
>
> > Please see https://www.coreboot.org/CBFS
>
> Hello John,
>
> From the pointer:* magic** is a 32 bit number that identifies the ROM as
> a CBFS type. The magic number is 0x4F524243, which is 'ORBC' in ASCII.*
>
> I did install on my F24 VM (in order to verify this info) wxHexEditor
> source code package (wxHexEditor-v0.23-src.tar.bz2):
> http://www.wxhexeditor.org/home.php
>
> Please, you can all try it, there are some environmental catches/packages
> and CCP flags (CCPFLAGS) to be added, but it is fairly manageable. Here is
> how GUI looks like:
>
> [image: Inline image 1]
>
> Interesting enough, wxHexAuthor Erdem (U. Altinyurt) is a jobless computer
> engineer, born and living since 1981,in Istanbul, Turkey. Why Erdem is
> jobless, that is the (crucial) question??? ;-)
>
> Zoran
>
> On Fri, Aug 19, 2016 at 11:49 AM, John Lewis  wrote:
>
>> Hi Benoit,
>>
>> Please see https://www.coreboot.org/CBFS
>>
>> Kind Regards,
>>
>> John.
>>
>> On 19/08/16 10:43, Benoit SANSONI wrote:
>>
>> Hi all,
>>
>> I would like to know if it is possible, via a signature or a magic
>> number, in the coreboot.rom file to recognize that it is a "coreboot" file.
>> I did not find anything in the Makefile.inc.
>>
>> Thanks in advance
>>
>>
>>
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Test hardware initialization in emulator

[Rishav Ambasta]

I am exploring Coreboot.
I had bought a Minnowboard, which will take some time to arrive.
Meanwhile I wanted to carry out the learning on an emulator.
I had compiled a ROM for QEMU and it ran successfully. I even tried with
different payloads (which I hear is the easy part of the boot process)
Now I wanted to learn the "hard" part, mainly RAM initialization and PCI
enumeration.

I had generated a ROM using the Minnowboard FSP, but I was not able to boot
QEMU using it.

Need suggestions on how can one, trace or at-least log the steps in the
boot-block stage, ROM stage and RAM stage of Minnowboard on an Emulator.

Regards,
*Rishav Ambasta*

*Save Plants, Save Life ...*
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot image signature

[John Lewis]

Zoran,

I'm a bit confused as to where you are coming from with this - you can
search for ASCII/hex strings using something as light as hexedit. No
need to install a more full-blown hex editor especially. I'm not a fan
of using sledgehammers to crack nuts.

John.


On 24/08/16 09:54, Zoran Stojsavljevic wrote:
> > Please see https://www.coreboot.org/CBFS
>
> Hello John,
>
> From the pointer:*/_magic_/*/_is a 32 bit number that identifies the
> ROM as a CBFS type. *The magic number is 0x4F524243, which is 'ORBC'
> in ASCII*._/
>
> I did install on my F24 VM (in order to verify this info) wxHexEditor
> source code package (wxHexEditor-v0.23-src.tar.bz2):
> http://www.wxhexeditor.org/home.php
>
> Please, you can all try it, there are some environmental
> catches/packages and CCP flags (CCPFLAGS) to be added, but it is
> fairly manageable. Here is how GUI looks like:
>
> Inline image 1
>
> Interesting enough, wxHexAuthor Erdem (U. Altinyurt) is a jobless
> computer engineer, born and living since 1981,in Istanbul, Turkey. Why
> Erdem is jobless, that is the (crucial) question??? ;-)
>
> Zoran
>
> On Fri, Aug 19, 2016 at 11:49 AM, John Lewis  > wrote:
>
> Hi Benoit,
>
> Please see https://www.coreboot.org/CBFS
>
> Kind Regards,
>
> John.
>
>
> On 19/08/16 10:43, Benoit SANSONI wrote:
>> Hi all,
>>
>> I would like to know if it is possible, via a signature or a
>> magic number, in the coreboot.rom file to recognize that it is a
>> "coreboot" file.
>> I did not find anything in the Makefile.inc.
>>
>> Thanks in advance
>>
>>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> 
> https://www.coreboot.org/mailman/listinfo/coreboot
> 
>
>

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot image signature

[Zoran Stojsavljevic]

> Please see https://www.coreboot.org/CBFS

Hello John,

>From the pointer:* magic** is a 32 bit number that identifies the ROM as a
CBFS type. The magic number is 0x4F524243, which is 'ORBC' in ASCII.*

I did install on my F24 VM (in order to verify this info) wxHexEditor
source code package (wxHexEditor-v0.23-src.tar.bz2):
http://www.wxhexeditor.org/home.php

Please, you can all try it, there are some environmental catches/packages
and CCP flags (CCPFLAGS) to be added, but it is fairly manageable. Here is
how GUI looks like:

[image: Inline image 1]

Interesting enough, wxHexAuthor Erdem (U. Altinyurt) is a jobless computer
engineer, born and living since 1981,in Istanbul, Turkey. Why Erdem is
jobless, that is the (crucial) question??? ;-)

Zoran

On Fri, Aug 19, 2016 at 11:49 AM, John Lewis  wrote:

> Hi Benoit,
>
> Please see https://www.coreboot.org/CBFS
>
> Kind Regards,
>
> John.
>
> On 19/08/16 10:43, Benoit SANSONI wrote:
>
> Hi all,
>
> I would like to know if it is possible, via a signature or a magic number,
> in the coreboot.rom file to recognize that it is a "coreboot" file.
> I did not find anything in the Makefile.inc.
>
> Thanks in advance
>
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [RFC] Deciding on style for multi-line comments

[Paul Menzel via coreboot]

Dear coreboot folks,


The coding style currently demands the following style of multi-line
comments [1].

> The preferred style for long (multi-line) comments is:


/*
 * This is the preferred style for multi-line
 * comments in the Linux kernel source code.
 * Please use it consistently.
 *
 * Description:  A column of asterisks on the left side,
 * with beginning and ending almost-blank lines.
 */

This is straight from the Linux Kernel coding style [2].

Certain parts of the code do not follow this style, so the question is
how to deal with this. There has been some discussion on Gerrit about
that [3]. But the list is the forum for such discussions, so I am
bringing it up here.

Julius’ last comment:

> No offense, but that part of the Wiki literally reads:
>
> > For files in net/ and drivers/net/ the preferred style for long
> > (multi-line) comments is a little different.
>
> ...so I'm not really sure why we should take something that has
> obviously been carelessly bulk-copy into there from Linux
> kernel sources eons ago as more authoritative than living development
> practice of the last few years.
>
> The coreboot wiki is, sorry I have to say it, for the most part
> pretty awful and outdated. It would probably be a good thing to fix
> if somebody has the time for it, but until then I don't think we
> should put too much stake into it (at least in the stuff that hasn't
> been updated and maintained recently).

I think that the extra blank lines in multi-line comments make them
stand out better, which I prefer over having more lines on the screen.

Also staying close to the Linux Kernel coding style makes it easier to
use their tools, and not having to adapt them, and people only have to
remember one style.

But in the end it’s a matter of taste.

So what should be done? Adapt the coreboot coding syle, or gradually
change the style in the existing code, but require the style in new
commits?


Thanks,

Paul


[1] https://www.coreboot.org/Coding_Style#Commenting
[2] https://www.kernel.org/doc/Documentation/CodingStyle
[3] https://review.coreboot.org/16060

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Motivating AMD to libreboot and RYF Re: [libreplanet-discuss] GNU Libreboot, version 20160818 released

[Logan Streondj]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Leah, thanks for the great news!
GNU Libreboot team, good work! :-D

I saw a few AMD motherboards on the list.
So it really got me motivated and
I opened a discussion on AMD developers forum entitled:
When will XDMA compatible motherboards support Libreboot and-or RYF?

For clarification XDMA are motherboards which have multiple PCIe3
slots, and allow for multiple GPU's to run in parallel together.

It allows for vast amount of cheap processing power to be used.
Remember that a GPU FLOP is 100 times cheaper than a CPU FLOP.
1 GPU GFLOP ~= $0.05, 1 CPU GFLOP ~= $5.

I'm hoping that you could comment in support of either AMD helping to
make Libreboot RYF compatible software stacks, or XDMA in particular.

Feel free to note the Libreboot versions of AMD hardware that are
available, as well as what would be required to make them top notch.
As well as anything that might be necessary to make AMD RYF compliant.

here is the forum thread:
https://community.amd.com/thread/204611

Thanks!
Logan

On 08/18/16 18:59, Leah Rowe wrote:
> GNU Libreboot 20160818
> 
> This is a brand GNU release. Libreboot joined the GNU project on
> 14 May 2016. This 18 August 2016 release is the first GNU release
> of libreboot.
> 
> Get it from https://libreboot.org/download/
> 
> NEW BOARDS ADDED: * ASUS Chromebook C201 (ARM laptop) (thanks to 
> Paul Kocialkowski) * Gigabyte GA-G41M-ES2L motherboard (desktop) 
> (thanks to Damien Zammit) * Intel D510MO motherboard (desktop) 
> (thanks to Damien Zammit) * ASUS KCMA-D8 motherboard (desktop) 
> (thanks to Timothy Pearson) * ASUS KFSN4-DRE motherboard (server) 
> (thanks to Timothy Pearson) * ASUS KGPE-D16 motherboard (server) 
> (thanks to Timothy Pearson) For details development history on 
> these boards, refer to the git log and documentation.
> 
> For boards previously supported, many fixes from upstream have
> been merged.
> 
> Other changes (compared to libreboot 20150518), for libreboot in 
> general or for previously supported systems: (this is a summary. 
> For more detailed change list, refer to the git log)
> 
> 256MiB VRAM allocated on GM45 (X200, T400, T500, R400) instead of 
> 32MiB. This is an improvement over both Lenovo BIOS and Libreboot 
> 20150518, allowing video decoding at 1080p to be smoother. (thanks 
> Arthur Heymans) To clarify, GM45 video performance in libreboot 
> 20160818 is better than on the original BIOS and the previous 
> libreboot release.
> 
> 64MiB VRAM on i945 (X60, T60, MacBook2,1) now supported in 
> coreboot-libre, and used by default (in the previous release, it 
> was 8MiB allocated). Thanks to Arthur Heymans.
> 
> Higher battery life on GM45 (X200, T400, T500, R400) due to higher 
> cstates now being supported (thanks Arthur Heymans). C4 power 
> states also supported.
> 
> Higher battery life on i945 (X60, T60, MacBook2,1) due to better 
> CPU C-state settings. (Deep C4, Dynamicl L2 shrinking, C2E).
> 
> Text mode on GM45 (X200, T400, T500, R400) now works, making it 
> possible to use MemTest86+ comfortably. (thanks to Nick High from 
> coreboot)
> 
> Dual channel LVDS displays on GM45 (T400, T500) are now 
> automatically detected in coreboot-libre. (thanks Vladimir 
> Serbinenko from coreboot)
> 
> Partial fix in coreboot-libre for GRUB display on GM45, for dual 
> channel LVDS higher resolution LCD panels (T400, T500). (thanks 
> Arthur Heymans)
> 
> Massively improved GRUB configuration, making it easier to boot 
> more encrypted systems automatically, and generally a more useful 
> menu for booting the system (thanks go to Klemens Nanni of the 
> autoboot project). Libreboot now uses the grub.cfg provided by the
>  installed GNU/Linux distribution automatically, if present, 
> switching to that configuration. This is done across many 
> partitions, where libreboot actively searches for a configuration 
> file (also on LVM volumes and encrypted volumes). This should make 
> libreboot more easy to use for non-technical users, without having
> to modify the GRUB configuration used in libreboot.
> 
> Utilities archives is now source only. You will need to compile
> the packages in there (build scripts included, and a script for 
> installing build dependencies in Trisquel 7). (binary utility 
> archives are planned again in the next release, when the new build
>  system is merged)
> 
> SeaGRUB is now the default payload on all x86 boards. (SeaBIOS 
> configured to load a compressed GRUB payload from CBFS
> immediately, without providing an interface in SeaBIOS. This way,
> GRUB is still used but now BIOS services are available, so you get
> the best of both worlds). Thanks go to Timothy Pearson of coreboot
> for this idea.
> 
> crossgcc is now downloaded and built as a separate module to 
> coreboot-libre, with a universal revision used to build all 
> boards.
> 
> Individual boards now have their own coreboot revision and
> patches, independently of each other board. This makes maintenance

[coreboot] New on blogs.coreboot.org: [GSOC] Panic Room, Recap

[WordPress]

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

[WordPress]

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] X220t missing ACPI events

[Nicola Corna]

Hello everyone,

I have a X220t with coreboot and I've noticed that two ACPI events are missing 
from the original BIOS:

video/tabletmode TBLT 008A 
video/tabletmode TBLT 008A 0001

These two are the ACPI events generated when the screen is flipped into 
"tablet" or "laptop" positions.
They are very useful because, when in "tablet" position, the back of the screen 
touches the trackpoint and generates random movements; with these ACPI events I 
could instruct the acpi daemon to disable the trackpoint in the tablet 
configuration.

Unfortunately I have no experience of ACPI tables, but I can easily flash the 
original BIOS and provide any dump or log if needed.
Any help?

Thanks
Nicola Corna

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot