>
> seabios doesn't read the log, instead it'll append its own messages.
> Which I expect will continue to work fine, except when it hits the end
> of the log buffer, where seabios will simply stop logging instead of
> rolling over.
>
Right, sorry, I confused something while writing the explanatio
>
> Is it possible to figure whenever the cbmem buffer supports rollover or
> not, so a updated seabios version can work correctly with both old and
> new coreboot?
>
Not explicitly, but it should still work fine with both versions. The old
coreboot can only either not fill up the buffer or fill u
>
> Is there an easy way for a running payload to extract additional files
> from its CBFS image in ROM? I'd like to have a reproducible kernel and
> initrd as the primary payload, with user data (and keys) stored in a
> separate payload section of the CBFS.
>
> On the build host I can use cbfstoo
coreboot has multiple stages that run one after the other. If you don't
have UART output you can't be sure how far coreboot gets before it hangs,
so you'll want to check all of them and see which ones contain the
addresses you get from your JTAG. Disassemble
/build/cbfs/fallback/bootblock.debug, ro
+chromium-os-dev
bcc: coreboot
On Fri, Apr 21, 2017 at 11:27 AM, wrote:
>
> Folks,
> If this query more correctly belongs on ChromiumOS list, I will re-post.
>
Yeah, it does. This tool is only related to Chromium OS (and in fact way
older than coreboot on Chromebooks).
> This utility appears
[-seabios for the GRUB part of the thread]
> Could you please also check, if GRUB’s CBMEM console driver, and the
> the command cbmemc to display it need any updates?
>
Thanks, I wasn't aware that GRUB also had a driver for this. I'm happy to
write a patch for it, but unfortunately I'm having so
>
> I'm very concerned with compatibility. You can't guarantee that coreboot
> and payload match. And in case of mismatch you get a memory corruption that
> is very hard to trace. Can we please change signature of cbmem entry?
I would rather allow older implementations to continue working as best
>
> Did you check that all implementations use unsigned?
>
Yes, all the ones that I'm now aware of used unsigned, 32-bit.
> I am able to build it, I just had to figure out how and install some
>> dependencies. But I tried booting it on an HP Chromebook 14 2013 (falco)
>> and it doesn't seem to r
Managed to get it working with serial input now. Found a few issues with my
patch. Will send a new, tested version out.
On Tue, Apr 25, 2017 at 11:48 AM, Julius Werner
wrote:
> Did you check that all implementations use unsigned?
>>
>
> Yes, all the ones that I'm now aware
Is there an easy way to sign up for notifications on new issues in certain
categories? I'm happy to sign up and be responsive for areas that I'm
familiar with, but I don't really have time to just keep up with the whole
thing.
Also, If we wanted to allow something like that we'd likely need much f
But does it have Bluetooth support? I feel like I should really be
able to use my Bluetooth mouse to configure my DRAM timings.
Also no .webp for the splash screen image... like some sort of BIOS
from 2010. Sad.
On Wed, Jun 7, 2017 at 4:16 PM, ron minnich wrote:
> read it and weep, or something.
On Wed, Jun 7, 2017 at 8:37 AM, Johnysecured88 via coreboot
wrote:
> What I don't understand is how this will matter. Releasing the source code
> won't mean that is the source code they are using for PSP. Think of it like
> an open source program with a compiled binary available. The only way to
>
I agree with most of what Patrick said, I think dynamic scaling to integer
multiples may be best. Scaling the font up at compile-time seems like
unnecessary bloat to the binary (although I'm not sure, how big are these
fonts?). If you do want to include them at compile time, you may as well
include
>
> Unfortunately, this picture represents ONLY 32bit transitions, there are
> two more modes for 64 bit, not shown here. If I find the representative,
> I'll post it on the forum (@ list).
>
The box labeled "IA-32e Mode" is 64-bit mode (in their infinite wisdom,
Intel chose a name containing the
FWIW, there should be no reason to build crossystem as part of
coreboot's compile-time utilities at all. crossystem is a helper meant
to run on the target device (the one that uses vboot-enabled
firmware), it doesn't make any sense to have it on the build machine.
We should fix the Makefiles so tha
> The awkward thing about BIOS is that it was a second OS from the first
> day on – while the reasonable philosophy behind firmware should be:
> Start the board, load the OS and go back into your flash until reboot.
My history lessons may be failing me here, but IIRC the main reason
for that was m
> The error is fixed by commit
> 54fd92bc (util/cbfstool/lz4frame.c: Add comment to fall through).
Looks like I'm too late for that commit, but in general, please do not
just hack around in the LZ4 files. That code was pulled in verbatim
from the upstream source -- if there are issues with it, ple
The only special thing about Chromebooks is that they have a
standardized debug header, specified here:
https://www.chromium.org/chromium-os/servo
The header is not populated on consumer devices, but the footprint
should still be there so you can solder it yourself. You can also just
solder to the
> And now I'm kinda stuck. The effect of this commit doesn't seem to interface
> with bios for me. So how does original IBASE/DFI bios can overcome code
> error before this commit?
>
> What can be the source of my problem? What should I investigate more precise
> based on result that I've got?
My
We try to keep the Chromium tree very close to upstream these days (just a
few days of delay at most). So usually you can just add the upstream
repository as a remote and check it out in the coreboot directory of your
Chromium OS SDK chroot, and then the Chromium OS ebuilds will happily build
the u
>
> In grepping the sources I see the API is provided and only used in a
> handful of cases, mainly x86.
>
> On an ARMv8 target is there a power-off use-case for Coreboot?
> This is strictly from Coreboot perspective, not Depthcharge.
>
You're right, there is no globally standardized power off API
>
> I’d really like to *enable as much warnings* as possible to let the
> build tools *catch as much errors as possible*, and having to adapt the
> code to work with this is in my opinion worth the effort.
>
This is not just a question of whether we want to spend the one-time effort
to adapt the c
Hi Patrick et. al.,
Continuing from what you said on IRC, let's please discuss this before you
spend time to work on any major changes to the ARMv8 MMU code. I don't
think that should be necessary (especially changing the GRANULE_SIZE which
is a complication I'd really like to avoid having), and I
Mar 2, 2018 at 10:36 AM, David Hendricks
wrote:
>
>
> On Thu, Mar 1, 2018 at 11:30 PM, Patrick Rudolph <
> patrick.rudo...@9elements.com> wrote:
>
>> Am Donnerstag, den 01.03.2018, 14:11 -0800 schrieb Julius Werner:
>> > Hi Patrick et. al.,
>> >
>&
I have access to the schematics for Speedy... I'm not allowed to share
them, but I'm happy to look up something specific for you if it helps.
Nico is right, only one of the four DP lanes coming out of the SoC is
routed to the connector. If your panel requires more than that, you're
probably SOL. A
> So looking at the specs for the display that comes with the ASUS
Chromebook C201 I can see the following PIN structure [1] is required on
the display end.
I'm confused... there's 30 pins there, but there should only be 20 on the
connector. I guess you got this from the panel datasheet directly?
>
> While this might be closer to the optimum for 60Hz, it would still try
> to pump data at around 136MHz. DP doesn't use a variable pixel clock on
> the physical layer. It's using either 1.62GHz (reduced bit-rate, RBR) or
> 2.7GHz (high bit-rate, HBR). Or (not supported by this code and likely
>
On Thu, Mar 1, 2018 at 6:38 AM, Peter Stuge wrote:
> Marshall Dawson wrote:
> >1. You can skip this step in your instructions. Instead, when running
> >make menuconfig, look in Chipset / ChromeOS and select "Build for
> >ChromeOS". This should cause Depthcharge to appear as a payloa
>
> It would be great to get some of the google developers to ack these, as
> this touches their code...
>From the coreboot point of view I guess we're fine with it since it claims
to maintain all of the existing functionality. It's just changing the
kernel-level plumbing for these drivers and I
[resend in plain text]
> It would be great to get some of the google developers to ack these, as
> this touches their code...
From the coreboot point of view I guess we're fine with it since it claims
to maintain all of the existing functionality. It's just changing the
kernel-level plumbing for
[repost to list with the right sender address]
> I just had the following CL fail in Jenkins:
> https://review.coreboot.org/c/coreboot/+/25393
>
> It fails for GOOGLE_CHELL but the one file it touches doesn't even get
> compiled for that board. I'm not quite sure that to make of the error but
> i
>
> And you seem to assume that CBFS is memory mapped which might not always
> be the case.
>
This is a very important part to keep in mind when we are talking UART.
There has been an attempt inside the Chrome OS team before to make the UART
runtime-configurable, and it fell flat on its face becau
I was trying to understand how to best implement the coreboot SPI API for a
new SoC, and as I was reading into it I got increasingly confused. This has
changed a bit last year (with the addition of struct spi_ctrlr), and I
don't think it was fully consistent before that across all implementations
e
> > My question is basically what happens when bytesout and bytesin are both
> > non-zero. My previous understanding was always that the SPI controller
> It's up to the spi controller itself. They should support full duplex,
> if possible.
And if not? The problem is that right now xfer() means tw
> How does it mean two different things? The pairing of a controller and
> device where a full duplex operation is needed but the controller
> doesn't support things should indeed fail. I do not undertand how
> xfer() means two different things. Whenever pairing hardware together
> one needs to val
> While you guys are at it, it might be worth folding spi_claim_bus()
> and spi_release_bus() into these changes so that CS is managed
> automatically for things like SPI flash transactions. Right now they
> return 0 for controllers that don't define ctrlr->claim_bus and
> ctrlr->release_bus, meani
> All the ARM64 boards I've seen that are desktop or higher class ship
> with AMI UEFI and AMI BMC. Plus they contain their own magic blobs,
> some akin to the ME. ARM64 is not a panacea either; OpenPOWER's
> actually shipping open POWER9 systems right now with source code. Why
> not go down tha
> >> Providers of blobs should sign them and take responsibility
> >> that the signed blobs were unaltered after compilation (e.g.
> >> do not contain malware). It is *recommended* that the public
> >> key needed to verify the signature is obtainable through a
> >> specific
> Yes, I agree and already did so when writing the above. That's why I
> made it a recommendation and not a requirement. I also intentionally
> didn't write "vendor". Just whoever provides the blob should sign it.
I still don't really get what signing in general is solving here. Digital
signatures
> You really seem to miss the point of free software.
Okay, now this is starting to get personal again, let's please not go
there. You too have been among those who spoke out against that in that
derailment thread recently. It's insulting to insinuate that some of us
don't understand or don't care
> Ok, I'll try to break this loop here. You are repeating the great bene-
> fits for a user (that I agree to) even if a blob is involved. And I keep
> asking why it should happen on our master branch (I don't see how we
> would take something away by not maintaining everything. Also, I never
> trie
Looks like I'm a little too late and outnumbered here, but I really don't
like this. It moves us away from kernel style unnecessarily, which both
makes importing code more cumbersome and adds cognitive load to the many of
us that regularly work on both coreboot and Linux. I also agree with the
vert
> build/romstage/drivers/spi/spi-generic.o: In function `spi_setup_slave':
/mnt/develop/bettong/coreboot/master/coreboot/src/drivers/spi/spi-generic.c:129:
undefined reference to `spi_ctrlr_bus_map'
/mnt/develop/bettong/coreboot/master/coreboot/src/drivers/spi/spi-generic.c:131:
undefined referen
I'm not an x86 guy so I don't really know the details here, but I think
this might just not work for non-Chrome OS builds yet. The error you get
suggests that the problem is about you not having an IFWI section in your
FMAP.
The FMAP describes the high-level layout of the ROM. Chrome OS has a bunc
> I try to read link scripts of coreboot.
> In addition to the x86 platform, code segments and data segments are
> contiguous during the bootblock/romstage phase.
There is no data segment for bootblock/romstage on x86. You are not
allowed to use global (or static local) variables. The build syste
> Any other idea?
Kconfig? Seems to be the simplest solution to me. Is this really
something that users would want to change at runtime? If you want to
have it you build it in, otherwise you don't... same with all other
optional features (e.g. timestamps, CBMEM console, stuff like that).
--
core
This is a complicated case most firmware USB stacks don't support (I
don't have experience with SeaBIOS, but I know that both U-Boot and
libpayload won't work with that either). A USB 3.0 hub is essentially
two completely separate logical hubs connecting to two completely
separate logical ports on
I think the idea behind this change was mostly that the old API was
too inflexible and some I2C device drivers could not be properly
written with it. Take a look at line 139 in this file from the first
patch: http://review.coreboot.org/#/c/7751/3/src/drivers/i2c/tpm/tpm.c@139
. What this really doe
I'd like to propose an API change/cleanup for a long-standing problem
with architecture-independent code that people have hit and privately
discussed/cursed multiple times already, but no one really had time to
make the big change/fix yet. (Some earlier discussion among Chromium
people about this i
> The x86 was recently fixed to take in void *. The order of arguments was
> discussed before, and the agreement is to use write*(addr, val);
> This has the advantage of being consistent with other accessor functions, such
> as PCI, and follows the logical C ordering of the assignment operator.
> d
>> As Patrick already said, compared to the total effort to integrate external
>> sources, the issue of argument order is insignificant. In the time you spent
>> writing this email, you could have found out how to do it with coccinelle,
>> and
>> could have applied it to any number of sources.
>
>
> I think nobody disagrees that type checking is a bad idea here.
I ain't not unsure that you failed to not make no mistake with the
missing lack of double negatives there... ;)
> I don't think this argument makes sense for code that is being actively
> developed in other code bases and imported
On Thu, Feb 19, 2015 at 12:21 AM, Werner Zeh wrote:
> OK, forget my last Mail...I was to blind to see the truth :-)
> We already have my approach with the new interface.
>
> We maybe can expand it to have informations like time-out or retry count for
> a given segment.
One word of caution I'd li
Okay, the doodle has been up for a while now and it seems that
write32(address, value) is preferred by a clear majority of people. I've
prepared a set of patches starting at
https://chromium-review.googlesource.com/#/c/254862 to enact that change in
the Chromium repo. As mentioned before, I think d
>
> In the past Ron also disagreed on changing headers by Samsung – taken
>> from U-Boot I think – saying their lawyers drafted those and therefore
>> it should stay that way.
>>
>
> That's right, you don't get to change other people's headers, especially
> when the headers are created by company l
> Section 1 of the GPLv2 contains: "keep intact all the notices that refer
to this License".
Yes, but that only applies to verbatim copies. Section 2 explicitly allows
you to distribute modified versions (and isn't incorporation into a larger
code body always a modification?) as long as the whole
Sounds like this could've been solved with a simple ALIGN(8) in the
ldscript, right? I don't know what made the compiler think that it
would have to align i386 pointers to 8 byte (which seems to be what
happened), but if it makes that decision then it should also conclude
that sizeof(struct boot_st
> You are right that it would work, but back solving for which alignment
> the compiler decided is hard. It's definitely whack-a-mole in that
> case. It could have very well decided 16 too. Without any insight as
> to why that breaks down. Or you go the route of putting alignments on
> structures j
All ChromiumOS firmware components and support tools are open source
(minus vendor blobs on certain platforms). The 'crossystem' and
'futility' (which contains 'gbb_utility' which is called by the
set_gbb_flags.sh script) tools are part of
https://chromium.googlesource.com/chromiumos/platform/vboot
> That said, I went back and looked at the assembly dump. It was using
> 0x14 as the size of the structure when sequencing through the entries.
>
> 001465dc R _bs_init_begin
> 001465e0 r cbmem_bscb
> 00146600 r gcov_bscb
> 0014663c R _bs_init_end
>
> Each *entry* was aligned to 0x20. Just aligning
> 145a8a: 83 c3 14add$0x14,%ebx
Okay, sorry, I didn't know you looked that closely into this. That's
quite unrefuteable.
The only question that I still have is then WTF the compiler was
thinking... this just sounds like a plain bug somewhere (but I agree
that doesn't r
> ** CID 1295489:(OVERRUN)
>
>
>
> *** CID 1295489:(OVERRUN)
> /src/mainboard/google/veyron_jerry/mainboard.c: 77 in configure_codec()
> 71 gpio_output(GPIO(2, B, 1), 1); /
> commit f780c40f (CBFS: Correct ROM_SIZE for ARM boards, use CBFS_SIZE
> for cbfstool) [1] adds a description to the Kconfig variable
> `CBFS_SIZE`, which makes it, I think, visible in the Kconfig menu (`make
> menuconfig`).
Sorry about that. The menuconfig for the Chromium tree I originally
wrot
> I'd also like the interface to be friendlier. What granularity is
> actually supported for the option? I doubt that it's single bytes?
>
> Maybe make it decimal kb? The default value depends on ROM_SIZE, right?
I would very much prefer it to stay byte sized. This makes the
Makefiles that use it
> It's trivial to add another variable between the user interface and
> Makefile rules to turn the friendly value into what's convenient for
> the code.
Yeah. But then again, we already agreed that this is a very rare-use
expert option. I don't think it's worth adding yet more lines to the
Kconfig
>> To my knowledge, upstreaming boards during the Haswell days wasn't a
>> priority, and was often done by non-Google devs (like me) who happened to
>> have a particular device. Within the last ~6 mos this has changed
>> significantly, and there's been a large push to keep the two in sync.
I don'
> Example full build logs are available here:
> ASUS KFSN4-DRe:
> https://www.raptorengineeringinc.com/coreboot/autotest/logs/1431127557-0-10158,2.log.bz2
>
> QEMU x86_64 Q35:
> https://www.raptorengineeringinc.com/coreboot/autotest/logs/1431127541-1-10158,2.log.bz2
>
> The builders are up to date
Hi Naman,
> Presently, arm64 isn’t a supported architecture for coreboot in emulation,
> mainly due to the fact that the port we have runs in 32-bit for bootblock and
> romstage stages. I would work to re-structure this and get these stages
> running in 64-bit.
Just wanted to make sure you kno
What commit of coreboot are you building? Your line numbers do not
match master (fde8109). In there phdr is assigned unconditionally just
two lines below the declaration, so there's really not much that could
fail. If this is an arch package, maybe it should just be updated to
use a newer version o
Hi Naman,
Just some pointers to make sure we don't try to pull in different directions:
> Next up, was another hitch. During the build, ‘mmu_enable()’ and
> ‘arch_secondary_cpu_init()’ function calls are happening for all stages but
> the definitions for these functions are getting compiled only
Is there no way to make RISCV support unaligned accesses? There's a
bunch of things in coreboot (and especially libpayload) that depend on
it. I think that it generally makes code look much simpler (and run
faster) if you can assume that it's supported across the board.
If we do need to make CBFS
On Fri, Jul 17, 2015 at 3:13 PM, ron minnich wrote:
> we're going to support unaligned accesses, they make it easy. I think it's
> silly that have data structs that are not 64-bit aligned, however :-)
Of course. Unfortunately they're usually embedded in age-old
specifications that are extremely h
-mno-unaligned-access is ARM32 only, unfortunately. You'd have to
convince GCC developers to generalize it.
> This statement is true for coreboot tables. CBFS files are aligned to 64
> bytes by default.
The problem is that the CBFS stage and payload headers themselves
contain inherently misalign
I think this was http://review.coreboot.org/#/c/10212. It should've
changed the filenames in cbfstool/Makefile in the same manner as
cbfstool/Makefile.inc. Should be pretty simple to fix. (I don't think
many people build cbfstool standalone, and apparently neither does
Jenkins... so this is easy to
Hi Naman,
> This finally gave some leads in the qemu debug. There seems be some
> misalignment in smp_processor_id.
> While tracing in gdb, we have
> 0x0908 in ?? ()
> => 0x0908: 06 fe ff 97 bl 0x120
> (which is actually bl smp_processor_id (from src/arch/arm64/stage_ent
+Dave for visibility, was a simple oversight in the refactoring
On Fri, Sep 4, 2015 at 5:12 AM, Iru Cai wrote:
> Hi,
>
> I was trying to build coreboot with the latest git code and build failed
> when CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT is set. Some of the error message
> is:
>
> $ make
> CR
I'd bet it's just a single large allocation somewhere. You can try adding
CFLAGS_ramstage += -Wstack-usage=1024
somewhere in coreboot/Makefile.inc and then clean+rebuild your code while
passing '-k' to make. You'll get a bunch of compiler warnings, and one of
them is likely to be the culprit.
--
Hi,
I recently landed a coding style change to define some rules about how
#include directives should be written and when it's okay to
"chain-include" a header, because this has been a frequent topic of
discussion and cleanup patches in the past year(s) and people seemed
to keep having different o
I'm just curious... have we ever considered booting some of our QEMU
targets as part of the Jenkins CI? I know they don't do a lot but they
do cover some stuff (e.g. CBFS). I randomly happened to boot one of my
in-flight patch trains on qemu-i440fx recently and discovered that I
accidentally broke
>
> https://qa.coreboot.org/job/coreboot-boot-test/ sends off ToT builds to
> 9esec's Lava system where they are run on some virtual and real devices.
> See for example the comments to
> https://review.coreboot.org/c/coreboot/+/51189 where Lava reports passing
> on 5 qemu configs and 3 real devices
> > https://review.coreboot.org/c/coreboot/+/51825 proposes getting rid of the
> > rule to make if-statement blocks (and the like) as short as possible.
> > The rationale is to encourage a style that avoids subtle bugs which then
> > need to be found by tooling such as Coverity Scan and fixed by
> Any objections to moving the code out there that has no other upstream (e.g.
> src/vendorcode/google/chromeos or src/vendorcode/eltan, I think?) while
> moving in code from elsewhere in the tree that fits the "it has a foreign
> upstream" description (e.g. the lzma library)?
Sorry, I just res
>> I think we still need to have a difference between hacky vendor stuff
>> and normal coreboot code. For example, the Eltan mboot stuff is
>> something we didn't really want to have in coreboot in that form, and
>> so they kinda put it in vendorcode as a compromise. We should make
>> sure it remai
> The issue is that Tianocore fails to execute (hangs the system) when
> used as a legacy boot/alternative bootloader entry on 90% of CrOS
> devices which support the alternative bootloader feature, and since
> coreboot disables console output via the CPU UART, I don't have a good
> way to debug th
Sorry for being a bit late here, but I wanted to second what Nico
said. It's important to not add undue burden to the development
process. I think the master branch is meant for development, not for
shipping long-term stable products. If you're installing coreboot in a
train or medical device, then
> > As an
> > open source project, coreboot doesn't have anywhere near the resources
> > to do enough QA to guarantee that the tip of the master branch (or any
> > branch or tag, for that matter) was stable enough to be shipped in a
> > product at any point in time... even Linux cannot do that, and
> > Rebasing for security seems odd. Usually one has to re-evaluate security
> > completely after a rebase. In my experience, security features randomly
> > break upstream like everything else. There is no stability guarantee.
>
> Maybe it is odd, but backporting Intel Boot Guard or vboot to old br
Hi Patrick, Martin,
The coreboot.org mirror of the arm-trusted-firmware repo
(https://review.coreboot.org/admin/repos/arm-trusted-firmware) seems
to be half a year out of date. According to the description (although
that may be out of date) it's still syncing from the old GitHub
location (https://
Hi Patrick, Martin,
I just noticed that we seem to have dropped support for cgit on the
coreboot Gerrit. I don't exactly remember how it worked, but I seem to
have been able to get a link like
https://review.coreboot.org/cgit/qc_blobs.git/plain/sc7180/qtiseclib/libqtisec.a
some time last year. Now
> why can't you use the gerrit 'download' button to either cherry pick the
> patch or pull the stack?
I want to download the raw file, not the Git patch. I want to be able
to tell someone who needs this blob "just click this link to download
it". Right now I have to say "click this link to downlo
> Hi Julius,
> Appending "?format=TEXT" to the file link in Gitiles (the "txt" link at the
> bottom of the page) will give a base64-encoded copy of the file.
Yeah, I wish they just had a ?format=raw instead, I don't get why they
don't implement the most obvious option. Seems like they're not real
> but as an immediate workaround, all our repos are mirrored ~hourly to
> github.com/coreboot, too (and therefore are available through
> raw.githubusercontent.com)
Oh, perfect! At least for my purposes that's good enough. Thanks!
___
coreboot mailing
Pulling out some of the discussions that we already had inside Google
to this wider audience, I am strongly against parallelization
mechanisms that pull this much extra complexity into existing code
(particularly the already very complicated CBFS framework). I think
https://review.coreboot.org/c/co
know what you think.
>
> Thanks!
>
> On Wed, Jul 7, 2021 at 7:24 PM Julius Werner wrote:
> >
> > Pulling out some of the discussions that we already had inside Google
> > to this wider audience, I am strongly against parallelization
> > mechanisms that pull this mu
> Since it doesn't seem possible to have each boot component using the same log
> format, we added a log_format and log_phys_addr fields to give flexibility in
> how logs are stored. An example of a different log format that can be used is
> the cbmem_console log format used by coreboot:
I am not
> After some more community discussion about what's going on here, a proposal:
Can you link to that discussion? I feel like I'm missing most of
what's going on here.
In general, I can second what Patrick and Nico said: the notion of
running coreboot "after" BL2 doesn't make any sense, because cor
> If I remember correctly, coreboot’s goal to only do minimal hardware
> initialization originally meant, that the payload/OS does PCI
> initialization.
FWIW, coreboot does do device initialization for things that are only
needed by the payload in other cases too: we've been doing display and
USB
> But, currently, selecting Google Asurada in Kconfig (`make menuconfig`),
> display initialization cannot be disabled, and I do not see a way to
> disable USB init either.
That's a fair point, I think that's just not implemented because
nobody needed it yet. Display init is already globally guard
The libpayload CBFS stack ("libcbfs") has recently been rewritten from
scratch in order to eliminate a bunch of very old warts and better
match the new CBFS API in coreboot
(https://review.coreboot.org/59497). For the time being, the old
libcbfs code remains side-by-side to the new one so that the
Hi,
We occasionally get into discussions in code reviews when code uses a
GCC extension, and a reviewer asks that it be rewritten to be C
standard compliant instead. A recent example was on the use of `void
*` arithmetic in this patch
https://review.coreboot.org/c/coreboot/+/56791/9/src/soc/mediat
1 - 100 of 237 matches
Mail list logo
