[coreboot] switch or router hardware with coreboot

[Carl-Daniel Hailfinger]

Hi,

is there any currently commercially available switch or router hardware
(10Gbit/s or more) running coreboot and preferably also Linux?

I'm currently trying to build a PoC network where all components have
mostly FOSS firmware and operating systems.

My Wifi access points and 1 Gbit/s switches are running U-Boot and
OpenWrt, so on that tier I'm covered. OpenWrt is even running on very
few select 10 Gbit/s switches, but there the bootloader seems to be
U-Boot+blob.
For routing, I'm currently using PCEngines APU2 with coreboot and
Debian, but those are not really made to handle routing or even NAT at
more than 1 Gbit/s.

Once the PoC phase is done, I expect required routing/NAT/packet
filtering bandwidth to exceed 5 Gbit/s and I'd like to use a coreboot
based product for that.
If necessary, I can add a few network cards to a general-purpose server,
but a purpose-built device would be preferred.

Suggestions? Comments?

Thanks,
Carl-Daniel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] id.coreboot.org Keycloak server problems

[Carl-Daniel Hailfinger]

Hi,

I just tried to log in to Gerrit with the link "Keycloak OAuth2
(gerrit-oauth-provider plugin)
",
but the redirect to https://id.coreboot.org/... gets stuck during TLS
negotiation. Firefox says PR_END_OF_FILE_ERROR.

Regards,
Carl-Daniel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] FOSDEM 2023 stand for coreboot/flashrom

[Carl-Daniel Hailfinger]

Hi everyone,

I'm happy to tell you that we'll have a combined coreboot/flashrom stand
at FOSDEM.

When? Feb 4-5 2023
Where? ULB, Brussels, Belgium
Exact location? Building Aw, Level 1, Université libre de Bruxelles,
Campus du Solbosch, Avenue Franklin D. Roosevelt 50, 1050 Bruxelles, Belgium
Travel info: https://fosdem.org/2023/practical/transportation/
List of stands: https://fosdem.org/2023/stands/

Who? You!
Want to join? Sure! We would love to have 2+ people at the stand at all
times. It helps even if you can only help us for one hour.

Practical info if you want to join/help out/talk to visitors:
- Stand buildup has to be finished by Saturday 10:00
- Stand teardown starts at Sunday 17:00
- Stand duty on Saturday ends 19:00
- Stand duty on Sunday starts 9:00
- "Stand duty" is flexible (when and how long), but it would be cool if we can 
plan a little ahead.
- If you bring something, please tell me via email
- I will bring wired ethernet (if we're lucky and get something to plug
in)+power
- If you volunteer for stand duty, please tell me via email or show up
sometime on Saturday so we can plan Sunday shifts.



More info? Christian Walter and I will be managing the stand/booth.

Regards,
Carl-Daniel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: What should we do about freenode IRC services?

[Carl-Daniel Hailfinger]

Am 27.05.21 um 11:22 schrieb Urja Rannikko:
>>> Currently, on libera there are 46 people and on OFTC 2 people (me included).
>>>
>>> So I would say let's move to libera.
>> Agreed. Let’s do what most members in #coreboot users already did.
> +1
>
> I know I'm not a regular contributor or anything, but fwiw currently
> the only channels keeping me connected to freenode are #coreboot and
> #flashrom (I assume flashrom will just tag along where coreboot goes),
> so .. let's go, we've watched this long enough.

The shipped flashrom binaries, the man page and the README mention IRC
directly.

I think we should start with pointing users to a flashrom.org web page
instead of mentioning IRC in case another move (Matrix, IRC, Discord,
whatever) is needed or desired. Once such a patch is committed, we would
have to get all the distribution packages updated to point to the new
location. Doable, but it's a lot of work.

Regards,
Carl-Daniel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Error 404 , can't open change 38107 on Gerrit

[Carl-Daniel Hailfinger]

Hi Mike,

maybe the archives contain some salvageable info:
https://mail.coreboot.org/hyperkitty/list/coreboot-ger...@coreboot.org/

On 08.01.20 08:36, Mike Banon wrote:
> Same problem with many other "Drop boards with ROMCC_BOOTBLOCK"
> changes. So much work has been lost...
>
> On Wed, Jan 8, 2020 at 10:25 AM Mike Banon  wrote:
>> For some reason I couldn't open change 38107 - it gives me a 404 :
>>
>> https://review.coreboot.org/c/coreboot/+/38107
>> coreboot[master]: mb/gizmosphere/gizmo2: Drop boards with ROMCC_BOOTBLOCK
>>
>> Error 404 (Not Found): Not found: coreboot~38107
>>
>> This change is vitally important for preserving a Gizmo2 board, so I
>> hope you could fix this Gerrit problem.
>>
>> Best regards,
>> Mike Banon

Regards,
Carl-Daniel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: FOSDEM 2020 CfP

[Carl-Daniel Hailfinger]

Hi everyone,

the deadline for a stand is approaching quickly. I can't do this alone.
Does anyone want to be my backup organizer?

There are two devrooms which fit our profile perfectly:

FOSDEM 2020 Open Source Firmware, BMC and Bootloader Devroom
https://lists.fosdem.org/pipermail/fosdem/2019q4/002933.html

FOSDEM 2010 Hardware Enablement Devroom
https://fosdem.org/2020/schedule/track/hardware_enablement/

Please submit a talk!

Regards,
Carl-Daniel

On 29.09.19 00:45, Carl-Daniel Hailfinger wrote:
> Hi,
>
> we want to participate again in FOSDEM 2020. Location: Brussels. Date:
> 1&2 February.
>
> Deadlines:
> Own developer room: Expired...
> Stand: 1 November
> Main track talk: first batch 11 October, second batch 8 November
> Lightning talk: 22 November
> Talk/Demo in foreign devroom: probably end of October
>
> If you want me to submit a stand request for a combine
> coreboot/flashrom/LinuxBoot stand, please have someone volunteer as
> backup organizer. We also need stand volunteers.
> Side note: Should we reach out to the OpenBMC/u-bmc communities?
>
> https://fosdem.org/2020/news/2019-08-13-call-for-participation/
>
> Regards,
> Carl-Daniel
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] FOSDEM 2020 CfP

[Carl-Daniel Hailfinger]

Hi,

we want to participate again in FOSDEM 2020. Location: Brussels. Date: 1&2 
February.

Deadlines:
Own developer room: Expired...
Stand: 1 November
Main track talk: first batch 11 October, second batch 8 November
Lightning talk: 22 November
Talk/Demo in foreign devroom: probably end of October

If you want me to submit a stand request for a combine 
coreboot/flashrom/LinuxBoot stand, please have someone volunteer as backup 
organizer. We also need stand volunteers.
Side note: Should we reach out to the OpenBMC/u-bmc communities?

https://fosdem.org/2020/news/2019-08-13-call-for-participation/

Regards,
Carl-Daniel___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: April 10 and April 24 coreboot leadership meeting minutes

[Carl-Daniel Hailfinger]

Hi,

Am 26.04.19 um 23:01 schrieb Martin Roth:

--
24 April 2019 meeting minutes
--
Attendees: StefanR, WernerZ, PatrickG, MartinR, MattD, Dhendricks,
FelixH, PhilippD, Jay Trivedi, Aheymans
[...]

How does the coreboot project want to spend the money we’ve collected?
[...]
 * Request: Test setup on real hardware?
   - We need a plan on how to implement this.
   - The amount we’d be willing to spend per month depends on what we get.
     - We'd be looking at an upfront portion (cost of board +
setup fee) then a fee for ongoing maintenance.
   - How frequently are we looking at having the boards tested?
     - Every 4 hours / 1 day / every commit?
   - There’s worry about long-term sustainability of testing.
   - Just test a few key platforms


BSI has allocated a substantial sum of money (and a boatload of
mainboards) for this, but right now the problem is that I need to find
someone willing and able to maintain such a solution for us, and this
includes visiting the BSI premises (Bonn, Germany) if the problem is not
fixable remotely. The testing rig is offline right now since I lack the
time to take care of it.

If you know somebody willing and able to take on such a project, please
send an email to . Bonus points if
this is a solution used and maintained by someone else, i.e. the bus
factor should be greater than 1.

Regards,
Carl-Daniel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] FOSDEM 2019: Success!

[Carl-Daniel Hailfinger]

Hello everyone,

a huge THANK YOU to everyone who helped at the
coreboot/LinuxBoot/flashrom booth and/or gave talks or helped in other
ways at FOSDEM. The booth was busy the whole time, the rooms with the
talks were over capacity and each of you has helped spread the word
about our projects. There even was a hardware enablement devroom.

FOSDEM was awesome.

This wouldn't have been possible without you.

Thank you. See you next time.
Carl-Daniel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Fwd: FOSDEM stand info

[Carl-Daniel Hailfinger]

Hi everyone,

TL;DR:
- Our stand is in building Aw https://fosdem.org/2019/schedule/buildings/#aw
- Stand buildup has to be finished Saturday 10:00
- Stand duty on Saturday ends 19:00
- Stand duty on Sunday starts 9:00
- Stand teardown starts at Sunday 17:00
- If you bring something, please tell me via email
- I will bring wired ethernet (if we're lucky and get soemthing to plug
in)+power
- If you volunteer for stand duty, please tell me via email or show up
sometime on Saturday so we can plan Sunday shifts.

Have a great FOSDEM!

Thanks!
Carl-Daniel

 Forwarded Message 
From:   Pieter De Praetere 
Subject:[FOSDEM standholders] Practical information for your FOSDEM 
stand
To: standhold...@lists.fosdem.org



Dear FOSDEM stand organisers,

Welcome to FOSDEM! We are very happy to welcome your project this year. Please 
take your time to read through this information sheet and the Code of Conduct 
(https://fosdem.org/2019/practical/conduct/).

Stands are located in three buildings on the campus: the upper (+2) and lower 
(+1) corridors of the K building, the lower floor of H and the corridors of AW. 
The list of stands with their location is on the FOSDEM website (https://
fosdem.org/2019/stands/). Note that the exact location (in the building) will 
only be known closer to the event.

During FOSDEM, the stands team and the building coordinators can be reached 
via the H or K infodesk. If it is very urgent, an emergency phone number is 
available: +32 2 788 74 74.

Build-up

Before the conference begins on Saturday, you will have time to set up your 
stand. We ask that you start around 8:30 with building up your stand and finish 
around 10:00 so all stands are ready by the time our visitors arrive.

We will provide each stand with a table, chairs and a power cord. While we try 
to provide every stand with an individual power socket (Belgian E type - 
http://www.worldstandards.eu/electricity/plugs-and-sockets/), the layout of 
the building makes this sometimes impossible, so some stands will share a 
power cord.
WiFi (best-effort) will be present in all buildings, but we cannot provide 
fixed (ethernet) internet.

Please do not move the tables or chairs; the position of stands has to be 
agreed beforehand with ULB for fire safety reasons, so we have very little 
flexibility there. For the same reason, we cannot provide extra tables.

To prevent damage to the buildings, please do not attach anything to the 
walls, windows etc. You can bring anything else (e.g. roll banners, a new, 
branded, table cloth, demo items etc.), as long as it fits on your table 
(180x80 cm). 

During the event
-
For security reasons, we ask that there is always someone from the project 
present at your stand. This also gives visitors a more pleasant experience, as 
there will always be somebody at hand to answer questions.

We ask that you do not distribute food or drinks; we do not have permission 
from the ULB to do so. Small quantities (e.g. cookies) are OK, but large-scale 
distribution or the selling of large amounts of food or drink is not allowed.

You must vacate the building by 19:00 on Saturday. Buildings are closed during 
the night, but not guarded. You can store your valuable items in the cloak 
room during the night (after 18:00); but you should take your items out before 
8. Sunday is a very busy day for the because many people will leave their 
luggage in the cloak room.

Please keep the vicinity of your stand clean; life is better for everybody if 
the conference is nice and clean. 

Tear-down

When the event ends on Sunday, please clear up your stand and the immediate 
vicinity. There is a person responsible for every building, and they will be 
able to help you with any questions you might have regarding tear-down.

The clean-up starts when the devrooms close, usually around 17:00. By 17:30, 
everything should be packed up so we can clean and close the buildings. All 
items you brought, you should take back. So all posters, stickers, banners 
etc. that you used to decorate your stand, or did not hand out to visitors, 
you should take with you or throw in the trash. You would make the clean-up 
volunteers very happy if you take the time to gently sweep the surroundings of 
your stand.

Every building has a central "Collection point" where you should bring chairs, 
tables and all other FOSDEM equipment. You will also find brooms and garbage 
bags there. Please put chairs and tables on the correct carts, and all other 
FOSDEM equipment in the labeled boxes. It will save us a lot of time 
afterwards if everything is nicely packed up.


We hope you will have a pleasant experience at FOSDEM and that your project 
will benefit from having a stand. Should you have any more questions or 
remarks, don't hesitate to contact us via sta...@fosdem.org. 

Kind regards,

The FOSDEM stands team
___
coreboot 

[coreboot] Re: [flashrom] [LinuxBoot] FOSDEM 2019 deadline today

[Carl-Daniel Hailfinger]

On 01.02.2019 08:48, Martin Kepplinger wrote:
> On 24.01.19 01:05, Carl-Daniel Hailfinger wrote:
>> Hey everyone,
>>
>> just 9 days until FOSDEM in Brussels (2+3 February)!
>> There are a couple of talks about coreboot and LinuxBoot and we have a
>> coreboot/LinuxBoot/flashrom stand (building AW). Plus, there is a
>> hardware enablement devroom.
>>
>> - Who's coming?
>> - Are you volunteering for a shift at the stand?
>> - What demo hardware can you bring? (We have only 1 table, so smaller
>> hardware is preferred.)
>> - What merchandise/giveaways can you bring?
>> - Do we have 1-page flyers about each of coreboot, LinuxBoot and
>> flashrom? (PDF is sufficient, I can print in black+white if needed.)
>> - Do we have a large coreboot/LinuxBoot/flashrom banner which helps
>> others find our stand?
>>
> hi,
>
> how're you doing with organisation?

It's a bit chaotic, but I think we can manage.


> I'm doing a 10min lightning talk about my little x230 coreboot project
> tomorrow and obviously have that with me.
>
> There are talks I'll definitely attend, but in case you urgently need
> somebody at the stand for a short shift, please just ask.
>
> I only have my X230 and some flashing hardware with me.

It would be nice if you could stop by at our booth. We don't have a plan
yet for the shifts at the booth, but I hope we can get something
organized either tonight or tomorrow in the morning.

Thanks,
Carl-Daniel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [flashrom] [LinuxBoot] FOSDEM 2019 deadline today

[Carl-Daniel Hailfinger]

Hey everyone,

just 9 days until FOSDEM in Brussels (2+3 February)!
There are a couple of talks about coreboot and LinuxBoot and we have a
coreboot/LinuxBoot/flashrom stand (building AW). Plus, there is a
hardware enablement devroom.

- Who's coming?
- Are you volunteering for a shift at the stand?
- What demo hardware can you bring? (We have only 1 table, so smaller
hardware is preferred.)
- What merchandise/giveaways can you bring?
- Do we have 1-page flyers about each of coreboot, LinuxBoot and
flashrom? (PDF is sufficient, I can print in black+white if needed.)
- Do we have a large coreboot/LinuxBoot/flashrom banner which helps
others find our stand?

Please forward this email to those who you think are coming and might be
willing to help out. Thank you.

Regards,
Carl-Daniel


On 30.11.2018 09:59, Carl-Daniel Hailfinger wrote:
> Hi,
>
> * FOSDEM 2-3 February 2019
> * We have a coreboot/LinuxBoot/flashrom stand! Need people for the stand
> (2 days, 1 table).
> * We're invited to the Hardware Enablement Devroom! CFP deadline Dec 1
> 2018: https://lists.fosdem.org/pipermail/fosdem/2018q4/002797.html
>
> On 03.11.2018 14:20, Paul Kocialkowski wrote:
>> Le vendredi 02 novembre 2018 à 22:59 +0100, Carl-Daniel Hailfinger a
>> écrit :
>>> In that case, I'd also like to point you to the deadline for submitting
>>> main track talks which is tomorrow(!).
>>> https://fosdem.org/2019/news/2018-08-10-call-for-participation/
>>> Having a coreboot/LinuxBoot talk there would be awesome. Ron/David,
>>> could you submit something or do you have someone in mind who can do that?
>>>
>>> There's also lightning talks, deadline is a bit later.
>> I just submitted the CFP for the hardware enablement devroom at FOSDEM.
>> Submissions related to coreboot and associated projects can definitely
>> be in the scope of the devroom, so feel free to submit talks!
>>
>> Our submission deadline is December 1st, so there is still some time
>> ahead.
> Great, thank you!
>
> Regards,
> Carl-Daniel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [flashrom] [LinuxBoot] FOSDEM 2019 deadline today

[Carl-Daniel Hailfinger]

On 17.12.2018 15:28, Arthur Heymans wrote:
> Carl-Daniel Hailfinger  writes:
>> * FOSDEM 2-3 February 2019
>> * We have a coreboot/LinuxBoot/flashrom stand! Need people for the stand
>> (2 days, 1 table).
> I Live in Antwerp, so reasonably close by, so I will certainly be there
> and can lend a hand if needed. I can also bring some hardware to showcase
> but I don't own shiny new stuff. Maybe my setup using Felix's qspimux
> that I use to quickly test roms on hardware can be interesting to
> showcase?

That would be awesome.

Regards,
Carl-Daniel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: coreboot is under attack? many access problems recently, need to check that sources haven't been tampered

[Carl-Daniel Hailfinger]

Dear Ivan,

Patrick Georgi did all the work, he deserves all the thanks.

Best regards,
Carl-Daniel

On 31.12.2018 17:48, Ivan Ivanov wrote:
> Dear Carl-Daniel, thank you very much for your assuring reply, and for
> keeping the old "pipermail" mailing list archive because it is much
> easier to wget and browse with links text browser. Happy coming New
> Year ! ;-)
>
> Best regards,
> Ivan
>
> пн, 31 дек. 2018 г. в 19:40, Carl-Daniel Hailfinger
> :
>> On 31.12.2018 12:34, Ivan Ivanov wrote:
>>> Had a lot of access problems recently, both to coreboot website and
>>> its' repositories. Was it a DDoS attack? How to make sure that the
>>> sources at review coreboot repository haven't been modified during
>>> this event?
>> No need to worry. There was a scheduled server migration (better
>> hardware) and the mailing list software was updated as well. This took
>> quite a lot of resources. Things should be a lot snappier now.
>>
>> For details, see the following message:
>>
>> Date: Tue, 25 Dec 2018 00:40:41 +0100
>> Message-ID: 
>> 
>> Subject: [coreboot] mailing list changes
>>
>> Regards,
>> Carl-Daniel
>>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] Rowhammer mitigation: RH activation probability

[Carl-Daniel Hailfinger]

Actually, the latest Rowhammer attack is harder to exploit on laptops
due to the power saving features for row activation. Servers use a
different row activation strategy which has better performance, but also
enables one-location hammering.
See Gruss, Lipp, Schwarz, Genkin et al.:
Another Flip in the Wall of Rowhammer Defenses
2018 IEEE Symposium on Security and Privacy

Regards,
Carl-Daniel

On 14.12.2018 23:36, taii...@gmx.com wrote:
> Upon doing more research I am noting in regards to my previous post
> about vendors who claimed to solve the problem by doubling the RAM
> refresh rate in their firmware that according to [1] it only postpones
> the problem rather than eliminating it.
>
> [1]
> https://googleprojectzero.blogspot.de/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
>
> On 12/14/2018 03:20 AM, Nico Huber wrote:> On 07.12.18 22:46,
> taii...@gmx.com wrote:
>>> rowhammer is almost entirely a laptop problem or for that matter
>>> anything that uses SODIMM's due to their high density.
>> That doesn't seem right. Can you give any examples of chips commonly
>> used on SO-DIMMs that can't be found on DIMMs?
> Ahhh good point commodity parts.
>
>> I had the feeling you find the same chips on both. SO-DIMMs often host
> 16 chips. If you'd
>> want the same capacity on a DIMM with less chip density, you'd need
>> 32 chips (or physically bigger chips). Never seen that (though didn't
>> look for it either).
> I had read it somewhere awhile back when the problem first appeared
> stating that it didn't appear as much in desktops and servers due to
> lower density RAM which made sense to me considering the size difference
> I also tested my various home computers and only my laptops had a
> problem not the desktops/servers (all have ecc but it didn't show any
> errors) so I figured that it was an accurate statement. This shows the
> value of going back to quickly research something before providing the
> statement (and having others who aren't me to review!)
>
>
> On 12/14/2018 12:21 PM, ron minnich wrote:
>
>> So, at first we have a non-specific ad-hominem attack:
> I want people to get the best advice possible (hence my list of
> alternative sources) and while I can cite examples I am prohibited from
> potentially starting arguments about them so I do not want to.
>
> To me providing good advice is important since someone reading it could
> be facing a life or death situation such as a journalist in a hostile
> country and why I always apologize and note a correction if I give wrong
> advice. I am also a better sysadmin than I am a programmer so I
> concentrate on my strong points.
>
>> On Fri, Dec 7, 2018 at 1:53 PM taii...@gmx.com  wrote:
>>> I would like to note that company has provided poor security advice on a
>>> variety of occasions
>> followed by poor security advice:
>>
>>> rowhammer is almost entirely a laptop problem or for that matter
>>> anything that uses SODIMM's due to their high density.
>> which is immediately disproven with a 3 term search on google:
>> https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervisor-at-google-cloud-security-in-plaintext
>>
>> "The Google Project Zero team led the way in discovering practical
>> Rowhammer attacks against client platforms. Google production machines
>> use double refresh rate to reduce errors, and ECC RAM that detects and
>> corrects Rowhammer-induced errors."
>>
>> so, please all, no ad-hominem attacks, and if you're going to make a
>> technical claim, please be ready to provide justification.
> I had read it in a whitepaper somewhere and I am attempting to find out
> where.
>
> That is a good idea to have a citation on hand for claims like this and
> I will do so from now on as if I were editing the wiki.
>
>> thanks
>>
>> ron
> If a post of mine is not acceptable then I encourage you or others to
> exorcise your right to deny it as sometimes I do not realize what is and
> what isn't considered okay.
>


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

Re: [coreboot] [flashrom] [LinuxBoot] FOSDEM 2019 deadline today

[Carl-Daniel Hailfinger]

Hi,

* FOSDEM 2-3 February 2019
* We have a coreboot/LinuxBoot/flashrom stand! Need people for the stand
(2 days, 1 table).
* We're invited to the Hardware Enablement Devroom! CFP deadline Dec 1
2018: https://lists.fosdem.org/pipermail/fosdem/2018q4/002797.html

On 03.11.2018 14:20, Paul Kocialkowski wrote:
> Le vendredi 02 novembre 2018 à 22:59 +0100, Carl-Daniel Hailfinger a
> écrit :
>> In that case, I'd also like to point you to the deadline for submitting
>> main track talks which is tomorrow(!).
>> https://fosdem.org/2019/news/2018-08-10-call-for-participation/
>> Having a coreboot/LinuxBoot talk there would be awesome. Ron/David,
>> could you submit something or do you have someone in mind who can do that?
>>
>> There's also lightning talks, deadline is a bit later.
> I just submitted the CFP for the hardware enablement devroom at FOSDEM.
> Submissions related to coreboot and associated projects can definitely
> be in the scope of the devroom, so feel free to submit talks!
>
> Our submission deadline is December 1st, so there is still some time
> ahead.

Great, thank you!

Regards,
Carl-Daniel

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

Re: [coreboot] [LinuxBoot] FOSDEM 2019 deadline today

[Carl-Daniel Hailfinger]

In that case, I'd also like to point you to the deadline for submitting
main track talks which is tomorrow(!).
https://fosdem.org/2019/news/2018-08-10-call-for-participation/
Having a coreboot/LinuxBoot talk there would be awesome. Ron/David,
could you submit something or do you have someone in mind who can do that?

There's also lightning talks, deadline is a bit later.

OK, I'm submitting a request for a stand. I need a backup contact for
the stand. Who is willing to do that? AFAICS we can still change the
backup contact later if life happens.

Regards,
Carl-Daniel

On 02.11.2018 20:48, David Hendricks wrote:
>
>
> On Fri, Nov 2, 2018 at 9:15 AM 'Ron Minnich' via linuxboot
> mailto:linuxb...@googlegroups.com>> wrote:
>
> I"m leaning to yes, by which I mean if you do it, I'll show up.
>
> I can't believe I said that.
>     On Fri, Nov 2, 2018 at 7:20 AM Carl-Daniel Hailfinger
>  <mailto:c-d.hailfinger.devel.2...@gmx.net>> wrote:
> >
> > Hi!
> >
> > FOSDEM next year will be on 2 & 3 February 2019.
> > The deadline for applying for a stand is today.
> > Do we want a coreboot/flashrom/LinuxBoot stand/booth?
>
>
> Same as what Ron said. I think someone from FB can be there to talk
> about coreboot/LinuxBoot stuff and perhaps bring some hardware to demo.
>
>


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

[coreboot] FOSDEM 2019 deadline today

[Carl-Daniel Hailfinger]

Hi!

FOSDEM next year will be on 2 & 3 February 2019.
The deadline for applying for a stand is today.
Do we want a coreboot/flashrom/LinuxBoot stand/booth?

There will be a hardware enablement devroom as well, and we might be
able to participate there, but that's not necessarily giving us a chance
to talk to people all day.

Regards,
Carl-Daniel

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

Re: [coreboot] flashrom and 256 MiB S256FL256S

[Carl-Daniel Hailfinger]

On 27.09.2018 22:34, Nico Huber wrote:
> On 9/27/18 10:11 PM, ron minnich wrote:
>> yeah, also is there a programmer you recommend for 32MiB parts?
> Any programmer that can handle arbitrary SPI commands, e.g. single-
> board computers with native SPI interface (RPi, BeagleBone Black etc.),
> CH341A is popular but slow, FTDI based programmers are faster (FT232H/
> FT2232H/FT4232H), serprog programmers (some may not be too slow), Bus-
> Pirate rather slow too.

If you want programming to be fast (almost on par with Dediprog): Either
Raspberry Pi or Beaglebone Black.

The Beaglebone Black has an abysmal internal power supply and for any
in-circuit flashing you'll need an additional 3.3V supply for the flash
chip. For standalone chips it usually is sufficient, though.

The Raspberry Pi has SPI disabled by default, you need to add
dtparam=spi=on to the file /boot/config.txt .

Regards,
Carl-Daniel


> Nico
>
>> thanks
>>
>> ron
>>
>> On Thu, Sep 27, 2018 at 1:10 PM Nico Huber  wrote:
>>
>>> Ah, dediprog... you happen to have the one programmer that is hard to
>>> support.
>>>
>>> On 9/27/18 9:49 PM, ron minnich wrote:
 hmm, is this useful?

 Found Spansion flash chip "S25FL256S..0" (32768 kB, SPI) on dediprog.
 Erasing and writing flash chip... 4-byte address requested but master
>>> can't
 handle 4-byte addresses.
>>> That is expected, native 4-byte instructions are tried first but they
>>> are not implemented yet for dediprog. It should fall back to another
>>> instruction though. Unless the dediprog resets the chip between in-
>>> structions, it should actually work. Though, David seemed to have
>>> trouble with that too, I didn't test it myself yet.
>>>
 Looking for another erase function.
>>> Can you please just post the whole log (best taken with -o logfile).
>>>
>>> Nico
>>>
>


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

Re: [coreboot] How is our SPI API supposed to work?

[Carl-Daniel Hailfinger]

Sorry to interrupt, but it seems that there are conflicting definitions
of full-duplex...

On 19.04.2018 05:39, Aaron Durbin via coreboot wrote:
> On Wed, Apr 18, 2018 at 8:46 PM, Julius Werner  wrote:
>> I was trying to understand how to best implement the coreboot SPI API for a
>> new SoC, and as I was reading into it I got increasingly confused. This has
>> changed a bit last year (with the addition of struct spi_ctrlr), and I
>> don't think it was fully consistent before that across all implementations
>> either. Basically, we've always had the following base transfer prototype
>> (used to be spi_xfer(), now a callback in struct spi_ctrlr):
>>
>>  int (*xfer)(const struct spi_slave *slave, const void *dout, size_t
>> bytesout, void *din, size_t bytesin);
>>
>> There's also a more recent addition that can handle multiple transfer
>> "vectors" at once, and the code will fall back to the basic xfer() callback
>> if a controller doesn't implement this:
>>
>>  struct spi_op {
>>  const void *dout;
>>  size_t bytesout;
>>  void *din;
>>  size_t bytesin;
>>  enum spi_op_status status;
>>  };
>>  int (*xfer_vector)(const struct spi_slave *slave, struct spi_op
>> vectors[], size_t count);
>>
>> My question is basically what happens when bytesout and bytesin are both
>> non-zero. My previous understanding was always that the SPI controller
> It's up to the spi controller itself. They should support full duplex,
> if possible.

Are you aware of any flash chip supporting full-duplex operation?


>> should then operate in full-duplex mode, clocking out bytes from the dout
>> array while reading bytes into the din array in the same cycle. AFAIK no
>> driver in coreboot actually wants to use the controller this way, but it is
>> a legitimate way to operate a SPI bus and it's not impossible that we may
>> one day have a need for it. The Rockchip, Samsung and (I believe, those are
>> a little harder to read) Nvidia SoC drivers are implemented this way. There
>> is also the following comment (and associated implemented code) in
>> spi_flash.c:do_spi_flash_cmd() which makes me think that this understanding
>> was at least at some point the intended one:
>>
>>  /*
>>   * SPI flash requires command-response kind of behavior. Thus, two
>>   * separate SPI vectors are required -- first to transmit dout and
>> other
>>   * to receive in din. If some specialized SPI flash controllers
>>   * (e.g. x86) can perform both command and response together, it
>> should
>>   * be handled at SPI flash controller driver level.
>>   */
>>   <...array with two spi_op structs, one having only din and one
>> only dout...>
> cmd *then* response behavior. As you noted you'd have to eat the cmd
> bytes in the receive buffer. The issue is that we are dealing with 2
> different types of spi *flash* controllers:
> 1. generic spi controller that can do any normal spi thing
> 2. spi flash controllers on x86 systems. The ones on x86 systems are
> not a normal spi controller, and they can't really be treated like
> one.

Speaking with my flashrom hat on, it's a bit more complicated.

Duplex perspective:
There are two main types (and a few subtypes) of SPI controllers used
for flash:
1.) Full-duplex controllers: Capable of sending and receiving at the
same time
1.a) For each clock cycle, a bit is sent and a bit is received at the
same time (e.g. Raspberry Pi SPI)
1.b) For the first 8 clock cycles, a bit is sent. After that, for each
clock cycle, a bit is sent and a bit is received at the same time (e.g.
AMD SB600 and successors)
1.c) After a defined number of clock cycles, a constant number of bits
is ignored in both directions (e.g. 8 bits ignored for FAST READ
command, supported by some controllers)
2.) Half-duplex controllers: Capable of either sending or receiving at
any given time
2.a) Send-then-receive: A number of bits (>0) is sent, and after that a
number of bits (>=0) is received (e.g. Intel SPI)
2.b) After a defined number of clock cycles, a constant number of bits
is ignored in both directions (e.g. 8 bits ignored for FAST READ
command, supported by some controllers)

Programming perspective:
1. Single-transaction programming: Send+receive count as well as send
buffer and optionally receive buffer supplied in a single call, CS (chip
select) happens automatically at the beginning and end of the transaction
2. Separate CS programming, single-transaction buffer handling: Activate
CS, send+receive count as well as send buffer and optionally receive
buffer supplied in a single call, deactivate CS
3. Separate CS programming, two-transaction buffer handling: Activate
CS, send count+buffer in one call, optional receive count+buffer in one
call, deactivate CS
4. Separate CS programming, multi-transaction buffer handling: Activate
CS, send count+buffer in multiple calls, optional receive 

Re: [coreboot] coreboot is going to make kcma-d8 obsolete

[Carl-Daniel Hailfinger]

On 07.04.2018 14:37, taii...@gmx.com wrote:
> Yeah x86 is dead freedomwise but that doesn't mean boards that people
> know are functional should be removed from coreboot just because.

If people knew that those boards are functional, they would not get
removed from git master.

Sorry, lots of testimonies from people running ancient versions of
coreboot on any given board does by definition not constitute knowledge
about the functionality of current git master on that board.

Regards,
Carl-Daniel

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

Re: [coreboot] Upgrade the 12 years old LZMA libraries - should we do it?

[Carl-Daniel Hailfinger]

Hi Ivan,

On 03.04.2018 20:03, Ivan Ivanov wrote:
> I have noticed that both coreboot and seabios are using the very old
> versions of LZMA SDK.

True. I introduced the lzma code in coreboot (back when it was called
LinuxBIOS) when we were working on OLPC XO-1 support.


> If we will upgrade our LZMA libraries from the
> outdated-by-12-years 4.42 to the current version 18.04 , speed and
> compression ratio should improve and maybe a few bugs will be fixed.

Do you have any numbers for this? An improved compression ratio and
improved speed would be nice indeed, but how does the size of the
decompression code change? If the decompression code grows more than the
size reduction from better compression, it would be a net loss. A
significantly reduced decompression speed would also be a problem.
Decompression speed would have to be measured both for stream
decompression (i.e. the decompressor gets the compressed data in
single-byte or multibyte chunks) as well as full-size decompression
(i.e. the decompressor can access all compressed data at once). We also
have to make sure that stream decompression still works after the change.


> Do you think it should be done, or you are OK with using such an
> outdated version?

A size benefit for the resulting image is a good reason to switch.

Regards,
Carl-Daniel

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

Re: [coreboot] Real name policy

[Carl-Daniel Hailfinger]

On 06.03.2018 09:13, awokd via coreboot wrote:
> On Tue, March 6, 2018 1:58 am, Gregg Levine wrote:
>> That's a great reason right there. Who knows how much they contributed
>> to the state of the art, and did not properly sign it. But in the end while
>> their world was collapsing around them, we knew who they were via Groklaw.
>>
>>
>> On Mon, Mar 5, 2018 at 8:50 PM, David Hendricks
>>  wrote:
>>
>>> On Mon, Mar 5, 2018 at 1:13 PM, taii...@gmx.com 
>>> wrote:
>>>
 I can't understand as to why doing a git commit requires your "real"
 name
>>>
>>> SCO.
>>>
>>> Ref: https://lkml.org/lkml/2004/5/23/10
> Could some type of asset-less legal entity be set up (cheaply,
> anonymously) somewhere in the world to accept anonymous code donations and
> commit them on behalf of their submitter? Would shield open source
> projects from frivolous lawsuits and protect contributors' privacy.
> Apologies if this has already all been discussed thoroughly somewhere else...

You're suggesting to set up a corporation. Your model would be almost
the code equivalent to a patent troll, a non-practicing entity set up
for lawsuit purposes.

Besides that, any project knowingly accepting code from an entity known
for questionable provenance of submitted code would itself become an
easy target for lawsuits.

Regards,
Carl-Daniel

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

Re: [coreboot] Are multiple GPUs with lots of memory (ex: 8GB+8GB) supported in coreboot?

[Carl-Daniel Hailfinger]

On 10.02.2018 19:57, Arthur Heymans wrote:
> "taii...@gmx.com"  writes:
>> I would like to add this information to the wiki so I am wondering if
>> anyone has successfully used for instance dual 8GB graphics cards with
>> coreboot.
>>
> I don't think that this gpu memory is mapped into the linear memory
> space. Such a GPU will typically have a PCI memory resource BAR that is
> (only) 256M large (could be 512M or more these days).
>
>> I am not sure if this would be an issue due to coreboot only having
>> 32bit MMIO space.
>>
> It depends a bit on how things are configured but with a fairly common
> 2G mmio space below 4G I think it is unlikely for 2 external GPU's to be
> an issue.
>
> It would of course be nice to have 64bit BAR support but that would
> require substantial changes in the allocator and more importantly a lot
> of time spend in a sane and thoughtful design...

I think Myles Watson (not 100% sure) worked on an improved resource
allocator with 64 bit resource support for v3. I do not know if it ever
was merged in v4, or if that was instead a port of the v2 allocator to
v3, in which case this would be mostly what we have now. The mails about
this are mostly from 2009.

Regards,
Carl-Daniel

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

[coreboot] Server systems shipped with coreboot

[Carl-Daniel Hailfinger]

Hi,

does anyone have a list of server systems which are shipped with
coreboot? I'm interested in coreboot+UEFI systems, coreboot+Linux
systems, coreboot+SeaBIOS systems, pure coreboot systems.

At 34C3 I was told by someone that a major vendor has been shipping
servers with coreboot without announcing this, and I unfortunately
neither remember the server model nor who told me about this. If said
person could remind contact me, I'd be thankful.

Regards,
Carl-Daniel

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

Re: [coreboot] New bugtracker/wiki registration process - please do not use freenode irc servers

[Carl-Daniel Hailfinger]

On 31.10.2017 15:50, dz6g...@tuta.io wrote:
> There was a talk about the registration process on the wiki and the
> bugtracker. [...]
>
> The coreboot maintainer agreed that the recent registration process
> should be changed. There was a talk about to use a irc bot + webchat
> for that instead of the more common captcha.[...]
>
> But please dont use freenode irc or any other IRC server that are
> blocking TOR users.

https://freenode.net/kb/answer/chat contradicts your claims.
There are loads of people on the net disagreeing with you as well, and
there are even HowTos:
https://medium.com/@defcon201/tutorial-connecting-to-freenode-via-tor-like-a-boss-f8d74199b634

So... have you actually tried it?

Regards,
Carl-Daniel

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

Re: [coreboot] Possibility to tear electrically out the Bios chip

[Carl-Daniel Hailfinger]

Hello Vincenzo,

On 13.10.2017 08:37, ingegneriafore...@alice.it wrote:
> please, has some of you ripped out the BIOS chip from the motherboard when 
> the pc is power on ? 
> Has someone of you done this experiment ?
> Could be damages to the motherboard ?

Many times. It always worked if the chip was in a socket. I have not
tried desoldering a chip in a running machine.
Modern Intel systems may cause problems if the Management Engine tries
to access the flash chip while it is removed, but IO'm not an expert on
that.


> Or maybe Coreboot should be programmed to switch electrically off the chip 
> before tear out it from its case ?

You can't switch off the power for the flash chip because there is no
switch in the hardware.


> I pose this question because, if really the Bios chip is only necessary for 
> the boot process of a machine, has not sense that it is on board during the 
> usual activity of the O.S.
>
> So, is it possible tear out it from its case after the boot process, when the 
> pc is working and the O.S. has taken into account the whole control of the pc 
> ?

I had some older PCs work fine without a flash chip for more than 4
weeks. Obviously, they needed the flash chip for booting, but after that
I had removed it.
For modern systems, it depends on various components and where their
firmware and/or configuration data is stored. A generic answer is not
really possible anymore.


> Tips are welcome. Thanks very much in advance !
>
> I hope to hear you soon.
>
> Best Regards.
>
> Vincenzo.


Regards,
Carl-Daniel

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

[coreboot] FOSDEM 2018, Feb. 3+4

[Carl-Daniel Hailfinger]

Hello everyone,

who's up for organizing a booth and maybe a devroom at FOSDEM 2018?

https://fosdem.org/2018/news/2017-08-21-dates-fosdem-2018/

Regards,
Carl-Daniel

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

[coreboot] coreboot at FrOSCon Germany? CFP ends tomorrow

[Carl-Daniel Hailfinger]

Hi,

the Call for Projects for the FrOSCon conference deadline is tomorrow.
https://www.froscon.de/1/cfp/cfprojects/

Conference date: 19th and 20th August 2017
Location: University of Applied Sciences Bonn-Rhein-Sieg, Sankt
Augustin, Germany

Did anybody already submit a proposal? If not, I'll try to make an
attempt at it.

I can be there, and I know the location. Last year coreboot was present
at the booth of the BSI (Bundesamt für Sicherheit in der
Informationstechnik, Federal Office for Information Security Germany),
but I'm not yet sure if there will be a BSI presence again. If there is
a BSI presence, I will be in charge of that as well, so unless anybody
else volunteers, I'll try to handle this as a joint appearance again.

Regards,
Carl-Daniel

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

Re: [coreboot] The OpenSSD Project

[Carl-Daniel Hailfinger]

Hi,

On 05.04.2017 15:48, taii...@gmx.com wrote:
> An alternative to blobbed drive firmware.
>
> http://www.openssd-project.org/wiki/The_OpenSSD_Project

Yes, Cosmos and Jasmine are really nice research platforms.

Jasmine is pretty old and you can't really use sizes above 30 GB or so.
It has a SATA interface and is really well documented.
Cosmos is new and I wouldn't yet recommend to use it as regular disk
with a normal general purpose OS because the internal wear leveling is
pretty basic. And depending on which part of the documentation you're
looking at, it also might not even be in a generally usable state
(incomplete code).


> I would like to share this and ask for opinions before I add it to the
> wiki.

You could mention it as research platform, but except for SSD related
research (graduate or PhD level) I don't see much use. If you're the
"free as in freedom" type and don't mind working with an old 30 GB SSD,
Jasmine should be stable enough to use.


> It is really neat that you can upgrade the memory chips individually,
> which should offset the high price.

Not in the foreseeable future. The base hardware is made for research
and is made in really small quantities, so the price is a few thousand
dollars higher than a mass-produced SSD controller board. Besides that,
buying flash without a controller is often more expensive than buying
flash with a controller because an attached controller can validate the
flash in-circuit, whereas without controller the flash manufacturer has
to spend money on expensive testing equipment. (See flash in SD cards
for an example.)

Besides that, it's hard to actually buy any OpenSSD platform. I tried
(for my PhD research), but never got a response from the official sales
contact. If you actually succeed, please tell me so I can buy some.

Regards,
Carl-Daniel

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

Re: [coreboot] How come the community meeting is hosted by proprietary software?

[Carl-Daniel Hailfinger]

On 17.03.2017 15:50, Juliana Rodrigues wrote:
> Don't know if anyone brought this up yet, but the FOSS communities
> that I know uses jitsi: https://meet.jit.si

Does it work better on low-end devices than it did a year ago? Back then
WebRTC was pretty much unusable in the browsers I tried on a Thinkpad
T60, mostly due to CPU limitations.
(Admittedly I haven't tried Bluejeans on my T60, so I can't compare the
two.)

Regards,
Carl-Daniel

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

[coreboot] European coreboot conference 2017

[Carl-Daniel Hailfinger (coreboot conference)]

Hello everyone,

we are currently planning to host a coreboot conference in Germany with 2 days 
of talks and an additional 2 days of hacking.
The date will probably either be October 19-22 or October 26-29, i.e. directly 
before or after Embedded Linux Conference Europe and LinuxCon Europe.

Ticket prices haven't been decided yet and depend on the location and venue 
availability.

The location will be either in Bonn or Bochum. Both Bochum and Bonn offer a 
variety of interesting activities for conference participants.
Bochum is reachable by public transport from Frankfurt Airport within 120 
minutes, from Dusseldorf Airport within 40 minutes and from Cologne Airport 
within 80 minutes.
Bonn is reachable by public transport from Frankfurt Airport within 70 
minutes, from Dusseldorf Airport within 70 minutes and from Cologne Airport 
within 30 minutes.

YOUR ACTION NEEDED! 

Please fill out the application and subscribe to the newsletter if you are 
planning to join us!

https://www.coreboot.org/events/ecc2017

Sincerely,
-- 
Hailfinger, Carl-Daniel
_
Section CK 14 - Cyber Security in Operating Systems and Applications
Federal Office for Information Security (BSI)

Godesberger Allee 185-189
53175 Bonn, Germany
phone:+49 (0)228 9582-5939
fax:  +49 (0)228 9582-5400
e-mail:   coreboot-confere...@bsi.bund.de
internet: www.bsi.bund.de

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

Re: [coreboot] power controller/serial port mux

[Carl-Daniel Hailfinger]

On 10.01.2017 22:56, ron minnich wrote:
> I need an ethernet-attached device for controlling power to 4 to 8 systems

With Schuko plug this ethernet controlled power strip is pretty nice
(they also have a USB-controlled variant)
http://energenie.com/item.aspx?id=7557=en

> and also a serial port mux which can allow multiple users to go to
> different systems. 
>
> If there is a box that does both that's a plus. I figure this group
> knows more than anybody about a good choice.

To be honest, if you want a cheap and scalable solution with good
electrical isolation, the solution I've seen quite often is to buy
wirelessly controllable power sockets (pack of 4 retails for ~15 EUR in
Germany). Wire up the power socket remote control with a raspberry pi
and you're done.

For serial ports, I just hooked up a bunch of USB-serial adapters to a
Raspberry Pi. Then again, this solution is probably unusable for
multi-user environments.

Regards,
Carl-Daniel

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

Re: [coreboot] chat.coreboot.org is on

[Carl-Daniel Hailfinger]

Hello Zoran,

I think a forum is too time-consuming to be useful. A forum makes sense
if you have volunteers with too much spare time like the various Linux
distributions.

A forum also means you need moderators to handle takedown requests,
complaints from users and other stuff. If you take a look at most
forums, you will notice that people add their signature (with lots of
smileys and useless info) to each post and the signal/noise ratio gets
really bad after some time.

There is also the danger that all forum contents will be lost if we ever
migrate from one forum software to another or if the server with the
forum crashes/dies. With distributed mailing list archives, that is
really unlikely.

Regards,
Carl-Daniel

On 07.01.2017 10:45, Zoran Stojsavljevic wrote:
> If you allow me, the (much) better decision will be to organize web
> forum/web domain http://www.coreboot.forum.com. Something lookalike:
> http://www.forums.fedoraforum.org/
>
> There are many advantages why to do this. I'll spell out few. Much
> higher visibility. Much more professional approach.
>
> On Sat, Jan 7, 2017 at 8:42 AM, Patrick Georgi  > wrote:
>
> we've set up a mattermost instance on https://chat.coreboot.org/
> in the hope to lower the barriers to entry into our community.
>
> It comes with a bridge to IRC, history (but not web-indexable,
> which was a major concern with IRC logs so far) and the ability to
> start topic channels that are discoverable yet separate from the
> main discussion.
>


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

Re: [coreboot] Welcome to the new coreboot.org!

[Carl-Daniel Hailfinger]

On 08.09.2016 02:50, Stefan Reinauer wrote:
> As some of you might already have noticed, our new web presence
> has gone live on https://www.coreboot.org/ today!
>
> I want to use this chance to send a big shout out to Philipp Deppenwiese
> and Martin Roth, and all the others that have been involved in making
> this moment happen, for their great work!

This is really awesome!

Thank you!

Regards,
Carl-Daniel

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

[coreboot] FOSDEM 2017

[Carl-Daniel Hailfinger]

Hi,

FOSDEM 2017 deadlines are soon.

Do we want to have a full developer room, a talk or just a stand?

Unfortunately I won't be able to attend, so someone else will have to be
the formal contact for organizing our stand/devroom/talk. I will help
with submitting proposals if this is desired by the person organizing
our stand/devroom/...

Who is willing to take care of our FOSDEM 2017 presence?

https://fosdem.org/2017/news/2016-07-20-call-for-participation/

Deadlines:

Developer Rooms: 9 September
Main Track Talks: 10 October
Stands: 31 October
Lightning talks: 25 November

Regards,
Carl-Daniel

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

Re: [coreboot] How to protect binary in flash chip? OTP?

[Carl-Daniel Hailfinger]

On 06.05.2016 09:49, Patrick Rudolph wrote:
> On 2016-05-06 02:45 AM, Zheng Bao wrote:
>> Is there any way to protect the binary image in flash chip from being
>> copied? Once the customers
>> gets the image, they can produce millions of board and do not tell me.
>> I just want to know the
>> amount of the mass production.
>> [...]
> 
> As you want to execute code from it, it needs to be readable.
> Protecting it from software doesn't make much sense as you could just
> de-solder the flash chip.
> 
> I guess what you want to know is: Should a copied image boot on another
> board ?
> 
> I've got two solutions:
> 1.
> You could encrypt the binary and store the secret in a TPM.
> That way every board would have the same encryption key.
> No idea if this is possible on your platform and how much work it would
> be to implement in coreboot.
> That'd be a good GSoC project :-)
> 
> 2.
> If you don't have a TPM you could use serial numbers of
> CPU/Southbridge/SoC.
> That way every board would have it's own encryption key.
> But I guess the decryption code could easily be reversed engineered.

I wouldn't go with encryption, but rather with some check which refuses
to boot if serial number (SoC, MAC address, ...) and a hash of it (in
OTP) mismatch. That way even reflashing the board won't erase the hash
by accident, and you can just give the manufacturer as many OTP images
as needed. They just need to supply the serial numbers to you in advance.


> An end user would be able to do a backup and would be able to reflash
> the bios *on the same board*.

Yes, ability to reflash is important.

Regards,
Carl-Daniel

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

Re: [coreboot] Flash ROM locking on S3 resume

[Carl-Daniel Hailfinger]

On 18.04.2016 19:02, David Hendricks wrote:
> On Mon, Apr 18, 2016 at 8:48 AM, Trammell Hudson  wrote:
> 
>> I'm curious why this is an option, especially since it seems almost tailor
>> made to re-create the Snorlax or Prince Harming vulnerabilities
>> (VU#577140):
>>
>> Flash ROM locking on S3 resume
>>> 1. Don't lock ROM sections on S3 resume (LOCK_SPI_ON_RESUME_NONE) (NEW)
>>   2. Lock all flash ROM sections on S3 resume (LOCK_SPI_ON_RESUME_RO) (NEW)
>>   3. Lock and disable reads all flash ROM sections on S3 resume
>> (LOCK_SPI_ON_RESUME_NO_ACCESS) (NEW)
>>
> 
> Maybe the default just needs to be changed to LOCK_SPI_ON_RESUME_RO?
> 
> LOCK_SPI_ON_RESUME_NONE is probably intended for developers who need to
> re-flash their systems a lot and might not want to rely on external
> programmers (especially for laptop development).


>From a defense in depth perspective, LOCK_SPI_ON_RESUME_NO_ACCESS is
more dangerous than LOCK_SPI_ON_RESUME_NONE. The former provides for
perfect stealth from in-system monitoring, the latter at least gives
in-system code a chance to perform a self-check even if a self-check of
a compromised system is very hard to do correctly and sometimes not
possible at all.

That said, I do see value in LOCK_SPI_ON_RESUME_NONE because it enables
use cases like automated coreboot test systems. Speaking with my
flashrom hat on, if you want to use it to write to the main system
flash, you have to make sure any written region is not marked readonly.

Changing the default setting to LOCK_SPI_ON_RESUME_RO may be a good
choice for quite a few use cases.

Regards,
Carl-Daniel

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

[coreboot] [RFC] board-status.git growth

[Carl-Daniel Hailfinger]

Hi,

since various automated systems started submitting board status files,
the board-status repository has grown significantly to a point where
submitting a new board from scratch requires a download which is bigger
than the whole coreboot repository.
Once I hook up four more systems in my lab, I expect this growth to
accelerate quite a bit. It will get even more extreme once I start
testing every commit instead of limiting the tests to one per hour.

This poses three problems:

1. Download size for people wanting to submit new logs.
Can be solved with shallow git clones of the board-status repository.

2. Download size for people wanting to find out where some breakage
happened.
Not really solvable unless we commit less reports, and that makes
bisection harder.

3. Server load for anything working with the board-status repo.
This means gitweb and the wiki, and that's not a problem (yet).

Should we just ignore the size until it becomes too large, is size not a
problem or should we immediately do something?

Regards,
Carl-Daniel

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

Re: [coreboot] commit messages and their suitability for coreboot.org

[Carl-Daniel Hailfinger]

Hi,

given that testing is something I value a lot, I'd like to chip in.


On 23.12.2015 17:06, Aaron Durbin via coreboot wrote:
> On Tue, Dec 22, 2015 at 7:12 PM, Alex G.  wrote:
>> [...]For the
>> sake of example, I will pick on a RABDOM commit message which follows
>> the format:
>>
>> BUG=chrome-os-partner:48412
>> BUG=chromium:445938
>> BRANCH=None
>> TEST=TBD
>> [...]
>> ### TEST tags ###
>>
>> The general attitude towards a patch is "if people have to ask how you
>> tested it, then you probably need to include it in the commit message".
>> There's no hard rule towards the format of the commit message body, so
>> TEST tags are perfectly fine.
>>
>> What is not fine is TEST tags that have no useful information. In this
>> case, a feature is introduced, and some later patch, the feature is
>> used. Where should the feature get tested? The patch that adds the
>> feature? The patch that uses the feature? There are cases where patches
>> have to be tested in bulk, and that's fine. Please describe the testing
>> methodology only on the last patch of the series.
>>
> Indeed good feedback on the code review, but it's not there. Actually,
> it looks like I didn't backfill what I did. Thanks for the pointer.
>
>> A very common TEST tag says "built and booted ". That's lazy.
>> First, every coreboot commit is build-tested build jenkins for each
>> board. Restating that the patch builds for a specific board is redundant.
> But it's not booted so in that sense it's actually a positive signal.
> Jenkins building also doesn't cover all the combinations of options
> that something could be impacted by.

One of the problems of jenkins is that it didn't detect that qemu normal
image (instead of simple fallback-only) didn't compile for half a year.
With the expected combinatorial explosion, this is expected, but it
still doesn't make me happy.
Maybe it would make sense to say "build-tested in a non-jenkins config"
if that was tested.

 
>> What does "booted" mean? Does it mean boot to ramstage? Does it mean
>> boot to payload? Which payload? Does it mean boot to kernel? Which
>> kernel? Does kernel crash or reach shell? Does it bluescreen? Does it
>> reach a shell? Graphical shell? Console shell? Is the console over
>> serial? Is it over network? Does USB work? Can you access SATA drives?
>> From what media was your kernel loaded?
>>
>> You get the point. "booted" provides no meaningful information. If your
>> testing involved "building and booting" a specific board, then please
>> leave out the TEST tag from your commit message, or remove it before
>> pushing the commit to coreboot.org.
> If you juggle that many definitions of 'booted' in your head I can see
> why the pedant comes out. It is my understanding that booted means
> booting through the OS to userspace. Is there really other
> definitions? And if there are wouldn't those be less progressing?
>
> Again, feel free to ignore it as well. While it may not be beneficial
> to you it may be beneficial to others.

Would flags help? E.g. payload+linux+net+usb?

Would it make sense to include a link to the boot log (that is, coreboot
console and dmesg)? Photo of the screen (to confirm gfx)?

>From my perspective, it would be great to use REACTS output in a way
that helps people check/confirm the awesomeness of a patch.

Regards,
Carl-Daniel

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

[coreboot] Fwd: Your stand proposal for FOSDEM 2016 has been accepted

[Carl-Daniel Hailfinger]

Hello everyone,

let's make this our best FOSDEM stand presence ever!
https://www.coreboot.org/FOSDEM_2016

Please fill in https://www.coreboot.org/Talk:FOSDEM_2016 if you're coming.

Regards,
Carl-Daniel

 Forwarded Message 
From: FOSDEM Stands Team 
To: Carl-Daniel 
Subject: Your stand proposal for FOSDEM 2016 has been accepted
Message-Id: <20151214195515.c04a3cb...@mailhost.gletsjer.net>
Date: Mon, 14 Dec 2015 20:54:56 +0100 (CET)

Hi Carl-Daniel,

The FOSDEM stands team is glad to be able to inform you that your request
for a stand for 'coreboot_flashrom' has been accepted.
There will be two tables reserved for you.

Like most years, we received roughly twice as many requests for stands
as we have tables available. We have aimed to grant as many requests as
feasible and to increase the diversity of the accepted stands. Because
of this, we have unfortunately had to reduce the space available for a
number of regular attendees, as well as reject some projects that have
been present in previous years years.

You will receive further information about what's expected of you closer
to the event date.

Looking forward to seeing you at FOSDEM 2016!

Kind regards,

Wynke Stulemeijer
FOSDEM stands team


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

Re: [coreboot] Re : FOSDEM deadlines now!

[Carl-Daniel Hailfinger]

[DEADLINE IS NOW+48 hours!]
Hi,

thanks to Paul and Florentin for announcing they will come and thanks to
Paul for submitting a talk!

Who else is coming?
Do we want one or two tables?

Regards,
Carl-Daniel

On 21.10.2015 10:15, eche...@free.fr (Florentin) wrote:
> +1
>
> * for the stands count me in : I can bring my AMD boards and if all is going 
> well I will be able to do demos on my G505s laptop. (I will also bring 
> various electronic stuff and tools..)
> * for the main tracks I cannot help unfortunately
> * for the lightining traks I have some (bold!) ideeas but they are not mature 
> yet (and I must first discuss with you about this .. maybe on irc..)


On 31.10.2015 10:41, Paul Kocialkowski wrote:
> I will definitely be around at FOSDEM, not sure I should have a seat at
> the table at this point (I'm still pretty new to the community), but I'd
> be happy to come by!

> ----- Mail d'origine -
> De: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2...@gmx.net>
> À: coreboot <coreboot@coreboot.org>, flashrom <flash...@flashrom.org>
> Envoyé: Tue, 20 Oct 2015 23:20:56 +0200 (CEST)
> Objet: [coreboot] FOSDEM deadlines now!
>
> Hi,
>
> we obviously want to participate in FOSDEM.
> https://fosdem.org/2016/news/2015-09-24-call-for-participation/
>
> ACT NOW!
>
> Some deadlines already expired. Some can still be managed.
>
> Main track talks: Deadline 2015-10-30 (10 days left)
> One hour of entertainment, huge audience.
> Anyone up for the challenge?
>
> Stands: Deadline 2015-11-13 (24 days left)
> I can send in the proposal if I'm not going to be alone there.
> How many tables do we want for our stand/booth(s)?
> Who is coming?
>
> Lightning talks: Deadline 2015-11-27 (38 days left)
> Short and to the point. Your 15-minute elevator pitch.
> Can you sell the project?
>
> All deadlines are at 23.59 UTC
>
> Developer room proposal: Deadline EXPIRED
> Maybe some developer room will accept talks/demos from us.
>
> Regards,
> Carl-Daniel
>
>


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

Re: [coreboot] SPD binaries in coreboot

[Carl-Daniel Hailfinger]

On 23.10.2015 21:15, Martin Roth wrote:
> I like what I understand Nico's proposal to be: Store the SPD data as
> a c struct with all of the different JEDEC fields broken out.  it
> would relatively trivial to compile this into an SPD binary, or it can
> be used in whatever other fashion is desired.  A tool to convert from
> a binary SPD to the structure file would be desirable to help the
> transition, but it's out of the build path.
>
> I believe this satisfies all the requirements:
> - It's easy to review differences.
> - It can be be built with no new tools.
> - The fields are broken out, so you can actually tell what you're doing.

Now that would be a nice way to combine the benefits of diffable source
and no-tool builds.

Ron, is that solution is acceptable to you?

Side note: There is a tool called decode-dimms which can be fed with
binary SPD dumps. It decodes everything in the SPD and could serve as a
nice way to verify the output of Ron's magic SPD tool.


Regards,
Carl-Daniel

> On Fri, Oct 23, 2015 at 12:44 PM, ron minnich  wrote:
>> Aaron is my hero :-)
>>
>> ron
>>
>> On Fri, Oct 23, 2015 at 11:35 AM Aaron Durbin  wrote:
>>> This one's for Ron.
>>>
>>> On Fri, Oct 23, 2015 at 10:32 AM, ron minnich  wrote:
 Build the tool in go. It's trivial. If you have an idea how it ought to
 work
 I can set it up in the playground in a few minutes.

 ron

 On Fri, Oct 23, 2015 at 8:24 AM Patrick Georgi 
 wrote:
> Hi,
>
> Some mainboards come with soldered-on memory without SPD ROM. For
> these, we carry the SPD data in coreboot.
>
> Currently, they're stored in a hexdump format that is then converted
> to binary at build time. The various mechanisms of doing so fail on
> some platform or another:
>  - "echo -e -n $stuff" isn't well-liked by some shells (emits "e -n
> $stuff")
>  - "printf '\x42'" isn't well-liked by some shells (or /usr/bin/printf
> tools) that don't support hexadecimal formats
>  - "printf '\0377'" isn't well-liked by some non-conforming, but
> existing
> shells
>  - xxd -rg1 $file > $file.bin requires xxd, which comes with vim and
> may just not exist
>
> I see essentially two ways out of this, before we can start reducing
> duplication across the tree in that area:
> We could build our own tool to parse hex files and dump binary, or we
> could ship SPD data as binary from the start (and only have to
> concatenate them).
>
> The second option has the appeal of being much simpler (and there
> isn't really a "preferred form" for editing SPD data that I'm aware of
> - is there?), but looks icky at a glance because it's binary (but it's
> really just as impenetrable as the equivalent hexdump).
>
> So what do these files contain? Parameters (as in: facts) about the
> hardware's size, layout, and timing, and a bunch of vendor/model
> identifier strings.
>
>
> So, is there a third option that I'm missing? Other opinions?
> Patrick
>


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

[coreboot] FOSDEM deadlines now!

[Carl-Daniel Hailfinger]

Hi,

we obviously want to participate in FOSDEM.
https://fosdem.org/2016/news/2015-09-24-call-for-participation/

ACT NOW!

Some deadlines already expired. Some can still be managed.

Main track talks: Deadline 2015-10-30 (10 days left)
One hour of entertainment, huge audience.
Anyone up for the challenge?

Stands: Deadline 2015-11-13 (24 days left)
I can send in the proposal if I'm not going to be alone there.
How many tables do we want for our stand/booth(s)?
Who is coming?

Lightning talks: Deadline 2015-11-27 (38 days left)
Short and to the point. Your 15-minute elevator pitch.
Can you sell the project?

All deadlines are at 23.59 UTC

Developer room proposal: Deadline EXPIRED
Maybe some developer room will accept talks/demos from us.

Regards,
Carl-Daniel


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

Re: [coreboot] Emergency: Talks needed for coreboot conference in Bonn

[Carl-Daniel Hailfinger]

On 04.10.2015 19:55, ron minnich wrote:
> BTW, will you be recording. That's something we've lacked in the past.

Um. I didn't think of that, but I like the idea. Not sure where to get
some good recording equipment this quickly.
Apart from that, it seems like a nice idea, but
- each speaker would have to opt in individually
- public discussions won't be recorded in any case.

regards,
Carl-Daniel


> ron
>
> On Sun, Oct 4, 2015 at 6:02 AM Alexander Couzens <lyn...@fe80.eu> wrote:
>
>> Hi,
>>
>> I would like to give a talk about my embedded controller programming.
>>
>> And beside that, I would like to have a talk/workshop something, to
>> think about the future/roadmap/vision/roadmap name how you like it.
>> how coreboot should be in the next year.
>>
>> Best,
>> lynxis
>>
>> On Fri, 2 Oct 2015 00:20:41 +0200
>> Carl-Daniel Hailfinger <c-d.hailfinger.devel.2...@gmx.net> wrote:
>> --
>> Alexander Couzens
>>
>> mail: lyn...@fe80.eu
>> jabber: lyn...@jabber.ccc.de
>> mobile: +4915123277221
>> --
>> 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] Emergency: Talks needed for coreboot conference in Bonn

[Carl-Daniel Hailfinger]

Hey everyone,

due to various reasons, a few speakers can't make it to the conference
and thus I have a severe lack of talks and the agenda is starting to
look like swiss cheese (holes everywhere). Admittedly I do love swiss
cheese (so many delicious kinds of cheese), but for a conference agenda
I'd rather like to have less holes.

PLEASE PLEASE if you attend the conference PLEASE consider doing a talk
about something - anything really - even if it's just three slides and
five minutes of talking, followed by lots of discussion from/with the
audience.

Any proposals (title, duration (talk/discussion), name of speaker,
preferred time (morning, noon, afternoon)) are highly appreciated.
PLEASE send them to
 ASAP so I can allocate a slot for you.

If you can't come but would be willing to donate slides for someone else
to do a talk on your behalf, PLEASE tell me at
 or hit me up on IRC.

Doing talks remotely via a video conference system of your choice is
also an option.

THANK YOU!

Regards,
Carl-Daniel

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

Re: [coreboot] Hotel rooms: coreboot conference 2015

[Carl-Daniel Hailfinger]

My sincere apologies, the email address seems to be out of order.

Please use wissenschaftszent...@wzbonn.de for booking a
bed+breakfast room at the conference venue.

Regards,
Carl-Daniel

On 10.09.2015 22:14, Carl-Daniel Hailfinger wrote:
> The venue still has 7 very affordable single/double rooms available!
>
> Email i...@wzbonn.de and tell them you're attending the coreboot
> conference. Those rooms are reserved for conference participants.
>
> Regards,
> Carl-Daniel
>
>
> On 05.09.2015 03:12, coreboot conference wrote:
>> Dear vendors, developers, users and interested parties,
>>
>> On behalf of the Federal Office for Information Security (BSI) Germany I 
>> would
>> like to invite you to the coreboot conference and developer meeting on 
>> October 9-11 2015 in Bonn, Germany.
>>
>> This conference and developer meeting is geared towards manufacturers of 
>> hardware (processors, chipsets, mainboards and servers/ laptops/ tablets/ 
>> desktops/ appliances) as well as developers of firmware with an interest in 
>> coreboot and the possibilities it offers as well as (potential) coreboot 
>> users. Both professionals and hobbyists are invited.
>>
>> Please see the full text of the invitation at 
>> http://coreboot.org/coreboot_conference_Bonn_2015
>>
>> Sincerely,
>> Carl-Daniel Hailfinger
>


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

[coreboot] Hotel rooms: coreboot conference 2015

[Carl-Daniel Hailfinger]

The venue still has 7 very affordable single/double rooms available!

Email i...@wzbonn.de and tell them you're attending the coreboot
conference. Those rooms are reserved for conference participants.

Regards,
Carl-Daniel


On 05.09.2015 03:12, coreboot conference wrote:
> Dear vendors, developers, users and interested parties,
>
> On behalf of the Federal Office for Information Security (BSI) Germany I would
> like to invite you to the coreboot conference and developer meeting on 
> October 9-11 2015 in Bonn, Germany.
>
> This conference and developer meeting is geared towards manufacturers of 
> hardware (processors, chipsets, mainboards and servers/ laptops/ tablets/ 
> desktops/ appliances) as well as developers of firmware with an interest in 
> coreboot and the possibilities it offers as well as (potential) coreboot 
> users. Both professionals and hobbyists are invited.
>
> Please see the full text of the invitation at 
> http://coreboot.org/coreboot_conference_Bonn_2015
>
> Sincerely,
> Carl-Daniel Hailfinger


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

Re: [coreboot] From wildcat linking to exploring new languages

[Carl-Daniel Hailfinger]

On 28.08.2015 18:29, ron minnich wrote:
 I would really like this to be in the tree. It gives us a chance to do
 things in coreboot that go beyond C and assembly. So that's my $.02.

Same here.
Besides that, SPARK gives us easier provability of code. That is
something governments and safety engineers care about, and it makes for
great marketing.

 What harm would it do?

Having it in the tree would be beneficial because it will be easier to
bisect than two separate trees.
The only thing I'm worried about is whether we can guarantee the
complete tree can be built on all of the platforms where it can be built
now, but that worry applies in the git submodule case as well.

Regards,
Carl-Daniel

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

Re: [coreboot] [PATCH 0/4] Libflashrom

[Carl-Daniel Hailfinger]

Hi Łukasz,

yesterday I built this on a Ubuntu 14.04.3 (amd64) and tried to run it,
but the tool segfaulted before even showing its own window. On the
second try, it ran, but didn't handle a missing edid-decode well:
sh: 1: edid-decode: not found

Regards,
Carl-Daniel

On 14.08.2015 10:30, Łukasz Dmitrowski wrote:
 Hello,

 I improved and extended libflashrom patch, so I am posting it for a
 second review.
 I based on work of Nico Huber and Anton Kochkov. As Nico Huber's patch
 has been
 already sent some time ago I will send only Anton Kochkov's building
 and compilation
 fixes (thanks for sharing it with me) and my changes.

 Content:
 1 / 4 - Fix libflashrom compilation (by Anton Kochkov)
 2 / 4 - Fix libflashrom building (by Anton Kochkov)
 3 / 4 - Added querying functions to libflashrom
 4 / 4 - Added function which returns string list of multiple chips found

 I will be grateful for your opinions - it helps me to improve the patch.

 All this code you can also find here:
 https://github.com/lukaszdmitrowski/flashrom/tree/libflashrom

 Regards,
 Lukasz  Dmitrowski





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

[coreboot] coreboot conference in Europe, October 2015

[Carl-Daniel Hailfinger]

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, we'll 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.
There's 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 I'm looking for right now is a rough show of hands who'd like to
attend so I can book a conference venue. I'd 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

Re: [coreboot] T60 with ATI has black screen

[Carl-Daniel Hailfinger]

Hi Richard,

On 28.06.2015 12:58, Richard Simpson wrote:
 I have to say that knowing that you have the same T60 and that it is
 working is a big moral boost!

Imagine how I felt when it happened to me. Fortunately that was at a
coreboot developer meeting and we had the tools to recover in case it
wouldn't have worked.


 Yes, the VGA port is working.

 Can you possibly expand on your instructions below?

 1) You suggest that I patch the option ROM myself.  Where would I find
 instructions on how to do this?

I had hoped that the option ROM patching was straightforward, e.g.
having LVDS data or somesuch in there. Comparing hexdumps of a
memory-extracted and a biosimage-extracted option ROM showed me that
while the differences are clearly visible, their meaning is not obvious
(it's not EDID). So this method is probably not going to fly.


 2) If I decide that I need to extract it from a running system then I
 presume that I need to re-flash the factory BIOS.  Can I just do this
 with the same flashrom command that I used to flash coreboot?

You can do this with the same flashrom command you used to flash the
image a second time. Please don't use bucts for flashing back from
coreboot to factory BIOS, you only need it in the BIOS-coreboot direction.
That said, I think Vladimir Serbinenko (phcoder) had a trick on how to
modify the original BIOS so that bucts wouldn't be needed any more in
either direction.

Łukasz Dmitrowski is one of our GSoC students and part of his project is
to try to make such stuff easier in the future. He needs data for that,
though.
Richard, could you please collect the following data (as root) from the
system while it's running the factory BIOS?
lspci -nnvvv
dmidecode
video BIOS via both extraction methods (please make sure that we can
find out which is which)
superiotool -deV
dmesg
/var/log/Xorg.0.log (name may be a bit different, I want a log file from
Xorg running on the machine while the factory BIOS is active)
flashrom dump of the factory BIOS

Please don't send that data to the mailing list, I'll provide some space
for you to upload it.


 3) On this page (http://www.coreboot.org/VGA_support) two ways of
 getting the video BIOS from a running system are listed ('Retrieval via
 Linux kernel' and 'Extraction from mapped memory').  Does it matter
 which one I try?

AFAICS the images you get should be identical. Better check them to make
sure.


 4) Can you be a lot more specific about what I should do about the checksum?

Either let SeaBIOS ignore the checksum:
# cbfstool build/coreboot.rom add-int -i 0 -n etc/optionroms-checksum
Or you correct the checksum of the option ROM itself. IIRC there is some
tool to do that, but I coudln't find it in my bash history.


 Apologies if all these instructions are in the Wiki and I have been too
 dumb to find them.

Not sure if all of this is in the wiki. If you think anything is
missing, please tell me so I can add it.

Regards,
Carl-Daniel


 On 27/06/15 23:19, Carl-Daniel Hailfinger wrote:
 On 27.06.2015 23:39, Richard Simpson wrote:
 I have finally successfully flashed the BIOS on my T60 with coreboot.
 Sadly, my ATI controlled screen remains completely black.  Fortunately I
 can still get in via ssh.  Here is what I can deduce so far.+
 AFAICS you have exactly the same T60 as I have.


 lspci says:
 01:00.0 0300: 1002:7145 (prog-if 00 [VGA controller])
 [...]
 The vgabios which I extracted from the factory bios
 Ah yes. Bad idea. AFAIK the factory BIOS patches the VGA optionrom at
 runtime with the correct values for the LVDS panel. This means you
 either have to patch the VGA optionrom yourself or you have to extract
 the VGA optionrom from the memory of the running system. If you extract
 it from memory, please note that the runtime patching causes the
 checksum to be incorrect, and you either have to fix the checksum or
 tell SeaBIOS to ignore the checksum.



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

Re: [coreboot] flashrom claims T60 is unsupported

[Carl-Daniel Hailfinger]

On 27.06.2015 15:20, Richard Simpson wrote:
 Hello,

 I have had partial success with flashing my T60.  After the first flash
 the laptop re-booted OK, but the screen is completely black.  Fiddling
 with the backlight buttons doesn't have any effect.  Fortunately, I can
 connect via ssh so I am not locked out.

 I believe that my mistake was to put my ATI VGA bios into coreboot
 rather than SeaBIOS.  I have now corrected this but I can't flash the
 updated version.  For the first flash I used the following command:

 ./flashrom/i686/flashrom_lenovobios_sst -p internal -w coreboot.rom

 I got loads of errors as mentioned in the instructions, but it seemed to
 work.  Since I now want to do another flash I have followed the
 instructions and used this simpler command:

 ./flashrom/i686/flashrom -p internal -w coreboot.rom

 I get the following error:

 flashrom v0.9.8-unknown on Linux 3.10.0-229.4.2.el7.x86_64 (x86_64)
 flashrom is free software, get the source code at http://www.flashrom.org

 Calibrating delay loop... OK.
 coreboot table found at 0xbfea.
 
 WARNING! You seem to be running flashrom on an unsupported laptop.
 Laptops, notebooks and netbooks are difficult to support and we
 recommend to use the vendor flashing utility. The embedded controller
 (EC) in these machines often interacts badly with flashing.
 See the manpage and http://www.flashrom.org/Laptops for details.

 If flash is shared with the EC, erase is guaranteed to brick your laptop
 and write may brick your laptop.
 Read and probe may irritate your EC and cause fan failure, backlight
 failure and sudden poweroff.
 You have been warned.
 
 Aborting.
 Error: Programmer initialization failed.

 I have tried flashrom, flashrom_lenovobios_sst and
 flashrom_lenovobios_macronix and get the same error every time.  I have
 also tried re-flashing the current working but blank screen bios and
 that won't go in either.

 Suggestions gratefully received.

flashrom -p internal:laptop=force_I_want_a_brick -w coreboot.rom

That should work.

Then take care of bucts again.

Regards,
Carl-Daniel

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

Re: [coreboot] T60 with ATI has black screen

[Carl-Daniel Hailfinger]

On 27.06.2015 23:39, Richard Simpson wrote:
 Hello,

 I have finally successfully flashed the BIOS on my T60 with coreboot.
 Sadly, my ATI controlled screen remains completely black.  Fortunately I
 can still get in via ssh.  Here is what I can deduce so far.+

AFAICS you have exactly the same T60 as I have.


 lspci says:
 01:00.0 0300: 1002:7145 (prog-if 00 [VGA controller])
 Subsystem: 1002:
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
 ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0, Cache Line Size: 64 bytes
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at e000 (32-bit, prefetchable) [size=128M]
 Region 1: I/O ports at 4000 [size=256]
 Region 2: Memory at ec12 (32-bit, non-prefetchable) [size=64K]
 Expansion ROM at ec10 [disabled] [size=128K]
 Capabilities: access denied
 Kernel driver in use: radeon

 The vgabios which I extracted from the factory bios

Ah yes. Bad idea. AFAIK the factory BIOS patches the VGA optionrom at
runtime with the correct values for the LVDS panel. This means you
either have to patch the VGA optionrom yourself or you have to extract
the VGA optionrom from the memory of the running system. If you extract
it from memory, please note that the runtime patching causes the
checksum to be incorrect, and you either have to fix the checksum or
tell SeaBIOS to ignore the checksum.


 reports as follows:

 Image 1:
 PCI Expansion ROM Header:
   Signature: 0x55aa (Ok)
   CPU unique data: 0x7e 0xe9 0x6f 0x02 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
   Pointer to PCI Data Structure: 0x0230

 PCI Data Structure:
   Signature: 0x50434952 'PCIR' (Ok)
   Vendor ID: 0x1002
   Device ID: 0x7145
   Vital Product Data:  0x
   PCI Data Structure Length: 0x0018 (24 bytes)
   PCI Data Structure Revision: 0x00
   Class Code: 0x03 (VGA Display controller)
   Image Length: 0x007e blocks (64512 bytes)
   Revision Level of Code/Data: 0x090c
   Code Type: 0x00 (Intel x86)
   Last-Image Flag: 0x80 (last image in rom)
   Reserved: 0x

 Platform specific data for x86 compliant option rom:
   Initialization Size: 0x7e (64512 bytes)
   Entry point for INIT function: 0x275

 This looks like the right VGA BIOS to me.

 Once I have added it to the coreboot image I can check the contents as
 follows:

 coreboot.rom: 2048 kB, bootblocksize 952, romsize 2097152, offset 0x0
 alignment: 64 bytes, architecture: x86

 Name   Offset Type Size
 cmos.default   0x0cmos_default 256
 cmos_layout.bin0x140  cmos_layout  1824
 fallback/dsdt.aml  0x8c0  raw  12037
 cpu_microcode_blob.bin 0x3800 microcode94208
 etc/ps2-keyboard-spinup0x1a880raw  8
 config 0x1a8c0raw  4046
 revision   0x1b8c0raw  571
 (empty)0x1bb40null 17432
 fallback/romstage  0x1ff80stage36524
 fallback/ramstage  0x28ec0stage53635
 fallback/payload   0x36080payload  55837
 pci1002,7145.rom   0x43b00raw  64512
 (empty)0x53740null 1754264

 I would be most grateful for any suggestions as to where I might be
 going wring or further diagnostics.

On the first coreboot try I had a black screen as well on my T60 (ATI
graphics). Funnily enough, the external VGA worked. Could you check if
that's the case for you?

Regards,
Carl-Daniel

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

Re: [coreboot] Fwd: Coreboot T-shirts

[Carl-Daniel Hailfinger]

Hi everyone,

I found out that spreadshirt.de (biggest t-shirt printing shop in
Germany) wants 21.99 EUR for a t-shirt (any size, any colour) including
front and back printing (durable foil) of the coreboot logo.
Shipping+handling to most locations in Europe is 3-4 EUR.

@Vladimir: This might be less hassle and cheaper than shipping t-shirts
from Russia to Switzerland or Germany.

On 31.05.2015 19:31, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
 On 31.05.2015 19:27, Matthias Apitz wrote:
 El día Sunday, May 31, 2015 a las 06:45:48PM +0200, Vladimir 
 'φ-coder/phcoder' Serbinenko escribió:

 Good news: now it's possible to have them in black as well.
 I received up to now only one request to which I replied by personal
 mail. If you didn't receive any reply, please resend your request.
 Please specify in request the size, color (white, black, few other
 colors if someone is interested), quantity and if you want it single or
 double-sided printing.

 Please tell me until Friday.
 Please post again an URL of the t-shirt layout. Thanks

 I don't have the URL. I'm waiting for Carl-Daniel to give me the file
 (in any format) wit layout he used last time.

Attached is what I remember as the layout I used.

Regards,
Carl-Daniel


Coreboot_hare_footer_standard.svg.gz
Description: GNU Zip compressed data
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot T-shirts

[Carl-Daniel Hailfinger]

On 21.05.2015 12:51, Vladimir 'phcoder' Serbinenko wrote:
 A contact of mine proposes to print coreboot T-shirts for the community.
 Black printing on white T-shirt. Expected price is 30€-35€ + shipping from
 CH or DE, double-sided printing, one-sided is 5-8€ less. It will be printed
 in Russia.

Please note that the coreboot T-Shirt I am wearing is black, with the
logo being a white plastic foil melted/glued to the t-shirt.
Could you ask your contact whether such a variant would be possible as
well? The foil variant is extremely durable and IMHO a black T-Shirt
fits a bit better with all the other hacker culture T-Shirts.

 I need to know who wants one and sizes by June 5th. For payment
 I accept paypal and bank wiring.
 It will be available in ~August. Do we have some kind of dev meeting in
 autumn where I could bring them?
 @carldani: could you give me the file used for printing?

Sure.

Regards,
Carl-Daniel

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

Re: [coreboot] coreboot community chat

[Carl-Daniel Hailfinger]

Hi Stefan,

thanks for organizing this! I think it's a really good idea.

On 07.05.2015 06:05, Stefan Reinauer wrote:
 Hi coreboot community!

 In order to have more face time and a more personal connection with each
 other than it is possible on the coreboot IRC channel, I would like to
 invite you to participate in a monthly video conference to discuss the
 up and coming projects, ideas and issues that all of us are involved in.
 [...]
 So I would like to invite interested contributors of the community to
 join us. The first video conference will be on Thursday, May 21th at
 9:15am Pacific Time (16:15 UTC). The meeting can be joined by clicking
 on this link: http://goo.gl/SD6t3G.

I am very much looking forward to this and will try to participate.

Regards,
Carl-Daniel

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

Re: [coreboot] QEMU x86_64 Q35 Automated Test Failure

[Carl-Daniel Hailfinger]

On 22.04.2015 06:01, Timothy Pearson wrote:
 On 04/21/2015 05:25 PM, Carl-Daniel Hailfinger wrote:
 Thank you for providing this service. It is very much appreciated.

 I would like to make a suggestion, though: The mail size of failure
 reports is increasing constantly as long as a boot problem remains
 unfixed. Would it make sense to only list the first 5 and last 5 commits
 in the failing series and replace the rest with ... or something
 similar?

 Done.  I also added a note of how many commits were in the skipped
 section.

Thank you!

Regards,
Carl-Daniel

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

Re: [coreboot] QEMU x86_64 Q35 Automated Test Failure

[Carl-Daniel Hailfinger]

On 21.04.2015 19:14, Timothy Pearson wrote:
 On 04/21/2015 11:44 AM, Timothy Pearson wrote:
 On 04/21/2015 11:31 AM, Patrick Georgi via coreboot wrote:
 2015-04-21 17:31 GMT+02:00 Gregg Levinegregg.drw...@gmail.com:
 I suspect somehow it was supposed to be internal to hs outfit only.
 Timothy provides boot testing of coreboot master with QEmu and a AMD
 board that he maintains as a service to the community.

 And something changed with regards to the logic behind how those
 annoying e-mail messages being sent to us.
 The system only sends mails when things look wrong.
 Right now coreboot is able to boot, but has issues with the cbmem
 console. According to Paul's analysis, that's why it's now reporting a
 failure.


 Patrick


 This is correct. Please see the thread marked cbmem console broken on
 Intel hardware since ec5e5e0 for additional information on the
 regression in coreboot itself.

 If the community would like me to stop sending these notifications I
 will do so; I could also adjust the maximum frequency if desired. As
 stated this is intended to be a service so that broken boards are
 detected and repaired; perhaps there should be an alternate way of
 reporting the test failure (e.g. the board status repository could be
 modified to store failed tests as well as successful ones?)


 After some thought I have limited the notification to a maximum of
 once per day.  This is in line with the default nag settings of other
 projects such as Bugzilla.  Developers wanting to verify that an issue
 has been fixed before the next 24 hour message window should refer to
 the board-status repository, which continues to update at the normal
 rate (within an hour or two of commit to mainline GIT).

Thank you for providing this service. It is very much appreciated.

I would like to make a suggestion, though: The mail size of failure
reports is increasing constantly as long as a boot problem remains
unfixed. Would it make sense to only list the first 5 and last 5 commits
in the failing series and replace the rest with ... or something similar?

Regards,
Carl-Daniel

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

Re: [coreboot] memtest86 reading 0k memory

[Carl-Daniel Hailfinger]

On 08.04.2015 22:55, Stefan Tauner wrote:
 On Thu, 19 Feb 2015 10:43:44 -0500
 Kevin O'Connor ke...@koconnor.net wrote:

 On Wed, Feb 18, 2015 at 10:26:21PM +0100, Stefan Reinauer wrote:
 * Timothy Pearson tpear...@raptorengineeringinc.com [150205 19:23]:
 e820: BIOS-provided physical RAM map:
 BIOS-e820: [mem 0x-0x0009fbff] usable
 BIOS-e820: [mem 0x0009fc00-0x0009] reserved
 BIOS-e820: [mem 0x000f-0x000f] reserved
 BIOS-e820: [mem 0x0010-0x3ffacfff] usable
 BIOS-e820: [mem 0x3ffad000-0x3fff] reserved
 BIOS-e820: [mem 0xe000-0xefff] reserved
  
 One of the issues seems to be that the coreboot table space is not
 marked as reserved (i.e. the lower 4k should be marked as reserved, and
 whatever is used at the top of memory)
 coreboot tends to reserve the first 4K, but this breaks lots of
 bootloaders.  So, SeaBIOS always overrides coreboot and unreserves the
 first 4K.  My experience is that the first one megabyte of the e820 is
 just magical and should always read as listed above.

 Separately, it is possible for SeaBIOS to remove the coreboot table
 forwarder, and thus force memtest86 to not use the coreboot tables.
 I'm not sure if this would affect other programs though.
 I ran into the problem today when trying to verify that the ASRock
 IMB-A180-H works correctly with coreboot. Is there any consensus on
 what to do? IMHO this is a bug in SeaBIOS... it creates the discrepancy
 between the tables and that leads to problems downstream... but that's
 arguable. What is not arguable: some action is required. :)

The Linux kernel expects coreboot+SeaBIOS to lie and marks the first 4K
as reserved again. Excerpt from my dmesg on a T60 running coreboot+SeaBIOS:

e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0009fbff] usable
BIOS-e820: [mem 0x0009fc00-0x0009] reserved
BIOS-e820: [mem 0x000f-0x000f] reserved
BIOS-e820: [mem 0x0010-0xcfec9fff] usable
BIOS-e820: [mem 0xcfeca000-0xcfff] reserved
BIOS-e820: [mem 0xf000-0xf3ff] reserved
SMBIOS 2.7 present.
DMI: LENOVO 2007VVT/2007VVT, BIOS CBET4000 4.0-7070-g2fc0a1d 10/18/2014
e820: update [mem 0x-0x0fff] usable == reserved
e820: remove [mem 0x000a-0x000f] usable

Regards,
Carl-Daniel

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

Re: [coreboot] coreboot paid development

[Carl-Daniel Hailfinger]

Hello Milton,

On 25.03.2015 00:28, Milton Krutt wrote:
 I ask the good people here if there is out there some
 form of paid development on coreboot such that a new
 contributor can apply to (apart from the GSoC).

I'm not sure if I understand you correctly. Are you looking for someone
to pay you for coreboot development without prior experience?

Regards,
Carl-Daniel

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

Re: [coreboot] [flashrom] New flashrom logo - fonts

[Carl-Daniel Hailfinger]

On 11.03.2015 14:30, Stefan Tauner wrote:
 This will be the last poll that evaluates specific features of the
 logo. There may be another one to determine the final design.

 I have selected a variety of fonts that I think are OK for a logo in
 terms of thickness and playfulness. Not all of them are free but I
 have included them in the poll anyway to get a better feeling about
 general preferences.

 http://epicdecide.com/ad3645e6-9a70-4cce-bd05-bf0e66e668e9/

This is the first poll where I think that all of the options suck.
Traditionally, flashrom is written all lowercase and I would love to
keep it that way. However, the letter f in the logos sucks in all
lowercase variants because of a IMHO way too high lateral stroke. That's
something I didn't like about the intermediate official logo, by the way.

Does anyone know a font where the lowercase f doesn't look like a
design error?

Regards,
Carl-Daniel

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

Re: [coreboot] Plans for upcoming Broadwell Thinkpads

[Carl-Daniel Hailfinger]

Hi,

On 06.02.2015 21:43, Zaolin wrote:
 let's say goodbye to all Intel notebooks produced by OEM's which are not
 Google ( Chromebooks ). Maybe the haswell/broadwell notebooks of Lenovo
 without U/Y processor can be used ( Thinkpad tXX xXX ). It depends if
 they are supporting Intel Boot Guard on the southbridge...

If I managed to find a VAR (value added reseller) who sells HP business
laptops without Boot Guard, would there be interest in this group to buy
a few machines?

Regards,
Carl-Daniel


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

Re: [coreboot] coreboot meeting this summer!

[Carl-Daniel Hailfinger]

On 12.03.2015 19:55, ron minnich wrote:
 Given all the high-tech ability in this group, I wonder if a joint,
 transglobal, meeting using gvc from san jose to whereever would work :-)

Now that sounds like a really neat plan. GVC is Google Video Conference?

That said, I was silently working on securing rooms (lab+lecture hall)
for a coreboot conference at Bonn-Rhein-Sieg university near Bonn,
Germany sometime during this summer/fall. So far it looks like we might
be able to get such rooms for free and accommodation at reasonable
prices. Plus, Cologne Cathedral is close to the venue.

We could try to combine both approaches from a timing perspective and
have the European end of the video conference at the venue I'd organize,
and get the American end set up in San Jose. I'd have to check how the
timing works, though.

Thoughts?

Regards,
Carl-Daniel


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

Re: [coreboot] [flashrom] New flashrom logo - please vote!

[Carl-Daniel Hailfinger]

On 03.03.2015 00:50, Stefan Tauner wrote:
 On Mon, 2 Mar 2015 09:03:59 -0800
 Vadim Bendebury vben...@chromium.org wrote:
 Not that I care much, but I can't help it: this new symbol looks very
 much like the infamous SS Bolts:
 http://www.adl.org/combating-hate/hate-on-display/c/ss-bolts.html#.VPSXeFX3-iw
 Yes, it could be mistaken for a sig rune although it clearly differs
 (the rune is not formed as an arrow on the bottom but is symmetric). I
 would not use two of this or similar symbols side by side because it
 could easily be seen as a political statement I definitely don't want
 to make. 

This is one of the reasons the lightning bolt of the old official logo
looks the way it does.
The following features had been chosen to avoid any unfortunate visual
associations:
- close in design to the high voltage warning sign used in Germany
- a bigger distance between the two long strokes
- the long strokes are slightly angled and not parallel
- one of the long strokes is terminated in arrow form.


I do like Stefan's renderings of SOIC8 chips. They represent the current
form of hardware we're working with, and I would like to see them in
combination with the old official lightning bolt form. That would give
us a modern new logo and at the same time avoid any unfortunate visual
associations.


For easier comparison of the two bolt forms, I extracted them from the
original svg logos they were part of. No further
editing/clipping/rotation was done.
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Automated test system: Nominations wanted

[Carl-Daniel Hailfinger]

This is a friendly reminder. 2 days left for nominations of systems.

On 19.02.2015 00:14, Carl-Daniel Hailfinger wrote:
 The selection of target systems should include:
 1. at least one x86 laptop without an active ME (present but inactive
 would be OK)
 2. at least one x86 laptop which can boot x86-blob-free (except microcode)
 3. at least one x86 board or laptop which needs neither blobs (except
 microcode) nor ME
 4. at least one x86 board with reasonable (past or present) business
 market penetration
 5. if the first two laptops use the same CPU vendor, a board using a
 different x86 CPU vendor
 [...]
 Please nominate machines (e.g. Thinkpad T60 with Intel graphics) and
 tell me to which category they belong. If a system fits into multiple
 categories, please specify that as well.
 I will try to consolidate the recommendations and buy those machines.
 Once the system is up and running (hopefully in May), I will add more
 machines suggested by the community as time permits.

 The time window for suggestions will close at the end of February.

So far I got the following nominations:
- asus f2a85-m (desktop board)
- tyan s8226 and/or supermicro h8scm and/or supermicro h8qgi (server board)
- Qemu and a couple of the boards supported by SimNOW (no category)
- Thinkpad T60 with ATI graphics (no ME, but with graphics blob)

I can't find the suggestions on IRC anymore (searching in the scrollback
buffer is harder than I thought), so if you still remember which
boards/machines were proposed on IRC, please send an email listing them.

Thanks,
Carl-Daniel


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

Re: [coreboot] [flashrom] New flashrom logo

[Carl-Daniel Hailfinger]

Hi,

On 22.02.2015 02:04, Stefan Tauner wrote:
 we have used two logos in the past for flashrom. The one most are
 familiar with is actually a generic icon stemming from coreboot's
 Related Tools section, i.e.:
 http://www.coreboot.org/images/a/ae/Chip_tools.png
 This is not only set up as the Mediawiki icon on flashrom.org but is
 also used on our Twitter account and other sites like openhub
 (https://www.openhub.net/p/flashrom)

 The second logo was specifically designed for this purpose and was used
 at various occasions in presentation slides and on marketing materials
 (e.g. posters). Namely
 http://3.bp.blogspot.com/_PTt3TWYKjnQ/TI_oZ3cqvaI/ALY/eLvM6K16Glw/s400/logo9white.png
 (the one described as Different style of bolt on
 http://kmacphail.blogspot.de/2010/09/flashrom-logos.html)
 I think that one is way lesser known since even I was not really aware
 about the fact that it kind of the official logo at the moment.

That logo (with slight modifications) was used in all flyers, all
presentations and at all booths since 2010. Please see the attachment
for details.


 I am not too happy with either. The hammer logo has grown dear to me...
 the hammer perfectly symbolizes the force we have to exert to get some
 systems to work and the logo as such is very recognizable. But... I
 only have it in very low quality... is there a better source for it?
 It also does not represent our generally gentle and cautious approach
 when dealing with hardware and our focus on stability.

To me, the hammer logo suggests chip tool in a general way, not
something related to flash chips. Besides that, nowadays PLCC32 flash
chips are almost extinct.


 The DIP logo on the other hand is available in SVG (at least
 Carl-Daniel has it AFAIK), but it looks a bit inanimate. The major
 problems I have with it are that it is not even nearly rectangular and
 it is very complex. There is the text with the lightning bolt replacing
 the h character and the DIP32 chip. Both is ok for posters and other
 big displays but sucks for other uses where simple, rectangular icons
 are required.

I don't really understand the requirement for a rectangular logo.
flashrom is a long word and if we want to place that word below any
logo, the logo will either need to be strechted out (like the one
attached to this mail) or it will be a bit clumsy due to its blobby size.

There is another question: Do we want a logo which can be used without
the word flashrom, and if so, should it still look good when the word
flashrom is written below?


 I have spent the last weekend with playing around with Blender and its
 freestyle renderer that is able to output SVG directly. I have managed
 to render a 3D model of a SOIC8 chip that way as a base for a possible
 new logo. It required some cleanup afterwards but it looks way better
 than everything I could draw by hand ;)

The result looks nice, but I have trouble associating this with
flashrom. The lightning bolt is a bit difficult to recognize as a
lightning bolt.

I do like that you used an 8-pin chip instead of a 32-pin chip. Looks
more modern.


 I have made two logos that I think are worth sharing. They are quite
 similar and the only major difference is the orientation of the chip...
 I have created 3 versions of each: one fully colored, one with outlines
 only and a two-colored simple version (e.g. for PCB silkscreens). I
 have attached the Inkscape SVGs as well as 96 pixel-wide PNG exports. I
 have not decided on an appropriate license... probably something
 similar to how the coreboot hare is licensed.

 What do you think about my suggestions and the whole matter? I would
 love to see proposals for alternatives as well!

I would like to keep the SVG logo used since 2010, perhaps paired with a
simplified version of the logo which is small and simple enough for
square icons.

What do you think about having a DIP8 chip for icons and other
space-constrained and detail-constrained applications? This would allow
us to have two logos, each one for the purpose it fits best.


There is also the question of whether we want a pure black-and-white
logo like coreboot or if we'll go full/partial color. For posters,
black-and-white vs. color is a matter of cost.

Regards,
Carl-Daniel
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Automated test system: Nominations wanted

[Carl-Daniel Hailfinger]

Hi,

I am currently planning to set up a test system with 5 (later up to 10)
machines boot testing each new coreboot commit. This test system will be
serviced (i.e. recovery from bricking) Mo-Fr during CET/CEST office hours.

Current goals for every commit:
- Check if coreboot + SeaBIOS are able to boot Linux to a point where
network is up and running

Current goals for every work day:
- Check if screen, keyboard and touchpad/mouse work
- Check if USB works and has the expected transfer speed (i.e. if USB
High and Super Speed both work)

Future goals for every work day:
- Run memtest86+ (short run)
- Run GRUB2 and boot Linux
- Check if USB works (see above)

Once any test running once per work day can be automated with reasonable
effort (i.e. not requiring robots or human interaction), it can be moved
to a per-commit goal.

The selection of target systems should include:
1. at least one x86 laptop without an active ME (present but inactive
would be OK)
2. at least one x86 laptop which can boot x86-blob-free (except microcode)
3. at least one x86 board or laptop which needs neither blobs (except
microcode) nor ME
4. at least one x86 board with reasonable (past or present) business
market penetration
5. if the first two laptops use the same CPU vendor, a board using a
different x86 CPU vendor

1+2 are designed to partially remove the potential for nasty surprises,
3 should remove nasty surprises completely, 4 is the one I need to show
that the test system is actually relevant for our goals, 5 should give
us better coverage outside the most common systems used by coreboot
developers.


Please nominate machines (e.g. Thinkpad T60 with Intel graphics) and
tell me to which category they belong. If a system fits into multiple
categories, please specify that as well.
I will try to consolidate the recommendations and buy those machines.
Once the system is up and running (hopefully in May), I will add more
machines suggested by the community as time permits.

The time window for suggestions will close at the end of February.

Fire away!

Regards,
Carl-Daniel


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

Re: [coreboot] On the subject of collaboration

[Carl-Daniel Hailfinger]

On 14.02.2015 14:37, Peter Stuge wrote:
 Carl-Daniel Hailfinger wrote:
 fork?
 a fork would be a good thing
 Hey look, I can quote without context, too!
 I hope this explains why quoting without context should not be done.
 Did you just hijack (or fork, as Alex likes to call it) the thread?

No, I was just replying to you, and by selectively quoting you I even
kept the topic you were talking about.

Regards,
Carl-Daniel

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

Re: [coreboot] GSOC 2015 Preperations

[Carl-Daniel Hailfinger]

On 14.02.2015 03:25, Alexandru Gagniuc wrote:
 On Saturday, February 14, 2015 02:50:15 AM Alexander Couzens wrote:
 I would like to attend as a student this year.
 I'm open for most of the ideas at the page.
 Here are some of my ideas.

 - porting new mainboards (hp micro n54L and x121e atm)
 - porting new arm platforms
 - refactoring amd code
 - create an opensource firmware for some Thinkpad (H8S based)
 - building a basic testing system (looking for a x60 or other
 supported_board)
 - add usb debug support to SerialICE
 Porting new boards is of limited value.

Indeed. Especially when those new boards are already 2-3 years off the
market. In that case it would only make sense if they still have a
really large user base, and AFAICS both your suggestions are in areas
where either the user base regularly changes hardware (X121e) or is
reluctant to touch something that's expected to run 24/7 (HP Micro N54L).


 New ARM platforms is definitely an interesting topic. Although you have to 
 consider whether your platform of choice can work blob-free, and whether or 
 not there is already a uboot port for it.

Especially in the ARM case it also depends on whether someone believes
the student to realistically be able to bring up a platform without
having the mentor figure out all the hard stuff.


 Refactoring code seems to have been a popular GSoC theme since I've been 
 doing 
 coreboot. Personally, and I will not be part of the decision making, I think 
 this is of limited value when that source code works. You see, coreboot is 
 nowadays being bombarded from all directions with binary-only components.

You will face resistance from two camps: First camp doesn't see a
benefit in the nth refactoring, second camp believes most refactoring
will make merging vendor code harder. IMO a refactoring is OK if it only
impacts binary-only vendor code, but others will disagree with me.


 I think that you can do a great deal more good by working on eliminating some 
 of 
 these blobs. Though tread carefully if you choose this path... reverse 
 engineering is not a valid project for GSoC, so RE should not be part of your 
 proposal or project.

IMO RE and reimplementation could be done in one proposal, but please
note that it all depends on your local legal landscape whether you want
to go all the way to a Chinese Wall type of reverse engineering or not.
That said, I believe that reverse engineering is one of the most
valuable activities in a time where binary blobs crop up everywhere.


 And this point is where you've really gotten my attention. It's gold. Pure 
 gold. Having a free software implementation of H8 firmware is a worthy goal 
 in 
 itself. Although there's the argument to be made that there already is such a 
 thing in ChromeEC, your should stress the counterpoint that the EC is not 
 something that can just be replaced, and the mere popularity of the H8 makes 
 it a great platform to target.

Doesn't Google have some open source code for H8-based ECs as well, not
just their own ChromeEC?


 Another amazing subject that I would suggest you consider is creating a free 
 replacement for the SMU firmware in AMD chipsets. Talk to ruik about it. He 
 may be able to tell you more. Regarding AMD chips up to fam16 at least, this 
 is the final frontier.


AFAIK the SMU firmware is not enforcing any restrictions on coreboot or
the platform, and thus I'd consider this a fun project, but without real
benefits for coreboot.

Regards,
Carl-Daniel


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

Re: [coreboot] On the subject of collaboration

[Carl-Daniel Hailfinger]

On 14.02.2015 03:27, Peter Stuge wrote:
 Peter Stuge pe...@stuge.se once said:
 Alexandru Gagniuc wrote:
 fork?

 a fork would be a good thing


Hey look, I can quote without context, too!
I hope this explains why quoting without context should not be done.

Regards,
Carl-Daniel


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

Re: [coreboot] coreboot code of conduct

[Carl-Daniel Hailfinger]

On 16.01.2015 19:15, Marc Jones wrote:
 A coreboot code of conduct has been posted on the wiki.
   - http://www.coreboot.org/Code_of_Conduct

 I have written a blog post about why we have a code of conduct.
   - http://blogs.coreboot.org/blog/2015/01/16/coreboot-code-of-conduct/

 Feel free to give feedback on the policy and how else we can contribute to
 a welcoming and collaborative environment.

How do we handle a conflict between our own Code of Conduct and the Code
of Conduct of a conference where coreboot is participating? Will we
ignore our own CoC or will we simply not attend? Does it depend on
whether the CoC is similar in spirit or not?
Some conferences declare their own CoC as binding for everyone and
disallow participating projects from enforcing any project CoC. Other
conferences allow every participating project to declare the project CoC
as binding.


Having a Code of Conduct is no silver bullet against people criticizing
you on the internet: The FOSDEM conference has a CoC on every printed
conference programme, tells attendees to report concerns to any staff
member, and the contact phone number is of one of the female staff
members. FOSDEM staff+volunteers will do everything possible to make you
feel welcome at their conference. The number of reports of harassment
for FOSDEM apparently is zero, both for reports to the staff and reports
on the internet.
That didn't help them, though. A quick google search will find a few
people calling for a boycott of FOSDEM because they think the FOSDEM CoC
is no proper code of conduct, others complaining that zero reports is
not the same as zero occurrences and claiming that if harassment
happens at other conferences it also must have happened at FOSDEM. Some
people even complained that FOSDEM allowed individual communities to
declare their own community CoC as binding for the community developer
rooms.


The Code of Conduct yes/no problem is a no-win situation with
ideological background. Regardless of what we do, someone will be
unhappy. It is fundamentally similar to the blob yes/no problem in
coreboot vs. libreboot. I sincerely hope this will not cause a community
split into a coreboot-be-nice and a coreboot-CoC camp.

Side note: Most advocates for a CoC on the internet seem to live in the
US and/or have visited conferences in the US. The harassment reports I
found online about tech conferences seem to have a statistical anomaly:
a disproportionately higher amount of complaints about US conferences.
Some female colleagues of mine prefer to visit conferences in the EU for
that reason. I would love to see a solid statistical study about this,
though. So far it's only a first impression for me.


Regards,
Carl-Daniel


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

[coreboot] GSoC 2015

[Carl-Daniel Hailfinger]

Applications for organizations are open again. The deadline is very
short this time: Only 10 days!

http://www.google-melange.com/gsoc/homepage/google/gsoc2015

Regards,
Carl-Daniel

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

Re: [coreboot] code of conduct (reloaded)

[Carl-Daniel Hailfinger]

On 08.02.2015 19:07, Alexandru Gagniuc wrote:
 I have until now ignored this code of conduct. There's been talk about how 
 people feel unwelcome in _other_ projects, about how _other_ projects (fill 
 in 
 the blank). What there hasn't been any talk of, however, is any instance 
 where 
 this has been a problem in _our_ community.

On January 16, 2015, Marc Jones wrote in a coreboot.org blog post:
 While most developers don’t experience something as terrible as the
 harassment that happened in the context of Gamergate or other terrible
 behavior documented at technical and open source conferences the last
 several years, it does indicate that there is a problem in our open
 source communities.

I think the sentence above pretty much describes what went wrong in the
process creating the coreboot code of conduct.
Using gamergate (Disclaimer: I'm not a gamer, I prefer real cardboard
puzzles) as an indicator that there is a problem in our open source
communities is a logical fallacy (majority of game market share is not
open source).
Using terrible behaviour documented at technical conferences as an
indicator that there is a problem in our open source communities is a
logical fallacy (majority of tech market share is not open source).
However, using terrible behaviour documented at open source conferences
as an indicator that there is a problem in our open source communities
is logically correct. Now there are some open source communities which
reportedly have more problems and some which reportedly have less or no
problems. It would be very interesting to see how they differ, and then
check how this can be applied to us.


Right now prescribing a code of conduct is hip and trendy because
everyone does it. It also seems to be necessary in many places.

Marc wrote: it's a part of growing up, but in the real-life community
I was brought up (i.e. the city where I lived), a code of conduct was
considered a sign that something had broken down before and needed
patching up. See school rules for an example. Consider a relationship:
If there is a code of conduct in a relationship, it's probably about who
may see or interact with the joint children at any given time.


On 08.02.2015 19:07, Alexandru Gagniuc wrote:
 There's a phenomenon of Oh, I saw this thing here, so let's implement it 
 irrespective of whether or not it's actually relevant. I call that liberal 
 bullshit. That's exactly what this is.

I don't know about liberals in the USA, but in the EU, this would be a
conservative position. Then again, the definitions of liberal and
conservative seem to be completely different in the US vs EU.


On 08.02.2015 19:07, Alexandru Gagniuc wrote:
 This code of conduct is an insult to our hard work over the years, and an 
 insult to our friendly nature and countless personal hours spent helping 
 others. When you've put up this code of conduct, you've basically said our 
 community is not capable of bettering itself by peer action and common sense, 
 so we need to enforce it. It degrades every person who has ever contributed, 
 and degrades the community as a whole. It's a degrading document that has no 
 place.

On January 16, 2015, Marc Jones wrote in a coreboot.org blog post:
 We can’t lose valuable contributors because they felt uncomfortable or
 unwanted.

Alexandru, since you are a valuable contributor and feel uncomfortable
with the to-be-established Code of Conduct in its current form, those
who created the Code of Conduct surely will want to make sure not to
lose you. I trust them to come up with a solution for this.



Regards,
Carl-Daniel


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

Re: [coreboot] Plans for upcoming Broadwell Thinkpads

[Carl-Daniel Hailfinger]

On 07.02.2015 21:14, Timothy Pearson wrote:
 So the real question is: are there any AMD notebooks on the market
 with similar build quality to the old IBM Thinkpads?  I've about had
 enough of Intel and their monopolistic ways.

I saw AMD-based HP laptops (Probook/Elitebook) and they are nice (if you
don't mind a miniscule return key on the keyboard). The build quality is
comparable to newer Thinkpads (sharp edges included). The docking
options are a bit limited, though.

That said, I do _not_ know if HP is using anything similar to Boot Guard
on those laptops. Judging from photos of an opened Elitebook 745 G2,
there are two flash chips next to each other, so either it's some sort
of Dual BIOS solution or possibly other parity checks or an EC accessing
both flash chips. Before you spend 1000 USD on such a machine, it would
be wise to make sure you are not being stopped by any AMD/HP equivalent
of Boot Guard.

Regards,
Carl-Daniel


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

Re: [coreboot] coreboot code of conduct

[Carl-Daniel Hailfinger]

On 04.02.2015 12:31, Patrick Georgi wrote:
 Am 2015-02-03 11:38, schrieb Carl-Daniel Hailfinger:
 The current development guidelines didn't appear overnight, but were
 refined over time without a lockdown on the wiki.
 And yet they're mostly useless.

 The CoC wikipage is now unlocked. Let's see what comes of it.

Thanks!

I changed the wording a bit, reordered some stuff and replaced one of
the homegrown definitions with the one used by the UN which is hopefully
not objectionable.

There is another pending proposal (not by me) which IMHO would be a nice
addition:

https://www.coreboot.org/Talk:Code_of_Conduct#Some_words_about_assessing_code_quality
 Some words about assessing code quality

 Proposal: Add to the list in the chat etiquette something like: 'Code
 that you are changing wasn't perfect (or you wouldn't change it).
 However, try to avoid assuming that it was written by monkeys, or that
 it must have always been broken. It's likely that it used to work and
 it's likely that your new work is necessary and important because
 circumstances changed where the code didn't.'

 Pros: Remind people that there's a coder behind the code. Assuming bad
 intent or stupidity (and doing so publicly) is as much a statement
 about the code as about the coder.

 Cons: Is that micromanaging things? 

The Mailing list and chat etiquette section of the CoC already has two
related items:
 * People who intentionally insult others (users, developers,
 corporations, other projects, or the coreboot project itself) will be
 dealt with. See policy below.
 * We are dealing with hardware with lots of undocumented pitfalls. It
 is quite possible that you did everything right, but coreboot or its
 tools still won’t work for you.

Admittedly some code has always been broken and nobody may have noticed
before, but I really do like the avoid assuming it was written by
monkeys part. Quite a lot of code in coreboot (especially
hardware-specific stuff) has been copy-pasted and changed until it
worked well enough. Some cleanups have removed code of that type, but
there probably still is such code that remains.
In flashrom, we do notice from time to time that the remaining really
old code was written in an age where some classes of bugs simply weren't
widely known and thus the coder could not have known how to avoid them.
Sometimes, enough code was written the wrong way to have zero net
effect. Yes, head-scratching and exclamations of WTF?!? happen whenever
we try to fix or clean up that code. Still, back then the code
contribution (patch) seems to have been considered a net positive,
otherwise it wouldn't have been merged. For me, this is mostly a
question about respecting our elders who didn't have our modern tools
and still got things to work.

Opinions?

Regards,
Carl-Daniel


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

Re: [coreboot] coreboot code of conduct

[Carl-Daniel Hailfinger]

On 02.02.2015 12:09, Patrick Georgi wrote:
 Am 2015-02-01 13:30, schrieb Carl-Daniel Hailfinger:
 It seems patches are being ignored or getting lost.
 It's not exactly news that people are busy. And patches on the list
 are ignored since 2011.

Yes, but this is the first time a part of the community has decided how
other parts of the community should behave and threatened draconian
sanctions for any deviating behaviour.


 There are two possible solutions: Removing the lock on the wiki page or
 A CoC with no editorial oversight at all is probably worse than no CoC.

A CoC with no community backing is probably worse than no CoC.

Marc wrote in his initial post: Feel free to give feedback on the
policy. I sincerely hope that the CoC will only be in effect after the
feedback has been incorporated.
The current development guidelines didn't appear overnight, but were
refined over time without a lockdown on the wiki. Besides that, the
development guidelines don't mention any sanctions and are thus less
aggressive.


Regards,
Carl-Daniel


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

Re: [coreboot] coreboot code of conduct

[Carl-Daniel Hailfinger]

Opening remark: While I did try to phrase this in the most accurate way
possible with the help of a dictionary, please keep in mind I'm not a
native speaker of English. My apologies for any misunderstanding which
may arise. There is no intent to offend on my side.


On 03.02.2015 17:11, Peter Stuge wrote:
 Carl-Daniel Hailfinger wrote:
 this is the first time a part of the community has decided how
 other parts of the community should behave
 That's not really the case here. The code of conduct applies to
 everyone in the community, not just other parts of the community.

Granted. Let me replace other parts of the community with themselves
and other parts of the community. This makes it more clear that one
part of the community makes decisions and the other part of the
community is expected to comply. It is kind of obvious that the
decision-making part of the community would comply with their own
decisions, and this is why I didn't mention them in my original statement.

 
 and threatened draconian sanctions for any deviating behaviour.
 Are you more concerned about how the code of conduct has been brought
 onto the agenda, or about the subject matter? It's hard to tell. :\

I am concerned with the combination of both.
I already mentioned my objections to parts of the Code of Conduct
earlier in this thread.
I also object to the way the CoC was presented. I would have been
totally OK with this is a draft, please comment, then after the
requested changes have consensus and everyone agrees, let's make this
binding. Instead, we get a public announcement of a Code of Conduct
which implies that it is finalized already. Let me quote from the
associated blog post: we are going a step farther and describing what
is unacceptable within our community with the coreboot Code of Conduct.
That doesn't sound like it's a draft or unfinished.

Having the arbitration team be disjoint from the team creating the Code
of Conduct would also have dispelled concern about one group of
individuals acting as policymaker, judge, jury and executioner. I happen
to have learned at school that separation of powers is essential and
this shapes the way I think.


 A CoC with no editorial oversight at all is probably worse than no CoC.
 A CoC with no community backing is probably worse than no CoC.
 I do not think that is true.

How would a CoC without community backing be any better than no CoC?

Please note that wiki accounts for editing are only handed out manually
by a select few people. This also means that even for an unlocked wiki
page (suggested by me as one of the possible solutions) there is in fact
oversight.


 And you can't claim to speak for the whole community.

I didn't claim to speak for the whole community. I didn't even claim to
speak for the majority. I just took Patrick's statement word for word
and replaced editorial oversight with community backing. The most
interesting question here is whether editorial oversight is more
important than community backing.


 Marc wrote in his initial post: Feel free to give feedback on the
 policy. I sincerely hope that the CoC will only be in effect after
 the feedback has been incorporated.
 Maybe the code of conduct was always in effect, just not formalized?

My impression is that there is/was some sort of universal agreement
about being reasonably nice to everyone who was interested in or wanted
to be involved with coreboot in some way. Occassional trolling on IRC
is/was also being dealt with.

However, formalizing a be nice policy would hopefully have resulted in
a text which focuses less on unacceptable behaviour and associated
sanctions.
Being nice also means not treating community members as potential
offenders. Reading sentences like Behave. (yes, that is a complete
sentence from the Code of Conduct) makes me feel like an unruly teenager
getting a dressing-down from the headmaster.

TL;DR: IMHO the CoC needs to be discussed, revised and ratified before
taking effect.

Regards,
Carll-Daniel


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

Re: [coreboot] AMD Mahogany Fam10 not booting

[Carl-Daniel Hailfinger]

On 02.02.2015 06:30, Kyösti Mälkki wrote:
 On 02/02/2015 05:40 AM, Scott Duplichan wrote:
 I found coreboot for AMD Mahogany Fam10 is no longer working. The
 problem
 starts with this change:
 http://www.coreboot.org/pipermail/coreboot-gerrit/2013-July/002391.html

 Some other older AMD boards are likely affected too. [...]

 Known issue, I am sorry you had to bisect this one too in the lack of
 bug tracking. [...]

Would the automated testsystem have caught this? If yes, which platforms
should be present in this automated testsystem to have reasonably good
coverage of systems still relevant to the community?

I hope to get the chance to allocate resources to run a bunch of
platforms in my own automated testsystem. A list of maybe 5-10 desirable
platforms/boards would be appreciated, preferably not just Thinkpads and
Chromebooks. If this works out (should know about this by May/June),
those boards would end up testing every mainline commit.

Regards,
Carl-Daniel


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

Re: [coreboot] coreboot code of conduct

[Carl-Daniel Hailfinger]

Hi everyone,

can we please put the Code of Conduct under some revision control?
It seems patches are being ignored or getting lost.

There are two possible solutions: Removing the lock on the wiki page or
having the CoC in git/gerrit with automatic publishing. I'm fine with
either solution.

Regards,
Carl-Daniel


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

Re: [coreboot] FOSDEM 2015

[Carl-Daniel Hailfinger]

Hi everyone,

if you're coming to FOSDEM and can help out at the booth, please send a
short reply to this mail.

This is a friendly reminder to fill in
https://www.coreboot.org/Talk:FOSDEM_2015 with the details of what
you're bringing.

Please also tell me if you want me to bring some bulky/heavy stuff. I
will arrive by car.

Regards,
Carl-Daniel

On 08.01.2015 10:48, Carl-Daniel Hailfinger wrote:
 Hi everyone,

 please fill in https://www.coreboot.org/Talk:FOSDEM_2015 if you're coming.
 The same page for 2014 maight give you some ideas on what to bring with you.
 We have a booth/stand with a single table.

 Regards,
 Carl-Daniel

 On 22.11.2014 01:43, Carl-Daniel Hailfinger wrote:
 31 Jan 2015 and 1 Feb 2015:
 https://fosdem.org/2015/news/2014-09-19-call-for-participation-part-two/

 I would love to be there again and some of you already said they'd try
 to be there, but I forgot who. Who can be there with me at the booth and
 when can you be there?





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

Re: [coreboot] why is firmware 32 bit as opposed to 64 bit

[Carl-Daniel Hailfinger]

Hi Scott,

congratulations to this awesome feat!

On 21.01.2015 06:08, Scott Duplichan wrote:
 ron minnich [mailto:rminn...@gmail.com] wrote:

 ]Sent: Sunday, August 10, 2014 06:34 PM
 ]To: Marc Jones
 ]Cc: Scott Duplichan; coreboot
 ]Subject: Re: [coreboot] why is firmware 32 bit as opposed to 64 bit
 ]
 ]I understand the arguments.
 ]
 ]It's worth remembering that coreboot has to date run on 5 different
 ]architectures. 4 of those used paging. The x86 has always been the
 ]outlier. Lack of paging has costs not discussed much. Rmodules would
 ]be a lot simpler if we had paging. We could make the code space
 ]readonly, which we should be doing anyway. We would have less fighting
 ]with the granularity and alignment restrictions of MTRRs. We could
 ]catch NULL pointers in hardware. These are clear benefits. And they
 ]all apply to the ramstage as well as other stages.
 ][...]
 ]
 ]In any event, this is all stuff that can be measured, and I propose to
 ]implement and measure it. Then we can see. I'm not convinced that a
 ]few percent either way on code size is a showstopper.

 Another reason to convert coreboot x86 to 64-bit mode is to avoid 
 negative comparisons to UEFI by those who don't know better. UEFI x86
 uses 32-bit code for the first part of execution and then 64-bit for
 the remainder. Some might say x86 UEFI is 64-bit, why not coreboot?
 [...]

 I wanted to do an experimental proof of concept port of x86 coreboot to
 64 bit mode. I was hoping to switch to 64-bit mode immediately. Running
 romstage before the x64 switch is too much like UEFI, in that a whole
 lot of execution runs in 32-bit mode.

 I chose ASRock E350M1 for the experiment because I have the board and
 the reference code is built from source. I did the conversion and got
 it working on simnow. But it failed on real hardware. It turns out the
 processor (and possibly all AMD processors) can't handle rom-based page
 tables. I tried presetting dirty and accessed bits, along with every
 MTRR cache setting. Nothing worked. It is possible Intel processors can
 use rom based page tables. But I have not bothered to test that because
 of lack of needed Intel reference code source.
 [...]

 I almost scrapped the experiment after finding rom based page tables
 couldn't be used. But I did try the next best thing, cache as ram page
 tables. This works and the board boots all the way to SeaBIOS. So cache
 as ram initialization runs in 32-bit mode as before, but agesa, cimx, and
 everything until payload launch runs in x64 mode.
 [...]
 Here is a summary of changes:

 Switch compiler code generation from 32-bit to 64-bit. Switch asm code too,
 [...]

I really hope this patch will not bitrot. It's a nice way to check where
we still hardcode things like 32 bit addresses.

From a coreboot promotion perspective, it also will help a lot. I look
forward to telling people at FOSDEM that coreboot can run in AMD64 long
mode if anyone is inclined to do that.

Regards,
Carl-Daniel


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

Re: [coreboot] coreboot code of conduct

[Carl-Daniel Hailfinger]

Hi Patrick,

I noticed that my comment on the wiki talk page for the CoC seemed to be
unnoticed, that's why I'm continuing the discussion on the mailing list.


On 19.01.2015 17:13, Patrick Georgi wrote:
 Am 2015-01-19 12:52, schrieb Carl-Daniel Hailfinger:
 Real citation needed, not just some sentiment. For example, quite a few
 feminist blogs point to intimidating and derogatory speech/actions as
 the primary hurdles against female participation in online communities.
 I have read no such reports about our community, but we did have some
 (relatively minor) incidents in the past that made contributors well
 less than welcome.

 I'd concentrate on solving our own issues first, over trying to fix
 all the world's grievances.

 That said, I'm not sure what bucket these incidents fall into, and I'm
 not sure if our list of examples of unsuitable behavior cover only
 harassment. Maybe we should replace Harassment includes: with
 Examples of actions we don't want to see in our community:?

The examples in the updated CoC were copied from the Citizen Code of
Conduct and there are countless better lists of examples out there.
If we really want this list of examples, can we at least remove the
really vague ones which include the word inappropriate?

I also would like to suggest a rewording elsewhere to make the CoC sound
a bit friendlier: Change
Check your motives: Using this code of conduct aggressively against
other people in the community might also be harassment. Behave. to
Using this code of conduct aggressively against other people in the
community might also be harassment. Be considerate when enforcing the
code of conduct and always try to listen to both sides before passing
judgment.

Regards,
Carl-Daniel


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

Re: [coreboot] coreboot code of conduct

[Carl-Daniel Hailfinger]

Hi Marc,

On 19.01.2015 01:49, Marc Jones wrote:
 On Sat Jan 17 2015 at 8:12:20 PM Carl-Daniel Hailfinger wrote:
 Hi Marc,

 thanks for writing this up.

 On 16.01.2015 19:15, Marc Jones wrote:
 A coreboot code of conduct has been posted on the wiki.
   - http://www.coreboot.org/Code_of_Conduct

 I have written a blog post about why we have a code of conduct.
   - http://blogs.coreboot.org/blog/2015/01/16/coreboot-code-of-conduct/

 Feel free to give feedback on the policy and how else we can contribute
 to a welcoming and collaborative environment.
 Given that the Code of Conduct has been announced publicly in a blog
 post, the feedback is probably expected to be public as well. Apologies
 if that is not the case.

 The current wording suggests that anyone can be expelled from the
 community permanently without warning for either perceived harrassment
 or for strongly enforcing the code of conduct. This is probably not the
 intention.
 Open discussion is acceptable.

Adding that sentence to the CoC would be helpful.


 Furthermore, the second paragraph of Unacceptable Behaviour is either
 redundant or woefully incomplete. If you really think the word
 harassing from the first paragraph needs to be defined, you should
 define the other words from the first paragraph intimidating,
 abusive, discriminatory, derogatory and demeaning as well. I
 suggest deleting that second paragraph.
 I'll disagree. Harassment is the most common problem in online communities

Real citation needed, not just some sentiment. For example, quite a few
feminist blogs point to intimidating and derogatory speech/actions as
the primary hurdles against female participation in online communities.


 and warrants the paragraph about those unacceptable behaviors.

If harassment is the most common problem, that definitely warrants
listing harassment first (which is not the case in the current CoC).


 Defining
 every other term would not make this policy any more robust.

Is the term harassment so unclear it warrants explanation? I thought
there was universal agreement that harassment is bad, but having to
define harassment implies that there is no such universal agreement (you
can't agree on something undefined).
I argue that creating our own homegrown definition of harassment (or
copying someone else's homegrown definition) makes this policy less
robust because this current homegrown definition is woefully incomplete.


 Please define community organizers. Did you mean arbitration team?
 Or is it the community members present at an event?
 It isn't not meant to be specific to an arbitration team. These members may
 not be present in all cases and organizers of events and online communities
 should uphold the good standards of the community.

Thanks for clarifying. The CoC would benefit from adding this clarification.

 
 How can we deploy this against people not part of our community? If
 they're not part of the community in the first place, it is by
 definition impossible to exclude them from our community and the Code of
 Conduct in its current form does not apply. If, on the other hand, we
 define everyone on the mailing list, everyone on IRC and everyone
 visiting our booths at various conferences and trade shows as being part
 of our community, we're going to overshoot the mark. I don't want to be
 guilty by association just because some troll on IRC joins all channels,
 spews some random offensive crap and disappears.
 It applies to everyone that participates in coreboot communication, online,
 at an event or in a conference booth. People that are not up to this
 standard of behavior are not welcome in our community and they should be
 asked to leave. If a troll joins and spams the channel, clearly ask them to
 leave. If they don't leave report them to a channel or IRCOP. If there is a
 question of the policy or of a behavior, please contact an organizer or
 someone from the arbitration team.

Great, thanks for the explanation and guideline!


Regards,
Carl-Daniel


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

Re: [coreboot] coreboot code of conduct

[Carl-Daniel Hailfinger]

On 19.01.2015 17:13, Patrick Georgi wrote:
 Am 2015-01-19 12:52, schrieb Carl-Daniel Hailfinger:
 Real citation needed, not just some sentiment. For example, quite a few
 feminist blogs point to intimidating and derogatory speech/actions as
 the primary hurdles against female participation in online communities.
 I have read no such reports about our community, but we did have some
 (relatively minor) incidents in the past that made contributors well
 less than welcome.

 I'd concentrate on solving our own issues first, over trying to fix
 all the world's grievances.

 That said, I'm not sure what bucket these incidents fall into, and I'm
 not sure if our list of examples of unsuitable behavior cover only
 harassment. Maybe we should replace Harassment includes: with
 Examples of actions we don't want to see in our community:?

 and warrants the paragraph about those unacceptable behaviors.

 If harassment is the most common problem, that definitely warrants
 listing harassment first (which is not the case in the current CoC).
 Let's just say, they're all pretty terrible?

 Please define community organizers. Did you mean arbitration team?
 Or is it the community members present at an event?
 It isn't not meant to be specific to an arbitration team. These
 members may
 not be present in all cases and organizers of events and online
 communities
 should uphold the good standards of the community.

 Thanks for clarifying. The CoC would benefit from adding this
 clarification.

 http://www.coreboot.org/Talk:Code_of_Conduct is generally writable
 with a Wiki account. Want to propose some language?

Thanks, I just did that.

Regards,
Carl-Daniel

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

Re: [coreboot] coreboot code of conduct

[Carl-Daniel Hailfinger]

Hi Marc,

thanks for writing this up.

On 16.01.2015 19:15, Marc Jones wrote:
 A coreboot code of conduct has been posted on the wiki.
   - http://www.coreboot.org/Code_of_Conduct

 I have written a blog post about why we have a code of conduct.
   - http://blogs.coreboot.org/blog/2015/01/16/coreboot-code-of-conduct/

 Feel free to give feedback on the policy and how else we can contribute to
 a welcoming and collaborative environment.

Given that the Code of Conduct has been announced publicly in a blog
post, the feedback is probably expected to be public as well. Apologies
if that is not the case.

The current wording suggests that anyone can be expelled from the
community permanently without warning for either perceived harrassment
or for strongly enforcing the code of conduct. This is probably not the
intention.

Furthermore, the second paragraph of Unacceptable Behaviour is either
redundant or woefully incomplete. If you really think the word
harassing from the first paragraph needs to be defined, you should
define the other words from the first paragraph intimidating,
abusive, discriminatory, derogatory and demeaning as well. I
suggest deleting that second paragraph.

Please define community organizers. Did you mean arbitration team?
Or is it the community members present at an event?

How can we deploy this against people not part of our community? If
they're not part of the community in the first place, it is by
definition impossible to exclude them from our community and the Code of
Conduct in its current form does not apply. If, on the other hand, we
define everyone on the mailing list, everyone on IRC and everyone
visiting our booths at various conferences and trade shows as being part
of our community, we're going to overshoot the mark. I don't want to be
guilty by association just because some troll on IRC joins all channels,
spews some random offensive crap and disappears.

That said, I think having a Code of Conduct may eventually prove helpful
in case we have to deal with problems.

Regards,
Carl-Daniel


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

Re: [coreboot] FOSDEM 2015

[Carl-Daniel Hailfinger]

Hi everyone,

please fill in https://www.coreboot.org/Talk:FOSDEM_2015 if you're coming.
The same page for 2014 maight give you some ideas on what to bring with you.
We have a booth/stand with a single table.

Regards,
Carl-Daniel

On 22.11.2014 01:43, Carl-Daniel Hailfinger wrote:
 31 Jan 2015 and 1 Feb 2015:
 https://fosdem.org/2015/news/2014-09-19-call-for-participation-part-two/

 I would love to be there again and some of you already said they'd try
 to be there, but I forgot who. Who can be there with me at the booth and
 when can you be there?



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

Re: [coreboot] Success in booting the kernel in less that 1 second on the x60

[Carl-Daniel Hailfinger]

Hi Charles,

the main talk deadline and lightning talk deadline for FOSDEM are over,
but maybe some of the developer rooms somewhat fit the topic and still
accept the talk? Not sure.

In any case, it would be great to have you there at FOSDEM at our booth
if we get a booth this year.

Regards,
Carl-Daniel

On 13.12.2014 08:47, ron minnich wrote:
 If you all get this take it to FOSDEM!

 BTW I need a tiny kernel for u-root, how small can you get it at this point?

 ron

 On Fri Dec 12 2014 at 9:51:46 PM Charles Devereaux coreb...@guylhem.net
 wrote:

 On Wed, Jul 2, 2014 at 10:48 AM, ron minnich rminn...@gmail.com wrote:
 This is great. We've gotten an acer c720 down to 1.7 seconds from power
 button to chromeos login screen. I've always wanted to get it done in under
 a second. I hope you can get there!

 It looks quite possible.

 I couldn't sleep much last night, so I burned the midnight oil to achieve
 my goal of a *real fast* boot, building on the i915.fastboot improvements.

 It may have taken 4 months, but I could finally trim the kernel boot time
 to about 0.8s after further hackish fixes - like starting the scsi and sata
 drivers before the tty and char drivers, enabling paralllel probe for ahci,
 making psmouse a module because it was delaying boot too much, etc.

 If you use systemd with the configuration files I suggested before, your
 system should now be ready 1.4s after coreboot started grub.
 [...]



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

Re: [coreboot] rfkill equivalent on the X60 - first partial success

[Carl-Daniel Hailfinger]

On 07.12.2014 04:31, Charles Devereaux wrote:
 It can be powered, since in the X60 the WWAN port only has the USB lines
 wired, so it's not much of a security problem for the PCI bus as long as it
 is not connected to the USB bus where it could wake up from suspend and
 pretend to be many different things.

 The hardware swich properly disconnects the bluetooth module from USB. It
 would be nice to do the same for wwan, but I guess ec_access and echo -n
 suspend are better than nothing. I plan to try and create a rfkill-wwan
 kernel module doing just that. I tried to find some code example for the RCBA
 but couldn't.

Has anyone ever managed to get the USB lines on the T60 WLAN slot to
work? I plugged in an Intel 7260 802.11ac + Bluetooth card, and it is
reportedly using USB for bluetooth and PCIe for WLAN. My problem is that
the Bluetooth part of the card doesn't even show up in lsusb.

This thread made me wonder whether this is just an issue with broken rfkill.

Regards,
Carl-Daniel

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

[coreboot] FOSDEM 2015

[Carl-Daniel Hailfinger]

Hi everyone!

31 Jan 2015 and 1 Feb 2015:
https://fosdem.org/2015/news/2014-09-19-call-for-participation-part-two/

I would love to be there again and some of you already said they'd try
to be there, but I forgot who. Who can be there with me at the booth and
when can you be there?

A preliminary stand application has already been sent by me to somewhat
hit the deadline, but I'd like to fill it in a bit more.

Side note: If someone has an interesting topic for a lightning talk,
please submit one!

Regards,
Carl-Daniel

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

Re: [coreboot] sourcing 128MB flash chips for an X60 with coreboot

[Carl-Daniel Hailfinger via coreboot]

Hi,

On 29.10.2014 05:17, Charles Devereaux via coreboot wrote:
 On Tue, Oct 28, 2014 at 8:56 PM, Kyösti Mälkki kyosti.mal...@gmail.com
 wrote:

 For the i82801gx part in x60, I am not sure if it will support 16MB SPI
 parts as datasheet specifies decode registers for the top 8MB only.

 Or was there already a proof-of-concept it works?

 FWH_DEC_EN1—Firmware Hub Decode Enable Register.
 Oops. you may be right. I just picked up 16 MB since it was the largest
 size SPI would support. For the moment, I guess I will have to restrict the
 images to 8MB

What does FWH_DEC_EN1 have to to with SPI flash? AFAICS it's for FWH
flash, a totally different beast.
Or put another way, why would that register restrict SPI flash size in
any way?

Regards,
Carl-Daniel


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

Re: [coreboot] apologies in advance for a question I may have asked

[Carl-Daniel Hailfinger]

Am 27.08.2014 22:07 schrieb ron minnich:
 well, stefan, I was hoping not to hear that answer, but I guess that's
 the way it goes :-)

Well, 16 MByte are doable and also happen on real hardware, but with
bigger chips you're out of luck. Both for SPI addressing reasons (24 bit
addresses by default) and for legacy reasons. I heard rumors that newer
x86 can handle larger flash chips, but AFAIK only with the help of PIO,
not directly mapped. Similar rule for Qemu.

That said, changing FLASH_MAP_BASE_MIN to

#define FLASH_MAP_BASE_MIN ((hwaddr)(0x1ULL - 16*1024*1024))

should work.


Regards,
Carl-Daniel

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

Re: [coreboot] New board with unsupported cpu, chipset, and superIO

[Carl-Daniel Hailfinger]

Am 28.08.2014 23:16 schrieb Todd Weaver:
 On Aug 28, 2014, at 11:26 AM, Todd Weaver t...@m2n.com wrote:
 On Aug 28, 2014, at 10:59 AM, ron minnich rminn...@gmail.com wrote:
 The truth here is that we NEED to have a blob-free version (libreboot), so 
 I have a lot of work ahead of me :)
 If you NEED blob-free, you may need to go ARM.
 We cannot easily (actually it would be quite impossible) to move from the 
 Intel hardware at this point.
 Per the private messages, I am asking upstream if we can switch to AMD, is 
 AMD in a state where we can attain (meaning it is possible (comparing that to 
 Intel)) a binary free BIOS?

You can, but with chipsets/CPUs released in the last few months you may
be out of luck. Right now, it appears AMD does not see compelling enough
business reasons to publish the source code for the newest hardware
generations, but you may be able to get the source code for the blobs
under NDA.
That said, there are quite a few pieces of recent (and still in
production) AMD hardware which do have full coreboot support. Exceptions
from the blob-free guarantee are graphics firmware and USB3 firmware,
which are both not executed on the main CPU.

Depending on how big your order is (not just enthusiasts all over the
world will surely buy it, but real money spent by your
company/organization), you might have some real leverage, even for
getting code published.

Regards,
Carl-Daniel

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

Re: [coreboot] disabling bios usb stack

[Carl-Daniel Hailfinger]

Hi Ron,

Am 26.08.2014 00:22 schrieb ron minnich:
 disabling the usb stack is the goal in this case.

AFAIK it's called USB keyboard support, USB legacy support or
something similar in most BIOSes. This internally maps a USB keyboard to
a virtual PS/2 keyboard and sometimes has quite a few issues. If that's
what your friend meant, disabling it should be straightforward in the
BIOS menu.
However, if your friend is a victim of EFI, I fear he is beyond help
except for trying coreboot.

Regards,
Carl-Daniel

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

Re: [coreboot] AMD PSP

[Carl-Daniel Hailfinger]

Am 26.08.2014 20:00 schrieb Bruce Griffith:
 Here's what I know about PSP:

 I'm utterly ignorant of the PSP -- is this thing like the Intel ME, and
 how scared should we be of it?
 Somewhat scared.

 The PSP is an actual processor that takes control when reset is released.
 The x86 does not start fetching code until the PSP is satisfied that BIOS
 meets whatever constraints have been programmed into the PSP firmware.

I can see this as a way to prevent modification of some signed parts of
coreboot, i.e. it can be a usable and desirable security mechanism
against unauthorized firmware replacement. However, if the key used for
verification is under control of a foreign entity and can't be changed,
some users (especially government users) won't consider this to be
additional security.


 There are TPM-like characteristics but I don't know any specifics.

 The PSP is capable of locking additional processor features that could
 be exploited to take over a system.

 My hope is that it ... deactivates itself silently.
 For the coreboot implementation, it runs, decides that the x86 code is not
 its concern, and the x86 starts fetching code.  From that point on, I
 think the PSP is transparent to the x86.

 After glancing thru [the PSP presentation], it looks more like they are
 grafting the security model of ARM-based SoCs onto x86 where a masked
 ROM loads the next stage.
 A masked processor and associated firmware (the PSP) validate the first
 stage of x86 code.  What comprises the first stage is arbitrary and gets
 signed with an AMD private key.  Your first stage could be bootblock,
 bootblock plus romstage, something more involved, or something less
 involved.  You need a legal arrangement with AMD to get your first stage
 signed. For coreboot, none of the x86 code is signed.

Hm. Is there a way to have AMD exchange that key for your own, possibly
by paying decent money?
That way, the platform can be under your own control which would make
security-conscious users (governments, military, ...) happy.

Regards,
Carl-Daniel

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

Re: [coreboot] earliest running code with qemu

[Carl-Daniel Hailfinger]

Am 13.08.2014 07:05 schrieb ron minnich:
 I'm sure it could run were someone to implement it.

A few years ago, I implemented partial MTRR support in Qemu. To be
exact, I added support for not throwing away the MTRR contents after a
write and now you can actually read the MTRRs after writing. That said,
you'd have to add real MTRR handling to get CAR (cache-as-RAM) to work
in Qemu. I once had some half-finished patches, but that was before Qemu
used QOM. It might be possible to salvage these half-finished patches
once I dig up my old hard drive. The mechanics of implementing CAR are a
bit tricky, but I think overall maybe 200 lines of code should suffice.
If you're still interested, tell me and I'll try to dig up my old patch
over the next few weeks (old hard drive is in a pile, and I don't know
which one has that patch).

Regards,
Carl-Daniel

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

Re: [coreboot] Any plans to fix payload builds on 64-bit machines?

[Carl-Daniel Hailfinger]

Am 21.05.2014 22:13 schrieb Patrick Georgi:
 Am 21.05.2014 03:31, schrieb Sean McNeil:
 All the recent changes to how the compiler is defined have now caused
 payloads like FILO and SeaBIOS to not build on X86_64 machines. Is
 anyone working to fix this?
 --- a/src/arch/x86/Makefile.inc
 +++ b/src/arch/x86/Makefile.inc
 @@ -347,6 +347,7 @@ seabios:
 CC=$(CC_x86_32) LD=$(LD_x86_32)
 OBJDUMP=$(OBJDUMP_x86_32) \
 OBJCOPY=$(OBJCOPY_x86_32)
 STRIP=$(STRIP_x86_32) \
 AS=$(AS_x86_32) \
 +   CFLAGS=$(CLAGS_x86_32) \

Typo, the f in CFLAGS_x86_32 is missing.


 CONFIG_SEABIOS_MASTER=$(CONFIG_SEABIOS_MASTER) \
 CONFIG_SEABIOS_STABLE=$(CONFIG_SEABIOS_STABLE) \

 CONFIG_SEABIOS_THREAD_OPTIONROMS=$(CONFIG_SEABIOS_THREAD_OPTIONROMS) \

 might do, or

 CC=$(CC_x86_32) $(CFLAGS_x86_x32) two lines earlier.

 I can't test since my host compiler _really_ is broken for
 firmware-style build tasks.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/


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

[coreboot] AMD A76M chipset?

[Carl-Daniel Hailfinger]

Hi,

HP and other laptop vendors claim to use an AMD A76M chipset in some of
their machines. I have been unable to find any info about (or even
confirm the existence of) the A76M on the AMD website or any other
reliable source.
https://en.wikipedia.org/wiki/Comparison_of_AMD_chipsets is also silent,
but the numbers there suggest the A76M might be a Bolton chipset.

Does anyone know if there are public docs for the A76M (possibly under
another name), and how feasible it is to drive it with current public
(or to-be-released) AGESA?

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/


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

Re: [coreboot] Thinkpad X61

[Carl-Daniel Hailfinger]

Hi mad,

someone who has experience porting chipsets could add support for the
i965 chipset with maybe 6-12 months of fulltime work. This is of course
under the (unlikely) assumption that full documentation is available. If
you're doing it as a hobby and have to learn firmware development first,
I expect 4 years of spare time, maybe more.
After that porting to the Thinkpad x61 would be relatively easy.

For more info see
http://www.coreboot.org/pipermail/coreboot/2011-July/065973.html

Regards, Carl-Daniel

-- 
http://www.hailfinger.org/


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

Re: [coreboot] P965/ICH8 support revisited

[Carl-Daniel Hailfinger]

Hi Yuval,

someone who has experience porting chipsets could add support for this
i965 chipset with maybe 6-12 months of fulltime work. This is of course
under the (unlikely) assumption that full documentation is available. If
you're doing it as a hobby and have to learn firmware development first,
I expect 4 years of spare time, maybe more.

Regards,
Carl-Daniel

Am 05.04.2014 01:24 schrieb Yuval Adam:
 The P965/ICH8 combo is suspiciously lacking from the coreboot supported 
 chipsets.
 However, I've never done any coreboot development nor do I have the proper 
 insight on how to go about this.
 [...]
 http://www.coreboot.org/pipermail/coreboot/2012-June/070247.html

-- 
http://www.hailfinger.org/


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