headers
Reinoud Zandijk | 2 Nov 2003 00:33
Picon

Alignment problems on Acorn{26,32}

Dear folks,

after the recent patches to allow for misaligned access, the kernel panics
on a Acorn32 RiscPC (ARM7) with an ne2000 podule. It tries to read a 16 bit
with `ldr r3, [r0, #0x0002]' (insw+0x30) in blockio.S and gets a `Alignment
Fault 1' trap and dies. It looks like it wants to execute the `fastinsw'
routine.

Other functions in blockio.S have the same alignment problems. Could anyone 
please take a look and fix it? (I haven't been following port-arm that much 
lately)

Cheers,
Reinoud

port-acorn32 portmaster
Permalink | Reply | 5 comments |
headers
Chris Gilbert | 2 Nov 2003 22:40
Picon

Re: Alignment problems on Acorn{26,32}

On Sun, 2 Nov 2003 00:33:25 +0100
Reinoud Zandijk <reinoud <at> netbsd.org> wrote:

> Dear folks,
> 
> after the recent patches to allow for misaligned access, the kernel
> panics on a Acorn32 RiscPC (ARM7) with an ne2000 podule. It tries to
> read a 16 bit with `ldr r3, [r0, #0x0002]' (insw+0x30) in blockio.S
> and gets a `Alignment Fault 1' trap and dies. It looks like it wants
> to execute the `fastinsw' routine.

> Other functions in blockio.S have the same alignment problems. Could
> anyone please take a look and fix it? (I haven't been following
> port-arm that much lately)

Perhaps the fastest way for now is to remove the aligned optimised
cases.

I also suspect that that code may not work correctly with big endian
either, but I'm not sure.

I believe ldrh and strh could be used on arms with those instructions to
speed up that code.

Chris
Permalink | Reply | 4 comments |
headers
Richard Earnshaw | 4 Nov 2003 00:00
Favicon

Re: Alignment problems on Acorn{26,32}

> On Sun, 2 Nov 2003 00:33:25 +0100
> Reinoud Zandijk <reinoud <at> netbsd.org> wrote:
> 
> > Dear folks,
> > 
> > after the recent patches to allow for misaligned access, the kernel
> > panics on a Acorn32 RiscPC (ARM7) with an ne2000 podule. It tries to
> > read a 16 bit with `ldr r3, [r0, #0x0002]' (insw+0x30) in blockio.S
> > and gets a `Alignment Fault 1' trap and dies. It looks like it wants
> > to execute the `fastinsw' routine.
>  
> > Other functions in blockio.S have the same alignment problems. Could
> > anyone please take a look and fix it? (I haven't been following
> > port-arm that much lately)
> 
> Perhaps the fastest way for now is to remove the aligned optimised
> cases.
> 
> I also suspect that that code may not work correctly with big endian
> either, but I'm not sure.
> 
> I believe ldrh and strh could be used on arms with those instructions to
> speed up that code.

STRH cannot be used on any Acorn machine since a store that misses the 
cache goes straight to the memory system.

LDRH can be used only if it can be guaranteed that the page is marked 
cacheable (not true for user-space since a shared page may be NCB).
(Continue reading)

Permalink | Reply | 3 comments |
headers
Steve Woodford | 4 Nov 2003 00:33
Picon

Re: Alignment problems on Acorn{26,32}

On Monday 03 November 2003 11:00 pm, Richard Earnshaw wrote:

> STRH cannot be used on any Acorn machine since a store that misses
> the cache goes straight to the memory system.
>
> LDRH can be used only if it can be guaranteed that the page is marked
> cacheable (not true for user-space since a shared page may be NCB).
>
> In either case, these instructions can only be used if it is a
> SA-only kernel.

I think in this case, adding an override option which prevents alignment 
fault being enabled is the best way forward.

Affected ports can define it in std.<machine>, or some other suitable 
place.

Cheers, Steve
Permalink | Reply | 2 comments |
headers
Richard Earnshaw | 4 Nov 2003 00:56
Favicon

Re: Alignment problems on Acorn{26,32}

> On Monday 03 November 2003 11:00 pm, Richard Earnshaw wrote:
> 
> > STRH cannot be used on any Acorn machine since a store that misses
> > the cache goes straight to the memory system.
> >
> > LDRH can be used only if it can be guaranteed that the page is marked
> > cacheable (not true for user-space since a shared page may be NCB).
> >
> > In either case, these instructions can only be used if it is a
> > SA-only kernel.
> 
> I think in this case, adding an override option which prevents alignment 
> fault being enabled is the best way forward.
> 
> Affected ports can define it in std.<machine>, or some other suitable 
> place.

Is it possible to do this only for kernels?  Ie, user-space is restricted 
to strict-alignment, but the kernel (which is normally processor-specific 
anyway) can do whichever is appropriate.

R.
Permalink | Reply | 1 comment |
headers
Steve Woodford | 4 Nov 2003 09:07
Picon

Re: Alignment problems on Acorn{26,32}

On Monday 03 November 2003 11:56 pm, Richard Earnshaw wrote:

> Is it possible to do this only for kernels?  Ie, user-space is
> restricted to strict-alignment, but the kernel (which is normally
> processor-specific anyway) can do whichever is appropriate.

Sure, it's possible.

Does the benefit of this compensate for the overhead of the additional 
cpu cycles on every exception/interrupt entry/exit? At least the normal 
COMPAT_15 behaviour can be disabled by simply no defining the option.

You'd also have to add the same overhead to the FIQ entry/exit points 
"Just In Case".

Cheers, Steve
Permalink | Reply | 0 comments |
headers
Hsu, Cheng-Hsin (Cheng-Hsin | 18 Nov 2003 19:09
Picon
Favicon

Re: LKM on evbarm

Hello All,

	I'm trying to modload on evbarm port to load Benedikt's example module. 
	Did I miss something in the following lkmtramp.awk? Should I modify lkmhide.awk and lkmwrap.awk?

Thanks,
Bear.

BEGIN {
        print "#include <machine/asm.h>"
}

$2 == "R_ARM_PC24" {
        if (x[$3] != "")
                next;
        print "ENTRY(__wrap_"$3")"
        print "\tldr\tpc, [pc, #-4]"
        print "\t.word\t__real_"$3
        x[$3]=".";
}

bart: {1010} nm fibo.o
00000000 t .gcc2_compiled.
         U .text
00000298 t __wrap_.text
000002a0 t __wrap_lkmdispatch
000002a8 t __wrap_lkmexists
000002b0 t __wrap_memset
000002b8 t __wrap_printf
000002c0 t __wrap_uiomove
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Earnshaw | 19 Nov 2003 02:36
Picon
Picon

Re: LKM on evbarm


> Hello All,
> 
> 	I'm trying to modload on evbarm port to load Benedikt's example module. 
> 	Did I miss something in the following lkmtramp.awk? Should I modify lkmhide.awk and lkmwrap.awk?
> 

I assume you are aware that Steve Woodford recently committed lkm support 
for arm on -current.  I haven't tried it myself yet, but I would assume 
that he wouldn't have committed it if it wasn't at least mostly functional.

R.
Permalink | Reply | 3 comments |
headers
Steve Woodford | 19 Nov 2003 14:10
Picon

Re: LKM on evbarm

On Wednesday 19 November 2003 1:36 am, Richard Earnshaw wrote:

> I assume you are aware that Steve Woodford recently committed lkm
> support for arm on -current.  I haven't tried it myself yet, but I
> would assume that he wouldn't have committed it if it wasn't at least
> mostly functional.

It was tested up to the point where modload(8) causes ld(1) to spit out 
an internal error:

verde# modload -n nullfs.o
ld: internal error: aborting at 
/export/build/evbarm/gnu/dist/toolchain/ld/ldlang.c line 3847 in 
lang_place_orphans
ld: please report this bug
modload: can't prelink `nullfs.o' creating `nullfs'

I ran out of time to figure out what the problem is, but it also happens 
with older lkm binaries...

Cheers, Steve
Permalink | Reply | 0 comments |
headers
markwoods774 | 26 Nov 2003 08:54
Picon

introduction

hello friend,
    sorry to approach you like this.i got your address through a business
directory.i dont know what kind of business you do but i am willing to invest
in any better business i believe will be of benefit at the end of the day.if
this proposal is okay with you,get back to me asap.once i am sure my funds
could be transfered to your location,i will be leaving for your country
with my wife and kids immediately.my country liberia is becoming more uncomfortable
so i need to move immediatley.please treat as urgent.
regards,
mark oman woods....
Permalink | Reply | 0 comments |

Gmane