On 1 July 2016 at 21:50, Jeremy Linton jeremy.linton@arm.com wrote:
On 06/28/2016 10:35 AM, Ryan Harkin wrote:
On 28 June 2016 at 15:03, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 24 June 2016 at 18:37, Ryan Harkin ryan.harkin@linaro.org wrote:
On 24 June 2016 at 11:29, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
This upgrades the MADT table so that it exposes the GIC as a v3. The virtual base address and interrupt, and the hypervisor base address are corrected as well.
Since the Foundation model has 4 cores at the most, and since refactoring this code to update the ACPI tables dynamically based on the actual core count is more trouble that its worth, remove the second cluster while we are at it.
I know I said I wasn't bothered about ACPI, and I'm not, but doesn't the AEMv8 model have 2 clusters of 4 cpus?
At the most, yes. My assumption is that the overhead of having the firmware figure this out at runtime, and patch the ACPI tables accordingly is not worth the trouble. FVP Base can run fine with 4 CPUs (or only one), so it is simply a matter of choosing a reasonable sweet spot.
Fair enough, I have no objection to that. I was mostly thinking about the DTB: people decided the kernel runs fine if the extra CPUs are missing in the model, so it has 8 CPUs and Foundation just runs without them.
I haven't had a chance to test this patch, but I imagine if everything is working ok the same thing should happen with ACPI. If there are only 4 cores, and the MADT has 8 then they just fail to come online and the kernel prints some ugly messages but everything works..
Indeed.
Really, we should be marking the unused ones offline and setting the GIC version in the table (eventually based on the command line parms). Something like Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c PlatformUpdateTables() seems like a good starting point. Its fairly common (and might actually be required, I should check the spec) to allocate table entries for future/hotplug cpus in the MADT and just leave them offline.
We have code already that detects the GIC version in the FVP platform: we use it to select the DTB blob if the image has any built in. So it should be fairly easy to use the same information to set the GIC version.
Obtaining the core count is not that straightforward, I'm afraid.
I can have a stab at implementing this, but that would require switching to .aslc format first. @Graeme: any updates there?