Allwinner A64/H5 SoCs come with a SID controller like the one in H3, but
without the silicon bug that makes the initial value at 0x200 wrong, so
the value at 0x200 can be directly read.
Add support for this kind of SID controller.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt | 1 +
drivers/nvmem/sunxi_sid.c | 6 ++++++
2 files changed, 7 insertions(+)
From: Maxime Ripard <hidden> Date: 2017-09-19 08:20:33
On Mon, Sep 18, 2017 at 11:42:04PM +0800, Icenowy Zheng wrote:
quoted hunk
Allwinner A64/H5 SoCs come with a SID controller like the one in H3, but
without the silicon bug that makes the initial value at 0x200 wrong, so
the value at 0x200 can be directly read.
Add support for this kind of SID controller.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt | 1 +
drivers/nvmem/sunxi_sid.c | 6 ++++++
2 files changed, 7 insertions(+)
How did you get those values?
Also, it's reported that the SID can only be accessed in secure mode,
did you test it?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170919/fed1212f/attachment.sig>
? 2017?9?19? GMT+08:00 ??4:20:19, Maxime Ripard [off-list ref] ??:
On Mon, Sep 18, 2017 at 11:42:04PM +0800, Icenowy Zheng wrote:
quoted
Allwinner A64/H5 SoCs come with a SID controller like the one in H3,
but
quoted
without the silicon bug that makes the initial value at 0x200 wrong,
so
quoted
the value at 0x200 can be directly read.
Add support for this kind of SID controller.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt | 1
Also, it's reported that the SID can only be accessed in secure mode,
did you test it?
Yes, however the secure is broken again, and this only
happen if Secure Boot bit is burned.
If it's really burned, we will have no clean way to access SID.
From: Maxime Ripard <hidden> Date: 2017-09-19 11:55:45
On Tue, Sep 19, 2017 at 04:23:14PM +0800, Icenowy Zheng wrote:
? 2017?9?19? GMT+08:00 ??4:20:19, Maxime Ripard [off-list ref] ??:
quoted
On Mon, Sep 18, 2017 at 11:42:04PM +0800, Icenowy Zheng wrote:
quoted
Allwinner A64/H5 SoCs come with a SID controller like the one in H3,
but
quoted
without the silicon bug that makes the initial value at 0x200 wrong,
so
quoted
the value at 0x200 can be directly read.
Add support for this kind of SID controller.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt | 1
On Tue, Sep 19, 2017 at 04:23:14PM +0800, Icenowy Zheng wrote:
quoted
? 2017?9?19? GMT+08:00 ??4:20:19, Maxime Ripard
[off-list ref] ??:
quoted
On Mon, Sep 18, 2017 at 11:42:04PM +0800, Icenowy Zheng wrote:
quoted
Allwinner A64/H5 SoCs come with a SID controller like the one in H3,
but
quoted
without the silicon bug that makes the initial value at 0x200 wrong,
so
quoted
the value at 0x200 can be directly read.
Add support for this kind of SID controller.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt | 1
This should be mentionned in your commit log then.
P.S. the 0x200 offset is not in the header, but as a proven experience
on new generation SID controllers.
quoted
quoted
Also, it's reported that the SID can only be accessed in secure
mode, did you test it?
Yes, however the secure is broken again, and this only
happen if Secure Boot bit is burned.
Is broken again, meaning?
As far as I know, the only breakage we've had is on the A80 / A83T,
but we don't have anything like it on the A64, do we?
A80/A83T is not the *only* breakage, but the *most serious* breakage,
which affected correctly using SMP in non-secure.
Newer Allwinner SoCs doesn't have the GIC broken, but the TZPC still
doesn't work when not Secure Boot, which means that all peripherals
set to secure-only can still be accessed. Affected SoCs are at least
H3, H5, A64.
It seems that the registers marked as secure-only inside PRCM still
works -- however this still has no meaningful secure/non-secure
seperation, as the secure setting register in PRCM is not
secure-only at least on SoCs without SB enabled.
quoted
If it's really burned, we will have no clean way to access SID.
Well, in such a case we shouldn't access it either, so..
We will need the THS calibration data.
Maybe a custom call to ATF can be created, but I consider it dirty.
From: Rob Herring <robh@kernel.org> Date: 2017-09-21 23:12:44
On Mon, Sep 18, 2017 at 11:42:04PM +0800, Icenowy Zheng wrote:
Allwinner A64/H5 SoCs come with a SID controller like the one in H3, but
without the silicon bug that makes the initial value at 0x200 wrong, so
the value at 0x200 can be directly read.
Add support for this kind of SID controller.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt | 1 +
drivers/nvmem/sunxi_sid.c | 6 ++++++
2 files changed, 7 insertions(+)
On Mon, Sep 18, 2017 at 11:42:04PM +0800, Icenowy Zheng wrote:
quoted
Allwinner A64/H5 SoCs come with a SID controller like the one in H3, but
without the silicon bug that makes the initial value at 0x200 wrong, so
the value at 0x200 can be directly read.
Add support for this kind of SID controller.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt | 1 +
drivers/nvmem/sunxi_sid.c | 6 ++++++
2 files changed, 7 insertions(+)
TBH, I don't fully understand the soc specifics here, but if you want me
to queue this patch, I would need an ack from Maxime.
thanks,
srini