Dear coreboot folks,
Often I am running into problems, when updating the tree.
Normally I do `git pull --rebase` to update my branch, and rebase my
changes on top of the upstream master branch. But if something in the
submodules, under `3rdparty` changes, I get a dirty tree. The same is
true,
This would be a good topic to bring up in the next community chat.
On Tue, Mar 21, 2017 at 1:21 PM, Sam Kuper wrote:
> On 21/03/2017, Martin Roth wrote:
>> Is there a reason we shouldn't switch to CC BY 4.0?
>
> Arguably, yes: doing so would permit the
>
> As fallback/payload is compressed in bios.bin, I'm not sure what strings
> will provide.
> I did run strings on bios.bin (as well as looking at it in hex editor) and
> found nothing
> explicitly suggesting depthcharge (or u-boot for that matter) was the
> payload. I made
> assumption u-boot
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 pulled all of the recovery images, but have
looked at ~10
* those interested in
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
On 28.03.2017 01:39, Denis 'GNUtoo' Carikli wrote:
> On Mon, 27 Mar 2017 16:14:53 +0200
> Zoran Stojsavljevic wrote:
>
>> [user@localhost projects]$ cat dmesg.txt | grep 00:19.0
>> [0.151652] pci :00:19.0: *[8086:294c*] type 00 class 0x02
>> [
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
On Mon, 27 Mar 2017 14:33:23 -0700
Andrey Petrov wrote:
> Hi,
>
> On 03/27/2017 01:05 PM, Denis 'GNUtoo' Carikli wrote:
> > Since until now, the code running on the management engine is:
> > - Signed by its manufacturer
> > - Proprietary software, without corresponding
On Mon, 27 Mar 2017 15:19:17 -0500
Timothy Pearson wrote:
> In general static timeouts are not a good idea. Is there a reliable
> way for coreboot to determine if the ME image has been
> "cleaned" (i.e. can it parse the ME descriptor and not even search
> for the
Hi,
Please find the latest report on new defect(s) introduced to coreboot found
with Coverity Scan.
13 new defect(s) introduced to coreboot found with Coverity Scan.
481 defect(s), reported by Coverity Scan earlier, were marked fixed in the
recent build analyzed by Coverity Scan.
New
10 matches
Mail list logo