Re: [PATCH v3 2/2] update README with instructions for stm32 patch

[Robin Müller]

Hi,

This patch now contains all files which have the problematic license so the
RTMES LwIP code stays free of them.
Actually, it probably would be a better idea if the patch is applied as
part of the build process.. Does anyone have experience how to do this with
waf?

Kind Regards
Robin Müller

On Sun, 24 Oct 2021 at 12:54, Robin Mueller 
wrote:

> ---
>  README.md | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/README.md b/README.md
> index ebbef12..3653b67 100644
> --- a/README.md
> +++ b/README.md
> @@ -17,6 +17,16 @@ It is recommended that the user supplies the
> `lwipopts.h` configuration file. Th
>  contain template option files to get started. The user can copy and
> rename this files into the
>  application and then pass the include path to the build system using the
> `--lwip-opts` option.
>
> +# Applying the STM32 patch file
> +
> +Some STM32 files are problematic due to the used license. Therefore, they
> are applied in form of
> +a patch. You need to perform the following steps in order to use the
> STM32H7 BSP:
> +
> +```sh
> +wget -O stm32.patch
> https://raw.githubusercontent.com/robamu-org/rtems-stm32-lwip-port-patch/main/stm32-bsp-eth-dhcp-files.patch
> +git am stm32.patch
> +```
> +
>  # Building with waf
>
>  It is assumed that the path(s) containing the `lwipopts.h` file was
> stored in the environmental
> --
> 2.32.0
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] STM32 lwIP addition and CMake support

[Robin Müller]

Hi,

Unfortunately, there was no other reply to the request.

Easiest solution would be to exclude the STM32 code completely out of RTEMS
code for now. I can host it as example code in a personal repository.
But then I might have to change the architecture of the lwIP code again
which provided some building blocks to make porting/using it easier.

Kind Regards
Robin

On Thu, 5 Aug 2021 at 17:00, Gedare Bloom  wrote:

> STM is not going to fix their Ultimate Liberty License at this time.
>
> https://github.com/STMicroelectronics/STM32CubeH7/issues/139#issuecomment-890806010
>
> So, we need to avoid using their example codes.
>
> On Wed, Jun 9, 2021 at 12:16 PM Gedare Bloom  wrote:
> >
> > I joined the Issue. Thanks for working on this.
> >
> > On Wed, Jun 9, 2021 at 11:30 AM Robin Müller 
> wrote:
> > >
> > > I posted a reply but I think it did not go through. Will post it now.
> > >
> > > Kind Regards
> > > Robin
> > >
> > > On Wed, 9 Jun 2021 at 18:31, Robin Müller 
> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I received a reply from STM32 about the licensing issues. They
> requested more specific information about the "vendor device restrictions"
> for the HAL code.
> > >> The issue is here:
> https://github.com/STMicroelectronics/STM32CubeH7/issues/139
> > >> Can anyone provide more information about this (maybe even directly
> in the issue) ? I can forward it to them as well. Thanks a lot in advance!
> > >>
> > >> Kind Regards
> > >> Robin
> > >>
> > >> On Wed, 28 Apr 2021 at 02:45, Chris Johns  wrote:
> > >>>
> > >>> On 28/4/21 2:58 am, Robin Müller wrote:
> > >>> > Okay, I can understand that you'd like to have one build system
> only. We had the
> > >>> > same issue with a former Makefile build system and the new CMake
> system and
> > >>> > decided to make the former system obsolete> because maintaining
> both of them would be too much work
> > >>> For RTEMS what we use has been selected for a range of important
> reasons and the
> > >>> rtems-central repo and the qual work highlights the importance of
> those
> > >>> decisions. Waf is a python framework for building software and in
> rtems.git our
> > >>> build system support is written in a clearly defined portable
> language with
> > >>> power helper libraries. We can run code formatters on our build
> system, have
> > >>> unit tests and there is even source level debuggers. We treat the
> build system
> > >>> like any other piece of code we have.
> > >>>
> > >>> > First thing I  can do is that I split up the patch and extract the
> CMake
> > >>> > specific files. Concerning a clean solution to allow users to use
> CMake without
> > >>> > introducing files like CMakeLists.txt,
> > >>> > I am not sure right now. Extracting the information required by
> CMake would
> > >>> > again require scripts to export source files and include paths.
> > >>> > The simplest solution would still be a CMakeLists.txt file in the
> root here
> > >>> > which simply sets source files and include paths in the parent
> scope.
> > >>> > which would again be another form of maintenance burden because it
> still needs
> > >>> > to figure out which port sources to add etc.
> > >>>
> > >>> What about scons, meson, or a plain Makefile for those who just want
> to use
> > >>> make, then there is GNU make and BSD make, the list is large? Do we
> open the
> > >>> repo up so all build systems are welcome? I think we would have to
> so we are not
> > >>> picking favourites.
> > >>>
> > >>> Who tests these build system files when the package is released? As
> the person
> > >>> who releases RTEMS I do not have the time or capability to do this.
> > >>>
> > >>> > The rtems-cmake support is able to live without CMakeLists.txt
> files in RTEMS
> > >>> > because the BSP is already compiled at that point. Doing something
> similar
> > >>> > would require a similar process like done in the BSP where
> rtems-lwip is
> > >>> > compiled as a static library for a specific BSP,
> > >>> > installed somewhere and then an application can link against it
> while also
> > &g

Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition

[Robin Müller]

Hello,

I am still waiting on STM32 reply because of the licensing issue. Might
still take weeks/months..

Another solution would be to write some scripts to copy the code from the
Cube sources..
But I would prefer to avoid them, because I also had to merge some of the
files provided by STM so that I could use/test all three APIs.

I was able to test and use all major APIs on a STM32H7 board with RTEMS,
including the Socket API.. Although I disliked about the Socket API that
it's
easy to forget the cache invalidation on the TX/RX buffers (forgot which
one it was) if they are not protected via MPU but that's also a STM32H7
specific issue.

The current version of the rtems-lwip support after I added STM32H7 can
still be found here:
https://github.com/rmspacefish/rtems-lwip/tree/mueller/master
and includes the TMS570 code as well.

There is also a LPC port here:
https://github.com/sacha23/lwip-rtems-support/tree/master/src/ports/driver/lpc_emac
But that one still appears to use Makefiles, and needs to be updated to waf
if it is integrated.

Kind Regards
Robin



On Thu, 22 Jul 2021 at 00:10, Vijay Kumar Banerjee  wrote:

> Hi,
>
>
> On Wed, Jul 21, 2021 at 2:25 AM Pavel Pisa  wrote:
> >
> > Hello Vijay,
> >
> > thanks of the status.
> >
>
> I added a note in the devel page:
> https://devel.rtems.org/wiki/Packages/LWIP
>
>
>
> > On Wednesday 21 of July 2021 07:16:51 Vijay Kumar Banerjee wrote:
> > > Hi Pavel,
> > >
> > > On Tue, Jul 20, 2021 at 1:13 PM Pavel Pisa 
> wrote:
> > > > Is it devel branch of  Vijay Kumar Banerjee's
> > > > repo
> > > >
> > > >   https://git.rtems.org/vijay/rtems-lwip.git/
> > >
> > > Right now yes. Once this is mature, it will probably be pushed to the
> > > top directory.
> > >
> > > > If so, it would worth to put that on the top
> > > > of LwIP RTEMS info page to guide people interested
> > > > to live work and not lose time in another
> > > > abandonned attempts
> > > >
> > > >   https://devel.rtems.org/wiki/Packages/LWIP
> > >
> > > Thanks, I'll add a note there.
> > >
> > > > Addition of pointers to STM WIP to some
> > > > central place would worth too with
> > > > pointer to the instructions or instructions
> > > > included...
> > >
> > > I haven't tested it myself. Robin is working on this one and might be
> > > able to add the instructions. But this is supposed to be merged into
> > > the repo you mentioned above.
> >
> > Great that there is the common merge place.
> >
> >
> > > > Generally I am curious what works and where
> > > > are problems. I do not expect to have time or
> > > > find students this summer but I try to offer
> > > > project as theses and next summer and there
> > > > chance (small) that I find some studnet
> > > > to participate.
> > >
> > > I am currently actively working on the lwip port to get it working
> > > with at least a few boards, along with a streamlined build system. I
> > > could only get the BBB running with a telnetd application that I added
> > > in the test/ directory in the rtems-lwip repository. I used the
> > > drivers from TI for BBB.
> >
> > OK, I have some access to BBB so when my or some studnet
> > time allows we can test it on this target.
> Thanks. Any feedback would be really appreciated.
>
> > I am more personally interested to TMS570.
> > I think that I can find some time for testing on TMS570LS3137
> > if the instructions and code is declared to worth to test.
> > I hope that I have all tools for this setup.
> >
> This has not been tested yet, I'm working on the build system to
> streamline the process further. It would be great to get this port
> tested. Please ping me if you have any build issues when testing (if
> you happen to test before the build system update :) ).
>
>
> > =
> > Side note to TMS570 FEE CTU code (if there is interest,
> > I it would worth to move to separate thread)
> >
> > By the way, the way my former colleagues who left faculty
> > stopped blocking (after many years) TMS570 Rapid Prototyping
> > Platform code
> >   http://rtime.felk.cvut.cz/rpp-tms570/
> > and changed master branch license to MIT (The work has been
> > exploited to gain money from their industrial partners and has
> > little value for them now). Code was and is licensed under our
> > faculty name and I can legally show it to third parties now
> > and  try to find arrangement to share my and my students effort
> > with community.
> >
> > There is XCP https://en.wikipedia.org/wiki/XCP_(protocol)
> > loader implemented on FreeRTOS base which allows to update
> > firmware over ETHERNET so it can be used as boot block for
> > RTEMS. It can make RTEMS support testing and even continuous
> > integration much easier. When RTEMS is run from SDRAM it
> > would prevent Flash wear-out, important for TMS570,
> > because guaranteed erase cycles are limited.
> >
> > Then there is support for lot of the TMS570 peripherals
> > in the state twisted with HalCoGen, not directly usable,
> > 

Re: Building a library for use with RTEMS via CMake

[Robin Müller]

tems-cmake uses the toolchain file functionality which takes care of
finding the RTEMS compiler and add the required flags for RTEMS.
If the CMakeLists.txt belongs to a library, I would guess you will compile
it as part of a  (dummy) project and you can still edit the top
CMakeLists.txt?
If you still need a custom toolchain file you can probably write your own
toolchain file and then include the rtems-cmake toolchain file but I have
never
tested doing something like that.

As long as your library does not require setting another toolchain file as
well, compiling it should not be an issue.

Kind Regards
Robin

On Wed, 21 Jul 2021 at 16:48, Robin Müller 
wrote:

> rtems-cmake uses the toolchain file functionality which takes care of
> finding the RTEMS compiler and add the required flags for RTEMS.
> If the CMakeLists.txt belongs to a library, I would guess you will compile
> it as part of a  (dummy) project and you can still edit the top
> CMakeLists.txt?
> If you still need a custom toolchain file you can probably write your own
> toolchain file and then include the rtems-cmake toolchain file but I have
> never
> tested doing something like that.
>
> As long as your library does not require setting another toolchain file as
> well, compiling it should not be an issue.
>
> Kind Regards
> Robin
>
> On Tue, 20 Jul 2021 at 13:07,  wrote:
>
>> Hey guys,
>>
>>
>>
>> that was so far very helpful in understanding the problem in more depth.
>>
>> Putting in the right flags at least reduced the linker errors by nearly
>> 99% or so, Thanks.
>>
>> Maybe I am on the right path now and just need to tweak it a bit to make
>> it work.
>>
>>
>>
>> The rtems-cmake repository looks also very promising to me, I surely have
>> to dig deeper into the processes going on there.
>>
>> Problem is that I should (ideally) not change the CMakeLists.txt from the
>> library so it stays independent.
>>
>> Do you have any thoughts on that Robin?
>>
>> Do you think wrapping the library CMakeLists.txt in another one which
>> then uses the repository might work?
>>
>>
>>
>> But I realized that I have missed some information while explaining this
>> issue.
>>
>> The RTEMS application itself is built with SCons and therefore the
>> desired build environment (flags and so forth) is already defined within a
>> python dictionary.
>>
>> Now we need to somehow build the library via CMake using the established
>> environment, install and link against it via SCons.
>>
>> Do you have worked with something  like this before?
>>
>>
>>
>> Best regards
>>
>> André
>>
>>
>>
>> *Von:* devel  *Im Auftrag von *Robin Müller
>> *Gesendet:* Dienstag, 20. Juli 2021 11:46
>> *An:* Michael Davidsaver ; devel@rtems.org
>> *Betreff:* Re: Building a library for use with RTEMS via CMake
>>
>>
>>
>> I managed to compile our project with CMake, using this repository:
>> https://github.com/spacefisch/rtems-cmake
>>
>> It uses the pkg-config files to set up the cross compiler given the BSP
>> and RTEMS prefix information.
>>
>>
>>
>> Maybe this can help you
>>
>>
>>
>> Kind Regards
>>
>> Robin
>>
>>
>>
>> On Tue, 20 Jul 2021 at 00:50, Michael Davidsaver 
>> wrote:
>>
>> On 7/19/21 6:17 AM, andre.nahrw...@dlr.de wrote:
>> > Hello,
>> >
>> > I have built RTEMS 5 and its tools for the Xilinx Zynq Zedboard and
>> installed the BSP and tools at a certain position on my machine.
>> > The tools are added to the PATH variable and RTEMS_BSPS is also
>> available in the environment.
>> >
>> > Now we need to build a library for the use with RTEMS via CMake.
>> > For this we wanted to use the toolchain files.
>> > Does anybody know how to correctly setup such a toolchain file using
>> the RTEMS compiler?
>> >
>> > We managed to get a toolchain file working which at least built the
>> library.
>> > But when we wanted to link to this library during compilation of a
>> RTEMS application we got a bunch of errors due to undefined references to
>> standard library functions.
>> > Does anybody has a clue where this might origin from?
>>
>> As it happens, I went through this exercise recently with libevent.
>> The main obstacle for me was that the CMake try_compile() command
>> actually tries to link an executable.  With RTEMS 5 this can't be
>> done generically without also adding '-lrtemsdefaultconfig'.
>>

Re: Building a library for use with RTEMS via CMake

[Robin Müller]

I managed to compile our project with CMake, using this repository:
https://github.com/spacefisch/rtems-cmake
It uses the pkg-config files to set up the cross compiler given the BSP and
RTEMS prefix information.

Maybe this can help you

Kind Regards
Robin

On Tue, 20 Jul 2021 at 00:50, Michael Davidsaver 
wrote:

> On 7/19/21 6:17 AM, andre.nahrw...@dlr.de wrote:
> > Hello,
> >
> > I have built RTEMS 5 and its tools for the Xilinx Zynq Zedboard and
> installed the BSP and tools at a certain position on my machine.
> > The tools are added to the PATH variable and RTEMS_BSPS is also
> available in the environment.
> >
> > Now we need to build a library for the use with RTEMS via CMake.
> > For this we wanted to use the toolchain files.
> > Does anybody know how to correctly setup such a toolchain file using the
> RTEMS compiler?
> >
> > We managed to get a toolchain file working which at least built the
> library.
> > But when we wanted to link to this library during compilation of a RTEMS
> application we got a bunch of errors due to undefined references to
> standard library functions.
> > Does anybody has a clue where this might origin from?
>
> As it happens, I went through this exercise recently with libevent.
> The main obstacle for me was that the CMake try_compile() command
> actually tries to link an executable.  With RTEMS 5 this can't be
> done generically without also adding '-lrtemsdefaultconfig'.
>
> eg.
>
> > string(APPEND CMAKE_EXE_LINKER_FLAGS_INIT " -lrtemsdefaultconfig")
>
> Also, if you use networking you might want to add.
>
> > set(CMAKE_REQUIRED_LIBRARIES "-lbsd")
>
> for eg. CheckFunctionExists.cmake to work correctly.
>
>
> The (fairly complex) result of this all can be found here:
>
> https://github.com/mdavidsaver/pvxs/tree/master/bundle
>
> The essential parts are:
>
> - cmake/RTEMS.cmake@
>
> Template toolchain file.  (expand using definitions from RTEMS makefiles)
>
> - cmake/Platform/
>
> Hooks into the CMake startup process.  The exact interplay between
> Platform/ and toolchain file is... quite involved.  Also not well
> documented.  The best I've found is:
>
>
> https://github.com/Kitware/CMake/blob/f86d8009c6a4482c81221114a2b04b375564cc94/Source/cmGlobalGenerator.cxx#L461-L504
>
>
>
> > Building a RTEMS application which does not use the own library works
> fine.
> >
> > Our toolchain file looks like this:
> >
> > # CMake toolchain file for ARM
> > # The compiler is based on
> > # The RTEMS_BSPS environment variable is expected to be set.
> > set(ARCH arm)
> > set(CMAKE_SYSTEM_NAME RTEMS5)
> >
> > set(CMAKE_CXX_FLAGS "" CACHE STRING "ARM RTEMS5 gcc additional compiler
> flags" FORCE)
> >
> > set(RTEMS_TOOLS_PATH $ENV{RTEMS_BSPS}/../../tools/bin)
> >
> > set(CMAKE_C_COMPILER ${RTEMS_TOOLS_PATH}/arm-rtems5-gcc CACHE PATH "ARM
> RTEMS5 gcc" FORCE)
> > set(CMAKE_CXX_COMPILER ${RTEMS_TOOLS_PATH}/arm-rtems5-gcc CACHE PATH
> "ARM RTEMS5 gcc" FORCE)
> > set(CMAKE_CXX_COMPILER_AR ${RTEMS_TOOLS_PATH}/arm-rtems5-gcc-ar CACHE
> PATH "ARM RTEMS5 ar" FORCE)
> > set(CMAKE_CXX_COMPILER_RANLIB ${RTEMS_TOOLS_PATH}/arm-rtems5-gcc-ranlib
> CACHE PATH "ARM RTEMS5 gcc ranlib" FORCE)
> > set(CMAKE_RANLIB ${RTEMS_TOOLS_PATH}/arm-rtems5-ranlib CACHE PATH "ARM
> RTEMS5 ranlib" FORCE)
> > set(CMAKE_READELF ${RTEMS_TOOLS_PATH}/arm-rtems5-readelf CACHE PATH "ARM
> RTEMS5 readelf" FORCE)
> > set(CMAKE_STRIP ${RTEMS_TOOLS_PATH}/arm-rtems5-strip CACHE PATH "ARM
> RTEMS5 strip" FORCE)
> > set(CMAKE_ADDR2LINE ${RTEMS_TOOLS_PATH}/arm-rtems5-addr2line CACHE PATH
> "ARM RTEMS5 addr2line" FORCE)
> > set(CMAKE_LINKER ${RTEMS_TOOLS_PATH}/arm-rtems5-ld CACHE PATH "ARM
> RTEMS5 ld" FORCE)
> > set(CMAKE_NM ${RTEMS_TOOLS_PATH}/arm-rtems5-nm CACHE PATH "ARM RTEMS5
> nm" FORCE)
> > set(CMAKE_OBJCOPY ${RTEMS_TOOLS_PATH}/arm-rtems5-objcopy CACHE PATH "ARM
> RTEMS5 objcopy" FORCE)
> > set(CMAKE_OBJDUMP ${RTEMS_TOOLS_PATH}/arm-rtems5-objdump CACHE PATH "ARM
> RTEMS5 objdump" FORCE)
> >
> > set(CMAKE_TARGET_CONFIG_POSTFIX .rtems5_gcc_arm)
> >
> > Best regards
> > Andre Nahrwold
> > --
> > Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
> > German Aerospace Center
> > Institute for Software Technolog | SRV-OSS BS | Lilienthalpl. 7 | 38108
> Braunschweig | Geb. 112C Raum 001
> > M.Sc. Andre Nahrwold | Telephone +49 531 295-3834 |
> andre.nahrw...@dlr.de
> > DLR.de
> >
> > ___
> > users mailing list
> > us...@rtems.org
> > http://lists.rtems.org/mailman/listinfo/users
> >
>
> ___
> users mailing list
> us...@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Fixes for TMS570 BSP

[Robin Müller]

Hello,

 I think this patch was forgotten. Pushing it up :-)

Kind regards
Robin

On Tue, 20 Apr 2021 at 16:56, Robin Müller 
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  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 
>> 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 

Re: [PATCH 2/2] This adds a way to print the host triplet

[Robin Müller]

Hi,

I think this patch was forgotten so I'm just pushing it up again :-)

Kind Regards
Robin

On Thu, 25 Feb 2021 at 10:57, Robin Müller 
wrote:

> I still think it would be nice if very common tool suites like ARM could
> be installed /downloaded in a pre-compiled way at least for Windows because
> the  tool building process is the only thing preventing
> development on Windows some(or most?) times.
> xPacks is doing that (and they use CXC for the Windows toolchain too,
> building it automatically for Windows on a Debian machine, see here
> https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/releases) and
> Arduino ships pre-compiled  toolchains with their software (but it's
> possible to download separately as well).
>
> Once the tool suite was available, I did not have any OS specific issues
> any more.
>
> Kind Regards
> Robin
>
> On Thu, 25 Feb 2021 at 10:44, Robin Müller 
> wrote:
>
>> I only used it to CXC the ARM toolchain (Linux -> Windows) mainly because
>> I have only needed the ARM tool suite up until now (and there were issues
>> building it  on Windows, but maybe that has been solved since).
>> That was a few weeks ago and I have not rebuilt it since.
>>
>> Kind Regards
>> Robin
>>
>> On Thu, 25 Feb 2021 at 01:30, Chris Johns  wrote:
>>
>>> On 25/2/21 9:21 am, Robin Müller wrote:
>>> > There is no first patch (the first patch file was a SIS update, but
>>> that's
>>> > already inside master I think).
>>> > I think I used this when I canadian cross-compiled the RTEMS ARM
>>> toolchain for
>>> > Windows on Linux and I was not sure what the triplet was.
>>>
>>> Great and thanks. Have you been using the Cxc mode recently? I have
>>> stopped
>>> testing it.
>>>
>>> Chris
>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] STM32 lwIP addition and CMake support

[Robin Müller]

I posted a reply but I think it did not go through. Will post it now.

Kind Regards
Robin

On Wed, 9 Jun 2021 at 18:31, Robin Müller  wrote:

> Hi,
>
> I received a reply from STM32 about the licensing issues. They requested
> more specific information about the "vendor device restrictions"  for the
> HAL code.
> The issue is here:
> https://github.com/STMicroelectronics/STM32CubeH7/issues/139
> Can anyone provide more information about this (maybe even directly in the
> issue) ? I can forward it to them as well. Thanks a lot in advance!
>
> Kind Regards
> Robin
>
> On Wed, 28 Apr 2021 at 02:45, Chris Johns  wrote:
>
>> On 28/4/21 2:58 am, Robin Müller wrote:
>> > Okay, I can understand that you'd like to have one build system only.
>> We had the
>> > same issue with a former Makefile build system and the new CMake system
>> and
>> > decided to make the former system obsolete> because maintaining both of
>> them would be too much work
>> For RTEMS what we use has been selected for a range of important reasons
>> and the
>> rtems-central repo and the qual work highlights the importance of those
>> decisions. Waf is a python framework for building software and in
>> rtems.git our
>> build system support is written in a clearly defined portable language
>> with
>> power helper libraries. We can run code formatters on our build system,
>> have
>> unit tests and there is even source level debuggers. We treat the build
>> system
>> like any other piece of code we have.
>>
>> > First thing I  can do is that I split up the patch and extract the CMake
>> > specific files. Concerning a clean solution to allow users to use CMake
>> without
>> > introducing files like CMakeLists.txt,
>> > I am not sure right now. Extracting the information required by CMake
>> would
>> > again require scripts to export source files and include paths.
>> > The simplest solution would still be a CMakeLists.txt file in the root
>> here
>> > which simply sets source files and include paths in the parent scope.
>> > which would again be another form of maintenance burden because it
>> still needs
>> > to figure out which port sources to add etc.
>>
>> What about scons, meson, or a plain Makefile for those who just want to
>> use
>> make, then there is GNU make and BSD make, the list is large? Do we open
>> the
>> repo up so all build systems are welcome? I think we would have to so we
>> are not
>> picking favourites.
>>
>> Who tests these build system files when the package is released? As the
>> person
>> who releases RTEMS I do not have the time or capability to do this.
>>
>> > The rtems-cmake support is able to live without CMakeLists.txt files in
>> RTEMS
>> > because the BSP is already compiled at that point. Doing something
>> similar
>> > would require a similar process like done in the BSP where rtems-lwip is
>> > compiled as a static library for a specific BSP,
>> > installed somewhere and then an application can link against it while
>> also
>> > including the headers.
>>
>> I welcome the idea of rtems-cmake to grow a community of those using
>> cmake to
>> build RTEMS applications. It is great to see this happening.
>>
>> > For the RTEMS BSP this is done through provided PKG Config files. It
>> just seems
>> > like a lot of effort for a comparatively small library.
>> > Maybe someone has a better idea?
>>
>> I do not have a better solution than PKG config. Most build systems
>> provide
>> support so it should be something that can be accommodated.
>>
>> > I am also not sure if users who are used to CMake would not just do the
>> same
>> > thing I did if there are no CMakeLists.txt files present and the
>> > library/repository is simple enough:
>>
>> I would discourage this and maybe not for the reasons you may be thinking
>> of.
>> The repo is new and is it is exciting there is work happening on it but
>> in time
>> it will become stable and it will be released with RTEMS and this puts it
>> in the
>> same configuration management basket as the BSP (kernel) and tools. The
>> RSB can
>> build it in a controlled way with reports and you just access it like the
>> BSP.
>>
>> > Add those themselves in the project root or throughout the repository
>> fork
>> > structure. But it's your call of course. Maybe some more (user)
>> opinions would
>> > help as well.
>>
>> I see rtems-cmake providing that role, thank you for it. We have learnt
>> the hard
>> way over a few decades to be mindful when adding these things. Strong
>> portable
>> eco-system level interfaces are our focus.
>>
>> Chris
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] STM32 lwIP addition and CMake support

[Robin Müller]

Hi,

I received a reply from STM32 about the licensing issues. They requested
more specific information about the "vendor device restrictions"  for the
HAL code.
The issue is here:
https://github.com/STMicroelectronics/STM32CubeH7/issues/139
Can anyone provide more information about this (maybe even directly in the
issue) ? I can forward it to them as well. Thanks a lot in advance!

Kind Regards
Robin

On Wed, 28 Apr 2021 at 02:45, Chris Johns  wrote:

> On 28/4/21 2:58 am, Robin Müller wrote:
> > Okay, I can understand that you'd like to have one build system only. We
> had the
> > same issue with a former Makefile build system and the new CMake system
> and
> > decided to make the former system obsolete> because maintaining both of
> them would be too much work
> For RTEMS what we use has been selected for a range of important reasons
> and the
> rtems-central repo and the qual work highlights the importance of those
> decisions. Waf is a python framework for building software and in
> rtems.git our
> build system support is written in a clearly defined portable language with
> power helper libraries. We can run code formatters on our build system,
> have
> unit tests and there is even source level debuggers. We treat the build
> system
> like any other piece of code we have.
>
> > First thing I  can do is that I split up the patch and extract the CMake
> > specific files. Concerning a clean solution to allow users to use CMake
> without
> > introducing files like CMakeLists.txt,
> > I am not sure right now. Extracting the information required by CMake
> would
> > again require scripts to export source files and include paths.
> > The simplest solution would still be a CMakeLists.txt file in the root
> here
> > which simply sets source files and include paths in the parent scope.
> > which would again be another form of maintenance burden because it still
> needs
> > to figure out which port sources to add etc.
>
> What about scons, meson, or a plain Makefile for those who just want to use
> make, then there is GNU make and BSD make, the list is large? Do we open
> the
> repo up so all build systems are welcome? I think we would have to so we
> are not
> picking favourites.
>
> Who tests these build system files when the package is released? As the
> person
> who releases RTEMS I do not have the time or capability to do this.
>
> > The rtems-cmake support is able to live without CMakeLists.txt files in
> RTEMS
> > because the BSP is already compiled at that point. Doing something
> similar
> > would require a similar process like done in the BSP where rtems-lwip is
> > compiled as a static library for a specific BSP,
> > installed somewhere and then an application can link against it while
> also
> > including the headers.
>
> I welcome the idea of rtems-cmake to grow a community of those using cmake
> to
> build RTEMS applications. It is great to see this happening.
>
> > For the RTEMS BSP this is done through provided PKG Config files. It
> just seems
> > like a lot of effort for a comparatively small library.
> > Maybe someone has a better idea?
>
> I do not have a better solution than PKG config. Most build systems provide
> support so it should be something that can be accommodated.
>
> > I am also not sure if users who are used to CMake would not just do the
> same
> > thing I did if there are no CMakeLists.txt files present and the
> > library/repository is simple enough:
>
> I would discourage this and maybe not for the reasons you may be thinking
> of.
> The repo is new and is it is exciting there is work happening on it but in
> time
> it will become stable and it will be released with RTEMS and this puts it
> in the
> same configuration management basket as the BSP (kernel) and tools. The
> RSB can
> build it in a controlled way with reports and you just access it like the
> BSP.
>
> > Add those themselves in the project root or throughout the repository
> fork
> > structure. But it's your call of course. Maybe some more (user) opinions
> would
> > help as well.
>
> I see rtems-cmake providing that role, thank you for it. We have learnt
> the hard
> way over a few decades to be mindful when adding these things. Strong
> portable
> eco-system level interfaces are our focus.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Issues with rtems_waf on Windows 10 with gccdeps module

[Robin Müller]

I also tried bld.path.find_or_declare('rtems.h') like in the supplied
example, but that did not work for me either.

Kind Regards
Robin

On Mon, 3 May 2021 at 14:31, Robin Müller  wrote:

> Hello Vijay,
>
> I tried bld.find_or_declare('rtems.h') but that did not work for me.
>
> Just out of curiosity, why was the patch not accepted? I did not find
> anything in the waf gitlab.
>
> Kind Regards
> Robin
>
> On Sat, 1 May 2021 at 20:29, Vijay Kumar Banerjee  wrote:
>
>> Hi Robin,
>>
>> On Fri, Apr 30, 2021 at 2:36 AM Robin Müller 
>> wrote:
>> >
>> > Issue can be reproduced by doing the quickstart application build on
>> Windows 10. The issue are backslashes in the absolute paths of the
>> dependency paths
>> > which were not stripped from dependency paths on Windows,
>> > causing waf to not recognize them as valid absolute paths. More
>> specifically, I printed the resulting dependency paths after stripping
>> >
>> >
>> C\:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/sparc-rtems6/erc32/lib/include/rtems/userenv.h
>> >
>> > The backslash at the start causes the issue.
>> > I was able to fix this with the following adaptations (gccdeps.py
>> starting line 108)
>> >
>> As I mentioned earlier, this patch will probably not be accepted in
>> upstream waf and it might not be a great idea to change it in the
>> RTEMS version of waf, since it'll cause issues in the future when we
>> try to sync up with the waf updates from upstream.
>>
>> Please try bld.find_or_declare from your wscript and see if that fixes
>> the header file not found issue. That is probably a cleaner solution
>> for now.
>>
>> > # Now join all the lines together
>> > txt = txt.replace('\\\n', '')
>> >
>> > val = txt.strip()
>> > val = [x.replace('\\ ', ' ') for x in re_splitter.split(val) if x]
>> > # This was added to replace backslashes which can cause issues on
>> Windows
>> > if os.name == 'nt':
>> >  val = [x.replace('C:\\', 'C:') for x in re_splitter.split(val) if
>> x]
>> > print(val)
>> > nodes = []
>> > bld = self.generator.bld
>> >
>> > I don't know whether this can have other evil side effects, but the waf
>> build works after that..
>> The possible evil side effects could be the issue with "\", as you
>> mentioned here. So better to avoid hacking it. :)
>>
>>
>> Best regards,
>> Vijay
>> >
>> > Kind Regards
>> > Robin
>> >
>> > On Fri, 30 Apr 2021 at 00:30, Vijay Kumar Banerjee 
>> wrote:
>> >>
>> >> Hi all,
>> >>
>> >>
>> >> On Thu, Apr 29, 2021 at 3:01 PM Chris Johns  wrote:
>> >> >
>> >> > On 30/4/21 5:01 am, Robin Müller wrote:
>> >> > > Yes that is the prefix. The rtems.h file is definitely located at
>> the location
>> >> > > in the warning and it works on older commit of rtems_waf (where
>> gccdeps.py is
>> >> > > not used).
>> >> > > I briefly looked through the gccdeps.py file and it is doing some
>> string
>> >> > > stripping operations.
>> >> > > Maybe that is the issue but I am not sure.
>> >> >
>> >> > Thank you for debugging this and I agree it look like something is a
>> little off
>> >> > in gccdeps.
>> >> >
>> >> Yes, I had a patch for that but I think there was a discussion
>> >> upstream between ita1024 and Chris and the conclusion was that the
>> >> patch won't be accepted. I can't find it right now but I could fix
>> >> this problem by using find_or_declare.
>> >>
>> >> @Robin: Please try to use the find function and see if it fixes.
>> >> Here's an example that worked quite nicely in rtems-examples:
>> >>
>> https://git.rtems.org/rtems-examples/tree/filesystem/fat_ramdisk/wscript#n34
>> >>
>> >>
>> >> Best regards,
>> >> Vijay
>> >>
>> >> > I will need to try and reproduce this to have a chance of finding
>> it. What
>> >> > happens if you remove gccdeps.py? Will that you get past this point?
>> >> >
>> >> > Chris
>> >> > ___
>> >> > devel mailing list
>> >> > devel@rtems.org
>> >> > http://lists.rtems.org/mailman/listinfo/devel
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Issues with rtems_waf on Windows 10 with gccdeps module

[Robin Müller]

Hello Vijay,

I tried bld.find_or_declare('rtems.h') but that did not work for me.

Just out of curiosity, why was the patch not accepted? I did not find
anything in the waf gitlab.

Kind Regards
Robin

On Sat, 1 May 2021 at 20:29, Vijay Kumar Banerjee  wrote:

> Hi Robin,
>
> On Fri, Apr 30, 2021 at 2:36 AM Robin Müller 
> wrote:
> >
> > Issue can be reproduced by doing the quickstart application build on
> Windows 10. The issue are backslashes in the absolute paths of the
> dependency paths
> > which were not stripped from dependency paths on Windows,
> > causing waf to not recognize them as valid absolute paths. More
> specifically, I printed the resulting dependency paths after stripping
> >
> >
> C\:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/sparc-rtems6/erc32/lib/include/rtems/userenv.h
> >
> > The backslash at the start causes the issue.
> > I was able to fix this with the following adaptations (gccdeps.py
> starting line 108)
> >
> As I mentioned earlier, this patch will probably not be accepted in
> upstream waf and it might not be a great idea to change it in the
> RTEMS version of waf, since it'll cause issues in the future when we
> try to sync up with the waf updates from upstream.
>
> Please try bld.find_or_declare from your wscript and see if that fixes
> the header file not found issue. That is probably a cleaner solution
> for now.
>
> > # Now join all the lines together
> > txt = txt.replace('\\\n', '')
> >
> > val = txt.strip()
> > val = [x.replace('\\ ', ' ') for x in re_splitter.split(val) if x]
> > # This was added to replace backslashes which can cause issues on Windows
> > if os.name == 'nt':
> >  val = [x.replace('C:\\', 'C:') for x in re_splitter.split(val) if x]
> > print(val)
> > nodes = []
> > bld = self.generator.bld
> >
> > I don't know whether this can have other evil side effects, but the waf
> build works after that..
> The possible evil side effects could be the issue with "\", as you
> mentioned here. So better to avoid hacking it. :)
>
>
> Best regards,
> Vijay
> >
> > Kind Regards
> > Robin
> >
> > On Fri, 30 Apr 2021 at 00:30, Vijay Kumar Banerjee 
> wrote:
> >>
> >> Hi all,
> >>
> >>
> >> On Thu, Apr 29, 2021 at 3:01 PM Chris Johns  wrote:
> >> >
> >> > On 30/4/21 5:01 am, Robin Müller wrote:
> >> > > Yes that is the prefix. The rtems.h file is definitely located at
> the location
> >> > > in the warning and it works on older commit of rtems_waf (where
> gccdeps.py is
> >> > > not used).
> >> > > I briefly looked through the gccdeps.py file and it is doing some
> string
> >> > > stripping operations.
> >> > > Maybe that is the issue but I am not sure.
> >> >
> >> > Thank you for debugging this and I agree it look like something is a
> little off
> >> > in gccdeps.
> >> >
> >> Yes, I had a patch for that but I think there was a discussion
> >> upstream between ita1024 and Chris and the conclusion was that the
> >> patch won't be accepted. I can't find it right now but I could fix
> >> this problem by using find_or_declare.
> >>
> >> @Robin: Please try to use the find function and see if it fixes.
> >> Here's an example that worked quite nicely in rtems-examples:
> >>
> https://git.rtems.org/rtems-examples/tree/filesystem/fat_ramdisk/wscript#n34
> >>
> >>
> >> Best regards,
> >> Vijay
> >>
> >> > I will need to try and reproduce this to have a chance of finding it.
> What
> >> > happens if you remove gccdeps.py? Will that you get past this point?
> >> >
> >> > Chris
> >> > ___
> >> > devel mailing list
> >> > devel@rtems.org
> >> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Issues with rtems_waf on Windows 10 with gccdeps module

[Robin Müller]

The "dirty solution" actually only works if the drive is named C, and maybe
the backslashes should not be there in the first place.
Maybe you already have dealt with this issue?

Kind Regards
Robin

On Fri, 30 Apr 2021 at 10:36, Robin Müller 
wrote:

> Issue can be reproduced by doing the quickstart application build on
> Windows 10. The issue are backslashes in the absolute paths of the
> dependency paths
> which were not stripped from dependency paths on Windows,
> causing waf to not recognize them as valid absolute paths. More
> specifically, I printed the resulting dependency paths after stripping
>
> C\:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/sparc-rtems6/erc32/lib/include/rtems/userenv.h
>
>
> The backslash at the start causes the issue.
> I was able to fix this with the following adaptations (gccdeps.py starting
> line 108)
>
> # Now join all the lines together
> txt = txt.replace('\\\n', '')
>
> val = txt.strip()
> val = [x.replace('\\ ', ' ') for x in re_splitter.split(val) if x]
> # This was added to replace backslashes which can cause issues on Windows
> if os.name == 'nt':
>  val = [x.replace('C:\\', 'C:') for x in re_splitter.split(val) if x]
> print(val)
> nodes = []
> bld = self.generator.bld
>
> I don't know whether this can have other evil side effects, but the waf
> build works after that..
>
> Kind Regards
> Robin
>
> On Fri, 30 Apr 2021 at 00:30, Vijay Kumar Banerjee 
> wrote:
>
>> Hi all,
>>
>>
>> On Thu, Apr 29, 2021 at 3:01 PM Chris Johns  wrote:
>> >
>> > On 30/4/21 5:01 am, Robin Müller wrote:
>> > > Yes that is the prefix. The rtems.h file is definitely located at the
>> location
>> > > in the warning and it works on older commit of rtems_waf (where
>> gccdeps.py is
>> > > not used).
>> > > I briefly looked through the gccdeps.py file and it is doing some
>> string
>> > > stripping operations.
>> > > Maybe that is the issue but I am not sure.
>> >
>> > Thank you for debugging this and I agree it look like something is a
>> little off
>> > in gccdeps.
>> >
>> Yes, I had a patch for that but I think there was a discussion
>> upstream between ita1024 and Chris and the conclusion was that the
>> patch won't be accepted. I can't find it right now but I could fix
>> this problem by using find_or_declare.
>>
>> @Robin: Please try to use the find function and see if it fixes.
>> Here's an example that worked quite nicely in rtems-examples:
>>
>> https://git.rtems.org/rtems-examples/tree/filesystem/fat_ramdisk/wscript#n34
>>
>>
>> Best regards,
>> Vijay
>>
>> > I will need to try and reproduce this to have a chance of finding it.
>> What
>> > happens if you remove gccdeps.py? Will that you get past this point?
>> >
>> > Chris
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Issues with rtems_waf on Windows 10 with gccdeps module

[Robin Müller]

Issue can be reproduced by doing the quickstart application build on
Windows 10. The issue are backslashes in the absolute paths of the
dependency paths
which were not stripped from dependency paths on Windows,
causing waf to not recognize them as valid absolute paths. More
specifically, I printed the resulting dependency paths after stripping

C\:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/sparc-rtems6/erc32/lib/include/rtems/userenv.h


The backslash at the start causes the issue.
I was able to fix this with the following adaptations (gccdeps.py starting
line 108)

# Now join all the lines together
txt = txt.replace('\\\n', '')

val = txt.strip()
val = [x.replace('\\ ', ' ') for x in re_splitter.split(val) if x]
# This was added to replace backslashes which can cause issues on Windows
if os.name == 'nt':
 val = [x.replace('C:\\', 'C:') for x in re_splitter.split(val) if x]
print(val)
nodes = []
bld = self.generator.bld

I don't know whether this can have other evil side effects, but the waf
build works after that..

Kind Regards
Robin

On Fri, 30 Apr 2021 at 00:30, Vijay Kumar Banerjee  wrote:

> Hi all,
>
>
> On Thu, Apr 29, 2021 at 3:01 PM Chris Johns  wrote:
> >
> > On 30/4/21 5:01 am, Robin Müller wrote:
> > > Yes that is the prefix. The rtems.h file is definitely located at the
> location
> > > in the warning and it works on older commit of rtems_waf (where
> gccdeps.py is
> > > not used).
> > > I briefly looked through the gccdeps.py file and it is doing some
> string
> > > stripping operations.
> > > Maybe that is the issue but I am not sure.
> >
> > Thank you for debugging this and I agree it look like something is a
> little off
> > in gccdeps.
> >
> Yes, I had a patch for that but I think there was a discussion
> upstream between ita1024 and Chris and the conclusion was that the
> patch won't be accepted. I can't find it right now but I could fix
> this problem by using find_or_declare.
>
> @Robin: Please try to use the find function and see if it fixes.
> Here's an example that worked quite nicely in rtems-examples:
>
> https://git.rtems.org/rtems-examples/tree/filesystem/fat_ramdisk/wscript#n34
>
>
> Best regards,
> Vijay
>
> > I will need to try and reproduce this to have a chance of finding it.
> What
> > happens if you remove gccdeps.py? Will that you get past this point?
> >
> > Chris
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Issues with rtems_waf on Windows 10 with gccdeps module

[Robin Müller]

Yes that is the prefix. The rtems.h file is definitely located at the
location in the warning and it works on older commit of rtems_waf (where
gccdeps.py is not used).
I briefly looked through the gccdeps.py file and it is doing some string
stripping operations.
Maybe that is the issue but I am not sure.

Kind Regards
Robin

On Thu, 29 Apr 2021 at 18:00, Gedare Bloom  wrote:

> On Thu, Apr 29, 2021 at 9:59 AM Gedare Bloom  wrote:
> >
> > On Thu, Apr 29, 2021 at 3:14 AM Robin Müller 
> wrote:
> > >
> > > I replaced the file in rtems_waf manually but it still throws the same
> error:
> > >
> > > [1/2] Compiling
> build/conf_check_995d7bdd1834199278843e9a51c37759/test.c
> > >
> > >
> ['C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe',
> '-mcpu=cypress',
> '-IC:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/sparc-rtems6/erc32/lib/include',
> '-MMD', '../test.c', '-c',
> '-oC:/Users/Robin/Documents/RTEMS/quickstart/build/conf_check_995d7bdd1834199278843e9a51c37759/testbuild/test.c.1.o']
> > > from C:/Users/Robin/Documents/RTEMS/quickstart: Test does not build:
> Traceback (most recent call last):
> > >   File
> "C:/Users/Robin/Documents/RTEMS/quickstart/waf3-2.0.22-1241519b19b496207abef1f72bbf61c2/waflib/Configure.py",
> line 335, in run_build
> > > bld.compile()
> > >   File
> "C:/Users/Robin/Documents/RTEMS/quickstart/waf3-2.0.22-1241519b19b496207abef1f72bbf61c2/waflib/Build.py",
> line 176, in compile
> > > raise Errors.BuildError(self.producer.error)
> > > waflib.Errors.BuildError: Build failed
> > > Traceback (most recent call last):
> > >   File
> "C:/Users/Robin/Documents/RTEMS/quickstart/waf3-2.0.22-1241519b19b496207abef1f72bbf61c2/waflib/Task.py",
> line 190, in process
> > > self.post_run()
> > >   File
> "C:/Users/Robin/Documents/RTEMS/quickstart/rtems_waf/gccdeps.py", line 140,
> in post_run
> > > raise ValueError('could not find %r for %r' % (path, self))
> > > ValueError: could not find ['C', ':', 'Users', 'Robin', 'Documents',
> 'RTEMS', 'rtems-tools', 'rtems', '6', 'sparc-rtems6', 'erc32', 'lib',
> 'include', 'rtems.h'] for
> > > {task 2179590063376: c test.c -> test.c.1.o}
> > >
> > It's looking for rtems.h in your rtems-tools directory and not in your
> > prefix. how did you configure waf?
> >
> Sorry, I should also ask, did you install rtems at
> C:\Users\Robin\Documents\RTEMS\rtems-tools/6
>
> > >
> > > no
> > > from C:/Users/Robin/Documents/RTEMS/quickstart: The configuration
> failed
> > >
> > > Kind Regards
> > > Robin
> > >
> > > On Wed, 28 Apr 2021 at 22:35, Chris Johns  wrote:
> > >>
> > >> On 28/4/21 7:59 pm, Robin Müller wrote:
> > >> > I think the following commit in rtems_waf breaks the waf build on
> Windows 10:
> > >> >
> > >> > commit 096372fc4504730e50b51b952ce47ca603b35f01
> > >> > Author: Chris Johns mailto:chr...@rtems.org>>
> > >> > Date:   Thu Oct 10 17:43:11 2019 +1100
> > >> >
> > >> > Use gccdeps for dependency scanning.
> > >> >
> > >> > I get the error that RTEMS is not able to find the rtems.h file in
> a certain
> > >> > directory when building the simple quick start application. The
> error does not
> > >> > occur on commits before that. I tried to run waf both in the
> WIndows CMD and in
> > >> > MinGW64, it is problematic for both.
> > >>
> > >> Could you please update your local version with ...
> > >>
> > >> https://gitlab.com/ita1024/waf/-/blob/master/waflib/extras/gccdeps.py
> > >>
> > >> ... and report back how that goes?
> > >>
> > >> Thanks
> > >> Chris
> > >
> > > ___
> > > devel mailing list
> > > devel@rtems.org
> > > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Issues with rtems_waf on Windows 10 with gccdeps module

[Robin Müller]

I replaced the file in rtems_waf manually but it still throws the same
error:

[1/2] Compiling build/conf_check_995d7bdd1834199278843e9a51c37759/test.c

['C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe',
'-mcpu=cypress',
'-IC:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/sparc-rtems6/erc32/lib/include',
'-MMD', '../test.c', '-c',
'-oC:/Users/Robin/Documents/RTEMS/quickstart/build/conf_check_995d7bdd1834199278843e9a51c37759/testbuild/test.c.1.o']
from C:/Users/Robin/Documents/RTEMS/quickstart: Test does not build:
Traceback (most recent call last):
  File
"C:/Users/Robin/Documents/RTEMS/quickstart/waf3-2.0.22-1241519b19b496207abef1f72bbf61c2/waflib/Configure.py",
line 335, in run_build
bld.compile()
  File
"C:/Users/Robin/Documents/RTEMS/quickstart/waf3-2.0.22-1241519b19b496207abef1f72bbf61c2/waflib/Build.py",
line 176, in compile
raise Errors.BuildError(self.producer.error)
waflib.Errors.BuildError: Build failed
Traceback (most recent call last):
  File
"C:/Users/Robin/Documents/RTEMS/quickstart/waf3-2.0.22-1241519b19b496207abef1f72bbf61c2/waflib/Task.py",
line 190, in process
self.post_run()
  File "C:/Users/Robin/Documents/RTEMS/quickstart/rtems_waf/gccdeps.py",
line 140, in post_run
raise ValueError('could not find %r for %r' % (path, self))
ValueError: could not find ['C', ':', 'Users', 'Robin', 'Documents',
'RTEMS', 'rtems-tools', 'rtems', '6', 'sparc-rtems6', 'erc32', 'lib',
'include', 'rtems.h'] for
{task 2179590063376: c test.c -> test.c.1.o}


no
from C:/Users/Robin/Documents/RTEMS/quickstart: The configuration failed

Kind Regards
Robin

On Wed, 28 Apr 2021 at 22:35, Chris Johns  wrote:

> On 28/4/21 7:59 pm, Robin Müller wrote:
> > I think the following commit in rtems_waf breaks the waf build on
> Windows 10:
> >
> > commit 096372fc4504730e50b51b952ce47ca603b35f01
> > Author: Chris Johns mailto:chr...@rtems.org>>
> > Date:   Thu Oct 10 17:43:11 2019 +1100
> >
> > Use gccdeps for dependency scanning.
> >
> > I get the error that RTEMS is not able to find the rtems.h file in a
> certain
> > directory when building the simple quick start application. The error
> does not
> > occur on commits before that. I tried to run waf both in the WIndows CMD
> and in
> > MinGW64, it is problematic for both.
>
> Could you please update your local version with ...
>
> https://gitlab.com/ita1024/waf/-/blob/master/waflib/extras/gccdeps.py
>
> ... and report back how that goes?
>
> Thanks
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] STM32 lwIP addition

[Robin Müller]

I integrated most of your points and added waf support. The lwIP support
can now be installed like the RTEMS BSP with waf so the PKG Config
generated by the BSP installation can be reused.  It puts some folders like
lwip / netif / compat into the include path, I hope this is not
problematic. I'll send the updated patch with the disclaimer that there are
still licensing issues to resolve after cleaning up a bit.

Kind Regards
Robin

On Wed, 28 Apr 2021 at 12:00, Robin Müller 
wrote:

> Small correction: I changed the ethernetif.c file to be usable by all
> three major APIs.
>
> Kind Regards
> Robin
>
> On Wed, 28 Apr 2021 at 11:55, Robin Müller 
> wrote:
>
>> Should I provide the changes for the code review as a separate patch or
>> should I squash them again?
>>
>> Using the upstream unchanged is tricky because the code was taken from
>> the examples and these examples are always targeted towards a specific API.
>> I changed the version to be usable by both APIs. I now applied the
>> __rtems__ preprocessor defines where applicable and moved the preprocessor
>> defines into a separate file.
>>
>> Kind Regards
>> Robin
>>
>> On Tue, 27 Apr 2021 at 22:21, Gedare Bloom  wrote:
>>
>>> On Tue, Apr 27, 2021 at 2:09 PM Gedare Bloom  wrote:
>>> >
>>> > On Tue, Apr 27, 2021 at 11:41 AM Robin Mueller
>>> >  wrote:
>>> > >
>>>
>>> I'm not sure what happened, it looks like my email client garbled the
>>> inline threaded reply. Hopefully my comments come through for you ok.
>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] STM32 lwIP addition

[Robin Müller]

Small correction: I changed the ethernetif.c file to be usable by all three
major APIs.

Kind Regards
Robin

On Wed, 28 Apr 2021 at 11:55, Robin Müller 
wrote:

> Should I provide the changes for the code review as a separate patch or
> should I squash them again?
>
> Using the upstream unchanged is tricky because the code was taken from the
> examples and these examples are always targeted towards a specific API.
> I changed the version to be usable by both APIs. I now applied the
> __rtems__ preprocessor defines where applicable and moved the preprocessor
> defines into a separate file.
>
> Kind Regards
> Robin
>
> On Tue, 27 Apr 2021 at 22:21, Gedare Bloom  wrote:
>
>> On Tue, Apr 27, 2021 at 2:09 PM Gedare Bloom  wrote:
>> >
>> > On Tue, Apr 27, 2021 at 11:41 AM Robin Mueller
>> >  wrote:
>> > >
>>
>> I'm not sure what happened, it looks like my email client garbled the
>> inline threaded reply. Hopefully my comments come through for you ok.
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Issues with rtems_waf on Windows 10 with gccdeps module

[Robin Müller]

Hi,

I think the following commit in rtems_waf breaks the waf build on Windows
10:

commit 096372fc4504730e50b51b952ce47ca603b35f01
Author: Chris Johns 
Date:   Thu Oct 10 17:43:11 2019 +1100

Use gccdeps for dependency scanning.

I get the error that RTEMS is not able to find the rtems.h file in a
certain directory when building the simple quick start application. The
error does not occur on commits before that. I tried to run waf both in the
WIndows CMD and in MinGW64, it is problematic for both.

Kind Regards
Robin
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] STM32 lwIP addition

[Robin Müller]

Should I provide the changes for the code review as a separate patch or
should I squash them again?

Using the upstream unchanged is tricky because the code was taken from the
examples and these examples are always targeted towards a specific API.
I changed the version to be usable by both APIs. I now applied the
__rtems__ preprocessor defines where applicable and moved the preprocessor
defines into a separate file.

Kind Regards
Robin

On Tue, 27 Apr 2021 at 22:21, Gedare Bloom  wrote:

> On Tue, Apr 27, 2021 at 2:09 PM Gedare Bloom  wrote:
> >
> > On Tue, Apr 27, 2021 at 11:41 AM Robin Mueller
> >  wrote:
> > >
>
> I'm not sure what happened, it looks like my email client garbled the
> inline threaded reply. Hopefully my comments come through for you ok.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] STM32 lwIP addition and CMake support

[Robin Müller]

Almost all files in the Cube repository have the new BSD3 license, but some
application and example files still appear to be licensed under SLA0044. I
created an
issue in the STM32H7 Cube repository (
https://github.com/STMicroelectronics/STM32CubeH7/issues/139) , and the
Cube developers seem to track the issue list quite regularly. Hopefully
there will be an answer soon..

Kind Regards
Robin

On Tue, 27 Apr 2021 at 18:58, Robin Müller 
wrote:

> Okay, I can understand that you'd like to have one build system only. We
> had the same issue with a former Makefile build system and the new CMake
> system and decided to make the former system obsolete
> because maintaining both of them would be too much work.
>
> First thing I  can do is that I split up the patch and extract the CMake
> specific files. Concerning a clean solution to allow users to use CMake
> without introducing files like CMakeLists.txt,
> I am not sure right now. Extracting the information required by CMake
> would again require scripts to export source files and include paths.
> The simplest solution would still be a CMakeLists.txt file in the root
> here which simply sets source files and include paths in the parent scope.
> which would again be another form of maintenance burden because it still
> needs to figure out which port sources to add etc.
> The rtems-cmake support is able to live without CMakeLists.txt files in
> RTEMS because the BSP is already compiled at that point. Doing something
> similar
> would require a similar process like done in the BSP where rtems-lwip is
> compiled as a static library for a specific BSP,
> installed somewhere and then an application can link against it while also
> including the headers.
> For the RTEMS BSP this is done through provided PKG Config files. It just
> seems like a lot of effort for a comparatively small library.
> Maybe someone has a better idea?
>
> I am also not sure if users who are used to CMake would not just do the
> same thing I did if there are no CMakeLists.txt files present and the
> library/repository is simple enough:
> Add those themselves in the project root or throughout the repository fork
> structure. But it's your call of course. Maybe some more (user) opinions
> would help as well.
>
> Kind Regards
> Robin
>
> On Tue, 27 Apr 2021 at 18:27, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 27/04/2021 17:23, Gedare Bloom wrote:
>>
>> >> I can try to get a better license for the files taken from the
>> example. If that doesn't work out, I guess some scripting will be
>> necessary. The problem is that these files were modified
>> >> to be usable for RTEMS..
>> >>
>> > Thanks. It might require iterating with the vendor. From past
>> > experience, that can take months or years, or never happen. I think we
>> > are generally interested in supporting the option for users to build
>> > such proprietary drivers. After all, a user might be creating their
>> > own drivers too. So, from a technical perspective, how we manage that
>> > integration is a welcome discussion. We just need to be careful that
>> > we don't try to integrate it at the source code level. I hope that
>> > makes sense.
>>
>> STMicroelectronics fixed their license at some point. The newer code has
>> this license:
>>
>> https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/include/stm32h7xx.h
>>
>> Maybe you can import the code from a more recent distribution.
>>
>> --
>> embedded brains GmbH
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.hu...@embedded-brains.de
>> phone: +49-89-18 94 741 - 16
>> fax:   +49-89-18 94 741 - 08
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRB 157899
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] STM32 lwIP addition and CMake support

[Robin Müller]

Okay, I can understand that you'd like to have one build system only. We
had the same issue with a former Makefile build system and the new CMake
system and decided to make the former system obsolete
because maintaining both of them would be too much work.

First thing I  can do is that I split up the patch and extract the CMake
specific files. Concerning a clean solution to allow users to use CMake
without introducing files like CMakeLists.txt,
I am not sure right now. Extracting the information required by CMake would
again require scripts to export source files and include paths.
The simplest solution would still be a CMakeLists.txt file in the root here
which simply sets source files and include paths in the parent scope.
which would again be another form of maintenance burden because it still
needs to figure out which port sources to add etc.
The rtems-cmake support is able to live without CMakeLists.txt files in
RTEMS because the BSP is already compiled at that point. Doing something
similar
would require a similar process like done in the BSP where rtems-lwip is
compiled as a static library for a specific BSP,
installed somewhere and then an application can link against it while also
including the headers.
For the RTEMS BSP this is done through provided PKG Config files. It just
seems like a lot of effort for a comparatively small library.
Maybe someone has a better idea?

I am also not sure if users who are used to CMake would not just do the
same thing I did if there are no CMakeLists.txt files present and the
library/repository is simple enough:
Add those themselves in the project root or throughout the repository fork
structure. But it's your call of course. Maybe some more (user) opinions
would help as well.

Kind Regards
Robin

On Tue, 27 Apr 2021 at 18:27, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 27/04/2021 17:23, Gedare Bloom wrote:
>
> >> I can try to get a better license for the files taken from the example.
> If that doesn't work out, I guess some scripting will be necessary. The
> problem is that these files were modified
> >> to be usable for RTEMS..
> >>
> > Thanks. It might require iterating with the vendor. From past
> > experience, that can take months or years, or never happen. I think we
> > are generally interested in supporting the option for users to build
> > such proprietary drivers. After all, a user might be creating their
> > own drivers too. So, from a technical perspective, how we manage that
> > integration is a welcome discussion. We just need to be careful that
> > we don't try to integrate it at the source code level. I hope that
> > makes sense.
>
> STMicroelectronics fixed their license at some point. The newer code has
> this license:
>
> https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/include/stm32h7xx.h
>
> Maybe you can import the code from a more recent distribution.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Patch attempt two to avoid nameclash of PAGESIZE define

[Robin Müller]

Can you try

git apply --reject --whitespace=fix mychanges.patch

taken from
https://stackoverflow.com/questions/4770177/git-patch-does-not-apply .
This worked for me

Kind Regards
Robin

On Fri, 23 Apr 2021 at 12:32, Robin Müller 
wrote:

> Can you try
>
> git apply --reject --whitespace=fix mychanges.patch
>
> taken from
> https://stackoverflow.com/questions/4770177/git-patch-does-not-apply .
> This worked for me
>
> Kind Regards
> Robin
>
> On Fri, 23 Apr 2021 at 11:42, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 21/04/2021 10:55, Robin Mueller wrote:
>>
>> > This commit excludes the PAGESIZE legacy define
>> > because there is a nameclash with a define of the same name
>> > coming from the RTEMS header limits.h.
>>
>> I am still not able to apply this patch.
>>
>> git am \[PATCH\]\ Patch\ attempt\ two\ to\ avoid\ nameclash\ of\
>> PAGESIZE\ define.eml
>> Applying: Patch attempt two to avoid nameclash of PAGESIZE define
>> error: patch failed: bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h:31
>> error: bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h: patch does
>> not apply
>> Patch failed at 0001 Patch attempt two to avoid nameclash of PAGESIZE
>> define
>> hint: Use 'git am --show-current-patch=diff' to see the failed patch
>> When you have resolved this problem, run "git am --continue".
>> If you prefer to skip this patch, run "git am --skip" instead.
>> To restore the original branch and stop patching, run "git am --abort".
>>
>> Maybe send the patch as an attachment.
>>
>> --
>> embedded brains GmbH
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.hu...@embedded-brains.de
>> phone: +49-89-18 94 741 - 16
>> fax:   +49-89-18 94 741 - 08
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRB 157899
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Correct NUCLEO-H743ZI Ethernet Pins

[Robin Müller]

I sent a follow-up patch.

Kind Regards
Robin

On Fri, 23 Apr 2021 at 09:45, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 23/04/2021 09:44, Robin Müller wrote:
>
> >
> > How can i specify a define to only be generated for a certain variant
> > and nothing for default?
> Yes, just use "default: null".
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 3/4] Additional define for stmh32xx_hal_uart.h

[Robin Müller]

Ping :)

On Mon, 12 Apr 2021 at 11:56, Robin.Mueller 
wrote:

> The DMA include was missing and could lead to compilation
> errors for certain cases.
> ---
>  bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h
> b/bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h
> index e9fecc4aa0..b171f7dac7 100644
> --- a/bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h
> +++ b/bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h
> @@ -27,6 +27,7 @@ extern "C" {
>
>  /* Includes
> --*/
>  #include "stm32h7xx_hal_def.h"
> +#include "stm32h7xx_hal_dma.h"
>
>  /** @addtogroup STM32H7xx_HAL_Driver
>* @{
> --
> 2.25.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Correct NUCLEO-H743ZI Ethernet Pins

[Robin Müller]

Hi Sebastian,

How can i specify a define to only be generated for a certain variant and
nothing for default?

Kind Regards
Robin

On Thu, 22 Apr 2021 at 19:56, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
> On 22/04/2021 19:35, Robin Mueller wrote:
> >
>
> Please change this to (add an option for STM32H7_ETH_GPIOB_PINS)
>
> #ifdef STM32H7_ETH_GPIOB_PINS
>
> > +static const stm32h7_gpio_config gpiob = {
> > +  .regs = GPIOB,
> > +  .config = {
> > +.Pin = GPIO_PIN_13,
> > +.Mode = GPIO_MODE_AF_PP,
> > +.Pull = GPIO_NOPULL,
> > +.Speed = GPIO_SPEED_FREQ_LOW,
> > +.Alternate = GPIO_AF11_ETH
> > +  }
> > +};
> > +
> >   void
> >   HAL_ETH_MspInit(ETH_HandleTypeDef *heth)
> >   {
> > @@ -73,4 +86,7 @@ HAL_ETH_MspInit(ETH_HandleTypeDef *heth)
> > stm32h7_gpio_init();
> > stm32h7_gpio_init();
> > stm32h7_gpio_init();
> > +#if RTEMS_BSP == nucleo-h743zi
>
> #ifdef STM32H7_ETH_GPIOB_PINS
>
> There should be not checks which use the BSP name.
>
> > +  stm32h7_gpio_init();
> > +#endif
> >   }
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: STM32H7 UART pins Update

[Robin Müller]

I think the pins for the UART 3 still need to be adapted. Everything can be
simplified because the pins are the same after all with GPIOD PIN 8 and
PIN9 for both variants.
I sent a patch which configures the ETH correctly for the Nucleo BSP
variant.

Kind Regards
Robin

On Thu, 22 Apr 2021 at 19:04, Robin Müller 
wrote:

> Thanks :-) I was able to omit the HAL_ETH_MspInit override in my lwIP code
> now.
>
> Kind Regards
> Robin
>
> On Thu, 22 Apr 2021 at 15:32, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello Robin,
>>
>> I hope it is now fixed. For the Ethernet pin customization, you can use
>> the same approach.
>>
>> --
>> embedded brains GmbH
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.hu...@embedded-brains.de
>> phone: +49-89-18 94 741 - 16
>> fax:   +49-89-18 94 741 - 08
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRB 157899
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: STM32H7 UART pins Update

[Robin Müller]

Thanks :-) I was able to omit the HAL_ETH_MspInit override in my lwIP code
now.

Kind Regards
Robin

On Thu, 22 Apr 2021 at 15:32, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Robin,
>
> I hope it is now fixed. For the Ethernet pin customization, you can use
> the same approach.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: STM32H7 UART pins Update

[Robin Müller]

Small corrections: I was always referring to GPIOB PIN9 and PIN10 of course.

Kind Regards
Robin

On Thu, 22 Apr 2021 at 15:20, Robin Müller 
wrote:

> Hi Sebastian
>
> You recently updated the UART pins configuration, allowing different
> variants.
> I recently checked the CubeH7 library about pin differences between the
> NUCLEO and the STM32H7 after finding out about the pin differences for the
> Ethernet module and I found out some weird things. I checked the datasheet
> which specifies that GPIOD PIN8 and PIN9 are the UART3 pins used for the
> console / print output.
>
> So basically, the default implementation is now okay for the Nucleo as
> well. I checked bspopts.h in the RTEMS tools installation path, and the
> default values GPIOD and PIN8 and PIN9 were specified here. So basically,
> the build variant specifications GPIOB PIN 8 and PIN 9 are not used.
>
> This was because of stray default-by-variant: [] in the respective BSP
> files. I then tested GPIOB PIN8 and PIN 9 by setting them in default: and
> those don't work as expected.
>
> If GPIOD PIN 8 and PIN 9 work for the board variant you used then these
> option specifications are obsolete now and that pin definition works for
> the NUCLEO and the board you used. The former implementation used GPIOB PIN
> 9 and PIN 10 (
> https://git.rtems.org/rtems/commit/bsps/arm/stm32h7/console/console-usart3-cfg.c?id=6600585fc8e5fa299bf1ca1e0856d44b23c195cf)
> which is the reason they were not working for the NUCLEO variant.
>
> Kind Regards
> Robin
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

STM32H7 UART pins Update

[Robin Müller]

Hi Sebastian

You recently updated the UART pins configuration, allowing different
variants.
I recently checked the CubeH7 library about pin differences between the
NUCLEO and the STM32H7 after finding out about the pin differences for the
Ethernet module and I found out some weird things. I checked the datasheet
which specifies that GPIOD PIN8 and PIN9 are the UART3 pins used for the
console / print output.

So basically, the default implementation is now okay for the Nucleo as
well. I checked bspopts.h in the RTEMS tools installation path, and the
default values GPIOD and PIN8 and PIN9 were specified here. So basically,
the build variant specifications GPIOB PIN 8 and PIN 9 are not used.

This was because of stray default-by-variant: [] in the respective BSP
files. I then tested GPIOB PIN8 and PIN 9 by setting them in default: and
those don't work as expected.

If GPIOD PIN 8 and PIN 9 work for the board variant you used then these
option specifications are obsolete now and that pin definition works for
the NUCLEO and the board you used. The former implementation used GPIOB PIN
9 and PIN 10 (
https://git.rtems.org/rtems/commit/bsps/arm/stm32h7/console/console-usart3-cfg.c?id=6600585fc8e5fa299bf1ca1e0856d44b23c195cf)
which is the reason they were not working for the NUCLEO variant.

Kind Regards
Robin
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Updated tick implementation for HAL_GetTick

[Robin Müller]

It worked for me. Can you specify that? The overflow check would have to be
implemented by an upper layer, right?
I can adapt my former patch using the tick solution to do the
multiplication first if this is better.

Kind Regards
Robin

On Wed, 21 Apr 2021 at 20:25, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 21/04/2021 19:30, Sebastian Huber wrote:
>
> > On 21/04/2021 11:00, Robin Müller wrote:
> >
> >> Okay, good to know. Do you think it's okay if my simpler
> >> implementation is used completely?
> >> Another option would be to use the simple function for the oscillator
> >> init functions (sth like a private HAL_GetTick_OscInit function).
> >> But maybe you have a better idea.
> > If the ticks base solution works it is all right. The HAL_GetTick() -
> > HAL_GetTick() (e.g. tick 0xabcd - tick 0x123) should return a
> > correct interval during a tick overflow.
> It should be 0x123 - 0xabcd.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

[Robin Müller]

Actually, the configurations for GPIOA and GPIOC are completely overlapping
and could be reused to the NUCLEO BSP.

Kind Regards
Robin

On Wed, 21 Apr 2021 at 11:23, Robin Müller 
wrote:

> I'm sorry I have to dig this up and bother you again but it's something
> that i spotted when browsing the STM CubeH7 code and which is a similar
> problem to the UART3 issue and might affect NUCLEO users who would like to
> use libbsd networking.
> Similarly to the UART3, the pins for the ETH initialization seem to be
> different for the NUCLEO device.
>
> More specifically, the code for the NUCLEO-H743ZI looks like this:
>
>   /* Configure PA1, PA2 and PA7 */
>   GPIO_InitStructure.Speed = GPIO_SPEED_FREQ_HIGH;
>   GPIO_InitStructure.Mode = GPIO_MODE_AF_PP;
>   GPIO_InitStructure.Pull = GPIO_NOPULL;
>   GPIO_InitStructure.Alternate = GPIO_AF11_ETH;
>   GPIO_InitStructure.Pin = GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_7;
>   HAL_GPIO_Init(GPIOA, _InitStructure);
>
>   /* Configure PB13 */
>   GPIO_InitStructure.Pin = GPIO_PIN_13;
>   HAL_GPIO_Init(GPIOB, _InitStructure);
>
>   /* Configure PC1, PC4 and PC5 */
>   GPIO_InitStructure.Pin = GPIO_PIN_1 | GPIO_PIN_4 | GPIO_PIN_5;
>   HAL_GPIO_Init(GPIOC, _InitStructure);
>
>   /* Configure PG2, PG11, PG13 and PG14 */
>   GPIO_InitStructure.Pin =  GPIO_PIN_2 | GPIO_PIN_11 | GPIO_PIN_13;
>   HAL_GPIO_Init(GPIOG, _InitStructure);
>
> So instead of GPIOA 1,2 and 7, GPIOG 11, 12 and 13 and GPIOC 1, 4, 5, the
> pins above are used.
>
> KInd Regards
> Robin
>
> On Mon, 12 Apr 2021 at 11:23, Robin Müller 
> wrote:
>
>> I can split up the rest of the patch.
>> I would rename STM32H7_ADD_LWIP from the BSP configuration to
>> RTEMS_USE_LWIP as a more generic variant which could be reused for other
>> BSPs if that is okay.
>>
>> Kind Regards
>> Robin
>>
>> On Mon, 12 Apr 2021 at 10:46, Robin Müller 
>> wrote:
>>
>>> The variant worked without issues.
>>>
>>> Kind Regards
>>> Robin
>>>
>>> On Fri, 9 Apr 2021 at 09:21, Robin Müller 
>>> wrote:
>>>
>>>> Hello Sebastian,
>>>>
>>>> I will have a look at it soon.
>>>>
>>>> Kind Regards
>>>> Robin
>>>>
>>>> On Tue, 6 Apr 2021 at 10:01, Sebastian Huber <
>>>> sebastian.hu...@embedded-brains.de> wrote:
>>>>
>>>>> Hello Robin,
>>>>>
>>>>> sorry for the delay. I checked in some patches to add a
>>>>> "arm/nucleo-h743zi" BSP variant. Could you please check if this
>>>>> variant
>>>>> works on the board.
>>>>>
>>>>> Could you please split up the remaining pieces of the patch into
>>>>> separate commits.
>>>>>
>>>>> --
>>>>> embedded brains GmbH
>>>>> Herr Sebastian HUBER
>>>>> Dornierstr. 4
>>>>> 82178 Puchheim
>>>>> Germany
>>>>> email: sebastian.hu...@embedded-brains.de
>>>>> phone: +49-89-18 94 741 - 16
>>>>> fax:   +49-89-18 94 741 - 08
>>>>>
>>>>> Registergericht: Amtsgericht München
>>>>> Registernummer: HRB 157899
>>>>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>>>>> Unsere Datenschutzerklärung finden Sie hier:
>>>>> https://embedded-brains.de/datenschutzerklaerung/
>>>>>
>>>>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

[Robin Müller]

I'm sorry I have to dig this up and bother you again but it's something
that i spotted when browsing the STM CubeH7 code and which is a similar
problem to the UART3 issue and might affect NUCLEO users who would like to
use libbsd networking.
Similarly to the UART3, the pins for the ETH initialization seem to be
different for the NUCLEO device.

More specifically, the code for the NUCLEO-H743ZI looks like this:

  /* Configure PA1, PA2 and PA7 */
  GPIO_InitStructure.Speed = GPIO_SPEED_FREQ_HIGH;
  GPIO_InitStructure.Mode = GPIO_MODE_AF_PP;
  GPIO_InitStructure.Pull = GPIO_NOPULL;
  GPIO_InitStructure.Alternate = GPIO_AF11_ETH;
  GPIO_InitStructure.Pin = GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_7;
  HAL_GPIO_Init(GPIOA, _InitStructure);

  /* Configure PB13 */
  GPIO_InitStructure.Pin = GPIO_PIN_13;
  HAL_GPIO_Init(GPIOB, _InitStructure);

  /* Configure PC1, PC4 and PC5 */
  GPIO_InitStructure.Pin = GPIO_PIN_1 | GPIO_PIN_4 | GPIO_PIN_5;
  HAL_GPIO_Init(GPIOC, _InitStructure);

  /* Configure PG2, PG11, PG13 and PG14 */
  GPIO_InitStructure.Pin =  GPIO_PIN_2 | GPIO_PIN_11 | GPIO_PIN_13;
  HAL_GPIO_Init(GPIOG, _InitStructure);

So instead of GPIOA 1,2 and 7, GPIOG 11, 12 and 13 and GPIOC 1, 4, 5, the
pins above are used.

KInd Regards
Robin

On Mon, 12 Apr 2021 at 11:23, Robin Müller 
wrote:

> I can split up the rest of the patch.
> I would rename STM32H7_ADD_LWIP from the BSP configuration to
> RTEMS_USE_LWIP as a more generic variant which could be reused for other
> BSPs if that is okay.
>
> Kind Regards
> Robin
>
> On Mon, 12 Apr 2021 at 10:46, Robin Müller 
> wrote:
>
>> The variant worked without issues.
>>
>> Kind Regards
>> Robin
>>
>> On Fri, 9 Apr 2021 at 09:21, Robin Müller 
>> wrote:
>>
>>> Hello Sebastian,
>>>
>>> I will have a look at it soon.
>>>
>>> Kind Regards
>>> Robin
>>>
>>> On Tue, 6 Apr 2021 at 10:01, Sebastian Huber <
>>> sebastian.hu...@embedded-brains.de> wrote:
>>>
>>>> Hello Robin,
>>>>
>>>> sorry for the delay. I checked in some patches to add a
>>>> "arm/nucleo-h743zi" BSP variant. Could you please check if this variant
>>>> works on the board.
>>>>
>>>> Could you please split up the remaining pieces of the patch into
>>>> separate commits.
>>>>
>>>> --
>>>> embedded brains GmbH
>>>> Herr Sebastian HUBER
>>>> Dornierstr. 4
>>>> 82178 Puchheim
>>>> Germany
>>>> email: sebastian.hu...@embedded-brains.de
>>>> phone: +49-89-18 94 741 - 16
>>>> fax:   +49-89-18 94 741 - 08
>>>>
>>>> Registergericht: Amtsgericht München
>>>> Registernummer: HRB 157899
>>>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>>>> Unsere Datenschutzerklärung finden Sie hier:
>>>> https://embedded-brains.de/datenschutzerklaerung/
>>>>
>>>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Updated tick implementation for HAL_GetTick

[Robin Müller]

Okay, good to know. Do you think it's okay if my simpler implementation is
used completely?
Another option would be to use the simple function for the oscillator init
functions (sth like a private HAL_GetTick_OscInit function).
But maybe you have a better idea.

Kind Regards
Robin


On Tue, 20 Apr 2021 at 19:48, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 20/04/2021 19:45, Robin Müller wrote:
>
> > Hmm, do you have an idea how to fix this cleanly? Was this the reason
> > the implementation returned 0?
> Yes.
> > This was not an issue with the other implementation:
> >
> > (rtems_clock_get_ticks_since_boot() * 1000) /
> > rtems_clock_get_ticks_per_second();
>
> This function is much simpler. It just reads a global variable. During
> startup the time is frozen.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Patch attempt two to avoid nameclash of PAGESIZE define

[Robin Müller]

I just resent the patch and I hope this can be applied properly.

Like already mentioned, when loading this file in Ubuntu 20.04, something
was done to the line endings automatically..
But maybe this is the reason the patch could not be applied before, because
I had the same issue of not being able to apply my patch file.

Kind Regards
Robin

On Wed, 21 Apr 2021 at 10:55, Robin Mueller 
wrote:

> This commit excludes the PAGESIZE legacy define
> because there is a nameclash with a define of the same name
> coming from the RTEMS header limits.h.
> ---
>  .../stm32h7/include/Legacy/stm32_hal_legacy.h | 172 +-
>  1 file changed, 88 insertions(+), 84 deletions(-)
>
> diff --git a/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
> b/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
> index c311c1618e..804a4c87da 100644
> --- a/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
> +++ b/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
> @@ -31,7 +31,7 @@
>  /* Exported constants
> */
>
>  /** @defgroup HAL_AES_Aliased_Defines HAL CRYP Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>  #define AES_FLAG_RDERR  CRYP_FLAG_RDERR
> @@ -45,7 +45,7 @@
>*/
>
>  /** @defgroup HAL_ADC_Aliased_Defines HAL ADC Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>  #define ADC_RESOLUTION12b   ADC_RESOLUTION_12B
> @@ -105,7 +105,7 @@
>*/
>
>  /** @defgroup HAL_CEC_Aliased_Defines HAL CEC Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -116,7 +116,7 @@
>*/
>
>  /** @defgroup HAL_COMP_Aliased_Defines HAL COMP Aliased Defines
> maintained for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>  #define COMP_WINDOWMODE_DISABLED   COMP_WINDOWMODE_DISABLE
> @@ -208,7 +208,7 @@
>*/
>
>  /** @defgroup HAL_CORTEX_Aliased_Defines HAL CORTEX Aliased Defines
> maintained for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>  #define __HAL_CORTEX_SYSTICKCLK_CONFIG HAL_SYSTICK_CLKSourceConfig
> @@ -217,7 +217,7 @@
>*/
>
>  /** @defgroup HAL_CRC_Aliased_Defines HAL CRC Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -229,7 +229,7 @@
>*/
>
>  /** @defgroup HAL_DAC_Aliased_Defines HAL DAC Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -258,7 +258,7 @@
>*/
>
>  /** @defgroup HAL_DMA_Aliased_Defines HAL DMA Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>  #define HAL_REMAPDMA_ADC_DMA_CH2DMA_REMAP_ADC_DMA_CH2
> @@ -392,7 +392,7 @@
>*/
>
>  /** @defgroup HAL_FLASH_Aliased_Defines HAL FLASH Aliased Defines
> maintained for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -420,7 +420,11 @@
>  #define TYPEPROGRAMDATA_FASTBYTE  FLASH_TYPEPROGRAMDATA_FASTBYTE
>  #define TYPEPROGRAMDATA_FASTHALFWORD  FLASH_TYPEPROGRAMDATA_FASTHALFWORD
>  #define TYPEPROGRAMDATA_FASTWORD  FLASH_TYPEPROGRAMDATA_FASTWORD
> +#ifndef __rtems__
> +/* Commented out for the RTEMS BSP because there can be nameclashes with
> another
> +similar defininition in limits.h */
>  #define PAGESIZE  FLASH_PAGE_SIZE
> +#endif /* __rtems__ */
>  #define TYPEPROGRAM_FASTBYTE  FLASH_TYPEPROGRAM_BYTE
>  #define TYPEPROGRAM_FASTHALFWORD  FLASH_TYPEPROGRAM_HALFWORD
>  #define TYPEPROGRAM_FASTWORD  FLASH_TYPEPROGRAM_WORD
> @@ -490,7 +494,7 @@
>*/
>
>  /** @defgroup HAL_JPEG_Aliased_Macros HAL JPEG Aliased Macros maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -508,7 +512,7 @@
>*/
>
>  /** @defgroup HAL_SYSCFG_Aliased_Defines HAL SYSCFG Aliased Defines
> maintained for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -534,7 +538,7 @@
>
>
>  /** @defgroup LL_FMC_Aliased_Defines LL FMC Aliased Defines maintained
> for compatibility purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>  #if defined(STM32L4) || defined(STM32F7) || defined(STM32H7) ||
> defined(STM32G4)
> @@ -553,7 +557,7 @@
>*/
>
>  /** @defgroup LL_FSMC_Aliased_Defines LL FSMC Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/

Re: [PATCH] Patch to avoid nameclash of PAGESIZE define

[Robin Müller]

Does this one work? For some reason the full header was not included..

Kind Regards
Robin

On Tue, 20 Apr 2021 at 20:11, Robin Mueller 
wrote:

> This commit excludes the PAGESIZE legacy define
> because there is a nameclash with a define of the same name
> coming from the RTEMS header limits.h.
>
> All other changes come from loading the file from a Unix system.
> ---
>  .../stm32h7/include/Legacy/stm32_hal_legacy.h | 172 +-
>  1 file changed, 88 insertions(+), 84 deletions(-)
>
> diff --git a/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
> b/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
> index c311c1618e..804a4c87da 100644
> --- a/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
> +++ b/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
> @@ -31,7 +31,7 @@
>  /* Exported constants
> */
>
>  /** @defgroup HAL_AES_Aliased_Defines HAL CRYP Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>  #define AES_FLAG_RDERR  CRYP_FLAG_RDERR
> @@ -45,7 +45,7 @@
>*/
>
>  /** @defgroup HAL_ADC_Aliased_Defines HAL ADC Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>  #define ADC_RESOLUTION12b   ADC_RESOLUTION_12B
> @@ -105,7 +105,7 @@
>*/
>
>  /** @defgroup HAL_CEC_Aliased_Defines HAL CEC Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -116,7 +116,7 @@
>*/
>
>  /** @defgroup HAL_COMP_Aliased_Defines HAL COMP Aliased Defines
> maintained for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>  #define COMP_WINDOWMODE_DISABLED   COMP_WINDOWMODE_DISABLE
> @@ -208,7 +208,7 @@
>*/
>
>  /** @defgroup HAL_CORTEX_Aliased_Defines HAL CORTEX Aliased Defines
> maintained for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>  #define __HAL_CORTEX_SYSTICKCLK_CONFIG HAL_SYSTICK_CLKSourceConfig
> @@ -217,7 +217,7 @@
>*/
>
>  /** @defgroup HAL_CRC_Aliased_Defines HAL CRC Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -229,7 +229,7 @@
>*/
>
>  /** @defgroup HAL_DAC_Aliased_Defines HAL DAC Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -258,7 +258,7 @@
>*/
>
>  /** @defgroup HAL_DMA_Aliased_Defines HAL DMA Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>  #define HAL_REMAPDMA_ADC_DMA_CH2DMA_REMAP_ADC_DMA_CH2
> @@ -392,7 +392,7 @@
>*/
>
>  /** @defgroup HAL_FLASH_Aliased_Defines HAL FLASH Aliased Defines
> maintained for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -420,7 +420,11 @@
>  #define TYPEPROGRAMDATA_FASTBYTE  FLASH_TYPEPROGRAMDATA_FASTBYTE
>  #define TYPEPROGRAMDATA_FASTHALFWORD  FLASH_TYPEPROGRAMDATA_FASTHALFWORD
>  #define TYPEPROGRAMDATA_FASTWORD  FLASH_TYPEPROGRAMDATA_FASTWORD
> +#ifndef __rtems__
> +/* Commented out for the RTEMS BSP because there can be nameclashes with
> another
> +similar defininition in limits.h */
>  #define PAGESIZE  FLASH_PAGE_SIZE
> +#endif /* __rtems__ */
>  #define TYPEPROGRAM_FASTBYTE  FLASH_TYPEPROGRAM_BYTE
>  #define TYPEPROGRAM_FASTHALFWORD  FLASH_TYPEPROGRAM_HALFWORD
>  #define TYPEPROGRAM_FASTWORD  FLASH_TYPEPROGRAM_WORD
> @@ -490,7 +494,7 @@
>*/
>
>  /** @defgroup HAL_JPEG_Aliased_Macros HAL JPEG Aliased Macros maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -508,7 +512,7 @@
>*/
>
>  /** @defgroup HAL_SYSCFG_Aliased_Defines HAL SYSCFG Aliased Defines
> maintained for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -534,7 +538,7 @@
>
>
>  /** @defgroup LL_FMC_Aliased_Defines LL FMC Aliased Defines maintained
> for compatibility purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>  #if defined(STM32L4) || defined(STM32F7) || defined(STM32H7) ||
> defined(STM32G4)
> @@ -553,7 +557,7 @@
>*/
>
>  /** @defgroup LL_FSMC_Aliased_Defines LL FSMC Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -564,7 +568,7 @@
>*/
>
>  /** @defgroup HAL_GPIO_Aliased_Macros HAL GPIO Aliased Macros maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup 

Re: [PATCH] Updated tick implementation for HAL_GetTick

[Robin Müller]

Hmm, do you have an idea how to fix this cleanly? Was this the reason the
implementation returned 0?
This was not an issue with the other implementation:

(rtems_clock_get_ticks_since_boot() * 1000) /
rtems_clock_get_ticks_per_second();

Kind Regards
Robin

On Tue, 20 Apr 2021 at 19:31, Robin Müller 
wrote:

> Yes, I tried to switch oscillator and clock init in the start hook, but
> that did not appear to solve the issue.
>
> Kind Regards
> Robin
>
> On Tue, 20 Apr 2021 at 19:24, Robin Müller 
> wrote:
>
>> This is really odd.. THe function is already called in the start up hook
>> function init_oscillator() before init.c . Maybe this is problematic.
>> The code crashes in line 508 of kern_tc.c (see rtems-crash.png).
>>
>> Kind Regards
>> Robin
>>
>> On Tue, 20 Apr 2021 at 19:09, Robin Müller 
>> wrote:
>>
>>> Okay, there is some issue with the rtems function to get the uptime
>>> nanoseconds.. The call appears to crash for some reason.
>>>
>>> Kind Regards
>>> Robin
>>>
>>> On Tue, 20 Apr 2021 at 18:31, Robin Mueller 
>>> wrote:
>>>
>>>> This now uses rtems_clock_get_uptime_nanoseconds
>>>> to calculate the uptime ticks in milliseconds.
>>>> ---
>>>>  bsps/arm/stm32h7/start/bspstart.c | 4 +++-
>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/bsps/arm/stm32h7/start/bspstart.c
>>>> b/bsps/arm/stm32h7/start/bspstart.c
>>>> index 2fc8133cca..7ae39f1410 100644
>>>> --- a/bsps/arm/stm32h7/start/bspstart.c
>>>> +++ b/bsps/arm/stm32h7/start/bspstart.c
>>>> @@ -32,9 +32,11 @@
>>>>
>>>>  #include 
>>>>
>>>> +/* Get number of milliseconds elapsed since startup */
>>>>  uint32_t HAL_GetTick(void)
>>>>  {
>>>> -  return 0;
>>>> +  uint64_t temp = rtems_clock_get_uptime_nanoseconds() / (1000 * 1000);
>>>> +  return temp;
>>>>  }
>>>>
>>>>  uint32_t stm32h7_systick_frequency(void)
>>>> --
>>>> 2.25.1
>>>>
>>>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/4] Patch to avoid nameclash of PAGESIZE define

[Robin Müller]

Hmm thats odd. File was created on Windows. Now im on Ubuntu, and if i try
to load it it automatically does something with the line endings of the
file taken from upstream/master..

Kind Regards
Robin

On Tue, 20 Apr 2021 at 19:17, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 12/04/2021 11:55, Robin.Mueller wrote:
>
> > This commit excludes the PAGESIZE legacy define
> > because there is a nameclash with a define of the same name
> > coming from the RTEMS header limits.h
> I have problems to apply this patch. There seems to be a clash of line
> endings.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Updated tick implementation for HAL_GetTick

[Robin Müller]

Yes, I tried to switch oscillator and clock init in the start hook, but
that did not appear to solve the issue.

Kind Regards
Robin

On Tue, 20 Apr 2021 at 19:24, Robin Müller 
wrote:

> This is really odd.. THe function is already called in the start up hook
> function init_oscillator() before init.c . Maybe this is problematic.
> The code crashes in line 508 of kern_tc.c (see rtems-crash.png).
>
> Kind Regards
> Robin
>
> On Tue, 20 Apr 2021 at 19:09, Robin Müller 
> wrote:
>
>> Okay, there is some issue with the rtems function to get the uptime
>> nanoseconds.. The call appears to crash for some reason.
>>
>> Kind Regards
>> Robin
>>
>> On Tue, 20 Apr 2021 at 18:31, Robin Mueller 
>> wrote:
>>
>>> This now uses rtems_clock_get_uptime_nanoseconds
>>> to calculate the uptime ticks in milliseconds.
>>> ---
>>>  bsps/arm/stm32h7/start/bspstart.c | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/bsps/arm/stm32h7/start/bspstart.c
>>> b/bsps/arm/stm32h7/start/bspstart.c
>>> index 2fc8133cca..7ae39f1410 100644
>>> --- a/bsps/arm/stm32h7/start/bspstart.c
>>> +++ b/bsps/arm/stm32h7/start/bspstart.c
>>> @@ -32,9 +32,11 @@
>>>
>>>  #include 
>>>
>>> +/* Get number of milliseconds elapsed since startup */
>>>  uint32_t HAL_GetTick(void)
>>>  {
>>> -  return 0;
>>> +  uint64_t temp = rtems_clock_get_uptime_nanoseconds() / (1000 * 1000);
>>> +  return temp;
>>>  }
>>>
>>>  uint32_t stm32h7_systick_frequency(void)
>>> --
>>> 2.25.1
>>>
>>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Updated tick implementation for HAL_GetTick

[Robin Müller]

Okay, there is some issue with the rtems function to get the uptime
nanoseconds.. The call appears to crash for some reason.

Kind Regards
Robin

On Tue, 20 Apr 2021 at 18:31, Robin Mueller 
wrote:

> This now uses rtems_clock_get_uptime_nanoseconds
> to calculate the uptime ticks in milliseconds.
> ---
>  bsps/arm/stm32h7/start/bspstart.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/bsps/arm/stm32h7/start/bspstart.c
> b/bsps/arm/stm32h7/start/bspstart.c
> index 2fc8133cca..7ae39f1410 100644
> --- a/bsps/arm/stm32h7/start/bspstart.c
> +++ b/bsps/arm/stm32h7/start/bspstart.c
> @@ -32,9 +32,11 @@
>
>  #include 
>
> +/* Get number of milliseconds elapsed since startup */
>  uint32_t HAL_GetTick(void)
>  {
> -  return 0;
> +  uint64_t temp = rtems_clock_get_uptime_nanoseconds() / (1000 * 1000);
> +  return temp;
>  }
>
>  uint32_t stm32h7_systick_frequency(void)
> --
> 2.25.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] updated HAL_GetTick function

[Robin Müller]

Okay, then I will just implement using rtems_clock_get_uptime_nanoseconds()
, similarly to how it was done in the lwIP sys_now implementation by Pavel.

Kind Regards
Robin

On Mon, 19 Apr 2021 at 19:53, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 19/04/2021 18:42, Gedare Bloom wrote:
>
> > On Mon, Apr 19, 2021 at 10:41 AM Gedare Bloom  wrote:
> >> On Mon, Apr 19, 2021 at 2:51 AM Robin Müller
> wrote:
> >>>  From 88ac5780f5597a8bb3bf68c6b37fe6694956faaf Mon Sep 17 00:00:00 2001
> >>> From: Robin Mueller
> >>> Date: Mon, 19 Apr 2021 10:39:55 +0200
> >>> Subject: [PATCH] updated HAL_GetTick function
> >>>
> >>> Patch text went missing, here is the full version of the patch.
> >>> Provides implementation for HAL_GetTick but uses RTEMS.
> >>> Accounts for the tick base not being 1ms now
> >>> ---
> >>>   bsps/arm/stm32h7/start/bspstart.c | 3 ++-
> >>>   1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/bsps/arm/stm32h7/start/bspstart.c
> b/bsps/arm/stm32h7/start/bspstart.c
> >>> index 2fc8133cca..e6e995a50c 100644
> >>> --- a/bsps/arm/stm32h7/start/bspstart.c
> >>> +++ b/bsps/arm/stm32h7/start/bspstart.c
> >>> @@ -32,9 +32,10 @@
> >>>
> >>>   #include 
> >>>
> >>> +/* Get number of milliseconds elapsed since startup */
> >>>   uint32_t HAL_GetTick(void)
> >>>   {
> >>> -  return 0;
> >>> +  return (rtems_clock_get_ticks_since_boot() * 1000) /
> rtems_clock_get_ticks_per_second();
> >> This is reasonable, but note that:
> >> 1. usually it is better to divide before multiplying, to reduce the
> >> chance of arithmetic overflows.
> >> 2. the ticks_since_boot is 32-bits, with 1000 Hz ticking it overflows
> >> in ~2 months
> >>
> >> I suggest you consider
> >>return rtems_clock_get_uptime_seconds()*1000;
> >>
> >> Or you can use rtems_clock_get_uptime_nanoseconds() / (1000) if ms
> >> precision is needed.
> >>
> > I just saw that the HAL function also returns a u32, so it will
> > overflow anyway and it doesn't really matter what you do.
> >
> The HAL_GetTick() should still be correct, otherwise you have an
> infrequent bug which may or may not trouble you seriously. Maybe just do
> the computation with 64-bit floating point numbers or just
> rtems_clock_get_uptime_nanoseconds() / 1000.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Fixes for TMS570 BSP

[Robin Müller]

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  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 
> 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 
> wrote:
> > >> When compiling the lwIP port for the TMS570, there
> > &

Re: [PATCH] Fixes for TMS570 BSP

[Robin Müller]

If this was intentional, I can also adapt the lwIP port sources to use
ti/herc. I was not sure about that.

Kind Regards
Robin

On Mon, 19 Apr 2021 at 10:55, Robin Mueller 
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
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] updated HAL_GetTick function

[Robin Müller]

>From 88ac5780f5597a8bb3bf68c6b37fe6694956faaf Mon Sep 17 00:00:00 2001
From: Robin Mueller 
Date: Mon, 19 Apr 2021 10:39:55 +0200
Subject: [PATCH] updated HAL_GetTick function

Patch text went missing, here is the full version of the patch.
Provides implementation for HAL_GetTick but uses RTEMS.
Accounts for the tick base not being 1ms now
---
 bsps/arm/stm32h7/start/bspstart.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bsps/arm/stm32h7/start/bspstart.c
b/bsps/arm/stm32h7/start/bspstart.c
index 2fc8133cca..e6e995a50c 100644
--- a/bsps/arm/stm32h7/start/bspstart.c
+++ b/bsps/arm/stm32h7/start/bspstart.c
@@ -32,9 +32,10 @@

 #include 

+/* Get number of milliseconds elapsed since startup */
 uint32_t HAL_GetTick(void)
 {
-  return 0;
+  return (rtems_clock_get_ticks_since_boot() * 1000) /
rtems_clock_get_ticks_per_second();
 }

 uint32_t stm32h7_systick_frequency(void)
-- 
2.29.2.windows.2

On Mon, 19 Apr 2021 at 10:48, Robin Mueller 
wrote:

> diff --git a/bsps/arm/stm32h7/start/bspstart.c
> b/bsps/arm/stm32h7/start/bspstart.c
> index 2fc8133cca..e6e995a50c 100644
> --- a/bsps/arm/stm32h7/start/bspstart.c
> +++ b/bsps/arm/stm32h7/start/bspstart.c
> @@ -32,9 +32,10 @@
>
>  #include 
>
> +/* Get number of milliseconds elapsed since startup */
>  uint32_t HAL_GetTick(void)
>  {
> -  return 0;
> +  return (rtems_clock_get_ticks_since_boot() * 1000) /
> rtems_clock_get_ticks_per_second();
>  }
>
>  uint32_t stm32h7_systick_frequency(void)
> --
> 2.29.2.windows.2
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/4] Implementation for HAL_GetTick

[Robin Müller]

This implementation is problematic because HAL_GetTick is supposed to
return elapsed milliseconds since boot and the current implementation
assumes there are 1000 ticks per second.
I'll send an updated patch.

Kind Regards
Robin

On Mon, 12 Apr 2021 at 11:55, Robin.Mueller 
wrote:

> This commit adds an implementation for the HAL_GetTick function.
> It simply forwards the call to the respective RTEMS function.
> ---
>  bsps/arm/stm32h7/start/bspstart.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bsps/arm/stm32h7/start/bspstart.c
> b/bsps/arm/stm32h7/start/bspstart.c
> index 2fc8133cca..d942fbdcb3 100644
> --- a/bsps/arm/stm32h7/start/bspstart.c
> +++ b/bsps/arm/stm32h7/start/bspstart.c
> @@ -34,7 +34,7 @@
>
>  uint32_t HAL_GetTick(void)
>  {
> -  return 0;
> +  return rtems_clock_get_ticks_since_boot();
>  }
>
>  uint32_t stm32h7_systick_frequency(void)
> --
> 2.25.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

[Robin Müller]

I can split up the rest of the patch.
I would rename STM32H7_ADD_LWIP from the BSP configuration to
RTEMS_USE_LWIP as a more generic variant which could be reused for other
BSPs if that is okay.

Kind Regards
Robin

On Mon, 12 Apr 2021 at 10:46, Robin Müller 
wrote:

> The variant worked without issues.
>
> Kind Regards
> Robin
>
> On Fri, 9 Apr 2021 at 09:21, Robin Müller 
> wrote:
>
>> Hello Sebastian,
>>
>> I will have a look at it soon.
>>
>> Kind Regards
>> Robin
>>
>> On Tue, 6 Apr 2021 at 10:01, Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>>
>>> Hello Robin,
>>>
>>> sorry for the delay. I checked in some patches to add a
>>> "arm/nucleo-h743zi" BSP variant. Could you please check if this variant
>>> works on the board.
>>>
>>> Could you please split up the remaining pieces of the patch into
>>> separate commits.
>>>
>>> --
>>> embedded brains GmbH
>>> Herr Sebastian HUBER
>>> Dornierstr. 4
>>> 82178 Puchheim
>>> Germany
>>> email: sebastian.hu...@embedded-brains.de
>>> phone: +49-89-18 94 741 - 16
>>> fax:   +49-89-18 94 741 - 08
>>>
>>> Registergericht: Amtsgericht München
>>> Registernummer: HRB 157899
>>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>>> Unsere Datenschutzerklärung finden Sie hier:
>>> https://embedded-brains.de/datenschutzerklaerung/
>>>
>>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

[Robin Müller]

The variant worked without issues.

Kind Regards
Robin

On Fri, 9 Apr 2021 at 09:21, Robin Müller  wrote:

> Hello Sebastian,
>
> I will have a look at it soon.
>
> Kind Regards
> Robin
>
> On Tue, 6 Apr 2021 at 10:01, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello Robin,
>>
>> sorry for the delay. I checked in some patches to add a
>> "arm/nucleo-h743zi" BSP variant. Could you please check if this variant
>> works on the board.
>>
>> Could you please split up the remaining pieces of the patch into
>> separate commits.
>>
>> --
>> embedded brains GmbH
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.hu...@embedded-brains.de
>> phone: +49-89-18 94 741 - 16
>> fax:   +49-89-18 94 741 - 08
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRB 157899
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

[Robin Müller]

Hello Sebastian,

I will have a look at it soon.

Kind Regards
Robin

On Tue, 6 Apr 2021 at 10:01, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Robin,
>
> sorry for the delay. I checked in some patches to add a
> "arm/nucleo-h743zi" BSP variant. Could you please check if this variant
> works on the board.
>
> Could you please split up the remaining pieces of the patch into
> separate commits.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

[Robin Müller]

 The change with void HAL_ETH_MspInit(ETH_HandleTypeDef *heth) was just
that most
other function definitions I saw were on one line so I assumed this was a
little formatting mistake. I can discard the change if this was
intentional.

I can add #ifndef __rtems__ for the section with the legacy defines as well.
Kind Regards
Robin

On Mon, 29 Mar 2021 at 17:52, Gedare Bloom  wrote:

> On Mon, Mar 29, 2021 at 6:17 AM Robin Mueller 
> wrote:
> >
> > This patch adds support for the STM32H743ZI-Nucleo board
> > variation. This currently works by setting the STM32H743ZI_NUCLEO
> > flag in the config.ini flag
> >
> > It also adds basic lwIP support which can be enabled
> > with the flag STM32H7_ADD_LWIP. This enables certain functionalities
> > required for lwIP to work properly
> >
> > This patch also changes the default implementation
> > of HAL_GetTick to return the system tick by forwarding the call
> > to the respective RTEMS function.
> >
> > ---
> >  bsps/arm/stm32h7/console/console-usart3-cfg.c | 21 
> >  bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c  | 16 -
> >  .../stm32h7/include/Legacy/stm32_hal_legacy.h |  4 +++-
> >  bsps/arm/stm32h7/include/stm32h7xx_hal_conf.h | 11 -
> >  bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h |  1 +
> >  bsps/arm/stm32h7/start/bspstart.c |  2 +-
> >  bsps/arm/stm32h7/start/stm32h7-hal-eth.c  |  3 +--
> >  spec/build/bsps/arm/stm32h7/bspstm32h7.yml|  4 
> >  spec/build/bsps/arm/stm32h7/opth743nucleo.yml | 13 ++
> >  spec/build/bsps/arm/stm32h7/optlwip.yml   | 24 +++
> >  10 files changed, 88 insertions(+), 11 deletions(-)
> >  create mode 100644 spec/build/bsps/arm/stm32h7/opth743nucleo.yml
> >  create mode 100644 spec/build/bsps/arm/stm32h7/optlwip.yml
> >
> > diff --git a/bsps/arm/stm32h7/console/console-usart3-cfg.c
> b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > index b40f6da5aa..dc552610e1 100644
> > --- a/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > +++ b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > @@ -25,12 +25,32 @@
> >   * POSSIBILITY OF SUCH DAMAGE.
> >   */
> >
> > +#ifdef __rtems__
> > +#include 
> > +#endif
> > +
> >  #ifdef HAVE_CONFIG_H
> >  #include "config.h"
> >  #endif
> >
> >  #include 
> >
> > +#if STM32H743ZI_NUCLEO == 1
> > +const stm32h7_uart_config stm32h7_usart3_config = {
> > +  .gpio = {
> > +.regs = GPIOD,
> > +.config = {
> > +  .Pin = GPIO_PIN_8 | GPIO_PIN_9,
> > +  .Mode = GPIO_MODE_AF_PP,
> > +  .Pull = GPIO_NOPULL,
> > +  .Speed = GPIO_SPEED_FREQ_LOW,
> > +  .Alternate = GPIO_AF7_USART3
> > +}
> > +  },
> > +  .irq = USART3_IRQn,
> > +  .device_index = 2
> > +};
> > +#else
> >  const stm32h7_uart_config stm32h7_usart3_config = {
> >.gpio = {
> >  .regs = GPIOB,
> > @@ -45,3 +65,4 @@ const stm32h7_uart_config stm32h7_usart3_config = {
> >.irq = USART3_IRQn,
> >.device_index = 2
> >  };
> > +#endif /*  STM32H743ZI_NUCLEO == 1 */
> > diff --git a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > index 4f2634df5b..6c3590bce8 100644
> > --- a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > +++ b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > @@ -146,6 +146,10 @@
> >  /* Includes
> --*/
> >  #include "stm32h7xx_hal.h"
> >
> > +#ifdef __rtems__
> > +#include 
> > +#endif
> > +
> >  /** @addtogroup STM32H7xx_HAL_Driver
> >* @{
> >*/
> > @@ -361,10 +365,10 @@ HAL_StatusTypeDef HAL_ETH_Init(ETH_HandleTypeDef
> *heth)
> >/*-- MAC, MTL and DMA default Configuration
> */
> >ETH_MACDMAConfig(heth);
> >
> > -#ifndef __rtems__
> > +#if STM32H7_ADD_LWIP == 1
>
> Someone else may be able to address whether we need to disable this
> stuff for 'non-lwip' builds of stm32. There is an ongoing effort to
> collect lwip drivers and lwip build as a library after building rtems,
> so maybe this will move eventually to the lwip driver repo when that
> gets into production.
>
> >/* SET DSL to 64 bit */
> >MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL,
> ETH_DMACCR_DSL_64BIT);
> > -#endif /* __rtems__ */
> > +#endif
> >
> >/* Set Receive Buffers Length (must be a multiple of 4) */
> >if ((heth->Init.RxBuffLen % 0x4U) != 0x0U)
> > @@ -2647,7 +2651,7 @@ static void
> ETH_MAC_MDIO_ClkConfig(ETH_HandleTypeDef *heth)
> >*/
> >  static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
> >  {
> > -#ifndef __rtems__
> > +#if STM32H7_ADD_LWIP == 1
> >ETH_DMADescTypeDef *dmatxdesc;
> >uint32_t i;
> >
> > @@ -2674,7 +2678,7 @@ static void
> ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
> >
> >/* Set Transmit Descriptor Tail pointer */
> >WRITE_REG(heth->Instance->DMACTDTPR, (uint32_t) heth->Init.TxDesc);
> > -#endif /* __rtems__ */
> > +#endif /* STM32H7_ADD_LWIP == 1 */
> >  }
> >
> >  /**
> > @@ -2686,7 +2690,7 @@ static void
> 

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

[Robin Müller]

Hi Vijay,

It looks interesting, but I am not really a LwIP expert. I might look into
it once I have more time in 1-2 weeks.
I only have a BBB and the STM32H7 as test HW right now, but I guess this is
a good starting point.
Does this mean that the lwIP repository contains the architecture specific
sources shown above? (so the DMA descriptors basically and maybe the LAN
device driver). The lwIP support would then be built as part of the BSP?
And would it use the mainloop mode or the OS mode? The STM32 example I
implemented uses the mainloop mode with NO_SYS defined to 1, so I am not
familiar with the OS mode, but I guess it would make sense to use the OS
mode, porting it to RTEMS.

Kind Regards
Robin


On Mon, 29 Mar 2021 at 22:25, Vijay Kumar Banerjee  wrote:

> On Mon, Mar 29, 2021 at 9:52 AM Gedare Bloom  wrote:
> >
> > On Mon, Mar 29, 2021 at 6:17 AM Robin Mueller 
> wrote:
> > >
> > > This patch adds support for the STM32H743ZI-Nucleo board
> > > variation. This currently works by setting the STM32H743ZI_NUCLEO
> > > flag in the config.ini flag
> > >
> > > It also adds basic lwIP support which can be enabled
> > > with the flag STM32H7_ADD_LWIP. This enables certain functionalities
> > > required for lwIP to work properly
> > >
> > > This patch also changes the default implementation
> > > of HAL_GetTick to return the system tick by forwarding the call
> > > to the respective RTEMS function.
> > >
> > > ---
> > >  bsps/arm/stm32h7/console/console-usart3-cfg.c | 21 
> > >  bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c  | 16 -
> > >  .../stm32h7/include/Legacy/stm32_hal_legacy.h |  4 +++-
> > >  bsps/arm/stm32h7/include/stm32h7xx_hal_conf.h | 11 -
> > >  bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h |  1 +
> > >  bsps/arm/stm32h7/start/bspstart.c |  2 +-
> > >  bsps/arm/stm32h7/start/stm32h7-hal-eth.c  |  3 +--
> > >  spec/build/bsps/arm/stm32h7/bspstm32h7.yml|  4 
> > >  spec/build/bsps/arm/stm32h7/opth743nucleo.yml | 13 ++
> > >  spec/build/bsps/arm/stm32h7/optlwip.yml   | 24 +++
> > >  10 files changed, 88 insertions(+), 11 deletions(-)
> > >  create mode 100644 spec/build/bsps/arm/stm32h7/opth743nucleo.yml
> > >  create mode 100644 spec/build/bsps/arm/stm32h7/optlwip.yml
> > >
> > > diff --git a/bsps/arm/stm32h7/console/console-usart3-cfg.c
> b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > > index b40f6da5aa..dc552610e1 100644
> > > --- a/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > > +++ b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > > @@ -25,12 +25,32 @@
> > >   * POSSIBILITY OF SUCH DAMAGE.
> > >   */
> > >
> > > +#ifdef __rtems__
> > > +#include 
> > > +#endif
> > > +
> > >  #ifdef HAVE_CONFIG_H
> > >  #include "config.h"
> > >  #endif
> > >
> > >  #include 
> > >
> > > +#if STM32H743ZI_NUCLEO == 1
> > > +const stm32h7_uart_config stm32h7_usart3_config = {
> > > +  .gpio = {
> > > +.regs = GPIOD,
> > > +.config = {
> > > +  .Pin = GPIO_PIN_8 | GPIO_PIN_9,
> > > +  .Mode = GPIO_MODE_AF_PP,
> > > +  .Pull = GPIO_NOPULL,
> > > +  .Speed = GPIO_SPEED_FREQ_LOW,
> > > +  .Alternate = GPIO_AF7_USART3
> > > +}
> > > +  },
> > > +  .irq = USART3_IRQn,
> > > +  .device_index = 2
> > > +};
> > > +#else
> > >  const stm32h7_uart_config stm32h7_usart3_config = {
> > >.gpio = {
> > >  .regs = GPIOB,
> > > @@ -45,3 +65,4 @@ const stm32h7_uart_config stm32h7_usart3_config = {
> > >.irq = USART3_IRQn,
> > >.device_index = 2
> > >  };
> > > +#endif /*  STM32H743ZI_NUCLEO == 1 */
> > > diff --git a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > > index 4f2634df5b..6c3590bce8 100644
> > > --- a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > > +++ b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > > @@ -146,6 +146,10 @@
> > >  /* Includes
> --*/
> > >  #include "stm32h7xx_hal.h"
> > >
> > > +#ifdef __rtems__
> > > +#include 
> > > +#endif
> > > +
> > >  /** @addtogroup STM32H7xx_HAL_Driver
> > >* @{
> > >*/
> > > @@ -361,10 +365,10 @@ HAL_StatusTypeDef HAL_ETH_Init(ETH_HandleTypeDef
> *heth)
> > >/*-- MAC, MTL and DMA default Configuration
> */
> > >ETH_MACDMAConfig(heth);
> > >
> > > -#ifndef __rtems__
> > > +#if STM32H7_ADD_LWIP == 1
> >
> > Someone else may be able to address whether we need to disable this
> > stuff for 'non-lwip' builds of stm32. There is an ongoing effort to
> > collect lwip drivers and lwip build as a library after building rtems,
> > so maybe this will move eventually to the lwip driver repo when that
> > gets into production.
> >
> Hi,
>
> Yes, we're moving all the network stacks out of RTEMS so that a user
> can choose their preferred network stack to work with RTEMS. The LWIP
> repository is in initial state and it is gradually starting to include
> the drivers. This lwip patch would be a great 

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

I solved it like you mentioned now by putting the descriptors in the
.bsp_no_cache section and with the correct alignment.

/* Put into special RTEMS section and align correctly */
ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT]
__attribute__((section(".bsp_nocache"),
__aligned__(DMA_DESCRIPTOR_ALIGNMENT)));
/* Put into special RTEMS section and align correctly */
ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT]
 __attribute__((section(".bsp_nocache"),
__aligned__(DMA_DESCRIPTOR_ALIGNMENT)));
uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_RX_BUFFER_SIZE];

I will update the patch I sent with the sections removed from linccmd.base
. Maybe it still would be a better idea to have a separate BSP for the
STm32H743ZIT6-Nucleo but I would have to look into how to do this again.

Kind Regards
Robin

On Fri, 26 Mar 2021 at 15:24, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
> On 26/03/2021 11:34, Robin Müller wrote:
> > How would you define a generic linker section? I tried to put the
> > following section into the
> > linkcmdsmemory file like you suggested (at
> > spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml):
> >
> >   SECTIONS {
> > .stm32h7_sram_3 (NOLOAD) : ALIGN_WITH_INPUT {
> >   bsp_stm32h7_sram_3_start = stm32h7_memory_sram_3_begin;
> >   bsp_stm32h7_sram_3_end = stm32h7_memory_sram_3_end;
> > } > SRAM_3 AT > FLASH
> >   }
>
> This should work. You need also input sections for this output section.
> I still don't know why you can't use the already existing:
>
>  .nocache : ALIGN_WITH_INPUT {
>  bsp_section_nocache_begin = .;
>  *(SORT_BY_ALIGNMENT (SORT_BY_NAME (.bsp_nocache*)))
>  bsp_section_nocache_end = .;
>  } > REGION_NOCACHE AT > REGION_NOCACHE_LOAD
>  bsp_section_nocache_size = bsp_section_nocache_end -
> bsp_section_nocache_begin;
>  bsp_section_nocache_load_begin = LOADADDR (.nocache);
>  bsp_section_nocache_load_end = bsp_section_nocache_load_begin +
> bsp_section_nocache_size;
>
>  .nocachenoload (NOLOAD) : ALIGN_WITH_INPUT {
>  bsp_section_nocachenoload_begin = .;
>  *(SORT_BY_ALIGNMENT (SORT_BY_NAME (.bsp_noload_nocache*)))
>  bsp_section_nocacheheap_begin = .;
>  . += ORIGIN (REGION_NOCACHE) + LENGTH (REGION_NOCACHE) -
> ABSOLUTE (.);
>  bsp_section_nocacheheap_end = .;
>  bsp_section_nocachenoload_end = .;
>  } > REGION_NOCACHE AT > REGION_NOCACHE
>  bsp_section_nocacheheap_size = bsp_section_nocacheheap_end -
> bsp_section_nocacheheap_begin;
>  bsp_section_nocachenoload_size = bsp_section_nocachenoload_end -
> bsp_section_nocachenoload_begin;
>
> For the stm32h7 these regions are used:
>
>REGION_ALIAS ("REGION_NOCACHE", SRAM_1);
>REGION_ALIAS ("REGION_NOCACHE_LOAD", SDRAM_1);
>
> >
> > But the waf build fails with  a syntax error:
> >
> > [1610/1611] Linking build/arm/stm32h7/testsuites/samples/ticker.exe
> > [1611/1611] Linking build/arm/stm32h7/testsuites/samples/unlimited.exe
> >
> c:/users/robin/rtems/rtems-tools/rtems/6/bin/../lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld.exe:linkcmds.memory:84:
>
> > syntax error
> > collect2.exe: error: ld returned 1 exit status
> >
> >
> c:/users/robin/rtems/rtems-tools/rtems/6/bin/../lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld.exe:linkcmds.memory:84:
>
> > syntax error
> > collect2.exe: error: ld returned 1 exit status
> What is around line 84?
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

How would you define a generic linker section? I tried to put the following
section into the
linkcmdsmemory file like you suggested (at
spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml):

  SECTIONS {
.stm32h7_sram_3 (NOLOAD) : ALIGN_WITH_INPUT {
  bsp_stm32h7_sram_3_start = stm32h7_memory_sram_3_begin;
  bsp_stm32h7_sram_3_end = stm32h7_memory_sram_3_end;
} > SRAM_3 AT > FLASH
  }

But the waf build fails with  a syntax error:

[1610/1611] Linking build/arm/stm32h7/testsuites/samples/ticker.exe
[1611/1611] Linking build/arm/stm32h7/testsuites/samples/unlimited.exe
c:/users/robin/rtems/rtems-tools/rtems/6/bin/../lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld.exe:linkcmds.memory:84:
syntax error
collect2.exe: error: ld returned 1 exit status

c:/users/robin/rtems/rtems-tools/rtems/6/bin/../lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld.exe:linkcmds.memory:84:
syntax error
collect2.exe: error: ld returned 1 exit status

Kind Regards
Robin

On Thu, 25 Mar 2021 at 13:15, Robin Müller 
wrote:

> That is how it was done in the lwIP demo provided by STM, I simply adopted
> that. The SRAM3 is small, but big enough for lwIP, so all of it is used
> completely by lwIP.
> How would you place the descriptors in code so that these linker script
> sections are not necessary? You mentioned RTEMS_SECTIONs. Are those used in
> the source code?
>
> Kind Regards
> Robin Müller
>
> On Mon, 22 Mar 2021 at 11:43, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 03/02/2021 14:50, Robin Müller wrote:
>>
>> > The following link contains more theoretical information about why
>> > these sections were placed at these addresses:
>> >
>> https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
>> > <
>> https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
>> >
>> >
>> > Kind Regards
>> > Robin
>> >
>> > On Wed, 3 Feb 2021 at 14:44, Robin Müller > > <mailto:robin.muelle...@gmail.com>> wrote:
>> >
>> > The DMA descriptors need to be placed at the start of the SRAM3
>> > and need to be aligned in a certain way. The RX buffer will take
>> > up the first (slightly less than) 16 kB of SRAM3 but needs to be
>> > placed
>> > behind the DMA descriptors. It also needs to be placed in a way
>> > that the MPU configuration required for the DMA descriptors will
>> > not do something with the RX buffers.
>> > In the example provided by STM32, the first 256 bytes are
>> > configured by MPU Config.
>> >
>> I had a look at the FAQ and the manual. Currently, we use the SRAM1 for
>> the .nocache area. This is in the D2 domain. The Ethernet module is in
>> the D2 domain. I am not sure why you have to change this to the smaller
>> SRAM3? The libbsd driver works well with the current setting.
>>
>> --
>> embedded brains GmbH
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.hu...@embedded-brains.de
>> phone: +49-89-18 94 741 - 16
>> fax:   +49-89-18 94 741 - 08
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRB 157899
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

That is how it was done in the lwIP demo provided by STM, I simply adopted
that. The SRAM3 is small, but big enough for lwIP, so all of it is used
completely by lwIP.
How would you place the descriptors in code so that these linker script
sections are not necessary? You mentioned RTEMS_SECTIONs. Are those used in
the source code?

Kind Regards
Robin Müller

On Mon, 22 Mar 2021 at 11:43, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 03/02/2021 14:50, Robin Müller wrote:
>
> > The following link contains more theoretical information about why
> > these sections were placed at these addresses:
> >
> https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
> > <
> https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
> >
> >
> > Kind Regards
> > Robin
> >
> > On Wed, 3 Feb 2021 at 14:44, Robin Müller  > <mailto:robin.muelle...@gmail.com>> wrote:
> >
> > The DMA descriptors need to be placed at the start of the SRAM3
> > and need to be aligned in a certain way. The RX buffer will take
> > up the first (slightly less than) 16 kB of SRAM3 but needs to be
> > placed
> > behind the DMA descriptors. It also needs to be placed in a way
> > that the MPU configuration required for the DMA descriptors will
> > not do something with the RX buffers.
> > In the example provided by STM32, the first 256 bytes are
> > configured by MPU Config.
> >
> I had a look at the FAQ and the manual. Currently, we use the SRAM1 for
> the .nocache area. This is in the D2 domain. The Ethernet module is in
> the D2 domain. I am not sure why you have to change this to the smaller
> SRAM3? The libbsd driver works well with the current setting.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

Any progress on this issue?
I am currently trying to compile the BBB BSP and the adaptations I did to
the linkcmds.base file are definitely problematic..

Kind Regards
Robin

On Fri, 19 Feb 2021 at 08:08, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 18/02/2021 20:55, Gedare Bloom wrote:
>
> > On Thu, Feb 4, 2021 at 10:58 AM Sebastian Huber
> >   wrote:
> >> On 04/02/2021 18:45, Robin Müller wrote:
> >>
> >>> Could you look into this, based on the existing patch? I don't really
> >>> have the time to look (deeply) into it in the next few weeks,
> >>> and the changes are probably easier  for you to implement. I can offer
> >>> to test it though :-)
> >> Ok, please remind me in a week. I am currently quite busy.
> >>
> > It's been a week.
> I am sorry. What makes things even worse is that I am not in the office
> next week.
> >
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] This adds a way to print the host triplet

[Robin Müller]

I still think it would be nice if very common tool suites like ARM could be
installed /downloaded in a pre-compiled way at least for Windows because
the  tool building process is the only thing preventing
development on Windows some(or most?) times.
xPacks is doing that (and they use CXC for the Windows toolchain too,
building it automatically for Windows on a Debian machine, see here
https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/releases) and
Arduino ships pre-compiled  toolchains with their software (but it's
possible to download separately as well).

Once the tool suite was available, I did not have any OS specific issues
any more.

Kind Regards
Robin

On Thu, 25 Feb 2021 at 10:44, Robin Müller 
wrote:

> I only used it to CXC the ARM toolchain (Linux -> Windows) mainly because
> I have only needed the ARM tool suite up until now (and there were issues
> building it  on Windows, but maybe that has been solved since).
> That was a few weeks ago and I have not rebuilt it since.
>
> Kind Regards
> Robin
>
> On Thu, 25 Feb 2021 at 01:30, Chris Johns  wrote:
>
>> On 25/2/21 9:21 am, Robin Müller wrote:
>> > There is no first patch (the first patch file was a SIS update, but
>> that's
>> > already inside master I think).
>> > I think I used this when I canadian cross-compiled the RTEMS ARM
>> toolchain for
>> > Windows on Linux and I was not sure what the triplet was.
>>
>> Great and thanks. Have you been using the Cxc mode recently? I have
>> stopped
>> testing it.
>>
>> Chris
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] This adds a way to print the host triplet

[Robin Müller]

I only used it to CXC the ARM toolchain (Linux -> Windows) mainly because I
have only needed the ARM tool suite up until now (and there were issues
building it  on Windows, but maybe that has been solved since).
That was a few weeks ago and I have not rebuilt it since.

Kind Regards
Robin

On Thu, 25 Feb 2021 at 01:30, Chris Johns  wrote:

> On 25/2/21 9:21 am, Robin Müller wrote:
> > There is no first patch (the first patch file was a SIS update, but
> that's
> > already inside master I think).
> > I think I used this when I canadian cross-compiled the RTEMS ARM
> toolchain for
> > Windows on Linux and I was not sure what the triplet was.
>
> Great and thanks. Have you been using the Cxc mode recently? I have stopped
> testing it.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] This adds a way to print the host triplet

[Robin Müller]

There is no first patch (the first patch file was a SIS update, but that's
already inside master I think).
I think I used this when I canadian cross-compiled the RTEMS ARM toolchain
for Windows on Linux and I was not sure what the triplet was.

Kind Regards
Robin

On Wed, 24 Feb 2021 at 22:34, Chris Johns  wrote:

> On 25/2/21 5:23 am, Robin Mueller wrote:
> > Can be useful for cross-compiling toolchains
>
> What is the use case for the option? We cross compile tools by default so
> I am
> interested to understand where I would use this option.
>
> Thanks
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] STM32H7 doc update

[Robin Müller]

Hello,

Just another bump for the small doc patch and a reminder for another patch
I sent, which still needs some smaller adaptations for lwIP  ([PATCH] Basic
lwIP for STM32H7 BSP)
Kind Regards
Robin Müller

On Thu, 21 Jan 2021 at 13:52, Robin Müller 
wrote:

> I'd just like to bump my patch. The last changes were just the formatting
> changes from the code review.
>
>
> Kind Regards
> Robin
>
> On Tue, 12 Jan 2021 at 12:36, Robin Mueller 
> wrote:
>
>> ---
>>
>> Added doc for board variation, added some  fixes
>> from code review. (typo and line width formatting)
>>
>>  user/bsps/arm/stm32h7.rst | 18 +-
>>  1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/user/bsps/arm/stm32h7.rst b/user/bsps/arm/stm32h7.rst
>> index 3eee511..e1b9d8c 100644
>> --- a/user/bsps/arm/stm32h7.rst
>> +++ b/user/bsps/arm/stm32h7.rst
>> @@ -11,16 +11,32 @@ This BSP supports the
>>  The BSP is known to run on these boards:
>>
>>  * `STM32H743I-EVAL 2 <
>> https://www.st.com/en/evaluation-tools/stm32h743i-eval.html>`_
>> +* `STM32H743ZI-Nucleo <
>> https://www.st.com/en/evaluation-tools/nucleo-h743zi.html>`_
>>
>>  Clock Driver
>>  
>>
>> -The clock driver uses the `ARMv7-M Systick` module.
>> +The clock driver uses the `ARMv7-M Systick` module. The HSE (external
>> +oscillator) value can also be different for different evaluation or
>> custom
>> +boards, so it is recommended to check the default values of the BSP.
>>
>>  Console Driver
>>  --
>>
>>  The console driver supports the on-chip UART and USART modules.
>> +Different board variations use different GPIO pins and blocks for the
>> default
>> +communication UART and it is recommended to check whether the default
>> +configuration provided is valid in the BSP.
>> +
>> +To specify that the BSP should be built for the STM32H743ZI-Nucleo board,
>> +users can supply ``STM32H743ZI_NUCLEO == True`` to ``config.ini`` when
>> +building the BSP.
>> +
>> +Alternatively, users can supply the configuration structs defined in
>> ``hal.h``
>> +in the applicaton for other boards. For the console driver, the
>> +``stm32h7_usartX_config`` structs are used to configure the GPIO pins
>> and other
>> +parameters. The default implementations can be found in
>> +``bsps/arm/stm32ht/console`` in the RTEMS sources.
>>
>>  Network Interface Driver
>>  
>> --
>> 2.23.0.windows.1
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

Could you look into this, based on the existing patch? I don't really have
the time to look (deeply) into it in the next few weeks,
and the changes are probably easier  for you to implement. I can offer to
test it though :-)

Kind Regards
Robin Müller

On Thu, 4 Feb 2021 at 14:41, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 04/02/2021 14:39, Joel Sherrill wrote:
>
> > On Thu, Feb 4, 2021, 6:18 AM Robin Müller  > <mailto:robin.muelle...@gmail.com>> wrote:
> >
> > I think the DMA descriptors need to be 32 byte (0x20) aligned.
> > That's the reason the example application was set up like this.
> >
> >
> > But you can just as easily turn them into pointers which point to 32
> > byte aligned areas in a nocache region.
> >
> > Just wondering if that's possible with the code because I think it
> > would be easier with the existing linkcmds to assign a nocache area as
> > you need and then split it by hand.
> >
> > Sebastian... ?
> I would prefer to use a generic linker section definition and then
> simply define global data structures in the right section with the right
> alignment (see RTEMS_ALIGN()).
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

I think the DMA descriptors need to be 32 byte (0x20) aligned. That's the
reason the example application was set up like this.

Kind Regards
Robin

On Wed, 3 Feb 2021 at 15:32, Joel Sherrill  wrote:

>
>
> On Wed, Feb 3, 2021, 8:26 AM Robin Müller 
> wrote:
>
>> Also, Andrei Chichak provided a very good explanation:
>>
>> The STM32x7 ethernet controllers need their descriptors and data areas to
>>> be located on 32-byte boundaries with a combination of cache being turned
>>> off and buffering being turned off. This is a side effect of the STM32x7
>>> DMA and data caching.
>>>
>>> The examples that ST have for LWiP under FreeRTOS have some issues with
>>> the linker file having overlapping sections and the stack (above the ETH
>>> data areas) being left with no cache and no buffering. The space above the
>>> rx/tx buffers is also less than the stack space minimum specified in the
>>> linker file as well.  Some rearranging of the ETH descriptors and data
>>> areas would be prudent. Like push them to the top of SRAM and locate the
>>> stack below.
>>>
>>> To get this all going, they set up the MPU for two overlapping sections,
>>> one being the top 16kB of SRAM and the other the 256B that contain the ETH
>>> descriptors. I believe the MPU regions can be set in increments of 32Bytes,
>>> so setting up the cache and buffering should be do-able without affecting
>>> the stack.
>>>
>>
> Just asking. Can this be a non-cacheable region and the variables not in
> special sections? I wonder if changing them to normal pointers to special
> memory would ripple. Do they just use the variables for initialization or
> reference them a lot?
>
> I think the standard linkcmds setup allows for nocache areas already.
>
> --joel
>
>
>> Kind Regards
>> Robin Müller
>>
>> On Wed, 3 Feb 2021 at 14:50, Robin Müller 
>> wrote:
>>
>>> The following link contains more theoretical information about why these
>>> sections were placed at these addresses:
>>> https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
>>>
>>> Kind Regards
>>> Robin
>>>
>>> On Wed, 3 Feb 2021 at 14:44, Robin Müller 
>>> wrote:
>>>
>>>> The DMA descriptors need to be placed at the start of the SRAM3 and
>>>> need to be aligned in a certain way. The RX buffer will take up the first
>>>> (slightly less than) 16 kB of SRAM3 but needs to be placed
>>>> behind the DMA descriptors. It also needs to be placed in a way that
>>>> the MPU configuration required for the DMA descriptors will not do
>>>> something with the RX buffers.
>>>> In the example provided by STM32, the first 256 bytes are configured by
>>>> MPU Config.
>>>>
>>>> Kind Regards
>>>> Robin
>>>>
>>>>
>>>>
>>>> On Wed, 3 Feb 2021 at 13:43, Sebastian Huber <
>>>> sebastian.hu...@embedded-brains.de> wrote:
>>>>
>>>>> On 02/02/2021 20:10, Robin Mueller wrote:
>>>>>
>>>>> > + /* Not an ideal solution but required for lwIP on the STM32H7
>>>>> BSP.
>>>>> > + This places the DMA descriptors for lwIP at the start of SRAM3.
>>>>> > + The MPU still needs to be configured for the DMA descriptor
>>>>> regions to be
>>>>> > + bufferable, non-cacheable, non-shareable (first 256 bytes) */
>>>>> > + .lwip_sec_stm32h7 (NOLOAD) : ALIGN_WITH_INPUT {
>>>>> > + . = ABSOLUTE(0x3004);
>>>>> > + *(.RxDecripSection)
>>>>> > + . = ABSOLUTE(0x30040060);
>>>>> > + *(.TxDecripSection)
>>>>> > + . = ABSOLUTE(0x30040200);
>>>>> > + *(.RxArraySection)
>>>>> > + } >SRAM_3 AT> REGION_TEXT_LOAD
>>>>> > +
>>>>>
>>>>> This is the wrong linker command file. This stuff should be in
>>>>>
>>>>> spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml
>>>>>
>>>>> with an output section name like ".stm32h7_sram_3" and corresponding
>>>>> input section names. Why do you need absolute addresses here?
>>>>>
>>>>> --
>>>>> embedded brains GmbH
>>>>> Herr Sebastian HUBER
>>>>> Dornierstr. 4
>>>>> 82178 Puchheim
>>>>> Germany
>>>>> email: sebastian.hu...@embedded-brains.de
>>>>> phone: +49-89-18 94 741 - 16
>>>>> fax:   +49-89-18 94 741 - 08
>>>>>
>>>>> Registergericht: Amtsgericht München
>>>>> Registernummer: HRB 157899
>>>>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>>>>> Unsere Datenschutzerklärung finden Sie hier:
>>>>> https://embedded-brains.de/datenschutzerklaerung/
>>>>>
>>>>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

Also, Andrei Chichak provided a very good explanation:

The STM32x7 ethernet controllers need their descriptors and data areas to
> be located on 32-byte boundaries with a combination of cache being turned
> off and buffering being turned off. This is a side effect of the STM32x7
> DMA and data caching.
>
> The examples that ST have for LWiP under FreeRTOS have some issues with
> the linker file having overlapping sections and the stack (above the ETH
> data areas) being left with no cache and no buffering. The space above the
> rx/tx buffers is also less than the stack space minimum specified in the
> linker file as well.  Some rearranging of the ETH descriptors and data
> areas would be prudent. Like push them to the top of SRAM and locate the
> stack below.
>
> To get this all going, they set up the MPU for two overlapping sections,
> one being the top 16kB of SRAM and the other the 256B that contain the ETH
> descriptors. I believe the MPU regions can be set in increments of 32Bytes,
> so setting up the cache and buffering should be do-able without affecting
> the stack.
>

Kind Regards
Robin Müller

On Wed, 3 Feb 2021 at 14:50, Robin Müller  wrote:

> The following link contains more theoretical information about why these
> sections were placed at these addresses:
> https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
>
> Kind Regards
> Robin
>
> On Wed, 3 Feb 2021 at 14:44, Robin Müller 
> wrote:
>
>> The DMA descriptors need to be placed at the start of the SRAM3 and need
>> to be aligned in a certain way. The RX buffer will take up the first
>> (slightly less than) 16 kB of SRAM3 but needs to be placed
>> behind the DMA descriptors. It also needs to be placed in a way that the
>> MPU configuration required for the DMA descriptors will not do something
>> with the RX buffers.
>> In the example provided by STM32, the first 256 bytes are configured by
>> MPU Config.
>>
>> Kind Regards
>> Robin
>>
>>
>>
>> On Wed, 3 Feb 2021 at 13:43, Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>>
>>> On 02/02/2021 20:10, Robin Mueller wrote:
>>>
>>> > + /* Not an ideal solution but required for lwIP on the STM32H7
>>> BSP.
>>> > + This places the DMA descriptors for lwIP at the start of SRAM3.
>>> > + The MPU still needs to be configured for the DMA descriptor
>>> regions to be
>>> > + bufferable, non-cacheable, non-shareable (first 256 bytes) */
>>> > + .lwip_sec_stm32h7 (NOLOAD) : ALIGN_WITH_INPUT {
>>> > + . = ABSOLUTE(0x3004);
>>> > + *(.RxDecripSection)
>>> > + . = ABSOLUTE(0x30040060);
>>> > + *(.TxDecripSection)
>>> > + . = ABSOLUTE(0x30040200);
>>> > + *(.RxArraySection)
>>> > + } >SRAM_3 AT> REGION_TEXT_LOAD
>>> > +
>>>
>>> This is the wrong linker command file. This stuff should be in
>>>
>>> spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml
>>>
>>> with an output section name like ".stm32h7_sram_3" and corresponding
>>> input section names. Why do you need absolute addresses here?
>>>
>>> --
>>> embedded brains GmbH
>>> Herr Sebastian HUBER
>>> Dornierstr. 4
>>> 82178 Puchheim
>>> Germany
>>> email: sebastian.hu...@embedded-brains.de
>>> phone: +49-89-18 94 741 - 16
>>> fax:   +49-89-18 94 741 - 08
>>>
>>> Registergericht: Amtsgericht München
>>> Registernummer: HRB 157899
>>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>>> Unsere Datenschutzerklärung finden Sie hier:
>>> https://embedded-brains.de/datenschutzerklaerung/
>>>
>>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

The following link contains more theoretical information about why these
sections were placed at these addresses:
https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices

Kind Regards
Robin

On Wed, 3 Feb 2021 at 14:44, Robin Müller  wrote:

> The DMA descriptors need to be placed at the start of the SRAM3 and need
> to be aligned in a certain way. The RX buffer will take up the first
> (slightly less than) 16 kB of SRAM3 but needs to be placed
> behind the DMA descriptors. It also needs to be placed in a way that the
> MPU configuration required for the DMA descriptors will not do something
> with the RX buffers.
> In the example provided by STM32, the first 256 bytes are configured by
> MPU Config.
>
> Kind Regards
> Robin
>
>
>
> On Wed, 3 Feb 2021 at 13:43, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 02/02/2021 20:10, Robin Mueller wrote:
>>
>> > + /* Not an ideal solution but required for lwIP on the STM32H7 BSP.
>> > + This places the DMA descriptors for lwIP at the start of SRAM3.
>> > + The MPU still needs to be configured for the DMA descriptor
>> regions to be
>> > + bufferable, non-cacheable, non-shareable (first 256 bytes) */
>> > + .lwip_sec_stm32h7 (NOLOAD) : ALIGN_WITH_INPUT {
>> > + . = ABSOLUTE(0x3004);
>> > + *(.RxDecripSection)
>> > + . = ABSOLUTE(0x30040060);
>> > + *(.TxDecripSection)
>> > + . = ABSOLUTE(0x30040200);
>> > + *(.RxArraySection)
>> > + } >SRAM_3 AT> REGION_TEXT_LOAD
>> > +
>>
>> This is the wrong linker command file. This stuff should be in
>>
>> spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml
>>
>> with an output section name like ".stm32h7_sram_3" and corresponding
>> input section names. Why do you need absolute addresses here?
>>
>> --
>> embedded brains GmbH
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.hu...@embedded-brains.de
>> phone: +49-89-18 94 741 - 16
>> fax:   +49-89-18 94 741 - 08
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRB 157899
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

The DMA descriptors need to be placed at the start of the SRAM3 and need to
be aligned in a certain way. The RX buffer will take up the first (slightly
less than) 16 kB of SRAM3 but needs to be placed
behind the DMA descriptors. It also needs to be placed in a way that the
MPU configuration required for the DMA descriptors will not do something
with the RX buffers.
In the example provided by STM32, the first 256 bytes are configured by MPU
Config.

Kind Regards
Robin



On Wed, 3 Feb 2021 at 13:43, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 02/02/2021 20:10, Robin Mueller wrote:
>
> > + /* Not an ideal solution but required for lwIP on the STM32H7 BSP.
> > + This places the DMA descriptors for lwIP at the start of SRAM3.
> > + The MPU still needs to be configured for the DMA descriptor
> regions to be
> > + bufferable, non-cacheable, non-shareable (first 256 bytes) */
> > + .lwip_sec_stm32h7 (NOLOAD) : ALIGN_WITH_INPUT {
> > + . = ABSOLUTE(0x3004);
> > + *(.RxDecripSection)
> > + . = ABSOLUTE(0x30040060);
> > + *(.TxDecripSection)
> > + . = ABSOLUTE(0x30040200);
> > + *(.RxArraySection)
> > + } >SRAM_3 AT> REGION_TEXT_LOAD
> > +
>
> This is the wrong linker command file. This stuff should be in
>
> spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml
>
> with an output section name like ".stm32h7_sram_3" and corresponding
> input section names. Why do you need absolute addresses here?
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] STM32H7 doc update

[Robin Müller]

I'd just like to bump my patch. The last changes were just the formatting
changes from the code review.


Kind Regards
Robin

On Tue, 12 Jan 2021 at 12:36, Robin Mueller 
wrote:

> ---
>
> Added doc for board variation, added some  fixes
> from code review. (typo and line width formatting)
>
>  user/bsps/arm/stm32h7.rst | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/user/bsps/arm/stm32h7.rst b/user/bsps/arm/stm32h7.rst
> index 3eee511..e1b9d8c 100644
> --- a/user/bsps/arm/stm32h7.rst
> +++ b/user/bsps/arm/stm32h7.rst
> @@ -11,16 +11,32 @@ This BSP supports the
>  The BSP is known to run on these boards:
>
>  * `STM32H743I-EVAL 2 <
> https://www.st.com/en/evaluation-tools/stm32h743i-eval.html>`_
> +* `STM32H743ZI-Nucleo <
> https://www.st.com/en/evaluation-tools/nucleo-h743zi.html>`_
>
>  Clock Driver
>  
>
> -The clock driver uses the `ARMv7-M Systick` module.
> +The clock driver uses the `ARMv7-M Systick` module. The HSE (external
> +oscillator) value can also be different for different evaluation or
> custom
> +boards, so it is recommended to check the default values of the BSP.
>
>  Console Driver
>  --
>
>  The console driver supports the on-chip UART and USART modules.
> +Different board variations use different GPIO pins and blocks for the
> default
> +communication UART and it is recommended to check whether the default
> +configuration provided is valid in the BSP.
> +
> +To specify that the BSP should be built for the STM32H743ZI-Nucleo board,
> +users can supply ``STM32H743ZI_NUCLEO == True`` to ``config.ini`` when
> +building the BSP.
> +
> +Alternatively, users can supply the configuration structs defined in
> ``hal.h``
> +in the applicaton for other boards. For the console driver, the
> +``stm32h7_usartX_config`` structs are used to configure the GPIO pins and
> other
> +parameters. The default implementations can be found in
> +``bsps/arm/stm32ht/console`` in the RTEMS sources.
>
>  Network Interface Driver
>  
> --
> 2.23.0.windows.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] This patch adds support for a STM32H7 variation

[Robin Müller]

Hi,

I can test the new BSP variant on my Nucleo board. Let me know when you
have pushed the changes.

Kind Regards
Robin

On Sun, 10 Jan 2021 at 01:02, Chris Johns  wrote:

> On 9/1/21 7:49 am, Sebastian Huber wrote:
> > On 08/01/2021 15:30, Joel Sherrill wrote:
> >> On Fri, Jan 8, 2021 at 6:58 AM Robin Müller  >> <mailto:robin.muelle...@gmail.com>> wrote:
> >>
> >> Are they really 12 BSPs or just build variants of this one BSP family?
> >>
> >> If just variants, I have come full circle on how I feel about having
> lots of
> >> BSP variants. I have seen multiple cases over the past few months where
> a new
> >> user only realized their board was supported because it shows up as a
> variant
> >> or it was explicitly mentioned in the user facing documentation by
> model.
> >> Either we explicitly have a variant with the model name or the list of
> models
> >> is in the guide with explicit instructions on how to build for them. We
> have
> >> the precedence on the Leon3 that we added variants to match specific
> hardware
> >> because it simplified the presentation to users. Little practical
> difference
> >> in the code but it makes a better user presentation.
> >>
> >> I know adding variants adds time to the full build sweep but I no
> longer care.
> >> It is just more time in the background on fast servers. None of us are
> killing
> >> time waiting for all the BSPs to do a test build.
>
> It does effect testing and also releases unless we can tie the build logs
> to the
> code stability. Filtering the build logs is possible with some scripting
> and
> procmail but it is another task someone needs to do before it becomes
> useful.
>
> Is it possible to determine from the build configuration which BSPs are
> functionally equivalent? We could then minimise the build set and testing
>
> >> The important thing is that search engines find the board someone is
> searching
> >> for and find that RTEMS supports it. This is the only
> marketing/advertising we
> >> have as a project. I think we have to be conscious that Google indexes
> our
> >> manuals and that if we support something, putting it in the
> documentation both
> >> helps users and helps market RTEMS.
> > Good, I was about to write something similar. Adding a BSP variant is
> simple.
>
> Yes having the boards supported listed is a good thing.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] This patch adds support for a STM32H7 variation

[Robin Müller]

Hi Sebastian,

That would also be a way. The question is whether all other board variation
should be included as well.
There are 12 boards listed in the STM32CubeH7 repository example
applications and I have not checked which pin and HSE values
these boards use or if there are any other important differences.. I would
guess that it will not be necessary to add 12 BSPs for each
board variation because some board settings will be identical, but maybe it
would make sense to determine the board differences and look where
it makes sense to add new BSPs..

In any case, I don't really know how to add BSPs (yet), my patch was just
the quickest way I could think of to make the Nucleo board work
correctly (at least console and clock, what I've tested so far) out of the
box with the correct config.ini settings.

Kind Regards
Robin


On Fri, 8 Jan 2021 at 06:35, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Robin,
>
> thanks for the updated patch. I am not sure if we should address the
> problem with a STM32H743ZI_NUCLEO option. An alternative would be to add
> a new BSP variant, e.g. stm32h743zi_nucleo, and two new options
> STM32H7_HSE_FREQUENCY and STM32H7_USART3_USE_GPIOD_PIN_8_PIN_9 with a
> default value determined by the BSP variant.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Squashed commit of the following:

[Robin Müller]

Hello Gedare,

I made the consistency changes. I am not sure about wrapping everything in
the __rtems__ define, I did wrap the include because every bspopts.h
include I saw was wrapped in that as well (if defines inside bspopts.h
might be used). I never saw whole code blocks wrapped by that define
though. About system_stm32h7xx.c : I am not sure, I don't know where it
gets defined first (it's a source file, so I would guess in the header
first, but the header is not included explicitely?). There was also another
define that determined if the HAL headers are included at all in
stm32h7xx.h (USE_HAL_DRIVER) and this one is not defined by default. I
think it's better if it's explicit that another HSE value is used for the
board.

I'll send the updated patch and I will also send a patch for the STM32H7
documentation.

Kind Regards
Robin

On Tue, 5 Jan 2021 at 17:01, Gedare Bloom  wrote:

> Hi Robin,
>
> On Tue, Jan 5, 2021 at 5:20 AM Robin.Mueller 
> wrote:
>
>> commit 8bcd2c40ac28bf575d6e012c57e3546799eefb40
>> Author: Robin.Mueller 
>> Date:   Tue Jan 5 12:16:19 2021 +0100
>>
>> deleted old cfg file
>>
>> commit 2da3db8799018e98d2237ee54b13f163690fbeb2
>> Author: Robin.Mueller 
>> Date:   Tue Jan 5 12:13:03 2021 +0100
>>
>> removed some moved components
>>
>> commit d63a12b6fde4c6025be5e755bb4fde547f968979
>> Author: Robin.Mueller 
>> Date:   Tue Jan 5 12:10:37 2021 +0100
>>
>> reverted gitignore change
>>
>> commit 6ac23279ddc8d8cf5b57c38f7c0e994f225f74af
>> Author: Robin.Mueller 
>> Date:   Tue Jan 5 12:09:31 2021 +0100
>>
>> merged changes from upstream
>>
>> commit a51d8f3c977abb23871dea6926de75a26592db09
>> Merge: d238213dd6 0cb2f4f4de
>> Author: Robin.Mueller 
>> Date:   Mon Jan 4 16:04:26 2021 +0100
>>
>> Merge branch 'mueller/nucleo-patch' into mueller/nucleo_another_try
>>
>> commit 0cb2f4f4deb0015f96866bc00869095b2e637437
>> Author: Robin.Mueller 
>> Date:   Mon Jan 4 16:04:03 2021 +0100
>>
>> better help output
>>
>>
>> commit 4e2645f7586508b0f68e2fb19f888e92d4ac5530
>> Author: Robin.Mueller 
>> Date:   Mon Jan 4 16:00:46 2021 +0100
>>
>> functions made public
>>
>> commit d238213dd657dcdd4825c8fa3db33422ecb37719
>> Merge: 3a243aabc1 a6675d388e
>> Author: Robin.Mueller 
>> Date:   Mon Jan 4 15:52:35 2021 +0100
>>
>> Merge branch 'mueller/nucleo-patch' into mueller/nucleo_another_try
>>
>> commit a6675d388e174ad23ce6d61b3084742c056186be
>> Author: Robin.Mueller 
>> Date:   Mon Jan 4 15:51:39 2021 +0100
>>
>> prepared patch
>>
>> commit 3a243aabc1cb933a1d1a0ed86eea0c9f54d97f90
>> Merge: 50a549d493 f867e7b6f4
>> Author: Robin.Mueller 
>> Date:   Mon Jan 4 15:48:18 2021 +0100
>>
>> Merge branch 'master' into mueller/nucleo_another_try
>>
>> commit 50a549d4938dc2681ec0cf18aa49bd1c74e1d13d
>> Author: Robin.Mueller 
>> Date:   Mon Jan 4 13:01:31 2021 +0100
>>
>> small tweak
>>
>> commit d920a820d4ad442dfb10ff733cef43b65b4bdea7
>> Author: Robin.Mueller 
>> Date:   Mon Jan 4 12:59:25 2021 +0100
>>
>> reverted stuff and made definitions weak
>>
>> commit ce36d0583959c146e48b3215b3b9000bd4a9ab66
>> Author: Robin.Mueller 
>> Date:   Mon Jan 4 11:24:03 2021 +0100
>>
>> stm32h7 config
>>
>> commit 3f460f0073d67f75bdd8ded2c02c0391bef9a131
>> Author: Robin.Mueller 
>> Date:   Sat Jan 2 18:51:47 2021 +0100
>>
>> correct uart chosen
>>
>> commit b6f27f08107450e832fa2dea30f8e7dae925fd31
>> Author: Robin.Mueller 
>> Date:   Sat Jan 2 16:39:25 2021 +0100
>>
>> trying to load bspopts
>>
>> commit cb345ef21d4ef442290715ce1e5fce48db91119b
>> Merge: 93c21c74f9 a299c4feef
>> Author: Robin Mueller 
>> Date:   Thu Dec 17 23:10:56 2020 +0100
>>
>> Merge remote-tracking branch 'upstream/master' into
>> mueller/added-nucleo-yaml
>>
>> commit 93c21c74f928796cbc618c7c4aef492244973402
>> Merge: 51104ac6a5 fe58f6ce4b
>> Author: Robin Mueller 
>> Date:   Fri Nov 27 00:00:59 2020 +0100
>>
>> Merge remote-tracking branch 'upstream/master' into
>> mueller/added-nucleo-yaml
>>
>> commit 51104ac6a5b700a65efb3ecca22b3c5df41a80f5
>> Author: Robin.Mueller 
>> Date:   Thu Nov 26 11:25:22 2020 +0100
>>
>> value hardcoded again
>>
>> commit 2d96d82a84ca4f96a1b17406a0aefe07bb52510e
>> Author: Robin.Mueller 
>> Date:   Thu Nov 26 11:15:38 2020 +0100
>>
>> define not propagated to header
>>
>> commit 706a4542c3bdc963497d6404602dcf24391dea01
>> Author: Robin.Mueller 
>> Date:   Wed Nov 25 23:48:36 2020 +0100
>>
>> comment moved
>>
>> commit bd8359bbd7c3d154f401a1ffdf16d90a6e8b34dd
>> Author: Robin.Mueller 
>> Date:   Wed Nov 25 21:40:19 2020 +0100
>>
>> moved config option
>>
>> commit ede140e783479c09fc82a0008651e07b612dc488
>> Author: Robin.Mueller 
>> Date:   Wed Nov 25 21:37:31 2020 +0100
>>
>> added build dependency
>>
>> commit 4e5c1404ce9277eaadd1b7e697310fc97206000f
>> Author: Robin.Mueller 
>> Date:   Wed Nov 25 20:16:45 2020 +0100
>>
>> trying to make it externally configurable
>>
>> commit 4fbd5f99683518c3442612c639b3894036de8b1e
>> Author: 

Re: [PATCH 1/3] prepared patch

[Robin Müller]

Patch can also be found here: https://devel.rtems.org/ticket/4209#comment:3

Kind Regards
Robin

On Mon, 4 Jan 2021 at 16:12, Robin.Mueller 
wrote:

> I added the weak attribute to some configuration structs so users can can
> supply their own configuration
> structs (otherwise I got redeclaration linker errors).
> ---
>  bsps/arm/stm32h7/console/console-usart3.c | 23 ++-
>  bsps/arm/stm32h7/include/stm32h7xx_hal_conf.h |  8 +++
>  bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h |  1 +
>  bsps/arm/stm32h7/start/stm32h7-config.c   | 11 ++---
>  bsps/arm/stm32h7/start/system_stm32h7xx.c |  6 +
>  spec/build/bsps/arm/stm32h7/bspstm32h7.yml|  2 ++
>  spec/build/bsps/arm/stm32h7/opth743nucleo.yml | 13 +++
>  7 files changed, 60 insertions(+), 4 deletions(-)
>  create mode 100644 spec/build/bsps/arm/stm32h7/opth743nucleo.yml
>
> diff --git a/bsps/arm/stm32h7/console/console-usart3.c
> b/bsps/arm/stm32h7/console/console-usart3.c
> index 6e0a10fe46..c84f6eb417 100644
> --- a/bsps/arm/stm32h7/console/console-usart3.c
> +++ b/bsps/arm/stm32h7/console/console-usart3.c
> @@ -25,13 +25,33 @@
>   * POSSIBILITY OF SUCH DAMAGE.
>   */
>
> +#ifdef __rtems__
> +#include 
> +#endif
> +
>  #ifdef HAVE_CONFIG_H
>  #include "config.h"
>  #endif
>
>  #include 
>
> -static const stm32h7_uart_config stm32h7_usart3_config = {
> +#if STM32H743ZI_NUCLEO == 1
> +__attribute__((weak)) static const stm32h7_uart_config
> stm32h7_usart3_config = {
> +  .gpio = {
> +.regs = GPIOD,
> +.config = {
> +  .Pin = GPIO_PIN_8 | GPIO_PIN_9,
> +  .Mode = GPIO_MODE_AF_PP,
> +  .Pull = GPIO_NOPULL,
> +  .Speed = GPIO_SPEED_FREQ_LOW,
> +  .Alternate = GPIO_AF7_USART3
> +}
> +  },
> +  .irq = USART3_IRQn,
> +  .device_index = 2
> +};
> +#else
> +__attribute__((weak)) static const stm32h7_uart_config
> stm32h7_usart3_config = {
>.gpio = {
>  .regs = GPIOB,
>  .config = {
> @@ -45,6 +65,7 @@ static const stm32h7_uart_config stm32h7_usart3_config =
> {
>.irq = USART3_IRQn,
>.device_index = 2
>  };
> +#endif
>
>  stm32h7_uart_context stm32h7_usart3_instance = {
>.uart = {
> diff --git a/bsps/arm/stm32h7/include/stm32h7xx_hal_conf.h
> b/bsps/arm/stm32h7/include/stm32h7xx_hal_conf.h
> index d423e4f782..7dd73075ba 100644
> --- a/bsps/arm/stm32h7/include/stm32h7xx_hal_conf.h
> +++ b/bsps/arm/stm32h7/include/stm32h7xx_hal_conf.h
> @@ -21,6 +21,9 @@
>  #ifndef __STM32H7xx_HAL_CONF_H
>  #define __STM32H7xx_HAL_CONF_H
>
> +#ifdef __rtems__
> +#include 
> +#endif /* __rtems__ */
>  #ifdef __cplusplus
>   extern "C" {
>  #endif
> @@ -103,7 +106,12 @@
>*(when HSE is used as system clock source, directly or through
> the PLL).
>*/
>  #if !defined  (HSE_VALUE)
> +#if STM32H743ZI_NUCLEO == 1
> +// HSE for the STM32H743ZI Nucleo
> +#define HSE_VALUE((uint32_t)800)
> +#else
>  #define HSE_VALUE((uint32_t)2500) /*!< Value of the External
> oscillator in Hz : FPGA case fixed to 60MHZ */
> +#endif
>  #endif /* HSE_VALUE */
>
>  #if !defined  (HSE_STARTUP_TIMEOUT)
> diff --git a/bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h
> b/bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h
> index e9fecc4aa0..b171f7dac7 100644
> --- a/bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h
> +++ b/bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h
> @@ -27,6 +27,7 @@ extern "C" {
>
>  /* Includes
> --*/
>  #include "stm32h7xx_hal_def.h"
> +#include "stm32h7xx_hal_dma.h"
>
>  /** @addtogroup STM32H7xx_HAL_Driver
>* @{
> diff --git a/bsps/arm/stm32h7/start/stm32h7-config.c
> b/bsps/arm/stm32h7/start/stm32h7-config.c
> index 874ad047db..22422f2c38 100644
> --- a/bsps/arm/stm32h7/start/stm32h7-config.c
> +++ b/bsps/arm/stm32h7/start/stm32h7-config.c
> @@ -29,12 +29,17 @@
>  #include "config.h"
>  #endif
>
> +#ifdef __rtems__
> +#include 
> +#endif
> +
>  #include 
>
> +
>  const uint32_t stm32h7_config_pwr_regulator_voltagescaling =
>PWR_REGULATOR_VOLTAGE_SCALE0;
>
> -const RCC_OscInitTypeDef stm32h7_config_oscillator = {
> +__attribute__((weak)) const RCC_OscInitTypeDef stm32h7_config_oscillator
> = {
>.OscillatorType = RCC_OSCILLATORTYPE_HSI | RCC_OSCILLATORTYPE_HSE
>  | RCC_OSCILLATORTYPE_LSE | RCC_OSCILLATORTYPE_HSI48,
>.HSEState = RCC_HSE_ON,
> @@ -54,7 +59,7 @@ const RCC_OscInitTypeDef stm32h7_config_oscillator = {
>.PLL.PLLFRACN = 0
>  };
>
> -const RCC_ClkInitTypeDef stm32h7_config_clocks = {
> +__attribute__((weak)) const RCC_ClkInitTypeDef stm32h7_config_clocks = {
>.ClockType = RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_SYSCLK
>  | RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2
>  | RCC_CLOCKTYPE_D3PCLK1 | RCC_CLOCKTYPE_D1PCLK1,
> @@ -69,7 +74,7 @@ const RCC_ClkInitTypeDef stm32h7_config_clocks = {
>
>  const uint32_t stm32h7_config_flash_latency = FLASH_LATENCY_4;
>
> -const RCC_PeriphCLKInitTypeDef stm32h7_config_peripheral_clocks = {
> +__attribute__((weak)) const 

Re: MSYS2 build: header file missing

[Robin Müller]

Hi Jiri,

Thanks for the quick fix. I was able to build sparc-rtems6 on the Windows
machine with the fix.

So basically, arm-rtesm6 is still problematic because of the missing
headers (but worked on Linux using Canadian Cross Compiling) but with
sparc-rtems6 it's the other way around, it works on Windows now, but not on
Linux when doing CXC. RSB appears to compile SIS for Linux there because it
also loads source files like line linenoise.c which are not compiled on
Windows.

In any case, the tool suites are both working now and I managed to build
related BSPs on Windows without issues using waf.


Kind Regards
Robin

On Fri, 18 Dec 2020 at 23:22, Chris Johns  wrote:

> On 18/12/20 10:24 pm, Sebastian Huber wrote:
> > On 18/12/2020 11:35, Chris Johns wrote:
> >
> >>> Since all parts of RTEMS build now with waf I think it is possible to
> build
> >>> RTEMS applications on Windows without having to install MSYS2/MinGW. It
> >>> should work with only a Python installation, but I haven't tested this
> yet.
> >> This maybe true In theory but I have not been able to achieve it.
> > What was the missing piece?
>
> At a technical level for our tools and building RTEMS I doubt any is
> missing. At
> a practical level you may need git and if you need to build an packages
> that has
> a standard make then you need more than just the tools we create. It was a
> comment on that aspect of developing applications than a specific technical
> issue with our approach.
>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: MSYS2 build: header file missing

[Robin Müller]

Hi Jiri,

Okay, I commented out that header on my Windows 10 machine (Version 20H2,
19042.685) and it compiled.

That error was on a different Linux machine when cross compiling the cross
toolchain for Windows (i686 rtems6-arm worked now, so that's nice). Maybe
this #define is also derived from the current OS?
I could try to supply it manually..

Kind Regards
Robin



On Fri, 18 Dec 2020 at 16:35, Jiri Gaisler  wrote:

>
> On 12/18/20 2:10 PM, Robin Müller wrote:
>
> In case you're interested, this is the fail report for the SIS Cxc build
> on Linux (failed both for i686 and x86_64).
>
> I think it fails because _WIN32_WINNT (windows version) is not defined,
> causing winsock2.h to exclude requires sections.
>
> Build command was:
>  ../source-builder/sb-set-builder
> --prefix=/c/Users/Robin/RTEMS/rtems-tools/rtems/6 --no-install
> --bset-tar-file --host=i686-w64-mingw32 6/rtems-sparc
>
> I had a quick look at this. The first problem with missing arpa/inet.h can
> be fixed by commenting out the include file, as it is not needed:
>
> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I.-DFAST_UART -O2 -g -pipe
> -I/home/rmueller/Documents/RTEMS/rtems-tools/src/rsb/rtems/build/tmp/sb-1000/6/rtems-sparc/c/Users/Robin/RTEMS/rtems-tools/rtems/6/include
> -MT greth.o -MD -MP -MF .deps/greth.Tpo -c -o greth.o greth.c
> greth.c:31:10: fatal error: arpa/inet.h: No such file or directory
>31 | #include 
>
>
> The second problem with winsock2.h is not obvious to me. On my old
> windows7/qemu system, remote.c compiles fine and winsock2.h provides the
> necessary defines. Which windows version are you using where it fails?
>
> I am about to release a new sis version with more RISCV support, so I
> could add fixes for MSYS2 if necessary ...
>
> Regards, Jiri.
>
>
> Kind Regards
> Robin
>
> On Fri, 18 Dec 2020 at 12:49, Robin Müller 
> wrote:
>
>> If I understand correctly, the BSPs can be installed with waf only if the
>> tool suite for the given architecture has been installed.
>> Problem is, the RSB build will fail even if a tiny component is
>> problematic.
>> I thought the tool suite itself is installed using the build commands
>> required by the sources (make, automake, etc).
>> Is it possible to also build these sources with waf?
>>
>> I have tried this cross compiling on linux for windows (I used x86_64
>> instead of i686) because everything was working on Linux, but there are
>> issues with the SIS tool for sparc-rtems6..
>> But SIS is now also problematic on the Windows machine where I almost
>> managed to build everything.
>>
>> Everything except SIS was built by the RSB and I copied the installed
>> files manually to install them and tried to build a BSP (is there actually
>> some script like do-install which will perform this step?)
>> But now some RTEMS tool is missing (rtems-bin2c):
>>
>> $ ./waf configure --prefix=$RTEMS_TOOLS --rtems-bsp=sparc/erc32
>> Setting top to   :
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/src/rtems
>> Setting out to   :
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/src/rtems/build
>> Configure board support package (BSP): sparc/erc32
>> Checking for program 'sparc-rtems6-gcc'  :
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe
>> Checking for program 'sparc-rtems6-g++'  :
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-g++.exe
>> Checking for program 'sparc-rtems6-ar'   :
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
>> Checking for program 'sparc-rtems6-ld'   :
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ld.exe
>> Checking for program 'ar':
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
>> Checking for program 'g++, c++'  :
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-g++.exe
>> Checking for program 'ar':
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
>> Checking for program 'gas, gcc'  :
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe
>> Checking for program 'ar':
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
>> Checking for program 'gcc, cc'   :
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe
>> Checking for program 'ar':
>> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
>> Checking for program 'rtems-bin2c'   : not foun

Re: MSYS2 build: header file missing

[Robin Müller]

In case you're interested, this is the fail report for the SIS Cxc build on
Linux (failed both for i686 and x86_64).

I think it fails because _WIN32_WINNT (windows version) is not defined,
causing winsock2.h to exclude requires sections.

Build command was:
 ../source-builder/sb-set-builder
--prefix=/c/Users/Robin/RTEMS/rtems-tools/rtems/6 --no-install
--bset-tar-file --host=i686-w64-mingw32 6/rtems-sparc

Kind Regards
Robin

On Fri, 18 Dec 2020 at 12:49, Robin Müller 
wrote:

> If I understand correctly, the BSPs can be installed with waf only if the
> tool suite for the given architecture has been installed.
> Problem is, the RSB build will fail even if a tiny component is
> problematic.
> I thought the tool suite itself is installed using the build commands
> required by the sources (make, automake, etc).
> Is it possible to also build these sources with waf?
>
> I have tried this cross compiling on linux for windows (I used x86_64
> instead of i686) because everything was working on Linux, but there are
> issues with the SIS tool for sparc-rtems6..
> But SIS is now also problematic on the Windows machine where I almost
> managed to build everything.
>
> Everything except SIS was built by the RSB and I copied the installed
> files manually to install them and tried to build a BSP (is there actually
> some script like do-install which will perform this step?)
> But now some RTEMS tool is missing (rtems-bin2c):
>
> $ ./waf configure --prefix=$RTEMS_TOOLS --rtems-bsp=sparc/erc32
> Setting top to   :
> C:/Users/Robin/Documents/RTEMS/rtems-tools/src/rtems
> Setting out to   :
> C:/Users/Robin/Documents/RTEMS/rtems-tools/src/rtems/build
> Configure board support package (BSP): sparc/erc32
> Checking for program 'sparc-rtems6-gcc'  :
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe
> Checking for program 'sparc-rtems6-g++'  :
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-g++.exe
> Checking for program 'sparc-rtems6-ar'   :
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
> Checking for program 'sparc-rtems6-ld'   :
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ld.exe
> Checking for program 'ar':
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
> Checking for program 'g++, c++'  :
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-g++.exe
> Checking for program 'ar':
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
> Checking for program 'gas, gcc'  :
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe
> Checking for program 'ar':
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
> Checking for program 'gcc, cc'   :
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe
> Checking for program 'ar':
> C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
> Checking for program 'rtems-bin2c'   : not found
> Could not find the program ['rtems-bin2c']
> (complete log in
> C:/Users/Robin/Documents/RTEMS/rtems-tools/src/rtems/build/config.log)
>
> In general the build process on Windows seems to be more "brittle" than on
> Linux, so maybe installers would be a good idea? I generally installed
> cross-compilers (e.g. arm-none-eabi-gcc) on Windows
> using installers (for example https://xpack.github.io/arm-none-eabi-gcc/)
> and have made very good experience with that.
>
> Kind Regards
> Robin
>
> On Fri, 18 Dec 2020 at 12:24, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 18/12/2020 11:35, Chris Johns wrote:
>>
>> >> Since all parts of RTEMS build now with waf I think it is possible to
>> build RTEMS applications on Windows without having to install MSYS2/MinGW.
>> It should work with only a Python installation, but I haven't tested this
>> yet.
>> > This maybe true In theory but I have not been able to achieve it.
>> What was the missing piece?
>>
>> --
>> embedded brains GmbH
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.hu...@embedded-brains.de
>> phone: +49-89-18 94 741 - 16
>> fax:   +49-89-18 94 741 - 08
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRB 157899
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>>
>> 

Re: MSYS2 build: header file missing

[Robin Müller]

If I understand correctly, the BSPs can be installed with waf only if the
tool suite for the given architecture has been installed.
Problem is, the RSB build will fail even if a tiny component is
problematic.
I thought the tool suite itself is installed using the build commands
required by the sources (make, automake, etc).
Is it possible to also build these sources with waf?

I have tried this cross compiling on linux for windows (I used x86_64
instead of i686) because everything was working on Linux, but there are
issues with the SIS tool for sparc-rtems6..
But SIS is now also problematic on the Windows machine where I almost
managed to build everything.

Everything except SIS was built by the RSB and I copied the installed files
manually to install them and tried to build a BSP (is there actually some
script like do-install which will perform this step?)
But now some RTEMS tool is missing (rtems-bin2c):

$ ./waf configure --prefix=$RTEMS_TOOLS --rtems-bsp=sparc/erc32
Setting top to   :
C:/Users/Robin/Documents/RTEMS/rtems-tools/src/rtems
Setting out to   :
C:/Users/Robin/Documents/RTEMS/rtems-tools/src/rtems/build
Configure board support package (BSP): sparc/erc32
Checking for program 'sparc-rtems6-gcc'  :
C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe
Checking for program 'sparc-rtems6-g++'  :
C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-g++.exe
Checking for program 'sparc-rtems6-ar'   :
C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
Checking for program 'sparc-rtems6-ld'   :
C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ld.exe
Checking for program 'ar':
C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
Checking for program 'g++, c++'  :
C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-g++.exe
Checking for program 'ar':
C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
Checking for program 'gas, gcc'  :
C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe
Checking for program 'ar':
C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
Checking for program 'gcc, cc'   :
C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe
Checking for program 'ar':
C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-ar.exe
Checking for program 'rtems-bin2c'   : not found
Could not find the program ['rtems-bin2c']
(complete log in
C:/Users/Robin/Documents/RTEMS/rtems-tools/src/rtems/build/config.log)

In general the build process on Windows seems to be more "brittle" than on
Linux, so maybe installers would be a good idea? I generally installed
cross-compilers (e.g. arm-none-eabi-gcc) on Windows
using installers (for example https://xpack.github.io/arm-none-eabi-gcc/)
and have made very good experience with that.

Kind Regards
Robin

On Fri, 18 Dec 2020 at 12:24, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 18/12/2020 11:35, Chris Johns wrote:
>
> >> Since all parts of RTEMS build now with waf I think it is possible to
> build RTEMS applications on Windows without having to install MSYS2/MinGW.
> It should work with only a Python installation, but I haven't tested this
> yet.
> > This maybe true In theory but I have not been able to achieve it.
> What was the missing piece?
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Quick Start improvements: Tickets updated

[Robin Müller]

Hi,

I updated the RTEMS tickets with the patches for the Quick Start guide
(also neat that there is the comparison view):

BSP tests:
https://devel.rtems.org/ticket/4188

Python Encoding Error:
https://devel.rtems.org/ticket/4183

Some version 5/6 improvements / clarifications, also added how to write a
small helper script which I have found very useful:
https://devel.rtems.org/ticket/4187

Would be great if you could assign those issues :-)

Kind Regards
Robin
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

MSYS2 build: header file missing

[Robin Müller]

Hi,

The RSB was updasted because there were some issues with GMP and I tested
whether this also fixed my MSYS2 build process for the RTEMS tools.

I now get a header file missing error when building newlib:


Making all in arm

In file included from
../../../../../../../../../../gnu-mirror-gcc-1cdad8b/newlib/libm/machine/arm/../../math/s_floor.c:65,

 from
../../../../../../../../../../gnu-mirror-gcc-1cdad8b/newlib/libm/machine/arm/s_floor.c:39:

../../../../../../../../../../gnu-mirror-gcc-1cdad8b/newlib/libm/machine/arm/../../../../newlib/libm/common/fdlibm.h:18:10:
fatal error: math_config.h: No such file or directory

   18 | #include "math_config.h"


I attached the tail of the RSB report. I will also try to build with
jobs=none, but did anyone have this issue before?

Kind Regards
Robin
Making all in arm

make[9]: Entering directory 
'/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/build/arg1n6xwm1/build/arm-rtems6/eb/thumb/armv7-r+fp/hard/newlib/libm/machine/arm'

/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/build/arg1n6xwm1/build/./gcc/xgcc
 
-B/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/build/arg1n6xwm1/build/./gcc/
 -nostdinc 
-B/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/build/arg1n6xwm1/build/arm-rtems6/eb/thumb/armv7-r+fp/hard/newlib/
 -isystem 
/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/build/arg1n6xwm1/build/arm-rtems6/eb/thumb/armv7-r+fp/hard/newlib/targ-include
 -isystem 
/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/build/arg1n6xwm1/gnu-mirror-gcc-1cdad8b/newlib/libc/include
 -B/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/arm-rtems6/bin/ 
-B/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/arm-rtems6/lib/ 
-isystem 
/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/arm-rtems6/include 
-isystem 
/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/arm-rtems6/sys-include 
 -mbig-endian -mthumb -march=armv7-r+fp -mfloat-abi=hard 
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" 
-DPACKAGE_VERSION=\"4.0.0\" -DPACKAGE_STRING=\"newlib\ 4.0.0\" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I. 
-I../../../../../../../../../../gnu-mirror-gcc-1cdad8b/newlib/libm/machine/arm 
-I 
../../../../../../../../../../gnu-mirror-gcc-1cdad8b/newlib/libm/machine/arm/../../../../newlib/libm/common
 -fno-builtin -ffunction-sections -fdata-sections  -D_COMPILING_NEWLIB 
-DCLOCK_PROVIDED -DMALLOC_PROVIDED -DEXIT_PROVIDED -DSIGNAL_PROVIDED 
-DGETREENT_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP 
-DHAVE_BLKSIZE -DHAVE_FCNTL -DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT 
-D_NO_GETUT -D_NO_GETPASS -D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN 
-D_NO_POSIX_SPAWN -DHAVE_INIT_FINI  -g -O2  -mbig-endian -mthumb 
-march=armv7-r+fp -mfloat-abi=hard -c -o lib_a-e_sqrt.o `test -f 'e_sqrt.c' || 
echo 
'../../../../../../../../../../gnu-mirror-gcc-1cdad8b/newlib/libm/machine/arm/'`e_sqrt.c

/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/build/arg1n6xwm1/build/./gcc/xgcc
 
-B/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/build/arg1n6xwm1/build/./gcc/
 -nostdinc 
-B/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/build/arg1n6xwm1/build/arm-rtems6/eb/thumb/armv7-r+fp/hard/newlib/
 -isystem 
/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/build/arg1n6xwm1/build/arm-rtems6/eb/thumb/armv7-r+fp/hard/newlib/targ-include
 -isystem 
/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/build/arg1n6xwm1/gnu-mirror-gcc-1cdad8b/newlib/libc/include
 -B/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/arm-rtems6/bin/ 
-B/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/arm-rtems6/lib/ 
-isystem 
/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/arm-rtems6/include 
-isystem 
/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/arm-rtems6/sys-include 
 -mbig-endian -mthumb -march=armv7-r+fp -mfloat-abi=hard 
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" 
-DPACKAGE_VERSION=\"4.0.0\" -DPACKAGE_STRING=\"newlib\ 4.0.0\" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I. 
-I../../../../../../../../../../gnu-mirror-gcc-1cdad8b/newlib/libm/machine/arm 
-I 
../../../../../../../../../../gnu-mirror-gcc-1cdad8b/newlib/libm/machine/arm/../../../../newlib/libm/common
 -fno-builtin -ffunction-sections -fdata-sections  -D_COMPILING_NEWLIB 
-DCLOCK_PROVIDED -DMALLOC_PROVIDED -DEXIT_PROVIDED -DSIGNAL_PROVIDED 
-DGETREENT_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP 
-DHAVE_BLKSIZE -DHAVE_FCNTL -DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT 
-D_NO_GETUT -D_NO_GETPASS -D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN 
-D_NO_POSIX_SPAWN -DHAVE_INIT_FINI  -g -O2  -mbig-endian -mthumb 
-march=armv7-r+fp -mfloat-abi=hard -c -o lib_a-ef_sqrt.o `test -f 'ef_sqrt.c' 
|| echo 
'../../../../../../../../../../gnu-mirror-gcc-1cdad8b/newlib/libm/machine/arm/'`ef_sqrt.c

/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/build/arg1n6xwm1/build/./gcc/xgcc
 

Re: CMake support

[Robin Müller]

Hi.

I now implemented pkg-config parsing and it works nicely with the tools
given by CMake / kitware. I was able to build the hello application with
the automatic pkg flag parsing for sparc/erc32, sparc/leon3 and arm/stm32h7.
I do not know exactly when this feature was added to be honest. I set the
minimum required version for CMake to 3.15 in my applications (not sure
whether I even use the feature which required this anymore) and have not
set a minimum requirement in the RTEMS support files yet.

It is still possible to disable the CMake PKG parsing and add RTEMS flags
manually for a given BSP by supplying a special define. I am also
considering adding the PKG parse variables to the CMakeCache so they can be
used globally and read in the CMake GUI or with ccmake.

I significantly improved the documentation both in code and in the main
README (primarily about how the build support can be configured and what
configuration options are required, how to get it working etc.)

I have changed RTEMS_PATH to RTEMS. The version number can already be
supplied or set in the application CMakeLists.txt manually and then there
will be no automatic determination. I can disable the automatic version
determination (it would not break the building process, however not having
a valid version number anywhere, either set manually or passed via command
line AND not able to parsing it will of course break the process) if you
think this is a bad idea.

Kind Regards
Robin

On Mon, 14 Dec 2020 at 01:12, Chris Johns  wrote:

> On 11/12/20 8:58 pm, Stanislav Pankevich wrote:
> > Having this said, I would like to avoid pushing the CMake-way of doing
> things as
> > a better way.
>
> Yeah, lets put that to one side. That is a topic for a coffee or a bar ...
> one
> day :)
>
> > Instead, I could contribute feedback to Robin's work here:
> > https://github.com/rmspacefish/rtems-cmake
> > . For example, I could do
> the
> > exercise of using his Just 3 files to see if our embedded target would
> compile
> > and run. No hard promises about the time frames though until the
> Christmas
> > holidays :)
>
> Your help in testing and suggesting changes would be most welcome. I think
> you
> would benefit from being able to use a standard RTEMS build with an cmake
> compatible method.
>
> Thanks
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CMake support

[Robin Müller]

I added the suggestions by Chris Johns now and performed some more tests
(for example disabling the default compiler checks, custom checks are
required for RTEMS).

I used RTEMS_PREFIX instead of PREFIX because PREFIX appears to be a
reserved name in CMake, and RTEMS_PREFIX is also a little bit more explicit.
It is now possible to set a separate BSP path by supplying RTEMS_PATH and a
different tools path by supplying RTEMS_TOOLS like suggested.

Maybe CMake can also read the .pc pkgfiles in some way to determine
compiler/linker flags automatically, at least Kitware has a module like
this
https://github.com/Kitware/CMake/blob/master/Modules/FindPkgConfig.cmake .

Kind Regards
Robin

On Fri, 11 Dec 2020 at 11:14, Robin Müller 
wrote:

> Hi,
>
> There seems to be positive feedback, thanks for that.
>
> I can adapt the naming to be more consistent with your system.
> My system is currently assuming that the RTEMS tools and the BSP are both
> located at RTEMS_INST
> I guess the first command:
>
> cmake -DPREFIX=/install-point -DRTEMS_BSP=arm/stm32h7
>
> Would have the purpose to install the BSP itself? Right now, I also used
> the tools path to autodetermine the RTEMS version
> if the version is not supplied manually.cmake by extracting the last
> number in the supplied RTEMS_INST path.
>
> I have not really thought about the install process yet, I simply built
> the binary in a separate folder out of source like normally done in CMake.
> But this should generally be possible, CMake has an install command as
> well and the install location can be set using CMAKE_INSTALL_PREFIX
>
> Is it possible to get the pkgconfig files without building the BSPs? That
> would be good so more hardware configurations can be added without having
> to build every BSP.
>
> Kind Regards
> Robin
>
> On Fri, 11 Dec 2020 at 10:59, Stanislav Pankevich 
> wrote:
>
>> Hi all,
>>
>> > I was wondering whether CMake support or an example is available or
>> will be added in the future. We are using a framework which has different
>> abstraction layers for OSes like (embedded) Linux, RTEMS and FreeRTOS, but
>> we would like to use the same build system to build applications and right
>> now CMake is our favourite because other tools like the Catch2 test
>> framework are also built with CMake and there is a lot more
>> documentation available for CMake.
>>
>> I would like to share our (PTS GmbH, Berlin) experience of using CMake
>> with RTEMS. Our case is similar to that of Robin Müller's and our own
>> software is all CMake-based. An additional advantage for using CMake for us
>> is that the NASA cFS framework has recently switched to CMake so it is much
>> easier to integrate it into the existing CMake tree. Another integration
>> exercise that we had done before was to build RTEMS and DLR Outpost with
>> CMake and that was also quite straightforward in spite of the fact the DLR
>> Outpost didn't have a CMake layer.
>>
>> ~1 year ago we have captured all the RTEMS compilation and linking
>> commands done by Autoconf for building the ARM-based BSP and converted them
>> into CMakeLists.txt files. At that time, we didn't know how exactly the
>> existing build system worked, so we were very careful and created many
>> CMakeLists files, one for a folder (example: cpukit/libmisc/cpuuse or our
>> own BSP folder). Our setup in the end is not 3 files but 60 files but the
>> idea is the same: configs are collected in a few files, the rest are simply
>> assigning source files to object/library targets. No changes are made to
>> RTEMS source or build files. Instead, we keep all CMake scripts in a
>> separate folder called: rtems-cmake-integration.
>>
>> One of the problems we see with this approach is updating to newer
>> versions of RTEMS. If the CMake files do not co-exist with the RTEMS
>> development tree, then it might be a manual exercise every time to make
>> sure that the CMake integration layer always reflects what the developers
>> of RTEMS intend it to be. Having this said, our 1-year-old CMake setup has
>> been very stable so far, so we might as well stick with it for the time
>> being.
>>
>> Having this said, I would like to avoid pushing the CMake-way of doing
>> things as a better way. Instead, I could contribute feedback to Robin's
>> work here: https://github.com/rmspacefish/rtems-cmake. For example, I
>> could do the exercise of using his Just 3 files to see if our embedded
>> target would compile and run. No hard promises about the time frames though
>> until the Christmas holidays :)
>>
>> Thank you for your attention.
>>
>> On Fri, Dec 11, 2020 at 1:15

Re: CMake support

[Robin Müller]

Hi,

There seems to be positive feedback, thanks for that.

I can adapt the naming to be more consistent with your system.
My system is currently assuming that the RTEMS tools and the BSP are both
located at RTEMS_INST
I guess the first command:

cmake -DPREFIX=/install-point -DRTEMS_BSP=arm/stm32h7

Would have the purpose to install the BSP itself? Right now, I also used
the tools path to autodetermine the RTEMS version
if the version is not supplied manually.cmake by extracting the last number
in the supplied RTEMS_INST path.

I have not really thought about the install process yet, I simply built the
binary in a separate folder out of source like normally done in CMake.
But this should generally be possible, CMake has an install command as well
and the install location can be set using CMAKE_INSTALL_PREFIX

Is it possible to get the pkgconfig files without building the BSPs? That
would be good so more hardware configurations can be added without having
to build every BSP.

Kind Regards
Robin

On Fri, 11 Dec 2020 at 10:59, Stanislav Pankevich 
wrote:

> Hi all,
>
> > I was wondering whether CMake support or an example is available or
> will be added in the future. We are using a framework which has different
> abstraction layers for OSes like (embedded) Linux, RTEMS and FreeRTOS, but
> we would like to use the same build system to build applications and right
> now CMake is our favourite because other tools like the Catch2 test
> framework are also built with CMake and there is a lot more documentation
> available for CMake.
>
> I would like to share our (PTS GmbH, Berlin) experience of using CMake
> with RTEMS. Our case is similar to that of Robin Müller's and our own
> software is all CMake-based. An additional advantage for using CMake for us
> is that the NASA cFS framework has recently switched to CMake so it is much
> easier to integrate it into the existing CMake tree. Another integration
> exercise that we had done before was to build RTEMS and DLR Outpost with
> CMake and that was also quite straightforward in spite of the fact the DLR
> Outpost didn't have a CMake layer.
>
> ~1 year ago we have captured all the RTEMS compilation and linking
> commands done by Autoconf for building the ARM-based BSP and converted them
> into CMakeLists.txt files. At that time, we didn't know how exactly the
> existing build system worked, so we were very careful and created many
> CMakeLists files, one for a folder (example: cpukit/libmisc/cpuuse or our
> own BSP folder). Our setup in the end is not 3 files but 60 files but the
> idea is the same: configs are collected in a few files, the rest are simply
> assigning source files to object/library targets. No changes are made to
> RTEMS source or build files. Instead, we keep all CMake scripts in a
> separate folder called: rtems-cmake-integration.
>
> One of the problems we see with this approach is updating to newer
> versions of RTEMS. If the CMake files do not co-exist with the RTEMS
> development tree, then it might be a manual exercise every time to make
> sure that the CMake integration layer always reflects what the developers
> of RTEMS intend it to be. Having this said, our 1-year-old CMake setup has
> been very stable so far, so we might as well stick with it for the time
> being.
>
> Having this said, I would like to avoid pushing the CMake-way of doing
> things as a better way. Instead, I could contribute feedback to Robin's
> work here: https://github.com/rmspacefish/rtems-cmake. For example, I
> could do the exercise of using his Just 3 files to see if our embedded
> target would compile and run. No hard promises about the time frames though
> until the Christmas holidays :)
>
> Thank you for your attention.
>
> On Fri, Dec 11, 2020 at 1:15 AM Joel Sherrill  wrote:
>
>>
>>
>> On Thu, Dec 10, 2020 at 5:58 PM Chris Johns  wrote:
>>
>>> On 11/12/20 8:51 am, Robin Müller wrote:
>>> > Hello,
>>> >
>>> > I created a repository on github for the first version of what a CMake
>>> support
>>> > for RTEMS might look like:
>>> >
>>> > https://github.com/rmspacefish/rtems-cmake
>>> > <https://github.com/rmspacefish/rtems-cmake>
>>> >
>>>
>>> Awesome and thanks. :)
>>>
>>
>> Agreed. Bear with us being picky. We want things to be as
>> consistent as possible across BSPs, architectures, RTEMS versions,
>> and (hopefully) build systems.
>>
>>
>>> > I tried to extract generic components like determining library paths
>>> into
>>> > functions  (RTEMSGeneric.cmake)
>>> > and there is a hardware specific file where flags for specific
>>> > BSPs/Architectures ca

Re: CMake support

[Robin Müller]

Hello,

I created a repository on github for the first version of what a CMake
support for RTEMS might look like:

https://github.com/rmspacefish/rtems-cmake

I tried to extract generic components like determining library paths into
functions  (RTEMSGeneric.cmake)
and there is a hardware specific file where flags for specific
BSPs/Architectures can be set (RTEMSHardware.cmake).

I was able to compile both the hello project and my STM32 blinky project
with really similar and short CMake files which simply call
rtems_general_config.
with a simple command like

cmake -DRTEMS_INST=$RTEMS_INST -DRTEMS_BSP=arm/stm32h7

or

cmake -DRTEMS_INST=$RTEMS_INST -DRTEMS_BSP=sparc/erc32

and then cmake --build .

I made a test repository containing everything :
https://github.com/rmspacefish/rtems-demo

Maybe this could be a part of the RTEMS repositories? In any case, I think
it can help people who would like to build their application
with CMake. The hello world example for CMake would be similar to building
the waf example for the sparc/erc32, with the difference that the
CMake support would have to be cloned and the build commands are a little
bit different.

Kind Regards
Robin


On Thu, 10 Dec 2020 at 03:26, Chris Johns  wrote:

> On 10/12/20 1:18 am, Joel Sherrill wrote:
> > As I read this thread, this morning, it occurred to me that the Users
> > Manual needs a chapter on build systems for end user applications.
> > It needs to cover fetching the settings from the pkgconfig files and
> using
> > waf, old Makefile infrastructure, etc. Guidance on using cmake, scons,
> > meson, Eclipse managed builds, and Visual Studio would probably be
> > of benefit. Or at least someone may care about each build system. Likely
> > no one individual cares about more than one or two. :)
>
> +1
>
> In this section ...
>
>
> https://docs.rtems.org/branches/master/user/exe/executables.html#building-an-application
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CMake support

[Robin Müller]

Thank you Sebastian. I'm looking at building the example erc32 application
and the blinky executable right now. There is the issue
that determining the BSP path,tool binary determination, all the checking
etc.. bleeds into the application CMakeLists.txt but there is
probably a good way to extract that checking into an external file. It
might even possible to make this generic.

Maybe this would also be interesting for the QuickStart guide or the
examples in general so if you are interested
I could submit a patch for this (if everything works out as expected).

Kind Regards
Robin

On Wed, 9 Dec 2020 at 13:59, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Robin,
>
> you can use whatever build system you want to build your applications.
> You can use pkgconfig to get the necessary flags for a particular BSP
> installation.
>
> On 09/12/2020 13:50, Robin Müller wrote:
> > I also had another question about a specific flag used when linking
> > RTEMS executables.
> > The link command for the example application is the following:
> >
> > arm-rtems6-gcc -mthumb -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard
> > -I=$RTEMS_INST/arm-rtems6/stm32h7/lib/include -MMD
> > -B$RTEMS_INST/arm-rtems6/stm32h7/lib -Wl,--gc-sections init.c.1.o
> > led.c.1.o stm32h7xx_nucleo.c.1.o -o blinky-test.elf -Wl,-Bstatic
> > -Wl,-Bdynamic -qrtems
> >
> > Can anyone tell me the meaning of the -q flag? I did not find anything
> > by running arm-rtems6-gcc --help
>
> This flag selects the right GCC specification for RTEMS. It is
> necessary, just use it.
>
> If you want to know how it works, you have to learn the GCC
> specification format. For a start you can use "arm-rtems6-gcc -dumpspecs".
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

CMake support

[Robin Müller]

Hello,

I was wondering whether CMake support or an example is available or will be
added in the future. We are using a framework which has different
abstraction layers for OSes like (embedded) Linux, RTEMS and FreeRTOS, but
we would like to use the same build system to build applications and right
now CMake is our favourite because other tools like the Catch2 test
framework are also built with CMake and there is a lot more documentation
available for CMake.

I set up a blinky example for a STM32 Nucleo board and had a look at the
raw commands used to build the application and I have not seen anything
special that requires waf explicitly.

I was hoping that I could also build the same application with CMake, eg.
with the following command sequence (with RTEMS_INST being the location
where RTEMS was installed)

mkdir build
cd build
cmake .. -D -DOS_FSFW=rtems -DRTEMS_INST=$RTEMS_INST
cmake --build .

I also had another question about a specific flag used when linking RTEMS
executables.
The link command for the example application is the following:

arm-rtems6-gcc -mthumb -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard
-I=$RTEMS_INST/arm-rtems6/stm32h7/lib/include -MMD
-B$RTEMS_INST/arm-rtems6/stm32h7/lib -Wl,--gc-sections init.c.1.o led.c.1.o
stm32h7xx_nucleo.c.1.o -o blinky-test.elf -Wl,-Bstatic -Wl,-Bdynamic -qrtems

Can anyone tell me the meaning of the -q flag? I did not find anything by
running arm-rtems6-gcc --help

Kind Regards
Robin
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] doc improvements

[Robin Müller]

I will provide another patch with version numbers corrected.

Kind Regards
Robin

On Wed, 2 Dec 2020 at 14:19, Robin Müller  wrote:

> Actually, I just saw that when switching to the 5 branch for the RTEMS
> sources, there is no waf tool (at least I can't run it) so later parts of
> the QuickStart guide won't work..
> I could just leave it like that, but then RTEMS 6 is built and all version
> numbers would have to be corrected..
>
> KInd Regards
> Robin
>
> On Wed, 2 Dec 2020 at 13:59, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello Robin,
>>
>> On 02/12/2020 13:46, Robin Mueller wrote:
>> > ---
>> >   user/start/sources.rst | 9 +
>> >   user/start/tools.rst   | 9 -
>> >   2 files changed, 17 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/user/start/sources.rst b/user/start/sources.rst
>> > index 8c40aa0..fddc439 100644
>> > --- a/user/start/sources.rst
>> > +++ b/user/start/sources.rst
>> > @@ -86,12 +86,21 @@ You can clone the Git repository to get all
>> versions of RTEMS including the
>> >   development head.  Release branches in Git are kept stable however
>> they may
>> >   differ from a release's source archive.
>> >
>> > +For this Quick Start guide, we will switch to the RTEMS 5 branches
>> because the
>> > +master branch does not contain the version 5 `rtems-sparc` build set.
>> > +If you wich to build with the master branch instead, it is recommended
>> to
>> > +replace the version number 5 with version 6 everywhere it is used in
>> the Quick Start guide.
>> the documentation for the master branch should not refer to the RTEMS 5
>> release. So, the right fix is to replace '5' with '6' if needed.
>> > +
>> >   .. code-block:: none
>> >
>> >   mkdir -p $HOME/quick-start/src
>> >   cd $HOME/quick-start/src
>> >   git clone git://git.rtems.org/rtems-source-builder.git rsb
>> > +git checkout origin/5
>> > +git checkout -b 5
>> >   git clone git://git.rtems.org/rtems.git
>> > +git checkout origin/5
>> > +git checkout -b 5
>> >
>> >   The :file:`rsb` repository clone contains the :ref:`RTEMS Source
>> Builder (RSB)
>> >   `.  We clone it into :file:`rsb` to get shorter paths during the
>> tool
>> > diff --git a/user/start/tools.rst b/user/start/tools.rst
>> > index baa2387..e0fe10d 100644
>> > --- a/user/start/tools.rst
>> > +++ b/user/start/tools.rst
>> > @@ -20,7 +20,14 @@ The tool suite for RTEMS and the RTEMS sources are
>> tightly coupled.  For
>> >   example, do not use a RTEMS version 5 tool suite with RTEMS version
>> 4.11
>> >   sources and vice versa.
>> >
>> > -Build and install the tool suite:
>> > +The available build sets can be displayed with:
>> > +
>> > +.. code-block:: none
>> > +
>> > +cd $HOME/quick-start/src/rsb/rtems
>> > +../source-builder/sb-set-builder --list-bsets
>> > +
>> > +Build and install the version 5 tool suite for the SPARC architecture:
>> >
>> >   .. code-block:: none
>> This part looks good to me.
>>
>> --
>> embedded brains GmbH
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.hub...@embedded-brains.de
>> phone: +49-89-18 94 741 - 16
>> fax:   +49-89-18 94 741 - 08
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRB 157899
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] doc improvements

[Robin Müller]

Actually, I just saw that when switching to the 5 branch for the RTEMS
sources, there is no waf tool (at least I can't run it) so later parts of
the QuickStart guide won't work..
I could just leave it like that, but then RTEMS 6 is built and all version
numbers would have to be corrected..

KInd Regards
Robin

On Wed, 2 Dec 2020 at 13:59, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Robin,
>
> On 02/12/2020 13:46, Robin Mueller wrote:
> > ---
> >   user/start/sources.rst | 9 +
> >   user/start/tools.rst   | 9 -
> >   2 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/user/start/sources.rst b/user/start/sources.rst
> > index 8c40aa0..fddc439 100644
> > --- a/user/start/sources.rst
> > +++ b/user/start/sources.rst
> > @@ -86,12 +86,21 @@ You can clone the Git repository to get all versions
> of RTEMS including the
> >   development head.  Release branches in Git are kept stable however
> they may
> >   differ from a release's source archive.
> >
> > +For this Quick Start guide, we will switch to the RTEMS 5 branches
> because the
> > +master branch does not contain the version 5 `rtems-sparc` build set.
> > +If you wich to build with the master branch instead, it is recommended
> to
> > +replace the version number 5 with version 6 everywhere it is used in
> the Quick Start guide.
> the documentation for the master branch should not refer to the RTEMS 5
> release. So, the right fix is to replace '5' with '6' if needed.
> > +
> >   .. code-block:: none
> >
> >   mkdir -p $HOME/quick-start/src
> >   cd $HOME/quick-start/src
> >   git clone git://git.rtems.org/rtems-source-builder.git rsb
> > +git checkout origin/5
> > +git checkout -b 5
> >   git clone git://git.rtems.org/rtems.git
> > +git checkout origin/5
> > +git checkout -b 5
> >
> >   The :file:`rsb` repository clone contains the :ref:`RTEMS Source
> Builder (RSB)
> >   `.  We clone it into :file:`rsb` to get shorter paths during the
> tool
> > diff --git a/user/start/tools.rst b/user/start/tools.rst
> > index baa2387..e0fe10d 100644
> > --- a/user/start/tools.rst
> > +++ b/user/start/tools.rst
> > @@ -20,7 +20,14 @@ The tool suite for RTEMS and the RTEMS sources are
> tightly coupled.  For
> >   example, do not use a RTEMS version 5 tool suite with RTEMS version
> 4.11
> >   sources and vice versa.
> >
> > -Build and install the tool suite:
> > +The available build sets can be displayed with:
> > +
> > +.. code-block:: none
> > +
> > +cd $HOME/quick-start/src/rsb/rtems
> > +../source-builder/sb-set-builder --list-bsets
> > +
> > +Build and install the version 5 tool suite for the SPARC architecture:
> >
> >   .. code-block:: none
> This part looks good to me.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hub...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] doc improvements

[Robin Müller]

 [PATCH] doc improvements is related to ticket
https://devel.rtems.org/ticket/4187 which can then be closed

On Wed, 2 Dec 2020 at 13:46, Robin Mueller 
wrote:

> ---
>  user/start/sources.rst | 9 +
>  user/start/tools.rst   | 9 -
>  2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/user/start/sources.rst b/user/start/sources.rst
> index 8c40aa0..fddc439 100644
> --- a/user/start/sources.rst
> +++ b/user/start/sources.rst
> @@ -86,12 +86,21 @@ You can clone the Git repository to get all versions
> of RTEMS including the
>  development head.  Release branches in Git are kept stable however they
> may
>  differ from a release's source archive.
>
> +For this Quick Start guide, we will switch to the RTEMS 5 branches
> because the
> +master branch does not contain the version 5 `rtems-sparc` build set.
> +If you wich to build with the master branch instead, it is recommended to
> +replace the version number 5 with version 6 everywhere it is used in the
> Quick Start guide.
> +
>  .. code-block:: none
>
>  mkdir -p $HOME/quick-start/src
>  cd $HOME/quick-start/src
>  git clone git://git.rtems.org/rtems-source-builder.git rsb
> +git checkout origin/5
> +git checkout -b 5
>  git clone git://git.rtems.org/rtems.git
> +git checkout origin/5
> +git checkout -b 5
>
>  The :file:`rsb` repository clone contains the :ref:`RTEMS Source Builder
> (RSB)
>  `.  We clone it into :file:`rsb` to get shorter paths during the tool
> diff --git a/user/start/tools.rst b/user/start/tools.rst
> index baa2387..e0fe10d 100644
> --- a/user/start/tools.rst
> +++ b/user/start/tools.rst
> @@ -20,7 +20,14 @@ The tool suite for RTEMS and the RTEMS sources are
> tightly coupled.  For
>  example, do not use a RTEMS version 5 tool suite with RTEMS version 4.11
>  sources and vice versa.
>
> -Build and install the tool suite:
> +The available build sets can be displayed with:
> +
> +.. code-block:: none
> +
> +cd $HOME/quick-start/src/rsb/rtems
> +../source-builder/sb-set-builder --list-bsets
> +
> +Build and install the version 5 tool suite for the SPARC architecture:
>
>  .. code-block:: none
>
> --
> 2.29.2
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel