[coreboot] Re: There is a python in our toolchain?!?

[Stefan Reinauer]

On Wed, Sep 29, 2021 at 7:44 AM Jack Rosenthal  wrote:

> Overall I think introducing Python to the build would provide net benefit,
> mainly from Kconfiglib, but could also find other good uses in e2e tests
> like Ricardo was working on. Most people's Linux distros ship with a Python
> interpreter too, so most developers would be unlikely to notice the extra
> dependency introduction.
>
> In terms of Kconfiglib, we have a lot to gain by switching away from the
> Linux C implementation of Kconfig, mainly the ~30kloc of C code that we've
> forked from the Linux tree and hacked in our own customizations
> (KCONFIG_NEGATIVES). With Kconfiglib, these customizations get turned into
> a miniature Python script
> 
> that we use to handle our custom header format, and a stable API to work
> off of so that we can uprev Kconfiglib without needing to change our
> scripts.
>

Looking at the current Kconfiglib implementation we would be replacing the
C code with 21873 lines of Python code that is now taking the code to
deviate from what the Linux kernel is doing. I am having a hard time seeing
a "net benefit" in this scenario. Given the mess that Python 2 to Python 3
conversion has been (and still is), this is just inviting a lot of trouble
into what has been a fairly stable part of coreboot for the last decade.

In terms of Kconfiglib's stability and track record: I think it has it
> covered. We adopted Kconfiglib in both Zephyr OS and in Depthcharge already
> without any issues at all.
>

I am failing to see how anybody involved in coreboot would sign up for and
commit to porting 20k lines of Python code to the next version, when it
arrives. My indication is that not even the python code that is currently
in the tree has been ported to python3 yet.


> At a minimum, I think we should consider introducing Python on an optional
> basis (i.e., the C Kconfig implementation only gets used if a Python
> interpreter is unavailable), but making it required would be even better.
>

Come on, we do not need two types of Kconfig parsers in the tree. Let's
focus coreboot on actually booting cores, not collections of
implementations in different programming languages. There are better
projects for that, such as https://github.com/mame/quine-relay

What coreboot problems that we have seen in the past are we actually
solving with these rewrites?

Stefan


>
> On Wed, Sep 29, 2021 at 5:39 AM Rao G  wrote:
>
>> Hi Patrick,
>>
>> That's good to hear, would there be change to "make menuconfig" with
>> kconfiglib
>>
>
> No, we'd make it so that all the "make *config" commands run the
> Kconfiglib alternatives without any user action required.
>
> The "menuconfig" interface in specific is very similar to the
> lxdialog-based interface that the C Kconfig uses, except it's a bit more
> polished and refined feeling.
>
>
>>
>> Thanks
>> Ranga
>>
>> On Wed, Sep 29, 2021 at 10:58 AM Patrick Georgi via coreboot <
>> coreboot@coreboot.org> wrote:
>>
>>> Hi everybody,
>>>
>>> Historically, coreboot avoided depending on python too much (we got rid
>>> of an entire python based configuration and build system, for example),
>>> with few minor exceptions.
>>>
>>> The main reason has been that while python code is quick to slap
>>> together, it has demonstrated a penchant for breaking in all kinds of
>>> mysterious ways (python 2->3 really was just a slightly bigger instance of
>>> what's going on in python all the time), and its users demonstrate a
>>> disregard for their fellow developers as demonstrated by endless stack
>>> traces on trivial errors (or is the language too complicated to properly
>>> catch them all?)
>>>
>>> While probably nice for one-off prototypes, long term maintenance is a
>>> concern: this project has over 20 years of history under its belt, with
>>> more to come.
>>>
>>> That said, python makes its way back into the tree every now and then
>>> (typically as small snippets to compute and add hashes to binaries as
>>> needed by ARM SoCs). Uncanny, but typically not a big deal.
>>>
>>> There are two bigger initiatives proposed that would significantly
>>> increase our python footprint:
>>> 1. Replacing Linux's kconfig with kconfiglib (
>>> https://review.coreboot.org/c/coreboot/+/48679)
>>> 2. Using pytest for end-to-end testing utilities (
>>> https://review.coreboot.org/c/coreboot/+/57869)
>>>
>>> Compared to the "inject a hash value at a fixed location" scripts, these
>>> would probably be here to stay, and sufficiently integrated that everybody
>>> will have to deal with them.
>>>
>>> People spending time working on python code when it has no chance to
>>> land isn't a good use of their time and we should avoid that in the project.
>>>
>>> People spending time arguing that python shouldn't be used (to avoid
>>> the other outcome) even though the project's culture shifted and is now
>>> accepting Python isn't creating a grea

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

[Stefan Reinauer]

On Tue, May 25, 2021 at 6:01 AM Patrick Georgi via coreboot <
coreboot@coreboot.org> wrote:

> Hi everybody,
>
> you might have heard that freenode.org recently changed management under
> weird circumstances. Given that we use their services for our project
> chat, this concerns us as well.
>
> In last week's leadership meeting we had a wide variety of opinions: To
> go for libera.chat (a network created by former freenode staff), some
> other IRC network, to leave IRC behind and go for something newer and
> Matrix and Mattermost have been brought up as examples of where this
> might lead. Of course, we could also decide to stay on freenode,
> although from what transpires that option seems less and less attractive
> every day.
>
> So, what should we do?
>

As we are present on a number of social media, I want to throw in another
option - which some folks will love, and others will hate - and that's
perfectly fine. This community has grown enough that there will never be a
one size fits all again:

Discord

It can both be accessed in a web browser or through a mobile app. I started
a "Discord Server" for us there. If you want to come check it out, join us
through https://discord.gg/JqT8NM5Zbg

 Stefan

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

[coreboot] Re: Native RAM init

[Stefan Reinauer]

Alif,

you will need the System Agent source code from Intel to produce a mrc.bin
for Cedarview. Given that the platform is from 2011, there's not much point
in spending the effort though.

Stefan

On Fri, Oct 30, 2020 at 3:21 AM Alif Ilhan  wrote:

> hello,
> Is there a way to extract mrc.bin from a normal(not chromehook rom) bios
> binary from the flash dump? There's no chromebook available with the Atom
> N2600 chip. There is one with Atom N570, but will it work? If not then I
> want to know if native ram init is supported in CedarTrail chipsets. I
> think it should be because Sandy bridge is supported and they were
> simillar(I think). CedarTail has no FSPs available on github so I must
>  have to build the non-FPS version.which means I cannot get mrc.bin.
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: What are splitted / several flash ROMs about?

[Stefan Reinauer]

Yes, this is often done as a cost reduction method. The habit started with
the arrival of the ME and the firmware descriptor allowing you to spread
your different firmware regions across one or both chips. The tool ifdtool
will help you analyze images for Intel firmware descriptors.
Sounds like in this case ME and the other regions live in the larger chip,
allowing the smaller chip to be fully used for system firmware. If that's
the case, erasing the larger chip will brick your system. Better do some
analysis first.

Stefan

On Mon, 16 Sep 2019, 04:50 Philipp Stanner,  wrote:

> Hi folks,
>
> Platforms like the x230 have two flash ROMs which are virtually treated
> as a single one.
>
> So:
>1. What the heck is the meaning of this? Why do vendors buy and solder
>   two small chips (even worse, on the x230, one with 8M and one with
>   4M) instead of a single big one? Is this cheaper? Sounds unlikely to
>   me, in technics one big thing is usually cheaper than several small
>   ones. Beyond that, I imagine you have some effort to concatenate the
>   two chips virtually.
>2. The manual for the x230 [1] (is there a version in the new
>   documentation btw?) states that you can just flash the smaller (4M)
>   chip and then you're done. So I assume:
>   1. the 4M chip is the one the CPU first executes code from
>   2. neither coreboot nor the payload will ever jump "into" the larger
>  chip, therefore code from it will not be executed.
>   3. Therefore, it does not matter if you overwrite the 8M chip or
>  not.
>
> But what lays on this larger ROM? What if there are parts of the IME on
> it I would like to annihilate?
>
> The whole thing is really awkward to me. Especially, because the
> predecessor x220 already has a place on the board ready to host the
> second chip, but it was left empty on this device.
>
> P.
>
>
> [1] https://www.coreboot.org/Board:lenovo/x230
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Does NSA contribute to Coreboot?

[Stefan Reinauer via coreboot]

Remember that the project was started by Los Alamos National Labs (LANL), the guys that also brought you the Manhattan Project.Contributions have also been made by the BSI (German version of the NSA) and their contractors.On 22 Jun 2019 21:30, Anac  wrote:Dear all,

Is it true that there's code provided by the NSA implemented in Coreboot?

https://www.tomshardware.com/news/nsa-contributes-low-level-stm-coreboot,39704.html

Any thoughts?

Cheers
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: More coding style change proposals

[Stefan Reinauer via coreboot]

On 20 Jun 2019 08:26, ron minnich  wrote:clang-format is not a textual preprocessor. It is basically the ast

builder of followed by output.



So in your case, I just tried it

main() {



  if (foo)

    bar();

    baz();

}



and got the right thing, i.e. braces around bar but not baz.
The right thing (e.g. the obviously intended thing) would be too have braces around both. clang-format in this case masks the problem and makes it harder to identify by expanding the syntax of the unwanted behavior to look intentional.Stefan


The history of reviewers looking at code is they miss this kind of

error. Constantly. I'm in favor of as much automation as we can get.



ron



On Thu, Jun 20, 2019 at 5:25 AM Nico Huber  wrote:

>

> On 20.06.19 06:01, Jacob Garber wrote:

> > On Wed, Jun 19, 2019 at 08:38:14PM -0700, ron minnich wrote:

> >> Given the number of serious problems that lack of braces causes, I

> >> like this proposal. It's indicative that both Rust and Go require the

> >> {}, for reasons of safety.

> >

> > There was a famous vulnerability in Apple's SSL code several years ago

> > because of lack of braces. clang-format can also reformat old code to have

> > mandatory braces if I'm not mistaken.

>

> What will clang-format do if it encounters?

>

> if (foo)

> bar();

> baz();

>

> a)

> if (foo) {

> bar();

> }

> baz();

>

> or b)

> if (foo) {

> bar();

> baz();

> }

>

> Will it spit out a warning? If not, this shows how dangerous automatic

> formatting can be. Because after the formatter run, it's much less ob-

> vious for the reviewer that something is wrong.

>

> Nico

___

coreboot mailing list -- coreboot@coreboot.org

To unsubscribe send an email to coreboot-le...@coreboot.org


___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Chainloading Windows from a Linux Payload

[Stefan Reinauer]

* ron minnich  [190611 07:13]:
> if you boot windows 12 would you need tianocore?

Need is a harsh word, but the simple answer to a simple question is yes,
you do.

You can use SeaBIOS, but Windows does not officially support legacy BIOS
since at least Windows 7, so whatever works today might stop working
tomorrow.

> 
> On Mon, Jun 10, 2019 at 1:44 PM Nico Huber  wrote:
> >
> > On 09.06.19 20:53, Matt B wrote:
> > > It is possible through u-root support for multiboot images [1] to 
> > > chainload
> > > grub?
> >
> > Yes, I would think so. But in case we are still on topic: It won't
> > help you to boot Windows (unless you also implement UEFI services
> > in your LinuxBoot and use a UEFI GRUB).
> >
> > To chainload something for Windows I would currently go either one of
> > these ways:
> >
> > coreboot -> LinuxBoot -> SeaBIOS   -> Windows loader
> > coreboot -> LinuxBoot -> tianocore -> Windows loader
> >
> > I think SeaBIOS already has an option to build a multiboot image. In
> > either case you could also (in theory) pack either into a bzImage and
> > feed that to kexec.
> >
> > Nico
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: coreboot leadership meeting minutes for May 8 & May 22

[Stefan Reinauer via coreboot]

Guys, it is a bit tricky to prevent discussions in a call when someone
brings up a topic, and I'm not sure that blocking that is useful. The
meetings are open and particularly people commenting here have been invited
to the calls. Please make use of that opportunity and join, if you think
that you have a strong opinion.

In this case, I made the suggestion to look at what is located in each
heater file and cone up with clear interfaces, rather than jumping into the
next "let's make coreboot source more similar to go by removing headset
file guards" discussion.



On Thu, 23 May 2019, 16:43 Julius Werner,  wrote:

> > >* We should be more strict about how we define our blocks’ APIs.
> >
> > Ok, but.. I just don't understand this proposal? Can someone explain?
>
> I second this... this sounds like another code style
> discussion/change. Can we please keep all code style discussions on
> the mailing list? Or if there really needs to be a VC meeting for such
> a discussion, can it be pre-announced so everyone interested can
> participate?
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Can't build (for g505s) with crossgcc-x64 toolchain, builds fine with crossgcc-i386

[Stefan Reinauer]

64bit builds are not supported at this time.StefanOn 15 May 2019 22:27, Mike Banon  wrote:Here's a final part of coreboot build log for crossgcc-x64 build
attempt. This does not happen while building with crossgcc-i386, so
seems to be x64-only problem.

    CC romstage/lib/stack.o
    CC romstage/lib/timestamp.o
    CC romstage/lib/version.o
    CC romstage/mainboard/lenovo/g505s/BiosCallOuts.o
    CC romstage/mainboard/lenovo/g505s/OemCustomize.o
    CC romstage/mainboard/lenovo/g505s/buildOpts.o
    CC romstage/mainboard/lenovo/g505s/romstage.o
    CC romstage/northbridge/amd/agesa/family15tn/dimmSpd.o
    CC romstage/northbridge/amd/agesa/family15tn/state_machine.o
    CC romstage/southbridge/amd/agesa/hudson/early_setup.o
    CC romstage/southbridge/amd/agesa/hudson/imc.o
    CC romstage/southbridge/amd/agesa/hudson/ramtop.o
    CC romstage/southbridge/amd/agesa/hudson/smbus.o
    CC romstage/southbridge/amd/agesa/hudson/smbus_spd.o
    CC romstage/vendorcode/amd/agesa/common/agesa-entry.o
    LINK   cbfs/fallback/romstage.debug
/home/mikeb/coreboot/util/crossgcc/xgcc/bin/x86_64-elf-ld.bfd:
build/romstage/console/vtxprintf.o: in function `number':
/home/mikeb/coreboot/src/console/vtxprintf.c:104: undefined reference
to `__udivmoddi4'
/home/mikeb/coreboot/util/crossgcc/xgcc/bin/x86_64-elf-ld.bfd:
build/romstage/lib/gcc.o: in function `__wrap___udivdi3':
/home/mikeb/coreboot/src/lib/gcc.c:33: undefined reference to `__udivdi3'
src/arch/x86/Makefile.inc:251: recipe for target
'build/cbfs/fallback/romstage.debug' failed
make: *** [build/cbfs/fallback/romstage.debug] Error 1
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Syntax highlighting screwed up (orange function parameters)?

[Stefan Reinauer]

On 29 Apr 2019 17:46, Julius Werner  wrote:> Wanna file a bug at https://bugs.chromium.org/p/gerrit/issues/list ?



Are we sure this is a general Gerrit bug? I've not seen the same thing

on the Chromium Gerrit so I'm assuming it's specific to the coreboot

installation. I've opened a coreboot bug for now

(https://ticket.coreboot.org/issues/205), if Patrick (or whoever

manages that stuff) decides it's not specific to our setup we can

still complain to Gerrit directly.
We do not have coreboot specific changes to the syntax highlighting code (e.g. this is stock Gerrit). 2.16.7 had a number of changes in their syntax highlighting though, and typically Chromium is not running on a release build but something in between releases or highly customized.Stefan
___

coreboot mailing list -- coreboot@coreboot.org

To unsubscribe send an email to coreboot-le...@coreboot.org


___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Question regarding 7th generation Intel CPUs

[Stefan Reinauer]

Hi Coins,

I'm not coreboot, but I'm a part of it, so I will try to answer your
question. CCing the coreboot mailing list for more input, as I can only
assume that that list was the intended recipient for your email.

It is unproven that Intel deliberately builds in backdoors into their
CPUs. However, a lot of their software / hardware designs create a
rather large attack surface that could be exploited, if someone puts the
right amount of resources on the problem.

This attack surface lives
 
- in the SOC's converged security management engine (CSME / ME), which
  in some SKUs enables remote access to the system through builtin
  network interfaces. The CSME cannot be fully disabled, but some
  security issues can be mitigated in a good hardware software design
  i.e. by using the non-enterprise (aka 1.5M SKU) of the ME firmware or
  by not using the SOC associated network interfaces (questionable) or
  by disabling as many CSME features as possible.
  CSME is particularly problematic because it can access main memory, so
  a remote attack could steal your private keys, rendering your
  cryptographical secrets useless.

- FSP / BLOBS. Closed source firmware pieces generally have the problem
  that they are impossible to audit. Even if there are fixed version out
  in the field, you can not tell from a binary what is fixed or not.
  Bugs are also impossible to fix, even when known. Imaginable attack
  scenarios could also be deliberate changes to memory training data
  which open known but fixed memory controller issues.

Generally coreboot tries to enable the user / developer / systembuilder
to address as many of these concerns as possible, but it can not 100%
fix them at this point. If you are concerned about your hardware
architecture, please study the source code of coreboot and the available
open documentation on x86 hardware (of which there is a fair amount) and
help us audit our code.

Stefan



* Coins  [190331 18:29]:
> Dear Coreboot,
> 
> As far as I know, Intel puts proprietary backdoors in any recent CPU they
> develop.
> 
> How does this affect the security of a PC/laptop with coreboot installed
> when it is using such a processor?
> 
> Best regards,
> 
> 
> Coins
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: mailing list changes

[stefan . reinauer]

Great work, Patrick. And thank you for spending your holidays on this special gift for all of us in the coreboot community!StefanOn Dec 25, 2018 07:40, Patrick Georgi via coreboot  wrote:Hi everybody,I took the opportunity of the slow season to make some changes to the mail server configuration: it's moved to another server and the mailing lists are now driven by mailman3 (before: mailman2) with hyperkitty as mailing list archive system (before: pipermail).I'm still importing and otherwise handling the archives, but the mailing list should work now. For you, I hope that the only impact will be that mailman3 has a new user management concept that manages users on a per-server basis and not per mailing list like mailman2 did. This means that your mailman credentials are void and you'll have to request new ones.If you notice anything odd with the mailing list, I'd appreciate a heads-up.Thanks,Patrick-- Google Germany GmbH, ABC-Str. 19, 20354 HamburgRegistergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: HamburgGeschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] Why do we have FSP-S

[Stefan Reinauer]

* Timothy Pearson  [180501 04:58]:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> All the ARM64 boards I've seen that are desktop or higher class ship
> with AMI UEFI and AMI BMC.  Plus they contain their own magic blobs,
> some akin to the ME.  ARM64 is not a panacea either;

It's certainly good to have more options.

As far as AArch64 goes... 
Google's Pixel C is ARM64 and running coreboot. All rk3399 devices, too.

Stefan


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

[Stefan Reinauer]

* Paul Menzel  [171006 09:43]:
> Dear Martin,
> 
> 
> Am Dienstag, den 03.10.2017, 08:07 -0600 schrieb Martin Roth:
> > I'd say that it doesn't make sense to require that coreboot builds
> > with anything other than the coreboot toolchain.
> > Additionally, It isn't reasonable to introduce a new requirement this
> > close to the release.
> 
> Having the code base compatible with future toolchains is quite
> important and convenient in my opinion.

And if you wish to lead this effort, patches are very welcome.

Stefan


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

Re: [coreboot] vboot/futility: Two Clang 5 warnings: address-of-packed-member and enum-conversion

[Stefan Reinauer]

Dear Paul,

* Paul Menzel  [171007 11:05]:
> Dear coreboot folks,
> 
> 
> Clang 5.0 shows the warnings below. I don’t know if Clang 4.0 also
> warns about these.
> 
> ```
> CCfirmware/lib/vboot_api_kernel.o
> firmware/lib/vboot_api_kernel.c:334:26: error: taking address of packed 
> member 'kernel_version_tpm' of class or structure
>   'VbSharedDataHeader' may result in an unaligned pointer value 
> [-Werror,-Waddress-of-packed-member]
> if (RollbackKernelRead(&shared->kernel_version_tpm)) {
> ^~
> firmware/lib/vboot_api_kernel.c:512:16: error: implicit conversion from 
> enumeration type 'enum vb2_nv_param' to different enumeration type
>   'VbNvParam' (aka 'enum VbNvParam') [-Werror,-Wenum-conversion]
> VbNvGet(&vnc, VB2_NV_DEV_BOOT_FASTBOOT_FULL_CAP,
> ~~~   ^
> 2 errors generated.
> ```

Clang is not currently supported by coreboot. However, if you wish to
contribute a patch to fix above issues, it will probably get merged.

Stefan

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

Re: [coreboot] AGESA fam15 code removals

[Stefan Reinauer]

* Martin Roth via coreboot  [171005 19:00]:
> I've got very mixed feelings about pushing the changes that we know aren't
> going to work, especially right before we abandon the boards to a branch.

We are not abandoning any boards. The whole reason we are doing branches
and not tags is that boards can be fixed on older branches after they
are no longer part of ToT.

Part of keeping coreboot flexible and fresh is to reduce the amount of
boards one has to consider for any given change. Trying to keep boards
forever was great when we had 30 boards in the tree, and Ron had all of
them. These days we add 30 boards per year or more, and 10yr old silicon
does not bring a whole lot to the table for making the latest and
greatest coreboot better. If it makes the code much worse and nobody
maintains it, it should live in a branch. Where it also does not further
decay without testing, so it really is a win win situation both for old
and new boards.

Stefan



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

Re: [coreboot] Does coreboot table still exist in F000 segment?

[Stefan Reinauer]

* WANG FEI  [171013 20:20]:
> Hi, all
> 
> Beside placing coreboot table (lb_header) in low RAM (0x0-0x1000), I remember 
> a
> copy of coreboot table should be placed at F000 segment and it can be
> controlled with a Kconfig flag, does this feature still exist? I just can't
> find it right now.

SeaBIOS will copy the coreboot table from the low segment (0x530) into
the F segment. Typically the majority of the coreboot table lives in
CBMEM at the end of memory below 4G.

Stefan


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

Re: [coreboot] Discussion about fixing dead code / ACPI TRAP

[Stefan Reinauer]

On 01-Jul-17 06:20, Patrick Rudolph wrote:

Hello community,
I'll want to start a discussion about fixing dead code.

How it all started:
I tried to run docking code on Lenovo T400 and found it's not working.
While investigation it turns out that the ACPI TRAP mechanism is being
used, and that it doesn't start the SMM handler.
The mechanism works fine on Lenovo X60 and T60 because they enable the
IO TRAP in romstage.

Fixing it:
I found that every Intel southbridge has code to support ACPI TRAP, but
doesn't enable the trap mechanism by default. The idea is to enable ACPI
TRAP in southbridge depending on a Kconfig option. The fix is here [1]

The problem:
Nico pointed out that while the fix might be technically correct, it
would touch a lot dead code. There are only a very few boards using the
mechanism.

The following questions came up:
Should dead code be "fixed" at all ?
Should the "dead" code be removed on platforms that do not use ACPI TRAP
? Developers that want to use the mechanism in the future will have to
reimplement it.
As it touches a lot "dead" code, it cannot be easily tested on some
platforms. Should patches be accepted for those platforms ?
Should we get rid of ACPI TRAP mechanism and reimplement everything in
AML only ?
Should we mark ACPI TRAP as bad and force future development to use AML
only ?



I added the ACPI TRAP code as an example on how to add ACPI traps in 
case a platform would ever need that feature.
There can be a number of scenarios where that is needed, I believe at 
the time Windows was disallowing access
of the smbus through ACPI. On platforms where smbus attached devices 
were used to control the platform, an ACPI

trap would be the only way to achieve this sort of thing.

I don't know if turning on ACPI traps can be called "fixing the code". 
It's there as an example on how to use it, but it is
disabled, because no platform seems to actually use that feature (it was 
just copy-catted around from my original i945 implementation)

But I don't think that we should remove the knowledge from the code base.

Stefan



Regards,
Patrick

References:
[1]: https://review.coreboot.org/#/c/20328/




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

Re: [coreboot] question on SMM

[Stefan Reinauer]

On 30-Jun-17 10:46, ron minnich wrote:

Thanks for the good explanations.

So I have a question for you all. We've been doing some testing of 
linux-as-ramstage. We've done a proof of concept that linux can set up 
the SMM handler at 0xa, the relocate stub at 0x38000, run the 
relocate stub, and have a working smm handler. The smm handler can 
trampoline to 64-bit mode and call the kernel, using existing 
mechanisms. So our SMM handler, in this scenario, is a set of 
functions provided by the kernel, not a binary blob. The result is a 
teeny tiny SMM handler and complete elimination of the vendor-supplied 
SMM code.


How do you do the relocation on a system where the vendor bios has 
already relocated the SMM_BASE (i.e. when not running on a machine you 
have the bios source code for)?




There are lots of benefits. The SMM is no longer at a fixed location 
-- it's kind of ASLR for SMM code; there is very little code that runs 
in SMM; and the SMM handlers we implement run in 64-bit mode with full 
memory protections. The big one for me is that persistent firmware 
blobs are reduced by one -- it's part of a goal to create an air gap 
between firmware and kernel. Another part of this work is that we're 
going to discard firmware-supplied ACPI tables and use ones supplied 
by the kernel.


SMM was never a blob on coreboot.



I realize this is not a general approach. But for small, limited 
configurations, such as OCP servers which come in a small number of 
flavors, it's quite doable.


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?


You could add the security that your bios implemented back into your 
kernel SMM handler ;-) Look at the open source SMM handler in coreboot 
for how that is done.




Thoughts on this are welcome.

ron

On Fri, Jun 30, 2017 at 6:01 AM Alexander Couzens > wrote:


On Fri, 30 Jun 2017 04:25:06 +
ron minnich mailto:rminn...@gmail.com>> wrote:

> there's something I am certain I don't understand about SMM on intel
> chipsets.
>
> The question is pretty simple. Consider a system with a recent intel
> chipset and flash. Is there some special secret sauce that disables
> writing to flash unless in SMM and if so, what is it?

There is also a talk explaining it (without SMM_BWP).


https://media.ccc.de/v/31c3_-_6129_-_en_-_saal_2_-_201412282030_-_attacks_on_uefi_security_inspired_by_darth_venamis_s_misery_and_speed_racer_-_rafal_wojtczuk_-_corey_kallenberg



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

Re: [coreboot] more smm questions

[Stefan Reinauer]

On 03-Jul-17 10:01, ron minnich wrote:

I've got a question right at this code:
https://github.com/coreboot/coreboot/blob/fec0328c5f653233859d4aec7dae0b94acb67e97/src/cpu/x86/smm/smmrelocate.S#L101

/* Check revision to see if AMD64 style SMM_BASE
*   Intel Core Solo/Duo:  0x30007
*   Intel Core2 Solo/Duo: 0x30100
*   Intel SandyBridge:0x30101
*   AMD64:0x3XX64
* This check does not make much sense, unless someone ports
* SMI handling to AMD64 CPUs.
*/

mov $0x38000 + 0x7efc, %ebx
addr32 mov (%ebx), %al
cmp $0x64, %al
je 1f

mov $0x38000 + 0x7ef8, %ebx
jmp smm_relocate
1:
mov $0x38000 + 0x7f00, %ebx

As I read it, it tests for %al being 0x64 and, if so, it assumes the 
offset is at 7f00. As I read the intel x86 docs, this is wrong, or 
qemu is wrong. As I read the docs and Xeno's writeups, the offset is 
at 0x7ef8 on 64-bit processors. But the ich9 version at least in qemu 
is 0x20064, and that would mean coreboot thinks the register is at 
7f00, which it does not appear to be.


So: am I missing something? does this work on amd64 today? where is 
the offset on modern em64t CPUs? And why does it work on coreboot with 
q35, qemu, and multiple cores if this offset is wrong?


Not sure what the issue you are seeing is, but you can assume that Qemu 
is getting that part of the hardware emulation wrong.


What chipset emulations are you trying? Q35? Or Ich9? Do they behave the 
same? The ICH9 (southbridge) should have very little to do with this 
particular piece of the code, because it's the southbridge, but the code 
is dependent on the CPU you emulate.


Last time I checked, Qemu could not emulate SMM properly.




Also, a different question. The offset at 7ef8 is a 32-bit number on 
64-bit systems. It seems to me this implies that the the save state 
can be located anywhere in the low 4G memory on a per-core basis. I'm 
a bit lost on the need for the large contiguous SMM save state area.


This is the code that is used to move the initial SMM offset from 
0x38000 to some other place. The safe state is always located at a fixed 
offset from SMM_BASE.




So, for example, it seems to me we could leave a very small SMM stub 
at 0xa, and as long as it had a simple way to set its offset at 
7ef8 it could put its save state at any convenient location. Why do we 
need the giant contiguous memory area for save state if this is the case?


There is no giant contiguous memory involved. It's only a few hundred 
bytes for the state. The way we layed it out is to save maximum space 
when you have a lot of CPU cores. Read the documentation graphics in one 
of those files. The code (besides the trampoline) is also shared between 
all cores.





The main motivation for the TSEG seems to be the requirement of the 
large contiguous save state area for SMM, but I don't see anything 
that says it has to be physically contiguous, given the existence of 
the 32-bit offset.


Traditionally you want to protect the SMM handler from being overwritten 
by the OS. That protection requires a defined (thus contiguous) piece of 
memory.




Current status btw is that linux is able to set up the relocation area 
and I'm able to run SMIs from the command line and the code Linux sets 
up gets run.


It seems to me we ought to be able to break a lot of these fixed 
address issues and as a result reduce attack surface, but we'll see. 
I'm got lots of ignorance, little knowledge, and this can be good or 
bad :-)


There really are no fixed address issues, except for the initial setup 
(and those will be hard to fix unless you change the silicon)


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

Re: [coreboot] FILO 0.6.0 payload bootloader - Bug Reports!

[Stefan Reinauer via coreboot]

On Tue, Jun 13, 2017 at 10:33 AM Ivan Ivanov  wrote:

> === If you have some ideas about one or more of FILO problems, please tell
> ===
>
> %%% 1st problem - FILO is impossible to build on the modern x86_64
> system (Ubuntu 16.04.2 LTS with gcc 5.4.0) :
> ...
>   CC  build/x86/context.o
>   AS  build/x86/switch.S.o
> /bin/sh: 1: --32: not found
> Makefile:177: error while executing receipt for target
> «/home/owner/filo/build/x86/switch.S.o»
> make: *** [/home/owner/filo/build/x86/switch.S.o] Error 127
>
> No matter what crosscompiling stuff I am trying or what edits I do to
> Makefile - it always fails with this error. However it compiles fine
> at the 32-bit version of the same OS with the same versions of
> packages except for a different architecture
>
> FILO is probably the only payload which has this problem - and this is
> indeed a major problem, because all the major Linux distributions are
> abandoning 32-bit soon. To fix this error, most likely the edits of
> Makefile are needed, but sadly looks like my skills are not enough to
> fix it (spent the whole day without a success) ...
>

Look at the xcompile script. It seems to not detect your assembler
correctly.

Your xcompile output should look like this:

~/git/filo/ > sh util/xcompile/xcompile
# x86 TARCH_SEARCH=  /git/filo/util/crossgcc/xgcc/bin/i386-elf-
i386-elf- /git/filo/util/crossgcc/xgcc/bin/i386-eabi- i386-eabi-
/git/filo/util/crossgcc/xgcc/bin/x86_64-elf- x86_64-elf-
/git/filo/util/crossgcc/xgcc/bin/x86_64-eabi- x86_64-eabi-
# elf32-i386 toolchain (i386-elf-gcc)
CC_i386:=i386-elf-gcc  -Wno-unused-but-set-variable  -Wa,--divide
-fno-stack-protector -Wl,--build-id=none -fuse-ld=bfd  -march=i686
AS_i386:=i386-elf-as
LD_i386:=i386-elf-ld.bfd
NM_i386:=i386-elf-nm
OBJCOPY_i386:=i386-elf-objcopy
OBJDUMP_i386:=i386-elf-objdump
READELF_i386:=i386-elf-readelf
STRIP_i386:=i386-elf-strip
AR_i386:=i386-elf-ar

# arm TARCH_SEARCH=  /git/filo/util/crossgcc/xgcc/bin/armv7a-elf-
armv7a-elf- /git/filo/util/crossgcc/xgcc/bin/armv7a-eabi- armv7a-eabi-
Warning: no suitable GCC for arm.
IASL:=iasl

# native toolchain
HOSTCC:=gcc




> %%% 2nd problem: There are only three "tested" SATA controllers in
> FILO built-in "approved" list - and FILO does not even try to
> initialize the not-listed controllers, despite that the attempt could
> have been successful if tried! By default, FILO just outputs "ahci:
> Not using untested SATA controller" message, without any option for a
> user to try forcing its usage... The only currently available
> workaround for this is to manually edit
> *./coreboot/payloads/libpayload/drivers/storage/ahci.c * and  remove
> two " #if
> IS_ENABLED(CONFIG_LP_STORAGE_AHCI_ONLY_TESTED) ... #endif " parts,
>
>
Just disable CONFIG_LP_STORAGE_AHCI_ONLY_TESTED in your libpayload config.



> %%% 3rd problem: while trying to access hard drive with commands like
> filo> kernel hda:/vmlinuz I am getting the following errors:
>
> Disk read error dev=1 drive=0 sector=0
> Disk read error dev=1 drive=0 sector=2
> Disk read error dev=1 drive=0 sector=2
> Disk read error dev=1 drive=0 sector=128
> Disk read error dev=1 drive=0 sector=16
> Disk read error dev=1 drive=0 sector=64
> Disk read error dev=1 drive=0 sector=0
> Disk read error dev=1 drive=0 sector=64
> Disk read error dev=1 drive=0 sector=0
> Disk read error dev=1 drive=0 sector=0
> Unknown filesystem type.
>
>

> Error 15: File not found.
>
> Is there any workaround for this? Or maybe I am using the wrong
> commands? If so, please tell - what are the correct FILO real-hardware
> commands for trying to boot a Linux kernel thats stored on FAT16
> partition at the beginning of DOS-partitioned MBR hard drive? Or this
> is a problem with my hardware?
>

It seems you would have to look inside of a partition, not just on the raw
disk. e.g. hda1:/...



>
> Best regards,
> qmastery
>


Stefan


smime.p7s
Description: S/MIME Cryptographic Signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Please revert change of List-Id

[Stefan Reinauer]

On 04/07/2017 01:01 AM, Paul Menzel via coreboot wrote:
> Dear coreboot server list administrators,
>
>
> It looks like the List-Id of the lists provided by the coreboot server
> – at least coreboot, flashrom, SeaBIOS – changed from
>
> List-Id: coreboot project mailing list 
>
> to
>
> List-Id: coreboot project mailing list 
>
> which looks like a change in the domain name/host name from
> *coreboot.org* to *mail.coreboot.org*.
>
> That affects the configured filters of probably a lot of subscribers.
> It’d be awesome, if the ID could be reverted to the old one.
>
>
> Thanks,
>
> Paul

This has been changed back to the old behavior. It was a side effect of
mailman eagerly reacting to some effort to docker up the different
services running on coreboot.org.

Thank you for the note, and thank you for your patience.

Stefan

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

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

[Stefan Reinauer]

* Peter Stuge  [170317 14:27]:
> Patrick Georgi via coreboot wrote:
> > 2017-03-17 13:17 GMT+01:00 Dumitru Ursu :
> > > I never tried the web interface.
> > 
> > We did, it failed us.
> 
> I wish someone would have mentioned that sooner.
> 
> What problems did people have with mumble-web, and where was the
> websockets server running, relative to the mumble server?

It was actually your mumble server. We used it for one or two meetings, and the
sound was choppy and it was basically impossible to have a conversation.

Stefan

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

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

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

[Stefan Reinauer]

* taii...@gmx.com  [170317 23:35]:
> I believe it needs fixing - It is a philosophical issue, I mean you have to
> draw the line or you get the slippery slope for "just a little non-free here
> for convenience just this once" has lead to most of the community thinking
> that a system with 100% blobbed hw init is "free firmware" (coreboot just
> being a wrapper shim loader for FSP in that case) or that linux drivers with
> a binary blob are "open source drivers".
> It is a matter of pride.
> 
> The linux communities quiet acceptance of things like ME/PSP (ex: why don't
> sysadmins say no and buy POWER?) - is because of philosophy-slacking.
 
Nothing about this is quiet. We have been actively working with hardware
vendors to open up as much stuff as possible, for a good two decades
now. 

The reason is not philosophy-slacking. Because philosophy makes you feel
righteous, but it does not get any work done. Instead of having this
discussion (and making hundreds of people read it) this community could
spend the same time making coreboot better and mentoring the corporate
community members.

The sooner we get away from an "us vs them" mentality, the faster we can
be actually changing things.

Stefan


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

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

[Stefan Reinauer]

* Patrick Georgi via coreboot  [170317 16:05]:
> 2017-03-17 15:50 GMT+01:00 Juliana Rodrigues :
> > that I know uses jitsi: https://meet.jit.si
> > It's MIT, but works very well.
> Thanks for the pointer.
> 
> We already tried jitsi, but I think without the bridge service (which
> only seems to exist for about a year).
> So, something to re-evaluate, but the last time we tried "works very
> well" was the opposite of our experience due to bandwidth
> requirements.

To shed some light on this, there are several types of issues we have
encountered with this sort of software:

 - some software works really great for 1:1 video conferencing but does
   not scale when you are trying to have 15-20 people on a call. So
   unless you ran 20 people meetings successfully, "It works very well"
   might just cover a really different use case.

 - The software has to work on a variety of misconfigured (ahem) open
   source OSes and distributions, mainly by knowing about quirks of the
   various OSes / distributions and working around them. We have tried
   a number of solutions that ended up with half of the people not
   hearing the other half for various reasons.

If you folks are interested in working on deploying these types of
systems or fixing these sorts of issues, please, I advise you to join
one of the open source projects that aims at creating video / audio
conferencing software in the free software realm. These projects are in
desperate need of great engineers to make them usable for cross planet
conferencing on a larger (10-20ppl) scale. Do we want to solve these
problems in the coreboot project, or on the coreboot mailing list? No.
This project is all about booting computers. So as others here have
mentioned, please save your (and everybody elses) time and energy for
exactly that.

> Patrick
> (note to all so I don't have to sound like a grumpy, broken record: Is
> it FOSS and reasonably popular? Then it's rather likely that we
> already tried it)

Or, as a dear friend of mine likes to say: This ain't our first rodeo
:-)

All the best,

Stefan




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

Re: [coreboot] SPI Flash Writeprotect

[Stefan Reinauer]

* John Lewis  [170227 10:38]:
> Hi Naveed,
> 
> It's probably the MRC cache or something like that, which IIRC you can 
> disable.

This is correct. Unfortunately, if you disable the MRC cache you will
lose functionality like the ability to resume from S3 suspend, and your
boot time will go up between 300ms and 30 some seconds, depending on the
chipset you are looking at.

Stefan

> Whether there is also something else writing to the chip from coreboot I'm not
> 100% but others will chime in on that, I'm sure.
> 
> Kind Regards,
> 
> John.
> 
> 
> On 27/02/17 08:15, Naveed Ghori wrote:
> 
> 
> Hi all,
> 
> Does Coreboot write to the flash chip it resides on? Can this be disabled?
> 
> Verify of the SPI bios chip fails once the unit has booted up at least
> once.
> 
> �
> 
> Best Regards,
> 
> Naveed
> 
> Naveed Ghori | Lead Firmware & Driver Engineer
> DTI Group Ltd | Transit Security & Surveillance
> 31 Affleck Road, Perth Airport, Western Australia 6105, Australia
> P +61 8 9373 2905,151 | F +61 8 9479 1190 |�naveed.gh...@dti.com.au
> Visit our website��www.dti.com.au
> The information contained in this email is confidential. If you receive
> this email in error, please inform DTI Group Ltd via the above contact
> details. If you are not the intended recipient, you may not use or 
> disclose
> the information contained in this email or attachments.
> 
>
> 
> 

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


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

Re: [coreboot] No external PCIe GPU possible/working on Gigabyte g41m-es2l

[Stefan Reinauer]

* i1w5d7gf38...@tutanota.com  [170226 21:59]:
> Hardware: Gigabyte g41m-es2l, latest coreboot git, latest seabios git, two
> nvidia gpu cards tested
> 
> I tried to use some external GPU on a g41m-es2l to get some digial screen
> output. It does not seem to work. When having build coreboot with native
> vga-init for the internal intel gpu, i never get a output from the nvidia 
> card.
> When i connect the analog VGA cable to the internal intel gpu and boot up i 
> can
> see many nouveau (memory-space?) errors. Both GPUs (nvidia and intel) are then
> enabled at once. Kernel 4.10 cant boot.
> 
> I tried removing the native vga-init. The only change is then that the Intel
> GPU works only when the kernel have load. Nvidia card deliver still same
> errors.
> 
> With OEM-bios the intel card gets disabled and a PCIe GPU works fine.

Please provide coreboot boot logs.

Stefan


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

Re: [coreboot] payload coreinfo - no button press works

[Stefan Reinauer]

Hello anonymous,

* i1w5d7gf38...@tutanota.com  [170226 21:23]:
> Hardware: g41m-es2l, latest coreboot git, latest seabios git, native vga, ps2
> keyboard + usb keyboard
> 
> I liked to try out coreinfo. It show the CPU Information page at start. When i
> then press any button (f1,f2,a,b,c,d) nothing happens. I also cant reboot by
> pressing ctrl+alt+del. Have to press the ATX-power-on/off-button.
> 
> I then shut down and connected a USB-Keyboard. I pressed in Seabios esc (usb
> keyboard is working) and then inside coreinfo i was again unable to get any
> functionality by pressing some button.

Did you compile USB support, support for your USB host controller, and
USB keyboard support into libpayload when compiling for coreinfo?

Stefan


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

Re: [coreboot] How to reduce formal issues with new contributions from corporations?

[Stefan Reinauer]

* Paul Menzel via coreboot  [170226 14:37]:
> Dear coreboot folks,
[..]
> My impression is though, that a lot of these contributions have formal
> issues in the beginning. As the coding style and the commit message
> guide lines are well documented in our Wiki [1][2], and there are even
> scripts checking commits, the developers starting to work on coreboot
> just don’t seem to know about this.
> 
> How can this be improved?

Hi Paul,

there is definitely a learning curve involved with people new to the
coreboot community. Thank you for pointing that out. Do you have a few
such examples of what you mean? That will make it much easier to address
these issues, than having to try and reach out to a large sub group of
coreboot community members with fairly vague feedback.

> Could the companies make sure, that there developers read those, and
> use the scripts?

Just like on the non-commercial side of the project, the people involved
in coreboot through their respective corporations are not necessarily a
single entity. I know of several independent groups at both Intel and
Google, that are contributing to coreboot. So while we might all share
the second half of our email addresses, that might be as far as the
similarities and overlaps go (and that's a great thing for coreboot).

Also, the list of contributors is continuously growing. Please be patient
with these folks, and continue to treat them like you would treat any
other individual in the coreboot community. I'm sure most of these folks
appreciate your mentorship on these issues.

> Should this documentation be moved to the repository? A lot of the
> “guideline Wiki pages” are locked anyway. People knowing the Linux
> kernel, would expect that to also live in the source code repository?

Yes, I am in favor of moving relevant documentation into the source
tree, as I believe that we should obsolete the wiki all together.

Stefan



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

Re: [coreboot] REACTS Pricing Changes

[Stefan Reinauer]

* Timothy Pearson  [170111 23:38]:
> When you purchase a REACTS license, you are helping us continue to
> maintain and improve the only publicly available CI hardware testing
> solution for coreboot.

The only other one besides this one, which has been available without
license restrictions and free of charge since 2006:

https://www.coreboot.org/Distributed_and_Automated_Testsystem
https://www.coreboot.org/PDFs/LinuxBIOS-testing/coreboot-testsystem.tar.gz

Thanks,

Stefan


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

[coreboot] PSA: abandoning old patches (again)

[Stefan Reinauer]

Hi,

we're planning (as we have done in the past), to abandon patches that
have been crowding up gerrit without any update in the last 18 months.

The list of patches in question is
https://review.coreboot.org/#/q/status:open+age:18months

If you want to preserve any of those patches, please rebase them against
current ToT, take them over, maintain them, or whatever, because I plan
to abandon everything that is still in this list at the end of next week
(November 4th)

Stefan


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

Re: [coreboot] Stops at 0xD2

[Stefan Reinauer]

* Riko Ho  [161026 03:36]:
> Everyone,
> 
> I tried to initialize UART on IT8718F and it stopped at 0xD2...
> Here's the complete function, any clues ?

Yes, there is a halt() right after the post_code(0xd2); so that is where
your last post code is coming from.

use superiotool (from coreboot/util) to dump the superio registers on a
running system and compare them with what you write in there and the
data sheet.

Are you sure you are using the correct SuperIO driver?

Stefan

> 
> Cheers
> ===
> void mainboard_romstage_entry(unsigned long bist)
> {
> int s3resume = 0, boot_mode = 0;
> 
> if (bist == 0)
> enable_lapic();
> 
> ich7_enable_lpc();
> post_code(0xD1);
> /* Enable SuperIO PM */
> //lpc47m15x_enable_serial(PME_DEV, 0x680);
> //lpc47m15x_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE); /* 0x3f8 */
> //enable_dev(SERIAL_DEV);
> //ite_conf_clkin();//needs a parameter, what is it ?
> 
> /*
> 04:24:31 AM) idwer: 24 or 48 MHz?
> 
> (04:25:18 AM) idwer: how do you find out? run superiotool when
> having booted with the vendor bios, and look atregister
> CR23
>  */
> //ite_conf_clkin(CLKIN_DEV, ITE_UART_CLK_PREDIVIDE_24);
> ite_conf_clkin(CLKIN_DEV, ITE_UART_CLK_PREDIVIDE_48);
> 
> 
> ite_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE); /* 0x3f8 */
> //printk(BIOS_DEBUG,"HELLO WORLD FROM COREBOOT BY RIKO HO...\n");
> //it8716f_enable_dev(SERIAL_DEV, CONFIG_TTYS0_BASE);
> it8718f_disable_reboot(GPIO_DEV);
> /* Set up the console */
> console_init();
> post_code(0xD2);
> printk(BIOS_DEBUG,"HELLO WORLD FROM COREBOOT ...\n");
> halt();
> post_code(0xD3);
> 
> 
> 
> /* Halt if there was a built in self test failure */
> report_bist_failure(bist);
> 
> if (MCHBAR16(SSKPD) == 0xCAFE) {
> printk(BIOS_DEBUG, "soft reset detected.\n");
> boot_mode = 1;
> }
> 
> /* Perform some early chipset initialization required
>  * before RAM initialization can work
>  */
> i945_early_initialization();
> post_code(0xD4);
> s3resume = southbridge_detect_s3_resume();
> 
> /* Enable SPD ROMs and DDR-II DRAM */
> enable_smbus();
> 
> #if CONFIG_DEFAULT_CONSOLE_LOGLEVEL > 8
> dump_spd_registers();
> #endif
> 
> sdram_initialize(s3resume ? 2 : boot_mode, NULL);
> 
> /* Perform some initialization that must run before stage2 */
> early_ich7_init();
> 
> /* This should probably go away. Until now it is required
>  * and mainboard specific
>  */
> rcba_config();
> 
> /* Chipset Errata! */
> fixup_i945_errata();
> 
> /* Initialize the internal PCIe links before we go into stage2 */
> i945_late_initialization(s3resume);
> }
> 
> -- 
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
> 

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

Re: [coreboot] i946GZ test

[Stefan Reinauer]

* Riko Ho  [161019 06:29]:
> Hello everyone..
> 
>  I've put W39F040FCPZ on the board...but I can not see any messages on
> serial...
> I can hear tuck tuck on motherboard buzzardrepeatedly
> 
> command : sudo putty /dev/ttyUSB0 -serial -sercfg 115200,8,n,1,N on the host
> 
> What should I do next to debug ?
> 
> Cheers


Use a scope or a bus analyzer to figure out whether you are executing
code, and where you die. Check your SuperIO init code to see if you are
doing the right thing.

Stefan


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

Re: [coreboot] Microcode question ?

[Stefan Reinauer]

* Riko Ho  [161017 02:18]:
> Is it ok if I'm not including microcode updates ?

It might, or might not. On the i945/946 it probably is ok. A lot of
modern CPUs can't boot successfully anymore without loading microcode.
 
Stefan

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

Re: [coreboot] WY1200LE with coreboot

[Stefan Reinauer]

* Riko Ho  [161018 09:31]:
> Everyone,
> 
> Does coreboot suport WY1200LE? it's using AMD geode, and I can't access its
> BIOS...directly to windows and no BIOS key access ..

AMD Geode GX support has been dropped a while ago. Older versions of
coreboot will support the chip, but the mainboard was never supported.

> Anyone has ported it ?
 
No.

> Cheers

Stefan


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

Re: [coreboot] ite_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE); ?

[Stefan Reinauer]

* Riko Ho  [161018 14:29]:
> Everyone,
> Does this line use port on 0x3F8 ?

It uses whatever you configured for CONFIG_TTYS0_BASE in your .config.

Stefan


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

Re: [coreboot] W39V040FB and W39V040FC?

[Stefan Reinauer]

* Antonius Riko  [161016 07:38]:
> Everyone,
> 
> Is W39V040FB compatible with W39V040FC ?
> Cheers

That depends on your uyse case. They have different erase block sizes.

>From the data sheets:

The W39V040FC is a 4-megabit, 3.3-volt only CMOS flash memory organized
as 512K x 8 bits. For flexible erase capability, the 4Mbits of data are
divided into 16 x 8 Kbytes pages and 6 x 64 Kbytes sectors or 8 x 64
Kbytes sectors.

The W39V040FB is a 4-megabit, 3.3-volt only CMOS flash memory organized
as 512K x 8 bits. For flexible erase capability, the 4Mbits of data are
divided into 8 uniform sectors of 64 Kbytes

Stefan

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

Re: [coreboot] [coreboot-announce] SHORT NOTICE: coreboot.berlin next weekend, Oct. 7-9

[Stefan Reinauer]

Have fun, folks! Wish I could be there. Send updates and pictures!

Stefan

* ron minnich  [161001 05:23]:
> See you there! I just registered and am really looking forward to seeing
> everyone! Thanks Peter!
> 
> ron
> 
> On Fri, Sep 30, 2016 at 9:41 AM Peter Stuge  wrote:
> 
> Hello all,
> 
> I'm happy to *finally* have the information and registration page online:
> 
> https://coreboot.berlin/
> 
> 
> Yes, it's very late, but I hope that we will still be a good number
> of people meeting up next weekend.
> 
> Quick feedback helps me make sure that everyone will get food.
> 
> If you are interested in attending, but unable to register at the
> Community Registration Fee cost then please get in touch with me,
> so that we can try to work something out.
> 
> 
> Thank you very much, and hope to see you in Berlin on the 7:th!
> 
> //Peter
> 
> ___
> coreboot-announce mailing list
> coreboot-annou...@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot-announce
> 

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


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

Re: [coreboot] How to pass custom defined data from Coreboot to GRUB2

[Stefan Reinauer]

* Mohan Shanmuga Sundaram  [161005 09:55]:
> Paul, Thanks for the info!
> I looked into CBTABLES, but cannot understand others than CMOS table. It 
> looks simple to me to use CMOS table that I have to define some region for 
> user data in the 'cmos.layout' and use it at GRUB or Ubuntu Linux. But where 
> does CMOS tables really reside? On the boot flash or DDR3?
> 
> Regards,
> Mohan

Hi Mohan,

check out lib/coreboot_table.c:lb_gpios() - This is what Chrome OS
devices use to pass GPIO information to the payload. It might be usable
for the problem you are trying to solve.

Stefan


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

[coreboot] Welcome to the new coreboot.org!

[Stefan Reinauer]

Hi!

As some of you might already have noticed, our new web presence
has gone live on https://www.coreboot.org/ today!

I want to use this chance to send a big shout out to Philipp Deppenwiese
and Martin Roth, and all the others that have been involved in making
this moment happen, for their great work!

With the new web page, our presence has not only arrived in the 21st
century. We also have a better portal to catch the different groups
interested in coreboot, in the future: End users, software developers
and hardware manufacturers.

There will be changes, modifications and optimizations in the next
couple of days or weeks, but please feel free to send us feedback on
coreboot's new look and content.

Thanks,
Stefan

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

Re: [coreboot] initrd in 4.4 versus head

[Stefan Reinauer]

* Trammell Hudson  [160727 13:58]:
> I see a difference in the way 4.4 handles initrd images for linux
> payloads versus the way it is done in head.  With 4.4 my Linux
> kernel can not find the external initrd, so it is necessary to
> build it as part of the kernel.  With head it works fine.
> 
> It looks like 4.4 is adding the initrd as a separate section
> named "(empty)" with type "null" and the kernel can't find it:

(empty) is indeed what it claims to be, empty space in the image.
There is no initrd in there.

> performing operation on 'COREBOOT' region...
> Name   Offset Type Size
> cbfs master header 0x0cbfs header  32
> cpu_microcode_blob.bin 0x80   microcode22528
> cmos.default   0x5900 cmos_default 256
> cmos_layout.bin0x5a40 cmos_layout  1948
> fallback/dsdt.aml  0x6240 raw  13847
> (empty)0x98c0 null 26264
> fallback/romstage  0xff80 stage74020
> (empty)0x22140null 56664
> mrc.cache  0x2fec0mrc_cache65536
> fallback/ramstage  0x3ff00stage84790
> fallback/payload   0x54a80payload  1618769
> (empty)0x1dfe40   null 2226328
> bootblock  0x3ff700   bootblock1952
> 
> While in head it is bundling them together into the payload
> region (3.9 MB == bzImage + initrd.img) -- the kernel can
> find the image and use it:
> 
> Performing operation on 'COREBOOT' region...
> Name   Offset Type Size
> cbfs master header 0x0cbfs header  32
> fallback/romstage  0x80   stage14620
> cpu_microcode_blob.bin 0x3a00 microcode22528
> fallback/ramstage  0x9280 stage43781
> cmos_layout.bin0x13dc0cmos_layout  1948
> fallback/dsdt.aml  0x145c0raw  4021
> fallback/payload   0x155c0payload  3906169
> (empty)0x3cf080   null 199256
> bootblock  0x3ffb00   bootblock960
> 
> I don't see any changes in the util/cbfstool/cbfs-payload-linux.c
> file between these two versions.  Is there something else
> that changed?

It seems these two images are significantly different from each other,
apart from the payload. Almost all the stages are about twice as big in
the first image.

Did you compare the .config files for both images? Did you use the same
compiler to produce them? Are these for the same mainboard? Which one?

Stefan




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

Re: [coreboot] What is the best way to treat warnings reported by checkpatch.pl

[Stefan Reinauer]

* Julius Werner  [160727 23:41]:
> > typedef struct dmar_atsr_entry {
> >u16 type;
> >u16 length;
> >u8 flags;
> >u8 reserved;
> >u16 segment;
> > } __attribute__ ((packed)) dmar_atsr_entry_t;
> 
> Looking at the original example here, I would still recommend not to
> use the packed attribute. It forces the compiler to use accesses that
> would work on unaligned data... for x86 that doesn't matter (and
> granted, this sounds x86-specific, but it's worth applying the same
> principles to all code), but for other architectures it may generate
> very inefficient code (even on ARM where unaligned accesses are okay
> after you turn on caching, GCC keeps doing this for all packed
> structures and there's no way to convince it otherwise). In this case,
> the members are all correctly aligned so there's no need to insert
> padding, so you can (and therefore should) leave out the packed
> attribute.

The point is, that without ((packed)) there is no guarantee that gcc
won't choose a different alignment over what you and I think would make
sense.

Stefan

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

Re: [coreboot] What is the best way to treat warnings reported by checkpatch.pl

[Stefan Reinauer]

* ron minnich  [160727 02:26]:
> A couple of questions preceded by the usual curmudgeonly comment :-)
> 
> I'm not a big fan of checkpatch.pl. It's 5965 lines of dense perl spaghetti
> code, continues to grow, and is attempting to achieve that which I understand
> may be impossible: parsing C with REs and random blobs of PERL. Given that the
> problem may be impossible, checkpatch finds it hard, and makes mistakes, as
> experienced on the projects that use it.

It also finds a lot of inconsistencies in our code base, which are
(arguably) worth fixing.

> It's not surprising it continues to grow, and not  surprising it's got lots of
> errors. You can find discussions on the various lists which boil down to "just
> ignore checkpatch.pl in this case." This is not confidence-inspiring.

I didn't see any errors reported since its use in coreboot, besides the
current discussion of whether it is the right thing to abstract out gcc
__attribute__(()) qualifiers or not.

> I'd most prefer to move to clang-format for this sort of thing, which is what
> we're doing on at least one other kernel project I work on.

clang-format's scope is very different. It copes with whitespace, more
like indent.

> I continue to not understand the injunction on typedefs; operating systems
> written by the inventors of C continued to use them until Bell Labs disbanded
> the OS group in 2015 ... 

Agreed.

> Finally, why the use of packed? In general you really only want to use packed
> when you're using it to directly address data. Why not deserialize the data
> from memory into an unpacked struct? That's how ACPICA seems to do it.

Because in most cases, it is not data, but register space we are
accessing.

Are you suggesting to learn our coding style from ACPI? Who are you and
what did you do to Ron Minnich? ;)

> thanks
> 
> ron

Stefan


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

Re: [coreboot] ARM Trusted Firmware build issue

[Stefan Reinauer]

On 20-Jul-16 16:19, Julius Werner wrote:


Well... honestly, isn't it our fault for uprevving to a buggy
toolchain? If there was a way to write this code such that it will
result in the binary output ARM wants and works on all versions,
submitting a patch to them would be reasonable... but otherwise I can
kinda understand that they don't want to use an inferior solution
because we insist on using an assembler that doesn't know how to
assemble stuff correctly. Isn't the best solution to only uprev archs
that really need new compiler features until the GCC guys manage to
produce a stable version?


Yes, I was wrong. After reading the other threads and talking with 
Martin, it indeed seems to be a toolchain issue.
However, the new toolchain had many advantages over the previous one, 
and the code was not in (our) ARM TF at the time we uprevved.


The maintenance burden of keeping different versions of toolchains 
supported for different architectures as part of the reference toolchain 
is imho almost always significantly higher than actually fixing the 
issues. (Especially if they are not time critical)


Martin produced a binutils fix for the issue. Whether the binutils 
people will find it to be the "right" fix is still to be found out, but 
it seems to allow compiling the latest, unmodified ARM TF.


Stefan

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

Re: [coreboot] TXE and Descriptor bin management in Coreboot

[Stefan Reinauer]

* Mayuri Tendulkar  [160714 00:50]:
> Ok, so do we need to ask Intel if we use Intel baytrail processor? How we can 
> create this descriptor.bin?

Please have a look at util/ifdtool and util/ifdfake for our tools
dealing with Intel Firmware Descriptors. The most comprehensive way of
producing the information you need is by using Intel's fitc tool,
however.

If you are willing to put some development effort into this, we could
use help, merging ifdtool and ifdfake, as well as incorporating more
fitc like capabilities into the tool.

Stefan



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

Re: [coreboot] How to read the gpio status?

[Stefan Reinauer]

* ��?�?��??  [160713 06:39]:
> When write 0x7000 write to SC_GP_LVL, Can read the 0x00 from SC_GP_LVL.
> everytime.
 
Are you by any chance doing an 8 bit read (0x00) instead of a 16 bit
read (0x)?

Stefan


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

Re: [coreboot] ARM Trusted Firmware build issue

[Stefan Reinauer]

* Martin Roth  [160713 16:57]:
> We can't roll the entire toolchain back to binutils 2.25 because of
> the RISC-V work.  Is it reasonable to roll back to binutils 2.25 for
> just the ARM toolchain builds?

No, that is not feasible. The cross toolchain builder has seen a fair
amount of bloat already in the last couple of months. Let's fix this in
ARM TF.

Stefan

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

[coreboot] A word on releases

[Stefan Reinauer]

Hi people,

we have had a great first year with regular coreboot releases. Exactly
12 months ago, we released coreboot 4.1, the first release after the 4.0
release in 2011 and our "classic" branch in 2014.

Since then we have had 4 successful releases, both Patrick and Martin
went through the release process, and with this process we were able to
move two corporations working with coreboot (Intel and Google)
significantly closer to working with upstream coreboot.

However, releases take a lot of time, and we were not able to tighten
the release process with each release, as we had originally hoped, and
so, after I talked with Patrick and Martin, we have decided to move to
a slightly slower paced release cycle, creating only two releases per
year. In turn, we will try to improve the overall quality of the
releases in the future. This switch will mean, that the coreboot 4.5
release will happen in fall 2016, rather than this month.

I have written up a few questions that I came across, and some answers
to them. 

If you are using coreboot releases, I would like to hear from you, so
that we can continue to improve the release process and tune it towards
its users, while we spend the majority of the time on making coreboot
better.

We're continually improving the release process and raising the quality
bar and look for developers interested in helping on that topic.

Questions and comments, flames and praise are, as always, welcome!

Stefan



FAQ
---

1. What kind of releases do we do?

The coreboot project is now creating a new release every six months.

Before this cycle, we created a new release every quarter, but every
second release has basically been unused.


2. Why do we need releases at all?

Lots of people work "offline". You check out a given revision of
coreboot, and do your work. When you are done, you will have to fix up
your patch to still work with the now latest revision, before you can
submit it to the upstream tree. Depending on how complex your problem
is, or how busy you are with other stuff, a lot of time can pass between
the start and the finish line.

Releases are a simple mechanism to make sure everybody is on the same
page. A way of documenting what has changed between the start of your
effort and it's availability to the community.


3. Isn't this just psychological?

In the past we have seen groups of people working together on a
coreboot port to a new platform, with slightly different trees, being 1
or 2 weeks apart. This can cause all kinds of funny effects, that take
away from the efficiency of the development process, and that, lacking
up to date documentation, every engineer has to go through again.

With over 100 people contributing over 3000 patches per year to our code
base, these little changes sum up to a significant amount.


4. Who are these releases for?

If you are a developer that wants to put coreboot on your board at home,
you probably don't care much, yet, because chances are, we didn't even
test your board before making the release.

If you are setting up an internal coreboot tree for your fellow
coworkers to colaborate with you, and you can't work on coreboot.org
directly, please use the latest released version to base your work off,
rather than top of tree. This will make it much easier to support your
work.


5. What about testing releases?

Right now, we are hand testing releases on a few selected machines
before every release by boot testing on a given setup. We try to cover
as much diversity as we can (e.g. Intel, AMD, ARM, ARM64). However, this
part of the release process is less formalized as the coreboot project
lacks a large scale test system setup at the moment. Mostly, what the
release manager for a release has available at the time is what will be
tested.


6. What's with that dropped board thing?

Short story: It's not really worth bringing forward all boards all the
time, so we're trying to find a reasonable cut-off line.

Long story:
Coreboot is a fast moving project with a lot (a whole lot) of boards,
and even more features.

In the very early days (1999 - 2003), most boards wouldn't compile or
work shortly after they've been merged, unless someone went ahead and
fixed it. When we added abuild to the development process, that didn't
happen anymore and so we attempted to move all boards forward to the
latest feature set all of the time.

Since coreboot itself has no user interface and barely any attack
surface, there are barely good reasons to update your firmware very
often, especially if work on your board has generally stopped. On the
same hand, a lot of design decisions made 10 or 15 years ago can only
be overcome with significant effort that is not justified for obsolete
hardware.
In order to keep the code healthy and clean, we are retiring old boards
in release branches. For example, if a board was removed right after the
release of 4.4, you can still check out the "4.4" branch and build your
board with that branch. If the board is broken on 

Re: [coreboot] RFC: implementing a way to force external EDID use.

[Stefan Reinauer]

Hi Arthur,

* Arthur Heymans  [160622 23:34]:
> Hi
> 
> In Linux it is possible to load an EDID externally. Coreboot can
> currently not do this. Do you think it is worth implementing this
> feature?

So far we have not come across devices without an EDID or with a bad
EDID, but if that is the case for you, you should implement this.

What platform are you looking at?

> An EDID file is a bit to big (128 bytes) to fit in nvram so it would have to 
> go in cbfs.

Since the information is not going to change (for a mobile device,
anyways), CBFS is the right place.

> Where in the code do you think this setting should be implemented:
> NB code, read_edid in drivers, decode_edid in lib, somewhere else?

The code should probably live in lib, as it is not chip specific, and be
called from the chip specific code, e.g.

intel_gmbus_read_edid(pmmio + GMBUS0, 3, 0x50, edid_data, 128);
decode_edid(edid_data, sizeof(edid_data), &edid);

would become something like

if (IS_ENABLED(CONFIG_OVERRIDE_EDID)
cbfs_read_edid(edid_data, sizeof(edid_data));
else
intel_gmbus_read_edid(pmmio + GMBUS0, 3, 0x50, edid_data, 128);
decode_edid(edid_data, sizeof(edid_data), &edid);

> How do you think this feature should be turned on: nvram option or build
> option?
 
This depends on your use case. Since this is not something that should
be messed with in the field, I would suggest to make it a Kconfig
option.

Stefan


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

Re: [coreboot] kgpe-d16

[Stefan Reinauer]

* ron minnich  [160620 20:19]:
> I have a kgpe-d16 with coreboot and it *was* working with linux. I now have a
> linux kernel that won't boot on fuctory bios or coreboot. I can't recall
> changing anything ...
> 
> If somebody's got a known good .config for linux I could sure use it. I'm
> booting stock tinycore and it seems to hang a lot.

The Ubuntu 16.04 default config worked fine on the system.

Stefan



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

[coreboot] PSA: old coreboot versions now available via git

[Stefan Reinauer]

Hi,

the ancient coreboot versions coreboot v1 and coreboot v3 have been
recovered from some old svn trees and are now available in the coreboot
repository under the branch names "coreboot-v1" and "coreboot-v3".

Enjoy,
Stefan



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Say hi to avatars on review.coreboot.org

[Stefan Reinauer]

Hello coreboot folks,

I've played around with gerrit's avatar feature this weekend and as
a little gimmick, I have turned on avatars for our gerrit instance at
https://review.coreboot.org/

In a never-ending effort to make it harder for everybody in the
community to be mad at each other, you will now have the priceless
opportunity to stare at each other's friendly faces while doing
code reviews.

NOTE: This feature is not using the gravatar service (and as such is
not forwarding any personal information to another site), but only shows
pictures locally stored on photos.coreboot.org.
So if you're not showing up with a photo, I didn't have
a good, publicly available photo of you. Right now the image store is
completely manual, so if you want to have your own avatar show up in
gerrit.coreboot.org, please feel free to send me a picture, preferrably
in JPG format, square, at least 128x128.

Stefan


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

Re: [coreboot] coreboot specific ACPI table

[Stefan Reinauer]

On 04/18/2016 08:17 PM, Julius Werner wrote:
> For comparison, the coreboot device tree interface on ARM
> (https://lkml.org/lkml/2014/6/16/622, unfortunately never picked up by
> the maintainers but still used on Chromebooks today) only exports
> start address and size of the coreboot table and the whole CBMEM area,
> so maybe ACPI should just match that. (I guess if CBMEM is referenced
> by the coreboot table like Aaron said, we could also drop that part.)
>
Did you get other feedback than the one mail by Rob Herring?
We should keep pushing this.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot specific ACPI table

[Stefan Reinauer]

On 04/22/2016 02:35 PM, Aaron Durbin via coreboot wrote:
> 1. coreboot tables base address and size.
> 2. console base address and size.
> 3. ramoops info.
Since ramoops already has its own object in the DSDT, do we want to
mention it here?
What about other cbmem entries? coverage, timestamps...?
Do we want a pointer to cbmem in there, instead?

Here's the 1 million dollar question: Do we want to get rid of coreboot
table and only have a coreboot
specific table? For a non-ACPI OS it's not much harder to read a
(non-DSDT) ACPI table than the current
coreboot table approach. For ACPI OSes it might make things a bit easier
(and counter the argument that
coreboot requires "support for non-standard tables")

> On Fri, Apr 22, 2016 at 2:00 PM, Duncan Laurie  wrote:
>> On Tue, Apr 19, 2016 at 6:49 AM, Aaron Durbin  wrote:
>>> On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner 
>>> wrote:
 I think we should only export the coreboot table location and size
 through ACPI and then read everything else from there. That way we can
 share almost all of the kernel driver code with ARM and just need a
 tiny platform-specific stub to look up the table location first. If we
 add all the information into an actual ACPI table, we're building an
 x86-only solution again. (A generic, platform-independent coreboot
 driver could just as easily export the stuff we want into sysfs.)

>>> That's fine. The only thing I was concerned about was implementing an
>>> ACPI table proper or try to do some ACPI device shenanigans like the
>>> ramoops device. coreboot doesn't currently have a ACPI ID assigned to
>>> it. If we go with a ACPI device coreboot should apply for an ACPI ID.
>>> I personally think the coreboot ACPI table seems more straight
>>> forward, but I was wondering if people knew of any downsides to going
>>> that route.
>>>
>>
>> The official tables are all defined in the ACPI spec while the related
>> tables are also linked to from the spec, so we'd need to convince the UEFI
>> forum to at least reserve the signature for us (and then link to our table
>> definition) since they intend to act as gatekeepers to avoid collisions in
>> table signatures:
I like the idea of having a separate table rather than an object.


>>
>> "Requests to reserve a 4-byte alphanumeric table signature should be sent to
>> the email address i...@acpi.info and should include the purpose of the table
>> and reference URL to a document that describes the table format."
>>
>> An easier path would be to define a specific device in the DSDT and populate
>> it with the various data we want to be there on every system.  That would
>> allow us to control the format and be able to alter it in the future if we
>> want to expose new information.
>>
>> As you note a Device would need a valid unique HID, and that needs an ID
>> prefix if it wants to be official.  In theory we could request something
>> like "CORE" as an official APCI ID from
>> http://www.uefi.org/PNP_ACPI_Registry
> OK. Time for bikeshedding:
>
> 1. CORE
This one is it!

> 2. CBOOT
Would end up as CBOO... dunno.

> 3. ... ?
We could try just "BOOT" (Drop the core, it's cleaner!)

> Stefan, we'll likely need you to request the HID w/ your coreboot.org email.
Can't wait to do it, this is exciting. But we should come up with a
reasonable data structure first, and document it (as Duncan quoted the
standard)

>> I suppose the real difference between the two is whether we need this data
>> early in boot before there is an AML interpreter available in the OS.
> I don't think we need it that early. Right now the current usage (at
> least on x86) is all very late since we're doing AML evaluation. We
> could go w/ the ACPI device first. Just need to request that HID.

A driver could merge our log with dmesg if it ran early enough.

>> -duncan
Stefan



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] coreboot toolchain update after 4.4 release

[Stefan Reinauer]

Hi folks!

We're planning to update the coreboot reference toolchain very soon now,
right after the coreboot 4.4 release which will roughly happen at the
end of this month.

We have fixed a few issues with the new toolchain already, and I am
building and running coreboot images with the new toolchain daily, but
we need more testing from all of you and for all of your coreboot
systems. So please: Build the new toolchain and build and run coreboot
images with it during the next week!

The patch for updating the toolchain is here:
https://review.coreboot.org/#/c/14227/

How to build the new toolchain
$ cd coreboot/
$ git fetch https://review.coreboot.org/coreboot
refs/changes/27/14227/11 && git cherry-pick FETCH_HEAD
$ rm -r util/crossgcc/xgcc
$ make crossgcc CPUS=4 # replace with your number of CPU cores

$ rm .xcompile

Stefan



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to deal with Coverity reports?

[Stefan Reinauer]

On 03/14/2016 04:05 PM, Julius Werner wrote:
> Is our general goal just to triage or to actually fix (as in: change
> code so that they disappear) all Coverity errors? I think it's a great
> tool that occasionally really finds that one odd bug, but most of the
> issues I've looked at so far seem to be false positives of some sort
> or another (either because for some error types it really just
> guesses, or because of aggressive overinterpretation of the C
> standard). Some of those may be easy to fix, but others may not, and I
> don't think we should sacrifice speed or readability to make a tool
> happy. It would be ideal if we could just mark a certain issue that it
> found as "resolved" somehow (it already seems to report everything
> only once, but something more explicit with maybe a comment field
> would be nice).

Most issues have not even been triaged yet. I agree that a fair amount
of issues are not critical, and are flagged because coverity was not
designed for low level software. These issues can be classified as False
Positive or Intentional, which will make them go away.

Stefan



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

Re: [coreboot] Missing Coverity reports

[Stefan Reinauer]

On 03/12/2016 01:51 PM, Paul Menzel wrote:
> Dear coreboot folks,
>
>
> does Coverity still check the coreboot code base or have there been
> changes? It’d be great to get it going again and to have the errors
> fixed in code that is currently committed.
>
>
> Thanks,
>
> paul

There are no automatic runs of coverity right now, but the plan is to
continue having coverity check the code base.
It would be nice to build a task force for fixing the issues found by
coverity. Any takers?

Stefan


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

Re: [coreboot] Member list of coreboot leadership

[Stefan Reinauer]

On 03/12/2016 02:02 PM, Paul Menzel wrote:
> Dear coreboot folks,
>
>
> neither in the coreboot Wiki [1] nor the repository I was able to find
> a list of the members of the so called coreboot leadership. Stefan’s
> blog post from May 2015 [2] lists the people below.

The group that I get my advice from is varying and may be different,
depending on the individual problems to be solved.
Whether or not someone is on a formal list, anybody in the community can
show leadership and drive the project forward.

I believe the blog post from last May to still be fairly accurate and
consider the blog a good place for this document.

> Is that still accurate? Sorry, if I missed a document. If it is not
> documented, where should it be?
>
>
> Thanks,
>
> Paul
>
>
> [1] https://www.coreboot.org/Welcome_to_coreboot
> [2] http://blogs.coreboot.org/blog/2015/05/11/on-coreboot-leadership/

Stefan



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

Re: [coreboot] Query

[Stefan Reinauer]

Hi Damany,

On 03/08/2016 12:00 PM, Damany Reid wrote:

Good Day, My name is Damany and I’m new to the area of open source software 
contributing. I learnt of the opportunities afforded through Google Summer of 
Code and I’m just wondering if I’m qualified enough to participate in your 
project. Im first year in university learning c which i would have completed it 
by the end of this semester, before summer.

Thanks in advance,
Damany


Please feel free to look around, see if you like the project, and could 
imagine contributing to one of our GSoC projects:

https://www.coreboot.org/GSoC

You will find the requirements and sub projects there. Of course you can 
also suggest your own project.


Stefan

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

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

[Stefan Reinauer]

I suggest you start looking at the progress made last year and try to 
reproduce it:


http://blogs.coreboot.org/blog/author/namang/

On 03/08/2016 06:35 PM, Saket Sinha wrote:

Hi Stephan,

Any update on this.


Regards,
Saket Sinha


On Mon, Mar 7, 2016 at 10:47 AM, Saket Sinha  wrote:

Hi Stefan,

Thanks for the reply.

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

Let me know how to get started on the same.


Regards,
Saket Sinha


On Mon, Mar 7, 2016 at 4:10 AM, Stefan Reinauer
 wrote:

Hi Saket!

Welcome to coreboot!

Please check out our GSoC page at https://www.coreboot.org/GSoC and have a
look at our three sub projects this year: coreboot, flashrom and SerialICE.
If you have specific questions, please don't hesitate to ask.

Stefan


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

Hi,

Congratulations to the coreboot team for selection in GSOC 2016.

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

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

Regards,
Saket Sinha



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


Hi,

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

This is to discuss the idea further.

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

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


Regards,
Saket Sinha



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



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

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

[Stefan Reinauer]

Hi Saket!

Welcome to coreboot!

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

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

Stefan

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

Hi,

Congratulations to the coreboot team for selection in GSOC 2016.

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

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

Regards,
Saket Sinha



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


Hi,

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

This is to discuss the idea further.

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

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


Regards,
Saket Sinha




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

Re: [coreboot] GSoC 2016

[Stefan Reinauer]

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

Respected Sir,

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


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


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


Regards
Tahir Ramzan


Hi Tahir,

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

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


Stefan

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

Re: [coreboot] Timestamp

[Stefan Reinauer]

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

Hi

how we can get the timestamp from coreboot ?

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

What is the configuration needed to obtain the timestamp table ?

thanks
ᐧ


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


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



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

Re: [coreboot] Coreboot table

[Stefan Reinauer]

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

Hi

I need your help please :)

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




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


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

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

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

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

Re: [coreboot] explore Coreboot,with Doxygen

[Stefan Reinauer]

On 25-Feb-16 08:16, ron minnich wrote:
We tried to do Doxygen starting in 2000, but the experiment never 
seemed to work out. I still like the idea. One result was that you could

make documentation
and get a manual for the board you were working on at the time. That 
actually did work for a few years but it all kind of decayed.


In fact you can run 'make doxygen' and it should work just fine. I had a 
service running until around 2011 to rebuild doxygen documentation every 
couple of builds, but it was slow enough and nobody seemed to be using 
it, so that we stopped the regular updates once we switched to jenkins. 
I guess we could turn them back on, but most comments in coreboot are 
not doxygen style.


Stefan




ron

On Thu, Feb 25, 2016 at 12:11 AM daoud yessine 
mailto:yessine.daoud...@gmail.com>> wrote:


Hi

Can coreboot be explored using Doxygen ?
Who tried it ?

Thanks
--
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] [ANNOUNCEMENT] PS/2 devices working on ASRock E350M1

[Stefan Reinauer]

That's great news! Congratulations!

Stefan

On 13-Feb-16 02:23, Paul Menzel wrote:

Dear coreboot folks,


just a short thank you to Timothy Pearson from Raptor Engineering [1]
for implementing auxiliary channel PS/2 device presence detection in
coreboot [2] in commit 448e3863 (drivers/pc80: Add PS/2 mouse presence
detect).

As a result it was easy to adapt it for the Nuvoton NCT5572D used on
the ASRock E350M1 in commit bf725b48 (superio/nuvoton/nct5572d: Add
PS/2 presence detect) [3]. So now, PS/2 devices work with this board!

So for all those of you, suffering from similar problems on different
boards using Winbond or Nuvoton Super I/Os, please give it try to do
similar adaptations, and submit patches!


Thanks,

Paul


PS: With proprietary, closed firmware, this would not have been
possible over six years after a board was released. (Though to be fair,
normally such things work right away with the shipped vendor firmware
when you buy a board.)


[1] https://raptorengineeringinc.com/content/base/main.htm
[2] https://review.coreboot.org/13165
[3] https://review.coreboot.org/13618




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

Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines

[Stefan Reinauer]

* Alex G.  [160131 00:05]:
> I conclude from these, that your assertion that this has been an
> unspoken rule, is not true. Furthermore, I believe that this arbitrary
> change was done as an act of spite towards a set of engineers. Also,
> since you, and the rest of the coreboot leadership have shown a pattern
> of first discussing changes to the project publicly, on the mailing
> list, I conclude that a discussion about this issue was deliberately
> avoided in order to prevent those engineers, as well as other coreboot
> community members, from presenting their arguments.

That is a really surprising statement coming from you, Alex, as you and I
have discussed this very topic in person several times, and I have
explained to you why I initially checked in Scott's patches with mixed
syntax and we both had agreed that in the long run the code has to be
rewritted in AT&T syntax. So now you are using the fact that there is no
log on the mailing list about this discussion to hurt the project and
create some sort of artificial divide in the community once again.

I am really disappointed in you.

  Stefan

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

Re: [coreboot] Long boot delay with a large CBFS

[Stefan Reinauer]

* Ben Gardner  [151116 19:32]:
> [The previous email got chopped. This is a re-send.]
> 
> Hi all,
> 
> I have a 16 MB BIOS flash on a fsp_baytrail based design.
> 
> I tried expanding the CBFS to fill the whole space, but found that to
> cause a 10-15 sec boot delay.

Sounds like your CBFS file got corrupted. Anything you can share about
your build (e.g. log, source code) will raise the chance of getting this
fixed.

Are you running without ME firmware? What do your sections look like in
the firmware descriptor?

Stefan


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

Re: [coreboot] Fwd: sgabios ans grub2 payload (without SeaBIOS)

[Stefan Reinauer]

* maxime de Roucy  [151105 10:32]:
> -- Forwarded message --
> From: maxime de Roucy 
> Date: 2015-11-05 10:25 GMT+01:00
> Subject: Re: [coreboot] sgabios ans grub2 payload (without SeaBIOS)
> To: Gerd Hoffmann 
> 
> 2015-11-05 10:16 GMT+01:00 Gerd Hoffmann :
> > That isn't going to work I think.  sgabios works by hijaking vgabios,
> > and when loaded as coreboot payload grub2 probably will not try to use
> > vgabios in the first place ...
> 
> It works great when sgabios is run by SeaBIOS even if serial support
> disable in seabios and grub (so I am sure the serial output is
> generated by sgabios).

Without SeaBIOS there is no way of doing intXX callbacks after coreboot
is finished running, that is why you wouldn't see any output in that
case.

Your two options are indeed to put the serial (or whatever output) code
in grub2 directly, or use SeaBIOS as an intermediate step.

Stefan


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

Re: [coreboot] setting up a bug tracker

[Stefan Reinauer]

* Alexander Couzens  [151110 05:30]:
> @Stefan/Patrick Can you create a CName for ticket.coreboot.org -> 
> coreboot.dtn10.de

Done.

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

Re: [coreboot] [RFC] Remove empty mainboard.c files up for review

[Stefan Reinauer]

* Paul Menzel  [151109 23:42]:
> Dear coreboot folks,
> 
> I pushed change set I379e4b1e1b1725648c6231bc6954ac3cc655a596
> (mainboard: Remove empty mainboard.c files) [1] for review.
> 
> ```
> mainboard: Remove empty mainboard.c files
> 
> All the deleted mainboard files contain no code besides some print
> statements denoting, that the init is executed.
> 
> If such statements are desired, this should be done in common code so it
> does not have to be added to each mainboard.
> 
> Therefore, also delete files with just print statements.
> ```
 
This is much appreciated. These files are really only boilerplate
(which could indicate that all of these ports are really incomplete,
but that's a different story ;)

I am going to submit the patch.

Stefan


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

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release

[Stefan Reinauer]

* Stefan Reinauer  [151027 21:39]:
> I want to add the following boards (and their chipsets and super ios)
> that have been in the tree and basically unmaintained for 10+ys:
> 
>  * arima/hdama
>  * digitallogic/adl855pc
>  * ibm/e325
>  * ibm/e326
>  * iwill/dk8s2
>  * iwill/dk8x
>  * newisys/khepri
>  * tyan/s2735 
>  * tyan/s2850 
>  * tyan/s2875 
>  * tyan/s2880 
>  * tyan/s2881
>  * tyan/s2882  
>  * tyan/s2885  
>  * tyan/s2891  
>  * tyan/s2892  
>  * tyan/s2895  
>  * tyan/s4880  
>  * tyan/s4882

CLs are up:

http://review.coreboot.org/#/c/12368/ and following.

Stefan



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

Re: [coreboot] setting up a bug tracker

[Stefan Reinauer]

* Patrick Georgi  [151105 19:00]:
> 2015-11-04 16:57 GMT+01:00 Martin Roth :
> > - Are there any required login methods? Does it need to support the
> > login types that review.coreboot.org supports?
> redmine has an omniauth plugin that should allow OpenID and OAuth2
> (Google/Github flavor).
> I'd prefer using that over yet another account database.

+2!

> > - Is (anonymous) public reporting desired, or do we want to require
> > sign-in and user validation first? (I'd vote for sign in)
> We're lucky with gerrit (or maybe OpenID is enough of a hurdle), but
> anonymous bug trackers tend to be extremely maintenance heavy to sort
> out the spam.
> I'd go for requesting OpenID/OAuth accounts, similar to gerrit.

Looking at how long it took for people to stop sending award bios
disassemblies around to the mailing list, I strongly encourage not
having an anonymous service. It's not doing the project a good service.

Stefan


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

Re: [coreboot] setting up a bug tracker

[Stefan Reinauer]

* Timothy Pearson  [151103 20:55]:
> Is Bugzilla out of the question?
 
I would like Bugzilla, too. 

Stefan
 

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

Re: [coreboot] Coreboot hackaton 2016 (proposal in Paris)

[Stefan Reinauer]

* David Hendricks  [151102 21:00]:
> Piggybacking on other conferences can certainly help overseas travellers. Are
> there other major conferences later in the year?
> 
> Hosting after FOSDEM 2016 actually seems ideal and it will be in Brussels (<2
> hours away by train, or <1 hour by flight). It is a bit soon after the Bonn
> conference, though but maybe that won't matter? This isn't intended to be a 
> big
> formal event anyway. If you get enough community members in the Doodle poll I
> think you should go for it :-)

I also want to double stress the importance of getting an official
invitation out early is crucial. People from overseas might need to go
through a visa application process to attend, which might take several
months (and is not seldomly tied to an official invitation)

Stefan



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

Re: [coreboot] A case for branching AGESA

[Stefan Reinauer]

* Alex G.  [151101 21:29]:
> Except for VX900 and sandybridge, every chipset implements its own SPD
> parsing routines.
 
Gee, let's keep VX900 around then, it's one of the few good examples ;)

> Alex

Stefan

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

Re: [coreboot] coreboot binary policy

[Stefan Reinauer]

* Alex Gagniuc  [151030 18:59]:
> On Fri, Oct 30, 2015 at 9:03 AM, Marc Jones  wrote:
> > It might be a good idea, but that might be too limiting
> 
> I think historically, it has been assumed that everything in blobs is
> open up for RE and modification. There are plenty of examples of
> people reverse-engineering stuff in blobs, and also modifying the blob
> itself [1]. First and foremost, we should protect the project, and
> with that, our contributors.

Alex, I think this is a great suggestion, but as I have explained to you
in person before, from a perspective of reaching a legal agreement this
is almost equivalent (if not more effort) than working on an agreement
to open source that code to begin with. The coreboot project's objective 
is not to reimplement what other people have done, but to change the
industry to create more open computing devices.

That said, if you want to drive an example terms of use with your
employer that fulfills your advanced criteria, you are more than welcome
to do so, and I believe it would serve as a role model in the silicon
industry.

I am happy to help with such an arrangement, and would be even happier
if we could just open source the code in question. But we can take this
offline.

> We can have a process where we might grant exceptions from these
> (proposed) rules to certain non-ISA blobs. For example, we might
> exempt microcode on the basis that (we believe) It's impractical to
> RE, and keeping that avenue open is not of any particular value.

Reverse engineering is impractical in all cases. Specifically this
document is focussing on what BLOBs we can ship in the 3rdparty/blobs
directory, not generally which BLOBs are allowed in coreboot.

In terms of many blobs (like FSP, hint hint), we are not even at the
point where we can redistribute them in 3rdparty/blobs yet. Adding
additional restrictions would, if anything, change nothing at all
(except that our users will have to get their own collection of BLOBs if
they want to participate).

> We can grandfather in existing blobs, or we can have a process where
> we keep them for a while (a year?) while we try to work out
> appropriate licensing terms with the power-that-be of said blob.

I would like to get the existing BLOBs into 3rdparty/blobs first before
we talk about removing them in a year (e.g. FSP, hint hint).

All the best,
Stefan


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

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release

[Stefan Reinauer]

* Aaron Durbin  [151028 14:52]:
> > Various improvements and important bug fixes, that will be introduced to a
> > master branch and affect all the coreboot boards, will not be automatically
> > applied to that separate AMD branch. Those coreboot developers which have
> > AMD boards and want to constantly use and test latest and greatest coreboot
> > builds, they will have to constantly check the coreboot commit log and
> > backport all these improvements and fixes to their separate (and soon to be
> > abandoned) AMD branch. That will be adding lots of unnecessary manual work
> > and draining lots of workhours, which otherwise could have been spent on
> > writing the bug reports or improving a coreboot code which is common for all
> > the coreboot-supported boards.
> 
> Those developers should then take a more active role in improving the
> code that is applicable to them. As it stands now, I don't see any
> work going in improving those code bases.

And there I am, waiting for people to review my AMD64 cleanup patches
since July ;-) hint hint. 

Stefan


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

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release

[Stefan Reinauer]

* Martin Roth  [151026 22:51]:
> I'd like to start a discussion about boards, chipsets, drivers, or
> other code that can be removed from the tree.
> 
> At the coreboot conference in Bonn, we discussed this some. I believe
> that we decided to wait until the next release/branch of the coreboot
> tree before removing anything.  By planning ahead and deleting the
> components immediately after the release, we can list the things that
> have been end-of-lifed in the branch release notes.
> 
> By discussing this on the mailing list instead of just pushing commits
> to the tree, we can get better buy in from all interested parties.
> 
> 
> I'd request that these be boards & chips that are no longer being
> produced, and haven't been updated in a few years.
> 
> These seem like good candidates to start the discussion:
>mainboard/via/epia-m700 - http://review.coreboot.org/#/c/7470
>northbridge/via/vx800 - http://review.coreboot.org/#/c/7471
> 
> As far as I can tell, the last real contributions to these came in
> 2009 - all the changes since then have been cleanup and modifications
> for other changes across the coreboot tree.
 
Since 2009 is really only 6ys ago, I'm a bit hesitant about the VX800
stuff (while leaving the older CN700 / CX700 in the tree)
It also seems VIA gave up on coreboot at this point, so it might not
matter, unless we want to work on bringing them back?

Is anybody in contact with VIA at this point?

> What other directories should be removed from the tree after the next release?

I want to add the following boards (and their chipsets and super ios)
that have been in the tree and basically unmaintained for 10+ys:

 * arima/hdama
 * digitallogic/adl855pc
 * ibm/e325
 * ibm/e326
 * iwill/dk8s2
 * iwill/dk8x
 * newisys/khepri
 * tyan/s2735 
 * tyan/s2850 
 * tyan/s2875 
 * tyan/s2880 
 * tyan/s2881
 * tyan/s2882  
 * tyan/s2885  
 * tyan/s2891  
 * tyan/s2892  
 * tyan/s2895  
 * tyan/s4880  
 * tyan/s4882

 
> Eventually it would be nice to be able to use submissions to
> board-status repo to determine what's being used.  We're just not at
> that point yet.

I think this is a hard problem. Churn on a board's or chipset's code
does not necessarily coincide with a board being used or the other way
around. A target might just be stable and working well.

We need to get to the point where 100% of the boards in the tree are
boot tested 100% of the time.

Stefan


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

Re: [coreboot] GPL license headers

[Stefan Reinauer]

>From my previous discussions with lawyers on the topic, the third
paragraph is unproblematic to remove. With resolutions of today's
monitors and keyboards often having a page down key, keeping the second
paragraph seems like a good compromise to stay friends with the legal
experts and err on the safe side.

Stefan

* ron minnich  [151021 05:41]:
> Let me ask around.
> 
> ron
> 
> On Tue, Oct 20, 2015 at 7:20 PM Martin Roth  wrote:
> 
> I haven't seen any disagreement that we get rid of the entire third
> paragraph.
> 
> Alex votes that we should get rid of the second paragraph of the
> header as well, and what Ron posted SEEMS to support that we can,
> although the wording in that license header might be different enough
> that it doesn't apply to our case.
> 
> Personally, I'm in favor of keeping the second paragraph.  It looks to
> me like the first paragraph just discusses distribution, not
> liability.  I don't really see any NEED to get rid of the second
> paragraph.
> 
> Are there any other thoughts either way on getting rid of the second
> paragraph?
> 
> Martin
> 
> 
> 
> On Tue, Oct 20, 2015 at 6:47 PM, Alex G.  wrote:
> > On 10/20/2015 10:54 AM, ron minnich wrote:
> >> Eben Moglen, who ought to know, guided us on the release rules for the
> >> Plan 9 GPL release.
> >>
> >> Here is what he told us could go in each file:
> >> /*
> >>  * This file is part of the UCB release of Plan 9. It is subject to the
> >> license
> >>  * terms in the LICENSE file found in the top-level directory of this
> >>  * distribution and at 
> http://akaros.cs.berkeley.edu/files/Plan9License.
> No
> >>  * part of the UCB release of Plan 9, including this file, may be
> copied,
> >>  * modified, propagated, or distributed except according to the terms
> >> contained
> >>  * in the LICENSE file.
> >>  */
> >
> > +2
> >
> >> On Tue, Oct 20, 2015 at 10:30 AM Patrick Georgi  >> > wrote:
> >>     Get (the right set of) lawyers to sign off on that.
> >
> > You were saying, Patrick?
> >
> > Alex
> >
> > --
> > coreboot mailing list: coreboot@coreboot.org
> > http://www.coreboot.org/mailman/listinfo/coreboot
> 

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


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

Re: [coreboot] [help]build cbfstool fail with cygwin64

[Stefan Reinauer]

I think switching to c99 per default is a great idea. The problem below should 
be fixed by http://review.coreboot.org/#/c/11666/ and the following patch.

Stefan

On Oct 19, 2015, Julius Werner  wrote:
>> is there anyway to dynamic define std to gnu99 when detect build with
>cygwin?
>
>cbfstool is already defining -std=c99. I don't see a strong reason why
>we shouldn't just change that to gnu99 globally.
>
 2. default build will error as below,
 HOSTCC cbfstool/cbfstool.o
 /cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c: In function
>'main':
 /cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c:1075:5: error:
>array
 subscript has type 'char' [-Werror=char-subscripts]
  if (tolower(suffix[0])=='k') {
  ^
>
>This sounds like an bug in cygwin and you should file it with them.
>They're probably implementing tolower() in their standard header as a
>macro which directly indexes an array with an argument. They should at
>least be casting the argument inside that macro or they are not
>POSIX-compliant.

-- 
Sent with https://play.google.com/store/apps/details?id=com.onegravity.k10.pro2";>K-@
 Mail - the evolution of emailing.-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Broadwell IGD (on Auron_Paine)

[Stefan Reinauer]

* Georg Wicherski  [151019 17:39]:
> Hi,
> 
> thanks to Marc Jones' SGD patch for the Auron board
> (f3214d02482a4104d7276f06d6b326b2a54c4262), I was able to get my
> Auron_Paine up to ramstage.
> 
> Unfortunately, the IGD code in soc/intel/broadwell/ appears to be
> somewhat broken. Based off Aaron's guidance on IRC, I've pin-pointed the
> issue to be within igd_setup_panel . The first gtt_read there seems to
> hang already (BIOS_SPEW log attached). Find my current code with those
> debug prints at . FWIW, I've
> tested with some commenting-out, etc. that it's any gtt_read that
> immediately causes a hang there. Also dumped the gtt_res, small excerpt
> from the log:
> 
> --8<--
> igd's gtt_res = { base=e000, size=100, limit=e0ff,
> flags=6201 }
> igd_init: waited for pre-graphics delay to pass
> igd_init: went through early init
> igd_init: RP1 graphics frequency is set
> gtt_read(PCH_PORT_HOTPLUG)
> --8<--
> 
> People on IRC mentioned that this is an issue that people may have run
> into before on Broadwell, any suggestions on how to fix the hang there?
> 
> 
> Thanks,
> G

Hi Georg,

it seems that the refcode binary was not running. Can you verify that
it was part of the image and gets executed?

Stefan



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

Re: [coreboot] steps before screen mods

[Stefan Reinauer]

* Mario Goljak  [150925 16:06]:
> Hi guys,
> 
> I just came across thinkpad forum thread where people are discuss about
> hardware mods for getting FHD screen on lenovo x220/x230 laptops.
> http://forum.thinkpads.com/viewtopic.php?f=43&t=106919&start=90
>  
> What do you guys think, will this affect coreboot at all? Are there any
> necessary steps before playing with the screen?


You probably want to force your display to digital 2, as well, like in
the example pictures on http://letsitbe.jugem.jp/?eid=62

In coreboot you can do that in the int15 handler code, part of the
mainboard ramstage code.

Stefan

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

Re: [coreboot] [help]build cbfstool fail with cygwin64

[Stefan Reinauer]

* Kurt Qiao  [150909 09:42]:
> does anyone try cygwin64 to build coreboot in windows7 64bit?
> i got fail when build cbfstool with cygwin64.

Can you try the following two patches to see if they solve your problem

http://review.coreboot.org/11636 Don't use fileno() to get file size
http://review.coreboot.org/11637 fmd: Use _fileno() on MINGW

Also, if that doesn't work try to replace the MINGW check with something
like #if defined (_WIN64) || defined (__CYGWIN64__) instead.

(Make sure to run make clean in the cbfstool directory before trying)

Stefan

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

Re: [coreboot] Acer Chromebook 15 debug

[Stefan Reinauer]

* John Lewis  [150830 18:43]:
> Hi Guys,
> 
> Coolstar Organisation wants to do his Windows thang with one of the
> Broadwell Chromebooks, so I'm trying to build a working ROM with 
> chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware-yuna-6301.59.B
> to give him a hand. Luckily USB debug works with this, so here is
> what I'm getting. What could I do next?
 
Do you happen to know if the hang happens at the same spot when using
serial?


> Incidentally, if I flash back my backup, it goes into recovery mode
> now every time I boot (flags are 0x489), I've tried pulling the
> battery to no avail. If anyone has a trick to get around that, I'd
> appreciate it, as the Acer is my main machine.
 
What is the recovery reason? ( at the recovery screen)


> -⁠John.
> 
> coreboot-⁠5cbe3a8-⁠dirty romstage Sun Aug 23 12:18:55 BST 2015
> starting...
> 
> PM1_STS:   8910
> 
> PM1_EN:
> 
> PM1_CNT:   
> 
> TCO_STS:    
> 
> GPE0_STS:  1ef82df0 187d4fdf 0005f240 
> 
> GPE0_EN:      
> 
> GEN_PMCON: 0200 2024 520b
> 
> Previous Sleep State: S5
> 
> CPU: Intel(R) Core(TM) i3-⁠5005U CPU @ 2.00GHz
> 
> CPU: ID 306d4, Broadwell E0 or F0, ucode: 001d
> 
> CPU: AES supported, TXT NOT supported, VT supported
> 
> MCH: device id 1604 (rev 09) is Broadwell F0
> 
> PCH: device id 9cc5 (rev 03) is Broadwell U Base
> 
> IGD: device id 1616 (rev 09) is Broadwell U GT2
> 
> CPU: frequency set to 2000 MHz
> 
> SPD: index 1 (GPIO47=0 GPIO9=0 GPIO13=1)
> 
> SPD: module type is DDR3
> 
> SPD: module part is HMT425S6AFR6A-⁠PB
> 
> SPD: banks 8, ranks 1, rows 15, columns 10, density 4096 Mb
> 
> SPD: device width 16 bits, bus width 64 bits
> 
> SPD: module size is 2048 MB (per channel)
> 
> Boot Count incremented to 8
> 
> ME: FW Partition Table  : OK
> 
> ME: Bringup Loader Failure  : NO
> 
> ME: Firmware Init Complete  : NO
> 
> ME: Manufacturing Mode  : NO
> 
> ME: Boot Options Present: NO
> 
> ME: Update In Progress  : NO
> 
> ME: Current Working State   : Normal
> 
> ME: Current Operation State : Bring up
> 
> ME: Current Operation Mode  : Normal
> 
> ME: Error Code  : No Error
> 
> ME: Progress Phase  : BUP Phase
> 
> ME: Power Management Event  : Pseudo-⁠global reset
> 
> ME: Progress Phase State: Waiting for DID BIOS message
> 
> ME: HSIO Version: 8705 (CRC 0xfbc2)
> 
> No FMAP found at ffe1.
> 
> FMAP: area RW_MRC_CACHE not found
> 
> No MRC cache found.
> 
> Starting Memory Reference Code
> 
> Initializing Policy
> 
> Installing common PPI
> 
> MRC: Starting...
> 
> Initializing Memory
> 
> MRC: Done.
> 
> MRC Version 2.6.0 Build 0
> 
> memcfg DDR3 clock 1600 MHz
> 
> memcfg channel assignment: A: 0, B  1, C  2
> 
> memcfg channel[0] config (00780008):
> 
>enhanced interleave mode on
> 
>rank interleave on
> 
>DIMMA 2048 MB width x16 single rank, selected
> 
>DIMMB 0 MB width x16 single rank
> 
> memcfg channel[1] config (00780008):
> 
>enhanced interleave mode on
> 
>rank interleave on
> 
>DIMMA 2048 MB width x16 single rank, selected
> 
>DIMMB 0 MB width x16 single rank
> 
> CBMEM: root @ 7cfff000 254 entries.
> 
> MRC data at ff7d0d9c 6246 bytes
> 
> Relocate MRC DATA from ff7d0d9c to 7cfeb000 (6246 bytes)
> 
> create cbmem for dimm information
> 
> -- 
> 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] i855GM on laptop - possible or not?

[Stefan Reinauer]

Hi Andrey,

* Andrey Korolyov  [150802 22:22]:
> I am trying to estimate amount of effort to make an old military Getac
> to work with coreboot (currently it runs Insyde with computrace-style
> code). All currently supported boards, lanner/em8510 and
> digitallogic/adl855pc are desktops, which means that I should play
> with EC support almost from scratch. Given the fact that i855G(M) was
> quite popular in P-M era, are there any real issues standing behind
> lack of support of a simular mobile platform in a tree?

The ADL855PC is an embedded module that is using the i855GME chipset
(the same as the Getac W130 as far as I remember).

Last I checked, the 855 port was not very good, but there's probably
nothing in the way of attempting to write a port for that laptop.

You should make sure you have some means of recovering your flash chip
back to something working, because writing a port and getting a system
booting typically takes a few tries ;)

Stefan


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

Re: [coreboot] Finding whether the BIOS is coreboot or not

[Stefan Reinauer]

* ron minnich  [150718 18:10]:
> Could you also look for LBIO in the e and f segments?

Since we moved the coreboot tables out of e and f you won't find
anything like that anymore.

1. Use cbmem tool
2. Dump coreboot table with nvramtool
3. dmidecode
4. ACPI table vendor
5. flashrom -r and check the image for CBFS, ID and master header

Stefan

> On Sat, Jul 18, 2015 at 12:34 AM Patrick Georgi  wrote:
> 
> 2015-07-18 9:03 GMT+02:00 Kevin Wilson :
> > Is there a way, from a device running Linux,  to which I have access
> > to the command line, to know
> > whether the BIOS is coreboot or not ? by some utility, or by some sysfs
> entry ?
> We usually have coreboot related vendor names for ACPI tables (eg.
> dsdt table id 'COREBOOT'). Those are visible early on in dmesg, I
> think.
> Also our cbmem utility (coreboot source tree, util/cbmem) can print a
> coreboot specific table's content.
> 
> Neither of these are guaranteed to be around (it would be possible to
> cloak things thoroughly), but it's likely that they are on coreboot,
> and pretty much non-existent otherwise.
> 
> 
> 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 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] No code in SMM handler address (0xa0000)

[Stefan Reinauer]

* Yu-Cheng Liu  [150724 09:13]:
> hello,
> Here I have some questions in smi.c file (coreboot/src/southbridge/intel/
> i82801ix/smi.c)
> 
> in smm_install function, one statement is to copy handler to SMRAM(0xa):
> 1.I can't find copy source data ( _binary_smm_start ),where is it write? I
> watch (_binary_smm_start) memory address,and it has value in it.

The SMM handler is created as a separate binary that is then copied to
0xa. This binary is produced by src/cpu/x86/smm/Makefile.inc
> 
> 2.After execute the memcpy statement,there is nothing change in 0xa,the
> value in 65535

What do you mean by that?

After memcpy is done, the SMM region is locked again, so you will see
VGA memory shadowed over it, as long as you are not actually in SMM.

> In smm_relocate function, the pointer goes in the " if " statement and then
> "return" , the relocation code did not copy to 0x38000:
 
> 3.How do I let the program go through and do the job below the " if "
> statement?

>From when I was playing around with Qemu last, its SMM implementation is
not 100% correct. You should probably look at some actual hardware here.

Stefan 


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

Re: [coreboot] How to trigger SMI and implement SMM

[Stefan Reinauer]

* Yu-Cheng Liu  [150721 11:04]:
> Hello,
> 
> I purpose to trigger SMI event and do something in SMM mode .
> 
>  
> 
> I trace the coreboot source code and found that, during the coreboot
> environment setup, the file locate at southbridge/intel/i82801ix/smi.c  will 
> be
> excute. Is it enough for SMI/SMM operation?

That is just the code that installs the SMM handler (well, part of it)

> I didn’t see the code under cpu/smm be locate in the ramstage.debug symbol.

The SMM handler is a separate module.

> What is the different purpose between southbridge/intel/i82801ix/smi.c and 
> /cpu
> /x86/smm?

The code in southbridge/intel/i82801ix/smi.c is the chipset specific SMI
initialization. southbridge/intel/i82801ix/smihandler.c is the chipset
specific SMI handler.

The code under cpu/x86/smm is generic for the x86 architecture.

> How do I trigger the SMI event?

Typically hardware triggers an SMI, e.g. on a GPE event, timeout, or
such. See southbridge/intel/i82801ix/smihandler.c for a more
comprehensive list of southbridge SMI sources.

You can also use the APMC SMI command mechanism to manually trigger
SMIs, see southbridge_smi_apmc(void) for details.

Stefan

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

Re: [coreboot] cbfs alignment

[Stefan Reinauer]

* ron minnich  [150717 21:45]:
> riscv is taking alignment traps reading cbfs.
> 
> The issue is that 64-bit fields are 32-bit aligned, which fails many places.
> 
> Thaminda found this comment: 
> 
>   * Since coreboot is usually compiled 32bit, gcc will align 64bit
>     types to 32bit boundaries. If the coreboot table is dumped on a
>     64bit system, a uint64_t would be aligned to 64bit boundaries,
>     breaking the table format.

This statement is true for coreboot tables. CBFS files are aligned
to 64 bytes by default.

You can see if your compiler supports -mno-unaligned-access which will
get rid of the problem for you.

> We can fix it, with an ugly macro, but ... what's the right move here?

1. The cleanest solution would be to have our read32/write32 functions
   exist in aligned and unaligned versions and using the latter for
   accesses to packed data structures. Also the most intrusive, in the
   code base
2. Enable -mno-unaligned-access. 
3. Enable some mechanism in the CPU that will take care of unaligned
   accesses. That's what we do on ARM
4. Write an exception handler that takes care of the problem for you.

Stefan


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

Re: [coreboot] Cbfstool compilation error with gcc 5.1

[Stefan Reinauer]

* Anatol Pomozov  [150531 08:49]:
> Hi
> 
> I am trying to compile coreboot cbfstool on Arch where gcc 5.1 is used. And I
> see following compilation error. I wonder if it is coreboot or gcc issue.
> 
> ==> Starting build()...
> make: Entering directory 
> '/home/anatol/sources/archpackages/coreboot-utils-git/
> src/coreboot/util/cbfstool'
> mkdir -p ./
> cc -D_FORTIFY_SOURCE=2 -D_DEFAULT_SOURCE  -D_POSIX_C_SOURCE=200809L  
> -Iflashmap
> -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=
> ssp-buffer-size=4 -g3 -std=c99 -Werror -Wall -Wextra -Wcast-qual
> -Wmissing-prototypes -Wredundant-decls -Wshadow -Wstrict-prototypes
> -Wwrite-strings -c -o rmodule.o rmodule.c
> rmodule.c: In function ‘rmodule_create’:
> rmodule.c:286:29: error: ‘phdr’ may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
>         (phdr->p_vaddr + phdr->p_memsz))) {
>                              ^
> rmodule.c:203:14: note: ‘phdr’ was declared here
>   Elf64_Phdr *phdr;
>               ^
> cc1: all warnings being treated as errors
> Makefile:55: recipe for target 'rmodule.o' failed
> make: *** [rmodule.o] Error 1
> make: Leaving directory '/home/anatol/sources/archpackages/coreboot-utils-git/
> src/coreboot/util/cbfstool'
> ==> ERROR: A failure occurred in build().

Looks like a false positive. ctx-phdr only gets passed on if nelements
is 1, in which we know that phdr was set.

Stefan


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

Re: [coreboot] Flashrom won't work with DediProg SF100 fw 6.5.03

[Stefan Reinauer]

* Steve Goodrich  [150602 20:38]:
> I got the Chromium version of flashrom to work, but it takes 20 minutes to
> flash/verify the 8 MB device.  So, while "working" is far better than "not
> working", it is a bit sluggish.  :-)

I seem to remember there are two ways flashrom can program through a
dediprog, the slow one that always works, and the fast one that we
didn't know which chips it's working with, so it defaults to the slow
path.

Stefan

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

Re: [coreboot] coreboot community chat (request for feedback)

[Stefan Reinauer]

Hey folks!

It's been a few days since our community meet-up, and I would like to 
ask
you to fill out a quick (1min) poll about the meeting. Please have a 
look,

even (or especially) if you couldn't participate:

  https://goo.gl/FoQgWo

Please let me know any feedback you can think of, or how we can improve 
the meeting.


Thanks,
Stefan

On 2015-05-06 21:05, Stefan Reinauer wrote:

Hi coreboot community!

In order to have more face time and a more personal connection with 
each

other than it is possible on the coreboot IRC channel, I would like to
invite you to participate in a monthly video conference to discuss the
up and coming projects, ideas and issues that all of us are involved 
in.


We suggest to have these meetings via Google Hangouts, as we have
figured out in the past that other alternatives like Mumble didn’t work
as well for us.

So I would like to invite interested contributors of the community to
join us. The first video conference will be on Thursday, May 21th at
9:15am Pacific Time (16:15 UTC). The meeting can be joined by clicking
on this link: http://goo.gl/SD6t3G. If, for some reason you can not
access Hangouts, we can try and call you (no promises). Please let me
know ahead of time if you need assistance!

The agenda for the first meeting is available here: 
http://goo.gl/7E0zYz


Looking forward to seeing y’all!

Stefan



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

Re: [coreboot] coreboot community chat

[Stefan Reinauer]

Quick reminder: This is coming up tomorrow (about 18h from now)

Looking forward to seeing you all

Stefan

* Stefan Reinauer  [150507 06:05]:
> Hi coreboot community!
> 
> In order to have more face time and a more personal connection with each
> other than it is possible on the coreboot IRC channel, I would like to
> invite you to participate in a monthly video conference to discuss the
> up and coming projects, ideas and issues that all of us are involved in.
> 
> We suggest to have these meetings via Google Hangouts, as we have
> figured out in the past that other alternatives like Mumble didn’t work
> as well for us. 
> 
> So I would like to invite interested contributors of the community to
> join us. The first video conference will be on Thursday, May 21th at
> 9:15am Pacific Time (16:15 UTC). The meeting can be joined by clicking
> on this link: http://goo.gl/SD6t3G. If, for some reason you can not
> access Hangouts, we can try and call you (no promises). Please let me
> know ahead of time if you need assistance!
> 
> The agenda for the first meeting is available here: http://goo.gl/7E0zYz
> 
> Looking forward to seeing y’all!
> 
> Stefan
> 
> 
> 
> -- 
> 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] [poll] device_t

[Stefan Reinauer]

* ron minnich  [150507 21:35]:
> one counter-question: is romcc ever going away, or at least is the usage
> gong to change such that no code would ever use the uint32 version of
> device_t? 
> 
> 
> If it's *never* going away then I think the change makes no sense. If romcc is
> going away, then I would favor the change.

With our current bootblock concept, it is never going away on x86 (for
bootblock usage)

Stefan


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

[coreboot] [poll] device_t

[Stefan Reinauer]

Since Edward started hijacking patches on gerrit to push his
agenda of getting rid of device_t without prior discussion,
I would like to start a poll on how people think about this,
and maybe find reasons for why it might be a good idea.

Edward wrote:
> The issue of 'device_t' has many heads. The primary issue I have here
> is that these patches introduce many more 'device_t' instances that
> make the job of sorting out which 'device_t' are 'uint32_t' and which
> are 'struct device *' significantly harder as this sort of thing
> progresses.

> If the author would just use 'struct device *' and there is (for some
> wrapped reasoning) a consensus to only use 'device_t' then it is trivial
> to go do 's/struct device * /device_t /g'.
> There is actually no reason needed here to use a opaque type which was
> invented to solve a particular issue however has now spilled over to
> becoming rampant though the tree.

The reality here is that device_t was a concept used ever since coreboot
v2 (LinuxBIOS v2 from 2003 actually) existed. It is indeed the use of
struct device that has accidently spilled over.

The reason this was done was to use the same driver code in romstage and
ramstage. While this can be achieved by other means, no doubt, I don't
think that this churn on the code base is particularly useful.

Before we continue on this path I would like to see a reason for not
using device_t or why the difference between the type has to be sorted
out. The whole idea is that it does not matter, and the code does not
have to know.

Check out the poll at https://doodle.com/vvqtyhdxr9yhvqci

Stefan


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

[coreboot] coreboot community chat

[Stefan Reinauer]

Hi coreboot community!

In order to have more face time and a more personal connection with each
other than it is possible on the coreboot IRC channel, I would like to
invite you to participate in a monthly video conference to discuss the
up and coming projects, ideas and issues that all of us are involved in.

We suggest to have these meetings via Google Hangouts, as we have
figured out in the past that other alternatives like Mumble didn’t work
as well for us. 

So I would like to invite interested contributors of the community to
join us. The first video conference will be on Thursday, May 21th at
9:15am Pacific Time (16:15 UTC). The meeting can be joined by clicking
on this link: http://goo.gl/SD6t3G. If, for some reason you can not
access Hangouts, we can try and call you (no promises). Please let me
know ahead of time if you need assistance!

The agenda for the first meeting is available here: http://goo.gl/7E0zYz

Looking forward to seeing y’all!

Stefan



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

Re: [coreboot] [Announcement] Please rebuild utility cbmem after new addition of time stamps

[Stefan Reinauer]

* Paul Menzel  [150423 22:43]:
> With old cbmem:
> 
>   15:starting LZMA decompress (ignore for x86) 238,557 (211)
>   16:finished LZMA decompress (ignore for x86) 255,012 (16,454)
> 
> After rebuilding cbmem:
> 
> 12 entries total:
> 
>   15: 238,557 (211)
>   16: 255,012 (16,454)

... or possibly the other way around. :-)

Stefan


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

Re: [coreboot] Question on VGA BIOS extraction

[Stefan Reinauer]

* Iru Cai  [150330 18:24]:
> Hi,
> 
> I'm trying to build Coreboot for ThinkPad X220. I first backup the vendor 
> BIOS,
> then use UEFITool to extract a VBIOS. The romheader program detects the ROM's
> PCI data structure and reports the device id is 8086:0106, but the VGA
> controller's device id is 8086:0126. I extracted the video ROM from a running
> X220 memory and use romheader to test it, the result is still 8086:0106. How
> could this happen?

The same VGA OPROM binary is used for a whole set of different chipsets.
However, the PCI header specification does not have a way to express
that. The main system firmware has to know that, for a 0x0126 device it
has to look for the 0x0106 OPROM. Hence coreboot has a mapping function
for most newer (Intel) chipsets.

Stefan


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

Re: [coreboot] GCC update broke AMD Fam10h boot

[Stefan Reinauer]

* Aaron Durbin  [150316 22:44]:
> A quick hack is add ALIGN(32) to the linker script before
> _bs_init_begin: src/arch/x86/ramstage.ld
> 
> But I think we'll need to store pointers to the structures in order to
> properly handle the situation where the compiler is effectively making
> alignment/size decisions for some reason.

I suggest trying to enforce alignment / size instead of adding another
layer of indirection.

Stefan


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