OSD3358-SM custom board linux boot issue

Forums Devices OSD335x-SM OSD3358-SM custom board linux boot issue

Viewing 14 reply threads
  • Author
    Posts
    • #9065
      Anthony PAnthony
      Participant

      Hello,

      I built a custom board with the OSD3358-512-BSM. It is based loosely on the pocketbeagle but includes I2C and SPI components, a host USB and a wifi module. I did not breakout the UART0 so can’t tell the boot status. The boot config appears correct because I have it configured to boot first from my SD card. I implemented the patches to bypass the EEPROM ID. I flashed the beaglebone Linux image and tried booting with no success. I would have assumed if the board boots properly, I would see a USB network device like I do with the beagleboard and be able to ssh in but the device never shows up. A few seconds after powering up, I can detect a RNDIS/Ethernet Gadget from Texas Instruments but it disappears after a few seconds.

      I assumed I applied the EEPROM bypass patches correctly and this may be a device tree issue. When I don’t apply patches, I never see the RNDIS/Ethernet Gadget. I am working to build a custom device tree now but having issues compiling it because I can’t use the custom board compiler since I’m not able to ssh in.

      I tried using the pocketbeagle and beaglebone black wireless compiled device trees with no luck. Does this seem like a device tree issue to you or would it still boot to a level where I would be able to see the USB network device to ssh in? Any help is appreciated!

      Thanks

    • #9066
      Anthony PAnthony
      Participant

      I have been trying to compile a new custom device tree for my custom board. However, I am running Ubuntu 18.04 on the laptop I used to compile and getting errors (unable to parse input tree) with the am33xx.dtsi file. I assume the compiler with my Ubuntu isn’t compatible with the version files I am modifying. If this is the case, can you please direct me to the appropriate version of DTB-Rebuilder?

    • #9068
      Eric TannerEricT
      Participant

      Anthony, It really could be a number of things. As far as I can tell, without the UART0, it will be near impossible to figure out. Any chance you can get UART0 on at least one board?

      You can build your dtb on Ubuntu 18.04 you will have to set up your environment to cross-compile for the ARM architecture.

    • #9069
      Anthony PAnthony
      Participant

      Hi Eric,

      Unfortunately, the boards have been built and we did not breakout those UART pins. Is it at least safe to assume that we need to get a working device tree up before one can see the usb network device?

      If so, I will keep working that. I was able to find a beaglebone board to run dtb-rebuilder on my device tree but running into this error.

      Error: src/arm/am33xx.dtsi:14.1-2 syntax error
      FATAL ERROR: Unable to parse input tree
      Makefile:148: recipe for target ‘src/arm/pelican_v0.dtb’ failed
      make[1]: *** [src/arm/pelican_v0.dtb] Error 1
      Makefile:96: recipe for target ‘all_arm’ failed
      make: *** [all_arm] Error 2

    • #9070
      Neeraj Dantu
      Moderator

      Hey Anthony,

      The error log for the dtb rebuilder indicates that there is an error in line 14 of file am33xx.dtsi. Did you change anything in this file?

      Please see the device tree tutorial: https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/linux-device-tree/ and pinmux tutorial for dtb-rebuilder usage: https://octavosystems.com/app_notes/osd335x_pinmux/

      Note that the USB RNDIS adapter gadget is started by a startup script: https://github.com/RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh and it checks for the model name “/proc/device-tree/model” against the strings here: https://github.com/RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh#L113(may vary for different Beagle images). The model is set in the device tree like: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/src/arm/am335x-boneblack.dts#L16. If you are using a custom device tree, you may want to copy Beaglebone Black model name and compatibility string in the device tree.

      For the board, if you are able to see the ethernet gadget for a little while, the board has indeed booted and is at least running the internal ROM code.

      We suggest you use one of the BLANK images from Beagle from https://rcn-ee.com/rootfs/bb.org/testing/ without any patch being necessary. These images do not check for a Beagle ID in the EEPROM. For example: BBB-blank-debian-9.5-iot-armhf-2018-10-07-4gb.img.xz

      You should also verify all the output voltage rails and clock on the SD card CLK line to make sure that the board is not failing and is probing the SD card for an image to boot.

      Please let us know how it goes and if you have more questions.

      Best,

      Neeraj

      • #9071
        Anthony PAnthony
        Participant

        Hi Neeraj,

        Thanks for the detailed response. I was able to resolve the error in the log shortly after posting.

        When you mention copying a BBB model name and compatibility string in my custom device tree, do you mean arbitrarily adding these strings or does it matter which model I enter? My board is essentially a pocketbeagle with wifi and a usb host.

        model = “TI AM335x BeagleBone Black”;
        compatible = “ti,am335x-bone-black”, “ti,am335x-bone”, “ti,am33xx”;

        I’ll try the BLANK image you posted. Is it safe to assume I’ll still need a working device tree for by board for it to fully boot or is this just easier than applying those patches to bypass the EEPROM check?

        Thanks for all your help
        Anthony

    • #9072
      Neeraj Dantu
      Moderator

      Anthony,

      The model you enter does make a difference for start-up services. I would suggest try the Beaglebone Black model name to try and boot the board and communicate via the RNDIS ethernet adapter since that is your first goal.

      You will not need a separate device tree to boot the board if you are booting from the SD card interface using the same pins as PocketBeagle and if you are using the same USB0 configuration as on the PocketBeagle.

      Now, in order for the board to be fully functional however, you would need to build a custom device tree that includes the wifi module and other devices on your board.

      Hope that helps.

      Best,

      Neeraj

    • #9073
      Anthony PAnthony
      Participant

      Hi Neeraj,

      If it is possible to progressively update the device tree, I would assume using the pocketbeagle device tree should at least get me communicating over the USB client (USB0) and board booted from SD (MMC0) since I used the same pins from the Pocketbeagle for these 2 components. I know I won’t have WIFI or the USB host but by using the default Pocketbeagle device tree, should I at least be able to boot the board and see the network device on my computer?

      Thanks,
      Anthony

    • #9074
      Neeraj Dantu
      Moderator

      Anthony,

      Yes, you should be able to boot the board with the PocketBeagle device tree

      Best,

      Neeraj

    • #9075
      Anthony PAnthony
      Participant

      Neeraj,

      Update – I tried using the BLANK image you provided above (without patches) with the am335x-pocketbeagle.dtb tree but had no luck. I wasn’t able to see to ethernet gadget with this configuration.

      When I used the latest beaglebone image, with the patches and the am335x-pocketbeagle.dtb tree, I was able to get the board to boot and ssh over usb. I will try to update this tree with my board updates and see how it turns out.

      Thanks for all your help!

      Anthony

    • #9077
      Neeraj Dantu
      Moderator

      Anthony,

      Thanks for the update! Glad you are able to get it to work.

      I am not sure why you were unable to boot with the BLANK image. Do you have an RTC oscillator on OSC1 on the board? If you do not, my guess is that u-boot is trying to exercise RTC and running into a fault(See https://octavosystems.com/forums/topic/osd335x-c-sip-bootloader-issues/)

      Let us know if you have any other questions.

      Best,

      Neeraj

    • #9079
      Anthony PAnthony
      Participant

      Neeraj,

      You are correct. I do not have an RTC oscillator for OSC1.

      Anthony

    • #9110
      Anthony PAnthony
      Participant

      Neeraj,

      To run the BLANK image, I would like to update the SLP to disable the RTC but can’t seem to find the instructions to do this. Can you please provide these instructions?

      Thanks,
      Anthony

    • #9111
      Neeraj Dantu
      Moderator
    • #9150
      Anthony PAnthony
      Participant

      Neeraj,

      Thanks! I’ll try the guide out today and report back!

      I have a separate issue to inquire about now. I have the WL1835 integrated and wired per the guide with the BB blue as a reference. I used the BB blue device tree as a baseline and everything seems to work fine. However, when I scan wifi and issue “services” command in connmanctl, it returns an empty list. The “technologies” command shows the wifi is powered. I’ve tried different antennas with no luck. Any troubleshooting tips for this?

      Thanks
      Anthony

    • #9160
      Anthony PAnthony
      Participant

      Neeraj,

      Please disregard the last post. Some device tree updating fixed my wifi problem so that is resolved. I tried following the guide above to disable RTC but still having issues booting the BLANK image. I’ll continue to troubleshoot that but if you have any other tips, please let me know.

      Thanks for all your help
      Anthony

Viewing 14 reply threads
  • You must be logged in to reply to this topic.