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.
Before the new build system is integrated in the master, I will do a
final rebase to the master and squash commits.
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.
--
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.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
