Hello, I think this patch was forgotten. Pushing it up :-)
Kind regards Robin On Tue, 20 Apr 2021 at 16:56, Robin Müller <robin.muelle...@gmail.com> wrote: > 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 <ppisa4li...@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.muelle...@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.muelle...@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... >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
