[coreboot] Re: failure cherry-picking patches from https://review.coreboot.org/coreboot

- > From: Peter Stuge > Sent: Thursday, May 20, 2021 10:57 AM > To: coreboot@coreboot.org > Subject: [coreboot] Re: failure cherry-picking patches from > https://review.coreboot.org/coreboot > > Aaron Durbin via coreboot wrote: > > > We are observing since 3 days in

[coreboot] Re: failure cherry-picking patches from https://review.coreboot.org/coreboot

On Wed, May 19, 2021 at 6:25 PM Bensaid, Selma wrote: > Hi, > > We are observing since 3 days instabilities while cherry-picking patches > from coreboot.org: > > git fetch https://review.coreboot.org/coreboot refs/changes/40/52140/3 && > git cherry-pick FETCH_HEAD > > fatal: The remote end hung

[coreboot] Re: [RFC] Replace strapping entries in coreboot table

On Thu, Oct 22, 2020 at 4:01 PM Tim Wawrzynczak via coreboot < coreboot@coreboot.org> wrote: > > > On Thu, Oct 22, 2020 at 2:01 PM Nico Huber wrote: > >> 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

[coreboot] Re: [RFC] Replace strapping entries in coreboot table

On Wed, Oct 21, 2020 at 2:37 PM Tim Wawrzynczak wrote: > On Wed, Oct 21, 2020 at 1:50 PM Aaron Durbin wrote: > >> >> >> On Wed, Oct 21, 2020 at 1:20 PM Tim Wawrzynczak via coreboot < >> coreboot@coreboot.org> wrote: >> >>> Hi coreboot

[coreboot] Re: [RFC] Replace strapping entries in coreboot table

On Wed, Oct 21, 2020 at 1:20 PM Tim Wawrzynczak via coreboot < coreboot@coreboot.org> wrote: > Hi coreboot community, > > Currently there are 3 different "strapping" entries in the coreboot > tables, and with the recent addition of fw_config ( > https://review.coreboot.org/c/coreboot/+/41209), we

[coreboot] Re: Resource allocator: Getting v4 back in

On Fri, May 22, 2020 at 10:01 AM Nico Huber wrote: > 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

[coreboot] Re: Resource allocator: multiple boards regression

On Thu, May 14, 2020 at 3:46 PM Aaron Durbin wrote: > > > On Thu, May 14, 2020 at 2:46 PM Mike Banon wrote: > >> Unfortunately it seems a lot of boards are affected by this. A88XM-E >> and Lenovo G505S (AMD fam15h) also got broken: they rarely succeed at >> bootin

[coreboot] Re: Resource allocator: multiple boards regression

SUCCESS : > https://lava.9esec.io/r/3424 Ya. Those are fixed from the patches that fixed your device, Keith. > > > Thanks > Keith > > On Thu, May 14, 2020 at 5:47 PM Aaron Durbin wrote: > > > > > > > > On Thu, May 14, 2020 at 2:46 PM Mike Banon wrote

[coreboot] Re: Resource allocator: multiple boards regression

> Turns out I have to back out all four of Furquan's patches > > (CB:39486~39489) for my board to boot normally again. > > > > Thoughts? > > > > I'll now get a log with everything in at SPEW. > > > > > > On Thu, May 14, 2020 at 1:05 PM Aaron Durbin wrot

[coreboot] Re: Change in coreboot[master]: nb/intel/i440bx: add resources during read_resources()

gt; Thanks > Keith > > On Thu, May 14, 2020 at 4:01 PM Aaron Durbin wrote: > > > > Hi Keith, > > > > Did the newresalloc.log file contain this patch? > https://review.coreboot.org/c/coreboot/+/41363 > > > > I ask because I see the fixed resources on the d

[coreboot] Re: Change in coreboot[master]: nb/intel/i440bx: add resources during read_resources()

Hi Keith, Did the newresalloc.log file contain this patch? https://review.coreboot.org/c/coreboot/+/41363 I ask because I see the fixed resources on the domain that are dram: DOMAIN: resource base 0 size a align 0 gran 0 limit 0 flags e0004200 index a DOMAIN: resource base

[coreboot] Re: i440BX regression; P3B-F flashrom board enable is finally happening

rote: > > > > Similar fix for i440x: https://review.coreboot.org/c/coreboot/+/41368 > > > > On Wed, May 13, 2020 at 11:29 AM Aaron Durbin > wrote: > > > > > > i440x chipset is doing things in the wrong way like sandybridge. I > uploaded this fix for

[coreboot] Re: i440BX regression; P3B-F flashrom board enable is finally happening

i440x chipset is doing things in the wrong way like sandybridge. I uploaded this fix for sandy: https://review.coreboot.org/c/coreboot/+/41364 We'll need to do the equivalent for i440x. On Wed, May 13, 2020 at 11:13 AM Aaron Durbin wrote: > OK. I'll take a look at your logs and see what's go

[coreboot] Re: i440BX regression; P3B-F flashrom board enable is finally happening

entry ending at 03ff, which I think have > more to do than the 41363's scope. > > Keith > > On Wed, May 13, 2020 at 12:24 PM Aaron Durbin wrote: > > > > I think the following patch will fix things up: > https://review.coreboot.org/c/coreboot/+/41363 Please

[coreboot] Re: i440BX regression; P3B-F flashrom board enable is finally happening

I think the following patch will fix things up: https://review.coreboot.org/c/coreboot/+/41363 Please let me know. On Wed, May 13, 2020 at 8:43 AM Keith Hui wrote: > Thanks Furquan. > > Here are 3 logs. Log 1 is at the commit just before the problem. Log 2 > is at the problem commit. Log 3 is

[coreboot] Re: What does mirror_payload() do and do we still need it?

On Fri, Mar 6, 2020 at 6:52 PM Julius Werner wrote: > [resend with right account] > > On Fri, Mar 6, 2020 at 5:50 PM Julius Werner wrote: > > > > Hi, > > > > I'm trying to refactor some CBFS code (which necessarily leaks into > > the prog_loaders) and > >

[coreboot] Re: [RFC] Using relocatable module program parameters to pass cbmem_top() on X86

On Sat, Oct 19, 2019 at 9:42 AM Arthur Heymans wrote: > Hi > > Currently all stages that need cbmem need an implementation of a > cbmem_top function. On platforms with fully open source coreboot code it > is generally not a problem to link in all stages the code reading the > hardware registers

[coreboot] Re: Adding System76 to End Users webpage

On Thu, Oct 10, 2019 at 11:13 AM Matt DeVillier wrote: > just checkout and push changes to the 'homepage' project > FWIW: https://review.coreboot.org/admin/repos/homepage > > On Thu, Oct 10, 2019 at 12:05 PM Jeremy Soller > wrote: > >> Hello, >> >> Now that System76 is providing products with

[coreboot] Re: PCIe Hotplug for Thunderbolt and U.2

Engineering Manager > jer...@system76.com > > > > On Wed, Oct 9, 2019, at 1:29 PM, Aaron Durbin wrote: > > Please include intel and google on your patches because we'll be needing > this support in the near future as well. The allocator limitations are > known, and Kyos

[coreboot] Re: PCIe Hotplug for Thunderbolt and U.2

Please include intel and google on your patches because we'll be needing this support in the near future as well. The allocator limitations are known, and Kyosti and I have talked about improving things here. As for the children comment you need to reserve a sufficiently large mmio space and in

[coreboot] Re: [PATCH] x86_64 support needs testing

ame thing. Minimum 4KiB stack granularity is necessary as well as ensuring physical and virtual address spaces are split up to allow guard pages. Currently everything is assumed 1:1. > > On Tue, Oct 1, 2019 at 10:27 AM Aaron Durbin wrote: > >> >> >> On Tue, Oct 1

[coreboot] Re: [PATCH] x86_64 support needs testing

On Tue, Oct 1, 2019 at 9:42 AM Raul Rangel wrote: > That's exciting. That means we can finally catch stack overflows in SMM. > Because of paging? > > On Sun, Sep 29, 2019 at 5:42 AM Patrick Rudolph > wrote: > >> Dear coreboot community, >> Please test and review the patch series [1]. >> >> It

[coreboot] Re: Fixing Hidden PCI devices on Intel common SoCs

On Fri, Sep 27, 2019 at 10:42 AM Nico Huber wrote: > On 27.09.19 15:42, Kyösti Mälkki wrote: > > On Thu, Sep 26, 2019 at 7:45 PM Aaron Durbin wrote: > >> > >> On Thu, Sep 26, 2019 at 10:06 AM Kyösti Mälkki > wrote: > >>> Should be easy enoug

[coreboot] Re: Fixing Hidden PCI devices on Intel common SoCs

On Fri, Sep 27, 2019 at 11:11 AM Nico Huber wrote: > On 26.09.19 18:45, Aaron Durbin via coreboot wrote: > > Here's some of the requirements/issues we should resolve that come to > mind: > > > > 1. Easy way to directly retrieve a device's chip config object w/o &

[coreboot] Re: Fixing Hidden PCI devices on Intel common SoCs

On Thu, Sep 26, 2019 at 10:06 AM Kyösti Mälkki wrote: > In a nutshell: > > The implementation of dev_find_slot() traverses the linked list of all > devices in the devicetree, regardless of the topology. Since PCI bus > numbers are only assigned in early ramstage, this function is not a >

[coreboot] Re: Fixing Hidden PCI devices on Intel common SoCs

On Thu, Sep 26, 2019 at 8:51 AM Kyösti Mälkki wrote: > Hi Matt, > > thanks for bringing the topic up. Please also contact your Intel reps > about this via commercial support channel as well. I believe Patrick > G. once stated that he could act as a relay when it comes to disputes > between

[coreboot] Re: [coreboot-gerrit] Change in ...coreboot[master]: usbdebug: Fix reserve in CAR

On Thu, Jan 31, 2019 at 11:13 AM Kyösti Mälkki (Code Review) < ger...@coreboot.org> wrote: > Aaron, Julius; there is a bit of dilemma with car.ld. > > 1) We need consistent layout across PRE_RAM stages > 2) We want RO bootblock, unaware of (future) RW romstage requirements > 3) I don't like the

[coreboot] Re: Fallback mechanisms on x86 with C_ENVIRONMENT_BOOTBLOCK

On Thu, Jan 24, 2019 at 6:24 PM Julius Werner wrote: > > What does that practically look like? Every time we have to re-walk we > have to reverify the integrity of the metadata. > > I mean, that is exactly what we're doing right now anyway (unless > something significantly changed in CBFS code

[coreboot] Re: Fallback mechanisms on x86 with C_ENVIRONMENT_BOOTBLOCK

; > -Ursprüngliche Nachricht- > > Von: Julius Werner [mailto:jwer...@chromium.org] > > Gesendet: Donnerstag, 24. Januar 2019 00:01 > > An: Aaron Durbin > > Cc: Julius Werner; Arthur Heymans; Coreboot > > Betreff: [coreboot] Re: Fallback mechanisms on x86 with >

[coreboot] Re: Fallback mechanisms on x86 with C_ENVIRONMENT_BOOTBLOCK

On Wed, Jan 23, 2019 at 4:00 PM Julius Werner wrote: > > For 1, this is attempting to protect physical attack. Obviously this > particular problem can't be solved in isolation, but it's something to > think about. > > But isn't this something that per-file hashing would probably make > easier to

[coreboot] Re: Fallback mechanisms on x86 with C_ENVIRONMENT_BOOTBLOCK

On Tue, Jan 22, 2019 at 6:21 PM Julius Werner wrote: > > FWIW, it's my opinion I think we'll need to start splitting cbfs into > smaller ones. This isn't specific to this situation, but splitting slots > into multiple cbfses (rw-a-1, rw-a-2, etc) allows one to chain/group > resources as they

[coreboot] Re: Fallback mechanisms on x86 with C_ENVIRONMENT_BOOTBLOCK

On Tue, Jan 22, 2019 at 6:45 AM Arthur Heymans wrote: > Hi > > As more and more x86 platforms are moving to C_ENVIRONMENT_BOOTBLOCK > and therefore don't use a romcc compiled bootblock anymore a certain > question arises. With the romcc bootblock there was a normal/fallback > mechanism. > > It

Re: [coreboot] Coreboot hangs during SYS_RESET

On Wed, Nov 7, 2018 at 6:47 AM Antony AbeePrakash X V wrote: > > Hi, > > > > We are developing coreboot (with Intel FSP) for apollo lake platform custom > board. We are facing a hang issue during the SYS_RESET button press. > > > > Observations: > > With soft reset the board gets hang(occurs

Re: [coreboot] MRC in coreboot

ESERVED How old of a cbmem utility are you using? don't understand where the 1MiB mappings are coming from. > > > > Thanks, > > Antony > > > > From: Aaron Durbin [mailto:adur...@google.com] > Sent: Friday, October 12, 2018 7:12 PM > To: Antony AbeePraka

Re: [coreboot] MRC in coreboot

would fix that particular problem. Note, with that current error, that you should see a PAT error in dmesg. > > Thanks & Regards, > > Antony > > *From:* Aaron Durbin [mailto:adur...@google.com] > *Sent:* Thursday, October 11, 2018 9:44 PM > *To:* Antony AbeePrakas

Re: [coreboot] MRC in coreboot

com> wrote: > Hi Aaron, > > PFA the console log for your reference. > > Please look into this and provide feedback. > > Thanks, > Antony > > -Original Message- > From: Aaron Durbin [mailto:adur...@google.com] > Sent: Thursday, October 11, 2018 7:27 PM &g

Re: [coreboot] MRC in coreboot

codes. We would like to reduce the boot time to > less than 2sec. > > Could anyone please tell what can be done further ? You're going to need to post more information (cbmem timings and console logs). > > Thanks, > Antony > > -----Original Message- > From: Aaron Durb

Re: [coreboot] Loading Linux payloads on RISC-V

On Sun, Sep 23, 2018 at 9:00 AM ron minnich wrote: > > ah sorry I forgot. > > I think selfboot could be reworked (and should be) to interpret "0" as > "somewhere useful"? Why is the kernel being loaded at 0? > > On Sat, Sep 22, 2018 at 10:47 PM ron minnich wrote: >> >> shouldn't we fix the

Re: [coreboot] MRC in coreboot

On Wed, Sep 5, 2018 at 8:06 AM Antony AbeePrakash X V wrote: > > Hi, > > > > We are developing coreboot for Apollo lake custom board. MRC training data > save is enabled in FSP using Binary configuration tool. > > > > But we are getting logs like, > > > > No MRC cache found. > > MRC SeCUmaSize

Re: [coreboot] Whether coreboot has restrictions on the bootblock program, cannot use static variables with initial values.

On Wed, Jul 11, 2018 at 1:16 AM 王翔 wrote: > I am try to read the code that cache-as-ram of bootblock stage. And found > that just cleared the memory and did not initialize the data segment code. > > So, I want to ask : "Whether coreboot has restrictions on the bootblock > program, cannot use

Re: [coreboot] FSP 2.0 headers in coreboot

On Tue, May 22, 2018 at 2:25 PM, Youness Alaoui wrote: > On Fri, May 18, 2018 at 2:59 PM, Nico Huber wrote: >> >> I have to admit, I don't like your patch. While it gets the job done, >> it brings `MemInfoHob.h` and `FspsUpd.h` out of sync, so the

Re: [coreboot] FSP 2.0 headers in coreboot

On Thu, May 10, 2018 at 5:10 PM, Nico Huber wrote: > 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

Re: [coreboot] PC Engines apu2 boot regression

On Sat, May 5, 2018 at 4:26 PM, Kyösti Mälkki <kyosti.mal...@gmail.com> wrote: > On Sun, May 6, 2018 at 12:17 AM, Aaron Durbin <adur...@google.com> wrote: >>> I find it particularly hard to be civil on your first question, so >>> trying with sarcasm instead. A

Re: [coreboot] FSP 2.0 headers in coreboot

On Sat, May 5, 2018 at 5:36 AM, Nico Huber <nic...@gmx.de> wrote: > On 04.05.2018 23:41, Aaron Durbin via coreboot wrote: >> On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui >> <kakar...@kakaroto.homelinux.net> wrote: >>> Hi, >>> >>> I'v

Re: [coreboot] PC Engines apu2 boot regression

On Fri, May 4, 2018 at 8:49 PM, Kyösti Mälkki <kyosti.mal...@gmail.com> wrote: > On Fri, May 4, 2018 at 8:22 PM, Aaron Durbin <adur...@google.com> wrote: >> On Fri, May 4, 2018 at 11:16 AM, Kyösti Mälkki <kyosti.mal...@gmail.com> >> wrote: >>> On

Re: [coreboot] FSP 2.0 headers in coreboot

On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui wrote: > Hi, > > I've just pushed a commit for review on gerrit > (https://review.coreboot.org/#/c/coreboot/+/26108/) and I'm hoping to > open the discussion here on whether the public coreboot code should > have the

Re: [coreboot] PC Engines apu2 boot regression

On Fri, May 4, 2018 at 11:16 AM, Kyösti Mälkki <kyosti.mal...@gmail.com> wrote: > On Fri, May 4, 2018 at 7:19 PM, Kyösti Mälkki <kyosti.mal...@gmail.com> wrote: >> On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin <adur...@google.com> wrote: >>>> >>>>

Re: [coreboot] DDR1 K8 boot broken too (was: Re: PC Engines apu2 boot regression)

On Fri, May 4, 2018 at 10:01 AM, Jonathan A. Kollasch wrote: > On Fri, May 04, 2018 at 05:23:40PM +0200, Piotr Król wrote: >> Hi Aaron, >> I tried to boot PC Engines apu2 on recent master branch and discovered >> that it not boot. Bisection points to: >> >> 60320182d011

Re: [coreboot] PC Engines apu2 boot regression

On Fri, May 4, 2018 at 9:23 AM, Piotr Król wrote: > Hi Aaron, > I tried to boot PC Engines apu2 on recent master branch and discovered > that it not boot. Bisection points to: > > 60320182d011 console: only allow console messages after initialization > > It is hard to

Re: [coreboot] Why do we have FSP-S

On Mon, Apr 30, 2018 at 9:46 PM, taii...@gmx.com wrote: > Like I have said I believe the gradual encroachment of blobs and corporate > control will end up leaving coreboot dead in the water and eventually even Can you articulate what 'corporate control' is impacting coreboot?

Re: [coreboot] Why do we have FSP-S

On Sat, Apr 28, 2018 at 7:16 AM, Nico Huber wrote: > Hello coreboot folks, hello Intel and Google coreboot developers, > > back on Tuesday, some of us discovered a commit on gerrit [1] that > implements (another) foreign interface inside coreboot. Discussing It's more of a bridge

Re: [coreboot] How is our SPI API supposed to work?

On Thu, Apr 19, 2018 at 4:51 PM, Julius Werner wrote: >> 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()

Re: [coreboot] How is our SPI API supposed to work?

On Thu, Apr 19, 2018 at 4:06 PM, Julius Werner wrote: >> > 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

Re: [coreboot] How is our SPI API supposed to work?

On Wed, Apr 18, 2018 at 8:46 PM, Julius Werner wrote: > 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

Re: [coreboot] Problem with tianocore compilation in coreboot-sdk:1.50

On Wed, Apr 4, 2018 at 8:40 AM, Piotr Król <piotr.k...@3mdeb.com> wrote: > > > On 04/04/2018 05:31 PM, Aaron Durbin wrote: >> On Wed, Apr 4, 2018 at 4:55 AM, Piotr Król <piotr.k...@3mdeb.com> wrote: >>> Hi all, >>> I can't compile tianocore pay

Re: [coreboot] Problem with tianocore compilation in coreboot-sdk:1.50

On Wed, Apr 4, 2018 at 4:55 AM, Piotr Król wrote: > Hi all, > I can't compile tianocore payload using coreboot-sdk:1.50 and coreboot 4.7. > > VfrUtilityLib.cpp: In member function 'CHAR8* > CVfrStringDB::GetVarStoreNameFormStringId(EFI_STRING_ID)': > >

Re: [coreboot] VbTryLoadKernel restriction on 512 byte sector size

On Tue, Apr 3, 2018 at 10:26 AM, wrote: > Folks, > Can anyone on this list expound on why VbTryLoadKernel() performs a > sanity-check on bytes_per_lba != 512? >--->---/* >--->--- * Sanity-check what we can. FWIW, VbTryLoadKernel() is always

Re: [coreboot] Out of MTRRs

On Sat, Mar 31, 2018 at 10:21 AM, Nico Huber wrote: > On 31.03.2018 17:31, Nico Huber wrote: >> >> On 23.03.2018 16:29, Jay Talbott wrote: >>> >>> Do you think they will resolve the issue that I am seeing? >> >> >> I don't know. As you top posted, I haven't looked at it yet. I'll

Re: [coreboot] Assigning PCI resources clobbers console with io-mapped / memory-mapped UART

On Thu, Mar 29, 2018 at 3:36 PM, Jay Talbott wrote: > We ran into an issue where we were not getting a full coreboot log on > Denverton with the Harcuvar CRB, where it just abruptly stops the serial > console output during the assignment of the PCI resources. > >

Re: [coreboot] Out of MTRRs

On Mon, Mar 19, 2018 at 10:55 AM, Jay Talbott wrote: > See below… > - Jay > [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=79fff000 End=7a00 (Size 1000) [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7a00 End=7a80 (Size 80) [Mon Mar 19

Re: [coreboot] only 8GB RAM on ThinkPad X230 after commit 7539b8c3

Could you please post the logs? On Sun, Mar 18, 2018 at 4:42 PM, Marek Behun wrote: > Hello, > > with the commit 7539b8c3 "nb/intel/sandybridge: Use common mrc cache > functions" I only have accessible 8 GB of ram on ThinkPad X230, > although I have two 8 GB modules. On the

Re: [coreboot] Out of MTRRs

Please post the full logs so we can see the address space. The 'Unable to insert temporary MTRR range' log message is only for tempoarility mapping the SPI flash. However, it's impossible to debug w/o the full logs to see what your address space looks like. On Sat, Mar 17, 2018 at 12:28 PM, Jay

Re: [coreboot] Intel soc ACPI generation using soc/intel/common/block/acpi

On Thu, Feb 8, 2018 at 8:54 AM, Julien Viard de Galbert <jviarddegalb...@online.net> wrote: > > > Le 8 févr. 2018 à 17:24, Aaron Durbin <adur...@google.com> a écrit : > > On Thu, Feb 8, 2018 at 7:20 AM, Julien Viard de Galbert > <jviarddegalb...@online.net> w

Re: [coreboot] Intel soc ACPI generation using soc/intel/common/block/acpi

On Thu, Feb 8, 2018 at 7:20 AM, Julien Viard de Galbert wrote: > Hello all, > > First sorry for mailing direclty those of you who are on the coreboot > mailing list. > > I’m currently in the process of upstreaming the changes we have on > denverton. > On the ACPI I see

Re: [coreboot] 16 GPUs on one board

On Sun, Jan 7, 2018 at 2:05 PM, Adam Talbot wrote: > Lets take a slight differently tactic. What would happen if we removed the > ROM from a GPU/NIC? Would the GPU's still require 256MB~304MB of PCI_MMIO? > Yes, I would expect it to. Those cards have on-board memory that

Re: [coreboot] 16 GPUs on one board

On Thu, Jan 4, 2018 at 1:33 PM, Arthur Heymans wrote: > Hi > > What target are you on? > > Coreboot tries to locate all PCI BAR's below 4G in the PCI_MMIO region and > above the lower DRAM > limit (the rest of the DRAM is mapped above 4G). Typically a GPU takes > around 256M

Re: [coreboot] Depthcharge License

happy to > add once I'm able to start contributing to the project. > Cheers, > T.mike > > On Tue, Dec 19, 2017 at 9:19 AM, ron minnich <rminn...@gmail.com> >> wrote: >> >> Is there even a question? Looks like aaron just answered the >>> original qu

Re: [coreboot] Depthcharge License

On Tue, Dec 19, 2017 at 8:03 AM, wrote: > On 2017-12-15 13:39, ttu...@codeaurora.org wrote: > >> Preparing to mirror the coreboot.org requires us to vet the various >> licenses, etc. >> >> There doesn't appear to be a LICENSE or COPYING file in the Depthcharge >> tree. >>

Re: [coreboot] SMM save area in MSRs on newer intel CPUs

haswell and on has this. You can see it in the haswell code. We actually opted not to use it but for relocation so we could look at each cpu's save state from a single cpu to see who caused the smi, etc. On Sat, Oct 7, 2017 at 8:38 AM, ron minnich wrote: > can someone point

Re: [coreboot] How is depreciating 95% of coreboot boards worth it for such minor improvements?

On Wed, Aug 23, 2017 at 8:31 PM, Kyösti Mälkki wrote: > On Thu, Aug 24, 2017 at 12:29 AM, taii...@gmx.com wrote: >> Ah I see thanks for explaining. >> >> I had read all the AGESA boards were going to be removed, besides the asus >> D8/D16 those are the

Re: [coreboot] How is depreciating 95% of coreboot boards worth it for such minor improvements?

On Wed, Aug 23, 2017 at 2:06 PM, Felipe Sanches wrote: > Is there an index of which was the latest git commit for each removed board > ? > That would help anyone interested in working on them in the future. It is > not strictly necessary, but would certainly make life

Re: [coreboot] About Paging, Realmode and what is going on

On Wed, Aug 2, 2017 at 1:36 PM, ron minnich wrote: > > > On Wed, Aug 2, 2017 at 12:08 PM Zoran Stojsavljevic > wrote: >> >> >> >> So, turning on the Virtual Mode (paging ON), you'll also imply that >> Coreboot will initialize and use MMU, don't

Re: [coreboot] What does *intelblocks* mean?

On Mon, Jun 5, 2017 at 2:48 AM, Paul Menzel wrote: > Dear coreboot folks, > > > In commit a554b0c5b7 (soc/intel/common/block: Add Intel XHCI driver > support) [1] the directory > `src/soc/intel/common/block/include/intelblocks` is created. > > Could somebody

Re: [coreboot] Will we maintain Skylake/FSP1.1?

On Tue, May 9, 2017 at 10:14 AM, Nico Huber wrote: > Hi, > > I was walking through the Skylake FSP1.1 support in coreboot and asked > myself if it is worth to clean it up and maintain the code? given that > the upcoming release of Kabylake FSP should be able to supersede

Re: [coreboot] Intel PCH: When is the code for SPI flash reading used?

On Thu, May 4, 2017 at 4:16 PM, Marek Behun wrote: > Hello, > > is the code for SPI flash reading (from src/drivers/spi/spi_flash.c) > used at all? From what I understood when reading Intel PCH datasheets, > the SPI controller alone reads the whole BIOS. Is this wrong? Does

Re: [coreboot] Why does src/soc/intel/ exist?

On Tue, May 2, 2017 at 5:24 AM, Arthur Heymans wrote: > Hi > > I am wondering why newer intel code is being pushed to src/soc/intel/*/ > instead of the traditional src/{cpu,southbridge,northbridge}/intel ? The era of mix and match ICs is pretty much gone. Even when there are

Re: [coreboot] SPI Flash does not work on Intel LeafHill CRB

On Thu, Mar 30, 2017 at 4:53 AM, Goetz Salzmann wrote: > Dear Toan, > >> I tried as your suggestion: flashed an 8 MB Intel-provided image, read >> back from SPI chip right after flashing, got a 16 MB file (since SPI >> chip is 16 MB size). >> The first 8 MB of 2 files are

Re: [coreboot] Group demographics

On Tue, Mar 28, 2017 at 3:20 PM, wrote: > On 2017-03-24 17:42, Julius Werner wrote: >>> >>> * Google's recovery manifest (from linux_recovery.sh) can pull a >>> recovery image for a specific product, I have yet to find >>> depthcharge as a payload >>> * Obviously I haven't

Re: [coreboot] [coreboot-gerrit] Change in coreboot[master]: KBL: Update FSP headers - upgrade to FSP.2.0.0

Why can't I access this CL on gerrit, but I'm getting emails for it? On Tue, Mar 28, 2017 at 10:10 AM, Subrata Banik (Code Review) wrote: > Subrata Banik has posted comments on this change. ( > https://review.coreboot.org/19023 ) > > Change subject: KBL: Update FSP headers

Re: [coreboot] Group demographics

On Fri, Mar 24, 2017 at 10:39 AM, wrote: > On 2017-03-24 08:23, ron minnich wrote: >> >> On Fri, Mar 24, 2017 at 8:14 AM wrote: >> >>> Q.1) Are questions related to Coreboot + Payload that boots a >>> Chromebook >>> appropriate for this list or a

Re: [coreboot] Intel Leafhill/Apollolake wrong CBFS header address in coreboot.rom

On Sun, Mar 19, 2017 at 1:20 AM, Gailu Singh wrote: > Failing grub code > -- > static void > init_cbfsdisk (void) > { > grub_uint32_t ptr; > struct cbfs_header *head; > > ptr = *(grub_uint32_t *) 0xfffc; > head = (struct

Re: [coreboot] Some errors by compiling romstage (I am a newbie)

On Fri, Mar 3, 2017 at 11:23 AM, Maxim Gusev wrote: > Yes, Aaron. I tried to figure it all out. > Some option doesn't works correctly. But the compiler and the linker are > supporting these options. > There is a log of "readelf -e imd_cbmem.o": http://pastebin.com/G5y36uU4

Re: [coreboot] Some errors by compiling romstage (I am a newbie)

On Fri, Mar 3, 2017 at 8:37 AM, Maxim Gusev wrote: > It doesn't work any case. > As I understood these options remove the unreferenced symbols, but I have > referenced symbols (the error is undefined reference). > The definition of the used functions is in the file that is

Re: [coreboot] Some errors by compiling romstage (I am a newbie)

On Fri, Mar 3, 2017 at 6:41 AM, Maxim Gusev wrote: > These options are supported. > But the option -fno-pie is not supported (Don’t produce a position > independent executable). > Is it the reason of the fault? I wouldn't think so. If you remove that option does it

Re: [coreboot] Some errors by compiling romstage (I am a newbie)

On Thu, Mar 2, 2017 at 8:33 AM, Maxim Gusev wrote: > Hello, Aaron! > > I am compiling sourses of my arch e2k. > I have compiled bootblock with my sources. There aren't my sources in other > stages. I have create arch directory and mainboard directory where the > sources are

Re: [coreboot] Some errors by compiling romstage (I am a newbie)

On Thu, Mar 2, 2017 at 7:24 AM, Maxim Gusev via coreboot wrote: > Hi everbody! > > I have a question. Very hope for your help. > > When I am compiling the romstage there are 2 errors by the linker: > Undefined refference to 'bootmem_add_range' > Undefined refference to

Re: [coreboot] Dont filter supported CPUs on a mainboard by the CPUID

On Fri, Feb 24, 2017 at 5:04 AM, wrote: > Yes, this die() is what i mean. Try to get maybe some functionality is i > think better then just stopping there and providing zero functionality. > > I also know, that there is a message when the CPUID is not known. Its about

Re: [coreboot] Dont filter supported CPUs on a mainboard by the CPUID

On Thu, Feb 23, 2017 at 2:39 AM, Nico Huber wrote: > On 23.02.2017 00:07, i1w5d7gf38...@tutanota.com wrote: > >> There is a Filter to stop booting when the CPUID is not in a list of >> supported CPUs. This filter does not make sense in the real world usage. > > It's not a filter.

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

with the IFWI and makes it work with coreboot's implementation/support for apollolake. > > Thank you, > Zoran > > On Wed, Feb 22, 2017 at 5:05 PM, Aaron Durbin <adur...@google.com> wrote: >> >> On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic >>

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic wrote: > I can admit my errors: > > This is what I have: > > user@localhost FspBin]$ pwd > /home/user/projects/coreboot/coreboot/APL-I_FSP/ApolloLakeFspBinPkg/FspBin > [user@localhost FspBin]$ ls -al > total 672

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

On Wed, Feb 22, 2017 at 9:56 AM, Nico Huber wrote: > On 22.02.2017 08:12, Zoran Stojsavljevic wrote: >> Hello to community, >> >> I finally, after 3 days of additional very hard struggle, found out why I >> have (while I am in the last stage of building CBFS) nonsense

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

. I was attempting to help with the situation, but as you are purposefully being opaque about settings it's impossible for me to help. > > Thank you, > Zoran > > On Wed, Feb 22, 2017 at 4:29 PM, Aaron Durbin <adur...@google.com> wrote: > >> >> >> On Wed,

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

pset uses the Intel Firmware Descriptor to describe the* > * layout of the SPI ROM chip.* > > *if HAVE_INTEL_FIRMWARE* > > *comment "Intel Firmware"* > > *config HAVE_IFD_BIN* > > Zoran > > On Wed, Feb 22, 2017 at 4:13 PM, Aaron Durbin <adur...@google.com> wr

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

in red have nothing to do with the flash descriptor settings. Please look in src/southbridge/intel/common/firmware/Kconfig for that list. Also, without the full details of your config it's impossible to know what you are or aren't doing. > Zoran > > On Wed, Feb 22, 2017 at 3:39

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

On Wed, Feb 22, 2017 at 1:12 AM, Zoran Stojsavljevic wrote: > Hello to community, > > I finally, after 3 days of additional very hard struggle, found out why I > have (while I am in the last stage of building CBFS) nonsense while building > APL-I Coreboot

Re: [coreboot] Understand vboot logic to select FW_B

On Wed, Feb 15, 2017 at 3:20 PM, <ttu...@codeaurora.org> wrote: > On 2017-02-15 09:45, Aaron Durbin via coreboot wrote: >> >> On Wed, Feb 15, 2017 at 11:38 AM, <ttu...@codeaurora.org> wrote: >>> >>> On 2017-02-15 07:46, Aaron Durbin via coreboot wrote

Re: [coreboot] Understand vboot logic to select FW_B

On Wed, Feb 15, 2017 at 11:38 AM, <ttu...@codeaurora.org> wrote: > On 2017-02-15 07:46, Aaron Durbin via coreboot wrote: >> >> On Tue, Feb 14, 2017 at 8:26 PM, <ttu...@codeaurora.org> wrote: >>> >>> >>> Folks, >>> I'm working on core

Re: [coreboot] Understand vboot logic to select FW_B

On Tue, Feb 14, 2017 at 8:26 PM, wrote: > > Folks, > I'm working on coreboot on ARMv8 architecture and recently attempted to > verify FW_B can be selected if FW_A is corrupted. > > In reviewing the code-path through coreboot vboot wrapper and > vboot_reference library I'm

Re: [coreboot] Add coreboot storage driver

On Tue, Feb 14, 2017 at 1:07 PM, Patrick Georgi <pgeo...@google.com> wrote: > 2017-02-14 17:12 GMT+01:00 Aaron Durbin via coreboot <coreboot@coreboot.org>: >> For an optimized bootflow >> all pieces of work that need to be done pretty much need to be closely >&g

Re: [coreboot] Add coreboot storage driver

On Tue, Feb 14, 2017 at 1:06 PM, Nico Huber wrote: > On 14.02.2017 18:56, ron minnich wrote: >> At what point is ramstage a kernel? I think at the point we add file >> systems or preemptive scheduling. We're getting dangerously close. If we >> really start to cross that boundary,

  1   2   3   4   >