Martin Roth via coreboot wrote:
> > On Mon, 2022-04-11 at 22:23 +, Peter Stuge wrote:
> >> Martin Roth via coreboot wrote:
> >> > 1) Please don't use the term deprecate - use "moved to a branch"
> >>
> >> I don't think the wording matters, my points are discoverability and
> >> drive-by
Obviously a way to sidestep all this would be to simply test the board in
question, which is a small investment of money and time.
It's sad that automated testing appears to no longer be ongoing. I might
wonder whether coreboot sponsors would support a coreboot-associated
automated test lab.
The
Apr 12, 2022, 12:14 by f...@mniewoehner.de:
> On Mon, 2022-04-11 at 22:23 +, Peter Stuge wrote:
>
>> Martin Roth via coreboot wrote:
>> > 1) Please don't use the term deprecate - use "moved to a branch"
>>
>> I don't think the wording matters, my points are discoverability and
>>
ron minnich wrote:
> My goal was pretty simple: Kill the UEFI HOBs, and the FSP UPD, and
> put something better in their place. coreboot tables could easily
> replace HOBs, save that intel will never accept that;
Thanks, now I understand.
> but I don't see coreboot tables replacing UPD.
Why
My goal was pretty simple: Kill the UEFI HOBs, and the FSP UPD, and
put something better in their place. coreboot tables could easily
replace HOBs, save that intel will never accept that; but I don't see
coreboot tables replacing UPD.
[one might argue that what Intel will accept matters a lot
ron minnich wrote:
> peter, you are right about CBOR, and that says to me it does not
> really meet the original goal of self-describing data.
Hm, whose goal is that?
Anyway, using some data structure serialized in CBOR requires
defining the structure somewhere. Using coreboot tables requires
On Mon, 2022-04-11 at 22:23 +, Peter Stuge wrote:
> Martin Roth via coreboot wrote:
> > 1) Please don't use the term deprecate - use "moved to a branch"
>
> I don't think the wording matters, my points are discoverability and
> drive-by maintainance.
>
>
> > If a platform is perfect and
On 4/12/22 10:17, Nico Huber wrote:
Hello Insurgo,
On 12.04.22 16:01, Insurgo Technologies Libres / Open Technologies wrote:
On April 12, 2022 8:55:56 AM UTC, Arthur Heymans
wrote:
Would it make sense to backport your fix to old releases and bump
those release numbers to a .1 on the end?
peter, you are right about CBOR, and that says to me it does not
really meet the original goal of self-describing data. But coreboot
tables, at least in my understanding, is also not self-describing.
Do you have some thoughts on a good format that is self-describing?
On Mon, Apr 11, 2022 at 3:05
Hello Insurgo,
On 12.04.22 16:01, Insurgo Technologies Libres / Open Technologies wrote:
> On April 12, 2022 8:55:56 AM UTC, Arthur Heymans wrote:
>>> Would it make sense to backport your fix to old releases and bump
>>> those release numbers to a .1 on the end?
>>>
>>
>> Some see releases as
On April 12, 2022 8:55:56 AM UTC, Arthur Heymans wrote:
>Hi
>
>Would it make sense to backport your fix to old releases and bump
>> those release numbers to a .1 on the end?
>>
>
>Some see releases as mere synchronization tags & nice PR.
>Some releases are also branches in gerrit but there are
Arthur Heymans wrote:
> > Would it make sense to backport your fix to old releases and bump
> > those release numbers to a .1 on the end?
..
> It's a bit weird to have releases that you'd have to advertise as *don't
> use*, but I've seen us do that in the past (because issues are quite often
>
Hi
Would it make sense to backport your fix to old releases and bump
> those release numbers to a .1 on the end?
>
Some see releases as mere synchronization tags & nice PR.
Some releases are also branches in gerrit but there are none affected by
this (latest is 4.12 and it was introduced in
Hi
The obvious easy solution is to not use SMM but that's a different topic.
I think it should also be doable to write unit tests that would do a setup
for 1 (1 is often a special case) and many cpus and see that things like
stubs, stack, save state, permanent handler, ... don't overlap.
I
Hi,
I am looking for info to add WINBOND SPI FLASH part W25Q256JW (0x6019).
tried adding below entry in winbond.c, is there any other changes required
to enable this part to boot from?
{
/* W25Q256JW */
.id[0] = 0x6019,
.nr_sectors_shift = 13,
15 matches
Mail list logo
