Re: Long boot delay on 460EX with 2.6.28-rc8
Stefan Roese wrote:
Is this an expected behavior - detection of 256 MiB NAND flash
takes around 20 seconds. The ndfc driver works fine after boot.
No, 20 seconds is definitely too long. Something must be wrong with the
ndfc
driver or the NAND dts entries.
Best regards,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Thanks, Stefan
My ndfc DTS entry looks like this
n...@3,0 {
compatible = amcc,ndfc;
reg = 0x0003 0x 0x2000;
ccr = 0x1000;
bank-settings = 0x8000;
#address-cells = 1;
#size-cells = 1;
partit...@0 {
label = data;
reg = 0x 0x1000;
};
};
I also had to modify u-boot to provide ndfc ebc mappings.
Not sure if it's the best solution, but it worked. Sorry for
posting u-boot stuff here, I'll stop doing that if list thinks
it's irrelevant.
My u-boot code looks like this (modified canyonlands code):
void ft_board_setup(void *blob, bd_t *bd)
{
u32 val[8];
int rc;
ft_cpu_setup(blob, bd);
/* Fixup NOR mapping */
val[0] = 0; /* chip select number */
val[1] = 0; /* always 0 */
val[2] = CFG_FLASH_BASE_PHYS_L; /* we fixed up this address
*/
val[3] = gd-bd-bi_flashsize;
/* Set NAND Controller mapping */
val[4] = CFG_NAND_CS; /* chip select number */
val[5] = 0; /* always 0 */
val[6] = CFG_NAND_ADDR; /* NAND address */
val[7] = 0x2000; /* NAND register area
size */
rc = fdt_find_and_setprop(blob, /plb/opb/ebc, ranges,
val, sizeof(val), 1);
if (rc) {
printf(Unable to update property NOR mapping, err=%s\n,
fdt_strerror(rc));
}
}
Felix.
--
View this message in context:
http://www.nabble.com/Long-boot-delay-on-460EX-with-2.6.28-rc8-tp21070179p21087540.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Long boot delay on 460EX with 2.6.28-rc8
Stefan Roese wrote:
Is this an expected behavior - detection of 256 MiB NAND flash
takes around 20 seconds. The ndfc driver works fine after boot.
No, 20 seconds is definitely too long. Something must be wrong with the
ndfc
driver or the NAND dts entries.
Best regards,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Thanks, Stefan
My ndfc DTS entry looks like this
n...@3,0 {
compatible = amcc,ndfc;
reg = 0x0003 0x 0x2000;
ccr = 0x1000;
bank-settings = 0x8000;
#address-cells = 1;
#size-cells = 1;
partit...@0 {
label = data;
reg = 0x 0x1000;
};
};
I also had to modify u-boot to provide ndfc ebc mappings.
Not sure if it's the best solution, but it worked. Sorry for
posting u-boot stuff here, I'll stop doing that if list thinks
it's irrelevant.
My u-boot code looks like this (modified canyonlands code):
void ft_board_setup(void *blob, bd_t *bd)
{
u32 val[8];
int rc;
ft_cpu_setup(blob, bd);
/* Fixup NOR mapping */
val[0] = 0; /* chip select number */
val[1] = 0; /* always 0 */
val[2] = CFG_FLASH_BASE_PHYS_L; /* we fixed up this address
*/
val[3] = gd-bd-bi_flashsize;
/* Set NAND Controller mapping */
val[4] = CFG_NAND_CS; /* chip select number */
val[5] = 0; /* always 0 */
val[6] = CFG_NAND_ADDR; /* NAND address */
val[7] = 0x2000; /* NAND register area
size */
rc = fdt_find_and_setprop(blob, /plb/opb/ebc, ranges,
val, sizeof(val), 1);
if (rc) {
printf(Unable to update property NOR mapping, err=%s\n,
fdt_strerror(rc));
}
}
Felix.
--
View this message in context:
http://www.nabble.com/Long-boot-delay-on-460EX-with-2.6.28-rc8-tp21070179p21087541.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/10] powerpc/4xx: Extended DCR support v2
On Fri, Dec 19, 2008 at 04:13:22PM +1100, Benjamin Herrenschmidt wrote:
This adds supports to the extended DCR addressing via
the indirect mfdcrx/mtdcrx instructions supported by some
4xx cores (440H6 and later)
I enabled the feature for now only on AMCC 460 chips
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Acked-by: Josh Boyer jwbo...@linux.vnet.ibm.com
In general, if you just carry over my previous Acks it'll make life
easier ;)
josh
---
This variant uses 440x6 instead of 440H6. I made no other
changes to the code as I think the codegen is the less bad I've
had so far and I rely on Josh further work on cleaning up the
type of 440core selection at Kconfig time so the feature are
properly reflected in the POSSIBLE and ALWAYS masks based on
the core selection. That way, if only one core type is selected
the feature test should resolve at compile time.
arch/powerpc/include/asm/cputable.h |7 ++-
arch/powerpc/include/asm/dcr-native.h | 63
+++---
arch/powerpc/kernel/cputable.c|4 +-
arch/powerpc/sysdev/dcr-low.S |8 +++-
4 files changed, 65 insertions(+), 17 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/cputable.h2008-12-17
12:28:23.0 +1100
+++ linux-work/arch/powerpc/include/asm/cputable.h 2008-12-17
12:30:52.0 +1100
@@ -164,6 +164,7 @@ extern const char *powerpc_base_platform
#define CPU_FTR_NEED_PAIRED_STWCX ASM_CONST(0x0400)
#define CPU_FTR_LWSYNCASM_CONST(0x0800)
#define CPU_FTR_NOEXECUTE ASM_CONST(0x1000)
+#define CPU_FTR_INDEXED_DCR ASM_CONST(0x2000)
/*
* Add the 64-bit processor unique features in the top half of the word;
@@ -369,6 +370,8 @@ extern const char *powerpc_base_platform
#define CPU_FTRS_8XX (CPU_FTR_USE_TB)
#define CPU_FTRS_40X (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN |
CPU_FTR_NOEXECUTE)
#define CPU_FTRS_44X (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN |
CPU_FTR_NOEXECUTE)
+#define CPU_FTRS_440x6(CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN |
CPU_FTR_NOEXECUTE | \
+ CPU_FTR_INDEXED_DCR)
#define CPU_FTRS_E200 (CPU_FTR_USE_TB | CPU_FTR_SPE_COMP | \
CPU_FTR_NODSISRALIGN | CPU_FTR_COHERENT_ICACHE | \
CPU_FTR_UNIFIED_ID_CACHE | CPU_FTR_NOEXECUTE)
@@ -455,7 +458,7 @@ enum {
CPU_FTRS_40X |
#endif
#ifdef CONFIG_44x
- CPU_FTRS_44X |
+ CPU_FTRS_44X | CPU_FTRS_440x6 |
#endif
#ifdef CONFIG_E200
CPU_FTRS_E200 |
@@ -495,7 +498,7 @@ enum {
CPU_FTRS_40X
#endif
#ifdef CONFIG_44x
- CPU_FTRS_44X
+ CPU_FTRS_44X CPU_FTRS_440x6
#endif
#ifdef CONFIG_E200
CPU_FTRS_E200
Index: linux-work/arch/powerpc/include/asm/dcr-native.h
===
--- linux-work.orig/arch/powerpc/include/asm/dcr-native.h 2008-09-29
14:21:37.0 +1000
+++ linux-work/arch/powerpc/include/asm/dcr-native.h 2008-12-17
12:30:52.0 +1100
@@ -23,6 +23,7 @@
#ifndef __ASSEMBLY__
#include linux/spinlock.h
+#include asm/cputable.h
typedef struct {
unsigned int base;
@@ -39,23 +40,45 @@ static inline bool dcr_map_ok_native(dcr
#define dcr_read_native(host, dcr_n) mfdcr(dcr_n + host.base)
#define dcr_write_native(host, dcr_n, value) mtdcr(dcr_n + host.base, value)
-/* Device Control Registers */
-void __mtdcr(int reg, unsigned int val);
-unsigned int __mfdcr(int reg);
+/* Table based DCR accessors */
+extern void __mtdcr(unsigned int reg, unsigned int val);
+extern unsigned int __mfdcr(unsigned int reg);
+
+/* mfdcrx/mtdcrx instruction based accessors. We hand code
+ * the opcodes in order not to depend on newer binutils
+ */
+static inline unsigned int mfdcrx(unsigned int reg)
+{
+ unsigned int ret;
+ asm volatile(.long 0x7c000206 | (%0 21) | (%1 16)
+ : =r (ret) : r (reg));
+ return ret;
+}
+
+static inline void mtdcrx(unsigned int reg, unsigned int val)
+{
+ asm volatile(.long 0x7c000306 | (%0 21) | (%1 16)
+ : : r (val), r (reg));
+}
+
#define mfdcr(rn) \
({unsigned int rval;\
- if (__builtin_constant_p(rn)) \
+ if (__builtin_constant_p(rn) rn 1024) \
asm volatile(mfdcr %0, __stringify(rn)\
: =r (rval)); \
+ else if (likely(cpu_has_feature(CPU_FTR_INDEXED_DCR))) \
+ rval = mfdcrx(rn); \
else\
rval = __mfdcr(rn); \
rval;})
#define mtdcr(rn, v) \
do { \
- if
Re: [PATCH 7/10] powerpc/44x: No need to mask MSR:CE,ME or DE in _tlbil_va on 440
On Fri, Dec 19, 2008 at 04:13:46PM +1100, Benjamin Herrenschmidt wrote: The handlers for Critical, Machine Check or Debug interrupts will save and restore MMUCR nowadays, thus we only need to disable normal interrupts when invalidating TLB entries. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org Acked-by: Josh Boyer jwbo...@linux.vnet.ibm.com --- arch/powerpc/mm/tlb_nohash_low.S | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) --- linux-work.orig/arch/powerpc/mm/tlb_nohash_low.S 2008-12-15 13:34:57.0 +1100 +++ linux-work/arch/powerpc/mm/tlb_nohash_low.S2008-12-15 13:35:07.0 +1100 @@ -75,18 +75,19 @@ _GLOBAL(_tlbil_va) mfspr r5,SPRN_MMUCR rlwimi r5,r4,0,24,31 /* Set TID */ - /* We have to run the search with interrupts disabled, even critical - * and debug interrupts (in fact the only critical exceptions we have - * are debug and machine check). Otherwise an interrupt which causes - * a TLB miss can clobber the MMUCR between the mtspr and the tlbsx. */ + /* We have to run the search with interrupts disabled, otherwise + * an interrupt which causes a TLB miss can clobber the MMUCR + * between the mtspr and the tlbsx. + * + * Critical and Machine Check interrupts take care of saving + * and restoring MMUCR, so only normal interrupts have to be + * taken care of. + */ mfmsr r4 - lis r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@ha - addir6,r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@l - andcr6,r4,r6 - mtmsr r6 + wrteei 0 mtspr SPRN_MMUCR,r5 tlbsx. r3, 0, r3 - mtmsr r4 + wrtee r4 bne 1f sync /* There are only 64 TLB entries, so r3 64, ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 10/10] powerpc/44x: 44x TLB doesn't need Guarded set for all pages
On Fri, Dec 19, 2008 at 04:13:54PM +1100, Benjamin Herrenschmidt wrote: After discussing with chip designers, it appears that it's not necessary to set G everywhere on 440 cores. The various core errata related to prefetch should be sorted out by firmware by disabling icache prefetching in CCR0. We add the workaround to the kernel however just in case ld firmwares don't do it. This is valid for -all- 4xx core variants. Later ones hard wire the absence of prefetch but it doesn't harm to clear the bits in CCR0 (they should already be cleared anyway). We still leave G=1 on the linear mapping for now, we need to stop over-mapping RAM to be able to remove it. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org I've been testing this for the past couple of days and it has been working generally well on large process and heavy threaded workloads. I'd like to get better testcases, but that's an on-going need so: Acked-by: Josh Boyer jwbo...@linux.vnet.ibm.com --- arch/powerpc/kernel/head_44x.S | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) --- linux-work.orig/arch/powerpc/kernel/head_44x.S 2008-12-10 16:11:35.0 +1100 +++ linux-work/arch/powerpc/kernel/head_44x.S 2008-12-10 16:29:08.0 +1100 @@ -69,6 +69,17 @@ _ENTRY(_start); li r24,0 /* CPU number */ /* + * In case the firmware didn't do it, we apply some workarounds + * that are good for all 440 core variants here + */ + mfspr r3,SPRN_CCR0 + rlwinm r3,r3,0,0,27/* disable icache prefetch */ + isync + mtspr SPRN_CCR0,r3 + isync + sync + +/* * Set up the initial MMU state * * We are still executing code at the virtual address @@ -570,7 +581,6 @@ finish_tlb_load: rlwimi r10,r12,29,30,30/* DIRTY - SW position */ and r11,r12,r10 /* Mask PTE bits to keep */ andi. r10,r12,_PAGE_USER /* User page ? */ - ori r11,r11,_PAGE_GUARDED /* 440 errata, needs G set */ beq 1f /* nope, leave U bits empty */ rlwimi r11,r11,3,26,28 /* yes, copy S bits to U */ 1:tlbwe r11,r13,PPC44x_TLB_ATTRIB /* Write ATTRIB */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/10] powerpc: Preliminary work to enable SMP BookE (v3)
On Dec 18, 2008, at 11:13 PM, Benjamin Herrenschmidt wrote: This series of patches is aimed at supporting SMP on non-hash based processors. It consists of a rework of the MMU context management and TLB management, clearly splitting hash32, hash64 and nohash in both cases, adding SMP safe context handling and some basic SMP TLB management. There is room for improvements, such as implementing lazy TLB flushing on processors without invalidate-by-PID support HW, some better IPI mechanism, lock less fast path in the MMU context switch, etc... but it should basically work. This version addresses the issues raised about some of the patches in the previous batch, removes the ones that were already merged in -next and and rebases the remaining ones when needed. All patches Acked-by: Kumar Gala ga...@kernel.crashing.org Please put these in powerpc/next and I can work up some 85xx SMP support on top of them. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] wrapper: Use the child-bus #address-cells to decide which range entry to use
The correct #address-cells was still used for the actual translation, so the impact is only a possibility of choosing the wrong range entry or failing to find any match. Most common cases were not affected. Signed-off-by: Scott Wood scottw...@freescale.com --- arch/powerpc/boot/devtree.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/boot/devtree.c b/arch/powerpc/boot/devtree.c index 5d12336..a7e21a3 100644 --- a/arch/powerpc/boot/devtree.c +++ b/arch/powerpc/boot/devtree.c @@ -213,7 +213,7 @@ static int find_range(u32 *reg, u32 *ranges, int nregaddr, u32 range_addr[MAX_ADDR_CELLS]; u32 range_size[MAX_ADDR_CELLS]; - copy_val(range_addr, ranges + i, naddr); + copy_val(range_addr, ranges + i, nregaddr); copy_val(range_size, ranges + i + nregaddr + naddr, nsize); if (compare_reg(reg, range_addr, range_size)) -- 1.5.6.rc1.6.gc53ad.dirty ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mm/shmem.c: fix division by zero
On Fri, 19 Dec 2008 08:44:57 +0300
Yuri Tikhonov y...@emcraft.com wrote:
The following patch fixes division by zero, which we have in
shmem_truncate_range() and shmem_unuse_inode(), if use big
PAGE_SIZE values (e.g. 256KB on ppc44x).
With 256KB PAGE_SIZE the ENTRIES_PER_PAGEPAGE constant becomes
too large (0x1..), so this patch just changes the types
from 'ulong' to 'ullong' where it's necessary.
Signed-off-by: Yuri Tikhonov y...@emcraft.com
---
mm/shmem.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index 0ed0752..99d7c91 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -57,7 +57,7 @@
#include asm/pgtable.h
#define ENTRIES_PER_PAGE (PAGE_CACHE_SIZE/sizeof(unsigned long))
-#define ENTRIES_PER_PAGEPAGE (ENTRIES_PER_PAGE*ENTRIES_PER_PAGE)
+#define ENTRIES_PER_PAGEPAGE ((unsigned long
long)ENTRIES_PER_PAGE*ENTRIES_PER_PAGE)
#define BLOCKS_PER_PAGE (PAGE_CACHE_SIZE/512)
#define SHMEM_MAX_INDEX (SHMEM_NR_DIRECT + (ENTRIES_PER_PAGEPAGE/2) *
(ENTRIES_PER_PAGE+1))
@@ -95,7 +95,7 @@ static unsigned long shmem_default_max_inodes(void)
}
#endif
-static int shmem_getpage(struct inode *inode, unsigned long idx,
+static int shmem_getpage(struct inode *inode, unsigned long long idx,
struct page **pagep, enum sgp_type sgp, int *type);
static inline struct page *shmem_dir_alloc(gfp_t gfp_mask)
@@ -533,7 +533,7 @@ static void shmem_truncate_range(struct inode *inode,
loff_t start, loff_t end)
int punch_hole;
spinlock_t *needs_lock;
spinlock_t *punch_lock;
- unsigned long upper_limit;
+ unsigned long long upper_limit;
inode-i_ctime = inode-i_mtime = CURRENT_TIME;
idx = (start + PAGE_CACHE_SIZE - 1) PAGE_CACHE_SHIFT;
@@ -1175,7 +1175,7 @@ static inline struct mempolicy *shmem_get_sbmpol(struct
shmem_sb_info *sbinfo)
* vm. If we swap it in we mark it dirty since we also free the swap
* entry since a page cannot live in both the swap and page cache
*/
-static int shmem_getpage(struct inode *inode, unsigned long idx,
+static int shmem_getpage(struct inode *inode, unsigned long long idx,
struct page **pagep, enum sgp_type sgp, int *type)
{
struct address_space *mapping = inode-i_mapping;
umm, ok, maybe. I guess that it would be more appropriate to use
loff_t in here, and things like
if (!diroff !offset upper_limit = stage) {
need a bit of thought (`stage' is still unsigned long).
I'll queue the patch as-is pending review from Hugh. Thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Long boot delay on 460EX with 2.6.28-rc8
Stefan Roese wrote: On Friday 19 December 2008, Felix Radensky wrote: Thanks a lot to everyone who replied. I've managed to identify the cause of the delay. The board is equipped with 256 MiB Samsung NAND flash. Since NAND support is a must for this platform, I've intergated the ndfc driver recently posted by Sean McLennan. With this driver enabled the delay is present, without it messages appear on the console immediately. Is this an expected behavior - detection of 256 MiB NAND flash takes around 20 seconds. The ndfc driver works fine after boot. No, 20 seconds is definitely too long. Something must be wrong with the ndfc driver or the NAND dts entries. Best regards, Stefan Hi, Sean Do you have any ideas what can cause such delay ? Thanks. Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Update 8641hpcn dts file to match latest u-boot
The newest revision of uboot reworks the memory map for this
board to look more like the 85xx boards. Also, some regions
which were far larger than the actual hardware have been scaled
back to match the board, and the imaginary second flash bank has
been removed. Rapidio and PCI are mutually exclusive in the hardware,
and they now are occupying the same space in the address map.
The Rapidio node is commented out of the .dts since PCI is the
common use case.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 56 ++-
1 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
index d665e76..e79af90 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -26,7 +26,7 @@
serial1 = serial1;
pci0 = pci0;
pci1 = pci1;
- rapidio0 = rapidio0;
+ /* rapidio0 = rapidio0; */
};
cpus {
@@ -62,18 +62,17 @@
reg = 0x 0x4000; // 1G at 0x0
};
- local...@f8005000 {
+ local...@ffe05000 {
#address-cells = 2;
#size-cells = 1;
compatible = fsl,mpc8641-localbus, simple-bus;
- reg = 0xf8005000 0x1000;
+ reg = 0xffe05000 0x1000;
interrupts = 19 2;
interrupt-parent = mpic;
- ranges = 0 0 0xff80 0x0080
- 1 0 0xfe00 0x0100
- 2 0 0xf820 0x0010
- 3 0 0xf810 0x0010;
+ ranges = 0 0 0xef80 0x0080
+ 2 0 0xffdf8000 0x8000
+ 3 0 0xffdf 0x8000;
fl...@0,0 {
compatible = cfi-flash;
@@ -103,13 +102,13 @@
};
};
- soc8...@f800 {
+ soc8...@ffe0 {
#address-cells = 1;
#size-cells = 1;
device_type = soc;
compatible = simple-bus;
- ranges = 0x 0xf800 0x0010;
- reg = 0xf800 0x1000; // CCSRBAR
+ ranges = 0x 0xffe0 0x0010;
+ reg = 0xffe0 0x1000; // CCSRBAR
bus-frequency = 0;
i...@3000 {
@@ -295,17 +294,17 @@
};
};
- pci0: p...@f8008000 {
+ pci0: p...@ffe08000 {
cell-index = 0;
compatible = fsl,mpc8641-pcie;
device_type = pci;
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
- reg = 0xf8008000 0x1000;
+ reg = 0xffe08000 0x1000;
bus-range = 0x0 0xff;
ranges = 0x0200 0x0 0x8000 0x8000 0x0 0x2000
- 0x0100 0x0 0x 0xe200 0x0 0x0010;
+ 0x0100 0x0 0x 0xffc0 0x0 0x0001;
clock-frequency = ;
interrupt-parent = mpic;
interrupts = 24 2;
@@ -436,7 +435,7 @@
0x0100 0x0 0x
0x0100 0x0 0x
- 0x0 0x0010;
+ 0x0 0x0001;
uli1...@0 {
reg = 0 0 0 0 0;
#size-cells = 2;
@@ -446,7 +445,7 @@
0x0 0x2000
0x0100 0x0 0x
0x0100 0x0 0x
- 0x0 0x0010;
+ 0x0 0x0001;
i...@1e {
device_type = isa;
#interrupt-cells = 2;
@@ -504,17 +503,17 @@
};
- pci1: p...@f8009000 {
+ pci1: p...@ffe09000 {
cell-index = 1;
compatible = fsl,mpc8641-pcie;
device_type = pci;
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
- reg = 0xf8009000 0x1000;
+ reg = 0xffe09000 0x1000;
bus-range = 0 0xff;
ranges = 0x0200 0x0 0xa000 0xa000 0x0 0x2000
- 0x0100 0x0 0x 0xe300 0x0 0x0010;
+ 0x0100 0x0 0x 0xffc1 0x0 0x0001;
clock-frequency = ;
interrupt-parent = mpic;
interrupts = 25 2;
@@ -537,18
[PATCH] powerpc/5200: Make internal 5200 PIC the default interrupt controller
From: Grant Likely grant.lik...@secretlab.ca The MPC5200 internal interrupt controller setup function needs to set the default interrupt controller when it is called. Without this irq_create_of_mapping() cannot be called without first determining the pointer to the irq controller (ie. call with controller = NULL). Signed-off-by: Grant Likely grant.lik...@secretlab.ca --- arch/powerpc/platforms/52xx/mpc52xx_pic.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pic.c b/arch/powerpc/platforms/52xx/mpc52xx_pic.c index c2fa60e..72865e8 100644 --- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c +++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c @@ -547,6 +547,8 @@ void __init mpc52xx_init_irq(void) if (!mpc52xx_irqhost) panic(__FILE__ : Cannot allocate the IRQ host\n); + irq_set_default_host(mpc52xx_irqhost); + pr_info(MPC52xx PIC is up and running!\n); } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
970FX thermal diode on G5
Hi, Is the thermal diode on a 970FX used on a G5? Can it be read by software? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 970FX thermal diode on G5
On Fri, 2008-12-19 at 18:54 -0800, Kevin Diggs wrote: Hi, Is the thermal diode on a 970FX used on a G5? Can it be read by software? The existing thermal control should do all you need already :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Long boot delay on 460EX with 2.6.28-rc8
On Fri, 19 Dec 2008 23:23:58 +0200 Felix Radensky fe...@embedded-sol.com wrote: Hi, Sean Do you have any ideas what can cause such delay ? Sorry, I haven't been following this thread :( We also use a 256M NAND, although a Spansion S29GL. While there is a small delay in u-boot, there is no noticeable during the ndfc startup. Can you read and write the NAND properly in u-boot? That is always the first step. If that works, we can look at what might be different between the u-boot and the ndfc driver. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Long boot delay on 460EX with 2.6.28-rc8
Sean MacLennan-2 wrote: On Fri, 19 Dec 2008 23:23:58 +0200 Felix Radensky fe...@embedded-sol.com wrote: Hi, Sean Do you have any ideas what can cause such delay ? Sorry, I haven't been following this thread :( We also use a 256M NAND, although a Spansion S29GL. While there is a small delay in u-boot, there is no noticeable during the ndfc startup. Can you read and write the NAND properly in u-boot? That is always the first step. If that works, we can look at what might be different between the u-boot and the ndfc driver. Cheers, Sean Thanks, Sean I've found the cause of the delay. It was a stupid error on my part, not related to ndfc driver, which is fine. Thanks a lot for you work on this. I apologize for the noise. Felix. -- View this message in context: http://www.nabble.com/Long-boot-delay-on-460EX-with-2.6.28-rc8-tp21070179p21102440.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH]: [MPC5200] Add ATA DMA support
On Tue, Nov 25, 2008 at 8:19 AM, Matt Sealey m...@genesi-usa.com wrote: On Tue, Nov 25, 2008 at 8:45 AM, Lehmann, Hans (Ritter Elektronik) hans.lehm...@ritter-elektronik.de wrote: Tim, Grant, just an info. Very often the Bestcomm-FEC crashed without any error logs if I initiate a transaction over FEC and save the file to disk (I rememeber I have read something like that). A restart of FEC don't work. But no I figured out, if I connect to the other ethernet port of our board (natsemi) the FEC will awake to life again, if I initiate a new transaction over natsemi. This seems a little oddly to me. Hi guys, We tried to get the SUSE guys to push the patch into openSUSE 11.1 release and the tests came back negative here too with regards to FEC support; for some odd reason, it does this; https://bugzilla.novell.com/show_bug.cgi?id=445856#c10 There is some weird interaction here, but I can't imagine what it might be. Tim, did you ever see any ethernet problems like this? It looks like something getting messed up during allocation of buffers and not DMA operation related at all. I don't see the problem here... Digging deeper I think the problem is due to this: --- Comment #6 From Olaf Hering 2008-11-18 01:32:52 MST --- Also, the patches do not seem to apply and compile with our kernel-source. bcom_task-bd changed to void*, this breaks sound/ppc/mpc52xx_ac97.c. It looks like an unneeded cosmetic change. The Kconfig changes are appearently also not required for an existing .config. I removed the bcom_task-bd change. The patch does depend on bcom_task-bd being (void *). Without it the calculation of BD offsets is entirely wrong in bcom_get_bd(). That being said, the next version of the patch will leave the pointer as (bcom_bd *) and handle the offset calculation in a different way. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
