AM1I-A Failing to Boot

[Matt B]

Hi,

In the spirit of board report coverage, I pulled out the (used, but new to
me) AM1I-A I have and spent a day or two trying to install the latest
coreboot on it.

The board boots fine under the stock bios, and returns to working order if
flashed with my backup, but shows little signs of life with coreboot.

Along the way I extracted and included the vgabios rom, as well as tried
with a nivida card, so I'm pretty sure that's not it.

I tried having it save the console output to flash, but that made the build
fail. [1]

Yesterday evening I noticed it was configured by default to use open-source
init (and for some reason the build finishes without error), but as far as
I know that doesn't exist for family 16h. Switching to BinaryPI causes the
build to fail. [2] 3rd party blobs are cloned and enabled.

I'm running an Athlon 5250, or something of that nature, with a couple of
gigs of ram on one dimm. My current .config is [3].

Sincerely,
    -Matt

[1] https://pastebin.com/FZEiCq8P
[2] https://pastebin.com/Q30u7Lgs
[3] https://pastebin.com/ufuq22i8

[Matt B]

I've also left the board for an hour or two, just in case this was slow ram
training or something

-Matt

On Sun, Dec 8, 2019 at 1:43 PM Matt B  wrote:
> Hi,
>
> In the spirit of board report coverage, I pulled out the (used, but new to
> me) AM1I-A I have and spent a day or two trying to install the latest
> coreboot on it.
>
> The board boots fine under the stock bios, and returns to working order if
> flashed with my backup, but shows little signs of life with coreboot.
>
> Along the way I extracted and included the vgabios rom, as well as tried
> with a nivida card, so I'm pretty sure that's not it.
>
> I tried having it save the console output to flash, but that made the
> build fail. [1]
>
> Yesterday evening I noticed it was configured by default to use
> open-source init (and for some reason the build finishes without error),
> but as far as I know that doesn't exist for family 16h. Switching to
> BinaryPI causes the build to fail. [2] 3rd party blobs are cloned and
> enabled.
>
> I'm running an Athlon 5250, or something of that nature, with a couple of
> gigs of ram on one dimm. My current .config is [3].
>
> Sincerely,
>     -Matt
>
> [1] https://pastebin.com/FZEiCq8P
> [2] https://pastebin.com/Q30u7Lgs
> [3] https://pastebin.com/ufuq22i8

[Kyösti Mälkki]

On Sun, Dec 8, 2019 at 8:44 PM Matt B  wrote:
> Hi,
>
> In the spirit of board report coverage, I pulled out the (used, but new to me) AM1I-A I have and spent a day or two trying to install the latest coreboot on it.

I hope board-status repository shows its value here for you as the
previous record is from early November. There appears to be download
link for pre-built image as well.

This platform with family16kb "Kabini" was the last scrubbed
vendorcode released so it is not binaryPI. From what I remember
CONSOLE_SPI_FLASH has not been tested with AGESA or binaryPI, the
board seems to have a serial port so maybe put that into good use.

Disclaimer: Due the time constraints to transition away from
ROMCC_BOOTBLOCK we have merged code changes that affect all
fam14-15tn-16kb AGESA, while not being able to test on a wide variety
of boards. By the end of 2019, the boards will either extinct or be
tested to boot, but todays status is somewhat volatile.

Kyösti

[Elisenda Cuadros]

Hi Matt,

Did you see this old thread?

https://www.mail-archive.com/[e-mail]/msg51097.html

I have and AM1I-A too and I had some problems at the beginning..

Regards,

Eli

On 08/12/2019 19:43, Matt B wrote:
> Hi,
>
> In the spirit of board report coverage, I pulled out the (used, but 
> new to me) AM1I-A I have and spent a day or two trying to install the 
> latest coreboot on it.
>
> The board boots fine under the stock bios, and returns to working 
> order if flashed with my backup, but shows little signs of life with 
> coreboot.
>
> Along the way I extracted and included the vgabios rom, as well as 
> tried with a nivida card, so I'm pretty sure that's not it.
>
> I tried having it save the console output to flash, but that made the 
> build fail. [1]
>
> Yesterday evening I noticed it was configured by default to use 
> open-source init (and for some reason the build finishes without 
> error), but as far as I know that doesn't exist for family 16h. 
> Switching to BinaryPI causes the build to fail. [2] 3rd party blobs 
> are cloned and enabled.
>
> I'm running an Athlon 5250, or something of that nature, with a couple 
> of gigs of ram on one dimm. My current .config is [3].
>
> Sincerely,
>     -Matt
>
> [1] https://pastebin.com/FZEiCq8P
> [2] https://pastebin.com/Q30u7Lgs
> [3] https://pastebin.com/ufuq22i8
>
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Matt B]

Ok. I'm kind of annoyed at myself now.

Your thread revealed the answer. The stock bios will boot if the dimm is in
either slot. Coreboot will only boot if it is in the outermost one.
It never occurred to me to try this.

The board now boots to the OS. More details to follow later this evening
or tomorrow morning.

Thanks,
    -Matt

On Sun, Dec 8, 2019 at 3:45 PM Elisenda Cuadros  wrote:
> Hi Matt,
>
> Did you see this old thread?
>
> https://www.mail-archive.com/[e-mail]/msg51097.html
>
> I have and AM1I-A too and I had some problems at the beginning..
>
> Regards,
>
> Eli
> On 08/12/2019 19:43, Matt B wrote:
>
> Hi,
>
> In the spirit of board report coverage, I pulled out the (used, but new to
> me) AM1I-A I have and spent a day or two trying to install the latest
> coreboot on it.
>
> The board boots fine under the stock bios, and returns to working order if
> flashed with my backup, but shows little signs of life with coreboot.
>
> Along the way I extracted and included the vgabios rom, as well as tried
> with a nivida card, so I'm pretty sure that's not it.
>
> I tried having it save the console output to flash, but that made the
> build fail. [1]
>
> Yesterday evening I noticed it was configured by default to use
> open-source init (and for some reason the build finishes without error),
> but as far as I know that doesn't exist for family 16h. Switching to
> BinaryPI causes the build to fail. [2] 3rd party blobs are cloned and
> enabled.
>
> I'm running an Athlon 5250, or something of that nature, with a couple of
> gigs of ram on one dimm. My current .config is [3].
>
> Sincerely,
>     -Matt
>
> [1] https://pastebin.com/FZEiCq8P
> [2] https://pastebin.com/Q30u7Lgs
> [3] https://pastebin.com/ufuq22i8
>
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Matt B]

Question specifically for Kyösti Mälkki or those similarly knowledgeable:

My current .config seems to say I'm still using romcc.
I assume I've pulled the latest ("git clone
https://review.coreboot.org/coreboot" as of a couple days ago) so would
those changes you mentioned be present?
If so, is there an option to test the C bootblock in the menu somewhere?

Thanks,
    -Matt

On Sun, Dec 8, 2019 at 5:19 PM Matt B  wrote:
> Ok. I'm kind of annoyed at myself now.
>
> Your thread revealed the answer. The stock bios will boot if the dimm is
> in either slot. Coreboot will only boot if it is in the outermost one.
> It never occurred to me to try this.
>
> The board now boots to the OS. More details to follow later this evening
> or tomorrow morning.
>
> Thanks,
>     -Matt
>
> On Sun, Dec 8, 2019 at 3:45 PM Elisenda Cuadros  wrote:
> > Hi Matt,
> >
> > Did you see this old thread?
> >
> > https://www.mail-archive.com/[e-mail]/msg51097.html
> >
> > I have and AM1I-A too and I had some problems at the beginning..
> >
> > Regards,
> >
> > Eli
> > On 08/12/2019 19:43, Matt B wrote:
> >
> > Hi,
> >
> > In the spirit of board report coverage, I pulled out the (used, but new
> > to me) AM1I-A I have and spent a day or two trying to install the latest
> > coreboot on it.
> >
> > The board boots fine under the stock bios, and returns to working order
> > if flashed with my backup, but shows little signs of life with coreboot.
> >
> > Along the way I extracted and included the vgabios rom, as well as tried
> > with a nivida card, so I'm pretty sure that's not it.
> >
> > I tried having it save the console output to flash, but that made the
> > build fail. [1]
> >
> > Yesterday evening I noticed it was configured by default to use
> > open-source init (and for some reason the build finishes without error),
> > but as far as I know that doesn't exist for family 16h. Switching to
> > BinaryPI causes the build to fail. [2] 3rd party blobs are cloned and
> > enabled.
> >
> > I'm running an Athlon 5250, or something of that nature, with a couple of
> > gigs of ram on one dimm. My current .config is [3].
> >
> > Sincerely,
> >     -Matt
> >
> > [1] https://pastebin.com/FZEiCq8P
> > [2] https://pastebin.com/Q30u7Lgs
> > [3] https://pastebin.com/ufuq22i8
> >
> > coreboot mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> >
> > coreboot mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]

[Kyösti Mälkki]

On Mon, Dec 9, 2019 at 12:32 AM Matt B  wrote:
> Question specifically for Kyösti Mälkki or those similarly knowledgeable:
>
> My current .config seems to say I'm still using romcc.

Please read the recent thread "AMD AGESA board removals".
> I assume I've pulled the latest ("git clone https://review.coreboot.org/coreboot" as of a couple days ago) so would those changes you mentioned be present?
> If so, is there an option to test the C bootblock in the menu somewhere?

There will be no option as romcc will be gone for good. You should do
a checkout on commit f66da11 [1], make similar changes to asus/am1i-a,
and push your work for review. I have done quick boottest on
asrock/imb-a180 with commit ca150dc [2] and it got past the made
bootblock changes.

[1] https://review.coreboot.org/c/coreboot/+/37453/9
[2] https://review.coreboot.org/c/coreboot/+/37440/10

Kyösti

[Matt B]

Hi,

Thanks for the pointer.

I need a bit more context here, being completely unfamiliar with how
coreboot works.
I've never done any non-userspace programming, and this is the first time
I've gotten a freshly-compiled coreboot to actually boot.
I do have most of a degree in computer engineering, but that's
unfortunately 99% theory with little-to-no hands-on experience.

A) If I understand correctly, [1] is the complete change (not the last
commit in a series for this board) to remove romcc usage from
asrock/imb-a180.
The same changes need to be applied to asus/am1i-a.

B) If I understand correctly, the necessary family16h changes have been
made elsewhere, so only changes to the mainboard-specific code need to be
made.
This would explain why there is a net removal of code, not addition.

C) I can't say that I really understand the contents of this file. Can
someone explain how
> /* Set LPC decode enables. */
> pci_devfn_t dev = PCI_DEV(0, 0x14, 3);
> pci_write_config32(dev, 0x44, 0xff03ffd5);

and
> /* Enable the AcpiMmio space */
> outb(0x24, 0xcd6);
> outb(0x1, 0xcd7);

and
> /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> outb(0xea, 0xcd6);
> outb(0x1, 0xcd7);

becomes
> /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> pm_write8(0xea, 0x1);

?

D) I'm a bit confused about what [2] is. Is this an earlier, unrefined
version of the changes?

I don't think that a naive transform would be wise, as there is a lot more
stuff going on in [3] :P
For instance:
1) would
> /* In Hudson RRG, PMIOxD2[5:4] is "Drive strength control for
> LpcClk[1:0]".  To be consistent with Parmer, setting to 4mA
> even though the register is not documented in the Kabini BKDG.
> Otherwise the serial output is bad code.
>
> */
> outb(0xD2, 0xcd6);
> outb(0x00, 0xcd7);

and
> /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> outb(0xEA, 0xcd6);
> outb(0x1, 0xcd7);

be transformed similarly to how
> /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> outb(0xea, 0xcd6);
> outb(0x1, 0xcd7);

was?
2) would
> /* Set LPC decode enables. */
> pci_devfn_t dev2 = PCI_DEV(0, 0x14, 3);
> pci_write_config32(dev2, 0x44, 0xff03ffd5);

and
> /* Enable the AcpiMmio space */
> outb(0x24, 0xcd6);
> outb(0x1, 0xcd7);

completely disappear?
what about
> hudson_lpc_port80();

in the middle?
4) Would
> /* Configure ClkDrvStr1 settings */
> addr32 = (u32 *)0xfed80e24;
> *addr32 = 0x030800aa;

/* Configure MiscClkCntl1 settings */
> addr32 = (u32 *)0xfed80e40;
> *addr32 = 0x000c4050;
> /* enable SIO LPC decode */
> dev = PCI_DEV(0, 0x14, 3);
> byte = pci_read_config8(dev, 0x48);
> byte |= 3; /* 2e, 2f & 4e, 4f */
> pci_write_config8(dev, 0x48, byte);
> ite_gpio_conf(GPIO_DEV);
> ite_evc_conf(ENVC_DEV);
> ite_conf_clkin(CLKIN_DEV, ITE_UART_CLK_PREDIVIDE_48);
> ite_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
> ite_kill_watchdog(GPIO_DEV);
> /*
> On Larne, after LpcClkDrvSth is set, it needs some time to be stable,
> because of the buffer ICS551M
>
> */
> for (i = 0; i < 200000; i++)
> val = inb(0xcd6);

remain unchanged?

Sincerely,
    -Matt

[1] https://review.coreboot.org/c/coreboot/+/37453/9
[2] https://review.coreboot.org/c/coreboot/+/37440/10
[3] src/mainboard/asus/am1i-a/romstage.c (for reference:
https://pastebin.com/kSka2YL7)

On Sun, Dec 8, 2019 at 6:57 PM Kyösti Mälkki 
wrote:
> On Mon, Dec 9, 2019 at 12:32 AM Matt B  wrote:
> > Question specifically for Kyösti Mälkki or those similarly knowledgeable:
> >
> > My current .config seems to say I'm still using romcc.
>
> Please read the recent thread "AMD AGESA board removals".
> > I assume I've pulled the latest ("git clone
>
> https://review.coreboot.org/coreboot" as of a couple days ago) so would
> those changes you mentioned be present?
> > If so, is there an option to test the C bootblock in the menu somewhere?
>
> There will be no option as romcc will be gone for good. You should do
> a checkout on commit f66da11 [1], make similar changes to asus/am1i-a,
> and push your work for review. I have done quick boottest on
> asrock/imb-a180 with commit ca150dc [2] and it got past the made
> bootblock changes.
>
> [1] https://review.coreboot.org/c/coreboot/+/37453/9
> [2] https://review.coreboot.org/c/coreboot/+/37440/10
>
> Kyösti

[Michal Zygowski]

On 09.12.2019 05:36, Matt B wrote:
> Hi,

Hi Matt,
> Thanks for the pointer.
>
> I need a bit more context here, being completely unfamiliar with how
> coreboot works.
> I've never done any non-userspace programming, and this is the first
> time I've gotten a freshly-compiled coreboot to actually boot.
> I do have most of a degree in computer engineering, but that's
> unfortunately 99% theory with little-to-no hands-on experience.
>
> A) If I understand correctly, [1] is the complete change (not the last
> commit in a series for this board) to remove romcc usage from
> asrock/imb-a180.
> The same changes need to be applied to asus/am1i-a.
>
> B) If I understand correctly, the necessary family16h changes have
> been made elsewhere, so only changes to the mainboard-specific code
> need to be made.
> This would explain why there is a net removal of code, not addition.
>
> C) I can't say that I really understand the contents of this file. Can
> someone explain how
> /* Set LPC decode enables. */
> pci_devfn_t dev = PCI_DEV(0, 0x14, 3);
> pci_write_config32(dev, 0x44, 0xff03ffd5);
>
> and
> /* Enable the AcpiMmio space */
> outb(0x24, 0xcd6);
> outb(0x1, 0xcd7);
>
> and
> /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> outb(0xea, 0xcd6);
> outb(0x1, 0xcd7);
>
> becomes
> /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> pm_write8(0xea, 0x1);
>
> ?

We did a lot of cleanup with Kyösti and unified implementations of LPC
decode enables and ACPIMMIO. Those instructions you point to were moved
to southbridge bootblock initialization, because it is not mainboard
specific. Also pm_write8(0xea, 0x1); does the same thing as outb(0xea,
0xcd6); and outb(0x1, 0xcd7); but in more readable form. See:
https://review.coreboot.org/c/coreboot/+/37177
https://review.coreboot.org/c/coreboot/+/37329/
https://review.coreboot.org/c/coreboot/+/37168/
> D) I'm a bit confused about what [2] is. Is this an earlier, unrefined
> version of the changes?
>
> I don't think that a naive transform would be wise, as there is a lot
> more stuff going on in [3] :P
> For instance:
>
> would
>
> /* In Hudson RRG, PMIOxD2[5:4] is "Drive strength control for
> LpcClk[1:0]".  To be consistent with Parmer, setting to 4mA
> even though the register is not documented in the Kabini BKDG.
> Otherwise the serial output is bad code.
>
> */
>  outb(0xD2, 0xcd6);
>  outb(0x00, 0xcd7);
>
> and

This was also moved to southbridge bootblock initialization - not
mainboard specific.
> /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> outb(0xEA, 0xcd6);
> outb(0x1, 0xcd7);
>
> be transformed similarly to how
>  /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> outb(0xea, 0xcd6);
> outb(0x1, 0xcd7);

coreboot uses lowercase for hex values. This should be transformed to
pm_write8(0xea, 1).
> was? 
> 2) would
> /* Set LPC decode enables. */
> pci_devfn_t dev2 = PCI_DEV(0, 0x14, 3);
> pci_write_config32(dev2, 0x44, 0xff03ffd5);
>
> and
> /* Enable the AcpiMmio space */
> outb(0x24, 0xcd6);
> outb(0x1, 0xcd7);
>
> completely disappear?
> what about
> hudson_lpc_port80();
>
> in the middle?
> 4) Would
> /* Configure ClkDrvStr1 settings */
> addr32 = (u32 *)0xfed80e24;
> *addr32 = 0x030800aa;
>
> /* Configure MiscClkCntl1 settings */
> addr32 = (u32 *)0xfed80e40;
> *addr32 = 0x000c4050;
> /* enable SIO LPC decode */
> dev = PCI_DEV(0, 0x14, 3);
> byte = pci_read_config8(dev, 0x48);
> byte |= 3;/* 2e, 2f & 4e, 4f */
> pci_write_config8(dev, 0x48, byte);
> ite_gpio_conf(GPIO_DEV);
> ite_evc_conf(ENVC_DEV);
> ite_conf_clkin(CLKIN_DEV, ITE_UART_CLK_PREDIVIDE_48);
> ite_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
> ite_kill_watchdog(GPIO_DEV);
> /*
> * On Larne, after LpcClkDrvSth is set, it needs some time to be
> stable,
> * because of the buffer ICS551M
> */
> for (i = 0; i < 200000; i++)
> val = inb(0xcd6);
>
> remain unchanged?

It should be something like:

/* Configure ClkDrvStr1 settings */
misc_write32(0x24, 0x030800aa);
/* Configure MiscClkCntl1 settings */
misc_write32(0x40, 0x000c4050);
ite_gpio_conf(GPIO_DEV);
ite_evc_conf(ENVC_DEV);
ite_conf_clkin(CLKIN_DEV, ITE_UART_CLK_PREDIVIDE_48);
ite_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
ite_kill_watchdog(GPIO_DEV);
/*
* On Larne, after LpcClkDrvSth is set, it needs some time to be stable,
* because of the buffer ICS551M
*/
for (i = 0; i < 200000; i++)
val = inb(0xcd6);

The rest is already done in southbridge bootblock init. The file with
modifications should include
#include <amdblocks/acpimmio.h>

Regards,

[Matt B]

Hi,

I am likely unable to work on this until after the 14th. (with final exams
finishing this week)
As I understand it, unfixed boards will be disabled from automatic
building after the 14th, but will not be dropped until the 31st?

-Matt

On Mon, Dec 9, 2019 at 10:55 AM Michal Zygowski 
wrote:
> On 09.12.2019 05:36, Matt B wrote:
>
> Hi,
>
> Hi Matt,
>
> Thanks for the pointer.
>
> I need a bit more context here, being completely unfamiliar with how
> coreboot works.
> I've never done any non-userspace programming, and this is the first time
> I've gotten a freshly-compiled coreboot to actually boot.
> I do have most of a degree in computer engineering, but that's
> unfortunately 99% theory with little-to-no hands-on experience.
>
> A) If I understand correctly, [1] is the complete change (not the last
> commit in a series for this board) to remove romcc usage from
> asrock/imb-a180.
> The same changes need to be applied to asus/am1i-a.
>
> B) If I understand correctly, the necessary family16h changes have been
> made elsewhere, so only changes to the mainboard-specific code need to be
> made.
> This would explain why there is a net removal of code, not addition.
>
> C) I can't say that I really understand the contents of this file. Can
> someone explain how
> > /* Set LPC decode enables. */
> > pci_devfn_t dev = PCI_DEV(0, 0x14, 3);
> > pci_write_config32(dev, 0x44, 0xff03ffd5);
>
> and
> > /* Enable the AcpiMmio space */
> > outb(0x24, 0xcd6);
> > outb(0x1, 0xcd7);
>
> and
> > /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> > outb(0xea, 0xcd6);
> > outb(0x1, 0xcd7);
>
> becomes
> > /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> > pm_write8(0xea, 0x1);
>
> ?
>
> We did a lot of cleanup with Kyösti and unified implementations of LPC
> decode enables and ACPIMMIO. Those instructions you point to were moved to
> southbridge bootblock initialization, because it is not mainboard specific.
> Also pm_write8(0xea, 0x1); does the same thing as outb(0xea, 0xcd6); and
> outb(0x1, 0xcd7); but in more readable form. See:
> https://review.coreboot.org/c/coreboot/+/37177
> https://review.coreboot.org/c/coreboot/+/37329/
> https://review.coreboot.org/c/coreboot/+/37168/
>
> D) I'm a bit confused about what [2] is. Is this an earlier, unrefined
> version of the changes?
>
> I don't think that a naive transform would be wise, as there is a lot more
> stuff going on in [3] :P
> For instance:
> would
> > /* In Hudson RRG, PMIOxD2[5:4] is "Drive strength control for
> > LpcClk[1:0]".  To be consistent with Parmer, setting to 4mA
> > even though the register is not documented in the Kabini BKDG.
> > Otherwise the serial output is bad code.
> >
> > */
> > outb(0xD2, 0xcd6);
> > outb(0x00, 0xcd7);
>
> and
>
> This was also moved to southbridge bootblock initialization - not
> mainboard specific.
>
> /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> > outb(0xEA, 0xcd6);
> > outb(0x1, 0xcd7);
>
> be transformed similarly to how
> > /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> > outb(0xea, 0xcd6);
> > outb(0x1, 0xcd7);
>
> coreboot uses lowercase for hex values. This should be transformed to
> pm_write8(0xea, 1).
>
> was?
> 2) would
> > /* Set LPC decode enables. */
> > pci_devfn_t dev2 = PCI_DEV(0, 0x14, 3);
> > pci_write_config32(dev2, 0x44, 0xff03ffd5);
>
> and
> > /* Enable the AcpiMmio space */
> > outb(0x24, 0xcd6);
> > outb(0x1, 0xcd7);
>
> completely disappear?
> what about
> > hudson_lpc_port80();
>
> in the middle?
> 4) Would
> > /* Configure ClkDrvStr1 settings */
> > addr32 = (u32 *)0xfed80e24;
> > *addr32 = 0x030800aa;
>
> /* Configure MiscClkCntl1 settings */
> > addr32 = (u32 *)0xfed80e40;
> > *addr32 = 0x000c4050;
> > /* enable SIO LPC decode */
> > dev = PCI_DEV(0, 0x14, 3);
> > byte = pci_read_config8(dev, 0x48);
> > byte |= 3; /* 2e, 2f & 4e, 4f */
> > pci_write_config8(dev, 0x48, byte);
> > ite_gpio_conf(GPIO_DEV);
> > ite_evc_conf(ENVC_DEV);
> > ite_conf_clkin(CLKIN_DEV, ITE_UART_CLK_PREDIVIDE_48);
> > ite_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
> > ite_kill_watchdog(GPIO_DEV);
> > /*
> > On Larne, after LpcClkDrvSth is set, it needs some time to be stable,
> > because of the buffer ICS551M
> >
> > */
> > for (i = 0; i < 200000; i++)
> > val = inb(0xcd6);
>
> remain unchanged?
>
> It should be something like:
>
> /* Configure ClkDrvStr1 settings */
> misc_write32(0x24, 0x030800aa);
> /* Configure MiscClkCntl1 settings */
> misc_write32(0x40, 0x000c4050);
> ite_gpio_conf(GPIO_DEV);
> ite_evc_conf(ENVC_DEV);
> ite_conf_clkin(CLKIN_DEV, ITE_UART_CLK_PREDIVIDE_48);
> ite_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
> ite_kill_watchdog(GPIO_DEV);
> /*
> On Larne, after LpcClkDrvSth is set, it needs some time to be stable,
> because of the buffer ICS551M
>
> */
> for (i = 0; i < 200000; i++)
> val = inb(0xcd6);
>
> The rest is already done in southbridge bootblock init. The file with
> modifications should include
> #include <amdblocks/acpimmio.h>
>
> Regards,
>
> Sincerely,
>     -Matt
>
> [1] https://review.coreboot.org/c/coreboot/+/37453/9
> [2] https://review.coreboot.org/c/coreboot/+/37440/10
> [3] src/mainboard/asus/am1i-a/romstage.c (for reference:
> https://pastebin.com/kSka2YL7)
>
> On Sun, Dec 8, 2019 at 6:57 PM Kyösti Mälkki 
> wrote:
> > On Mon, Dec 9, 2019 at 12:32 AM Matt B 
> > wrote:
> > > Question specifically for Kyösti Mälkki or those similarly
> >
> > knowledgeable:
> > > My current .config seems to say I'm still using romcc.
> >
> > Please read the recent thread "AMD AGESA board removals".
> > > I assume I've pulled the latest ("git clone
> >
> > https://review.coreboot.org/coreboot" as of a couple days ago) so would
> > those changes you mentioned be present?
> > > If so, is there an option to test the C bootblock in the menu somewhere?
> >
> > There will be no option as romcc will be gone for good. You should do
> > a checkout on commit f66da11 [1], make similar changes to asus/am1i-a,
> > and push your work for review. I have done quick boottest on
> > asrock/imb-a180 with commit ca150dc [2] and it got past the made
> > bootblock changes.
> >
> > [1] https://review.coreboot.org/c/coreboot/+/37453/9
> > [2] https://review.coreboot.org/c/coreboot/+/37440/10
> >
> > Kyösti
>
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Mike Banon]

It would be nice if this "drop time" could be extended until at least
mid January (i.e 19th Jan), so that those of us who have New Year
holidays will be able to spend them working on coreboot. I also want
to save AM1I-A but don't have much time in December.

On Thu, Dec 12, 2019 at 12:52 AM Matt B  wrote:
> Hi,
>
> I am likely unable to work on this until after the 14th. (with final exams finishing this week)
> As I understand it, unfixed boards will be disabled from automatic building after the 14th, but will not be dropped until the 31st?
>
> -Matt
>
> On Mon, Dec 9, 2019 at 10:55 AM Michal Zygowski  wrote:
> > On 09.12.2019 05:36, Matt B wrote:
> >
> > Hi,
> >
> > Hi Matt,
> >
> > Thanks for the pointer.
> >
> > I need a bit more context here, being completely unfamiliar with how coreboot works.
> > I've never done any non-userspace programming, and this is the first time I've gotten a freshly-compiled coreboot to actually boot.
> > I do have most of a degree in computer engineering, but that's unfortunately 99% theory with little-to-no hands-on experience.
> >
> > A) If I understand correctly, [1] is the complete change (not the last commit in a series for this board) to remove romcc usage from asrock/imb-a180.
> > The same changes need to be applied to asus/am1i-a.
> >
> > B) If I understand correctly, the necessary family16h changes have been made elsewhere, so only changes to the mainboard-specific code need to be made.
> > This would explain why there is a net removal of code, not addition.
> >
> > C) I can't say that I really understand the contents of this file. Can someone explain how
> > > /* Set LPC decode enables. */
> > > pci_devfn_t dev = PCI_DEV(0, 0x14, 3);
> > > pci_write_config32(dev, 0x44, 0xff03ffd5);
> >
> > and
> > > /* Enable the AcpiMmio space */
> > > outb(0x24, 0xcd6);
> > > outb(0x1, 0xcd7);
> >
> > and
> > > /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> > > outb(0xea, 0xcd6);
> > > outb(0x1, 0xcd7);
> >
> > becomes
> > > /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> > > pm_write8(0xea, 0x1);
> >
> > ?
> >
> > We did a lot of cleanup with Kyösti and unified implementations of LPC decode enables and ACPIMMIO. Those instructions you point to were moved to southbridge bootblock initialization, because it is not mainboard specific. Also pm_write8(0xea, 0x1); does the same thing as outb(0xea, 0xcd6); and outb(0x1, 0xcd7); but in more readable form. See:
> > https://review.coreboot.org/c/coreboot/+/37177
> > https://review.coreboot.org/c/coreboot/+/37329/
> > https://review.coreboot.org/c/coreboot/+/37168/
> >
> > D) I'm a bit confused about what [2] is. Is this an earlier, unrefined version of the changes?
> >
> > I don't think that a naive transform would be wise, as there is a lot more stuff going on in [3] :P
> > For instance:
> > would
> > > /* In Hudson RRG, PMIOxD2[5:4] is "Drive strength control for
> > > LpcClk[1:0]".  To be consistent with Parmer, setting to 4mA
> > > even though the register is not documented in the Kabini BKDG.
> > > Otherwise the serial output is bad code.
> > >
> > > */
> > > outb(0xD2, 0xcd6);
> > > outb(0x00, 0xcd7);
> >
> > and
> >
> > This was also moved to southbridge bootblock initialization - not mainboard specific.
> > > /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> > > outb(0xEA, 0xcd6);
> > > outb(0x1, 0xcd7);
> >
> > be transformed similarly to how
> > > /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> > > outb(0xea, 0xcd6);
> > > outb(0x1, 0xcd7);
> >
> > coreboot uses lowercase for hex values. This should be transformed to pm_write8(0xea, 1).
> >
> > was?
> > 2) would
> > > /* Set LPC decode enables. */
> > > pci_devfn_t dev2 = PCI_DEV(0, 0x14, 3);
> > > pci_write_config32(dev2, 0x44, 0xff03ffd5);
> >
> > and
> > > /* Enable the AcpiMmio space */
> > > outb(0x24, 0xcd6);
> > > outb(0x1, 0xcd7);
> >
> > completely disappear?
> > what about
> > > hudson_lpc_port80();
> >
> > in the middle?
> > 4) Would
> > > /* Configure ClkDrvStr1 settings */
> > > addr32 = (u32 *)0xfed80e24;
> > > *addr32 = 0x030800aa;
> > >
> > > /* Configure MiscClkCntl1 settings */
> > > addr32 = (u32 *)0xfed80e40;
> > > *addr32 = 0x000c4050;
> > > /* enable SIO LPC decode */
> > > dev = PCI_DEV(0, 0x14, 3);
> > > byte = pci_read_config8(dev, 0x48);
> > > byte |= 3; /* 2e, 2f & 4e, 4f */
> > > pci_write_config8(dev, 0x48, byte);
> > > ite_gpio_conf(GPIO_DEV);
> > > ite_evc_conf(ENVC_DEV);
> > > ite_conf_clkin(CLKIN_DEV, ITE_UART_CLK_PREDIVIDE_48);
> > > ite_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
> > > ite_kill_watchdog(GPIO_DEV);
> > > /*
> > > On Larne, after LpcClkDrvSth is set, it needs some time to be stable,
> > > because of the buffer ICS551M
> > >
> > > */
> > > for (i = 0; i < 200000; i++)
> > > val = inb(0xcd6);
> >
> > remain unchanged?
> >
> > It should be something like:
> >
> > /* Configure ClkDrvStr1 settings */
> > misc_write32(0x24, 0x030800aa);
> > /* Configure MiscClkCntl1 settings */
> > misc_write32(0x40, 0x000c4050);
> > ite_gpio_conf(GPIO_DEV);
> > ite_evc_conf(ENVC_DEV);
> > ite_conf_clkin(CLKIN_DEV, ITE_UART_CLK_PREDIVIDE_48);
> > ite_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
> > ite_kill_watchdog(GPIO_DEV);
> > /*
> > On Larne, after LpcClkDrvSth is set, it needs some time to be stable,
> > because of the buffer ICS551M
> >
> > */
> > for (i = 0; i < 200000; i++)
> > val = inb(0xcd6);
> >
> > The rest is already done in southbridge bootblock init. The file with modifications should include
> > #include <amdblocks/acpimmio.h>
> >
> > Regards,
> >
> > Sincerely,
> >     -Matt
> >
> > [1] https://review.coreboot.org/c/coreboot/+/37453/9
> > [2] https://review.coreboot.org/c/coreboot/+/37440/10
> > [3] src/mainboard/asus/am1i-a/romstage.c (for reference: https://pastebin.com/kSka2YL7)
> >
> > On Sun, Dec 8, 2019 at 6:57 PM Kyösti Mälkki  wrote:
> > > On Mon, Dec 9, 2019 at 12:32 AM Matt B  wrote:
> > > > Question specifically for Kyösti Mälkki or those similarly knowledgeable:
> > > >
> > > > My current .config seems to say I'm still using romcc.
> > >
> > > Please read the recent thread "AMD AGESA board removals".
> > > > I assume I've pulled the latest ("git clone https://review.coreboot.org/coreboot" as of a couple days ago) so would those changes you mentioned be present?
> > > > If so, is there an option to test the C bootblock in the menu somewhere?
> > >
> > > There will be no option as romcc will be gone for good. You should do
> > > a checkout on commit f66da11 [1], make similar changes to asus/am1i-a,
> > > and push your work for review. I have done quick boottest on
> > > asrock/imb-a180 with commit ca150dc [2] and it got past the made
> > > bootblock changes.
> > >
> > > [1] https://review.coreboot.org/c/coreboot/+/37453/9
> > > [2] https://review.coreboot.org/c/coreboot/+/37440/10
> > >
> > > Kyösti
> >
> > coreboot mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> >
> > coreboot mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Kyösti Mälkki]

On Thu, Dec 12, 2019 at 11:58 AM Mike Banon  wrote:
> It would be nice if this "drop time" could be extended until at least
> mid January (i.e 19th Jan), so that those of us who have New Year
> holidays will be able to spend them working on coreboot. I also want
> to save AM1I-A but don't have much time in December.

Download board-status for 4.11-400 so that I know it boots, solution
for am1i-a may magically appear after that.

Kyösti

[Matt B]

Hello,

4.11-400

What is the extra -400? It doesn't seem like a commit hash.

Sincerely,
    -Matt

On Thu, Dec 12, 2019 at 5:23 PM Kyösti Mälkki 
wrote:
> On Thu, Dec 12, 2019 at 11:58 AM Mike Banon  wrote:
> > It would be nice if this "drop time" could be extended until at least
> > mid January (i.e 19th Jan), so that those of us who have New Year
> > holidays will be able to spend them working on coreboot. I also want
> > to save AM1I-A but don't have much time in December.
>
> Download board-status for 4.11-400 so that I know it boots, solution
> for am1i-a may magically appear after that.
>
> Kyösti

[Mike Banon]

I hope this board is saved with a change
https://review.coreboot.org/c/coreboot/+/37829 ( asus/am1i-a: Switch
away from ROMCC_BOOTBLOCK )

On Mon, Dec 23, 2019 at 11:40 AM Matt B  wrote:
> Hello,
> > 4.11-400
>
> What is the extra -400? It doesn't seem like a commit hash.
>
> Sincerely,
>     -Matt
>
> On Thu, Dec 12, 2019 at 5:23 PM Kyösti Mälkki  wrote:
> > On Thu, Dec 12, 2019 at 11:58 AM Mike Banon  wrote:
> > > It would be nice if this "drop time" could be extended until at least
> > > mid January (i.e 19th Jan), so that those of us who have New Year
> > > holidays will be able to spend them working on coreboot. I also want
> > > to save AM1I-A but don't have much time in December.
> >
> > Download board-status for 4.11-400 so that I know it boots, solution
> > for am1i-a may magically appear after that.
> >
> > Kyösti

[Mike Banon]

a discrete GPU problem is fixed with this tiny change -
https://review.coreboot.org/c/coreboot/+/38214

On Thu, Dec 26, 2019 at 10:30 AM Mike Banon  wrote:
> I hope this board is saved with a change
> https://review.coreboot.org/c/coreboot/+/37829 ( asus/am1i-a: Switch
> away from ROMCC_BOOTBLOCK )
>
> On Mon, Dec 23, 2019 at 11:40 AM Matt B  wrote:
> > Hello,
> > > 4.11-400
> >
> > What is the extra -400? It doesn't seem like a commit hash.
> >
> > Sincerely,
> >     -Matt
> >
> > On Thu, Dec 12, 2019 at 5:23 PM Kyösti Mälkki  wrote:
> > > On Thu, Dec 12, 2019 at 11:58 AM Mike Banon  wrote:
> > > > It would be nice if this "drop time" could be extended until at least
> > > > mid January (i.e 19th Jan), so that those of us who have New Year
> > > > holidays will be able to spend them working on coreboot. I also want
> > > > to save AM1I-A but don't have much time in December.
> > >
> > > Download board-status for 4.11-400 so that I know it boots, solution
> > > for am1i-a may magically appear after that.
> > >
> > > Kyösti