coreboot October 2017

coreboot@coreboot.org

66 participants
140 discussions

Re: [coreboot] Recommendation for Flashing Clips / mass order
by Peter Stuge 19 Oct '17

19 Oct '17

[799] via coreboot wrote: > Do you have any recommendations if it makes sense to invest a bit > more budget and buy a more expensive clip or will the quality be > the same? > > The Pomona 5250 Clip: > https://www.tme.eu/gb/details/pom-5250/test-clips/pomona/5250/ I have no idea about the clip you used before, but the Pomona 5250 plastic compound is not very hard and contacts are not very robust, so after some (ab)use it will certainly also wear out. These clips are test tools for occasional use, not development tools. You can obvioulys use them for development anyway, but keep in mind what they are designed for, so that you have the right expectations. //Peter

4 5

Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
by Аладышев Константин 18 Oct '17

18 Oct '17

Ok, I've done some investigations about what can be the source of my problem: 1) last value of COMMAND register from BIOS I've dumped all EHCI registers (pci and memory) at the beginning of linux kernel EHCI initialization. And to my surprise pretty all memory registers in original BIOS look like almost uninitialized compared to my coreboot+seabios image. I don't really know how to work with EHCI controller, but seabios do it through periodic and async schedule and their enable bits (in COMMAND register from commit!) aren't active in original BIOS. I've tried to disable ehci initialization in seabios and after that registers dump started to look almost the same, compared to original bios, but it didn't solve my issue. Also without them USB doesn't work in grub. So it doesn't seem like BIOS last value of COMMAND register really matter. 2) SMI There are special registers for EHCI controller SMIs in its pci config space: -USB EHCI Legacy Support Extended -Intel Specific USB 2.0 SMI But in both of them SMIs are disabled as in coreboot+seabios image as in original bios. 3) ACPI In original BIOS ACPI doesn't do anything to EHCI COMMAND register from commit. It doesn't have a name for it or declare it in some region. Anyway I've copied almost all asl EHCI controller code, but it didn't help. BUT! I've provided MP-table and PIRQ table to coreboot and I can say that the problem disappears when I boot with 'acpi=off' parameter! Also it disappears when I boot with 'nolapic' parameter What do they have in common?? -----Original Message----- From: jwerner(a)google.com [mailto:jwerner@google.com] On Behalf Of Julius Werner Sent: Tuesday, October 10, 2017 5:56 AM To: Аладышев Константин Cc: Coreboot Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards > And now I'm kinda stuck. The effect of this commit doesn't seem to > interface with bios for me. So how does original IBASE/DFI bios can > overcome code error before this commit? > > What can be the source of my problem? What should I investigate more > precise based on result that I've got? My gut feeling would be to blame ACPI. The Linux patch is about caching a host controller register in the kernel, and in some cases (e.g. ehci_reset()), the patch re-reads the cached version from the hardware whereas the previous code didn't. If some BIOS ACPI mucks with that register, it's possible that this got the kernel's cached copy out of sync before this patch, but with the patch the kernel will re-read it from the hardware at the right time. Maybe only coreboot's ACPI routines touch the register in that path, or maybe the vendor BIOS' routines were more careful to restore the original state afterwards. Besides ACPI this could also be in SMM code, I guess (especially if the problem occurs around system suspend/resume, although it sounds like it doesn't for you).

1 0

Re: [coreboot] coreboot Digest, Vol 152, Issue 25
by Alexandre Desnoyers 18 Oct '17

18 Oct '17

Hi Peter, We only used Coreboot on the FT1 for testing some audio codec initialization and PCIe hotplug before requesting our proprietary BIOS vendor to make the modifications. We've not used Coreboot in production for this project. So there is no wishes from our SW developer to support Coreboot on our FT1 platform. Basically, for us, Coreboot on the FT1 was a proof of concept to prove that it's actually working and can be used for board bring-up by enabling all the AGESA debugging output. We have our new custom FP4 SoC module using Coreboot that my colleague Ricardo Ribalda will try to upstream in the next few months. We just need more real-life testing before we upstream. If by chance you are at the Embedded Linux Conference Europe next week, you can see our demo on Tuesday October 24th between 17h35 and 19h30, and talk with Ricardo. Thank you Alexandre Desnoyers Electronic Design Engineer Qtechnology A/S Valby Langgade 142, 1.sal - 2500 Valby - Denmark - www.qtec.com coreboot-request(a)coreboot.org wrote: > Date: Tue, 17 Oct 2017 11:31:20 +0000 > From: Peter Stuge<peter(a)stuge.se> > To:coreboot@coreboot.org > Subject: Re: [coreboot] Add socket support for amd/socket-ft1? > Message-ID:<20171017113120.GO4167(a)stuge.se> > Content-Type: text/plain; charset=us-ascii > > Hey Alexander, > > Alexandre Desnoyers wrote: >> I can tell you that this persimmon motherboard is booting on my own >> FT1 custom SoC design with very few changes. > Can we encourage you to post a patch to include your board into the > coreboot repository? > > > //Peter

1 0

Recommendation for Flashing Clips / mass order
by [799] 18 Oct '17

18 Oct '17

Hello, after learning about Coreboot and how to flash, my cheap flashing clip stopped working. Do you have any recommendations if it makes sense to invest a bit more budget and buy a more expensive clip or will the quality be the same? The Pomona 5250 Clip: https://www.tme.eu/gb/details/pom-5250/test-clips/pomona/5250/ As getting the Clip and attaching the wires to it and then attach those to the Raspberry Pi, has someone thought about ordering some more and offer preconfigured Coreboot Kits maybe also through the Coreboot website with additional costs to support the Coreboot project. Unique selling point: add some stickers :-) Seriously I would be happy if I could save my time to get all the parts together and if I could get a prebuild "flashing kit" I would have bought it. [799]

1 0

Re: [coreboot] [RFC] Successful build with GCC 7.2 and IASL 20170831 for coreboot 4.7
by Paul Menzel 18 Oct '17

18 Oct '17

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. Especially for bisecting an issue, people don’t rebuild the toolchain in each step. In practice, people also don’t rebuild the toolchain each time, as it takes so much time. And going back, and being hold up, because there are build problems with the new toolchain is very inconvenient. Also, I believe the build system does not warn about, if you use a newer toolchain. The good side is, that most warnings and errors of newer toolchains actually point out real problems – most of them don’t affect anything though –, so fixing those would be a good thing. Thanks, Paul

3 2

vboot/futility: Two Clang 5 warnings: address-of-packed-member and enum-conversion
by Paul Menzel 18 Oct '17

18 Oct '17

Dear coreboot folks, Clang 5.0 shows the warnings below. I don’t know if Clang 4.0 also warns about these. ``` CC firmware/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. ``` Thanks, Paul

2 1

Re: [coreboot] AGESA fam15 code removals
by Stefan Reinauer 18 Oct '17

18 Oct '17

* Martin Roth via coreboot <coreboot(a)coreboot.org> [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

1 0

ASUS KFSN4-DRE Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 18 Oct '17

18 Oct '17

The ASUS KFSN4-DRE fails verification for branch master as of commit 530c6f9cc8dd2c0cd0c586d3d14f11cb8021242f The following tests failed: BOOT_FAILURE Commits since last successful test: 530c6f9 intel/cannonlake_rvp: enable HS400 See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] Does coreboot table still exist in F000 segment?
by Stefan Reinauer 17 Oct '17

17 Oct '17

* WANG FEI <wangfei.jimei(a)gmail.com> [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

1 0

Re: [coreboot] Does coreboot table still exist in F000 segment?
by Marc Jones 17 Oct '17

17 Oct '17

I believe that is a seabios option. On Fri, Oct 13, 2017 at 12:21 PM WANG FEI <wangfei.jimei(a)gmail.com> wrote: > 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. > > -Fei > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- http://marcjonesconsulting.com

1 0

← Newer
1
2
3
4
5
6
7
8
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2017