First I will apologize for such a lengthy post, I hope someone reads it anyways
"OMAP-L137 EVM PSP User’s Guide" is not very good. It contains most of the information you need, but is written in an order that isn't unlike doing your taxes. In writing this I found myself laughing at things I did... Some of which were just dumb, some of which were just not clear in retrospect. I would encourage others to do the same and help improve the quality of the next release. I also added at the end, a set of features that I think would really enhance the utility of this kit.
Here is areas where I feel the documentation needs improvement.
2.2 System requirements:
This section is grossly lacking. The first thing which isn't clear here is what you actually need to run the system and why. Specifically:
Setting up the system requires BOTH a Windows and a Linux installation. The wording in the documentation makes it sound like you support both platforms (as in you can develop on either). You should really stress that fact, so bone-heads like myself don't go looking for the windows installer program for the MV tools. Also indicate that the board really is (for the moment at least) something that is tethered to a set of computers and is easiest to bring up that way.
I would list the 2 systems you require along with the software that is required/prefered for each. The linux directions are probably obvious to linux developers and the bootloader ones are probably obvious to an embedded developer, but this product bridges those two worlds so more detail is probably needed.
- Windows
- Hyperterm
- Code Composer Studio 3.3.38
- JTAG emulator
- ...
- Linux
- tftp server (for hosting uImage)
- nfs server (for hosting root directory)
- etc...
2.3-3.x :
i think the document here is completely backwards. Imagine you just got this card.. what is the first thing you want to do? If you are excited like I was, you want to plug it in, turn it on, a run a hello.world on it. The order currently written goes through all the linux steps, and then kernel compilations and finally you talk to the hardware after that... Way too much work without blow bits in the chip. Also there is a difference between steps 1-7 where your feedback is in CCS and steps 9-13 where now the serial port is the main communication to the target eventually moving later on to where the network is the feedback. This wasn't obvious at first and I was trying to figure out where my u-Boot info was. Thing should be grouped accordingly and clear when you are changing from one tool to another. The order (I think ) should be to get the board running linux first, and showing you how to tweak/compile the system second. I guess this would be my mini tutorial if a co-worker asked me how to get the card up.
*** Linux Quickstart Steps ***
- Explain these steps and what each one will do, and why they are in this order.
- Install the Windows Tools
- Connect the card
- Power on the system and demonstrate basic board downloading process/verify functionality
- Load the SPI flash loader using CCS.
- Run the SPI flash loader ( would consider modifying this to repeat the proces to make the spi loading more seamless)
- Install DSP-AIS SPI-UBL an U-Boot.
- power off card, Change the pin settings to load from the spi
- Plug in Serial Cable and power on the board.
- Verify u-boot on serial port. this now is a good place to discuss u-boot, what it does and what settings one should use that will work (panic=2 is especially helpful since the likellyhood of getting every right first is unlikely)
- Install the tftp server and verify booting of the kernel
- Install the NFS server and verify nfs connection
- Install the Linux Target files verify complete boot of the sytem
***** at this point you have a happy user that can develop directly on the target and the next step are optional*****
- Install/configure/test the MV cross compiler/environment (* may not be initially needed)
- Install/configure/test the MV Kernel (* may not be needed by most users)
- how to compile SPI flash loader (really just showing the project file)
- how to compile DSP-AIS
- how to compile SPI-UBL
- how to compile u-Boot
*** Features I wish TI would add (maybe I just haven't found them yet) ***
- U-Boot should have drivers for the MMC/SD cards so you can boot off it directly without a connected host. Conceivably both uImage and the root filesystem could live here, and it wouldn't have to be limited to Linux.
- The linux installers are quite silly.
- They start as executables on a CD that you can't run because the CD is readonly.
- Then all they do is extract 2 files each (1 on which isn't needed) which are still compressed.
- You then have to manually uncompress them anyways.
- Why not just provides the .tar.gz and save you from having to copy the "installer", run it, and them decompress it. maybe I'm missing something.
- A simple sample set of projects using the correct interfaces (DSP/BIO and Linux) showing for example the user toggling a dip switch and the information being read by the DSP, making it's way through the proper locks and being displayed on the arm linux screen, and the arm->DSP->LED to show the other direction.
- Perhaps a more complicated example where the ARM loads the DSP.
A simple port of the tools that allows you to compile DSP code on the Linux/Target host so you don't need 2 boxes (or a vm) to develop for this chip.
Sorry again for the long post. I hope it's helpful to someone.
~JM
