rtems from TMS570 SDRAM or INTRAM

Fri Apr 28 15:16:44 UTC 2017

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.

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?

Could you also give me examples of I2C EEPROM programmed chips?

---
Regards, Nikolay Komashinskiy.