Re: Keystone Issue

[CodeWiz2280 <codewiz2280@xxxxxxxxx>]

On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier <maz@xxxxxxxxxx> wrote:
>
> On 2020-06-15 20:14, CodeWiz2280 wrote:
>
> [...]
>
> > Also, the latest linux kernel still has the X-Gene storm distributor
> > address as "0x78010000" in the device tree, which is what the Xen code
> > considers a match with the old firmware.  What were the addresses for
> > the device tree supposed to be changed to?
>
> We usually don't care, as the GIC address is provided by the bootloader,
> whether via DT or ACPI (this is certainly what happens on Mustang).
> Whatever is still in the kernel tree is just as dead as the platform it
> describes.
>
> > Is my understanding
> > correct that there is a different base address required to access the
> > "non-secure" region instead of the "secure" 0x78010000 region?  I'm
> > trying to see if there are corresponding different addresses for the
> > keystone K2E, but haven't found them yet in the manuals.
>
> There is no such address. Think of the NS bit as an *address space*
> identifier.
>
> The only reason XGene presents the NS part of the GIC at a different
> address is because XGene is broken enough not to have EL3, hence no
> secure mode. To wire the GIC (and other standard ARM IPs) to the core,
> the designers simply used the CPU NS signal as an address bit.
>
> On your platform, the NS bit does exist. I strongly suppose that it
> isn't wired to the GIC. Please talk to your SoC vendor for whether iot
> is possible to work around this.
>
I do have a question about this out to TI, but at least this method
gives me something to work with in the meantime.  I was just looking
to confirm that there wouldn't be any other undesirable side effects
with Dom0 or DomU when using it.  Was there an actual FPGA for the
X-Gene that needed to be updated which controlled the GIC access?  Or
by firmware do you mean the boot loader (e.g. uboot).  Thanks for the
support so far to all.

>          M.
> --
> Jazz is not dead. It just smells funny...