[coreboot] New on blogs.coreboot.org: coreboot changelog Feb 17 - March 1

[WordPress]

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%)

Re: [coreboot] Fwd: Aspirant for GSOC 2016 with coreboot for ARM64 qemu port

[Saket Sinha]

Hi Stefan,

Thanks for the reply.

I am interested in working with the ARM64 support in coreboot which
was developed on Qemu last year. I want to carry forward the project
and bring the support over real ARM64 board(I would be having Rasberry
PI3 available with me pretty soon) .

Let me know how to get started on the same.


Regards,
Saket Sinha


On Mon, Mar 7, 2016 at 4:10 AM, Stefan Reinauer
 wrote:
> Hi Saket!
>
> Welcome to coreboot!
>
> Please check out our GSoC page at https://www.coreboot.org/GSoC and have a
> look at our three sub projects this year: coreboot, flashrom and SerialICE.
> If you have specific questions, please don't hesitate to ask.
>
> Stefan
>
>
> On 02/29/2016 11:38 AM, Saket Sinha wrote:
>>
>> Hi,
>>
>> Congratulations to the coreboot team for selection in GSOC 2016.
>>
>> I am looking forward to participate in GSOC 2016 with coreboot for
>> ARM64 qemu port.
>>
>> I request you to guide me as where to start with to prepare for this
>> project.
>>
>> Regards,
>> Saket Sinha
>>
>>
>>
>> -- Forwarded message --
>> From: Saket Sinha 
>> Date: Fri, Feb 12, 2016 at 10:24 AM
>> Subject: Aspirant for GSOC 2016 with coreboot for ARM64 qemu port
>> To: adur...@chromium.org, coreboot@coreboot.org
>> Cc: Patrick Georgi 
>>
>>
>> Hi,
>>
>> I think this is early for this but I am looking forward to participate
>> in GSOC 2016 with coreboot for ARM64 qemu port.
>>
>> This is to discuss the idea further.
>>
>> I guess the project was a part of last year GSOC as well so we already
>> have some base-work to start with.
>>
>> I request you to guide me as where to start with to prepare for this
>> project.
>>
>>
>> Regards,
>> Saket Sinha
>>
>
>
> --
> 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] On Memtest86+ change sets up for review

[Martin Roth]

Absolutely, please do. I'm not saying that I don't want development on
our tree.  I'm just not trying to take over from the memtest86+ guys
at canardpc.

I sent Doc TB a message to let him know that I had started the repo
here, but I've got no idea how active he is, or even if he's still
working on Memtest86+.  He hasn't responded to me yet.

Martin

On Wed, Mar 2, 2016 at 4:07 PM, Ben Gardner  wrote:
> I'm all for a sane hosting location of memtest86+.
> I marked all patches that I'm current using in my personal tree with
> 'code-review+2' in gerrit.
>
> I've been sitting on Baytrail support patches.
> If you are OK with this being an active branch, I can send those patches 
> along.
>
> Ben
>
> On Mon, Feb 29, 2016 at 3:51 PM, Martin Roth  wrote:
>> Hi Paul,
>>   I'm not really interested in taking over memtest86+, I'm just
>> creating a repository that we can build from and run as a payload.  I
>> originally looked at having the build process download the tarball and
>> apply patches, but once I got up to 10 patches, I opted for starting a
>> repo instead.  One of my patches is to brand this as a coreboot
>> release of Memtest86+ so that it's not confused with the 'official'
>> release.
>>
>> I supplied some patches to Doc TB for the 5.0 release, but i haven't
>> talked to anyone there recently.  If they wanted to make this the
>> official upstream repository and not use the coreboot branding, I'd be
>> fine with that, but that wasn't my intention in creating this repo.
>>
>> Martin
>>
>> On Mon, Feb 29, 2016 at 12:56 PM, Paul Menzel
>>  wrote:
>>> Dear coreboot folks,
>>>
>>>
>>> There are patches up for review [1], creating a new memtest86plus
>>> project [2].
>>>
>>> Martin, as you are the author, could you please give a little bit more
>>> information?
>>>
>>> The last Memtest86+ release seems to be from 2013, and looking at your
>>> change sets there are a lot of patches applied from the distributions.
>>> So there is not much maintenance going on upstream. I could not find a
>>> mailing list, but there is some activity in the forum [4].
>>>
>>> I am interested in what the goal is? Do we want to be the new
>>> Memtest86+ upstream?
>>>
>>> Have you talked to the Memtest86+ folks, so that they are informed?
>>> Will they hand over the domain for example?
>>>
>>>
>>> Thanks,
>>>
>>> Paul
>>>
>>>
>>> [1] https://review.coreboot.org/#/q/project:memtest86plus
>>> [2] https://review.coreboot.org/#/c/13818/
>>> [3] http://www.memtest.org/
>>> [4] http://forum.canardpc.com/forums/73-Memtest86-Official-forum
>>> --
>>> coreboot mailing list: coreboot@coreboot.org
>>> http://www.coreboot.org/mailman/listinfo/coreboot
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] Compile coreboot 4.3 for Pc Engines Alix2d3

[Andrey Korolyov]

On Mon, Mar 7, 2016 at 2:19 AM, Reto Rayen  wrote:
> Hi guys
>
>
>
> I tried now with the latest coreboot 4.3 to run the coreboot bios on a
> Alix2d3. But it always hangs after: «* DRAM Controller init done.». After
> this i do not see any further Output. Does anyone of you have a an idea what
> could be the issue?
>
>
>
> I added a ipxe Rom Image to the coreboot Rom. The layout is as follows:
>
>
>
> Name   Offset Type Size
>
> cbfs master header 0x0cbfs header  32
>
> fallback/romstage  0x80   stage12404
>
> fallback/ramstage  0x3180 stage69972
>
> fallback/payload   0x14340payload  60882
>
> pci1106,3053.rom   0x23180raw  81920
>
> config 0x37200raw  428
>
> revision   0x37400raw  602
>
> payload_config 0x376c0raw  1563
>
> payload_revision   0x37d40raw  219
>
> vsa0x37e80stage57532
>
> (empty)0x45f80null 236568
>
> bootblock  0x7fbc0bootblock768
>
>
>
> The config file with the build Options can be found here:
>
> https://file.youngsolutions.ch/index.php/s/MrXbSGYdS5E8DsH
>
>
>
>
>
> Here a trace of the full Output:
>
>
>
> Setup throttling delays to proper mode
>
> Done cpuRegInit
>
> Ram1.00
>
> Ram2.00
>
> * sdram_set_spd_register
>
> spd_read_byte dev 50 addr 15 returns ff
>
> * Check DIMM 0
>
> * Check DIMM 1
>
> spd_read_byte dev 51 returns 0xff
>
> * Check DDR MAX
>
> spd_read_byte dev 50 addr 09 returns 0a
>
> spd_read_byte dev 51 returns 0xff
>
> * AUTOSIZE DIMM 0
>
> * Check present
>
> spd_read_byte dev 50 addr 02 returns 07
>
> * MODBANKS
>
> spd_read_byte dev 50 addr 05 returns 01
>
> * FIELDBANKS
>
> spd_read_byte dev 50 addr 11 returns 04
>
> * SPDNUMROWS
>
> spd_read_byte dev 50 addr 03 returns 03
>
> spd_read_byte dev 50 addr 04 returns 0a
>
> * SPDBANKDENSITY
>
> spd_read_byte dev 50 addr 1f returns 40
>
> * DIMMSIZE
>
> * BEFORT CTZ
>
> * TEST DIMM SIZE>8
>
> * PAGESIZE
>
> spd_read_byte dev 50 addr 04 returns 0a
>
> * MAXCOLADDR
>
> * >12address test
>
> * RDMSR CF07
>
> * WRMSR CF07
>
> * ALL DONE
>
> * AUTOSIZE DIMM 1
>
> * Check present
>
> spd_read_byte dev 51 returns 0xff
>
> * set cas latency
>
> spd_read_byte dev 50 addr 12 returns 10
>
> spd_read_byte dev 50 addr 17 returns 3c
>
> spd_read_byte dev 50 addr 19 returns 4b
>
> spd_read_byte dev 51 returns 0xff
>
> * set all latency
>
> spd_read_byte dev 50 addr 1e returns 28
>
> spd_read_byte dev 51 returns 0xff
>
> spd_read_byte dev 50 addr 1b returns 0f
>
> spd_read_byte dev 51 returns 0xff
>
> spd_read_byte dev 50 addr 1d returns 0f
>
> spd_read_byte dev 51 returns 0xff
>
> spd_read_byte dev 50 addr 1c returns 0a
>
> spd_read_byte dev 51 returns 0xff
>
> spd_read_byte dev 50 addr 2a returns 46
>
> spd_read_byte dev 51 returns 0xff
>
> * set emrs
>
> spd_read_byte dev 50 addr 16 returns ff
>
> spd_read_byte dev 51 returns 0xff
>
> * set ref rate
>
> spd_read_byte dev 50 addr 0c returns 3a
>
> spd_read_byte dev 51 returns 0xff
>
> Ram3
>
> * DRAM controller init done.
>
>
>
> Gesendet von Mail für Windows 10
>
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot

Hi Reto,

I noticed that a month and a half ago [0] on a very simular board and
it turned to be a romcc issue as it was suggested here in ML. Using
very old tree, I was able to boot the board, though there was (still
unsolved, blame to myself) issues with cbfs ELF execution when VSA
blob is presented. If you would try to use some pre-cbfs alix/geode
code you would see the same issue with ELF loader (both cases could be
dirty-hacked for feeding an appropriate beginning of the bios
payload). I barely checked the presence of the endless loop and have
done zero effort yet to research from where it comes and if it
possible to fix it without getting too deep in a romcc code.

0. https://www.coreboot.org/pipermail/coreboot/2016-January/080867.html

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

[coreboot] Compile coreboot 4.3 for Pc Engines Alix2d3

[Reto Rayen]

Hi guys

I tried now with the latest coreboot 4.3 to run the coreboot bios on a Alix2d3. 
But it always hangs after: «* DRAM Controller init done.». After this i do not 
see any further Output. Does anyone of you have a an idea what could be the 
issue?

I added a ipxe Rom Image to the coreboot Rom. The layout is as follows: 

Name   Offset Type Size
cbfs master header 0x0cbfs header  32
fallback/romstage  0x80   stage12404
fallback/ramstage  0x3180 stage69972
fallback/payload   0x14340payload  60882
pci1106,3053.rom   0x23180raw  81920
config 0x37200raw  428
revision   0x37400raw  602
payload_config 0x376c0raw  1563
payload_revision   0x37d40raw  219
vsa0x37e80stage57532
(empty)0x45f80null 236568
bootblock  0x7fbc0bootblock768

The config file with the build Options can be found here: 
https://file.youngsolutions.ch/index.php/s/MrXbSGYdS5E8DsH


Here a trace of the full Output:

Setup throttling delays to proper mode
Done cpuRegInit
Ram1.00
Ram2.00
 * sdram_set_spd_register
spd_read_byte dev 50 addr 15 returns ff
 * Check DIMM 0
 * Check DIMM 1
spd_read_byte dev 51 returns 0xff
 * Check DDR MAX
spd_read_byte dev 50 addr 09 returns 0a
spd_read_byte dev 51 returns 0xff
 * AUTOSIZE DIMM 0
 * Check present
spd_read_byte dev 50 addr 02 returns 07
 * MODBANKS
spd_read_byte dev 50 addr 05 returns 01
 * FIELDBANKS
spd_read_byte dev 50 addr 11 returns 04
 * SPDNUMROWS
spd_read_byte dev 50 addr 03 returns 03
spd_read_byte dev 50 addr 04 returns 0a
 * SPDBANKDENSITY
spd_read_byte dev 50 addr 1f returns 40
 * DIMMSIZE
 * BEFORT CTZ
 * TEST DIMM SIZE>8
 * PAGESIZE
spd_read_byte dev 50 addr 04 returns 0a
 * MAXCOLADDR
 * >12address test
 * RDMSR CF07
 * WRMSR CF07
 * ALL DONE
 * AUTOSIZE DIMM 1
 * Check present
spd_read_byte dev 51 returns 0xff
 * set cas latency
spd_read_byte dev 50 addr 12 returns 10
spd_read_byte dev 50 addr 17 returns 3c
spd_read_byte dev 50 addr 19 returns 4b
spd_read_byte dev 51 returns 0xff
 * set all latency
spd_read_byte dev 50 addr 1e returns 28
spd_read_byte dev 51 returns 0xff
spd_read_byte dev 50 addr 1b returns 0f
spd_read_byte dev 51 returns 0xff
spd_read_byte dev 50 addr 1d returns 0f
spd_read_byte dev 51 returns 0xff
spd_read_byte dev 50 addr 1c returns 0a
spd_read_byte dev 51 returns 0xff
spd_read_byte dev 50 addr 2a returns 46
spd_read_byte dev 51 returns 0xff
 * set emrs
spd_read_byte dev 50 addr 16 returns ff
spd_read_byte dev 51 returns 0xff
 * set ref rate
spd_read_byte dev 50 addr 0c returns 3a
spd_read_byte dev 51 returns 0xff
Ram3
 * DRAM controller init done.

Gesendet von Mail für Windows 10

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

Re: [coreboot] Fwd: Aspirant for GSOC 2016 with coreboot for ARM64 qemu port

[Stefan Reinauer]

Hi Saket!

Welcome to coreboot!

Please check out our GSoC page at https://www.coreboot.org/GSoC and have 
a look at our three sub projects this year: coreboot, flashrom and 
SerialICE.

If you have specific questions, please don't hesitate to ask.

Stefan

On 02/29/2016 11:38 AM, Saket Sinha wrote:

Hi,

Congratulations to the coreboot team for selection in GSOC 2016.

I am looking forward to participate in GSOC 2016 with coreboot for
ARM64 qemu port.

I request you to guide me as where to start with to prepare for this project.

Regards,
Saket Sinha



-- Forwarded message --
From: Saket Sinha 
Date: Fri, Feb 12, 2016 at 10:24 AM
Subject: Aspirant for GSOC 2016 with coreboot for ARM64 qemu port
To: adur...@chromium.org, coreboot@coreboot.org
Cc: Patrick Georgi 


Hi,

I think this is early for this but I am looking forward to participate
in GSOC 2016 with coreboot for ARM64 qemu port.

This is to discuss the idea further.

I guess the project was a part of last year GSOC as well so we already
have some base-work to start with.

I request you to guide me as where to start with to prepare for this project.


Regards,
Saket Sinha




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

Re: [coreboot] GSoC 2016

[Stefan Reinauer]

On 03/06/2016 10:35 AM, Tahir Ramzan wrote:

Respected Sir,

I am a MS CS scholar of Virtual University of Pakistan, I want to 
participate in GSoC 2016 for coreboot. Data Science, Networks, 
Information security, digital forensics and ethical hacking are my 
core areas of interest.


Currently, I am working on a research project on live forensics of GPU 
and volatile memories like RAMs and Caches.


I am looking forward your guidance to start my contribution for 
coreboot, thanks in anticipation.


Regards
Tahir Ramzan


Hi Tahir,

Thank you for your interest. Your background looks very interesting!

did you take the time to determine what you might be interested in 
working on, already?
Please take a look at our GSoC page at https://www.coreboot.org/GSoC and 
the ideas pages of the three projects we are hosting this year 
(coreboot, flashrom, serialice) and let us know if you have any questions


Stefan

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

Re: [coreboot] Timestamp

[Stefan Reinauer]

On 03/06/2016 10:36 AM, daoud yessine wrote:

Hi

how we can get the timestamp from coreboot ?

what's the name of table in the source code in which the timestamps 
are saved ?

What is the configuration needed to obtain the timestamp table ?

thanks
ᐧ


TThe timestamps live in an area at the end of the memory below 4G that 
we call "CBMEM"


Other information like the in-memory console or code coverage 
information, lives in that same memory data structure.



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

Re: [coreboot] Coreboot table

[Stefan Reinauer]

On 03/06/2016 07:50 AM, daoud yessine wrote:

Hi

I need your help please :)

About coreboot table , where is its location in memory ? Its size ? 
Its contents ? Is it saved in buffer ?




The coreboot table typically lives at the end of physical memory in the 
4G space (e.g. in "cbmem space"). There is a
forwarder entry pointing to it, living in the lower 4k of memory 
(typically at 0x500)


The coreboot table contains various information coreboot collects about 
the system, such as

- memory map
- coreboot version
- cmos options
- framebuffer configuration

You can use the nvramtool utility to dump the coreboot table and look at it.

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

[coreboot] GSoC 2016

[Tahir Ramzan]

Respected Sir,

I am a MS CS scholar of Virtual University of Pakistan, I want to
participate in GSoC 2016 for coreboot. Data Science, Networks, Information
security, digital forensics and ethical hacking are my core areas of
interest.

Currently, I am working on a research project on live forensics of GPU and
volatile memories like RAMs and Caches.

I am looking forward your guidance to start my contribution for coreboot,
thanks in anticipation.

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

[coreboot] Timestamp

[daoud yessine]

Hi

how we can get the timestamp from coreboot ?

what's the name of table in the source code in which the timestamps are
saved ?
What is the configuration needed to obtain the timestamp table ?

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

[coreboot] Coreboot table

[daoud yessine]

Hi

I need your help please :)

About coreboot table , where is its location in memory ? Its size ? Its
contents ? Is it saved in buffer ?

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