Interested in BeagleBoard GSoC 2016 project

[Andrew_Bradford]

Hi Patryk,

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_Mezydlo]

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,

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]: enc28j60.c « microchip « ethernet « net « drivers - kernel/git/torvalds/linux.git - Linux kernel source tree

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_Mezydlo]

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_Mezydlo]

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,

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