* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Scott Wood @ 2008-08-21 21:35 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, paulus
In-Reply-To: <20080821.142134.127315039.davem@davemloft.net>
David Miller wrote:
>> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
>>> 2) When CONFIG_SPARC, shift the device address down by one bit before
>>> giving it to the Linux I2C layer.
>> Maybe we should distinguish by the type of I2C bus node instead.
>
> How so? If a Sparc and a PowerPC system use similar I2C
> controllers, we risk double matches.
It's not really an instruction-set architecture issue, it's a binding
issue. What if a non-OF embedded SPARC comes along that copies i2c from
a PowerPC DTS file, or we come across a real-OF PowerPC that does it the
SPARC way?
If we do come across two systems that claim their i2c bus nodes are
compatible but use different bindings, *then* we'll find some
out-of-band information to disambiguate.
> If you guys created this format in your compressed openfirmware
> trees, is it possible for you to "fix" it to match what Sparc
> systems following the proper bindings do?
Possibly, though it'll cause some pain when old trees are used with a
kernel that expects the new binding.
You mentioned having an actual binding document for I2C on Open
Firmware; is it available online anywhere?
> Don't PowerMACs and such have I2C controllers and devices?
> How do they encode these I2C client device reg properties?
As far as I can tell from poking around
http://penguinppc.org/historical/dev-trees-html/, they don't include reg
at all for i2c clients.
-Scott
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: David Miller @ 2008-08-21 21:21 UTC (permalink / raw)
To: scottwood; +Cc: sparclinux, linuxppc-dev, paulus
In-Reply-To: <20080821163256.GC15669@ld0162-tx32.am.freescale.net>
From: Scott Wood <scottwood@freescale.com>
Date: Thu, 21 Aug 2008 11:32:56 -0500
> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
> > 2) When CONFIG_SPARC, shift the device address down by one bit before
> > giving it to the Linux I2C layer.
>
> Maybe we should distinguish by the type of I2C bus node instead.
How so? If a Sparc and a PowerPC system use similar I2C
controllers, we risk double matches.
If you guys created this format in your compressed openfirmware
trees, is it possible for you to "fix" it to match what Sparc
systems following the proper bindings do?
This way we won't need any of these ifdefs at all.
Don't PowerMACs and such have I2C controllers and devices?
How do they encode these I2C client device reg properties?
^ permalink raw reply
* Re: porting linux 2.6.27 to embedded powerpc board
From: Laxmikant Rashinkar @ 2008-08-21 21:12 UTC (permalink / raw)
To: Scott Wood, David Jander; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]
Just wanted to thank all of you for the detailed feedback and suggestions.
I am going to try them out now and keep my fingers crossed.
thanks again
LK
----- Original Message ----
From: Scott Wood <scottwood@freescale.com>
To: David Jander <david.jander@protonic.nl>
Cc: linuxppc-embedded@ozlabs.org; Laxmikant Rashinkar <lk.atwork@yahoo.com>
Sent: Thursday, August 21, 2008 9:12:23 AM
Subject: Re: porting linux 2.6.27 to embedded powerpc board
David Jander wrote:
> 4. Be sure that the device(s) necessary to produce output on your console are
> correctly placed in the DT. Also make sure that u-boot knows about it
> (#define OF_STDOUT_PATH... in your u-boot board config file)
OF_STDOUT_PATH is deprecated; you should enable
CONFIG_OF_SERIAL_VIA_ALIAS, and provide aliases in the device tree for
serial0, serial1, etc.
> 6. Remember to always specify the "rootfstype=" option on the commandline if
> booting from anything other than NFS. This was not necessary back in the
> 2.6.15-times AFAICR.
It still should not be necessary.
> 7. Boot with a device-tree (in u-boot: "bootm $addrofkernel - $addrofdtb",
> don't forget the dash if you are not using an initrd). If you don't do this,
> u-boot can't fix your DT, and the kernel probably won't find it either.
s/probably/definitely/
> 8. Be sure to use the correct version of the DTC (DT compiler) for your kernel
> (the sources are included nowadays, somewhere in arch/powerpc/boot IIRC). The
> command used to compile, should probably be something like this:
Or just use the most recent DTC.
-Scott
[-- Attachment #2: Type: text/html, Size: 2129 bytes --]
^ permalink raw reply
* [PATCH] POWERPC: Allow 32-bit pgtable code to support 36-bit physical
From: Becky Bruce @ 2008-08-21 21:09 UTC (permalink / raw)
To: linuxppc-dev
This rearranges a bit of code, and adds support for
36-bit physical addressing for configs that use a
hashed page table. The 36b physical support is not
enabled by default on any config - it must be
explicitly enabled via the config system.
This patch *only* expands the page table code to accomodate
large physical addresses on 32-bit systems and enables the
PHYS_64BIT config option for 6xx. It does *not*
allow you to boot a board with more than about 3.5GB of
RAM - for that, SWIOTLB support is also required (and
coming soon).
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
---
arch/powerpc/include/asm/io.h | 2 +-
arch/powerpc/include/asm/page_32.h | 10 ++++-
arch/powerpc/include/asm/pgtable-ppc32.h | 35 +++++++++++++-
arch/powerpc/include/asm/types.h | 2 +-
arch/powerpc/kernel/head_32.S | 4 +-
arch/powerpc/kernel/head_fsl_booke.S | 2 -
arch/powerpc/mm/hash_low_32.S | 78 +++++++++++++++++++++++------
arch/powerpc/mm/pgtable_32.c | 4 +-
arch/powerpc/platforms/Kconfig.cputype | 14 ++++--
9 files changed, 120 insertions(+), 31 deletions(-)
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 77c7fa0..08266d2 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -711,7 +711,7 @@ static inline void * phys_to_virt(unsigned long address)
/*
* Change "struct page" to physical address.
*/
-#define page_to_phys(page) (page_to_pfn(page) << PAGE_SHIFT)
+#define page_to_phys(page) ((phys_addr_t)page_to_pfn(page) << PAGE_SHIFT)
/* We do NOT want virtual merging, it would put too much pressure on
* our iommu allocator. Instead, we want drivers to be smart enough
diff --git a/arch/powerpc/include/asm/page_32.h b/arch/powerpc/include/asm/page_32.h
index ebfae53..0b253f6 100644
--- a/arch/powerpc/include/asm/page_32.h
+++ b/arch/powerpc/include/asm/page_32.h
@@ -13,10 +13,18 @@
#define ARCH_KMALLOC_MINALIGN L1_CACHE_BYTES
#endif
+#ifdef CONFIG_PTE_64BIT
+#define PTE_FLAGS_OFFSET 4 /* offset of PTE flags, in bytes */
+#define LNX_PTE_SIZE 8 /* size of a linux PTE, in bytes */
+#else
+#define PTE_FLAGS_OFFSET 0
+#define LNX_PTE_SIZE 4
+#endif
+
#ifndef __ASSEMBLY__
/*
* The basic type of a PTE - 64 bits for those CPUs with > 32 bit
- * physical addressing. For now this just the IBM PPC440.
+ * physical addressing.
*/
#ifdef CONFIG_PTE_64BIT
typedef unsigned long long pte_basic_t;
diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h b/arch/powerpc/include/asm/pgtable-ppc32.h
index 6fe39e3..bf21a05 100644
--- a/arch/powerpc/include/asm/pgtable-ppc32.h
+++ b/arch/powerpc/include/asm/pgtable-ppc32.h
@@ -363,7 +363,12 @@ extern int icache_44x_need_flush;
#define _PAGE_EXEC 0x200 /* software: i-cache coherency required */
#define _PAGE_RW 0x400 /* software: user write access allowed */
+#ifdef CONFIG_PTE_64BIT
+/* We never clear the high word of the pte, mask those off */
+#define _PTE_NONE_MASK (0xffffffff00000000ULL | _PAGE_HASHPTE)
+#else
#define _PTE_NONE_MASK _PAGE_HASHPTE
+#endif
#define _PMD_PRESENT 0
#define _PMD_PRESENT_MASK (PAGE_MASK)
@@ -517,7 +522,13 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void);
#define pte_none(pte) ((pte_val(pte) & ~_PTE_NONE_MASK) == 0)
#define pte_present(pte) (pte_val(pte) & _PAGE_PRESENT)
+
+#if (defined(CONFIG_PTE_64BIT) && (_PAGE_HASHPTE != 0))
+#define pte_clear(mm, addr, ptep) \
+ do { pte_update((ptep), (~_PAGE_HASHPTE), __pte(0)); } while (0)
+#else
#define pte_clear(mm,addr,ptep) do { set_pte_at((mm), (addr), (ptep), __pte(0)); } while (0)
+#endif
#define pmd_none(pmd) (!pmd_val(pmd))
#define pmd_bad(pmd) (pmd_val(pmd) & _PMD_BAD)
@@ -656,10 +667,32 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
pte_t *ptep, pte_t pte)
{
#if _PAGE_HASHPTE != 0
+#ifndef CONFIG_PTE_64BIT
pte_update(ptep, ~_PAGE_HASHPTE, pte_val(pte) & ~_PAGE_HASHPTE);
#else
+ /*
+ * We have to do the write of the 64b pte as 2 stores. This
+ * code assumes that the entry we're storing to is currently
+ * not valid and that all callers have the page table lock.
+ * Having the entry be not valid protects readers who might read
+ * between the first and second stores.
+ */
+ unsigned int tmp;
+
+ __asm__ __volatile__("\
+1: lwarx %0,0,%4\n\
+ rlwimi %L2,%0,0,30,30\n\
+ stw %2,0(%3)\n\
+ eieio\n\
+ stwcx. %L2,0,%4\n\
+ bne- 1b"
+ : "=&r" (tmp), "=m" (*ptep)
+ : "r" (pte), "r" (ptep), "r" ((unsigned long)(ptep) + 4), "m" (*ptep)
+ : "cc");
+#endif /* CONFIG_PTE_64BIT */
+#else
*ptep = pte;
-#endif
+#endif /* _PAGE_HASHPTE */
}
/*
diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/asm/types.h
index d3374bc..a9a9262 100644
--- a/arch/powerpc/include/asm/types.h
+++ b/arch/powerpc/include/asm/types.h
@@ -55,7 +55,7 @@ typedef u64 phys_addr_t;
typedef u32 phys_addr_t;
#endif
-#ifdef __powerpc64__
+#if defined(__powerpc64__) || defined(CONFIG_PHYS_64BIT)
typedef u64 dma_addr_t;
#else
typedef u32 dma_addr_t;
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index 99ee2f0..6e2889d 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -369,13 +369,13 @@ i##n: \
DataAccess:
EXCEPTION_PROLOG
mfspr r10,SPRN_DSISR
+ stw r10,_DSISR(r11)
andis. r0,r10,0xa470 /* weird error? */
bne 1f /* if not, try to put a PTE */
mfspr r4,SPRN_DAR /* into the hash table */
rlwinm r3,r10,32-15,21,21 /* DSISR_STORE -> _PAGE_RW */
bl hash_page
-1: stw r10,_DSISR(r11)
- mr r5,r10
+1: lwz r5,_DSISR(r11) /* get DSISR value */
mfspr r4,SPRN_DAR
EXC_XFER_EE_LITE(0x300, handle_page_fault)
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index 3cb52fa..4ccceab 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -422,7 +422,6 @@ skpinv: addi r6,r6,1 /* Increment */
* r12 is pointer to the pte
*/
#ifdef CONFIG_PTE_64BIT
-#define PTE_FLAGS_OFFSET 4
#define FIND_PTE \
rlwinm r12, r10, 13, 19, 29; /* Compute pgdir/pmd offset */ \
lwzx r11, r12, r11; /* Get pgd/pmd entry */ \
@@ -431,7 +430,6 @@ skpinv: addi r6,r6,1 /* Increment */
rlwimi r12, r10, 23, 20, 28; /* Compute pte address */ \
lwz r11, 4(r12); /* Get pte entry */
#else
-#define PTE_FLAGS_OFFSET 0
#define FIND_PTE \
rlwimi r11, r10, 12, 20, 29; /* Create L1 (pgdir/pmd) address */ \
lwz r11, 0(r11); /* Get L1 entry */ \
diff --git a/arch/powerpc/mm/hash_low_32.S b/arch/powerpc/mm/hash_low_32.S
index b9ba7d9..d63e20a 100644
--- a/arch/powerpc/mm/hash_low_32.S
+++ b/arch/powerpc/mm/hash_low_32.S
@@ -75,7 +75,7 @@ _GLOBAL(hash_page_sync)
* Returns to the caller if the access is illegal or there is no
* mapping for the address. Otherwise it places an appropriate PTE
* in the hash table and returns from the exception.
- * Uses r0, r3 - r8, ctr, lr.
+ * Uses r0, r3 - r8, r10, ctr, lr.
*/
.text
_GLOBAL(hash_page)
@@ -106,9 +106,15 @@ _GLOBAL(hash_page)
addi r5,r5,swapper_pg_dir@l /* kernel page table */
rlwimi r3,r9,32-12,29,29 /* MSR_PR -> _PAGE_USER */
112: add r5,r5,r7 /* convert to phys addr */
+#ifndef CONFIG_PTE_64BIT
rlwimi r5,r4,12,20,29 /* insert top 10 bits of address */
lwz r8,0(r5) /* get pmd entry */
rlwinm. r8,r8,0,0,19 /* extract address of pte page */
+#else
+ rlwinm r8,r4,13,19,29 /* Compute pgdir/pmd offset */
+ lwzx r8,r8,r5 /* Get L1 entry */
+ rlwinm. r8,r8,0,0,20 /* extract pt base address */
+#endif
#ifdef CONFIG_SMP
beq- hash_page_out /* return if no mapping */
#else
@@ -118,7 +124,11 @@ _GLOBAL(hash_page)
to the address following the rfi. */
beqlr-
#endif
+#ifndef CONFIG_PTE_64BIT
rlwimi r8,r4,22,20,29 /* insert next 10 bits of address */
+#else
+ rlwimi r8,r4,23,20,28 /* compute pte address */
+#endif
rlwinm r0,r3,32-3,24,24 /* _PAGE_RW access -> _PAGE_DIRTY */
ori r0,r0,_PAGE_ACCESSED|_PAGE_HASHPTE
@@ -127,9 +137,15 @@ _GLOBAL(hash_page)
* because almost always, there won't be a permission violation
* and there won't already be an HPTE, and thus we will have
* to update the PTE to set _PAGE_HASHPTE. -- paulus.
+ *
+ * If PTE_64BIT is set, the low word is the flags word; use that
+ * word for locking since it contains all the interesting bits.
*/
+#if (PTE_FLAGS_OFFSET != 0)
+ addi r8,r8,PTE_FLAGS_OFFSET
+#endif
retry:
- lwarx r6,0,r8 /* get linux-style pte */
+ lwarx r6,0,r8 /* get linux-style pte, flag word */
andc. r5,r3,r6 /* check access & ~permission */
#ifdef CONFIG_SMP
bne- hash_page_out /* return if access not permitted */
@@ -137,6 +153,11 @@ retry:
bnelr-
#endif
or r5,r0,r6 /* set accessed/dirty bits */
+#ifdef CONFIG_PTE_64BIT
+ subf r10,r6,r8 /* create false data dependency */
+ subi r10,r10,PTE_FLAGS_OFFSET
+ lwzx r10,r6,r10 /* Get upper PTE word */
+#endif
stwcx. r5,0,r8 /* attempt to update PTE */
bne- retry /* retry if someone got there first */
@@ -203,9 +224,9 @@ _GLOBAL(add_hash_page)
* we can't take a hash table miss (assuming the code is
* covered by a BAT). -- paulus
*/
- mfmsr r10
+ mfmsr r9
SYNC
- rlwinm r0,r10,0,17,15 /* clear bit 16 (MSR_EE) */
+ rlwinm r0,r9,0,17,15 /* clear bit 16 (MSR_EE) */
rlwinm r0,r0,0,28,26 /* clear MSR_DR */
mtmsr r0
SYNC_601
@@ -214,14 +235,14 @@ _GLOBAL(add_hash_page)
tophys(r7,0)
#ifdef CONFIG_SMP
- addis r9,r7,mmu_hash_lock@ha
- addi r9,r9,mmu_hash_lock@l
-10: lwarx r0,0,r9 /* take the mmu_hash_lock */
+ addis r6,r7,mmu_hash_lock@ha
+ addi r6,r6,mmu_hash_lock@l
+10: lwarx r0,0,r6 /* take the mmu_hash_lock */
cmpi 0,r0,0
bne- 11f
- stwcx. r8,0,r9
+ stwcx. r8,0,r6
beq+ 12f
-11: lwz r0,0(r9)
+11: lwz r0,0(r6)
cmpi 0,r0,0
beq 10b
b 11b
@@ -234,10 +255,20 @@ _GLOBAL(add_hash_page)
* HPTE, so we just unlock and return.
*/
mr r8,r5
+#ifndef CONFIG_PTE_64BIT
rlwimi r8,r4,22,20,29
+#else
+ rlwimi r8,r4,23,20,28
+ addi r8,r8,PTE_FLAGS_OFFSET
+#endif
1: lwarx r6,0,r8
andi. r0,r6,_PAGE_HASHPTE
bne 9f /* if HASHPTE already set, done */
+#ifdef CONFIG_PTE_64BIT
+ subf r10,r6,r8 /* create false data dependency */
+ subi r10,r10,PTE_FLAGS_OFFSET
+ lwzx r10,r6,r10 /* Get upper PTE word */
+#endif
ori r5,r6,_PAGE_HASHPTE
stwcx. r5,0,r8
bne- 1b
@@ -246,13 +277,15 @@ _GLOBAL(add_hash_page)
9:
#ifdef CONFIG_SMP
+ addis r6,r7,mmu_hash_lock@ha
+ addi r6,r6,mmu_hash_lock@l
eieio
li r0,0
- stw r0,0(r9) /* clear mmu_hash_lock */
+ stw r0,0(r6) /* clear mmu_hash_lock */
#endif
/* reenable interrupts and DR */
- mtmsr r10
+ mtmsr r9
SYNC_601
isync
@@ -267,7 +300,8 @@ _GLOBAL(add_hash_page)
* r5 contains the linux PTE, r6 contains the old value of the
* linux PTE (before setting _PAGE_HASHPTE) and r7 contains the
* offset to be added to addresses (0 if the MMU is on,
- * -KERNELBASE if it is off).
+ * -KERNELBASE if it is off). r10 contains the upper half of
+ * the PTE if CONFIG_PTE_64BIT.
* On SMP, the caller should have the mmu_hash_lock held.
* We assume that the caller has (or will) set the _PAGE_HASHPTE
* bit in the linux PTE in memory. The value passed in r6 should
@@ -313,6 +347,11 @@ _GLOBAL(create_hpte)
BEGIN_FTR_SECTION
ori r8,r8,_PAGE_COHERENT /* set M (coherence required) */
END_FTR_SECTION_IFSET(CPU_FTR_NEED_COHERENT)
+#ifdef CONFIG_PTE_64BIT
+ /* Put the XPN bits into the PTE */
+ rlwimi r8,r10,8,20,22
+ rlwimi r8,r10,2,29,29
+#endif
/* Construct the high word of the PPC-style PTE (r5) */
rlwinm r5,r3,7,1,24 /* put VSID in 0x7fffff80 bits */
@@ -499,14 +538,18 @@ _GLOBAL(flush_hash_pages)
isync
/* First find a PTE in the range that has _PAGE_HASHPTE set */
+#ifndef CONFIG_PTE_64BIT
rlwimi r5,r4,22,20,29
-1: lwz r0,0(r5)
+#else
+ rlwimi r5,r4,23,20,28
+#endif
+1: lwz r0,PTE_FLAGS_OFFSET(r5)
cmpwi cr1,r6,1
andi. r0,r0,_PAGE_HASHPTE
bne 2f
ble cr1,19f
addi r4,r4,0x1000
- addi r5,r5,4
+ addi r5,r5,LNX_PTE_SIZE
addi r6,r6,-1
b 1b
@@ -545,7 +588,10 @@ _GLOBAL(flush_hash_pages)
* already clear, we're done (for this pte). If not,
* clear it (atomically) and proceed. -- paulus.
*/
-33: lwarx r8,0,r5 /* fetch the pte */
+#if (PTE_FLAGS_OFFSET != 0)
+ addi r5,r5,PTE_FLAGS_OFFSET
+#endif
+33: lwarx r8,0,r5 /* fetch the pte flags word */
andi. r0,r8,_PAGE_HASHPTE
beq 8f /* done if HASHPTE is already clear */
rlwinm r8,r8,0,31,29 /* clear HASHPTE bit */
@@ -590,7 +636,7 @@ _GLOBAL(flush_hash_patch_B)
8: ble cr1,9f /* if all ptes checked */
81: addi r6,r6,-1
- addi r5,r5,4 /* advance to next pte */
+ addi r5,r5,LNX_PTE_SIZE /* go to next linux pte flag word */
addi r4,r4,0x1000
lwz r0,0(r5) /* check next pte */
cmpwi cr1,r6,1
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 2001abd..c31d6d2 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -73,7 +73,7 @@ extern unsigned long p_mapped_by_tlbcam(unsigned long pa);
#endif /* HAVE_TLBCAM */
#ifdef CONFIG_PTE_64BIT
-/* 44x uses an 8kB pgdir because it has 8-byte Linux PTEs. */
+/* Some processors use an 8kB pgdir because they have 8-byte Linux PTEs. */
#define PGDIR_ORDER 1
#else
#define PGDIR_ORDER 0
@@ -288,7 +288,7 @@ int map_page(unsigned long va, phys_addr_t pa, int flags)
}
/*
- * Map in all of physical memory starting at KERNELBASE.
+ * Map in a big chunk of physical memory starting at KERNELBASE.
*/
void __init mapin_ram(void)
{
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 7f65127..ca5b58b 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -128,18 +128,22 @@ config FSL_EMB_PERFMON
config PTE_64BIT
bool
- depends on 44x || E500
+ depends on 44x || E500 || 6xx
default y if 44x
- default y if E500 && PHYS_64BIT
+ default y if PHYS_64BIT
config PHYS_64BIT
- bool 'Large physical address support' if E500
- depends on 44x || E500
+ bool 'Large physical address support' if E500 || 6xx
+ depends on 44x || E500 || 6xx
select RESOURCES_64BIT
default y if 44x
---help---
This option enables kernel support for larger than 32-bit physical
- addresses. This features is not be available on all e500 cores.
+ addresses. This features is not be available on all cores.
+
+ If you have more than 3.5GB of RAM or so, you also need to enable
+ SWIOTLB under Kernel Options for this to work. The actual number
+ is platform-dependent.
If in doubt, say N here.
--
1.5.5.1
^ permalink raw reply related
* Re: [PATCH] math-emu: Add support for reporting exact invalid exception
From: David Miller @ 2008-08-21 21:05 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1219323021-7273-2-git-send-email-galak@kernel.crashing.org>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Thu, 21 Aug 2008 07:50:21 -0500
> Some architectures (like powerpc) provide status information on the exact
> type of invalid exception. This is pretty straight forward as we already
> report invalid exceptions via FP_SET_EXCEPTION.
>
> We add new flags (FP_EX_INVALID_*) the architecture code can define if it
> wants the exact invalid exception reported.
>
> We had to split out the INF/INF and 0/0 cases for divide to allow reporting
> the two invalid forms properly.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] math-emu: Fix compiler warnings
From: David Miller @ 2008-08-21 21:03 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1219323021-7273-1-git-send-email-galak@kernel.crashing.org>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Thu, 21 Aug 2008 07:50:20 -0500
> Fix warnings of the form:
> arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f1' may be used uninitialized in this function
> arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f0' may be used uninitialized in this function
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
You should look at the compiler options we use on sparc to build this
stuff :-)
EXTRA_CFLAGS = -Iinclude/math-emu -w
^ permalink raw reply
* Re: [RFC][PATCH] I2C driver
From: Steven A. Falco @ 2008-08-21 20:37 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <200808212105.29963.sr@denx.de>
Stefan Roese wrote:
> On Thursday 21 August 2008, Sean MacLennan wrote:
>> On Thu, 21 Aug 2008 13:06:24 -0400
>>
>> "Steven A. Falco" <sfalco@harris.com> wrote:
>>> However, while the i2c-ibm_of.c driver works with the sequoia .dts,
>>> i2c-ibm_iic.c does not, because it is looking for an "index" property,
>>> which is not in the .dts file. I added one:
>> I don't know where i2c-ibm_of.c came from....
>
> It's a temporary DENX version for arch/powerpc which we created, since it took
> too long to get something accepted upstream (I remember endless discussions
> about index properties...). And we needed something functional quite a while
> ago.
>
>> but in the 2.6.26 kernel
>> you need the index property.
>>
>> The 2.6.27 kernel has a fully OF aware i2c-ibm_iic driver. You do
>> not need the index. And it will walk the device tree and setup the
>> devices for you.
>
> Yes. Since 2.6.27 the "original" IBM I2C driver should be enough. We will drop
> our local special version soon.
>
> Best regards,
> Stefan
>
> =====================================================================
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
> =====================================================================
>
I was able to cherry-pick the i2c-ibm_iic driver from .27 into .26, so
I withdraw my comments regarding the soon-to-be-discarded i2c-ibm_of
driver.
Steve
^ permalink raw reply
* Re: New Patchwork beta
From: Kumar Gala @ 2008-08-21 20:32 UTC (permalink / raw)
To: Jeremy Kerr
Cc: linuxppc-dev, bazaar-ng, linux-mtd, cbe-oss-dev,
linuxppc-embedded
In-Reply-To: <200808211822.27786.jk@ozlabs.org>
Some feedback:
* Can we increase the font size a bit?
* For the list of patches can we change the background of every other
line (light gray)
* Parsing subject header for determining state -- "[RFC]"
w/o being able to log in that's my initial two cents.
Both otherwise it looks good and seem much faster than the old version.
- k
^ permalink raw reply
* [PATCH] POWERPC: Change total_memory to phys_addr_t
From: Becky Bruce @ 2008-08-21 20:10 UTC (permalink / raw)
To: linuxppc-dev
Also change consumers of various lmb funcs/arrays that are now
phys_addr_t to also be phys_addr_t.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
---
arch/powerpc/mm/mem.c | 19 ++++++++++---------
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 1c93c25..89dc32b 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -75,14 +75,14 @@ static inline pte_t *virt_to_kpte(unsigned long vaddr)
int page_is_ram(unsigned long pfn)
{
- unsigned long paddr = (pfn << PAGE_SHIFT);
+ phys_addr_t paddr = ((phys_addr_t)pfn << PAGE_SHIFT);
#ifndef CONFIG_PPC64 /* XXX for now */
return paddr < __pa(high_memory);
#else
int i;
for (i=0; i < lmb.memory.cnt; i++) {
- unsigned long base;
+ phys_addr_t base;
base = lmb.memory.region[i].base;
@@ -195,7 +195,8 @@ EXPORT_SYMBOL_GPL(walk_memory_resource);
void __init do_init_bootmem(void)
{
unsigned long i;
- unsigned long start, bootmap_pages;
+ phys_addr_t start;
+ unsigned long bootmap_pages;
unsigned long total_pages;
int boot_mapsize;
@@ -234,8 +235,8 @@ void __init do_init_bootmem(void)
/* reserve the sections we're already using */
for (i = 0; i < lmb.reserved.cnt; i++) {
- unsigned long addr = lmb.reserved.region[i].base +
- lmb_size_bytes(&lmb.reserved, i) - 1;
+ phys_addr_t addr = lmb.reserved.region[i].base +
+ lmb_size_bytes(&lmb.reserved, i) - 1;
if (addr < lowmem_end_addr)
reserve_bootmem(lmb.reserved.region[i].base,
lmb_size_bytes(&lmb.reserved, i),
@@ -290,7 +291,7 @@ static int __init mark_nonram_nosave(void)
*/
void __init paging_init(void)
{
- unsigned long total_ram = lmb_phys_mem_size();
+ phys_addr_t total_ram = lmb_phys_mem_size();
phys_addr_t top_of_ram = lmb_end_of_DRAM();
unsigned long max_zone_pfns[MAX_NR_ZONES];
@@ -310,10 +311,10 @@ void __init paging_init(void)
kmap_prot = PAGE_KERNEL;
#endif /* CONFIG_HIGHMEM */
- printk(KERN_DEBUG "Top of RAM: 0x%llx, Total RAM: 0x%lx\n",
- (unsigned long long)top_of_ram, total_ram);
+ printk(KERN_DEBUG "Top of RAM: 0x%llx, Total RAM: 0x%llx\n",
+ (unsigned long long)top_of_ram, (unsigned long long)total_ram);
printk(KERN_DEBUG "Memory hole size: %ldMB\n",
- (long int)((top_of_ram - total_ram) >> 20));
+ (unsigned long)((top_of_ram - total_ram) >> 20));
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
#ifdef CONFIG_HIGHMEM
max_zone_pfns[ZONE_DMA] = lowmem_end_addr >> PAGE_SHIFT;
--
1.5.5.1
^ permalink raw reply related
* Re: [PATCH] 85xx: fix build warning, remove silly cast
From: Kumar Gala @ 2008-08-21 19:58 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <1219344622-13638-1-git-send-email-becky.bruce@freescale.com>
On Aug 21, 2008, at 1:50 PM, Becky Bruce wrote:
> This fixes a build warning when PHYS_64BIT is enabled, and
> removes an unnecessary cast to phys_addr_t (the variable
> being cast is already a phys_addr_t)
>
> Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
> ---
> arch/powerpc/mm/fsl_booke_mmu.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
applied to powerpc-next.
- k
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Board support for GE Fanuc SBC610
From: Kumar Gala @ 2008-08-21 19:54 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080821144144.fed06908.martyn.welch@gefanuc.com>
>
> diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts b/arch/powerpc/
> boot/dts/gef_sbc610.dts
> new file mode 100644
> index 0000000..32168c6
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/gef_sbc610.dts
> @@ -0,0 +1,268 @@
> +/*
> + * GE Fanuc SBC610 Device Tree Source
> + *
> + * Copyright 2008 GE Fanuc Intelligent Platforms Embedded Systems,
> Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as
> published by the
> + * Free Software Foundation; either version 2 of the License, or
> (at your
> + * option) any later version.
> + *
> + * Based on: SBS CM6 Device Tree Source
> + * Copyright 2007 SBS Technologies GmbH & Co. KG
> + */
> +
> +/*
> + * Compiled with dtc -I dts -O dtb -o gef_sbc610.dtb gef_sbc610.dts
> + */
> +
> +/dts-v1/;
Look at fixing whitespace (using tabs instead of spaces)
>
> +
> +/ {
> + model = "GEF_SBC610";
> + compatible = "gef,sbc610";
> + #address-cells = <1>;
> + #size-cells = <1>;
You should add an aliases node and references as newer u-boots expect
that to setup various properties.
>
> +
> + cpus {
> + #cpus = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,8641@0 {
> + device_type = "cpu";
> + reg = <0x00000000>;
> + d-cache-line-size = <32>; // 32 bytes
> + i-cache-line-size = <32>; // 32 bytes
> + d-cache-size = <32768>; // L1, 32K
> + i-cache-size = <32768>; // L1, 32K
> + timebase-frequency = <0>; // From uboot
> + bus-frequency = <0>; // From uboot
> + clock-frequency = <0>; // From uboot
> + l2cr = <0x80000000>; // Enable L2
> + 32-bit;
> + };
> + PowerPC,8641@1 {
> + device_type = "cpu";
> + reg = <0x00000001>;
> + d-cache-line-size = <32>; // 32 bytes
> + i-cache-line-size = <32>; // 32 bytes
> + d-cache-size = <32768>; // L1, 32K
> + i-cache-size = <32768>; // L1, 32K
> + timebase-frequency = <0>; // From uboot
> + bus-frequency = <0>; // From uboot
> + clock-frequency = <0>; // From uboot
> + l2cr = <0x80000000>; // Enable L2
> + 32-bit;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00000000 0x40000000>; // set by u-boot
> + };
> +
> + soc8641@fef00000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #interrupt-cells = <2>;
> + device_type = "soc";
> + ranges = <0x00000000 0xfef00000 0x00100000>;
> + reg = <0xfef00000 0x00100000>; // CCSRBAR 1M
> + bus-frequency = <0>;
> +
> + i2c1: i2c@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "i2c";
> + compatible = "fsl-i2c";
> + reg = <0x00003000 0x00000100>;
> + interrupts = <0x2b 0x2>;
> + interrupt-parent = <&mpic>;
> + dfsrr;
> +
> + eti@6b {
> + compatible = "dallas,ds1682";
> + reg = <0x0000006b>;
> + };
> + };
> +
> + i2c2: i2c@3100 {
> + device_type = "i2c";
> + compatible = "fsl-i2c";
> + reg = <0x00003100 0x00000100>;
> + interrupts = <0x2b 0x2>;
> + interrupt-parent = <&mpic>;
> + dfsrr;
> + };
> +
> + ecc@2000 {
> + device_type = "dram-controller";
> + compatible = "mpc86xx";
> + reg = <0x00002000 0x00001000>;
> + interrupts = <0x12 0x2>;
> + interrupt-parent = <&mpic>;
> + };
> +
> + ecc@6000 {
> + device_type = "dram-controller";
> + compatible = "mpc86xx";
> + reg = <0x00006000 0x00001000>;
> + interrupts = <0x12 0x2>;
> + interrupt-parent = <&mpic>;
> + };
> +
Take a look at the mpc8572ds.dts for examples of the memctrl device
nodes
>
> + dma@21300 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,mpc8641-dma", "fsl,eloplus-dma";
> + reg = <0x21300 0x4>;
> + ranges = <0x0 0x21100 0x200>;
> + cell-index = <0>;
> + dma-channel@0 {
> + compatible = "fsl,mpc8641-dma-channel",
> + "fsl,eloplus-dma-channel";
> + reg = <0x0 0x80>;
> + cell-index = <0>;
> + interrupt-parent = <&mpic>;
> + interrupts = <20 2>;
> + };
> + dma-channel@80 {
> + compatible = "fsl,mpc8641-dma-channel",
> + "fsl,eloplus-dma-channel";
> + reg = <0x80 0x80>;
> + cell-index = <1>;
> + interrupt-parent = <&mpic>;
> + interrupts = <21 2>;
> + };
> + dma-channel@100 {
> + compatible = "fsl,mpc8641-dma-channel",
> + "fsl,eloplus-dma-channel";
> + reg = <0x100 0x80>;
> + cell-index = <2>;
> + interrupt-parent = <&mpic>;
> + interrupts = <22 2>;
> + };
> + dma-channel@180 {
> + compatible = "fsl,mpc8641-dma-channel",
> + "fsl,eloplus-dma-channel";
> + reg = <0x180 0x80>;
> + cell-index = <3>;
> + interrupt-parent = <&mpic>;
> + interrupts = <23 2>;
> + };
> + };
> +
> + mdio@24520 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "mdio";
> + compatible = "fsl,gianfar-mdio";
> + reg = <0x00024520 0x00000020>;
> +
> + phy0: ethernet-phy@0 {
> + interrupt-parent = <&mpic>;
> + interrupts = <0x0 0x1>;
> + reg = <0x00000001>;
> + device_type = "ethernet-phy";
drop device_type
>
> + };
> + phy2: ethernet-phy@2 {
> + interrupt-parent = <&mpic>;
> + interrupts = <0x0 0x1>;
> + reg = <0x00000003>;
> + device_type = "ethernet-phy";
> + };
ditto
>
> + };
> +
> + ethernet@24000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <0x00024000 0x00001000>;
> + mac-address = [ 00 00 00 00 00 00 ]; // set by u-boot
> + interrupts = <0x1d 0x2 0x1e 0x2 0x22 0x2>;
> + interrupt-parent = <&mpic>;
> + phy-handle = <&phy0>;
> + phy-connection-type = "gmii";
> + };
> +
> + ethernet@26000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <0x00026000 0x00001000>;
> + mac-address = [ 00 00 00 00 00 00 ]; // set by u-boot
> + interrupts = <0x1f 0x2 0x20 0x2 0x21 0x2>;
> + interrupt-parent = <&mpic>;
> + phy-handle = <&phy2>;
> + phy-connection-type = "gmii";
> + };
> +
> + serial0: serial@4500 {
> + cell-index = <0>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <0x00004500 0x00000100>;
> + clock-frequency = <0>;
> + interrupts = <0x2a 0x2>;
> + interrupt-parent = <&mpic>;
> + };
> +
> + serial1: serial@4600 {
> + cell-index = <1>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <0x00004600 0x00000100>;
> + clock-frequency = <0>;
> + interrupts = <0x1c 0x2>;
> + interrupt-parent = <&mpic>;
> + };
> +
> + mpic: pic@40000 {
> + clock-frequency = <0>;
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + reg = <0x00040000 0x00040000>;
> + built-in;
> + compatible = "chrp,open-pic";
> + device_type = "open-pic";
> + big-endian;
> + };
> +
> + global-utilities@e0000 {
> + compatible = "fsl,mpc8641-guts";
> + reg = <0x000e0000 0x00001000>;
> + fsl,has-rstcr;
> + };
> +
> + };
> +
> + pcie@fef08000 {
> + compatible = "fsl,mpc8641-pcie";
> + device_type = "pci";
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + reg = <0xfef08000 0x00001000>;
> + bus-range = <0x0 0xff>;
> + ranges = <0x02000000 0x0 0x80000000 0x80000000 0x0 0x40000000
> + 0x01000000 0x0 0x00000000 0xfe000000 0x0 0x00400000>;
> + clock-frequency = <33333333>;
> + interrupt-parent = <&mpic>;
> + interrupts = <0x18 0x2>;
> + interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
> + interrupt-map = <
> + 0x0000 0x0 0x0 0x1 &mpic 0x0 0x1
> + 0x0000 0x0 0x0 0x2 &mpic 0x1 0x1
> + 0x0000 0x0 0x0 0x3 &mpic 0x2 0x1
> + 0x0000 0x0 0x0 0x4 &mpic 0x3 0x1
> + >;
> +
You need the pcie@0 sub node to represent the virtual P2P bridge.
>
> + };
> +
> +};
- k
^ permalink raw reply
* Re: facing problem with io_p2v() function
From: Olof Johansson @ 2008-08-21 20:00 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <18965524.post@talk.nabble.com>
On Wed, Aug 13, 2008 at 08:31:28AM -0700, Misbah khan wrote:
> Below is the error message
The below panic is not from a powerpc system, it looks like it might
be from ARM. I suggest you find an ARM embedded list to ask these
questions on.
-Olof
^ permalink raw reply
* Re: [RFC][PATCH] I2C driver
From: Stefan Roese @ 2008-08-21 19:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sean MacLennan
In-Reply-To: <20080821132731.47a2f49a@lappy.seanm.ca>
On Thursday 21 August 2008, Sean MacLennan wrote:
> On Thu, 21 Aug 2008 13:06:24 -0400
>
> "Steven A. Falco" <sfalco@harris.com> wrote:
> > However, while the i2c-ibm_of.c driver works with the sequoia .dts,
> > i2c-ibm_iic.c does not, because it is looking for an "index" property,
> > which is not in the .dts file. I added one:
>
> I don't know where i2c-ibm_of.c came from....
It's a temporary DENX version for arch/powerpc which we created, since it took
too long to get something accepted upstream (I remember endless discussions
about index properties...). And we needed something functional quite a while
ago.
> but in the 2.6.26 kernel
> you need the index property.
>
> The 2.6.27 kernel has a fully OF aware i2c-ibm_iic driver. You do
> not need the index. And it will walk the device tree and setup the
> devices for you.
Yes. Since 2.6.27 the "original" IBM I2C driver should be enough. We will drop
our local special version soon.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* [PATCH] 85xx: fix build warning, remove silly cast
From: Becky Bruce @ 2008-08-21 18:50 UTC (permalink / raw)
To: linuxppc-dev
This fixes a build warning when PHYS_64BIT is enabled, and
removes an unnecessary cast to phys_addr_t (the variable
being cast is already a phys_addr_t)
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
---
arch/powerpc/mm/fsl_booke_mmu.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index ce10e2b..23cee39 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -202,7 +202,7 @@ adjust_total_lowmem(void)
cam_max_size = max_lowmem_size;
/* adjust lowmem size to max_lowmem_size */
- ram = min(max_lowmem_size, (phys_addr_t)total_lowmem);
+ ram = min(max_lowmem_size, total_lowmem);
/* Calculate CAM values */
__cam0 = 1UL << 2 * (__ilog2(ram) / 2);
@@ -225,7 +225,8 @@ adjust_total_lowmem(void)
printk(KERN_INFO "Memory CAM mapping: CAM0=%ldMb, CAM1=%ldMb,"
" CAM2=%ldMb residual: %ldMb\n",
__cam0 >> 20, __cam1 >> 20, __cam2 >> 20,
- (total_lowmem - __cam0 - __cam1 - __cam2) >> 20);
+ (long int)((total_lowmem - __cam0 - __cam1 - __cam2)
+ >> 20));
__max_low_memory = __cam0 + __cam1 + __cam2;
__initial_memory_limit_addr = memstart_addr + __max_low_memory;
}
--
1.5.5.1
^ permalink raw reply related
* Re: Strange behavior with I2C on Sequoia board
From: Wolfgang Denk @ 2008-08-21 18:45 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, Stefan Roese, Sean MacLennan
In-Reply-To: <48AD5FD1.1090809@ru.mvista.com>
Dear Valentine Barshak,
In message <48AD5FD1.1090809@ru.mvista.com> you wrote:
>
> U-boot thinks that all memory above the first 8MB is out of reach for
> the kernel and puts kernel bootargs and boardinfo structure below 8MB as
> close as possible to this limit. Including the i2c driver into the
> kernel increases the kernel image size. So when u-boot unpacks the
> kernel to 0x400000 (Load Address: 00400000) it overwrites the kernel
> parameters. So when the kernel actually starts, it reads zeros instead
> of boardinfo (and mac addresses)
>
> The 8MB limit is set for all AMCC boards in include/configs/amcc-common.h:
> #define CFG_BOOTMAPSZ (8 << 20) /* Initial Memory map for Linux */
See also the initrd_high environment variable to adjust the limits
without need for recompiling U-Boot.
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
The complexity of software is an essential property, not an acciden-
tal one. Hence, descriptions of a software entity that abstract away
its complexity often abstract away its essence. - Fred Brooks, Jr.
^ permalink raw reply
* Re: Strange behavior with I2C on Sequoia board
From: Wolfgang Denk @ 2008-08-21 18:45 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Stefan Roese, linuxppc-dev, Sean MacLennan
In-Reply-To: <Pine.LNX.4.64.0808211630170.20704@vixen.sonytel.be>
Dear Geert,
In message <Pine.LNX.4.64.0808211630170.20704@vixen.sonytel.be> you wrote:
>
> Can you actually boot a plain uImage from U-Boot?
yes, of course you can (you will need a device tree, too).
> I've just gave it a try. While arch/powerpc/boot/cuImage.sequoia boots fine,
> after `make uImage', I get arch/powerpc/boot/uImage, but it doesn't boot:
>
> | ## Booting image at 00100000 ...
> | Image Name: Linux-2.6.27-rc4-dirty
> | Image Type: PowerPC Linux Kernel Image (gzip compressed)
> | Data Size: 1398827 Bytes = 1.3 MB
> | Load Address: 00000000
> | Entry Point: 00000000
> | Verifying Checksum ... OK
> | Uncompressing Kernel Image ... Error: inflate() returned -3
> | GUNZIP ERROR - must RESET board to recover
> |
> | U-Boot 1.2.0-gc0c292b2 (Jun 5 2007 - 07:16:12)
>
> and I'm back to U-Boot...
See the FAQ: http://www.denx.de/wiki/view/DULG/LinuxUncompressingError
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
A conservative is a man who believes that nothing should be done for
the first time. - Alfred E. Wiggam
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Board support for GE Fanuc SBC610
From: Scott Wood @ 2008-08-21 18:38 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, Martyn Welch, paulus
In-Reply-To: <48ADB153.20208@freescale.com>
Jon Loeliger wrote:
>> + mpic: pic@40000 {
>> + clock-frequency = <0>;
>> + interrupt-controller;
>> + #address-cells = <0>;
>> + #interrupt-cells = <2>;
>> + reg = <0x00040000 0x00040000>;
>> + built-in;
>> + compatible = "chrp,open-pic";
>> + device_type = "open-pic";
>> + big-endian;
>
> IIRC, we dropped "big-endian" too. (?)
And "built-in".
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Board support for GE Fanuc SBC610
From: Jon Loeliger @ 2008-08-21 18:17 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080821144144.fed06908.martyn.welch@gefanuc.com>
Martyn Welch wrote:
> Support for the SBC610 VPX Single Board Computer from GE Fanuc (PowerPC
> MPC8641D).
>
> This is the basic board support for GE Fanuc's SBC610, a 6U single board
> computer, based on Freescale's MPC8641D.
>
> Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
> ---
>
> arch/powerpc/boot/dts/gef_sbc610.dts | 268 ++++++++++++++++++++++++++++++
> arch/powerpc/platforms/86xx/Kconfig | 9 +
> arch/powerpc/platforms/86xx/Makefile | 1
> arch/powerpc/platforms/86xx/gef_sbc610.c | 187 +++++++++++++++++++++
> 4 files changed, 464 insertions(+), 1 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/gef_sbc610.dts
> create mode 100644 arch/powerpc/platforms/86xx/gef_sbc610.c
>
>
> + soc8641@fef00000 {
No "8641" in this name, please.
Oh, and drop the ""32-bit" in the CPU sections too.
> + ecc@2000 {
> + device_type = "dram-controller";
Hmmm, I suspect that should be dropped.
> + compatible = "mpc86xx";
And that changed to indicate some form of controller thing.
Using "mpc86xx" here is just not right at all.
> +
> + serial0: serial@4500 {
> + cell-index = <0>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <0x00004500 0x00000100>;
> + clock-frequency = <0>;
> + interrupts = <0x2a 0x2>;
> + interrupt-parent = <&mpic>;
> + };
> +
> + serial1: serial@4600 {
> + cell-index = <1>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <0x00004600 0x00000100>;
> + clock-frequency = <0>;
> + interrupts = <0x1c 0x2>;
> + interrupt-parent = <&mpic>;
> + };
There's some form of indenting issue there...
> + mpic: pic@40000 {
> + clock-frequency = <0>;
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + reg = <0x00040000 0x00040000>;
> + built-in;
> + compatible = "chrp,open-pic";
> + device_type = "open-pic";
> + big-endian;
IIRC, we dropped "big-endian" too. (?)
> diff --git a/arch/powerpc/platforms/86xx/gef_sbc610.c b/arch/powerpc/platforms/86xx/gef_sbc610.c
> new file mode 100644
> index 0000000..6b92876
> --- /dev/null
> +++ b/arch/powerpc/platforms/86xx/gef_sbc610.c
> @@ -0,0 +1,187 @@
> +
> +/*
> + * Based on: mpc86xx_hpcn.c
> + *
> + * MPC86xx HPCN board specific routines
> + *
> + * Recode: ZHANG WEI <wei.zhang@freescale.com>
> + * Initial author: Xianghua Xiao <x.xiao@freescale.com>
> + *
> + * Copyright 2006 Freescale Semiconductor Inc.
> + *
> + */
This seems misleading some. Sure, state your attributions
and derivation sources, but this also still looks like it
is stating that it *is* the MPC86xx HPCN board code.
Thanks,
jdl
^ permalink raw reply
* Re: [RFC][PATCH] I2C driver
From: Sean MacLennan @ 2008-08-21 17:27 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev
In-Reply-To: <48ADA090.8020100@harris.com>
On Thu, 21 Aug 2008 13:06:24 -0400
"Steven A. Falco" <sfalco@harris.com> wrote:
> However, while the i2c-ibm_of.c driver works with the sequoia .dts,
> i2c-ibm_iic.c does not, because it is looking for an "index" property,
> which is not in the .dts file. I added one:
I don't know where i2c-ibm_of.c came from.... but in the 2.6.26 kernel
you need the index property.
The 2.6.27 kernel has a fully OF aware i2c-ibm_iic driver. You do
not need the index. And it will walk the device tree and setup the
devices for you.
Cheers,
Sean
^ permalink raw reply
* Re: [RFC][PATCH] I2C driver
From: Josh Boyer @ 2008-08-21 17:17 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev
In-Reply-To: <48ADA090.8020100@harris.com>
On Thu, 21 Aug 2008 13:06:24 -0400
"Steven A. Falco" <sfalco@harris.com> wrote:
> Josh Boyer wrote:
> > On Thu, 2008-08-21 at 12:21 -0400, Steven A. Falco wrote:
> >> The following patch enables building the I2C driver for 4xx chips.
> >> Tested on a Sequoia board. Comments invited.
> >>
> >> Signed-off-by: Steven A. Falco <sfalco@harris.com>
> >> ---
> >> drivers/i2c/busses/Kconfig | 7 +++++++
> >> drivers/i2c/busses/i2c-ibm_of.c | 5 ++---
> >> 2 files changed, 9 insertions(+), 3 deletions(-)
> >
> > That file doesn't even exist in the mainline kernel:
> >
> > [jwboyer@yoda linux-2.6]$ find drivers/i2c/ -name *ibm*
> > drivers/i2c/busses/i2c-ibm_iic.c
> > drivers/i2c/busses/i2c-ibm_iic.h
> > [jwboyer@yoda linux-2.6]$
> >
> > josh
> >
> >
>
> Interesting. Ok - I found the problem with the driver you *did* find:
.26 doesn't have what can be considered awesome i2c support. But the
latest git trees are much better. See git commits:
d3dc685eb5ef64aa695dabb74f00440ec3ab6796
and
b1204e6ec16468ebf89d9d818bfe425ca7adcdf3
They deal with the problems you highlighted with the listing and index
stuff. There might be more issues outstanding, but using the latest
kernel is going to get you better support and prevent you from finding
problems that are already fixed :)
josh
^ permalink raw reply
* Re: [RFC][PATCH] I2C driver
From: Steven A. Falco @ 2008-08-21 17:06 UTC (permalink / raw)
To: jwboyer; +Cc: linuxppc-dev
In-Reply-To: <1219336202.26429.55.camel@jdub.homelinux.org>
Josh Boyer wrote:
> On Thu, 2008-08-21 at 12:21 -0400, Steven A. Falco wrote:
>> The following patch enables building the I2C driver for 4xx chips.
>> Tested on a Sequoia board. Comments invited.
>>
>> Signed-off-by: Steven A. Falco <sfalco@harris.com>
>> ---
>> drivers/i2c/busses/Kconfig | 7 +++++++
>> drivers/i2c/busses/i2c-ibm_of.c | 5 ++---
>> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> That file doesn't even exist in the mainline kernel:
>
> [jwboyer@yoda linux-2.6]$ find drivers/i2c/ -name *ibm*
> drivers/i2c/busses/i2c-ibm_iic.c
> drivers/i2c/busses/i2c-ibm_iic.h
> [jwboyer@yoda linux-2.6]$
>
> josh
>
>
Interesting. Ok - I found the problem with the driver you *did* find:
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
index 85dbf34..569161d 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -989,6 +989,7 @@ static int __devexit iic_remove(struct of_device *ofdev)
static const struct of_device_id ibm_iic_match[] = {
{ .compatible = "ibm,iic-405ex", },
{ .compatible = "ibm,iic-405gp", },
+ { .compatible = "ibm,iic-440epx", },
{ .compatible = "ibm,iic-440gp", },
{ .compatible = "ibm,iic-440gpx", },
{ .compatible = "ibm,iic-440grx", },
However, while the i2c-ibm_of.c driver works with the sequoia .dts,
i2c-ibm_iic.c does not, because it is looking for an "index" property,
which is not in the .dts file. I added one:
diff --git a/arch/powerpc/boot/dts/sequoia.dts b/arch/powerpc/boot/dts/sequoia.dts
index 72d6756..538aadb 100644
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -248,6 +248,7 @@
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
interrupts = <2 4>;
+ index = <0>;
};
IIC1: i2c@ef600800 {
@@ -255,6 +256,7 @@
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
interrupts = <7 4>;
+ index = <1>;
};
ZMII0: emac-zmii@ef600d00 {
However, something is still not right. Using the mystery i2c-ibm_of.c
driver, I get:
i2c /dev entries driver
IBM IIC driver v2.1
m41t80_probe called
rtc-m41t80 0-0068: chip found, driver version 0.05
rtc-m41t80 0-0068: rtc core: registered m41t80 as rtc0
ibm-iic(/plb/opb/i2c@ef600700): using standard (100 kHz) mode
ibm-iic(/plb/opb/i2c@ef600800): using standard (100 kHz) mode
But with the i2c-ibm_iic.c driver, I get:
i2c /dev entries driver
ibm-iic 1ef600700.i2c: using standard (100 kHz) mode
ibm-iic 1ef600800.i2c: using standard (100 kHz) mode
I.e. it doesn't find the rtc (which I added to my sequoia board).
Steve
^ permalink raw reply related
* Re: boot cuImage on an old u-boot
From: Scott Wood @ 2008-08-21 16:15 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: linuxppc-dev
In-Reply-To: <20080820150958.GA23294@Chamillionaire.breakpoint.cc>
On Wed, Aug 20, 2008 at 05:09:58PM +0200, Sebastian Siewior wrote:
> I have here a mpc8540ads board and a u-boot 1.0.0. I've build the
> defconfig for the board and I tried to boot the genarated
> cuImage.mpc8540ads image. After the bootm command I see just
>
> |8540> bootm 1000000
> |## Booting image at 01000000 ...
> | Image Name: Linux-2.6.26
> | Image Type: PowerPC Linux Kernel Image (gzip compressed)
> | Data Size: 1232711 Bytes = 1.2 MB
> | Load Address: 00400000
> | Entry Point: 004005ac
> | Verifying Checksum ... OK
> | Uncompressing Kernel Image ... OK
> |
>
> I don't see the device tree fixups printfs, so crash happend quite
> early. Anyone an idea what I could have done wrong?
Make sure the device tree contains /chosen/linux,stdout-path.
-Scott
^ permalink raw reply
* Re: porting linux 2.6.27 to embedded powerpc board
From: Scott Wood @ 2008-08-21 16:12 UTC (permalink / raw)
To: David Jander; +Cc: Laxmikant Rashinkar, linuxppc-embedded
In-Reply-To: <200808211143.45782.david.jander@protonic.nl>
David Jander wrote:
> 4. Be sure that the device(s) necessary to produce output on your console are
> correctly placed in the DT. Also make sure that u-boot knows about it
> (#define OF_STDOUT_PATH... in your u-boot board config file)
OF_STDOUT_PATH is deprecated; you should enable
CONFIG_OF_SERIAL_VIA_ALIAS, and provide aliases in the device tree for
serial0, serial1, etc.
> 6. Remember to always specify the "rootfstype=" option on the commandline if
> booting from anything other than NFS. This was not necessary back in the
> 2.6.15-times AFAICR.
It still should not be necessary.
> 7. Boot with a device-tree (in u-boot: "bootm $addrofkernel - $addrofdtb",
> don't forget the dash if you are not using an initrd). If you don't do this,
> u-boot can't fix your DT, and the kernel probably won't find it either.
s/probably/definitely/
> 8. Be sure to use the correct version of the DTC (DT compiler) for your kernel
> (the sources are included nowadays, somewhere in arch/powerpc/boot IIRC). The
> command used to compile, should probably be something like this:
Or just use the most recent DTC.
-Scott
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Scott Wood @ 2008-08-21 16:32 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, paulus
In-Reply-To: <20080821.001012.265401427.davem@davemloft.net>
On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
> Mostly straightforward stuff _except_ for the I2C address encoding.
>
> What I2C IEEE1275 device binding was used to write that code in
> of_i2c.c? Is it some PowerPC specific thing? Was it "invented"
> by the embedded folks (I hope not)?
Yes, it was "invented". There was no documented i2c OF binding that I
could find, and AFAIR nobody came forward with examples of existing
practice at the time.
> And, furthermore, the device address is shifted up 1 bit higher
> than the Linux I2C layer expects. It includes the low direction
> bit, bit 0, so we have to shift it down by 1 bit before we give
> it to the Linux I2C layer.
Yuck.
> 2) When CONFIG_SPARC, shift the device address down by one bit before
> giving it to the Linux I2C layer.
Maybe we should distinguish by the type of I2C bus node instead.
-Scott
^ permalink raw reply
* Re: [RFC][PATCH] I2C driver
From: Josh Boyer @ 2008-08-21 16:30 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev
In-Reply-To: <48AD9610.8090205@harris.com>
On Thu, 2008-08-21 at 12:21 -0400, Steven A. Falco wrote:
> The following patch enables building the I2C driver for 4xx chips.
> Tested on a Sequoia board. Comments invited.
>
> Signed-off-by: Steven A. Falco <sfalco@harris.com>
> ---
> drivers/i2c/busses/Kconfig | 7 +++++++
> drivers/i2c/busses/i2c-ibm_of.c | 5 ++---
> 2 files changed, 9 insertions(+), 3 deletions(-)
That file doesn't even exist in the mainline kernel:
[jwboyer@yoda linux-2.6]$ find drivers/i2c/ -name *ibm*
drivers/i2c/busses/i2c-ibm_iic.c
drivers/i2c/busses/i2c-ibm_iic.h
[jwboyer@yoda linux-2.6]$
josh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox