Robin, yeah your right it would be very limited based on this thanks
for pointing out all the subtle details. Also your correct the best
one could hope from would be a 2d-dma fast system call that just loads
the pair of mmrs and returns. Which btw is exactly what I
want. Some details need to be worked out on how the kernel
would poll for the completion of the transfer. And how the kernel
would safe guard against reuse of the channel by another process. 2 very
difficult system issues.
The details of the execution enviornment is really important and I
appreciate the brick thrown. Lets look at the flow and make sure I
have it right.
1. exception occurs
2. hardware dispatches to ex_trap_c unless otherwise handled
3. ex_trap_c, modifies the LVL5 hardware event handler so no
hardware events can occur until the exception finishes (correct)?
then the exception is deferred to LVL5.
4. trap_c is called from LVL5.
5. handled events are covered via switch(event) construct in C.
Which makes me believe trap_c is the place we would want in general to
be mutable. If it is already its far from obvious.
Here is another example of a place where one might want to modify the
exception handling behavior. Illegal instruction I want the ability
to write simulation semantics that provides in a similar way
architectural extensions they might be slow. E.g. FCORE4 provides some
enhanced cache instructions we might want to simulate them in a way
the maintains binary compatibility. X86 did this and it was very
successful i.e. X386 and X486 fp instructions.
Now the question turns to how does one make trap_c mutable? And until
my concept of 2d-dma fast os call is flushed out I need to hold back
on that request. But, the discussion I think is important to
understand at least for me and probably others.
Robin Getz writes:
> On Sat 7 Apr 2007 20:05, Marc Hoffman pondered:
> > Some of the things that I have want to do are related specialized
> > exception handlers.
>
> After thinking about this a little more, (Marc and I briefly discussed this
> on
> Friday, and a few other times), what you are able to do in exception space
> is
> pretty limited...
>
> You have limited access to a stack. (there is no exception stack - we store
> the existing stack pointer into the return from NMI register (retn), and
> load
> a fixed stack _exception_stack_top - in it's place).
> You have no access to kernel functions (not all kernel memory/instruction is
> locked in the CPLB tables).
> You don't really know if your module would be locked in the CPLB tables (but
> you could find where it is, and walk the table, and lock it in - today this
> would not be a big deal, since we use 4Meg CPLB pages to cover iCPLBs, but
> this will get more difficult in the future, as we actually do better memory
> protection, and have smaller CPLBs).
> The same issue would exist for any data/bss for your module/exception
> handler.
As to your point this is way too complex! And all one could do is
something like the following of course with a safe guard wrapper.
swexcpt_hand_2dma:
[--sp]=p0;
<<assert not in use. global variable in a non cachable region maybe L1
if unavailable r0=0. and retx
>>
p0.h,p0.l = address of S1 dma chanin
[p0]=r0;
p0.h,p0.l = address of D1 dma chanin
[p0]=r1;
p0=[sp++];
r0=1;
retx;
Anyways thats probably the point, you can't do much more. But this
would be fast and its about all you need to do.
user space:
prepare_dma_descs_with_flags (&s1,&d1,&flag);
while (fast_2d_dma (s1,d1));
do useful work
wait_for_dma(&flag);
The above is a bit rough but I think the idea is there.
>
> > Places where this seems to be interesting to me are.
> >
> > 1. fast 2d-dma drivers for video
>
> This seems like it would be just a few MMR writes via registers that are
> passed in? (or were you thinking anything more complex)? Getting the
> compiler
> to output the right code to call your custom exception might be a little
> tricky (a little inline assembly should be all that is necessary). Were you
> thinking that this would be C-callable, or just from a .S file?
>
> > 2. performance modeling drivers i.e. install specialized excpt handler
> > for performance counters.
> I'm not sure what is meant by this. Can you describe what you were thinking
> of?
An event is fired off by the hardware when the performance counter
hits zero. .e.g. You can set the system up to trigger an exception on the
hundredth cache fill bank A.
>
> Before we jump to allowing extending the exception handlers via run time
> modules, we should allow them to be extended with a static compile, without
> having to change the entry.S file. (this doesn't exist today)
>
I agree, this needs to be done in your way. I'm just learning this
kernel and how to navigate. Actually, a pair of register/unregister
functions that extend the internal hard switch of trap_c is probably a
reasonable idea. Kind of like
register_hardware_exception_hook (excptno, handler);
unregister_hardware_exception_hook (excptno, handler);
> There would need to be some defined method to how we should put all the
> exception handling code/data together in a section so - so we can make sure
> it
> is locked in the CPLB. What we do now, is just try to ensure it is all in
> the
> first 4Meg... Which only works, because we cover things with 4Meg pages,
> and
> our kernel is normally small.
>
> __ex_table is a symbol that we have defined in the vmlinux.lds.S file, but
> it
> doesn't seem to be used in the source anywhere (like it is in other ports).
> I
> am guessing that is what we should be using for a section name to start?
>
> -Robin
_______________________________________________
Uclinux-dist-devel mailing list
Uclinux-dist-devel@blackfin.uclinux.org
http://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
