Re: [coreboot] Please upload board status Asus AM1I-A

[Gergely Kiss]

Hi Paul, hi Eli,

looks like I missed this thread, sorry about the late answer.

Thanks, Eli for taking care of Paul's request!

Regards,
Gergely

On 12 February 2018 at 11:55, Elisenda Cuadros  wrote:

> Dear Paul,
>
> Sure, I will be happy to do it :-)
>
> Best Regards,
>
> Eli
>
> On 12/02/2018 9:47, Paul Menzel wrote:
>
> Dear Gergely, dear Elisenda,
>
>
> Welcome to coreboot and thank you for making and using the port for the
> Asus AM1I-A.
>
> Could one of you, please upload the current status to the board status
> repository? See the file `README` in `util/board_status/`.
>
> Please make sure, that you build from a non-dirty coreboot commit, that
> means, the output from `git describe --dirty` should not contain the
> word *dirty*.
>
>
> Thanks,
>
> Paul
>
>
>
>
> --
> 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] Asus AM1I-A

[Gergely Kiss]

Seems like there's little information publicly available about the AM1
platform. As you can see here [1] there's plenty of information available
for the Bolton FCH which is used in newer APUs, while the Hudson FCH is
basically undocumented.

The BKDG for the Kabini platform [2] mentions two registers ("D0F0x98_x26
ORB IOMMU Control 0" and "D0F0x98_x27 ORB IOMMU Control 1") which suggests
the platform has an IOMMU.

A reddit thread [3] quotes a customer service response from AMD which
confirms the platform has an IOMMU but the ability to use it depends on the
mainboard being used:

"Yes the processor AMD AM1 5350 supports PCI Pass through via AMD-Vi/IOMMU.
However, we request you to contact the motherboard manufacturer and check
if the Motherboard and Chipset support IOMMU."

Maybe the best way to see this is to try virtualizing some hardware?

Regards,
Gergely

[1] https://developer.amd.com/resources/developer-guides-manuals/
[2] http://support.amd.com/TechDocs/48751_16h_bkdg.pdf
[3]
https://www.reddit.com/r/homelab/comments/4j5zf8/amd_apu_a1_5350_proxmox_ve/


On 14 February 2018 at 00:20, taii...@gmx.com  wrote:

> Has anyone figured out if the AM1 platform has IOMMU? the OEM bios on the
> AM1ML has an option for it but it doesn't work.
>
> The lack of that is really disappointing.
>
> I am also unable to locate the spec sheets for the AM1 platform that would
> confirm this.
>
> --
> 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] Asus AM1I-A

[taii...@gmx.com]

Has anyone figured out if the AM1 platform has IOMMU? the OEM bios on 
the AM1ML has an option for it but it doesn't work.


The lack of that is really disappointing.

I am also unable to locate the spec sheets for the AM1 platform that 
would confirm this.


--
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.

2 new defect(s) introduced to coreboot found with Coverity Scan.


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


** CID 1385944:  Null pointer dereferences  (NULL_RETURNS)



*** CID 1385944:  Null pointer dereferences  (NULL_RETURNS)
/src/drivers/generic/adau7002/adau7002.c: 36 in adau7002_fill_ssdt()
30 static void adau7002_fill_ssdt(struct device *dev)
31 {
32  if (!dev->enabled)
33  return;
34 
35  /* Device */
>>> CID 1385944:  Null pointer dereferences  (NULL_RETURNS)
>>> Dereferencing a pointer that might be null "acpi_device_scope(dev)" 
>>> when calling "acpigen_write_scope".
36  acpigen_write_scope(acpi_device_scope(dev));
37  acpigen_write_device(acpi_device_name(dev));
38  acpigen_write_name_string("_HID", ADAU7002_ACPI_HID);
39  acpigen_write_name_integer("_UID", 0);
40  acpigen_write_name_string("_DDN", dev->chip_ops->name);
41  acpigen_write_STA(ACPI_STATUS_DEVICE_ALL_ON);

** CID 1385943:  Error handling issues  (CHECKED_RETURN)
/src/soc/amd/common/block/s3/s3_resume.c: 30 in get_s3nv_info()



*** CID 1385943:  Error handling issues  (CHECKED_RETURN)
/src/soc/amd/common/block/s3/s3_resume.c: 30 in get_s3nv_info()
24 #define DEFAULT_MRC_VERSION 0
25 
26 void get_s3nv_info(void **base, size_t *size)
27 {
28  struct region_device rdev;
29 
>>> CID 1385943:  Error handling issues  (CHECKED_RETURN)
>>> Calling "mrc_cache_get_current" without checking return value (as is 
>>> done elsewhere 6 out of 7 times).
30  mrc_cache_get_current(MRC_TRAINING_DATA, DEFAULT_MRC_VERSION, );
31  *base = rdev_mmap_full();
32  *size = region_device_sz();
33  if (!*base || !*size)
34  printk(BIOS_ERR, "Error: S3 NV data not found\n");
35  else



To view the defects in Coverity Scan visit, 
https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbLuoVetFLSjdonCi1EjfHRqWGQvojmmkYaBE-2BPJiTQvQ-3D-3D_q4bX76XMySz3BXBlWr5fXXJ4cvAsgEXEqC7dBPM7O5as2qtTD-2BnoixG71pS-2FVfGTkZkMmiFMbKzAzAYLYNWUQeAj52qoGMxBF4O-2BR8Kt-2F-2F5cIBYgw9JJtBVKPZL9xQSstzwk2CTW2QvuTgz0bhqIQIxtTyZeZ9eyeGeUCr8YwJwTl8ItqSaKQd9llo19F9yOmIXyChyw4W4Wj55anXSAtwO46jUtJdfcRnniN1Dcal0-3D


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

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

[Paul Kocialkowski]

Hi,

Le vendredi 09 février 2018 à 14:33 -0500, Youness Alaoui a écrit :
> On Tue, Feb 6, 2018 at 4:41 AM, Mike Banon 
> wrote:
> > 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)
> 
> There will probably be some things in common. I don't know how much
> of
> ec-1.75 is good enough to be reused though, or if it's maintainable,
> etc.. but yes, it could be a good starting point.

There is indeed a lot in common with that code, but the code itself is
not structured and organized at all so reusing the codebase makes very
little sense. I mostly use this code for reference and it has already
proven useful (e.g. for special trickery that has to be implemented
when going to low power mode).

> > @ 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/projec
> > t:flashrom

Note that the patches have been merged at this point, so ENE EDI
support in flashrom is now ready. I am also wondering about using
libflashrom to write an EDI debugger (since, after all, EDI has access
to the whole external memory).

> > 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
> 
> 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.

> > 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!

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 :
> > >