Linux/BEAGLEBOARD-X15: A step-by-step manual to build and load TI Processor Limux SDK for Beagleboard X15 (revB1/C)

a.,

Thanks for your post. I'll try to answer your questions as best I can:

Adam Nemcek said:

Question #1: is the installation really this complicated ? or  am I making a mistake while interpreting the manuals ?

You've written a good summary. The SDK is a very large software package with practically everything you need to develop a Linux system on a TI platform. That's a lot of stuff. The two ways you've described are the two most common by far.

Adam Nemcek said:

Question #2: is this the correct bitbake command ? it does produce the "deploy" images (yet it takes quite a many hours to complete). Is there anything faster ?

That will build the "base" filesystem, which is pretty small. To build the full SDK filesystem, you need to use the arago-core-tisdk-image.

Adam Nemcek said:

Question #3: how to image a SD card with the specific arago output (deploy images) ? do I indeed have to use the create-sdcard.sh script, or is there any other way I shall  use ?

The script is certainly easier, especially if you need to partition the card. Once you have the card partitioned, it depends what you are wanting to update on the card. If you just need to update a few files, like the zImage, for example, just building and copying over zImage is certainly better than completely building a new card.

The script has provisions for using files you've built yourself. That is covered in this section:

http://software-dl.ti.com/processor-sdk-linux/esd/docs/05_02_00_10/linux/Overview_Getting_Started_Guide.html#sd-card-using-custom-images

Adam Nemcek said:

Question #4: I do see that the arago outputs files with BeagleBoard X15 name in there - so I do suppose the TI SDK supports the X15 board natively, am I correct ?

Our Linux SDK is a packaging of several open source components, like U-Boot and the Linux kernel. These projects certainly include support for the X15 and you will see files named as such. However, it is not officially supported by the SDK as indicated by the "Supported Platforms":

http://software-dl.ti.com/processor-sdk-linux/esd/docs/05_02_00_10/linux/Release_Specific_Supported_Platforms_and_Versions.html

This board is very similar to the GP EVM and in general it works fine.

I clearly understand that you wanted a complete and precise guide. I don't have a recent Arago build at the moment so I can't do that. I've kicked one off, but it will take a little while before I can provide specifics. However, it is pretty simple. The script allows you to point it to different files, as indicated above. The deploy directory will have these files in some format. You might have to move things around a bit to get it to be a perfect match, but it is only a few files.

Also, you will probably rarely want to do a complete build. Most of your work will be with specific pieces and you will likely want to just update those. You will probably want to move away from SD Cards pretty quickly as well to something like NFS for speedier development.

Adam Nemcek said:

How will the SD card imager figure out that I want to write a SD card image just and specifically for X15. Do I have to manually pick the files ? which ones  then, and how ?

This is largely taken care of for you by the "MACHINE=" in your bitbake command.

Adam Nemcek said:

Or will  all of these get loaded to the SD card,  and the u-boot picks the proper DTS ? based on what ? uenv ? do I have to edit it ?

There is an EEPROM on the board that follows a specific header format. U-Boot reads that information and uses that to decide what DTS file to load from the card.

I hope this helps you.

a.,

Glad the feedback helped you move forward.

Adam Nemcek said:

I'm still struggling with the Arago output, e.g. on how to properly insert it to the create_sdcard.sh script.
It seems the build made all the files that would be neccesary to builda new SD card image, yet I'm missing a clear mapping between the create_sdcard.sh script prompts and the files in the images/am57xx-evm folder.
I will go through the links you have provided and try to figure it out.

I kicked off a  base build and ran the sdcard-create script. I'm attaching what I did as a text file so you can review it. It provides a few details that need to be added to the documentation.

/cfs-file/__key/communityserver-discussions-components-files/791/sdcard_2D00_create_2D00_yocto.txt

As an optimization, I would probably copy just the MLO and U-Boot files needed to a separate directory so that only those are put on the /boot partition of the SD Card. They are all that is needed. The others won't hurt anything, but they are already included in the rootfs and that is where U-Boot will try to load them from.

I hope this helps clarify things.

Adam Nemcek said:

Yes you are correct, for the final HW there will be no SD card. I have to struggle with it only for the eval kits.

I would quickly switch to U-Boot on the SD Card and mount the rootfs on NFS. This is much more efficient for development.

Adam Nemcek said:

How much work is it going to take, to modify the TI SDK (say the am57xx-evk build) to a new custom hardware ?

This depends very much on:

• Your experience.
• How much driver development has to be done.
• How different the custom h/w is from TI platforms. Tied to the above.

Linux changes are largely encapsulated in creating a custom DTS file for the new H/W and getting it to work. U-Boot also has to be modified. Finally, changes needed to the filesystem have to be comprehended.

All of the changes then need to be applied to Yocto.

This training series should help with the Yocto stuff:

https://training.ti.com/customizing-yocto-for-production-series

But, it does not speak to the Linux and U-Boot changes necessary.

For Linux, which is mainly Device Tree, I highly recommend:

https://www.youtube.com/watch?v=m_NyYEBxfn8

Adam Nemcek said:

Also, as you describe, the boards do have EEPROM with a specific contents, which is used to determine the proper DTS.
In the TI SDK, is this implemented via a standard u-boot way, or did TI implement it (or made modifications to it)?
I'm wondering if it would be wise to repeat this approach (use the EEPROM) or to completely remove this piece from the boot process.

EEPROM detection is a TI implementation added to U-Boot. Whether you need this or not is going to be up to you. I think it has many advantages and builds in an easy way to handle board revisions or even different products in the future. The most important thing to remember is that you must deal with it for you new H/W somehow.

I hope this helps you. I think this pretty much covers your request, so I'm going to mark this as resolved. Feel free to reply back if you need clarification, but if it is a new issue, please create a new thread.

Thanks.