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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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... >
_______________________________________________ devel mailing list [email protected] http://lists.rtems.org/mailman/listinfo/devel
