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 <jinh...@konkuk.ac.kr>
Cc: devel@rtems.org; j...@konkuk.ac.kr
Subject: Re: Update virtio network driver
On Thu, Nov 10, 2016 at 4:42 AM, Jinhyun <jinh...@konkuk.ac.kr> 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
