• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 1242 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

Linux/AM4378: Creating custom board. what changes to u-boot do i need if i don't include the EEPROM?

Linux/AM4378: Modifying u-boot evm board to not use I2C EEPROM data

cobsonchael
Mastermind 7930 points
Part Number: AM4378

Tool/software: Linux

we are about to have a custom board and we do not plan on having a serial EEPROM to keep the board name, MAC, etc.  if i were to not include TI_I2C_BOARD_DETECT from arch/arm/mach-omap2/am33xx/Kconfig

and we based our custom board directory on the am437x board files in board/ti/am43xx

and removed the "do_board_detect" call from my board/ti/mycustomboard/board.c as well as:

board_is_idk

rtc_only_update_board_type

rtc_only_get_board_type

board_is_eposevm

board_is_evm_14_or_later

board_is_evm_12_or_later

board_is_gpevm

board_is_sk

set_board_info_env

get_device_type

as well as removing from board.h

board_ti_is references

as well as removing from mux.c

board_is_evm

board_is_sk

board_is_idk

board_is_eposevm

and of course making the necessary changes to the hardware specific to our board.

do i still need to make changes to board_detect.c in board/ti/common/board_detect.c in order for u-boot to be able to properly boot my hardware?

  • 0
    TI__Mastermind 30536 points
    Thanks for the post. We don’t have a document for this process, but I will take a closer look I’m Monday so I can provide some more specific guidance.
  • 0
    TI__Mastermind 30536 points

    I took a look into this and discussed it with a few colleagues as well to come up with some recommendations. We haven't documented this to date as there are so many system dependent variables that could lead to completely different results based on what you might want to do. For example, it is very beneficial to keep the ability to run the same code on an EVM for testing and such. This is a great debug step and since you've used the SK as a reference, it could be very useful for you in the future. If you completely rip out the board detect code, you will no longer be able to do this easily.

    Instead, you might want to create a config for your board that basically avoids reading the eeprom but initializes the header with the right information for your board (basically short circuiting the eeprom reads and actign like it read them and returned your board. This is all done in board/ti/common/board_detect.c and .h. This would allow you to build for your board and easily switch back to building for the SDK and SK for testing if needed.

    All of the rest of the U-Boot logic is based off of this setting, using the "board_is" calls to read the U-Boot structure in RAM (populated from the eeprom) to decide what board is being used. Therefore, if you've set the structure up for your board, it should read these correctly and make the right decisions. You could simply change the board_is_sk function to always return true. Or you could use a different board name and add that logic to the paths that the SK chooses. This would give you some additional flexibility to keep from modifying the SK code if it became necessary. These calls are all in the board/ti/am43xx/board.h file.

    I believe this is a good path forward to maintain relatively easy compatability with the SDK and SK and allow you to build and run very similar code one your new platform.

    On this:

    cobsonchael said:
    we are about to have a custom board and we do not plan on having a serial EEPROM to keep the board name, MAC, etc.  if i were to not include TI_I2C_BOARD_DETECT from arch/arm/mach-omap2/am33xx/Kconfig

    I couldn't get this to build right and believe we have a bug in this config. So, without further debug, it won't be useful. I'm going to try it on the latest SDK to make sure this has been corrected. For the reasons listed above, I don't believe I'd use it anyway if you want to be able to easily run on TI's EVMs.

    I hope these recommendations make sense and provide some guidance for you. If I can clarify anything, please let me know.

    Thanks.

  • 0 in reply to RonB
    Mastermind 7930 points
    so let's forget about the evm and let's say i want to strip out all mention of any other board from my custom board directory and files. let's say my goal is to change as little as possible in the core files and make most of my modifications to my board.c/mux.c files. i'm ok with rebuilding u-boot but i am not ok with having to remember 10 months down the road what changes i have to undo or the fact that i have to make any changes at all except use the right config file when issuing the "make" command.

    does board detect happen no matter what for a board in the TI folder/config? if i remove TI_I2C_BOARD_DETECT does it skip board detect or does it produce some kind of error/bug? ultimately my goal would be skip board detect and try to not use any of the values that would have been gathered from said board detect and use just hard-coded values for now. is this or is this not possible without changing board_detect.c

    i have a start of a board directory and files for our board with TI_I2C_BOARD_DETECT not specified and it compiles but i have nothing to test it on (our board isn't built yet)
  • 0 in reply to cobsonchael
    TI__Mastermind 30536 points
    If you remove TI_I2C_BOARD_DETECT, board_detect.c shouldn't even be built based on the Kconfig. So, you should not get any board detect settings. board_is functions will simply return false. This seems like it would meet your needs.

    I hope this is helpful to you.
  • 0 in reply to RonB
    TI__Mastermind 30536 points
    Hello,

    I wanted to check back in with you to see if you had further questions on this topic. If not, I'd like to go ahead and close this thread. You are always welcome to post new questions to a separate thread or reopen this one if you feel it is the same issue.

    Thanks.
  • 0 in reply to RonB
    Mastermind 7930 points
    until we get the boards - mid march - i likely won't have any questions. if i do i will make a new thread