[PATCH] BSP for TMS570LS31x Hercules Development Kit from TI (TMS570LS3137)

[Sebastian Huber]

On 14/08/14 09:48, Pavel Pisa wrote:
> Hello Sebastian,
>
> On Thursday 14 of August 2014 07:39:19 Sebastian Huber wrote:
>> Hello,
>>
>> its nice that you use the new Termios device API.  I would be happy to
>> receive comments if you found something odd about it.
>>
>> Contains the current GCC 4.8 or 4.9 branch HEAD all what is necessary for
>> your BSP?
>
> I have rebuild x86_64 -> arm-rtems4.11 toolchain after you have redone
> Cortex-R patch and all Premek's works is done by that. Even newlib
> has been updated after official single  liner correction.

Ok, good.

>
>> I recently committed a patch for the Cortex-M floating point unit.  There
>> are probably now some conflicts with your Cortex-R floating point code.
>
> As for floating-point, we use softfloat for Cortex-R still, sorry.
> Premek has been busy enough with other stuff till now.
> But I expect that after your change it should be quite straightforward
> to test with VFP-D16. We do that.
>
> As for registers and fields names, the initial fragments are generated
> by Ti manual Python parser and then adjusted by hand.
>
> https://github.com/AoLaD/rtems-tms570-utils/tree/master/parser
>
> Again, parser has not been updated after Premek's initial version too
> much because focus was to have something running first.
>
> Comments and alignments are easy. I think that registers structures
> per module are OK either. As for fields, I am not sure what to select.
> One option is to use unions in structures
>
>    union {
>      uint32_t v;
>      struct {
>         unsigned xxx : 10;
>         unsigned yy : 5;
>      }
>    }
>
> This is roughly what original Ti headers use. But problem is that
> BSP should be reusable for more TMS570 chips and in future even
> for RM48 and RM57. The last two are used in industrial area may be
> even more than TMS570 (automotive/safety) and are little endian.
> Ti has all blocks of bitfields twice with endian ifdef. I would prefer
> more Linux kernel MIPS approach if bitfields are used
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/mips/include/uapi/asm/inst.h?id=refs/tags/v3.15#n486

My experience with bitfields at this level is that GCC is regularly broken in 
this area.

>
> But I generally prefer more only defines used for such fields.
>
> Then it would look something like
>
>    TMS570_SCI_SCICLEARINT_XXX
>
> My notation is to add suffix "_m" for mask, "_b" for starting bit position
> if used and where are offset from base "_o". The "_m" and "_b" quite usesfull
> because C dosenit warn you when starting bit or mask is mixed and results
> of mixing are quite damaging.
>
> But use of macros leads to quite complex/long lines in the code.

Yes, I prefer this too.  You may have a look at

http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/shared/include/arm-pl011-regs.h

>
> As for formating, the LPC BSP uses mixing of defines and structure fields
> declarations. Quite readable but on the other hand overview
> of compact structure is little lost. So may it be that compact
> structure and then list of macros with comment about field or even
> offset macros would be more readabble
>
>    TMS570_SCI_SCICLEARINT_o
>
> The alone at beginning would be easier for Premek now than inserting
> fields between already defined fields.
>
> Anyway, I expect that the parser enhancement is the right way
> and only manageable way for us if we consider all periferals
> which we already have running on Ti provided headers in our
> other projects and which we want to move to RTEMS when it
> we have solid support (SPI, CAN, FlexRay, N2HET etc.)
>    http://rtime.felk.cvut.cz/rpp-tms570/
> Because we have no resources to prepare all headers manually
> and Premek does not look at Ti headers for unclear license reasons.
>
> Best wishes,
>
>                    Pavel
>
> PS: I have not get to promissed testing of Cortex-M4F yesterday
>      and I have only LPC1788 based board at hand now. I have struck
>      mostly on consultation a helping move motion control to some
>      FPGA based Profinet stack which is diploma thesis of our other
>      student. I have testing Cortex-M4F on my list but I get to
>      it probably only next week.
>

I only tested it with the spfatal26 and spcontext01 tests so far.  These two 
tests are quite handy and may help you with the Cortex-R floating point 
support.  My next step is to figure out if the LPC4088 works better with Google 
Skia which uses 32-bit floats for the anti-aliasing calculations etc.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.