Re: [RFC 1/4] arm64: amd-seattle: Adding device tree for AMD Seattle platform
From: Suravee Suthikulpanit
Date: Fri Oct 24 2014 - 08:08:33 EST
On 10/10/2014 8:45 AM, Mark Rutland wrote:
Hi Suravee,
On Sun, Sep 28, 2014 at 09:53:27PM +0100, suravee.suthikulpanit@xxxxxxx wrote:
From: Suravee Suthikulpanit <Suravee.Suthikulpanit@xxxxxxx>
Initial revision of device tree for AMD Seattle platform
To check: how is it possible to make use of a DTB generated from this
dts? Can a user update the DTB used by the Seattle firmware?
In the current FW, there is a mechanism that users can modify and
provide UEFI with the updated device tree to override the one that comes
with Seattle firmware.
[...];
+
+ timer@1,1060000 {
+ compatible = "arm,standalone_a5_twd";
+ reg = <0 0x1060000 0 0x40>;
+ interrupts =
+ <0 378 4>,
+ <0 379 4>;
+ };
This binding does not exist in mainline.
I am removing this.
+
+ ccp: ccp@1,00100000 {
+ compatible = "amd,ccp-seattle-v1a";
+ reg = <0 0x00100000 0 0x10000>;
+ interrupts = <0 3 4>;
+ dma-coherent;
+ };
Nor does this.
The binding for this one is here
(http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/crypto/amd-ccp.txt).
> [....]
+ linux,pci-probe-only;
Why is this necessary?
This was defined in the PCI Generic Host Controller binding here
(http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/pci/host-generic-pci.txt).
+ };
+
+ aliases {
+ serial0 = &v2m_serial0;
+ };
+
+ /* Note: This entry is modified by UEFI */
In what way is this modified?
1. UEFI would basically take out certain CPUs and modify the cpu-map
accordingly.
2. Change method to psci-0.2 when support is in place.
3. Update release address.
Actually, the "cpus" entry should/will be fully auto generated by UEFI
in the future BIOS. I think I'll be taking this out completely for now.
[...]
+
+ /* Note: This entry is modified by UEFI */
+ memory@8000000000 {
+ device_type = "memory";
+ reg = <0x00000080 0x00000000 0x1 0x00000000>; /* 4GB */
+ };
Why does UEFI modify this? When booted via UEFI we use the UEFI memory
map.
True. But for non-EFI boot (as fallback), we still need this. UEFI will
update the amount of detected memory.
Actually, same here as the "cpus", this entry should/will go away
completely from the static DT, and UEFI will auto-generate this in the
future firmware.
Thanks,
Suravee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/