* Re: platform/board removal update
From: 'Aristeu Sergio Rozanski Filho' @ 2005-07-28 13:03 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-dev list, Embedded PPC Linux list
In-Reply-To: <42E87B2F.30705@intracom.gr>
> There's a fs_enet driver in the works which will use Andy's work.
>
> Please refrain from doing anything :)
great! 8)
--
Aristeu
^ permalink raw reply
* Re: [PATCH][1/3] ppc32: add 440ep support
From: Domen Puncer @ 2005-07-28 13:02 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Andrew Morton, linux-kernel, linuxppc-embedded
In-Reply-To: <17128.4407.838024.111955@cargo.ozlabs.ibm.com>
On 27/07/05 18:56 -0400, Paul Mackerras wrote:
> Andrew Morton writes:
>
> > Matt Porter <mporter@kernel.crashing.org> wrote:
> > >
> > > +static u64 dma_mask = 0xffffffffULL;
How about just DMA_32BIT_MASK from dma-mapping.h, that one has to be
correct. ;-)
> >
> > I'm sure you're totally uninterested in this, but the above will probably
> > generate warnings on (say) ppc64, where u64 is implemented as unsigned
> > long.
> >
> > I usually chuck a simple `-1' in there and the compiler always gets it
> > right, regardless of signedness and size and architecture.
>
> Umm, I think we actually want 2^32-1 not -1, don't we? In which case
> I think Matt's code is what we have to have.
>
> I tried a little test compile with gcc 4.0 with -m64 -Wall and it
> didn't generate a warning with the 0xffffffffULL constant.
^ permalink raw reply
* Re: eth1 on linux 2.4.25 from ELDK 3.1.1 becomes slowly when is pinged by great packets
From: Wolfgang Denk @ 2005-07-28 12:51 UTC (permalink / raw)
To: Igor Marnat; +Cc: linuxppc-embedded
In-Reply-To: <200507281603.22332.marny@rambler.ru>
Dear Igor,
in message <200507281603.22332.marny@rambler.ru> you wrote:
>
> I tried to work with kernel 2.4.25 from ELDK 3.1.1 from Denx. My board is
> PPChameleon EVB (PPC 405 EP). First, the kernel even didn't compile as is for
You must be using old code (probably the version that came with ELDK
3.1.1?). Please fetch the current code from CVS; see commit "Fix
problems with second ethernet interface on 405EP".
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
Any technology distinguishable from magic is insufficiently advanced.
^ permalink raw reply
* eth1 on linux 2.4.25 from ELDK 3.1.1 becomes slowly when is pinged by great packets
From: Igor Marnat @ 2005-07-28 12:03 UTC (permalink / raw)
To: linuxppc-embedded
Hi list!
I tried to work with kernel 2.4.25 from ELDK 3.1.1 from Denx. My board is
PPChameleon EVB (PPC 405 EP). First, the kernel even didn't compile as is for
this architecture, I've forced to made changes (see the patch below) to be
able to build the kernel for this board. Now I'm experiencing the following
problem: I've inited both interfaces (eth0 and eth1). When I ping eth1 with
small packet (less that 2k), it works fine. When I ping eth1 with the packets
of size greater that 2k, time of responce becomes about n * 1000
milliseconds. I.e., ping writes me:
3008 bytes from 90.0.0.139: icmp_seq=1 ttl=64 time=3001 ms
3008 bytes from 90.0.0.139: icmp_seq=2 ttl=64 time=3002 ms
...
3008 bytes from 90.0.0.139: icmp_seq=6 ttl=64 time=3003 ms
3008 bytes from 90.0.0.139: icmp_seq=7 ttl=64 time=3003 ms
Sometimes it is 2000 ms, sometimes it is 1000 ms, but it's always like this.
After it was one time pinged by the great packets, it'll responce in such a
fashion allways, even when is pinged by the smapll packets. Once crashed, it
is crashed till it is reinited. To make it work normally once again, I do:
#ifconfig eth1 down
#ifconfig eth1 up
and it helps, i.e. after reinitialization eth1 work normally. Eth0 works fine
anyway with pings of any sizes. What is the status of PPChameleon in ELDK
3.1.1? Is it supported in general? Any ideas or suggestions? I've searched
the archives and tried the patches of Matt Porter (of Mar 3, about jumbo
packets size), but it didn't help.
Regards,
Igor Marnat
diff -uprN -X dontdiff linux-2.4.25/arch/ppc/platforms/ibm405ep.c
linux-2.4.25-07-mar-2005/arch/ppc/platforms/ibm405ep.c
--- linux-2.4.25/arch/ppc/platforms/ibm405ep.c 2003-11-11 19:33:37.000000000
+0300
+++ linux-2.4.25-07-mar-2005/arch/ppc/platforms/ibm405ep.c 2005-07-28
14:25:21.000000000 +0400
@@ -31,6 +31,7 @@ static struct ocp_func_emac_data ibm405e
.mal_tx1_chan = 0, /* MAL tx channel 1 number */
.mal_tx2_chan = 1, /* MAL tx channel 2 number */
.wol_irq = BL_MAC_WOL, /* WOL interrupt number */
+ .jumbo = 0,
.mdio_idx = -1, /* No shared MDIO */
};
@@ -43,6 +44,7 @@ static struct ocp_func_emac_data ibm405e
.mal_tx1_chan = 2, /* MAL tx channel 1 number */
.mal_tx2_chan = 3, /* MAL tx channel 2 number */
.wol_irq = BL_MAC_WOL, /* WOL interrupt number */
+ .jumbo = 0,
.mdio_idx = -1, /* No shared MDIO */
};
diff -uprN -X dontdiff linux-2.4.25/drivers/mtd/nand/ppchameleonevb.c
linux-2.4.25-07-mar-2005/drivers/mtd/nand/ppchameleonevb.c
--- linux-2.4.25/drivers/mtd/nand/ppchameleonevb.c 2004-05-29
19:46:27.000000000 +0400
+++ linux-2.4.25-07-mar-2005/drivers/mtd/nand/ppchameleonevb.c 2005-07-28
14:35:06.000000000 +0400
@@ -58,12 +58,30 @@ __setup("ppchameleonevb_fio_pbase=",ppch
/*
* Define static partitions for flash device
*/
+/*
static struct mtd_partition partition_info[] = {
{ name: "PPChameleonEVB Nand Flash",
offset: 0,
size: 32*1024*1024 }
};
#define NUM_PARTITIONS 1
+*/
+/*
+ * Define static partitions for flash device
+ */
+static struct mtd_partition partition_info[] = {
+ { name: "PPChameleonEVB NAND flash main part",
+ offset: 0,
+ size: 24*1024*1024 },
+ { name: "PPChameleonEVB Nand Flash etc part",
+ offset: 24*1024*1024,
+ size: 4*1024*1024 },
+ { name: "PPChameleonEVB Nand Flash var part",
+ offset: (24 + 4)*1024*1024,
+ size: 4*1024*1024 }
+
+};
+#define NUM_PARTITIONS 3
#endif
diff -uprN -X dontdiff linux-2.4.25/drivers/net/ibm_emac/ibm_ocp_enet.c
linux-2.4.25-07-mar-2005/drivers/net/ibm_emac/ibm_ocp_enet.c
--- linux-2.4.25/drivers/net/ibm_emac/ibm_ocp_enet.c 2005-01-17
18:39:43.000000000 +0300
+++ linux-2.4.25-07-mar-2005/drivers/net/ibm_emac/ibm_ocp_enet.c
2005-07-28 15:30:12.000000000 +0400
@@ -1042,7 +1042,7 @@ emac_adjust_to_link(struct ocp_enet_priv
/* set speed (default is 10Mb) */
switch(speed) {
case SPEED_1000:
- mode_reg |= EMAC_M1_JUMBO_ENABLE | EMAC_M1_RFS_16K;
+ mode_reg |= EMAC_M1_JUMBO_ENABLE /*| EMAC_M1_RFS_16K */;
if (fep->rgmii_dev) {
struct ibm_ocp_rgmii *rgmii =
RGMII_PRIV(fep->rgmii_dev);
@@ -1264,7 +1264,7 @@ emac_init_rings(struct net_device *dev)
int loop;
ep->tx_desc = (struct mal_descriptor *) ((char *)
ep->mal->tx_virt_addr +
- (ep->mal_tx_chan * MAL_DT_ALIGN));
+ (ep->mal_tx1_chan * MAL_DT_ALIGN));
ep->rx_desc = (struct mal_descriptor *) ((char *)
ep->mal->rx_virt_addr +
(ep->mal_rx_chan * MAL_DT_ALIGN));
@@ -1281,7 +1281,9 @@ emac_init_rings(struct net_device *dev)
/* Format the receive descriptor ring. */
ep->rx_slot = 0;
- ep->rx_buffer_size = ENET_DEF_BUF_SIZE;
+ //ep->rx_buffer_size = ENET_DEF_BUF_SIZE;
+ ep->rx_buffer_size =
+ dev->mtu + ENET_HEADER_SIZE + ENET_FCS_SIZE;
emac_rx_fill(dev, 0);
if (ep->rx_slot != 0) {
printk(KERN_ERR
@@ -1752,11 +1754,12 @@ static int emac_init_device(struct ocp_d
/* Fill out MAL informations and register commac */
ep->mal = mal;
- ep->mal_tx_chan = emacdata->mal_tx_chan;
+ ep->mal_tx1_chan = emacdata->mal_tx1_chan;
+ ep->mal_tx2_chan = emacdata->mal_tx2_chan;
ep->mal_rx_chan = emacdata->mal_rx_chan;
ep->commac.ops = &emac_commac_ops;
ep->commac.dev = ndev;
- ep->commac.tx_chan_mask = MAL_CHAN_MASK(ep->mal_tx_chan);
+ ep->commac.tx_chan_mask = MAL_CHAN_MASK(ep->mal_tx1_chan) |
MAL_CHAN_MASK(ep->mal_tx2_chan);
ep->commac.rx_chan_mask = MAL_CHAN_MASK(ep->mal_rx_chan);
rc = mal_register_commac(ep->mal, &ep->commac);
if (rc != 0)
diff -uprN -X dontdiff linux-2.4.25/drivers/net/ibm_emac/ibm_ocp_enet.h
linux-2.4.25-07-mar-2005/drivers/net/ibm_emac/ibm_ocp_enet.h
--- linux-2.4.25/drivers/net/ibm_emac/ibm_ocp_enet.h 2005-01-17
18:39:43.000000000 +0300
+++ linux-2.4.25-07-mar-2005/drivers/net/ibm_emac/ibm_ocp_enet.h
2005-07-28 13:59:14.000000000 +0400
@@ -158,7 +158,7 @@ struct ocp_enet_private {
int zmii_input;
struct ibm_ocp_mal *mal;
- int mal_tx_chan, mal_rx_chan;
+ int mal_tx1_chan, mal_tx2_chan, mal_rx_chan;
struct mal_commac commac;
struct ocp_device *tah_dev;
diff -uprN -X dontdiff linux-2.4.25/include/asm-ppc/ibm4xx.h
linux-2.4.25-07-mar-2005/include/asm-ppc/ibm4xx.h
--- linux-2.4.25/include/asm-ppc/ibm4xx.h 2005-01-17 18:39:44.000000000
+0300
+++ linux-2.4.25-07-mar-2005/include/asm-ppc/ibm4xx.h 2005-07-28
13:31:13.000000000 +0400
@@ -25,7 +25,7 @@
* The "residual" board information structure the boot loader passes
* into the kernel.
*/
-extern bd_t __res;
+extern unsigned char __res[];
#endif
/* Device Control Registers */
diff -uprN -X dontdiff linux-2.4.25/include/asm-ppc/ocp_ids.h
linux-2.4.25-07-mar-2005/include/asm-ppc/ocp_ids.h
--- linux-2.4.25/include/asm-ppc/ocp_ids.h 2005-01-17 18:39:44.000000000
+0300
+++ linux-2.4.25-07-mar-2005/include/asm-ppc/ocp_ids.h 2005-07-28
13:46:40.000000000 +0400
@@ -112,7 +112,8 @@
int zmii_mux; /* ZMII input of this EMAC */
int mal_idx; /* MAL device index */
int mal_rx_chan; /* MAL rx channel number */
- int mal_tx_chan; /* MAL tx channel 1 number */
+ int mal_tx1_chan; /* MAL tx channel 1 number */
+ int mal_tx2_chan; /* MAL tx channel 2 number */
int wol_irq; /* WOL interrupt */
int mdio_idx; /* EMAC idx of MDIO master or -1 */
int tah_idx; /* TAH device index or -1 */
^ permalink raw reply
* Re: burst
From: Wojciech Kromer @ 2005-07-28 11:25 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <42E8BB67.8070407@dgt.com.pl>
Forgot to say, it's on mpc8250
> How to enable burst acces for external device?
> What i did:
> - program UPMx with correct cycles
> - setup ORx BRx, and not set BI (BurstInhibit)
> - done opremap instead of opremap_nocache
>
> An no burst acces is done.
>
> Do I have to do DMA transfers?
>
>
^ permalink raw reply
* Re: Linuxppc-embedded Digest, Vol 11, Issue 74
From: somshekar chandrashekar kadam @ 2005-07-28 11:08 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linuxppc-embedded-request
[-- Attachment #1: Type: text/plain, Size: 202 bytes --]
HI All ,
I checked the mailing list , and found that still Linuxppc kernel 2.6 for mpc8xx is not complete . if anyone has been able to port it please let me ,
Thanks And Regards
Somshekar
[-- Attachment #2: Type: text/html, Size: 462 bytes --]
^ permalink raw reply
* Re: 答复: How to load a linux kernel under vxworks bootloader (PPC860board)
From: Esben Nielsen @ 2005-07-28 11:07 UTC (permalink / raw)
To: FCG WANG Baohua; +Cc: linuxppc-embedded
In-Reply-To: <A9DE2BAF233E444FA9C5E77A5825A01E86504A@ydmail.sbell.com.cn>
On Thu, 28 Jul 2005, FCG WANG Baohua wrote:
> Dear Esben:
> Thanks for your advice. I guess the vxworks 5.3.1 can process the ELF fo=
rmat.=20
> Can you tell me "the link address of the VxWorks kernel ELF file" ?=20
> Someone said that "make sure the Linux kernel is linked at that same ad=
dress".
> Other one said to use zImage of kernel instead of ELF "vmlinux" image, h=
ave you tested using zImage on vxWorks?=20
>
I used the compressed elf image. I lost my HD since so I can't find it
now, but I think it was called arch/ppc/boot/zImage.elf or something like
that. It is around 1+-0.4 Mb big. Use the file command to check wether it
is elf or not.
=20
> Can you give me some step tips when processing your 5.5 bootloader ?
Hmm, in the boot-prompt I just type the file-name of the linux kernel
instead of the vxWorks kernel. Not special issues. I guess I was lucky,
because I really don't know much about these issues!
Esben
> need to revise the entry points? using the 0x200000 original addresss o=
f linux kernel ?=20
> The serial port print what info after "starting at 0x200000 ...." ?=20
> =20
> thanks a lot!
> =20
>=20
> -----=D4=AD=CA=BC=D3=CA=BC=FE-----
> =B7=A2=BC=FE=C8=CB: Esben Nielsen [mailto:simlo@phys.au.dk]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA7=D4=C228=C8=D5 15:47
> =CA=D5=BC=FE=C8=CB: Frank
> =B3=AD=CB=CD: FCG WANG Baohua; linuxppc-embedded@ozlabs.org
> =D6=F7=CC=E2: Re: How to load a linux kernel under vxworks bootloader
> (PPC860board)
>=20
>=20
> On Wed, 27 Jul 2005, Frank wrote:
>=20
> >=20
> >=20
> > --- FCG WANG Baohua <Baohua.WANG@alcatel-sbell.com.cn> wrote:
> >=20
> > > Dear All:
> > > I want to boot a linux 2.4.25 kernel under vxworks
> > > bootloader. When I using flat mode(0x200000 --> 0x10000)
> > > kernel uncompressed ELF format ( vmlinux ),
> > > and download it using TFTP of vxworks, it print the "starting
> > > at 0x1000 ...." and freeze. No input or output on serial
> > > port.
> > > The version of vxworks is 5.3.1.=20
> > > can you give me some detail advice or give me a tool to slove
> > > it? thanks !
>=20
> I have done it on a MPC5200 with a vxWorks 5.5 bootsector with ethernet
> support: I just boot over FTP. Give it the Linux kernel in elf-format,=
=20
> the bootsector doesn't care, _what_ the code actually is, it just loads
> and run it.=20
>=20
> For vxWorks <=3D 5.4 I believe coff is used instead of elf - at least on
> some architectures. Then you have a problem, because the kernel isn't
> compiled to coff :-(
>=20
> Esben
>=20
>=20
> >=20
> > Do what I did:
> > Replace the vxWorks rom with you u-boot and you can boot Linux
> > or vxWorks with the same bootloader.
> >=20
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around=20
> > http://mail.yahoo.com=20
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >=20
>=20
>=20
^ permalink raw reply
* burst
From: Wojciech Kromer @ 2005-07-28 11:03 UTC (permalink / raw)
To: linuxppc-embedded
How to enable burst acces for external device?
What i did:
- program UPMx with correct cycles
- setup ORx BRx, and not set BI (BurstInhibit)
- done opremap instead of opremap_nocache
An no burst acces is done.
Do I have to do DMA transfers?
^ permalink raw reply
* 答复: How to load a linux kernel under vxworks bootloader (PPC860board)
From: FCG WANG Baohua @ 2005-07-28 10:08 UTC (permalink / raw)
To: Esben Nielsen, Frank; +Cc: linuxppc-embedded
Dear Esben:
Thanks for your advice. I guess the vxworks 5.3.1 can process the ELF =
format.=20
Can you tell me "the link address of the VxWorks kernel ELF file" ?=20
Someone said that "make sure the Linux kernel is linked at that same =
address".
Other one said to use zImage of kernel instead of ELF "vmlinux" image, =
have you tested using zImage on vxWorks?=20
=20
Can you give me some step tips when processing your 5.5 bootloader ?
need to revise the entry points? using the 0x200000 original addresss =
of linux kernel ?=20
The serial port print what info after "starting at 0x200000 ...." ?=20
=20
thanks a lot!
=20
-----=D4=AD=CA=BC=D3=CA=BC=FE-----
=B7=A2=BC=FE=C8=CB: Esben Nielsen [mailto:simlo@phys.au.dk]
=B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA7=D4=C228=C8=D5 15:47
=CA=D5=BC=FE=C8=CB: Frank
=B3=AD=CB=CD: FCG WANG Baohua; linuxppc-embedded@ozlabs.org
=D6=F7=CC=E2: Re: How to load a linux kernel under vxworks bootloader
(PPC860board)
On Wed, 27 Jul 2005, Frank wrote:
>=20
>=20
> --- FCG WANG Baohua <Baohua.WANG@alcatel-sbell.com.cn> wrote:
>=20
> > Dear All:
> > I want to boot a linux 2.4.25 kernel under vxworks
> > bootloader. When I using flat mode(0x200000 --> 0x10000)
> > kernel uncompressed ELF format ( vmlinux ),
> > and download it using TFTP of vxworks, it print the "starting
> > at 0x1000 ...." and freeze. No input or output on serial
> > port.
> > The version of vxworks is 5.3.1.=20
> > can you give me some detail advice or give me a tool to slove
> > it? thanks !
I have done it on a MPC5200 with a vxWorks 5.5 bootsector with ethernet
support: I just boot over FTP. Give it the Linux kernel in elf-format,=20
the bootsector doesn't care, _what_ the code actually is, it just loads
and run it.=20
For vxWorks <=3D 5.4 I believe coff is used instead of elf - at least on
some architectures. Then you have a problem, because the kernel isn't
compiled to coff :-(
Esben
>=20
> Do what I did:
> Replace the vxWorks rom with you u-boot and you can boot Linux
> or vxWorks with the same bootloader.
>=20
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around=20
> http://mail.yahoo.com=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* Re: CPM MCC sample driver?
From: Alex Zeffertt @ 2005-07-28 9:41 UTC (permalink / raw)
To: bbosch; +Cc: linuxppc-embedded
In-Reply-To: <17127.49093.492554.638213@waldo.lisle.iphase.com>
On Wed, 27 Jul 2005 12:09:25 -0500
bbosch@iphase.com wrote:
> A couple of years ago, Adam Kaczynski announced a sample MCC HDLC and
> Transparent mode driver. Both the URL Adam posted and Adam's email
> address are no longer valid. Is this code or any other Linux MCC
> driver available anywhere? I need to develop an MCC driver for a
> project I am working on and it would be very helpful to have an
> example to start with.
>
I'm not sure what you mean by MCC. I've got an PQI SCC tranparent mode driver which implements a
character device for reading from/writing to a PCM bus. I wrote it a couple of years ago and tested
it using an external loopback - but I've never used it in anger. Would this be useful to you?
Alex
^ permalink raw reply
* Re: [RFC PATCH 1/4] PHY Abstraction Layer III (now with more splitiness)
From: Jörn Engel @ 2005-07-28 9:18 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Netdev, linuxppc-embedded, Francois Romieu
In-Reply-To: <1122500059.28777@shark.he.net>
On Wed, 27 July 2005 14:34:19 -0700, Randy Dunlap wrote:
> >
> > Ok, here I won't agree to disagree with you. !foo as a check for
> > NULL is a reasonable idea, but not my style. If that's the preferred
> > style for the kernel, I will do that.
> >
> > But (var == constant) is a style that asks for errors. By putting
> > the constant first in these checks, you never run the risk of leaving
> > a bug like this:
> >
> > if (dev = NULL)
> > ...
> >
> > This kind of error is quite frustrating to detect, and the eye will
> > often miss it when scanning for errors. If you follow constant ==
> > var, though, then the bug looks like this:
> >
> > if (NULL = dev)
> >
> > which is instantly caught by the compiler.
> >
> > Just my 32 cents
>
> Yes, we know about that argument. :)
The counter-argument basically goes like this:
1. All relevant compilers (GCC) warn on "if (dev = NULL)", so you will
only miss the bug if you ignore compiler warnings. Ignoring compiler
warnings is not generally endorsed by the kernel crowd.
2. Very hard to read, "if (NULL = dev)" is. Reversing the order is a
fun thing to do for small green characters in fantasy and scifi
stories and fairly popular in peotry as well. But understanding the
meaning of reverse order sentences takes more time. In the kernel,
peer review is an important aspect and making the code hard to read
hurts peer review.
And maybe you can add another one:
3. Im my personal experience, reverse order comparisons were a good
indicator of buggy code.
Jörn
--
Schrödinger's cat is <BLINK>not</BLINK> dead.
-- Illiad
^ permalink raw reply
* Re : custom ads8272 board PCI interrupt no response
From: Sam Song @ 2005-07-28 8:57 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050727135233.7367.qmail@web15803.mail.cnb.yahoo.com>
Sam Song <samlinuxppc@yahoo.com.cn> wrote:
> Hi all,
>
> A PCI interrupt probelm confused me when porting
> 2.6.13-rc3 on a custom 8248 board. There was a
> Gb ethernet RTL8110S on board with IDSEL AD25 and
> IRQ3. So I made some changes as follows:
>
> --- linux-2.6.13-rc3/arch/ppc/platforms/pq2ads.h
> +++ linux-2.6.13-rc3-sam/arch/ppc/platforms/pq2ads.h
> @@ -74,11 +78,11 @@
> -#define PCI_INT_TO_SIU SIU_INT_IRQ2
> +#define PCI_INT_TO_SIU SIU_INT_IRQ3
Ummm, not the case. ADS8272 uses a CPLD PCI interrupt
controller which takes up IRQ2. No need to me:-)
> --- linux-2.6.13-rc3/arch/ppc/syslib/m82xx_pci.c
> +++ linux-2.6.13-rc3-sam/arch/ppc/syslib/m82xx_pci.c
> @@ -60,12 +60,20 @@
> * A B C D
> */
> {
> +#if 0
> { PIRQA, PIRQB, PIRQC, PIRQD },/* IDSEL 22 - PCI
>
> slot 0 */
> { PIRQD, PIRQA, PIRQB, PIRQC }, /* IDSEL 23 -
> PCI
> slot 1 */
> { PIRQC, PIRQD, PIRQA, PIRQB }, /* IDSEL 24 -
> PCI
> slot 2 */
> +#else
> + {22, 22, 22, 22},/* IDSEL 22/IRQ4-PCI slot 0-USB
> */
> + {23, 23, 23, 23},/* IDSEL 23/IRQ5-PCI slot 1-IDE
> */
> + {24, 24, 0, 0},/* IDSEL 24 - PCI slot # - NULL
> */
> + {25, 25, 25, 25},/* IDSEL 25/IRQ3-PCI slot 2- Gb
> */
Set IRQ3 in the last line as 21 to assign the IRQ3
to Gb ethernet.
> Gb interrupt remained unchangable in the whole test
> process. I could ping target itself but not for
> outside machine. So I suspect this result was due to
> PCI interrupt setting but don't know where the
> probelm is. Any idea?
Well, I finally masked pq2ads interrupt irq init and
adjusted SIUMCR IRQ3 setting correctly. Then
everything went as smoothly as clockwork.
Sorry to bother here:-)
Sam
__________________________________________________
赶快注册雅虎超大容量免费邮箱?
http://cn.mail.yahoo.com
^ permalink raw reply
* Re: How to load a linux kernel under vxworks bootloader (PPC860 board)
From: Esben Nielsen @ 2005-07-28 7:47 UTC (permalink / raw)
To: Frank; +Cc: FCG WANG Baohua, linuxppc-embedded
In-Reply-To: <20050728042840.36296.qmail@web32203.mail.mud.yahoo.com>
On Wed, 27 Jul 2005, Frank wrote:
>
>
> --- FCG WANG Baohua <Baohua.WANG@alcatel-sbell.com.cn> wrote:
>
> > Dear All:
> > I want to boot a linux 2.4.25 kernel under vxworks
> > bootloader. When I using flat mode(0x200000 --> 0x10000)
> > kernel uncompressed ELF format ( vmlinux ),
> > and download it using TFTP of vxworks, it print the "starting
> > at 0x1000 ...." and freeze. No input or output on serial
> > port.
> > The version of vxworks is 5.3.1.
> > can you give me some detail advice or give me a tool to slove
> > it? thanks !
I have done it on a MPC5200 with a vxWorks 5.5 bootsector with ethernet
support: I just boot over FTP. Give it the Linux kernel in elf-format,
the bootsector doesn't care, _what_ the code actually is, it just loads
and run it.
For vxWorks <= 5.4 I believe coff is used instead of elf - at least on
some architectures. Then you have a problem, because the kernel isn't
compiled to coff :-(
Esben
>
> Do what I did:
> Replace the vxWorks rom with you u-boot and you can boot Linux
> or vxWorks with the same bootloader.
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: platform/board removal update
From: Pantelis Antoniou @ 2005-07-28 6:29 UTC (permalink / raw)
To: 'Aristeu Sergio Rozanski Filho'
Cc: linuxppc-dev list, Embedded PPC Linux list
In-Reply-To: <20050727214600.GB30557@cathedrallabs.org>
'Aristeu Sergio Rozanski Filho' wrote:
>>8xx_io/fec.c is still using v2.4's workqueue infrastructure but other than
>>that its working fine.
>>
>>The fix will be pushed upstream ASAP.
>>
>>BTW, we should schedule 8xx_io/fec.c for removal, but before that we ought to
>>test all supported PHY's on the new driver.
>>
>>Aris was talking to me about this on OLS. Aris, what are the PHY's not supported
>>by Panto's driver again? We should build a list of those and ask around for
>>testers.
>
> I think that with Andy Fleming's PHY abstraction layer, the best thing to be done
> is change fec_8xx to use this abstraction layer and then look for
> testers. what you think?
>
There's a fs_enet driver in the works which will use Andy's work.
Please refrain from doing anything :)
Regards
Pantelis
^ permalink raw reply
* 答复: ?-?¤: How to load a linux kernel under vxworks bootloader (PPC860 board)
From: FCG WANG Baohua @ 2005-07-28 5:12 UTC (permalink / raw)
To: Frank; +Cc: linuxppc-embedded
RGVhciBGcmFuazoNCiAgSG93IGNhbiBJIHJldmlzZSB0aGUgYWRkcmVzcyBvZiBsaW5rZWQgdG8g
Ym9vdCBpbiBVLUJvb3QgTWFrZWZpbGUgb3IgY29uZmlnIGZpbGUgPyBUaGFua3MgIQ0KICBJIHVz
ZSB0aGUgbWtpbWFnZSB1dGlsaXR5IG9mIFBQQ0Jvb3QgdG8gcmVsb2NhdGUgdGhlIGVudHJ5IHBv
aW50IHRvIDB4MTAwMCwgYnV0IEkgc3RpbGwgZ2V0IHRoZSANCiAic3RhcnRpbmcgYXQgMHgyODAw
MDAuLi4uLiIuIEhvdyB0byBtYWtlIGl0IGVmZmVjdD8gVGhhbmtzICENCg0KDQotLS0tLeWOn+Wn
i+mCruS7ti0tLS0tDQrlj5Hku7bkuro6IEZyYW5rIFttYWlsdG86ZnJhbm5rX20xQHlhaG9vLmNv
bV0NCuWPkemAgeaXtumXtDogMjAwNeW5tDfmnIgyOOaXpSAxMjo1Nw0K5pS25Lu25Lq6OiBGQ0cg
V0FORyBCYW9odWENCuS4u+mimDogUmU6ID8tP8KkOiBIb3cgdG8gbG9hZCBhIGxpbnV4IGtlcm5l
bCB1bmRlciB2eHdvcmtzIGJvb3Rsb2FkZXIgKFBQQzg2MCBib2FyZCkNCg0KDQpTb3JyeSwNCkJ1
dCB5b3Ugd2lsbCBoYXZlIHRvIHJlY29tcGlsZSB1LWJvb3QgYXQgdGhhdCBhZGRyZXNzLiBJdCdz
DQpvcmlnaW5hbGx5IGNvbXBpbGVkIGFuZCBsaW5rZWQgdG8gYm9vdCBhdCAweGZmZjAwMTAwLiBJ
IGRvbid0DQprbm93IHdoYXQgeW91IGhhdmUgdG8gZG8gd2l0aCB2eFdvcmtzIHJvbS4uLg0KDQot
LS0gRkNHIFdBTkcgQmFvaHVhIDxCYW9odWEuV0FOR0BhbGNhdGVsLXNiZWxsLmNvbS5jbj4gd3Jv
dGU6DQoNCj4gRGVhciBGcmFuazoNCj4gIEkgY2Fubm90IHJlcGxhY2UgdGhlIHZ4V29ya3MgYm9v
dHJvbSBiZWNhdXNlIEkgaGF2ZSBubyBzb3VyY2UNCj4gYW5kIGJpbiBmaWxlcyBvZiB2eHdvcmtz
IGJvb3Rsb2FkZXIsIEkgaGF2ZSBldmVuIG5vIHRoZSANCj4gIGhhcmR3YXJlIGRpYWdyYW0gcmVz
b3VyY2Ugb2YgbXkgUFBDIDg2MCBib2FyZC4gIElmIEkgd3JpdGUNCj4gdGhlIFUtQm9vdCBpbnRv
IHRoZSByb20sIEkgbW9zdCBwb3NzaWJsZSBjYW5ub3QgYm9vdHVwIHRoZQ0KPiBib2FyZC4NCj4g
IEhvdyB0byBkb3dubG9hZCB0aGUgVS1Cb290IGludG8gUkFNIGRpcmVjdGx5IHVzaW5nIHRoZQ0K
PiB2eFdvcmtzIGJvb3Rsb2FkZXIsIEkgdHJpZWQgdG8gbG9hZCB0aGUgVS1Cb290IEVMRiBpbWFn
ZSBidXQNCj4gZ2V0IHRoZSBzYW1lIA0KPiAgcmVzdWx0ICJzdGFydGluZyBhdCAweDI4MDAwMCAu
Li4iIHRoZW4gbm8gcmVzcG9uc2UgZnJvbSB0aGUNCj4gc2VyaWFsIGNvbnNvbGUuDQo+ICBUaGUg
b25seSB0aGluZyBJIGNhbiBkbyBpcyB1c2UgdnhXb3JrcyBURlRQIHRvIGRvd25sb2FkIHRoZQ0K
PiBFTEYgaW1hZ2UgZm9yIGxpbnV4IGtlcm5lbCBvciBVLUJvb3QgaW50byBSQU0uIA0KPiAgIENh
biB5b3UgdGVsbCBtZSBob3cgdG8gc2xvdmUgdGhlICBVLUJvb3QgInN0YXJ0aW5nIGF0DQo+IDB4
MjgwMDAwIC4uLiIgIHByb2JsZW0gPyB0aGFua3MhDQo+ICAgDQo+IA0KPiAtLS0tLcOlxb3FuMOl
wqfigLnDqeKAmsKuw6TCu8K2LS0tLS0NCj4gw6XCj+KAmMOkwrvCtsOkwrrCujogRnJhbmsgW21h
aWx0bzpmcmFubmtfbTFAeWFob28uY29tXQ0KPiDDpcKP4oCYw6nigqzCgcOm4oCUwrbDqeKAlOKA
sjogMjAwNcOlwrnigLI3w6bFk8uGMjjDpuKAlO+/pSAxMjoyOQ0KPiDDpuKAncK2w6TCu8K2w6TC
usK6OiBGQ0cgV0FORyBCYW9odWE7IGxpbnV4cHBjLWVtYmVkZGVkQG96bGFicy5vcmcNCj4gw6TC
uMK7w6nvv6DLnDogUmU6IEhvdyB0byBsb2FkIGEgbGludXgga2VybmVsIHVuZGVyIHZ4d29ya3MN
Cj4gYm9vdGxvYWRlciAoUFBDODYwIGJvYXJkKQ0KPiANCj4gDQo+IA0KPiANCj4gLS0tIEZDRyBX
QU5HIEJhb2h1YSA8QmFvaHVhLldBTkdAYWxjYXRlbC1zYmVsbC5jb20uY24+IHdyb3RlOg0KPiAN
Cj4gPiBEZWFyIEFsbDoNCj4gPiAgIEkgd2FudCB0byBib290IGEgbGludXggMi40LjI1IGtlcm5l
bCB1bmRlciB2eHdvcmtzDQo+ID4gYm9vdGxvYWRlci4gV2hlbiBJIHVzaW5nIGZsYXQgbW9kZSgw
eDIwMDAwMCAtLT4gIDB4MTAwMDApDQo+ID4ga2VybmVsICB1bmNvbXByZXNzZWQgRUxGIGZvcm1h
dCAoIHZtbGludXggKSwNCj4gPiAgYW5kIGRvd25sb2FkIGl0IHVzaW5nIFRGVFAgb2Ygdnh3b3Jr
cywgaXQgcHJpbnQgdGhlDQo+ICJzdGFydGluZw0KPiA+IGF0IDB4MTAwMCAuLi4uIiBhbmQgIGZy
ZWV6ZS4gIE5vIGlucHV0IG9yIG91dHB1dCBvbiBzZXJpYWwNCj4gPiBwb3J0Lg0KPiA+ICBUaGUg
dmVyc2lvbiBvZiB2eHdvcmtzIGlzIDUuMy4xLiANCj4gPiAgY2FuIHlvdSBnaXZlIG1lIHNvbWUg
ZGV0YWlsIGFkdmljZSBvciBnaXZlIG1lIGEgdG9vbCB0bw0KPiBzbG92ZQ0KPiA+IGl0PyB0aGFu
a3MgIQ0KPiANCj4gRG8gd2hhdCBJIGRpZDoNCj4gUmVwbGFjZSB0aGUgdnhXb3JrcyByb20gd2l0
aCB5b3UgdS1ib290IGFuZCB5b3UgY2FuIGJvb3QgTGludXgNCj4gb3IgdnhXb3JrcyB3aXRoIHRo
ZSBzYW1lIGJvb3Rsb2FkZXIuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPiBEbyBZb3UgWWFob28hPw0KPiBUaXJlZCBvZiBzcGFtPyAg
WWFob28hIE1haWwgaGFzIHRoZSBiZXN0IHNwYW0gcHJvdGVjdGlvbg0KPiBhcm91bmQgDQo+IGh0
dHA6Ly9tYWlsLnlhaG9vLmNvbSANCj4gDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCkRvIFlvdSBZYWhvbyE/DQpUaXJlZCBvZiBzcGFtPyAg
WWFob28hIE1haWwgaGFzIHRoZSBiZXN0IHNwYW0gcHJvdGVjdGlvbiBhcm91bmQgDQpodHRwOi8v
bWFpbC55YWhvby5jb20gDQo=
^ permalink raw reply
* 答复: How to load a linux kernel under vxworks bootloader (PPC860 board)
From: FCG WANG Baohua @ 2005-07-28 4:49 UTC (permalink / raw)
To: Frank, linuxppc-embedded
RGVhciBGcmFuazoNCiBJIGNhbm5vdCByZXBsYWNlIHRoZSB2eFdvcmtzIGJvb3Ryb20gYmVjYXVz
ZSBJIGhhdmUgbm8gc291cmNlIGFuZCBiaW4gZmlsZXMgb2Ygdnh3b3JrcyBib290bG9hZGVyLCBJ
IGhhdmUgZXZlbiBubyB0aGUgDQogaGFyZHdhcmUgZGlhZ3JhbSByZXNvdXJjZSBvZiBteSBQUEMg
ODYwIGJvYXJkLiAgSWYgSSB3cml0ZSB0aGUgVS1Cb290IGludG8gdGhlIHJvbSwgSSBtb3N0IHBv
c3NpYmxlIGNhbm5vdCBib290dXAgdGhlIGJvYXJkLg0KIEhvdyB0byBkb3dubG9hZCB0aGUgVS1C
b290IGludG8gUkFNIGRpcmVjdGx5IHVzaW5nIHRoZSB2eFdvcmtzIGJvb3Rsb2FkZXIsIEkgdHJp
ZWQgdG8gbG9hZCB0aGUgVS1Cb290IEVMRiBpbWFnZSBidXQgZ2V0IHRoZSBzYW1lIA0KIHJlc3Vs
dCAic3RhcnRpbmcgYXQgMHgyODAwMDAgLi4uIiB0aGVuIG5vIHJlc3BvbnNlIGZyb20gdGhlIHNl
cmlhbCBjb25zb2xlLg0KIFRoZSBvbmx5IHRoaW5nIEkgY2FuIGRvIGlzIHVzZSB2eFdvcmtzIFRG
VFAgdG8gZG93bmxvYWQgdGhlIEVMRiBpbWFnZSBmb3IgbGludXgga2VybmVsIG9yIFUtQm9vdCBp
bnRvIFJBTS4gDQogIENhbiB5b3UgdGVsbCBtZSBob3cgdG8gc2xvdmUgdGhlICBVLUJvb3QgInN0
YXJ0aW5nIGF0IDB4MjgwMDAwIC4uLiIgIHByb2JsZW0gPyB0aGFua3MhDQogIA0KDQotLS0tLeWO
n+Wni+mCruS7ti0tLS0tDQrlj5Hku7bkuro6IEZyYW5rIFttYWlsdG86ZnJhbm5rX20xQHlhaG9v
LmNvbV0NCuWPkemAgeaXtumXtDogMjAwNeW5tDfmnIgyOOaXpSAxMjoyOQ0K5pS25Lu25Lq6OiBG
Q0cgV0FORyBCYW9odWE7IGxpbnV4cHBjLWVtYmVkZGVkQG96bGFicy5vcmcNCuS4u+mimDogUmU6
IEhvdyB0byBsb2FkIGEgbGludXgga2VybmVsIHVuZGVyIHZ4d29ya3MgYm9vdGxvYWRlciAoUFBD
ODYwIGJvYXJkKQ0KDQoNCg0KDQotLS0gRkNHIFdBTkcgQmFvaHVhIDxCYW9odWEuV0FOR0BhbGNh
dGVsLXNiZWxsLmNvbS5jbj4gd3JvdGU6DQoNCj4gRGVhciBBbGw6DQo+ICAgSSB3YW50IHRvIGJv
b3QgYSBsaW51eCAyLjQuMjUga2VybmVsIHVuZGVyIHZ4d29ya3MNCj4gYm9vdGxvYWRlci4gV2hl
biBJIHVzaW5nIGZsYXQgbW9kZSgweDIwMDAwMCAtLT4gIDB4MTAwMDApDQo+IGtlcm5lbCAgdW5j
b21wcmVzc2VkIEVMRiBmb3JtYXQgKCB2bWxpbnV4ICksDQo+ICBhbmQgZG93bmxvYWQgaXQgdXNp
bmcgVEZUUCBvZiB2eHdvcmtzLCBpdCBwcmludCB0aGUgInN0YXJ0aW5nDQo+IGF0IDB4MTAwMCAu
Li4uIiBhbmQgIGZyZWV6ZS4gIE5vIGlucHV0IG9yIG91dHB1dCBvbiBzZXJpYWwNCj4gcG9ydC4N
Cj4gIFRoZSB2ZXJzaW9uIG9mIHZ4d29ya3MgaXMgNS4zLjEuIA0KPiAgY2FuIHlvdSBnaXZlIG1l
IHNvbWUgZGV0YWlsIGFkdmljZSBvciBnaXZlIG1lIGEgdG9vbCB0byBzbG92ZQ0KPiBpdD8gdGhh
bmtzICENCg0KRG8gd2hhdCBJIGRpZDoNClJlcGxhY2UgdGhlIHZ4V29ya3Mgcm9tIHdpdGggeW91
IHUtYm9vdCBhbmQgeW91IGNhbiBib290IExpbnV4DQpvciB2eFdvcmtzIHdpdGggdGhlIHNhbWUg
Ym9vdGxvYWRlci4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCkRvIFlvdSBZYWhvbyE/DQpUaXJlZCBvZiBzcGFtPyAgWWFob28hIE1haWwgaGFz
IHRoZSBiZXN0IHNwYW0gcHJvdGVjdGlvbiBhcm91bmQgDQpodHRwOi8vbWFpbC55YWhvby5jb20g
DQo=
^ permalink raw reply
* Re: How to load a linux kernel under vxworks bootloader (PPC860 board)
From: Frank @ 2005-07-28 4:28 UTC (permalink / raw)
To: FCG WANG Baohua, linuxppc-embedded
In-Reply-To: <A9DE2BAF233E444FA9C5E77A5825A01E8652D4@ydmail.sbell.com.cn>
--- FCG WANG Baohua <Baohua.WANG@alcatel-sbell.com.cn> wrote:
> Dear All:
> I want to boot a linux 2.4.25 kernel under vxworks
> bootloader. When I using flat mode(0x200000 --> 0x10000)
> kernel uncompressed ELF format ( vmlinux ),
> and download it using TFTP of vxworks, it print the "starting
> at 0x1000 ...." and freeze. No input or output on serial
> port.
> The version of vxworks is 5.3.1.
> can you give me some detail advice or give me a tool to slove
> it? thanks !
Do what I did:
Replace the vxWorks rom with you u-boot and you can boot Linux
or vxWorks with the same bootloader.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* How to load a linux kernel under vxworks bootloader (PPC860 board)
From: FCG WANG Baohua @ 2005-07-28 4:16 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 410 bytes --]
Dear All:
I want to boot a linux 2.4.25 kernel under vxworks bootloader. When I using flat mode(0x200000 --> 0x10000) kernel uncompressed ELF format ( vmlinux ),
and download it using TFTP of vxworks, it print the "starting at 0x1000 ...." and freeze. No input or output on serial port.
The version of vxworks is 5.3.1.
can you give me some detail advice or give me a tool to slove it? thanks !
[-- Attachment #2: Type: text/html, Size: 1168 bytes --]
^ permalink raw reply
* using bestcomm
From: 钟磊 @ 2005-07-28 3:32 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 401 bytes --]
Hi all:
In my embeded linux directory , I found the bestcomm API (ELDK\ppc_82xx\usr\src\linuxppc_2_4_devel
\arch\ppc\5xxx_io\bestcomm\capi)
But I don't know how to use the API to handle my task which is to transfer a block of data from the FPGA's internal RAM to the PowerPC MPC5200.
Pls give me a simple example of how to use the bestcomm to transfer data from FPGA
Thanks
zhonglei
[-- Attachment #2: Type: text/html, Size: 938 bytes --]
^ permalink raw reply
* Re: [PATCH 00/14] ppc32: Remove board ports that are no longer maintained
From: Kumar Gala @ 2005-07-27 23:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Gala Kumar K.-galak, linuxppc-embedded
In-Reply-To: <20050727125746.54329281.akpm@osdl.org>
On Jul 27, 2005, at 2:57 PM, Andrew Morton wrote:
> Kumar Gala <galak@freescale.com> wrote:
>
>>
>> The following board ports are no longer maintained or have become
>> obsolete:
>>
>> adir
>> ash
>> beech
>> cedar
>> ep405
>> k2
>> mcpn765
>> menf1
>> oak
>> pcore
>> rainier
>> redwood
>> sm850
>> spd823ts
>>
>> We are there for removing support for them.
>>
>
> I'll merge all these into -mm for now, but will hold off sending
> any of
> them upstream pending confirmation of which patches we really want to
> proceed with.
Sounds good. We will get to some resolution on the ep405 which seems
the be the only system that people are making noise on today.
- kumar
^ permalink raw reply
* Re: [PATCH 00/14] ppc32: Remove board ports that are no longer maintained
From: Kumar Gala @ 2005-07-27 23:34 UTC (permalink / raw)
To: Matt Porter
Cc: Andrew Morton, linux-kernel, Gala Kumar K.-galak,
linuxppc-embedded
In-Reply-To: <20050727101502.B1114@cox.net>
On Jul 27, 2005, at 12:15 PM, Matt Porter wrote:
> On Wed, Jul 27, 2005 at 09:27:41AM -0700, Eugene Surovegin wrote:
>
>> On Wed, Jul 27, 2005 at 12:13:23PM -0400, Michael Richardson wrote:
>>
>>> Kumar, I thought that we had some volunteers to take care of some of
>>> those. I know that I still care about ep405, and I'm willing to
>>>
> maintain
>
>>> the code.
>>>
>>
>> Well, it has been almost two months since Kumar asked about
>>
> maintenance
>
>> for this board. Nothing happened since then.
>>
>> Why is it not fixed yet? Please, send a patch which fixes it. This is
>> the _best_ way to keep this board in the tree, not some empty
>> maintenance _promises_.
>>
>
> When we recover our history from the linuxppc-2.4/2.5 trees we can
> show exactly how long it's been since anybody touched ep405.
>
> Quick googling shows that it's been almost 2 years since the last
> mention of ep405 (exluding removal discussions) on linuxppc-embedded.
> Last ep405-related commits are more than 2 years ago.
So we are ok with it being removed. This seems to be the only board
port that I removed that has caused any noise.
- kumar
^ permalink raw reply
* Re: [PATCH][1/3] ppc32: add 440ep support
From: Andrew Morton @ 2005-07-27 23:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <17128.4407.838024.111955@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> wrote:
>
> Andrew Morton writes:
>
> > Matt Porter <mporter@kernel.crashing.org> wrote:
> > >
> > > +static u64 dma_mask = 0xffffffffULL;
> >
> > I'm sure you're totally uninterested in this, but the above will probably
> > generate warnings on (say) ppc64, where u64 is implemented as unsigned
> > long.
> >
> > I usually chuck a simple `-1' in there and the compiler always gets it
> > right, regardless of signedness and size and architecture.
>
> Umm, I think we actually want 2^32-1 not -1, don't we?
Doh. Cant coun't.
^ permalink raw reply
* Re: [PATCH][1/3] ppc32: add 440ep support
From: Paul Mackerras @ 2005-07-27 22:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <20050727131857.78a56972.akpm@osdl.org>
Andrew Morton writes:
> Matt Porter <mporter@kernel.crashing.org> wrote:
> >
> > +static u64 dma_mask = 0xffffffffULL;
>
> I'm sure you're totally uninterested in this, but the above will probably
> generate warnings on (say) ppc64, where u64 is implemented as unsigned
> long.
>
> I usually chuck a simple `-1' in there and the compiler always gets it
> right, regardless of signedness and size and architecture.
Umm, I think we actually want 2^32-1 not -1, don't we? In which case
I think Matt's code is what we have to have.
I tried a little test compile with gcc 4.0 with -m64 -Wall and it
didn't generate a warning with the 0xffffffffULL constant.
Paul.
^ permalink raw reply
* Re: platform/board removal update
From: 'Aristeu Sergio Rozanski Filho' @ 2005-07-27 21:46 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-dev list, Embedded PPC Linux list
In-Reply-To: <20050726100500.GB28003@dmt.cnet>
> 8xx_io/fec.c is still using v2.4's workqueue infrastructure but other than
> that its working fine.
>
> The fix will be pushed upstream ASAP.
>
> BTW, we should schedule 8xx_io/fec.c for removal, but before that we ought to
> test all supported PHY's on the new driver.
>
> Aris was talking to me about this on OLS. Aris, what are the PHY's not supported
> by Panto's driver again? We should build a list of those and ask around for
> testers.
I think that with Andy Fleming's PHY abstraction layer, the best thing to be done
is change fec_8xx to use this abstraction layer and then look for
testers. what you think?
--
Aristeu
^ permalink raw reply
* Re: [RFC PATCH 1/4] PHY Abstraction Layer III (now with more splitiness)
From: Randy Dunlap @ 2005-07-27 21:34 UTC (permalink / raw)
To: Andy Fleming, Randy Dunlap, Francois Romieu, Netdev,
linuxppc-embedded
> On Jul 27, 2005, at 13:08, Randy Dunlap wrote:
>
> >
> >
> >> On Jul 25, 2005, at 16:06, Francois Romieu wrote:
> >>
> >>
> >>
> >>>> +int mdiobus_register(struct mii_bus *bus)
> >>>> +{
> >>>> + int i;
> >>>> + int err = 0;
> >>>> +
> >>>> + spin_lock_init(&bus->mdio_lock);
> >>>> +
> >>>> + if (NULL == bus || NULL == bus->name ||
> >>>> + NULL == bus->read ||
> >>>> + NULL == bus->write)
> >>>>
> >>>>
> >>>
> >>> Be spartan:
> >>> if (!bus || !bus->name || !bus->read || !bus->write)
> >>>
> >>
> >>
> >> I think we have to agree to disagree here. I could be convinced, but
> >> I'm partial to using NULL explicitly.
> >>
> >
> > But there are 2 issues here (at least). One is to use NULL or
> > not. The other is using (constant == var) or (var == constant).
> >
> > It's not described in CodingStlye afaik, but most recent email
> > on the subject strongly prefers (var == constant) [in my
> > unscientific survey -- of bits in my head].
> >
> > So using the suggested style will fix both of these. :)
>
>
> Ok, here I won't agree to disagree with you. !foo as a check for
> NULL is a reasonable idea, but not my style. If that's the preferred
> style for the kernel, I will do that.
>
> But (var == constant) is a style that asks for errors. By putting
> the constant first in these checks, you never run the risk of leaving
> a bug like this:
>
> if (dev = NULL)
> ...
>
> This kind of error is quite frustrating to detect, and the eye will
> often miss it when scanning for errors. If you follow constant ==
> var, though, then the bug looks like this:
>
> if (NULL = dev)
>
> which is instantly caught by the compiler.
>
> Just my 32 cents
Yes, we know about that argument. :)
> >>>> + /* Otherwise, we allocate the device, and initialize the
> >>>> + * default values */
> >>>> + dev = kmalloc(sizeof(*dev), GFP_KERNEL);
> >>>> +
> >>>> + if (NULL == dev) {
> >>>> + errno = -ENOMEM;
> >>>> + return NULL;
> >>>> + }
> >>>> +
> >>>> + memset(dev, 0, sizeof(*dev));
> >>>>
> >>>>
> >>>
> >>> The kernel provides kcalloc.
> >>>
> >>
> >>
> >> I went looking for it, and found it in fs/cifs/misc.c. I'm hesitant
> >> to link to a function defined in the filesystem code just to save 1
> >> line of code
> >>
> >
> > It's more global than that.
>
>
> Should we move the function, then, to include/linux/slab.h? Or
> somewhere else?
It's there, like Francois said. Get use a current tree.
---
~Randy
^ 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