[coreboot] Sandybridge: native ram init

Hello, I'm trying to get the GA-B75M-D3H to work, but I'm stuck at native ram init. It stops at c320c discovery failed. I figured out that the lower 4 lanes 0-3 are always erroneous in this test. The upper 4 lanes are working as expected and return errors depending on the skew chosen. All

[coreboot] PciExpressGraphics on Intel Sandybridge

Hello, I'm currently working on enabling PEG and run into some trouble. With pending patches [1] applied, I was able to activate the Nvidia GPU. The system hangs at Seabios/Grub2 with 2 GPUs enabled at the same time. As I'm using the EHCI Debug Port I don't have any Seabios console output. Is

Re: [coreboot] Discussion about dynamic PCI MMIO size on x86

On 2016-06-06 09:58 PM, ron minnich wrote: > On Mon, Jun 6, 2016 at 12:52 PM Patrick Rudolph <s...@das-labor.org> > wrote: > >> To summarize: >> The easy way is to use 2G. >> The preferred way would be to mimic mrc behaviour and reboot after >> finding t

Re: [coreboot] Discussion about dynamic PCI MMIO size on x86

To summarize: The easy way is to use 2G. The preferred way would be to mimic mrc behaviour and reboot after finding the correct size. On 2016-06-06 09:36 PM, ron minnich wrote: > I'm getting the sense here that reasonably modern CPUs can easily > handle the 2G hole. From what I've seen, it would

Re: [coreboot] Discussion about dynamic PCI MMIO size on x86

On 2016-06-03 05:41 PM, Aaron Durbin via coreboot wrote: > On Fri, Jun 3, 2016 at 7:04 AM, Patrick Rudolph <s...@das-labor.org> wrote: >> Hello, >> I want to start a discussion about PCI MMIO size that hit me a couple of >> times using coreboot. >> I'm focused

[coreboot] Discussion about dynamic PCI MMIO size on x86

Hello, I want to start a discussion about PCI MMIO size that hit me a couple of times using coreboot. I'm focused on Intel Sandybridge, but I guess this topic applies to all x86 systems. On most Intel systems the PCI mmio size is hard-coded in coreboot to 1024Mbyte, but the value is hidden deep

Re: [coreboot] 16GB dimm on Sandy/Ivy Bridge status

Hi Iru, >From T420 manual [1]: "Memory: Up to 8GB DDR3 - 1333MHz (2 DIMM Slots)" While it seems possible to use 16GB (2x 8GB), it isn't possible to use 16GB DIMMs. I haven't tested by myself, but it seems like a hardware limitation. Please provide raminit logs, just to make sure. Regards,

Re: [coreboot] T420 Optimus/NVIDIA GPU support

On 2016-06-26 07:25 AM, Intel Miner wrote: > Hi everyone, > > Apologies if this is the wrong place to ask about this, but > > I'm eyeing off buying a Lenovo T420 ThinkPad, specifically one with the > NVIDIA GPU, with "Optimus" support > > The information I can dig up on the initial support says

Re: [coreboot] Linux as payload

On 2016-04-07 06:31 PM, daoud yessine wrote: > Hi > > how to build coreboot with linux as payload ? > I need Bzimage only ? > what about the file system ? > > thanks > ᐧ Hello, I'm using a linux payload. Here are a few pitfalls you should mind: * Fedora's prebuild kernel doesn't work any

Re: [coreboot] ThinkPad x220 - Status

On 2016-05-23 05:20 PM, Nuno Moreira wrote: > Hi Iru, Arian and Alexander. > Thanks a lot for your feedback :) > > Trying to reply to your input and presenting some questions emerging > from it: > > [IRU] "X220 has been supported for years :)" > [/ME] Indeed. My mistake. After a better Internet

Re: [coreboot] SeaBios serial(RX) is not running.

Seabios isn't able to read from serial, as it would require to map several received characters to scancodes. You can try sgabios, an option rom that works over serial. In theory adding serial rx support to Seabios using sgabios source code should be simple. Regards, Patrick On 2016-05-17 04:01

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

On 2016-05-06 02:45 AM, Zheng Bao wrote: > Hi, All, > Is there any way to protect the binary image in flash chip from being > copied? Once the customers > gets the image, they can produce millions of board and do not tell me. > I just want to know the > amount of the mass production. > > OTP

Re: [coreboot] Strange postcodes

Hi. Most post codes use pre defined values instead of hardcoded values ( src/include/console/post_codes.h) . Sadly there's no documentation of possible post codes, as it's board specific. Binary blobs, like Intel mrc.bin, have their own 16bit post code set. Asm code is of course sending post

Re: [coreboot] anyone use coreboot on Lenovo T520?

On Thu, 8 Sep 2016 19:25:15 +0800 Iru Cai <mytbk920...@gmail.com> wrote: > Hi Patrick, > > On Wed, Sep 07, 2016 at 05:36:45PM +0200, Patrick Rudolph wrote: > > On Wed, 7 Sep 2016 21:15:05 +0800 > > Iru Cai <mytbk920...@gmail.com> wrote: > > > >

Re: [coreboot] More details about ram issues

Am Tue, 8 Nov 2016 02:15:31 -0500 schrieb Charlotte Plusplus : > Hello > > I have done further ram testing. > > My first guess was to disable the XMP code - it didn't help, but I > may have done things wrong as I was trying with a normal and a > fallback mode to try

Re: [coreboot] Patch: support for the Lenovo Thinkpad W520

Hello Charlotte, thanks for adding support for W520. Am 06.11.2016 um 09:33 schrieb Charlotte Plusplus: Hello I am new to coreboot. I tried to run coreboot on my Thinkpad W520 to replace my Sandy Bridge CPU by a Ivy Bridge CPU, since several people reported it worked very well. Following

Re: [coreboot] More details about ram issues

Am Fri, 11 Nov 2016 13:53:16 +0100 schrieb Nico Huber : > Hi Charlotte, > > On 11.11.2016 08:14, Charlotte Plusplus wrote: > > So I did many more tests today (more than 6h, and flashing around 30 > > times), with SPD settings hardcoded into raminit, and without the > > mrc cache

Re: [coreboot] VGA and Graphics

VBT is documented by intel-gpu-tools. There's intel_vbt_decode (former intel_bios_decode) available https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tools/intel_vbt_decode.c that will print all tables in human readable form. Regards Patrick Am 4. April 2017 20:45:15 MESZ schrieb Nico

Re: [coreboot] Coreboot gamers?

None of the features you listed are implemented as there's no public documentation how to change those values. It might be possible to decrease the critical temperature limit, which would reduce CPU clock speed once it gets too hot. Have a look at the t420 mainboard specific configuration.

Re: [coreboot] ThinkPad X230 with working truncated ME and 11 MB space for payload

On Tue, 18 Apr 2017 16:08:09 +0200 Marek Behun wrote: > > I would try the following to narrow it down: Run the memory training > > with the original ME firmware; keep the MRC cache intact while > > switching to the truncated ME firmware; boot. If it doesn't work > > with the

[coreboot] Discussion about fixing dead code / ACPI TRAP

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

Re: [coreboot] [RFH] Please test current code on your devices before coreboot 4.6 release

Hi Persmule, I did some tests on thinkpad T430. I disabled SeaBios CONFIG_TCGBIOS and was able to communicate with TPM in GNU Linux, did a self test and took ownership. It doesn't report as temporarily deactivated any more. It looks like SeaBIOS' TPM driver is broken, possible related to this

[coreboot] Intel GMA: Backlight brightness driver

Dear coreboot users, The following commit adds Mailbox 3 support for improved panel back- light brigthness control on Intel GMA platforms. It fixes the problem with 100% brightness on S3 resume. Please test and review https://review.coreboot.org/#/c/coreboot/+/27711 / Regards, Patrick --

Re: [coreboot] Intel GMA: Backlight brightness driver

On 2018-07-29 06:39 PM, Alexander Couzens wrote: > Hi Patrick, > > thanks for your work. > Are there any documentation or description what Mailbox 3 support is? > Where it come from? > It's documented here: https://01.org/sites/default/files/documentation/skl_opregion_rev0p5.pdf > Best, >

[coreboot] coreboot ThinkPad users

Dear coreboot ThinkPad users, with the current master (and next stable release) it is possible to power cycle the BDC (Bluetooth Daughter Card) from within an ACPI compliant OS. As the implementation follows the vendors one, all you need is to use existing drivers, like the thinkpad_acpi kernel

Re: [coreboot] More ACPI errors on Lenovo X201i

Hi Matthias, On 2018-07-23 03:32 PM, Matthias Gazzari wrote: > Hi Patrick, > > I found new ACPI errors on my Lenovo X201i: > > commit "60eca531df ec/lenovo/h8/acpi: Add WWAN ACPI methods" introduces > the following error just before shutdown: > > thinkpad_acpi_ acpi_evalf(\WGSV, vd, ...)

Re: [coreboot] ACPI Errors on Lenovo X201i

e > { > Return (Zero) > } >} > >Method (SBDC, 1, NotSerialized) >{ > If (HBDC) > { > Local0 = ((Arg0 & 0x02) >> One) > BTEB = Local0 > } >} > >Hope that helps. > >Cheers,

Re: [coreboot] ACPI Errors on Lenovo X201i

; Return (Local0) > > > } > > > Else > > > { > > > Return (Zero) > > > } > > > } > > > > > > Method (SBDC, 1, NotSerialized) > > > { > > > If (HBDC) > > > { > > &g

Re: [coreboot] ACPI Errors on Lenovo X201i

Hi Matthias, It looks like the Ssdt generator on x201/nehalem doesn't work as expected. It was broken and has been fixed in commit https://review.coreboot.org/#/c/coreboot/+/26287/ Do you see "ACPI:* H8" in coreboot console log ? Do you see any HBDC method in disassembled ACPI ? Regards

[coreboot] armv8 mmu limitation?

This commit enables 48 bits on all armv8 SoCs: https://review.coreboot.org/#/c/coreboot/+/24970/ Regards, -- Patrick Rudolph 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudo...@9elements.com Phone: +49 234 / 68 94 188 Sitz der Gesellschaft: Bochum

Re: [coreboot] How to handle vbt.bin

On Thu, 2018-04-05 at 11:34 -0500, Matt DeVillier wrote: > On Thu, Apr 5, 2018 at 11:29 AM, Nico Huber wrote: > > On 05.04.2018 18:15, Matt DeVillier wrote: > > > my instinct is to put it in the 3rd party blobs repo, since it's > > added to > > > the CBFS w/o modification (ie, is

Re: [coreboot] How to handle vbt.bin

On Sun, 2018-04-15 at 13:43 +0200, Nico Huber wrote: > On 15.04.2018 12:48, Patrick Rudolph wrote: > > On Thu, 2018-04-05 at 11:34 -0500, Matt DeVillier wrote: > > > On Thu, Apr 5, 2018 at 11:29 AM, Nico Huber <nic...@gmx.de> wrote: > > > > On 05.04.2018 18:15

Re: [coreboot] How to handle vbt.bin

On 2018-04-15 11:30 PM, Nico Huber wrote: > On 15.04.2018 17:12, Patrick Rudolph wrote: >> On Sun, 2018-04-15 at 13:43 +0200, Nico Huber wrote: >>> On 15.04.2018 12:48, Patrick Rudolph wrote: >>>> On Thu, 2018-04-05 at 11:34 -0500, Matt DeVillier wrote: >>>&

Re: [coreboot] ARMv8 MMU changes

o for now. I'd really want to avoid using a 4KB granule, as I'd have to implement either level0 page talbes, or use PA!=VA mappings. Regards, Patrick > Thanks, > Julius -- Patrick Rudolph 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudo...@9elements.com

Re: [coreboot] romstage prints from qemu-440bx emualtor

Hi Ron, There's a patch on Gerrit that (indirectly) fixes the issue: https://review.coreboot.org/c/coreboot/+/29578 Regards On November 11, 2018 9:36:00 PM GMT+01:00, ron minnich wrote: >So, with latest tip of tree, I still get no romstage prints. I'm told >that's fixed, can someone here test

Re: [coreboot] Loading Linux payloads on RISC-V

On 2018-09-26 10:29 PM, Philipp Hug wrote: > In my local tree I just added the ram address in selfboot. > Doing this beforehand with cbfstool would be even better. (E.g. only > when choosing linux payload) > The proposed mechanism was already implemented here:

Re: [coreboot] SPI controller and Lock bits

Hi Youness, On 2018-09-26 01:30 AM, Youness Alaoui wrote: > Hi, > > I'm trying to add a way to lock the SPI flash to be read-only via > software *after* coreboot boots. The scenario is basically with using > Heads, you could authenticate to it (with a yubikey/nitrokey/librem > key) then be able

Re: [coreboot] how users can control additional features?

On 2018-09-23 12:22 PM, Nico Huber wrote: > Hi Lynxis, > > TLDR; I would prefer NVRAM settings and reading (but not writing) NVRAM > from ASL code directly. > > On 9/15/18 10:05 PM, Alexander Couzens wrote: >> I would like to merge https://review.coreboot.org/c/coreboot/+/12888 >> But how the

Re: [coreboot] Loading Linux payloads on RISC-V

Can you make use of the uImage/FIT [1] mechanism coreboot supports ? It just needs some architecture specific code. Can you provide a ling to the Linux calling conventions for riscv ? [1] https://doc.coreboot.org/lib/payloads/fit.html Regards, Patrick On 2018-09-23 04:59 PM, ron minnich wrote:

[coreboot] Open Source Firmware Assembly @ Chaos Communication Congress (35C3) in Leipzig, Germany

Hello everyone, 9elements is going to build up an Open Source Firmware Assembly at the Chaos Communication Congress in Leipzig from 27th to 30th Dec. 2018 [1] We reserved some tables as done in the last years. You can get in touch with solutions like coreboot, Linuxboot, Tianocore and U-Root. We

[coreboot] Maintainer for FSP broadwell DE

Hi folks, it looks like York Yang doesn't work at Intel any more and thus isn't maintaining the FSP broadwell DE platform. Is there somebody at Intel who can take care of that platform and review and test patches ? Regards, -- Patrick Rudolph 9elements GmbH, Kortumstraße 19-21, 44787 Bochum

Re: [coreboot] Further coreboot releases, setting new standards

On 2018-11-23 04:32 PM, Arthur Heymans wrote: > Patrick Georgi via coreboot writes: > >> Am Fr., 23. Nov. 2018 um 14:43 Uhr schrieb Arthur Heymans >> : >> >> I'd argue for requiring the following: >> >> In which time frame? The next release, ie May 2019? In two releases, >> November 2019? >> >

[coreboot] Nvidia Optimus support, help needed

Hi folks, In order to add Nvidia Optimus support on Lenovo laptops, I'm trying to fix the last issues on [1], but I need your help to do some test on Lenovo's firmware. On Lenovo Sandy Bridge / Ivy Bridge series the PMH7 register 0x50 controls dGPU power. Comments on Gerrit show that different

[coreboot] New API to clear DRAM at boot

API, PAE enabled memset on x86, and helper functions to clear all DRAM on Broadwell DE: https://review.coreboot.org/#/q/project:coreboot+branch:master+topic:security_dram_clear The code can be easily extended to other platforms. Please comment, test and improve the patchset. Regards, -- Patrick

[coreboot] Re: New API to clear DRAM at boot

On Tue, 2019-02-26 at 11:16 -0800, ron minnich wrote: > On Tue, Feb 26, 2019 at 6:41 AM Patrick Rudolph > wrote: > > > > Hi coreboot folks, > > in order to support TEE like Intel TXT it is necessary to be able > > to > > clear all DRAM at boot on request. >

[coreboot] Re: RFC: Replacing IS_ENABLED(CONFIG_XXX) with the shorter CONFIG(XXX)

FYI. Please let me know if anyone has any concerns with this. > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org -- Patrick Rudolph 9elements Agency GmbH, Kortumstraße 19-21, 44787 Bo

[coreboot] Re: Intel Braswell uploads

tain coreboot code. Regards, -- Patrick Rudolph 9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudo...@9elements.com Phone: +49 234 68 94 188 Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 17519 Geschäftsführung: Sebast

[coreboot] Re: New API to clear DRAM at boot

h from the FSP maintainers to detect this corner case and skip the slow memory clearing on coreboot site. Regards, > Steve Mooney > Senior Consulting Engineer > SysPro Consulting, LLC > https://www.sysproconsulting.com/ > > > -Original Message- > From:

[coreboot] Re: Intel Braswell uploads

solution for that, except request reviews in regular intervals. Regards, > > -----Original Message- > From: Patrick Rudolph [mailto:patrick.rudo...@9elements.com] > Sent: donderdag 28 februari 2019 09:20 > To: Michal Zygowski ; > coreboot@coreboot.org > Subject: [corebo

[coreboot] Re: MEC1619 gpio access question (X230)

The interface is proprietary and only a few know bits are implemented. Have a look at the thinkpad_acpi kernel module or vendor ACPI code for additional bits. Some basic fan and power management functionality is implemented. Without a datasheet (by Lenovo) for every EC generation it's impossible

[coreboot] Re: getting rid of CAR_GLOBAL and early_variables.h

] > https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/VJ34MNXVZRO4VUZAK2YXUMTBRFWNF7NM/ > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org -- Patrick Rudolph

[coreboot] Refactor tianocore payload

t additional in-tree patches to build a working payload. Please tell me what you think about the proposed solution. [1]: https://github.com/MrChromebox/edk2 -- Patrick Rudolph 9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudo...@9elements.com Phone: +49 234

[coreboot] Re: Refactor tianocore payload

Hi, What are Google's and Intel's plan on migrating to a stable UEFI payload on x86 coreboot ? On Wed, 2019-02-13 at 10:15 +0100, Nico Huber wrote: > Hi, > > On 13.02.19 09:45, Patrick Rudolph wrote: > > With UEFI the defactor standard it seems reasonable to improve the > &

[coreboot] Re: How to connect with my mentors for GSoC project

ect email to avoid too > many emails for other members? > > Thank you, > Asami > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Regards, -- Patrick Rudolph 9el

[coreboot] Missing gerrit change

Hi, I'm looking for https://review.coreboot.org/18381 which corresponds to 03e971cd23e96b9293fc3ecc420f56ad91326cd9. While the commit is in master I cannot access the change on gerrit. Was the database corrupted? Was the change made private after it has been merged? Was it deleted? Please

[coreboot] Re: Suggestion Computer-On-Module implementations

Hi Frans and Felix, On 2019-07-09 11:56 AM, Felix Held wrote: Hi Frans! Proposal is creating a COM directory ‘src/com’ where the module manufacturer and module name are used. (Similar to mainboard). In this src/com directory common module support is placed. mainboard will use this COM module

[coreboot] Deprecate Cavium ThunderX support

with he next release (4.11) and removed before the 4.12 release. Regards, Patrick Rudolph 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudo...@9elements.com Phone: +49 234 / 68 94 188 Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 13207

[coreboot] Proposal: Improved ACPI generation

this: const char *(*acpi_hid)(const struct device *dev); How about that? Regards, Patrick Rudolph 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudo...@9elements.com Phone: +49 234 / 68 94 188 Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 13207

[coreboot] [PATCH] x86_64 support needs testing

Dear coreboot community, Please test and review the patch series [1]. It adds support for x86 long mode on qemu and allows to build test most of coreboot's common code using the x86_64 toolchain. It serves as reference implementation to migrate real hardware to long mode. Here some technical

[coreboot] [PATCH v2 0/3] firmware: google: Fix minor bugs

From: Patrick Rudolph This patch series fixes 3 independent bugs in the google firmware drivers. Patch 1-2 do proper cleanup at kernel module unloading. Patch 3 adds a check if the optional GSMI SMM handler is actually present in the firmware and responses to the driver. Changes in v2: - Add

[coreboot] [Patch v2 2/3] firmware: google: Unregister driver_info on failure and exit in gsmi

From: Arthur Heymans Fix a bug where the kernel module couldn't be loaded after unloading, as the platform driver wasn't released on exit. Signed-off-by: Arthur Heymans Signed-off-by: Patrick Rudolph --- drivers/firmware/google/gsmi.c | 6 ++ 1 file changed, 6 insertions(+) diff --git

[coreboot] [Patch v2 1/3] firmware: google: Release devices before unregistering the bus

From: Patrick Rudolph Fix a bug where the kernel module can't be loaded after it has been unloaded as the devices are still present and conflicting with the to be created coreboot devices. Signed-off-by: Patrick Rudolph --- drivers/firmware/google/coreboot_table.c | 7 +++ 1 file changed

[coreboot] [Patch v2 3/3] firmware: google: Probe for a GSMI handler in firmware

the calling argument in %eax in the SMM save state untouched that generally means the is no handler for GSMI. Signed-off-by: Arthur Heymans Signed-off-by: Patrick Rudolph --- drivers/firmware/google/gsmi.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/drivers/firmware

[coreboot] [PATCH v3 0/3] firmware: google: Fix minor bugs

From: Patrick Rudolph This patch series fixes 3 independent bugs in the google firmware drivers. Patch 1-2 do proper cleanup at kernel module unloading. Patch 3 adds a check if the optional GSMI SMM handler is actually present in the firmware and responses to the driver. Changes in v2: - Add

[coreboot] [PATCH v3 1/3] firmware: google: Release devices before unregistering the bus

From: Patrick Rudolph Fix a bug where the kernel module can't be loaded after it has been unloaded as the devices are still present and conflicting with the to be created coreboot devices. Signed-off-by: Patrick Rudolph --- -v2: Add missing return statement. -v3: Add missing

[coreboot] [PATCH 1/3] firmware: google: Release devices before unregistering the bus

From: Patrick Rudolph Fix a bug where the kernel module can't be loaded after it has been unloaded as the devices are still present and conflicting with the to be created coreboot devices. Signed-off-by: Patrick Rudolph --- drivers/firmware/google/coreboot_table.c | 6 ++ 1 file changed

[coreboot] [PATCH 0/3] firmware: google: Fix minor bugs

From: Patrick Rudolph This patch series fixes 3 independent bugs in the google firmware drivers. Patch 1-2 do proper cleanup at kernel module unloading. Patch 3 adds a check if the optional GSMI SMM handler is actually present in the firmware and responses to the driver. Arthur Heymans (2

[coreboot] [PATCH 1/2] firmware: google: Expose CBMEM over sysfs

From: Patrick Rudolph Make all CBMEM buffers available to userland. This is useful for tools that are currently using /dev/mem. Make the id, size and address available, as well as the raw table data. Tools can easily scan the right CBMEM buffer by reading /sys/bus/coreboot/drivers/cbmem

[coreboot] [PATCH 2/2] firmware: google: Expose coreboot tables over sysfs

From: Patrick Rudolph Make all coreboot table entries available to userland. This is useful for tools that are currently using /dev/mem. Besides the tag and size also expose the raw table data itself. Tools can easily scan for the right coreboot table by reading /sys/bus/coreboot/devices

[coreboot] [PATCH 0/2] firmware: google: Expose coreboot tables and CBMEM

From: Patrick Rudolph As user land tools currently use /dev/mem to access coreboot tables and CBMEM, provide a better way by using sysfs attributes. Unconditionally expose all tables and buffers making future changes in coreboot possible without modifying a kernel driver. Patrick Rudolph (2

[coreboot] [PATCH 2/3] firmware: google: Unregister driver_info on failure and exit in gsmi

From: Arthur Heymans Fix a bug where the kernel module couldn't be loaded after unloading, as the platform driver wasn't released on exit. Signed-off-by: Arthur Heymans --- drivers/firmware/google/gsmi.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/firmware/google/gsmi.c

[coreboot] [PATCH 3/3] firmware: google: Probe for a GSMI handler in firmware

From: Arthur Heymans Currently this driver is loaded if the DMI string matches coreboot and has a proper smi_command in the ACPI FADT table, but a GSMI handler in SMM is an optional feature in coreboot. So probe for a SMM GSMI handler before initializing the driver. If the smihandler leaves the

[coreboot] Using kernelCI infrastructure for firmware testing

reboot.org/ [2]: https://review.coreboot.org/ Kind Regards, Patrick Rudolph 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudo...@9elements.com Phone: +49 234 / 68 94 188 Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 13207 Geschäftsführung:

[coreboot] Community event in Germany

/index.php/Main_Page https://signup.c3assemblies.de/assembly/ecc631c2-c723-448f-af16-313d3fc4f4e7 https://osfc.io Kind regards, Patrick Rudolph 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudo...@9elements.com Phone: +49 234 / 68 94 188 Sitz der Gesellschaft: Bochum Hande

[coreboot] Community event in Germany

eing you there to chat about open source firmware or related projects, the Open Source Firmware Conference (OSFC) or how to flash firmware in general. You can find the assembly at "Chaos West" cluster. Kind Regards, Patrick Rudolph 9elements GmbH, Kortumstraße 19-21, 44787 Boc

[coreboot] x86_64 support needs review

Hi folks, While working on x86_64 support for the qemu mainboard target I gave it a try on real hardware and I got my machine booting with only 3 additional patches. The current solution seems to work without problems with the following specs: * All stages are compiled in x86_64 * page

[coreboot] Re: LAVA support

Hi Wim, the lava as QA system is still being worked on, but currently has the lowest priority. While some hardware has been automated for firmware testing, some glue code is still missing. Some details can be found here: https://9esec.io/blog/bios-test-station/ Regards, Patrick On

[coreboot] Re: [PATCH] x86_64 support needs testing

. Because of paging? On Sun, Sep 29, 2019 at 5:42 AM Patrick Rudolph wrote: Dear coreboot community, Please test and review the patch series [1]. It adds support for x86 long mode on qemu and allows to build test most of coreboot's common code using the x86_64 toolchain. It serves as reference

[coreboot] Microcode update in coreboot on Intel HT enabled CPUs

1: https://review.coreboot.org/c/coreboot/+/35739/ 2: https://lore.kernel.org/patchwork/patch/889353/ Regards, Patrick Rudolph 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudo...@9elements.com Phone: +49 234 / 68 94 188 Sitz der Gesellschaft: Bochum Hande

[coreboot] Linux kernel drivers to expose additional coreboot functions

CBFS partition in use. Please test and review. [1]: https://github.com/fwupd/fwupd/pull/1370 [2]: https://lkml.org/lkml/2019/10/8/378 [3]: https://review.coreboot.org/c/coreboot/+/35377 Regards, Patrick Rudolph 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudo

[coreboot] Re: Debugging undetected SATA disk?

Hi Mogens, According to "Intel® ME - 1.5MB FW Bring Up Guide" the Intel ME region contains the ICC profiles. If you simply replace the ME without applying the same ICC configuration to the new Intel ME, some hardware might not work as expected. Regards, Patrick Rudolph 9elements A

[coreboot] Re: OSFC videos

Hi Alexander, it would be great to have the OSFC videos hosted on an additional CDN. However this will only be possible for future OSFC videos. We will not upload the 2019 OSFC videos on anything than Youtube, due to various reasons. I'm sorry for the inconvenience. Kind Regards, Patrick Rudolph

[coreboot] Proposal of tasks to update coreboot's documentation

feedback. Kind Regards, Patrick Rudolph 9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudo...@9elements.com Phone: +49 234 / 68 94 188 Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 13207 Geschäftsführung: Eray Basar, Sebastian Deutsch

[coreboot] [PATCH v4 0/2] firmware: google: Expose coreboot tables and CBMEM

From: Patrick Rudolph As user land tools currently use /dev/mem to access coreboot tables and CBMEM, provide a better way by using read-only sysfs attributes. Unconditionally expose all tables and buffers making future changes in coreboot possible without modifying a kernel driver. Changes

[coreboot] [PATCH v4 1/2] firmware: google: Expose CBMEM over sysfs

From: Patrick Rudolph Make all CBMEM buffers available to userland. This is useful for tools that are currently using /dev/mem. Make the id, size and address available, as well as the raw table data. Tools can easily scan the right CBMEM buffer by reading /sys/bus/coreboot/drivers/cbmem

[coreboot] [PATCH v4 2/2] firmware: google: Expose coreboot tables over sysfs

From: Patrick Rudolph Make all coreboot table entries available to userland. This is useful for tools that are currently using /dev/mem. Besides the tag and size also expose the raw table data itself. Update the ABI documentation to explain the new sysfs interface. Tools can easily scan

[coreboot] Re: Planning the next coreboot release

Hi Jonathan, I'll have a look, but I cannot help on the IIO stuff, as we still don't have access to Intel's confidential documents. Kind Regards, Patrick Rudolph B.Sc. Electrical Engineering System Firmware Developer 9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email

[coreboot] Need advise updating Intel's microcode in MPInit

and Hyper-Threading enabled CPUs only. 1: https://review.coreboot.org/q/topic:%22mpinit_cleanup%22+(status:open%20OR%20status:merged) Kind Regards, Patrick Rudolph B.Sc. Electrical Engineering System Firmware Developer 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email

[coreboot] Re: RFC: On testing and reporting how well coreboot does on real hardware

est result for the properties defined earlier. The status-report would be submitted for a specific coreboot version and build config. You could 'add', 'list', 'sort', 'filter', 'delete' reports for "products" as well. Regards, Patrick Rudolph B.Sc. Electrical Engineering Syste

[coreboot] Re: ECC in native ram init? (sandy/ivy)

. The best place to look for this information would be the PDG and BWG which is available under NDA. Kind Regards, Patrick Rudolph Patrick Rudolph B.Sc. Electrical Engineering System Firmware Developer 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudo...@9elements.com Phone

[coreboot] Re: ECC in native ram init? (sandy/ivy)

Hi Matt, the ECC support on Sandy/Ivy Bridge should be fully working since Aug 2020, to be exact, commit b5fa9c8200423beb660403b6656fa8fd5d7edc31 . By default it is automatically enabled if the hostbridge and all DIMMs are ECC capable. It was tested on HP Z220 workstation PC. Regards, Patrick

[coreboot] Re: RFC: On testing and reporting how well coreboot does on real hardware

om this category). > > Cheers, Daniel > > > [1] https://www.systemtestportal.org/ > [2] https://media.ccc.de/v/froscon2019-2359-testing_software_yes_please > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscri

[coreboot] [coreboot - Bug #121] T520: Hangs in OS

Issue #121 has been updated by Patrick Rudolph. Does limiting the max C-state in MSR MSR_PKG_CST_CONFIG_CONTROL also work around the issue? What setting is being used on vendor firmware for MSR MSR_PKG_CST_CONFIG_CONTROL? Currently the code doesn't check if the processor supports C6/C3 sleep

[coreboot] [coreboot - Bug #121] T520: Hangs in OS

Issue #121 has been updated by Patrick Rudolph. I compared the vendor ACPI code for T520 and T530: - The T520 is missing _CST entries, thus the C-states are reported in FADT. I couldn't find a firmware dump that has a FADT. - The T530 has _CST, but the latencies are higher: For C3 148usec, vs

[coreboot] [coreboot - Bug #401] edk2 hangs indefiniately

Issue #401 has been updated by Patrick Rudolph. Do you have an EDK2 log with DEBUG_CACHE logging enabled? Bug #401: edk2 hangs indefiniately https://ticket.coreboot.org/issues/401#change-1035 * Author: Sean Rhodes * Status: New * Priority: Normal

[coreboot] [coreboot - Bug #121] T520: Hangs in OS

Issue #121 has been updated by Patrick Rudolph. I made good progress with https://review.coreboot.org/c/coreboot/+/81597 It allows to configure the VR12-compatible regulator adjusting the CPU core voltage. Especially the PSI state are from interest, since those are using in Package C3

[coreboot] [coreboot - Bug #121] T520: Hangs in OS

Issue #121 has been updated by Patrick Rudolph. Jun Muta wrote in #note-91: > Patrick Rudolph wrote in #note-89: > > I checked the vendor BIOS for (X220, T420 and T420s) and it hard-codes PSI2 > > and PSI3 values to 0 in PowerManagment2.efi. > > The X230 vendor BIOS doe

[coreboot] [coreboot - Bug #121] T520: Hangs in OS

Issue #121 has been updated by Patrick Rudolph. I checked the vendor BIOS for (X220, T420 and T420s) and it hard-codes PSI2 and PSI3 values to 0 in PowerManagment2.efi. The X230 vendor BIOS does not hard-code those values in PowerManagment2.efi. Thus this is likely a bug in the voltage

[coreboot] [coreboot - Bug #538] [Soft Brick] x230 Dock Causes Internal Display to "Permanently" Malfunction

Issue #538 has been updated by Patrick Rudolph. Looking at the schematics there's no way the LVDS can be disconnected. However it might be possible that the display isn't powered, though it's unclear why coreboot would cause this effect. Bug #538: [Soft

[coreboot] [coreboot - Bug #121] T520: Hangs in OS

Issue #121 has been updated by Patrick Rudolph. My X220 is stable for more than 48h, which wasn't possible before as it would crash within a couple of hours. Since the issue doesn't appear any more I must assume it's fixed on my device. There might be other settings causing a similar problem

  1   2   >