• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 2406 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.

AM572x Processor SDK porting to custom board

Tom Newman
Intellectual 380 points
Other Parts Discussed in Thread: AM5728

I'm looking at porting the processor SDK to a custom board featuring the AM5728, which is--for the most part--very similar to the GPEVM.

I have generated pinmux files using TI's online pinmux tool and have generated DDR configuration files using TI's EMIF configuration tool.

I'm looking for guidance on how I utilize these files, in combination with the processor SDK, to build an SD-card image that I can use to boot Linux.

I'm ideally looking to boot a minimal version of the processor SDK (minus the Matrix touchscreen application, for example).

Are the Sitara Linux Training modules on board porting relevant here?

Thanks for your help.

  • 0
    TI__Guru**** 393215 points
    Hi,

    The software team have been notified. They will respond here.
  • 0
    TI__Guru**** 161600 points
    Hi Tom,

    First of all, you can't use the files in the format, in which the tools provide them. You should take just the generated values & implement them in u-boot.

    For Pinmux tool file you should refer to board/ti/am57xx/mux_data.c & arch/arm/dts/<your_corresponding_devicetree_file>

    The values generated by the emif tool should be relevant to:
    arch/arm/cpu/armv7/omap5/hw_data.c
    arch/arm/cpu/armv7/omap5/emif.c
    arch/arm/cpu/armv7/omap5/sdram.c
    board/ti/am57xx/board.c

    In the official TISDKs there is a prebuilt minimal filesystem, it is located in ~/ti-processor-sdk-linux-am57xx-evm-03.01.00.06/filesystem/arago-base-tisdk-image-am57xx-evm.tar.xz

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Intellectual 380 points
    Yordan

    Thanks for your reply.

    In terms of process, would I modify these files within the minimal file system and then re-compile?

    Do I need to use OpenEmbedded layers to do this?


    Thanks

    Tom
  • 0 in reply to Tom Newman
    TI__Guru**** 161600 points
    Hi Tom,

    There is no need to rebuild the whole yocto filesystem.
    You can just modify & rebuild the kernel/u-boot sources & use the prebuilt filesystem provided with the SDK.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Intellectual 380 points

    Yordan

    Thanks for the quick reply.

    For clarity, there is no need to create a new Yocto layer and use bitbake to implement these changes?  I can just make the changes within the sub-directories of the board-support directory of the processor SDK?  

    Do I then need to run a certain set of commands to build these sources into images that can be loaded onto an SD card?

    Thanks
    Tom

  • 0 in reply to Yordan Kovachev
    Intellectual 380 points

    Yordan

    Please ignore my previous message ... I now see how these changes are implemented.

    Two further questions:

    • Is it necessary to change and re-compile the device tree for the board in both u-boot and the Linux kernel, or just in the Kernel?
    • Am I correct in stating that the u-boot device tree needs only to contain the devices that need to be accessed/utilised by the bootloader?


    Thanks

  • 0 in reply to Tom Newman
    TI__Guru**** 161600 points
    Hi,

    Is it necessary to change and re-compile the device tree for the board in both u-boot and the Linux kernel, or just in the Kernel?

    Yes, because latest SDK uses device tree for both u-boot & kernel you should recompile both dts files. The easiest way (I've found so far) is to use the top level make file:
    cd ~/ti-processor-sdk-linux-am57xx-evm-03.01.00.06
    export ARCH=arm
    export PATH=~/ti-processor-sdk-linux-am57xx-evm-03.01.00.06/linux-devkit/sysroots/x86_64-arago-linux/usr/bin
    export CROSS_COMPILE=arm-linux-gnueabihf-
    make u-boot_clean
    make u-boot
    make linux_clean
    make linux
    make linux-dtbs_clean
    make linux-dtbs

    Am I correct in stating that the u-boot device tree needs only to contain the devices that need to be accessed/utilised by the bootloader?

    Yes, your understanding is correct, you can keep the u-boot dts minimized as to what the bootloader uses, then in kernel dts you can add everything else that will be needed in linux kernel.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Intellectual 380 points

    Yordan

    Looking at the .dts files for the GPEVM and the IDK, the GPEVM device tree seems to use a lot more pinctrl nodes than the IDK.  These nodes are for leds, i2c, hdmi and uart3, for example.  Both device trees use pinctrl nodes for mmc. 

    Can you explain why the IDK does not use pinctrl nodes for these devices?  Are these redundant?

    Can you also explain how the register address offsets for the pins are obtained?  I am looking at mmc1_clk, where the datasheet shows an address offset of 0x1754 whilst the GPEVM device tree shows 0x354.

    Thanks

    Tom

  • 0 in reply to Yordan Kovachev
    Intellectual 380 points
    Yordan

    I have also asked a question as to which files I should use with the SD card creation script, post u-boot compilation, here: e2e.ti.com/.../2033683.

    If you are able to offer any advice, it is much appreciated.

    Thanks
    Tom
  • 0 in reply to Tom Newman
    TI__Genius 13567 points

    Hi Tom,

    The offsets found in the device tree come from the generic PadConf.txt file that the PinMux Tool generates. The mmc1_clk offset of 0x1754 is added to the control module base address: 0x4A002000.

    Update: I just noticed the uboot dts has 0x354 for the offset. When I checked the Linux dts earlier it had 0x3754 for the offset. I've asked my software contact for clarification on the differences.

    Regards,
    Ahmad

  • 0 in reply to Ahmad_Rashed
    TI__Genius 13567 points

    It turns out that in uboot it uses a 0x1400 offset defined in dra7.dtsi. The control module's base address is 0x4A002000 but this 0x1400 offset is added to skip the IRQ and DMA section and jump to the start of the PAD registers. Therefore the register offsets in the uboot DTS are the original offset from TRM and Pinmux Tool but 0x1400 is subtracted (0x1754 - 0x1400 = 0x354).