[Linaro-uefi] Platforms/ARM: Fix FVP FADT version

Message ID 1466609119-12424-1-git-send-email-graeme.gregory@linaro.org
State Accepted
Commit 697d58bd4a4d9776daf052e054170dcf8f310f65
Headers show

Commit Message

Graeme Gregory June 22, 2016, 3:25 p.m.
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(-)

Comments

Leif Lindholm June 28, 2016, 11:05 a.m. | #1
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
>
Graeme Gregory June 28, 2016, 12:11 p.m. | #2
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
>>
Ryan Harkin June 28, 2016, 12:43 p.m. | #3
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/d0126a368a1f712d1d4bf723cd9be663aba88e08

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
Al Stone June 28, 2016, 4:21 p.m. | #4
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/d0126a368a1f712d1d4bf723cd9be663aba88e08
> 
> 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
>
Ryan Harkin June 28, 2016, 4:34 p.m. | #5
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/d0126a368a1f712d1d4bf723cd9be663aba88e08
>>
>> 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
> -----------------------------------

Patch

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