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
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.
Regar
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 cached values, someth
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
fix
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
hat granule, but a Kconfig should do 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, G
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
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 treated like a bl
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 wrote:
> > > > On 05.04.2018 18:15, Matt DeVillier wrot
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:
>>>&
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 Patric
> Return (Zero)
> }
>}
>
>Method (SBDC, 1, NotSerialized)
>{
> If (HBDC)
> {
> Local0 = ((Arg0 & 0x02) >> One)
> BTEB = Local0
> }
>}
>
>Hope that helps.
>
>Cheers,
>Matthi
; > Return (Local0)
> > > }
> > > Else
> > > {
> > > Return (Zero)
> > > }
> > > }
> > >
> > > Method (SBDC, 1, NotSerialized)
> > > {
> > > If (HBDC)
> > > {
> &g
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 mod
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, ...) failed
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
--
core
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,
> lynxis
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 use
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:
>
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 to
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:
https://review.coreboot.org/#/c/coreb
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 previo
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 there
test 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.
Rega
ne from 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 unsu
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
y for sure.
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...@9ele
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
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
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 148use
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
or
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
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
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
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.
Issue #476 has been updated by Patrick Rudolph.
Might be related: https://github.com/torvalds/linux/commit/dff054e691dae
Feature #476: Add option to convert coreboot-inited linear frame buffer to
efifb directly
https://ticket.coreboot.org/issues/476
Issue #538 has been updated by Patrick Rudolph.
Since it works when using the VBIOS the hardware isn't broken and it's likely a
software bug or miss-configuration.
Maybe a regression in libgfxinit or coreboot? No VBT included? Wrong VBT
included?
UEFI firmware patches the VBT, whil
Issue #538 has been updated by Patrick Rudolph.
Probably related issue: https://ticket.coreboot.org/issues/278
Bug #538: [Soft Brick] x230 Dock Causes Internal Display to "Permanently"
Malfunction
https://ticket.coreboot.org/issues/538#c
Issue #121 has been updated by Patrick Rudolph.
> I tried booting with kernel command line parameter idle=nomwait.
That should make the OS use the `hlt` instruction instead of `mwait`, which is
similar to package C1-state.
When using `powertop` or similar tools it should show how much time
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 a
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?
>>
>
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 w
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, 44
522no_CAR_GLOBAL%2522+
> [2]
> 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...@co
ould use this repo without 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...@9ele
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
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
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.
>
see a patch 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-
> F
eally maintain
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ühru
good 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: [core
> quick 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
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 t
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
to do it via video chat or direct 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
Reg
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
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 inves
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
rked deprecated 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: Amtsgeric
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 d
ack overflows in
SMM.
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 toolchai
your time.
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: Bo
ctive
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
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 2019-11-01
ut this?
[1]: https://coreboot.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
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 ch
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
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 b
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
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
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
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
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
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 ch
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(+)
di
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
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
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 mi
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 tables
/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
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
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 Ru
t and give 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, Sebasti
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
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 in
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
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 for
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
erialize MP init
microcode updates on non FIT 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, Ko
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 more.
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 seems
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 A
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 s
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,
Patrick
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 in
On 2016-06-03 05:41 PM, Aaron Durbin via coreboot wrote:
> On Fri, Jun 3, 2016 at 7:04 AM, Patrick Rudolph wrote:
>> 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, b
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 n
On 2016-06-06 09:58 PM, ron minnich wrote:
> On Mon, Jun 6, 2016 at 12:52 PM Patrick Rudolph
> wrote:
>
>> 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.
>
> I&
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
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 code
1 - 100 of 105 matches
Mail list logo