MADT will now compile with v6.1 fields so we need to bump the FADT to indicate v6.1 compatability otherwise kernel will fail to parse MADT correctly and issue the error "No valid GICC entries exist".
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Graeme Gregory graeme.gregory@linaro.org --- Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl b/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl index c288ae2..b52413f 100644 --- a/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl +++ b/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl @@ -35,7 +35,7 @@
[0004] Signature : "FACP" [0004] Table Length : 0000010C -[0001] Revision : 05 +[0001] Revision : 06 [0001] Checksum : 18 [0006] Oem ID : "LINARO" [0008] Oem Table ID : "RTSMVEV8" @@ -195,3 +195,4 @@ [0001] Encoded Access Width : 01 [Byte Access:8] [0008] Address : 0000000000000000
+[0008] Hypervisor ID : 0000000000000000
On 06/22/2016 10:25 AM, Graeme Gregory wrote:
MADT will now compile with v6.1 fields so we need to bump the FADT to indicate v6.1 compatability otherwise kernel will fail to parse MADT correctly and issue the error "No valid GICC entries exist".
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Graeme Gregory graeme.gregory@linaro.org
Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl b/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl index c288ae2..b52413f 100644 --- a/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl +++ b/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl @@ -35,7 +35,7 @@
[0004] Signature : "FACP" [0004] Table Length : 0000010C -[0001] Revision : 05 +[0001] Revision : 06 [0001] Checksum : 18 [0006] Oem ID : "LINARO" [0008] Oem Table ID : "RTSMVEV8" @@ -195,3 +195,4 @@ [0001] Encoded Access Width : 01 [Byte Access:8] [0008] Address : 0000000000000000
+[0008] Hypervisor ID : 0000000000000000
This fixes a boot failure on the foundation model with an ACPI 4.7rc4 kernel I've been testing (on a fedora root fs).
There are assorted other ugly messages including the "GICv3 system registers enabled, broken firmware!" message, but it boots!
Tested-by: Jeremy Linton jeremy.linton@arm.com
Thanks!
So, the fix looks good, but clearly this is one of those lock-step updates...
It does not however seem like the required acpica-tools update breaks any of the existing public builds, so I guess it's just time for another bump.
Acpica-tools 20160527 is now the one to use.
Thanks, pushed!
On 22 June 2016 at 16:25, Graeme Gregory graeme.gregory@linaro.org wrote:
MADT will now compile with v6.1 fields so we need to bump the FADT to indicate v6.1 compatability otherwise kernel will fail to parse MADT correctly and issue the error "No valid GICC entries exist".
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Graeme Gregory graeme.gregory@linaro.org
Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl b/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl index c288ae2..b52413f 100644 --- a/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl +++ b/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl @@ -35,7 +35,7 @@
[0004] Signature : "FACP" [0004] Table Length : 0000010C -[0001] Revision : 05 +[0001] Revision : 06 [0001] Checksum : 18 [0006] Oem ID : "LINARO" [0008] Oem Table ID : "RTSMVEV8" @@ -195,3 +195,4 @@ [0001] Encoded Access Width : 01 [Byte Access:8] [0008] Address : 0000000000000000
+[0008] Hypervisor ID : 0000000000000000
2.8.1
On 28 June 2016 at 12:05, Leif Lindholm leif.lindholm@linaro.org wrote:
So, the fix looks good, but clearly this is one of those lock-step updates...
It does not however seem like the required acpica-tools update breaks any of the existing public builds, so I guess it's just time for another bump.
Acpica-tools 20160527 is now the one to use.
Thanks, pushed!
Yes, this is why I think I made a mistake choosing .asl. These lock-step upgrades are a pain and avoided using the aslc macros.
Graeme
On 22 June 2016 at 16:25, Graeme Gregory graeme.gregory@linaro.org wrote:
MADT will now compile with v6.1 fields so we need to bump the FADT to indicate v6.1 compatability otherwise kernel will fail to parse MADT correctly and issue the error "No valid GICC entries exist".
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Graeme Gregory graeme.gregory@linaro.org
Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl b/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl index c288ae2..b52413f 100644 --- a/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl +++ b/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl @@ -35,7 +35,7 @@
[0004] Signature : "FACP" [0004] Table Length : 0000010C -[0001] Revision : 05 +[0001] Revision : 06 [0001] Checksum : 18 [0006] Oem ID : "LINARO" [0008] Oem Table ID : "RTSMVEV8" @@ -195,3 +195,4 @@ [0001] Encoded Access Width : 01 [Byte Access:8] [0008] Address : 0000000000000000
+[0008] Hypervisor ID : 0000000000000000
2.8.1
On 28 June 2016 at 13:11, G Gregory graeme.gregory@linaro.org wrote:
On 28 June 2016 at 12:05, Leif Lindholm leif.lindholm@linaro.org wrote:
So, the fix looks good, but clearly this is one of those lock-step updates...
It does not however seem like the required acpica-tools update breaks any of the existing public builds, so I guess it's just time for another bump.
Acpica-tools 20160527 is now the one to use.
I'm testing with this commit right now:
https://github.com/acpica/acpica/commit/d0126a368a1f712d1d4bf723cd9be663aba8...
A quick busybox build on FVP and Juno seems to confirm that it's fine with the existing code I use.
Thanks, pushed!
Yes, this is why I think I made a mistake choosing .asl. These lock-step upgrades are a pain and avoided using the aslc macros.
Graeme
On 22 June 2016 at 16:25, Graeme Gregory graeme.gregory@linaro.org wrote:
MADT will now compile with v6.1 fields so we need to bump the FADT to indicate v6.1 compatability otherwise kernel will fail to parse MADT correctly and issue the error "No valid GICC entries exist".
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Graeme Gregory graeme.gregory@linaro.org
Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl b/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl index c288ae2..b52413f 100644 --- a/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl +++ b/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl @@ -35,7 +35,7 @@
[0004] Signature : "FACP" [0004] Table Length : 0000010C -[0001] Revision : 05 +[0001] Revision : 06 [0001] Checksum : 18 [0006] Oem ID : "LINARO" [0008] Oem Table ID : "RTSMVEV8" @@ -195,3 +195,4 @@ [0001] Encoded Access Width : 01 [Byte Access:8] [0008] Address : 0000000000000000
+[0008] Hypervisor ID : 0000000000000000
2.8.1
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
On 06/28/2016 06:43 AM, Ryan Harkin wrote:
On 28 June 2016 at 13:11, G Gregory graeme.gregory@linaro.org wrote:
On 28 June 2016 at 12:05, Leif Lindholm leif.lindholm@linaro.org wrote:
So, the fix looks good, but clearly this is one of those lock-step updates...
It does not however seem like the required acpica-tools update breaks any of the existing public builds, so I guess it's just time for another bump.
Acpica-tools 20160527 is now the one to use.
I'm testing with this commit right now:
https://github.com/acpica/acpica/commit/d0126a368a1f712d1d4bf723cd9be663aba8...
A quick busybox build on FVP and Juno seems to confirm that it's fine with the existing code I use.
Are these tools always built from source? Any particular reason?
Both Debian and Fedora have been updated to this version. I usually update the packages about a week after the upstream release (they sometimes have to patch them so I wait for the source to settle a bit). I keep the Linaro package tree updated, too, so that whenever Jenkins gets fixed [0], the package can be rebuilt from there, as well [1].
[0] https://bugs.linaro.org/show_bug.cgi?id=953 [1] https://git.linaro.org/people/al.stone/acpica-tools.git
Thanks, pushed!
Yes, this is why I think I made a mistake choosing .asl. These lock-step upgrades are a pain and avoided using the aslc macros.
Graeme
On 22 June 2016 at 16:25, Graeme Gregory graeme.gregory@linaro.org wrote:
MADT will now compile with v6.1 fields so we need to bump the FADT to indicate v6.1 compatability otherwise kernel will fail to parse MADT correctly and issue the error "No valid GICC entries exist".
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Graeme Gregory graeme.gregory@linaro.org
Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl b/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl index c288ae2..b52413f 100644 --- a/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl +++ b/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl @@ -35,7 +35,7 @@
[0004] Signature : "FACP" [0004] Table Length : 0000010C -[0001] Revision : 05 +[0001] Revision : 06 [0001] Checksum : 18 [0006] Oem ID : "LINARO" [0008] Oem Table ID : "RTSMVEV8" @@ -195,3 +195,4 @@ [0001] Encoded Access Width : 01 [Byte Access:8] [0008] Address : 0000000000000000
+[0008] Hypervisor ID : 0000000000000000
2.8.1
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
On 28 June 2016 at 17:21, Al Stone al.stone@linaro.org wrote:
On 06/28/2016 06:43 AM, Ryan Harkin wrote:
On 28 June 2016 at 13:11, G Gregory graeme.gregory@linaro.org wrote:
On 28 June 2016 at 12:05, Leif Lindholm leif.lindholm@linaro.org wrote:
So, the fix looks good, but clearly this is one of those lock-step updates...
It does not however seem like the required acpica-tools update breaks any of the existing public builds, so I guess it's just time for another bump.
Acpica-tools 20160527 is now the one to use.
I'm testing with this commit right now:
https://github.com/acpica/acpica/commit/d0126a368a1f712d1d4bf723cd9be663aba8...
A quick busybox build on FVP and Juno seems to confirm that it's fine with the existing code I use.
Are these tools always built from source? Any particular reason?
Yes, because I need specific versions depending on what version of the code I'm building.
Sometimes, old versions won't build newer code and newer versions won't build older code. And I can't rely on the user installing the correct version: it's gone wrong for me several times and I've had a glut of support requests. I've had none since I started building from source.
Both Debian and Fedora have been updated to this version. I usually update the packages about a week after the upstream release (they sometimes have to patch them so I wait for the source to settle a bit). I keep the Linaro package tree updated, too, so that whenever Jenkins gets fixed [0], the package can be rebuilt from there, as well [1].
[0] https://bugs.linaro.org/show_bug.cgi?id=953 [1] https://git.linaro.org/people/al.stone/acpica-tools.git
Thanks, pushed!
Yes, this is why I think I made a mistake choosing .asl. These lock-step upgrades are a pain and avoided using the aslc macros.
Graeme
On 22 June 2016 at 16:25, Graeme Gregory graeme.gregory@linaro.org wrote:
MADT will now compile with v6.1 fields so we need to bump the FADT to indicate v6.1 compatability otherwise kernel will fail to parse MADT correctly and issue the error "No valid GICC entries exist".
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Graeme Gregory graeme.gregory@linaro.org
Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl b/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl index c288ae2..b52413f 100644 --- a/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl +++ b/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/facp.asl @@ -35,7 +35,7 @@
[0004] Signature : "FACP" [0004] Table Length : 0000010C -[0001] Revision : 05 +[0001] Revision : 06 [0001] Checksum : 18 [0006] Oem ID : "LINARO" [0008] Oem Table ID : "RTSMVEV8" @@ -195,3 +195,4 @@ [0001] Encoded Access Width : 01 [Byte Access:8] [0008] Address : 0000000000000000
+[0008] Hypervisor ID : 0000000000000000
2.8.1
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
-- ciao, al
Al Stone Software Engineer Linaro Enterprise Group al.stone@linaro.org
-
Al Stone -
G Gregory -
Graeme Gregory
-
Jeremy Linton -
Leif Lindholm -
Ryan Harkin