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