512-861-3400Log inCreate Account

memaher

Forum Replies Created

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • March 26, 2020 at 8:12 am in reply to: EEPROM WP #9952
    Mat Mat Mahermemaher
    Participant

      Resolved: needed to change the external pullups (2k2 now) on the I2C line.

      November 1, 2019 at 7:27 am in reply to: Ethernet port failure on 2nd stage u-boot #9339
      Mat Mat Mahermemaher
      Participant

        To conclude this thread (as I’m now giving up)…

        in Debian 9, dtb= and/or fdtfile= statements are overwritten by the findfdt= macro during boot. This makes it almost impossible to insert a custom device tree using uEnv.txt. The options are therefore:

        1. modify/rebuild u-boot
        2. use Debian 8
        3. implement changes as overlays (however this limits the changes that are possible)

        November 1, 2019 at 3:48 am in reply to: Ethernet port failure on 2nd stage u-boot #9338
        Mat Mat Mahermemaher
        Participant

          I think its a more deep-seated problem. Looking at the startup logs

          95: Using: dtb=emanip-arm-ctrl.dtb
          105: uboot_overlays: Switching too: dtb=am335x-boneblack-uboot-univ.dtb

          Looking into the u-boot source it seems that dtb= (and therefore fdtfile=) can be set to whatever in uEnv.txt, but is then automatically overridden during the i2c EEPROM check.

          Everything is pointing at the moment to needing a custom u-boot build, which I’ve been trying to avoid

          October 29, 2019 at 10:21 am in reply to: Ethernet port failure on 2nd stage u-boot #9328
          Mat Mat Mahermemaher
          Participant

            u-boot is loading a LOT of device trees in addition to my custom one! Is there any way to shut these down other than customising u-boot?

             

            October 25, 2019 at 7:29 am in reply to: Ethernet port failure on 2nd stage u-boot #9290
            Mat Mat Mahermemaher
            Participant

              and finally…

              PHY ADDRESS = 4 is hard-coded somewhere in the system: it is NOT being read from the custom device tree.

              I can say that now, as…

              1. Changing my hardware 2nd PHY address away from 4 to 0 (with changing the device tree to match) results in

              [ 18.311930] libphy: PHY 4a101000.mdio:04 not found
              [ 18.353779] net eth0: phy “4a101000.mdio:04” not found on slave 0, err -19

              So something, somewhere, is hard-coding this address and it was just coincidence that I chose adr=4 for my second phy.

              2. changing my hardware 1st PHY address to 4 (leaving 2nd phy at 0) results in the ethernet port now working (regardless of device tree setting).

              So, I now have a working ethernet port. However, it doesn’t explain the root cause of the problem: maybe its the original suspicion of beaglebone overlays still being loaded on top of the custom overlay?

              October 25, 2019 at 5:06 am in reply to: Ethernet port failure on 2nd stage u-boot #9289
              Mat Mat Mahermemaher
              Participant

                ok, so my theory about the highest address doesn’t stack up. But, I can confirm that changing the PHYID within the cpsw {} device tree sections doesn’t make the slightest bit of difference to the PHYID allocation.

                I can also confirm that the extra 1.5k pullup isn’t the issue (now removed).

                I’ve modified the board as follows

                ethernet#1 = PHYID 5 (this is my eth0 port)
                ethernet#2 = PHYID 4

                1. setting the device tree to addresses 0 & 1 respectively results in ethtool detecting PHYID=4 as eth0 (aka it doesn’t work)
                2. setting the device tree to addresses 5 & 4 respectively results in ethtool detecting PHYID=4 on eth0 (ditto)
                3. setting the device tree backwards to 4 & 5 respectively results in exactly the same PHYID=4.

                Something is finding address 4 and prioritising it over everything, but I’ve no idea what. It still remains the same problem: eth0 works brilliantly, but only when a cable is plugged into eth1 – otherwise it doesn’t detect a valid link.

                October 25, 2019 at 3:00 am in reply to: Ethernet port failure on 2nd stage u-boot #9285
                Mat Mat Mahermemaher
                Participant

                  Two logs attached.

                  Later today I’ll attempt to physically change the phy address on eth0 to be higher than eth1 phy. Should confirm whether or not it’s just picking the highest number.

                  Attachments:
                  1. dmesg_compare.zip
                  October 24, 2019 at 6:21 am in reply to: Ethernet port failure on 2nd stage u-boot #9282
                  Mat Mat Mahermemaher
                  Participant

                    I made all the changes except for the allocation of MII vs GMII. Not sure where to go here, as the options are GMII, RGMII or RMII. As I’m using the full MII I didn’t want to head to RMII. Despite the MDIO problems, using GMII works fine: I get a very stable link up (but of course only when I’ve got both ethernet cables connected).

                    Interestingly, I tried breaking the cpsw_emac definitions by allocating PHY2 to the wrong address:

                    &cpsw_emac0
                    {
                    phy_id = <&davinci_mdio>, <0>;
                    phy-mode = “mii”;
                    dual_emac_res_vlan = <1>;
                    ifname = “eth0”;
                    };
                    &cpsw_emac1
                    {
                    phy_id = <&davinci_mdio>, <1>;
                    phy-mode = “mii”;
                    dual_emac_res_vlan = <2>;
                    ifname = “eth1”;
                    };

                    The end result was the same, it still allocated the eth0 PHY to address 4 (ethtool printout below).

                    This to me indicates one thing: the eth0 PHY address is being picked up as the last-found address from an automatic scan of the MDIO bus, NOT the device tree.

                    Still lost how to fix it though!

                    Mat
                    ——————————————–

                    Settings for eth0:
                    Supported ports: [ TP MII ]
                    Supported link modes: 10baseT/Half 10baseT/Full
                    100baseT/Half 100baseT/Full
                    Supported pause frame use: Symmetric Receive-only
                    Supports auto-negotiation: Yes
                    Supported FEC modes: Not reported
                    Advertised link modes: 10baseT/Half 10baseT/Full
                    100baseT/Half 100baseT/Full
                    Advertised pause frame use: No
                    Advertised auto-negotiation: Yes
                    Advertised FEC modes: Not reported
                    Link partner advertised link modes: 10baseT/Half 10baseT/Full
                    100baseT/Half 100baseT/Full
                    Link partner advertised pause frame use: Symmetric
                    Link partner advertised auto-negotiation: Yes
                    Link partner advertised FEC modes: Not reported
                    Speed: 100Mb/s
                    Duplex: Full
                    Port: MII
                    PHYAD: 4
                    Transceiver: internal
                    Auto-negotiation: on
                    Cannot get wake-on-lan settings: Operation not permitted
                    Current message level: 0x00000000 (0)

                    Link detected: yes

                    October 22, 2019 at 3:05 am in reply to: Ethernet port failure on 2nd stage u-boot #9272
                    Mat Mat Mahermemaher
                    Participant

                      Thanks for the comments. I’ll make the amendments but I don’t think they are the route cause of this problem.

                      dmesg reattached, from what I can ascertain:
                      1. Both PHYs are detected correctly on MDIO ([1.171191] + [1.171200])
                      2. eth0 clearly gets brought up with MDIO:04 [17.571013].

                      MAt

                      Attachments:
                      1. dmesg.zip
                      October 21, 2019 at 9:39 am in reply to: Ethernet port failure on 2nd stage u-boot #9255
                      Mat Mat Mahermemaher
                      Participant

                        Final bit of useful information. Both dmesg log and EthTool both list the PHY as being at address 4. So, what I think is happening is that the kernel is mis-configured between MII port and MDIO address. What should be:
                        MII0 == MDIO Addr 0
                        MII1 == MDIO Addr 4

                        is actually reading

                        MII0 == MDIO Addr 4
                        MII1 == MDIO Addr 0

                        This would explain why MII0 port fails if MDIO<4> says the port is disconnected.

                        However, this being the case, you would think that just swapping the cpsw {} entries for phy addesses would resolve the problem. Alas not: it doesn’t actually make the slightest difference: EthTool STILL reports address 4!

                        —————————————————————————————————-

                        Settings for eth0:
                        Supported ports: [ TP MII ]
                        Supported link modes: 10baseT/Half 10baseT/Full
                        100baseT/Half 100baseT/Full
                        Supported pause frame use: Symmetric Receive-only
                        Supports auto-negotiation: Yes
                        Supported FEC modes: Not reported
                        Advertised link modes: 10baseT/Half 10baseT/Full
                        100baseT/Half 100baseT/Full
                        Advertised pause frame use: No
                        Advertised auto-negotiation: Yes
                        Advertised FEC modes: Not reported
                        Link partner advertised link modes: 10baseT/Half 10baseT/Full
                        100baseT/Half 100baseT/Full
                        Link partner advertised pause frame use: Symmetric
                        Link partner advertised auto-negotiation: Yes
                        Link partner advertised FEC modes: Not reported
                        Speed: 100Mb/s
                        Duplex: Full
                        Port: MII
                        PHYAD: 4
                        Transceiver: internal
                        Auto-negotiation: on
                        Cannot get wake-on-lan settings: Operation not permitted
                        Current message level: 0x00000000 (0)

                        Link detected: yes

                        October 21, 2019 at 8:11 am in reply to: Ethernet port failure on 2nd stage u-boot #9252
                        Mat Mat Mahermemaher
                        Participant

                          Some progress since, but even more confusing now…

                          The good news is that its now working. However, to get it working, I had to connect both ethernet ports to a valid target (including the one which isn’t actually being used)! If either Ethernet port is disconnected, then both fail to operate. Is this something you’ve come across before?

                          I’ll re-upload my files (with .txt extension): please let me know if you spot anything or can shed some light on why its operating in this manner?

                          My ultimate aim is to have the 3 ethernet ports operating as a switch (CPU as the 3rd). However, I’d settle for just one ethernet port operating (with the other disconnected) for now!

                          I appreciate your support!

                          Mat

                          Attachments:

                          1. eth.pdf

                          1. emanip-arm-ctrl.txt
                          October 16, 2019 at 9:19 am in reply to: Device tree changes for dual Ethernet port usage #9240
                          Mat Mat Mahermemaher
                          Participant

                            Thanks Eshtaartha,

                            I’ve implemented the changes for dual ethernet as suggested but I think it highlights a more fundamental problem with my system! I’ll post in a new thread…

                            July 3, 2019 at 7:58 am in reply to: automated power up/power down sequencing #8568
                            Mat Mat Mahermemaher
                            Participant

                              good suggestions. I followed them by putting an MSP430 as power/reset supervisor coupling to a supercap bank. Calculations show this should provide enough power to keep the system alive long enough to perform shutdown.

                              However, one problem I’ve got is knowing when the processor is actually shutdown. Of course the default response would be to wait for PMIC_PGOOD to fall, but this may be a very long time after the processor has departed. Reading a GPIO is the next best thing, but any application driving this will get removed before shutdown.

                              Can you think of any way to detect the moment of powerdown?

                            • Author
                              Posts
                            Viewing 13 posts - 1 through 13 (of 13 total)

                            Octavo Systems LLC all rights reserved
                            OCTAVO is registered in the U.S. Patent and Trademark Office. OSD, C-SiP, and the Octavo Logo are trademarks of Octavo Systems LLC.