Just tested temperature reading code and the unit seems to be correct, as on cold boot, both PHY and SoC show very similar reading of around 22 deg C (room temperature). However, in sensors output I then see the CPU and WiFi-frontend temperature raising, quite quickly reaching values above 35 deg C while the temperature of the two Ethernet PHYs reads out constant – while the PHYs actually also get warm subjectively… Maybe we need to trigger latching of new sensor read-out values somehow to update the temperature?
Is pwm/thermal definition right in r3mini dts (soc temp)? Noticed no fan activity when booting linux (i’m currently most time in uboot).
Have you found a way to fix uboot phy driver? My version has now the builtin-firmware option,have a priv and probe and i replaced spaces by tabs on indentation.
Thanks, tomorrow I have some time to look in to this.
Edit:
I am following the original code and the datasheet-snippet I have received on this:
#define AIR_PHY_HOST_CMD_3 0x800e
#define AIR_PHY_HOST_CMD_3_MODE1 0x1101
#define AIR_PHY_HOST_CMD_3_DOCMD 0x1100
#define AIR_PHY_HOST_CMD_4 0x800f
#define AIR_PHY_HOST_CMD_4_MODE1 0x0002
#define AIR_PHY_HOST_CMD_4_INTCLR 0x00e4
#define AIR_PHY_HOST_CMD_4_READTEMP 0x00e5
#define EN8811H_TEMPERATURE 0x3b38
ret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AIR_PHY_HOST_CMD_3,
AIR_PHY_HOST_CMD_3_DOCMD);
if (ret < 0)
return ret;
ret = phy_write_mmd(phydev, MDIO_MMD_VEND1, AIR_PHY_HOST_CMD_4,
AIR_PHY_HOST_CMD_4_READTEMP);
if (ret < 0)
return ret;
ret = air_buckpbus_reg_read(phydev, EN8811H_TEMPERATURE, &pbus_value);
if (ret < 0)
return ret;
*value = pbus_value;
Btw, on 1000Mbps I got:
[ 5] 0.00-1.00 sec 114 MBytes 957 Mbits/sec 0 509 KBytes
[ 5] 1.00-2.00 sec 113 MBytes 945 Mbits/sec 0 509 KBytes
[ 5] 2.00-3.00 sec 112 MBytes 943 Mbits/sec 0 509 KBytes
[ 5] 3.00-4.00 sec 113 MBytes 945 Mbits/sec 0 509 KBytes
[ 5] 4.00-5.00 sec 112 MBytes 936 Mbits/sec 0 509 KBytes
[ 5] 5.00-6.00 sec 112 MBytes 943 Mbits/sec 0 509 KBytes
[ 5] 6.00-7.00 sec 112 MBytes 942 Mbits/sec 0 509 KBytes
[ 5] 7.00-8.00 sec 112 MBytes 942 Mbits/sec 0 509 KBytes
[ 5] 8.00-9.00 sec 112 MBytes 944 Mbits/sec 0 509 KBytes
[ 5] 9.00-10.00 sec 112 MBytes 939 Mbits/sec 0 509 KBytes
This does seem ok on this connection.
Try the other direction iperf3 -R -c ... as well…
Is there a public datashet now?
No, I have just received a small snippet, so I can continue…
So I got Russell’s ideas implemented (which is possible), also air_buckpbus_reg_modify() and 1 use of it (still need to change the others).
Seems working ok, but I should check the leds are still functioning…
So the extra device that is seen at phy-address + 8, it is the device used by the air_pbus_reg_read/write() functions.
While most host registers are accessible through ‘buckpbus’, few (for now only 1 known) registers are accessed through ‘pbus’, which presents itself as an extra device on the mdio bus. For the en8811h it is found at phy-address + 8.
So, about re-introducing air_pbus_reg_read/write() the following:
First I used the devicetree to add this extra device, I saved this version in the net-next-airoha-extradev branch.
Since it is clear that it is not really an extra device, but only a different way to access the same device, I now have a version where the mdio-device is added by the en8811h driver itself (in the .probe function). No need for any extra devicetree entries. I saved this version in the normal net-next-airoha branch. I believe this is the version to send upstream.
Any suggestions?
So it is confirmed by Airoha, the register on pbus does not need to be written to.
So the entire access to the extra mdio device can be dropped.
2 Likes
Imho it would still be good to somehow document the presence of those extra devices in the MDIO bus, just to avoid confusion of people who may look into this in the future.
So the basic outline of v3 patch-set is ready and in the net-next-airhoa branch. The firmware files must be in initramfs, or otherwise available at early boot.
I’m still in contact about how to finally describe mode 1
I’ll do some more testing, checking and cosmetics, before sending.
Any comments before sending would be easier to fix now.
1 Like
which is your latest branch here? there is a net-next-airoha-v2 too…commits have same date, but code is different
net-next-airoha is the latest branch. I forgot I had that v2 branch, it is gone now.
It has been reviewed and no comments yet 
1 Like
Patch is applied to net-next!
1 Like
Great work,hope we can port the driver to uboot to have network support there too.
I am not very familiar with uboot, but does it do like so when executing network commands?
Link up - execute command - link diwn.
If so, then need to restart mcu at beginning of command, starting at second command. ,(or already at end if command)
I’m not sure but with current driver we have the problem that only first network access works then it is blocked,not sure why
I think that is why, but need to see when uboot does link up/down.
The hardware does not handle link down and then link up again very nicely.
Edit:
After firmware load the mcu is reset, so this is why it only works once. Then after link down, need to reset mcu when going link up again.
The code in net-next does like so, so perhaps porting is enough.
Maybe problem is that we use genphy_shutdown here?
Reset is done on startup (till the linked line…also a bit above).
But afair this is only called once (not on second net access).
Seems there are no link_up/down callbacks.