On 6/5/2023 2:02 am, Gedare Bloom wrote: > On Fri, May 5, 2023 at 9:02 AM <o...@c-mauderer.de> wrote: >> >> Hello Gedare, >> >> thanks for taking a look at the patch set. >> >> Am 05.05.23 um 15:56 schrieb Gedare Bloom: >>> On Thu, May 4, 2023 at 9:01 AM Christian Mauderer >>> <christian.maude...@embedded-brains.de> wrote: >>>> >>>> Hello, >>>> >>>> this patch set for the arm/imxrt BSP family updates the SDK files to the >>>> latest version of the mcux-sdk from NXP and prepares the BSP for further >>>> chip variants. I plan to add a BSP that uses the IMXRT1166 soon. >>>> >>>> As a base for the mcux-sdk files, I now use the NXP git repository >>>> instead of zip files that can be downloaded from NXP. I kept the exact >>>> file system structure to make future updates simpler. >>>> >>>> To import the files, I used a script. It is not a clean script and it >>>> was only tested on a Linux machine. Despite that, I added that script to >>>> the BSP directory in case someone else ever wants to update the >>>> mcux-sdk. Updating the SDK is also possible without the script. It's >>>> just a lot more manual work. So if we don't want a script in that state >>>> in the repository, I can also just keep it on a private branch. >>>> >>> I would recommend that you document the import/update process for the >>> SDK in this BSP (or family) documentation. You could provide a stable >>> external link to the script there instead of including it in the >>> rtems.git tree. I'm not convinced that including scripts etc in the >>> same tree as the source they manipulate is a great practice. It seems >>> to violate separation of concerns. >> >> Disadvantage is that the script (and documentation) is a bit less simple >> to find. But that's not a problem for me (I know where to search) so I >> will adapt that. >> >> De we have an official preferred stable location? Otherwise, I think >> either a small repo in my https://git.rtems.org/christianm or a repo on >> github should be a good place (most likely the later one). >> > This should be fine. ftp.rtems.org should also be usable (in theory) > >>> >>>> The patches that import the new SDK files (patch 0002) and remove the >>>> old ones (patch 0004) are too big for the list. I'll only send the >>>> summary. You can find the full patches here: >>>> >>>> 0002: >>>> https://gitlab.com/c-mauderer/rtems/-/commit/2a871672767a95598e5af42373bfebd3eb9440d3 >>>> 0004: >>>> https://gitlab.com/c-mauderer/rtems/-/commit/2a3e104fa808d7f34a1930344d7b39d11cf39f3d >>>> >>>> The complete patch set is on this branch: >>>> >>>> https://gitlab.com/c-mauderer/rtems/-/commits/cm/20230504_imxrt/ >>>> >>>> At the moment, I import the support files for all currently available >>>> i.MXRT* variants. The headers for the CPU registers are really big (a >>>> few megabytes per header) which makes the complete source tree of the >>>> mcux-sdk bigger than 90MB. If preferred, I can remove most variants and >>>> only keep the ones that are currently used or will be used soon >>>> (IMXRT1052 and IMXRT1166) to reduce the size. >>>> >>> Thanks, I think this is fine. The increase in the number of HAL/SDK >>> that we have to import is starting to concern me in general. I wonder >>> if there is a better way to manage these external sources. >>> >> >> I think I have a language problem here: Is it fine that I push 96MB or >> is it fine that I reduce the size of the patch before pushing? >> > My apologies, I missed this also. If it's not that much more work, it > might be best to remove the unused variants. We don't like to carry > around dead code in the repo as another general rule. > >> In this case I only updated the existing HAL with more chips, but I >> agree that having a better solution to manage HALs than the >> clone-and-own approach would be great. >> >> One possible solutions could be to use subrepos. We can clone the lib to >> the git.rtems.org, add necessary patches and add that as a subrepo. If >> an update is necessary, patches can just be rebased on the latest >> version of the upstream lib. Another one could be something like the >> west tool that is used in Zephyr. Maybe can also make it simpler to >> include libs with vendor specific licenses. >> >> But approaches like that will have a big impact on how to handle a lot >> of tasks in RTEMS. For example you would have to init submodules before >> building BSPs. The submodules have to be handled during release. And a >> lot more. So we shouldn't discuss that as a side note to a patch set but >> rather as a new mail thread. >> > Agreed.
Do these HAL systems provide stable API interfaces? If so is all RTEMS needs to interface to is the API headers? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel