We will need to define the "hidden" entry in host _crs to be match with
> E820 "reserved" entry? They may cause some manual work, maybe we can have
> some code change to make it automatically?
>
>
> Tim Wawrzynczak via coreboot 于2022年8月23日周二
> 04:27写道：
>
>
Re-forwarding the prior email as an attachment per Paul M's request.
-Tim
--- Begin Message ---
Hello fellow coreboot folks,
I recently received this message from some associates in the Linux kernel
community which describes
a bug in coreboot firmware for many Intel boards. The gist of it related
Hello fellow coreboot folks,
I recently received this message from some associates in the Linux kernel
community which describes
a bug in coreboot firmware for many Intel boards. The gist of it related to
inconsistencies between the
hostbridge's _CRS method in ACPI and the E820 table (although
Hi Sameer,
The version of the ME RW binary must match
the CONFIG_SOC_INTEL_CSE_RW_VERSION Kconfig value (it's a string).
-Tim
On Sat, Aug 20, 2022 at 12:08 AM Sameeruddin Shaik <
sameeruddin.sha...@gmail.com> wrote:
> hi ,
> I built a coreboot image for ADL RVP, In that image cse lite cbfs
>
On Fri, May 6, 2022 at 6:16 AM Peter Stuge wrote:
> Valerii Gugnin wrote:
> > What are the most popular systems on which coreboot is typically used?
>
> I guess that's the various Chromebooks, all of which ship with coreboot.
>
>
> > What mainboards, southbridges, SoCs etc do these systems use?
Good day folks,
In a recent change[0], it was proposed that we drop support for the Intel
Ice Lake platform.
The only mainboard supporting the platform was the Intel RVP, but as far as
anyone knows,
it appears the project never progressed past the initial silicon, and so
the code is now
Hi Werner,
Sorry if you think https://review.coreboot.org/c/coreboot/+/34385 could
break things for you. Feel free to push
somewhat of a revert (if you can think of a better message than "bad
counts" :) )
-Tim
On Thu, Apr 29, 2021 at 8:55 AM Zeh, Werner wrote:
> In the meantime Kyösti
Hi Werner,
I agree we could probably do a little better than we do today (feel free to
submit a patch ;)),
but speaking for what I have seen on bringing up Chrome OS devices, the
ODMs ultimately
end up having to tweak these values depending on the board design (bus
load, etc.); e.g.
```
$
git
Hi Rocky,
You have a couple of options that I can think of:
1) Add the device to the DSDT, but find a way to implement a `_STA` Method
that will return 0x0 if the device does not exist, and 0xF if it does
2) Push a patch to add a similar mechanism to load a `ssdt.aml` file from
CBFS (similar to
On Tue, Jan 19, 2021 at 9:27 AM Michał Żygowski
wrote:
>
> On 1/19/21 5:10 PM, Tim Wawrzynczak via coreboot wrote:
> > Dear Michał,
> >
> > Do you have a config for us to look at for your board? Are you
> > using INTEL_CAR_NEM_ENHANCED ?
>
>
Dear Michał,
Do you have a config for us to look at for your board? Are you
using INTEL_CAR_NEM_ENHANCED ?
Based on the post code you observed last, I might guess that you overfilled
the cache when doing the cache fill
operation, e.g. the next few lines in cache_as_ram.S after post-code 0x26;
I will admit that I am a big fan of the `BIT` macro as well, but that seems
to not be as well-received, so if that's not an option, I would second `1u
<< 31`
On Thu, Jan 7, 2021 at 3:25 PM Furquan Shaikh
wrote:
> Would it make sense to use BIT(31)?
>
> On Thu, Jan 7, 2021 at 2:20 PM Matt
Hi Rafael,
The 'hidden' keyword in devicetree hadn't been used in a while, so we
repurposed its meaning.
The usage here was for PCI devices that Intel hides (during calls to FSP);
we know they exist
and there are device operations we still want to associate with the device
(fixed memory and I/O
> >>>
> >>>> On 21.10.20 21:19, Tim Wawrzynczak via coreboot wrote:
> >>>>> Currently there are 3 different "strapping" entries in the coreboot
> >>>> tables,
> >>>>> and with the recent addition of fw_config (
&g
On Wed, Oct 21, 2020 at 4:54 PM Nico Huber wrote:
> On 22.10.20 00:29, Tim Wawrzynczak wrote:
> > On Wed, Oct 21, 2020 at 4:00 PM Nico Huber wrote:
> >
> >> On 21.10.20 21:19, Tim Wawrzynczak via coreboot wrote:
> >>> Currently there are 3 different
On Wed, Oct 21, 2020 at 4:00 PM Nico Huber wrote:
> On 21.10.20 21:19, Tim Wawrzynczak via coreboot wrote:
> > Currently there are 3 different "strapping" entries in the coreboot
> tables,
> > and with the recent addition of fw_config (
> > https://review.co
On Wed, Oct 21, 2020 at 1:50 PM Aaron Durbin wrote:
>
>
> On Wed, Oct 21, 2020 at 1:20 PM Tim Wawrzynczak via coreboot <
> coreboot@coreboot.org> wrote:
>
>> Hi coreboot community,
>>
>> Currently there are 3 different "strapping" entries in the
Hi coreboot community,
Currently there are 3 different "strapping" entries in the coreboot tables,
and with the recent addition of fw_config (
https://review.coreboot.org/c/coreboot/+/41209), we would also like to add
the 64-bit fw_config field (updated here
Hi Thomas,
On Tue, Oct 6, 2020 at 11:07 AM Thomas Clarke via coreboot <
coreboot@coreboot.org> wrote:
> Greetings Coreboot community!
>
> I’m currently engaged in an effort to bring support for vboot on the Asus
> KGPE-D16 for use in the Heads boot environment. Things had been going well
> until
No worries, Gerrit uses the 'Change-Id' line to distinguish between
different PRs/patches. Did you remove the Change-Id line when editing the
commit?
Cheers,
-Tim
On Thu, Sep 17, 2020 at 12:15 PM bzt wrote:
> Thank you very much!
>
> I've tried "git push origin HEAD:refs/for/master" but didn't
Hi Keith,
Many ACPI devices use an EISAID for their _HID, and I believe that Linux's
ACPICPA converts an EISAID to a string for _HID matching.
You could try something like this instead (you can see in the Linux sources
there are 3 ACPI _HID matches, and this is one of them).
`Name(_HID,
21 matches
Mail list logo
