Issue #538 has been updated by Nico Huber.
Brian L wrote in #note-16:
> > If you want to get libgfxinit working again, a log would really be the next
> > best step.
>
> See attached full ADA debug log, thanks
Thanks. Not what I expected. Gave me some ideas, though, even
Issue #538 has been updated by Nico Huber.
Brian L wrote in #note-13:
> This is not correct, if you've read the above, SeaBios is the only way that
> the option rom does work. I am not sure what the confusion is here. I've
> restated multiple times the environments I've tested and w
Issue #538 has been updated by Nico Huber.
One very important thing: Do you remember the exact coreboot version / config
that you used when it broke?
Many of my ealier thoughts were based on the assumption that it was stock HEADS
and that libgfxinit worked before with your panel. But maybe
Issue #538 has been updated by Nico Huber.
Brian L wrote in #note-10:
> Yup, so I'm like 99% sure now. Coreboot does not initialize my internal
> display whether using libgfxinit or vga blob. However, if SeaBios runs the
> vgablob, then it does work
>
> So... i just foun
Issue #538 has been updated by Nico Huber.
Patrick Rudolph wrote in #note-4:
> UEFI firmware patches the VBT, while coreboot does not. Maybe a wrong version
> was checked in causing this issue?
This could indeed be part of the problem:
```
$ intel_vbt_decode --file=src/mainboard/lenov
Issue #536 has been updated by Nico Huber.
Why explicitly specify `libcurl4` anyway? If it's a dependency, `apt-get` can
solve it. If we want to build anything with it, we need one of the `-dev`
variants instead.
Bug #536: Cannot build coreboot-sdk
Hi coreboot fellows,
yesterday some patches[1] surfaced on Gerrit about a handover for 64-bit
x86 payloads. Strictly speaking, we don't have to do anything for this
right now, as the original, protected-mode handover would work too. How-
ever, there is X86S on the horizon. If you don't know
Issue #522 has been updated by Nico Huber.
Valerii Huhnin wrote in #note-14:
> * What are well-formed regions?
> * The last address of the region should be representable as a `size_t`
> value?
Definitely yes.
> * The last address of the region +1 should be r
Hi everybody!
as you may know already, flashrom-stable was removed from
review.coreboot.org a while ago. flashrom-stable was a short-
lived semi-fork, based on flashrom v1.2 [1].
The effort to keep developing a stable flash programming tool
for everyone, however, shall continue. I have hence
On 29.11.23 02:01, Julius Werner wrote:
>> I don't like superlatives. I don't think it needs to be "completely
>> separate". For instance, when somebody discusses coreboot for a new
>> platform behind closed doors[1]. And they implement something on the
>> same code base. If they did that
Hi Julius,
On 28.11.23 03:31, Julius Werner wrote:
> Sounds to me like what you're asking for is really documentation, not
> a spec?
well, yes and no. It would be documenting what we did all along.
But also serve as a blueprint for coreboot.
I'm not all set on the term. I think it fits, even if
Hi folks,
something I've been thinking back and forth about since the hackathon
a week ago: Should we give people who promote coreboot something to
refer to, something that more clearly states, what coreboot is?
I know, some of you who know me might feel the urge to check if it
isn't April the
Hi Keith,
On 14.09.23 06:30, Keith Hui wrote:
> What more set up I have to do to get my edk2 and grub boot menu back?
>
> I've attached logs from minicom, cbmem, and my Kconfig, if it helps.
this seems to be the culprit:
CONFIG_VGA_TEXT_FRAMEBUFFER=y
EDK2 requires a linear framebuffer. You
Hello Hannah,
On 07.09.23 20:49, Williams, Hannah wrote:> Already there are binaries
FSP, AGESA, PSP being used in Coreboot and> because of IP and licensing
issues everything cannot be open sourced.
> The uGOP is just a stripped down version of GOP that is already inside
> FSP. This is the
On 25.08.23 06:52, Williams, Hannah wrote:
> I think your suggestion to use similar interface to libgfxinit
> (gma_gfxinit(), gma_gfxstop()) is a good idea. Please add your comments to
> the CLs and we will work on it.
Thanks. I'll wait though, until the decisions about open-sourcing and
Hi Hannah,
On 24.08.23 05:33, Williams, Hannah wrote:
> We understand the hesitation to introduce one more binary blob in Coreboot.
> We are not opposed to open sourcing (we did support libgfxinit for our
> previous platforms). The Meteor Lake platform is at the final stages of
> development
On 24.08.23 07:02, Martin Roth via coreboot wrote:
> I don't like that idea, but as was said in the meeting today, coreboot is
> willing to accept that, but on the condition that the source for the binary
> (and future similar binaries) is made open. To show good faith Intel could
> guarantee
Hi Jeremy,
On 24.08.23 00:24, Compostella, Jeremy wrote:
>> 3) Is there a reason that the uGOP driver can't be open sourced, at
>> least once the Graphics Programmer Reference Manuals are released?
>
> We cannot open-source the code for platforms for which the PRMs are
> not publicly published
On 23.08.23 11:32, Arthur Heymans wrote:
>>> ReportStatusCode() to report debug information which coreboot prints
> using printk.
>> can you point me to the code integrating this? I could find this
> identifier only in vendorcode/ headers. Is it for debugging?
>
> I meant code calling back to the
Hi Arthur,
On 23.08.23 10:41, Arthur Heymans wrote:
> We already have code similar to ReportStatusCode
can you point me to the code integrating this? I could find this
identifier only in vendorcode/ headers. Is it for debugging?
> and ramstage PPI so maybe
> it's not a problem.
I thought this
Hi Jeremy,
On 14.08.23 22:52, Compostella, Jeremy wrote:
> We propose to take advantage of a proprietary driver Intel already supports,
> validates and includes in FSP silicon: the Intel Graphics PEIM (Pre-EFI
> Initialization Module) driver also known as the GOP (Graphical Output
> Protocol)
Hi all,
due to ongoing reliability issues with the matrix.org-to-libera.chat
bridge, channel portalling is going to be disabled [1]. Hence there
is a new Matrix channel #coreboot:matrix.org [2] that is bridged to
the IRC channel on Libera. Hopefully, this will work a little better.
AIUI, the old
Issue #500 has been updated by Nico Huber.
Related links updated
Nico Huber wrote in #note-7:
> It probably needs some tuning, but could work in theory. Anyone with a
> compatible .jpg, please test :)
Found
[ThePlexus](https://github.com/osresearch/heads/blob/master/blobs/ThePlexus-boot
Issue #500 has been updated by Nico Huber.
Related links updated
I don't think there is a limitation to legacy resolutions. At least, I've never
heard of one. So far the resolution had to match the .jpg and that had to be a
multiple of 16 pixels, AIUI.
Until somebody takes on integrating any
Issue #499 has been updated by Nico Huber.
We should probably focus on one problem and one machine (that we can get edk2
logs from) at a time. Sean, thanks for your logs so far. Looking at the latest
logs, I see what Michał pointed out: The 0xFEC0 error is present even
without top-down
Issue #499 has been updated by Nico Huber.
Sean Rhodes wrote in #note-17:
> It's asserting on L1900 of
> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
This?
```
if (((EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)ChildTable)->Dsdt !=
0) {
TableToInstal
Issue #499 has been updated by Nico Huber.
Related links updated
Oberon 4071 wrote in #note-13:
> Nico Huber wrote in #note-11:
> > Alas, nothing obvious in the log. If there is any resource unknown to
> > coreboot, even with a log of the failing boot, we might end up simply
&
Issue #499 has been updated by Nico Huber.
Related links updated
Alas, nothing obvious in the log. If there is any resource unknown to coreboot,
even with a log of the failing boot, we might end up simply constraining the
space for allocations. So we can try that right away: [Here's a patch
Issue #499 has been updated by Nico Huber.
With CONSOLE_SPI_FLASH it seems to hang too early for any useful output. If
you'd return to a working config, a cbmem log would be more comprehensive. It
won't show the same as one with RESOURCE_ALLOCATION_TOP_DOWN, but could already
provide some
Issue #499 has been updated by Nico Huber.
Alas, the flash console log ends before ramstage. It's often not fully working,
but was worth a shot.
Maybe a cbmem log with RESOURCE_ALLOCATION_TOP_DOWN disabled would already
provide some insight. But it's really a bit like shooting in the dark
Issue #499 has been updated by Nico Huber.
> Modifying src/device/Kconfig to change RESOURCE_ALLOCATION_TOP_DOWN to
> "def_bool n" appears to fix the problem on my machine.
The cannonical way would be to add a `default n` to the mainboard or
northbridge Kconfig. However, fixi
Issue #499 has been updated by Nico Huber.
Assignee set to Nico Huber
Could you get a coreboot log of the failing boot? If nothing else is available,
CONFIG_CONSOLE_SPI_FLASH might work.
Bug #499: coreboot will not boot edk2 on Lenovo T440p
On 21.06.23 04:58, David Hendricks wrote:
> On Tue, Jun 20, 2023 at 4:41 PM Peter Stuge wrote:
>> ron minnich wrote:
>>> And, yes, no question, this is an activity that likely occurs less than it
>>> should. Such is our industry.
>>
>> Such is project policy. Maybe because it's the lowest common
On 21.06.23 01:23, ron minnich wrote:
> The approach in the last 24 years (of this unsustainable project :-) has
> been to get several mainboards of a type, and, once we have them, try to
> work out what code is truly common and what code is similar but not truly
> common.
AFAICT, for the last
On 21.06.23 01:07, Peter Stuge wrote:
> (sorry if you receive this twice)
>
> David Hendricks wrote:
>> it will be easier to refactor portions of the code with the large
>> patches merged in a buildable and (hopefully) usable/testable state.
>
> That's pretty weak sauce and I think you all know
On 19.06.23 23:01, Paul Menzel wrote:
> Am 19.06.23 um 22:31 schrieb Martin Roth:
>> Duplicated code between mainboards isn't a big issue in my opinion.
>> It allows the boards to be customized without worrying about other
>> companies' mainboards. We've tried to make mainboards as small as we
>>
Issue #478 has been updated by Nico Huber.
Can you provide a dmesg log? or even better, one with coreboot and one with
vendor. It's probably just a flag somewhere that's telling Linux to use TSC.
But that's easiest debugged in the OS.
Bug #478: X200
Hi Keith,
On 02.04.23 15:33, Keith Hui wrote:
> Here is the command line I figured would work, gathered with "make -n":
>
> gcc -Isrc -Isrc/include -Isrc/commonlib/include
> -Isrc/commonlib/bsd/include -Ibuild -I3rdparty/vboot/firmware/include
> -include src/include/kconfig.h -include
Hi Pratik,
On 10.03.23 02:19, Prajapati, Pratikkumar V wrote:
> For my patch https://review.coreboot.org/c/coreboot/+/71120, the Jenkins
> build fails with following error:
>
> "Check Kconfig files for errors (lint-stable-008-kconfig): #! Error:
>
Issue #460 has been updated by Nico Huber.
I mean `lga1155` and `lga1150` respectively.
Refactoring #460: Make mainboards using the variant concept
https://ticket.coreboot.org/issues/460#change-1417
* Author: Felix Singer
* Status: New
* Priority
Issue #460 has been updated by Nico Huber.
It's actually quite simple to put an accurate name on it: Use something that is
soldered to the mainboard. In case of platform code that supports multiple
chipsets, it's usually the CPU socket that they have in common. `lga1155`
should work here
Hi Martin,
thanks for your reply.
On 15.01.23 00:36, coreboot org wrote:
> Since both branches are actually in the same repo here, I don't think
> any change is needed, or actually even desired. My opinion is that if
> we cherry-pick between branches at coreboot.org and update those tags,
>
Hi fellow coreboot developers,
it was pointed out to me that I didn't do exactly what Chromium
developers are used to (i.e. what util/scripts/cross-repo-cherrypick
does) when picking patches to flashrom-stable.
The major difference is that I didn't prepend Signed-off-by tags
with an `Original-`.
On 08.01.23 17:42, ron minnich wrote:
> For reasons I still don't understand, the various linux distros no longer
> ship .a as part of the library package.
They ship them separately. On Ubuntu, usually a -dev package. I even
recall -devel-static packages (-devel was headers only and such)
~20
On 07.01.23 23:53, Rafael Send wrote:
> If I wanted to try your first suggestion, does the toolchain build
> transcend directories? In order to not mix up trees & versions so far I
> have just checked out the latest master and the version in question into
> two totally separate coreboot folders.
Hi Rafael,
On 07.01.23 22:03, Rafael Send wrote:
> I didn't downgrade the toolchain intentionally, I'm looking to build a fork
> of coreboot for a specific platform (mjg59's X2100 port) that never got
> upstreamed. After pulling his repo at
> https://github.com/mjg59/coreboot/tree/x2100_ng, that
Hi Denis,
On 05.01.23 18:03, Denis 'GNUtoo' Carikli wrote:
> On Wed, 4 Jan 2023 09:58:59 -0700
> Nicholas Chin wrote:
>>> And given that there is no way to guarantee that a Mainboard doesn't
>>> get removed, we'd also need to watch what is happening with the GM45
>>> Thinkpads as well, as this
Hi Denis,
On 04.01.23 17:33, Denis 'GNUtoo' Carikli wrote:> On Wed, 4 Jan 2023
04:37:01 +0100 (CET)
> Martin Roth wrote:
>> I think you're right that we need some way to guarantee that boards
>> added to coreboot aren't going to be dropped again in a short period
>> of time, but that requires
Hi Arthur, coreboot fellows,
On 30.09.22 13:53, Arthur Heymans wrote:
> What are your thoughts?
printing, bonfire...
> Do we take a stance against FSP-I integration in coreboot?
I think we already do. From coreboot.org:
"coreboot is an extended firmware platform that delivers a lightning
Hello Roman,
On 09.09.22 17:48, roman perepelitsin wrote:
> I use coreboot for ApolloLake CPU (Atom). We have SuperIO WB83627-DHG chip
> on carrier board. LPC enabled, POST codes work normal. But I can't get
> access to SIO under Linux (via port 0x2e). Superiotool can't find chip.
> Also, I have
Issue #415 has been updated by Nico Huber.
File t500.log added
File hermes.log added
Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks booting
https://ticket.coreboot.org/issues/415#change-1094
* Author: Sean Rhodes
* Status: New
* Priority: Low
* Target
Issue #415 has been updated by Nico Huber.
File up_squared.log added
Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks booting
https://ticket.coreboot.org/issues/415#change-1093
* Author: Sean Rhodes
* Status: New
* Priority: Low
* Target version: none
Issue #415 has been updated by Nico Huber.
Subject changed from RESOURCE_ALLOCATION_TOP_DOWN breaks booting
(edk2) to RESOURCE_ALLOCATION_TOP_DOWN breaks booting
Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks booting
https://ticket.coreboot.org/issues/415
Issue #415 has been updated by Nico Huber.
Subject changed from RESOURCE_ALLOCATION_TOP_DOWN breaks booting (-edk2-) to
RESOURCE_ALLOCATION_TOP_DOWN breaks booting (edk2)
Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks booting (edk2)
https
Issue #415 has been updated by Nico Huber.
Subject changed from RESOURCE_ALLOCATION_TOP_DOWN breaks edk2 to
RESOURCE_ALLOCATION_TOP_DOWN breaks booting (-edk2-)
It turned out that there are a lot of platforms in the tree that still don't
report their fixed resources correctly. These should
Issue #412 has been updated by Nico Huber.
```
[ERROR] SF size 0xc0 does not correspond to CONFIG_ROM_SIZE 0x40!!
```
`CONFIG_ROM_SIZE` needs to cover both chips. It's a known issue that coreboot
will write the MRC cache at the wrong offset otherwise. As reading happens
memory-mapped
Hi,
On 25.08.22 08:53, Moorthi M.s wrote:
> Hi Nico,
>
>> did you get that from the binary or from the running system? It's
>> possible that your BIOS patches it at runtime, and the one in flash might
>> be unusable. On Linux, you can find the active VBT in debugfs, usually
>>
Hi Moorthi,
On 19.08.22 07:32, Moorthi M.s wrote:
> I have also extracted and added the vbt.bin from BIOS to coreboot.
did you get that from the binary or from the running system? It's
possible that your BIOS patches it at runtime, and the one in flash
might be unusable. On Linux, you can find
On 12.08.22 14:04, Sam Kuper wrote:
> On Thu, Aug 04, 2022 at 10:26:25PM +, Felix Singer wrote:
>> However, I have an idea for a solution. I took a look at the Redmine
>> database and I played around with the Google login method. My tests
>> showed that it creates a normal user account, as it
On 25.06.22 22:05, Nico Huber wrote:
> Reasons for the changes are somewhat the same as always: we haven't
> finished the support for 64-bit resources. Currently one has to opt
> in for a placement above 4G with a resource flag, and even this has
> its limitations. For instance, re
Hi Pedro,
On 06.08.22 18:45, Pedro Erencia wrote:
> I was going to try coreboot on an ASROCK FM2A88X Extreme4+ (
> https://www.asrock.com/mb/AMD/FM2A88X%20Extreme4+/) with the configuration
> of the supported ASUS A88XM-E (
> https://doc.coreboot.org/mainboard/asus/a88xm-e.html) which has the
Hello Petr,
thanks for reporting this. Are you using your host toolchain to build
coreboot by any chance (CONFIG_ANY_TOOLCHAIN)? or do you use `make
crossgcc*`?
On 10.07.22 05:40, Petr Cvek wrote:
> but on my setup there is no ORBC magic ID. Instead it seems a
> ".note.gnu.property"
> section
Issue #343 has been updated by Nico Huber.
I think this is related:
https://review.coreboot.org/c/coreboot/+/64235
Bug #343: Fails to load GRUB payload: CPU Index 0 - APIC 0 Unexpected
Exception:6 @ 10:9016 - Halting
https
Hi coreboot fellows,
after two years with the new resource allocator it's time again for
some changes[1]. Much less invasive than last time, but again there
will be changes in the pattern where resources are placed. So once
more this may uncover bugs in case fixed resources are not reserved
Issue #387 has been updated by Nico Huber.
Raul Rangel wrote in #note-7:
> Just FYI, the board schematics are here:
> https://github.com/FrameworkComputer/Mainboard/blob/main/Electrical/Mainboard_Interfaces_Schematic.pdf
That's just bits about the connectors,
Issue #387 has been updated by Nico Huber.
> Framework controls this key, and has proposed creating both a signed
> "official" coreboot image as well as signed shim which would allow user-built
> coreboot firmware to be used.
I hope they know what they are talking about.
Hi Sheng,
On 16.04.22 11:01, Sheng Lean Tan wrote:
> Personally I think moving Galileo soc to stable branch is a win-win situation
> for all of us.
it looks like nobody is maintaining such a stable branch yet. Would you
volunteer to maintain one for Quark? AIUI, some people already want to
take
On 12.04.22 23:22, Martin Roth via coreboot wrote:
> Apr 12, 2022, 12:14 by f...@mniewoehner.de:
>> Maintaining without ability to test will make it degrade, too.
>>
> Exactly. By moving it to a branch, if someone wants to work on a platform,
> they can do it in a more stable environment.
I
Hello Ron,
I agree with most what you are saying in general. However, I find it
very concerning that you make it about Quark. Are you sure you are
not just jumping on the bandwagon because people started to pick on
Quark? There are probably many boards in the tree that are even more
abandoned and
Hello Insurgo,
On 12.04.22 16:01, Insurgo Technologies Libres / Open Technologies wrote:
> On April 12, 2022 8:55:56 AM UTC, Arthur Heymans wrote:
>>> Would it make sense to backport your fix to old releases and bump
>>> those release numbers to a .1 on the end?
>>>
>>
>> Some see releases as
On 22.03.22 12:01, Mariusz Szafrański via coreboot wrote:
>> At some point of time I was thinking about something called
>> "subdomains" concept to cover this multiple root buses in one
>> domain case so to make something like:
>>
>> domain 0 //domain
>> domain 1
On 22.03.22 09:57, Mariusz Szafrański via coreboot wrote:
> e.g. if we got from HOB info that physical stack x has preallocated PCI
> buses 0x20..0x2f, io form 0x2000..0x2fff, mem 0xd000..0xdfff,
> mem 0x100...0x1ff and there are 2 root buses 0x20 and
> 0x28 instead of
On 22.03.22 10:30, Arthur Heymans wrote:
> OTOH, does it even make sense to map this in the devicetree? The way FSP
> reports stacks is generated at runtime and differs depending on the
> hardware configuration.
> So having a static structure mapping that may not be interesting?
IMO, a static
Hi Lance,
On 18.03.22 05:06, Lance Zhao wrote:
> Stack idea is from
> https://www.intel.com/content/www/us/en/developer/articles/technical/utilizing-the-intel-xeon-processor-scalable-family-iio-performance-monitoring-events.html
thank you very much! The diagrams are enlightening. I always
Hi Arthur,
On 17.03.22 19:03, Arthur Heymans wrote:
> Now my question is the following:
> On some Stacks there are multiple root busses, but the resources need to be
> allocated on the same window. My initial idea was to add those root busses
> as separate struct bus in the domain->link_list.
On 15.03.22 12:25, Nico Huber wrote:
> Hi Peter, Paul,
>
> On 15.03.22 02:18, Peter Stuge wrote:
>> Paul Menzel wrote:
>>> x86_64-linux-gnu-gcc-12 .. -std=gnu11 ..
>> ..
>>> In file included from src/include/cpu/x86/lapic.h:4,
>>> f
Hi Peter, Paul,
On 15.03.22 02:18, Peter Stuge wrote:
> Paul Menzel wrote:
>> x86_64-linux-gnu-gcc-12 .. -std=gnu11 ..
> ..
>> In file included from src/include/cpu/x86/lapic.h:4,
>> from src/cpu/x86/lapic/lapic.c:5:
>> In function 'read32',
>> inlined from 'xapic_read' at
Hello Galarazamba,
On 25.02.22 14:47, Galarazamba via coreboot wrote:
> I am trying to build a Heads x230-maximized.rom on Debian 10.4.0,
>
> but right at the beginning I get the error, that the certificate of
> www.coreboot.org cannot be trusted because it has expired.
you can see the received
Hi Keith,
On 01.02.22 08:18, Keith Hui wrote:
> Read my story then tell me what I need to know and do, and if I've
> taken on too much.
>
> With my P8Z77-M board committed, I've restarted another decade-old
> platform coreboot port.
>
> This time it's the M4A785TD-M EVO, another Asus board, also
Hi Rao,
On 28.01.22 14:30, Rao G wrote:
> 2)
> ScSpiBar0 = MmioRead32 (SpiInstance->PchSpiBase +
> PCI_BASE_ADDRESSREG_OFFSET) & 0xF000;
>
> Expectation:
> this should return value at 0xC00FD010
>
> Result
> The above code is throwing processor exception
>
> PchSpiBase at 0xC00FD000
>
Hi Bernd,
On 18.01.22 14:41, bernd...@web.de wrote:
> So, after having made clear the corresponding points do you think that the
> following hardware will be sufficient to flash the coreboot/SeaBIOS ROM to the
> chip of my ThinkPad X220 (notebook version, not tablet version):
>
> Raspberry Pi
Hi,
On 19.01.22 14:27, Jeff Daly wrote:
> Intel continues to support inclusion of support for Denverton in coreboot,
> but there will be a shift in day to day maintenance is all rather than the
> maintenance being completely internal.
AFAICT, this doesn't mean it will shift but it may start.
On 18.01.22 10:40, bernd...@web.de wrote:
> "Depends on your ThinkPad model, usually yes if the clip fits the chip,
> the wires fit the clip and aren't too long, and you have PSUs to power
> everything."
>
> It's a ThinkPad X220 (notebook version, not tablet version). Let's provide
> that
> the
On 16.01.22 18:16, bernd...@web.de wrote:
> Hello Nico,
>
> ... "It can act as the second computer, you just need a keyboard and screen I
> suppose. flashrom works well on the RPi. Usually you can just install
> it with your package manager." ...
>
> Is a Raspberry Pi with keyboard, screen and
Hello Bernd,
On 16.01.22 11:09, bernd...@web.de wrote:
> ... "other solutions like a Raspberry Pi or STM32." ...
>
> Is the STM32 a board like the CJMCU-2232H which has a USB connection and a pin
> header and that's attached to a second computer via USB and to the programming
> clip via jumper
s currently based on one changing the PCI ID
macro in `xhci.c`. When you cherry-pick the xHCI commit alone (on master
where the macro name didn't change), the file contents are different.
Nico
>
>
> -----Original Message-
> From: Nico Huber
> Sent: Wednesday, January 12, 2022 12:0
On 12.01.22 16:21, Jeff Daly wrote:
> Ok that sort of makes sense, but for example in the case of the XHCI patch,
> the merge conflict appears to be that since soc/intel/denverton_ns/xhci.c was
> changed completely to reflect the usage of the common code and shouldn't
> cause an issue with
Hi Igor,
On 23.12.21 15:49, Igor Bagnucki wrote:
>
> Dear coreboot community,
>
> as a part of coreboot port for Talos II POWER9 architecture, we are
> porting the cbmem tool. [1] This platform can switch between the
> big-endian and the little-endian. coreboot operates in big-endian but in
>
On 15.12.21 13:24, Krystian Hebel wrote:
> Hi Nico,
>
> On 15.12.2021 12:21, Nico Huber wrote:
>> Hi Krystian,
>>
>> On 14.12.21 13:00, Krystian Hebel wrote:
>>> For our work on POWER9 coreboot port we were using Skiboot [1] packed
>>> into
>>>
Hi,
On 15.12.21 14:25, Sid_key wrote:
> Hello, is 915G supported?
alas not, and it never was, AFAICT. i945 is supported and i855 was once.
> Is it hard to implement support for Gigabyte
> 8i915md-g?
It very much depends on your skillset. It's not hard compared to a
modern mainboard. However,
Hi Krystian,
On 14.12.21 13:00, Krystian Hebel wrote:
> For our work on POWER9 coreboot port we were using Skiboot [1] packed into
> FIT payload.
I might just miss it because I never worked with FIT, but maybe I'm not
the only one: Can you elaborate why you chose FIT? Reading through your
mail
On 10.12.21 12:56, Keith Emery wrote:
> Am I correct in my understanding that bison is complaining about some
> component of the tool chain?
`bison` just shows warnings. The actual problem is the C compiler
showing some errors (actually just warnings, but acpica is configured
to make them
Hi Keith,
On 10.12.21 09:28, Keith Emery wrote:
> So I set out to repeat the experiment on my local computer. Only to find
> that the current master branch of Coreboot fails to build the tool
> chain. I was following the tutorial to the letter, but received the
> following:
>
>
Hello Matthew,
On 02.12.21 19:55, Matthew K wrote:
> 1. Am I even looking at the right chip?
No.
> Is there a different 32MB Rom that I should be flashing to?
Yes and no. There is another chip, but a current Chromebook shouldn't
require you to access the chip directly. Generally, one should be
On 01.12.21 15:57, Ivan Ivanov wrote:
> Thank you, these seem to be good points. However, in regards to:
>
>> If you have any hope of open-source coreboot for newer platforms, you
>> shouldn't make it harder for coreboot to advance.
>
> Where to advance? Are there any "newer platforms" that are
On 01.12.21 11:28, Ivan Ivanov wrote:
> Good thing about what I've suggested - "different places for v3 and v4
> allocators" - is that it's (almost?) already done ;-)
It would mean a constant burden for the project. The resource allocation
is kind of the heart of coreboot's ramstage, it's
On 29.11.21 15:58, awokd wrote:
> Nico Huber:
>> On 29.11.21 14:49, awokd wrote:
>>>>
>>>> Branching
>>>> -
>>>> I know some people are easily offended by the thought, but I want to
>>>> mention it anyway as it seems to m
On 29.11.21 14:49, awokd wrote:
>>
>> Branching
>> -
>> I know some people are easily offended by the thought, but I want to
>> mention it anyway as it seems to me like a cheap solution for the com-
>> munity as a whole. We could maintain platforms on separate branches.
>
> Is this
On 28.11.21 19:54, Nico Huber wrote:
> Oh, and I almost forgot, the board ports don't look like coreboot code.
> There's CamelCase, odd tables in C code (as if there was no devicetree),
> AGESA configuration done in the code of each and every mainboard that
> should be do
Hi coreboot folks,
there have always been platforms in the coreboot tree that are easy to
maintain and others, alas, that seem to be the complete opposite. When
new features or new iterations of existing code are pushed, we'd love
to keep everything up-to-date. But this is infeasible. Given the
1 - 100 of 832 matches
Mail list logo
