LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* 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

* [2.6 patch] arch/ppc/kernel/ppc_ksyms.c: remove unused #define EXPORT_SYMTAB_STROPS
From: Adrian Bunk @ 2005-07-28 14:47 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel

This #define is only used on sparc.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 10 Jul 2005

--- linux-2.6.13-rc2-mm1-full/arch/ppc/kernel/ppc_ksyms.c.old	2005-07-10 17:35:05.000000000 +0200
+++ linux-2.6.13-rc2-mm1-full/arch/ppc/kernel/ppc_ksyms.c	2005-07-10 17:35:12.000000000 +0200
@@ -51,9 +51,6 @@
 #include <asm/commproc.h>
 #endif
 
-/* Tell string.h we don't want memcpy etc. as cpp defines */
-#define EXPORT_SYMTAB_STROPS
-
 extern void transfer_to_handler(void);
 extern void do_IRQ(struct pt_regs *regs);
 extern void MachineCheckException(struct pt_regs *regs);

^ permalink raw reply

* Re: How to load a linux kernel under vxworks bootloader (PPC860 board)
From: Guy Streeter @ 2005-07-28 15:01 UTC (permalink / raw)
  To: FCG WANG Baohua; +Cc: linuxppc-embedded
In-Reply-To: <A9DE2BAF233E444FA9C5E77A5825A01E8652D4@ydmail.sbell.com.cn>

On Thu, 2005-07-28 at 12:16 +0800, FCG WANG Baohua 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 !

Most ppc kernels depend on the bootloader to configure some devices and
to leave some configuration data in a known memory location so that the
kernel (or the kernel's boot wrapper) can use the devices and data
during startup.
None of the board-specific startup code in kernel supports booting from
a VxWorks bootloader. Code I have written to do that for some boards
doesn't appear to be in the kernel anywhere.
You will need to look at the startup code your board is using and figure
out how to do without the device and data setup normally provided by the
bootloader. I addition, you will need to make sure the kernel is trying
to use the console port at the same baud rate as VxWorks.

--Guy Streeter

^ permalink raw reply

* MPC8245 Broadcom BMW board help
From: Guilherme Mazzela @ 2005-07-28 14:25 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/html, Size: 741 bytes --]

^ permalink raw reply

* PQ2 platform devices
From: Vitaly Bordug @ 2005-07-28 15:24 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-embedded list

Kumar,
What is the latest version of PQ2 platform devices 
(pq2_devices.c/pq2_sys.c) - does anything changed since `RFC: 
cpm2_devices.c` discussion?
If yes, can you post it to the list?

-- 
Sincerely, 
Vitaly

^ permalink raw reply

* Re: 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 16:18 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <20050728125132.7B8FD352584@atlas.denx.de>

On 28 July 2005 16:51, Wolfgang Denk wrote:
> You must be using old code (probably the version that came with =A0ELDK
> 3.1.1?). =A0Please =A0fetch =A0the =A0current =A0code from CVS; see commi=
t "Fix
> problems with second ethernet interface on 405EP".
> Wolfgang Denk

Wolfgang, thank you!=20
I've renewed the kernel from CVS and it works much better now.=20
By the way, the driver for PPChameleonEVB is presented in linuxppc_2_4_deve=
l=20
module only and is not presented in linux-2.4 module of CVS (there miss the=
=20
whole <linux>/drivers/net/ibm_emac directory).

Thank you again, regards,
Igor Marnat

^ permalink raw reply

* Problem allocating large meory using m8260_cpm_hostalloc
From: Prashant Alange @ 2005-07-28 16:50 UTC (permalink / raw)
  To: Linuxppc-embedded

Hi everyone,
I am having problem in allocating large memory using=20
m8260_cpm_hostalloc function in my driver. (Approx 256 Kbytes). I
tried increaing the NUM_CPM_HOST_PAGES macro in cpm_8260.h file to 64
but still it fails for 200K of memory request. This macro is used by
alloc_bootmem_pages() function. I have read that we should use this
function if we intend to have consecutive memory pages allocated.

Could anyone tell what I am missing here?
How can I allocate large memory in my driver using this hostalloc function?

Thanks for your time.

Prashant

^ permalink raw reply

* Linux 2.6.12.1 PowerPC 750FX Initialization Failures (Caching & MMU)
From: Goodman, Brad @ 2005-07-28 17:22 UTC (permalink / raw)
  To: Linuxppc-embedded

I am running the 2.6.12.1 Kernel with a Force CPCI-695 board.

(This board has a PPC 750FX, with a Marvell Disco II (MV64360) - although it uses a 8250, instead of the Disco II UART.)

Anyway…

This thing is hanging like a buffalo on bootup - in early Kernel initialization:

I setup_common_caches it gets to here:

  mfspr r11,SPRN_HID0				← HID0 is 0x800200a4
  andi. r0,r11,HID0_DCE
  ori r11,r11,HID0_ICE|HID0_DCE
  ori r8,r11,HID0_ICFI
  bne 1f      /* don't invalidate the D-cache */
  ori r8,r8,HID0_DCI    /* unless it wasn't enabled */
1:  sync
  mtspr SPRN_HID0,r8    /* enable and invalidate caches */     ← r8 is now 0x8002cca4
  ### NEVER GETS HERE
  sync
  mtspr SPRN_HID0,r11   /* enable caches */  
  mr r3,r11

So it's hanging trying to enable and invalidate the caches.

So - trying to ditch that problem until later - I had it leave the caches off and continuing.

Now, it gets to the point where it tries to enable the MMU, and in the turn_on_mmu function it appears to go unresponsive right after the return-from-interrupt:

turn_on_mmu:
  mfmsr r0
  ori r0,r0,MSR_DR|MSR_IR
  mtspr SPRN_SRR1,r0
  lis r0,start_here@h
  ori r0,r0,start_here@l
  mtspr SPRN_SRR0,r0
  SYNC
  ## GETS HERE
  RFI       /* enables MMU */

I put a check in start_here - and it never reaches it. The BATs should all be set up per-normal initialization, and I verified that it was mapping Physical address 0 to Effective Address 0xc0000000 - but still no luck.

BTW - I am loading my znetboot image (zImage with no ELF header) at 0x800000 - so it's not relocating on startup (and verified that this was happening correctly.)

I don't know if the caching issue is related to the MMU issue - or they are two totally separate things.

Any ideas????

Brad Goodman
Empirix, Inc.
bgoodman -et- empirix -dut- com

^ permalink raw reply

* Re: [PATCH 0/3] Support for SPI busses and devices
From: Grant Likely @ 2005-07-28 17:25 UTC (permalink / raw)
  To: Yuli Barcohen, Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <17124.61231.988084.399036@astp0002.localdomain>

On 7/25/05, Yuli Barcohen <yuli@arabellasw.com> wrote:
> >>>>> Kate Alhola writes:
>=20
>     Yuli> SPI is very similar to I2C IMHO. I'm not sure separate
>     Yuli> infrastructure is needed. We support SPI on MPC8xx/82xx/85xx
>     Yuli> using the standard I2C infrastructure. I only had to add a
>     Yuli> couple of IOCTLs to control clock frequency and polarity. Due
>     Yuli> to such an implementation, lm-sensors work OK with SPI
>     Yuli> temperature sensors, for example.
>=20
>     Kate> SPI IS wery similar than I2C and for this reason it looks a
>     Kate> like that all SPI subsystems implementations are based on I2C
>     Kate> code.

Thanks for the comments everyone.  I had seen the first cut at an SPI
subsystem on the lkml, but I hadn't seen the revised patch.  My
understanding from GregKH's comments on the first patch is that i2c is
a bit of a mess:

>From http://lkml.org/lkml/2005/5/31/251
"The i2c dev interface is a mess, please don't duplicate it, there is
no need to do so."

What is current opinion on the i2c subsystem?  Did I misunderstand
Greg's I2C comments?  I put together the SPI patch as an alternative
implementation that matches the current coding conventions (as I
understand them).

Yuli, are there any plans to submit your i2c changes to support SPI
back to mainline?

I've now got to go back and review the revised SPI patch on the LKML.

Thanks again,
g.

^ permalink raw reply

* RE: Problem allocating large meory using m8260_cpm_hostalloc
From: Goodman, Brad @ 2005-07-28 17:29 UTC (permalink / raw)
  To: Prashant Alange, Linuxppc-embedded

I think you have to increase MAX_ORDER in linux/mmzone.h

This number means you can allocate a maximum of 2^(MAX_ORDER-1)
contiguous pages.

Brad Goodman


-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Prashant
Alange
Sent: Thursday, July 28, 2005 12:50 PM
To: Linuxppc-embedded@ozlabs.org
Subject: Problem allocating large meory using m8260_cpm_hostalloc

Hi everyone,
I am having problem in allocating large memory using=20
m8260_cpm_hostalloc function in my driver. (Approx 256 Kbytes). I
tried increaing the NUM_CPM_HOST_PAGES macro in cpm_8260.h file to 64
but still it fails for 200K of memory request. This macro is used by
alloc_bootmem_pages() function. I have read that we should use this
function if we intend to have consecutive memory pages allocated.

Could anyone tell what I am missing here?
How can I allocate large memory in my driver using this hostalloc
function?

Thanks for your time.

Prashant
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

^ permalink raw reply

* Regarding LAPD on MPC8260/70 Boards.
From: Manish Joshi @ 2005-07-28 17:22 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

Hi,
 
I am working on a project with the objective of bringing up ISDN Layer 2 on MPC8270 boards.
Is there somebody who has done it before on this list ? If yes, please let me know the things I would have to do to accomplish this.
 
As I understand it today, I wil have to write a MCC Driver for MCC and then link the MCC channels to TDM ( 4 ports for me) using SI. My Q.921 layer in turn will receive the HDLC frames from MCC for processing Q.921 state m/c. 
This is from a very high level and I understand that I will have to do lot of peripheral stuff for this.
If somebody can throw more light on this, it will be of great help.
 
TIA,
Manish

		
---------------------------------
 Start your day with Yahoo! - make it your home page 

[-- Attachment #2: Type: text/html, Size: 926 bytes --]

^ permalink raw reply

* Re: Problem allocating large meory using m8260_cpm_hostalloc
From: Prashant Alange @ 2005-07-28 17:55 UTC (permalink / raw)
  To: Goodman, Brad; +Cc: Linuxppc-embedded
In-Reply-To: <BD261180E6D35F4D9D32F3E44FD3D901011B00CC@EMPBEDEX.empirix.com>

Thanks I saw linux/mmzone.h file. MAX_ORDER depends on the
CONFIG_FORCE_MAX_ZONEORDER macro. But I do not see any option in
menuconfig to change this value. I am using 2.4.22 kernel on MPC8260
kernel. Can you pls tell me how to chaneg this?

Thanks,
Prashant
I do not see any option in menuconfig to change this value.

On 7/28/05, Goodman, Brad <bgoodman@empirix.com> wrote:
> I think you have to increase MAX_ORDER in linux/mmzone.h
>=20
> This number means you can allocate a maximum of 2^(MAX_ORDER-1)
> contiguous pages.
>=20
> Brad Goodman
>=20
>=20
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Prashant
> Alange
> Sent: Thursday, July 28, 2005 12:50 PM
> To: Linuxppc-embedded@ozlabs.org
> Subject: Problem allocating large meory using m8260_cpm_hostalloc
>=20
> Hi everyone,
> I am having problem in allocating large memory using
> m8260_cpm_hostalloc function in my driver. (Approx 256 Kbytes). I
> tried increaing the NUM_CPM_HOST_PAGES macro in cpm_8260.h file to 64
> but still it fails for 200K of memory request. This macro is used by
> alloc_bootmem_pages() function. I have read that we should use this
> function if we intend to have consecutive memory pages allocated.
>=20
> Could anyone tell what I am missing here?
> How can I allocate large memory in my driver using this hostalloc
> function?
>=20
> Thanks for your time.
>=20
> Prashant
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>

^ permalink raw reply

* Re: Problem allocating large meory using m8260_cpm_hostalloc
From: Dan Malek @ 2005-07-28 18:06 UTC (permalink / raw)
  To: Prashant Alange; +Cc: Linuxppc-embedded
In-Reply-To: <6d145b4205072809505b101b48@mail.gmail.com>


On Jul 28, 2005, at 12:50 PM, Prashant Alange wrote:

> Could anyone tell what I am missing here?

You are not supposed to be using this function for such memory
allocations.

> How can I allocate large memory in my driver using this hostalloc 
> function?

You don't.  If you look at the existing drivers and comments, you'll 
see it's
intended to only allocate small objects that are too inefficient to 
manage
with the usual Linux DMA allocation functions.  You must use the 
standard
Linux DMA for large allocations.  Read Documentation/DMA-API.txt, and
in particular the non-PCI functions.

Thanks.


	-- Dan

^ permalink raw reply

* Re: Problem allocating large meory using m8260_cpm_hostalloc
From: Prashant Alange @ 2005-07-28 18:29 UTC (permalink / raw)
  To: Dan Malek; +Cc: Linuxppc-embedded
In-Reply-To: <5367eda3a78096bb46168292371e9530@embeddededge.com>

Could you pls tell me what function I should be using for larger
memories. I do not know much about the memory management in linux.  It
would be heleful if you can throw some light on this in terms of
functions I should use. I could not find the file DMA-API.txt file but
I did get DMA-mapping.txt. Is this the file you were referring to?

Thanks,
Prashant


On 7/28/05, Dan Malek <dan@embeddededge.com> wrote:
>=20
> On Jul 28, 2005, at 12:50 PM, Prashant Alange wrote:
>=20
> > Could anyone tell what I am missing here?
>=20
> You are not supposed to be using this function for such memory
> allocations.
>=20
> > How can I allocate large memory in my driver using this hostalloc
> > function?
>=20
> You don't.  If you look at the existing drivers and comments, you'll
> see it's
> intended to only allocate small objects that are too inefficient to
> manage
> with the usual Linux DMA allocation functions.  You must use the
> standard
> Linux DMA for large allocations.  Read Documentation/DMA-API.txt, and
> in particular the non-PCI functions.
>=20
> Thanks.
>=20
>=20
>        -- Dan
>=20
>

^ permalink raw reply

* [PATCH] ppc32: add missing 4xx EMAC sysfs nodes
From: Eugene Surovegin @ 2005-07-28 18:32 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linuxppc-embedded

Add missing 4xx EMAC data sysfs nodes.

Sugned-off-by: Eugene Surovegin <ebs@ebshome.net>

diff --git a/include/asm-ppc/ibm_ocp.h b/include/asm-ppc/ibm_ocp.h
--- a/include/asm-ppc/ibm_ocp.h
+++ b/include/asm-ppc/ibm_ocp.h
@@ -71,6 +71,8 @@ struct ocp_func_emac_data {
 
 /* Sysfs support */
 #define OCP_SYSFS_EMAC_DATA()						\
+OCP_SYSFS_ADDTL(struct ocp_func_emac_data, "%d\n", emac, rgmii_idx)	\
+OCP_SYSFS_ADDTL(struct ocp_func_emac_data, "%d\n", emac, rgmii_mux)	\
 OCP_SYSFS_ADDTL(struct ocp_func_emac_data, "%d\n", emac, zmii_idx)	\
 OCP_SYSFS_ADDTL(struct ocp_func_emac_data, "%d\n", emac, zmii_mux)	\
 OCP_SYSFS_ADDTL(struct ocp_func_emac_data, "%d\n", emac, mal_idx)	\
@@ -78,9 +80,14 @@ OCP_SYSFS_ADDTL(struct ocp_func_emac_dat
 OCP_SYSFS_ADDTL(struct ocp_func_emac_data, "%d\n", emac, mal_tx_chan)	\
 OCP_SYSFS_ADDTL(struct ocp_func_emac_data, "%d\n", emac, wol_irq)	\
 OCP_SYSFS_ADDTL(struct ocp_func_emac_data, "%d\n", emac, mdio_idx)	\
+OCP_SYSFS_ADDTL(struct ocp_func_emac_data, "%d\n", emac, tah_idx)	\
+OCP_SYSFS_ADDTL(struct ocp_func_emac_data, "%d\n", emac, phy_mode)	\
+OCP_SYSFS_ADDTL(struct ocp_func_emac_data, "0x%08x\n", emac, phy_map)	\
 									\
 void ocp_show_emac_data(struct device *dev)				\
 {									\
+	device_create_file(dev, &dev_attr_emac_rgmii_idx);		\
+	device_create_file(dev, &dev_attr_emac_rgmii_mux);		\
 	device_create_file(dev, &dev_attr_emac_zmii_idx);		\
 	device_create_file(dev, &dev_attr_emac_zmii_mux);		\
 	device_create_file(dev, &dev_attr_emac_mal_idx);		\
@@ -88,6 +95,9 @@ void ocp_show_emac_data(struct device *d
 	device_create_file(dev, &dev_attr_emac_mal_tx_chan);		\
 	device_create_file(dev, &dev_attr_emac_wol_irq);		\
 	device_create_file(dev, &dev_attr_emac_mdio_idx);		\
+	device_create_file(dev, &dev_attr_emac_tah_idx);		\
+	device_create_file(dev, &dev_attr_emac_phy_mode);		\
+	device_create_file(dev, &dev_attr_emac_phy_map);		\
 }
 
 #ifdef CONFIG_40x
@@ -157,7 +167,7 @@ OCP_SYSFS_ADDTL(struct ocp_func_iic_data
 									\
 void ocp_show_iic_data(struct device *dev)				\
 {									\
-	device_create_file(dev, &dev_attr_iic_fast_mode);			\
+	device_create_file(dev, &dev_attr_iic_fast_mode);		\
 }
 #endif /* __IBM_OCP_H__ */
 #endif /* __KERNEL__ */

^ permalink raw reply

* Re: Problem allocating large meory using m8260_cpm_hostalloc
From: Dan Malek @ 2005-07-28 19:03 UTC (permalink / raw)
  To: Prashant Alange; +Cc: Linuxppc-embedded
In-Reply-To: <6d145b42050728112919ab22b@mail.gmail.com>


On Jul 28, 2005, at 2:29 PM, Prashant Alange wrote:

> Could you pls tell me what function I should be using ....

Just look at some of the existing 82xx/CPM2 drivers, like
the SCC/FEC/FCC Ethernet.

> ..... I could not find the file DMA-API.txt file but
> I did get DMA-mapping.txt. Is this the file you were referring to?

Ugh ...  a newer kernel would help.  The DMA-mapping.txt doesn't
apply to the local CPM devices, so just look at some existing drivers.

Thanks.


	-- Dan

^ permalink raw reply

* Musbhsfc USB gadget appears in latest 440EP/Bamboo patch
From: John Otken @ 2005-07-28 20:39 UTC (permalink / raw)
  To: wfarnsworth; +Cc: linuxppc-embedded

Hi Wade,

In your most recent patch for the Bamboo board, you added an entry for the 440EP's "musbhsfc" USB device/gadget.  I do not see a driver in the 2.6 tree for this device.  Did I overlook something or perhaps you are working on it?  Thanks in advances for any information.

John Otken

^ permalink raw reply

* Re: Musbhsfc USB gadget appears in latest 440EP/Bamboo patch
From: Wade Farnsworth @ 2005-07-28 20:43 UTC (permalink / raw)
  To: John Otken; +Cc: linuxppc-embedded
In-Reply-To: <42E94288.7070509@softadvances.com>

On Thu, 2005-07-28 at 13:39, John Otken wrote:
> Hi Wade,
> 
> In your most recent patch for the Bamboo board, you added an entry for the 440EP's "musbhsfc" USB device/gadget.  I do not see a driver in the 2.6 tree for this device.  Did I overlook something or perhaps you are working on it?  Thanks in advances for any information.
> 
> John Otken

Hi John,

I'm currently working on a driver for the on-board USB device.

-Wade

^ permalink raw reply

* Linux 2.6.12.1 PowerPC 750FX Initialization Failures (Caching & MMU)
From: Goodman, Brad @ 2005-07-28 21:11 UTC (permalink / raw)
  To: Linuxppc-dev


I am running the 2.6.12.1 Kernel with a Force CPCI-695 board.

(This board has a PPC 750FX, with a Marvell Disco II (MV64360) - although it uses a 8250, instead of the Disco II UART.)

Anyway…

This thing is hanging like a buffalo on bootup - in early Kernel initialization:

I setup_common_caches it gets to here:

  mfspr r11,SPRN_HID0				← HID0 is 0x800200a4
  andi. r0,r11,HID0_DCE
  ori r11,r11,HID0_ICE|HID0_DCE
  ori r8,r11,HID0_ICFI
  bne 1f      /* don't invalidate the D-cache */
  ori r8,r8,HID0_DCI    /* unless it wasn't enabled */
1:  sync
  mtspr SPRN_HID0,r8    /* enable and invalidate caches */     ← r8 is now 0x8002cca4
  ### NEVER GETS HERE
  sync
  mtspr SPRN_HID0,r11   /* enable caches */  
  mr r3,r11

So it's hanging trying to enable and invalidate the caches.

So - trying to ditch that problem until later - I had it leave the caches off and continuing.

Now, it gets to the point where it tries to enable the MMU, and in the turn_on_mmu function it appears to go unresponsive right after the return-from-interrupt:

turn_on_mmu:
  mfmsr r0
  ori r0,r0,MSR_DR|MSR_IR
  mtspr SPRN_SRR1,r0
  lis r0,start_here@h
  ori r0,r0,start_here@l
  mtspr SPRN_SRR0,r0
  SYNC
  ## GETS HERE
  RFI       /* enables MMU */

I put a check in start_here - and it never reaches it. The BATs should all be set up per-normal initialization, and I verified that it was mapping Physical address 0 to Effective Address 0xc0000000 - but still no luck.

BTW - I am loading my znetboot image (zImage with no ELF header) at 0x800000 - so it's not relocating on startup (and verified that this was happening correctly.)

I don't know if the caching issue is related to the MMU issue - or they are two totally separate things.

Any ideas????

Brad Goodman
Empirix, Inc.
bgoodman -et- empirix -dut- com

^ permalink raw reply

* [PATCH] 8xx: fec: fix interrupt handler prototypes
From: Marcelo Tosatti @ 2005-07-28  9:16 UTC (permalink / raw)
  To: akpm; +Cc: linux-ppc-embedded


From: Aristeu Sergio Rozanski Filho <aris@cathedrallabs.org>

8xx: fec: fix interrupt handler prototypes

Signed-off-by: Aristeu Sergio Rozanski Filho <aris@conectiva.com.br>
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>

Index: 2.6-8xx/arch/ppc/8xx_io/fec.c
===================================================================
--- 2.6-8xx.orig/arch/ppc/8xx_io/fec.c	2005-07-04 11:45:57.000000000 -0300
+++ 2.6-8xx/arch/ppc/8xx_io/fec.c	2005-07-04 11:45:57.000000000 -0300
@@ -199,7 +199,8 @@
 #ifdef	CONFIG_USE_MDIO
 static void fec_enet_mii(struct net_device *dev);
 #endif	/* CONFIG_USE_MDIO */
-static void fec_enet_interrupt(int irq, void * dev_id, struct pt_regs * regs);
+static irqreturn_t fec_enet_interrupt(int irq, void * dev_id,
+		       					struct pt_regs * regs);
 #ifdef CONFIG_FEC_PACKETHOOK
 static void  fec_enet_tx(struct net_device *dev, __u32 regval);
 static void  fec_enet_rx(struct net_device *dev, __u32 regval);
@@ -471,7 +472,7 @@
 /* The interrupt handler.
  * This is called from the MPC core interrupt.
  */
-static	void
+static	irqreturn_t
 fec_enet_interrupt(int irq, void * dev_id, struct pt_regs * regs)
 {
 	struct	net_device *dev = dev_id;
@@ -525,6 +526,7 @@
 		}
 
 	}
+	return IRQ_RETVAL(IRQ_HANDLED);
 }
 
 
@@ -1403,11 +1405,11 @@
 
 /* This interrupt occurs when the PHY detects a link change.
 */
-static void
+static
 #ifdef CONFIG_RPXCLASSIC
-mii_link_interrupt(void *dev_id)
+void mii_link_interrupt(void *dev_id)
 #else
-mii_link_interrupt(int irq, void * dev_id, struct pt_regs * regs)
+irqreturn_t mii_link_interrupt(int irq, void * dev_id, struct pt_regs * regs)
 #endif
 {
 #ifdef	CONFIG_USE_MDIO
@@ -1440,6 +1442,9 @@
 printk("%s[%d] %s: unexpected Link interrupt\n", __FILE__,__LINE__,__FUNCTION__);
 #endif	/* CONFIG_USE_MDIO */
 
+#ifndef CONFIG_RPXCLASSIC
+	return IRQ_RETVAL(IRQ_HANDLED);
+#endif	/* CONFIG_RPXCLASSIC */
 }
 
 static int

^ permalink raw reply

* [PATCH] 8xx: convert fec driver to use work_struct
From: Marcelo Tosatti @ 2005-07-28  9:13 UTC (permalink / raw)
  To: akpm; +Cc: linux-ppc-embedded


From: Aristeu Sergio Rozanski Filho <aris@cathedrallabs.org>

8xx: convert fec driver to use work_struct

Signed-off-by: Aristeu Sergio Rozanski Filho <aris@conectiva.com.br>
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>

Index: 2.6-8xx/arch/ppc/8xx_io/fec.c
===================================================================
--- 2.6-8xx.orig/arch/ppc/8xx_io/fec.c	2005-07-04 11:40:54.000000000 -0300
+++ 2.6-8xx/arch/ppc/8xx_io/fec.c	2005-07-04 11:45:57.000000000 -0300
@@ -173,7 +173,7 @@
 	uint	phy_status;
 	uint	phy_speed;
 	phy_info_t	*phy;
-	struct tq_struct phy_task;
+	struct work_struct phy_task;
 
 	uint	sequence_done;
 
@@ -1263,8 +1263,9 @@
 	printk(".\n");
 }
 
-static void mii_display_config(struct net_device *dev)
+static void mii_display_config(void *priv)
 {
+	struct net_device *dev = (struct net_device *)priv;
 	struct fec_enet_private *fep = dev->priv;
 	volatile uint *s = &(fep->phy_status);
 
@@ -1294,8 +1295,9 @@
 	fep->sequence_done = 1;
 }
 
-static void mii_relink(struct net_device *dev)
+static void mii_relink(void *priv)
 {
+	struct net_device *dev = (struct net_device *)priv;
 	struct fec_enet_private *fep = dev->priv;
 	int duplex;
 
@@ -1323,18 +1325,16 @@
 {
 	struct fec_enet_private *fep = dev->priv;
 
-	fep->phy_task.routine = (void *)mii_relink;
-	fep->phy_task.data = dev;
-	schedule_task(&fep->phy_task);
+	INIT_WORK(&fep->phy_task, mii_relink, (void *)dev);
+	schedule_work(&fep->phy_task);
 }
 
 static void mii_queue_config(uint mii_reg, struct net_device *dev)
 {
 	struct fec_enet_private *fep = dev->priv;
 
-	fep->phy_task.routine = (void *)mii_display_config;
-	fep->phy_task.data = dev;
-	schedule_task(&fep->phy_task);
+	INIT_WORK(&fep->phy_task, mii_display_config, (void *)dev);
+	schedule_work(&fep->phy_task);
 }
 
 

^ permalink raw reply

* [PATCH] 8xx: using dma_alloc_coherent() instead consistent_alloc()
From: Marcelo Tosatti @ 2005-07-28  9:14 UTC (permalink / raw)
  To: akpm; +Cc: linux-ppc-embedded


From: Aristeu Sergio Rozanski Filho <aris@conectiva.com.br>

8xx: using dma_alloc_coherent() instead consistent_alloc()

Signed-off-by: Aristeu Sergio Rozanski Filho <aris@conectiva.com.br>
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>

Index: 2.6-8xx/arch/ppc/8xx_io/fec.c
===================================================================
--- 2.6-8xx.orig/arch/ppc/8xx_io/fec.c	2005-07-04 11:45:57.000000000 -0300
+++ 2.6-8xx/arch/ppc/8xx_io/fec.c	2005-07-04 11:45:58.000000000 -0300
@@ -1580,7 +1580,7 @@
 	struct fec_enet_private *fep;
 	int i, j, k, err;
 	unsigned char	*eap, *iap, *ba;
-	unsigned long	mem_addr;
+	dma_addr_t	mem_addr;
 	volatile	cbd_t	*bdp;
 	cbd_t		*cbd_base;
 	volatile	immap_t	*immap;
@@ -1645,7 +1645,8 @@
 		printk("FEC initialization failed.\n");
 		return 1;
 	}
-	cbd_base = (cbd_t *)consistent_alloc(GFP_KERNEL, PAGE_SIZE, &mem_addr);
+	cbd_base = (cbd_t *)dma_alloc_coherent(dev->class_dev.dev, PAGE_SIZE,
+					       &mem_addr, GFP_KERNEL);
 
 	/* Set receive and transmit descriptor base.
 	*/
@@ -1662,7 +1663,10 @@
 
 		/* Allocate a page.
 		*/
-		ba = (unsigned char *)consistent_alloc(GFP_KERNEL, PAGE_SIZE, &mem_addr);
+		ba = (unsigned char *)dma_alloc_coherent(dev->class_dev.dev,
+							 PAGE_SIZE,
+							 &mem_addr,
+							 GFP_KERNEL);
 		/* BUG: no check for failure */
 
 		/* Initialize the BD for every fragment in the page.

^ 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 23:08 UTC (permalink / raw)
  To: Igor Marnat; +Cc: linuxppc-embedded
In-Reply-To: <200507282018.17849.marny@rambler.ru>

In message <200507282018.17849.marny@rambler.ru> you wrote:
>
> Wolfgang, thank you! 

You are welcome.

> I've renewed the kernel from CVS and it works much better now. 

Fine.

> By the way, the driver for PPChameleonEVB is presented in linuxppc_2_4_devel 
> module only and is not presented in linux-2.4 module of CVS (there miss the

Yes, this is intentional. The linux-2.4 module  is  a  more  or  less
frozen  version  of  linux  kernel  version 2.4.4 which we keep alife
because some of our customers continue to use this in their projects.

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
"In Christianity neither morality nor religion come into contact with
reality at any point."                          - Friedrich Nietzsche

^ permalink raw reply

* request_8xxirq
From: Manish Joshi @ 2005-07-29  1:33 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

Hi,
 
I am working on an old code which uses  request_8xxirq() call which I can't find in latest kernel.
Has this been replaced by something else ?
 
I see the references on net about replacing request_8xxirq()  with request_irq(). Can I do it ?
 
TIA,
Manish
 

		
---------------------------------
 Start your day with Yahoo! - make it your home page 

[-- Attachment #2: Type: text/html, Size: 545 bytes --]

^ permalink raw reply

* 答复: How to load a linux kernel under vxworks bootloader (PPC860 board)
From: FCG WANG Baohua @ 2005-07-29  2:13 UTC (permalink / raw)
  To: John W. Linville; +Cc: linuxppc-embedded

Dear Linville:
  I use the zImage to download  to RAM from the vmlinux TFTP. The =
strange thins happened :=20
 The serial console print the following message and halted :
 "Starting at 0x380000... "
   I want to ask:
  I. I saw the System.map is starting at the address 0x00000, but why =
the zImage is starting at 0x380000 ?=20
  2.  "Thankfully, I recall that later kernel versions did not have that =
problem."
    I use the ELDK3.1.1,  kernel 2.4.25.tar.bz2, Which version had you =
revised the kernel ? 2.6.x ?
       If I need the 2.4.25 (for its config file fits the PPC860 ADS), =
What can I do ?=20
  3.  In the vxworks BSP Makefile :
      ROM_TEXT_ADRS    =3D 02800100 # ROM entry address
      ROM_SIZE         =3D 00200000 # number of bytes of ROM space

      RAM_LOW_ADRS     =3D 00010000 # RAM text/data address
     RAM_HIGH_ADRS    =3D 00200000 # RAM text/data address
   =20
    How can I relocate to the right address if I download the linux =
kernel and excute it in RAM?=20
    =20
   Thanks a lot !



-----=D4=AD=CA=BC=D3=CA=BC=FE-----
=B7=A2=BC=FE=C8=CB: John W. Linville [mailto:linville@tuxdriver.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA7=D4=C229=C8=D5 0:58
=CA=D5=BC=FE=C8=CB: FCG WANG Baohua
=D6=F7=CC=E2: Re: How to load a linux kernel under vxworks bootloader =
(PPC860
board)


On Thu, Jul 28, 2005 at 01:02:04PM +0800, FCG WANG Baohua wrote:
>  Dear linville:
>    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 !

It looks like Guy Streeter gave you as good advice as I could give.
Be sure to read his post on linuxppc-embedded.

In the past there was an issue in that the VxWorks boot loader only
loaded .text and .data sections from ELF images.  At that time,
zImage files packed the "real" kernel image into an extra section
in the ELF file, and the VxWorks loader would not load it.  The fix
then was to hack the ELF header to make the extra section appear to
be part of the .data section.

Thankfully, I recall that later kernel versions did not have that
problem.  I think using a zImage (or zImage.initrd) file that has
been properly modified to support your board should be all that
is necessary.  Using a zImage is necessary because it includes a
"shim" that knows how to communicate critical information to the
actual Linux kernel.  The VxWorks boot loader does not provide this
information to Linux.

As someone else suggested, your best bet would be to use U-Boot or some
other loader that understands Linux.  U-Boot ports are fairly simple.
If you don't want to do one, you probably could convince me to do
a U-Boot port if you wanted to send me a board (and possibly some
reasonably compensation)... :-)

Good luck!

John
--=20
John W. Linville
linville@tuxdriver.com

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox