[PATCH] Fixes for TMS570 BSP
Pavel Pisa
ppisa4lists at pikron.com
Mon Apr 19 19:02:00 UTC 2021
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...
More information about the devel
mailing list