Does it matter that there is a new stable release coming from the LwIP people
very soon now?
As a target user of the system, I can live with pulling STM’s HAL out of the
RTEMS tree completely and adding it back in myself. The HAL calls in RTEMS are
no different than the fight that just happened
Hi, Robin,
There are a number of ways to manage this, but the first thought that comes to
my mind is:
* Priority #1: protect the license-integrity of the RTEMS src tree. That means
any “license contamination” must be quarantined.
I like the way NetBSD (BSD) handles source covered by some forei
Hi Shiro,
So you mean, retain the STM32 file unchanged in the source tree and then
applying the patch? Or copy it from somewhere and then apply the patch?
I thought of that option as well.
The only issue I see here is that I merged the (example) files provided
by STM32 so that one file can be
Hi, Robin,
Would it be possible to retain the STM32 code, but carve out the “contaminated”
lwIP code into a patch file. Then RTEMS code base remains “clean” and if I,
any user, chose to enable lwIP on STM32, I could do so by applying that patch.
I’d contaminate my src tree, but that’d be my r
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
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
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 STM3
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 th
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 eve
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
On Tue, Apr 27, 2021 at 10: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
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 tr
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
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
Hi Robin,
I'm wading in here a little bit late, but I want to address a couple things.
First, if we will move forward with this, it would be best to separate
the functional patch from the build patch. I.e., split the cmake stuff
from the driver/code improvements. That said, see the following 2
po
This patch adds CMake support to RTEMS lwIP.
It also improves the architecture to make integration
of new BSPs easier.
https://github.com/rmspacefish/rtems-stm32-lwip is a self-contained
repository to test the lwIP integration for the arm/stm32h7
and arm/nucleo-h743zi BSP.
The STM32 port includes
16 matches
Mail list logo
