[coreboot] Re: ASUS A88XM-E internal flashing

[Balázs Vinarz]

The factory BIOS is write protected with that efi module. To have an
unrestricted factory firmware, your options are:
- dump the chip, remove the module and reflash the content
- remove the module from the image you want to flash, and flash it with EZflash
This module exists in the factory BIOS for the A88XM-E from the very
beginning, and was introduced to F2A85-M in a later release.
For more information please refer to:
https://doc.coreboot.org/mainboard/asus/f2a85-m.html#internal-programming

Regards

Mike Banon  ezt írta (időpont: 2020. okt. 16., P, 19:02):
>
> maybe Balazs could advise. However, to make sure you could easily
> unbrick your A88XM-E in the case of a bad coreboot build, I really
> recommend you to order a cheap USB CH341A programmer (preferably with
> a Green PCB) - and PLCC clip to easily remove a DIP8 flash chip from a
> motherboard's socket without bending the chip's legs. Then, you'll be
> able to easily install a new coreboot image by plugging a DIP8 flash
> chip into the programmer's socket and using the opensource flashrom
> tool.
>
> On Fri, Oct 16, 2020 at 10:04 AM mejim67741--- via coreboot
>  wrote:
> >
> > The documentation says
> >
> > The main SPI flash can be accessed using flashrom, if the AmdSpiRomProtect 
> > modules have been deleted in the factory image previously.
> >
> > So what does that mean? How can i do that? I would like to flash it internal
> > ___
> > coreboot mailing list -- coreboot@coreboot.org
> > To 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: ASUS A88XM-E internal flashing

[Marshall Dawson]

>
> if the AmdSpiRomProtect modules have been deleted in the factory image
> previously.
> So what does that mean? How can i do that? I would like to flash it
> internal


I don't recognize the "AmdSpiRomProtect modules".  My top guess, though, is
it's referring to something that would program the RomProtect registers at
D14F3x050, 54, etc.  These are write-once and require a reset to unprotect
the regions.

Thanks,
Marshall


On Fri, Oct 16, 2020 at 11:03 AM Mike Banon  wrote:

> maybe Balazs could advise. However, to make sure you could easily
> unbrick your A88XM-E in the case of a bad coreboot build, I really
> recommend you to order a cheap USB CH341A programmer (preferably with
> a Green PCB) - and PLCC clip to easily remove a DIP8 flash chip from a
> motherboard's socket without bending the chip's legs. Then, you'll be
> able to easily install a new coreboot image by plugging a DIP8 flash
> chip into the programmer's socket and using the opensource flashrom
> tool.
>
> On Fri, Oct 16, 2020 at 10:04 AM mejim67741--- via coreboot
>  wrote:
> >
> > The documentation says
> >
> > The main SPI flash can be accessed using flashrom, if the
> AmdSpiRomProtect modules have been deleted in the factory image previously.
> >
> > So what does that mean? How can i do that? I would like to flash it
> internal
> > ___
> > coreboot mailing list -- coreboot@coreboot.org
> > To 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 mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: ASUS A88XM-E internal flashing

[Mike Banon]

maybe Balazs could advise. However, to make sure you could easily
unbrick your A88XM-E in the case of a bad coreboot build, I really
recommend you to order a cheap USB CH341A programmer (preferably with
a Green PCB) - and PLCC clip to easily remove a DIP8 flash chip from a
motherboard's socket without bending the chip's legs. Then, you'll be
able to easily install a new coreboot image by plugging a DIP8 flash
chip into the programmer's socket and using the opensource flashrom
tool.

On Fri, Oct 16, 2020 at 10:04 AM mejim67741--- via coreboot
 wrote:
>
> The documentation says
>
> The main SPI flash can be accessed using flashrom, if the AmdSpiRomProtect 
> modules have been deleted in the factory image previously.
>
> So what does that mean? How can i do that? I would like to flash it internal
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To 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: How to debug open-source AGESA with serial console?

[Peter Stuge]

Michal Zygowski wrote:
> I don't think it is necessary to port IDS to Kconfig.

I have an old branch where I started doing just that. I think I
posted some patches but there was no traction. At that time I think
it was still uncertain if we would ever receive any AGESA support
from AMD, so there was some reluctance to change the AGESA source.

I think it would still make sense, but it's not a trivial exercise. :\


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

[coreboot] Re: General fan question

[Michal Zygowski]

Of course it is reachable. Here's the license:
https://www.coreboot.org/Logo#coreboot_Logo_License

On 16.10.2020 17:46, Peter Stuge wrote:
> Vegetable Lasagna via coreboot wrote:
>> I really want to show my fan for you so if you have some stickers
>> for my laptop so I could brag it :) that will do my day.
> When the coreboot.org wiki was online it was possible to download the
> logo files and see the logo license terms.
>
> That way, you could order some stickers yourself. I don't know if
> that wiki page is still reachable somehow. I couldn't find it on
> coreboot.org. Does anyone know?
>
>
> Thanks
>
> //Peter
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: General fan question

[Peter Stuge]

Vegetable Lasagna via coreboot wrote:
> I really want to show my fan for you so if you have some stickers
> for my laptop so I could brag it :) that will do my day.

When the coreboot.org wiki was online it was possible to download the
logo files and see the logo license terms.

That way, you could order some stickers yourself. I don't know if
that wiki page is still reachable somehow. I couldn't find it on
coreboot.org. Does anyone know?


Thanks

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

[coreboot] Re: AMD AGESA: Missing PCI bridge 00:15.2 on Asus F2A85-M PRO

[Paul Menzel]

Dear Peter, dear Michal,


Am 16.10.20 um 15:22 schrieb Michal Zygowski:


..

PCI: 00:15.0 init
PCI: 00:15.0 init finished in 0 msecs
PCI: 00:15.1 init
PCI: 00:15.1 init finished in 0 msecs
PCI: 00:18.1 init
PCI: 00:18.1 init finished in 0 msecs

Note that there is no init for 15.2 above. I don't know why, if it's
enabled in the mainboard devicetree file.



15.2 is a PCIe root port, so it is natural that there is no init for it,
if the endpoint device isn't detected. There won't be PCIe root port
because AGESA hides it, if endpoint is not detected.


Do you know, what AGESA code does that?


Another thought - have you compared PCI bus numbers and addresses
between vendor BIOS and coreboot? They can change around, certainly
bus numbers but wasn't there a thread a while back with addresses
being confused too?



This is another thing that can be customized. Each mainboard has an
OemCustomize.c file which defines an array of type
PCIe_PORT_DESCRIPTOR., the 3rd (and 4th on some families) parameter in
PCIE_PORT_DATA_INITIALIZER indicate the device number that will be
assigned to the PCIe engines (lanes). So you can freely route the ports
to device numbers.


But isn’t that just for the lanes of CPU/northbridge devices (numbered 
below 00:10.x)?


The bridge 15.2 should be part of the Fusion Controller Hub (FCH), and 
the for PCIe general purpose lanes (GPP) can be configured there with 
`FchGpp->GppLinkConfig`.


I reference the Bolton FCH datasheets [1][2], as I couldn’t find one for 
A85X (Hudson-3) specifically.


The AGESA vendor code has `PreInitGppLink()` in 
`src/vendorcode/amd/agesa/f15tn/Proc/Fch/Pcie/GppPortInit.c` [3].


I haven’t found out yet, how to figure the lane configuration out from 
the board without schematics or the vendor firmware. I’d assume 
PortA2B1C1 or PortA2B1C1. Hardcoding them, some hang the system, but I 
forgot the two working ones.


I have to further study and analyze that code. Hints are very much 
appreciated.



Kind regards,

Paul


[1]: 
https://www.amd.com/system/files/TechDocs/51205_Bolton_FCH_BIOS_Dev_Guide.pdf

[2]: https://www.amd.com/system/files/TechDocs/51191_Bolton_FCH_RPR.pdf
[3]: 
https://review.coreboot.org/plugins/gitiles/coreboot/+/6147314344ae257081ec91dd709b18da283878fc/src/vendorcode/amd/agesa/f15tn/Proc/Fch/Pcie/GppPortInit.c#160

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

[coreboot] Re: AMD AGESA: Missing PCI bridge 00:15.2 on Asus F2A85-M PRO

[Peter Stuge]

Christian Walter wrote:
> if we are sure it is behind 15.2 - one can also try to make it hidden.

Sounds like that's worth a try. How to do that?


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

[coreboot] Re: AMD AGESA: Missing PCI bridge 00:15.2 on Asus F2A85-M PRO

[Michal Zygowski]

Hi Peter,
> ..
>> PCI: 00:15.0 init
>> PCI: 00:15.0 init finished in 0 msecs
>> PCI: 00:15.1 init
>> PCI: 00:15.1 init finished in 0 msecs
>> PCI: 00:18.1 init
>> PCI: 00:18.1 init finished in 0 msecs
> Note that there is no init for 15.2 above. I don't know why, if it's
> enabled in the mainboard devicetree file.
15.2 is a PCIe root port, so it is natural that there is no init for it,
if the endpoint device isn't detected. There won't be PCIe root port
because AGESA hides it, if endpoint is not detected.
> Another thought - have you compared PCI bus numbers and addresses
> between vendor BIOS and coreboot? They can change around, certainly
> bus numbers but wasn't there a thread a while back with addresses
> being confused too?
This is another thing that can be customized. Each mainboard has an
OemCustomize.c file which defines an array of type
PCIe_PORT_DESCRIPTOR., the 3rd (and 4th on some families) parameter in
PCIE_PORT_DATA_INITIALIZER indicate the device number that will be
assigned to the PCIe engines (lanes). So you can freely route the ports
to device numbers.
> Sorry I can't suggest anything more concrete
>
> //Peter
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

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

[coreboot] Re: AMD AGESA: Missing PCI bridge 00:15.2 on Asus F2A85-M PRO

[Christian Walter]

Hi,

if we are sure it is behind 15.2 - one can also try to make it hidden.
This way the device will be enabled no matter what. If that solves the
problem - you need to investigate why coreboot does not enable the device.

Best,

Chris

On 10/16/20 3:05 PM, Peter Stuge wrote:
> Paul Menzel wrote:
>> With the vendor firmware 6601, it is
>>
>>  04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
>> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] 
>> (rev 09)
>>
>> behind PCI bridge 00:15.2.
> ..
>> In the current state [1], coreboot says device 00:15.2 is disabled
>>
>>> Show all devs... After init.
> ..
>>> PCI: 00:15.0: enabled 1
>>> PCI: 00:15.1: enabled 1
>>> PCI: 00:15.2: enabled 0
>> But it is enabled in the devicetree 
>> `src/mainboard/asus/f2a85-m/devicetree_f2a85-m_pro.cb`.
>>
>>  device pci 15.2 on end # PCI bridge
>> spew log
> ..
>> Enabling cache
>> Setting up local APIC...
>>  apic_id: 0x11 done.
>> siblings = 01, CPU #1 initialized
>> All AP CPUs stopped (1060 loops)
>> CPU0: stack: 0x5fef4000 - 0x5fef5000, lowest used address 0x5fef455c, stack 
>> used: 2724 bytes
>> CPU1: stack: 0x5fef3000 - 0x5fef4000, lowest used address 0x5fef3dbc, stack 
>> used: 580 bytes
>> CPU_CLUSTER: 0 init finished in 64 msecs
>> PCI: 00:00.0 init
>> PCI: 00:00.0 init finished in 0 msecs
> ..
>> PCI: 00:15.0 init
>> PCI: 00:15.0 init finished in 0 msecs
>> PCI: 00:15.1 init
>> PCI: 00:15.1 init finished in 0 msecs
>> PCI: 00:18.1 init
>> PCI: 00:18.1 init finished in 0 msecs
> Note that there is no init for 15.2 above. I don't know why, if it's
> enabled in the mainboard devicetree file.
>
>
> Another thought - have you compared PCI bus numbers and addresses
> between vendor BIOS and coreboot? They can change around, certainly
> bus numbers but wasn't there a thread a while back with addresses
> being confused too?
>
>
> Sorry I can't suggest anything more concrete
>
> //Peter
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
-- 
*Christian Walter*
*Head of Firmware Development / Cyber Security *



9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email:  christian.wal...@9elements.com
Phone:  _+49 234 68 94 188 _
Mobile:  _+49 176 70845047 _

Sitz der Gesellschaft: Bochum
Handelsregister: Amtsgericht Bochum, HRB 17519
Geschäftsführung: Sebastian Deutsch, Eray Basar

Datenschutzhinweise nach Art. 13 DSGVO 
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Flashing coreboot and Intel Flash Descriptor Erase Issue

[Peter Stuge]

Balaji Sivakumar wrote:
> Am working on adding a feature to upgrading the BIOS (complete
> IFD+ME+Coreboot) using intel-spi driver at the OS level. Able to
> successfully take the backup full 16MB spi nor flash data which
> includes IFD+ME+BIOS using flashrom Internal Programmer option and
> it is identified as Opaque flash chip and using dd command as well.

I believe identified as "Opaque flash chip" means that no positive
identification was possible - this means that flashrom is not able to
perform all the SPI commands it needs using this programmer method
(internal) on this system.

I added a warning message to the flashrom output many years ago when
a flash chip could not be positively identified, which said that
erase and quite possibly also write can never work unless the chip is
correctly identified.


> But we are seeing the erase fail through both flashrom and flash_erase
> utility. I believe it fails to erase at the flash descriptor location.
> 
> As far as Read/Write access to the SPI regions, I have enabled the Host CPU
> BIOS write access and ME Master Access as 0x through Intel FIT Tool but
> still not able to erase it and it fails.
> 
> Is there anything that could be preventing to enable read/write access to
> the Intel flash descriptor or any SOC SPI controller protection to access
> the Flash descriptor?

I guess that since you work on a platform with ME hardware it is not
intended to allow what you want to do.

As a first step you could try erasing the BIOS flash region, but I
don't think that can work until flashrom successfully identifies the
actual flash chip you are using. How to get there is unclear, but do
run flashrom with verbose output and see if the OPMENU contains the
SPI commands needed to identify, erase and write. I guess it might not.


//Peter
___
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.

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


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


** CID 1433626:  Insecure data handling  (TAINTED_SCALAR)
/src/lib/cbfs.c: 328 in cbfs_prog_stage_load()



*** CID 1433626:  Insecure data handling  (TAINTED_SCALAR)
/src/lib/cbfs.c: 328 in cbfs_prog_stage_load()
322 fsize = cbfs_stage_load_and_decompress(fh, foffset, fsize, load,
323  stage.memlen, 
stage.compression);
324 if (!fsize)
325 return -1;
326 
327 /* Clear area not covered by file. */
>>> CID 1433626:  Insecure data handling  (TAINTED_SCALAR)
>>> Passing tainted variable "stage.memlen - fsize" to a tainted sink. 
>>> [Note: The source code implementation of the function has been overridden 
>>> by a builtin model.]
328 memset([fsize], 0, stage.memlen - fsize);
329 
330 prog_segment_loaded((uintptr_t)load, stage.memlen, SEG_FINAL);
331 
332 out:
333 prog_set_area(pstage, load, stage.memlen);

** CID 1432270:  Parse warnings  (PARSE_ERROR)
/3rdparty/arm-trusted-firmware/include/lib/libc/stdint.h: 93 in ()



*** CID 1432270:  Parse warnings  (PARSE_ERROR)
/3rdparty/arm-trusted-firmware/include/lib/libc/stdint.h: 93 in ()
87 #define INTMAX_C(x)  x ## LL
88 #define UINTMAX_C(x) x ## ULL
89 
90 typedef signed char int8_t;
91 typedef short int16_t;
92 typedef int int32_t;
>>> CID 1432270:  Parse warnings  (PARSE_ERROR)
>>> invalid redeclaration of type name "int64_t" (declared at line 1413 of 
>>> "/home/coreboot/node-root/workspace/coreboot-coverity/cov-int/emit/9bbe52bbb28b/config/29ec7ea376092a30b16589a913b3478c/gcc-config-0/coverity-compiler-compat.h")
93 typedef long long int64_t;
94 
95 typedef unsigned char uint8_t;
96 typedef unsigned short uint16_t;
97 typedef unsigned int uint32_t;
98 typedef unsigned long long uint64_t;

** CID 1429983:  Control flow issues  (DEADCODE)
/src/drivers/uart/acpi/acpi.c: 104 in uart_acpi_fill_ssdt()



*** CID 1429983:  Control flow issues  (DEADCODE)
/src/drivers/uart/acpi/acpi.c: 104 in uart_acpi_fill_ssdt()
98  reset_gpio_index >= 0 || enable_gpio_index >= 0) {
99  struct acpi_dp *dsd = acpi_dp_new_table("_DSD");
100 if (config->compat_string)
101 acpi_dp_add_string(dsd, "compatible",
102config->compat_string);
103 if (irq_gpio_index >= 0)
>>> CID 1429983:  Control flow issues  (DEADCODE)
>>> Execution cannot reach this statement: "acpi_dp_add_gpio(dsd, "irq-...".
104 acpi_dp_add_gpio(dsd, "irq-gpios", path,
105  irq_gpio_index, 0,
106  config->irq_gpio.active_low);
107 if (reset_gpio_index >= 0)
108 acpi_dp_add_gpio(dsd, "reset-gpios", path,
109  reset_gpio_index, 0,

** CID 1429781:  Integer handling issues  (CONSTANT_EXPRESSION_RESULT)
/src/cpu/x86/mtrr/earlymtrr.c: 108 in var_mtrr_set_with_cb()



*** CID 1429781:  Integer handling issues  (CONSTANT_EXPRESSION_RESULT)
/src/cpu/x86/mtrr/earlymtrr.c: 108 in var_mtrr_set_with_cb()
102min base bit set and maximum size bit set. */
103 if (addr_lsb > size_msb)
104 mtrr_size = 1 << size_msb;
105 else
106 mtrr_size = 1 << addr_lsb;
107 
>>> CID 1429781:  Integer handling issues  (CONSTANT_EXPRESSION_RESULT)
>>> "(uint64_t)addr >> 32" is 0 regardless of the values of its operands. 
>>> This occurs as the operand of assignment.
108 base.hi = (uint64_t)addr >> 32;
109 base.lo = addr | type;
110 mask.hi = ctx->upper_mask;
111 mask.lo = ~(mtrr_size - 1) | MTRR_PHYS_MASK_VALID;
112 callback(ctx, addr, mtrr_size, base, mask);
113 ctx->used_var_mtrrs++;

** CID 1429778:  Integer handling issues  (BAD_SHIFT)
/src/cpu/x86/mtrr/earlymtrr.c: 108 in var_mtrr_set_with_cb()

[coreboot] Re: AMD AGESA: Missing PCI bridge 00:15.2 on Asus F2A85-M PRO

[Peter Stuge]

Paul Menzel wrote:
> With the vendor firmware 6601, it is
> 
>  04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] 
> (rev 09)
> 
> behind PCI bridge 00:15.2.
..
> In the current state [1], coreboot says device 00:15.2 is disabled
> 
> > Show all devs... After init.
..
> > PCI: 00:15.0: enabled 1
> > PCI: 00:15.1: enabled 1
> > PCI: 00:15.2: enabled 0

> But it is enabled in the devicetree 
> `src/mainboard/asus/f2a85-m/devicetree_f2a85-m_pro.cb`.
> 
>  device pci 15.2 on end # PCI bridge

> spew log
..
> Enabling cache
> Setting up local APIC...
>  apic_id: 0x11 done.
> siblings = 01, CPU #1 initialized
> All AP CPUs stopped (1060 loops)
> CPU0: stack: 0x5fef4000 - 0x5fef5000, lowest used address 0x5fef455c, stack 
> used: 2724 bytes
> CPU1: stack: 0x5fef3000 - 0x5fef4000, lowest used address 0x5fef3dbc, stack 
> used: 580 bytes
> CPU_CLUSTER: 0 init finished in 64 msecs
> PCI: 00:00.0 init
> PCI: 00:00.0 init finished in 0 msecs
..
> PCI: 00:15.0 init
> PCI: 00:15.0 init finished in 0 msecs
> PCI: 00:15.1 init
> PCI: 00:15.1 init finished in 0 msecs
> PCI: 00:18.1 init
> PCI: 00:18.1 init finished in 0 msecs

Note that there is no init for 15.2 above. I don't know why, if it's
enabled in the mainboard devicetree file.


Another thought - have you compared PCI bus numbers and addresses
between vendor BIOS and coreboot? They can change around, certainly
bus numbers but wasn't there a thread a while back with addresses
being confused too?


Sorry I can't suggest anything more concrete

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

[coreboot] Re: How to debug open-source AGESA with serial console?

[Krystian Hebel]

Hi Paul,

On 15.10.2020 10:53, Paul Menzel wrote:

Dear coreboot folks,


To get PCI bridge 0:15.2 enabled for the network device on the Asus 
F2A85-M PRO, I want to debug the PCIe General Purpose Ports lane 
configuration of the FCH.


I’d like to print some variables in

    src/vendorcode/amd/agesa/f15tn/Proc/Fch/Pcie/GppPortInit.c

over the serial console. It looks like

    #include 

and `printk(BIOS_DEBUG, …)` compiles, but the messages are not sent 
over serial console. Is that expected?
Between InitReset and InitEnv (IIRC) redirection of serial port (and a 
few others) is disabled
by default, this may be the reason why `printk()` doesn't work. If that 
is the case, building with

`HUDSON_LEGACY_FREE` disabled may help.


Do I need to use AGESA’s Integrated Debug Services (IDS) [1], and 
enable the console in `src/mainboard/asus/f2a85-m/OptionsIds.h`?



Kind regards,

Paul


[1]: 
https://www.coreboot.org/images/3/36/AGESA_Interface_Spec_for_Arch_2008_v3.00.pdf


Best regards,

--
Krystian Hebel
Firmware Engineer
https://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to debug open-source AGESA with serial console?

[Michal Zygowski]

Hi Paul,

I think I got it... It is pretty easy to enable the serial output. Just
define IDSOPT_TRACING_ENABLED to TRUE in
src/mainbaord/MAINBAORDDIR/OptionsIds.h . It will link the coreboot's
printk (debug level 7) to AGESA console. So if you enable serial port in
coreboot's Kconfig it will work out-of-the-box. But expect fixing the
vendorcode to get it compiled. In the end you should have full output
from AGESA.

Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

On 16.10.2020 10:19, Michal Zygowski wrote:
> Hi Paul,
>
> See inline repsonses.
>
> On 15.10.2020 20:04, Angel Pons wrote:
>>> Clay
>>>
>>>
>>> On Thu, Oct 15, 2020 at 3:54 AM Paul Menzel  wrote:
 Dear coreboot folks,


 To get PCI bridge 0:15.2 enabled for the network device on the Asus
 F2A85-M PRO, I want to debug the PCIe General Purpose Ports lane
 configuration of the FCH.

 I’d like to print some variables in

  src/vendorcode/amd/agesa/f15tn/Proc/Fch/Pcie/GppPortInit.c

 over the serial console. It looks like

  #include 

 and `printk(BIOS_DEBUG, …)` compiles, but the messages are not sent over
 serial console. Is that expected?

 Do I need to use AGESA’s Integrated Debug Services (IDS) [1], and enable
 the console in `src/mainboard/asus/f2a85-m/OptionsIds.h`?
>
> I got it once working for apu1 (agesa f14) but it took a lot to fix
> (printf formats, etc.). Yes it is compiled with IDS settings in the
> mainboard directory. I have to look if I have a branch with the code still.
>
>> I don't know if AGESA is compiled into a different stage, which would
>> be called `libagesa`. I've just seen some mentions of this in the
>> coreboot code. I suspect logging there might need to be handled
>> differently (similar to how we handle logging in SMM, which is
>> disabled by default).
>>
>> I'd be surprised if any of the IDS stuff still builds fine. No one
>> bothered to migrate the IDS controls in OptionsIds.h to Kconfig.
>> Should you want to do so, please add various config files in configs/
>> to ensure the IDS code gets build-tested.
>>
>>
> Angel,
>
> The basic IDS which are required to build are fine, but if you enable
> something additional, well... probably you will need to fix few more
> things in vendorcode :) Yes, it is compiled as libagesa, but it doesn't
> make any difference, since it is linked to each stage IIRC. The macros
> AGESA is using to print debug info (IDS_HTD_CONSOLE) is linked to
> coreboot's printk so it ends up in the same console.
>
> I don't think it is necessary to port IDS to Kconfig. i f you include
> config.h in the ids.h in the mainboard and bind the correct defines, it
> should work?
>
> Best regards,
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to debug open-source AGESA with serial console?

[Michal Zygowski]

Hi Paul,

See inline repsonses.

On 15.10.2020 20:04, Angel Pons wrote:
>
>> Clay
>>
>>
>> On Thu, Oct 15, 2020 at 3:54 AM Paul Menzel  wrote:
>>> Dear coreboot folks,
>>>
>>>
>>> To get PCI bridge 0:15.2 enabled for the network device on the Asus
>>> F2A85-M PRO, I want to debug the PCIe General Purpose Ports lane
>>> configuration of the FCH.
>>>
>>> I’d like to print some variables in
>>>
>>>  src/vendorcode/amd/agesa/f15tn/Proc/Fch/Pcie/GppPortInit.c
>>>
>>> over the serial console. It looks like
>>>
>>>  #include 
>>>
>>> and `printk(BIOS_DEBUG, …)` compiles, but the messages are not sent over
>>> serial console. Is that expected?
>>>
>>> Do I need to use AGESA’s Integrated Debug Services (IDS) [1], and enable
>>> the console in `src/mainboard/asus/f2a85-m/OptionsIds.h`?


I got it once working for apu1 (agesa f14) but it took a lot to fix
(printf formats, etc.). Yes it is compiled with IDS settings in the
mainboard directory. I have to look if I have a branch with the code still.

> I don't know if AGESA is compiled into a different stage, which would
> be called `libagesa`. I've just seen some mentions of this in the
> coreboot code. I suspect logging there might need to be handled
> differently (similar to how we handle logging in SMM, which is
> disabled by default).
>
> I'd be surprised if any of the IDS stuff still builds fine. No one
> bothered to migrate the IDS controls in OptionsIds.h to Kconfig.
> Should you want to do so, please add various config files in configs/
> to ensure the IDS code gets build-tested.
>
>
Angel,

The basic IDS which are required to build are fine, but if you enable
something additional, well... probably you will need to fix few more
things in vendorcode :) Yes, it is compiled as libagesa, but it doesn't
make any difference, since it is linked to each stage IIRC. The macros
AGESA is using to print debug info (IDS_HTD_CONSOLE) is linked to
coreboot's printk so it ends up in the same console.

I don't think it is necessary to port IDS to Kconfig. i f you include
config.h in the ids.h in the mainboard and bind the correct defines, it
should work?

Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

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

[coreboot] ASUS A88XM-E internal flashing

[mejim67741--- via coreboot]

The documentation says

The main SPI flash can be accessed using flashrom, if the AmdSpiRomProtect 
modules have been deleted in the factory image previously.

So what does that mean? How can i do that? I would like to flash it internal
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org