Linux/TMDXIDK5728: Menuconfig - Linux SD Card Kernel

Hi Alec,

Can you give a general description of what you're trying to develop and debug?  The process can look quite a bit different depending on whether you're talking u-boot, kernel, Linux user space, graphical application, etc.

Alec Phillips said:

Also to assume that all developers using Linux on the ARM core are running Linux OS on their host computer is inaccurate.

You can open tera term or putty from your Windows PC and log into a console.  You can also use CCS from Windows or Linux.  However, to build u-boot, kernel, file system, etc. you need a Linux host PC.  That's more of a requirement than an assumption.

Alec Phillips said:

I am developing in Windows using Linux on the IDK.

My main PC is a Windows PC too.  I usually have a Tera Term window for my target console as well as a putty window where I SSH into my Linux PC.  You might want to consider exporting an NFS or samba share from your Linux PC and then mounting it from the ARM.  That allows you to easily build programs from your Linux box (e.g. putty console) and then run them from the ARM (e.g. Tera Term).

Normally I use JTAG debug for u-boot and printf for just about everything else.  For heavy duty app development you may want to consider gdb as well.

Alec Phillips said:

I have access to a Linux laptop but my primary workstation is a Windows laptop; so if I can debug simply on the board, this makes my life a lot easier.

To some degree it depends on your expectations for debug.  If it is console prints, then yes, you can absolutely do that directly on the board.

I'm sure I didn't fully answer your question in my reply.  My intent is mostly to get the conversation moving in a productive direction.

Best regards,
Brad

Alec Phillips said:

We have various communication protocols, CAN, TCP/IP, etc. We are using the DSP on the Sitara for our control loops, and the ARM for other processes, such as the Human-Machine Interface, and other, less process-intensive, controls. I have very little experience using Linux, but I understand the Linux kernel on the ARM core is the preferred/best method for development. 

HMI is better-suited to the ARM.  There are rich graphical frameworks/utilities available (Qt, Chrome, etc.).

Alec Phillips said:

I'm not sure about exporting the NFS or samba share, but it seems like what I'm trying to do. Can you provide more details on this please? 

First, you should make sure anything you're doing with respect to network shares complies with your IT requirements, regulations, etc.

Personally, I like using Samba shares because they are visible everywhere (Windows, Linux Host, Embedded Linux Target).  If you're not dealing with super sensitive stuff (for starters), you can just use a simple "guest" share.  This is open access to anyone on your network, so this is likely not the best solution for all cases, but it's certainly the easiest solution to get started.  There are lots of tutorials on the creation of shared folders, so I'm going to leave that as a separate item for you to get started.  Once you have a shared folder you can mount that drive from the Linux target with a command along these lines:

mkdir -p /mnt/samba

mount -t cifs -o guest,vers=3.0 //<machine>/<dir> /mnt/samba

Alec Phillips said:

It is confusing for me in the TI material, whether the Linux instructions are for inside the Linux OS, or for root debugging.

Any materials pertaining to building code are from the Host PC perspective.  We don't generally build anything from the target.  When we execute the programs, that's done from the target.

Alec Phillips said:

I guess my expectations are similar to CCS, because that's what I have experience using.

In order to have IDE debug you would likely need to transition entirely to your Linux PC for development.  You would then configure CCS for gdb debug (i.e. via Ethernet not JTAG).  There are some more details here:

http://software-dl.ti.com/processor-sdk-linux/esd/docs/05_02_00_10/linux/Foundational_Components_Tools.html#gdb-setup-with-ccs

Alec Phillips said:

Am I able to develop programs in the root?

The examples provided with the SDK are generally run from a "root" login.  For your initial development you will likely want to keep it that way.

Alec Phillips said:

mkdir -p /mnt/samba

mount -t cifs -o guest,vers=3.0 //<machine>/<dir> /mnt/samba

I am not sure if this will go over. So as an alternative to this networked method, what would you suggest? Rewriting onto the SD card with each change I make?  

Rewriting the SD card becomes a bottleneck if you're making frequent changes.  There are other ways that might be more acceptable from an IT perspective.

On a related note, your Linux PC should be able to find your EVM using its mDNS name (am57xx-evm.local).  In other words, you should be able to run "ping am57xx-evm.local" to ping your board.  Taking that one step further you can use "scp" (secure copy) for copying a file from your Linux PC to your target.  For example:

scp my_compiled_program root@am57xx-evm.local:/home/root

Alec Phillips said:

Why can't I use the JTAG to USB XDS100v2 for debugging in Linux? Linux CCS can only be debugged via Ethernet? I am pretty sure I was able to run an example program through the JTAG interface and had gotten minicom console output. 

You can only load/debug fully linked executables with CCS.  Linux programs are dynamically linked at run-time, e.g. you don't know at what address they will physically reside.  Also, JTAG debug is highly invasive in that it stops the entire CPU while you are stepping through code.  Often in Linux you want everything else to keep executing while you are stepping through a single thread.  So to do that you use gdb.

Alec Phillips said:

Thank you for the link. It seems as though I will need to fully transition to Linux for the development environment, rather than bounce around between Windows and Linux laptops.

If you're doing full time development on this project I recommend it.  Make sure your host PC is configured with 64-bit Linux as we use 64-bit toolchains.  Ubuntu 18.04 64-bit would be a good choice (or even 16.04).

Alec Phillips said:

I meant developing programs like adding my own C code to a source file or header. I am guessing this is not possible within the u-boot/root environment, but am looking for a confirmation if this is accurate. 

I'm sorry, but I am not following.  I think I'm even more confused now that you've mentioned u-boot as well.  I assumed you were talking about embedded Linux applications that run on the AM572x.

Alec Phillips said:

Booting from the SD card is called "U-boot", right? Maybe I'm causing the confusion due to inaccuracies in my knowledge of each term...

No, u-boot is the name of the open source bootloader that is used to boot the kernel.  In fact, when you build u-boot, you end up with two different versions of it:

1. u-boot-spl (SPL = Secondary Program Loader).  This is a trimmed down version of u-boot that can fit into internal RAM.  Its sole purpose is configuring the DPLL's and DDR and then loading u-boot.  In the file system, the "MLO" program is u-boot-spl.  It is renamed to "MLO" because that is the file name the boot ROM looks for.  You can boot from eMMC, SD card, etc.
2. u-boot.  This is the "full" u-boot.  Its main purpose is loading the Linux kernel.

Alec Phillips said:

In CCS, I am able to change code, build, and test in the IDE. Can I modify/add the source files or headers within the "root" dev environment, or is this the added benefit of using CCS in the first place?

What you're describing is certainly the norm in the RTOS world, though not nearly as common or easy in the Linux environment.  Most projects tend to be makefile based.  You can setup a "makefile project" in CCS where clicking the build button equates to running "make" from the command line.  You still need some way of being able to "push" your updated code to the target (could be scp command or RSE which was discussed on the wiki) and you need to be able to launch gdbserver on the target.

I'm not an expert in using gdb for debugging applications.  I spend a lot more side doing kernel debug than application debug.  If you have specific issues or questions in getting that operational then I recommend starting a new thread.

Best regards,
Brad