Re: [coreboot] Coreboot wiki: what license is the content under?

[Patrick Georgi via coreboot]

The wiki is mostly dead, its data mostly useless. Whatever we'll build
as its replacement can start with a new, clear license system, and
wiki content is either relicensed by its author and then ported over
or deleted/rewritten.

I'd go with CC-BY for the simple reason that documentation acts as
marketing material which should see the widest distribution possible.
People who dislike licensing their content that freely can publish
elsewhere and set up a (CC-BY'd) link.

In any case, we can (and IMHO should) decouple the discussions about
dealing with current content and about future licensing.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

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

[coreboot] Design discussions on gerrit

[Patrick Georgi via coreboot]

Hi,

I just pushed https://review.coreboot.org/19242, which adds a document
discussing mitigations for the ReBAR SMM attack Intel Security
presented in January. I think we had a couple of people bringing it up
on IRC and on the list, but these were relatively unstructured and
nothing happened from there.

I'd just use this opportunity to try out Gerrit as design discussion
tool, so if you're interested in that topic, feel free to comment.


Thanks,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

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

Re: [coreboot] Design discussions on gerrit

[Patrick Georgi via coreboot]

2017-04-12 4:17 GMT+02:00 taii...@gmx.com :
> I was under the impression that coreboots native init boards disabled SMM
> post-init and that this issue only applies to intel's FSP blobbed stuff, am
> I incorrect?
SMM is used on many boards, FSP or not, for tasks such as preparing
for shutdown (eg on i945 it needs to disable busmaster on all devices
for shutdown to work) or to handle certain EC tasks (eg. brightness
settings, potentially only if ACPI isn't enabled).


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

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

Re: [coreboot] Intel ME The Way of the Static Analysis

[Patrick Georgi via coreboot]

Fun tidbit: The ME is running MINIX3 (confirmed by a file in the
Google cache: 
http://webcache.googleusercontent.com/search?q=cache:tCcU0NRwTnQJ:ftp://ftp.supermicro.com/CDR-X11-UP_1.10_for_Intel_X11_UP_platform/Intel/ME/Other_Licenses/Minix3_License.txt+&cd=1&hl=de&ct=clnk&gl=de&lr=lang_de%7Clang_en)

2017-04-26 22:47 GMT+02:00 Youness Alaoui :
> Thanks for the links.
> This is the article that I had seen :
> http://blog.ptsecurity.com/2017/04/intel-me-way-of-static-analysis.html
>
>
> On Tue, Apr 25, 2017 at 10:38 AM, Shawn  wrote:
>>
>> slide:
>> https://www.troopers.de/downloads/troopers17/TR17_ME11_Static.pdf
>>
>> video:
>> https://www.youtube.com/watch?v=2_aokrfcoUk
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot



-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

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

Re: [coreboot] Anyone got an opinion, technical or otherwise, on this?

[Patrick Georgi via coreboot]

Semi-Accurate only claims accuracy according to what's on the box. The
official documentation of the issue can be found at
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075

It looks like a software bug in the AMT firmware. Therefore:
- No AMT (eg on non-business consumer devices) -> no (bug | exploit).
- Present but disabled AMT (eg. on business devices without AMT
enrollment) -> no (bug | exploit). (although there's apparently a way
to enable AMT unsupervised under some circumstances with some level of
local access. or something.)


Patrick

2017-05-02 19:31 GMT+02:00 John Lewis :
> https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/
>
> The article says "all" Intel boards since 2008 are locally vulnerable
> (ME exploit), but the Intel advisory (linked within) says consumer
> devices are okay.
>
> What the article says about even low end devices still having the
> features albeit turned "off" rings true to me, based on stuff I've read
> here and elsewhere. What's your take (bearing in mind the technical
> details aren't available, yet)?
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot



-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

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

Re: [coreboot] CONFIG_CBFS_SIZE vs CONFIG_ROM_SIZE

[Patrick Georgi via coreboot]

We always add an FMAP now (think of it of a vendor neutral flash partition
table), which resides outside CBFS.

2017-05-23 9:49 GMT-07:00 Gailu Singh :

> Hi Experts,
>
> If we use CBFS_SIZE to be same as ROM_SIZE on our apollolake board grub
> fails to load grub.cfg located in CBFS. Based on experiments we found that
> grub.cfg is loaded correctly if we keep minimum difference of 64KB between
> CBFS_SIZE and ROM_SIZE if we reduce it to less that 64KB problem happens.
>
> Can someone please explain the behavior and if it is expected behavior or
> a bug?
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>



-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Documentation on the website

[Patrick Georgi via coreboot]

Hi everybody,

to elaborate a bit on what Martin reported from the community meeting:

In the last few days I set up our server[0] to regularly render our
repositories Documentation/ directory to
https://www.coreboot.org/Documentation/, using hugo for formatting and
conversion.
The old "Documentation" page on the wiki was renamed to Documentation/old.

The consequence is that contributions to documentation can be made with the
same credentials and using the same review process on gerrit as code
contributions. This should alleviate some of the concerns that were
recently voiced on this list over the process to obtain wiki accounts.

This transition is far from done:

Documentation/ itself is a collection of docs of the last 15 years in at
least four different formats (TeX, unstructured ASCII text, markdown, PDF),
some of it outdated, most of it without declaring a license for
distribution (I suppose GPLv2, just like the entire tree, might be
applicable, but we should definitely see that we get on top of things here).

Documentation/ now explicitly declares CC-BY 4.0 as license for all new
contributions as of 2 days ago (there weren't any, so no unexpected
surprises here), providing a much clearer situation going forward.

The configuration of the site is rather rudimentary: Several documents
aren't linked anywhere and the sidebar is somewhat nonsensical, merely
mirroring what the old index.html exposed. The design might need
improvements.
All in all I believe it's a foundation to build upon, though.

I'll clean up things over time, but that's not my primary project right
now. Feel free to beat me to it :-)
Contributions welcome!


Thanks,
Patrick

[0] https://review.coreboot.org/#/c/19881/ plus some server-side work
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Gerrit update to 2.14

[Patrick Georgi via coreboot]

Hi everybody,

I just updated Gerrit to 2.14, which brings some notable and user-visible
changes that you might want to deal with:

* There's a new UI based on Polymer. This will eventually replace the
current GWT based UI but isn't complete yet. There's a "new/old UI" toggle
near the end of the page.

* There's an assignee field now. This can denote responsibility (but comes
with no rights or obligations)

* Emails now ship with an HTML part. This can be disabled in your user
settings.
* speaking of emails: They changed the template format for the emails, so
now we could finally develop a new structure for gerrit's notification,
something people want for a long time but which I postponed to wait for
precisely this transition.
* speaking of emails, pt 2: There's now limited support for accepting
comments to changes in email replies. I'd need to enable it to work, but I
hereby want to gauge interest in such a feature.

Feedback welcome!

Thanks,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] AMDPSP discussion

[Patrick Georgi via coreboot]

I hope y'all realize that you're preaching to the choir - and to the choir
only?
The folks making these weird decisions typically aren't signed onto such
mailing lists.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] AMD EPYC and PSP

[Patrick Georgi via coreboot]

Since these discussions flare up time and time again (without ever being
resolved in any productive way because the discussion happens in the wrong
forum [0]):
Netflix et al are (probably) required by their contracts with the content
providers (producers, distributors) to make it reasonably hard to access
the unencrypted bits of sufficiently high quality video (discussing the
merit and feasibility of these approaches should also happen elsewhere [0]).
The PSP (or ME, or ARM TrustZone) provide the technical means for a
programmable DRM path (what Intel calls the PAVP, protected audio/video
path, which seems to be partly implemented by the ME) with sufficient
security guarantees that Netflix et al are willing to risk sending HD  (or
4K or better) video through that channel.

Therefore: A CPU with PSP/ME/ARM TZ is one that won't support Netflix [1].


Patrick

[0] Preaching to the choir is fun the first 10 times. It's slightly less
fun the next 10 times. And totally tedious the 1000th-1010th times. Sorry
that you're late to the party but that's not our fault.
Worse, debating these things here helps nothing since the people that you
really should to talk to for making a difference aren't subscribed to
technical lists like this one. They probably play golf and enjoy the sun.
You can likely talk to them if you present a business case with ~8
significant non-zero digits in some currency not very unlike the USD. While
playing golf. And enjoying the sun.

[1] It's quite possible to build designs that come without such a "locked
down processor with access to everything". There's also little money to be
had in building these, while the current designs have a certain level of
maturity that makes any significant deviation a serious risk: These chains
of contracts that connect these coprocessors with Hollywood (probably) come
with contractual penalties for breaches that result from reckless behavior
(such as changing the security architecture nilly-willy). "Not rocking the
boat" is a rather sensible option under such constraints.
Those ~8 significant digits in some USD-style currency mentioned earlier
might help change that risk assessment. You won't be able to crowdfund them
here.

2017-06-08 21:00 GMT+02:00 Rene Shuster :

> Nico,
> Would you mind to elaborate and enlighten us on this matter?
>
> On Thu, Jun 8, 2017 at 1:31 PM, Nico Huber  wrote:
>
>> On 08.06.2017 16:48, Johnysecured88 via coreboot wrote:
>> > Does anyone anticipate the new EPYC cpus not having PSP?
>>
>> Well, I don't. The answer is quite simple if you ask the question
>> differently: Do you expect AMD to drop Netflix support?
>>
>> Nico
>>
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>
>
>
> --
> Tech III * AppControl * Endpoint Protection * Server Maintenance
> Buncombe County Schools Technology Department Network Group
> ComicSans Awareness Campaign 
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>



-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Yet another gerrit update (2.14.1)

[Patrick Georgi via coreboot]

Hi everybody,

I just updated our gerrit instance, which should fix a number of
performance related regressions.

Since there were requests for supporting ecdsa and ed25519 keys in gerrit's
ssh interface, I also want to point out that 2.14 brought support for them.
I didn't mention it because it was known to be broken, but 2.14.1 is
supposed to fix it, so feel free to use it now.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] question on SMM

[Patrick Georgi via coreboot]

2017-06-30 19:46 GMT+02:00 ron minnich :

> The only question that has been raised: are we losing an essential
> security guarantee since flash is writeable in this kernel-based "SMM"? The
> big question is whether we're opening up the possibility of firmware
> getting changed, once the kernel is our "smm mode". Is there a reasonable
> mitigation we could use in the SMM handler before we trampoline back up to
> the kernel?
>
To expand on Trammell's comment, FILO has code to work around a similar
issue on some older AMD chipsets: There, you can lock down the chipset's
flash write capability, only to see it circumvented by manual SPI commands
to write to flash. The solution is to tell the SPI flash itself to go
read-only:
https://review.coreboot.org/cgit/filo.git/tree/drivers/sb600.c#n1204

If you're certain that you don't need any more flash writes (for a _long_
time - I believe that one even survived cold resets), that could be another
defensive layer.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Hi-DPI displays and showing text information for kevin in depthcharge

[Patrick Georgi via coreboot]

2017-07-16 11:32 GMT+02:00 Paul Kocialkowski :

> So I am wondering what the best way to solve this would be. I see a few
> options:
> * Having larger fonts for hi-dpi displays
>
I'd go with that. Plus, maybe, a function to select the right font given a
few constraints (display resolution, desired terminal grid size)

There are a bunch of font options with higher resolutions in the Linux
sources (lib/fonts) that could be lifted into libpayload.

* Scaling the font to reach a particular DPI (e.g. based on the physical
> screen size reported from the EDID)
>
This could be a reasonable fallback (eg in case payloads are storage
constrained and can't ship x fonts, or if even the largest font is
intolerably small).
Going for integer multiples (and statically generating the fonts in the
internal format, registering it just like any shipped font) should be good
enough.
No need for any fancy scaling algo either, just duplicate the pixels in all
directions.


> * Reducing the resolution, by optionally providing a preferred one from
> the config
>
Besides the potential dependency on resolution in later stages that you
mentioned, the panel may or may not work well with a lower resolution, or
might just show the same tiny pixels - just fewer of them with a nice,
shiny, black border.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Gerrit: Can't abandon patch

[Patrick Georgi via coreboot]

Hi Denis,

there are two accounts of yours in Gerrit. Maybe you're logged in with one,
and the CL was created with the other?


Patrick

2017-07-13 23:21 GMT+02:00 Denis 'GNUtoo' Carikli :

> Hi,
>
> In the (javascript) web interface, I find no way to abandon a change.
>
> Through ssh I can't either:
> > $ ssh review.coreboot.org gerrit review --abandon 15072,1
> > error: fatal: abandon not permitted
> >
> > fatal: one or more reviews failed; review output above
>
> 15072 is supposed to be the following change:
> Kconfig: Clarify FRAMEBUFFER_KEEP_VESA_MODE.
>
> Denis.
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>



-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Hi-DPI displays and showing text information for kevin in depthcharge

[Patrick Georgi via coreboot]

I wouldn't scale at compile time (as said, storage constrained payloads
might not be happy about that).

I wouldn't scale each character up on each access though (we won't hardware
accelerate the scaling, and yes, that does get slow - framebuffers aren't
always the fastest type of memory and that way the access pattern is the
same set of memcpy()s as for any other huge font, so we won't need to deal
with "fast fonts" and "slow fonts" beyond basic geometry characteristics),
but synthesize a new font in the regular font table at init-time and then
use it like any pre-existing font (just that it happened to be added after
load).

2017-07-17 21:47 GMT+02:00 Julius Werner :

> I agree with most of what Patrick said, I think dynamic scaling to integer
> multiples may be best. Scaling the font up at compile-time seems like
> unnecessary bloat to the binary (although I'm not sure, how big are these
> fonts?). If you do want to include them at compile time, you may as well
> include a real larger font rather than just a scaled one.
>



-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot and INT13H

[Patrick Georgi via coreboot]

2017-07-19 23:24 GMT+02:00 ingegneriafore...@alice.it <
ingegneriafore...@alice.it>:

> 1- where (the name of the file) the INT 13H is implemented in the coreboot
> source code ?
>
It's not. coreboot doesn't provide BIOS services. For those, see seabios (
www.seabios.org)


> 2- if the INT 13H interrupt, when invoked by OS (or application programs),
> can do writing operations in the filesystem of the drive attached to the PC
> or only limits  to writing operations in memory regions different by the
> filesystem ?
>
Not applicable

3- Is a way to see on the screen the fully sequence of operations coreboot
> execute during the boot ? (i don't use QUEMU but program directly the bios
> eeprom chip).

coreboot boots too fast for any meaningful screen output so we dropped
support for that years ago.
There's a log in memory (cbmem -c) or on serial, if configured.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] About Paging, Realmode and what is going on

[Patrick Georgi via coreboot]

2017-07-31 10:52 GMT+02:00 Philipp Stanner :
> 1. cb switches the CPU immediately to Protected Mode, yet Payloads like 
> seaBIOS work in Real Mode. Does coreboot switch the CPU always back to RM 
> before jumping to the payload?
No, payloads are started in pmode.

> 2. When CB switches to PM - who generates and administrates the Page Tables 
> and where?
We use flat mode: 4gb segments starting at 0, for code and data.
Virtual address == logical address == physical address

> 3. Gustavo Duarte writes that GRUB switches from protected mode to real mode 
> and vice versa all the time to address >1MiB of RAM and also use the 
> BIOS-calls. If this is true using GRUB as payload would not work, as GRUB 
> needs to call the non-existent BIOS, right?
It uses BIOS calls, except when built for coreboot.

> 4. Once CB is in PM it can't access physical addresses anymore? It doesn't 
> need to, too?
We use flat mode, see above.

> 5. PM means RAM-access is only possible through virtual addresses which are 
> translated by the MMU using the Page Tables. This question is similar to 
> [2.]: If coreboot generates the Page Tables and the payload would start in PM 
> as well (is this even possible? At least the Linux-Kernel has entry points 
> for RM and PM) this would mean the payload needs to use the Page Tables 
> generated by CB. That wouldn't be a problem as they're linked in the register 
> CR3 anyways?
As stated above, payloads start in pmode. As stated above, we use a
flat representation which comes with no surprises. The payload can
then reconfigure the system to setup its own configuration.

> Why does every modern CPU still start in RM? I do get the compatibility 
> problem, but on the other hand: Do you need it for anything beside booting 
> MS-DOS on your Ryzen? Is it really impossible for AMD and Intel to create a 
> new CPU-generation with the x86-instruction set without RM, 16-bit-registers 
> and 20-bit-mode registers like CS, SS etc. No modern OS uses bios calls. No 
> CPU is ever switched to RM again after booting up. They should get rid of 
> this old stuff.
"Every modern x86 CPU". In the end, that's something to ask the CPU
vendors (but don't expect any answers). Some guesses:

1. Windows 7 uses BIOS calls (although they stopped switching back to
real mode for that, they use x86 16bit emulation. still, BIOS services
need to be there)
2. CPUs might not be switched back to real mode today, but from 32bit
modes it's a pretty short route to vm86 modes, which are effectively
identical to real mode and still in use.
3. Why change a working system and risk compatibility issues? x86's
biggest selling point is compatibility, and if you forfeit that, users
may move off your architecture entirely.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

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

Re: [coreboot] About Paging, Realmode and what is going on

[Patrick Georgi via coreboot]

2017-07-31 14:46 GMT+02:00 Nico Huber :
> No idea about the kernel's requirements
Windows 7's kernel uses int10 calls for checking out various graphics
properties, even when booting with UEFI (and therefore GOP drivers
better put some int10 handler in the right place if they want to
continue to support Win7).

> No idea, all of them? usually through a CSM (Compatibility Support
> Module). It's kind of the SeaBIOS of UEFI.
SeaBIOS can be compiled as CSM, too (though commercial UEFIs probably
don't ship with SeaBIOS for licensing reasons)


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

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

Re: [coreboot] About Paging, Realmode and what is going on

[Patrick Georgi via coreboot]

2017-08-02 21:08 GMT+02:00 Zoran Stojsavljevic :
> And my question is: what for? Or I did not get the idea... Who really needs
> to use paging in boot-loaders? Even INTEL, which (on purpose) makes things
> way over-dimensioned and over-complicated, does NOT use paging in UEFI
> BIOSes, so far???
They must for X64 builds. Long Mode _requires_ page tables (even if
it's a single 1TB page to create a 1:1 mapping).

But fear not, UEFI also supported paging for a _really_ long time for
Runtime Services, so everything DXE onward better prepares for being
called by Runtime Services or SMM, even if the spec explicitly says
that it shouldn't happen - it did. Apparently they just couldn't fully
eschew the mantle of superfluous complexity.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

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

Re: [coreboot] x86 : Puzzles about reset code

[Patrick Georgi via coreboot]

2017-08-16 5:03 GMT+02:00 王翔 :
> What is the meaning of hand coding?  In 16-bit mode, the last two bytes
are ignored.
This is _very_ old code. Back in the day, before we started to strongly
encourage people to use our compiler, we had to deal with tons of different
versions of the toolchain.
As the comment to the code indicates, 16bit relocations worked for some and
failed for others. Therefore we went for the safe route and manually
created a 32bit relocation.
We could probably clean up this part of the code now, but since so few
people are ever concerned with it (because it does exactly what it's
supposed to), there was no pressing need yet.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Why I don't like links in commit messages and comments ...

[Patrick Georgi via coreboot]

2017-08-17 13:49 GMT+02:00 Peter Stuge :
> Let's agree to disagree. Direct links are, well, direct; eliminating
> an undesirable extra search step.
Science today uses doi numbers/links, which plan for moves by addint
indirection.

> I think that broken links are a temporary problem in these early days
> of digital storage
Cue Ted Nelson (http://www.xanadu.net/)


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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

Re: [coreboot] util/cbfstool in coreboot master

[Patrick Georgi via coreboot]

It's used for the hashing features and pulled in by one of the
submodules. Use `git submodule update --init` to pull in all of them
(except blobs, which is disabled by default).

2017-08-21 10:55 GMT+02:00 John Lewis :
> Hi Guys,
>
> Apparently, in coreboot master, util/cbfstool has a reference to some vboot
> code that isn't pulled in. Can someone (possibly Patrick) tell me why? This
> looks like a barrier to people being able to use/compile things.
>
> root@beaglebone:~/coreboot/util/cbfstool# make
> HOSTCC cbfstool/cbfstool.o
> In file included from /root/coreboot/util/cbfstool/cbfstool.c:27:0:
> /root/coreboot/util/cbfstool/cbfs.h:23:21: fatal error: vb2_api.h: No such
> file or directory
>  #include 
>
> Cheers,
>
> John.
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot



-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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

Re: [coreboot] util/cbfstool in coreboot master

[Patrick Georgi via coreboot]

Good call. I amended https://www.coreboot.org/Git to ask users to do
`git clone --recurse-submodules` which will checkout the submodules as
part of the download.

2017-08-21 11:07 GMT+02:00 John Lewis :
> Thanks Patrick - is that written somewhere reasonably obvious that I missed?
> Just thinking from the POV of people new to the project or who aren't coding
> mavens (like me).
>
>
> On Mon, 21 Aug, 2017 at 10:04 AM, Patrick Georgi  wrote:
>
> It's used for the hashing features and pulled in by one of the submodules.
> Use `git submodule update --init` to pull in all of them (except blobs,
> which is disabled by default). 2017-08-21 10:55 GMT+02:00 John Lewis
> :
>
> Hi Guys, Apparently, in coreboot master, util/cbfstool has a reference to
> some vboot code that isn't pulled in. Can someone (possibly Patrick) tell me
> why? This looks like a barrier to people being able to use/compile things.
> root@beaglebone:~/coreboot/util/cbfstool# make HOSTCC cbfstool/cbfstool.o In
> file included from /root/coreboot/util/cbfstool/cbfstool.c:27:0:
> /root/coreboot/util/cbfstool/cbfs.h:23:21: fatal error: vb2_api.h: No such
> file or directory #include  Cheers, John. -- coreboot mailing
> list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer:
> Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul
> Manicle, Halimah DeLaine Prado



-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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

Re: [coreboot] util/cbfstool in coreboot master

[Patrick Georgi via coreboot]

2017-08-21 11:25 GMT+02:00 John Lewis :
> Do you think there's something that could be also be done in
> this regard on https://github.com/coreboot/coreboot (like customise the
> message in the "clone or download" button?
GitHub is not our platform, we're merely guests there (and that's the
reason we have read-only repos there). So no, AFAIK that can't be
changed.

> Because when I do a search for
> "coreboot git" that's what comes up as the top result, and obviously then
> you will probably have people blindly git cloning and wondering why things
> don't work.
That's sad. The only fix I see is to take down the mirror.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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

Re: [coreboot] Moving the command line for Linux kernel payloads

[Patrick Georgi via coreboot]

2017-09-07 0:09 GMT+02:00 Trammell Hudson :
> Is there a current or historical reason for the ordering?
The reason for this order is that there had to be _some_ order.
So go ahead and push the change for review, it looks reasonable.


Thanks,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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

Re: [coreboot] [kernel-hardening] ME and PSP

[Patrick Georgi via coreboot]

Am 07.09.2017 20:03 schrieb "Timothy Pearson" <
tpear...@raptorengineering.com>:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/07/2017 10:11 AM, Peter Stuge wrote:
> ron minnich wrote:
>> I don't think we can assume that an open, unlicensed instruction set
>> guarantees open, unlicensed, blob-free CPUs and platforms.
>
> This is of course absolutely accurate.
>
> But a freely licensed ISA and implementation(s) thereof are *one step*
> in the right direction, and a significant one.
>
> RISC-V is not so much a guarantee of anything as it is a potential
> enabler of something.
>
> The fabulous thing about RISC-V is what makes ARM successful; there
> can and will be multiple different silicon vendors, offering products
> with many different features and tradeoffs.
>
> Some can be top performance but proprietary.
> Some can be transparent/open but slower.

We already have this (think cheap ARM SoCs vs. a Xeon).  In practice it
means that if you want to use a computer for real work (such as
developing libre software) you have to go proprietary, which is not what
I think we want to see here.

OpenPOWER is the first attempt to change this that we have seen in a
long time.  I'm honestly surprised at the overall community betting on a
long shot (RISC-V) vs. using what's available and open right now
(POWER9); could anyone shed some light on these decision making
processes?

There is no coherent decision making process.

open ISA and core design does not guarantee open silicon,
and in fact one could argue that it will mean any performance
improvements end up highly locked under NDA and similar to avoid
competitors coming online and ruining tens of millions of dollars of
investment for even one SoC improvement.

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

iQEcBAEBAgAGBQJZsYl8AAoJEK+E3vEXDOFb41AH/1tmCF8BOVua+WZeuGdy6b21
gud7YdlaEKPs8W9uPdsMv0heXXcIZTEl4vNAkZ/QkaH5/+apauekRso21eG66aJK
IcRx3Hi6e6JZ1//ixKhzk7/yQJK/DU8r54qThAXy9TmB7GAepAXdJwAXh9F0nhGv
LYSxdj0m5kSZiKz8qbK5L+emxuCFJ2k7IS92jk6mowBB7xY9DlHVQO+4nskQ1wlW
3zBeNFEFQVvmgoUsCwwNRG86PuJPeaGTQQftlg4r/JCwMPIcv/U419i35csG48ax
WUGhPNpSDrdmS1iC9RUtjnYJcXmEi4WsgF4zFyqqdxTueYOdQn0hcZDCSvfqYAg=
=z92D
-END PGP SIGNATURE-

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

Re: [coreboot] 64 UEFI payload boot fail on Denverton platform but 32 UEFI payload works

[Patrick Georgi via coreboot]

2017-09-22 3:33 GMT+02:00 Melissa Yi :
>Anyone can give some information?
Probably not.

64bit tianocore as payload should work in general (since it still
comes with a 32bit entry point, just switches to long mode really
early).
It's hard to tell what's going on if the entire report is "doesn't work".


Regards,
Patrick Georgi

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

Re: [coreboot] [RFC] Successful build with GCC 7.2 and IASL 20170831 for coreboot 4.7

[Patrick Georgi via coreboot]

2017-10-06 9:43 GMT+02:00 Paul Menzel :
> Having the code base compatible with future toolchains is quite
> important and convenient in my opinion.
That's a great argument to switch out the toolchain 4 months before a release.
Which means 3.5 months ago.

> Especially for bisecting an issue, people don’t rebuild the toolchain
> in each step.
Which means that no matter what we do to crossgcc, there's no reproducibility.
That's not a good argument for doing something or anything at all.

> The good side is, that most warnings and errors of newer toolchains
> actually point out real problems – most of them don’t affect anything
> though –, so fixing those would be a good thing.
Fixing real issues? Yes, please.
Swapping out the entire code optimizer phase, potentially introducing
regressions through no code change at all in coreboot itself? Not at
this time.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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

Re: [coreboot] greetings and laptop questions

[Patrick Georgi via coreboot]

Hi Youness,

2017-10-10 1:54 GMT+02:00 Youness Alaoui :
> it uses FSP, but you fail to mention that anything using coreboot will
> use the FSP unless it's 10 year old hardware (Sandybridge is the
> latest FSP-free supported CPU).
While I understand your frustration, and agree with the general thrust
of your email, and disregarding the "10 years", the Samsung Chromebook
Plus (and many other devices of similar age) beg to differ.
There are devices from 2016 and 2017 shipping with coreboot and no CPU
level blobs in the firmware (the only CPU side blob would be the
kernel's GPU driver).


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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

Re: [coreboot] Freedom Inside - certification system

[Patrick Georgi via coreboot]

2017-10-11 1:29 GMT+02:00 taii...@gmx.com :
> I also propose a hardware-freedom-generic mailinglist be created for
> philosophy debates, "should I buy X?", newbie questions etc moreso now that
> TALOS 2 is in the picture the hardware freedom world is more than just
> coreboot so I think it would be a great idea.
Good idea to move the non-technical fluff elsewhere. Once you've set
it up, please tell us so we can forward any future discussions in that
area.


Thanks,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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

[Patrick Georgi via coreboot]

Am Do., 2. Nov. 2017 um 14:14 Uhr schrieb Peter Stuge :

> Wiki admins: Would that need more effort than IRC integration?
>
JFYI: This thread is the first time I hear about such ideas, and I kinda
administrate the wiki.
So there's that.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 AMD-vi fails because combined sata is enabled

[Patrick Georgi via coreboot]

That's the bitfield item's size field, not its default value.


Am Fr., 3. Nov. 2017 um 04:56 Uhr schrieb Thierry Laurion <
thierry.laur...@gmail.com>:

> As I understand the code, KGPE-d16 doesn't use AGESA part (nor any?).
>
> Any reason why this value would be defaulting to enabled for whole sb700
> dependents?
>
> --- a/src/vendorcode/amd/cimx/sb700/SBTYPE.h
> +++ b/src/vendorcode/amd/cimx/sb700/SBTYPE.h
> @@ -133,7 +133,7 @@ typedef struct _AMDSBCFG
>  UINT32  SataPortMultCap :1; //6, 0:OFF   1:ON
>  UINT32  SataReserved:2; //8:7, Reserved
>  UINT32  SataClkAutoOff  :1; //9, AutoClockOff
> for IDE modes 0:Disabled, 1:Enabled
> -UINT32  SataIdeCombinedMode :1; //10,
> SataIDECombinedMode 0:Disabled, 1:Enabled
> +UINT32  SataIdeCombinedMode :0; //10,
> SataIDECombinedMode 0:Disabled, 1:Enabled
>  UINT32  SataIdeCombMdPriSecOpt:1;   //11, Combined
> Mode, SATA as primary or secondary 0:primary 1:secondary
>  UINT32  SataReserved1   :6; //17:12, Not used
> currently
>  UINT32  SataEspPort :6; //23:18 SATA port
> is external accessiable on a signal only connector (eSATA:)
>
>
> Le jeu. 2 nov. 2017 à 09:33, Peter Stuge  a écrit :
>
>> Thierry Laurion wrote:
>> > ENABLE_IDE_COMBINED_MODE available for sp800 but not for sp700, for
>> ewhich
>> > sp5100 is derived from:
>> ..
>> > Suggested Workaround
>> > Disable combined mode by setting a platform BIOS callback option to CIMx
>> > called "SataIdeCombinedMode" to 0.
>> ..
>> > Is there something i'm missing? Is it possible to disable combined
>> > sata mode for sb700 from coreboot?
>>
>> SB700 mainboard support seems copypasted rather than engineered. The
>> sustainable solution is to move sb700_cfg.c from src/mainboard/*/
>> to src/southbridge/amd/cimx/sb700/ and hook the configuration in that
>> file into Kconfig.
>>
>> Until someone does that, you could indeed change the assignment of
>> that option by looking for
>>
>> SataIdeCombinedMode
>>
>> in the source code, if a sb700_cimx_config() function is called for
>> this board - but that might not be the case if the board port chose
>> not to use that part of AGESA.
>>
>>
>> //Peter
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problem with tianocore compilation in coreboot-sdk:1.50

[Patrick Georgi via coreboot]

Am Mi., 4. Apr. 2018 um 18:10 Uhr schrieb Aaron Durbin via coreboot <
coreboot@coreboot.org>:

> > Agree, but coreboot use old commit from edk2. Is it fine to push
> vUDK2018?
>
> I guess? I'm not really sure who uses edk2. I guess tianocore payload?
> Patrick is on holiday right now, but he would probably the best person
> to answer that.
>
It's used for the tianocore payload, indeed.
And yes, updating to a newer commit is fine.


> > I believe coreboot should stick to edk2 releases not to random commits
> > in the tree.
>
That sounds like a reasonable guideline.
However if a release isn't fit for use as a coreboot payload, I'd go for
(not so) random commits that fix problems rather than stick to another
project's schedule and keep things broken.

> Can anyone tell what tests were made against tianocore payload? There
> > are patches in payload/external/tianocore/patches and I'm not sure
> > against what hardware those should be validated.
>
The payload integration stuff is provided on a best-effort basis, so right
now "it builds and it boots on one system" is good enough.
If you want to support the default payload selection for your board(s),
I'll appreciate your effort, and we could tighten up the policy around it
(so that you, and others who volunteer to test, would have to sign off on
updates that might affect their supported systems).
Ideally we'd have automated hardware testing, but that's a sore point for
years now. :-(


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Problem with tianocore compilation in coreboot-sdk:1.50

[Patrick Georgi via coreboot]

Am Fr., 6. Apr. 2018 um 17:15 Uhr schrieb Piotr Król :

> Can you tell what is this "one system"?
>
Sorry, "any one system" - just the system that the developer who last
touched the payload integration happened to test with.

As said, there's little rigor around the payload integration. All
professional deployments I know use separately built payload binaries.
And as said, if you want to take this on, we can certainly tighten up the
rules going forward.


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

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

[Patrick Georgi via coreboot]

taii...@gmx.com  schrieb am Sa., 7. Apr. 2018, 14:39:

> that doesn't mean boards that people
> know are functional should be removed from coreboot just because.
>
> I highly doubt these policies happen in a vacuum.

That particular policy was created because we consider it worse to pretend
that we support boards on master that are untested for a long time just to
inflate numbers and to keep personal pet projects around long after their
due date.

The simple solution is to show every now and then that the board still
boots with master (and fix up issues). Which is exactly what we ask for.

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

[coreboot] ANN: "corporate" group on gerrit

[Patrick Georgi via coreboot]

Hi everybody,

yesterday I created a user group "corporate" on review.coreboot.org and
added all people who I assume are paid for working on coreboot (based on
their email address domains).

Corporate contributions tend to be high volume and there are usually
multiple people interested in getting them through review, so they're
typically well-covered with regard to review activity.
At the same time due to these properties they risk drowning out individual
contributions which are often smaller and by developers without large teams
supporting them: Simple by the number of commits and the amount of
activity, corporate contributions tend to fill up the first page of commits
in gerrit (which is sorted by activity), pushing other contributions into
the back catalog.

Using the group as a filter
https://review.coreboot.org/q/is:open+-ownerin:corporate provides a view of
just the changes that might otherwise be overlooked. If you want you can
add it as a shortcut to Gerrit's menu at
https://review.coreboot.org/settings/#Menu (entries defined here appear in
the "Your" menu)

The group isn't perfect (there are some folks still missing, and I'm still
tuning my scripts to help with automatic group maintenance), but I hope
it's already a helpful tool for increasing visibility of non-corporate
community members' contributions.


Regards,
Patrick Georgi
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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

[coreboot] Proposing a change to Coding Style

[Patrick Georgi via coreboot]

Hi everybody,

after just running into an issue on the EC code base, I hereby propose that
going forward, we should always wrap conditional blocks in braces, even
one-liners.
That is:

if (foo) {
   bar();
}

instead of

if (foo)
   bar();

It doesn't hurt too much but saves us from accidentally adding baz() after
bar(), forgetting to add the - now required - braces. If we get rough
consensus over this, I'd change Coding_Style to match.


Thoughts?
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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

[coreboot] Who is still using a 1980's tty for coreboot development?

[Patrick Georgi via coreboot]

That is, who would unbearably suffer from 132 characters per line of code?


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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

Re: [coreboot] Who is still using a 1980's tty for coreboot development?

[Patrick Georgi via coreboot]

Am Fr., 25. Mai 2018 um 17:05 Uhr schrieb Vadim Bendebury <
vben...@chromium.org>:
> limiting width to 80 columns helps greatly when one wants to see several
screens side by side.

$ echo $COLUMNS
274

Two terminals of 120 + metadata (linenumbers, window frames, ...) fit well,
and that's just a plain old Full HD display.
I heard 4K is all the rage now ;-)

> And of course implicitly keeps the code cleaner - if so much indentation
is needed, the code is likely ripe for refactoring.
Several of our function signatures are longer than a line.

Two levels of indentation (function level + if clause), plus
'printk(BIOS_ERROR, "\n");' is already more than half an 80 column screen.
Breaking up messages means that they're harder to find with a git grep.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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

Re: [coreboot] Who is still using a 1980's tty for coreboot development?

[Patrick Georgi via coreboot]

Am Fr., 25. Mai 2018 um 18:40 Uhr schrieb Nico Huber :
>   o Set a hard limit around 100 chars (96 would be a nice number).
>   o If a line doesn't contain a string literal, recommend a
> visible width <= 72 chars.
As Sam noted, it's hard to find tooling for that.
But even with 96 characters clang-format's output looks much better
than with 80.

One thing your transfer of the 72 char rule from continuous text to
code doesn't take into account is that in code, individual lines often
stand on their own. Consider the following block:

/* this function will fill the corresponding manufacturer */
void smbios_fill_dimm_manufacturer_from_id(uint16_t mod_id,
   struct smbios_type17 *t)
{
   switch (mod_id) {
   case 0x2c80:
   t->manufacturer = smbios_add_string(t->eos,
   "Crucial");
   break;

You'd never set a chapter in a book like this except maybe as an art
project (that I'd decline to read).
It's more readable after collapsing both the header and the add_string
call to a single line each (two "carriage returns" in the middle of a
statement less), despite passing the 72/80 character limit - except if
you're on an old-fashioned terminal where part of the line is missing
because it's too long now.

If people write chapters full of documentation in comments, by all
means, let's limit that to a 72 character width (plus indentation for
"/* ").
Code formatters generally leave comments alone if they can help it, so
that requires a different tool if we want to enforce it.


Patrick

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

Re: [coreboot] Problem in building the toolchain with gcc-8.1

[Patrick Georgi via coreboot]

We're currently working on upgrading our toolchain to gcc 8.1. Feel
free to try out https://review.coreboot.org/c/coreboot/+/25997


Regards,
Patrick
Am Di., 5. Juni 2018 um 13:00 Uhr schrieb Akendo :
>
> Hello everyone,
>
> I currently having a problem build the toolchain from a freshly checkout
> coreboot repository. I've tried to build with different options: For
> example with all platforms and only with i386 support. Multi core
> (CPUS=4) and with a single core. Here an example build:
>
> Building toolchain using 1 thread(s).
>
> Target architecture is i386-elf
>
> Found compatible Ada compiler, enabling Ada support by default.
>
> Downloading and verifing tarballs ...
>  * gmp-6.1.2.tar.xz (cached)... hash verified
> (9dc6981197a7d92f339192eea974f5eca48fcffe)
>
>  * mpfr-3.1.5.tar.xz (cached)... hash verified
> (c0fab77c6da4cb710c81cc04092fb9bea11a9403)
>
>  * mpc-1.0.3.tar.gz (cached)... hash verified
> (b8be66396c726fdc36ebb0f692ed8a8cca3bcc66)
>
>  * binutils-2.29.1.tar.xz (cached)... hash verified
> (172244a349d07ec205c39c0321cbc354c125e78e)
>
>  * gcc-6.3.0.tar.bz2 (cached)... hash verified
> (928ab552666ee08eed645ff20ceb49d139205dea)
>
> Downloaded tarballs ... ok
> Unpacking and patching ...
>  * gmp-6.1.2.tar.xz
>o gmp-6.1.2_freebsd-configure.patch
>  * mpfr-3.1.5.tar.xz
>  * mpc-1.0.3.tar.gz
>  * binutils-2.29.1.tar.xz
>o binutils-2.29.1_mips-gold.patch
>o binutils-2.29.1_no-bfd-doc.patch
>  * gcc-6.3.0.tar.bz2
>o gcc-6.3.0_ada-musl_workaround.patch
>o gcc-6.3.0_ada-raise.patch
>o gcc-6.3.0_elf_biarch.patch
>o gcc-6.3.0_gnat.patch
>o gcc-6.3.0_libgcc.patch
>o gcc-6.3.0_memmodel.patch
>o gcc-6.3.0_nds32_ite.patch
>o gcc-6.3.0_no-p-var.patch
>o gcc-6.3.0_pointer_integer.patch
>o gcc-6.3.0_riscv.patch
> Unpacked and patched ... ok
> Building packages ...
> Building GMP v6.1.2 for host ... ok
> Building MPFR v3.1.5 for host ... ok
> Building MPC v1.0.3 for host ... ok
> Building BINUTILS v2.29.1 for target ... ok
> Building GCC v6.3.0 for target ... failed. Check
> 'build-i386-elf-GCC/build.log'.
>
> make[3]: *** [Makefile:26: build_gcc] Error 1
> make[2]: *** [Makefile:48: build-i386] Error 2
> make[1]: *** [Makefile:16: all_without_gdb] Error 2
> make: *** [util/crossgcc/Makefile.inc:37: crossgcc] Error 2
>
>
>
> I also tried to do this with clang, with similar result.
>
> Here is the log from clang:
>
> [ 52%] Building CXX object
> projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.x86_64.dir/sanitizer_stoptheworld_linux_libcdep.cc.o
>
> /home/akendo/src/coreboot/util/crossgcc/llvm-4.0.0.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:
> In function 'int __s$
> nitizer::TracerThread(void*)':
> /home/akendo/src/coreboot/util/crossgcc/llvm-4.0.0.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:278:22:
> error: aggreg$
> te 'sigaltstack handler_stack' has incomplete type and cannot be defined
>struct sigaltstack handler_stack;
>   ^
> make[2]: ***
> [projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.x86_64.dir/build.make:255:
> projects/compiler-rt/lib/sanitizer_common/$
> MakeFiles/RTSanitizerCommonLibc.x86_64.dir/sanitizer_stoptheworld_linux_libcdep.cc.o]
> Error 1
> make[1]: *** [CMakeFiles/Makefile2:14006:
> projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.x86_64.dir/all]
> Error 2
> make: *** [Makefile:152: all] Error 2
> ./buildgcc: line 840: cd:
> /home/akendo/src/coreboot/util/crossgcc/xgcc/lib/clang/4.0.0/lib: No
> such file or directory
>
>
>
>
> A look into the build log from GCC seems to disclose a similar error:
>
> make[1]: Nothing to be done for 'all'.
> make[1]: Leaving directory
> '/home/akendo/src/coreboot/util/crossgcc/build-i386-elf-GCC/libdecnumber'
> make[1]: Entering directory
> '/home/akendo/src/coreboot/util/crossgcc/build-i386-elf-GCC/fixincludes'
> make[1]: Nothing to be done for 'all'.
> make[1]: Leaving directory
> '/home/akendo/src/coreboot/util/crossgcc/build-i386-elf-GCC/fixincludes'
> make[1]: Entering directory
> '/home/akendo/src/coreboot/util/crossgcc/build-i386-elf-GCC/gcc'
> gnatgcc -c -O2  -fomit-frame-pointer -m64   -gnatpg -gnatwG  -W -Wall
> -nostdinc -I- -I. -Iada/generated -Iada -I../../gcc-6.3.0/gcc/ada
> -I../../gcc-6.3.0/gcc/ada/gcc-interface
> ../../gcc-6.3.0/gcc/ada/aspects.adb -o ada/aspects.o
> aspects.adb:38:29: warning: use clause for package "HTable" has no effect
> make[1]: *** [../../gcc-6.3.0/gcc/ada/gcc-interface/Make-lang.in:119:
> ada/aspects.o] Error 1
> make[1]: Leaving directory
> '/home/akendo/src/coreboot/util/crossgcc/build-i386-elf-GCC/gcc'
> make: *** [Makefile:4108: all-gcc] Error 2
> /bin/sh ../gcc-6.3.0/mkinstalldirs
> /home/akendo/src/coreboot/util/crossgcc/xgcc
> /home/akendo/src/coreboot/util/crossgcc/xgcc
> /bin/sh: line 3: cd: i386-elf/libgcc: No such file or directory
> make: *** [Makef

[coreboot] ANN: release notes are now maintained in Documentation/release

[Patrick Georgi via coreboot]

Hi everybody,

Martin pasted the release notes into coreboot.git's Documentation
folder and also added a stub for coreboot 4.9.

Since the volume of coreboot changes increased a lot in the last few
years, it's infeasible to create release notes after the fact by
looking at the commits since last release.

When you add noteworthy changes, please add a commit to your patch
train that extends the upcoming release notes. Use your own words,
provide some background - right now, it's mostly a list of bullet
points, but it doesn't need to be.
I'm quite sure that we'll manage to develop a common voice for the
release notes as well for all other documentation.

New chipsets and mainboards can be automatically covered by scripts
that extract the information, so they don't _need_ such a manual
description. These automated entries will be rather bland though, so
if you want to see context, feel free to add something for them as
well.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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

Re: [coreboot] wiki backup

[Patrick Georgi via coreboot]

Leah Rowe  schrieb am Di., 12. Juni 2018, 20:16:

> Now that the wiki is being retired, is there a backup of the wiki
> (database, files etc) so that someone else can host it elsewhere? For
> archival purposes.
>

Various formats are available at https://www.coreboot.org/wikidump
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Patrick Georgi via coreboot]

Merlin Büge  schrieb am Do., 14. Juni 2018, 19:30:

> I just want to mention:
> Generally, helping out with documentation and (especially) code review
> and even ordinary users who report bugs are also a value-add to the
> coreboot project.
>
Indeed. Not necessarily when it comes deciding about the maintenance of
code that they never touched, ran, documented or tested though.


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

Re: [coreboot] Fixing gitweb links on coreboot.org

[Patrick Georgi via coreboot]

Hi Julius,

sorry for the late response. I setup forwarders so these links resolve
to the right location.
As an aside, an entrypoint to cgit that already worked is the commit
ID in the CL view of gerrit (eg. "595e777" on
https://review.coreboot.org/1).


Patrick
Am Fr., 22. Juni 2018 um 00:29 Uhr schrieb Julius Werner :
>
> Hi coreboot.org admins,
>
> For a while now (probably since we switched to the PolyGerrit UI?),
> the gitweb links on pages like
> https://review.coreboot.org/admin/projects and
> https://review.coreboot.org/admin/projects/coreboot,branches have been
> broken. They link to pages like
> https://review.coreboot.org/admin/gitweb?p=coreboot.git;a=summary
> which just says "Server Error: gitweb" and hangs.
>
> Instead, we have a perfectly working Cgit implementation at
> https://review.coreboot.org/cgit/coreboot.git, but you can't find it
> unless you happen to know the URL or switch back to the old UI.
> There's not even a link to it on the coreboot.org landing page or
> https://coreboot.org/developers.html.
>
> Can we fix this to make it more discoverable and get rid of the broken
> links in Gerrit? It keeps tripping me up every time I'm trying to link
> anyone to coreboot sources...



-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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

Re: [coreboot] Kaby Lake FSP

[Patrick Georgi via coreboot]

Nate, thank you for getting these things out and for the public update!

Could you please ask the lawyers if they consider 2.1 (b) and (c) of the
license sufficient for unmodified redistribution (eg in the coreboot blobs
repo: paths change, the files remain unmodified)? It seems like that should
be possible, but since I'm just a software developer and they're the
lawyers who wrote the license they ought to know.
That would make it easier to create FSP based configurations that build out
of the box with the coreboot tree.

Thanks,
Patrick

Am Mi., 11. Juli 2018 um 03:06 Uhr schrieb Desimone, Nathaniel L <
nathaniel.l.desim...@intel.com>:

> Hi All,
>
> I am a UEFI firmware architect working for Intel Corp. One of my focus
> areas is FSP. There was some prior discussion here regarding the lack of
> public updates for Kaby Lake FSP binaries and headers and questions
> regarding specialized FSP binaries being built for specific boards. I would
> like to clear up some of these questions and concerns. We just pushed all
> of the recently released versions of Kaby Lake FSP (3.1.0 through 3.6.0) to
> https://github.com/IntelFsp/FSP/tree/Kabylake. While there might appear
> to be forks of Kaby Lake FSP, they are actually just snapshots at different
> points in time. For example, there is one commit labelled as "Gold release
> for Kaby Lake FSP" that appears to be special fork for IoT devices... this
> commit is actually just Kaby Lake FSP Release 2.6.0 without any IoT
> specific modifications. Apologies for the confusing commit messages and for
> the temporary lapse in updates.
>
> With Best Regards,
>
> Nate
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coffee Lake FSP Released

[Patrick Georgi via coreboot]

Hi Nate,

thank you for the announcement and for reworking the repository layout.
That helps a lot!

Since there are several FSP users that'd feel way more comfortable relying
on this if there's a way to enable it be mirrored somewhere else and not
rely on GitHub infrastructure, is there anything that can be done to
improve in that area? (ie. get redistribution rights into the license since
these binaries are rather public already)

Thanks,
Patrick

Am Mi., 22. Aug. 2018 um 21:36 Uhr schrieb Desimone, Nathaniel L <
nathaniel.l.desim...@intel.com>:

> Hi All,
>
> Intel is pleased to announce that Coffee Lake FSP is now available on
> https://github.com/IntelFsp/FSP. In addition, the previously discussed
> reorganization to move all FSP binaries in the master branch has been
> completed.
>
> With Best Regards,
>
> Nate
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Downloading an archive of the coreboot wiki

[Patrick Georgi via coreboot]

Am Sa., 15. Sep. 2018 um 16:10 Uhr schrieb taii...@gmx.com :

> Would this be the best way to do it? [...]

wget -r -k -np -p -l 0 http://coreboot.com/wiki

Maybe not. See https://www.coreboot.org/wikidump/ for more suitable formats.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] UEFI Payload update

[Patrick Georgi via coreboot]

Regarding the (off-topic) discussion of slimboot's merits: I share some of
the sentiment, but it's certainly possible to phrase it a less
confrontational way. We can moderate individuals on this list, so if you
can't watch your words, I will.


Regards,
Patrick


Am Di., 18. Sep. 2018 um 11:56 Uhr schrieb Ivan Ivanov :

> Slim Bootloader? Thanks, but
> " We wanted the open source Intel ME / FSP firmwares, and all we got
> is this lousy byproduct of Not-Invented-Here syndrome "
> /thread
> вт, 18 сент. 2018 г. в 5:18, You, Benjamin :
> >
> > Hi,
> >
> > A staging project "UEFIPayload" has been started to upgrade the
> Coreboot*Pkgs in EDK II repository.
> >
> > The new features are:
> > - Supporting Slim Bootloader (https://github.com/slimbootloader) in
> addition to Coreboot
> > - Source file configuration using .ini format
> > - User extension using simple "C" libs
> > - Platform supporting lib
> >
> > The link of this project is:
> https://github.com/tianocore/edk2-staging/tree/UEFIPayload
> >
> > Thanks,
> >
> > - ben
> >
> >
> > --
> > coreboot mailing list: coreboot@coreboot.org
> > https://mail.coreboot.org/mailman/listinfo/coreboot
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot



-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Downloading an archive of the coreboot wiki

[Patrick Georgi via coreboot]

They were made on the day that I marked the wiki read-only, after I marked
it read-only. After that, nothing changed (see
https://coreboot.org/index.php?title=Special:RecentChanges&limit=10&days=3
)

So yes, they're as new as the wiki can get and they should all be identical
(modulo potentially export failures)


Patrick

Am Do., 27. Sep. 2018 um 22:45 Uhr schrieb taii...@gmx.com :

> On 09/15/2018 10:11 AM, Patrick Georgi wrote:
> > Am Sa., 15. Sep. 2018 um 16:10 Uhr schrieb taii...@gmx.com <
> taii...@gmx.com
> >> :
> >
> >> Would this be the best way to do it? [...]
> >
> > wget -r -k -np -p -l 0 http://coreboot.com/wiki
> >
> > Maybe not. See https://www.coreboot.org/wikidump/ for more suitable
> formats.
> >
> >
> > Patrick
> >
>
> Thanks, but are those new? The date says june 2018.
>
> And are they are all identical?
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Is this fake news or not? Bloomberg says China is using a rice-sized chip to hack amazon servers.

[Patrick Georgi via coreboot]

I could think of a few approaches to backdoor a system by having a very
tiny chip connect to a select set of traces.

But generally speaking: that discussion is rather off topic for this
mailing list.
Please look for some more suitable venue to discuss "people potentially
tampering other people's devices (with no obvious connection to coreboot)".


Patrick

Am Do., 4. Okt. 2018 um 18:02 Uhr schrieb fightfakenews via coreboot <
coreboot@coreboot.org>:

> I came across this news today. Bloomberg says China is using a rice-sized
> chip to hack amazon servers. They published videos and photos here:
>
> https://twitter.com/business/status/1047788207557865473
>
> https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies
>
> They publish very limited evidence, so it leads me questioning whether the
> report is true. As a worker in China's hardware industry, I'm very
> concerned with this report. Is this true or just another fake news
> deliberately created to escalate the trade war between US and China?
>
> They did not mention the product name. But they published a gif image,
> then I did a little research to compare Supermicro's Microblade severs with
> the one in this gif file. It seems the product is the MBI-6128R-T2
> https://www.supermicro.com/products/MicroBlade/module/MBI-6128R-T2.cfm
>
> This board has dual socket R3 (LGA 2011) that supports Intel® Xeon®
> processor E5-2600 v4†/ v3 family. So the processor is likely to be an intel
> one. So this board may support Intel's strict security features like
> BootGuard and Intel ME. These security features are so strong that even the
> top hackers in the open source community haven't fully cracked...
>
> The only techinical information they give is: The chips could do all this
> because they were connected to the baseboard management controller, a kind
> of superchip that administrators use to remotely log in to problematic
> servers, giving them access to the most sensitive code even on machines
> that have crashed or are turned off. (It sounds like something related with
> the IPMI? Is this really can be done? Even this can be done, can this be
> used to access data?)
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot



-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] IMB-A180 Real Time Clock is 20-30% slow (coreboot only, not original AMI BIOS)

[Patrick Georgi via coreboot]

Hi Mark,

First, Linux rarely uses the real time clock - use the 'hwclock' tool to
query it repeatedly and compare that against your stop watch to figure out
if RTC is involved.

If it isn't: Linux keeps its own system clock which is only once
synchronized against RTC. I don't know off-hand what Linux uses to
determine time progression, but I know that it believes whatever is in the
ACPI about cpu frequency scaling. Maybe some values are off, and the CPU is
clocked lower in some modes than Linux thinks it is, or moving to higher
CPU clocks has no effect (I think I saw that on one board due to
insufficient ACPI data).
To my knowledge, the linux system clock can be fed from different sources -
so it's also possible that with AMI, ACPI (or similar tables) enable a
different set of clock sources than coreboot, showing different behaviour.
The kernel's log messages should tell you.


Patrick

Mark C. Mason via coreboot  schrieb am Tue Nov 04
2014 at 01:21:49:

>
> We are working with both vanilla Coreboot and Sage's BSP version of
> Coreboot,
> and we stumbled upon the fact that the system clock is running 20-30% slow.
>
> This does not occur when booting from the original AMI BIOS.
> We are running both CentOS 6.4 and Ubuntu 14.04 versions of Linux.
>
> To reproduce, run "sleep 10" and time it with a stopwatch.  Our timings
> indicate about 12.2 seconds when booting from either vanilla or Sage BSP
> Coreboot.
>
> I've searched the Coreboot mailing list archives (and google), but I
> don't see anything.
>
> Does anyone know anything about this?  I'll start looking at the code,
> but any help
> will be greatly appreciated.
>
>
> Best regards,
>
> Mark Mason
> Engineering Design Team
>
>
> --
> 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

Re: [coreboot] Unifying IO accessor macros

[Patrick Georgi via coreboot]

2015-02-18 17:23 GMT+01:00 Vadim Bendebury :
>> kernel, u-boot, etc. They all have the write(val, addr) semantics. I
>> see no good reason to artificially erect an ever present barrier for
>> integrating code into a coreboot system.
>>
Since all imported code requires some rework before it works for us,
and redoing that particular issue is a matter of a simple spatch
(http://coccinelle.lip6.fr/), I'm not sure that's actually that big a
concern.

@@
expression a,v;
@@
-writel(v,a)
+write32(a, v)


Patrick
-- 
Google Germany GmbH
ABC-Str. 19
20354 Hamburg

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

Re: [coreboot] Unifying IO accessor macros

[Patrick Georgi via coreboot]

2015-02-18 18:35 GMT+01:00 Aaron Durbin via coreboot :
> coreboot is different than:
> 1. linux
> 2. uboot
And similar to Solaris, Windows and the BSDs.
As for libpayload, I'd rather import code from BSD than Linux for
licensing reasons.

> 3. libpayload
> 4. Anything using libpayload
Which could be fixed (since some changes are necessary in any case)


Patrick
-- 
Google Germany GmbH
ABC-Str. 19
20354 Hamburg

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

Re: [coreboot] Automated test system: Nominations wanted

[Patrick Georgi via coreboot]

2015-02-19 0:14 GMT+01:00 Carl-Daniel Hailfinger
:
> 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)
http://blogs.coreboot.org/blog/author/ayushsagar/ documents last
year's GSoC project to implement some of those - incl. a screen test
using the display present signals.

Through external flashing, there's also no need to handle unbricking manually.


Patrick
-- 
Google Germany GmbH
ABC-Str. 19
20354 Hamburg

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

Re: [coreboot] Automated test system: Nominations wanted

[Patrick Georgi via coreboot]

2015-02-19 17:22 GMT+01:00 Kevin O'Connor :
> It would be a bit of work to get the software working and packaged
> nicely - but if it was, I think it could enable many more users to
> participate in automated tests and remote development.
That already was the hope of many coreboot related automated testing
projects before.
Wiring up some hardware isn't the problem.


Patrick
-- 
Google Germany GmbH
ABC-Str. 19
20354 Hamburg

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

Re: [coreboot] New interface for I2C in coreboot

[Patrick Georgi via coreboot]

2015-02-19 21:12 GMT+01:00 Peter Stuge :
>> I think the question is really what we would gain from this.
>
> I think it's less about performance and more about an accurate and
> clean model being available to mainboard code when needed.
From discussing things with Werner, one of his concerns (as I
understood them) was higher stability in light of picky I2C devices:
When you schedule the entire communication in one pass, the
(sufficiently capable) controller makes sure that things happen in the
right order and at the right time. If some of that is arbitrated by
CPU code, there's more room for error.

Even for the I2C controllers that essentially bitbang things with no
help by the controller chip, that should help avoid mistakes, since
all the nasty warts of I2C (of which were seem to be many) are managed
in the bus driver, not in every single slave driver.


Patrick
-- 
Google Germany GmbH
ABC-Str. 19
20354 Hamburg

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

Re: [coreboot] Coreboot reproducible builds

[Patrick Georgi via coreboot]

2015-02-26 16:23 GMT+01:00 Emilian Bold :
> It seems that Coreboot doesn't have reproducible builds yet.
You're right, it doesn't. One of the major items is probably to
replace the current build time stamps with something more reasonable.
For example, the current commit's time stamp (unless the tree is
dirty, in which reproducability is impossible).

> I think Coreboot should adopt this concept.
Patches accepted.

>
> It seems like we are halfway there with INCLUDE_CONFIG_FILE but what I've
> noticed is that even if I extract the CONFIG_ values the build still needs
> some manual tweaking.
>
> Ideally we should record the tools used (crossgcc version, etc), the
We do.

> coreboot git revision id,
We do.

> the CONFIG_ values and the build info for the
We optionally do.

> payloads (for the auto-downloaded SeaBIOS I think just the git revision id
> would be enough).
Payloads are more intricate. I'd stick with the coreboot parts, that
is, a coreboot build without adding a payload is bit-identical. Then
do the same for the payload (we can add meta-data to cbfs files or
store payload information in a separate cbfs file).

> Is there anyone willing to help me with this (or already working on this)?
Like Peter I'm happy to review changesets on gerrit.


Patrick
-- 
Google Germany GmbH
ABC-Str. 19
20354 Hamburg

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

Re: [coreboot] Building ARM toolchain fails with `cc1: fatal error: .vis: No such file or directory`

[Patrick Georgi via coreboot]

2015-02-26 21:56 GMT+01:00 Aaron Durbin :
> I reproduced the error. I was trying to figure out how to debug it. I
> entered into the util/crossgcc/build-armv7-a-eabi-gcc directory and
> typed make. Everything worked... I'm trying again. I'm not really sure
> why one way would fail and the other not.
Interesting.

Paul, could you try executing buildgcc manually (not through a make rule)?
If that works, there's some make environment stuff that survives and
breaks things.


Patrick
-- 
Google Germany GmbH
ABC-Str. 19
20354 Hamburg

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

Re: [coreboot] Long license headers (ANGER WARNING)

[Patrick Georgi via coreboot]

2015-03-04 14:58 GMT+01:00 Peter Stuge :
> I haven't gotten the impression that anyone is suggesting to remove
> or even change any copyright notices.
>
> Copyright documents authorship (like git does too) but says nothing
> about licensing terms.
Section 1 of the GPLv2 contains: "keep intact all the notices that
refer to this License".
I'm not a lawyer or I'd have more interesting things to do than to
argue on mailing lists, but that doesn't look quite as clear cut to
me.


Patrick
-- 
Google Germany GmbH
ABC-Str. 19
20354 Hamburg

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

Re: [coreboot] Long license headers (ANGER WARNING)

[Patrick Georgi via coreboot]

2015-03-04 18:32 GMT+01:00 ron minnich :
> Peter, per Patrick's note here, and discussions I've had with people who
> actually are real lawyers, who earn their money doing IP licensing, I think
> you are quite wrong. We should not change the license text in the files
> *unless it is done in consultation with the copyright holders*.
There are things we can do, before "perfect" kills "good" again:
Decide how we want it done in the future, and formalize that
somewhere. Then let existing copyright holders decide if they want to
go for the new format (they're easy to find: they're listed right in
the headers we're debating), and let them do it (they are allowed to,
after all).


Patrick
-- 
Google Germany GmbH
ABC-Str. 19
20354 Hamburg

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

Re: [coreboot] questions about google/samus

[Patrick Georgi via coreboot]

Hi all,

I put the mailing list under emergency moderation for a while because
things heated up quickly. This wasn't coordinated with anyone, so
please direct complaints about that at me.

All incoming emails (to this thread = all of them) in that period were
rejected with an explanation (I hope these ended up with the authors,
we don't use that mechanism very often), and their authors can resend
them if they feel that the mails add value while keeping the flames
low.

There are tons of fun (and some not so fun) stories about interactions
with silicon vendors, some of them involving various degrees of binary
only modules. But I think they're better told in person over some
beverage of choice (eg. at the meet-ups we want to do in summer?)
rather than on an impersonal medium like a mailing list - especially
because it's such a frustrating issue.


Patrick (speaking only for myself)

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

Re: [coreboot] [Rangeley C2000] Can't step when in romstage main function of MohonPeak

[Patrick Georgi via coreboot]

Hi Hook Guo,

2015-03-27 11:11 GMT+01:00 郭佳 :
> At the time this main function has been called, the Cache as RAM has been 
> setup
> by FSP, and the MTRR_PHYSBASE0 is FEF0_0006.

> BTW: (1) Using the debugger's memory window, I can see Cache as RAM region of
> temporary stack are full of A5 5A, is it the correct case?

For FSP related questions you should ask your Intel developer
relations contact or sales representative.
FSP isn't open source, and so we can't help you since we have no idea
what it does either, and even if people knew, there also isn't a lot
of interest within the coreboot community to provide free support for
components like these.


Thank you for your understanding,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

[coreboot] License headers

[Patrick Georgi via coreboot]

Hi,

we had some fun discussion a while back about the license headers we
use in our tree. Asking legal experts, they proposed we go for keeping
the usual GPL license header intact, only stripping the FSF address
(which gave the most churn on licenses in our tree, and as you can see
in the commit below, we didn't even do a good job on keeping those
current, or uniform).

The rationale is that there are tools and work flows that expect
license markers to be in some kind of 'normal form', and that's the
one that exists for the GPL.

Just like they typically have no opinion about firmware development
matters (although lawyers are a weird bunch, some even write great
graphics card drivers!), I have little to say about their opinion on
license matters, so my proposal is to follow expert advice.

http://review.coreboot.org/#/c/9233/ is my work in progress towards
that goal. It's not complete yet, and I'd love to have some automated
verification in our 'lint' tool set to make sure that no FSF addresses
creep in once we exorcised them.

I deliberately kept util/kconfig as-is to keep changes compared to its
upstream to a minimum.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

[coreboot] server maintenance: review.coreboot.org will be down on 2015-04-09 morning CEST

[Patrick Georgi via coreboot]

Hi,

I'll do some maintenance on our code review site tomorrow morning
(CEST). There's not really a schedule, but it will be quicker than
last time.

I plan to integrate an authentication module to support Google
accounts for authentication beyond April 20th when Google retires the
protocol we currently use. I will report to the mailing list when I'm
done.

Note: The change will require some work by affected users (1 minute
per account) to migrate the authentication information and retain
access. I'll post instructions when the system is ready.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

[coreboot] Server maintenance done. Action Required for users that authenticate with Google accounts

[Patrick Georgi via coreboot]

Hi,

gerrit maintenance is done, the site is back to normal.
What changed: Besides the current OpenID configuration, it's now also
possible to log in with OAuth. This change is necessary because Google
will retire the OpenID authentication scheme for their users this
month.

I also considered adding GitHub as authentication provider but held
off because it's not yet possible to link OAuth credentials to
existing accounts, a bug in the authentication provider we're using
(and I'm trying to avoid duplicate accounts)
GitHub as authentication provider will be added as soon as the
remaining issue on the server is sorted out.


To retain access with a Google based account after April 19th (or so,
timezones are complicated), some work is required. Even though the
instructions are very detailed, it's a really quick process, so do it
now!

1. Log out of review.coreboot.org (top right of the screen)
2. Log in again, select 'Google OAuth2 (gerrit-oauth-provider-plugin)'
3. Google will ask you if you want to grant 'coreboot' some limited
access to your account. Acknowledge that
4. After the login is done, go to
http://review.coreboot.org/#/settings/web-identities
4a. You should see a line 'Google Account' for the email address you
used as identifier, and another line with the same email address and a
long number is 'identity'.
5. If there are more Google Accounts in that list for which there
isn't another line with a numerical identifier, repeat the process for
them.


After the switch-over at Google, this automatic linking of accounts
may or may not stop to work (I have no idea).
If you notice that you end up with a new account
(http://review.coreboot.org/#/dashboard/self empty when it shouldn't
be), contact me ASAP so I can link the accounts on the server side
before the new account sees lots of activity.
Since that's additional work for you and me, please try to avoid it :-)


Thanks,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

Re: [coreboot] force https on review.coreboot.org

[Patrick Georgi via coreboot]

2015-04-16 15:57 GMT+02:00 Alexander Couzens :
> than let us change to StartSSL or someother SSL authority.
I'll ask CNNIC. I heard they have good offers.

> PPS. Please write a +1 if you're supporting this opinion.
Please don't.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

[coreboot] Gerrit access rules

[Patrick Georgi via coreboot]

Hi,

after deliberation to encourage positive feedback, gerrit rules are
changed so that 'reviewers' can now give +2 Code-Reviews.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

Re: [coreboot] Zako coreboot serial output does not insert 'return caret'

[Patrick Georgi via coreboot]

2015-04-21 7:35 GMT+02:00 Anatol Pomozov :
> I use google's servo to deploy FW to the board and I see a weird debug log
> in my console. The log from coreboot looks like newline is inserted, but
> return caret is not. SeaBIOS debug looks normal. Here and the log example
> https://gist.github.com/anatol/8e30c8d5045ddf7e6b03
http://review.coreboot.org/#/c/8857/ changed the output format from
ASCII to UNIX.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

Re: [coreboot] QEMU x86_64 Q35 Automated Test Failure

[Patrick Georgi via coreboot]

2015-04-21 17:31 GMT+02:00 Gregg Levine :
> 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

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

[coreboot] Reviving flag days

[Patrick Georgi via coreboot]

Hi,

some of you might remember the flag days initiative, which led to some
useful information on how to keep up with upstream development while
maintaining local branches (or repos). If you don't, please look at
the marvel that is
http://coreboot.org/index.php?title=Flag_Days&oldid=10718

The short story is that for each change that required sweeping
changes, eg. a new function call that certain drivers need to
implement, a new argument to a function, or a Kconfig variable that is
retired a short blurb was written so developers could follow up.
Where practical, these could contain coccinelle patches, reducing work
for fellow developers even more.

With the switch to git, we dropped the habit.

Do we want to reestablish that routine?

A rule of thumb is that there's a flag day if a mainboard or chipset
that was copied out of the tree before your commit and submitted after
your commit needs to be adapted due to your change.

That sounds contrived, but it's actually quite common: people copy the
code for a mainboard similar to what they're working on, hack on it
for a while, then try to upstream. Chances are that there are changes
to the original mainboard code to follow up on.

My proposal on implementation is to integrate flag day docs with git:
let's create the convention that such changes come with documentation
in documentation/flagdays/, maybe keyed to the author's email address
to avoid conflicts, and some description, for example
documentation/flagdays/pgeo...@google.com-rename-console.h-to-textout.h.md
(I don't actually want to do that rename, calm down :-) ).

From there, a server side script can determine the commit date (which
is the effective date for when the change was submitted) and commit
id, and create a wiki page from those files.
Since I still hope that we eventually get rid of the wiki, I propose
to use plain text (.txt suffix) or markdown (.md suffix) as 'neutral'
formats. pandoc can make this into wiki syntax (or pretty much
everything else) with ease.
The same script could be used locally to generate the documentation as
well (ie. it resides somewhere below util/).
To allow for post-hoc additions of flag days, there should also be a
way to declare a commit id within the doc (eg. first line stating:
commit-id: 1a2b3c4)

If we go with this proposal (or some variant thereof), I'll take care
of the scripting and automation to generate the doc. It would be our
collective responsibility to remember when to write such docs, or to
request them to be added during review where needed.


Thoughts?
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

[coreboot] gerrit authentication

[Patrick Georgi via coreboot]

Hi,

To provide more options to contributors, it's now possible to login to
our code review system at http://review.coreboot.org using GitHub
credentials. On the login screen, simply pick 'GitHub OAuth2'.

If you already have an account, you can link your GitHub account to it
by logging in on gerrit, clicking 'Link Another Identity' on
http://review.coreboot.org/#/settings/web-identities, and selecting
GitHub OAuth2 (and acknowleding on GitHub that you want to associate
your account with coreboot code review).

Of course, OpenID still works, as does logging in using Google
Accounts through OAuth2.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

Re: [coreboot] error building coreboot

[Patrick Georgi via coreboot]

2015-04-28 8:42 GMT+02:00  :
> after running "make" im getting the following error and the building process
> is stopped:
> -
> /coreboot/util/cbfstool/cbfs_image.c:451:59: error: comparison between
> signed and unsigned integer expressions [-Werror=sign-compare]
>   assert((char*)CBFS_SUBHEADER(entry) - image->buffer.data ==
>^
> cc1: all warnings being treated as errors
> make: *** [build/util/cbfstool/cbfs_image.o] Fehler 1
> -
>
> any ideas what is causing this error and how to fix it?
You're probably building on a 32bit host system, which isn't a
well-tested environment (our autobuilders are 64bit as are, it seems,
most developer machines).
http://review.coreboot.org/#/c/10015/ should fix the issue.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

Re: [coreboot] coreboot ported to the ASUS KGPE-D16 (Libreboot: blobless, fully functional!)

[Patrick Georgi via coreboot]

2015-05-03 23:12 GMT+02:00 Emilian Bold :
> I'm curious, is there some Coreboot Foundation that would gather this money
> and purchase the copyright or would Raptor just somehow crowd-fund this
> money to license their work as GPLv2 while keeping the copyright?
With coreboot there's no organization and no copyright assignment.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

Re: [coreboot] QEMU build failure in master

[Patrick Georgi via coreboot]

2015-05-05 21:49 GMT+02:00 Timothy Pearson :
> While working on the test system earlier today I noticed that QEMU builds
> are currently failing with the following error:
>
> coreboot/src/lib/timestamp.c:184: undefined reference to
> `timer_monotonic_get'
>
> Builds using the same configuration were working yesterday.  The KFSN4-DRE
> does not appear to be affected at this time.
Regarding build failures we should be covered (at least for default
configurations).
When looking at http://qa.coreboot.org/job/coreboot/, I don't see this error.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

Re: [coreboot] [poll] device_t

[Patrick Georgi via coreboot]

2015-05-07 22:00 GMT+02:00 Stefan Reinauer :
> With our current bootblock concept, it is never going away on x86 (for
> bootblock usage)
Which isn't that much of a problem once we provide separate headers
for x86 bootblock code. There's really very tiny overlap.
That could then be reused to deal with raminit on romcc-boards, too:
from coreboot's point of view, raminit is just an overly large
piece of cache-as-ram code, followed by a raminit noop.
This is simplified by the lack of the need for development tools (eg
printk) to develop new non-car x86 raminits.


One of these days...
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

Re: [coreboot] [poll] device_t

[Patrick Georgi via coreboot]

2015-05-08 17:31 GMT+02:00 Aaron Durbin :
> In romstage *both* struct device and device_t are present but are
> completely different types. It's the romstage, ramstage, and smm
> overlap that is large and extremely annoying to deal with.
History time:
Until not too long ago, bootblock and romstage used u32 device_t,
ramstage used struct device, smm didn't really matter and nothing else
existed.
This was further enforced by struct device being available in ramstage
_only_. We now have a read-only view of the device tree available in
romstage that makes things look more complicated.

One of the ideas that led to the devicetree in romstage was to make
struct device the default interface where possible, together with the
aforementioned isolation of romcc based code. Essentially: for romcc,
use u32. For everything else, struct device.

We may want to determine first what data structure we want to use in
each stage. This could be 'u32 for all hardware accesses, with some
struct device -> u32 conversion to move from devicetree to hardware',
which sounds like what you propose (and is completely contrary to that
other idea).
But until there's a consensus on that, I guess it's too early to
discuss the fate of device_t.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

Re: [coreboot] x230 - vgabios

[Patrick Georgi via coreboot]

2015-05-23 1:06 GMT+02:00 Michael Gerlach :
> GET_VBIOS: 7b46 3714 8b a2 e9

> printk(BIOS_DEBUG, "GET_VBIOS: %x %x %x %x %x\n",
> oprom->signature, pcir->vendor, pcir->classcode[0],
> pcir->classcode[1], pcir->classcode[2]);
>
> But Signature should be 0x55aa:
Just to double check: did you add the vgabios with or without
compression? coreboot only supports uncompressed vgabios images (while
seabios allows them compressed as well, if the name matches)


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

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

[coreboot] Re: Intel CBnT tooling and dealing with NDA

[Patrick Georgi via coreboot]

Am Di., 9. Feb. 2021 um 11:34 Uhr schrieb Arthur Heymans <
arthur.heym...@9elements.com>:

> So TL;DR:
> - Is (temporarily) adding a tool to the blobs repo ok?
>
If it matches the requirements of the blobs repo wrt. license terms and
documentation, I don't see why not from a formal perspective.
It's telling though (in the sense of a Freudian slip) that you put the
"temporarily" in parentheses already: interim solutions like these tend to
survive their best due date ;-)


> - Is integrating an (optional) not yet open tool into the build system ok?
>
This one is IMHO the bigger issue: that tool will only run on
Linux/x86(-64?), and probably only with a select set of libc
implementations. While we have portability issues every now and then,
they're always accidentally introduced because our testing isn't good
enough while adding this to the build flow deliberately makes all other
platforms second tier build hosts.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Mailing list moderation

[Patrick Georgi via coreboot]

Hi everybody,

As we're encountering a spam campaign right now by a sufficiently motivated
actor to get through our filters I put the mailing list on moderation until
this silliness subsides.

For this reason delivery of mails sent to this list may be delayed.

Thanks for your patience,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Mailing list issues, update

[Patrick Georgi via coreboot]

Hi everybody,

There have been some issues with the mailing lists hosted at coreboot.org
(spanning multiple projects: coreboot, flashrom, seabios and openbios)
related to configuration changes in response to our precious little
spammer. As a result some people have seen mailing list delivery to them
disabled due to bounces. I reversed that change for the affected users so
everybody's back in.

To avoid this type of issue going forward, the server manual has been
revised to point out some pitfalls in the mail server configuration and how
to avoid them.


Again thank you for your patience,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Regarding GSoC 2020

[Patrick Georgi via coreboot]

Hi Vedant,

coreboot has applied to this year's GSoC but GSoC still has to decide on
the projects they want to host: That will be announced on March 9.


Patrick

Am Sa., 20. Feb. 2021 um 07:40 Uhr schrieb :

> Hi, I am interested to apply to gsoc2020, is coreboot going to apply in
> gsoc 2021?
>
> Regards,
> Vedant Paranjape
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: GSoC query

[Patrick Georgi via coreboot]

Hi Hritik Vijay,

we applied to GSoC but they will only announce the projects that will
participate this year on March 9.


Regards,
Patrick

Am Fr., 19. Feb. 2021 um 09:52 Uhr schrieb Hritik Vijay via coreboot <
coreboot@coreboot.org>:

> Hi
> Coreboot appeared last year in the GSoC initiative, I wanted to know if
> there are plans to appear again?
>
>
> From the terminal
> Hritik Vijay
>
> Sent with ProtonMail  Secure Email.
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Regarding GSoC 2020

[Patrick Georgi via coreboot]

Am Mo., 22. Feb. 2021 um 12:31 Uhr schrieb Vedant Paranjape <
vedantparanjape160...@gmail.com>:

> Thanks for the update. I joined coreboot IRC, it doesn't seem active. Any
> other communication channel to lookout for?
>
The channel is reasonably active for a medium size project like coreboot,
but activity differs _a lot_ depending on weekday and time.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel CBnT tooling and dealing with NDA

[Patrick Georgi via coreboot]

Hi Enrico,

(list to bcc)

not speaking about the technical difficulties you face with golang or the
general topic of blob use here, just one thing:

Don't post conspiracy theories here. Well, two things: We also do not
punching here (except for cards, maybe, if we're in the mood for some retro
computing.)

It took me some deliberation whether or not to moderate you, but I also
didn't want to deal with the (very realistic risk of you) whining that
you're being censored. You're not: Later messages with such content will
drop out of the moderation queue without further comment, but you still
have an entire Internet (minus coreboot.org) at your disposal to try to
disseminate your world view.

Am Di., 23. Feb. 2021 um 20:38 Uhr schrieb Enrico Weigelt, metux IT consult
:

> that already devastated several major

cities in the US last year and also stormed into the US capitol ?

I really don't like to have anything to do with those people. ]
>

If you're really worried about being associated (even several times remote)
with organizations that are (or may be) responsible for devastation of
cities, I have really bad news for you:

coreboot, originally LinuxBIOS, was initially funded by the US DoE through
LANL (https://www.coreboot.org/FAQ#Who_is_funding_coreboot.3F) of which
Wikipedia (https://en.wikipedia.org/wiki/Los_Alamos_National_Laboratory)
has this to say: "initially organized during World War II for the design of
nuclear weapons as part of the Manhattan Project". There are few
organizations that can lay claim to "devastation of major cities" to the
degree that they can.

It was later kept alive through projects indirectly (and maybe directly)
paid for by the German government, with purposes - among others - like
controlling Patriot ground-to-air missiles (the laptop seen at
https://youtu.be/0RfPSXL6yLw?t=67 looks like a Roda RK8 series device and
probably runs coreboot). I'm trying to put it mildly, but Patriot isn't
typically used for home improvement.

Nowadays the support of companies like Google, Facebook and Amazon is
elemental in keeping coreboot usable on current platforms (even if there
are caveats with those platforms). Some people claim that these companies
devastate societies and economies: Under the loose-association philosophy
that you seem to live by, some brick & mortar store owners (the backbone of
inner city living infrastructure) might have a word or two to say about you
being affiliated with a project that is used by Amazon. Some people in San
Francisco (a major US city) are rather unhappy about Google and Facebook as
well, due to a perception that there's some negative impact of their
headquarter on cost of living in the area. (And if this section contains a
larger amount of weasel words than usual note that I'm not trying to take a
position here, just present a point of view)

Therefore if you don't like to have anything to do with people who
devastate cities, you better look elsewhere (and given that Free Software
and Open Source licensing in general forbids "field of endeavour" clauses
you'll have a hard time living that philosophy anywhere in the FLOSS
ecosystem)


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Announcing our new job board

[Patrick Georgi via coreboot]

Hi everybody,

In our leadership meetings we repeatedly had companies using coreboot look
for qualified staff. In response this created a job site at coreboot.org,
linked prominently from our landing page, accessible at
https://coreboot.org/jobs.html

So if you're looking for a coreboot related job, check out these job
postings and if you're with a company that is looking for new folks, feel
free to push a change to our homepage.git repository to add your company
there!


Best regards,
Patrick Georgi
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Running QEMU targets in Jenkins

[Patrick Georgi via coreboot]

Hi Julius,

https://qa.coreboot.org/job/coreboot-boot-test/ sends off ToT builds to
9esec's Lava system where they are run on some virtual and real devices.
See for example the comments to
https://review.coreboot.org/c/coreboot/+/51189 where Lava reports passing
on 5 qemu configs and 3 real devices.


Regards,
Patrick

Am Do., 4. März 2021 um 02:42 Uhr schrieb Julius Werner <
jwer...@chromium.org>:

> I'm just curious... have we ever considered booting some of our QEMU
> targets as part of the Jenkins CI? I know they don't do a lot but they
> do cover some stuff (e.g. CBFS). I randomly happened to boot one of my
> in-flight patch trains on qemu-i440fx recently and discovered that I
> accidentally broke rmodule loading. Would be nice if Jenkins could
> just do that for you automatically.
>
> Just wanted to know whether this had been discussed before and people
> have come up with good reasons not to do it, or if it's just a matter
> of nobody had time to implement it yet. (And if someone wanted to
> implement it, what would be the best hook point? Put it into abuild?)
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Kann keinen Thread eröffnen

[Patrick Georgi via coreboot]

Dear Mr. Kunze,

Am Di., 16. März 2021 um 17:43 Uhr schrieb web25322986p1 <
gottfried.ku...@fanfara.de>:

> Trotz Anmeldung bei der Mailiglist (bin eingeloggt) kann ich jedoch keinen 
> Thread beginnen. Ich erhalte stets:
>  *Error 404 not found.
> *
>
> We disabled the mail editor in hyperkitty due to spammers abusing that
interface (ruining it for everybody). Since hyperkitty has no "official"
way of doing that, we routed the editor into a 404 error.

(by the way, the mailing list language is English)


Best regards,
Patrick Georgi
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Posting via web interface doesn't work (was: Kann keinen Thread eröffnen)

[Patrick Georgi via coreboot]

Am Do., 18. März 2021 um 04:04 Uhr schrieb Tobias Wiese <
tob...@tobiaswiese.com>:

> Actually since HyperKitty Version 1.3.4 the HYPERKITTY_ALLOW_WEB_POSTING
> setting should do that.
> This might prevent further confusion for others.
>
The last time I looked that didn't exist yet, but I disabled the web editor
"properly" now.


Thanks for the heads up!
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] coding style discussions, again.

[Patrick Georgi via coreboot]

Hello everybody,

https://review.coreboot.org/c/coreboot/+/51825 proposes getting rid of the
rule to make if-statement blocks (and the like) as short as possible.
The rationale is to encourage a style that avoids subtle bugs which then
need to be found by tooling such as Coverity Scan and fixed by commits like
https://review.coreboot.org/51786.

Julius disagrees and requests wider discussion, specifically on the mailing
list.
So here we are: Arguments? Opinions?

Julius, maybe you want to make your case, I didn't want to risk
representing a distorted position.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] On handling vendorcode

[Patrick Georgi via coreboot]

Hi everybody,

We recently landed a change (https://review.coreboot.org/51827) to be more
selective which parts of src/vendorcode are checked for coding style
because some areas are really coreboot code "by vendors".

The original purpose of that subhierarchy was to isolate code we draw in
from the outside to make every dev aware that the file they're touching has
some upstream other than coreboot and that this code shouldn't be modified
except to track that upstream.

Any objections to moving the code out there that has no other upstream
(e.g. src/vendorcode/google/chromeos or src/vendorcode/eltan, I think?)
while moving in code from elsewhere in the tree that fits the "it has a
foreign upstream" description (e.g. the lzma library)?


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: On handling vendorcode

[Patrick Georgi via coreboot]

Am Di., 6. Apr. 2021 um 21:21 Uhr schrieb Peter Stuge :

> Patrick Georgi via coreboot wrote:
> > Any objections to moving the code out there that has no other upstream
> > (e.g. src/vendorcode/google/chromeos or src/vendorcode/eltan, I think?)
> > while moving in code from elsewhere in the tree that fits the "it has a
> > foreign upstream" description (e.g. the lzma library)?
>
> I think that can make sense, but where would the chromeos, eltan and
> other directories go instead? Someplace existing, or someplace new?
>
I first wanted to make sure that there are no major issues with the overall
idea, but to further the discussion:

- src/vendorcode/eltan/security -> src/security/mboot
- src/vendorcode/google/chromeos is a mixed bag: some src/drivers/tpm/cr50,
some src/lib (e.g. elog, vpd), some src/acpi/chromeos (acpi*)

I'm not sure about Siemens' hwilib: if that's imported, it remains there,
if this version is written for coreboot, src/drivers/siemens perhaps?

The other things look to be "real" vendorcode, even if we're probably the
last codebase by now that still ships (our versions of) amd/agesa.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: On handling vendorcode

[Patrick Georgi via coreboot]

Am Mi., 7. Apr. 2021 um 01:12 Uhr schrieb Julius Werner <
jwer...@chromium.org>:

> I think we still need to have a difference between hacky vendor stuff
> and normal coreboot code. For example, the Eltan mboot stuff is
> something we didn't really want to have in coreboot in that form, and
> so they kinda put it in vendorcode as a compromise. We should make
> sure it remains clear that that code isn't "proper" coreboot code and
> didn't go through the same level of review.
>
It might have started that way, but I don't think that's an accurate
portrayal of eltan's work at this point:
The eltan code uses vboot for the cryptographic primitives these days and
as far as I can see, extends it for measured boot - which vboot itself
doesn't do, ever.

Also, regarding your point on gerrit (collecting arguments in this thread)
that we don't have duplicate things, look no further than graphics init:
- src/device/oprom/realmode
- src/device/oprom/yabel
- src/drivers/intel/gma
- FSP can do the graphics init, too (and report it in cbtables)

(I didn't count the native ARM graphics init routines because we don't ship
alternatives for those)


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [RFC] How should we manage tree-wide changes?

[Patrick Georgi via coreboot]

Hi everybody,

In our leadership meeting[1] we discussed how we should deal with tree-wide
changes (ranging from "new file header" to "some API is gone now"). The
concern was that right now, anything can change at any time, making local
development harder.

There have been a few ideas but nothing definite yet:

One idea was to declare some interfaces (e.g. those used by
src/mainboards/**), with varying stability horizons (e.g. "only change
right after a release"), or backward compatibility guarantees (although the
details still seemed hazy on how that could work in practice.)

Another idea brought up was to require that such changes come with
documentation and, ideally, migration support in the form of scripts and
the like. We had something like this in the past[2] and I created a
proposal[3] to establish it as a rule and build a culture around
documenting sweeping changes.

One doesn't exclude the other, and there may be other approaches on how to
make development easier without calcifying our codebase. Or maybe people
don't see a problem that needs fixing?

In any case, I wanted to bring it up in a larger forum to make sure that we
find rough consensus across the community before a decision is made on how
to proceed here.


Regards,
Patrick

[1] minutes at
https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit#heading=h.9hutkekd50uf
[2]
http://web.archive.org/web/20130315025026/http://www.coreboot.org/Flag_Days
[3] https://review.coreboot.org/c/coreboot/+/52576
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Intent to release coreboot 4.14 on May 10

[Patrick Georgi via coreboot]

Hi everybody,

This email starts the release process for coreboot 4.14, so we're now at
the "~2 weeks prior to release" step in our
https://doc.coreboot.org/releases/checklist.html

As usual, our releases don't denote any particular feature or stability
milestone, they only serve two purposes:
1. Avoid the impression that coreboot is dead - an idea that actually came
up before we started doing time-based releases
2. Provide anchor points that downstream coreboot users can use to base
their work against if they wish to do so

What everybody can do: Consider testing the devices you have against our
current master branch, send in board-status reports so boards are
known-good in https://coreboot.org/status/board-status.html, report or,
even better, fix issues you encounter.

As a developer, please consider if your large scale tree change can wait
for after the release so that the tree can settle down a bit. But also, if
you have large changes that are waiting (such as toolchain updates), you
could already start to bring them in shape to merge after the release!

Also, please check out the release notes in Documentation/releases/
coreboot-4.14-relnotes.md to see if any notable work of the last 6 months
is missing there. Addition and deletion of mainboards and SoCs will be
added shortly before the release with script assistance, but everything
else won't be. Patches to extend our release notes are appreciated!

Thanks y'all for making coreboot what it is now. As a release manager I'll
merely put another label on it :-)


Best regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [RFC] How should we manage tree-wide changes?

[Patrick Georgi via coreboot]

Am Do., 22. Apr. 2021 um 22:58 Uhr schrieb Peter Stuge :

> Patrick Georgi via coreboot wrote:
> > tree-wide changes
> ..
> > there may be other approaches on how to make development easier
>
> I'm a big fan of semantic patching as provided by coccinelle and used
> heavily in Linux kernel development.
>
> Perhaps one way to make lives easier is to require tree-wide changes
> to be the result of an spatch, which can then be applied downstream too?
>
I proposed that in https://review.coreboot.org/c/coreboot/+/52576 already
because I'm also a fan of this idea.

That said, both in the meeting and in Nico's sibling comment there have
been concerns on putting additional burden on developers (although,
personally, I'd rather review a CL that is created by a tool + a simple
rule set than a tree-wide refactoring made by hand...)


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Dropping the "cbfs master header" file

[Patrick Georgi via coreboot]

Hi Arthur,

The master header is a legacy thing and I'm in favor of removing it. That
said, as you and Michal mentioned, there's some work to do first. I started
https://ticket.coreboot.org/issues/306 to help track what's missing.


Patrick


Am Mi., 28. Apr. 2021 um 08:42 Uhr schrieb Arthur Heymans <
art...@aheymans.xyz>:

> Hi
>
> Currently the "COREBOOT" FMAP cbfs region has a file named "cbfs master
> header" at the bottom of this fmap region and the X86 bootblock has a
> pointer at 0xFFFC to it. Other ARCH have a "header pointer" file at the
> top of that FMAP region pointing to it.
>
> Currently this file is only used as an anchor point to use cbfs with
> walkcbfs_asm on X86 to access cbfs in assembly (before any C code). There
> are 2 uses for this at the moment:
> 1) updating microcode on Intel systems that don't feature FIT before
> setting up CAR
> 2) finding FSP-T (if FSP_CAR is used) before jumping to it
> Both the cbfstool and the C coreboot code don't rely on it anymore, so it
> is a legacy feature. Other cbfs FMAP region like FW_MAIN_A/B in a VBOOT
> setup don't feature it.
>
> Accessing cbfs with walkcbfs_asm breaks hardware based root of trust
> security mechanisms like Intel bootguard/TXT/CBnT, because no verification
> or measurement whatsoever happens on either " cbfs master header" of
> "fsp-t" files. So for instance even if TXT/Bootguard measured or verified
> FSP-T as an IBB so that it is trusted, an attacker could insert a new cbfs
> file with the same name, "fsp-t" at a lower address and coreboot will run
> it anyway.  So a static pointer to fsp-t is required. Sidenote/Rant: FSP-T
> continuously causes such integration problems... Blobs that set up the
> execution environment are just a very bad idea.
>
> So I propose to drop the legacy "cbfs master header" file and adapt the 2
> current use cases in the following way:
> - Reuse the Intel FIT table and implement FIT microcode updates in
> assembly/software. (I had this working on some point, before I decided to
> use walkcbfs_asm)
> - Either fix the location of FSP-T via for instance a Kconfig option or
> add a pointer to "fsp-t" at a fixed location in the bootblock and have the
> tooling update the pointer during the build process. I think the Kconfig
> option is the least amount of work and cbfstool is already overloaded with
> options and flags, so my preference goes to this.
>
> Let me know what you think.
>
> Kind regards
>
> Arthur Heymans
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [RFC] How should we manage tree-wide changes?

[Patrick Georgi via coreboot]

Am Do., 6. Mai 2021 um 14:03 Uhr schrieb Piotr Król :

> If 3mdeb maintains some boards, we already testing those and would be
> glad to hook, in secure way, to patch testing system, but I would like
> to know where is interface documentation so I can evaluate cost of
> integration and convince customers to go that path. This was expressed
> many times in various communication channels (conferences, slack).
>
We're at the ~5th or so public test infrastructure project by now and it's
still not nailed down.
Part of it is that it's simply a hard problem.

Another problem is that whoever pulls this off needs to be in the very
narrow intersection of having time (i.e. not a product driven coreboot
developer) and having money and a few other resources (i.e. not a
hobbyist), so they can run enough of the infrastructure by themselves that
others who could hook into the infrastructure see the benefit.

I think it can be expensive to go all-in in that direction, but if we
> could go in that direction it would be great.
>
If you want to maintain any particular release as a long term branch,
announce your intent and we'll set up a branch!


> Question is why coreboot change so dramatically in all mentioned areas?
> Does projects with similar lifetime also change in so significant way?
>
One reason is that we're dealing with the guts of an industry that is
changing around us _very_ quickly.
But I disagree that we're changing dramatically: on the contrary, we're
pretty careful about remaining compatible in various important ways for
long stretches of time to help everybody move at their own pace.

Some examples off the top of my head:
- We used to compile out strings for log levels we didn't print for space
reasons. Space is now no concern and there's the cbmem console, so we leave
everything in for better debugging. The remnants of the "compile out"
approach, gone for ~10 years, have only been removed within the last two
months.
- We used to have CBFS with a master header that defined "off limit"
regions at the start and end of flash. That's fine as long as you don't
regularly write to flash (where you risk blasting away parts of the CBFS
structure), but these days we do write to flash, sadly, so there's now a
partitioning scheme (fmap), making the master header obsolete. The header
is still around, SeaBIOS still can't read FMAP.
- We added per-file metadata to CBFS in a compatible way even though the
structure is a bit more complicated than it could have been if we hadn't
cared about compatibility.
- The "read/write registers" code had to change because C compilers like to
tighten up their rules around aliasing and volatile types and stuff like
that. So we rewrite our macros into functions, with proper types, just so
that a newer compiler doesn't break our entire code base.
- All that vboot/mboot/bootguard security stuff just was not a thing when
coreboot started. It brought in tons of complexity: more flash
partitioning, more boot stages, just "tons more code", more memory
management (for example, we now have some funky "free last two malloced
objects" free() implementation. We got by without free() for 15 years)
- Thunderbolt (and USB4) have some pretty arcane requirements on
configuration buses. Originally LinuxBoot was supposed to set up only the
bare minimum to jump into a kernel. With TBT/USB4 you can forget about that.
- More and more external complexity brought in: IOMMUs seem to add a new
data structure with every chip generation, ACPI is getting ever more
complex (and we can't opt out of that madness or OSes won't boot), ...

So everything changes around us, sometimes in unexpected ways: compilers,
interfaces, hardware. It would be a miracle if we didn't have to change to
go along with that.

The main reason why you notice that with coreboot but not other firmware is
that ancient-UEFI never gets uprevved (and while other firmware, like
u-boot, collects firmware build support in their main repo, in products
they're still used mostly in a copy&forget model). I just turned down a
couple of older (non-coreboot) firmware build processes because they rely
on python 2. They're dead, while coreboot isn't.

The main reason why it's slightly less painful with Linux (but ask any
out-of-tree module maintainer!) is that chip vendors provide open source
code for Linux and maintain it whenever they raise the complexity bar a
notch or two, and compiler vendors (gcc, clang) are coordinating against
Linux (while they usually don't really care about coreboot).

tl;dr: All things considered, we're a pretty small project punching _way_
above our weight, working sometimes against the interests of other parties
in the ecosystem who'd prefer to keep things closed that we open. Since (at
this time) we can't offload the pain to those who inflict it on us the way
Linux is doing, we'll have to bear it.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesells

[coreboot] Releasing coreboot 4.14 (on Monday)

[Patrick Georgi via coreboot]

Hi everybody,

I still plan to do the coreboot release on Monday (or, if things are really
bad, on Tuesday), even though I'm somewhat behind on our checklist.
This means we are at the
https://doc.coreboot.org/releases/checklist.html#week-prior-to-release
stage.

Therefore, if you have hardware and the ability to flash and recover,
please test our current code on it, and report back if there are problems.
If you think a feature you worked on since 4.13 was released deserves a
shout-out in our release notes and it isn't already there, create a change
that adds it to Documentation/releases/coreboot-4.14-relnotes.md


Thanks,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [RFC] How should we manage tree-wide changes?

[Patrick Georgi via coreboot]

Am Sa., 8. Mai 2021 um 03:08 Uhr schrieb Julius Werner :

> I understand that you might like to have both [features and stability] but
> I think that's just fundamentally impossible -- big new features just tend
> to require deep, invasive changes.

+1


> I think we could encourage that, I don't think it's really something
> you can make a hard requirement. spatches just don't work well for all
> kinds of API changes. Starting this as a sort of "experiment" like you
> suggested to see how it goes sounds like a good idea.
>
This is why my proposed documentation change (
https://review.coreboot.org/c/coreboot/+/52576/1/Documentation/getting_started/gerrit_guidelines.md#335)
states:
"Providing a script or a [coccinelle](
https://coccinelle.gitlabpages.inria.fr/website/) semantic patch to
automate this step is extra helpful, so consider doing that if possible."

The only "shall do" request is that there's _some_ documentation about what
has been going on, and that can be as short as "commit abc replaced
foo(a,b) with bar(b,a)."

Do I need to emphasize the "if possible" part some more?


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org