sparc64_install_isr_entries function is no longer used. Removing it also
allows to use the default bsppredriverhook for usiii and bspstart for niagara.
This code was only referenced for r46xx CPU models. There are
no BSPs currently in the tree with this CPU model. The r46xx
was the original target for the MIPS port and it is likely that
the code has not been used on actual hardware in many years.
All MIPS BSPs successfully built after this was removed.
This change starts with removing the effectively empty file
timerdrv.h. The prototypes for benchmark_timer_XXX() were in
btimer.h which was not universally used. Thus every use of
timerdrv.h had to be changed to btimer.h. Then the prototypes
for benchmark_timer_read() had to be adjusted to return
benchmark_timer_t rather than int or uint32_t.
I took this opportunity to also correct the file headers to
separate the copyright from the file description comments which
is needed to ensure the copyright isn't propagated into Doxygen
output.
Implement new cache functions for or1k and create new bspstart function
for or1ksim to initialize instruction and data caches. Also, sim.cfg
is modified to enable/confiure cache units.
Adds functions that allows the user to specify which cores that should
perform the cache operation. SMP messages are sent to all the specified
cores and the caller waits until all cores have acknowledged that they
have flushed their cache. If CPU_CACHE_NO_INSTRUCTION_CACHE_SNOOPING is
defined the instruction cache invalidation function will perform the
operation on all cores using the previous method.
Also cleanup:
* Remove un-needed interrupt disables.
* Address errata "e989: FLASH: Disable Prefetch during programming and erase"
* Use RTEMS_ARRAY_SIZE() macro instead of own macro.
Fix context switch on SMP for ARM, PowerPC and SPARC.
Atomically test and set the is executing indicator of the heir context
to ensure that at most one processor uses the heir context. Break the
busy wait loop also due to heir updates.
This reverts commit d9ff8b3e68.
It is not that simple:
https://sourceware.org/ml/binutils/2014-06/msg00062.html
On Fri, Jun 06, 2014 at 01:31:48PM +0200, Sebastian Huber wrote:
> On 2014-06-06 13:23, Sebastian Huber wrote:
> >Ok, so this "cmplwi cr0, rX, ppc_exc_lock_std@sdarel" is illegal,
> >since
> >ppc_exc_lock_std@sdarel is signed and the immediate is unsigned
> >16-bit? The
> >assembler doesn't issue a warning about this.
> >
> >Exists there a way to rescue this cmplwi hack without relaxing the
> >overflow
> >checks?
>
> Hm, sorry, it was surprisingly simple. This works:
>
> "cmplwi cr0, rX, ppc_exc_lock_std@sdarel@l"
>
> I was not aware that you can add several @ in a row.
That is the wrong thing to use here. sdarel@l translates to a VLE
reloc which applies to a split 16-bit field in VLE insns.
You want
cmpwi cr0, rX, ppc_exc_lock_std@sdarel
to properly compare a 16-bit signed number from sym@sdarel.
Note that the assembler does error if you write something like
cmplwi 3,-30000
or
cmpwi 3,40000
so what the linker is now doing is extending this behaviour to link
time.
See also
https://sourceware.org/ml/binutils/2014-06/msg00059.html
On Fri, Jun 06, 2014 at 11:01:10AM +0200, Sebastian Huber wrote:
> I performed a git bisect and found this:
>
> 93d1b056cb396d6468781fe0e40dd769891bed32 is the first bad commit
> commit 93d1b056cb396d6468781fe0e40dd769891bed32
> Author: Alan Modra <amodra@gmail.com>
> Date: Tue May 20 11:42:42 2014 +0930
>
> Rewrite ppc32 backend .sdata and .sdata2 handling
Hmm, I'm surprised that your git bisect found this patch. Was
_SDA_BASE_ set differently before this?
> 0x00000000000dfc00 _SDA_BASE_
> 0x00000000000d7f78 ppc_exc_lock_std
> 4b8: 28 05 00 00 cmplwi r5,0
> 4ba: R_PPC_SDAREL16 ppc_exc_lock_std
ppc_exc_lock_std@sdarel will be calculating 0xd7f78 - 0xdfc00
which is 0xf...fff8378, and that falls foul of
commit 86c9573369616e7437481b6e5533aef3a435cdcf
Author: Alan Modra <amodra@gmail.com>
Date: Sat Mar 8 13:05:06 2014 +1030
Better overflow checking for powerpc32 relocations
cmplwi has an *unsigned* 16-bit field, and we now check the overflow
properly.
I wonder how many more of these we'll hit, and whether the uproar will
be enough that I'll be forced to relax the checks?
