512-861-3400Log inCreate Account

Dusty

Forum Replies Created

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • July 11, 2018 at 7:47 am in reply to: Device Tree Rebuilder #5951
    Dusty
    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 10, 2018 at 10:44 am in reply to: Device Tree Rebuilder #5946
      Dusty
      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, 6 months ago by Dusty.
        Attachments:
        1. dtb.zip
        July 8, 2018 at 7:18 pm in reply to: Device Tree Rebuilder #5904
        Dusty
        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 6, 2018 at 5:11 pm in reply to: Device Tree Rebuilder #5900
          Dusty
          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 6, 2018 at 2:54 pm in reply to: Device Tree Rebuilder #5898
            Dusty
            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 4, 2018 at 3:06 pm in reply to: Device Tree Rebuilder #5883
              Dusty
              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
                June 29, 2018 at 2:27 pm in reply to: Device Tree Rebuilder #5857
                Dusty
                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 9:44 am in reply to: Device Tree Rebuilder #5850
                  Dusty
                  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, 6 months ago by Dusty.
                    • This reply was modified 6 years, 6 months ago by Dusty.
                    Attachments:
                    1. DeviceTree-files2.zip
                    June 27, 2018 at 9:51 am in reply to: Custom board, first boot – UART0 baudrate 'off'? #5822
                    Dusty
                    Participant

                      Thanks Neeraj,

                      the 10k pull up helped to recognize the correct SYSBOOT bits and the system boots with 115200 baud.

                      The next steps will tell if the stronger pull up messes with the external signal after boot. If that’s the case (or maybe anyway), we’ll add buffers for the shared signals on the next board spin…

                      Dusty.

                      June 26, 2018 at 4:58 pm in reply to: Custom board, first boot – UART0 baudrate 'off'? #5817
                      Dusty
                      Participant

                        Thank you Neeraj.

                        1) Both OSC0 pins show a nice 24MHz signal. The p-p voltage on OSC0_OUT is about 800mV, on OSC0_IN about 50mV. We’re using the 7A-24.000MAAJ-T crystal.

                        2) SYSBOOT[15] is pulled down with 100k, and SYSBOOT[14] is pulled up with 100k.

                        And by checking this I probably just answered my question…:

                        SYSBOOT pins [15] and [14] (as well as SYSBOOT[11..8]) are also connected to other hardware as GPIO (or rather MII0_PRU), due to the lack of other pinmux options. The plan was to hold that other chip in reset with a pulldown on it’s reset# line, until the OSD3358-SM actively takes it out of reset by setting this GPIO output to high after booting.

                        I guess the other chip still pulls SYSBOOT[14] too far down, although held in reset. SYSBOOT[15] shows 2.1mV (OK) and SYSBOOT[14] has 648mV (not OK).

                        I looked into buffer / line driver options to isolate the external signal during boot when designing the board, but ‘hoped’ the reset trick will work without further hardware.

                        Do you have any (proven) recommendations for this issue?

                        Thanks again,
                        Dusty.

                         

                         

                      • Author
                        Posts
                      Viewing 10 posts - 1 through 10 (of 10 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.