AMD AGESA board removals

[Kyösti Mälkki]

Hi

Regarding the deprecation of AGESA platforms due to ROMCC_BOOTBLOCK.

As of 3rd December there is active development, while not much testing
yet, only for the following AGESA platform boards:

* asrock/imb-a180
* lenovo/g505s
* pcengines/apu1

Developers will help people who have these platforms to bring their
board sources to current standards. The process begins by uploading a
fresh board-status result for the board you volunteer to work on and
announce this by replying to this thread.

Using one of the above boards as a sample, it might not take more than
30 minutes and two boots to make the required transition. But first we
need to have the above boards working of course.

Our board-status repository has some previous results for the boards
listed below, and we need your assistance to keep these boards in:

* amd/olivehill
* amd/persimmon
* amd/thatcher
* asrock/e350m1
* asus/am1i-a
* asus/f2a85-m
* biostar/am1ml
* gizmosphere/gizmo
* hp/pavilion_m6_1035dx
* jetway/nf81-t56n-lf
* lippert/frontrunner-af
* msi/ms7721

Same offer and request of help as above applies to the following
boards, for which we have no previous board-status records:

* amd/inagua
* amd/parmer
* amd/south_station
* amd/union_station
* bap/ode_e20XX
* biostar/a68n_5200
* elmex/pcm205400
* gizmosphere/gizmo2
* hp/abm
* lippert/toucan-af

Any board with ROMCC_BOOTBLOCK will be disabled from automatic
build-testing by 14th December at latest, such that ROMCC_BOOTBLOCK
removal in common code can proceed. Boards that see no activity will
be removed from the tree 31st December 2019.

Once a board has its source removed, it will face the standard review
process should someone want to bring it back. Reincarnations until
next (4.12) release might not be accepted.

Kind regards,
Kyösti Mälkki

[Michal Zygowski]

On 03.12.2019 18:29, Kyösti Mälkki wrote:
> Hi
>
> Regarding the deprecation of AGESA platforms due to ROMCC_BOOTBLOCK.
>
> As of 3rd December there is active development, while not much testing
> yet, only for the following AGESA platform boards:
> asrock/imb-a180
> lenovo/g505s
> pcengines/apu1

I do not exactly understand "not much testing". While uploading patches
for family14 or apu1 I always build, flash, boot Linux test whether it
works...
> Developers will help people who have these platforms to bring their
> board sources to current standards. The process begins by uploading a
> fresh board-status result for the board you volunteer to work on and
> announce this by replying to this thread.
>
> Using one of the above boards as a sample, it might not take more than
> 30 minutes and two boots to make the required transition. But first we
> need to have the above boards working of course.
>
> Our board-status repository has some previous results for the boards
> listed below, and we need your assistance to keep these boards in:
> amd/olivehill
> amd/persimmon
> amd/thatcher
> asrock/e350m1
> asus/am1i-a
> asus/f2a85-m
> biostar/am1ml
> gizmosphere/gizmo
> hp/pavilion_m6_1035dx
> jetway/nf81-t56n-lf
> lippert/frontrunner-af
> msi/ms7721
>
> Same offer and request of help as above applies to the following
> boards, for which we have no previous board-status records:
> amd/inagua
> amd/parmer
> amd/south_station
> amd/union_station
> bap/ode_e20XX
> biostar/a68n_5200
> elmex/pcm205400
> gizmosphere/gizmo2
> hp/abm
> lippert/toucan-af
>
> Any board with ROMCC_BOOTBLOCK will be disabled from automatic
> build-testing by 14th December at latest, such that ROMCC_BOOTBLOCK
> removal in common code can proceed. Boards that see no activity will
> be removed from the tree 31st December 2019.
>
> Once a board has its source removed, it will face the standard review
> process should someone want to bring it back. Reincarnations until
> next (4.12) release might not be accepted.
>
> Kind regards,
> Kyösti Mälkki
> _______________________________________________
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Kyösti Mälkki]

On Wed, Dec 4, 2019 at 4:48 PM Michal Zygowski
 wrote:
> On 03.12.2019 18:29, Kyösti Mälkki wrote:
> > Hi
> >
> > Regarding the deprecation of AGESA platforms due to ROMCC_BOOTBLOCK.
> >
> > As of 3rd December there is active development, while not much testing
> > yet, only for the following AGESA platform boards:
> > asrock/imb-a180
> > lenovo/g505s
> > pcengines/apu1
>
> I do not exactly understand "not much testing". While uploading patches
> for family14 or apu1 I always build, flash, boot Linux test whether it
> works...

You can read this no testing at all for fam15tn and fam16kb so far,
and testing fam14 with a single board.

I believe there was a commit for apu1 where newly added bootblock.c
file was not linked in, while the boot sequence to OS worked just
perfect? Some super-io configuration bits are sticky and powered from
Vbat /Vrtc or Vstb rails, these bootblock changes should be verified
with (RTC) battery removed.

Kyösti

[Michal Zygowski]

On 04.12.2019 16:15, Kyösti Mälkki wrote:
> On Wed, Dec 4, 2019 at 4:48 PM Michal Zygowski
>  wrote:
> > On 03.12.2019 18:29, Kyösti Mälkki wrote:
> > > Hi
> > >
> > > Regarding the deprecation of AGESA platforms due to ROMCC_BOOTBLOCK.
> > >
> > > As of 3rd December there is active development, while not much testing
> > > yet, only for the following AGESA platform boards:
> > > asrock/imb-a180
> > > lenovo/g505s
> > > pcengines/apu1
> >
> > I do not exactly understand "not much testing". While uploading patches
> > for family14 or apu1 I always build, flash, boot Linux test whether it
> > works...
>
> You can read this no testing at all for fam15tn and fam16kb so far,
> and testing fam14 with a single board.
>
> I believe there was a commit for apu1 where newly added bootblock.c
> file was not linked in, while the boot sequence to OS worked just
> perfect? Some super-io configuration bits are sticky and powered from
> Vbat /Vrtc or Vstb rails, these bootblock changes should be verified
> with (RTC) battery removed.

True. The NCT5104D has UARTA LDN enabled by default with
IO base 0x3f8. So Vbat wouldn't affect it at all.
> Kyösti
> _______________________________________________
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Matt B]

Hi,

Regarding lenovo/g505s, asus/am1i-a, and maybe some others (suggestions
welcome!) I'd be willing to put up some money on
https://www.bountysource.com/ for their migration away from ROMCC_BOOTBLOCK.

Thoughts?

Sincerely,
    -Matt

On Wed, Dec 4, 2019 at 10:26 AM Michal Zygowski 
wrote:
> On 04.12.2019 16:15, Kyösti Mälkki wrote:
> > On Wed, Dec 4, 2019 at 4:48 PM Michal Zygowski
> >  wrote:
> > > On 03.12.2019 18:29, Kyösti Mälkki wrote:
> > > > Hi
> > > >
> > > > Regarding the deprecation of AGESA platforms due to ROMCC_BOOTBLOCK.
> > > >
> > > > As of 3rd December there is active development, while not much testing
> > > > yet, only for the following AGESA platform boards:
> > > > asrock/imb-a180
> > > > lenovo/g505s
> > > > pcengines/apu1
> > >
> > > I do not exactly understand "not much testing". While uploading patches
> > > for family14 or apu1 I always build, flash, boot Linux test whether it
> > > works...
> >
> > You can read this no testing at all for fam15tn and fam16kb so far,
> > and testing fam14 with a single board.
> >
> > I believe there was a commit for apu1 where newly added bootblock.c
> > file was not linked in, while the boot sequence to OS worked just
> > perfect? Some super-io configuration bits are sticky and powered from
> > Vbat /Vrtc or Vstb rails, these bootblock changes should be verified
> > with (RTC) battery removed.
>
> True. The NCT5104D has UARTA LDN enabled by default with
> IO base 0x3f8. So Vbat wouldn't affect it at all.
> > Kyösti
> > _______________________________________________
> > coreboot mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]

[Peter Stuge]

Kyösti Mälkki wrote:
> gizmosphere/gizmo

I have a gizmo and would like to help it stay in tree. If I understand you
correctly I should start by trying to build and boot current master?

//Peter

[Kyösti Mälkki]

On Wed, Dec 4, 2019 at 11:44 PM Peter Stuge  wrote:
> Kyösti Mälkki wrote:
> > gizmosphere/gizmo
>
> I have a gizmo and would like to help it stay in tree. If I understand you
> correctly I should start by trying to build and boot current master?

Nice, a fresh board-status is most welcome. With no super-io to set up
in the bootblock, gizmo would get a free ride [1].

[1] https://review.coreboot.org/c/coreboot/+/37452

Kyösti

[Denis 'GNUtoo' Carikli]

On Tue, 3 Dec 2019 19:29:48 +0200
Kyösti Mälkki  wrote:
> Hi

Hi,
> Regarding the deprecation of AGESA platforms due to ROMCC_BOOTBLOCK.
>
> As of 3rd December there is active development, while not much testing
> yet, only for the following AGESA platform boards:
> asrock/imb-a180
> lenovo/g505s
> pcengines/apu1
>
> Using one of the above boards as a sample, it might not take more than
> 30 minutes and two boots to make the required transition. But first we
> need to have the above boards working of course.

- Do you have some pointers to commits doing that transition?
- What to do if the board doesn't boot anymore with master
  (f2a85m-pro)? Should I bisect the issue first? Or would the
  conversion be able to fix the issue?

Denis.

[Kyösti Mälkki]

On Sun, Dec 8, 2019 at 6:20 PM Denis 'GNUtoo' Carikli
 wrote:
> On Tue, 3 Dec 2019 19:29:48 +0200
> Kyösti Mälkki  wrote:
> > Hi
>
> Hi,
> > Regarding the deprecation of AGESA platforms due to ROMCC_BOOTBLOCK.
> >
> > As of 3rd December there is active development, while not much testing
> > yet, only for the following AGESA platform boards:
> > asrock/imb-a180
> > lenovo/g505s
> > pcengines/apu1
> >
> > Using one of the above boards as a sample, it might not take more than
> > 30 minutes and two boots to make the required transition. But first we
> > need to have the above boards working of course.
> Do you have some pointers to commits doing that transition?

Here is fam16kb asrock/imb-a180 with super-io init moved to bootblock:
https://review.coreboot.org/c/coreboot/+/37453

And a fam15tn lenovo/g505s without serial port:
https://review.coreboot.org/c/coreboot/+/37499
> What to do if the board doesn't boot anymore with master
> (f2a85m-pro)? Should I bisect the issue first? Or would the
> conversion be able to fix the issue?

Bisect first and return master to a working state please. There is a
recent fam15tn test so I hope your board did not regress since 4.10
tag.

Kyösti

[Denis 'GNUtoo' Carikli]

On Sun, 8 Dec 2019 18:49:26 +0200
Kyösti Mälkki  wrote:
> Here is fam16kb asrock/imb-a180 with super-io init moved to bootblock:
> https://review.coreboot.org/c/coreboot/+/37453

Thanks.

I've tried to do the same for the E350M1 and I end up with:
> [...]/i386-elf-ld.bfd: build/bootblock/arch/x86/bootblock_crt0.o: in
>      function `enable_sse':
> [...]/src/arch/x86/bootblock_crt0.S:71: undefined reference to
>      `bootblock_pre_c_entry'

Only src/soc/amd/common/block/cpu/car/cache_as_ram.S seem to have it
for AMD CPUs/SOCs.

However that cache_as_ram.S is selected by SOC_AMD_COMMON_BLOCK_CAR,
which is only used in src/soc/amd/stoneyridge/Kconfig.

I don't understand why the other boards converted to switch away from
ROMCC_BOOTBLOCK don't have that issue.

Denis.

[Kyösti Mälkki]

On Mon, Dec 9, 2019 at 1:53 AM Denis 'GNUtoo' Carikli
 wrote:
> On Sun, 8 Dec 2019 18:49:26 +0200
> Kyösti Mälkki  wrote:
> > Here is fam16kb asrock/imb-a180 with super-io init moved to bootblock:
> > https://review.coreboot.org/c/coreboot/+/37453
>
> Thanks.
>
> I've tried to do the same for the E350M1 and I end up with:
> > [...]/i386-elf-ld.bfd: build/bootblock/arch/x86/bootblock_crt0.o: in
> >      function `enable_sse':
> > [...]/src/arch/x86/bootblock_crt0.S:71: undefined reference to
> >      `bootblock_pre_c_entry'

You want to rebase your changes on pcengines/apu1 transition [1]
which is the first fam14 board to drop ROMCC_BOOTBLOCK.

[1] https://review.coreboot.org/c/coreboot/+/37332/11

Kyösti

[Denis 'GNUtoo' Carikli]

On Mon, 9 Dec 2019 02:20:29 +0200
Kyösti Mälkki  wrote:
> On Mon, Dec 9, 2019 at 1:53 AM Denis 'GNUtoo' Carikli
>  wrote:
> > I've tried to do the same for the E350M1 and I end up with:
> > > [...]/i386-elf-ld.bfd: build/bootblock/arch/x86/bootblock_crt0.o:
> > > in function `enable_sse':
> > > [...]/src/arch/x86/bootblock_crt0.S:71: undefined reference to
> > >      `bootblock_pre_c_entry'
>
> You want to rebase your changes on pcengines/apu1 transition [1]
> which is the first fam14 board to drop ROMCC_BOOTBLOCK.
>
> [1] https://review.coreboot.org/c/coreboot/+/37332/11

Thanks a lot, that now compiles. Though that changeset makes the
normal/fallback mechanism options disappear from make menuconfig.
Was that intended?

That mechanism is really handy for testing some of the changes:
- First I test with the normal/ prefix
- If it works I rebuild from scratch with the fallback prefix to make
  sure that it also works in the standard configuration and retest
  afterward.
- If it doesn't work and that I'm bisecting something I just reboot
  several times until it goes back to fallback.

Though as it's implemented in the bootblock it's often required not to
have the two images drift too much as one bootblock is used to boot
both images.

It also doesn't prevent me to flash known bad images on fallback/ as I
still need to be 100% sure that the image really don't work before
telling about it on the mailing list, but it still helps me speeding up
bisection a lot.

Denis.

[Denis 'GNUtoo' Carikli]

On Mon, 9 Dec 2019 02:20:29 +0200
Kyösti Mälkki  wrote:

[E350M1]
> You want to rebase your changes on pcengines/apu1 transition [1]
> which is the first fam14 board to drop ROMCC_BOOTBLOCK.
>
> [1] https://review.coreboot.org/c/coreboot/+/37332/11

I've done that, and after build it, flashing it and powering off and on
the board, nothing appears on the serial port.

Denis.

[Kyösti Mälkki]

On Tue, Dec 10, 2019 at 1:07 AM Denis 'GNUtoo' Carikli
 wrote:
> On Mon, 9 Dec 2019 02:20:29 +0200
> Kyösti Mälkki  wrote:
>
> [E350M1]
> > You want to rebase your changes on pcengines/apu1 transition [1]
> > which is the first fam14 board to drop ROMCC_BOOTBLOCK.
> >
> > [1] https://review.coreboot.org/c/coreboot/+/37332/11
>
> I've done that, and after build it, flashing it and powering off and on
> the board, nothing appears on the serial port.

You can push your own commits on top of the existing (but not yet
merged) works on gerrit. Run 'git push --dry-run' and if it only shows
your commit as new/updated you would not mess with the already
existing branch we have. You can achieve this by making sure the
parent commit is one that you already find gerrit UI, in other words
do not rebase when you have done a checkout.

We'll do some tests on cimx/sb800, probably some missing LPC route or clock.

Kyösti

[Denis 'GNUtoo' Carikli]

On Sun, 8 Dec 2019 18:49:26 +0200
Kyösti Mälkki  wrote:
> > What to do if the board doesn't boot anymore with master
> > (f2a85m-pro)? Should I bisect the issue first? Or would the
> > conversion be able to fix the issue?
>
> Bisect first and return master to a working state please. There is a
> recent fam15tn test so I hope your board did not regress since 4.10
> tag.

I found the commit that broke the F2A85M-PRO booting:
> 51b75ae50aa device: Use scan_static_bus() over scan_lpc_bus()

Denis.

[Kyösti Mälkki]

On Mon, Dec 9, 2019 at 5:48 PM Denis 'GNUtoo' Carikli
 wrote:
> On Sun, 8 Dec 2019 18:49:26 +0200
> Kyösti Mälkki  wrote:
> > > What to do if the board doesn't boot anymore with master
> > > (f2a85m-pro)? Should I bisect the issue first? Or would the
> > > conversion be able to fix the issue?
> >
> > Bisect first and return master to a working state please. There is a
> > recent fam15tn test so I hope your board did not regress since 4.10
> > tag.
>
> I found the commit that broke the F2A85M-PRO booting:
> > 51b75ae50aa device: Use scan_static_bus() over scan_lpc_bus()

Weird. Seems like I let the devicetree in a bit of a bad shape back in 2015.
Try if this makes any difference: https://review.coreboot.org/c/coreboot/+/37619

Kyösti

[Denis 'GNUtoo' Carikli]

On Mon, 9 Dec 2019 18:54:18 +0200
Kyösti Mälkki  wrote:

[f2a85m-pro broken on master]
> Weird. Seems like I let the devicetree in a bit of a bad shape back
> in 2015. Try if this makes any difference:
> https://review.coreboot.org/c/coreboot/+/37619

I tried that through the normal/fallback mechanism on top of master and
it didn't boot.

Denis.

[Kyösti Mälkki]

On Tue, Dec 10, 2019 at 1:10 AM Denis 'GNUtoo' Carikli
 wrote:
> On Mon, 9 Dec 2019 18:54:18 +0200
> Kyösti Mälkki  wrote:
>
> [f2a85m-pro broken on master]
> > Weird. Seems like I let the devicetree in a bit of a bad shape back
> > in 2015. Try if this makes any difference:
> > https://review.coreboot.org/c/coreboot/+/37619
>
> I tried that through the normal/fallback mechanism on top of master and
> it didn't boot.

It should be pretty obvious we are building new bootblocks, you can't
test with the fallback/normal mechanism of romcc bootblock.

Someone should create a mock verstage to support the equivalent of
fallback/normal mechanism, but I don't know anyone working actively on
it.

Kyösti

[Kyösti Mälkki]

On Tue, Dec 10, 2019 at 10:22 AM Kyösti Mälkki  wrote:
> On Tue, Dec 10, 2019 at 1:10 AM Denis 'GNUtoo' Carikli
>  wrote:
> > On Mon, 9 Dec 2019 18:54:18 +0200
> > Kyösti Mälkki  wrote:
> >
> > [f2a85m-pro broken on master]
> > > Weird. Seems like I let the devicetree in a bit of a bad shape back
> > > in 2015. Try if this makes any difference:
> > > https://review.coreboot.org/c/coreboot/+/37619
> >
> > I tried that through the normal/fallback mechanism on top of master and
> > it didn't boot.
>
> It should be pretty obvious we are building new bootblocks, you can't
> test with the fallback/normal mechanism of romcc bootblock.

Ah.. I just realised this wasn't a bootblock change we are talking
about. Anyways, try fix the f2a85m-pro, send logs here if necessary.

Kyösti

[Nico Huber]

Hi Denis,

On 10.12.19 00:10, Denis 'GNUtoo' Carikli wrote:
> On Mon, 9 Dec 2019 18:54:18 +0200
> Kyösti Mälkki  wrote:
>
> [f2a85m-pro broken on master]
> > Weird. Seems like I let the devicetree in a bit of a bad shape back
> > in 2015. Try if this makes any difference:
> > https://review.coreboot.org/c/coreboot/+/37619
>
> I tried that through the normal/fallback mechanism on top of master and
> it didn't boot.

we didn't find a reason how 51b75ae50aa could have broken it. However,
its direct successor on the master branch is very suspicious, hence
Kyösti's patch.

Please re-check your bisect result, and if 2f8192bc6b (asus/f2a85m_pro:
Fix superio type in devicetree) is the culprit, cherry pick Kyösti's
patch on top of that. We don't know if it was a single commit that broke
your board or if later commits broke it further. If the patch helps on
top of 2f8192bc6b but not on master, you'll have to bisect again with
the patch picked on top of every candidate.

Hope that helps,
Nico

[Denis 'GNUtoo' Carikli]

On Tue, 10 Dec 2019 10:31:38 +0100
Nico Huber  wrote:
> Hi Denis,

Hi,

[f2a85m-pro]
> Please re-check your bisect result,

I'm sorry for having messed up here. Doing too much things at the same
time didn't help (too much deadlines around the same date). I double
checked everything this time.

Here's the results:
- At "51b75ae50aa device: Use scan_static_bus() over scan_lpc_bus()",
  the board boots.
- At "2f8192bc6b9 asus/f2a85m_pro: Fix superio type in devicetree"
  the board fails to boot and pressing the power-on button for a long
  time cannot shut it down after that (I've to power off the PSU for
  enough time to do that).
- At 2f8192bc6b9 asus/f2a85m_pro: Fix superio type in devicetree" with
  Kyösti's patch, the board fails to boot but shuts down properly with
  the power button.

I'll try to find the time to do the setup required to get some logs.

As the serial port doesn't work (it needs to be fixed in Coreboot), I
need to look for an alternative way to get the logs (I'll probably try
finding the EHCI debug port or setting up a PCIe serial port card).

Denis.

[Github Hun]

Hi,

just to give a heads-up status: as of today (13.12.2019) with the current Master revision, I can confirm, that for lenovo/g505s coreboot builds and boots perfectly with ROMCC_BOOTBLOCK already removed.

There are two modifications are needed though:
1. revise commit: 0178760 on Oct 25: 'Don't use both of _ADR and _HID' patch --> for Fam15h '_CID' is missing from:
 src/northbridge/amd/agesa/family15tn/acpi/northbridge.asl
therefore, you have to add this (from eg. fam14h asl file). Otherwise Linux will not boot (4.19.x and 5.3.x, 5.4.x...).
2. in lenovo/g505s/bootblock.c, you'll need an 'empty' bootblock_mainboard_early_init(void) function.  Of course if you'll ever need PCI debug card support, then the LPC code will need to be still fixed (eg. from Gizmo2?)

[Kyösti Mälkki]

On Fri, Dec 13, 2019 at 1:38 PM Github Hun  wrote:
> Hi,
>
> just to give a heads-up status: as of today (13.12.2019) with the current Master revision, I can confirm, that for lenovo/g505s coreboot builds and boots perfectly with ROMCC_BOOTBLOCK already removed.

Upload  the board-status, please !!
> There are two modifications are needed though:
> revise commit: 0178760 on Oct 25: 'Don't use both of _ADR and _HID' patch --> for Fam15h '_CID' is missing from:
>
> src/northbridge/amd/agesa/family15tn/acpi/northbridge.asl

Please elaborate, or better yet push a fix.
> therefore, you have to add this (from eg. fam14h asl file). Otherwise Linux will not boot (4.19.x and 5.3.x, 5.4.x...).
> 2. in lenovo/g505s/bootblock.c, you'll need an 'empty' bootblock_mainboard_early_init(void) function.  Of course if you'll ever need PCI debug card support, then the LPC code will need to be still fixed (eg. from Gizmo2?)

Empty bootblock_mainboard_early_init() is in lib/bootblock.c already.
What exactly do you think is broken with LPC?

Kyösti

[Sergej Ivanov]

Hello,
I'm back with biostar/am1ml development. I've currently tested it with
ROMCC_BOOTBLOCK, all works fine. Current board status has been uploaded.
What is the last date to submit version without ROMCC?

пт, 13 дек. 2019 г. в 15:22, Kyösti Mälkki :
> On Fri, Dec 13, 2019 at 1:38 PM Github Hun  wrote:
> > Hi,
> >
> > just to give a heads-up status: as of today (13.12.2019) with the
>
> current Master revision, I can confirm, that for lenovo/g505s coreboot
> builds and boots perfectly with ROMCC_BOOTBLOCK already removed.
>
> Upload  the board-status, please !!
> > There are two modifications are needed though:
> > revise commit: 0178760 on Oct 25: 'Don't use both of _ADR and _HID'
>
> patch --> for Fam15h '_CID' is missing from:
> > src/northbridge/amd/agesa/family15tn/acpi/northbridge.asl
>
> Please elaborate, or better yet push a fix.
> > therefore, you have to add this (from eg. fam14h asl file). Otherwise
>
> Linux will not boot (4.19.x and 5.3.x, 5.4.x...).
> > in lenovo/g505s/bootblock.c, you'll need an 'empty'
>
> bootblock_mainboard_early_init(void) function.  Of course if you'll ever
> need PCI debug card support, then the LPC code will need to be still fixed
> (eg. from Gizmo2?)
>
> Empty bootblock_mainboard_early_init() is in lib/bootblock.c already.
> What exactly do you think is broken with LPC?
>
> Kyösti
> _______________________________________________
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Kyösti Mälkki]

On Fri, Dec 13, 2019 at 10:16 PM Sergej Ivanov  wrote:
> Hello,
> I'm back with biostar/am1ml development. I've currently tested it with ROMCC_BOOTBLOCK, all works fine. Current board status has been uploaded. What is the last date to submit version without ROMCC?

Any board with ROMCC_BOOTBLOCK will be disabled from automatic
build-testing by 14th December at latest, such that ROMCC_BOOTBLOCK
removal in common code can proceed. Boards that see no activity will
be removed from the tree 31st December 2019.

Once a board has its source removed, it will face the standard review
process should someone want to bring it back. Reincarnations until
next (4.12) release might not be accepted.

Kind regards,
Kyösti Mälkki

[Github Hun]

Nothing is broken with LPC, pls. disregard my second comment...
I'll upload the status as soon as I can.
Githubhun

F2M85 serial port not working (was: Re: AMD AGESA board removals)

[Michael Büchler]

Hi Denis,

On Wed, 2019-12-11 at 01:35 +0100, Denis 'GNUtoo' Carikli wrote:
> As the serial port doesn't work (it needs to be fixed in Coreboot), I
> need to look for an alternative way to get the logs (I'll probably
> try
> finding the EHCI debug port or setting up a PCIe serial port card).

I'm using the F2M85 port as a basis for trying to port to ASUS M5A97.
Serial console works, at least until AmdInitEarly, after these changes:

- make sure the LPC controller is enabled, see hudson_lpc_port80().
Until 657d68bddc030e38bc19eb4eef07f59b5e5258e4 this was called in
f2a85-m/romstage.c

- don't set HUDSON_LEGACY_FREE (default y), otherwise
FchInitResetLpcProgram() will clear bit 6 on the LPC controller's
PCI_Reg 44h that enables serial port decoding.

I also changed the second part of sbxxx_enable_48mhzout() a bit, but
that might be specific to my board:

+       /* [1:0] clk1_sel = b10 --> 48 MHz
+        * [2]   clk1_OutputEnB = b1 --> 14M_25M_48M_OSC output
+        *                           enabled */
        reg32 = SB_MMIO_MISC32(0x40);
-       reg32 &= ~0x80u;
+       reg32 |= (1 << 1);
+       reg32 &= ~((1 << 0) | (1 << 2));
        SB_MMIO_MISC32(0x40) = reg32;

I Hope this helps.

Michael

[Denis 'GNUtoo' Carikli]

On Tue, 3 Dec 2019 19:29:48 +0200
Kyösti Mälkki  wrote:
> Hi

Hi,
> The process begins by uploading a fresh board-status result for the
> board you volunteer to work on and announce this by replying to this
> thread.

I've done that for asrock/e350m1.

Denis.