Interested in BeagleBoard GSoC 2016 project

Hi, All

I am writing to express my interest in becoming a stipendist in the next edition of Google Summer of Code in 2016. Currently I am in my second year of engineering studies at Gdańsk University of Technology in Poland.
I have been looking through the project ideas for GSoC-2015 and I am particularly interested in enhancing ADC driver for BeagleBone Black. I have experience in working with platforms such as Intel Galileo, Atmel AVR, FPGA (Altera, DE0-NANO-SOC with ARM9). I am also familiar with programming languages such as C, ASM, PYTHON, and hardware description language like VERIOG and VHDL. I can use Git repository and perform cross-compilation.
Lately I have been devoting a lot of time to FPGA, combining its advantages with those of ARM9 cores. If there was a project involving the use of FPGA I would be eager to do it.
I would like to ask if there is something I could do before the project’s start in order to prove my abilities.

I look forward to your response.
Best regards,
Patryk Mężydło

I spent the last two months familiarizing myself with BeagleBone.

During this time I was able to do the following:

  • compile the kernel, bootloader and device tree

  • submit compiled parts

  • eMMC and SD flash

  • write simple LKMs (kernel threads, interrupts, linux headers)

  • write assembler code for PRU and write DTS for GPIO

I spent a few days dealing with PRU processors, and I particularly liked the idea of using them. I feel comfortable writing on them, and for this reason I would like to engage in a project based on PRU. For the time being I decided to take up the project “Using BeagleBone PRUs to control CNC and 3D printer stepper motor Drivers”. I wrote a simple stepper motor driver based on PRU. You can find the code here: https://github.com/pmezydlo/BBB_PRUSSv2_SM

I own a digital oscilloscope, which is useful during tests and debugging.

I can create diagrams in Eagle.

Best regards,
Patryk Mężydło

Hello Jason,

I sent you the test application you requested me to do on Github.
Will there be any project involving PRU and a mentor?

Best regards
Patryk Mężydło

Can’t make promises like that. Do you have a specific idea? I think you could engage folks on #beagle and here and get your idea added to the ideas page.

I wanted to do a project with GSoC 2015. It is Using BeagleBone PRUs to control CNC and 3D printer stepper motor Drivers.
Maybe one of the proposed mentors would like to get involved?

I really like the new project ideas for prus. I would like to make open-source memory flasher. I think that will be easy to develop it, add new types of memory and new features. I would like to start thinking on this project.

Congratulations BeagleBoard for participation in the next edition of GSOC. I am interested in the project SPI Flash Emulator. I would like to discuss the project and ask for further details.

I think the use of PRU as a driver SPI is a good option, therefore I would like to adjust the controller to both PRUs - user would decide which coprocessor he wants to use.

Memory parameters such as: SPI speed, memory organization, GPIO define and number of PRU would be saved in the configuration file that is loaded during the upload.

Device functions: reading from memory, memory programming, memory erasing and verification.

Types of memory: NOR Flash, EEPROM(optional), SRAM(optional) and Data Flash(optional).

Types of batch files (the memory contents): raw binary and intel hex (optional).

Counting checksum (crc32) on the PRU is to occur during the programming and reading.

Host application on the PC is supposed to use the Qt framework.

Communication between pc and beaglebone would be via by ssh and scp.

The project is quite extensive and it requires determining the real boundaries. Taking into account the further development of the project. I see two possibilities.

First, focus on support for multiple types of memory (SRAM, EEPROM, data flash, nor flash) and extensive functionality (crc, erase, read, program verification, intel hex and raw binary). The other possibility is to write applications for Windows/Linux and communication through ssh and scp, as well as programming only particular types of memory (nor flash) and limited functionality (programming, raw binary).

I am looking forward to your suggestions and propositions.

Best regards

Patryk Mężydło

Hi Patryk,

Congratulations BeagleBoard for participation in the next edition of GSOC.
I am interested in the project SPI Flash Emulator. I would like to discuss
the project and ask for further details.

I think the use of PRU as a driver SPI is a good option, therefore I would
like to adjust the controller to both PRUs - user would decide which
coprocessor he wants to use.

Memory parameters such as: SPI speed, memory organization, GPIO define and
number of PRU would be saved in the configuration file that is loaded
during the upload.

Device functions: reading from memory, memory programming, memory erasing
and verification.

Types of memory: NOR Flash, EEPROM(optional), SRAM(optional) and Data
Flash(optional).

Types of batch files (the memory contents): raw binary and intel hex
(optional).

Counting checksum (crc32) on the PRU is to occur during the programming and
reading.

Host application on the PC is supposed to use the Qt framework.

Communication between pc and beaglebone would be via by ssh and scp.

The project is quite extensive and it requires determining the real
boundaries. Taking into account the further development of the project. I
see two possibilities.

First, focus on support for multiple types of memory (SRAM, EEPROM, data
flash, nor flash) and extensive functionality (crc, erase, read, program
verification, intel hex and raw binary). The other possibility is to write
applications for Windows/Linux and communication through ssh and scp, as
well as programming only particular types of memory (nor flash) and limited
functionality (programming, raw binary).

You seem very excited, which is a very good thing, but what you outline
here in terms of memory types and functionality may already exist in
common tools and/or may be a much more ambitious project than time will
allow for in GSoC.

Can you make a list of 10 weeks worth of work and a breakdown of how
long each task will take to accomplish some meaningful progress towards
a goal of creating a tool that does not yet exist and leverages a
BeagleBoard.org hardware component?

I am looking forward to your suggestions and propositions.

Have you looked at the existing solutions for programming of SPI flash
devices from Linux such as https://flashrom.org/Flashrom and tools like
the Dediprog SF100 http://www.dediprog.com/pd/spi-flash-solution/sf100
and Tin Can Tools SPI Hook http://www.tincantools.com/SPI_Hook.html ?

Please study these existing SPI flash programmers and how they interface
via USB to a Linux host as they are already decently supported tools
that people use for SPI flash programming in development, such as for
loading u-boot onto a target which boots from SPI flash.

Regarding the SPI flash emulator idea on the Ideas page, effectively I'd
like to produce the capability to do what the Dediprog EM100Pro device
does, to emulate a SPI flash, but use a BeagleBone (and potentially a
custom cape to provide for the physical interface to handle level
shifting) which is much less expensive. The EM100Pro is upwards of $800
USD. http://www.dediprog.com/pd/spi-flash-solution/em100pro

If you would like to use the PRU(s) to handle this interface, please look
at the AM335x TRM and explain to me how the MISO and MOSI lines could be
implemented in the PRU(s) given that the BeagleBone won't know what the
SPI clock rate is ahead of time. I do not know if using the PRUs is the
best choice for this project or not, as the McSPI interface as a SPI
slave may be more suited to the task at hand.

Thanks,
Andrew

Thanks for your reply

Sorry for misunderstanding the information on the website. The project got slightly shorter, but it has become more difficult.

Actually, on second thought I decided that PRU coprocessor is not the best solution. Looking at the nor flash random memory

documentation, I found out that the spi clock’s speed reaches 70Mhz during the reading, while for PRU it is maximally 20 Mhz.

That is why McSPI should be used. However, after briefly studying the subject I noticed that there is little information I could use. The documentation is rather extensive, so it is what I will focus on.

I think that it would be best to write a driver which would allocate the necessary amount of memory, giving easy access from the user level. After installing the driver, it would configurate McSPI to work in slave mode. The driver would cyclically react to received addresses and commands, saving or sending back the data.

What is the name of nor flash memory which is supposed to be emulated by beagle? I would like to familiarize myself with its documentation.

Thanks to the use of interruptions, the response time would be much shortened, making the stream of date easier to control; so my question is, would it be possible to use it?

I have familiarized myself with writing drivers. Do you think it is a good idea to use them?

I would like to create PCB.

Could you explain to me what is exactly “level shifting”?

Best regards

Patryk Mężydło

Hi Patryk,

Thanks for your reply

Sorry for misunderstanding the information on the website. The project got
slightly shorter, but it has become more difficult.

Actually, on second thought I decided that PRU coprocessor is not the best
solution. Looking at the nor flash random memory
documentation, I found out that the spi clock’s speed reaches 70Mhz during
the reading, while for PRU it is maximally 20 Mhz.

That is why McSPI should be used. However, after briefly studying the
subject I noticed that there is little information I could use. The
documentation is rather extensive, so it is what I will focus on.

The McSPI maximum clock rate is 48 MHz, if I recall correctly, which
will not allow a true SPI NOR flash part's high speed abilities to be
emulated, but many existing SPI flash emulators also have limitations on
the clock speed. Limiting to 48 or 24 MHz operation is perfectly OK.

Usually when people use emulators, be it for SPI devices or otherwise,
it is understood that the emulator provides functionality which is
desired but may impose other limitations which can easily be delt with.
Using a SPI flash emulator can reduce the amount of time it takes to
load data onto a board for testing by 10 to 100x, so being forced to
only run the SPI bus at a relatively low clock rate is often perfectly
OK to do as the benefits greatly outweigh the downsides.

I think that it would be best to write a driver which would allocate the
necessary amount of memory, giving easy access from the user level. After
installing the driver, it would configurate McSPI to work in slave mode.
The driver would cyclically react to received addresses and commands,
saving or sending back the data.

Please do a survey of the existing proposed SPI slave drivers which have
previously been publicly sent to various Linux kernel mailing lists. To
my knowledge, none have been accepted and one of the sticking points is
that a good API for general purpose SPI slave operations needs to be in
place which can be used for more than one specific purpose.

Using a generic SPI slave driver interface, or modifying an existing
proposal, is likely going to have the best chance of being able to be
upstreamed to Linux down the road.

What is the name of nor flash memory which is supposed to be emulated by
beagle? I would like to familiarize myself with its documentation.

For example, a SPI flash which might want to be emulated would be the
Micron N25Q064A series of parts [1]. Obviously the dual and quad I/O
operations wouldn't need to be supported, since McSPI does not support
these, and the maximum frequency to be emulated could be 48 or 24 MHz.

[1]: https://www.micron.com/products/datasheets/7b8b89ea-d081-4f49-8e6f-43cc4c911d3f

Thanks to the use of interruptions, the response time would be much
shortened, making the stream of date easier to control; so my question is,
would it be possible to use it?

Yes, I expect that interrupts would need to be used, along with DMA.
Instructions like the 03h READ instruction provide no time between the
end of the SPI address data and the first bit of the read data that the
flash has to return, so there will likely need to be some considerable
effort put into ensuring that deadlines like this can be met at the
supported SPI clock frequencies.

I have familiarized myself with writing drivers. Do you think it is a good
idea to use them?

Yes, writing a driver is likely to be the only way to implement the SPI
flash emulation, as far as I can see. Leveraging a more generic SPI
slave driver API (as mentioned above) will hopefully help to reduce the
amount of code needed.

I would like to create PCB.

Ideally we should keep this GSoC project as a software-only exercise.
If you'd like to create a PCB to enhance the software capabilities
developed during GSoC, that'd be awesome! But the focus of GSoC should
stay on software, please.

Could you explain to me what is exactly “level shifting”?

Since the BeagleBone exposes most of the SPI and GPIO pins on the P8 and
P9 headers as 3.3 V I/O, any device which interfaces to the BeagleBone is
expected to also use 3.3 V I/O. Most SPI NOR flash have a voltage range
that they support for I/O, such as from 2.7 V to 3.6 V or from 1.7 V to
2.0 V. In order to ensure that a SPI flash emulator could hook up to a
system which doesn't use exactly 3.3 V I/O, some kind of level shifting
needs to be put into place to shift the voltage level of the BeagleBone
to match that of the SPI master.

Parts like TI's SN74LVC1T45 [2] would be a decent choice for a level
shifter for SPI bus uses.

[2]: http://www.ti.com/product/SN74LVC1T45

Thanks! :slight_smile:
-Andrew

Hi Andrew

Thanks for your reply

By „tables” I meant memory allocation,

but I already worked it out by myself anyway.

I am familiarising myself with kobjects, I’m doing quite well.

After installing LKM it allocates char array, therefore I have

an easy access to it from the user level.

I already found a few codes of McSPI

drivers – their analysis will give me some idea

about how they work and a starting point from where

I should start the project.

I would like to start writing my application, so

could you tell me something more about what

should it contain?

I look forward to your response.

Best regards,
Patryk Mężydło

Hi Patryk,

Hi Andrew

Thanks for your reply

By „tables” I meant memory allocation,

but I already worked it out by myself anyway.

I am familiarising myself with kobjects, I’m doing quite well.

After installing LKM it allocates char array, therefore I have

an easy access to it from the user level.

I already found a few codes of McSPI

drivers – their analysis will give me some idea

about how they work and a starting point from where

I should start the project.

Can you provide links to the information you've found useful regarding
writing SPI slave drivers?
I just want to make sure I'm able to follow along with the research you
are doing.

I would like to start writing my application, so

could you tell me something more about what

should it contain?

I believe there will be an official GSoC application for students to
complete in order to be considered for GSoC starting on 14 March. Until
then, we can continue to discuss your research and other activities via
this list (beagle-gsoc).

Thanks,
Andrew

Hi Andrew

Thanks for your reply
I hope you don’t mind that I’m not very active on irc,
I just prefer to use email.

Concept of McSPI in slave mode is rather new regarding
implementation in the driver.
While i was looking through the mailing list, I often encountered
information about lack of implementation in slave mode.

Here you can find the code:
https://github.com/beagleboard/linux/blob/4.1/drivers/spi/spi-omap2-mcspi.c

it is important how big portions of data beaglebone is to
send and receive to emulator.

the most important is detection of the first 4 bytes
of data - they will provide us with the address and command.

If the driver receives write command, it must allocate data
from McSPI buffer and it must increment address.

Unfortunately, I don’t know how large data portions
(during one transmission) the emulator will exchange
with beaglebone,
therefore it is easier to assume that we will allocate
data after each byte.

If the driver receives read command it must calculate
address and send data from memory to McSPI buffer
and it must increment address.

I dealt with handling interrupts in drivers and i think
i will have to change the handler.

I want to use innterrputs: send_byte, receive_byte if
such events have their handlers.

DMA transfers 32 bytes in a single transfer, and
sends the entire contents of the buffer.
I think that the DMA is hard to use in our project,
however I know it optimizes,

I look forward to your response.
Best regards,
Patryk Mężydło

The cape project (schematic and board) is not taken into consideration in GSOC, I’m doing it in my free time. Would you like to take a look on the scheme before routing?

(Attachment BBB_Emulator_sch.png is missing)

sorry png with 1000 dpi is not available

BBB_Emulator_sch.png

Hi Patryk,

Are you still awaiting feedback on this schematic diagram? I know you
obtained some responses via IRC.

Thanks,
Andrew

hi Andrew

I have some important questions beacuse submission of applications begins on monday.

1.What do you mean by “USB gadget capabilities to load the data from a PC host”?
Do you want the driver to appear in Linux system as emulator-gadget by USB?
I did communication via ssh, scp and i’m writing drivers - i’m doing pretty
well but I do not know how to operate the device for USB.

2.I dealt with handling interrupts in drivers and i think
i will have to change the handler.
I want to use innterrputs: send_byte, receive_byte
if such events have their handlers.

3.I checked in one of the flash programmer which types of files
to upload and i think it will be Intel Hex and Raw Binary. What do you think?

4.in my free time i’m writing LKM; allocating memory, free access,
loading data and showing data is not a problem, the only difficult part is DMA, McSPI.

5.I have an idea which I’ll show you in a few steps:

  1. install LKM and definition in parameters memory size
  2. in /sys/kernel appears file e.g. memory (kobjects)
  3. (optional by users) program in c/python programs memory by entering into this file
  4. during initialization set McSPI in slave mode and set interrupt (optional DMA)
  5. wait for interrupt and upload to one byte
  6. latch the address, command and data
  7. response to the command, set the address and send or write byte or bytes
    (I think the McBSP is addressed, and we will be able to refer to this)

6.PCB design is ready, We discussed layout, scheme and routing with Michael Welling on IRC.

7.DMA transfers 32 bytes in a single transfer, and sends the entire contents of the buffer.
I think that the DMA is hard to use in our project, however I know it optimizes.
Do you think this is necessary?

8.I created a simple debugging tool in python which reads the kernel logs with specific structure,
I have not seen any good tools, do you know any?

I look forward to your response.
Best regards,
Patryk Mężydło

Hi Patryk,

hi Andrew

I have some important questions beacuse submission of applications begins
on monday.

1.What do you mean by "USB gadget capabilities to load the data from a PC
host"?
Do you want the driver to appear in Linux system as emulator-gadget by
USB?
I did communication via ssh, scp and i'm writing drivers - i'm doing
pretty
well but I do not know how to operate the device for USB.

My thought is that the BeagleBone when operating as a SPI flash emulator
will show up as a USB device to a host PC. Then data can be sent to the
BeagleBone using normal host PC libraries such as libusb. Many USB
based SPI flash programmers already use libusb in flashrom in order to
program SPI flash devices (see Dediprog SF100 and Tin Can Tools SPI Hook
programmers) so my naive expectation is that continuing to use flashrom
will not be a poor choice for the emulator. I have not done much
research to really understand what alternatives exist.

Implementation of the BeagleBone's USB device capabilities would use
something like functionfs [1] or gadgetfs [2] and/or the gadget configfs
interface [3].

[1]: https://www.kernel.org/doc/Documentation/usb/functionfs.txt
[2]: http://www.linux-usb.org/gadget/
[3]: https://www.kernel.org/doc/Documentation/usb/gadget_configfs.txt

2.I dealt with handling interrupts in drivers and i think
i will have to change the handler.
I want to use innterrputs: send_byte, receive_byte
if such events have their handlers.

3.I checked in one of the flash programmer which types of files
to upload and i think it will be Intel Hex and Raw Binary. What do you
think?

Generally, it is my understanding that binary files are the most likely
format to be programmed to a given flash part. Possibly there are uses
where hex files are desired. I would advise to start with raw binary
files first.

4.in my free time i'm writing LKM; allocating memory, free access,
loading data and showing data is not a problem, the only difficult part
is
DMA, McSPI.

5.I have an idea which I'll show you in a few steps:
1. install LKM and definition in parameters memory size
2. in /sys/kernel appears file e.g. memory (kobjects)
3. (optional by users) program in c/python programs memory by entering
into
this file
4. during initialization set McSPI in slave mode and set interrupt
(optional DMA)
5. wait for interrupt and upload to one byte
6. latch the address, command and data
7. response to the command, set the address and send or write byte or
bytes
  (I think the McBSP is addressed, and we will be able to refer to this)
6.PCB design is ready, We discussed layout, scheme and routing with
Michael
Welling on IRC.

7.DMA transfers 32 bytes in a single transfer, and sends the entire
contents of the buffer.
I think that the DMA is hard to use in our project, however I know it
optimizes.
Do you think this is necessary?

I don't know if DMA will be needed or not to implement the core concept.
I expect that DMA will greatly help in reducing CPU load when doing
large reads or writes but I have not put enough time into understanding
what the limitations would be without DMA.

8.I created a simple debugging tool in python which reads the kernel logs
with specific structure,
I have not seen any good tools, do you know any?

I'm sorry, I'm not sure I understand your question. Are you trying to
parse dmesg output or something else?

Thanks,
Andrew

Hi Andrew

I just finished writing application, Could you assess what I have to improve?

thanks

Patryk

GsoC 2016 Application.pdf (761 KB)

I added according to requests mentors in the form of a document google

Link is here:
https://docs.google.com/document/d/1Bp0QN7v_AXWWhBNbX2SzdPrpaVmat1RzTWUT2aVSltA/edit