A.J.'s Notes

General Notes

##TODO: ###Delphino:

• Start up a basic project that has debugging from USB UART and can DMA data to the UART

Work Log

Day	Description
1-6-15	Setup Workstations
1-7-15	Beaglebone kernel
1-8-15	Delphino UART/DMA
1-9-15	Xenomai on the Beaglebone
1-11-15	Beaglebone Kernel
1-12-15	Beaglebone Xenomai
1-13-15	Delphino Bootloader
1-14-15	Delphino Bootloader
1-15-15	Delphino Memory Layout
1-16-15	Delphino Base Project
1-20-15	Delphino Base Project
1-22-15	Delphino Base Project

##1-22-15 ###Delphino Base Project Now that we have a small base project which can run from RAM or FLASH that can debug over the USBUART now the next feature that is needed is DMA transfers to the UART. Today I got the interrupts for the UART added to the base project. Now I need to add a DMA to directly transfer instead of doing it inside interrupts.

##1-20-15 ###Delphino Base Project Got the base project fully working, fixing issues with pin multiplexing on the LEDs. First commit of the base project to the GitHub.

##1-16-15 ###Delphino Base Project Set up the base for the initial Delphino project using the knowledge gained in the past week. Will be able to debug from USB UART and to DMA over data via UART.

##1-15-15 ###Bootloader Goals The attempt of the bootloader is to load up a .out file from the microSD for a project for both CPU1 and CPU2 and launch them as if they were being launched from RAM via the debugger. This will make it so that we do not need to worry about our code working differently when we run it away from the debugger. Instead of developing a bootloader and using a microSD it should be possible to develop a program for FLASH. That program can copy vital functions to ram. We can still upgrade the device via a small program that loads up into RAM and reprograms the flash. Additionally if we run from RAM there is the problem that there is much less RAM than there is FLASH. 10k of usable RAM for a program vs ~50k of usable flash (or more). Due to this reason I've concluded we're just going to use FLASH.

###Delphino Memory Layout Relinking this valuable page Our bootloader will need at least some memory to run. It is a good idea to make it share stack/bss space with the loaded program. (Info leak, security issue but probably not a big deal).

For RAM This appears to be the location of the more important segments:

Segment	CPU1 (RAM)	CPU2 (RAM)	CPU1 (FLASH)	CPU2 (FLASH)
.text	M0 D0 LS0-4	D0 LS0-4	B-E	B
.stack	M1	M1	M1	M1
.ebss	LS5	LS5	LS5 GS0 GS1	LS5
.econst	LS5	LS5	F G H	B
.esysmem	LS5	LS5	LS5	LS5

The important difference is that CPU2 isn't using M0 for the .text. No idea why this actually is. It's probably safe to just do everything the CPU2 way and we will only use M0 if we need the extra space.

The general plan for now is to use D0 and LS0-4 for our .text. The stack will be in M1. The bss/const/sysmem will all be in LS5.

As for the flash program the biggest issue appears to be the fact that CPU1 uses more banks than CPU2. All that means is we will need to possibly allocate more banks if we run out of space. For the flash program we can plan to do it as CPU1 does.

###Reading in the file While reversing the binary format so we can actually load it is still on my todo list here are some remarks on actually getting the file in.

As mentioned earlier the microSD will need to be 2GB or less since I don't want to program in SDHC support. It's not worth the time just for more space than we need. It is probably a good idea to separate everything into different files and read them as needed. The goal for now is to just copy the .out files from CodeComposer on to the root of the microSD. One project per core, for now to be simple we'll just do everything as is in that project. If we end up caring more about performance we can move on to building a basic OS with multi threading.

Questions that need to be answered:

• Can we access the debug USB from CPU2?
• Can we access the microSD from CPU2?
• If we can is the a problem reading from it from both CPUs at once? (probably)

Likely the plan will be to load up the binary file for CPU2 from CPU1. CPU1 will talk to CPU2 though IPC and send the actual binary file by using shared ram.

###Making a Delphino Project Everything in the samples is directory dependent making it really difficult to switch to a more

##1-14-15 ###Delphino Bootloader A:SW1 can be used to turn off UART. Look at it if UART breaks. The provided microSD code does not support SDXC. Should investigate if it supports SDHC or not. If it doesn't we'll have to use a microSD that's 2GB or less. Noticing that random characters are being dropped. I should be aware of this in the future. I plan on reversing the format more on Friday over the weekend so I'm going to start building the basic structure for the bootloader now.

##1-13-15 ###Delphino Bootloader I tested a few simple projects from both flash and ram. Because of how slow it takes to program to flash (>3 minutes for a 500kb file) and the fact that we only have about 4MB max of usable space on flash I decided a microSD card is the way to go.

I tested the built in microsd code and it worked without any issues at all.

##1-12-15 ###Beaglebone Xenomai I attempted to install a pre built Xenomai package from rcn-ee.net's package system, both v3.8.13-xenomai-r69 and v3.14.26-ti-xenomai-r44. Unfortunately the Beaglbone would no longer boot when using those kernels. I finally gave up on Xenomai for now, I'll probably want to look more at this page and installing from source more cleanly than the hacks provided in the wiki.

Giving up on Xenomai I switched to the linux-rt image that at least mostly worked. Before when I got it I was doing apt-get update by doing apt-get dist-upgrade I was able to actually fix the USB to some degree. It shows up as a serial device though the /boot isn't mounted, usb ethernet doesn't work, and when connecting to the serial port we don't get a login terminal. These are all likely software issues and can be fixed.

###Delphino Bootloader Design While all this was going on I worked with the Delphino chip more. I began looking into designing the bootloader. I need to decide between using the on board flash and a microsd card. Page 62 of this provides valuable information needed for designing the bootloader.

##1-11-15 ##More Beaglebone Kernel Unbricked the Beaglebone and ended up re bricking it multiple times while attempting to install Xenomai from source. I downloaded a pre built image which had linux-rt as the kernel. While it worked it broke the usb capabilities meaning the only way to communicate with the device was via SSH. Since this works I'll likely use this if Xenomai ends up not working out.

##1-9-15 ###Xenomai on the Beaglebone Installation attempted again and failed. The problem appears to be that the build scripts are broken and generate files instead of directories. One of the problems being in /lib/modules/3.8.13-bone69 with the folders kernel build and source

Also of an annoyance the build script deleted most of the filesystem.

##1-8-15 ###Delphino UART/DMA I got the sample code for UART and DMA to work and tested doing both in a dual core setting. It's worth noting that the sample code for the UART does not entirely work as stated "Characters typed in one terminal should be echoed in the other and vice versa.". As it originally was only the data from the micro-USB (/dev/ttyACM0) to the mini-USB (/dev/ttyUSB0) was mirrored.

For DMA everything worked great after the pins were discovered, have a look at TMDSCNCD28377D_180cCARD_pinout_R1_1.pdf in F28377D Pinouts-Schematics.tar.gz for what pins are what.

##1-7-15 ###Beaglebone Kernel The current kernel on the Beaglebone, standard Linux, has latency issues and will not respond to interrupts fast enough. Two kernels were investigated linux-rt and Xenomai. Based on this article Xenomai meets our situation better. It additionally is easier to install since there are instructions for installation also see this link. Note: I did not finish compiling the kernel and will have to resume this work later on.

##1-6-15 ###Setup Workstations Installed Ubuntu, core development packages, and Code Composer. libudev0 doesn't exist in current repositories used a symlink from version 1: ln -sf /lib/i386-linux-gnu/libudev.so.1 /lib/i386-linux-gnu/libudev.so.0