512-861-3400Log inCreate Account

Device Tree Rebuilder

Forums › Devices › OSD335x-SM › Device Tree Rebuilder

Viewing 17 reply threads
  • Author
    Posts
    • June 28, 2018 at 10:26 am #5842
      Dusty PaulsenDusty
      Participant

        Hello,

        I followed the instructions in the “OSD335x Lesson 2: Linux Device Tree” App Note to modify and rebuild our custom board device tree.

        I ran into this issue when trying to compile using Robert Nelson’s Device Tree Rebuilder:

        Attached are the two input files located in the /src/arm/ folder.

        What am I doing wrong?

        Thank you,
        Dusty

        • This topic was modified 6 years, 4 months ago by Dusty PaulsenDusty.
        Attachments:
        1. DeviceTree-files.zip
      • June 28, 2018 at 6:37 pm #5849
        Eshtaartha BasuEshtaartha Basu
        Moderator

          Hello Dusty,

          It looks like you’re using v4.17 OSD335x Device Tree files. These files are incompatible with v4.4 dtb-rebuilder. To get around this problem, you should use v4.4 OSD335x Device Tree files.

          You can get them here: https://github.com/octavosystems/OSD335x-Device-Tree/tree/v4.4.

          You can also manually navigate to this page on our Github Device Tree page by clicking on “Branches” drop down menu > Tags > v4.4. I’ll soon update the Lesson 2 webpages to directly point to this version.

          While going through your device tree files, I found few other issues that you will have to fix once you get around the version problem.

          1. In line 139 of WV_OSD3358-SM__066.dts, small brackets “( )” are not allowed as part of node names. This will lead to syntax error (Check Table 2.2 of Device Tree Spec v0.2 for all the allowed characters).

          2. In the same file, there are references to the following non-existent nodes/labels which will lead to invalid reference error:

          mmc1_pins

          emmc_pins

          cpsw_default

          cpsw_sleep

          davinci_mdio_sleep

          Also, make sure all the new pin muxing nodes you’ve added are properly referenced/used by suitable nodes to make sure your hardware operates as intended.

          Please let us know if you have any other questions.

        • June 29, 2018 at 9:44 am #5850
          Dusty PaulsenDusty
          Participant

            Thank you Eshtaartha.

            I included the osd335x-sm.dtsi file you referenced and (believe) I fixed the invalid references.

            Please see error message below…  did I miss something? Attached are the two input files used.

            Thank you,
            Dusty

             

             

            • This reply was modified 6 years, 4 months ago by Dusty PaulsenDusty.
            • This reply was modified 6 years, 4 months ago by Dusty PaulsenDusty.
            Attachments:
            1. DeviceTree-files2.zip
          • June 29, 2018 at 2:10 pm #5856
            Eshtaartha BasuEshtaartha Basu
            Moderator

              Hello Dusty,

              Could you please tell me which Debian image you’re using (RED Debian image or one of the BeagleBoard Debian images)?

              This will help me use the same kernel version while debugging this problem so that I can give you the right solution.

               

            • June 29, 2018 at 2:27 pm #5857
              Dusty PaulsenDusty
              Participant

                Hello Eshtaartha,

                on the uSD card is the latest “bone-debian-9.4-iot-armhf-2018-06-17-4gb” image, and the host computer (where the SD card is inserted in) runs Ubuntu 18.04 LTS.

                Thank you,
                Dusty

                 

              • June 29, 2018 at 4:21 pm #5859
                Eshtaartha BasuEshtaartha Basu
                Moderator

                  Thanks Dusty. I’m currently working on resolving your issue and will get back to you shortly.

                • July 3, 2018 at 4:39 pm #5880
                  Eshtaartha BasuEshtaartha Basu
                  Moderator

                    Dusty,

                    We apologize for the inconvenience.  During our most recent update, we had modified all of the device tree files so that they could be built under the mainline Linux build flow.  Unfortunately, we did not also make sure that they were able to be used within the dtb_rebuilder mentioned in the tutorials.  We have now posted a version of the device tree files that can be used in the dtb_rebuilder.  You can find them here:

                    https://github.com/octavosystems/OSD335x-Device-Tree

                    I was able to successfully build your custom device tree file (WV_OSD3358-SM__066.dts) after pairing it with the new tested .dtsi file (osd335x-sm.dtsi) and making the following changes:

                    a. I corrected an improper reference to “pruss” node (have added comment in file to indicate the same).

                    b. I commented out a reference to non-existent node “emmc_pins” (have added comment in file to indicate the same).

                    I was also able to login to Debian (I used the latest BeagleBoard Debian Image 9.4 LXQT) using WV_OSD3358-SM__066.dtb. 

                    Before making further modifications to your device tree files, I would suggest building the files I’ve sent on your setup to make sure you have a good starting point. 

                    Please let us know if you have any other questions.

                    Attachments:
                    1. YourCustomDT.zip
                  • July 4, 2018 at 3:06 pm #5883
                    Dusty PaulsenDusty
                    Participant

                      Hello Eshtaartha, thank you very much for following up!

                      I was also able to build my dtb, using both dts and dtsi files you attached to your last response.

                      Here’s the output:

                      Interesting, my dtb has a different file size than yours (47kb vs 50kb).

                      I attach the dtb I built, as well as the boot log when booting the OSD3358-SM with your dtb vs. mine.

                      My uEnv.txt is also attached.

                      Thank you again for the great support!
                      Dusty

                      Attachments:
                      1. DeviceTree.zip
                    • July 5, 2018 at 4:44 pm #5897
                      Eshtaartha BasuEshtaartha Basu
                      Moderator

                        Hello Dusty,

                        You’re welcome. I’m glad you were able to build the device tree on your setup.

                        I built your dtb on my development board (OSD3358-RED) running latest Debian 9.4. I did not get any warnings. I believe your compiler version is different from mine since you’re  using dtb-rebuilder on Ubuntu.

                        All BeagleBoard images and RED image come with a “dtc” (Device Tree Compiler). You can find it under /usr/bin of BeagleBoard Debian image or RED image. dtb-rebuilder uses this compiler to compile your dts into dtb. I don’t know which version of dtc you’ve installed on your Ubuntu machine (Keep in mind that dtb-rebuilder does not come with a dtc).

                        I would recommend copying dtb-rebuilder (or you could just clone the git repo) directly to one of the directories of your dev board (hope you have one of BeagleBoards or RED board) running Debian 9.4 and building device tree files directly on the dev board as described in Device Tree article. This should resolve the warnings.

                      • July 6, 2018 at 2:54 pm #5898
                        Dusty PaulsenDusty
                        Participant

                          Thanks a lot, Eshtaartha.

                          I have it now all locally on a PocketBeagle with the latest official beagleboard 9.4 debian image and dtb-rebuilder-4.4-ti, but run into ‘permission denied’ issues when trying to build the dtb:

                          I tried with root permission and moved it to different locations, but can’t figure out the ‘permission denied’ issue yet.

                          I know, it’s not related to the original issue, but I wanted to let you know why I haven’t confirmed success with building the custom dtb yet…

                          Best regards,
                          Dusty

                           

                        • July 6, 2018 at 4:24 pm #5899
                          Eshtaartha BasuEshtaartha Basu
                          Moderator

                            Hello Dusty,

                            It is better to always keep the “dtb-rebuilder” at home directory ( /home/debian ) to avoid permission issues. The permissions on some of your files might have gotten altered when you copied dtb-rebuilder to PocketBeagle. Check the file permissions of fixdep file by running ls -l command in /dtb-rebuilder-4.4-ti/scripts/basic directory. The permissions for this file should be 755 (-rwxr-xr-x). If you have something different, change the permissions using chmod.

                            Also, resolve time skew warnings by running make clean command in /dtb-rebuilder-4.4-ti directory. If that doesn’t fix it, run the touch * command in the dtb-rebuilder directory and the dtb-rebuilder/src, dtb-rebuilder/src/arm sub-directories to update the file modification time of all files to resolve the warning.

                          • July 6, 2018 at 5:11 pm #5900
                            Dusty PaulsenDusty
                            Participant

                              Yes Sir, thank you again. This did help to fix the permissions issue.

                              The dtb compiled without warnings.

                              The boot process on the custom board using the just built dtb got stuck in the “RNDIS – The remote end did not respond in time” (log attached), so next up is verifying the Device Tree for correctness, and the boot configuration (set to [4:0] 11100, booting from uSD at MMC0).

                              Thanks again!
                              Dusty

                              Attachments:
                              1. custom-boot-log.txt
                            • July 8, 2018 at 7:18 pm #5904
                              Dusty PaulsenDusty
                              Participant

                                Sorry – can’t edit the previous post. Looks like the uEnv.txt was corrupted. Now it boots with the custom dtb (see log below).

                                Looks like we need to debug eth0 (KSZ9031 gbit PHY) next…

                                Thanks again for your help!
                                Dusty

                                 

                              • July 9, 2018 at 11:35 am #5912
                                Eshtaartha BasuEshtaartha Basu
                                Moderator

                                  Hello Dusty,

                                  You’re welcome.

                                  Make sure there are no issues in the custom pin muxing and device tree bindings in your custom device tree. Have you checked if phy_id is correct on your device tree? Your ethernet PHY (KSZ9031) has 3 address pins: 35, 15 and 17. I don’t know what these are set to on your board. But, make sure it matches your phy_id. 

                                  For example, in the RED device tree, phy_id is as follows:

                                  phy_id = <&davinci_mdio>, <4>;

                                  It is set to “4” because the phy_addr pins of our Eth PHY are set to “4” in RED hardware. Also make sure your Eth PHY is powered up properly and not held in reset.

                                  You can also use dmesg command and kernel log ( /var/log/kern.log ) to better debug your design and quickly find the source of the problem.

                                   

                                • July 10, 2018 at 10:44 am #5946
                                  Dusty PaulsenDusty
                                  Participant

                                    Thank you Eshtaartha.

                                    The PHYAD[2:0] strap-in options are set in hardware to 001b.

                                    In the dts I have used phy addr 1 at emac0:

                                    Interesting part is that the PHY seems to be detected

                                    but still fails to load properly

                                    Wondering why it is trying to find the PHY at addr 4, although I have specified 1?

                                    Since you mentioned the RED uses addr 4…  following the app note, I programmed the board ID to being an Octavo Systems OSD3358-SM-RED board

                                    Suspecting this to be the issue, I reprogrammed the board ID to the BeagleLogic Standalone, which uses the same PHY at the same address (https://github.com/RobertCNelson/omap-image-builder)

                                    Now the boot process stalls at ‘Starting Kernel…’

                                    If I abort autoboot, I can talk to the PHY at address 1 through mii commands so I don’t suspect an MDIO issue talking to the PHY.

                                    Can the board ID be the problem?

                                    Thank you again,
                                    Dusty

                                     

                                     

                                     

                                     

                                     

                                    • This reply was modified 6 years, 3 months ago by Dusty PaulsenDusty.
                                    Attachments:
                                    1. dtb.zip
                                  • July 10, 2018 at 6:40 pm #5949
                                    Eshtaartha BasuEshtaartha Basu
                                    Moderator

                                      Hello Dusty,

                                      It doesn’t look like there is anything wrong with your Device Tree. I think it is better if you do a clean re-build of your dtb and also re-flash your SD card and/or eMMC with a clean image and try again. If the problem persists, you can try probing the MDIO lines and observing the signals.

                                      On researching about KSZ9031 PHY online, I found a couple of discussions of TI forum which talk about issues that are very similar to what you’re facing. Looks like many people have faced the same issue with this particular PHY:

                                      1. https://e2e.ti.com/support/arm/sitara_arm/f/791/t/488807?Micrel-9031-on-Phy-address-0x0-is-not-working- (Pay attention go Biser Gatchev-XID’s comments)

                                      2. https://e2e.ti.com/support/arm/sitara_arm/f/791/t/182794 (Check if any of the recommendations done by Mugunthan V N applies to your case)

                                      This may be a reset timing issue as explained by Biser. If your current setup supports external control of PHY’s reset pin, I would suggest experimenting with it. Also, try experimenting with PHY address by changing it to 0, 2,3 or 4 (although your PHY is on 1) as done by the person from forum post (1) above.

                                    • July 11, 2018 at 7:47 am #5951
                                      Dusty PaulsenDusty
                                      Participant

                                        Thanks Eshtaartha.

                                        I’m aware of the posts and have checked most of it, but I will make a brand new card/build and go over everything again at this point…

                                        Just to make sure: Once the boot process gets past the board ID check (and loads the beagleboard image), the device tree will ‘override’ the board/device configuration. Means, the board ID programmed into the EEPROM doesn’t really matter (whether it’s the RED or BBB or anything else) as long as the image loads, only the custom DTB does in terms of device configuration, is that correct?

                                        Also, in general, for a custom board, would you recommend to work off of the beagleboard.org image or rather using the TI SDK (http://www.ti.com/tool/PROCESSOR-SDK-AM335X)?

                                        Thanks,
                                        Dusty

                                      • July 13, 2018 at 11:59 am #6019
                                        Eshtaartha BasuEshtaartha Basu
                                        Moderator

                                          Hello Dusty,

                                          The Board ID continues to matter as long as U-Boot is in control (i.e., even after the Board ID check). Because, the Board ID not only helps U-Boot choose the right “dtb” but also affects other U-Boot environment variables. You can understand this better if you go through the U-Boot patch code that helps you bypass Board ID check. The patches make sure U-Boot boot process continues normally even without the Board ID. From the code you should be able to infer the other uses of Board-ID:

                                          https://rcn-ee.com/repos/git/u-boot-patches/v2018.03/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch

                                          https://rcn-ee.com/repos/git/u-boot-patches/v2018.03/0002-U-Boot-BeagleBone-Cape-Manager.patch

                                          OSD335x EEPROM During Boot (https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/) gives you more information about the usage of the above patches.

                                          Both BeagleBoard Debian images and TI SDK are fine for development but we do not know the status of development/support for TI SDK. But, we do know that the BeagleBoard Debian is being actively developed, maintained and supported.

                                           

                                      • Author
                                        Posts
                                      Viewing 17 reply threads
                                      • You must be logged in to reply to this topic.

                                      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.