Update virtio network driver
Hi, all! We removed our RTEMS-virtio driver's dependencies on architecture. We used built-in function of gcc, __sync_synchronize(). This function generates proper memory barrier for target architecture on compile time. In addition, we replaced pcib_conf_read/write functions to pci_read/write_config functions. We added several lines of codes for exception handling suggested by Pavel Pisa. Thank you, Pavel Pisa. As we removed dependencies on CPU architectures, we moved the virtio source directory located at c/src/lib/libbsp/i386/pc386/ to c/src/lib/libbsp/shared. We plan to enhance the virtio driver for RTEMS, and we have several additional patches for it. To easily manage this project from our side, we created Github repository. You can see the latest version of our virtio driver in our Github: https://github.com/sslab-konkuk/RTEMS-virtio Recently, we succeeded to test the virtio with Motorola_powerpc BSP. For this, we made additional modifications. Motorola_powerpc BSP doesn't support functions such as rtems_insterrupt_handler_install, so we used functions such as BSP_install_rtems_irq_handler instead of those. Moreover, in order to make our virtio work on PowerPC, we added initialization codes to virtio_pci.c because qemu_fakerom, which is the PowerPC bios of Motorola_powerpc BSP, doesn't initialize the virtio back-end driver. But some runtime error is occurred on RTEMS master branch, so we will submit about it again soon. Best regards, Jin-Hyun. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Time to bump gcc on master?
On Thu, Nov 10, 2016 at 1:36 AM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > For the libbsd update we need the November Newlib snapshot (or the > release). I have also a libgomp (OpenMP) performance improvement in the > queue, for this I need a future GCC snapshot. > > Is the 20161025 snapshot that Jeff just posted OK? We can bump again when something newer is available. So gcc 6.2 is not worth the trouble to update to? Are we looking at a gcc pre-7 snapshot or pre-6.3? Between the new gcc versioning and the "future GCC snapshot", I am not sure what you want. GCC makes snapshots about once a week. Which of these would you be wanting? ftp://gcc.gnu.org/pub/gcc/snapshots/6-20161103/ ftp://gcc.gnu.org/pub/gcc/snapshots/7-20161106/ With the assumption that we would be moving 4.12 to a released version as soon as we can. I am happy to bump the RSB. I just want to make sure I know where we need to go. --joel > > On 10/11/16 00:44, Joel Sherrill wrote: > >> Hi >> >> As we approach a 4.12 branching point, we need to pick >> a better gcc version. The current RTEMS default is >> gcc-6-20160609 >> >> I am testing now to bump newlib to newlib-2.4.0.20161025-1. >> >> This reports as: >> >> sparc-rtems4.12-gcc (GCC) 6.1.1 20160609 (RTEMS 4.12, RSB >> 6d2eaba6c9bccedc04dfc2802a0d11835a98a417, Newlib 2.4.0.20161025) >> >> gcc 6.2 was released in August and based on their new numbering >> scheme, that should be the release immediately following our >> snapshot. >> >> Anyone have any objections to me updating to gcc 6.2 after >> seeing how the newlib version bump goes? >> >> Thanks. >> >> --joel >> >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel >> > > -- > 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
Update Master to GDB 7.12
Hi After I get through bumping newlib and gcc, is it time to bump the master from gdb 7.11 to 7.12? Looking at the 7.11 bset, I see three sets of patches. (1) sis simulator patches (2) addition of aarch64 and x86_64 rtems targets (3) FreeBSD specific Python support patch (2) has been merged upstream. (1) and (3) are still needed. They apply cleanly. Any objections to updating to 7,12? any chance of getting patches (1) and (3) upstream. :) --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Update virtio network driver
On Thu, Nov 10, 2016 at 4:42 AM, Jinhyun wrote: > Hi, all! > > We removed our RTEMS-virtio driver's dependencies on architecture. We used > built-in function of gcc, __sync_synchronize(). This function generates > proper memory barrier for target architecture on compile time. In addition, Would RTEMS_COMPILER_MEMORY_BARRIER() work for you? > we replaced pcib_conf_read/write functions to pci_read/write_config > functions. We added several lines of codes for exception handling suggested > by Pavel Pisa. Thank you, Pavel Pisa. As we removed dependencies on CPU > architectures, we moved the virtio source directory located at > c/src/lib/libbsp/i386/pc386/ to c/src/lib/libbsp/shared. > > We plan to enhance the virtio driver for RTEMS, and we have several > additional patches for it. To easily manage this project from our side, we > created Github repository. You can see the latest version of our virtio > driver in our Github: https://github.com/sslab-konkuk/RTEMS-virtio > > Recently, we succeeded to test the virtio with Motorola_powerpc BSP. For > this, we made additional modifications. Motorola_powerpc BSP doesn't support > functions such as rtems_insterrupt_handler_install, so we used functions > such as BSP_install_rtems_irq_handler instead of those. Moreover, in order > to make our virtio work on PowerPC, we added initialization codes to > virtio_pci.c because qemu_fakerom, which is the PowerPC bios of > Motorola_powerpc BSP, doesn't initialize the virtio back-end driver. But > some runtime error is occurred on RTEMS master branch, so we will submit > about it again soon. > > Best regards, > Jin-Hyun. > > > ___ > 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: Update Master to GDB 7.12
On 10/11/16 18:17, Joel Sherrill wrote: > Hi > > After I get through bumping newlib and gcc, is it time > to bump the master from gdb 7.11 to 7.12? > > Looking at the 7.11 bset, I see three sets of patches. > > (1) sis simulator patches > (2) addition of aarch64 and x86_64 rtems targets > (3) FreeBSD specific Python support patch > > (2) has been merged upstream. > > (1) and (3) are still needed. They apply cleanly. > > Any objections to updating to 7,12? > > any chance of getting patches (1) and (3) upstream. :) I can try to submit the sis patches to gdb again. Last time I only managed to get about 10 patches accepted, and it was a slow and painful process. Maybe I will have better luck this time ... :-) Jiri. > > --joel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS 4.11.0 RC6 Available
RTEMS 4.11.0 RC6 Release: 4.11.0-rc6 Date : 11 November 2016 URL: https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.0-rc6/ This is hopefully the final release candidate (RC6) for RTEMS 4.11.0. This release contains examples-v2 and rtems-libbsd. We are planning to release 4.11.0 next week if there are no new issues. Please download, review, check, build and test sending any issues to the mailing lists. To build click on the link and follow the releases README.txt's "Quick Guide to Building" section. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: Update virtio network driver
We use __sync_synchronize() to generate hardware memory barrier same as mb() of
FreeBSD does.
And we know that RTEMS_COMPILER_MEMORY_BARRIER() generates compiler memory
barrier not hardware memory barrier, doesn't it?
On PowerPC, it seems that RTEMS_COMPILER_MEMORY_BARRIER() is replaced by
__asm__ volatile("":::"memory").
But mb() of FreeBSD is replaced by __asm__ volatile("sync":::"memory").
And __sync_synchronize() generates assembly code "sync".
So we use __sync_synchronize() to replace mb() of FreeBSD.
However the driver also works well when we use RTEMS_COMPILER_MEMORY_BARRIER()
because the driver almost works well without any barrier, too.
-Original Message-
From: ged...@gwmail.gwu.edu [mailto:ged...@gwmail.gwu.edu] On Behalf Of Gedare
Bloom
Sent: Friday, November 11, 2016 3:27 AM
To: Jinhyun
Cc: devel@rtems.org; j...@konkuk.ac.kr
Subject: Re: Update virtio network driver
On Thu, Nov 10, 2016 at 4:42 AM, Jinhyun wrote:
> Hi, all!
>
> We removed our RTEMS-virtio driver's dependencies on architecture. We
> used built-in function of gcc, __sync_synchronize(). This function
> generates proper memory barrier for target architecture on compile
> time. In addition,
Would RTEMS_COMPILER_MEMORY_BARRIER() work for you?
> we replaced pcib_conf_read/write functions to pci_read/write_config
> functions. We added several lines of codes for exception handling
> suggested by Pavel Pisa. Thank you, Pavel Pisa. As we removed
> dependencies on CPU architectures, we moved the virtio source
> directory located at c/src/lib/libbsp/i386/pc386/ to c/src/lib/libbsp/shared.
>
> We plan to enhance the virtio driver for RTEMS, and we have several
> additional patches for it. To easily manage this project from our
> side, we created Github repository. You can see the latest version of
> our virtio driver in our Github:
> https://github.com/sslab-konkuk/RTEMS-virtio
>
> Recently, we succeeded to test the virtio with Motorola_powerpc BSP.
> For this, we made additional modifications. Motorola_powerpc BSP
> doesn't support functions such as rtems_insterrupt_handler_install, so
> we used functions such as BSP_install_rtems_irq_handler instead of
> those. Moreover, in order to make our virtio work on PowerPC, we added
> initialization codes to virtio_pci.c because qemu_fakerom, which is
> the PowerPC bios of Motorola_powerpc BSP, doesn't initialize the
> virtio back-end driver. But some runtime error is occurred on RTEMS
> master branch, so we will submit about it again soon.
>
> Best regards,
> Jin-Hyun.
>
>
> ___
> 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: Time to bump gcc on master?
- Joel Sherrill schrieb: > On Thu, Nov 10, 2016 at 1:36 AM, Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > > > For the libbsd update we need the November Newlib snapshot (or the > > release). I have also a libgomp (OpenMP) performance improvement in the > > queue, for this I need a future GCC snapshot. > > > > > Is the 20161025 snapshot that Jeff just posted OK? We can bump again > when something newer is available. The snapshot is in general, but not sufficient for the libbsd update. We can bump again, its not a problem. I struggle currently a bit with the UMA after the FreeBSD update. > > So gcc 6.2 is not worth the trouble to update to? Are we looking at > a gcc pre-7 snapshot or pre-6.3? Between the new gcc > versioning and the "future GCC snapshot", I am not sure what > you want. GCC makes snapshots about once a week. Which > of these would you be wanting? > > ftp://gcc.gnu.org/pub/gcc/snapshots/6-20161103/ I would bump to the 6-20161103 snapshot. We should switch to GCC 7 right after the branch on the master. > ftp://gcc.gnu.org/pub/gcc/snapshots/7-20161106/ > > With the assumption that we would be moving 4.12 to a released > version as soon as we can. > > I am happy to bump the RSB. I just want to make sure I know > where we need to go. > > --joel > > > > > > On 10/11/16 00:44, Joel Sherrill wrote: > > > >> Hi > >> > >> As we approach a 4.12 branching point, we need to pick > >> a better gcc version. The current RTEMS default is > >> gcc-6-20160609 > >> > >> I am testing now to bump newlib to newlib-2.4.0.20161025-1. > >> > >> This reports as: > >> > >> sparc-rtems4.12-gcc (GCC) 6.1.1 20160609 (RTEMS 4.12, RSB > >> 6d2eaba6c9bccedc04dfc2802a0d11835a98a417, Newlib 2.4.0.20161025) > >> > >> gcc 6.2 was released in August and based on their new numbering > >> scheme, that should be the release immediately following our > >> snapshot. > >> > >> Anyone have any objections to me updating to gcc 6.2 after > >> seeing how the newlib version bump goes? > >> > >> Thanks. > >> > >> --joel > >> > >> > >> ___ > >> devel mailing list > >> devel@rtems.org > >> http://lists.rtems.org/mailman/listinfo/devel > >> > > > > -- > > 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. > > > > -- 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.huber at 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
