headers
m madhuker | 2 Aug 2004 09:25
Picon
Favicon

Regarding parallel port in MPC8245...


Hello all...
         Im working on MPC8245 board..
with timesys GPL-linux..

I want to transfer data(just glow a light) in serial
port or parallel port...

so i worte a simple program to glow a light in
parallel port as follows:

---------
#include "asm/io.h"
#include<unistd.h>
#include<stdlib.h>
#include<stdio.h>
main()
{
        outb(0x378,0xff);
        printf("Data sent out \n");
}
----------------------------------------

but when i compiled,it showing errors as follows:

[root <at> mail root]# powerpc-linux-gcc out.c
/tmp/ccED5Jlo.o: In function `main':
/tmp/ccED5Jlo.o(.text+0x20): undefined reference to
`outb'
/tmp/ccED5Jlo.o(.text+0x20): relocation truncated to
(Continue reading)

Permalink | Reply | 3 comments |
headers
Pantelis Antoniou | 2 Aug 2004 09:34
Picon
Favicon

Re: Regarding parallel port in MPC8245...


m madhuker wrote:
> Hello all...
>          Im working on MPC8245 board..
> with timesys GPL-linux..
>
> I want to transfer data(just glow a light) in serial
> port or parallel port...
>
> so i worte a simple program to glow a light in
> parallel port as follows:
>
> ---------
> #include "asm/io.h"
> #include<unistd.h>
> #include<stdlib.h>
> #include<stdio.h>
> main()
> {
>         outb(0x378,0xff);
>         printf("Data sent out \n");
> }
> ----------------------------------------
>
> but when i compiled,it showing errors as follows:
>
> [root <at> mail root]# powerpc-linux-gcc out.c
> /tmp/ccED5Jlo.o: In function `main':
> /tmp/ccED5Jlo.o(.text+0x20): undefined reference to
> `outb'
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wolfgang Denk | 2 Aug 2004 10:13
Picon
Picon
Favicon

Re: Regarding parallel port in MPC8245...


In message <20040802072537.86860.qmail <at> web13604.mail.yahoo.com> you wrote:
>
>          Im working on MPC8245 board..
> with timesys GPL-linux..
...
> ---------
> #include "asm/io.h"
> #include<unistd.h>
> #include<stdlib.h>
> #include<stdio.h>
> main()
> {
>         outb(0x378,0xff);
>         printf("Data sent out \n");
> }
> ----------------------------------------
...
> the oub function  defination is in  "asm/io.h"..which
> i included but also it is showing error undefined
> reference...

You make many errors here at once.

First: "asm/io.h" is a kernel header file, and you are  not  supposed
to include it at all in a user space application file.

Second: outb() is only available for kernel code (drivers) on PowerPC.

Third: I don't think that 0x378 will work on your MPC8245 board.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 2 Aug 2004 10:53
Picon
Picon
Favicon

Re: Regarding parallel port in MPC8245...


Dear Pantelis,

in message <410DEE94.8030601 <at> intracom.gr> you wrote:
>
> > so i worte a simple program to glow a light in
> > parallel port as follows:
...
> http://www.amazon.com/exec/obidos/tg/detail/-/0764551302/002-9292903-4601667?v=glance

Did you _really_ intend to point to "Gardening for Dummies"  by  Mike
MacCaskey & Bill Marken?

How is this related to this topic?

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
There are no data that cannot be plotted on a straight  line  if  the
axis are chosen correctly.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Permalink | Reply | 0 comments |
headers
Richard Williams | 2 Aug 2004 23:13

Looking for fast flash programming code


Hi,

I am looking for fast flash programming code for AMD. Does this exist anywhere?

In kernel 2.4.24, amd_flash.c only implements the slow programming algorithm.

Regards,
Richard

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Permalink | Reply | 2 comments |
headers
Eugene Surovegin | 3 Aug 2004 02:35

Re: Looking for fast flash programming code


On Tue, Aug 03, 2004 at 09:13:40AM +1200, Richard Williams wrote:
>
> I am looking for fast flash programming code for AMD. Does this exist anywhere?
>
> In kernel 2.4.24, amd_flash.c only implements the slow programming algorithm.

IIRC, buffer write support for AMD chips is in MTD CVS.

--
Eugene

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Permalink | Reply | 1 comment |
headers
David Woodhouse | 3 Aug 2004 10:15
Favicon

Re: Looking for fast flash programming code


On Mon, 2004-08-02 at 17:35 -0700, Eugene Surovegin wrote:
> On Tue, Aug 03, 2004 at 09:13:40AM +1200, Richard Williams wrote:
> >
> > I am looking for fast flash programming code for AMD. Does this exist anywhere?
> >
> > In kernel 2.4.24, amd_flash.c only implements the slow programming algorithm.
>
> IIRC, buffer write support for AMD chips is in MTD CVS.

...which means it's in 2.6 already. Why are you still using 2.4?

--
dwmw2

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Permalink | Reply | 0 comments |
headers
Josh Boyer | 4 Aug 2004 01:05
Favicon

Large TLBs on 40x


Howdy,

In 2.6, the PPC mm code for 4xx platforms uses large TLB entries for
most of RAM.  Specifically, I am looking at arch/ppc/mm/4xx_mmu.c at the
mmu_mapin_ram function.  In there, the pmd pointers are setup with
_PMD_SIZE_16M | _PAGE_HWEXEC | _PAGE_HWWRITE.

Doesn't this allow the text pages of the kernel to be written to?  So to
my understanding, a buggy driver that went off into the weeds could
corrupt the text pages of the kernel.

I would think that you would want the kernel text pages to be
non-writable so that if something like the above scenario happened you
don't have possibly bad text pages.  Debugging wouldn't be much fun.

I think I am missing something here.  If so, please excuse my lack of
knowledge on TLBs, but I am somewhat new to the low level stuff.  Anyone
care to point out what I am missing?

thx,
josh

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Permalink | Reply | 17 comments |
headers
Matt Porter | 4 Aug 2004 02:16

Re: Large TLBs on 40x


On Tue, Aug 03, 2004 at 06:05:42PM -0500, Josh Boyer wrote:
>
> Howdy,
>
> In 2.6, the PPC mm code for 4xx platforms uses large TLB entries for
> most of RAM.  Specifically, I am looking at arch/ppc/mm/4xx_mmu.c at the
> mmu_mapin_ram function.  In there, the pmd pointers are setup with
> _PMD_SIZE_16M | _PAGE_HWEXEC | _PAGE_HWWRITE.
>
> Doesn't this allow the text pages of the kernel to be written to?  So to

Yes.

> my understanding, a buggy driver that went off into the weeds could
> corrupt the text pages of the kernel.

Yes.

> I would think that you would want the kernel text pages to be
> non-writable so that if something like the above scenario happened you
> don't have possibly bad text pages.  Debugging wouldn't be much fun.

Ideally, that's true. However, the kernel lowmem large TLB mapping is
there for performance. There's no way to manage default page size
protection on the text pages. It's a tradeoff between performance
and the ease of debugging a misguided driver. With all the kernel
debugging tools these days, it sure seems like performance is the
clear winner.
(Continue reading)

Permalink | Reply | 16 comments |
headers
Josh Boyer | 4 Aug 2004 13:49
Favicon

Re: Large TLBs on 40x


On Tue, 2004-08-03 at 19:16, Matt Porter wrote:
> > I would think that you would want the kernel text pages to be
> > non-writable so that if something like the above scenario happened you
> > don't have possibly bad text pages.  Debugging wouldn't be much fun.
>
> Ideally, that's true. However, the kernel lowmem large TLB mapping is
> there for performance. There's no way to manage default page size
> protection on the text pages. It's a tradeoff between performance
> and the ease of debugging a misguided driver. With all the kernel
> debugging tools these days, it sure seems like performance is the
> clear winner.

Well at least my understanding of what was going on was right :).  I see
the tradeoff, I was just wondering if there was some happy medium.
Maybe pinning a read-only TLB entry for most of the text pages for
however large you can get would work...  or maybe not.

It's probably not that large of an issue for a normal user because the
kernel and drivers are fairly stable, which makes performance more
important.  But when someone is writing new drivers, randomly poking
holes in the kernel text pages and then executing instructions from
there leads to some strange panics.  Although, the new driver should be
suspect in that case anyway :).

>
> > I think I am missing something here.  If so, please excuse my lack of
> > knowledge on TLBs, but I am somewhat new to the low level stuff.  Anyone
> > care to point out what I am missing?
>
(Continue reading)

Permalink | Reply | 15 comments |

Gmane