Hi
So to play devil's advocate on why having a 64bit payload handoff/entry
point on AMD64 might be desirable:
- speed (how long does the mode transition take?)
- flexibility: loading and jumping to it above 4G
However I'm not convinced by either argument and I agree with your proposal.
It's
Hi Mike
Same thing as on that AMD platform. Qemu does not support that. In general
x86 will require a special memory map for larger than 16M boot medium, as
below 4G - 16M there are other default MMIO things that will conflict, like
the LAPIC base. That capability to deal with larger flash is
H
I'm not seeing this and the type of the option is set in
src/device/Kconfig. Do you have some local changes that affect that?
Arthur
On Sun, Feb 18, 2024 at 6:33 PM Mike Banon wrote:
> After this commit - https://review.coreboot.org/c/coreboot/+/79058 -
> now I always have this warning
Hi Simon
I agree that both cbfs or fmap for that matter are not practical options as
on some SOC the boot memory is not memory mapped and requires
some hardware init.
We have other instances where cbfstool updates the bootblock code post
compilation: cbfs verification.
See
Hi Hannah
So the only reason for including uGOP as a blob is a failed planning at
Intel and nothing technical?
I agree with Patrick here. This is really an Intel-problem and not
something coreboot should have to put up with.
Arthur
On Thu, Sep 7, 2023, 21:50 Williams, Hannah
wrote:
> It is
Hi Hannah
It looks like your information is not up to date.
https://www.phoronix.com/news/Intel-HDMI-2.1-FRL-Linux so hdmi 2.1
upstreaming in Linux began 10 months ago?
Both Linux and
https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/commits/master/ has
support for VBT, which should suffice
Issue #508 has been updated by Arthur Heymans.
Yu-Ping Wu wrote:
> Similar to #499, after https://review.coreboot.org/c/coreboot/+/75012, Dojo
> fails to boot.
> Disabling CONFIG_RESOURCE_ALLOCATION_TOP_DOWN fixes the problem.
> However I'm not sure how to fix it from MediaTek's PC
mplementation of
> multiprocessing.
>
On Wed, Aug 23, 2023 at 11:14 AM Nico Huber wrote:
> 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
Hi
> 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) driver.
Usually the reasoning for using a binary is because
Hi
The NIC device needs to be in the devicetree.cb for on_board to be set to 1
(done by sconfig).
On the GA-G41M-ES2L you see the onboard nic as a child device below a PCIe
port:
device pci 1c.1 on # PCIe 2 (NIC)
device pci 00.0 on # PCI 10ec:8168
subsystemid 0x1458
Issue #457 has been updated by Arthur Heymans.
It is quite hard to relocate a binary (mrc.bin). This was done for the
sandybridge using a hexeditor, but that is quite errorprone.
Native init could use a different address but it is not as complete as the
mrc.bin.
For instance I think dram
Hi all
On most modern x86 systems a lot of the silicon init happens as part of
blob (FSP, binaryPI)
or some reference code (AGESA). Very often that silicon init enables or
hides
PCI devices. This means that this code needs to run before coreboot device
enumeration code.
With coreboot's current
Issue #420 has been updated by Arthur Heymans.
https://review.coreboot.org/c/coreboot/+/51710 Implements the TCG one. The
coreboot implementation is not a 'proprietary' format. That would imply that
there is a license restriction on using it which there is not.
A lot of the TCG spec simply
t=PLehYIRQs6PR5N73cbW8CPvU_stDTAG_j5
>
>
>
> Thanks,
>
> *Laurie*
>
>
>
> laurie.jarlst...@intel.com,
>
> System Firmware Products
>
> Firmware Ecosystem & Business Dev.
>
> (503) 880 5648 Mobile
>
>
>
> *From:* ron minnich
> *Sen
Issue #401 has been updated by Arthur Heymans.
Christian Walter wrote in #note-4:
> Is this a problem within coreboot - or do we rather need to fix up EDKII ?
The problem is inside EDKII. Those reverts would create problems for other
payloads and Linux would even complain about incoherent M
Issue #392 has been updated by Arthur Heymans.
Can you check if https://review.coreboot.org/c/coreboot/+/65250 fixes it?
Bug #392: coreboot 4.16 & 4.17 - SeaBIOS Windows 10 BSOD "ACPI Error"
https://ticket.coreboot.org/issues/392#change
e stack. */
> andl$0xfff0, %esp
>
> /* Call C code */
> callmain
>
> The question is why we can't reach main() anymore. Any clues?
>
> Kind regards,
> Sumo
>
>
>
>
> On Tue, Jun 14, 2022 at 6:27 AM Arthur Heymans
> wro
Hi
Awesome initiative!
I think more openness around FSP-S is indeed the best way to start
improving things for both developers and users on Intel hardware.
It's not uncommon that you have to tell a customer that you can't fix a
problem because the cause is inside the FSP.
Even if you have the
on minnich wrote:
>
>> arthur, what might we do with either the build process or startup to
>> avoid this problem in future? Do you think we could find a way to
>> catch this programmatically soon, rather than humanly too late?
>>
>> On Mon, Apr 11, 2022 at 2:48 AM
Hi
Those arguments not to use #pragma once make a lot of sense. Thanks Martin!
I've made some good progress on getting boards to build with clang (each
x86 board now builds). Clang at least warns about #ifndef and #define lines
not being equal so we'd have that check covered.
Kind regards
Hi
I have patches that improve those platforms and wrote code that should make
some of
the AGESA platforms easier to transition to newer soon to be mandated
codepaths and I did so
with past codepath mandates with both code and review.
My message about moving code from the master branch was more
Issue #343 has been updated by Arthur Heymans.
Bisected. 4ea7bae51f97e49c84dc67ea30b466ca8633b9f6 is the culprit in grub.
Bug #343: Fails to load GRUB payload: CPU Index 0 - APIC 0 Unexpected
Exception:6 @ 10:9016 - Halting
https
Issue #322 has been updated by Arthur Heymans.
Status changed from New to Resolved
Fixed by https://review.coreboot.org/c/coreboot/+/61938
Bug #322: Image fails to boot on Thinkpad X201 if built with GCC 11
https://ticket.coreboot.org/issues/322#change
Hi Julius
Sounds good to me.
Btw a similar discussion happened on the LKML.
https://lore.kernel.org/lkml/CAHk-=whFKYMrF6euVvziW+drw7-yi1pYdf=uccnzj8k09do...@mail.gmail.com/
is the upshot,
which is complete agreement with what you said.
Kind regards
Arthur
On Fri, Apr 15, 2022 at 11:30 PM Julius
Hi
In 2016 'uart_pci_addr' was added to the coreboot table entry for serial
devices.
(https://review.coreboot.org/c/coreboot/+/14609)
It was done for the Intel Quark platform which has its uart on a PCI device
like other
Intel hardware. Right now only Quark sets this to a non zero value using an
Hi
When platforms stand in the way of improving the general code base, I think
that's it's not controversial
to ask people to either step up and do necessary maintenance or move the
platform to a branch. Past examples of
that would things like dropping romcc bootblock, car global, ...
When a
ve seen us do that in the past (because issues are quite often
just fixed in master).
Kind regards
Arthur
On Tue, Apr 12, 2022 at 12:52 AM Peter Stuge wrote:
> Arthur Heymans wrote:
> > I think this issue might affect a lot more systems than I initially
> thought.
>
> Would it
roblem in future? Do you think we could find a way to
> catch this programmatically soon, rather than humanly too late?
>
> On Mon, Apr 11, 2022 at 2:48 AM Arthur Heymans
> wrote:
> >
> > Hi
> >
> > After last week's SMM loader problem on all but the BSP, I
Hi
After last week's SMM loader problem on all but the BSP, I noticed another
problem in the SMM setup.
The permanent smihandler is currently built as a relocatable module such
that coreboot
can place it wherever it thinks it's a good idea. (TSEG is not known at
buildtime).
These relocatable
might affect a lot more systems than I initially
thought.
Kind regards
Arthur
On Fri, Apr 8, 2022 at 12:43 AM Arthur Heymans wrote:
> Hi
>
> When refactoring the coreboot SMM setup I noticed that there is a security
> vulnerability in our SMM setup code.
>
> It boils down to this:
Hi
When refactoring the coreboot SMM setup I noticed that there is a security
vulnerability in our SMM setup code.
It boils down to this: except on the BSP the smihandler code will execute
code at a random location, but most likely at offset 0. With some carefully
crafted code a bootloader or
Hi
I would like to add a few notes to the meeting notes to clarify things a
bit better.
* In the coreboot meeting, it was suggested that we push to just use
> coreboot tables as they’re already supported in a number of
> payloads. This really isn’t practical however. Intel would
nction would essentially be a loop over the
devicetree struct which seems more fragile when things are being appended
to it (scan_bus).
On Tue, Mar 22, 2022 at 2:11 PM Mariusz Szafrański via coreboot <
coreboot@coreboot.org> wrote:
> W dniu 22.03.2022 o 12:38, Arthur Heymans pisze:
> >
Hi
Hi
>
>
>> 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 adding one domain with "physical" stack we
that I was used for some time was to use
> something like:
> domain 0
> //first root bus
> pci 0:0.1end
>
> //second root bus
> pci 0x20:0end //overflow at 0x20 pci bus number boundary
>
> end
&g
this situation (multiple root busses on
> one stack) we "virtually" splitted this stack and its resource window to
> two or more virtual stacks and later handled as separate stacks.
>
> Mariusz
>
> W dniu 17.03.2022 o 19:03, Arthur Heymans pisze:
> > Hi
> >
&
Hi all
Thanks a lot for the input.
I looked a bit further into this and it looks like only the resource
allocation parts assumes one downstream bus under link_list.
The rest of coreboot seems to properly account for sibling busses, so maybe
making the allocator loop over ->next in busses is
not
struct bus'ses is certainly an option here,
but I was told that having only one bus here was a design decision on the
allocator v4 rewrite. I'm not sure how common that assumption is in the
tree, so things could be broken in awkward ways.
Do you have any suggestions to move forward?
Kind regards
Hi
It looks like alignment on a packed struct being cast two times to
different integers was the root cause for the ironlake platform.
https://review.coreboot.org/c/coreboot/+/61938 fixed the issue.
Kind regards
On Mon, Feb 14, 2022 at 9:12 AM Arthur Heymans wrote:
> Hi
>
> There
Hi
There have been some reports of GCC11 not booting on some AGESA fam15
platforms and on Intel ironlake.
I confirmed that on my X201 (ironlake). The system hangs at an endless loop
during heci init.
The code generated doing that part is not wrong, which makes me think that
other code in that
ing all the
> > > > people who would like to build coreboot for AMD boards from this
> list, even right now I am in an
> > > > active message exchange with >10 people who are switching to these
> boards to run coreboot
> > > > on them - and any user may give back to
lt;< 1)
> +#define H_SMRAME (1 << 7)
Those are northbridge specific register on how to handle the SMM windows
(SMRAM). The BKDG should have something similar.
TSEG is also an interesting search parameter.
On Thu, Nov 25, 2021 at 7:39 PM awokd via coreboot
wrote:
> Arthur Hey
> To address the OP, it seems like there is some activity on getting an
> AGESA RESOURCE_ALLOCATOR_V4 working, but is an AGESA PARALLEL_MP init
> also needed (and is there any activity or something I can do to help?)
> Realize resources may not exist to spoon feed problem definitions to a
> level
we still care about the coreboot marketshare on
> > > the worldwide-available consumer PCs. Small improvement in the common
> > > source, but a huge loss of boards? (almost 50!). For the sake of the
> > > bright future of the coreboot project, this must be prevented at a
(although there
> might have been some other problems undercover). I wonder if it could
> help and will be happy to test the new changes related to this.
>
>
> On Wed, Nov 24, 2021 at 8:52 PM Arthur Heymans
> wrote:
> >
> > > We could announce this deprecation in the 4
> We could announce this deprecation in the 4.16 release notes, then
deprecate after 4.18 (8.5 months from now). At that point, we'd create a
branch and set up a verification builder so that any deprecated platforms
could be continued in the 4.18 branch.
That timeline of 8.5 months does sound
Hi
I would like to suggest to deprecate some legacy codepaths inside the
coreboot tree and therefore make some newer ones mandatory.
The first one I'd like to deprecate is LEGACY_SMP_INIT. This also includes
the codepath for SMM_ASEG. This code is used to start APs and do some
feature
Hi
That MTRR setup looks suboptimal for sure, but not fatally flawed.
What's located at 0x7700 till 0x8000? I suspect it's just dram but
maybe allocated for different purposes like TSEG, GFX stolen memory,
If you mark it as such during resource allocation the MTRR solution will be
>
> 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 Python a dependency, however I think it's fine to keep things
> as-is where it can be used for helper scripts and utilities for
Hi
Try with https://review.coreboot.org/c/coreboot/+/55389 applied.
Kind regards
Arthur
On Thu, Jun 10, 2021 at 3:16 PM Sumo wrote:
> Hi,
>
> Coreboot is not starting on denverton due to this commit:
> * 0f068a600e drivers/intel/fsp2_0: Fix the FSP-T position
> (found this by doing a manual
of boot performance on this platform.
- I also have some WIP code to merge postcar into ramstage which would save
15k.
Maybe on coreboot release 4.15 you will have a better time building a fully
working image with the default configuration.
Kind regards
Arthur Heymans
On Fri, May 21, 2021 at 7:08 AM
Hi Werner
Sounds good.
I got rid of the SeaBIOS dependency on the CBFS master haeder:
https://mail.coreboot.org/hyperkitty/list/seab...@seabios.org/thread/PSLZAMCG7C5IU6TLEGXWZCESXHPYUS76/
Maybe that can be of use for you?
Arthur
On Fri, Apr 30, 2021 at 12:38 PM Zeh, Werner wrote:
> Hi
ption or add
a pointer to "fsp-t" at a fixed location in the bootblock and have the
tooling update the pointer during the build process. I think the Kconfig
option is the least amount of work and cbfstool is already overloaded with
options and flags, so my pre
Hi
Thanks for your input!
Peter Stuge writes:
> Arthur Heymans wrote:
>> To make Intel CBnT (Converged Bootguard and TXT) useful in coreboot
some
>> tooling is required to generate both a Key Manifest (A signed
binary, that
>> is checked against a key fused into the ME,
Patrick Georgi via coreboot writes:
> Am Di., 9. Feb. 2021 um 11:34 Uhr schrieb Arthur Heymans
:
>
> So TL;DR:
> - Is (temporarily) adding a tool to the blobs repo ok?
>
> If it matches the requirements of the blobs repo wrt. license terms
and documentation, I don't see why
we hope that this is an acceptable solution to the
community.
So TL;DR:
- Is (temporarily) adding a tool to the blobs repo ok?
- Is integrating an (optional) not yet open tool into the build system ok?
Let me know what you think.
Kind regards.
Arthur Heymans
9elements GmbH, Kortumstraße 19-21
is not pro, but I don't
> know off my head what the difference is. And I get to deal with ME.
>
Best way to deal with ME is to not deal with it at all and just flash
the BIOS region ;). Some possible differences are enabled/disabled pci
devices and gpio's. You should be able to add th
ic mailing list...
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
Kind regards
--
==
Arthur Heymans
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe s
with a similar PEI/mrc.bin is better at guarding against invalid
values. Maybe that code should be adapted to haswell.
1600MT/s is what the controller officially supports. Anything faster is
overclocking and the mrc.bin likely does not support that.
--
Arthur Heymans
_
iew.coreboot.org/c/coreboot/+/36143/
https://review.coreboot.org/c/coreboot/+/36144
https://review.coreboot.org/c/coreboot/+/36145/
> Any thoughts?
>
> Arthur Heymans
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsu
as on S3 resume the ramstage is typically
fetched from RAM (cbmem or tseg stage cache).
Any thoughts?
Arthur Heymans
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
People can contribute to coreboot without even owning a physical device
on which coreboot runs, let alone *your* favorite board. The board you
suggest is not a good example at all. The code supporting that board has
some serious quality issues.
Kind regards
--
==
Arthur Heym
ase)
implements the things you are asking for. Just wondering is this a
mainline driver in FreeBSD? Linux got one quite recently.
--
==
Arthur Heymans
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
Arthur Heymans writes:
> Now moving forward it would be a nice goal to set for the October
> release 2020 to have NO_CAR_GLOBAL_MIGRATION as a mandatory feature?
> This was already discussed in [2], without a decisive conclusion.
I meant Oktober 2019, that is 9 months from now which s
Hi
Currently most x86 platforms have CONFIG_NO_CAR_GLOBAL_MIGRATION set by
implementing POSTCAR_STAGE. This means that global variables during CAR
stages don't need to be migrated to cbmem when initializing cbmem, as
stages are cleanly separated programs (in other words you don't tear
down CAR
a proper default
FMAP, populate the CBFS FMAP regions, implementing a cbfs_locator) but
does allow for nice features like locking the fallback CBFS region to
make sure the fallback can't be erased by accident.
Any thought or suggestions?
Kind regards
Arthur Heymans
symbols are found. Supposedly it allows board porters
to gradually work towards with a checklist of things to do while
in reality its just an extra burden to maintain a list of symbols.
So can we remove util/checklist? [1] does that.
Kind regards
Arthur Heymans
[1] https://review.coreboot.org/c
ith DDR3 (implements S3 resume) and a SPI boot
medium, that would be fun.
It does not look this has anything to do with the original thread title
so sorry for hijacking it a little...
> Regards
>
> Felix
Kind regards
--
==
Arthur Heymans
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
ome hardware to showcase
but I don't own shiny new stuff. Maybe my setup using Felix's qspimux
that I use to quickly test roms on hardware can be interesting to
showcase?
Kind regards
--
======
Arthur Heymans
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mail
and resetting and programming that value on AP's
Kind regards
Arthur Heymans
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
globals can be dropped are FSP1.0 platforms and geode_lx.
geode_lx still has to implement EARLY_CBMEM (requirement for 4.7 and 4.9 is
coming soon)...
Kind regards
Arthur Heymans
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
ds
>> > in the tree is a nice service to Jay. Thanks, but we're well
>> aware.
>> > Can you also convince us that it's a good service to the users of
>> > Jay's boards who expect master (and any future release) to work, given
>> > that there's code for boards of that specific name?
>> >
>>
>> First, it's more than just me. I know for a fact that we aren't the only
>> ones developing coreboot-based solutions based on both Broadwell-DE
>> and Bay Trail that would like to see support continued, not arbitrarily
>> removed because it didn't conform to the proposal. So please don't
>> belittle it down to being just a "nice service to Jay". This is much bigger
>> than just me, my company, or our clients.
>>
>> >
>> > (Jay, sorry for singling you out like that)
>> >
>> > Regards,
>> > Patrick
>> > --
>> > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und
>> > -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
>> > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
>>
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
--
==
Arthur Heymans
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
?
Kind regards
Arthur Heymans
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
ree not to integrate such monsters into coreboot in the future?
BTW baytrail has a non FSP port that will likely be in better shape.
Kind regards
Arthur Heymans
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
5
> (480) 445-9895 (FAX)
> jaytalb...@sysproconsulting.com
> http://www.sysproconsulting.com
>
> Original Message ----
> Subject: Re: [coreboot] Further coreboot releases, setting new standards
> From: Arthur Heymans
> Date: Fri, November 23, 2018 8:32 am
> To: Patrick G
is this
> a
> git repository?
> Makefile:18: recipe for target 'seabios' failed
You can try to build the payload separately.
>
> Could someone fix the MSI MS6178 mainboard so that it can be used with the
> recent coreboot?
That would require that platform (i810) to have
ease fix this to:
> 1) Remove kernel log and replace it with "uname -r" to just know the kernel
> version.
The kernel log does contain other useful information, so dropping it
would make the board status repo less useful.
--
==
Arthur Heymans
--
coreboot mail
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?
>
That is indeed w
Dear coreboot community
While the next coreboot release is due for november 2018, I think it
is worthwhile to think about further releases and standards we want to
set.
In the past coreboot adapted numerous general improvements, which were not
always ported to all coreboot targets. Keeping those
t in place to keep that fsp
bootpath happy) I fully endorse the removal of this code.
--
==
Arthur Heymans
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
"cpu_microcode_bins" isnt defined, microcode_amd_fam15h.bin
> isnt included, and update_microcode.c is either never launched or
> gives an error
>
It is tested and the update is done quite early on to make sure the CPU
operates properly before done any other initialization.
--
==
It is however read-
only.
Kind regards
--
Arthur Heymans
signature.asc
Description: This is a digitally signed message part
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
hich case it needs to be programmed on each AP...
Kind regards
--
==
Arthur Heymans
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
lso dispatch
>serializing).
>
>This mode of LFENCE may be enabled by setting MSR C001_1029[1]=1.
>
>This is important and covers a variety of boards such as the KGPE-D16,
>KCMA-D8 and G505s (all the last and best owner controlled x86_64
>systems)
--
Arthur Heymans--
coreboot
on devices from big coreboot vendors (like Google).
So what are your thoughts on this?
Kind regards
Arthur Heymans
--
[1] https://review.coreboot.org/#/c/coreboot/+/18902/
[2] https://review.coreboot.org/#/c/coreboot/+/19905/
--
coreboot mailing list: coreboot@coreboot.org
https
common
2G mmio space below 4G I think it is unlikely for 2 external GPU's to be
an issue.
It would of course be nice to have 64bit BAR support but that would
require substantial changes in the allocator and more importantly a lot
of time spend in a sane and thoughtful design...
> Thanks!
--
===
Dear coreboot community
This is the report of yesterdays community meeting:
General coreboot news & Discussion
==
There is patch [1] up for review that implements LinuxBoot as payload.
- Currently with u-root in the initrd, which is an userspace entirely
he win!
>
> Is this just a BIOS level issue? Or is there some hardware component I should
> be aware of?
>
> Thanks for the help.
> -Adam
>
--
Arthur Heymans
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
you think Coreboot will get around this hangup and, if so,
> can you advise a
> motherboard for me to test with?
>
> Its been a long time sense I last compiled linuxbios. ;-)
>
> Thanks
> -Adam
Kind regards
--
Arthur Heymans
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
util/cbfstool/lz4frame.c:
Add comment to fall through"
Kind regards
--
Arthur Heymans
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
(no EFI bootloader on it), it
seemed to work fine and greeted me with the tianocore loading screen.
--
Arthur Heymans
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Peter Stuge <pe...@stuge.se> writes:
> Arthur Heymans wrote:
>> https://gist.github.com/ArthurHeymans/c5ef494ada01af372735f237f6c6adbe
>
> I note these differences from what I wrote up in the wiki:
> (that may no longer be there though)
>
It's still there for the most
Hi
With some new code and methods the process of flashing a thinkpad x60
from vendor bios (and to some extend a thinkpad t60) can be eased a bit
and wrote down a hopefully useful guide:
Here is the link:
https://gist.github.com/ArthurHeymans/c5ef494ada01af372735f237f6c6adbe
Feedback is of
ed some tweaking).
Kind regards
--
Arthur Heymans
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
rc/misc.o
> Compile checking out/src/stacks.o
> Compile checking out/src/output.o
>
Not sure what you are asking here...
> Third How can I test my ROM with and emulator before installing it?
>
Not possible unless the rom is compiled for a virtual target like qemu.
On real hardwar
f vendor_layout
Then only flash the descriptor region:
flashrom -w x200-descriptor --layout vendor_layout --image fd
> Thanks in advance,
> Michael Widlok
--
Arthur Heymans
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
it for every display output).
There is an FSP path for sandy bridge but it is not used much due to
native code being easier to work with.
>
> Thanks
<#secure method=pgpmime mode=sign>
--
Arthur Heymans
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Hi
In the latest CCM[1] the question was raised whether someone still uses
the configuration option baud_rate from RTC nvram (CMOS) and if not
maybe think about removing this.
The issues raised with this code were:
* they are an extra burden to maintain since console init is done over
multiple
Ok thanks for clarifying.
Aaron Durbin <adur...@google.com> writes:
> On Tue, May 2, 2017 at 5:24 AM, Arthur Heymans <art...@aheymans.xyz> wrote:
>> Hi
>>
>> I am wondering why newer intel code is being pushed to src/soc/intel/*/
>> instead of the tradi
/northbridge/amd memory controller code resides, while in
src/southbridge the code for both the northbridge and the southbridge
resides.
So my question is why does the newer codebase need to be separated like
this and what is the benefit of doing so?
Kind regards
Arthur Heymans
--
coreboot
1 - 100 of 128 matches
Mail list logo
