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]: SN74LVC1T45 data sheet, product information and support | TI.com
Thanks! 
-Andrew
BBB_Emulator_sch.png