Restore broken ThunderX support in 12 by MFCing r343764?

[kraileth at elderlinux.org]

Hi,

FreeBSD was working well on 11.x but stopped with r336520 when  
vt_efifb was added to GENERIC on ARM64. As pointed out by John F Carr,  
all it takes to fix this locally, is setting the tunable  
hw.syscons.disable  
(https://lists.freebsd.org/pipermail/freebsd-arm/2019-February/019422.html).

However -CURRENT broke _twice_ during the development phase of 12.  
After a few more nights of building kernels to exactly nail down the  
second issue, I have the commit that broke support and the one that  
restored it uncovered:

While r338537's commit message says that it's increasing two values  
because of ThunderX, after the commit the kernel wouldn't boot any  
longer even with the tunable set. Some time later commit r343764  
(targeting ThunderX2) accidentally fixed the problem for ThunderX,  
too. After that point setting the tunable results in a working system  
again.

However the second commit was made after 12 was branched off and so to  
this day 12 is completely broken. I've confirmed that both 12-STABLE  
and 12.0-RELEASE work when the following patch is applied before  
building the kernel:

------
--- sys/arm/arm/physmem.c.orig  2019-02-17 08:47:05.675448000 +0100
+++ sys/arm/arm/physmem.c       2019-02-17 08:48:53.209050000 +0100
@@ -29,6 +29,7 @@
  #include <sys/cdefs.h>
  __FBSDID("$FreeBSD: stable/12/sys/arm/arm/physmem.c 341760  
2018-12-09 06:46:53Z mmel $");

+#include "opt_acpi.h"
  #include "opt_ddb.h"

  /*
@@ -48,8 +49,13 @@
   * that can be allocated, or both, depending on the exclusion flags  
associated
   * with the region.
   */
+#ifdef DEV_ACPI
+#define MAX_HWCNT       32      /* ACPI needs more regions */
+#define MAX_EXCNT       32
+#else
  #define        MAX_HWCNT       16
  #define        MAX_EXCNT       16
+#endif

  #if defined(__arm__)
  #define        MAX_PHYS_ADDR   0xFFFFFFFFull
------

Not being a developer though, I cannot judge if this cannot be MFC'd  
into 12-STABLE due to making invasive changes or if it simply never  
was because it was thought to be an improvement for 13 only and not an  
actually pretty vital fix for 12.

If the changes from r343764 can be applied to 12-STABLE that would  
mean a future 12.1 could run on ThunderX again. If not, the reference  
platform for server-class ARM64 would be broken in all of 12 which  
would be rather unfortunate.

Is there a chance to get the fix into 12-STABLE?

Regards,
Michael