Interested in BeagleBoard GSoC 2016 project

[Patryk Mężydlo]

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

[Patryk Mężydlo]

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

[Patryk Mężydlo]

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

--
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard GSoC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard-gsoc/kmw_pXEeaEY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard-gs...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jason Kridner]

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.

You received this message because you are subscribed to the Google Groups "BeagleBoard GSoC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard-gs...@googlegroups.com.

[Patryk Mężydlo]

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?

[Patryk Mężydlo]

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.

[Patryk Mężydlo]

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

[Andrew Bradford]

Hi Patryk,

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

[Patryk Mężydlo]

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

[Andrew Bradford]

Hi Patryk,

On 03/03 01:21, Patryk Mężydlo wrote:
> 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! :)
-Andrew

[Patryk Mężydlo]

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?

[Andrew Bradford]

Hi Patryk,

On Fri, Mar 4, 2016, at 06:13 PM, Patryk Mężydlo wrote:
>
>
> 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

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

[Patryk Mężydlo]

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

[Patryk Mężydlo]

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?

​

​

[Patryk Mężydlo]

sorry png with 1000 dpi is not available

​

 BBB_Emulator_sch.png

​

[Andrew Bradford]

Hi Patryk,

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

Thanks,
Andrew

On 03/07 23:18, Patryk Mężydlo wrote:
> sorry png with 1000 dpi is not available
>
> ​

> BBB_Emulator_sch.png
> <https://drive.google.com/file/d/0B1Sxahs4DCgrb0prWnpkSUswaEE/view?usp=drive_web>

[Patryk Mężydlo]

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

[Andrew Bradford]

Hi Patryk,

On Wed, Mar 9, 2016, at 07:39 PM, Patryk Mężydlo wrote:
> 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.

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?

[Patryk Mężydlo]

Hi Andrew

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

thanks

Patryk

[Patryk Mężydlo]

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

[Andrew Bradford]

Hi Patryk,

On 03/15 02:12, Patryk Mężydlo wrote:
> 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

Thanks for making a google doc! :)

I think it would be helpful to include in your project the creation of a
generic SPI slave framework within Linux and then to make the emulation
of a SPI flash as the first protocol driver consumer of that framework
and McSPI on AM335x the first hardware layer for that framework. In the
same way that SPI master operations happen in Linux, there is a top
protocol driver which userspace can interface to, the generic SPI master
APIs which are used by protocol drivers, and then the low level McSPI
interface to the actual hardware. I would expect that a generic SPI
slave framework should likely follow a similar architecture so as to be
reusable and have the best chance of being upstreamed into Linux.

Ideally, you could also outline how userspace Linux, within the BBB,
will interface to your slave flash protocol driver. Such as:
* How will userspace tell the driver the size of the flash?
* How will userspace load data into the driver?
* How will userspace know that it should not change the data in the
driver due to the emulator currently seeing the target is interacting
with the emulated flash?

There should be existing SPI slave code/patches which you can find via
searching the Internet. If you could find a few of these proposals for
SPI slave frameworks/drivers which have previously been attempted by
others and include an evaluation of why they were unsuccessful and how
your plan will address their shortcomings, that will be very helpful in
terms of having this project appear to have mainline Linux
applicability.

Also, I think you can focus less on the libusb parts and host PC
control. Maybe we can make the host PC app and libusb portions of the
project more like "reach goals." After looking over your proposed
schedule, simply being able to emulate a SPI flash and creating the
Linux SPI slave framework (mentioned above), I think also trying to make
a host PC interface using libusb may be a bit optimistic. If you feel
otherwise, let's talk about it more. I just don't want to have you take
on too much work for the short duration of GSoC as if you are unable to
complete a majority of the work you define, that often doesn't look very
good during reviews.

In your document, can you also explain that the SPI slave functionality
in AM335x will not be able to run at the same speed as a real flash
would? What other shortcomings do you expect the emulator to have?
(Shortcomings are expected, it's an emulator.)
Clearly explaining what the shortcomings of your proposal are will help
others to evaluate it better, I think.

Thanks!
-Andrew

[Andrew Bradford]

Hi Patryk,

I just wanted to clarify some of my wording below: I do not want to
mislead you into thinking that your project is being accepted or not
accepted even though some of my wording uses the present and future
tense and that I used the word "we" when talking about your proposal.

Currently, students are to submit proposals for GSoC, no decisions have
been made by Google yet regarding who will or won't be accepted as GSoC
students.

Sorry if I've caused any confusion.
-Andrew

[Patryk Mężydlo]

Hi, Andrew

What do you mean by API? Parameters, files that appear in linux and allow you to communicate applications with the driver?

I have a new short plan:

1. My task is to write the driver McSPI slave.

2. API (Implemented functions in the driver for communicating with applications)

3. Documentation, tutorials, examples showing how to implement

4. Flash emulator application using my api

5. Implementation of USB if I will have enough time.

I think this project is really interesting, I like it very much but I have doubts if I will manage to do it.

I have not spent lot of time with this McSPI master code.

I feel much more comfortable with the PRU Framebuffer project, since I already worked with such LCDs on FPGAs, they have 26 pins.

Have you thought about how to solve this problem? In my opinion, for example, you can take only the most significant bits such as RGB323, in that case 

you need only 11 gpios.

I feel much more comfortable writing in PRU.

I'm sorry, I just got a bit confused.

I do know that for a beagleboard community project McSPI driver is more important.

Could you find a while for conversation on IRC, how about tomorrow at 16-20 (your time zone)

Please find attached a picture of my FPGA with its LCD. 

Thanks 

Patryk

[Andrew Bradford]

Hi Patryk,

On 03/16 02:35, Patryk Mężydlo wrote:
> Hi, Andrew
>
> What do you mean by API? Parameters, files that appear in linux and allow
> you to communicate applications with the driver?

By API I mean that if you look at the interfaces exposed for SPI master
protocol drivers to use [1] in order to talk to a device on the SPI bus,
there is a common set of function calls which a protocol driver can use
no matter if the underlying SPI hardware is from TI, Freescale, Intel,
or any other manufacturer. The higher level SPI master interface is
always the same for a protocol driver to use. This is due to, what is
in my understanding, a 3 layer stack used for SPI master operations.

[1]: https://www.kernel.org/doc/htmldocs/device-drivers/spi.html

At the bottom level is SoC or processor specific code, such as for McSPI
on TI parts. At the middle level is the interfaces and function calls
shown in [1]. At the top level is a protocol driver, such as the driver
for the Microchip ENC28J60 Ethernet controller [2] which is a SPI
protocol driver [3].

[2]: https://www.microchip.com/wwwproducts/en/en022889
[3]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/microchip/enc28j60.c

In the same way, it is my opinion that a generic SPI slave
subsystem/framework in Linux should have 3 layers, too. In this way,
there can be low level hardware interfaces to SPI hardware like McSPI in
slave mode, a middle layer of common functions to call by protocol
drivers, and then a top protocol driver layer which can be used to
implement, for example, emulation of a SPI flash.

Doing this in a generic way is likely the best way to get such code into
mainline Linux, as from what I've read and observed, any framework which
cannot easily be extended for other hardware and other uses is unlikely
to gain support from Linux maintainers. However, implementing a more
generic architecture will bring downsides, possibly complicating the
design or making the design slightly lower in performance, so the
implementation will need to understand these tradeoffs and document
them.

> I have a new short plan:
> 1. My task is to write the driver McSPI slave.
> 2. API (Implemented functions in the driver for communicating with
> applications)
> 3. Documentation, tutorials, examples showing how to implement
> 4. Flash emulator application using my api
> 5. Implementation of USB if I will have enough time.
>
> I think this project is really interesting, I like it very much but I have
> doubts if I will manage to do it.

What are your doubts?

In order for any project, not only GSoC, to be successful, a proper set
of expectations needs to be in place. Trying to do too much in a given
time frame is a recipe for failure, so setting expectations and the
amount of work which will be able to be accomplished is the first step.
That's why contacting mentors before GSoC (like you are doing, which is
awesome!) is so critical to success for any project, including GSoC.

If you feel that other projects in GSoC would be better suited to your
skills and interests, please do feel free to submit more than one
proposal, Google allows this and Google will ensure that a maximum of
one of your proposals is accepted [4].

[4]: https://developers.google.com/open-source/gsoc/faq#can_i_submit_more_than_one_proposal

> I have not spent lot of time with this McSPI master code.

If you are interested in any GSoC project but you are not yet famliar
with the code, there is still plenty of time before actual GSoC coding
starts to become familiar. There are many resources online which can
stand as examples or tutorials so that you can become more familiar with
the code prior to the GSoC coding starting date. There are also great
examples and reasonably good documentation within Linux source code
itself, too.

> I feel much more comfortable with the PRU Framebuffer project, since I
> already worked with such LCDs on FPGAs, they have 26 pins.
> Have you thought about how to solve this problem? In my opinion, for
> example, you can take only the most significant bits such as RGB323, in
> that case
> you need only 11 gpios.
>
> I feel much more comfortable writing in PRU.

My expectation is that the PRU framebuffer project will need to include
both PRU code and Linux drivers in order to be successful, as just
having one without the other cannot likely be demonstrated very easily.

> I'm sorry, I just got a bit confused.
>
> I do know that for a beagleboard community project McSPI driver is more
> important.

I don't know which is more important. I'm the person who proposed both
the PRU framebuffer project and the SPI slave project. I don't speak
for beagleboard.org, I am just proposing projects which seem interesting
to me and which have overlap with beagleboard.org.

I do not work for TI, beagleboard.org, or any of the Beagle Board
manufacturers, I just enjoy the beagleboard.org community. The
project ideas which I submitted as potential GSoC projects are related
to my own interests while being related to beagleboard.org in some way.

> Could you find a while for conversation on IRC, how about tomorrow at 16-20
> (your time zone)

I'm usually at my computer and on IRC from about 0800 to 1600 in the
Eastern time zone (we just started daylight savings, so are now 4 hours
west of UTC). Email is the best way to discuss longer thoughts, but
please do not hesitate to send me questions on IRC even if I'm not
around, I will see them when I return to my computer and can respond to
you.

> Please find attached a picture of my FPGA with its LCD.

Cool! :)

Thanks!
-Andrew

[Patryk Mężydlo]

Hi Andrew

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

Link is here:

https://docs.google.com/document/d/1QGxnjvGWkyppsN7H8Hrc7XFoltBzVDaxKx9nXnQ1fBY/edit

thanks

[Patryk Mężydlo]

Hi Andrew,

I think I won't write another application. I already have an implementation plan and 

development timeline, however I don't have a good reason why the project is important for the community.

To prepare myself I'm writing a code that transfers the data between the driver and the userspace.

It works very well.

m_w drew my attention to important problem concerning synchronization between the driver and the userspace.

The driver must transfer the information about receiving data as soon as possible.

I was thinking about atomic operations; in kernel they run quite ok, unfortunately, gcc won't compile them.

Do you know how to solve this problem?

Thanks

Patryk

[Andrew Bradford]

Hi Patryk,

On 03/19 23:12, Patryk Mężydlo wrote:
> Hi Andrew,
>
> I think I won't write another application. I already have an implementation
> plan and
> development timeline, however I don't have a good reason why the project is
> important for the community.

Regarding importance to beagleboard community, I can agree that making a
direct argument about SPI slave operations be considered important could
be difficult. But as importance to the greater Linux community, there
have been many past proposals and desires expressed for having a generic
SPI slave capability in Linux. Beaglebone is one of (if not, the) best
platforms to develop this capability on.

The first implementation being a SPI flash emulator is just a suggestion
(although unfortunately I made it the title of the idea). Emulating an
existing SPI slave device is likely to be the easiest to test, as
there's no SPI master code to write, just use existing software that can
do SPI master and then focus the effort on the implementation of the SPI
slave.

> To prepare myself I'm writing a code that transfers the data between the
> driver and the userspace.
> It works very well.
>
> m_w drew my attention to important problem concerning synchronization
> between the driver and the userspace.
> The driver must transfer the information about receiving data as soon as
> possible.
> I was thinking about atomic operations; in kernel they run quite ok,
> unfortunately, gcc won't compile them.
>
> Do you know how to solve this problem?

I don't think syncronizing data between userspace and kernel space is a
requirement of the project. The top level SPI slave protocol driver
could just present itself as a SPI flash to some SPI master, there is
not even a need to load data into the device from userspace from the SPI
slave Linux system.

However, one simple way to load data into the SPI slave from userspace
could just be that userspace writes a bunch of data into the SPI slave
(which presents itself as a block device) and then a sysfs flag has to
be set (or ioctl) which effectively locks userspace out. While
userspace is not locked out, the SPI slave won't operate, it just will
wait for data from userspace. Once userspace is locked out, then the
SPI slave will operate and it can be sure that no one but itself will
change the data.

This is just an idea.

Thanks,
Andrew

> Thanks
> Patryk
>
> On Thu, Mar 17, 2016 at 11:50 PM, Patryk Mężydlo <mezy...@gmail.com>
> wrote:
>
> > Hi Andrew
> >
> > I just finished writing new application, Could you assess what I have to
> > improve?
> >
> > Link is here:
> >
> > https://docs.google.com/document/d/1QGxnjvGWkyppsN7H8Hrc7XFoltBzVDaxKx9nXnQ1fBY/edit
> >
> > thanks
> >