On Tue, 25 Feb 2020 at 11:54, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > > On 25/02/2020 11:00, Hesham Almatary wrote: > > On Mon, 24 Feb 2020 at 22:50, Chris Johns<chr...@rtems.org> wrote: > >> On 21/2/20 11:11 pm, Sebastian Huber wrote: > >>> On 21/02/2020 12:26, Hesham Almatary wrote: > >>>> On Fri, 21 Feb 2020 at 11:07, Sebastian Huber > >>>> <sebastian.hu...@embedded-brains.de> wrote: > >>>>> Hello Hesham, > >>>>> > >>>>> On 20/02/2020 16:40, Hesham Almatary wrote: > >>>>>> Hello, > >>>>>> > >>>>>> Are there any progress updates to the Waf build system integration in > >>>>>> RTEMS? > >>>>>> > >>>>>> I have pulled [1] and it seems like it hasn't got many updates since > >>>>>> December. I wonder what's still remaining/blocking to merge it, or at > >>>>>> least push it as a development branch (without re-writing history) > >>>>>> that others, including me, can use it and submit patches against. > >>>>>> > >>>>>> [1] git://git.rtems.org/sebh/rtems.git > >>>>> technically, the new build system is ready for integration into the > >>>>> master branch. I would need about one day to rebase and test it before > >>>>> the push. The integration is currently blocked since Chris and Joel had > >>>>> no time to look at it. > >>>>> > >>>> Thanks for your input, Sebastian. Is there a recommended branch I > >>>> should be based on? I noticed there's "build" and "build-next". > >>> The "build" branch contains the state of the first review. I updated > >>> "build-next" a couple of times to integrate the changes on the RTEMS > >>> master. > >>> > >>>> Do you intend to re-write git history in either? > >>> Yes, when I started with the build system work I didn't expect a more > >>> than two > >>> months review period. > >> I have discussed this merge with Joel. We have decided to release RTEMS 5 > >> before > >> we merge a new build system. A release with parallel build systems is > >> confusing > >> and distracting. > >> > > That makes sense to me. I think we should both try to push for an > > RTEMS release soon, and make the waf/build > > branch more stable and/or in the view (e.g., push as an experimental > > branch) for developer to use until a release comes out. I understand > > another branch would incur more maintaibility efforts, but it will > > also help make the the new build system more usable. > > I can do a forced update of the "build" branch with my latest version > based on rebase of the current master by the end of the week. > Afterwards, I can do merges from the master instead of forced pushes. > This should enable you to base your work on this branch. You can also > send me patches. > That will be great, thanks! I have WIP patches to both LLVM and rtems/waf to build for RISC-V BSPs. I'd like to move to rtems/waf in our local CI system with our RTEMS fork. Once I feel confident about those patches and tested them, I'll submit them.
> Before the new build system is integrated in the master, I will do a > final rebase to the master and squash commits. > OK, sounds good. > > > >> I think we are close to a release if master can stay stable. The milestone > >> ticket page ... > >> > >> https://devel.rtems.org/milestone/5.1 > >> > >> ... shows 43 in progress and 2 closed. Help with the tickets will help > >> progress > >> things. > >> > >> I am working on moving the libbsd release to the 5-freebsd-12 branch and > >> the > >> side effects that causes. I will need reports of a libbsd release snapshort > >> running on ... > >> > >> beagleboneblack, imx7, xilinx_zynq_zedboard, qoriq_e500 > >> > >> I can do this for the beagleboneblack and xilinx_zynq_zedboard. > >> > > I recently got libbsd working with RISC-V on QEMU. On my TODO list, > > I'll create a soft SoC with DTB/FDT and devices for testing on an FPGA > > board, I will report about that if I got some apps/tests reasonably > > working. > > > >> Finally there is the FDT file managements, I would like a resolution on a > >> suitable path to get FDT files into a release and at least one BSP to > >> support > >> this. I have selected the BeagleBone Black because I have one to test on. > >> > > I can pitch in with RISC-V (QEMU and/or FPGA SoCs/board). I'd like for > > FDT management to be as generic as could be across different > > BSPs/architectures. > > The FreeBSD device tree support should be fairly architecture > independent. However, it is not as good/complete/robust as the Linux > device tree support. I am not in favour of adding an RTEMS-specific > device tree support. > I might be more biased to FreeBSD here, but I don't have strong opinions about it yet. > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. -- Hesham _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
