rtems from TMS570 SDRAM or INTRAM

[Pavel Pisa]

Hello Nikolay,

thanks for the reply

On Sunday 23 of April 2017 01:07:55 Nikolay Komashinskiy wrote:
> > 20.04.2017, 17:42, "Gedare Bloom" <gedare at rtems.org>:
> > On Tue, Mar 21, 2017 at 2:57 PM, Nikolay Komashinskiy
> > <nikolay.komashinskiy at yandex.ru> wrote:
> >
> >  i2c and spi Linux APIs are preferred, see cpukit/dev/*
> >
> >  GPIO + i2c + spi is a realistic scope of work.
> >
> >  I think that way too. For testing I can use a beaglebone.
> >
> > Can you explain what you mean by using a beaglebone for testing?
> > What//how would you test?
>
> I am going to use a beaglebone for functional testing, I mean I want to
> establish connections with a beaglebone board and transfer data from/to it.
> Honestly, I haven't looked at how peripheral is tested in rtems yet.

Do you want to use BeagleBone as the SPI and I2C slave/peripheral?
Using full features system as the peripheral has significant
andvantage for debuggin and hardware in the loop testing.
But problem is that SPI slave functionality is not present
in the current mainline Linux SPI drivers at all

  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/Kconfig#n4

There are some proposals and enhancements in this direction

  http://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg07317.html

  http://elinux.org/Tests:MSIOF-SPI-Slave

But I do not suggest to start attempt to work on this support
with Linux for now because it porting that to BeagleBone
and pushing it with all requirements and generality to the mainline
would be equivalent to theamount of work required for RTEMS.

Preparing simple slave test on bare metal or RTEMS running
on BeagleBone could be fine.

I2C slave support and EEPROM device emulation is imlemented
in the Linux mainline

  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/Kconfig#n113

but I am not sure if BegleBone driver has functionality enabled/programmed.

I would suggest to start with a simple I2C EEPROM chip programmed
by some data (or connect SDA, SCL, GND and VCC signals from some monitor
VGA cable where EDID DDC I2C is mandatory) to RTEMS based system
and check that it works.

For SPI, the simple test is to interconnect MISO and MOSI and check
if you read back some patter which you send to the device.
Then connect MISO to VCC (+3.3V probably on Begle Bone) and check
that you read all 0xFF then to GND and check for 0x00.
Then you need oscilloscope or some real device to check
chip selects and correct phase, polarity mode for clock
versus data changes alignment.

> >  Could you expand what do you mean by "i2c and spi Linux APIs"?
> >  As far as I remember, in Linux there were a kernel spi support and
> >  SPIDEV modules (userspace).
> >
> >  Also, there was only a master-mode support in Linux. Should RTEMS
> > support also a slave-mode?
> >
> > Please have a look at the existing device drivers that have been
> > implemented in RTEMS. You can find them under the c/src/lib/libbsp/
> > directory. Currently I think only arm devices have been supported at
> > all:
> > * libbsp/arm/atsam/i2c
> > * libbsp/arm/raspberrypi/i2c
> > * libbsp/arm/xilinx-zynq/i2c
> >
> > And for SPI I think only atsam has one merged.
> >
> > The GPIO interface was originally designed and implemented for
> > raspberrypi and a student (Ketul) wrote it for beaglebone black:
> > * libbsp/arm/raspberrypi/gpio
> > * libbsp/arm/beagle/gpio
> >
> > -Gedare
>
> Thank you. Currently, I am trying to figure out how to run rtems on top of
> my board which has a slightly different processor from the one which has an
> RTEMS bsp. 

Please, specify which chips and boards you have and want to use.
TMS570LS3137 HDK would be easiest for start.
I have TMS570LC4357 HDK there and it is the next most
interresting target for me, but it is more complex.
If you have intention to work on it, I add terminal pins
file for this variant into RTEMS mainline. TMS570LC4357
is superset of TMS570LS3137.
If you have and want to use TMS570LS1227 then it should be subset
of TMS570LS3137 peripherals.
The BSP UART code should be compatible with all of these
but base address and UARTs count may need adjustment for
the concrete chip.

1) You have option to setup chip by independent HalCoGen application
but it works best if you can load RTEMS code to the external
RAM.
2) You can use independent HalCoGen setup and setup RTEMS
ldscripts to run from some upper address from Flash.
3) You can compare HalCoGen generated files with RTEMS included
startup (hwinit) and provide tables and values alternative for your
chip.
4) I have tested option to combine mostly unchanged HalCoGen
files with RTEMS which does allow easier star but is not
a way to support multiple chips by single RTEMS TMS570 BSP
codebase. I do not like much this option but to help users
I consider adding the config option for this solution
to the RTEMS mainline. But no HalCoGen files because
it would be non-portable. Inclusion depends on others
maintainers opinion if RTEMS community wants BSP
option which makes RTEMS dependant on the third party
generated code (fortunately BSD licence compatible for now).

Please, inform me what option(s) and chips do you consider
and which variant are you trying and if/what problems
do you encounter. What tools, debuggers are you using?

After your project is selected by RTEMS/Google (or if you
intend to work on the project anyway), I can try to contact
Ti support and may it be there is chance that they
donate one board for the project. In such case,
the easier path is to select TMS570LS3137 HDK to focus
directly on SPI and I2C but some other boards
can be more interresting from long term BSP perspective.
I.e. cheaper Launchpads to allow broader community
to use BSP or TMS570LC43xx because it matches RTEMS
well and much more tests can be run directly from its
larger internal RAM without wearing Flash with limited
erase cycles count. Extending BSP and proving that
it can be used with more TMS570 chip variants would
worth additional time required for the later case. 

Best wishes,

Pavel

PS: As for the e-mails to the lists, plain text
    is preferred by me. HTML requires to adjust quoting
    when converted to plain text in the reply.
    Same for the code and patches, HTML makes
    these unusable. But it worth to setup GIT
    to send patches anyway because even text format
    is malformed by many fancy e-mail clients today.