> > > Having an undocumented (or silently installed, therefore unexpected)
> > > dependency is undesirable (especially for a firmware), no question
> > > about that.
> >
> > Sorry, I still get the impression that there is a fundamental
> > misunderstanding about what Git submodules are here.
>
> I
Julius Werner wrote:
> > Having an undocumented (or silently installed, therefore unexpected)
> > dependency is undesirable (especially for a firmware), no question
> > about that.
>
> Sorry, I still get the impression that there is a fundamental
> misunderstanding about what Git submodules are
Am Mi., 18. Nov. 2020 um 23:54 Uhr schrieb Julius Werner <
jwer...@chromium.org>:
> because unlike everything
> else you need to build coreboot there seems to be no way to get an ADA
> toolchain from crossgcc.
gnat (gcc's Ada implementation) needs an Ada implementation to bootstrap
(just like
> Having an undocumented (or silently installed, therefore unexpected)
> dependency is undesirable (especially for a firmware), no question about that.
Sorry, I still get the impression that there is a fundamental
misunderstanding about what Git submodules are here. It's *just*
source code! It's
Am Mi., 18. Nov. 2020 um 22:03 Uhr schrieb Nico Huber :
> The vboot dependency has been a PITA for a while. I'll happily accept
> patches that make it less of a pain even if that means a little more
> maintenance effort. I'd even accept a local hash implementation.
That's an option. That isn't
Am Mi., 18. Nov. 2020 um 22:15 Uhr schrieb bzt :
> I believe you are both unnecessarily overcomplicate this. The way I
> see it the only issue here is a few missing ifdef guards for
> CONFIG_VBOOT in cbfs, that's all. Quite straightforward to solve.
>
CONFIG_VBOOT enables vboot, the verified boot
I think I should continue here, sorry that my previous response was to
gcc requirements.
David Hendricks wrote:
> Can you be more specific? I ran thru the instructions and built for a qemu
> target and did not run into any problems
Here are the commands that I've used. Without submodules,
Hello Patrick,
I'm a bit concerned about the tone of your email. Maybe you were just
reflecting the meeting literally. In that case, sorry in advance.
In several spots you seem to imply that Peter would settle for less
than what is expected. I have no idea where that comes from. Also,
I don't
Hi Julius,
On 12.11.20 03:29, Julius Werner wrote:
> So I think the "official" rule is basically that the minimum
> requirement for host utilities is the same compiler and version that
> crossgcc uses, which I think makes some amount of sense (otherwise
> we'll just have to keep tracking and
Hi all,
On 12.11.20 03:29, Julius Werner wrote:
> I don't think it's fair to single in on vboot as the big problem here.
it's not by any definition but, FWIW, it became one in practice. I don't
think it's because of GCC versions or anything that we should try to fix
by testing. One big
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:America/Denver
X-LIC-LOCATION:America/Denver
BEGIN:DAYLIGHT
TZOFFSETFROM:-0700
TZOFFSETTO:-0600
TZNAME:MDT
DTSTART:19700308T02
Am Di., 17. Nov. 2020 um 18:54 Uhr schrieb Peter Stuge :
> Patrick Georgi via coreboot wrote:
> > coreboot doesn't, cbfstool does.
>
> If that were the case things would already be a lot better!
>
> Alas, coreboot unconditionally requires vboot in these files:
>
Oops, I forgot about those, you're
Angel wrote...
Well, I'd like to see your code: which memcfg parameters you're using,
among other things. Could you please put it somewhere (e.g.
review.coreboot.org) so that I can take a look?
I have basically just taken the memcfg structure from the Intel Comet
Lake reference platform and
On 14.11.20 00:52, Daniel Kiper wrote:
> Hey,
>
> This is next attempt to create firmware and bootloader log specification.
> Due to high interest among industry it is an extension to the initial
> bootloader log only specification. It takes into the account most of the
> comments which I got up
On 16/11/2020 08.02, Ulrich Windl wrote:
Daniel Kiper schrieb am 14.11.2020 um 00:52 in
> Nachricht <20201113235242.k6fzlwmwm2xqh...@tomti.i.net-space.pl>:
> ...
>> The members of struct bf_log_msg:
>> ‑ size: total size of bf_log_msg struct,
>> ‑ ts_nsec: timestamp expressed in
Marshall Dawson wrote:
> Hi Chen,
>
> We'll have FSP images for Picasso available very soon. Once that's in
> place we'll modify the Kconfig defaults to automatically include them into
> the build.
>
> Thanks,
> Marshall
>
>
> On Tue, Oct 27, 2020 at 12:13 AM chen.kenyy(a)inventec.com wrote:
Hi Andy
On Wed, Nov 18, 2020 at 1:22 PM Andy Pont wrote:
>
> Angel wrote...
>
> I can’t match what is printed on the top of the Micron devices (two lines of
> text “0JE75” and “D9ZFW”) to any part numbers on Micron’s website. Is it some
> kind of encoded version of the part number or is it
To understand the exact failure cause in FSPM, you need to get post code
from FSP. What is printed in log is Coreboot post code only.
Did you get memory part number from dmidecode -t 17 ?
If you read top of dimm, that will avoid confusion & in my experience
typically part number is printed. In
Angel wrote...
I can’t match what is printed on the top of the Micron devices (two lines of
text “0JE75” and “D9ZFW”) to any part numbers on Micron’s website. Is it some
kind of encoded version of the part number or is it just factory and build
information? Looking at the website I would
Am Mi., 18. Nov. 2020 um 09:14 Uhr schrieb David Hendricks <
david.hendri...@gmail.com>:
> or is the problem here just the fact that the hashing library is part of a
> submodule?
>
If it's the submodule that is in question here, we _could_ import vboot as
a subtree (and compatibly, too!),
Hi,
On Wed, Nov 18, 2020 at 10:00 AM Andy Pont wrote:
>
> Naresh wrote…
>
> Don't know how to recover SPD from UEFI but Try to read memory part number
> written on chip and provide that. Look for SPD file with that name if it's
> already present in coreboot.
>
> The schematics for the platform
Naresh wrote…
Don't know how to recover SPD from UEFI but Try to read memory part
number written on chip and provide that. Look for SPD file with that
name if it's already present in coreboot.
The schematics for the platform show Samsung K4A8G165WB-BCRC devices
which are (8Gb, 2400Mbps,
>
> > You seem to imply that this may cause some kind of security or
> availability problem
>
> Can you guarantee that a silently installed submodule's repo won't get
> hacked and replaced with malicious code for example? We have seen that
> happening with other repos already (github, sourceforge
23 matches
Mail list logo
