Re: [coreboot] Re : Re: New user of KGPE-D16

[taii...@gmx.com]

Don't forget to check the bottom of the CPU to make sure that all the 
bits are present and accounted for and there are no scratches on the 
pads or mis-aligned capacitors (potentially dangerous) all of which are 
common problems with used CPU's.


Used 6386SE goes for around $150-250, I wouldn't pay more and I wouldn't 
get one that is damaged or has the missing capacitor issue (what the 
hell are these ebay guys doing with their CPU's?!??!)


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Postcode at Lenovo x230

[Kyösti Mälkki]

Hi Rafael

On Fri, Feb 16, 2018 at 2:03 PM, Rafael Machado
 wrote:

> The problem is that this time, with this x230, after I connected the
> postcard and turned the system on, the system stopped to boot. And the post
> card does not stop at a specific post code.

These cheap POST80 displays do not use PCI-e signalling. Looking at
Wistron Dasher-2 schematics that to my knowledge is (a/the) x230
mainboard, required LPC signals are not routed to either of the
mini-PCI-e slots. There is a separate (unpopulated) connector CN14 and
card-edge GF1 to use for post80 display.

> What happens now, is that every time I turn the system on, the battery led
> blinks 3 times, being two blinks followed by a 1 second stop and after that
> the last blink, and the system reboots.

:(

> The post card I'm using is this:
> https://www.ebay.com/itm/3in1-Mini-PCI-E-PCI-LPC-Tester-PC-Desktop-Diagnostic-Post-Card-Error-Code-Test/191862585496?hash=item2cabe6b898:g:x8MAAOSw2x1XKB5E

I have one these as well. That mini-PCI-e card-edge is not so great,
it is missing pads for pins 1 and 2. It also appears to be narrower
what the specs says, so you need to be very careful with proper
alignment on installation. Also have laptop battery removed while
doing so!

>
> So my questions are:
>
> -Does someone believe this postcard could have bricked the system? (Why?)
> -Any idea about how to solve that?

I would measure the 3.3V power rail on the mainboard (VCC3WLAN) . If
you had installed the postcard improperly/skewed to the socket you
could have caused some shortcut to GND and damaged the on-board power
circuitry. Other than that, I don't see how this post card could harm
a x230.

Hope this helps,
Kyösti

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] Fix undefined behavior with left shifts in whole code base

[Julius Werner]

>
> I’d really like to *enable as much warnings* as possible to let the
> build tools *catch as much errors as possible*, and having to adapt the
> code to work with this is in my opinion worth the effort.
>

This is not just a question of whether we want to spend the one-time effort
to adapt the code. It will be a constant readability issue going forward.
Almost no project out there writes shifts like that and almost no
programmer is used to reading them like that. I agree that automated
sanitizer coverage is a very good thing, but it is not the only thing that
matters. If a sanitizer tool forces us two rewrite code in a way that
creates serious friction for day-to-day development, then maybe we need to
wait until the authors of that tool add options to make it less aggressive
in that regard. GCC has already recognized the insanity of reporting that
construct as an error every time and thus given us the -Wshift-overflow=1 /
-Wshift-overflow=2 distinction, so I hope the UBSAN guys may eventually get
there as well.

For now, I think we should deactivate the whole shift test (I'm not an
UBSAN expert but from the documentation it sounds like
-fno-sanitize=shift-base should work), and then we'll still get the vast
majority of coverage without imposing excessive hoops to jump through onto
developers.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Postcode at Lenovo x230

[Rafael Machado]

Hi Eli

Thanks for the answer.

In fact I already tried this, but didn't work.
What I am afraid is the possibility of having bricked the system by using
the postcode at the wireless card slot.
Any idea if this could have happened?

Thanks
Rafael



Em sex, 16 de fev de 2018 às 16:18, Elisenda Cuadros 
escreveu:

> Hi Rafael,
>
> I have a X230, but this has never happened to me before. Sorry :-( .
>
> Have you tried unplugging, waiting 10 seconds and plugging the CMOS
> battery cable and trying to boot afterwards?
>
>
> Also disconnect the laptop battery during this procedure.
>
> Regards,
>
> - Eli
>
> On 16/02/18 13:03, Rafael Machado wrote:
>
> Hi everyone
>
> Since here are the most skilled professions I've seeing I believe someone
> can help me.
>
> I have a Lenovo x230, and I'll would like to install coreboot in it to
> start to understand how it works, and in future start to help the
> community, as soon as I have the knowledge for that.
>
> Last week I did a test that makes my progress stop.
>
> Just for fun, and to check how the commercial bios works, I connected a
> postcard on the wireless slot (as far as I know this is a pcie slot).
> I already did that with other notebooks I have and nothing wrong happened.
>
> The problem is that this time, with this x230, after I connected the
> postcard and turned the system on, the system stopped to boot. And the post
> card does not stop at a specific post code.
> What happens now, is that every time I turn the system on, the battery led
> blinks 3 times, being two blinks followed by a 1 second stop and after that
> the last blink, and the system reboots.
>
> The post card I'm using is this:
> https://www.ebay.com/itm/3in1-Mini-PCI-E-PCI-LPC-Tester-PC-Desktop-Diagnostic-Post-Card-Error-Code-Test/191862585496?hash=item2cabe6b898:g:x8MAAOSw2x1XKB5E
>
> So my questions are:
>
> -Does someone believe this postcard could have bricked the system? (Why?)
> -Any idea about how to solve that?
>
> My next test will be to write a coreboot build at this system using
> buspirate, but since I'll only have time for this next week, I would like
> to have some things to think about, this is why I sent this e-mail before
> doing the coreboot flash test.
>
> Any comment will be helpful.
>
> Thanks and Regards
> Rafael R. Machado
>
>
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

[Youness Alaoui]

>> Sure, you can trust hardware flashing more than software flashing,
>> but
>> I really need software flashing. If it was just for me, yeah, I could
>> fiddle with it to flash it by hardware for my personal needs, but
>> when
>> it's about deploying it to all our customer base, that's another
>> story, the only solution is software flashing. Obviously, it would
>> have to work in coreboot, so whatever coreboot is doing wrong (or AMI
>> is doing right.. my guess is that it's probably something with the EC
>> ACPI code), we'd have to figure that out first in order to get the
>> read/write support.
>
> Either way, since the EC firmware resides in the SPI flash, it'll be no
> issue to reflash it both by software and hardware.

On the librems, the EC firmware resides in a separate 64KB SPI flash,
it's not shared with the bios, and I haven't found a way to access it.
The 'ectool' is able to read it (ram idx reads if i remember
correctly) but it only worked with AMI BIOS. So there will definitely
be some work to be done there. You probably know a lot more about this
already, like what this 'ram idx' is, and why it didn't work in
coreboot, or if it's possible to read/write the flash using this EDI
interface, etc...

>
>> > Latest status update for Origami-EC firmware:
>> > https://www.mail-archive.com/coreboot@coreboot.org/msg50646.html
>>
>> Thanks! Good to see the status update on that.
>
> In order to kickstart the development of the Origami-EC firmware, I am
> designing evaluation boards for both the KB9012 and the KB3930 that
> will expose most of the I/O ports with headers, LEDs, buttons,
> connectors, etc. The design is done with KiCAD and will be released
> under the GPLv3+ as part of the Origami-EC project. I am also preparing
> a debug board to reflash the EC on the G505s from the keyboard
> connector.
>
> There is also ongoing work on the emulator and the SerialICE-like
> library for relatying and tracing I/O on the device via UART. Also,
> note that the emulator can now emulate a virtual console so it's
> already possible to build and interract with the firmware!
>
That's some really great news. A dev board will definitely be useful
for testing/debugging/developing Origami-EC!

> Cheers,
>
> Paul
>
>> > On Mon, Feb 5, 2018 at 9:47 PM, Youness Alaoui
>> >  wrote:
>> > > Hi Marty,
>> > >
>> > > Unfortunately, the EC firmware on the Librems is not open and we
>> > > have
>> > > someone working on that aspect, but with everything we have to
>> > > handle,
>> > > I think it's only being done part time.
>> > > We found something similar to you with the private submodule for
>> > > the
>> > > PS/2 module on the OLPC code.
>> > > More specifically :
>> > > http://lists.laptop.org/pipermail/openec/2011-January/000158.html
>> > > And http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A
>> > > 1
>> > >
>> > > I had opened a ticket a while ago here :
>> > > https://tracker.pureos.net/T178 which mentions Origami-EC. I
>> > > don't
>> > > know the status of that project, maybe you can contact the
>> > > developer
>> > > (Paul Kocialkowski) and see where he's at with his development of
>> > > that
>> > > project (which, I need to mention, hasn't been publicly launched
>> > > yet,
>> > > as far as I know) and he might benefit from your help if you are
>> > > interested in doing that.
>> > > The last time we spoke he said :
>> > > "The OLPC code is nowhere close to usable on any other platform.
>> > > Additionally, it is so poorly written that I don't think it is a
>> > > suitable codebase for any future development. On the other hand,
>> > > my
>> > > Origami-EC project (that I will publicly launch soon) should
>> > > provide a
>> > > flexible codebase to add support for new devices."
>> > >
>> > > Note that the tracker ticket above is quite outdated, we know how
>> > > to
>> > > dump the EC (the problem was that it can't be done via hardware
>> > > because the EC is on the same power rail as the 64KB flash chip,
>> > > so
>> > > when we power the flash via hardware, the EC boots and takes
>> > > control
>> > > of the SPI lines) but for some reason, we could only dump it via
>> > > software (using ectool) through the AMI BIOS firmware, with
>> > > coreboot,
>> > > we only get 0xFF returned, I don't believe we had time to
>> > > investigate
>> > > the cause for that.
>> > >
>> > > Sorry for not having any better news for you, but I hope this
>> > > helps a
>> > > little you at least.
>> > >
>> > > Good luck,
>> > > Youness.
>> > >
>> > >
>> > > On Fri, Feb 2, 2018 at 10:17 AM, Marty E. Plummer
>> > >  wrote:
>> > > > Greetings,
>> > > >
>> > > > Currently working on a port for the hp g7-2247us laptop, which
>> > > > features
>> > > > an ene kb3940q ec, which hopefully should be very similar to
>> > > > the kb3930
>> > > > ec, which has a datasheet available to the public in a few
>> > > > places.
>> > > >
>> > > > Said similar ec is used in some OLPC 

[coreboot] Re : Re: New user of KGPE-D16

[echelon]

FYI:
https://www.ebay.com/itm/AMD-Opteron-6386-2-8GHz-16-Core-Socket-G34-CPU-OS6386YETGGHK-TQ1458-/112768599369?
https://www.ebay.com/itm/Lot-of-4-AMD-Opteron-6386-SE-2-8GHz-Sixteen-Core-OS6386YETGGHK-Processor/132477925722?hash=item1ed84cb95a:g:~6MAAOSw0W5aJN~t
Regards,
 Florentin

- Mail d'origine -
De: taii...@gmx.com
À: Elisenda Cuadros , coreboot 
Envoyé: Thu, 15 Feb 2018 23:47:19 +0100 (CET)
Objet: Re: [coreboot] New user of KGPE-D16

...

> My cpu is 6238 not 6328, but thank you for your advise :-) .
I suggest obtaining the faster 6386SE ASAP before they become harder to 
come by (as AMD/ASUS has stopped making all G34/C32 stuff, so stock up 
while you can)

...

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Postcode at Lenovo x230

[Elisenda Cuadros]

Hi Rafael,

I have a X230, but this has never happened to me before. Sorry :-( .

Have you tried unplugging, waiting 10 seconds and plugging the CMOS 
battery cable and trying to boot afterwards?



Also disconnect the laptop battery during this procedure.

Regards,

- Eli


On 16/02/18 13:03, Rafael Machado wrote:

Hi everyone

Since here are the most skilled professions I've seeing I believe 
someone can help me.


I have a Lenovo x230, and I'll would like to install coreboot in it to 
start to understand how it works, and in future start to help the 
community, as soon as I have the knowledge for that.


Last week I did a test that makes my progress stop.

Just for fun, and to check how the commercial bios works, I connected 
a postcard on the wireless slot (as far as I know this is a pcie slot).

I already did that with other notebooks I have and nothing wrong happened.

The problem is that this time, with this x230, after I connected the 
postcard and turned the system on, the system stopped to boot. And the 
post card does not stop at a specific post code.
What happens now, is that every time I turn the system on, the battery 
led blinks 3 times, being two blinks followed by a 1 second stop and 
after that the last blink, and the system reboots.


The post card I'm using is this: 
https://www.ebay.com/itm/3in1-Mini-PCI-E-PCI-LPC-Tester-PC-Desktop-Diagnostic-Post-Card-Error-Code-Test/191862585496?hash=item2cabe6b898:g:x8MAAOSw2x1XKB5E


So my questions are:

-Does someone believe this postcard could have bricked the system? (Why?)
-Any idea about how to solve that?

My next test will be to write a coreboot build at this system using 
buspirate, but since I'll only have time for this next week, I would 
like to have some things to think about, this is why I sent this 
e-mail before doing the coreboot flash test.


Any comment will be helpful.

Thanks and Regards
Rafael R. Machado




-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] New Defects reported by Coverity Scan for coreboot

[scan-admin]

Hi,

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

15 new defect(s) introduced to coreboot found with Coverity Scan.
29 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 15 of 15 defect(s)


** CID 1386126:  Null pointer dereferences  (REVERSE_INULL)
/src/mainboard/siemens/mc_bdx1/mainboard.c: 266 in pca9538_get_dev()



*** CID 1386126:  Null pointer dereferences  (REVERSE_INULL)
/src/mainboard/siemens/mc_bdx1/mainboard.c: 266 in pca9538_get_dev()
260 {
261 struct device *dev = NULL;
262 do {
263 dev = dev_find_path(dev, DEVICE_PATH_I2C);
264 if (dev->path.i2c.device == PCA9538_SLAVE_ADR)
265 break;
>>> CID 1386126:  Null pointer dereferences  (REVERSE_INULL)
>>> Null-checking "dev" suggests that it may be null, but it has already 
>>> been dereferenced on all paths leading to the check.
266 } while (dev);
267 return dev;
268 }
269 
270 
271 BOOT_STATE_INIT_ENTRY(BS_DEV_ENUMERATE, BS_ON_ENTRY, 
wait_for_legacy_dev, NULL);

** CID 1384426:(FORWARD_NULL)
/dev/cb-build/coreboot-coverity.0/PCENGINES_APU5/libagesa/amdlib.c: 492 in 
LibAmdCLFlush()
/dev/cb-build/coreboot-coverity.0/PCENGINES_APU4/libagesa/amdlib.c: 492 in 
LibAmdCLFlush()
/dev/cb-build/coreboot-coverity.0/PCENGINES_APU3/libagesa/amdlib.c: 492 in 
LibAmdCLFlush()
/dev/cb-build/coreboot-coverity.0/ODE_E21XX/libagesa/amdlib.c: 492 in 
LibAmdCLFlush()
/dev/cb-build/coreboot-coverity.0/GOOGLE_GRUNT/libagesa/amdlib.c: 489 in 
LibAmdCLFlush()
/dev/cb-build/coreboot-coverity.0/GOOGLE_KAHLEE/libagesa/amdlib.c: 489 in 
LibAmdCLFlush()
/dev/cb-build/coreboot-coverity.0/AMD_LAMAR/libagesa/amdlib.c: 492 in 
LibAmdCLFlush()
/src/vendorcode/amd/agesa/common/amdlib.c: 444 in LibAmdCLFlush()
/dev/cb-build/coreboot-coverity.0/AMD_BETTONG/libagesa/amdlib.c: 492 in 
LibAmdCLFlush()
/dev/cb-build/coreboot-coverity.0/AMD_DB_FT3B_LC/libagesa/amdlib.c: 492 in 
LibAmdCLFlush()
/dev/cb-build/coreboot-coverity.0/AMD_GARDENIA/libagesa/amdlib.c: 489 in 
LibAmdCLFlush()
/dev/cb-build/coreboot-coverity.0/PCENGINES_APU2/libagesa/amdlib.c: 492 in 
LibAmdCLFlush()
/dev/cb-build/coreboot-coverity.0/AMD_OLIVEHILLPLUS/libagesa/amdlib.c: 492 in 
LibAmdCLFlush()



*** CID 1384426:(FORWARD_NULL)
/dev/cb-build/coreboot-coverity.0/PCENGINES_APU5/libagesa/amdlib.c: 492 in 
LibAmdCLFlush()
486   UINT8  *address32;
487   UINTN  Index;
488   address32 = 0;
489   hwcrSave = SetFsBase (Address);
490   for (Index = 0; Index < Count; Index++){
491 _mm_mfence ();
>>> CID 1384426:(FORWARD_NULL)
>>> Dereferencing null pointer "address32".
492 _mm_clflush_fs ( [Index * 64]);
493   }
494   RestoreHwcr (hwcrSave);
495 }
496 
497 
/dev/cb-build/coreboot-coverity.0/PCENGINES_APU4/libagesa/amdlib.c: 492 in 
LibAmdCLFlush()
486   UINT8  *address32;
487   UINTN  Index;
488   address32 = 0;
489   hwcrSave = SetFsBase (Address);
490   for (Index = 0; Index < Count; Index++){
491 _mm_mfence ();
>>> CID 1384426:(FORWARD_NULL)
>>> Dereferencing null pointer "address32".
492 _mm_clflush_fs ( [Index * 64]);
493   }
494   RestoreHwcr (hwcrSave);
495 }
496 
497 
/dev/cb-build/coreboot-coverity.0/PCENGINES_APU3/libagesa/amdlib.c: 492 in 
LibAmdCLFlush()
486   UINT8  *address32;
487   UINTN  Index;
488   address32 = 0;
489   hwcrSave = SetFsBase (Address);
490   for (Index = 0; Index < Count; Index++){
491 _mm_mfence ();
>>> CID 1384426:(FORWARD_NULL)
>>> Dereferencing null pointer "address32".
492 _mm_clflush_fs ( [Index * 64]);
493   }
494   RestoreHwcr (hwcrSave);
495 }
496 
497 
/dev/cb-build/coreboot-coverity.0/ODE_E21XX/libagesa/amdlib.c: 492 in 
LibAmdCLFlush()
486   UINT8  *address32;
487   UINTN  Index;
488   address32 = 0;
489   hwcrSave = SetFsBase (Address);
490   for (Index = 0; Index < Count; Index++){
491 _mm_mfence ();
>>> CID 1384426:(FORWARD_NULL)
>>> Dereferencing null pointer "address32".
492 _mm_clflush_fs ( [Index * 64]);
493   }
494   RestoreHwcr (hwcrSave);
495 }
496 
497 
/dev/cb-build/coreboot-coverity.0/GOOGLE_GRUNT/libagesa/amdlib.c: 489 in 
LibAmdCLFlush()
483   UINT8  *address32;
484   UINTN  Index;
485   address32 = 0;
486   hwcrSave = SetFsBase (Address);
487   for (Index = 0; Index < Count; Index++){
488 _mm_mfence ();
>>> CID 1384426:(FORWARD_NULL)
>>> 

[coreboot] Postcode at Lenovo x230

[Rafael Machado]

Hi everyone

Since here are the most skilled professions I've seeing I believe someone
can help me.

I have a Lenovo x230, and I'll would like to install coreboot in it to
start to understand how it works, and in future start to help the
community, as soon as I have the knowledge for that.

Last week I did a test that makes my progress stop.

Just for fun, and to check how the commercial bios works, I connected a
postcard on the wireless slot (as far as I know this is a pcie slot).
I already did that with other notebooks I have and nothing wrong happened.

The problem is that this time, with this x230, after I connected the
postcard and turned the system on, the system stopped to boot. And the post
card does not stop at a specific post code.
What happens now, is that every time I turn the system on, the battery led
blinks 3 times, being two blinks followed by a 1 second stop and after that
the last blink, and the system reboots.

The post card I'm using is this:
https://www.ebay.com/itm/3in1-Mini-PCI-E-PCI-LPC-Tester-PC-Desktop-Diagnostic-Post-Card-Error-Code-Test/191862585496?hash=item2cabe6b898:g:x8MAAOSw2x1XKB5E

So my questions are:

-Does someone believe this postcard could have bricked the system? (Why?)
-Any idea about how to solve that?

My next test will be to write a coreboot build at this system using
buspirate, but since I'll only have time for this next week, I would like
to have some things to think about, this is why I sent this e-mail before
doing the coreboot flash test.

Any comment will be helpful.

Thanks and Regards
Rafael R. Machado
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot