[coreboot] Re: On handling vendorcode

[Julius Werner]

> 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 responded to this on
https://review.coreboot.org/c/coreboot/+/51827 before I saw this mail.

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 remains clear that that code isn't "proper" coreboot code and
didn't go through the same level of review.

If you want to separate the two cases, maybe just make a
src/vendorcode/mirrored/ subdirectory and put the stuff that was
mirrored from a different upstream under there?
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: problem after "convert to ASL 2.0"

[Michael Niewöhner]

Hi,

could you test if this one resolves the problem, too, please?
https://review.coreboot.org/c/coreboot/+/52144

Thanks!
Michael



___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: problem after "convert to ASL 2.0"

[Andrew A . I .]

Yes,reverting comit 81d55cf solved the problem with current measurement on BAT state on lenovo T420. Angel, thanks!Also, thanks to all coreboot developers! 06.04.2021, 21:57, "Angel Pons" :Hi Andrew, listOn Tue, Apr 6, 2021 at 6:52 PM Andrew A. I.  wrote: Hello, Elyes! After "Convert to ASL 2.0 syntax" set of commits to current coreboot branch, i lost the data of battery current on BAT state from: cat /sys/class/power_supply/BAT0/current_now 0 On AC state (charging) data is present: cat /sys/class/power_supply/BAT0/current_now 1346000 Checkout to coreboot tag/4.13 is fixing the problem. But system was very unstable with: Apr 4 23:45:06 tp0 kernel: [ 60.868922] BUG: unable to handle page fault for address: 00ccfffc Apr 4 23:45:06 tp0 kernel: [ 60.868992] #PF: supervisor read access in kernel mode Apr 4 23:45:06 tp0 kernel: [ 60.869033] #PF: error_code(0x) - not-present page Apr 4 23:45:06 tp0 kernel: [ 60.869074] PGD 0 P4D 0 Apr 4 23:45:06 tp0 kernel: [ 60.869102] Oops:  [#1] SMP PTI Apr 4 23:45:06 tp0 kernel: [ 60.869134] CPU: 0 PID: 1960 Comm: git Tainted: G U 5.10.0-5-amd64 #1 Debian 5.10.24-1 Apr 4 23:45:06 tp0 kernel: [ 60.869261] RIP: 0010:__d_lookup_rcu+0x82/0x170 System: Lenovo T420 coreboot-4.13-2951-g0972871a23-T420 Debian bullseye/sid Battery in main slot Any ideas?It's most likely this commit, and I already noticed an issue with it:https://review.coreboot.org/50317You can try reverting it to see if the problem gets fixed.  ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.orgBest regards,Angel___coreboot mailing list -- coreboot@coreboot.orgTo unsubscribe send an email to coreboot-le...@coreboot.org___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: On handling vendorcode

[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 that fits the "it has a
> foreign upstream" description (e.g. the lzma library)?

I think that can make sense, but where would the chromeos, eltan and
other directories go instead? Someplace existing, or someplace new?


//Peter
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: problem after "convert to ASL 2.0"

[Angel Pons]

Hi Andrew, list

On Tue, Apr 6, 2021 at 6:52 PM Andrew A. I.  wrote:
>
> Hello, Elyes!
> After "Convert to ASL 2.0 syntax" set of commits to current coreboot branch, 
> i lost the data of battery current on BAT state from:
> cat /sys/class/power_supply/BAT0/current_now
> 0
> On AC state (charging) data is present:
> cat /sys/class/power_supply/BAT0/current_now
> 1346000
> Checkout to coreboot tag/4.13 is fixing the problem.
> But system was very unstable with:
>
> Apr  4 23:45:06 tp0 kernel: [   60.868922] BUG: unable to handle page fault 
> for address: 00ccfffc
> Apr  4 23:45:06 tp0 kernel: [   60.868992] #PF: supervisor read access in 
> kernel mode
> Apr  4 23:45:06 tp0 kernel: [   60.869033] #PF: error_code(0x) - 
> not-present page
> Apr  4 23:45:06 tp0 kernel: [   60.869074] PGD 0 P4D 0
> Apr  4 23:45:06 tp0 kernel: [   60.869102] Oops:  [#1] SMP PTI
> Apr  4 23:45:06 tp0 kernel: [   60.869134] CPU: 0 PID: 1960 Comm: git 
> Tainted: G U5.10.0-5-amd64 #1 Debian 5.10.24-1
> Apr  4 23:45:06 tp0 kernel: [   60.869261] RIP: 0010:__d_lookup_rcu+0x82/0x170
>
> System:
> Lenovo T420
> coreboot-4.13-2951-g0972871a23-T420
> Debian bullseye/sid
> Battery in main slot
>
> Any ideas?

It's most likely this commit, and I already noticed an issue with it:
https://review.coreboot.org/50317
You can try reverting it to see if the problem gets fixed.

> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

Best regards,

Angel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] problem after "convert to ASL 2.0"

[Andrew A . I .]

Hello, Elyes!After "Convert to ASL 2.0 syntax" set of commits to current coreboot branch, i lost the data of battery current on BAT state from:cat /sys/class/power_supply/BAT0/current_now  0On AC state (charging) data is present:cat /sys/class/power_supply/BAT0/current_now 1346000Checkout to coreboot tag/4.13 is fixing the problem.But system was very unstable with:Apr  4 23:45:06 tp0 kernel: [   60.868922] BUG: unable to handle page fault for address: 00ccfffc Apr  4 23:45:06 tp0 kernel: [   60.868992] #PF: supervisor read access in kernel modeApr  4 23:45:06 tp0 kernel: [   60.869033] #PF: error_code(0x) - not-present pageApr  4 23:45:06 tp0 kernel: [   60.869074] PGD 0 P4D 0  Apr  4 23:45:06 tp0 kernel: [   60.869102] Oops:  [#1] SMP PTIApr  4 23:45:06 tp0 kernel: [   60.869134] CPU: 0 PID: 1960 Comm: git Tainted: G U    5.10.0-5-amd64 #1 Debian 5.10.24-1Apr  4 23:45:06 tp0 kernel: [   60.869261] RIP: 0010:__d_lookup_rcu+0x82/0x170System:Lenovo T420coreboot-4.13-2951-g0972871a23-T420Debian bullseye/sidBattery in main slot Any ideas? ___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] On handling vendorcode

[Patrick Georgi via coreboot]

Hi everybody,

We recently landed a change (https://review.coreboot.org/51827) to be more
selective which parts of src/vendorcode are checked for coding style
because some areas are really coreboot code "by vendors".

The original purpose of that subhierarchy was to isolate code we draw in
from the outside to make every dev aware that the file they're touching has
some upstream other than coreboot and that this code shouldn't be modified
except to track that upstream.

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)?


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] New Defects reported by Coverity Scan for coreboot

[scan-admin--- via coreboot]

Hi,

Please find the latest report on new defect(s) introduced to coreboot found 
with Coverity Scan.

1 new defect(s) introduced to coreboot found with Coverity Scan.
1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent 
build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)


** CID 1452005:  Memory - corruptions  (OVERRUN)
/tests/lib/malloc-test.c: 53 in setup_calloc_test()



*** CID 1452005:  Memory - corruptions  (OVERRUN)
/tests/lib/malloc-test.c: 53 in setup_calloc_test()
47 
48  return 0;
49 }
50 
51 static int setup_calloc_test(void **state)
52 {
>>> CID 1452005:  Memory - corruptions  (OVERRUN)
>>> Overrunning buffer pointed to by "&_heap" of 1 bytes by passing it to a 
>>> function which accesses it at byte offset 4194303 using argument 
>>> "4194304UL". [Note: The source code implementation of the function has been 
>>> overridden by a builtin model.]
53  memset(&_heap, 0xFF, TEST_HEAP_SZ);
54  return setup_test(state);
55 }
56 
57 static void test_malloc_out_of_memory(void **state)
58 {



To view the defects in Coverity Scan visit, 
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yq2SfQfrHt3Prsn4qSLrYIrajINpiFX8l0vrlNSf8iCrS27qY0Cr0DkycwNUgGZJj8-3DOBmv_L-2FDzr14mnrsJO5b1wX1hp9b1MAQygl7x-2B74RAaH2cn2D-2FM5I3nUzOwPmvfgKcy9xVtX9P5U9TE-2FITY-2FVDbWjsPc00LFasnemVsrv8J9ABzwmNNqohdu7Nx5L7FeB-2FIS-2FbSTsasY3L-2Bpa7imNT6alE9OQTajEAjiLizXH0IO2X4V2Byx-2FDx0xdagtQ8paZhBJR3BP-2FHuARBxzsIsKtj6obDFjK8hLKUhFfPiStWLp4TQ-3D

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: CB:46587 - pirq_routing

[Mike Banon]

Hi there Elyes,

Your "getpir" idea really helped me to implement a set of CB:48427
"AMD good IRQ" patches.
Thank you so much for your kind help! Wanted to thank you earlier but
it got lost in drafts ;-)
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org