From: Athanasios A. <th...@at...> - 2005-08-01 09:35:33
|
Hello All "An application may request the use of a shared resource (e.g., the accumulator in CP0) by issuing an access to the resource, which will result in an undefined exception. The operating system may grant access to this coprocessor by setting the appropriate bit in the Coprocessor Access Register and return to the application where the access is retried." This is from the Intels pxa255 developers manual. Can this be regarded as the deafult implementation for an OS? Is this what really happens in the gumstix kernel? It sounds "slow" :-) What would be the default state of the DSP coprocessor access bit? If it is disabled, which would be the best place in the kernel to enable it? Is there a part in the kernel code that initialises the PXA255? I am reffering to the kernel because the developers manual clearly states that access to the DSP coprocessor is enabled only by "priviledged code" Looking forward hearing from you thanOS |
From: Doug S. <do...@pr...> - 2005-08-01 13:51:46
|
Athanasios, The quote below is not from the PXA255 developer's manual. There is no DSP coprocessor on PXA255. Are you reading the 80200 developer manual? -- Doug Athanasios Anastasiou wrote: > "An application may request the use of a shared resource (e.g., the > accumulator in CP0) by issuing an access to the resource, which will > result in an undefined exception. The operating system may grant access > to this coprocessor by setting the appropriate bit in the Coprocessor > Access Register and return to the application where the access is retried." I see that quote here: |
From: Dave H. <dhy...@gm...> - 2005-08-01 18:18:34
|
Hi Athanasios, > If it is disabled, which would be the best place in the kernel to enable = it? >=20 > Is there a part in the kernel code that initialises the PXA255? You have a couple of options. There's a macro called arch_initcall (include/linux/init.h) that you can use: static int __init my_machine_initializations(void) { ... Do dtuff here ... } arch_initcall( my_machine_initializations ); Then as long as your object file is linked into the kernel, you routine will be called. device_initcall (level 6) is where all of the device drivers are initialized. arch_initcall is level 3. That should give you an idea. If you really, really need to initialize stuff earlier, then at the end of pxa_map_io function (in asm/arch/mach-pxa/generic.c) is the earliest time that the virtual memory map is setup. Using the arch_initcall would be preferred. As an aside, most of the initialization stuff takes place through the use of the MACHINE data structure at the end of arch/arm/mach-pxa/gumstix.c. The gumstix_init function is called using arch_initcall, so there's no real advantage to modifying that file. It's probably easier to add a new file with it's own arch_initcall --=20 Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Piero O. <ot...@gm...> - 2005-08-31 09:44:39
|
Hi there, is there any news about this interesting thread? Bye Piero Alle 11:29, luned=C3=AC 1 agosto 2005, Athanasios Anastasiou ha scritto: > Hello All > > "An application may request the use of a shared resource (e.g., the > accumulator in CP0) by issuing an access to the resource, which will > result in an undefined > exception. The operating system may grant access to this coprocessor by > setting the appropriate bit > in the Coprocessor Access Register and return to the application where > the access is retried." > > This is from the Intels pxa255 developers manual. Can this be regarded > as the deafult implementation for an OS? Is this what really happens in > the gumstix kernel? It sounds "slow" :-) > > What would be the default state of the DSP coprocessor access bit? > > If it is disabled, which would be the best place in the kernel to enable > it? > > Is there a part in the kernel code that initialises the PXA255? > > I am reffering to the kernel because the developers manual clearly > states that access to the DSP coprocessor is enabled only by > "priviledged code" > > Looking forward hearing from you > thanOS > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |