OpenOCD + Actel (Microsemi) CoreMP7
In my engineer degree work I used CoreMP7-enabled ProASIC3 Development Kit (part number M7A3P-DEV-KIT-SCS). In a time it was launched by Actel (acquired by Microsemi) it was one of the first attempts of creating a SoPC with soft ARM core available for wide market without royalties. This particular kit has M7A3P1000 chip with 484 balls, 1M system gates and can drive internal PLL up to 350 MHz, so it’s pretty powerful. There is 1 MB of on-board RAM and 16 MB of Intel FLASH.
ARM7TDMI-S processor itself is available as a compiled and pre-placed component that can be put into user system design in SmartDesign tool (part of Libero environment). Although one cannot simulate core directly due to the lack of HDL source files, there is a BFM script compiler which produces HDL testbenches simulating transfers over AHB system bus. User writes BFM (TCL-like) scripts as if they were processor read and write operations.
The board provides several ways of programming the device. FPGA configuration is loaded with on-board FlashPro3 programmer. The same tool can be used to program and debug software written for ARM processor via SoftConsole IDE (which is modified Eclipse software). Microsemi’s FlashPro3 debugger has serious limitation, however: it can only debug code running in RAM. It can program FLASH memory using additional application (cliarm.exe console) and on this its functionality ends. Producer didn’t left programmer without choice, there is additional JTAG header on board. It is called RV (RealView) header and can be connected with 20-wire (2×10) flat cable to regular JTAG programmer. This was the reason I installed and configured fresh Eclipse with CodeSourcery G++ Lite (now Mentor Graphics) version 2011.03-42 with GCC 4.5.2 and OpenOCD in version 0.4.0 (2010-02-22-19:05). Maybe in some further post I will discuss how to set up this environment, now let’s look how to connect a programmer to the ARM core.
I use device based on FT2232 (-C, -D, -L) chip, it is similar to Amontec JAGkey. This piece of hardware was designed by Freddie Chopin. It is has a standard JTAG dual-row pin header which easily connects with P3 connector on board:
The tricky part is how to connect the header to ARM processor. On the core side there are following connections:
Note, that UJTAG group refers to the ports that have predefined physical design constraints – they are automatically connected in Designer I/O Attribute Editor. They serve as a JTAG connected to FlashPro3.
As you can see ports in RV_ICE_If group are not one-to-one compatible with pins on board. What you have to do is to make a HDL wrapper that will sort these pins and do some other actions to make things work. In this step extremely helpful was sample project distributed with board. Its sources are present on a CD or in ZIP downloaded from Actel’s website, in folder M7A3P_CDImage.zip/Disk1/Sample Design/. To get that idea look at file Hardware/Source/socTop.v. There is also an example on how to connect memories to CoreMemCtrl module.
Finally, I had to write OpenOCD configuration scripts. Traditionally, they are split in two: one referring to CPU-specific settings and second with settings related to board. Unlike in hard processor cores in CoreMP7 you are the one who designs memory map, so most probably both of these files must be altered before use. Be sure to read the comments!
coremp7.cfg
m7a3p_dev_kit_scs.cfg
If you read this you probably already know there’s not much information about designs in Actel/Microsemi devices in the Internet. Producer gives excellent documentation and examples, but that’s all. I am aware that my article hasn’t covered topic even in a small part. This FPGA/ARM7 board is also quite ancient device (odd, isn’t it? 2007 if I recall well…) and I have experience only with this specific one. But it finally worked, so feel free to encourage me to write more:-)
Preserving /home directory on LVM while switching distros
I have been using Slackware since I remember. Well, it wasn’t that long ago but it was one of the first distros I tried to use. It works (like a charm, I can’t deny) on my laptop, PC, VMs and in few other places. Times changed and now I decided to switch to other distro I know and like which is Debian. The question is, how to do this and not to loose any data in /home directory?
On virtual machine with Slackware I have four partitions:
/dev/sda1 – / ext4 (root directory)
/dev/sda2 – swap
/dev/sda3 – LVM PV
/dev/sda4 – LVM PV
As numbers say (and I say), all of them are primary.
Two PVs, sda3 and sda4 are merged into one VG named “user_data” and on this there is one LV named “home” containing /home directory with ext4 filesystem. I know this design is a bit weird but on this machine I used to play with LVM (adding, removing, resizing and more) and this is what has left. What I want to do is to throw away everything except /home directory. The final, satisfactory result will be fresh Debian installation with the same /home content. There is not much to do with partition design in my case, so I won’t be doing strange joining nor splitting.
So this is what to do if you want to save existing LVM partitions while installing Debian.
Start normal installation. Go through first steps, then in “Partition disks” window select manual partitioning method. Installer should properly recognize existence of LVM volumes. There should be two lists of devices on the screen, one starting with “LVM” referring to VG and one entitled “SCSI1” which is hard disk (virtual in my case). In both there are sublists of devices.
Under “SCSI1” there are all physical partitions. Since we do not want to change PVs we are interested only in sda1 (#1) for root and sda2 (#2) for swap. In “Partition settings” displayed after selecting #1 choose filesystem type you want in “Use as”, set mount point to “/” and agree on formatting partition. Be sure that bootable flag is set and that’s it. Swap (#2) configuration is straightforward as installer should detect it automatically.
Under “LVM” there are listed all existing LVs. In our example there is only one and we want it to be /home. What we need to do is to select it and setup as a normal partition. Extremely important is to not format it. Make sure the chosen option says “no, keep existing data”.
After that just select “Finish partitioning and write changes to disk” then confirm formatting of partitions #1 and #2. Continue normal installation and after reboot we have what we wanted: /dev/mapper/user_data-home device mounted to /home directory with all data already there.
Moving existing local GIT repository into a fresh gitolite setup
One of the tools I use is gitolite, a nice solution for hosting GIT repositories with privileges control and many more. Installation is trivial, just follow the tutorial instructions.
Let’s say you already have local repository and start to use gitolite on a remote server. This may happen when changing servers, git hosting provider etc. How to safely transfer your project? Firstly, you have to create new (usually bare) repository. In gitolite you just add to gitolite-admin/conf/gitolite.conf something similar:
repo test_repository RW+ = user
Then go to your local working copy and type:
$ git remote origin
This will show you all remote repositories that you used to connect with. In my case there was only “origin”, and it was the exact one I wanted to replace. With following commands you remove existing repository:
$ git remote rm origin
and add a new one:
$ git remote add origin gitolite@example.com:test_repository.git
What will show more verbose version of “git remote” now?
$ git remote -v origin gitolite@example.com:test_repository.git (fetch) origin gitolite@example.com:test_repository.git (push)
That’s it. Now you can send your data to server:
$ git push origin master
Because it is very first “push” into an empty repo, you must explicitly point which remote and what branch you are sending data to. This will be remembered as default, so you don’t need to type it anymore. The same applies to the first “pull” or “fetch”:
$ git pull origin master