* Re: RFC: PHY Abstraction Layer II
From: Pantelis Antoniou @ 2005-05-12 6:08 UTC (permalink / raw)
To: Andy Fleming; +Cc: netdev, linuxppc-embedded, David S. Miller
In-Reply-To: <30d87aabd768216ef8bee800f3e09b9e@freescale.com>
Andy Fleming wrote:
>
> On Apr 17, 2005, at 08:00, James Chapman wrote:
>
>> Andy Fleming wrote:
>>
>>> Ok, here's the new patch with changes suggested by James Chapman:
>>
>>
>> I guess I still have questions about the way interrupts are used.
>>
>> Using an interrupt to schedule a work queue which then sets a variable
>> that is used by a timer seems odd. Why not do all the work in the work
>> queue and schedule it from the interrupt handler or timer?
>
>
> Ok, I've set up a new system for handling interrupts. There are now two
> "special" interrupt values, PHY_POLL, and PHY_IGNORE_INTERRUPT. The
> first one is used to indicate that the PHY layer will poll the PHY for
> state changes, and won't enable interrupts. The second indicates that
> the PHY layer will neither poll, nor enable interrupts, and thus will
> allow the driver to handle interrupts. The PHY layer will still operate
> its state machine, though.
>
> The driver must insure a couple things:
>
> 1) It must set phydev->state to PHY_CHANGELINK
> 2) It must do that in a work queue (or other non-interrupt time)
>
> The first one tells the PHY layer that the link state changed (it has to
> grab a lock to do this). The second one is required in order to
> properly take the lock.
>
>>
>> Also, did you mean to leave the #if 0 code in davicom.c?
>
>
> For now. It worked around a problem some people were reporting, so I'd
> like to see if they report it again now that the code's out. If so,
> they have a fairly easy fix, and I can reinsert it (or at least
> reevaluate it) in the future.
>
>>
>> /james
>
>
> Andy
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Hi Andy.
Mind taking a look at the combined FEC/FCC driver I've posted and
comment on how hard it'll be to use your PAL? I'd be especially
interested at any API mismatches, and problems you might find.
Regards
Pantelis
^ permalink raw reply
* how is flow in linux right from bootstrap program
From: majid khan khan @ 2005-05-12 6:43 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 345 bytes --]
Hi All,
i am new to PowerPC arch , is anyone tell me what is the best way to know the flow in linux-ppc right from bootstrap program. if it could be better if anyone already has the flow for specific processor say MPC7447 processsor along with their function names.
ur reply most appreciated.
Thanks,
Majid
Thanks/Majid.
[-- Attachment #2: Type: text/html, Size: 626 bytes --]
^ permalink raw reply
* Hi!
From: venkata ramesh @ 2005-05-12 7:29 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
I am developing driver for MPC8260 for MCC.
After issuing reset command, there is space
for intrrupt table but flag is generated
for interrupt queue is overflow.
Can u suggest me how to solve the problem ??
Thanks.
Regards,
RAMESH
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
^ permalink raw reply
* ELDK/DENX linking fails for <iostream>
From: Peter Gehirnforce @ 2005-05-12 7:50 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
when I try to link (after successful compile), I get the following type of
errors (for example):
...
undefined reference to 'std::allocator<char>::allocator[in-charge]()'
...
undefined reference to '__cxa_allocate_exception'
...
Can someone explain what happens?
thx
Peter
--
+++ Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS +++
GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail
^ permalink raw reply
* Re: how is flow in linux right from bootstrap program
From: Marc Leeman @ 2005-05-12 7:47 UTC (permalink / raw)
To: majid khan khan; +Cc: linuxppc-dev
In-Reply-To: <20050512064316.16591.qmail@webmail18.rediffmail.com>
[-- Attachment #1: Type: text/plain, Size: 482 bytes --]
> i am new to PowerPC arch , is anyone tell me what is the best way to know
Off the top of my mind; ...
The only thing that you need to know IIRC is that the boot address is at
0xfff00000. I believe that's fixed. If your bootloader is placed there,
you can let it jump to whereever you want.
--
greetz, marc
Harvey, kiss my medulla oblongata.
Crichton - Infinite Possibilities - Daedalus Demands.shtml
scorpius 2.6.11 #1 Wed Mar 2 16:38:38 CET 2005 GNU/Linux
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: ELDK/DENX linking fails for <iostream>
From: Wolfgang Denk @ 2005-05-12 8:27 UTC (permalink / raw)
To: Peter Gehirnforce; +Cc: linuxppc-embedded
In-Reply-To: <25943.1115884246@www45.gmx.net>
In message <25943.1115884246@www45.gmx.net> you wrote:
>
> when I try to link (after successful compile), I get the following type of
How exactly are you trying to link?
> errors (for example):
> ...
> undefined reference to 'std::allocator<char>::allocator[in-charge]()'
> ...
> undefined reference to '__cxa_allocate_exception'
> ...
> Can someone explain what happens?
This is most probably a usage error. But you don't provide enough
information.
Please show us the EXACT commands you're using, and provide a
(simple) example that shows the problem.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I don't mind criticism. You know me. I've never been one to take
offence at criticism. No one could say I'm the sort to take offence
at criticism -- Not twice, anyway. Not without blowing bubbles.
- Terry Pratchett, _Witches Abroad_
^ permalink raw reply
* Re: how is flow in linux right from bootstrap program
From: Wolfgang Denk @ 2005-05-12 8:29 UTC (permalink / raw)
To: Marc Leeman; +Cc: majid khan khan, linuxppc-dev
In-Reply-To: <20050512074751.GH21217@scorpius.homelinux.org>
In message <20050512074751.GH21217@scorpius.homelinux.org> you wrote:
>
> The only thing that you need to know IIRC is that the boot address is at
> 0xfff00000. I believe that's fixed. If your bootloader is placed there,
No, it is not. Assuming we're talking about PowerPC systems only: it
may be at 0x0100 on some systems, or 0xFFF00100 on others, orit may
be configurable (for example with a jumper) to be either of these
addresses, or it may be 0xFFFFFFFC on other processors.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Harrisberger's Fourth Law of the Lab:
Experience is directly proportional to the
amount of equipment ruined.
^ permalink raw reply
* Re: [ANNOUNCE] mini_fo-0.6.0 overlay file system]
From: Wolfgang Denk @ 2005-05-12 8:37 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: Markus Klotzbuecher, linuxppc-embedded
Dear Pantelis,
you wrote:
>
...
> >>Could you post the patches in the list so that we can discuss
> >>them properly?
The sources are probably a bit too big for posting. As Markus
mentioned before, the source tarball is available at
http://www.denx.de/twiki/bin/view/Know/MiniFOHome:
> Yes, so we can discuss them...
The code is here:
http://www.denx.de/twiki/pub/Know/MiniFOHome/mini_fo-0-6-1-pre1.tar.bz2
> It's a very useful functionality that's I'd like to be present
> in the vanilla kernel if possible.
That would be great. Please keep Markus and me informed what it needs
to get there.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
God grant me the senility to accept the things I cannot change, The
frustration to try to change things I cannot affect, and the wisdom
to tell the difference.
^ permalink raw reply
* Re: ELDK/DENX: doesn't find iostream-lib when linking
From: Peter Gehirnforce @ 2005-05-12 9:13 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050512074615.30BE8C1512@atlas.denx.de>
I use a makefile with dependencies:
--------------------------------------------------
# Makefile for simple test program
# The CROSS_COMPILE is set globally, as well as ELDK gcc-paths
compiler = ${CROSS_COMPILE}gcc
simple_server_objects = ServerSocket.o Socket.o simple_server_main.o
simple_client_objects = ClientSocket.o Socket.o simple_client_main.o
all : Socket ServerSocket simple_server_main simple_server ClientSocket
simple_c
lient_main simple_client
simple_server: $(simple_server_objects)
$(compiler) -o simple_server $(simple_server_objects)
simple_client: $(simple_client_objects)
$(compiler) -o simple_client $(simple_client_objects)
#ppc_gcc dependencies, added for compiling with ppc only!!
Socket:
$(compiler) -o Socket.o -c Socket.cpp
ServerSocket: Socket.o
$(compiler) -o ServerSocket.o -c ServerSocket.cpp
ClientSocket: Socket.o
$(compiler) -o ClientSocket.o -c ClientSocket.cpp
simple_server_main: ServerSocket.o
$(compiler) -o simple_server_main.o -c simple_server_main.cpp
simple_client_main: ClientSocket.o
$(compiler) -o simple_client_main.o -c simple_client_main.cpp
clean:
rm -f *.o simple_server simple_client
------------------------------------------------
The program itself is using <string> <iostream> and other STL libs with
namespaces in use.
It compiles for i686 on my host machine.
BUT I had to change the Makefile!!! (that is why I posted it)
The dependencies starting from "gcc-ppc" dependencies are added.
Are they defined wrong?
Peter
> --- Ursprüngliche Nachricht ---
> Von: Wolfgang Denk <wd@denx.de>
> An: "Peter Gehirnforce" <Gehirnmann@gmx.de>
> Kopie: etux@embeddedtux.org
> Betreff: Re: ELDK/DENX: doesn't find iostream-lib when linking
> Datum: Thu, 12 May 2005 09:46:10 +0200
>
> In message <28918.1115882747@www45.gmx.net> you wrote:
> >
> > when compiling for ppc_6xx architecture, the linker doesn't find the
> lib's
> > for iostream headers.
> > Do I have to use other headers than the standard <iostream> ones, or do
> they
> > simply not exist?
>
> I guess this is a usage error. Can you please provide a simple
> example which shows the problem?
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> What is research but a blind date with knowledge? -- Will Harvey
> _______________________________________________
> etux mailing list
> etux@embeddedtux.org
> http://www.embeddedtux.org/mailman/listinfo/etux
>
--
+++ Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS +++
GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail
^ permalink raw reply
* PPPoE setup
From: Atit_Shah @ 2005-05-12 9:25 UTC (permalink / raw)
To: linuxppc-embedded
Does any one know how I can start the pppoe server and how I can get an
IP address assigned to the port?
Is there a web-site where I can get details on this?
Atit
DISCLAIMER:
This email (including any attachments) is intended for the sole use of =
the intended recipient/s and may contain material that is CONFIDENTIAL =
AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or =
copying or distribution or forwarding of any or all of the contents in =
this message is STRICTLY PROHIBITED. If you are not the intended =
recipient, please contact the sender by email and delete all copies; =
your cooperation in this regard is appreciated.
^ permalink raw reply
* Re: ELDK/DENX: doesn't find iostream-lib when linking
From: Wolfgang Denk @ 2005-05-12 9:47 UTC (permalink / raw)
To: Peter Gehirnforce; +Cc: linuxppc-embedded
In-Reply-To: <25101.1115889218@www45.gmx.net>
In message <25101.1115889218@www45.gmx.net> you wrote:
> I use a makefile with dependencies:
I asked for the COMMANDS used, not for a Makefile. A log of the build
process would have been more useful, but anyway...
> compiler = ${CROSS_COMPILE}gcc
...
> simple_client: $(simple_client_objects)
> $(compiler) -o simple_client $(simple_client_objects)
>
> #ppc_gcc dependencies, added for compiling with ppc only!!
> Socket:
> $(compiler) -o Socket.o -c Socket.cpp
...
> Are they defined wrong?
You are using the wrong compiler. GCC is a C Compiler, but you are
trying to compile and link C++ code. GCC does not know how to handle
this. Please use a C++ compiler - i. e. "g++" - instead.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Unix is like a toll road on which you have to stop every 50 feet to
pay another nickel. But hey! You only feel 5 cents poorer each time.
- Larry Wall in <1992Aug13.192357.15731@netlabs.com>
^ permalink raw reply
* Re: [PATCH 03/04] Freescale Ethernet combined driver
From: Pantelis Antoniou @ 2005-05-12 9:37 UTC (permalink / raw)
To: Matt Porter; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <20050510064702.B21835@cox.net>
[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]
Matt Porter wrote:
> On Tue, May 10, 2005 at 04:14:51PM +0300, Pantelis Antoniou wrote:
>
>>Matt Porter wrote:
>>
>>>On Tue, May 10, 2005 at 08:13:48AM -0400, Dan Malek wrote:
>>>
>>>
>>>>On May 10, 2005, at 7:17 AM, Pantelis Antoniou wrote:
>>>>
>>>>
>>>>
>>>>>This patch replace iopa use with virt_to_phys.
>>>>
>>>>Not gonna work .....
>>>>
>>>>When you map uncached on 8xx you get a new vmalloc()
>>>>space. The virt_to_xxx macros don't work on those addresses.
>>>>You need to use the dma_consistent() function, stash the
>>>>real physical address it returns and then use it where
>>>>appropriate.
>>>
>>>
>>>That and the use of virt_to_* and friends is deprecated by
>>>the DMA API. You'll never get that upstream even if it were
>>>a case where it did work. That's a good thing to know for
>>>anybody doing other drivers...
>>>
>>>-Matt
>>>
>>>
>>
>>OK then.
>>
>>What's the recommended function to call to go from a
>>virtual -> physical address, but without doing a cache
>>flush/invalidate?
>
>
> There is no generic function to do that in a driver since
> no mainstream drivers in the kernel need to do it. Generally
> you can rework the driver such that you cache the DMA address
> as Dan suggested already. I don't know your exact usage, however,
> you can allocate memory with dma_alloc_noncoherent() that is
> cached on ppc32 NOT_CACHE_COHERENT prcoessors and stash the
> dma_addr_t/void * for later use. The other way is to kmalloc and
> dma_map_single() (stashing the same way) which is basically the
> same thing.
>
> Do you have a case where this doesn't work?
>
> -Matt
>
>
Here is the final (I hope) fix.
This patch kills iopa/virt_to_phys usage by using the returned
physical address from the DMA API.
Comments?
Regards
Pantelis
[-- Attachment #2: fs_enet-iopa-kill.patch --]
[-- Type: text/x-patch, Size: 2328 bytes --]
Index: linux-2.6.11.7-fs_enet/drivers/net/fs_enet/mac-fcc.c
===================================================================
--- linux-2.6.11.7-fs_enet.orig/drivers/net/fs_enet/mac-fcc.c
+++ linux-2.6.11.7-fs_enet/drivers/net/fs_enet/mac-fcc.c
@@ -212,8 +212,10 @@ static void restart(struct net_device *d
{
cpm2_map_t *immap = (cpm2_map_t *)CPM_MAP_ADDR;
struct fs_enet_private *fep = netdev_priv(dev);
+ const struct fs_platform_info *fpi = fep->fpi;
fcc_t *fccp = fep->fcc.fccp;
fcc_enet_t *ep = fep->fcc.ep;
+ dma_addr_t rx_bd_base_phys, tx_bd_base_phys;
__u16 paddrh, paddrm, paddrl;
__u16 mem_addr;
const unsigned char *mac;
@@ -225,9 +227,13 @@ static void restart(struct net_device *d
for (i = 0; i < sizeof(*ep); i++)
__fcc_out8((char *)ep + i, 0);
+ /* get physical address */
+ rx_bd_base_phys = fep->ring_mem_addr;
+ tx_bd_base_phys = rx_bd_base_phys + sizeof(cbd_t) * fpi->rx_ring;
+
/* point to bds */
- W32(ep, fen_genfcc.fcc_rbase, iopa((__u32)fep->rx_bd_base));
- W32(ep, fen_genfcc.fcc_tbase, iopa((__u32)fep->tx_bd_base));
+ W32(ep, fen_genfcc.fcc_rbase, rx_bd_base_phys);
+ W32(ep, fen_genfcc.fcc_tbase, tx_bd_base_phys);
/* Set maximum bytes per receive buffer.
* It must be a multiple of 32.
Index: linux-2.6.11.7-fs_enet/drivers/net/fs_enet/mac-fec.c
===================================================================
--- linux-2.6.11.7-fs_enet.orig/drivers/net/fs_enet/mac-fec.c
+++ linux-2.6.11.7-fs_enet/drivers/net/fs_enet/mac-fec.c
@@ -271,6 +271,7 @@ static void restart(struct net_device *d
struct fs_enet_private *fep = netdev_priv(dev);
fec_t *fecp = fep->fec.fecp;
const struct fs_platform_info *fpi = fep->fpi;
+ dma_addr_t rx_bd_base_phys, tx_bd_base_phys;
int r;
__u32 addrhi, addrlo;
@@ -303,11 +304,15 @@ static void restart(struct net_device *d
FW(fecp, r_buff_size, PKT_MAXBLR_SIZE);
FW(fecp, r_hash, PKT_MAXBUF_SIZE);
+ /* get physical address */
+ rx_bd_base_phys = fep->ring_mem_addr;
+ tx_bd_base_phys = rx_bd_base_phys + sizeof(cbd_t) * fpi->rx_ring;
+
/*
* Set receive and transmit descriptor base.
*/
- FW(fecp, r_des_start, iopa((__u32)fep->rx_bd_base));
- FW(fecp, x_des_start, iopa((__u32)fep->tx_bd_base));
+ FW(fecp, r_des_start, rx_bd_base_phys);
+ FW(fecp, x_des_start, tx_bd_base_phys);
fs_init_bds(dev);
^ permalink raw reply
* Re: ELDK/DENX: doesn't find iostream-lib when linking
From: Matej Kupljen @ 2005-05-12 9:12 UTC (permalink / raw)
To: Peter Gehirnforce; +Cc: linuxppc-embedded
In-Reply-To: <25101.1115889218@www45.gmx.net>
Hi
> compiler = ${CROSS_COMPILE}gcc
>
> .... <snip>
>
> The program itself is using <string> <iostream> and other STL libs with
> namespaces in use.
Change the gcc to g++ if you use STL and C++ programs.
BR,
Matej
^ permalink raw reply
* Re: ELDK/DENX: doesn't find iostream-lib when linking
From: Jaap-Jan Boor @ 2005-05-12 10:26 UTC (permalink / raw)
To: Peter Gehirnforce; +Cc: linuxppc-embedded
In-Reply-To: <25101.1115889218@www45.gmx.net>
Peter,
you should use g++ as compiler front end when compiling C++ programs
> compiler =3D ${CROSS_COMPILE}g++
best regards,
Jaap-Jan
On 12-mei-05, at 11:13, Peter Gehirnforce wrote:
> I use a makefile with dependencies:
>
> --------------------------------------------------
> # Makefile for simple test program
> # The CROSS_COMPILE is set globally, as well as ELDK gcc-paths
>
> compiler =3D ${CROSS_COMPILE}gcc
> simple_server_objects =3D ServerSocket.o Socket.o simple_server_main.o
> simple_client_objects =3D ClientSocket.o Socket.o simple_client_main.o
>
>
> all : Socket ServerSocket simple_server_main simple_server =
ClientSocket
> simple_c
> lient_main simple_client
>
> simple_server: $(simple_server_objects)
> $(compiler) -o simple_server $(simple_server_objects)
>
>
> simple_client: $(simple_client_objects)
> $(compiler) -o simple_client $(simple_client_objects)
>
> #ppc_gcc dependencies, added for compiling with ppc only!!
> Socket:
> $(compiler) -o Socket.o -c Socket.cpp
>
> ServerSocket: Socket.o
> $(compiler) -o ServerSocket.o -c ServerSocket.cpp
>
> ClientSocket: Socket.o
> $(compiler) -o ClientSocket.o -c ClientSocket.cpp
>
> simple_server_main: ServerSocket.o
> $(compiler) -o simple_server_main.o -c simple_server_main.cpp
>
> simple_client_main: ClientSocket.o
> $(compiler) -o simple_client_main.o -c simple_client_main.cpp
>
> clean:
> rm -f *.o simple_server simple_client
> ------------------------------------------------
>
> The program itself is using <string> <iostream> and other STL libs =
with
> namespaces in use.
> It compiles for i686 on my host machine.
> BUT I had to change the Makefile!!! (that is why I posted it)
> The dependencies starting from "gcc-ppc" dependencies are added.
> Are they defined wrong?
>
> Peter
>
>> --- Urspr=FCngliche Nachricht ---
>> Von: Wolfgang Denk <wd@denx.de>
>> An: "Peter Gehirnforce" <Gehirnmann@gmx.de>
>> Kopie: etux@embeddedtux.org
>> Betreff: Re: ELDK/DENX: doesn't find iostream-lib when linking
>> Datum: Thu, 12 May 2005 09:46:10 +0200
>>
>> In message <28918.1115882747@www45.gmx.net> you wrote:
>>>
>>> when compiling for ppc_6xx architecture, the linker doesn't find the
>> lib's
>>> for iostream headers.
>>> Do I have to use other headers than the standard <iostream> ones, or=20=
>>> do
>> they
>>> simply not exist?
>>
>> I guess this is a usage error. Can you please provide a simple
>> example which shows the problem?
>>
>> Best regards,
>>
>> Wolfgang Denk
>>
>> --=20
>> Software Engineering: Embedded and Realtime Systems, Embedded Linux
>> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
>> What is research but a blind date with knowledge? -- Will Harvey
>> _______________________________________________
>> etux mailing list
>> etux@embeddedtux.org
>> http://www.embeddedtux.org/mailman/listinfo/etux
>>
>
> --=20
> +++ Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS +++
> GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] Freescale Ethernet combined driver
From: Jaap-Jan Boor @ 2005-05-12 10:53 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <427F4D41.10908@intracom.gr>
Hi,
May be a little late (I'm trying to catch up on all mailing list mail)
but I was wondering if the io port handling functions I see now in
these patches
should not be 'atomic'. So toggling MII pins does not interfere with
toggling
e.g. I2C bit-bang interface pins when those pins happen to be on the
same
port (A/B/C/D/E).
best regards,
Jaap-Jan
^ permalink raw reply
* Re: [PATCH] Freescale Ethernet combined driver
From: Pantelis Antoniou @ 2005-05-12 10:43 UTC (permalink / raw)
To: Jaap-Jan Boor; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <883b9affce23db0859a4619cff66da4e@aimsys.nl>
Jaap-Jan Boor wrote:
> Hi,
>
> May be a little late (I'm trying to catch up on all mailing list mail)
> but I was wondering if the io port handling functions I see now in these
> patches
> should not be 'atomic'. So toggling MII pins does not interfere with
> toggling
> e.g. I2C bit-bang interface pins when those pins happen to be on the same
> port (A/B/C/D/E).
>
> best regards,
>
> Jaap-Jan
>
>
>
Jaap-Jan
All mii operations are done under a spinlock with interrupts disabled.
Regards
Pantelis
^ permalink raw reply
* JFFS Filesystem Problem
From: Vijesh VH @ 2005-05-12 10:56 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 15936 bytes --]
Hi,
I am trying to mount a JFFS Filesystem from Flash as a root Device. I faced
the following Problem . Required help on this regard
*****************
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
cramfs: wrong magic
attempt to access beyond end of device
1f:00: rw=0, want=65, limit=64
isofs_read_super: bread failed, dev=1f:00, iso_blknum=32, block=64
JFFS: Trying to mount device 1f:00.
jffs_build_fs()
jffs_create_control()
jffs_build_begin()
fmc->flash_size = 65536 bytes
jffs_scan_flash(): start pos = 0x0, end = 0x10000
check_partly_erased_sector():checking sector which contains offset 0x0 for
flipping bits..
flash_safe_read(c03e6260, 00000000, c03a6000, 00001000)
flash_safe_read(c03e6260, 00000000, c0367000, 00001000)
flash_safe_read(c03e6260, 00000000, c0367000, 00001000)
flash_safe_read(c03e6260, 00000000, c0367000, 00001000)
flash_safe_read(c03e6260, 00000000, c0367000, 00001000)
check_partly_erased_sector():checking sector which contains offset 0x1000
for flipping bits..
flash_safe_read(c03e6260, 00001000, c03a6000, 00001000)
flash_safe_read(c03e6260, 00001000, c0367000, 00001000)
flash_safe_read(c03e6260, 00001000, c0367000, 00001000)
flash_safe_read(c03e6260, 00001000, c0367000, 00001000)
flash_safe_read(c03e6260, 00001000, c0367000, 00001000)
check_partly_erased_sector():checking sector which contains offset 0x2000
for flipping bits..
flash_safe_read(c03e6260, 00002000, c03a6000, 00001000)
flash_safe_read(c03e6260, 00002000, c0367000, 00001000)
flash_safe_read(c03e6260, 00002000, c0367000, 00001000)
flash_safe_read(c03e6260, 00002000, c0367000, 00001000)
flash_safe_read(c03e6260, 00002000, c0367000, 00001000)
check_partly_erased_sector():checking sector which contains offset 0x3000
for flipping bits..
flash_safe_read(c03e6260, 00003000, c03a6000, 00001000)
flash_safe_read(c03e6260, 00003000, c0367000, 00001000)
flash_safe_read(c03e6260, 00003000, c0367000, 00001000)
flash_safe_read(c03e6260, 00003000, c0367000, 00001000)
flash_safe_read(c03e6260, 00003000, c0367000, 00001000)
check_partly_erased_sector():checking sector which contains offset 0x4000
for flipping bits..
flash_safe_read(c03e6260, 00004000, c03a6000, 00001000)
flash_safe_read(c03e6260, 00004000, c0367000, 00001000)
flash_safe_read(c03e6260, 00004000, c0367000, 00001000)
flash_safe_read(c03e6260, 00004000, c0367000, 00001000)
flash_safe_read(c03e6260, 00004000, c0367000, 00001000)
check_partly_erased_sector():checking sector which contains offset 0x5000
for flipping bits..
flash_safe_read(c03e6260, 00005000, c03a6000, 00001000)
flash_safe_read(c03e6260, 00005000, c0367000, 00001000)
flash_safe_read(c03e6260, 00005000, c0367000, 00001000)
flash_safe_read(c03e6260, 00005000, c0367000, 00001000)
flash_safe_read(c03e6260, 00005000, c0367000, 00001000)
check_partly_erased_sector():checking sector which contains offset 0x6000
for flipping bits..
flash_safe_read(c03e6260, 00006000, c03a6000, 00001000)
flash_safe_read(c03e6260, 00006000, c0367000, 00001000)
flash_safe_read(c03e6260, 00006000, c0367000, 00001000)
flash_safe_read(c03e6260, 00006000, c0367000, 00001000)
flash_safe_read(c03e6260, 00006000, c0367000, 00001000)
check_partly_erased_sector():checking sector which contains offset 0x7000
for flipping bits..
flash_safe_read(c03e6260, 00007000, c03a6000, 00001000)
flash_safe_read(c03e6260, 00007000, c0367000, 00001000)
flash_safe_read(c03e6260, 00007000, c0367000, 00001000)
flash_safe_read(c03e6260, 00007000, c0367000, 00001000)
flash_safe_read(c03e6260, 00007000, c0367000, 00001000)
check_partly_erased_sector():checking sector which contains offset 0x8000
for flipping bits..
flash_safe_read(c03e6260, 00008000, c03a6000, 00001000)
flash_safe_read(c03e6260, 00008000, c0367000, 00001000)
flash_safe_read(c03e6260, 00008000, c0367000, 00001000)
flash_safe_read(c03e6260, 00008000, c0367000, 00001000)
flash_safe_read(c03e6260, 00008000, c0367000, 00001000)
check_partly_erased_sector():checking sector which contains offset 0x9000
for flipping bits..
flash_safe_read(c03e6260, 00009000, c03a6000, 00001000)
flash_safe_read(c03e6260, 00009000, c0367000, 00001000)
flash_safe_read(c03e6260, 00009000, c0367000, 00001000)
flash_safe_read(c03e6260, 00009000, c0367000, 00001000)
flash_safe_read(c03e6260, 00009000, c0367000, 00001000)
check_partly_erased_sector():checking sector which contains offset 0xa000
for flipping bits..
flash_safe_read(c03e6260, 0000a000, c03a6000, 00001000)
flash_safe_read(c03e6260, 0000a000, c0367000, 00001000)
flash_safe_read(c03e6260, 0000a000, c0367000, 00001000)
flash_safe_read(c03e6260, 0000a000, c0367000, 00001000)
flash_safe_read(c03e6260, 0000a000, c0367000, 00001000)
check_partly_erased_sector():checking sector which contains offset 0xb000
for flipping bits..
flash_safe_read(c03e6260, 0000b000, c03a6000, 00001000)
flash_safe_read(c03e6260, 0000b000, c0367000, 00001000)
flash_safe_read(c03e6260, 0000b000, c0367000, 00001000)
flash_safe_read(c03e6260, 0000b000, c0367000, 00001000)
flash_safe_read(c03e6260, 0000b000, c0367000, 00001000)
check_partly_erased_sector():checking sector which contains offset 0xc000
for flipping bits..
flash_safe_read(c03e6260, 0000c000, c03a6000, 00001000)
flash_safe_read(c03e6260, 0000c000, c0367000, 00001000)
flash_safe_read(c03e6260, 0000c000, c0367000, 00001000)
flash_safe_read(c03e6260, 0000c000, c0367000, 00001000)
flash_safe_read(c03e6260, 0000c000, c0367000, 00001000)
check_partly_erased_sector():checking sector which contains offset 0xd000
for flipping bits..
flash_safe_read(c03e6260, 0000d000, c03a6000, 00001000)
flash_safe_read(c03e6260, 0000d000, c0367000, 00001000)
flash_safe_read(c03e6260, 0000d000, c0367000, 00001000)
flash_safe_read(c03e6260, 0000d000, c0367000, 00001000)
flash_safe_read(c03e6260, 0000d000, c0367000, 00001000)
check_partly_erased_sector():checking sector which contains offset 0xe000
for flipping bits..
flash_safe_read(c03e6260, 0000e000, c03a6000, 00001000)
flash_safe_read(c03e6260, 0000e000, c0367000, 00001000)
flash_safe_read(c03e6260, 0000e000, c0367000, 00001000)
flash_safe_read(c03e6260, 0000e000, c0367000, 00001000)
flash_safe_read(c03e6260, 0000e000, c0367000, 00001000)
check_partly_erased_sector():checking sector which contains offset 0xf000
for flipping bits..
flash_safe_read(c03e6260, 0000f000, c03a6000, 00001000)
flash_safe_read(c03e6260, 0000f000, c0367000, 00001000)
flash_safe_read(c03e6260, 0000f000, c0367000, 00001000)
flash_safe_read(c03e6260, 0000f000, c0367000, 00001000)
flash_safe_read(c03e6260, 0000f000, c0367000, 00001000)
check_partly_erased_sector():Done checking all sectors till offset 0x10000
for flipping bits.
*************** Dirty flash memory or bad inode: hexdump(pos = 0x0, len =
128):
0: 2a56 5044 0000 2a4e 4100 0612 3456 7890 *VPD..*NA...4Vx.
16: 442a 454e 4400 0000 0000 0000 0000 0000 D*END...........
32: 0000 0000 ffff ffff ffff ffff ffff ffff ....������������
48: ffff ffff ffff ffff ffff ffff ffff ffff ����������������
64: ffff ffff ffff ffff ffff ffff ffff ffff ����������������
80: ffff ffff ffff ffff ffff ffff ffff ffff ����������������
96: ffff ffff ffff ffff ffff ffff ffff ffff ����������������
112: ffff ffff ffff ffff ffff ffff ffff ffff ����������������
jffs_fmalloced()
struct jffs_fmcontrol: 0xc036e2e0
{
65536, /* flash_size */
0, /* used_size */
36, /* dirty_size */
65500, /* free_size */
8192, /* sector_size */
32768, /* min_free_size */
4096, /* max_chunk_size */
0xc03e6260, /* mtd */
0xc03661e0, /* head */ (head->offset = 0x00000000)
0xc03661e0, /* tail */ (tail->offset + tail->size = 0x00000024)
0x00000000, /* head_extra */
0x00000000, /* tail_extra */
}
struct jffs_fm: 0xc03661e0
{
0x00000000, /* offset */
36, /* size */
0x00000000, /* prev */
0x00000000, /* next */
0x00000000, /* nodes */
}
jffs_scan_flash(): 0xffffffff at pos 0x24.
flash_safe_read(c03e6260, 00000024, c0367000, 00001000)
jffs_scan_flash():0xffffffff ended at pos 0x1000.
Dirty space: Starting 0x24 for 0xfdc bytes
jffs_fmalloced()
struct jffs_fmcontrol: 0xc036e2e0
{
65536, /* flash_size */
0, /* used_size */
4096, /* dirty_size */
61440, /* free_size */
8192, /* sector_size */
32768, /* min_free_size */
4096, /* max_chunk_size */
0xc03e6260, /* mtd */
0xc03661e0, /* head */ (head->offset = 0x00000000)
0xc0366200, /* tail */ (tail->offset + tail->size = 0x00001000)
0x00000000, /* head_extra */
0x00000000, /* tail_extra */
}
struct jffs_fm: 0xc0366200
{
0x00000024, /* offset */
4060, /* size */
0xc03661e0, /* prev */
0x00000000, /* next */
0x00000000, /* nodes */
}
*************** Dirty flash memory or bad inode: hexdump(pos = 0x1000, len =
128):
4096: 4f53 2d4f 5045 4e00 0000 009c 0000 0006 OS-OPEN.........
4112: 0000 0000 0000 0000 0000 0000 0000 0000 ................
4128: 0000 0002 0400 0000 0400 0000 ffff ffff ............����
4144: 0000 0000 0000 0000 0101 ff01 0000 0000 ..........�.....
4160: 0000 0000 0000 0000 0101 0001 0000 0000 ................
4176: c0a8 3021 c0a8 308f 0100 0101 0000 0000 ..0!..0.........
4192: 0000 0000 0000 0000 0101 0201 0000 0001 ................
4208: 0000 0000 0000 0000 0001 ff01 0000 0000 ..........�.....
jffs_fmalloced()
struct jffs_fmcontrol: 0xc036e2e0
{
65536, /* flash_size */
0, /* used_size */
4140, /* dirty_size */
61396, /* free_size */
8192, /* sector_size */
32768, /* min_free_size */
4096, /* max_chunk_size */
0xc03e6260, /* mtd */
0xc03661e0, /* head */ (head->offset = 0x00000000)
0xc0366220, /* tail */ (tail->offset + tail->size = 0x0000102c)
0x00000000, /* head_extra */
0x00000000, /* tail_extra */
}
struct jffs_fm: 0xc0366220
{
0x00001000, /* offset */
44, /* size */
0xc0366200, /* prev */
0x00000000, /* next */
0x00000000, /* nodes */
}
jffs_scan_flash(): 0xffffffff at pos 0x102c.
flash_safe_read(c03e6260, 0000102c, c0367000, 00001000)
jffs_scan_flash():0xffffffff ended at pos 0x1030.
Dirty space: Starting 0x102c for 0x4 bytes
jffs_fmalloced()
struct jffs_fmcontrol: 0xc036e2e0
{
65536, /* flash_size */
0, /* used_size */
4144, /* dirty_size */
61392, /* free_size */
8192, /* sector_size */
32768, /* min_free_size */
4096, /* max_chunk_size */
0xc03e6260, /* mtd */
0xc03661e0, /* head */ (head->offset = 0x00000000)
0xc0366240, /* tail */ (tail->offset + tail->size = 0x00001030)
0x00000000, /* head_extra */
0x00000000, /* tail_extra */
}
struct jffs_fm: 0xc0366240
{
0x0000102c, /* offset */
4, /* size */
0xc0366220, /* prev */
0x00000000, /* next */
0x00000000, /* nodes */
}
jffs_scan_flash(): 0x00000000 at pos 0x1030.
jffs_scan_flash(): 0x00 ended at pos 0x1038.
jffs_fmalloced()
struct jffs_fmcontrol: 0xc036e2e0
{
65536, /* flash_size */
0, /* used_size */
4152, /* dirty_size */
61384, /* free_size */
8192, /* sector_size */
32768, /* min_free_size */
4096, /* max_chunk_size */
0xc03e6260, /* mtd */
0xc03661e0, /* head */ (head->offset = 0x00000000)
0xc0366260, /* tail */ (tail->offset + tail->size = 0x00001038)
0x00000000, /* head_extra */
0x00000000, /* tail_extra */
}
struct jffs_fm: 0xc0366260
{
0x00001030, /* offset */
8, /* size */
0xc0366240, /* prev */
0x00000000, /* next */
0x00000000, /* nodes */
}
*************** Dirty flash memory or bad inode: hexdump(pos = 0x1038, len =
128):
4152: 0101 ff01 0000 0000 0000 0000 0000 0000 ..�.............
4168: 0101 0001 0000 0000 c0a8 3021 c0a8 308f ..........0!..0.
4184: 0100 0101 0000 0000 0000 0000 0000 0000 ................
4200: 0101 0201 0000 0001 0000 0000 0000 0000 ................
4216: 0001 ff01 0000 0000 0000 0000 0000 0000 ..�.............
4232: 0001 ff01 0000 0000 0000 0000 001e 001e ..�.............
4248: 0280 01b8 ffff ffff ffff ffff ffff ffff ....������������
4264: ffff ffff ffff ffff ffff ffff ffff ffff ����������������
jffs_fmalloced()
struct jffs_fmcontrol: 0xc036e2e0
{
65536, /* flash_size */
0, /* used_size */
4252, /* dirty_size */
61284, /* free_size */
8192, /* sector_size */
32768, /* min_free_size */
4096, /* max_chunk_size */
0xc03e6260, /* mtd */
0xc03661e0, /* head */ (head->offset = 0x00000000)
0xc0366280, /* tail */ (tail->offset + tail->size = 0x0000109c)
0x00000000, /* head_extra */
0x00000000, /* tail_extra */
}
struct jffs_fm: 0xc0366280
{
0x00001038, /* offset */
100, /* size */
0xc0366260, /* prev */
0x00000000, /* next */
0x00000000, /* nodes */
}
jffs_scan_flash(): 0xffffffff at pos 0x109c.
flash_safe_read(c03e6260, 0000109c, c0367000, 00001000)
flash_safe_read(c03e6260, 0000209c, c0367000, 00001000)
flash_safe_read(c03e6260, 0000309c, c0367000, 00001000)
flash_safe_read(c03e6260, 0000409c, c0367000, 00001000)
flash_safe_read(c03e6260, 0000509c, c0367000, 00001000)
flash_safe_read(c03e6260, 0000609c, c0367000, 00001000)
flash_safe_read(c03e6260, 0000709c, c0367000, 00001000)
flash_safe_read(c03e6260, 0000809c, c0367000, 00001000)
flash_safe_read(c03e6260, 0000909c, c0367000, 00001000)
flash_safe_read(c03e6260, 0000a09c, c0367000, 00001000)
flash_safe_read(c03e6260, 0000b09c, c0367000, 00001000)
flash_safe_read(c03e6260, 0000c09c, c0367000, 00001000)
flash_safe_read(c03e6260, 0000d09c, c0367000, 00001000)
flash_safe_read(c03e6260, 0000e09c, c0367000, 00001000)
flash_safe_read(c03e6260, 0000f09c, c0367000, 00000f64)
jffs_scan_flash():0xffffffff ended at pos 0x10000.
Free space accepted: Starting 0x109c for 0xef64 bytes
jffs_build_end()
struct jffs_fmcontrol: 0xc036e2e0
{
65536, /* flash_size */
0, /* used_size */
4252, /* dirty_size */
61284, /* free_size */
8192, /* sector_size */
32768, /* min_free_size */
4096, /* max_chunk_size */
0xc03e6260, /* mtd */
0xc03661e0, /* head */ (head->offset = 0x00000000)
0xc0366280, /* tail */ (tail->offset + tail->size = 0x0000109c)
0x00000000, /* head_extra */
0x00000000, /* tail_extra */
}
jffs_scan_flash(): Leaving...
jffs_find_file(): ino: 1
jffs_find_file(): Didn't find file with ino 1.
jffs_add_virtual_root(): Creating a virtual root directory.
jffs_insert_file_into_hash(): f->ino: 1
jffs_possibly_delete_file(): ino: 1
jffs_remove_redundant_nodes(): ino: 1, name: "", newest_type: 1
jffs_insert_file_into_tree(): name: ""
jffs_find_file(): ino: 0
jffs_find_file(): Didn't find file with ino 0.
jffs_build_file(): ino: 1, name: ""
jffs_update_file(): ino: 1, version: 0
JFFS: Dumping the file system's hash table...
*** c->hash[1]: "" (ino: 1, pino: 0)
/ (ino: 1, highest_version: 0, size: 0)
jffs_read_inode(): inode->i_ino == 1
read_inode(): down biglock
jffs_find_file(): ino: 1
jffs_find_file(): Found file with ino 1. (name: "")
read_inode(): up biglock
JFFS: GC thread pid=8.
JFFS: Successfully mounted device 1f:00.
VFS: Mounted root (jffs filesystem) readonly.
Freeing unused kernel memory: 80k init
jffs_lookup(): dir: 0xc0384ba0, name: "dev"
lookup(): down biglock
jffs_find_child()
jffs_find_child(): Didn't find the file "dev".
jffs_lookup(): Couldn't find the file. f = 0x00000000, name = "dev", d =
0xc036e360, d->ino = 1
lookup(): up biglock
Warning: unable to open an initial console.
jffs_lookup(): dir: 0xc0384ba0, name: "sbin"
lookup(): down biglock
jffs_find_child()
jffs_find_child(): Didn't find the file "sbin".
jffs_lookup(): Couldn't find the file. f = 0x00000000, name = "sbin", d =
0xc036e360, d->ino = 1
lookup(): up biglock
jffs_lookup(): dir: 0xc0384ba0, name: "etc"
lookup(): down biglock
jffs_find_child()
jffs_find_child(): Didn't find the file "etc".
jffs_lookup(): Couldn't find the file. f = 0x00000000, name = "etc", d =
0xc036e360, d->ino = 1
lookup(): up biglock
jffs_lookup(): dir: 0xc0384ba0, name: "bin"
lookup(): down biglock
jffs_find_child()
jffs_find_child(): Didn't find the file "bin".
jffs_lookup(): Couldn't find the file. f = 0x00000000, name = "bin", d =
0xc036e360, d->ino = 1
lookup(): up biglock
Kernel panic: No init found. Try passing init= option to kernel.
--
Thanks and Regards,
Vijesh V H
[-- Attachment #2: Type: text/html, Size: 23508 bytes --]
^ permalink raw reply
* Re: m8xx_pcmcia driver ported to v2.6
From: Mark Chambers @ 2005-05-12 11:29 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linux-ppc-embedded
In-Reply-To: <4282F263.8080501@intracom.gr>
> >>There is one pending problem: the M8xx does not accept
> >>access to non present ioports (an exception is triggered),
> >>which is quite common while inserting/removing cards.
> >>
> > Ah yes, I remember this problem from the 68360 days.
> >
> > This is a matter of how you set up the option register ORx
> > <snip>
> > for instance, you could turn external ack on once a card
> > was inserted.
> >
> > As I recall, some PCMCIA cards can have VERY long
> > cycles in the configuration space, so even the maximum
> > number of wait states in ORx may not be sufficient.
> >
> Unfortunately this does not work on 8xx since the PCMCIA
> port is not on a chip select. It's a different peripheral
> and always expectes a DTACK to terminate the cycle.
>
> To get over this problem we need to do something more drastic.
>
> Take a look at the __do_in_asm macro in include/asm-ppc/io.h.
>
> Regards
>
> Pantelis
>
You are right, I had forgotten that. I'd also forgotten that PCMCIA
uses negative WAIT, which should have a pull-up on it, so there
should be no problem with non-existent cards.
Another potential problem could be the Bus Monitor Timeout
being set too short and generating a TEA before a valid WAIT is
released.
Mark Chambers
^ permalink raw reply
* Re: linux-2.6.10, ppc8280, odd ARP request - solved
From: Richard Danter @ 2005-05-12 11:31 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <427F553A.1060506@ntlworld.com>
Richard Danter wrote:
>
> My board boots using U-Boot. It tftp loads the kernel image via FCC2, so
> I know the FCC's are working (I have tested the others too). This part
> is fine, but once the kernel has loaded it tries to NFS mount the root
> filesystem. When it gets to the point of looking up the RPC port it
> first sends an ARP request for the server. When eth0 is any of the FCC's
> I see a 59 byte packet on the wire (using ethereal). The server either
> does not see the packet or just ignores it so there is no reply to the
> board.
>
> When I boot using SCC1 as eth0 the ARP request sent is 60 bytes long. It
> is replied to and the NFS mount works.
>
> I noticed that U-Boot also sends an ARP request before the tftp download
> starts and it is 60 bytes long using both SCC and FCC ports. But as far
> as I know, ARP requests can be varying length (the last few bytes seem
> to be just padding).
Looks like the problem may be with the setup of the FCC, particularly
with working out what speed to run at. I connected my board to a
100BaseT hub and it worked perfectly. It was failing when I was using an
older 10BaseT hub. In both cases the hub is a Netgear and I have never
had a problem with any other board or PC.
Odd how it effects Linux but not U-Boot. Seems to indicate a driver
issue anyway.
Rich
^ permalink raw reply
* Re: [PATCH] Freescale Ethernet combined driver
From: Jaap-Jan Boor @ 2005-05-12 12:50 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <4283335A.7070209@intracom.gr>
Ah, very good, thanks
Jaap-Jan
On 12-mei-05, at 12:43, Pantelis Antoniou wrote:
> Jaap-Jan
>
> All mii operations are done under a spinlock with interrupts disabled.
>
> Regards
>
> Pantelis
^ permalink raw reply
* Re: Status of isp116x driver... (on mpc8xx)?
From: David Jander @ 2005-05-12 12:55 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20050511132810.E7228C1512@atlas.denx.de>
On Wednesday 11 May 2005 15:28, Wolfgang Denk wrote:
>[...]
> > Is the isp1160 chip really supported by the driver? tested?
>
> We only use (and tested) this driver with a ISP1361 ...
Ok. The sources of your driver and the one from Roman Weissgaerber look very
different, so I can't really tell: did you start from scratch and picked some
things from RW's driver, or did you modify (beyond recognition) and extend
his driver?
I ask, because now I have RW's driver (version 0.9.6) working almost 100%
alright. The issues we still have are most probably related to bus-timing
problems (the ISP1160 is connected via a CPLD on an 8-bit wide bus controlled
by UPMA!) and occur sporadically. Your driver OTOH still doesn't manage to
receive Atl packets that are not entirely filled with zeroes ;-)
> > Is someone using a isp116x on a mpc8xx and can tell his experience on
> > getting it working?
>
> Sorry, we don't have any experience with a 1160. The driver in our
> tree works fine with the 1362, both as host driver and as device (as
> a gadget driver).
I'll work on the problem, and if I get your driver working, I'll send a patch
that hopefully fixes 116x support again ;-)
Greetings,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Re: Status of isp116x driver... (on mpc8xx)?
From: Wolfgang Denk @ 2005-05-12 13:47 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200505121455.15864.david.jander@protonic.nl>
Dear David,
in message <200505121455.15864.david.jander@protonic.nl> you wrote:
>
> Ok. The sources of your driver and the one from Roman Weissgaerber look very
> different, so I can't really tell: did you start from scratch and picked some
> things from RW's driver, or did you modify (beyond recognition) and extend
> his driver?
We used and extended a driver based on RW code. If you want to folow
the history of changes in our CVS then please note thatthe driver was
renamed from drivers/usb/hcd-1161.* into drivers/usb/host/hcd-1161.*,
so for the first changes look for drivers/usb/hcd-1161.*.
> I'll work on the problem, and if I get your driver working, I'll send a patch
> that hopefully fixes 116x support again ;-)
Thanks in advance, and good luck!
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The evolution of the human race will not be accomplished in the ten
thousand years of tame animals, but in the million years of wild
animals, because man is and will always be a wild animal.
- Charles Galton Darwin
^ permalink raw reply
* Re: [PATCH] BOOKE_WDT Part 1/2 (Re: PPC 44x Watchdog timer)
From: Kumar Gala @ 2005-05-12 15:37 UTC (permalink / raw)
To: Takeharu KATO; +Cc: Glenn Burkhardt, Gala Kumar K.-galak, linuxppc-embedded
In-Reply-To: <427BDBCF.8030908@ybb.ne.jp>
> diff -Nupr linux-2.6.orig/arch/ppc/kernel/head_4xx.S
> linux-2.6/arch/ppc/kernel/head_4xx.S
> --- linux-2.6.orig/arch/ppc/kernel/head_4xx.S=A0=A0 2005-05-06
> 05:03:55.000000000 +0900
> +++ linux-2.6/arch/ppc/kernel/head_4xx.S=A0=A0=A0=A0=A0=A0=A0 =
2005-05-07=20
> 05:03:24.000000000 +0900
> @@ -430,27 +430,24 @@ label:
>
Any reason you moved this code into DecrementerHandler?
> =A0 /* 0x1000 - Programmable Interval Timer (PIT) Exception */
> =A0 =A0=A0=A0=A0=A0 START_EXCEPTION(0x1000, Decrementer)
> -=A0=A0=A0=A0=A0=A0 NORMAL_EXCEPTION_PROLOG
> -=A0=A0=A0=A0=A0=A0 lis=A0=A0=A0=A0 r0,TSR_PIS@h
> -=A0=A0=A0=A0=A0=A0 mtspr=A0=A0 SPRN_TSR,r0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=
=A0 /* Clear the PIT exception */
> -=A0=A0=A0=A0=A0=A0 addi=A0=A0=A0 r3,r1,STACK_FRAME_OVERHEAD
> -=A0=A0=A0=A0=A0=A0 EXC_XFER_LITE(0x1000, timer_interrupt)
> +=A0=A0=A0=A0=A0=A0 b=A0=A0=A0 DecrementerHandler
>
> =A0 #if 0
> =A0 /* NOTE:
> - * FIT and WDT handlers are not implemented yet.
> + * FIT handler is not implemented yet.
> =A0=A0 */
>
> =A0 /* 0x1010 - Fixed Interval Timer (FIT) Exception
> =A0 */
> =A0 =A0=A0=A0=A0=A0 STND_EXCEPTION(0x1010,=A0 FITException,=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0=20
> UnknownException)
>
> -/* 0x1020 - Watchdog Timer (WDT) Exception
> -*/
> -
> -=A0=A0=A0=A0=A0=A0 CRITICAL_EXCEPTION(0x1020, WDTException, =
UnknownException)
> =A0 #endif
>
> +/* 0x1020 - Watchdog Timer (WDT) Exception
> + */
> +=A0=A0=A0=A0=A0=A0 START_EXCEPTION(0x1020, WDTException)
> +=A0=A0=A0=A0=A0=A0 b=A0=A0=A0 WatchDogHandler
> +
> =A0 /* 0x1100 - Data TLB Miss Exception
> =A0=A0 * As the name implies, translation is not in the MMU, so =
search the
> =A0=A0 * page tables and fix it.=A0 The only purpose of this function =
is to
> @@ -732,6 +729,13 @@ label:
> =A0 =A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 (MSR_KERNEL & =
~(MSR_ME|MSR_DE|MSR_CE)), \
> =A0 =A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 NOCOPY, =
crit_transfer_to_handler, ret_from_crit_exc)
>
> +DecrementerHandler:
> +=A0=A0=A0=A0=A0=A0 NORMAL_EXCEPTION_PROLOG
> +=A0=A0=A0=A0=A0=A0 lis=A0=A0=A0 r0,TSR_PIS@h
> +=A0=A0=A0=A0=A0=A0 mtspr=A0=A0=A0 SPRN_TSR,r0=A0=A0=A0=A0=A0=A0=A0 /* =
Clear the PIT exception */
> +=A0=A0=A0=A0=A0=A0 addi=A0=A0=A0 r3,r1,STACK_FRAME_OVERHEAD
> +=A0=A0=A0=A0=A0=A0 EXC_XFER_LITE(0x1000, timer_interrupt)
> +
> =A0 /*
> =A0=A0 * The other Data TLB exceptions bail out to this point
> =A0=A0 * if they can't resolve the lightweight TLB fault.
> @@ -804,6 +808,19 @@ finish_tlb_load:
> =A0 =A0=A0=A0=A0=A0 PPC405_ERR77_SYNC
> =A0 =A0=A0=A0=A0=A0 rfi=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=
=A0=A0 /* Should sync shadow TLBs */
> =A0 =A0=A0=A0=A0=A0 b=A0=A0=A0=A0=A0=A0 .=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=
=A0=A0=A0 /* prevent prefetch past rfi */
> +/*
> + * WatchDog Exception
> + */
> +WatchDogHandler:
> +=A0=A0=A0=A0=A0=A0 CRITICAL_EXCEPTION_PROLOG;
> +=A0=A0=A0=A0=A0=A0 addi=A0=A0=A0 r3,r1,STACK_FRAME_OVERHEAD;
> +#if defined(CONFIG_BOOKE_WDT)
> +=A0=A0=A0=A0=A0=A0 EXC_XFER_TEMPLATE(booke_wdt_exception, 0x1022, =
(MSR_KERNEL &
> ~(MSR_ME|MSR_DE|MSR_CE)),NOCOPY, crit_transfer_to_handler,
> ret_from_crit_exc)
> +
> +#else
> +=A0=A0=A0=A0=A0=A0 EXC_XFER_TEMPLATE(UnknownException, 0x1022, =
(MSR_KERNEL &
> ~(MSR_ME|MSR_DE|MSR_CE)),NOCOPY, crit_transfer_to_handler,
> ret_from_crit_exc)
> +#endif=A0 /*=A0 CONFIG_BOOKE_WDT=A0 */
> +
>
> =A0 /* extern void giveup_fpu(struct task_struct *prev)
> =A0=A0 *
^ permalink raw reply
* RE: Network Setup - HOW TO
From: Steve Witt @ 2005-05-12 15:48 UTC (permalink / raw)
To: Atit_Shah; +Cc: linuxppc-embedded
In-Reply-To: <D8595042F3765A4285B848A78A2C2ED10277B8@bsdmsg002.corp.satyam.ad>
On Thu, 12 May 2005, Atit_Shah wrote:
-- snip --
> The router should get an IP from my company server and assign it to eth1
> and then it should assign a IP to my standalone system connected to
> eth0. how do I do this?
>
I suspect you need to spend some time with the documentation of udhcp. You
should be able to configure with network interface the server and client
run on.
> DISCLAIMER: This email (including any attachments) is intended for the
> sole use of the intended recipient/s and may contain material that is
> CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by
> others or copying or distribution or forwarding of any or all of the
> contents in this message is STRICTLY PROHIBITED. If you are not the
> intended recipient, please contact the sender by email and delete all
> copies; your cooperation in this regard is appreciated.
Now that I've read this disclaimer, its not clear that I am allowed (by
your company) to answer your question. Its not clear to me whether I'm the
intended recipient, nor whether this information you've sent is company
private (to your company) or not.
These types of disclaimers are completely inappropriate for communications
with a group of people discussing Open Source software and are, in fact,
pointless. If you have company private information, then the
responsibility to protect it is yours, not mine. I would ask that you
remove this from subsequent emails to this list.
^ permalink raw reply
* Kernel build error
From: mcnernbm @ 2005-05-12 22:30 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]
Using the 2.4 kernel tree with a 2.4.26 kernel I am receive the following
error when trying to build for the powerpc 405.
I set the arch: to arch: ppc and set the cross-compile line in the make
file.
Make dep and make modules runs fine.
But when I run make zImage I receive the follwoing error:
mv: can't stat source zvmlinux
make[2]: *** [zImage] Error 1
make[2]: Leaving directory
'/ppclinux/v2.4.26_linuxppc_2_4_devel/linuxppc_2_4_devel/arch/ppc/boot/simple'
make[1]: *** [zImage] Error 2
make[1]: Leaving directory
'/ppclinux/v2.4.26_linuxppc_2_4_devel/linuxppc_2_4_devel/arch/ppc/boot/'
make: *** [zImage] Error 2
I am using the default xilinx_ml300 arch config file so I can at least get
the kernel to build before attempting to build one for my specific virtex
II pro board. Does anyone know what might be causing this?
I am using gcc-3.4.1 and glibc-2.3.5. Not sure if this is part of the
issue or but if so which version should I be using? And is it the 2.4.26
kernel that is the issue? Should i go back to an older one that is used
in alot of the tutorials for the xilinx ml300 board.
Thanks
Brett
[-- Attachment #2: Type: text/html, Size: 1736 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox