rtems from TMS570 SDRAM or INTRAM

Fri Apr 28 16:20:37 UTC 2017

On Fri, Apr 28, 2017 at 11:16 AM, Nikolay Komashinskiy
<nikolay.komashinskiy at yandex.ru> wrote:
> Hello,
>
> thank you for you reply and sorry for my long response.
>
> Am I using HTML formatting? If yes, I am going to set up my client properly.
>
>>
>> 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
>
> Oh, yes, I forgot about it, then I can use an stm32 board with HAL layer. It has the spi
> slave capabilities.
>>
>>   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.
>
> Yes, I am going to do it in this way, also I has a simple logic analyzer.
>
>> 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.
>
> I am going to work with TMS570LC4357 with LAUNCHXL2-
> 570LC43 board with its onboard dubugger (XDS110). I think
> I can use it in a couple with openocd debugger. And I already
> have this board.
>
I also have this board.

> The current stage of investigation of the board - I've just installed
> Halcogen under Wine and generated some code.
> I hope, I can compile it and debug it soon.
>
> I want to work with this board, because, for example, one of my
> colleagues wants to start to program it with a bare-metal Ada(!).
> So, I can see some interest to this board in my lab.
>
> I feel a need to show results of my work somewhere, could you
> recommend such a place? I don't like blogs, because they don't
> allow to easily represent the current stage and just show the process.
> Maybe, it is better to use some wiki + comments under the project's ticket?
>
If you are accepted (should find out May 4), then we will start some
procedures for GSoC purposes of tracking work. This will involve a
wiki page and a blog.

> Could you also give me examples of I2C EEPROM programmed chips?
>
>
> ---
> Regards, Nikolay Komashinskiy.