Re: [coreboot] ThinkPad W520 support

[taii...@gmx.com]

On 02/05/2018 04:20 PM, Evgeny wrote:

This is really great news, thank you!

Do you have any plans to support W530? I would be happy to help in any
way I can. I have the W530, the flashing hardware and (I think) the
debugging hardware (just need to figure out how to turn my Raspberry Pi
into EHCI debug dongle).

For the search-engineable record the W520 can support ivy bridge CPU's 
via coreboot in case anyone wants to know what to buy.


I suggest obtaining a USB CH341A for easier flashes, I have heard the 
RPI has a cumbersome flashing process (and it has shady closed source 
firmware)


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

[coreboot] QEMU x86_64 Q35 Automated Test Failure [master]

[Raptor Engineering Automated Coreboot Test Stand]

The QEMU x86_64 Q35 fails verification for branch master as of commit 
485c0ad0783aa168feab8944e498a393774512fd

The following tests failed:
BOOT_FAILURE

Commits since last successful test:
485c0ad0 inteltool: Add Cougar- and Pantherpoint PCH PCI IDs for SPI
921fa84 inteltool: Fix displaying 64bit spi registers
ad28259 mb/google/kahlee: Fix grunt I2C rise/fall times
f9d9781 soc/intel/appololake: Remove dead MPINIT code selection
4004081 cpu/intel/haswell: Don't select PARALLEL_CPU_INIT

<5 commits skipped>

75f5d99 mb/asus/m2v-mx_se: Add `cmos.default`
25874b8 mb/google/eve: Enable HotPlug on PCIe root port for WiFi
74ea48e soc/intel/skylake: Add devicetree variable for PCIe HotPlug
f5e3775 google/kahlee: Initialize non-early i2c buses in mainboard_init
e0ea982 soc/amd/stoneyridge: Add API to initialize non-early_init i2c buses

See attached log for details

This message was automatically generated from Raptor Engineering's QEMU x86_64 
Q35 test stand
Want to test on your own equipment?  Check out 
https://www.raptorengineering.com/content/REACTS/intro.html

Raptor Engineering also offers coreboot consulting services!  Please visit 
https://www.raptorengineering.com for more information

Please contact Timothy Pearson at Raptor Engineering 
 regarding any issues stemming from this 
notification


1517934712-1-automaster.log.bz2
Description: application/bzip2
-- 
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.

7 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 7 of 7 defect(s)


** CID 1385770:  Memory - corruptions  (OVERRUN)
/3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/pmu/pmu.c: 629 in 
rockchip_soc_cores_pwr_dm_on()



*** CID 1385770:  Memory - corruptions  (OVERRUN)
/3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/pmu/pmu.c: 629 in 
rockchip_soc_cores_pwr_dm_on()
623 int rockchip_soc_cores_pwr_dm_on(unsigned long mpidr, uint64_t 
entrypoint)
624 {
625 uint32_t cpu_id = plat_core_pos_by_mpidr(mpidr);
626 
627 assert(cpu_id < PLATFORM_CORE_COUNT);
628 assert(cpuson_flags[cpu_id] == 0);
>>> CID 1385770:  Memory - corruptions  (OVERRUN)
>>> Overrunning array "cpuson_flags" of 6 4-byte elements at element index 
>>> 4294967295 (byte offset 17179869180) using index "cpu_id" (which evaluates 
>>> to 4294967295).
629 cpuson_flags[cpu_id] = PMU_CPU_HOTPLUG;
630 cpuson_entry_point[cpu_id] = entrypoint;
631 dsb();
632 
633 cpus_power_domain_on(cpu_id);
634 

** CID 1385769:  Memory - corruptions  (OVERRUN)
/3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/pmu/pmu.c: 630 in 
rockchip_soc_cores_pwr_dm_on()



*** CID 1385769:  Memory - corruptions  (OVERRUN)
/3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/pmu/pmu.c: 630 in 
rockchip_soc_cores_pwr_dm_on()
624 {
625 uint32_t cpu_id = plat_core_pos_by_mpidr(mpidr);
626 
627 assert(cpu_id < PLATFORM_CORE_COUNT);
628 assert(cpuson_flags[cpu_id] == 0);
629 cpuson_flags[cpu_id] = PMU_CPU_HOTPLUG;
>>> CID 1385769:  Memory - corruptions  (OVERRUN)
>>> Overrunning array "cpuson_entry_point" of 6 8-byte elements at element 
>>> index 4294967295 (byte offset 34359738360) using index "cpu_id" (which 
>>> evaluates to 4294967295).
630 cpuson_entry_point[cpu_id] = entrypoint;
631 dsb();
632 
633 cpus_power_domain_on(cpu_id);
634 
635 return PSCI_E_SUCCESS;

** CID 1385768:  Code maintainability issues  (UNUSED_VALUE)
/3rdparty/arm-trusted-firmware/drivers/arm/gic/v3/arm_gicv3_common.c: 40 in 
arm_gicv3_distif_pre_save()



*** CID 1385768:  Code maintainability issues  (UNUSED_VALUE)
/3rdparty/arm-trusted-firmware/drivers/arm/gic/v3/arm_gicv3_common.c: 40 in 
arm_gicv3_distif_pre_save()
34  /*
35   * The GICR_WAKER.Sleep bit should be set only when both
36   * GICR_WAKER.ChildrenAsleep and GICR_WAKER.ProcessorSleep are set on
37   * all the Redistributors.
38   */
39  for (unsigned int i = 0; i < gicv3_driver_data->rdistif_num; i++) {
>>> CID 1385768:  Code maintainability issues  (UNUSED_VALUE)
>>> Assigning value from "gicv3_driver_data->rdistif_base_addrs[i]" to 
>>> "gicr_base" here, but that stored value is overwritten before it can be 
>>> used.
40  gicr_base = gicv3_driver_data->rdistif_base_addrs[i];
41  assert(gicr_base);
42  assert(gicr_read_waker(gicr_base) & WAKER_CA_BIT);
43  assert(gicr_read_waker(gicr_base) & WAKER_PS_BIT);
44  }
45 

** CID 1385767:  Memory - corruptions  (OVERRUN)



*** CID 1385767:  Memory - corruptions  (OVERRUN)
/3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/pmu/pmu.c: 633 in 
rockchip_soc_cores_pwr_dm_on()
627 assert(cpu_id < PLATFORM_CORE_COUNT);
628 assert(cpuson_flags[cpu_id] == 0);
629 cpuson_flags[cpu_id] = PMU_CPU_HOTPLUG;
630 cpuson_entry_point[cpu_id] = entrypoint;
631 dsb();
632 
>>> CID 1385767:  Memory - corruptions  (OVERRUN)
>>> Overrunning callee's array of size 6 by passing argument "cpu_id" 
>>> (which evaluates to 4294967295) in call to "cpus_power_domain_on".
633 cpus_power_domain_on(cpu_id);
634 
635 return PSCI_E_SUCCESS;
636 }
637 
638 int rockchip_soc_cores_pwr_dm_off(void)

** CID 1385766:  Memory - corruptions  (NEGATIVE_RETURNS)
/3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/pmu/pmu.c: 629 in 
rockchip_soc_cores_pwr_dm_on()



*** CID 

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

[Mike Banon]

Thank you very much for telling about EC-1.75 project!
http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A1
Maybe some of its' elements could be borrowed for Origami
if the hardware is similar? (haven't compared the datasheets)

@ Youness and Marty :

Proprietary firmware of KB9012 explicitly disables EDI - ENE Debug Interface
(the protocol used to access the internal memory of KB9012) unless pin
42 is grounded
_before_ powering the KB9012 controller ! Maybe its the same with your
another KB ?
If you ground that pin (not necessarily 42, your KB's pin number could
be different)
to put your EC into debug mode, maybe then you could successfully
read/write it ?

Here is the full description of my successful KB9012 hardware flashing setup
through the keyboard port using a flex cable with soldered wires: 0.5mm pitch
makes it hard to solder directly to keyboard port, and also I like
flex cable solution
because its much faster to remove/insert a cable than to
solder/desolder the wires

http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate

^^^ Had to unite three grounds ( programmer's, mainboard's and KB9012's 42 pin )
to make it work

Currently we are actively working on the inclusion of KB9012 flashing support
to the official flashrom - but its already possible via the unofficial patches.
Changes 23258 - 23263 at the https://review.coreboot.org/#/q/project:flashrom

I haven't compared the datasheets of KB9012 and your KB, so I don't know
if they are using exactly the same debug interface or it is slightly different
(please check if there are differences, maybe you'll have to write some code)

I trust hardware flashing more than the software, especially your
current AMI BIOS setup
which isn't free software. Maybe the direct hardware flashing is also
possible for you

Latest status update for Origami-EC firmware:
https://www.mail-archive.com/coreboot@coreboot.org/msg50646.html

Best regards,
Mike Banon

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-A1
>
> 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 devices, as well as some purism
>> devices, and I was hoping someone in the list would have some contacts
>> with those guys so as to be able to use their ec firmware as a bit of a
>> reference design, but the OLPC ec firmware repo has a 'private'
>> submodule which I cannot access and I simply cannot find a repo for the
>> purism ec firmware to reference.
>>
>> Any assistance you could provide on this matter would be greatly
>> appreciated.
>>
>> Marty E. Plummer
>>
>> --
>> 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

--