Issues Booting Custom Board

Forums Devices OSD335x-SM Issues Booting Custom Board


  • Author
  • #4524


    Hello Forum,

    We have a board that we designed, pretty much following the OSD3358-SM-RED reference design.

    The system appears to be running (everything from the Octavo bring up guide looks good).

    I am able to get to the UART boot mode, and am receiving a repeating ASCII ‘C’ over the terminal. I am assuming this indicates power rails and clocks are working as they are supposed too.

    However, I can not seem to get this design to run u-boot off an SD card or UART. I have tried some beaglebone SD card images, the OSD3358-sm-red image, and have built a few custom images.

    A logic analyzer on the SD lines show pulses on clock, cmd, and data for about 250 msec, then stops.

    I am missing some custom config/build setting? do I need to program the on chip EEPROM?






  • #4527
    Neeraj Dantu
    Neeraj Dantu

    Hi Eric,

    Yes, you need to program the EEPROM with corresponding board ID for the RED board. U-boot checks for this ID before proceeding to boot. Writing the Beaglebone Black ID to the EEPROM should be sufficient for it to boot the RED board image.

    Best regards,



    • #4583

      Neeraj, What is the recommended process for getting the eeprom programmed?

    • #4608
      Neeraj Dantu
      Neeraj Dantu

      Thank you Eric for your response.

      There are a couple of ways to get around the EEPROM ID check.

      1. Bypass the checks in u-boot:

      Here is a link to the section of code that you will need to modify:
      I’m not sure if this is exactly the same code as what you are running, but we have seen in the past that the puts() for the “Bad EEPROM …” statement would not actually print anything to the UART console and it would look like everything would just hang when the EEPROM was not programmed. If you look at the board/ti/am335x/mux.c file of your u-boot build, then you can see the actual code you are running and can modify it so that you use the “board_is_bone()” configuration for the pinmux (or define your own)

      2. Use Robert Nelson’s patch to create u-boot that will boot and allow you to program the EEPROM: In u-boot apply the patch:

      Using the “blank” image, create a file in the first partition:
      Use the variable:  board_eeprom_header
      For a built-in device:


      For a non built-in, use “eeprom_program”


      You can also just run the “run eeprom*” commands from U-Boot console.  (This works in “blank” and “normal” images.)

      One other thing that I wanted to mention:  I know you are aware of the Linux device tree, but u-boot also uses a device tree that you might need to modify.  You should find the u-boot device tress in ./arch/arm/dts  It is useful to look through the 0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch patch from Robert Nelson (see since this patch modifies device trees and can point you to important directories in u-boot.

      • This reply was modified 2 weeks, 5 days ago by Neeraj Dantu Neeraj Dantu. Reason: Formatting
      • This reply was modified 2 weeks, 5 days ago by Neeraj Dantu Neeraj Dantu.
  • #4555


    Ok, we programmed the internal EEPROM with the proper values and our system is running. We were wrongly assuming this was pre-programmed.



  • #4581

    Any suggestions on the best method to program the EEPROM? We are seeing a very similar issue.

    When we compare the SDcard commands on our board to those of the RED Dev board, we see a a pretty different looking trace.

    The SD CLK is running at ~120kHz on our board, compared to 400kHz on RED is a clear example of the differences.

    Can a non-programmed EEPROM cause these differences?

  • #4582


    Yes, a non-programmed  EEPROM will do to that to the SD clock.

    What I learned, is u-boot needs the EEPROM data to set things like clock speed, MMC, and other stuff.  If you have access to the I2C_0 pins, you can use a i2c tool to program the EEPROM.

    I was being lazy, so tried to boot over the UART following this guys blog:


    however I went in and hacked the uboot source to force it to use the BeagleBone Black configuration. if you want to do the same, edit:



    Once in the Uboot bootloader, I use the uboot i2c application to program the EEPROM.



  • #4584

    We’ve had success with the same approach!

    Thanks so much for blazing the trail EricT!


You must be logged in to reply to this topic.