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 exactly the same. So, fla
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
separate chips on a b
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 the
> SPI controller re
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 it (I
> presume it is?). A
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 please help me, what *intelblocks* mean
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 you?
>
>
> sure.
>
>>
>>
>> Am I correct, or you can
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 easier. And it can't
> be tha
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 last and best owner controlled x86 boards.
>
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 me at the documents th
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.
>>
>> My understanding is t
once I'm able to start contributing to the project.
> Cheers,
> T.mike
>
> On Tue, Dec 19, 2017 at 9:19 AM, ron minnich
>> wrote:
>>
>> Is there even a question? Looks like aaron just answered the
>>> original question, which boils down to Read The Source?
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 but I guess that coul
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 would need
to be address
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 a lot in common with the cod
On Thu, Feb 8, 2018 at 8:54 AM, Julien Viard de Galbert
wrote:
>
>
> Le 8 févr. 2018 à 17:24, Aaron Durbin a écrit :
>
> 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
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 Ta
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 previous commit whole
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 09:41:59.840 2018] MTRR Range: Start=7a80
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.
>
>
>
> Root Device assign_resources,
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 have a
>> look. B
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
>--->--- * called with only a s
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)':
>
> VfrUtilityLib.cpp:3375:26: error: ISO C++ for
On Wed, Apr 4, 2018 at 8:40 AM, Piotr Król wrote:
>
>
> On 04/04/2018 05:31 PM, Aaron Durbin wrote:
>> 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
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 spi_ctrlr), and I
> don't think i
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 duplex,
>> if possible
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() means two different th
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 into coreboot'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? I'm
curious as to wh
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 believe that this change caus
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 console: only allow console
On Fri, May 4, 2018 at 11:16 AM, Kyösti Mälkki wrote:
> On Fri, May 4, 2018 at 7:19 PM, Kyösti Mälkki wrote:
>> On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin wrote:
Any idea what can be result of such weird behavior?
>>>
>
> My current guess is AP CPUs do not see initialised memory for
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 FSP headers that match the public
On Fri, May 4, 2018 at 8:49 PM, Kyösti Mälkki wrote:
> On Fri, May 4, 2018 at 8:22 PM, Aaron Durbin wrote:
>> On Fri, May 4, 2018 at 11:16 AM, Kyösti Mälkki
>> wrote:
>>> On Fri, May 4, 2018 at 7:19 PM, Kyösti Mälkki
>>> wrote:
On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin wrote:
>>
On Sat, May 5, 2018 at 5:36 AM, Nico Huber wrote:
> On 04.05.2018 23:41, Aaron Durbin via coreboot wrote:
>> On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui
>> wrote:
>>> Hi,
>>>
>>> I've just pushed a commit for review on gerrit
>>> (ht
On Sat, May 5, 2018 at 4:26 PM, Kyösti Mälkki wrote:
> On Sun, May 6, 2018 at 12:17 AM, Aaron Durbin wrote:
>>> I find it particularly hard to be civil on your first question, so
>>> trying with sarcasm instead. After 5000 or so development hours and
>>> direct support from AMD, is the boot seque
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 take something away
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 state in
>> coreboot as a whole would match neith
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 stat
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 m
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 ris
On Thu, Feb 5, 2015 at 12:48 PM, Timothy Pearson
wrote:
> On 02/05/2015 12:38 PM, Jonathan A. Kollasch wrote:
>>
>> That's a pretty old memtest86+. Also, memtest86+ prefers
>> linuxbios/coreboot memory map to e820. This becomes a problem
>> when SeaBIOS sets up a USB controller to DMA to e820-re
On Tue, Feb 17, 2015 at 10:44 PM, Alexandru Gagniuc
wrote:
> On Tuesday, February 17, 2015 04:32:18 PM Julius Werner wrote:
>> > 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 advantag
On Wed, Feb 18, 2015 at 9:16 AM, Aaron Durbin wrote:
> On Tue, Feb 17, 2015 at 10:44 PM, Alexandru Gagniuc
> wrote:
>> On Tuesday, February 17, 2015 04:32:18 PM Julius Werner wrote:
>>> > The x86 was recently fixed to take in void *. The order of arguments was
>>> > discussed before, and the agre
On Wed, Feb 18, 2015 at 10:35 AM, Patrick Georgi wrote:
> 2015-02-18 17:23 GMT+01:00 Vadim Bendebury :
>>> kernel, u-boot, etc. They all have the write(val, addr) semantics. I
>>> see no good reason to artificially erect an ever present barrier for
>>> integrating code into a coreboot system.
>>>
On Wed, Feb 18, 2015 at 10:49 AM, Alexandru Gagniuc
wrote:
> On Wednesday, February 18, 2015 09:16:07 AM Aaron Durbin wrote:
>> As I have noted on http://review.coreboot.org/#/c/7924/ it's very
>> short sighted to go this route. In assembling a coreboot stack (which
>> includes libpayload and the
On Wed, Feb 18, 2015 at 11:41 AM, Alexandru Gagniuc
wrote:
> On Wednesday, February 18, 2015 11:35:13 AM Aaron Durbin wrote:
>> You still haven't made any counter-argument to the practicalness of being
>> compatible with the software systems where coreboot gets contribution.
>>
> And you still hav
On Thu, Mar 19, 2015 at 7:21 PM, Julius Werner wrote:
>> 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
On Thu, Mar 19, 2015 at 7:53 PM, Julius Werner wrote:
>> 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
On Tue, Apr 21, 2015 at 9:54 AM, Aaron Durbin wrote:
> On Mon, Apr 20, 2015 at 9:29 PM, Matt DeVillier
> wrote:
>> On 4/20/2015 3:29 PM, Aaron Durbin wrote:
>>> On Mon, Apr 20, 2015 at 9:23 AM, Matt DeVillier
>>> wrote:
On 4/20/2015 8:51 AM, Aaron Durbin wrote:
> On Fri, Apr 17, 2015 at
On Wed, May 6, 2015 at 9:36 AM, Timothy Pearson
wrote:
> On 05/06/2015 06:54 AM, Patrick Georgi wrote:
>>
>> 2015-05-05 21:49 GMT+02:00 Timothy
>> Pearson:
>>>
>>> While working on the test system earlier today I noticed that QEMU builds
>>> are currently failing with the following error:
>>>
>>>
On Wed, May 6, 2015 at 9:41 AM, Aaron Durbin wrote:
> On Wed, May 6, 2015 at 9:36 AM, Timothy Pearson
> wrote:
>> On 05/06/2015 06:54 AM, Patrick Georgi wrote:
>>>
>>> 2015-05-05 21:49 GMT+02:00 Timothy
>>> Pearson:
While working on the test system earlier today I noticed that QEMU buil
On Wed, May 6, 2015 at 9:45 AM, Timothy Pearson
wrote:
> On 05/06/2015 11:41 AM, Aaron Durbin wrote:
>>
>> That's probably my fault. I was under the impression monotonic_timer
>> was a first class citizen now (I at least recall someone doing that) I
>> thought wrong?
>>
>> You could add the follow
On Wed, May 6, 2015 at 9:51 AM, Timothy Pearson
wrote:
> On 05/06/2015 11:46 AM, Aaron Durbin wrote:
>>
>> On Wed, May 6, 2015 at 9:45 AM, Timothy Pearson
>> wrote:
>>>
>>> On 05/06/2015 11:41 AM, Aaron Durbin wrote:
That's probably my fault. I was under the impression monotonic_t
On Wed, May 6, 2015 at 9:54 AM, Aaron Durbin wrote:
> On Wed, May 6, 2015 at 9:51 AM, Timothy Pearson
> wrote:
>> On 05/06/2015 11:46 AM, Aaron Durbin wrote:
>>>
>>> On Wed, May 6, 2015 at 9:45 AM, Timothy Pearson
>>> wrote:
On 05/06/2015 11:41 AM, Aaron Durbin wrote:
>
>
On Thu, May 7, 2015 at 3:42 PM, Patrick Georgi via coreboot
wrote:
> 2015-05-07 22:00 GMT+02:00 Stefan Reinauer :
>> With our current bootblock concept, it is never going away on x86 (for
>> bootblock usage)
> Which isn't that much of a problem once we provide separate headers
> for x86 bootblock
On Fri, May 8, 2015 at 12:16 PM, Patrick Georgi wrote:
> 2015-05-08 17:31 GMT+02:00 Aaron Durbin :
>> In romstage *both* struct device and device_t are present but are
>> completely different types. It's the romstage, ramstage, and smm
>> overlap that is large and extremely annoying to deal with.
On Wed, May 13, 2015 at 9:02 AM, Raptor Engineering Automated Coreboot
Test Stand wrote:
> The QEMU x86_64 Q35 fails verification as of commit
> 0a50d9b35334d03f13b38e21497ba0aae8b16712
>
> The following tests failed:
> ACPI_DSDT_ACCESS_FAILURE
> ACPI_SSDT_ACCESS_FAILURE
> DMIDECODE_ACCESS_FAILUR
On Wed, May 13, 2015 at 9:54 AM, Aaron Durbin wrote:
> On Wed, May 13, 2015 at 9:02 AM, Raptor Engineering Automated Coreboot
> Test Stand wrote:
>> The QEMU x86_64 Q35 fails verification as of commit
>> 0a50d9b35334d03f13b38e21497ba0aae8b16712
>>
>> The following tests failed:
>> ACPI_DSDT_ACCE
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 u
riginal Message-
> 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
On Thu, Oct 11, 2018 at 3:24 AM Antony AbeePrakash X V
wrote:
>
> Hi All,
>
> We are able to achieve the memory initialization time reduction. Now we have
> achieved the boot time as 5sec until the Postcode 0xf8 (entry into Elf boot).
>
> We have reduced the unwanted codes. We would like to reduc
cbmem timstamps will be needed.
Looks like FSP is manipulating the tsc:
BS: BS_DEV_INIT_CHIPS times (us): entry 0 run 4291539104 exit 0
I have a hard time believing that took 4291 seconds.
On Thu, Oct 11, 2018 at 10:11 AM Antony AbeePrakash X V <
antonyabee.prakas...@lnttechservices.com> wrot
On Fri, Oct 12, 2018 at 4:38 AM Antony AbeePrakash X V <
antonyabee.prakas...@lnttechservices.com> wrote:
> Hi Aron,
>
>
>
> I am not able to get the cbmem timestamps. I am using cbmem utility to
> find the timestamps.
>
>
>
> *$ . /cbmem -t*
>
>
>
> The above command gives the following error.
>
On Mon, Oct 15, 2018 at 6:42 AM Antony AbeePrakash X V
wrote:
>
> Hi Aron,
>
>
>
> I have tried giving iomem=relaxed to the kernel command line. But still I am
> getting the same error.
>
>
>
> This time I tried with verbose option and the output is below
>
> $ ./cbmem -V -t
>
>
>
> Looking for c
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 with
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 wo
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 are
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
On Wed, Jan 23, 2019 at 11:17 PM Zeh, Werner wrote:
> Currently with the one CBFS containing all files it is easy and simple to
> access every file in every stage.
> Wouldn't this be harder if we chose to split the CBFS into several,
> stand-alone CBFSes?
> Or, on the other hand, wouldn't we end
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 si
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 se
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 commer
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
> reliable
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 ob
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 enough to implement
> >>> platform hook telling to not remo
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
On Tue, Oct 1, 2019 at 10:29 AM Raul Rangel wrote:
> Yeah, we can place the stack at the bottom of a page so if it overflows we
> get a page fault. I'm assuming that will work in SMM?
>
Paging works in SMM, yes. However, paging works on 32-bit as well where one
could achieve the same thing. Mini
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
the
On Wed, Oct 9, 2019 at 3:07 PM Jeremy Soller wrote:
> Will do. Any relevant emails I should CC when I have something?
>
I'm not sure about Intel, but you can include mine, Duncan's, and
Furquan's. Should be autocomplete in gerrit.
>
> --
> Jeremy Soller
> System76
> Engineering Manager
>
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
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 t
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
> > mirror_payload()/CONFIG_MIRROR_PAYLOAD_T
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 at
OK. I'll take a look at your logs and see what's going on. The patch link I
sent was based off of someone else's mainboard logs.
On Wed, May 13, 2020 at 10:59 AM Keith Hui wrote:
> Hi Aaron,
>
> It didn't help. There still a way out of whack entry in the coreboot
> table and e820 entry ending at
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 going
On Wed, May 13, 2020 at 10:51 PM Keith Hui wrote:
> Hi guys,
>
> I tested these fixes on my board, and I have to say there's still
> something wrong. They did address the hang or reset in SeaBIOS I first
> described, but now either my ATA hard drive failed to boot (it tried
> to hand off to GRUB
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 c
On Thu, May 14, 2020 at 2:25 PM Keith Hui wrote:
> Hi Aaron,
>
> I think I have success after applying 41363 as well. Please see
> attached and tell us if this is what you set out to do.
>
That looks correct, and what I was expecting. Thanks for the help gathering
logs.
> Thanks
> Keith
>
> On
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
> booting - and, when they do, no boot devices are available (virtual
> floppies too, for some reason) -
On Thu, May 14, 2020 at 4:44 PM Keith Hui wrote:
> Hi Aaron,
>
> You may want to check the QEMU-q35 target as well:
>
> Automatic boot test returned (PASS/FAIL/TOTAL): 2/2/4
> Emulation targets:
> "QEMU x86 q35/ich9" using payload TianoCore : FAIL :
> https://lava.9esec.io/r/3427
> "QEMU x86 q35/
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
>> booting - and, when they do, no boot d
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
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
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 community,
>>>
>>> Currently there are 3 different "strapping
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 Wawrzynczak
On Wed, Nov 18, 2015 at 7:49 PM, Alex G. wrote:
> Is there such a payload? Seabios is stuck with IO UARTs. Not sure if
> grub can handle it (and if so, how). Depthcharge is out of the question
> because it is unbelievably difficult to build outside chromium os's
> uber-cumbersome build system.
>
>
On Thu, Nov 19, 2015 at 4:07 PM, Ben Gardner wrote:
> Hi,
>
> I've narrowed down where the CBMEM console is getting corrupted and
> found a work around that gets it working again.
> It is getting corrupted in the FSP Early Init function. So in the
> Intel blob, not coreboot.
>
> I added logs to cb
On Thu, Nov 19, 2015 at 4:17 PM, Martin Roth wrote:
> Hi Ben, I'm still trying to get to this. I don't know if you saw how
> different the fsp cbmem route is from other platforms. The fsp copies the
> contents of the car stack to the top of memory when it tears down the cache
> as ram. The pointer
On Fri, Nov 20, 2015 at 7:30 AM, Ben Gardner wrote:
> Hi Aaron,
>
> That patch didn't make a difference that I could see. The console
> buffer is still filled with garbage that cbmemc_reinit() copies into
> the final buffer.
> The issue was also with the timestamps, so special handling of the
> co
On Sat, Nov 21, 2015 at 10:14 PM, Ben Gardner wrote:
> I think I found the issue, but won't be able to test for another week.
>
> car_get_var_ptr() assumes that the migrated base is the same as
> _car_data_start.
> On FSP 1.0, that isn't true. _car_data_start is 0x0c00 bytes past
> migrated base
1 - 100 of 183 matches
Mail list logo
