>> I think we still need to have a difference between hacky vendor stuff
>> and normal coreboot code. For example, the Eltan mboot stuff is
>> something we didn't really want to have in coreboot in that form, and
>> so they kinda put it in vendorcode as a compromise. We should make
>> sure it
Stuge
Cc: coreboot
Betreff: [coreboot] Re: On handling vendorcode
Am Di., 6. Apr. 2021 um 21:21 Uhr schrieb Peter Stuge <mailto:pe...@stuge.se>:
Patrick Georgi via coreboot wrote:
> Any objections to moving the code out there that has no other upstream
> (e.g. src/vendorcode/goog
Am Mi., 7. Apr. 2021 um 01:12 Uhr schrieb Julius Werner <
jwer...@chromium.org>:
> I think we still need to have a difference between hacky vendor stuff
> and normal coreboot code. For example, the Eltan mboot stuff is
> something we didn't really want to have in coreboot in that form, and
> so
Am Di., 6. Apr. 2021 um 21:21 Uhr schrieb Peter Stuge :
> Patrick Georgi via coreboot wrote:
> > Any objections to moving the code out there that has no other upstream
> > (e.g. src/vendorcode/google/chromeos or src/vendorcode/eltan, I think?)
> > while moving in code from elsewhere in the tree
> Any objections to moving the code out there that has no other upstream (e.g.
> src/vendorcode/google/chromeos or src/vendorcode/eltan, I think?) while
> moving in code from elsewhere in the tree that fits the "it has a foreign
> upstream" description (e.g. the lzma library)?
Sorry, I just
Patrick Georgi via coreboot wrote:
> Any objections to moving the code out there that has no other upstream
> (e.g. src/vendorcode/google/chromeos or src/vendorcode/eltan, I think?)
> while moving in code from elsewhere in the tree that fits the "it has a
> foreign upstream" description (e.g. the
6 matches
Mail list logo