[PATCH] Fixes for TMS570 BSP

Tue Apr 20 14:56:06 UTC 2021

I am currently extending the lwIP port provided by you for the
STM32H743ZI-Nucleo. I am also extending it to be more easily adaptable to
other BSPs and new ports:
https://github.com/rmspacefish/rtems-lwip/tree/78ec73e89644c2ffa3b66c94239e1dc6ccf8a2f8
.

I've managed to receive UDP packets via RAW Api, and I will test the other
lwIP APIs and TCP soon as well.  It would be amazing if you can test
whether your port still works properly after I have tested everything.
I managed to compile it with the BSP fixes some time ago, but some other
files have changed again.. I can notify you when I have tested everything.

Kind Regards
Robin

On Mon, 19 Apr 2021 at 21:02, Pavel Pisa <ppisa4lists at pikron.com> wrote:

> Hello Robin and Gedare,
>
> (sent again to pass into the list)
>
> On Monday 19 of April 2021 19:13:29 Gedare Bloom wrote:
> > Hi Robin, Pavel:
> >
> > On Mon, Apr 19, 2021 at 2:57 AM Robin Müller <robin.mueller.m at gmail.com>
> wrote:
> > > If this was intentional, I can also adapt the lwIP port sources to use
> > > ti/herc. I was not sure about that.
> >
> > I think Pavel should comment. I believe at the time care was taken to
> > avoid importing TI HalCoGen code generation, and maybe this missing
> > ti_herc is an artifact from that. I think over time TI has moved
> > toward providing a slightly better license (2-clause BSD with hardware
> > restriction) on their HAL/SOC libs. We won't merge code with the
> > hardware restriction clause. So it can be a little problematic to get
> > things working nicely, it has to be well documented the steps to
> > reproduce setups based on restrictive vendor-provided code.
> >
> > That's what I remember anyway. Pavel may explain better.
>
> Yes, the main problem has been incompatible license, other problem
> is that HalCoGen header files was and probably is still different
> for different family members. It seems to make header files to be generated
> partly by hand and by different people, some code fills hexadecimal numbers
> into registers without using predefined bit fields etc., basically
> basically the code quality which should never go into any safety related
> application.
>
> Premysl Houdek has workend o project as part of thesis work and GSoC.
> He converted complete fields description from the manual to the JSON
> files and then generated all header files according to format,
> which has been declared as the best one by Embedded Brains for other
> BSPs. Se the project with headers generation
>
>   https://github.com/AoLaD/rtems-tms570-utils
>
> But we have added option to compile RTEMS BSP with HalCoGen
> generated files the first. Then we have written UART
> and other parts from scratch, because there was not full documentation
> for test subsystem init, there has been some parts taken
> from Ti example files and where possible tidied up to use
> symbols for bitfields. When BSP is compiled with
>
>   TMS570_USE_HWINIT_STARTUP=1
>
> it can start without external initialization or loader.
>
> Long term plan has been to add support for TMS570LC4357
> as well but cooperation with other universities, open-source
> and RTEMS has been of no interrest of my former head...
>
> The work on this BSP is on my very long todo list, but
> with very low priority....
>
> Anyway, we achieved to port LwIP to RTEMS BSP, TMS570 part
> is generally rewrite from scratch, we have failde many times
> at that time with Ti provided code even with their FreeRTOS
> code. Our port is in omk-devel branch of the next repo
>
>   https://sourceforge.net/p/ulan/lwip-omk/ci/omk-devel/tree/
>
> Code worked with FreeRTOS and HalCoGen BSP as well as with RTEMS
>
>
> https://sourceforge.net/p/ulan/lwip-omk/ci/omk-devel/tree/ports/driver/tms570_emac/
>
> https://sourceforge.net/p/ulan/lwip-omk/ci/omk-devel/tree/ports/os/rtems/
>
> But on RTEMS there is some way to go still to integrate LwIP
> with RTEMS+NEWLIB to be usable same way as old included BSD
> and new external BSD stack. I hope that things move forward
> during this year GSoC.
>
> As for changes, I have not worked with TMS570 RTEMS for long time.
> Again, I would like to check that BSP runs correctly before next
> release, but time is a problem, so no promise there.
>
> If there is problem with defines collision, I ACK to change
> names. In the fact, it seems to be incorrect even in past.
>
> I have worked with BSP before switch to YAML based build,
> so I cannot say what is right for now. But ti_herc seems
> to be consistet with headers location in the BSP sources,
> so I think that the change is correct as well.
>
>
> > > On Mon, 19 Apr 2021 at 10:55, Robin Mueller <robin.mueller.m at gmail.com>
> wrote:
> > >> When compiling the lwIP port for the TMS570, there
> > >> were issues with the BSP. Headers are expected in a folder
> > >> named ti_herc which did not exist. This fixes the issue.
> > >>
> > >> Furthermore, there were multiple warnings about define redefinitions.
> > >> This was fixed as well.
> > >> ---
> > >>  bsps/arm/tms570/include/bsp/irq.h  | 6 +++---
> > >>  spec/build/bsps/arm/tms570/obj.yml | 2 +-
> > >>  2 files changed, 4 insertions(+), 4 deletions(-)
> > >>
> > >> diff --git a/bsps/arm/tms570/include/bsp/irq.h
> > >> b/bsps/arm/tms570/include/bsp/irq.h index c37ebadbc4..0b6ea1e6fd
> 100644
> > >> --- a/bsps/arm/tms570/include/bsp/irq.h
> > >> +++ b/bsps/arm/tms570/include/bsp/irq.h
> > >> @@ -34,7 +34,7 @@
> > >>
> > >>  #define BSP_INTERRUPT_VECTOR_MIN 0U
> > >>  #define TMS570_IRQ_ESM_HIGH 0
> > >> -#define TMS570_IRQ_RESERVED 1
> > >> +#define TMS570_IRQ_RESERVED_0 1
> > >>  #define TMS570_IRQ_TIMER_0 2
> > >>  #define TMS570_IRQ_TIMER_1 3
> > >>  #define TMS570_IRQ_TIMER_2 4
> > >> @@ -50,7 +50,7 @@
> > >>  #define TMS570_IRQ_ADC1_EVENT 14
> > >>  #define TMS570_IRQ_ADC1_GROUP_1 15
> > >>  #define TMS570_IRQ_CAN1_HIGH 16
> > >> -#define TMS570_IRQ_RESERVED 17
> > >> +#define TMS570_IRQ_RESERVED_1 17
> > >>  #define TMS570_IRQ_FLEXRAY_HIGH 18
> > >>  #define TMS570_IRQ_CRC_1 19
> > >>  #define TMS570_IRQ_ESM_LOW 20
> > >> @@ -63,7 +63,7 @@
> > >>  #define TMS570_IRQ_SCI_LEVEL_1 27
> > >>  #define TMS570_IRQ_ADC1_GROUP_2 28
> > >>  #define TMS570_IRQ_CAN1_LOW 29
> > >> -#define TMS570_IRQ_RESERVED
> > >> +#define TMS570_IRQ_RESERVED_2 30
> > >>  #define TMS570_IRQ_ADC1_MAG 31
> > >>  #define TMS570_IRQ_FLEXRAY_LOW 32
> > >>  #define TMS570_IRQ_DMA_FTCA 33
> > >> diff --git a/spec/build/bsps/arm/tms570/obj.yml
> > >> b/spec/build/bsps/arm/tms570/obj.yml index 7932299c1d..36f99a700e
> 100644
> > >> --- a/spec/build/bsps/arm/tms570/obj.yml
> > >> +++ b/spec/build/bsps/arm/tms570/obj.yml
> > >> @@ -29,7 +29,7 @@ install:
> > >>    - bsps/arm/tms570/include/bsp/tms570_selftest_parity.h
> > >>    - bsps/arm/tms570/include/bsp/tms570lc4357-pins.h
> > >>    - bsps/arm/tms570/include/bsp/tms570ls3137zwt-pins.h
> > >> -- destination: ${BSP_INCLUDEDIR}/bsp/ti/herc
> > >> +- destination: ${BSP_INCLUDEDIR}/bsp/ti_herc
> > >>    source:
> > >>    - bsps/arm/tms570/include/bsp/ti_herc/reg_adc.h
> > >>    - bsps/arm/tms570/include/bsp/ti_herc/reg_ccmsr.h
> > >> --
> > >> 2.29.2.windows.2
>
> So if the code builds for you and ideally if you can report that it runs
> well, then I ACK the change.
>
> I have there small local change as well. In the past, baudrate for UART
> has not
> been defined for some test. I have added wokaround to select 115200
> when baudrate is not selected anywhere. But this is hack which is probably
> solved on the other level already
>
> --- a/bsps/arm/tms570/console/tms570-sci.c
> +++ b/bsps/arm/tms570/console/tms570-sci.c
> @@ -261,6 +261,8 @@ bool tms570_sci_set_attributes(
>
>    /* Baud rate */
>    baudrate = rtems_termios_baud_to_number(cfgetospeed(t));
> +  if ( baudrate == 0 )
> +    baudrate = 115200;
>
>    rtems_termios_device_lock_acquire(base, &lock_context);
>
> Best wishes,
>
> Pavel
>
> PS: I pose both TMS570LS3137 and TMS570LC4357 HDK and I have even access
>     to newer TMS570LC4357 kits at Elektroline company, so I can run some
> tests.
>     As for development tools, I have modified OpenOCD for TMS570LS3137 but
>     changes are based on other series, which never has got into mainline
>       https://cmp.felk.cvut.cz/~pisa/tms570/
>     Binary only Flash API is another problem, but it can be solved by
> runtime ELF load.
>     I would be happy if somebody has newer OpenOCD working with
> TMS570LS3137
>     and even better if somebody has already invested time to TMS570LC4357
> support.
>     We have nice ETHERNET based XCP loader, but former head believes that
> he has control
>     about that proprietary code...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210420/5461bec3/attachment.html>