Hi Peter,
On 28.11.21 02:44, Peter Stuge wrote:
> TL;DR: If someone wants to deprecate older code then *they* have to
> first balance any compatibility debt introduced by the newer code.
sounds fair. However I have to ask, do you see things are unbalanced?
And in what direction?
Taking the
Hi Pedro,
On 27.11.21 00:02, Pedro Erencia wrote:
> I'm thinking about porting coreboot to a FM2A88X Extreme4+ board. This
> board has a DIP8 flash with a socket and I wondered what would be the best
> way to do an efficient development cycle. Ideally, I suppose that the best
> option would be to
Hi,
On 11.11.21 14:05, Julian Stecklina wrote:
> with the following patch, the Qemu coreboot image indeed does not write to ROM
> anymore.
>
> The question is whether this is behavior that is also considered broken on
> qemu?
>
> diff --git a/src/mainboard/emulation/qemu-i440fx/Kconfig
>
Am 10.11.21 um 10:43 schrieb Nico Huber:
Hi Julian,
Am 10.11.21 um 10:02 schrieb Julian Stecklina:
CBFS: Found 'fallback/romstage' @0x80 size 0x3ba0 in mcache @0x00014e2c
WARN - MOVS to ROM at RIP dc2f RCX ee8 ff200300->ff200300
The warning is from us. Improvising a stack tr
Hi Julian,
Am 10.11.21 um 10:02 schrieb Julian Stecklina:
CBFS: Found 'fallback/romstage' @0x80 size 0x3ba0 in mcache @0x00014e2c
WARN - MOVS to ROM at RIP dc2f RCX ee8 ff200300->ff200300
The warning is from us. Improvising a stack trace at this point yields:
cbfs_prog_stage_load ->
On 08.11.21 19:38, Martin Roth wrote:
>
> Nov 7, 2021, 04:29 by nic...@gmx.de:
>
>> On 07.11.21 00:15, Martin Roth wrote:
>>
>>>
>>> Nov 6, 2021, 05:49 by nic...@gmx.de:
>>>
It also seems that you underestimate the individuals in the
community.
>>> I don't understand your statement
On 08.11.21 19:57, Patrick Georgi wrote:
> Am So., 7. Nov. 2021 um 12:29 Uhr schrieb Nico Huber :
>
>> There's also a general reluctance to expect to support a project with
>> free software that has shown that it doesn't take the GPL seriously.
>>
>
> General reluct
On 08.11.21 19:15, bernd...@web.de wrote:
> Hi. Is the SeaBIOS payload open source, actually?
Yes.
> I have looked for SeaBIOS on
> Wikipedia but it has no entry of its own.
Please look closer [1].
Nico
[1] https://en.wikipedia.org/wiki/SeaBIOS
___
Hi Werner,
On 08.11.21 12:24, Zeh, Werner wrote:
> I fully can understand your point of view in this discussion. Unfortunately,
> we do live in a real world with real companies that are business-driven.
> With this sidenote in context the world changes dramatically in this regard.
>
> Your
On 02.11.21 14:49, bernd...@web.de wrote:
> Thanks for your reply and preventing me to go any further in the wrong
> direction.
>
> I've made it absolutely clear from the very start of the thread (see email
> subject lines) that I'd like to install coreboot with OpenBIOS.
Well, I hope you are
of all, I have to say that what I write is meant literally.
Please don't try to imagine something between the lines. But if you
really feel like you have to, please just ask how it was meant.
On 20.10.21 14:24, Nico Huber wrote:
> a recent yet-another-blob occurrence reminded me that I wan
On 07.11.21 00:15, Martin Roth wrote:
>
> Nov 6, 2021, 05:49 by nic...@gmx.de:
>
>> On 05.11.21 19:39, Patrick Georgi via coreboot wrote:
>>
>>> It [coreboot] would be dead: while there are still a few folks carefully
>>> maintaining
>>> i945 and GM45 in this reality, I'm not sure they would have
On 07.11.21 00:11, Martin Roth wrote:
> Nov 6, 2021, 05:21 by nic...@gmx.de:
>
>> On 05.11.21 18:15, Martin Roth via coreboot wrote:
>>
>>> Nov 4, 2021, 05:24 by pmen...@molgen.mpg.de:
>>>
>>>> On 20.10.21 14:24, Nico Huber wrote:
>>>>
On 06.11.21 23:40, Martin Roth wrote:
>
> Nov 5, 2021, 14:10 by nic...@gmx.de:
>
>> On 05.11.21 18:58, Martin Roth wrote:
>>
>>> This binary is also mandatory for the elkhart lake platform, so to support
>>> this platform, loading this is required, whether it's built from source as
>>> a part of
On 05.11.21 19:39, Patrick Georgi via coreboot wrote:
> Am Fr., 5. Nov. 2021 um 18:16 Uhr schrieb Martin Roth via coreboot <
> coreboot@coreboot.org>:
>
>> The current reality is that binary blobs are needed for almost every
>> platform in coreboot. I believe the coreboot leadership is united
On 05.11.21 19:10, ron minnich wrote:
> I'd like to get back to a rating system. There's a really simple
> measure that I've never seen improved upon, namely, for a given
> firmware image, what fraction of the bits in that image come from open
> source code?
>
> e.g., the KGPE-D16 would get a
On 05.11.21 18:15, Martin Roth via coreboot wrote:
> Being more involved in the planning phase would be great, and obviously there
> are companies contributing to coreboot who ARE involved in these discussions.
> Expecting companies to discuss their plans for future chips in the open
> probably
On 05.11.21 18:15, Martin Roth via coreboot wrote:
> Nov 4, 2021, 05:24 by pmen...@molgen.mpg.de:
>
>> On 20.10.21 14:24, Nico Huber wrote:
>>
>>> My proposal:
>>> How about we set up some guidelines how to proceed when adding support
>>> for a new pl
On 05.11.21 18:58, Martin Roth wrote:
>
> Oct 31, 2021, 15:03 by nic...@gmx.de:
>
>> Hi Sheng,
>>
>> On 27.10.21 06:29, Tan, Lean Sheng wrote:
>>
>>> As mentioned earlier the Firmware of the PSE needs to be loaded at boot
>>> time of the host CPU, this is mandatory for Elkhart Lake.
>>>
>> ...
>>
Hi,
On 02.11.21 12:19, bernd...@web.de wrote:
> The instructions say:
>
> "There should only be two lines (or 3 if you’re using the system toolchain):
>
> CONFIG_PAYLOAD_ELF=y
> CONFIG_PAYLOAD_FILE="payloads/coreinfo/build/coreinfo.elf""
>
> I'm not using the system toolchain. There are the
Hi Sheng,
On 27.10.21 06:29, Tan, Lean Sheng wrote:
> As mentioned earlier the Firmware of the PSE needs to be loaded at boot time
> of the host CPU, this is mandatory for Elkhart Lake. There is a patch on
> Gerrit provides an interface to load the PSE firmware (soc/intel/elkhartlake:
>
On 20.10.21 20:22, Martin Roth via coreboot wrote:
> Accidentally responded off the mailing list initally. :-/
>
>
> Oct 20, 2021, 08:07 by matt.devill...@gmail.com:
>
>> On Wed, Oct 20, 2021 at 8:53 AM Andy Pont wrote:
>>
>>>
>>> Nico wrote...
> How about we set up some guidelines how to
On 20.10.21 16:07, Matt DeVillier wrote:
> On Wed, Oct 20, 2021 at 8:53 AM Andy Pont wrote:
>>
>> Nico wrote...
How about we set up some guidelines how to proceed when adding support
for a new platform that requires any blobs? My vague idea is as follows:
Before the very first
Hi Andy,
On 20.10.21 15:53, Andy Pont wrote:
> Nico wrote...
>>> How about we set up some guidelines how to proceed when adding support
>>> for a new platform that requires any blobs? My vague idea is as
>>> follows:
>>> Before the very first commit for such a new platform can be merged, a
>>>
> How about we set up some guidelines how to proceed when adding support
> for a new platform that requires any blobs? My vague idea is as follows:
> Before the very first commit for such a new platform can be merged, a
> set of predefined, blob related questions (to be discussed) should be
>
Hi coreboot community,
a recent yet-another-blob occurrence reminded me that I wanted to
write about the matter for a long time.
Every few months, it seems (if not, more often), a new blob is
introduced to coreboot. Alas, this is often hidden to the last
minute, creating unnecessary friction and
Hello Sukanto,
welcome to the coreboot mailinglist!
I'm not an expert on the arm64 port of coreboot. But generally the
idea of coreboot is that it starts with the first instructions that
are loaded from flash (or the reset vector, on platforms where its
located in flash).
On 20.10.21 11:04,
On 13.10.21 20:50, Peter Stuge wrote:
> Martin Roth via coreboot wrote:
>> ## Objective:
>>
>> Linux is expecting more and more to use EFI supplied interfaces (UEFI
>> Boot Services in particular, even if many are stubbed out) so like it or
>> not, we’re going to need to support these interfaces.
On 04.10.21 22:17, Hendra wrote:
> hi Nico,
>
> "they" refers to the adversary.
huh? that's the first time you bring that up, IIRC. Your original
question, how it is connected to the internet, does not imply any
malicious intention. If you assume that, all bets are off. I don't
think the quotes
On 03.10.21 12:43, Hendra wrote:
> in my understanding,
>
> in their office, they know the password of their internet connection,
> therefore they can setup the password in the AMT,
> so they can access the devices remotely,
>
> but after the products being distributed all over the world,
> then
Hi,
On 03.10.21 07:13, Hendra wrote:
> But then, there is a familiar statement on the internet, that ME is still
> running and connected to the internet,
> even when the computer is off, as long as it has a battery.
>
> Let's say, we only use WIFI WLAN cards for internet connection,
> and the
On 02.10.21 16:11, Merlin Büge wrote:
> On Fri, 1 Oct 2021 20:58:14 +0200, Nico Huber wrote:
>> A quick search for "intel amt configure ip" led me here [1]. It seems
>> there was a time when one could configure individual IP addresses for
>> ME and host OS's, bu
Hi Hendra,
On 01.10.21 17:43, Hendra wrote:
> I read in Wikipedia that Intel ME has an independent internet connection.
> But what does "independent" mean ?
I don't think that's true. Maybe one could twist the word "independent"
enough so it makes sense, but I wouldn't call it that. I would say
Hi Jack,
On 30.09.21 15:22, Jack Rosenthal via coreboot wrote:
> On Thu, Sep 30, 2021 at 2:27 AM Arthur Heymans wrote:
>
>> As a rule of thumb, any project involving a substantial amount of Python
>>> always ends up needing a Docker container to build. So I'm in the "no" camp
>>> for making
Hi Daniel,
On 17.09.21 18:06, Daniel Kulesz via coreboot wrote:
> I plan to flash a Thinkpad T430. According to an article in the german
> "golem.de" magazine [1] accessing the flash via SPI is possible by connecting
> the wires from the SPI flasher to plug contacts on the upper side of the
>
On 17.09.21 01:41, Andreas Bauer wrote:
> Am Fri, Sep 17, 2021 at 01:18:53AM +0200 schrieb Nico Huber:
>
>> On 16.09.21 17:29, Andreas Bauer wrote:
>>> May I suggest the best way forward would be to compile coreboot with
>>> debug options and go ahead and flash
On 16.09.21 17:29, Andreas Bauer wrote:
> May I suggest the best way forward would be to compile coreboot with
> debug options and go ahead and flash it. You will find out quickly
> where the issues are. Obviously backup your current rom !
Not likely, but you can harm the hardware with such
On 16.09.21 16:37, Brian Milliron wrote:
>
>> Using a hardware flasher isn't a workaround, the signature check is
>> done in hardware by the ACM using keys fused into the ME. If Bootguard
>> enabled and keys fused, nothing can be done unfortunately.
>
> I checked the BIOS. There was nothing
On 09.09.21 08:04, Andreas Bauer wrote:
> By the way, during this process a thought occured to me: this process of
> manually poking different configurations, basically trial and error, does
> not scale very well.
>
> IF we have a vendor bios that does all the magic sauce, and even know
>
Hi,
On 09.09.21 00:37, Benjamin Doron wrote:
> On Wed, Sep 8, 2021 at 8:13 AM Andreas Bauer
> wrote:
>
>> Am Tue, Sep 07, 2021 at 03:29:55PM -0400 schrieb Benjamin Doron:
>>> The relevant modules for setting FSP-M configuration are
>>> BoardConfigInitPreMem and possibly PlatformInitPreMem. Since
Hi Tim,
On 11.09.21 22:15, tcullen2018 via coreboot wrote:
> ...
> LPGCC coreinfo.bin
> /home/tcullen/src/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/8.3.0/../../../../x86_64-elf/bin/ld.bfd:
> build/cpuinfo_module.o: in function `cpuinfo_module_init':
> cpuinfo_module.c:(.text+0x45e):
On 28.02.21 16:53, Nico Huber wrote:
> that we had another case of a missing-device-below-chip in a devicetree
> made me write a patch for `sconfig` [1]. Now that it's checking for the
> issue, that uncovered a few (31) more cases [2] that need to be fixed
> before upstream can
On 30.07.21 18:59, Rao G wrote:
> Thanks Nico.
>
> HPD is active , measured the signal
Is your coreboot port public somewhere? If the hardware is fine, maybe
the firmware isn't?
>
> Configured Ports
> 1.DDI0- PortB - DP with HDMI/DVI is good in BIOS & OS
> 2.DDI1- PortC - DP with HDMI/DVI is
Hi,
On 30.07.21 16:47, Rao G wrote:
> The problem originally I had was that on PortC, DP/HDMI did not work for
> the external display in the OS, In BIOS it looked good,
> so I configured PortC as an eDP interface then the external display started
> working in the OS.
this sounds much like you
Hello Rao,
On 30.07.21 13:53, Rao G wrote:
> trying to see the MMIO or VBIOS data when a external display device is
> plugged/unplugged with DP/HDMI interface, which MMIO register is set or
> cleared
I think you are looking at the right register (last one below).
>
> Any inputs are appreciated,
Hello Jonatan,
On 08.07.21 23:48, Jonatan Dolot wrote:
> When I install coreboot on lenovo thinkpad 11e (3rd gen) it will disable
> intel ME ? (Intel Management Engine)
short answer: No. (but it might not matter)
Generally, one can't "disable" the ME. One can reduce its firmware
features, but
Hello Michael,
On 11.06.21 18:43, Michael Di Domenico wrote:
> what's the likely hood that i can get coreboot to run on a tyan gpu server?
100% if you are willing to do or to pay for what is necessary; with
one exception: Tyan might lock you out from running your own firmware
with some digital
Hi Sven,
On 11.06.21 00:55, Sven Semmler wrote:
> this is my first time posting here and it is quite possible that I've
> overlooked something obvious. In that case please just point me to
> whatever I should have read and accept my apologies.
don't worry. If this were documented, I would have
Hi Piotr,
it feels like we are discussing the wrong things here. I've also looked
at the Gerrit discussion[1]. We are discussing solutions, while the root
cause is not understood yet.
On 06.05.21 00:13, Piotr Król wrote:
> There are many reasons for rebasing or updating firmware to name few
>
On 29.04.21 11:11, Mike Banon wrote:
> Dear Friends, please share your thoughts to help us at 3mdeb to
> advance a coreboot project - by participating in this opensource
> survey of just 7 questions:
>
> * Ideal platform for coreboot training?
> https://corequest.limesurvey.net/274886?lang=en
Hi,
On 21.04.21 20:33, Patrick Georgi via coreboot wrote:
> Hi everybody,
>
> In our leadership meeting[1] we discussed how we should deal with tree-wide
> changes (ranging from "new file header" to "some API is gone now"). The
> concern was that right now, anything can change at any time, making
rth another shot to ask.
Nico
--
M. Sc. Nico Huber
Senior Consultant SINA Software Development and Verification
Division Defence & Space
secunet Security Networks AG
Phone: +49-201-5454-3635, Fax: +49-201-5454-1325
E-Mail: nico.hu...@secunet.com
Mergenthalerallee 77, 65760 Esc
On 28.03.21 09:24, Gert Vanhaerents wrote:
> "Please note, that coreboot has nothing to do with the Intel Management
> Engine as it’s a separate “chip” running it’s own firmware [1]. "
>
> Can I completely disable that Intel ME software via coreboot?
No. At various levels. But you can probably
Hello Gert,
it's very nice to hear that your customers ask for coreboot :) \o/
I'll start with the annoying part, hopefully bringing more cheerful
news later:
coreboot is not a ready-to-install firmware. coreboot is used by ODMs
and OEMs like System76 or sometimes enthusiasts to build their
Hello Himanshu,
On 19.03.21 17:12, Himanshu Chauhan wrote:
> On Fri, Mar 19, 2021 at 09:33:43PM +0530, Himanshu Chauhan wrote:
>> Hi,
>>
>> I am working on a hypervisor and running coreboot as guest.
>> During a VMExit, I am seeing coreboot RIPs. Since coreboot
>> is mix of 16-bit/32-bit code and
Hi all,
that we had another case of a missing-device-below-chip in a devicetree
made me write a patch for `sconfig` [1]. Now that it's checking for the
issue, that uncovered a few (31) more cases [2] that need to be fixed
before upstream can benefit from the patch. Please help to fix the
Hi Kevin,
On 28.02.21 14:36, Kevin Keijzer via coreboot wrote:
> In coreboot 4.13, this bug is still present. So I decided to bisect the
> issue, and I found the offending commit:
>
> 96ae7a3a2d38b96c1dfee57fda2c2eaab7e9e762 is the first bad commit
thanks for the bisecting effort! I think I
On 09.02.21 20:40, Arthur Heymans wrote:
> I wish we had enough leverage as a community to change the silicon
> vendors way, but that is just not the case. I feel however that things
> improve in the right direction. OSF on server hardware is becoming a
> thing again, which was not the case at all
Hi Arthur,
I appreciate that you took the matter to the mailing list. This gives
us the chance to really discuss it before we create yet another prece-
dent. I urge all of us to not demand or make any hasty decision.
Please understand that integration of any new proprietary component
naturally
Hi coreboot folks,
I've just pushed a small RFC commit for our coding style:
https://review.coreboot.org/c/coreboot/+/49542
>From the commit message:
It seems since the increase of the code line length to 96 chars, many
developers felt encouraged to increase the line length of running text
as
Hi Angel,
as you brought it up, I guess we may as well discuss this on the list,
too.
I assume because some developers often don't remember that `+` takes
precedence before `<<`, GCC warns now that one should place brackets
in such cases even if they aren't necessary.
On 08.01.21 01:37, Angel
Hi Harshit,
On 08.01.21 01:35, Harshit Sharma wrote:
> Although, I agree that 1u << 31 is much better, I believe 1 << 31 is not
> wrong either as long as it is assigned to an 'unsigned int' as the compiler
> performs an implicit conversion from a lower data type to a higher data
> type ('int' to
Hi,
On 08.01.21 01:26, Peter Stuge wrote:
> Nico Huber wrote:
>> So, it's wrong but not broken
>
> ..yet
that's right. But I think chances are incredibly low that C compilers
would change this behavior. Of all the things that I'm worried about
that could change, this case
Hi Peter,
On 08.01.21 01:12, Peter Stuge wrote:
> Felix Held wrote:
>> While I find the BIT() macro to be much better than the BITx defines
>
> Why?
for me it's that the BITx defines provide no separation between the BIT
and the number. Also, the all-caps BIT letters come close to decimal
Hi coreboot fellows,
another patch that fixes a `1 << 31` to `1UL << 31` [1] reminded me that
some people objected to such changes. I'm not sure if we ever draw a
conclusion on the matter.
`1 << 31` is undefined behavior because the `1` can (and thus will) be
represented as a (signed) `int`
On 18.11.20 23:53, Julius Werner wrote:
> (Also, while we're on the subject of submodules causing pain, Nico...
> whenever I want to build test older Intel generations I have to first
> figure out again which of them don't rely on libgfxinit, or how to
> hack around in their Kconfigs to disable
Hello Patrick,
I'm a bit concerned about the tone of your email. Maybe you were just
reflecting the meeting literally. In that case, sorry in advance.
In several spots you seem to imply that Peter would settle for less
than what is expected. I have no idea where that comes from. Also,
I don't
Hi Julius,
On 12.11.20 03:29, Julius Werner wrote:
> So I think the "official" rule is basically that the minimum
> requirement for host utilities is the same compiler and version that
> crossgcc uses, which I think makes some amount of sense (otherwise
> we'll just have to keep tracking and
Hi all,
On 12.11.20 03:29, Julius Werner wrote:
> I don't think it's fair to single in on vboot as the big problem here.
it's not by any definition but, FWIW, it became one in practice. I don't
think it's because of GCC versions or anything that we should try to fix
by testing. One big
Hi Daniel,
I think this is a good idea. Alas, as I hear for the first time about
it, I lack any context of prior discussions / context. So bear with me,
if I ask things that have already been answered.
On 14.11.20 00:52, Daniel Kiper wrote:
> The goal is to pass all logs produced by various boot
Hi Mike,
On 10.11.20 19:22, Mike Banon wrote:
> Thank you very much for your advice, dear Naresh, I will try matching
> the UEFI routing.
I wouldn't expect too much. If things are configurable in the chipset
(they usually are these days) it's possible that coreboot configures
them differently
On 10.11.20 16:06, Nico Huber wrote:
> If anybody knows or discovers more cases where it needs to be enabled
> in advance by coreboot, please mention it here.
We just discussed on IRC cases where unfixable OS drivers might need it.
For such cases, it would probably be best to add indi
Hi,
On 04.11.20 23:21, Angel Pons wrote:
> 3. Please take a look at the preliminary release notes in
> Documentation/releases/coreboot-4.13-relnotes.md and add whatever
> happened since 4.12 that is worth mentioning. If unsure, simply push a
> change to Gerrit and have your fellow developers
On 10.11.20 00:38, Peter Stuge wrote:
> Branden Waldner wrote:
>> Is there an expected minimal system gcc version and if so, is it
>> documented? I couldn't find it noted anywhere.
I don't think it's documented. As you already noticed, we depend on
a 3rdparty library (vboot), so we actually don't
Hi folks,
I'm currently looking into making payload builds and testing more
convenient. That involves, among other things, QEMU make targets
with default options that should ease coreboot development, incre-
mental builds of payloads, support for local changes in payload
dirs.
So far I've
Hi Julius,
wasn't sure if you are addressing me personally. I'll assume these
questions are meant for me as you replied to my mail.
On 26.10.20 23:27, Julius Werner wrote:
Generally, I wouldn't assume / want board-specific drivers outside of
coreboot. It seems board-specific table
On 19.10.20 19:06, Paul Menzel wrote:
> Looking at the Asus A88XM-E files, it turns out there is a macro
> `BLDCFG_FCH_GPP_PORT2_PRESENT` to configure this behavior. Defining this
> to `TRUE`, the bridge and ethernet device are detected [4].
>
> Unfortunately, it still hangs, when coreboot tries
On 22.10.20 02:25, Tim Wawrzynczak wrote:
> 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 wr
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 "strapping" entries in the coreboot
>> tables,
>>> and wit
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.coreboot.org/c/coreboot/+/41209), we would also like to add
> the 64-bit fw_config field (updated here
Hi Daniel,
On 13.10.20 21:59, Daniel Kulesz via coreboot wrote:
> The build fails because I don't have the other proprietary parts
> (descriptor.bin, me.bin, gbe.bin).
you can simply omit them. If you don't tell that you have them (in your
config), coreboot won't miss them.
> Or is this
Hi,
have you tried omitting the `device lapic` line from the devicetree?
It would only matter if there is configuration associated with it, but
I can't see anything like that for `intel/harcuvar`.
What happens is that this `device lapic` line in the devicetree becomes
an entry in a list at
Hi Andrew,
On 13.09.20 05:59, Andrew Lee via coreboot wrote:
> Hello, when I tried to compile coreboot it gave me this error message.
> https://pastebin.com/raw/mK9jc5eX
you have to use the i386-elf toolchain. When you built it, you might
have to `rm .xcompile` in your toplevel coreboot dir. So
Hi,
On 04.09.20 04:11, Matt DeVillier wrote:
> On Thu, Sep 3, 2020 at 8:29 PM Desimone, Nathaniel L
> wrote:
>> Given that the newest coreboot releases have not supported the FSP 1.x
>> specification for years now
>
> support for FSP 1.0 was dropped, but FSP 1.1 is still used by Braswell
> and
Hi Paul,
On 27.07.20 09:20, Paul Menzel wrote:
> Making a Kaby Lake-U variant port [1], building an image, I notice the
> log say the microcode update files sizes in the FIT table are 0.
IIRC, this is intentional, because the update itself already has a
header that specifies its length. If the
Hello Andrey,
On 08.07.20 12:05, avi...@gmail.com wrote:
> Does it mean I can not use EDK II a full platform implementation with BIOS
> gui and use in coreboot ?
if you have such a "BIOS gui", you can integrate it with the tianocore
payload for coreboot. However, how to integrate it is more an
Hi Paul,
On 28.06.20 11:35, Paul Menzel wrote:
> The only remarkable difference in the logs is:
>
> -PCI: 06:00.0 bridge ctrl <- 016b
this seems very suspicious. Bit 3 enables VGA decoding. It shouldn't
matter because it's behind another bridge that hasn't the bit set, but
still, WTF? I have
Hi Michal,
On 25.06.20 10:56, Michal Zygowski wrote:
> One will have different max
> resolution display and everything will fall apart and look differently.
> AFAIK libgfxinit reads out the display information (EDID right?) so it
> is possible to calculate the scalers.
that's one use case for
On 24.06.20 15:25, Peter Stuge wrote:
> Michal Zygowski wrote:
>> when VGA option rom is used, SeaBIOS finds the mode it fits the bootsplash
>> resolution and bpp. Additionaly the display area is adjusted to cover whole
>> screen, i.e. when using 1024x768 bootsplash on 1920x1080 screen the
>>
On 23.06.20 16:51, Michal Zygowski wrote:
>>> Now the only thing that comes to my mind are the VGA interrupts, because
>>> SeaBIOS has more complete interrupt services than coreboot. Any comments
>>> or suggestions on that? I think my next step would be to trace all INT
>>> 10h and compare the
Hi Michal,
On 22.06.20 10:29, Michal Zygowski wrote:
> 3. Used VGA option rom to initialize graphics and display the bootsplash
> in coreboot and SeaBIOS as well. What surprised me is that coreboot
> displayed the bootsplash incorrectly (the same color issues as with
> libgfxinit) while SeaBIOS
Hi Julius,
many thanks for bringing this up on the mailing list.
On 11.06.20 02:05, Julius Werner wrote:
Would it be enough to just create a second repository
(3rdparty/restrictive_blobs or something like that) which is not
automatically checked out by CONFIG_USE_BLOBS so people
Hi Nitin,
On 11.06.20 18:44, nitin.ramesh.si...@gmail.com wrote:
> Flash start -> 0xFC00 (with-in 4GB space @4227858432)
this is misleading. Setting it in the FMAP makes sense to make the
calculations work, but the flash is not mapped there.
Because of other fixed resources below
Hello Jeremy,
On 05.06.20 16:28, Jeremy Jackson wrote:
> So far, after 3 people reviewing, there have been 2 identified users of
> the .config and "revision" files embedded in CFBS, which may be affected
> by adding the prefix fallback/normal/
>
> It was suggested to reach out via the mailing
Hello Alan,
On 31.05.20 06:20, Alan K.L. Mok wrote:
> 1. Can anyone please tell let me know how can I achieve the captioned
> objectives? I looked into ifdtool & uefitool but found nothing related to
> my goal. I also tried the "lock ME/TXE" option during make menuconfig but
> Intel chipsec is
On 19.05.20 02:07, Furquan Shaikh wrote:
> On Sun, May 17, 2020 at 2:01 PM Nico Huber wrote:
>> I told people that I had something similar in mind. But actually, I
>> don't like it very much. I fear, if we move things aside, they can be
>> left behind and we might soon hav
Hello together,
Furquan has landed his revert series of the new resource allocator. A
little sad, but this allows us to take a deep breath and fix things
without further breakage.
There is already one change series on Gerrit to bring it back [1]. This
one goes the most conservative way: It moves
Hi all,
On 16.05.20 18:07, Nico Huber wrote:
> On 16.05.20 15:39, Peter Stuge wrote:
>> Even worse, I also could not find any explanation of how the new algorithm
>> is different from the old, neither in commit messages nor in comments.
>
> Such an explanation would have been
Hi Peter,
On 16.05.20 15:39, Peter Stuge wrote:
> But I could not find any detailed explanation of the neccessity for touching
> much less *rewriting* this quite literally central piece of code in coreboot.
I can't speak for Furquan or Google, but I can provide some insight why
such work is
On 09.05.20 12:51, Michal Zygowski wrote:
> 4. If you have a discrete GPU, you may include its VGA option ROM into
> CBFS using correct naming, SeaBIOS should execute it and provide
> graphics output. There is also an option in Kconfig "Onboard VGA is
> prmiary", try to deselect it when using
101 - 200 of 832 matches
Mail list logo
