Are there any comments on this patch? If not, I
am going to push it.
On 5/27/2015 10:16 AM, Joel Sherrill wrote:
This was obsolete and broken based upon recent time keeping changes.
Thie build option was previously enabled by adding
USE_TICKS_FOR_STATISTICS=1 to the configure command line.
Thi
On Wed, Jun 3, 2015 at 7:57 AM, Sebastian Huber
wrote:
> The compiler is free to re-order load/store instructions to non-volatile
> variables around a load/store of a volatile variable. So the volatile
> generation counter is insufficent. In addition tests on a Freescale
> T4240 platform with 24
On Wed, Jun 3, 2015 at 2:39 AM, Rohini Kulkarni wrote:
> But, I can't say cache configurations have a role here.
>
> I'll push my code to my github project soon.
>
> P.S. The Pi2 board I possess seems to have broken down. It just isn't
> turning on. Unable to test further. Will order one immediate
On Tue, Jun 2, 2015 at 9:42 PM, Alan Cudmore wrote:
> The caches are being enabled on the RPI 1 BSP. The same code is being
> executed by the RPI 2 BSP, but obviously it’s not sufficient for the cache
> setup.
> I have been reading through this long thread, and it is very informative:
> https://ww
On Tue, Jun 2, 2015 at 5:45 PM, Pavel Pisa wrote:
> Hello Yang Qiao,
>
>
> On Tuesday 02 of June 2015 22:58:09 QIAO YANG wrote:
>> 2. The mmu configuration for framebuffer. I'm still confused about how to
>> deal with it.
>>
>> Is there anyway to setup the memory in the code ? For exemple: aft
The compiler is free to re-order load/store instructions to non-volatile
variables around a load/store of a volatile variable. So the volatile
generation counter is insufficent. In addition tests on a Freescale
T4240 platform with 24 PowerPC processors showed that real memory
barriers are require
On 03/06/15 12:59, Joel Sherrill wrote:
On June 3, 2015 4:34:31 AM EDT, Sebastian
Huber wrote:
>Hi,
>
>I added some points. What is a bit confusing is that the documentation
>is not up to date, e.g.
>
>https://docs.rtems.org/doc-current/share/rtems/html/bsp_howto/Clock-Driver.html#Clock-Driv
On June 3, 2015 4:34:31 AM EDT, Sebastian Huber
wrote:
>Hi,
>
>I added some points. What is a bit confusing is that the documentation
>is not up to date, e.g.
>
>https://docs.rtems.org/doc-current/share/rtems/html/bsp_howto/Clock-Driver.html#Clock-Driver
>
>still reflects the old clock driver
Hi,
I added some points. What is a bit confusing is that the documentation
is not up to date, e.g.
https://docs.rtems.org/doc-current/share/rtems/html/bsp_howto/Clock-Driver.html#Clock-Driver
still reflects the old clock driver API.
On 23/05/15 16:44, Joel Sherrill wrote:
Hi
A LOT has happ
Store the floating-point unit property in the thread control block
regardless of the CPU_HARDWARE_FP and CPU_SOFTWARE_FP settings. Make
sure the floating-point unit is only enabled for the corresponding
multilibs. This helps targets which have a volatile only floating point
context like SPARC for
The SPARC ABI is a bit special with respect to the floating point context.
The complete floating point context is volatile. Thus from an ABI point
of view nothing needs to be saved and restored during a context switch.
Instead the floating point context must be saved and restored during
interrupt
11 matches
Mail list logo
