[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [microblaze-uclinux] Low level access
Hi Steve,
I'm totally with you.
I don't like bureaucracy, love going straight to the point, hence I really
love uCLinux too ;-)
Warmest Regards to you, Steve ;-) ;-)
Duy-Ky
-----Original Message-----
From: owner-microblaze-uclinux@xxxxxxxxxxxxxx
[mailto:owner-microblaze-uclinux@xxxxxxxxxxxxxx] On Behalf Of Steve Spano
Sent: Friday, September 07, 2007 3:39 AM
To: microblaze-uclinux@xxxxxxxxxxxxxx
Subject: RE: [microblaze-uclinux] Low level access
Hi
A lot of real Linux guys will disagree here, but my 'thought' process on
uCLinux is to "ride" a standard application ontop of the feature set (i.e.
tcp/ip/etc) that uCLinux brings to the table.
A lot of legacy applications have been ported to uCLinux for various
platforms we have worked on.
For example, lets say you want to light an LED from an application.
If you have a real Linux with MMU, then you need a driver/etc to get to the
kernel and access a hardware port.
I love uCLinux because I can do this.
*(volatile unsigned long*)HARDWAREADDRESS = 0x55
to set the leds located at HARDWAREADDRESS to 0x55.
Or
STATUS=*(volatile unsigned long*)STATUSADDRESS
To read a value.
These assume a 32-bit location.
You could do *(volatile unsigned short*) or *(volatile unsigned char*) for
16 and 8 bit access as well.
I don't like O/S's telling me where I can and cannot write to in the memory
space - we never have pointer reference problems :)
Steve Spano
FLE
-----Original Message-----
From: owner-microblaze-uclinux@xxxxxxxxxxxxxx
[mailto:owner-microblaze-uclinux@xxxxxxxxxxxxxx] On Behalf Of Duy-Ky Nguyen
Sent: Friday, September 07, 2007 12:52 AM
To: microblaze-uclinux@xxxxxxxxxxxxxx
Subject: RE: [microblaze-uclinux] Low level access
Hello Benny,
You got the point.
My point is, in the old days where many human users shared only 1 CPU.
Being huamn means being err. If s/he made mistake, his/her job must be shut
down for the sake of others.
That kind of thing become less important for a Linux PC, a general-purpose
computer.
But, for a special-purpose one, an embeded system, in some cases, it's very
likely the system must be shutdown even if only 1 task misbehave.
Otherwise,
it could be a disaster.
That's why there's always a redundant computer backup in some critical
systems.
In general, nothing is perfect. Everything has both upside and downside.
People should not overdo, nor undo anything. But it's very chalenging to do
just right ;-( ;-( If we pick the most convenience working for ourselve,
it's likely we work in the best mood, hence less prone to err. To me, the
least code is the best as bug probability is proportinal to the code size.
As usual, I could be wrong !
Anyway, I may have made a little progrss in both ways high and low level
access ;-) ;-)
Cheers,
Duy-Ky
-----Original Message-----
From: owner-microblaze-uclinux@xxxxxxxxxxxxxx
[mailto:owner-microblaze-uclinux@xxxxxxxxxxxxxx] On Behalf Of Benny Chen
Sent: Thursday, September 06, 2007 6:25 PM
To: microblaze-uclinux@xxxxxxxxxxxxxx
Subject: Re: [microblaze-uclinux] Low level access
Hi Duy-ky,
Without hardware MMU support it is even more important for your application
code to access your ipcore via the IOCTL() command. This is so because it
would help prevent your application code from bringing down the kernel when
it does incorrect memory access due to pointer referencing error.
The recommended way is to write a thin driver for your ipcore and provide
access to the application program via the device file interface.
If you like the idea of referencing memory via their address instead of
IOCTL then look at mmap() support for your driver.
Cheers,
B,
Duy-Ky Nguyen wrote:
> Hello,
>
> I got some experiences on low level access in Linux using X86 and
> MPC8272. They were "real Linux" with memory protection between kernel
> and user space, so I had to go through ioctl for low level access.
>
> I'm quite aware that uCLinux does not have that kind of protection. In
> experience, loose something goes together with gain some thing, so I
> expect I'm able to have more direct access of low level.
>
> Let's say I have a user_ip at 0x40080000, I've created a new myapp_hw
> in user-apps, and failed to compile a code using
>
> // Start of code
> #include <asm/io.h>
> #define BASEADDR 0x40080000
> . .
> x = inl((volatile unsigned *) (BASEADDR)); // read-only reg
> outl(1, (volatile unsigned *) (BASEADDR)); // write 1 to RWreg
> ..
> // End of code
>
> I had very long list of error from the compilation.
>
> I'd really appreciate if I'd be shown how to use these low-level IO
> access functions.
>
> Thanks a lot,
>
> Duy-Ky
>
>
>
>
>
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@xxxxxxxxxxxxxx
> Project Home Page :
> http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive :
> http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
>
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive :
http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive :
http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive :
http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/