* [PATCH 2/4] net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >= num_of_ports
From: Andrew Lunn @ 2016-12-19 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161219141610.30934-3-romain.perier@free-electrons.com>
On Mon, Dec 19, 2016 at 03:16:07PM +0100, Romain Perier wrote:
> Some Marvell ethernet switches have internal ethernet transceivers with
> hardcoded phy addresses. These addresses can be grearer than the number
> of ports or its value might be different than the associated port number.
> This is for example the case for MV88E6341 that has 6 ports and internal
> Port 1 to Port4 PHYs mapped at SMI addresses from 0x11 to 0x14.
>
> This commits fixes the issue by removing the condition in MDIO callbacks.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
So it is not quite compatible with the 6352. Thanks Marvell :-(
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH 1/4] net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address 0x1
From: Romain Perier @ 2016-12-19 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161219143848.GA10048@lunn.ch>
Hi Andrew,
Le 19/12/2016 ? 15:38, Andrew Lunn a ?crit :
> On Mon, Dec 19, 2016 at 03:16:06PM +0100, Romain Perier wrote:
>> Currently, the function mv88e6xxx_smi_init() returns -EINVAL if the bit
>> zero of sw_addr is 0x1. However, on some platforms, ethernet switches
>> are configured in Multi chip addressing mode and available at MDIO
>> address 0x1.
>
> Hi Romain
>
> What branch is this against? net-next?
Until last friday it was based onto next-20161216, I rebased onto the
torvalds's tree this morning (so ~4.10-pre-rc1).
>
> Please see:
>
> https://www.spinics.net/lists/netdev/msg409156.html
Oh, it's already fixed, good. I did not see this patch :)
>
> It would be nicer to use Volodymyr, since it has been reviewed.
As the fix is already there, I will use it, sure.
Thanks,
Romain
^ permalink raw reply
* [PATCH 3/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341/88E6141
From: Romain Perier @ 2016-12-19 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161219145227.GC10048@lunn.ch>
Hi Andrew,
Le 19/12/2016 ? 15:52, Andrew Lunn a ?crit :
> Hi Romain
>
>> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
>> index 76d944e..72ba24b 100644
>> --- a/drivers/net/dsa/mv88e6xxx/chip.c
>> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
>> @@ -4086,6 +4086,20 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
>> .ops = &mv88e6321_ops,
>> },
>>
>> + [MV88E6341] = {
>> + .prod_num = PORT_SWITCH_ID_PROD_NUM_6341,
>> + .family = MV88E6XXX_FAMILY_6352,
>> + .name = "Marvell 88E6341",
>> + .num_databases = 4096,
>> + .num_ports = 6,
>> + .port_base_addr = 0x10,
>> + .global1_addr = 0x1b,
>> + .age_time_coeff = 15000,
>> + .tag_protocol = DSA_TAG_PROTO_EDSA,
>> + .flags = MV88E6XXX_FLAGS_FAMILY_6352,
>> + .ops = &mv88e6352_ops,
>
> Even if it i 100% compatible with the 6532, you should still add an
> ops structure for it. All chips have their own, even when the are
> exactly the same as other in the family.
Ack, I will fix this.
>
>> --- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
>> +++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
>> @@ -86,6 +86,7 @@
>> #define PORT_SWITCH_ID_PROD_NUM_6097 0x099
>> #define PORT_SWITCH_ID_PROD_NUM_6131 0x106
>> #define PORT_SWITCH_ID_PROD_NUM_6320 0x115
>> +#define PORT_SWITCH_ID_PROD_NUM_6341 0x340
>> #define PORT_SWITCH_ID_PROD_NUM_6123 0x121
>> #define PORT_SWITCH_ID_PROD_NUM_6161 0x161
>
> Ah, err..
>
> These should be in numerical order of the macro.
> PORT_SWITCH_ID_PROD_NUM_6320 is however in the wrong place. Please
> put the 6341 after the 6321.
good catch, ok.
Thanks,
Romain
^ permalink raw reply
* [PATCH 4/4] arm64: dts: marvell: Add ethernet switch definition for the EXPRESSObin
From: Thomas Petazzoni @ 2016-12-19 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161219141610.30934-5-romain.perier@free-electrons.com>
Hello,
On Mon, 19 Dec 2016 15:16:09 +0100, Romain Perier wrote:
> This defines and enables the Marvell ethernet switch MVE886341 on the
> Marvell EXPRESSObin board.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
I didn't want to make this (silly) comment but since you got another
comment that will let you send a new iteration, here is my silly
comment: the name of the board is EspressoBin, not ExpressoBin.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/4] net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address 0x1
From: Andrew Lunn @ 2016-12-19 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <292d4f15-c58b-3565-26ec-98a025b6adb3@free-electrons.com>
On Mon, Dec 19, 2016 at 03:56:34PM +0100, Romain Perier wrote:
> Hi Andrew,
>
> Le 19/12/2016 ? 15:38, Andrew Lunn a ?crit :
> >On Mon, Dec 19, 2016 at 03:16:06PM +0100, Romain Perier wrote:
> >>Currently, the function mv88e6xxx_smi_init() returns -EINVAL if the bit
> >>zero of sw_addr is 0x1. However, on some platforms, ethernet switches
> >>are configured in Multi chip addressing mode and available at MDIO
> >>address 0x1.
> >
> >Hi Romain
> >
> >What branch is this against? net-next?
>
> Until last friday it was based onto next-20161216, I rebased onto
> the torvalds's tree this morning (so ~4.10-pre-rc1).
This patchset is 80% networking. So please see:
Documentation/networking/netdev-FAQ.txt
> Oh, it's already fixed, good. I did not see this patch :)
>
> >
> >It would be nicer to use Volodymyr, since it has been reviewed.
>
>
> As the fix is already there, I will use it, sure.
Im not sure what happened to it. It might of fallen through the
cracks. Lets see what Volodymyr says. It might need resubmitting once
netdev reopens.
Andrew
^ permalink raw reply
* [PATCH 4/4] arm64: dts: marvell: Add ethernet switch definition for the EXPRESSObin
From: Romain Perier @ 2016-12-19 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161219155819.4cdf0f40@free-electrons.com>
Hi,
Le 19/12/2016 ? 15:58, Thomas Petazzoni a ?crit :
> Hello,
>
> On Mon, 19 Dec 2016 15:16:09 +0100, Romain Perier wrote:
>> This defines and enables the Marvell ethernet switch MVE886341 on the
>> Marvell EXPRESSObin board.
>>
>> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
>
> I didn't want to make this (silly) comment but since you got another
> comment that will let you send a new iteration, here is my silly
> comment: the name of the board is EspressoBin, not ExpressoBin.
>
> Thanks!
>
> Thomas
>
Ack for the two feedback (I don't know why I have replaced "es" by "ex"
:/, anyway...)
Thanks,
Romain
^ permalink raw reply
* [PATCH net 0/3] Fix integration of eee-broken-modes
From: Jerome Brunet @ 2016-12-19 15:05 UTC (permalink / raw)
To: linux-arm-kernel
The purpose of this series is to fix the integration of the ethernet phy
property "eee-broken-modes" [0]
The v3 of this series has been merged, missing a fix (error reported by
kbuild robot) available in the v4 [1]
More importantly, Florian opposed adding a DT property mapping a device
register this directly [2]. The concern was that the property could be
abused to implement platform configuration policy. After discussing it,
I think we agreed that such information about the HW (defect) should appear
in the platform DT. However, the preferred way is to add a boolean property
for each EEE broken mode.
[0]: http://lkml.kernel.org/r/1480326409-25419-1-git-send-email-jbrunet at baylibre.com
[1]: http://lkml.kernel.org/r/1480348229-25672-1-git-send-email-jbrunet at baylibre.com
[2]: http://lkml.kernel.org/r/e14a3b0c-dc34-be14-48b3-518a0ad0c080 at gmail.com
Jerome Brunet (3):
net: phy: fix sign type error in genphy_config_eee_advert
net: phy: use boolean dt properties for eee broken modes
dt: bindings: net: use boolean dt properties for eee broken modes
Documentation/devicetree/bindings/net/phy.txt | 10 ++++++++--
drivers/net/phy/phy_device.c | 22 +++++++++++++++++-----
include/dt-bindings/net/mdio.h | 19 -------------------
3 files changed, 25 insertions(+), 26 deletions(-)
delete mode 100644 include/dt-bindings/net/mdio.h
--
2.7.4
^ permalink raw reply
* [PATCH net 1/3] net: phy: fix sign type error in genphy_config_eee_advert
From: Jerome Brunet @ 2016-12-19 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482159938-13239-1-git-send-email-jbrunet@baylibre.com>
In genphy_config_eee_advert, the return value of phy_read_mmd_indirect is
checked to know if the register could be accessed but the result is
assigned to a 'u32'.
Changing to 'int' to correctly get errors from phy_read_mmd_indirect.
Fixes: d853d145ea3e ("net: phy: add an option to disable EEE advertisement")
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/net/phy/phy_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 9c06f8028f0c..ee5ebadb1463 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1187,8 +1187,8 @@ static int genphy_config_advert(struct phy_device *phydev)
*/
static int genphy_config_eee_advert(struct phy_device *phydev)
{
- u32 broken = phydev->eee_broken_modes;
- u32 old_adv, adv;
+ int broken = phydev->eee_broken_modes;
+ int old_adv, adv;
/* Nothing to disable */
if (!broken)
--
2.7.4
^ permalink raw reply related
* [PATCH net 2/3] net: phy: use boolean dt properties for eee broken modes
From: Jerome Brunet @ 2016-12-19 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482159938-13239-1-git-send-email-jbrunet@baylibre.com>
The patches regarding eee-broken-modes was merged before all people
involved could find an agreement on the best way to move forward.
While we agreed on having a DT property to mark particular modes as broken,
the value used for eee-broken-modes mapped the phy register in very direct
way. Because of this, the concern is that it could be used to implement
configuration policies instead of describing a broken HW.
In the end, having a boolean property for each mode seems to be preferred
over one bit field value mapping the register (too) directly.
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/net/phy/phy_device.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index ee5ebadb1463..92b08383cafa 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1665,7 +1665,7 @@ static void of_set_phy_supported(struct phy_device *phydev)
static void of_set_phy_eee_broken(struct phy_device *phydev)
{
struct device_node *node = phydev->mdio.dev.of_node;
- u32 broken;
+ u32 broken = 0;
if (!IS_ENABLED(CONFIG_OF_MDIO))
return;
@@ -1673,8 +1673,20 @@ static void of_set_phy_eee_broken(struct phy_device *phydev)
if (!node)
return;
- if (!of_property_read_u32(node, "eee-broken-modes", &broken))
- phydev->eee_broken_modes = broken;
+ if (of_property_read_bool(node, "eee-broken-100tx"))
+ broken |= MDIO_EEE_100TX;
+ if (of_property_read_bool(node, "eee-broken-1000t"))
+ broken |= MDIO_EEE_1000T;
+ if (of_property_read_bool(node, "eee-broken-10gt"))
+ broken |= MDIO_EEE_10GT;
+ if (of_property_read_bool(node, "eee-broken-1000kx"))
+ broken |= MDIO_EEE_1000KX;
+ if (of_property_read_bool(node, "eee-broken-10gkx4"))
+ broken |= MDIO_EEE_10GKX4;
+ if (of_property_read_bool(node, "eee-broken-10gkr"))
+ broken |= MDIO_EEE_10GKR;
+
+ phydev->eee_broken_modes = broken;
}
/**
--
2.7.4
^ permalink raw reply related
* [PATCH net 3/3] dt: bindings: net: use boolean dt properties for eee broken modes
From: Jerome Brunet @ 2016-12-19 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482159938-13239-1-git-send-email-jbrunet@baylibre.com>
The patches regarding eee-broken-modes was merged before all people
involved could find an agreement on the best way to move forward.
While we agreed on having a DT property to mark particular modes as broken,
the value used for eee-broken-modes mapped the phy register in very direct
way. Because of this, the concern is that it could be used to implement
configuration policies instead of describing a broken HW.
In the end, having a boolean property for each mode seems to be preferred
over one bit field value mapping the register (too) directly.
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
Documentation/devicetree/bindings/net/phy.txt | 10 ++++++++--
include/dt-bindings/net/mdio.h | 19 -------------------
2 files changed, 8 insertions(+), 21 deletions(-)
delete mode 100644 include/dt-bindings/net/mdio.h
diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
index 54749b60a466..ff1bc4b1bb3b 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -38,8 +38,14 @@ Optional Properties:
- enet-phy-lane-swap: If set, indicates the PHY will swap the TX/RX lanes to
compensate for the board being designed with the lanes swapped.
-- eee-broken-modes: Bits to clear in the MDIO_AN_EEE_ADV register to
- disable EEE broken modes.
+- eee-broken-100tx:
+- eee-broken-1000t:
+- eee-broken-10gt:
+- eee-broken-1000kx:
+- eee-broken-10gkx4:
+- eee-broken-10gkr:
+ Mark the corresponding energy efficient ethernet mode as broken and
+ request the ethernet to stop advertising it.
Example:
diff --git a/include/dt-bindings/net/mdio.h b/include/dt-bindings/net/mdio.h
deleted file mode 100644
index 99c6d903d439..000000000000
--- a/include/dt-bindings/net/mdio.h
+++ /dev/null
@@ -1,19 +0,0 @@
-/*
- * This header provides generic constants for ethernet MDIO bindings
- */
-
-#ifndef _DT_BINDINGS_NET_MDIO_H
-#define _DT_BINDINGS_NET_MDIO_H
-
-/*
- * EEE capability Advertisement
- */
-
-#define MDIO_EEE_100TX 0x0002 /* 100TX EEE cap */
-#define MDIO_EEE_1000T 0x0004 /* 1000T EEE cap */
-#define MDIO_EEE_10GT 0x0008 /* 10GT EEE cap */
-#define MDIO_EEE_1000KX 0x0010 /* 1000KX EEE cap */
-#define MDIO_EEE_10GKX4 0x0020 /* 10G KX4 EEE cap */
-#define MDIO_EEE_10GKR 0x0040 /* 10G KR EEE cap */
-
-#endif
--
2.7.4
^ permalink raw reply related
* [PATCH 1/4] net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address 0x1
From: Andrew Lunn @ 2016-12-19 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABHmqqDqhJa6N=Ayu-GFNyp4g90dXzTje6o8qfCEP2DacCFWdQ@mail.gmail.com>
On Mon, Dec 19, 2016 at 04:04:32PM +0100, Volodymyr Bendiuga wrote:
> Hi Andrew,
>
> No, it did not get accepted. Or at least I did not see
> David accepting it. Let me know if I should resubmit it.
Hi Volodymyr
Please do resend it. Probably netdev will reopen sometime after the
25th.
Don't forget to include the reviewed-by i gave.
Thanks
Andrew
^ permalink raw reply
* [PATCH net-next v4 2/4] dt-bindings: net: add EEE capability constants
From: Jerome Brunet @ 2016-12-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205143942.f3w6nmp3jvmrk5es@rob-hp-laptop>
Hi Rob,
First, Thx for this information and sorry for this late reply
As you may have seen yourself, there was little bit of confusion while
discussing this patch series.
The point is the v3 was applied before your reply (patches 2 and 3 not
combined unfortunately).
Because of this confusion, the series needed a few fixes witch removes
the previously added bindings [0].
This time, I made sure to modify (remove) the bindings along with the
documentation.
[0]:?http://lkml.kernel.org/r/1482159938-13239-1-git-send-email-jbrunet
@baylibre.com
Cheers
Jerome
On Mon, 2016-12-05 at 08:39 -0600, Rob Herring wrote:
> On Mon, Nov 28, 2016 at 04:50:26PM +0100, Jerome Brunet wrote:
> >
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
> > Tested-by: Andreas F?rber <afaerber@suse.de>
> > Tested-by: Neil Armstrong <narmstrong@baylibre.com>
> > ---
> > ?include/dt-bindings/net/mdio.h | 19 +++++++++++++++++++
> > ?1 file changed, 19 insertions(+)
> > ?create mode 100644 include/dt-bindings/net/mdio.h
>
> Seems changes are wanted on this, but patches 2 and 3 should be?
> combined. The header is part of the binding doc.
>
> Rob
^ permalink raw reply
* Problems to Allwinner H3's eFUSE/SID
From: Icenowy Zheng @ 2016-12-19 15:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi everyone,
Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
controller of H3 (incl. H2+).
See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
directly access 0x01c14200.
>From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
legacy kernel).
According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
0x58 is H3D (currently not known SoC) )
However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
with 0x02004620, which do not match this rule.
The readout by devmem2 is satisfying this rule: their first word is
0x02c00081, matches H3.
Then I found the SID-reading code from BSP U-Boot[2], which is based on
register operations. With this kind of code (I wrote one prototype in
userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
And, after accessing to the SID by registers, the value of *0x01c14200 become
also "02c00081".
With direct access to 0x01c14200 after boot with mainline kernel, I got also
"02004620".
Then I altered the program to do the register operations with sunxi-fel, the
result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
Summary:
+-----------------------------------------------+----------------+
| Read situation | The first word |
+-----------------------------------------------+----------------+
| Direct read by sunxi-fel | 02004620 |
| Direct read in mainline /dev/mem | 02004620 |
| Direct read in legacy /dev/mem | 02c00081 |
| Register access in FEL | 02c00081 |
| Register access in mainline | 02c00081 |
| Direct read after register access in FEL | 02c00081 |
| Direct read after register access in mainline | 02c00081 |
+-----------------------------------------------+----------------+
According to some facts:
- The register based access to SID is weird: it needs ~5 register
operations per word of SID.
- Reading via register access will change the value when reading by accessing
0x01c14200.
- In the u-boot code[2] there's some functions which read out the SID by
registers and then abandoned the value.
- This mismatch do not exist on A64.
I think that: Allwinner designed a "cache" to the SID to make the simplify the
code to read it, and it automatically loaded the cache when booting; however,
when doing first cache on H3, some byte shifts occured, and the value become
wrong. A manual read on H3 can make the cache right again. This is a silicon
bug, and fixed in A64.
This raises a problem: currently many systems has used the misread SID value to
generated lots of MAC addresses, and workaround this SID bug will change them.
However, if this bug is not workarounded, the sun8i-ths driver won't work well
(as some calibartion value lies in eFUSE). I think some early user of this
driver has already experienced bad readout value.
(The calibration value differs on my opi1 and KotCzarny's opipc)
And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
think sunxi-fel must have the workaround)
Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
Furthermore, A83T may also have this problem, testers are welcome!
[1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
[2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
Experiments:
- https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
A SID readout shell script via FEL with register access.
- https://31.135.195.151:20281/d/efuse/
A SID readout program via /dev/mem with register access by KotCzarny.
(with statically compiled binary)
Regards,
Icenowy
^ permalink raw reply
* [PATCH] ARM: dts: imx: Pass an empty 'chosen' node
From: Fabio Estevam @ 2016-12-19 15:28 UTC (permalink / raw)
To: linux-arm-kernel
Commit 7f107887d199 ("ARM: dts: imx: Remove skeleton.dtsi") causes boot
issues when the bootloader does not create a 'chosen' node if such node
is not present in the dtb.
The reason for the boot failure is well explained by Javier Martinez
Canillas: "the decompressor relies on a pre-existing chosen node to be
available to insert the command line and merge other ATAGS info."
, so pass an empty 'chosen' node to fix the boot problem.
This issue has been seen in the kernelci reports with Barebox as
bootloader.
Fixes: 7f107887d199 ("ARM: dts: imx: Remove skeleton.dtsi")
Reported-by: kernelci.org bot <bot@kernelci.org>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx1.dtsi | 1 +
arch/arm/boot/dts/imx23.dtsi | 1 +
arch/arm/boot/dts/imx25.dtsi | 1 +
arch/arm/boot/dts/imx27.dtsi | 1 +
arch/arm/boot/dts/imx28.dtsi | 1 +
arch/arm/boot/dts/imx31.dtsi | 1 +
arch/arm/boot/dts/imx35.dtsi | 1 +
arch/arm/boot/dts/imx50.dtsi | 1 +
arch/arm/boot/dts/imx51.dtsi | 1 +
arch/arm/boot/dts/imx53.dtsi | 1 +
arch/arm/boot/dts/imx6qdl.dtsi | 1 +
arch/arm/boot/dts/imx6sl.dtsi | 1 +
arch/arm/boot/dts/imx6sx.dtsi | 1 +
arch/arm/boot/dts/imx6ul.dtsi | 1 +
arch/arm/boot/dts/imx7s.dtsi | 1 +
15 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/imx1.dtsi b/arch/arm/boot/dts/imx1.dtsi
index b792eee..a9581b5 100644
--- a/arch/arm/boot/dts/imx1.dtsi
+++ b/arch/arm/boot/dts/imx1.dtsi
@@ -18,6 +18,7 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
aliases {
gpio0 = &gpio1;
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index ac2a9da..d00bc55 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -14,6 +14,7 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
interrupt-parent = <&icoll>;
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 831d09a..a0348b0 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -14,6 +14,7 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
aliases {
ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index 9d8b596..84652eb 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -19,6 +19,7 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
aliases {
ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 3aabf65..6635213 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -15,6 +15,7 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
interrupt-parent = <&icoll>;
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index 685916e..8a1ea22 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -12,6 +12,7 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
aliases {
serial0 = &uart1;
diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index 9f40e62..4c67438 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -13,6 +13,7 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
aliases {
ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index fe0221e..6e947bd 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -17,6 +17,7 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
aliases {
ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 33526ca..d1f8b93 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -19,6 +19,7 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
aliases {
ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index ca51dc0..ea308b0 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -19,6 +19,7 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
aliases {
ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 53e6e63..c9efd45 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -16,6 +16,7 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
aliases {
ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 4fd6de2..4cd16f2 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -14,6 +14,7 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
aliases {
ethernet0 = &fec;
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 076a30f..9bb1563 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -15,6 +15,7 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
aliases {
can0 = &flexcan1;
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 39845a7..a910fa3 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -15,6 +15,7 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
aliases {
ethernet0 = &fec1;
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 8ff2cbdd..6408b9d 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -50,6 +50,7 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
+ chosen {};
aliases {
gpio0 = &gpio1;
--
1.9.1
^ permalink raw reply related
* Problems to Allwinner H3's eFUSE/SID
From: Hans de Goede @ 2016-12-19 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <136061482160932@web34j.yandex.ru>
Hi,
On 19-12-16 16:22, Icenowy Zheng wrote:
> Hi everyone,
>
> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
> controller of H3 (incl. H2+).
>
> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>
> Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
> directly access 0x01c14200.
>
> From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
> legacy kernel).
>
> According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
> 0x58 is H3D (currently not known SoC) )
>
> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
> with 0x02004620, which do not match this rule.
>
> The readout by devmem2 is satisfying this rule: their first word is
> 0x02c00081, matches H3.
>
> Then I found the SID-reading code from BSP U-Boot[2], which is based on
> register operations. With this kind of code (I wrote one prototype in
> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
> And, after accessing to the SID by registers, the value of *0x01c14200 become
> also "02c00081".
>
> With direct access to 0x01c14200 after boot with mainline kernel, I got also
> "02004620".
>
> Then I altered the program to do the register operations with sunxi-fel, the
> result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>
> Summary:
>
> +-----------------------------------------------+----------------+
> | Read situation | The first word |
> +-----------------------------------------------+----------------+
> | Direct read by sunxi-fel | 02004620 |
> | Direct read in mainline /dev/mem | 02004620 |
> | Direct read in legacy /dev/mem | 02c00081 |
> | Register access in FEL | 02c00081 |
> | Register access in mainline | 02c00081 |
> | Direct read after register access in FEL | 02c00081 |
> | Direct read after register access in mainline | 02c00081 |
> +-----------------------------------------------+----------------+
>
> According to some facts:
> - The register based access to SID is weird: it needs ~5 register
> operations per word of SID.
> - Reading via register access will change the value when reading by accessing
> 0x01c14200.
> - In the u-boot code[2] there's some functions which read out the SID by
> registers and then abandoned the value.
> - This mismatch do not exist on A64.
>
> I think that: Allwinner designed a "cache" to the SID to make the simplify the
> code to read it, and it automatically loaded the cache when booting; however,
> when doing first cache on H3, some byte shifts occured, and the value become
> wrong. A manual read on H3 can make the cache right again. This is a silicon
> bug, and fixed in A64.
>
> This raises a problem: currently many systems has used the misread SID value to
> generated lots of MAC addresses, and workaround this SID bug will change them.
>
> However, if this bug is not workarounded, the sun8i-ths driver won't work well
> (as some calibartion value lies in eFUSE). I think some early user of this
> driver has already experienced bad readout value.
> (The calibration value differs on my opi1 and KotCzarny's opipc)
>
> And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
> think sunxi-fel must have the workaround)
>
> Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>
> Furthermore, A83T may also have this problem, testers are welcome!
>
> [1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
> [2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>
> Experiments:
> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
> A SID readout shell script via FEL with register access.
> - https://31.135.195.151:20281/d/efuse/
> A SID readout program via /dev/mem with register access by KotCzarny.
> (with statically compiled binary)
Good detective work!
I believe this would best be fixed by making u-boot use the register access
method to get the SID on affected chips, and make sure u-boot reads the
SID at-least once.
Can you write a patch for this ?
Regards,
Hans
^ permalink raw reply
* [PATCH] ARM: dts: imx: Pass an empty 'chosen' node
From: Javier Martinez Canillas @ 2016-12-19 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482161298-32624-1-git-send-email-fabio.estevam@nxp.com>
Hello Fabio,
On 12/19/2016 12:28 PM, Fabio Estevam wrote:
> Commit 7f107887d199 ("ARM: dts: imx: Remove skeleton.dtsi") causes boot
> issues when the bootloader does not create a 'chosen' node if such node
> is not present in the dtb.
>
> The reason for the boot failure is well explained by Javier Martinez
> Canillas: "the decompressor relies on a pre-existing chosen node to be
> available to insert the command line and merge other ATAGS info."
>
> , so pass an empty 'chosen' node to fix the boot problem.
>
> This issue has been seen in the kernelci reports with Barebox as
> bootloader.
>
> Fixes: 7f107887d199 ("ARM: dts: imx: Remove skeleton.dtsi")
> Reported-by: kernelci.org bot <bot@kernelci.org>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Appana Durga Kedareswara Rao @ 2016-12-19 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5248247.n0rV8xBPrZ@avalon>
Hi Laurent Pinchart,
Thanks for the review...
> >
> > + if (!chan->idle)
> > + return;
>
> Don't you need to perform the same check for the DMA and CDMA channels ? If
> so, shouldn't this be moved to common code ?
Will fix it in v2...
>
> There's another problem (not strictly introduced by this patch) I wanted to
> mention. The append_desc_queue() function, called from your tx_submit
> handler, appends descriptors to the pending_list. The DMA engine API states
> that a transfer submitted by tx_submit will not be executed until .issue_pending()
> is called. However, if a transfer is in progress at tx_submit time, I believe that
> the IRQ handler, at transfer completion, will start the next transfer from the
> pending_list even if .issue_pending() hasn't been called for it.
>
> > if (list_empty(&chan->pending_list))
> > return;
If user submits more than h/w limit then that case only driver will process
The descriptors from the pending_list for other cases the pending_list will be
Empty so driver just returns from there.
>
> Now that you catch busy channels with a software flag, do you still need the
> xilinx_dma_is_running() and xilinx_dma_is_idle() checks ? Three different checks
> for the same or very similar conditions are confusing, if you really need them
> you should document clearly how they differ.
Will remove the xilinx_dma_is_running and xilinx_dmais_idle() checks and will use
Chan->idle check across all the IP's. Will fix it v2...
>
> > @@ -1110,6 +1116,7 @@ static void xilinx_vdma_start_transfer(struct
> > xilinx_dma_chan *chan) vdma_desc_write(chan, XILINX_DMA_REG_VSIZE,
> > last->hw.vsize);
> > }
> >
> > + chan->idle = false;
>
> (and this too)
Will fix in v2...
Regards,
Kedar.
^ permalink raw reply
* [PATCH] ARM: dts: imx: Pass an empty 'chosen' node
From: Uwe Kleine-König @ 2016-12-19 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482161298-32624-1-git-send-email-fabio.estevam@nxp.com>
On Mon, Dec 19, 2016 at 01:28:18PM -0200, Fabio Estevam wrote:
> Commit 7f107887d199 ("ARM: dts: imx: Remove skeleton.dtsi") causes boot
> issues when the bootloader does not create a 'chosen' node if such node
> is not present in the dtb.
>
> The reason for the boot failure is well explained by Javier Martinez
> Canillas: "the decompressor relies on a pre-existing chosen node to be
> available to insert the command line and merge other ATAGS info."
>
> , so pass an empty 'chosen' node to fix the boot problem.
>
> This issue has been seen in the kernelci reports with Barebox as
> bootloader.
>
> Fixes: 7f107887d199 ("ARM: dts: imx: Remove skeleton.dtsi")
> Reported-by: kernelci.org bot <bot@kernelci.org>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
There is also a patch on the barebox list that makes barebox fix a dt
accordingly. It seems it's not in the repository though.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Appana Durga Kedareswara Rao @ 2016-12-19 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <689b1077-6ee3-60d0-1fdf-0a125003a479@synopsys.com>
Hi Jose Miguel Abreu,
Thanks for the review...
> >
> >>> - last = segment;
> >>> + for (j = 0; j < chan->num_frms; ) {
> >>> + list_for_each_entry(segment, &desc->segments, node)
> >> {
> >>> + if (chan->ext_addr)
> >>> + vdma_desc_write_64(chan,
> >>> +
> >> XILINX_VDMA_REG_START_ADDRESS_64(i++),
> >>> + segment->hw.buf_addr,
> >>> + segment->hw.buf_addr_msb);
> >>> + else
> >>> + vdma_desc_write(chan,
> >>> +
> >> XILINX_VDMA_REG_START_ADDRESS(i++),
> >>> + segment->hw.buf_addr);
> >>> +
> >>> + last = segment;
> >> Hmm, is it possible to submit more than one segment? If so, then i
> >> and j will get out of sync.
> > If h/w is configured for more than 1 frame buffer and user submits
> > more than one frame buffer We can submit more than one frame/ segment to
> hw right??
>
> I'm not sure. When I used VDMA driver I always submitted only one segment and
> multiple descriptors. But the problem is, for example:
>
> If you have:
> descriptor1 (2 segments)
> descriptor2 (2 segments)
>
> And you have 3 frame buffers in the HW.
>
> Then:
> 1st frame buffer will have: descriptor1 -> segment1 2nd frame buffer will have:
> descriptor1 -> segment2 3rd frame buffer will have: descriptor2 -> segment1
> but, 4th frame buffer will have: descriptor2 -> segment2 <---- INVALID because
> there is only 3 frame buffers
>
> So, maybe a check inside the loop "list_for_each_entry(segment, &desc-
> >segments, node)" could be a nice to have.
With the current driver flow user can submit only 1 segment per descriptor
That's why didn't checked the list_for_each_entry for each descriptors...
Hope it clarifies your query...
>
> >
> >>> + }
> >>> + list_del(&desc->node);
> >>> + list_add_tail(&desc->node, &chan->active_list);
> >>> + j++;
> >> But if i is non zero and pending_list has more than num_frms then i
> >> will not wrap-around as it should and will write to invalid framebuffer
> location, right?
> > Yep will fix in v2...
> >
> > If (if (list_empty(&chan->pending_list)) || (i == chan->num_frms)
> > break;
> >
> > Above condition is sufficient right???
>
> Looks ok.
Thanks...
> >>> @@ -1114,14 +1124,13 @@ static void
> >>> xilinx_vdma_start_transfer(struct
> >> xilinx_dma_chan *chan)
> >>> vdma_desc_write(chan, XILINX_DMA_REG_FRMDLY_STRIDE,
> >>> last->hw.stride);
> >>> vdma_desc_write(chan, XILINX_DMA_REG_VSIZE, last-
> hw.vsize);
> >> Maybe a check that all framebuffers contain valid addresses should be
> >> done before programming vsize so that VDMA does not try to write to
> >> invalid addresses.
> > Do we really need to check for valid address???
> > I didn't get you what to do you mean by invalid address could you please
> explain???
> > In the driver we are reading form the pending_list which will be
> > updated by pep_interleaved_dma Call so we are under assumption that user
> sends the proper address right???
>
> What I mean by valid address is to check that i variable has already been
> incremented by num_frms at least once since a VDMA reset. This way you know
> that you have programmed all the addresses of the frame buffers with an
> address and they are non-zero.
Ok Sure will fix in v2...
Regards,
Kedar.
>
> Best regards,
> Jose Miguel Abreu
>
^ permalink raw reply
* [PATCH 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Appana Durga Kedareswara Rao @ 2016-12-19 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <30884836.ckISXSrEvA@avalon>
Hi Laurent Pinchart,
Thanks for the review...
> > + int i = 0, j = 0;
> >
> > if (chan->desc_submitcount < chan->num_frms)
> > i = chan->desc_submitcount;
>
> I don't get this. i seems to index into a segment start address array, but gets
> initialized with a variable documented as "Descriptor h/w submitted count". I'm
> not familiar with the hardware, but it makes no sense to me.
Here i is the h/w buffer address.
For ex: If the h/w is configured for 3 frame buffers and user submits 4 desc's
Then we need to submit only 3 frame buffers to the h/w and the next desc will be submitted
After there is a room for buffers I mean when the free buffer is available.
>
> > - list_for_each_entry(segment, &desc->segments, node) {
> > - if (chan->ext_addr)
> > - vdma_desc_write_64(chan,
> > -
> XILINX_VDMA_REG_START_ADDRESS_64(i++),
> > - segment->hw.buf_addr,
> > - segment->hw.buf_addr_msb);
> > - else
> > - vdma_desc_write(chan,
> > -
> XILINX_VDMA_REG_START_ADDRESS(i++),
> > - segment->hw.buf_addr);
> > -
> > - last = segment;
>
> Isn't it an issue to write the descriptors only after calling
> xilinx_dma_start() ?
Until writing to the VSIZE h/w won't get started...
>
> > + for (j = 0; j < chan->num_frms; ) {
> > + list_for_each_entry(segment, &desc->segments, node)
> {
> > + if (chan->ext_addr)
> > + vdma_desc_write_64(chan,
> > +
> XILINX_VDMA_REG_START_ADDRESS_64(i++),
> > + segment->hw.buf_addr,
> > + segment->hw.buf_addr_msb);
> > + else
> > + vdma_desc_write(chan,
> > +
> XILINX_VDMA_REG_START_ADDRESS(i++),
> > + segment->hw.buf_addr);
>
> I assume the size of the start address array to be limited by the hardware, but I
> don't see how this code prevents from overflowing this.
>
> The whole function is very difficult to understand, it probably requires a rewrite.
Will fix it in v2...
>
> > + last = segment;
> > + }
> > + list_del(&desc->node);
> > + list_add_tail(&desc->node, &chan->active_list);
> > + j++;
> > + if (list_empty(&chan->pending_list))
> > + break;
> > + desc = list_first_entry(&chan->pending_list,
> > + struct
> xilinx_dma_tx_descriptor,
> > + node);
> > }
> > if (!chan->has_sg) {
> > - list_del(&desc->node);
> > - list_add_tail(&desc->node, &chan->active_list);
> > - chan->desc_submitcount++;
> > - chan->desc_pendingcount--;
> > if (chan->desc_submitcount == chan->num_frms)
> > chan->desc_submitcount = 0;
> > } else {
>
> While at it, can you merge this into the previous if (chan->has_sg) { ... } else { ... }
> ? Having them separate is confusing.
Ok sure will fix in v2...
Regards,
Kedar.
>
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* Problems to Allwinner H3's eFUSE/SID
From: Icenowy Zheng @ 2016-12-19 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a2e87cff-d92c-37e3-e380-48ce1710ec08@redhat.com>
19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
> Hi,
>
> On 19-12-16 16:22, Icenowy Zheng wrote:
>> ?Hi everyone,
>>
>> ?Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>> ?controller of H3 (incl. H2+).
>>
>> ?See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>
>> ?Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
>> ?directly access 0x01c14200.
>>
>> ?From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
>> ?the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
>> ?legacy kernel).
>>
>> ?According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
>> ?byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
>> ?0x58 is H3D (currently not known SoC) )
>>
>> ?However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
>> ?with 0x02004620, which do not match this rule.
>>
>> ?The readout by devmem2 is satisfying this rule: their first word is
>> ?0x02c00081, matches H3.
>>
>> ?Then I found the SID-reading code from BSP U-Boot[2], which is based on
>> ?register operations. With this kind of code (I wrote one prototype in
>> ?userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
>> ?my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
>> ?And, after accessing to the SID by registers, the value of *0x01c14200 become
>> ?also "02c00081".
>>
>> ?With direct access to 0x01c14200 after boot with mainline kernel, I got also
>> ?"02004620".
>>
>> ?Then I altered the program to do the register operations with sunxi-fel, the
>> ?result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>>
>> ?Summary:
>>
>> ?+-----------------------------------------------+----------------+
>> ?| Read situation | The first word |
>> ?+-----------------------------------------------+----------------+
>> ?| Direct read by sunxi-fel | 02004620 |
>> ?| Direct read in mainline /dev/mem | 02004620 |
>> ?| Direct read in legacy /dev/mem | 02c00081 |
>> ?| Register access in FEL | 02c00081 |
>> ?| Register access in mainline | 02c00081 |
>> ?| Direct read after register access in FEL | 02c00081 |
>> ?| Direct read after register access in mainline | 02c00081 |
>> ?+-----------------------------------------------+----------------+
>>
>> ?According to some facts:
>> ?- The register based access to SID is weird: it needs ~5 register
>> ???operations per word of SID.
>> ?- Reading via register access will change the value when reading by accessing
>> ???0x01c14200.
>> ?- In the u-boot code[2] there's some functions which read out the SID by
>> ???registers and then abandoned the value.
>> ?- This mismatch do not exist on A64.
>>
>> ?I think that: Allwinner designed a "cache" to the SID to make the simplify the
>> ?code to read it, and it automatically loaded the cache when booting; however,
>> ?when doing first cache on H3, some byte shifts occured, and the value become
>> ?wrong. A manual read on H3 can make the cache right again. This is a silicon
>> ?bug, and fixed in A64.
>>
>> ?This raises a problem: currently many systems has used the misread SID value to
>> ?generated lots of MAC addresses, and workaround this SID bug will change them.
>>
>> ?However, if this bug is not workarounded, the sun8i-ths driver won't work well
>> ?(as some calibartion value lies in eFUSE). I think some early user of this
>> ?driver has already experienced bad readout value.
>> ?(The calibration value differs on my opi1 and KotCzarny's opipc)
>>
>> ?And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
>> ?think sunxi-fel must have the workaround)
>>
>> ?Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
>> ?at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>
>> ?Furthermore, A83T may also have this problem, testers are welcome!
>>
>> ?[1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>> ?[2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>
>> ?Experiments:
>> ?- https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>> ???A SID readout shell script via FEL with register access.
>> ?- https://31.135.195.151:20281/d/efuse/
>> ???A SID readout program via /dev/mem with register access by KotCzarny.
>> ???(with statically compiled binary)
>
> Good detective work!
>
> I believe this would best be fixed by making u-boot use the register access
> method to get the SID on affected chips, and make sure u-boot reads the
> SID at-least once.
Yes.
However, what I considered is that fixing this bug will change H3 devices'
MAC addresses, as they are derived from SID.
Maybe we should add #ifdef's to MAC generation code after this fix.
(This is why I will create this discussion)
P.S. Are you still the maintainer of sunxi boards support of u-boot? The
MAINTAINER file in board/sunxi indicates this.
I've sent out a new board support several days ago (Orange Pi Zero), and got
one "Reviewd-By". Could you look at it?
>
> Can you write a patch for this ?
>
> Regards,
>
> Hans
^ permalink raw reply
* [PATCH] ARM: ep93xx: Disable TS-72xx watchdog before uncompressing
From: Hartley Sweeten @ 2016-12-19 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6d58631d-37a2-8362-e9aa-0c360fac4509@gmail.com>
On Sunday, December 18, 2016 7:08 PM, Florian Fainelli wrote:
> Le 12/11/16 ? 11:16, Florian Fainelli a ?crit :
>> The TS-72xx/73xx boards have a CPLD watchdog which is configured to
>> reset the board after 8 seconds, if the kernel is large enough that this
>> takes about this time to decompress the kernel, we will encounter a
>> spurious reboot.
>>
>> Do not pull ts72xx.h, but instead locally define what we need to disable
>> the watchdog.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Hartley, Ryan, do you guys maintain a git tree with EP93xx patches, or
> should I submit them through RMK's patch system once you are okay with them?
Ryan has an old tree on github but it has not been updated since Oct 14, 2013. I'm
not sure if he is doing any active development at this time.
This patch will have to go through RMK's patch system or some other tree.
Thanks,
Hartley
^ permalink raw reply
* Problems to Allwinner H3's eFUSE/SID
From: Hans de Goede @ 2016-12-19 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8758581482163602@web22j.yandex.ru>
Hi,
On 19-12-16 17:06, Icenowy Zheng wrote:
>
>
> 19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
>> Hi,
>>
>> On 19-12-16 16:22, Icenowy Zheng wrote:
>>> Hi everyone,
>>>
>>> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>> controller of H3 (incl. H2+).
>>>
>>> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>>
>>> Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
>>> directly access 0x01c14200.
>>>
>>> From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
>>> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
>>> legacy kernel).
>>>
>>> According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
>>> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
>>> 0x58 is H3D (currently not known SoC) )
>>>
>>> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
>>> with 0x02004620, which do not match this rule.
>>>
>>> The readout by devmem2 is satisfying this rule: their first word is
>>> 0x02c00081, matches H3.
>>>
>>> Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>> register operations. With this kind of code (I wrote one prototype in
>>> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
>>> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
>>> And, after accessing to the SID by registers, the value of *0x01c14200 become
>>> also "02c00081".
>>>
>>> With direct access to 0x01c14200 after boot with mainline kernel, I got also
>>> "02004620".
>>>
>>> Then I altered the program to do the register operations with sunxi-fel, the
>>> result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>>>
>>> Summary:
>>>
>>> +-----------------------------------------------+----------------+
>>> | Read situation | The first word |
>>> +-----------------------------------------------+----------------+
>>> | Direct read by sunxi-fel | 02004620 |
>>> | Direct read in mainline /dev/mem | 02004620 |
>>> | Direct read in legacy /dev/mem | 02c00081 |
>>> | Register access in FEL | 02c00081 |
>>> | Register access in mainline | 02c00081 |
>>> | Direct read after register access in FEL | 02c00081 |
>>> | Direct read after register access in mainline | 02c00081 |
>>> +-----------------------------------------------+----------------+
>>>
>>> According to some facts:
>>> - The register based access to SID is weird: it needs ~5 register
>>> operations per word of SID.
>>> - Reading via register access will change the value when reading by accessing
>>> 0x01c14200.
>>> - In the u-boot code[2] there's some functions which read out the SID by
>>> registers and then abandoned the value.
>>> - This mismatch do not exist on A64.
>>>
>>> I think that: Allwinner designed a "cache" to the SID to make the simplify the
>>> code to read it, and it automatically loaded the cache when booting; however,
>>> when doing first cache on H3, some byte shifts occured, and the value become
>>> wrong. A manual read on H3 can make the cache right again. This is a silicon
>>> bug, and fixed in A64.
>>>
>>> This raises a problem: currently many systems has used the misread SID value to
>>> generated lots of MAC addresses, and workaround this SID bug will change them.
>>>
>>> However, if this bug is not workarounded, the sun8i-ths driver won't work well
>>> (as some calibartion value lies in eFUSE). I think some early user of this
>>> driver has already experienced bad readout value.
>>> (The calibration value differs on my opi1 and KotCzarny's opipc)
>>>
>>> And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
>>> think sunxi-fel must have the workaround)
>>>
>>> Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
>>> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>>
>>> Furthermore, A83T may also have this problem, testers are welcome!
>>>
>>> [1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>> [2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>>
>>> Experiments:
>>> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>> A SID readout shell script via FEL with register access.
>>> - https://31.135.195.151:20281/d/efuse/
>>> A SID readout program via /dev/mem with register access by KotCzarny.
>>> (with statically compiled binary)
>>
>> Good detective work!
>>
>> I believe this would best be fixed by making u-boot use the register access
>> method to get the SID on affected chips, and make sure u-boot reads the
>> SID at-least once.
>
> Yes.
>
> However, what I considered is that fixing this bug will change H3 devices'
> MAC addresses, as they are derived from SID.
I know, but I think we will just need to accept this onetime change
of the fixed MAC addresses to fix this bug. I don't think this is
a big problem since the driver for the H3 ethernet has not been
merged into the mainline kernel yet.
> Maybe we should add #ifdef's to MAC generation code after this fix.
I would rather not see #ifdefs for this, see above, but that is no
longer my call, see below.
>
> (This is why I will create this discussion)
>
> P.S. Are you still the maintainer of sunxi boards support of u-boot? The
> MAINTAINER file in board/sunxi indicates this.
No I'm no longer the maintainer, I'm still the MAINTAINER file because
I have a lot of boards and as such I'm still the point of contact for
those boards (if there are any board specific issues / questions), but
as indicated in the main MAINTAINERS file Jagan Teki <jagan@openedev.com>
is the maintainer now.
Regards,
Hans
^ permalink raw reply
* Problems to Allwinner H3's eFUSE/SID
From: Icenowy Zheng @ 2016-12-19 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12fa0112-b0e2-21e0-f369-7372944153d5@redhat.com>
20.12.2016, 00:17, "Hans de Goede" <hdegoede@redhat.com>:
> Hi,
>
> On 19-12-16 17:06, Icenowy Zheng wrote:
>> ?19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
>>> ?Hi,
>>>
>>> ?On 19-12-16 16:22, Icenowy Zheng wrote:
>>>> ??Hi everyone,
>>>>
>>>> ??Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>>> ??controller of H3 (incl. H2+).
>>>>
>>>> ??See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>>>
>>>> ??Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
>>>> ??directly access 0x01c14200.
>>>>
>>>> ??From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
>>>> ??the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
>>>> ??legacy kernel).
>>>>
>>>> ??According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
>>>> ??byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
>>>> ??0x58 is H3D (currently not known SoC) )
>>>>
>>>> ??However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
>>>> ??with 0x02004620, which do not match this rule.
>>>>
>>>> ??The readout by devmem2 is satisfying this rule: their first word is
>>>> ??0x02c00081, matches H3.
>>>>
>>>> ??Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>>> ??register operations. With this kind of code (I wrote one prototype in
>>>> ??userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
>>>> ??my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
>>>> ??And, after accessing to the SID by registers, the value of *0x01c14200 become
>>>> ??also "02c00081".
>>>>
>>>> ??With direct access to 0x01c14200 after boot with mainline kernel, I got also
>>>> ??"02004620".
>>>>
>>>> ??Then I altered the program to do the register operations with sunxi-fel, the
>>>> ??result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>>>>
>>>> ??Summary:
>>>>
>>>> ??+-----------------------------------------------+----------------+
>>>> ??| Read situation | The first word |
>>>> ??+-----------------------------------------------+----------------+
>>>> ??| Direct read by sunxi-fel | 02004620 |
>>>> ??| Direct read in mainline /dev/mem | 02004620 |
>>>> ??| Direct read in legacy /dev/mem | 02c00081 |
>>>> ??| Register access in FEL | 02c00081 |
>>>> ??| Register access in mainline | 02c00081 |
>>>> ??| Direct read after register access in FEL | 02c00081 |
>>>> ??| Direct read after register access in mainline | 02c00081 |
>>>> ??+-----------------------------------------------+----------------+
>>>>
>>>> ??According to some facts:
>>>> ??- The register based access to SID is weird: it needs ~5 register
>>>> ????operations per word of SID.
>>>> ??- Reading via register access will change the value when reading by accessing
>>>> ????0x01c14200.
>>>> ??- In the u-boot code[2] there's some functions which read out the SID by
>>>> ????registers and then abandoned the value.
>>>> ??- This mismatch do not exist on A64.
>>>>
>>>> ??I think that: Allwinner designed a "cache" to the SID to make the simplify the
>>>> ??code to read it, and it automatically loaded the cache when booting; however,
>>>> ??when doing first cache on H3, some byte shifts occured, and the value become
>>>> ??wrong. A manual read on H3 can make the cache right again. This is a silicon
>>>> ??bug, and fixed in A64.
>>>>
>>>> ??This raises a problem: currently many systems has used the misread SID value to
>>>> ??generated lots of MAC addresses, and workaround this SID bug will change them.
>>>>
>>>> ??However, if this bug is not workarounded, the sun8i-ths driver won't work well
>>>> ??(as some calibartion value lies in eFUSE). I think some early user of this
>>>> ??driver has already experienced bad readout value.
>>>> ??(The calibration value differs on my opi1 and KotCzarny's opipc)
>>>>
>>>> ??And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
>>>> ??think sunxi-fel must have the workaround)
>>>>
>>>> ??Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
>>>> ??at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>>>
>>>> ??Furthermore, A83T may also have this problem, testers are welcome!
>>>>
>>>> ??[1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>>> ??[2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>>>
>>>> ??Experiments:
>>>> ??- https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>>> ????A SID readout shell script via FEL with register access.
>>>> ??- https://31.135.195.151:20281/d/efuse/
>>>> ????A SID readout program via /dev/mem with register access by KotCzarny.
>>>> ????(with statically compiled binary)
>>>
>>> ?Good detective work!
>>>
>>> ?I believe this would best be fixed by making u-boot use the register access
>>> ?method to get the SID on affected chips, and make sure u-boot reads the
>>> ?SID at-least once.
>>
>> ?Yes.
>>
>> ?However, what I considered is that fixing this bug will change H3 devices'
>> ?MAC addresses, as they are derived from SID.
>
> I know, but I think we will just need to accept this onetime change
> of the fixed MAC addresses to fix this bug. I don't think this is
> a big problem since the driver for the H3 ethernet has not been
> merged into the mainline kernel yet.
>
>> ?Maybe we should add #ifdef's to MAC generation code after this fix.
>
> I would rather not see #ifdefs for this, see above, but that is no
> longer my call, see below.
>
>> ?(This is why I will create this discussion)
>>
>> ?P.S. Are you still the maintainer of sunxi boards support of u-boot? The
>> ?MAINTAINER file in board/sunxi indicates this.
>
> No I'm no longer the maintainer, I'm still the MAINTAINER file because
> I have a lot of boards and as such I'm still the point of contact for
> those boards (if there are any board specific issues / questions), but
> as indicated in the main MAINTAINERS file Jagan Teki <jagan@openedev.com>
> is the maintainer now.
But the current status of the file will indicates you are the maintainer of boards
support of sunxi.
>
> Regards,
>
> Hans
^ permalink raw reply
* Problems to Allwinner H3's eFUSE/SID
From: Hans de Goede @ 2016-12-19 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13032681482164747@web30h.yandex.ru>
Hi,
On 19-12-16 17:25, Icenowy Zheng wrote:
>
>
> 20.12.2016, 00:17, "Hans de Goede" <hdegoede@redhat.com>:
>> Hi,
>>
>> On 19-12-16 17:06, Icenowy Zheng wrote:
>>> 19.12.2016, 23:30, "Hans de Goede" <hdegoede@redhat.com>:
>>>> Hi,
>>>>
>>>> On 19-12-16 16:22, Icenowy Zheng wrote:
>>>>> Hi everyone,
>>>>>
>>>>> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>>>> controller of H3 (incl. H2+).
>>>>>
>>>>> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>>>>
>>>>> Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
>>>>> directly access 0x01c14200.
>>>>>
>>>>> From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
>>>>> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
>>>>> legacy kernel).
>>>>>
>>>>> According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
>>>>> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
>>>>> 0x58 is H3D (currently not known SoC) )
>>>>>
>>>>> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
>>>>> with 0x02004620, which do not match this rule.
>>>>>
>>>>> The readout by devmem2 is satisfying this rule: their first word is
>>>>> 0x02c00081, matches H3.
>>>>>
>>>>> Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>>>> register operations. With this kind of code (I wrote one prototype in
>>>>> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
>>>>> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
>>>>> And, after accessing to the SID by registers, the value of *0x01c14200 become
>>>>> also "02c00081".
>>>>>
>>>>> With direct access to 0x01c14200 after boot with mainline kernel, I got also
>>>>> "02004620".
>>>>>
>>>>> Then I altered the program to do the register operations with sunxi-fel, the
>>>>> result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>>>>>
>>>>> Summary:
>>>>>
>>>>> +-----------------------------------------------+----------------+
>>>>> | Read situation | The first word |
>>>>> +-----------------------------------------------+----------------+
>>>>> | Direct read by sunxi-fel | 02004620 |
>>>>> | Direct read in mainline /dev/mem | 02004620 |
>>>>> | Direct read in legacy /dev/mem | 02c00081 |
>>>>> | Register access in FEL | 02c00081 |
>>>>> | Register access in mainline | 02c00081 |
>>>>> | Direct read after register access in FEL | 02c00081 |
>>>>> | Direct read after register access in mainline | 02c00081 |
>>>>> +-----------------------------------------------+----------------+
>>>>>
>>>>> According to some facts:
>>>>> - The register based access to SID is weird: it needs ~5 register
>>>>> operations per word of SID.
>>>>> - Reading via register access will change the value when reading by accessing
>>>>> 0x01c14200.
>>>>> - In the u-boot code[2] there's some functions which read out the SID by
>>>>> registers and then abandoned the value.
>>>>> - This mismatch do not exist on A64.
>>>>>
>>>>> I think that: Allwinner designed a "cache" to the SID to make the simplify the
>>>>> code to read it, and it automatically loaded the cache when booting; however,
>>>>> when doing first cache on H3, some byte shifts occured, and the value become
>>>>> wrong. A manual read on H3 can make the cache right again. This is a silicon
>>>>> bug, and fixed in A64.
>>>>>
>>>>> This raises a problem: currently many systems has used the misread SID value to
>>>>> generated lots of MAC addresses, and workaround this SID bug will change them.
>>>>>
>>>>> However, if this bug is not workarounded, the sun8i-ths driver won't work well
>>>>> (as some calibartion value lies in eFUSE). I think some early user of this
>>>>> driver has already experienced bad readout value.
>>>>> (The calibration value differs on my opi1 and KotCzarny's opipc)
>>>>>
>>>>> And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
>>>>> think sunxi-fel must have the workaround)
>>>>>
>>>>> Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
>>>>> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>>>>
>>>>> Furthermore, A83T may also have this problem, testers are welcome!
>>>>>
>>>>> [1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>>>> [2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>>>>
>>>>> Experiments:
>>>>> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>>>> A SID readout shell script via FEL with register access.
>>>>> - https://31.135.195.151:20281/d/efuse/
>>>>> A SID readout program via /dev/mem with register access by KotCzarny.
>>>>> (with statically compiled binary)
>>>>
>>>> Good detective work!
>>>>
>>>> I believe this would best be fixed by making u-boot use the register access
>>>> method to get the SID on affected chips, and make sure u-boot reads the
>>>> SID at-least once.
>>>
>>> Yes.
>>>
>>> However, what I considered is that fixing this bug will change H3 devices'
>>> MAC addresses, as they are derived from SID.
>>
>> I know, but I think we will just need to accept this onetime change
>> of the fixed MAC addresses to fix this bug. I don't think this is
>> a big problem since the driver for the H3 ethernet has not been
>> merged into the mainline kernel yet.
>>
>>> Maybe we should add #ifdef's to MAC generation code after this fix.
>>
>> I would rather not see #ifdefs for this, see above, but that is no
>> longer my call, see below.
>>
>>> (This is why I will create this discussion)
>>>
>>> P.S. Are you still the maintainer of sunxi boards support of u-boot? The
>>> MAINTAINER file in board/sunxi indicates this.
>>
>> No I'm no longer the maintainer, I'm still the MAINTAINER file because
>> I have a lot of boards and as such I'm still the point of contact for
>> those boards (if there are any board specific issues / questions), but
>> as indicated in the main MAINTAINERS file Jagan Teki <jagan@openedev.com>
>> is the maintainer now.
>
> But the current status of the file will indicates you are the maintainer of boards
> support of sunxi.
No it indicates that I'm the maintainer for the defconfig files for a whole list
of boards, nothing more and nothing less.
If you think it needs to be clarified, feel free to submit a patch to make this
more clear.
Regards,
Hans
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox