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

* 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: 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

* [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: 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

* 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 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

* 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: 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

* 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

* 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

* 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

* 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

* 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

* 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

* 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

* [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: 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


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