LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/7] powerpc: exports rheap symbol to modules
From: Sylvain Munaut @ 2007-09-16 10:53 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: Grant Likely, Sylvain Munaut, PowerPC dev list
In-Reply-To: <11899400103383-git-send-email-tnt@246tNt.com>

Theses can be useful in modules too. So we export them.

Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
 arch/powerpc/lib/rheap.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/lib/rheap.c b/arch/powerpc/lib/rheap.c
index ada5b42..22c3b4f 100644
--- a/arch/powerpc/lib/rheap.c
+++ b/arch/powerpc/lib/rheap.c
@@ -15,6 +15,7 @@
 #include <linux/types.h>
 #include <linux/errno.h>
 #include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/mm.h>
 #include <linux/err.h>
 #include <linux/slab.h>
@@ -275,6 +276,7 @@ rh_info_t *rh_create(unsigned int alignment)
 
 	return info;
 }
+EXPORT_SYMBOL_GPL(rh_create);
 
 /*
  * Destroy a dynamically created remote heap.  Deallocate only if the areas
@@ -288,6 +290,7 @@ void rh_destroy(rh_info_t * info)
 	if ((info->flags & RHIF_STATIC_INFO) == 0)
 		kfree(info);
 }
+EXPORT_SYMBOL_GPL(rh_destroy);
 
 /*
  * Initialize in place a remote heap info block.  This is needed to support
@@ -320,6 +323,7 @@ void rh_init(rh_info_t * info, unsigned int alignment, int max_blocks,
 	for (i = 0, blk = block; i < max_blocks; i++, blk++)
 		list_add(&blk->list, &info->empty_list);
 }
+EXPORT_SYMBOL_GPL(rh_init);
 
 /* Attach a free memory region, coalesces regions if adjuscent */
 int rh_attach_region(rh_info_t * info, unsigned long start, int size)
@@ -360,6 +364,7 @@ int rh_attach_region(rh_info_t * info, unsigned long start, int size)
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(rh_attach_region);
 
 /* Detatch given address range, splits free block if needed. */
 unsigned long rh_detach_region(rh_info_t * info, unsigned long start, int size)
@@ -428,6 +433,7 @@ unsigned long rh_detach_region(rh_info_t * info, unsigned long start, int size)
 
 	return s;
 }
+EXPORT_SYMBOL_GPL(rh_detach_region);
 
 /* Allocate a block of memory at the specified alignment.  The value returned
  * is an offset into the buffer initialized by rh_init(), or a negative number
@@ -502,6 +508,7 @@ unsigned long rh_alloc_align(rh_info_t * info, int size, int alignment, const ch
 
 	return start;
 }
+EXPORT_SYMBOL_GPL(rh_alloc_align);
 
 /* Allocate a block of memory at the default alignment.  The value returned is
  * an offset into the buffer initialized by rh_init(), or a negative number if
@@ -511,6 +518,7 @@ unsigned long rh_alloc(rh_info_t * info, int size, const char *owner)
 {
 	return rh_alloc_align(info, size, info->alignment, owner);
 }
+EXPORT_SYMBOL_GPL(rh_alloc);
 
 /* Allocate a block of memory at the given offset, rounded up to the default
  * alignment.  The value returned is an offset into the buffer initialized by
@@ -594,6 +602,7 @@ unsigned long rh_alloc_fixed(rh_info_t * info, unsigned long start, int size, co
 
 	return start;
 }
+EXPORT_SYMBOL_GPL(rh_alloc_fixed);
 
 /* Deallocate the memory previously allocated by one of the rh_alloc functions.
  * The return value is the size of the deallocated block, or a negative number
@@ -626,6 +635,7 @@ int rh_free(rh_info_t * info, unsigned long start)
 
 	return size;
 }
+EXPORT_SYMBOL_GPL(rh_free);
 
 int rh_get_stats(rh_info_t * info, int what, int max_stats, rh_stats_t * stats)
 {
@@ -663,6 +673,7 @@ int rh_get_stats(rh_info_t * info, int what, int max_stats, rh_stats_t * stats)
 
 	return nr;
 }
+EXPORT_SYMBOL_GPL(rh_get_stats);
 
 int rh_set_owner(rh_info_t * info, unsigned long start, const char *owner)
 {
@@ -687,6 +698,7 @@ int rh_set_owner(rh_info_t * info, unsigned long start, const char *owner)
 
 	return size;
 }
+EXPORT_SYMBOL_GPL(rh_set_owner);
 
 void rh_dump(rh_info_t * info)
 {
@@ -722,6 +734,7 @@ void rh_dump(rh_info_t * info)
 		       st[i].size, st[i].owner != NULL ? st[i].owner : "");
 	printk(KERN_INFO "\n");
 }
+EXPORT_SYMBOL_GPL(rh_dump);
 
 void rh_dump_blk(rh_info_t * info, rh_block_t * blk)
 {
@@ -729,3 +742,5 @@ void rh_dump_blk(rh_info_t * info, rh_block_t * blk)
 	       "blk @0x%p: 0x%lx-0x%lx (%u)\n",
 	       blk, blk->start, blk->start + blk->size, blk->size);
 }
+EXPORT_SYMBOL_GPL(rh_dump_blk);
+
-- 
1.5.3

^ permalink raw reply related

* [PATCH 0/7] MPC52xx Bestcomm submission for 2.6.24
From: Sylvain Munaut @ 2007-09-16 10:53 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: Grant Likely, PowerPC dev list

Hello Paul, Hi everyone,

This series of patch is mainly the bestcomm support for
the mpc5200. It was posted a while ago and received some
comments. Theses are all addressed here (afaik).

The first few patch are more a preparation for what
follows. (rheap module support & extended fields in psc
structure).

The rest is the core support followed by each specific
microcode support. (Previous emails explained the stucture
better, I'm not gonna repeat it here)

This particular version has been tested on the EFIKA and
works fine. Previous versions have been tested on a lot
of different platforms by numerous people. (and since the
changes since last version are cosmetic ...).

This series _doesn_t_ include any driver that actually make
use of bestcomm support. Hopefully theses will come. I
think Domen Puncer sent a cleaned up driver for ethernet.


        Sylvain

^ permalink raw reply

* Does gcc compiler support PowerPC 405 APU Instruction Set Extension?
From: Ming Liu @ 2007-09-16  9:32 UTC (permalink / raw)
  To: linuxppc-embedded

Dear all,
Is there anyone who knows, whether the cross-assember 
powerpc-405-linux-gnu-as can support and decode the instructions from the 
APU (auxiliary processing unit) extensive instruction set? For example the 
APU pre-defined instructions such as "ldfcmx" or "stdfcmx", and so on. 

If the answer is not, is that possible to modify the cross-compiler tool 
chain to make it support such a function? Any suggestion is appreciated. 
Thank you so much for your information. 

BR
Ming

_________________________________________________________________
免费下载 MSN Explorer:   http://explorer.msn.com/lccn  

^ permalink raw reply

* Re: [PATCH] i2c: devtree-aware iic support for PPC4xx
From: Stefan Roese @ 2007-09-16  9:08 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <20070915213617.817dd349.sfr@canb.auug.org.au>

On Saturday 15 September 2007, Stephen Rothwell wrote:
> [Just some trivial things]

Thanks for the feedback. I'll change those things and resubmit.

Best regads,
Stefan

^ permalink raw reply

* Re: [PATCH] i2c: devtree-aware iic support for PPC4xx
From: Stefan Roese @ 2007-09-16  9:07 UTC (permalink / raw)
  To: Vitaly Bordug; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <20070915152921.36ccbec7@localhost.localdomain>

On Saturday 15 September 2007, Vitaly Bordug wrote:
> > Where is dev->clkdiv initialized?
> >
> > My original version used iic_clkdiv() to calculate correct devider
> > based on OPB frequency. Did you even test this code?

Yes, I tested it successfully on the Sequoia eval board.

> heh, just my $0.02: the upper clearly shows one like missing, maybe during
> cleanup (since there is opb freq pulled in quote):
>
>         dev->clckdiv = iic_clckdiv(*prop); or smth like that

Could be. Thanks for the hint. I'll take a look at it an resubmit.

Best regards,
Stefan

^ permalink raw reply

* Re: Linux booting problem on Xilinx ppc
From: Junqiang Hu @ 2007-09-16  4:39 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <fa686aa40709152009k2b27ffc9kfb3fd0848f6b16d@mail.gmail.com>



Hi Grant,

   Thank you so much for the reply!  Fortunately I got it work now -- it's
the crosstool compiler problem.  Originally I was using gcc-4.1.0, yet when
compiling kernel 2.6.22, I noticed that it says gcc-4.1.0 will miscompile
the kernel, so I changed to another version, and now I can let it go!

  Right now still not fully booted because of the SystemACE problem, or
maybe the partition is not correct.  I'm still working on it, hopefully to
get it solved soon :-)

Thanks,
-J.


Grant Likely-2 wrote:
> 
> On 9/15/07, Junqiang Hu <jqhu936@yahoo.com> wrote:
>>
>>
>> Dear friends,
>>
>>    I'm trying to run Linux in AvNet (Memec) Xilinx-XC2VP50-EVKT-FF1152
>>  board.  The Linux version I'm using is 2.4; the cross-compiler is
>> gcc-4.1.0, glibc 2.3.6.  When booting the kernel, it shows:
>>       loaded at:     00400000 004B51E4
>>       board data at: 00000000 00000018
>>       relocated to:  0040526C 00405284
>>       zimage at:     00405B2B 004B177C
>>       avail ram:     004B6000 60000000
> 
> I strongly recommend moving to a 2.6 kernel.  Recent mainline has
> support for the Xilinx ppc built in.
>>
>>       Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part3 rw
>>       Uncompressing Linux...done.
>>       Now booting the kernel
>>
>> Then it hangs. First it seems to me that the "avail ram" is not correct,
>> since I configured only 32MB SDRAM.  Moreover, if it's first powered on,
>> the
>> end address of "avail ram" would be FFD9FBED. Then I tried to investigate
>> the problem using xmd.  When  launched, it says:
> 
> (If you're using u-boot) You might have a mismatch between the board
> info structure used by u-boot and the one used by Linux.
> 
> Also, you should use your debugger to inspect the __log_buf memory of
> the kernel.  A common problem is the kernel starts booting, but the
> console is setup incorrectly and so you see nothing.  But, you can
> read the console output directly from memory if you look at the
> __log_buf region (find the address in the System.map file; you might
> need to subtract 0xC0000000 from the address to view the memory)
> 
> Cheers,
> g.
> 
> -- 
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/Linux-booting-problem-on-Xilinx-ppc-tf4449060.html#a12696686
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

^ permalink raw reply

* Re: Linux booting problem on Xilinx ppc
From: Grant Likely @ 2007-09-16  3:09 UTC (permalink / raw)
  To: Junqiang Hu; +Cc: linuxppc-embedded
In-Reply-To: <12694083.post@talk.nabble.com>

On 9/15/07, Junqiang Hu <jqhu936@yahoo.com> wrote:
>
>
> Dear friends,
>
>    I'm trying to run Linux in AvNet (Memec) Xilinx-XC2VP50-EVKT-FF1152
>  board.  The Linux version I'm using is 2.4; the cross-compiler is
> gcc-4.1.0, glibc 2.3.6.  When booting the kernel, it shows:
>       loaded at:     00400000 004B51E4
>       board data at: 00000000 00000018
>       relocated to:  0040526C 00405284
>       zimage at:     00405B2B 004B177C
>       avail ram:     004B6000 60000000

I strongly recommend moving to a 2.6 kernel.  Recent mainline has
support for the Xilinx ppc built in.
>
>       Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part3 rw
>       Uncompressing Linux...done.
>       Now booting the kernel
>
> Then it hangs. First it seems to me that the "avail ram" is not correct,
> since I configured only 32MB SDRAM.  Moreover, if it's first powered on, the
> end address of "avail ram" would be FFD9FBED. Then I tried to investigate
> the problem using xmd.  When  launched, it says:

(If you're using u-boot) You might have a mismatch between the board
info structure used by u-boot and the one used by Linux.

Also, you should use your debugger to inspect the __log_buf memory of
the kernel.  A common problem is the kernel starts booting, but the
console is setup incorrectly and so you see nothing.  But, you can
read the console output directly from memory if you look at the
__log_buf region (find the address in the System.map file; you might
need to subtract 0xC0000000 from the address to view the memory)

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

^ permalink raw reply

* Re: [PATCH] ucc_geth: fix compilation
From: Jeff Garzik @ 2007-09-15 23:32 UTC (permalink / raw)
  To: Anton Vorontsov; +Cc: linuxppc-dev, netdev
In-Reply-To: <20070913152333.GA2381@localhost.localdomain>

Anton Vorontsov wrote:
> Currently qe_bd_t is used in the macro call -- dma_unmap_single,
> which is a no-op on PPC32, thus error is hidden today. Starting
> with 2.6.24, macro will be replaced by the empty static function,
> and erroneous use of qe_bd_t will trigger compilation error.
> 
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> 
> Reposting this to include netdev in Cc.
> 
>  drivers/net/ucc_geth.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

applied

^ permalink raw reply

* Re: Linux booting problem on Xilinx ppc
From: Junqiang Hu @ 2007-09-15 21:29 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <12694083.post@talk.nabble.com>



And I checked the xparameters_ml300.h for the possible problem yet not
found...


Junqiang Hu wrote:
> 
> 
> Dear friends,
> 
>    I'm trying to run Linux in AvNet (Memec) Xilinx-XC2VP50-EVKT-FF1152
>  board.  The Linux version I'm using is 2.4; the cross-compiler is
> gcc-4.1.0, glibc 2.3.6.  When booting the kernel, it shows:
>       loaded at:     00400000 004B51E4
>       board data at: 00000000 00000018
>       relocated to:  0040526C 00405284
>       zimage at:     00405B2B 004B177C
>       avail ram:     004B6000 60000000
> 
>       Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part3 rw
>       Uncompressing Linux...done.
>       Now booting the kernel
> 
> Then it hangs. First it seems to me that the "avail ram" is not correct,
> since I configured only 32MB SDRAM.  Moreover, if it's first powered on,
> the end address of "avail ram" would be FFD9FBED. Then I tried to
> investigate the problem using xmd.  When  launched, it says:
> 
>   Processor(s) in System ::
> 
>   PowerPC405(1) : ppc405_0
>   Address Map for Processor ppc405_0
>     (0x00000000-0x01ffffff) Infineon_Mobile_SDRAM_HYB25L128160AC_8plb
>     (0x40600000-0x4060ffff) RS232 plb->plb2opb->opb
>     (0x41200000-0x4120ffff) opb_intc_0    plb->plb2opb->opb
>     (0x41800000-0x4180ffff) SysACE_CompactFlash   plb->plb2opb->opb
>     (0x41c00000-0x41c0ffff) opb_timer_1   plb->plb2opb->opb
>     (0x80200000-0x8020ffff) RS232_1       plb
>     (0x80400000-0x8040ffff) Broadcom_BCM5221_Ethernet_Transceiver plb
>     (0xfffe0000-0xffffffff) plb_bram_if_cntlr_1   plb
> 
>   PowerPC405(2) : ppc405_1
>   Address Map for Processor ppc405_1
> 
>   Connecting to cable (Parallel Port - LPT1).
>   Checking cable driver.
>    Driver windrvr6.sys version = 7.0.0.0. LPT base address = 0378h.
>    ECP base address = 0778h.
>   Cable connection established.
>   INFO:MDT - Assumption: Selected Device 2 for debugging.
> 
>   JTAG chain configuration
>   --------------------------------------------------
>   Device   ID Code        IR Length    Part Name
>    1       0a001093           8        System_ACE
>    2       0129e093          14        XC2VP50
> 
>   XMD: Connected to PowerPC target. Processor Version No : 0x200108a0
>   Address mapping for accessing special PowerPC features from XMD/GDB:
>       I-Cache (Data)  :  Disabled
>       I-Cache (Tag)   :  Disabled
>       D-Cache (Data)  :  Disabled
>       D-Cache (Tag)   :  Disabled
>       ISOCM           :  Start Address  -  0xfffe0000, Size - 131072 bytes
>       TLB             :  Disabled
>       DCR             :  Disabled
>  
>   Connected to "ppc" target. id = 0
>   Starting GDB server for "ppc" target (id = 0) at TCP port no 1234
> 
> Then I download the Linux kernel using dow, and the following message
>  appears:
> 
>   WARNING: Attempted to read location: 0xfffffffc. Reading ISOCM memory
>  not supported
>         section, .text: 0x00400000-0x00404b6c
>         section, .data: 0x00405000-0x004b2000
>         section, .bss: 0x004b2000-0x004b51e4
>   Downloaded Program linux_kernel/zImage.elf
>   Setting PC with program start addr = 0x00400000
>   PC reset to 0x00400000, Clearing MSR Register
> 
> After typing "run" command, the following appears:
>     PC reset to 0x00400000, Clearing MSR Register
>     Processor started. Type "stop" to stop processor
> Then after issuing "stop", it says "unable to stop processor"
> 
> I also tried kernel version 2.6.22, but the same thing happens, except
> that the "avail ram" changed to 7C9E2378 and it's the same no matter first
> powered on or not.
> 
>   No idea how to continue...
> 
>   Could somebody give me some help? Thanks!
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Linux-booting-problem-on-Xilinx-ppc-tf4449060.html#a12694097
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

^ permalink raw reply

* Linux booting problem on Xilinx ppc
From: Junqiang Hu @ 2007-09-15 21:26 UTC (permalink / raw)
  To: linuxppc-embedded



Dear friends,

   I'm trying to run Linux in AvNet (Memec) Xilinx-XC2VP50-EVKT-FF1152
 board.  The Linux version I'm using is 2.4; the cross-compiler is
gcc-4.1.0, glibc 2.3.6.  When booting the kernel, it shows:
      loaded at:     00400000 004B51E4
      board data at: 00000000 00000018
      relocated to:  0040526C 00405284
      zimage at:     00405B2B 004B177C
      avail ram:     004B6000 60000000

      Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part3 rw
      Uncompressing Linux...done.
      Now booting the kernel

Then it hangs. First it seems to me that the "avail ram" is not correct,
since I configured only 32MB SDRAM.  Moreover, if it's first powered on, the
end address of "avail ram" would be FFD9FBED. Then I tried to investigate
the problem using xmd.  When  launched, it says:

  Processor(s) in System ::

  PowerPC405(1) : ppc405_0
  Address Map for Processor ppc405_0
    (0x00000000-0x01ffffff) Infineon_Mobile_SDRAM_HYB25L128160AC_8plb
    (0x40600000-0x4060ffff) RS232 plb->plb2opb->opb
    (0x41200000-0x4120ffff) opb_intc_0    plb->plb2opb->opb
    (0x41800000-0x4180ffff) SysACE_CompactFlash   plb->plb2opb->opb
    (0x41c00000-0x41c0ffff) opb_timer_1   plb->plb2opb->opb
    (0x80200000-0x8020ffff) RS232_1       plb
    (0x80400000-0x8040ffff) Broadcom_BCM5221_Ethernet_Transceiver plb
    (0xfffe0000-0xffffffff) plb_bram_if_cntlr_1   plb

  PowerPC405(2) : ppc405_1
  Address Map for Processor ppc405_1

  Connecting to cable (Parallel Port - LPT1).
  Checking cable driver.
   Driver windrvr6.sys version = 7.0.0.0. LPT base address = 0378h.
   ECP base address = 0778h.
  Cable connection established.
  INFO:MDT - Assumption: Selected Device 2 for debugging.

  JTAG chain configuration
  --------------------------------------------------
  Device   ID Code        IR Length    Part Name
   1       0a001093           8        System_ACE
   2       0129e093          14        XC2VP50

  XMD: Connected to PowerPC target. Processor Version No : 0x200108a0
  Address mapping for accessing special PowerPC features from XMD/GDB:
      I-Cache (Data)  :  Disabled
      I-Cache (Tag)   :  Disabled
      D-Cache (Data)  :  Disabled
      D-Cache (Tag)   :  Disabled
      ISOCM           :  Start Address  -  0xfffe0000, Size - 131072 bytes
      TLB             :  Disabled
      DCR             :  Disabled
 
  Connected to "ppc" target. id = 0
  Starting GDB server for "ppc" target (id = 0) at TCP port no 1234

Then I download the Linux kernel using dow, and the following message
 appears:

  WARNING: Attempted to read location: 0xfffffffc. Reading ISOCM memory
 not supported
        section, .text: 0x00400000-0x00404b6c
        section, .data: 0x00405000-0x004b2000
        section, .bss: 0x004b2000-0x004b51e4
  Downloaded Program linux_kernel/zImage.elf
  Setting PC with program start addr = 0x00400000
  PC reset to 0x00400000, Clearing MSR Register

After typing "run" command, the following appears:
    PC reset to 0x00400000, Clearing MSR Register
    Processor started. Type "stop" to stop processor
Then after issuing "stop", it says "unable to stop processor"

I also tried kernel version 2.6.22, but the same thing happens, except that
the "avail ram" changed to 7C9E2378 and it's the same no matter first
powered on or not.

  No idea how to continue...

  Could somebody give me some help? Thanks!


-- 
View this message in context: http://www.nabble.com/Linux-booting-problem-on-Xilinx-ppc-tf4449060.html#a12694083
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

^ permalink raw reply

* make menuconfig problem
From: jqhu @ 2007-09-15 20:14 UTC (permalink / raw)
  To: linuxppc-embedded


I'm compiling kernel 2.6.22 downloaded from kernel.org.  When running "make
menuconfig", it says:
  scripts/kconfig/conf arch/ppc/Kconfig
  #
  # using defaults found in /boot/config-2.6.3-7mdksmp
  #

So by default it's using the config file in /boot directory, which is not
correct.
  
I checked the source directory and notice that there's no .config file
present.  Could anybody tell me what I should do on this?

Thanks!
-- 
View this message in context: http://www.nabble.com/make-menuconfig-problem-tf4448774.html#a12693399
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

^ permalink raw reply

* Re: [patch 3/4] 4xx: Convert Walnut flash mappings to new binding
From: Segher Boessenkool @ 2007-09-15 19:20 UTC (permalink / raw)
  To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese, david
In-Reply-To: <1189877748.17593.9.camel@localhost.localdomain>

>> Maybe we can have  U-Boot  add  the  partition  information  if  it's
>> missing in the device tree, and extend the mtdparts command in U-Boot
>> to add / adjust settings so they match what is defined in U-Boot.
>
> That would be great for newer U-Boots.  For existing older ones, it
> doesn't really solve the problem.  But then again, there's no way to
> possibly define all the partitioning schemes people may have adopted to
> their needs on their boards.  And I believe that is why David has
> RedBoot and command line partitioning override what is in the DTS 
> today.

Yeah, partitioning information really doesn't belong in the device
tree -- with the possible exception of the partitions that the
firmware (uboot in this case) needs to know about anyway.

You *can* put all partitioning info in the device tree, but that
doesn't mean you *should* :-)


Segher

^ permalink raw reply

* Re: [patch 3/4] 4xx: Convert Walnut flash mappings to new binding
From: Josh Boyer @ 2007-09-15 17:35 UTC (permalink / raw)
  To: Wolfgang Denk; +Cc: linuxppc-dev, Stefan Roese, david
In-Reply-To: <20070915150901.AC712247CE@gemini.denx.de>

On Sat, 2007-09-15 at 17:09 +0200, Wolfgang Denk wrote:
> In message <1189866379.17593.2.camel@localhost.localdomain> Josh Boyer wrote:
> > On Sat, 2007-09-15 at 05:23 +0200, Stefan Roese wrote:
> ...
> > > There are not only Bamboo board running PIBS, but running U-Boot too. How 
> > > should we handle this different FLASH partitioning? Same goes for Ebony too 
> > > btw.
> > 
> > That's a good question.  I'm working on making the NOR flash show up for
> > Bamboo right now, and I had intended to just leave the partition
> > subnodes missing.
> 
> Maybe we can have  U-Boot  add  the  partition  information  if  it's
> missing in the device tree, and extend the mtdparts command in U-Boot
> to add / adjust settings so they match what is defined in U-Boot.

That would be great for newer U-Boots.  For existing older ones, it
doesn't really solve the problem.  But then again, there's no way to
possibly define all the partitioning schemes people may have adopted to
their needs on their boards.  And I believe that is why David has
RedBoot and command line partitioning override what is in the DTS today.

josh

^ permalink raw reply

* Re: Domen's MPC5200 FEC cleanup patch.
From: Jon Smirl @ 2007-09-15 15:55 UTC (permalink / raw)
  To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <20070915122218.GB19857@nd47.coderock.org>

On 9/15/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> On 15/09/07 00:28 -0400, Jon Smirl wrote:
> > On 9/14/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > This patch doesn't seem to working quite right on my hardware (Phytec
> > > pcm030). At boot I get a long pause.
> >
> > It also doesn't compile if  CONFIG_FEC_MPC52xx_MDIO is undefined.
>
> Right, darn.
> Try this one: http://coderock.org/tmp/fec-v3rc1/

    0.776407] 0x00f40000-0x00f80000 : "oftree"
[    0.782101] 0x00f80000-0x01000000 : "space"
[    0.788100] TCP cubic registered
[    0.791427] NET: Registered protocol family 1
[    0.795904] NET: Registered protocol family 17
[    1.305579] f0003000:00 not found
[    1.308985] net eth0: phy_connect failed
[    1.312961] net eth0: fec_init_phy failed
[    1.317188] IP-Config: Failed to open eth0
[    1.321362] IP-Config: No network devices available.
[    1.326973] Looking up port of RPC 100003/3 on 192.168.1.4



>
> Does it work without phy-handle in device tree, but
> with this part being unconditional (fec.c):
>  709 //        if (priv->has_phy)
>  710                 rcntrl |= FEC_RCNTRL_MII_MODE;
>
> This effectively disables phy part of the driver,
> but still allows hardware to use PHY/MII.

Makes no difference

>
> I am puzzled by the symptoms you see.
>
>
>         Domen
>
> >
> > --
> > Jon Smirl
> > jonsmirl@gmail.com
>


-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: [patch 3/4] 4xx: Convert Walnut flash mappings to new binding
From: Wolfgang Denk @ 2007-09-15 15:09 UTC (permalink / raw)
  To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese, david
In-Reply-To: <1189866379.17593.2.camel@localhost.localdomain>

In message <1189866379.17593.2.camel@localhost.localdomain> Josh Boyer wrote:
> On Sat, 2007-09-15 at 05:23 +0200, Stefan Roese wrote:
...
> > There are not only Bamboo board running PIBS, but running U-Boot too. How 
> > should we handle this different FLASH partitioning? Same goes for Ebony too 
> > btw.
> 
> That's a good question.  I'm working on making the NOR flash show up for
> Bamboo right now, and I had intended to just leave the partition
> subnodes missing.

Maybe we can have  U-Boot  add  the  partition  information  if  it's
missing in the device tree, and extend the mtdparts command in U-Boot
to add / adjust settings so they match what is defined in U-Boot.

Stefan, what do you think?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Without facts, the decision cannot be made logically. You  must  rely
on your human intuition.
	-- Spock, "Assignment: Earth", stardate unknown

^ permalink raw reply

* Re: PPC4xx maintainer?
From: Josh Boyer @ 2007-09-15 14:27 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18155.24590.33276.113415@cargo.ozlabs.ibm.com>

On Sat, 2007-09-15 at 14:31 +1000, Paul Mackerras wrote:
> Stefan Roese writes:
> 
> > I really think that now, as the PPC4xx Linux development is picking up in 
> > speed in the ongoing move to arch/powerpc, we need an "active" maintainer for 
> > the 4xx Linux kernel platform. Since I haven't heard anything from Matt in a 
> > long time, perhaps it would be better if somebody else takes care of this 
> > matter. I propose that Josh Boyer takes over this maintainership, and I know 
> > that he is competent enough and willing to dedicate the needed time for this 
> > task.
> 
> Glad you think so. :)  I asked Josh to be the 4xx maintainer a couple of
> weeks ago but didn't make an announcement about it, which I should
> have done - sorry about that.
> 
> Josh, please send me a patch for MAINTAINERS.

Will do.  Thanks everyone :).

josh

^ permalink raw reply

* Re: [patch 1/4] cuimage for Bamboo board
From: Josh Boyer @ 2007-09-15 14:26 UTC (permalink / raw)
  To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070915021952.GD25414@localhost.localdomain>

On Sat, 2007-09-15 at 12:19 +1000, David Gibson wrote:
> On Fri, Sep 14, 2007 at 01:54:11PM -0500, Josh Boyer wrote:
> > Add a cuboot wrapper for the Bamboo board.  This also removes some obsoleted
> > linker declarations that have been moved into ops.h
> > 
> > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > Acked-by: David Gibson <david@gibson.dropbear.id.au>
> 
> Heh, well, I know I acked this already, but...

:)

> 
> [snip]
> > --- /dev/null
> > +++ linux-2.6/arch/powerpc/boot/cuboot-bamboo.c
> > @@ -0,0 +1,30 @@
> > +/*
> > + * Old U-boot compatibility for Ebony
> 
> Error in the comment here.

Fixed.

> 
> [snip]
> > --- linux-2.6.orig/arch/powerpc/boot/bamboo.c
> > +++ linux-2.6/arch/powerpc/boot/bamboo.c
> > @@ -24,8 +24,7 @@
> >  #include "4xx.h"
> >  #include "44x.h"
> >  
> > -extern char _dtb_start[];
> > -extern char _dtb_end[];
> > +static u8 *bamboo_mac0, *bamboo_mac1;
> 
> This additional handling of the MAC addresses should really also be
> mentioned in the commit comment.

Quite right.  I'll revise the commit comment.

josh

^ permalink raw reply

* Re: [patch 3/4] 4xx: Convert Walnut flash mappings to new binding
From: Josh Boyer @ 2007-09-15 14:26 UTC (permalink / raw)
  To: Stefan Roese; +Cc: linuxppc-dev, david
In-Reply-To: <200709150523.12817.sr@denx.de>

On Sat, 2007-09-15 at 05:23 +0200, Stefan Roese wrote:
> On Friday 14 September 2007, Josh Boyer wrote:
> > A new binding for flash devices was recently introduced.  This updates the
> > Walnut DTS to use the new binding.
> >
> > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > ---
> >  arch/powerpc/boot/dts/walnut.dts |   17 ++++++++++++-----
> >  1 file changed, 12 insertions(+), 5 deletions(-)
> >
> > --- linux-2.6.orig/arch/powerpc/boot/dts/walnut.dts
> > +++ linux-2.6/arch/powerpc/boot/dts/walnut.dts
> > @@ -137,6 +137,10 @@
> >  			dcr-reg = <012 2>;
> >  			#address-cells = <2>;
> >  			#size-cells = <1>;
> > +			/* The ranges property is supplied by the bootwrapper
> > +			 * and is based on the firmware's configuration of the
> > +			 * EBC bridge
> > +			 */
> >  			clock-frequency = <0>; /* Filled in by zImage */
> >
> >  			sram@0,0 {
> > @@ -144,13 +148,16 @@
> >  			};
> >
> >  			flash@0,80000 {
> > -				device_type = "rom";
> > -				compatible = "direct-mapped";
> > -				probe-type = "JEDEC";
> > +				compatible = "jedec-flash";
> >  				bank-width = <1>;
> > -				partitions = <0 80000>;
> > -				partition-names = "OpenBIOS";
> >  				reg = <0 80000 80000>;
> > +				#address-cells = <1>;
> > +				#size-cells = <1>;
> > +				partition@0 {
> > +					label = "OpenBIOS";
> > +					reg = <0 80000>;
> > +					read-only;
> > +				};
> 
> There are not only Bamboo board running PIBS, but running U-Boot too. How 
> should we handle this different FLASH partitioning? Same goes for Ebony too 
> btw.

That's a good question.  I'm working on making the NOR flash show up for
Bamboo right now, and I had intended to just leave the partition
subnodes missing.

josh

^ permalink raw reply

* Re: [patch 3/4] 4xx: Convert Walnut flash mappings to new binding
From: Josh Boyer @ 2007-09-15 14:25 UTC (permalink / raw)
  To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070915022228.GF25414@localhost.localdomain>

On Sat, 2007-09-15 at 12:22 +1000, David Gibson wrote:
> On Fri, Sep 14, 2007 at 01:54:13PM -0500, Josh Boyer wrote:
> > A new binding for flash devices was recently introduced.  This updates the
> > Walnut DTS to use the new binding.
> > 
> > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> Acked-by: David Gibson <david@gibson.dropbear.id.au>
> 
> We should both really figure out the vendor/device ids of the JEDEC
> flash chips in use here and on Ebony, and add the appropriate
> properties as per the binding.

Yeah, I'll do that soon.

josh

^ permalink raw reply

* [PATCH] [PPC] Compile fix for 8xx CPM Ehernet driver
From: Jochen Friedrich @ 2007-09-15 14:05 UTC (permalink / raw)
  To: linuxppc-embedded

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


Add #include <asm/cacheflush.h> for flush_dcache_range
to make the driver compile again.

  CC      arch/ppc/8xx_io/enet.o
arch/ppc/8xx_io/enet.c: In function 'scc_enet_start_xmit':
arch/ppc/8xx_io/enet.c:240: error: implicit declaration of function
'flush_dcache_range'
make[1]: *** [arch/ppc/8xx_io/enet.o] Error 1
make: *** [arch/ppc/8xx_io] Error 2

Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
 arch/ppc/8xx_io/enet.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

[-- Attachment #2: bc5766a0a6e25ccdf6bc1068960cf197ebe5acf5.diff --]
[-- Type: text/x-patch, Size: 308 bytes --]

diff --git a/arch/ppc/8xx_io/enet.c b/arch/ppc/8xx_io/enet.c
index 703d47e..eace3bc 100644
--- a/arch/ppc/8xx_io/enet.c
+++ b/arch/ppc/8xx_io/enet.c
@@ -44,6 +44,7 @@
 #include <asm/mpc8xx.h>
 #include <asm/uaccess.h>
 #include <asm/commproc.h>
+#include <asm/cacheflush.h>
 
 /*
  *				Theory of Operation


^ permalink raw reply related

* Re: SPI INT line
From: Clemens Koller @ 2007-09-15 13:42 UTC (permalink / raw)
  To: Nicholas Hickman; +Cc: linuxppc-embedded
In-Reply-To: <8140AAF341CC904BA92C3D6A5A1909782F0E9D@ditech-1.ditechllc.com>

Nicholas Hickman schrieb:
> We are developing a system around the mpc8270.  On this system we are
> using an ISDN controller connected to the SPI interface of the 8270.
> For the INT line coming from the controller, should this be connected to
> one of the IRQ lines that we typically use for PCI bus, or should we
> connect it to one of the GPIO Group C pins?  Currently we have it to
> IRQ4, but I am worried that this is incorrect.

I would use an otherwise unused (even in reference 82xx platforms)
IRQ line and have a look into the kernel and see which
IRQs are free so minimize/eliminate extra patches.

Regards,
-- 
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm-technology.com
Phone: +49-89-741518-50
Fax: +49-89-741518-19

^ permalink raw reply

* Re: [PATCH] add Kconfig option for optimizing for cell
From: Arnd Bergmann @ 2007-09-15 13:30 UTC (permalink / raw)
  To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1189862035.3742.5.camel@shinybook.infradead.org>

On Saturday 15 September 2007, David Woodhouse wrote:
> On Sat, 2007-09-15 at 02:21 +0200, Arnd Bergmann wrote:
> > Since the PPE on cell is an in-order core, it suffers significantly
> > from wrong instruction scheduling. This adds an Kconfig option that
> > enables passing -mtune=cell to gcc in order to generate object
> > code that runs well on cell.
> 
> Do we have an option which is useful for a multiplatform kernel (and for
> userspace) and which lies between the two extremes? Something which will
> improve performance on Cell (and POWER6?) without sucking too hard
> elsewhere?

No, not really. The impact of -mtune=cell should not be too bad on other
out-of-order CPUs, but we don't have any good measurements to back that
up, and it may also be really bad for POWER6 and other in-order cores.

	Arnd <><

^ permalink raw reply

* Re: [PATCH] add Kconfig option for optimizing for cell
From: David Woodhouse @ 2007-09-15 13:13 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200709150221.57825.arnd@arndb.de>

On Sat, 2007-09-15 at 02:21 +0200, Arnd Bergmann wrote:
> Since the PPE on cell is an in-order core, it suffers significantly
> from wrong instruction scheduling. This adds an Kconfig option that
> enables passing -mtune=cell to gcc in order to generate object
> code that runs well on cell.

Do we have an option which is useful for a multiplatform kernel (and for
userspace) and which lies between the two extremes? Something which will
improve performance on Cell (and POWER6?) without sucking too hard
elsewhere?

-- 
dwmw2

^ permalink raw reply

* Re: Domen's MPC5200 FEC cleanup patch.
From: Domen Puncer @ 2007-09-15 12:22 UTC (permalink / raw)
  To: Jon Smirl; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910709142128l7a264a05ve68f59aee92b40e3@mail.gmail.com>

On 15/09/07 00:28 -0400, Jon Smirl wrote:
> On 9/14/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > This patch doesn't seem to working quite right on my hardware (Phytec
> > pcm030). At boot I get a long pause.
> 
> It also doesn't compile if  CONFIG_FEC_MPC52xx_MDIO is undefined.

Right, darn.
Try this one: http://coderock.org/tmp/fec-v3rc1/

Does it work without phy-handle in device tree, but
with this part being unconditional (fec.c):
 709 //        if (priv->has_phy)
 710                 rcntrl |= FEC_RCNTRL_MII_MODE;

This effectively disables phy part of the driver,
but still allows hardware to use PHY/MII.

I am puzzled by the symptoms you see.


	Domen

> 
> -- 
> Jon Smirl
> jonsmirl@gmail.com

^ permalink raw reply

* Re: [RFC PATCH v0.2] net driver: mpc52xx fec
From: Domen Puncer @ 2007-09-15 12:14 UTC (permalink / raw)
  To: Grant Likely; +Cc: netdev, linuxppc-embedded
In-Reply-To: <fa686aa40709030857j6c36c87ek60215f812864ee0f@mail.gmail.com>

On 03/09/07 09:57 -0600, Grant Likely wrote:
> On 9/2/07, Domen Puncer <domen@coderock.org> wrote:
> > Hi!
> >
> > new in this version:
> > - fixed stuff that was commented on.
> > - added 7-wire support (compile at least, if someone has the hardware,
> >         please test!)
> > - ethtool support
> 
> Thanks for this work Domen, comments below...

Thanks for reviewing and sorry for not replying sooner, I lost the
mail.

> 
> This is a large patch, and it should be broken up into logical
> changes.  ie. split into dts changes, bestcomm changes, fec driver and
> mdio driver.  Easier to review that way.  The bestcomm and dts changes
> don't need to go to the netdev list.

OK.

> > +config FEC_MPC52xx
> > +       tristate "FEC Ethernet"
> > +       depends on NET_ETHERNET
> > +       select PPC_BESTCOMM
> > +       select PPC_BESTCOMM_FEC
> > +       select CRC32
> > +       ---help---
> > +         This option enables support for the MPC5200's on-chip
> > +         Fast Ethernet Controller
> > +
> > +config FEC_MPC52xx_MDIO
> > +       bool "Use external Ethernet MII PHY"
> > +       depends on FEC_MPC52xx
> > +       select PHYLIB
> > +       default y
> > +       ---help---
> > +         The MPC5200's FEC can connect to the Ethernet either with
> > +         an external MII PHY chip or 10 Mbps 7-wire interface
> > +         (Motorola? industry standard).
> > +         If your board uses an external PHY, say y, else n.
> 
> This option should change.  Either build the MDIO driver into the FEC
> driver unconditionally and drop this option, or make the MDIO driver
> independent from the FEC driver (it does use the MDIO bus
> infrastructure after all).  Either way the FEC driver should detect
> the phy type at runtime (possibly based on the presence/absence of a
> phy-handle property) instead of being hard compiled.  5200 support is
> now multiplatform after all.
> 
> If you drop the MDIO config option, then I'd also consider eliminating
> driver/net/fec_mpc52xx/Kconfig entirely and rolling the single
> MPC52xx_FEC option into drivers/net/Kconfig.

Right. I separated it.

> > +static irqreturn_t fec_interrupt(int, void *);
> > +static irqreturn_t fec_rx_interrupt(int, void *);
> > +static irqreturn_t fec_tx_interrupt(int, void *);
> > +static struct net_device_stats *fec_get_stats(struct net_device *);
> > +static void fec_set_multicast_list(struct net_device *dev);
> > +static void fec_hw_init(struct net_device *dev);
> > +static void fec_stop(struct net_device *dev);
> > +static void fec_start(struct net_device *dev);
> > +static void fec_reset(struct net_device *dev);
> 
> Nit: Are all these forward decls needed?

Some aren't - cleaned.

> 
> > +
> > +static u8 mpc52xx_fec_mac_addr[6];
> 
> Why isn't this part of struct fec_priv?

Because at __setup time, there's no fec_priv instance.
OTOH, does anyone even use mpc52xx-mac=?

> 
> > +static const u8 null_mac[6];
> 
> null_mac?!?  Just for comparing a mac addr against 0?

right, is_zero_ether_addr is the right thing.

> 
> <snip>
> 
> > +#ifdef CONFIG_FEC_MPC52xx_MDIO
> 
> Once again; don't make this a conditional compile; detect at runtime.
> 
> <snip>
> 
> > +static void __init fec_str2mac(char *str, unsigned char *mac)
> > +{
> > +       int i;
> > +       u64 val64;
> > +
> > +       val64 = simple_strtoull(str, NULL, 16);
> > +
> > +       for (i = 0; i < 6; i++)
> > +               mac[5-i] = val64 >> (i*8);
> > +}
> > +
> > +static int __init mpc52xx_fec_mac_setup(char *mac_address)
> > +{
> > +       fec_str2mac(mac_address, mpc52xx_fec_mac_addr);
> > +       return 0;
> > +}
> 
> fec_str2mac is called in *1* place.  I'd roll it into mpc52xx_fec_mac_setup.
> 
> > +
> > +__setup("mpc52xx-mac=", mpc52xx_fec_mac_setup);
> > +
> 

OK.

Updated and split version at:
http://coderock.org/tmp/fec-v3rc1/

I'll repost to lists once I run-test them.


	Domen

> 
> 
> -- 
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

^ 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