On Tue 6 Nov 2007 04:50, Michael Schnell pondered:
>
> > the Blackfin processor has an MPU which means the
> > Blackfin Linux port can (and does) prevent user space from accessing
> > peripherals.
> While I don't doubt that you are right, I suppose the use of the MPU can
> be disabled, in cas
the Blackfin processor has an MPU which means the
Blackfin Linux port can (and does) prevent user space from accessing
peripherals.
While I don't doubt that you are right, I suppose the use of the MPU can
be disabled, in case the OP really wants to avoid writing a Device Driver.
-Michael
_
On Monday 05 November 2007, Gavin Lambert wrote:
> Quoth Mike Frysinger:
> > while some processors lack an MMU, then do not lack an MPU (memory
> > protection unit). for example, the Blackfin processor has an MPU which
> > means the Blackfin Linux port can (and does) prevent user space from
> > ac
Quoth Mike Frysinger:
> while some processors lack an MMU, then do not lack an MPU (memory
> protection unit). for example, the Blackfin processor has an MPU which
> means the Blackfin Linux port can (and does) prevent user space from
> accessing peripherals. we can (and have an experimental/in-d
On Sunday 04 November 2007, Michael Schnell wrote:
> While the recommended way is to do Kernel drivers for any hardware
> access (as it's required in standard Linux), with µCLinux it's possible
> to directly access any address (and thus even peripheral hardware) from
> userland. Unless interrupts a
While the recommended way is to do Kernel drivers for any hardware
access (as it's required in standard Linux), with µCLinux it's possible
to directly access any address (and thus even peripheral hardware) from
userland. Unless interrupts are necessary this would work in appropriate
cases.
-M
On Wednesday 31 October 2007, Gavin Lambert wrote:
> Quoth Mike Frysinger:
> > On Tuesday 30 October 2007, Gavin Lambert wrote:
> > > Just the opposite. As Greg said, at the driver level uClinux *is*
> > > Linux
> >
> > s/at the driver level//
>
> Well, I was talking about the kernel, so in the co
Quoth Mike Frysinger:
> On Tuesday 30 October 2007, Gavin Lambert wrote:
> > Just the opposite. As Greg said, at the driver level uClinux *is*
> > Linux
>
> s/at the driver level//
Well, I was talking about the kernel, so in the context of "driver level" vs
"platform-specific-code". So my state
Felipe Uderman wrote:
>Is there a document that explains how does uClinux works on
>providing the drivers and abstracts the hardwares? Maybe it is just to
>target specific?
It's nearly all the same as standard Linux - at least, the basic
features. The major difference is things to do
On Tuesday 30 October 2007, Gavin Lambert wrote:
> Quoth Felipe Uderman:
> > I am having some trouble finding uClinux documentation. I guess for
> > now that most of it is this list and the ucdot.org and uClinux
> > websites. Is there a document that explains how does uClinux works
> > on providing
Quoth Felipe Uderman:
> I am having some trouble finding uClinux documentation. I guess for
> now that most of it is this list and the ucdot.org and uClinux
> websites. Is there a document that explains how does uClinux works
> on providing the drivers and abstracts the hardwares? Maybe it is
>
11 matches
Mail list logo
