* Re: [PATCH 2.6.27] [POWERPC] Invalidate all TLB entries in a specified range
From: Benjamin Herrenschmidt @ 2008-08-14 22:28 UTC (permalink / raw)
To: Rocky Craig; +Cc: linuxppc-dev, paulus, Linux Kernel
In-Reply-To: <48A42F1A.6080903@hp.com>
On Thu, 2008-08-14 at 07:11 -0600, Rocky Craig wrote:
> From: Rocky Craig <rocky.craig@hp.com>
>
> The apparent intent of "flush_tlbs" is to invalidate TLB entries that
> might match in the address range 0 to 0x00400000. A loop counter is
> set up at the high value and decremented by page size. However, the
> loop is only done once as the sense of the conditional branch at the
> loop end does not match the setup/decrement.
>
> Signed-off-by: Rocky Craig <rocky.craig@hp.com>
> ---
>
> Source is from 2.6.27 development, but the bug appears as far back as 2.4.0.
> The small user-space program below demonstrates the loop behavior. It was
> compiled via crosstool gcc 3.4.5 / glibc 2.3.6 for an MPC8347 target.
Heh nice, that's a bug as old as the port I would say :-)
Ben.
> int main()
> {
> long endval; // 16(r31)
>
> __asm__ __volatile__(
> " lis 10,0x40\n"
> "1: addic. 10,10,-0x1000\n"
> " bgt 1b\n"
> " stw 10,16(31)\n"); // endval
>
> printf("end value = 0x%08lx\n", endval);
> }
>
> This might win the prize for "Smallest actual code patch ever".
>
> --- a/arch/powerpc/kernel/head_32.S.orig 2008-07-24 19:25:09.000000000 -0600
> +++ a/arch/powerpc/kernel/head_32.S 2008-07-24 19:25:22.000000000 -0600
> @@ -1155,7 +1155,7 @@ flush_tlbs:
> lis r10, 0x40
> 1: addic. r10, r10, -0x1000
> tlbie r10
> - blt 1b
> + bgt 1b
> sync
> blr
>
>
>
^ permalink raw reply
* [PATCH V2] DTC: Remove support for the legacy DTS source file format.
From: Jon Loeliger @ 2008-08-14 23:02 UTC (permalink / raw)
To: devicetree-discuss; +Cc: linuxppc-dev
Now that all in-kernel-tree DTS files are properly /dts-v1/,
remove direct support for the older, un-numbered DTS
source file format.
Convert existing tests to /dts-v1/ and remove support
for the conversion tests themselves.
For now, though, the conversion tool still exists.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Bah. Forgot to eliminate the legacy BASE and
LITERAL tokens in the first version of this patch.
There's still a bit more improvement possible WRT
the initial dts_versio value and lexer state. Later.
dtc-lexer.l | 23 ----------------------
dtc-parser.y | 46 ---------------------------------------------
tests/base01.dts | 24 ++++++++++++----------
tests/empty.dts | 2 +
tests/escapes.dts | 2 +
tests/label01.dts | 38 +++++++++++++++++++-----------------
tests/references_dts0.dts | 12 ++++++----
tests/run_tests.sh | 27 +-------------------------
tests/test01.dts | 38 +++++++++++++++++++-----------------
tests/test_tree1_dts0.dts | 18 +++++++++-------
10 files changed, 75 insertions(+), 155 deletions(-)
diff --git a/dtc-lexer.l b/dtc-lexer.l
index 6f8b7dd..e12a4ef 100644
--- a/dtc-lexer.l
+++ b/dtc-lexer.l
@@ -110,29 +110,6 @@ static int pop_input_file(void);
return DT_LABEL;
}
-<INITIAL>[bodh]# {
- yylloc.file = srcpos_file;
- yylloc.first_line = yylineno;
- if (*yytext == 'b')
- yylval.cbase = 2;
- else if (*yytext == 'o')
- yylval.cbase = 8;
- else if (*yytext == 'd')
- yylval.cbase = 10;
- else
- yylval.cbase = 16;
- DPRINT("Base: %d\n", yylval.cbase);
- return DT_BASE;
- }
-
-<INITIAL>[0-9a-fA-F]+ {
- yylloc.file = srcpos_file;
- yylloc.first_line = yylineno;
- yylval.literal = strdup(yytext);
- DPRINT("Literal: '%s'\n", yylval.literal);
- return DT_LEGACYLITERAL;
- }
-
<V1>[0-9]+|0[xX][0-9a-fA-F]+ {
yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
diff --git a/dtc-parser.y b/dtc-parser.y
index b2ab562..3762181 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -55,7 +55,6 @@ static unsigned long long eval_literal(const char *s, int base, int bits);
%token DT_MEMRESERVE
%token <propnodename> DT_PROPNODENAME
%token <literal> DT_LITERAL
-%token <literal> DT_LEGACYLITERAL
%token <cbase> DT_BASE
%token <byte> DT_BYTE
%token <data> DT_STRING
@@ -67,11 +66,8 @@ static unsigned long long eval_literal(const char *s, int base, int bits);
%type <data> propdataprefix
%type <re> memreserve
%type <re> memreserves
-%type <re> v0_memreserve
-%type <re> v0_memreserves
%type <addr> addr
%type <data> celllist
-%type <cbase> cellbase
%type <cell> cellval
%type <data> bytestring
%type <prop> propdef
@@ -90,10 +86,6 @@ sourcefile:
{
the_boot_info = build_boot_info($3, $4, 0);
}
- | v0_memreserves devicetree
- {
- the_boot_info = build_boot_info($1, $2, 0);
- }
;
memreserves:
@@ -114,37 +106,11 @@ memreserve:
}
;
-v0_memreserves:
- /* empty */
- {
- $$ = NULL;
- }
- | v0_memreserve v0_memreserves
- {
- $$ = chain_reserve_entry($1, $2);
- };
- ;
-
-v0_memreserve:
- memreserve
- {
- $$ = $1;
- }
- | label DT_MEMRESERVE addr '-' addr ';'
- {
- $$ = build_reserve_entry($3, $5 - $3 + 1, $1);
- }
- ;
-
addr:
DT_LITERAL
{
$$ = eval_literal($1, 0, 64);
}
- | DT_LEGACYLITERAL
- {
- $$ = eval_literal($1, 16, 64);
- }
;
devicetree:
@@ -269,23 +235,11 @@ celllist:
}
;
-cellbase:
- /* empty */
- {
- $$ = 16;
- }
- | DT_BASE
- ;
-
cellval:
DT_LITERAL
{
$$ = eval_literal($1, 0, 32);
}
- | cellbase DT_LEGACYLITERAL
- {
- $$ = eval_literal($2, $1, 32);
- }
;
bytestring:
diff --git a/tests/base01.dts b/tests/base01.dts
index f84bc49..97a5dd5 100644
--- a/tests/base01.dts
+++ b/tests/base01.dts
@@ -1,3 +1,5 @@
+/dts-v1/;
+
/ {
model = "SomeModel";
compatible = "Nothing";
@@ -6,26 +8,26 @@
memory@0 {
device_type = "memory";
- reg = <00000000 00000000 00000000 20000000>;
+ reg = <0x00000000 0x00000000 0x00000000 0x20000000>;
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
- d10 = <d# 10>; // hex: 0xa
- d23 = <d# 23>; // hex: 0x17
- b101 = <b# 101>; // hex: 0x5
- o17 = <o# 17>; // hex: 0xf
- hd00d = <h# d00d>; // hex: 0xd00d
+ d10 = < 10>; // hex: 0xa
+ d23 = < 23>; // hex: 0x17
+ b101 = < 0x5>; // hex: 0x5
+ o17 = < 017>; // hex: 0xf
+ hd00d = < 0xd00d>; // hex: 0xd00d
// hex: 0x4d2 0x163e 0x2334 0xd80
- stuff = <d# 1234 d# 5678 d# 9012 d# 3456>;
+ stuff = < 1234 5678 9012 3456>;
- bad-d-1 = <d# abc123>; // Hrm. 0
- bad-d-2 = <d# 123456789012345>;
- bad-o-1 = <o# 891>;
- bad-o-2 = <o# 123456123456>;
+ bad-d-1 = < 0>; // Hrm. 0
+ bad-d-2 = < 123456789012345>;
+ bad-o-1 = < 00>;
+ bad-o-2 = < 0123456123456>;
};
};
diff --git a/tests/empty.dts b/tests/empty.dts
index 336d7a2..e160dad 100644
--- a/tests/empty.dts
+++ b/tests/empty.dts
@@ -1,2 +1,4 @@
+/dts-v1/;
+
/ {
};
diff --git a/tests/escapes.dts b/tests/escapes.dts
index f1b8dbc..e05ab46 100644
--- a/tests/escapes.dts
+++ b/tests/escapes.dts
@@ -1,3 +1,5 @@
+/dts-v1/;
+
/ {
compatible = "test_string_escapes";
escape-str = "nastystring: \a\b\t\n\v\f\r\\\"";
diff --git a/tests/label01.dts b/tests/label01.dts
index 372b17a..a895803 100644
--- a/tests/label01.dts
+++ b/tests/label01.dts
@@ -1,6 +1,8 @@
-/memreserve/ 1000000000000000 0000000002000000;
-memrsv2: /memreserve/ 2000000000000000-20ffffffffffffff;
-/memreserve/ 0-13;
+/dts-v1/;
+
+/memreserve/ 0x1000000000000000 0x0000000002000000;
+memrsv2: /memreserve/ 0x2000000000000000 0x0100000000000000;
+/memreserve/ 0x0000000000000000 0x0000000000000014;
/ {
model = "MyBoardName";
@@ -9,28 +11,28 @@ memrsv2: /memreserve/ 2000000000000000-20ffffffffffffff;
#size-cells = <2>;
cpus {
- linux,phandle = <1>;
+ linux,phandle = <0x1>;
#address-cells = <1>;
#size-cells = <0>;
PowerPC,970@0 {
name = "PowerPC,970";
device_type = "cpu";
- reg = <0>;
- clock-frequency = <5f5e1000>;
- timebase-frequency = <1FCA055>;
+ reg = <0x00000000>;
+ clock-frequency = <1600000000>;
+ timebase-frequency = <33333333>;
linux,boot-cpu;
- i-cache-size = <10000>;
- d-cache-size = <8000>;
+ i-cache-size = <65536>;
+ d-cache-size = <32768>;
};
PowerPC,970@1 {
name = "PowerPC,970";
device_type = "cpu";
- reg = <1>;
- clock-frequency = <5f5e1000>;
- timebase-frequency = <1FCA055>;
- i-cache-size = <10000>;
- d-cache-size = <8000>;
+ reg = <0x00000001>;
+ clock-frequency = <1600000000>;
+ timebase-frequency = <33333333>;
+ i-cache-size = <65536>;
+ d-cache-size = <32768>;
};
};
@@ -38,8 +40,8 @@ memrsv2: /memreserve/ 2000000000000000-20ffffffffffffff;
node: randomnode {
prop: string = str: "foo", str_mid: "stuffstuff\t\t\t\n\n\n" str_end: ;
blob = [byte: 0a 0b 0c 0d byte_mid: de ea ad be ef byte_end: ];
- ref = < cell: &/memory@0 0 cell_mid: ffffffff cell_end: >;
- mixed = "abc", pre: [1234] post: , gap: < aligned: a b c>;
+ ref = < cell: &{/memory@0} 0x0 cell_mid: 0xffffffff cell_end: >;
+ mixed = "abc", pre: [1234] post: , gap: < aligned: 0xa 0xb 0xc>;
tricky1 = [61 lt1: 62 63 00];
subnode: child {
};
@@ -49,12 +51,12 @@ memrsv2: /memreserve/ 2000000000000000-20ffffffffffffff;
memory@0 {
device_type = "memory";
- memreg: reg = <00000000 00000000 00000000 20000000>;
+ memreg: reg = <0x00000000 0x00000000 0x00000000 0x20000000>;
};
chosen {
bootargs = "root=/dev/sda2";
- linux,platform = <00000600>;
+ linux,platform = <0x600>;
};
};
diff --git a/tests/references_dts0.dts b/tests/references_dts0.dts
index df82c23..36b6f51 100644
--- a/tests/references_dts0.dts
+++ b/tests/references_dts0.dts
@@ -1,19 +1,21 @@
+/dts-v1/;
+
/ {
/* Explicit phandles */
n1: node1 {
- linux,phandle = <2000>;
- ref = <&/node2>; /* reference precedes target */
+ linux,phandle = <0x2000>;
+ ref = <&{/node2}>; /* reference precedes target */
lref = <&n2>;
};
n2: node2 {
- linux,phandle = <1>;
- ref = <&/node1>; /* reference after target */
+ linux,phandle = <0x1>;
+ ref = <&{/node1}>; /* reference after target */
lref = <&n1>;
};
/* Implicit phandles */
n3: node3 {
- ref = <&/node4>;
+ ref = <&{/node4}>;
lref = <&n4>;
};
n4: node4 {
diff --git a/tests/run_tests.sh b/tests/run_tests.sh
index eb29462..30cd9a1 100755
--- a/tests/run_tests.sh
+++ b/tests/run_tests.sh
@@ -71,13 +71,6 @@ run_dtc_test () {
base_run_test wrap_test $VALGRIND $DTC "$@"
}
-CONVERT=../convert-dtsv0
-
-run_convert_test () {
- echo -n "convert-dtsv0 $@: "
- base_run_test wrap_test $VALGRIND $CONVERT "$@"
-}
-
tree1_tests () {
TREE=$1
@@ -287,21 +280,6 @@ dtc_tests () {
run_sh_test dtc-fatal.sh -I fs -O dtb nosuchfile
}
-convert_tests () {
- V0_DTS="test_tree1_dts0.dts references_dts0.dts empty.dts escapes.dts \
- test01.dts label01.dts"
- for dts in $V0_DTS; do
- run_dtc_test -I dts -O dtb -o cvtraw_$dts.test.dtb $dts
- run_dtc_test -I dts -O dts -o cvtdtc_$dts.test.dts $dts
- run_dtc_test -I dts -O dtb -o cvtdtc_$dts.test.dtb cvtdtc_$dts.test.dts
- run_convert_test $dts
- run_dtc_test -I dts -O dtb -o cvtcvt_$dts.test.dtb ${dts}v1
-
- run_wrap_test cmp cvtraw_$dts.test.dtb cvtdtc_$dts.test.dtb
- run_wrap_test cmp cvtraw_$dts.test.dtb cvtcvt_$dts.test.dtb
- done
-}
-
while getopts "vt:m" ARG ; do
case $ARG in
"v")
@@ -317,7 +295,7 @@ while getopts "vt:m" ARG ; do
done
if [ -z "$TESTSETS" ]; then
- TESTSETS="libfdt dtc convert"
+ TESTSETS="libfdt dtc"
fi
# Make sure we don't have stale blobs lying around
@@ -331,9 +309,6 @@ for set in $TESTSETS; do
"dtc")
dtc_tests
;;
- "convert")
- convert_tests
- ;;
esac
done
diff --git a/tests/test01.dts b/tests/test01.dts
index ed2b178..f9fd165 100644
--- a/tests/test01.dts
+++ b/tests/test01.dts
@@ -1,6 +1,8 @@
-/memreserve/ 1000000000000000 0000000002000000;
-/memreserve/ 2000000000000000-20ffffffffffffff;
-/memreserve/ 0-13;
+/dts-v1/;
+
+/memreserve/ 0x1000000000000000 0x0000000002000000;
+/memreserve/ 0x2000000000000000 0x0100000000000000;
+/memreserve/ 0x0000000000000000 0x0000000000000014;
/ {
model = "MyBoardName";
@@ -9,28 +11,28 @@
#size-cells = <2>;
cpus {
- linux,phandle = <1>;
+ linux,phandle = <0x1>;
#address-cells = <1>;
#size-cells = <0>;
PowerPC,970@0 {
name = "PowerPC,970";
device_type = "cpu";
- reg = <0>;
- clock-frequency = <5f5e1000>;
- timebase-frequency = <1FCA055>;
+ reg = <0x00000000>;
+ clock-frequency = <1600000000>;
+ timebase-frequency = <33333333>;
linux,boot-cpu;
- i-cache-size = <10000>;
- d-cache-size = <8000>;
+ i-cache-size = <65536>;
+ d-cache-size = <32768>;
};
PowerPC,970@1 {
name = "PowerPC,970";
device_type = "cpu";
- reg = <1>;
- clock-frequency = <5f5e1000>;
- timebase-frequency = <1FCA055>;
- i-cache-size = <10000>;
- d-cache-size = <8000>;
+ reg = <0x00000001>;
+ clock-frequency = <1600000000>;
+ timebase-frequency = <33333333>;
+ i-cache-size = <65536>;
+ d-cache-size = <32768>;
};
};
@@ -38,18 +40,18 @@
randomnode {
string = "\xff\0stuffstuff\t\t\t\n\n\n";
blob = [0a 0b 0c 0d de ea ad be ef];
- ref = < &/memory@0 >;
- mixed = "abc", [1234], <a b c>;
+ ref = < &{/memory@0} >;
+ mixed = "abc", [1234], <0xa 0xb 0xc>;
};
memory@0 {
device_type = "memory";
- memreg: reg = <00000000 00000000 00000000 20000000>;
+ memreg: reg = <0x00000000 0x00000000 0x00000000 0x20000000>;
};
chosen {
bootargs = "root=/dev/sda2";
- linux,platform = <00000600>;
+ linux,platform = <0x600>;
};
};
diff --git a/tests/test_tree1_dts0.dts b/tests/test_tree1_dts0.dts
index bc65819..6b40cf5 100644
--- a/tests/test_tree1_dts0.dts
+++ b/tests/test_tree1_dts0.dts
@@ -1,9 +1,11 @@
-/memreserve/ deadbeef00000000-deadbeef000fffff;
-/memreserve/ 75bcd15 1000;
+/dts-v1/;
+
+/memreserve/ 0xdeadbeef00000000 0x0000000000100000;
+/memreserve/ 0x00000000075bcd15 0x0000000000001000;
/ {
compatible = "test_tree1";
- prop-int = <deadbeef>;
+ prop-int = <0xdeadbeef>;
prop-str = "hello world";
subnode@1 {
@@ -12,18 +14,18 @@
subsubnode {
compatible = "subsubnode1", "subsubnode";
- prop-int = <h# deadbeef>;
+ prop-int = < 0xdeadbeef>;
};
};
subnode@2 {
- linux,phandle = <2000>;
- prop-int = <d# 123456789>;
+ linux,phandle = <0x2000>;
+ prop-int = < 123456789>;
subsubnode@0 {
- linux,phandle = <2001>;
+ linux,phandle = <0x2001>;
compatible = "subsubnode2", "subsubnode";
- prop-int = <o# 0726746425>;
+ prop-int = < 0726746425>;
};
};
};
--
1.5.6
^ permalink raw reply related
* Re: [PATCH 1/2] port ndfc driver to of platform
From: Sean MacLennan @ 2008-08-14 23:10 UTC (permalink / raw)
Cc: linuxppc-dev, dwmw2, Arnd Bergmann
In-Reply-To: <20080814165422.62339a5f@lappy.seanm.ca>
Port the ndfc driver to an OF platform driver.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 41f361c..ab0d77e 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -165,7 +165,7 @@ config MTD_NAND_S3C2410_HWECC
config MTD_NAND_NDFC
tristate "NDFC NanD Flash Controller"
- depends on 4xx && !PPC_MERGE
+ depends on 4xx
select MTD_NAND_ECC_SMC
help
NDFC Nand Flash Controllers are integrated in IBM/AMCC's 4xx SoCs
diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 955959e..75a3bf0 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -5,9 +5,13 @@
* Platform independend driver for NDFC (NanD Flash Controller)
* integrated into EP440 cores
*
+ * Ported to an OF platform driver by Sean MacLennan
+ *
* Author: Thomas Gleixner
*
* Copyright 2006 IBM
+ * Copyright 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
*
* 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
@@ -21,27 +25,17 @@
#include <linux/mtd/partitions.h>
#include <linux/mtd/ndfc.h>
#include <linux/mtd/mtd.h>
-#include <linux/platform_device.h>
-
+#include <linux/of_platform.h>
#include <asm/io.h>
-#ifdef CONFIG_40x
-#include <asm/ibm405.h>
-#else
-#include <asm/ibm44x.h>
-#endif
-
-struct ndfc_nand_mtd {
- struct mtd_info mtd;
- struct nand_chip chip;
- struct platform_nand_chip *pl_chip;
-};
-static struct ndfc_nand_mtd ndfc_mtd[NDFC_MAX_BANKS];
struct ndfc_controller {
- void __iomem *ndfcbase;
- struct nand_hw_control ndfc_control;
- atomic_t childs_active;
+ struct of_device *ofdev;
+ void __iomem *ndfcbase;
+ struct mtd_info mtd;
+ struct nand_chip chip;
+ int chip_select;
+ struct nand_hw_control ndfc_control;
};
static struct ndfc_controller ndfc_ctrl;
@@ -50,17 +44,14 @@ static void ndfc_select_chip(struct mtd_info *mtd, int chip)
{
uint32_t ccr;
struct ndfc_controller *ndfc = &ndfc_ctrl;
- struct nand_chip *nandchip = mtd->priv;
- struct ndfc_nand_mtd *nandmtd = nandchip->priv;
- struct platform_nand_chip *pchip = nandmtd->pl_chip;
- ccr = __raw_readl(ndfc->ndfcbase + NDFC_CCR);
+ ccr = in_be32(ndfc->ndfcbase + NDFC_CCR);
if (chip >= 0) {
ccr &= ~NDFC_CCR_BS_MASK;
- ccr |= NDFC_CCR_BS(chip + pchip->chip_offset);
+ ccr |= NDFC_CCR_BS(chip + ndfc->chip_select);
} else
ccr |= NDFC_CCR_RESET_CE;
- __raw_writel(ccr, ndfc->ndfcbase + NDFC_CCR);
+ out_be32(ndfc->ndfcbase + NDFC_CCR, ccr);
}
static void ndfc_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
@@ -80,7 +71,7 @@ static int ndfc_ready(struct mtd_info *mtd)
{
struct ndfc_controller *ndfc = &ndfc_ctrl;
- return __raw_readl(ndfc->ndfcbase + NDFC_STAT) & NDFC_STAT_IS_READY;
+ return in_be32(ndfc->ndfcbase + NDFC_STAT) & NDFC_STAT_IS_READY;
}
static void ndfc_enable_hwecc(struct mtd_info *mtd, int mode)
@@ -88,9 +79,9 @@ static void ndfc_enable_hwecc(struct mtd_info *mtd, int mode)
uint32_t ccr;
struct ndfc_controller *ndfc = &ndfc_ctrl;
- ccr = __raw_readl(ndfc->ndfcbase + NDFC_CCR);
+ ccr = in_be32(ndfc->ndfcbase + NDFC_CCR);
ccr |= NDFC_CCR_RESET_ECC;
- __raw_writel(ccr, ndfc->ndfcbase + NDFC_CCR);
+ out_be32(ndfc->ndfcbase + NDFC_CCR, ccr);
wmb();
}
@@ -102,9 +93,10 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
uint8_t *p = (uint8_t *)&ecc;
wmb();
- ecc = __raw_readl(ndfc->ndfcbase + NDFC_ECC);
- ecc_code[0] = p[1];
- ecc_code[1] = p[2];
+ ecc = in_be32(ndfc->ndfcbase + NDFC_ECC);
+ /* The NDFC uses Smart Media (SMC) bytes order */
+ ecc_code[0] = p[2];
+ ecc_code[1] = p[1];
ecc_code[2] = p[3];
return 0;
@@ -123,7 +115,7 @@ static void ndfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
uint32_t *p = (uint32_t *) buf;
for(;len > 0; len -= 4)
- *p++ = __raw_readl(ndfc->ndfcbase + NDFC_DATA);
+ *p++ = in_be32(ndfc->ndfcbase + NDFC_DATA);
}
static void ndfc_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
@@ -132,7 +124,7 @@ static void ndfc_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
uint32_t *p = (uint32_t *) buf;
for(;len > 0; len -= 4)
- __raw_writel(*p++, ndfc->ndfcbase + NDFC_DATA);
+ out_be32(ndfc->ndfcbase + NDFC_DATA, *p++);
}
static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
@@ -141,7 +133,7 @@ static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
uint32_t *p = (uint32_t *) buf;
for(;len > 0; len -= 4)
- if (*p++ != __raw_readl(ndfc->ndfcbase + NDFC_DATA))
+ if (*p++ != in_be32(ndfc->ndfcbase + NDFC_DATA))
return -EFAULT;
return 0;
}
@@ -149,10 +141,19 @@ static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
/*
* Initialize chip structure
*/
-static void ndfc_chip_init(struct ndfc_nand_mtd *mtd)
+static int ndfc_chip_init(struct ndfc_controller *ndfc,
+ struct device_node *node)
{
- struct ndfc_controller *ndfc = &ndfc_ctrl;
- struct nand_chip *chip = &mtd->chip;
+#ifdef CONFIG_MTD_PARTITIONS
+#ifdef CONFIG_MTD_CMDLINE_PARTS
+ static const char *part_types[] = { "cmdlinepart", NULL };
+#else
+ static const char *part_types[] = { NULL };
+#endif
+ struct mtd_partition *parts;
+#endif
+ struct nand_chip *chip = &ndfc->chip;
+ int ret;
chip->IO_ADDR_R = ndfc->ndfcbase + NDFC_DATA;
chip->IO_ADDR_W = ndfc->ndfcbase + NDFC_DATA;
@@ -160,8 +161,6 @@ static void ndfc_chip_init(struct ndfc_nand_mtd *mtd)
chip->dev_ready = ndfc_ready;
chip->select_chip = ndfc_select_chip;
chip->chip_delay = 50;
- chip->priv = mtd;
- chip->options = mtd->pl_chip->options;
chip->controller = &ndfc->ndfc_control;
chip->read_buf = ndfc_read_buf;
chip->write_buf = ndfc_write_buf;
@@ -172,143 +171,120 @@ static void ndfc_chip_init(struct ndfc_nand_mtd *mtd)
chip->ecc.mode = NAND_ECC_HW;
chip->ecc.size = 256;
chip->ecc.bytes = 3;
- chip->ecclayout = chip->ecc.layout = mtd->pl_chip->ecclayout;
- mtd->mtd.priv = chip;
- mtd->mtd.owner = THIS_MODULE;
-}
-
-static int ndfc_chip_probe(struct platform_device *pdev)
-{
- struct platform_nand_chip *nc = pdev->dev.platform_data;
- struct ndfc_chip_settings *settings = nc->priv;
- struct ndfc_controller *ndfc = &ndfc_ctrl;
- struct ndfc_nand_mtd *nandmtd;
-
- if (nc->chip_offset >= NDFC_MAX_BANKS || nc->nr_chips > NDFC_MAX_BANKS)
- return -EINVAL;
- /* Set the bank settings */
- __raw_writel(settings->bank_settings,
- ndfc->ndfcbase + NDFC_BCFG0 + (nc->chip_offset << 2));
+ ndfc->mtd.priv = chip;
+ ndfc->mtd.owner = THIS_MODULE;
- nandmtd = &ndfc_mtd[pdev->id];
- if (nandmtd->pl_chip)
- return -EBUSY;
+ ret = nand_scan(&ndfc->mtd, 1);
+ if (ret)
+ return ret;
- nandmtd->pl_chip = nc;
- ndfc_chip_init(nandmtd);
-
- /* Scan for chips */
- if (nand_scan(&nandmtd->mtd, nc->nr_chips)) {
- nandmtd->pl_chip = NULL;
- return -ENODEV;
- }
+ ndfc->mtd.name = ndfc->ofdev->dev.bus_id;
#ifdef CONFIG_MTD_PARTITIONS
- printk("Number of partitions %d\n", nc->nr_partitions);
- if (nc->nr_partitions) {
- /* Add the full device, so complete dumps can be made */
- add_mtd_device(&nandmtd->mtd);
- add_mtd_partitions(&nandmtd->mtd, nc->partitions,
- nc->nr_partitions);
-
- } else
-#else
- add_mtd_device(&nandmtd->mtd);
+ ret = parse_mtd_partitions(&ndfc->mtd, part_types, &parts, 0);
+ if (ret < 0)
+ return ret;
+
+#ifdef CONFIG_MTD_OF_PARTS
+ if (ret == 0) {
+ ret = of_mtd_parse_partitions(&ndfc->ofdev->dev, &ndfc->mtd,
+ node, &parts);
+ if (ret < 0)
+ return ret;
+ }
#endif
- atomic_inc(&ndfc->childs_active);
- return 0;
-}
+ if (ret > 0)
+ return add_mtd_partitions(&ndfc->mtd, parts, ret);
+#endif
-static int ndfc_chip_remove(struct platform_device *pdev)
-{
- return 0;
+ return add_mtd_device(&ndfc->mtd);
}
-static int ndfc_nand_probe(struct platform_device *pdev)
+static int __devinit ndfc_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
{
- struct platform_nand_ctrl *nc = pdev->dev.platform_data;
- struct ndfc_controller_settings *settings = nc->priv;
- struct resource *res = pdev->resource;
struct ndfc_controller *ndfc = &ndfc_ctrl;
- unsigned long long phys = settings->ndfc_erpn | res->start;
+ const u32 *reg;
+ u32 ccr;
+ int err, len;
-#ifndef CONFIG_PHYS_64BIT
- ndfc->ndfcbase = ioremap((phys_addr_t)phys, res->end - res->start + 1);
-#else
- ndfc->ndfcbase = ioremap64(phys, res->end - res->start + 1);
-#endif
+ spin_lock_init(&ndfc->ndfc_control.lock);
+ init_waitqueue_head(&ndfc->ndfc_control.wq);
+ ndfc->ofdev = ofdev;
+ dev_set_drvdata(&ofdev->dev, ndfc);
+
+ /* Read the reg property to get the chip select */
+ reg = of_get_property(ofdev->node, "reg", &len);
+ if (reg == NULL || len != 12) {
+ dev_err(&ofdev->dev, "unable read reg property (%d)\n", len);
+ return -ENOENT;
+ }
+ ndfc->chip_select = reg[0];
+
+ ndfc->ndfcbase = of_iomap(ofdev->node, 0);
if (!ndfc->ndfcbase) {
- printk(KERN_ERR "NDFC: ioremap failed\n");
+ dev_err(&ofdev->dev, "failed to get memory\n");
return -EIO;
}
- __raw_writel(settings->ccr_settings, ndfc->ndfcbase + NDFC_CCR);
+ ccr = NDFC_CCR_BS(ndfc->chip_select);
- spin_lock_init(&ndfc->ndfc_control.lock);
- init_waitqueue_head(&ndfc->ndfc_control.wq);
+ /* It is ok if ccr does not exist - just default to 0 */
+ reg = of_get_property(ofdev->node, "ccr", NULL);
+ if (reg)
+ ccr |= *reg;
+
+ out_be32(ndfc->ndfcbase + NDFC_CCR, ccr);
- platform_set_drvdata(pdev, ndfc);
+ /* Set the bank settings if given */
+ reg = of_get_property(ofdev->node, "bank-settings", NULL);
+ if (reg) {
+ int offset = NDFC_BCFG0 + (ndfc->chip_select << 2);
+ out_be32(ndfc->ndfcbase + offset, *reg);
+ }
- printk("NDFC NAND Driver initialized. Chip-Rev: 0x%08x\n",
- __raw_readl(ndfc->ndfcbase + NDFC_REVID));
+ err = ndfc_chip_init(ndfc, ofdev->node);
+ if (err) {
+ iounmap(ndfc->ndfcbase);
+ return err;
+ }
return 0;
}
-static int ndfc_nand_remove(struct platform_device *pdev)
+static int __devexit ndfc_remove(struct of_device *ofdev)
{
- struct ndfc_controller *ndfc = platform_get_drvdata(pdev);
+ struct ndfc_controller *ndfc = dev_get_drvdata(&ofdev->dev);
- if (atomic_read(&ndfc->childs_active))
- return -EBUSY;
+ nand_release(&ndfc->mtd);
- if (ndfc) {
- platform_set_drvdata(pdev, NULL);
- iounmap(ndfc_ctrl.ndfcbase);
- ndfc_ctrl.ndfcbase = NULL;
- }
return 0;
}
-/* driver device registration */
-
-static struct platform_driver ndfc_chip_driver = {
- .probe = ndfc_chip_probe,
- .remove = ndfc_chip_remove,
- .driver = {
- .name = "ndfc-chip",
- .owner = THIS_MODULE,
- },
+static const struct of_device_id ndfc_match[] = {
+ { .compatible = "amcc,ndfc", },
+ {}
};
-static struct platform_driver ndfc_nand_driver = {
- .probe = ndfc_nand_probe,
- .remove = ndfc_nand_remove,
- .driver = {
- .name = "ndfc-nand",
- .owner = THIS_MODULE,
+static struct of_platform_driver ndfc_driver = {
+ .driver = {
+ .name = "ndfc",
},
+ .match_table = ndfc_match,
+ .probe = ndfc_probe,
+ .remove = __devexit_p(ndfc_remove),
};
static int __init ndfc_nand_init(void)
{
- int ret;
-
- spin_lock_init(&ndfc_ctrl.ndfc_control.lock);
- init_waitqueue_head(&ndfc_ctrl.ndfc_control.wq);
-
- ret = platform_driver_register(&ndfc_nand_driver);
- if (!ret)
- ret = platform_driver_register(&ndfc_chip_driver);
- return ret;
+ return of_register_platform_driver(&ndfc_driver);
}
static void __exit ndfc_nand_exit(void)
{
- platform_driver_unregister(&ndfc_chip_driver);
- platform_driver_unregister(&ndfc_nand_driver);
+ of_unregister_platform_driver(&ndfc_driver);
}
module_init(ndfc_nand_init);
@@ -316,6 +292,4 @@ module_exit(ndfc_nand_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Thomas Gleixner <tglx@linutronix.de>");
-MODULE_DESCRIPTION("Platform driver for NDFC");
-MODULE_ALIAS("platform:ndfc-chip");
-MODULE_ALIAS("platform:ndfc-nand");
+MODULE_DESCRIPTION("OF Platform driver for NDFC");
^ permalink raw reply related
* Re: [PATCH 2/2] port ndfc driver to of platform
From: Sean MacLennan @ 2008-08-14 23:20 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <200808141208.57345.arnd@arndb.de>
The only real change from the last version was the updating of the dts
to use the chip select and offset for the NAND address rather than the
chip select and address.
Cheers,
Sean
Changes to the warp platform with the ndfc as an of platform device.
The main changes are:
* moving the NAND information to the DTS
* removing warp-nand.c
* moving the NAND fixups to cuboot-warp.c
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/boot/cuboot-warp.c b/arch/powerpc/boot/cuboot-warp.c
index 2178021..6d20a46 100644
--- a/arch/powerpc/boot/cuboot-warp.c
+++ b/arch/powerpc/boot/cuboot-warp.c
@@ -34,10 +34,30 @@ static void warp_fixup_one_nor(u32 from, u32 to)
v[0] = to;
setprop(devp, "reg", v, sizeof(v));
- printf("NOR 64M fixup %x -> %x\r\n", from, to);
+ printf("NOR 64M fixup %x -> %x\r\n", from, to);
}
}
+static void warp_fixup_one_nand(u32 from, u32 to, u32 size)
+{
+ void *devp;
+ char name[50];
+ u32 v[2];
+
+ sprintf(name, "/plb/opb/ebc/nand_flash@1,d0000000/partition@%x", from);
+
+ devp = finddevice(name);
+ if (!devp)
+ return;
+
+ if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
+ v[0] = to;
+ v[1] = size;
+ setprop(devp, "reg", v, sizeof(v));
+
+ printf("NAND 64M fixup %x -> %x\r\n", from, to);
+ }
+}
static void warp_fixups(void)
{
@@ -46,25 +66,39 @@ static void warp_fixups(void)
ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
- /* Fixup for 64M flash on Rev A boards. */
+ /* Fixup flash on Rev A boards. */
if (bd.bi_flashsize == 0x4000000) {
void *devp;
u32 v[3];
+ /* NOR */
devp = finddevice("/plb/opb/ebc/nor_flash@0,0");
- if (!devp)
- return;
-
- /* Fixup the size */
- if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
- v[2] = bd.bi_flashsize;
- setprop(devp, "reg", v, sizeof(v));
+ if (devp) {
+ /* Fixup the size */
+ if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
+ v[2] = bd.bi_flashsize;
+ setprop(devp, "reg", v, sizeof(v));
+ }
+
+ /* Fixup parition offsets */
+ warp_fixup_one_nor(0x300000, 0x3f00000);
+ warp_fixup_one_nor(0x340000, 0x3f40000);
+ warp_fixup_one_nor(0x380000, 0x3f80000);
}
- /* Fixup parition offsets */
- warp_fixup_one_nor(0x300000, 0x3f00000);
- warp_fixup_one_nor(0x340000, 0x3f40000);
- warp_fixup_one_nor(0x380000, 0x3f80000);
+ /* NAND */
+ devp = finddevice("/plb/opb/ebc/nand_flash@1,d0000000");
+ if (devp) {
+ /* Fixup the size */
+ if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
+ v[2] = bd.bi_flashsize;
+ setprop(devp, "reg", v, sizeof(v));
+ }
+
+ /* Fixup parition offsets */
+ warp_fixup_one_nand(0x00200000, 0x0200000, 0x3000000);
+ warp_fixup_one_nand(0x40000000, 0x3200000, 0x0e00000);
+ }
}
}
diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts
index f4e4ba6..ffff81a 100644
--- a/arch/powerpc/boot/dts/warp.dts
+++ b/arch/powerpc/boot/dts/warp.dts
@@ -155,6 +155,11 @@
reg = <0x00000000 0x00000000 0x00400000>;
#address-cells = <1>;
#size-cells = <1>;
+
+ partition@0 {
+ label = "splash";
+ reg = <0x00000000 0x00020000>;
+ };
partition@300000 {
label = "fpga";
reg = <0x0300000 0x00040000>;
@@ -168,6 +173,36 @@
reg = <0x0380000 0x00080000>;
};
};
+
+ nand_flash@1,0 {
+ compatible = "amcc,ndfc";
+ reg = <0x00000001 0x00000000 0x00002000>;
+ ccr = <0x00001000>;
+ bank-settings = <0x80002222>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "kernel";
+ reg = <0x00000000 0x00200000>;
+ };
+ partition@200000 {
+ label = "root";
+ reg = <0x00200000 0x03E00000>;
+ };
+ partition@40000000 {
+ label = "persistent";
+ reg = <0x04000000 0x04000000>;
+ };
+ partition@80000000 {
+ label = "persistent1";
+ reg = <0x08000000 0x04000000>;
+ };
+ partition@C0000000 {
+ label = "persistent2";
+ reg = <0x0C000000 0x04000000>;
+ };
+ };
};
UART0: serial@ef600300 {
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index 8d0b1a1..53fc7ec 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -8,6 +8,5 @@ obj-$(CONFIG_SEQUOIA) += sequoia.o
obj-$(CONFIG_KATMAI) += katmai.o
obj-$(CONFIG_RAINIER) += rainier.o
obj-$(CONFIG_WARP) += warp.o
-obj-$(CONFIG_WARP) += warp-nand.o
obj-$(CONFIG_CANYONLANDS) += canyonlands.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
diff --git a/arch/powerpc/platforms/44x/warp-nand.c b/arch/powerpc/platforms/44x/warp-nand.c
deleted file mode 100644
index 89ecd76..0000000
--- a/arch/powerpc/platforms/44x/warp-nand.c
+++ /dev/null
@@ -1,135 +0,0 @@
-/*
- * PIKA Warp(tm) NAND flash specific routines
- *
- * Copyright (c) 2008 PIKA Technologies
- * Sean MacLennan <smaclennan@pikatech.com>
- */
-
-#include <linux/platform_device.h>
-#include <linux/mtd/mtd.h>
-#include <linux/mtd/map.h>
-#include <linux/mtd/partitions.h>
-#include <linux/mtd/nand.h>
-#include <linux/mtd/ndfc.h>
-#include <linux/of.h>
-#include <asm/machdep.h>
-
-
-#ifdef CONFIG_MTD_NAND_NDFC
-
-#define CS_NAND_0 1 /* use chip select 1 for NAND device 0 */
-
-#define WARP_NAND_FLASH_REG_ADDR 0xD0000000UL
-#define WARP_NAND_FLASH_REG_SIZE 0x2000
-
-static struct resource warp_ndfc = {
- .start = WARP_NAND_FLASH_REG_ADDR,
- .end = WARP_NAND_FLASH_REG_ADDR + WARP_NAND_FLASH_REG_SIZE - 1,
- .flags = IORESOURCE_MEM,
-};
-
-static struct mtd_partition nand_parts[] = {
- {
- .name = "kernel",
- .offset = 0,
- .size = 0x0200000
- },
- {
- .name = "root",
- .offset = 0x0200000,
- .size = 0x3E00000
- },
- {
- .name = "persistent",
- .offset = 0x4000000,
- .size = 0x4000000
- },
- {
- .name = "persistent1",
- .offset = 0x8000000,
- .size = 0x4000000
- },
- {
- .name = "persistent2",
- .offset = 0xC000000,
- .size = 0x4000000
- }
-};
-
-struct ndfc_controller_settings warp_ndfc_settings = {
- .ccr_settings = (NDFC_CCR_BS(CS_NAND_0) | NDFC_CCR_ARAC1),
- .ndfc_erpn = 0,
-};
-
-static struct ndfc_chip_settings warp_chip0_settings = {
- .bank_settings = 0x80002222,
-};
-
-struct platform_nand_ctrl warp_nand_ctrl = {
- .priv = &warp_ndfc_settings,
-};
-
-static struct platform_device warp_ndfc_device = {
- .name = "ndfc-nand",
- .id = 0,
- .dev = {
- .platform_data = &warp_nand_ctrl,
- },
- .num_resources = 1,
- .resource = &warp_ndfc,
-};
-
-/* Do NOT set the ecclayout: let it default so it is correct for both
- * 64M and 256M flash chips.
- */
-static struct platform_nand_chip warp_nand_chip0 = {
- .nr_chips = 1,
- .chip_offset = CS_NAND_0,
- .nr_partitions = ARRAY_SIZE(nand_parts),
- .partitions = nand_parts,
- .chip_delay = 20,
- .priv = &warp_chip0_settings,
-};
-
-static struct platform_device warp_nand_device = {
- .name = "ndfc-chip",
- .id = 0,
- .num_resources = 0,
- .dev = {
- .platform_data = &warp_nand_chip0,
- .parent = &warp_ndfc_device.dev,
- }
-};
-
-static int warp_setup_nand_flash(void)
-{
- struct device_node *np;
-
- /* Try to detect a rev A based on NOR size. */
- np = of_find_compatible_node(NULL, NULL, "cfi-flash");
- if (np) {
- struct property *pp;
-
- pp = of_find_property(np, "reg", NULL);
- if (pp && (pp->length == 12)) {
- u32 *v = pp->value;
- if (v[2] == 0x4000000) {
- /* Rev A = 64M NAND */
- warp_nand_chip0.nr_partitions = 3;
-
- nand_parts[1].size = 0x3000000;
- nand_parts[2].offset = 0x3200000;
- nand_parts[2].size = 0x0e00000;
- }
- }
- of_node_put(np);
- }
-
- platform_device_register(&warp_ndfc_device);
- platform_device_register(&warp_nand_device);
-
- return 0;
-}
-machine_device_initcall(warp, warp_setup_nand_flash);
-
-#endif
^ permalink raw reply related
* Re: [PATCH V2] DTC: Remove support for the legacy DTS source file format.
From: David Gibson @ 2008-08-15 0:29 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <E1KTlq7-0005Gh-Co@jdl.com>
On Thu, Aug 14, 2008 at 06:02:43PM -0500, Jon Loeliger wrote:
> Now that all in-kernel-tree DTS files are properly /dts-v1/,
> remove direct support for the older, un-numbered DTS
> source file format.
Um.. why? I just don't see a compelling reason to remove this
backwards compatibility. It costs us very little to keep it around
indefinitely.
> Convert existing tests to /dts-v1/ and remove support
> for the conversion tests themselves.
>
> For now, though, the conversion tool still exists.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH v3] libfdt: Add support for using aliases in fdt_path_offset()
From: David Gibson @ 2008-08-15 1:34 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <20080814174348.GA19488@ld0162-tx32.am.freescale.net>
On Thu, Aug 14, 2008 at 12:43:48PM -0500, Scott Wood wrote:
> On Thu, Aug 14, 2008 at 08:28:19AM -0500, Kumar Gala wrote:
> > - if (*path != '/')
> > - return -FDT_ERR_BADPATH;
> > + /* see if we have an alias */
> > + if (*path != '/') {
> > + const char *q;
> > + int aliasoffset = fdt_path_offset(fdt, "/aliases");
> > +
> > + if (aliasoffset < 0)
> > + return -FDT_ERR_BADPATH;
> > +
> > + q = strchr(path, '/');
> > + if (!q)
> > + q = end;
> > +
> > + p = fdt_getprop_namelen(fdt, aliasoffset, path, q - p, NULL);
> > + if (!p)
> > + return -FDT_ERR_BADPATH;
> > + offset = fdt_path_offset(fdt, p);
> > +
> > + p = q;
> > + }
>
> Can we limit the recursion depth to avoid falling off the stack if an
> alias points to itself? Or if aliases pointing to aliases are
> disallowed, check for a leading '/' before recursively calling
> fdt_path_offset.
Hmm.. my reading of 1275 says that an alias pointing to another alias
is not permitted, but I'm not terribly confident I'm not misreading
it. Segher, do you know whether this is allowed?
If that's the case then, yes, we should not recurse if the alias value
doesn't start with a /. In fact, if I factor out a fdt_get_alias()
function, it should probably check the alias and return an error if
it's not an absolute path.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH v3] libfdt: Add support for using aliases in fdt_path_offset()
From: Mitch Bradley @ 2008-08-15 1:51 UTC (permalink / raw)
To: Scott Wood, Kumar Gala, linuxppc-dev, devicetree-discuss
In-Reply-To: <20080815013439.GB12327@yookeroo.seuss>
David Gibson wrote:
> On Thu, Aug 14, 2008 at 12:43:48PM -0500, Scott Wood wrote:
>
>> On Thu, Aug 14, 2008 at 08:28:19AM -0500, Kumar Gala wrote:
>>
>>> - if (*path != '/')
>>> - return -FDT_ERR_BADPATH;
>>> + /* see if we have an alias */
>>> + if (*path != '/') {
>>> + const char *q;
>>> + int aliasoffset = fdt_path_offset(fdt, "/aliases");
>>> +
>>> + if (aliasoffset < 0)
>>> + return -FDT_ERR_BADPATH;
>>> +
>>> + q = strchr(path, '/');
>>> + if (!q)
>>> + q = end;
>>> +
>>> + p = fdt_getprop_namelen(fdt, aliasoffset, path, q - p, NULL);
>>> + if (!p)
>>> + return -FDT_ERR_BADPATH;
>>> + offset = fdt_path_offset(fdt, p);
>>> +
>>> + p = q;
>>> + }
>>>
>> Can we limit the recursion depth to avoid falling off the stack if an
>> alias points to itself? Or if aliases pointing to aliases are
>> disallowed, check for a leading '/' before recursively calling
>> fdt_path_offset.
>>
>
> Hmm.. my reading of 1275 says that an alias pointing to another alias
> is not permitted, but I'm not terribly confident I'm not misreading
> it. Segher, do you know whether this is allowed?
>
The 1275 spec doesn't require multiple levels of aliasing, but my
current implementation allows it and uses it for things like components
of the network stack.
> If that's the case then, yes, we should not recurse if the alias value
> doesn't start with a /. In fact, if I factor out a fdt_get_alias()
> function, it should probably check the alias and return an error if
> it's not an absolute path.
>
>
^ permalink raw reply
* Re: oops in proc_sys_compare
From: Al Viro @ 2008-08-15 4:51 UTC (permalink / raw)
To: Hugh Dickins; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0808141908290.15191@blonde.site>
On Thu, Aug 14, 2008 at 07:31:06PM +0100, Hugh Dickins wrote:
> I got this oops below, after several hours of swap-heavy kernel builds
> in tmpfs, on 2.6.27-rc1-mm1 a couple of weeks ago. Tried to reproduce
> it without success, then got a very similar trace (not saved) from
> 2.6.27-rc3 itself doing the same test yesterday: again oopsing in
> proc_sys_compare on address -16, looks like it's trying for
> PROC_I(dentry->d_inode)->sysctl but d_inode is NULL.
>
> I looked to see what's been going on in fs/proc recently, and your
> [PATCH] sanitize proc_sysctl 9043476f726802f4b00c96d0c4f418dde48d1304
> does sound like it might be implicated. I've only seen this on
> PowerPC G5, similar tests on x86_32 and _64 haven't shown it:
> maybe a memory barrier needed somewhere?
Bloody interesting. We never create negative hashed dentries in there and
AFAICS we should never get d_delete() called on those... Missing barrier
would mean serious trouble in dcache.c and not just for /proc/sys...
Are you sure about oops decoding? At least disassembly of proc_sys_compare()
in the kernel image in question would be nice to see...
^ permalink raw reply
* Re: [PATCH 2/2] port ndfc driver to of platform
From: Sean MacLennan @ 2008-08-15 5:24 UTC (permalink / raw)
Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <20080814192009.0a06eccb@lappy.seanm.ca>
Hopefully the last change. I decided to remove all the rev A fixups
from the cuboot-warp file. I am the only person using a rev A, and I
can use the command line to specify any needed partitions. There is
really only one partition needed to boot from nand since u-boot can be
used to flash the images.
Note the patch is now smaller since we don't need the NAND fixups!
Cheers,
Sean
Changes to the warp platform with the ndfc as an of platform device.
The main changes are:
* move the NAND information to the DTS
* remove warp-nand.c
* remove rev A fixups from cuboot-warp.c
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/boot/cuboot-warp.c b/arch/powerpc/boot/cuboot-warp.c
index 2178021..806df69 100644
--- a/arch/powerpc/boot/cuboot-warp.c
+++ b/arch/powerpc/boot/cuboot-warp.c
@@ -18,57 +18,14 @@
static bd_t bd;
-static void warp_fixup_one_nor(u32 from, u32 to)
-{
- void *devp;
- char name[50];
- u32 v[2];
-
- sprintf(name, "/plb/opb/ebc/nor_flash@0,0/partition@%x", from);
-
- devp = finddevice(name);
- if (!devp)
- return;
-
- if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
- v[0] = to;
- setprop(devp, "reg", v, sizeof(v));
-
- printf("NOR 64M fixup %x -> %x\r\n", from, to);
- }
-}
-
-
static void warp_fixups(void)
{
ibm440ep_fixup_clocks(66000000, 11059200, 50000000);
ibm4xx_sdram_fixup_memsize();
ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
-
- /* Fixup for 64M flash on Rev A boards. */
- if (bd.bi_flashsize == 0x4000000) {
- void *devp;
- u32 v[3];
-
- devp = finddevice("/plb/opb/ebc/nor_flash@0,0");
- if (!devp)
- return;
-
- /* Fixup the size */
- if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
- v[2] = bd.bi_flashsize;
- setprop(devp, "reg", v, sizeof(v));
- }
-
- /* Fixup parition offsets */
- warp_fixup_one_nor(0x300000, 0x3f00000);
- warp_fixup_one_nor(0x340000, 0x3f40000);
- warp_fixup_one_nor(0x380000, 0x3f80000);
- }
}
-
void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
unsigned long r6, unsigned long r7)
{
diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts
index f4e4ba6..b92089c 100644
--- a/arch/powerpc/boot/dts/warp.dts
+++ b/arch/powerpc/boot/dts/warp.dts
@@ -149,12 +149,17 @@
reg = <0x00000002 0x00004000 0x00000A00>;
};
- nor_flash@0,0 {
+ nor@0,0 {
compatible = "amd,s29gl032a", "cfi-flash";
bank-width = <2>;
reg = <0x00000000 0x00000000 0x00400000>;
#address-cells = <1>;
#size-cells = <1>;
+
+ partition@0 {
+ label = "splash";
+ reg = <0x00000000 0x00020000>;
+ };
partition@300000 {
label = "fpga";
reg = <0x0300000 0x00040000>;
@@ -168,6 +173,36 @@
reg = <0x0380000 0x00080000>;
};
};
+
+ nand@1,0 {
+ compatible = "amcc,ndfc";
+ reg = <0x00000001 0x00000000 0x00002000>;
+ ccr = <0x00001000>;
+ bank-settings = <0x80002222>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "kernel";
+ reg = <0x00000000 0x00200000>;
+ };
+ partition@200000 {
+ label = "root";
+ reg = <0x00200000 0x03E00000>;
+ };
+ partition@40000000 {
+ label = "persistent";
+ reg = <0x04000000 0x04000000>;
+ };
+ partition@80000000 {
+ label = "persistent1";
+ reg = <0x08000000 0x04000000>;
+ };
+ partition@C0000000 {
+ label = "persistent2";
+ reg = <0x0C000000 0x04000000>;
+ };
+ };
};
UART0: serial@ef600300 {
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index 8d0b1a1..53fc7ec 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -8,6 +8,5 @@ obj-$(CONFIG_SEQUOIA) += sequoia.o
obj-$(CONFIG_KATMAI) += katmai.o
obj-$(CONFIG_RAINIER) += rainier.o
obj-$(CONFIG_WARP) += warp.o
-obj-$(CONFIG_WARP) += warp-nand.o
obj-$(CONFIG_CANYONLANDS) += canyonlands.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
diff --git a/arch/powerpc/platforms/44x/warp-nand.c b/arch/powerpc/platforms/44x/warp-nand.c
deleted file mode 100644
index 89ecd76..0000000
--- a/arch/powerpc/platforms/44x/warp-nand.c
+++ /dev/null
@@ -1,135 +0,0 @@
-/*
- * PIKA Warp(tm) NAND flash specific routines
- *
- * Copyright (c) 2008 PIKA Technologies
- * Sean MacLennan <smaclennan@pikatech.com>
- */
-
-#include <linux/platform_device.h>
-#include <linux/mtd/mtd.h>
-#include <linux/mtd/map.h>
-#include <linux/mtd/partitions.h>
-#include <linux/mtd/nand.h>
-#include <linux/mtd/ndfc.h>
-#include <linux/of.h>
-#include <asm/machdep.h>
-
-
-#ifdef CONFIG_MTD_NAND_NDFC
-
-#define CS_NAND_0 1 /* use chip select 1 for NAND device 0 */
-
-#define WARP_NAND_FLASH_REG_ADDR 0xD0000000UL
-#define WARP_NAND_FLASH_REG_SIZE 0x2000
-
-static struct resource warp_ndfc = {
- .start = WARP_NAND_FLASH_REG_ADDR,
- .end = WARP_NAND_FLASH_REG_ADDR + WARP_NAND_FLASH_REG_SIZE - 1,
- .flags = IORESOURCE_MEM,
-};
-
-static struct mtd_partition nand_parts[] = {
- {
- .name = "kernel",
- .offset = 0,
- .size = 0x0200000
- },
- {
- .name = "root",
- .offset = 0x0200000,
- .size = 0x3E00000
- },
- {
- .name = "persistent",
- .offset = 0x4000000,
- .size = 0x4000000
- },
- {
- .name = "persistent1",
- .offset = 0x8000000,
- .size = 0x4000000
- },
- {
- .name = "persistent2",
- .offset = 0xC000000,
- .size = 0x4000000
- }
-};
-
-struct ndfc_controller_settings warp_ndfc_settings = {
- .ccr_settings = (NDFC_CCR_BS(CS_NAND_0) | NDFC_CCR_ARAC1),
- .ndfc_erpn = 0,
-};
-
-static struct ndfc_chip_settings warp_chip0_settings = {
- .bank_settings = 0x80002222,
-};
-
-struct platform_nand_ctrl warp_nand_ctrl = {
- .priv = &warp_ndfc_settings,
-};
-
-static struct platform_device warp_ndfc_device = {
- .name = "ndfc-nand",
- .id = 0,
- .dev = {
- .platform_data = &warp_nand_ctrl,
- },
- .num_resources = 1,
- .resource = &warp_ndfc,
-};
-
-/* Do NOT set the ecclayout: let it default so it is correct for both
- * 64M and 256M flash chips.
- */
-static struct platform_nand_chip warp_nand_chip0 = {
- .nr_chips = 1,
- .chip_offset = CS_NAND_0,
- .nr_partitions = ARRAY_SIZE(nand_parts),
- .partitions = nand_parts,
- .chip_delay = 20,
- .priv = &warp_chip0_settings,
-};
-
-static struct platform_device warp_nand_device = {
- .name = "ndfc-chip",
- .id = 0,
- .num_resources = 0,
- .dev = {
- .platform_data = &warp_nand_chip0,
- .parent = &warp_ndfc_device.dev,
- }
-};
-
-static int warp_setup_nand_flash(void)
-{
- struct device_node *np;
-
- /* Try to detect a rev A based on NOR size. */
- np = of_find_compatible_node(NULL, NULL, "cfi-flash");
- if (np) {
- struct property *pp;
-
- pp = of_find_property(np, "reg", NULL);
- if (pp && (pp->length == 12)) {
- u32 *v = pp->value;
- if (v[2] == 0x4000000) {
- /* Rev A = 64M NAND */
- warp_nand_chip0.nr_partitions = 3;
-
- nand_parts[1].size = 0x3000000;
- nand_parts[2].offset = 0x3200000;
- nand_parts[2].size = 0x0e00000;
- }
- }
- of_node_put(np);
- }
-
- platform_device_register(&warp_ndfc_device);
- platform_device_register(&warp_nand_device);
-
- return 0;
-}
-machine_device_initcall(warp, warp_setup_nand_flash);
-
-#endif
^ permalink raw reply related
* Re: [RFC 2/2] powerpc: copy_4K_page tweaked for Cell - add CPU feature
From: Mark Nelson @ 2008-08-15 6:33 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <1218715848.10673.33.camel@localhost>
On Thu, 14 Aug 2008 10:10:48 pm Michael Ellerman wrote:
> On Thu, 2008-08-14 at 21:48 +1000, Mark Nelson wrote:
> > Hi Michael,
> >
> > On Thu, 14 Aug 2008 08:51:35 pm Michael Ellerman wrote:
> > > On Thu, 2008-08-14 at 16:18 +1000, Mark Nelson wrote:
> > > > Add a new CPU feature, CPU_FTR_CP_USE_DCBTZ, to be added to the CPUs that benefit
> > > > from having dcbt and dcbz instructions used in copy_4K_page(). So far Cell, PPC970
> > > > and Power4 benefit.
> > > >
> > > > This way all the other 64bit powerpc chips will have the whole prefetching loop
> > > > nop'ed out.
> > >
> > > > Index: upstream/arch/powerpc/lib/copypage_64.S
> > > > ===================================================================
> > > > --- upstream.orig/arch/powerpc/lib/copypage_64.S
> > > > +++ upstream/arch/powerpc/lib/copypage_64.S
> > > > @@ -18,6 +18,7 @@ PPC64_CACHES:
> > > >
> > > > _GLOBAL(copy_4K_page)
> > > > li r5,4096 /* 4K page size */
> > > > +BEGIN_FTR_SECTION
> > > > ld r10,PPC64_CACHES@toc(r2)
> > > > lwz r11,DCACHEL1LOGLINESIZE(r10) /* log2 of cache line size */
> > > > lwz r12,DCACHEL1LINESIZE(r10) /* Get cache line size */
> > > > @@ -30,7 +31,7 @@ setup:
> > > > dcbz r9,r3
> > > > add r9,r9,r12
> > > > bdnz setup
> > > > -
> > > > +END_FTR_SECTION_IFSET(CPU_FTR_CP_USE_DCBTZ)
> > > > addi r3,r3,-8
> > > > srdi r8,r5,7 /* page is copied in 128 byte strides */
> > > > addi r8,r8,-1 /* one stride copied outside loop */
> > >
> > > Instead of nop'ing it out, we could use an alternative feature section
> > > to either run it or jump over it. It would look something like:
> > >
> > >
> > > _GLOBAL(copy_4K_page)
> > > BEGIN_FTR_SECTION
> > > li r5,4096 /* 4K page size */
> > > ld r10,PPC64_CACHES@toc(r2)
> > > lwz r11,DCACHEL1LOGLINESIZE(r10) /* log2 of cache line size */
> > > lwz r12,DCACHEL1LINESIZE(r10) /* Get cache line size */
> > > li r9,0
> > > srd r8,r5,r11
> > >
> > > mtctr r8
> > > setup:
> > > dcbt r9,r4
> > > dcbz r9,r3
> > > add r9,r9,r12
> > > bdnz setup
> > > FTR_SECTION_ELSE
> > > b 1f
> > > ALT_FTR_SECTION_END_IFSET(CPU_FTR_CP_USE_DCBTZ)
> > > 1:
> > > addi r3,r3,-8
> > >
> > > So in the no-dcbtz case you'd get a branch instead of 11 nops.
> > >
> > > Of course you'd need to benchmark it to see if skipping the nops is
> > > better than executing them ;P
> >
> > Thanks for looking through this.
> >
> > That does look a lot better. In the first version there wasn't quite
> > as much to nop out (the cache line size was hardcoded to 128
> > bytes) so I wasn't so worried but I'll definitely try this with an
> > alternative section like you describe.
> >
> > The jump probably will turn out to be better because I'd imagine
> > that the same chips that don't need the dcbt and dcbz because
> > they've got beefy enough hardware prefetchers also won't be
> > disturbed by the jump (but benchmarks tomorrow will confirm;
> > or prove me wrong :) )
>
> Yeah, that would make sense. But you never know :)
It turns out that on Power6 using the alternative section doesn't
have any noticeable effect on performance. On Power5 though it
actually made the compile test a tiny bit slower:
with alternative feature section:
real 5m7.549s
user 17m24.256s
sys 1m0.621s
real 5m7.829s
user 17m24.879s
sys 1m0.465s
original implementation:
real 5m6.468s
user 17m22.891s
sys 0m59.765s
real 5m6.965s
user 17m23.160s
sys 0m59.844s
So I guess I'll leave it the way it is...
Thanks!
Mark
^ permalink raw reply
* Re: oops in proc_sys_compare
From: Hugh Dickins @ 2008-08-15 6:48 UTC (permalink / raw)
To: Al Viro; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080815045149.GC28946@ZenIV.linux.org.uk>
On Fri, 15 Aug 2008, Al Viro wrote:
> On Thu, Aug 14, 2008 at 07:31:06PM +0100, Hugh Dickins wrote:
> > I got this oops below, after several hours of swap-heavy kernel builds
> > in tmpfs, on 2.6.27-rc1-mm1 a couple of weeks ago. Tried to reproduce
> > it without success, then got a very similar trace (not saved) from
> > 2.6.27-rc3 itself doing the same test yesterday: again oopsing in
> > proc_sys_compare on address -16, looks like it's trying for
> > PROC_I(dentry->d_inode)->sysctl but d_inode is NULL.
> >
> > I looked to see what's been going on in fs/proc recently, and your
> > [PATCH] sanitize proc_sysctl 9043476f726802f4b00c96d0c4f418dde48d1304
> > does sound like it might be implicated. I've only seen this on
> > PowerPC G5, similar tests on x86_32 and _64 haven't shown it:
> > maybe a memory barrier needed somewhere?
>
> Bloody interesting. We never create negative hashed dentries in there and
> AFAICS we should never get d_delete() called on those... Missing barrier
> would mean serious trouble in dcache.c and not just for /proc/sys...
>
> Are you sure about oops decoding? At least disassembly of proc_sys_compare()
> in the kernel image in question would be nice to see...
Here it is: I'd changed config meanwhile, so this is from a rebuild,
but symbol addresses fit exactly with the trace (and the 2.6.27-rc1-mm1
fs/proc/proc_sysctl.c is identical to that in 2.6.27-rc3 or current git).
I did try "objdump -Sd" at first, but that just looked more confusing.
c000000000121e7c <.proc_sys_compare>:
proc_sys_compare():
/home/hugh/26271E1/fs/proc/proc_sysctl.c:383
c000000000121e7c: 7c 08 02 a6 mflr r0
c000000000121e80: fb e1 ff f0 std r31,-16(r1)
c000000000121e84: 7c a9 2b 78 mr r9,r5
c000000000121e88: 7c 9f 23 78 mr r31,r4
c000000000121e8c: f8 01 00 10 std r0,16(r1)
c000000000121e90: f8 21 ff 81 stdu r1,-128(r1)
/home/hugh/26271E1/fs/proc/proc_sysctl.c:385
c000000000121e94: 60 00 00 00 nop
c000000000121e98: 80 a4 00 04 lwz r5,4(r4)
c000000000121e9c: 80 09 00 04 lwz r0,4(r9)
c000000000121ea0: 7f 80 28 00 cmpw cr7,r0,r5
c000000000121ea4: 40 9e 00 3c bne- cr7,c000000000121ee0 <.proc_sys_compare+0x64>
/home/hugh/26271E1/fs/proc/proc_sysctl.c:387
c000000000121ea8: e8 89 00 08 ld r4,8(r9)
c000000000121eac: e8 7f 00 08 ld r3,8(r31)
c000000000121eb0: 4b f0 aa 45 bl c00000000002c8f4 <.memcmp>
c000000000121eb4: 60 00 00 00 nop
c000000000121eb8: 2f a3 00 00 cmpdi cr7,r3,0
c000000000121ebc: 40 9e 00 24 bne- cr7,c000000000121ee0 <.proc_sys_compare+0x64>
PROC_I():
/home/hugh/26271E1/fs/proc/proc_sysctl.c:384
c000000000121ec0: e9 3f ff e0 ld r9,-32(r31)
c000000000121ec4: e8 69 ff f0 ld r3,-16(r9)
c000000000121ec8: 4b f2 f8 4d bl c000000000051714 <.sysctl_is_seen>
c000000000121ecc: 60 00 00 00 nop
proc_sys_compare():
/home/hugh/26271E1/fs/proc/proc_sysctl.c:389
c000000000121ed0: 7c 63 00 34 cntlzw r3,r3
c000000000121ed4: 54 63 d9 7e rlwinm r3,r3,27,5,31
c000000000121ed8: 78 63 00 20 clrldi r3,r3,32
c000000000121edc: 48 00 00 08 b c000000000121ee4 <.proc_sys_compare+0x68>
c000000000121ee0: 38 60 00 01 li r3,1
/home/hugh/26271E1/fs/proc/proc_sysctl.c:390
c000000000121ee4: 38 21 00 80 addi r1,r1,128
c000000000121ee8: e8 01 00 10 ld r0,16(r1)
c000000000121eec: eb e1 ff f0 ld r31,-16(r1)
c000000000121ef0: 7c 08 03 a6 mtlr r0
c000000000121ef4: 4e 80 00 20 blr
^ permalink raw reply
* [PATCH] powerpc: Fix lockdep IRQ tracing bug
From: Benjamin Herrenschmidt @ 2008-08-15 7:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
A small bogon sneaked into the ppc64 lockdep support. A test is
branching slightly off causing a clobbered register value to
overwrite the irq state under some circumstances.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
This explains some of the reported weird lockdep errors, maybe
even all of them, we'll see.
We should probably backport that to 2.6.26-stable too, any candidate ?
arch/powerpc/include/asm/irqflags.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/irqflags.h 2008-08-15 16:48:43.000000000 +1000
+++ linux-work/arch/powerpc/include/asm/irqflags.h 2008-08-15 16:51:02.000000000 +1000
@@ -20,7 +20,7 @@
#define TRACE_ENABLE_INTS bl .trace_hardirqs_on
#define TRACE_DISABLE_INTS bl .trace_hardirqs_off
#define TRACE_AND_RESTORE_IRQ_PARTIAL(en,skip) \
- cmpdi en, 0; \
+ cmpdi en,0; \
bne 95f; \
stb en,PACASOFTIRQEN(r13); \
bl .trace_hardirqs_off; \
@@ -29,7 +29,8 @@
li en,1;
#define TRACE_AND_RESTORE_IRQ(en) \
TRACE_AND_RESTORE_IRQ_PARTIAL(en,96f); \
-96: stb en,PACASOFTIRQEN(r13)
+ stb en,PACASOFTIRQEN(r13); \
+96:
#else
#define TRACE_ENABLE_INTS
#define TRACE_DISABLE_INTS
^ permalink raw reply
* Re: [PATCH 1/2] port ndfc driver to of platform
From: Arnd Bergmann @ 2008-08-15 7:27 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, dwmw2
In-Reply-To: <20080814191041.60ffed5c@lappy.seanm.ca>
On Friday 15 August 2008, Sean MacLennan wrote:
> Port the ndfc driver to an OF platform driver.
>
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Looks great, but I just noticed one more detail:
> +static const struct of_device_id ndfc_match[] = {
> + { .compatible = "amcc,ndfc", },
> + {}
> };
>
You should add
MODULE_DEVICE_TABLE(of, &ndfc_match);
to enable module auto-loading.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/2] port ndfc driver to of platform
From: Arnd Bergmann @ 2008-08-15 7:28 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080815012402.72855c67@lappy.seanm.ca>
On Friday 15 August 2008, Sean MacLennan wrote:
> Changes to the warp platform with the ndfc as an of platform device.
> The main changes are:
>
> * move the NAND information to the DTS
> * remove warp-nand.c
> * remove rev A fixups from cuboot-warp.c
>
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: How to use ramdisk on the ml300?
From: wangyanlong @ 2008-08-15 8:40 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <931ae8260808132008i1cac2e91kc76c099ecc574cd0@mail.gmail.com>
It is work now ,Thanks for all your help :)
--
View this message in context: http://www.nabble.com/How-to-use-ramdisk-on-the-ml300--tp18975066p18995595.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Linux issues on Xilinx XUPV2P board
From: wangyanlong @ 2008-08-15 8:43 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4858FDD100015AFE@hawk.dcu.ie>
I meet the problem as yours . And my vga's display is not clear , have you
meet this?
Alan Casey wrote:
>
> Hi,
>
> I have tried running the Linux 2.6.24 and Linux 2.6.26 kernels from
> git.xilinx.com on the Xilinx XUPV2P board but have run into a few
> problems.
>
> Cross-compiler i use to compile applications was built using Crosstools
> and
> based on gcc 3.3.4. I use Xilinx EDK 7.1 for integrating hardware
> peripherals
> onto the board.
>
> The problems i've seen are:
>
> (i) gettimeofday software function returns time of 0 all the time.
>
> (ii) The Linux 2.6.24 kernel's Xilinx Framebuffer driver and/or the
> Xilinx
>
> PLB TFT Controller IP block (plb_tft_cntlr_ref_v1_00_d) does not
> appear
>
> to centre the display on a VGA screen properly(vertically offset).
>
> (iii) 64-bit write/read access to peripheral integrated onto the Xilinx
>
> Virtex-II Pro FPGA either causes a system crash or only lower part
>
> of 32-bit data to be written (i.e. lower part of 64-bit data
> appears
> to be mirrored on the upper and lower 32-bits of the system bus).
> However, 32-bit write/read access to the peripheral passes as well
> as 64-bit write/read access to the SDRAM memory address space.
> Peripheral interface has been verified to be IBM PLB compliant
> via IBM bus functional model simulations.
>
> (iv) The Linux 2.6.26 Xilinx Framebuffer driver on the Xilinx XUPV2P
> board
>
> does not appear to be working - nothing displayed to
> screen/console
>
> not switching to framebuffer device on bootup.
>
> Just wondering if anybody has seen these issues before and know how to
> resolve them?
>
> Any info. appreciated,
> Regards,
> Alan.
>
>
>
>
> _______________________________________________
> 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-issues-on-Xilinx-XUPV2P-board-tp18262250p18995644.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Linux issues on Xilinx XUPV2P board
From: Alan Casey @ 2008-08-15 9:59 UTC (permalink / raw)
To: wangyanlong, linuxppc-embedded
In-Reply-To: <18995644.post@talk.nabble.com>
Hi,
Yes i had a problem with using one of the Linux 2.6.26
kernel versions on the XUPV2P board where the VGA
display has not driven correctly, not sure why.
The Linux 2.6.24 kernel from git.xilinx.com works fine.
Regards,
Alan.
>-- Original Message --
>Date: Fri, 15 Aug 2008 01:43:37 -0700 (PDT)
>From: wangyanlong <killyouatonce@gmail.com>
>To: linuxppc-embedded@ozlabs.org
>Subject: Re: Linux issues on Xilinx XUPV2P board
>
>
>
>I meet the problem as yours . And my vga's display is not clear , have
you
>meet this?
>
>Alan Casey wrote:
>>
>> Hi,
>>
>> I have tried running the Linux 2.6.24 and Linux 2.6.26 kernels from
>
>> git.xilinx.com on the Xilinx XUPV2P board but have run into a few
>> problems.
>>
>> Cross-compiler i use to compile applications was built using Crossto=
ols
>> and
>> based on gcc 3.3.4. I use Xilinx EDK 7.1 for integrating hardware
>> peripherals
>> onto the board.
>>
>> The problems i've seen are:
>>
>> (i) gettimeofday software function returns time of 0 all the time.
>>
>> (ii) The Linux 2.6.24 kernel's Xilinx Framebuffer driver and/or the
>> Xilinx
>>
>> PLB TFT Controller IP block (plb_tft_cntlr_ref_v1_00_d) does no=
t
>> appear
>>
>> to centre the display on a VGA screen properly(vertically offse=
t).
>>
>> (iii) 64-bit write/read access to peripheral integrated onto the Xil=
inx
>>
>> Virtex-II Pro FPGA either causes a system crash or only lower
part
>>
>> of 32-bit data to be written (i.e. lower part of 64-bit data
>> appears
>> to be mirrored on the upper and lower 32-bits of the system bu=
s).
>> However, 32-bit write/read access to the peripheral passes as
well
>> as 64-bit write/read access to the SDRAM memory address space.=
>> Peripheral interface has been verified to be IBM PLB compliant=
>
>> via IBM bus functional model simulations.
>>
>> (iv) The Linux 2.6.26 Xilinx Framebuffer driver on the Xilinx XUPV2=
P
>> board
>>
>> does not appear to be working - nothing displayed to
>> screen/console
>>
>> not switching to framebuffer device on bootup.
>>
>> Just wondering if anybody has seen these issues before and know how=
>to
>> resolve them?
>>
>> Any info. appreciated,
>> Regards,
>> Alan.
>>
>>
>>
>>
>> _______________________________________________
>> 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-issues-on-Xili=
nx-XUPV2P-board-tp18262250p18995644.html
>Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Linux issues on Xilinx XUPV2P board
From: wangyanlong @ 2008-08-15 11:35 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4891711700018ABB@hawk.dcu.ie>
Hi Alan
I dow load the kernel from "
http://git.xilinx.com/cgi-bin/gitweb.cgi?p=linux-2.6-xlnx.git;a=summary "
Merge ../../linux-2.6 into 2.6.26-merge master commit | commitdiff | tree
| snapshot
this version ,but it not work well,which version you downloaded?
Many thanks
yanlong
Alan Casey wrote:
>
> Hi,
>
> Yes i had a problem with using one of the Linux 2.6.26
> kernel versions on the XUPV2P board where the VGA
> display has not driven correctly, not sure why.
> The Linux 2.6.24 kernel from git.xilinx.com works fine.
>
> Regards,
> Alan.
>
>
>>-- Original Message --
>>Date: Fri, 15 Aug 2008 01:43:37 -0700 (PDT)
>>From: wangyanlong <killyouatonce@gmail.com>
>>To: linuxppc-embedded@ozlabs.org
>>Subject: Re: Linux issues on Xilinx XUPV2P board
>>
>>
>>
>>I meet the problem as yours . And my vga's display is not clear , have
> you
>>meet this?
>>
>>Alan Casey wrote:
>>>
>>> Hi,
>>>
>>> I have tried running the Linux 2.6.24 and Linux 2.6.26 kernels from
>
>>
>>> git.xilinx.com on the Xilinx XUPV2P board but have run into a few
>>> problems.
>>>
>>> Cross-compiler i use to compile applications was built using
>>> Crosstools
>>> and
>>> based on gcc 3.3.4. I use Xilinx EDK 7.1 for integrating hardware
>>> peripherals
>>> onto the board.
>>>
>>> The problems i've seen are:
>>>
>>> (i) gettimeofday software function returns time of 0 all the time.
>>>
>>> (ii) The Linux 2.6.24 kernel's Xilinx Framebuffer driver and/or the
>>> Xilinx
>>>
>>> PLB TFT Controller IP block (plb_tft_cntlr_ref_v1_00_d) does not
>>> appear
>>>
>>> to centre the display on a VGA screen properly(vertically
>>> offset).
>>>
>>> (iii) 64-bit write/read access to peripheral integrated onto the
>>> Xilinx
>>>
>>> Virtex-II Pro FPGA either causes a system crash or only lower
> part
>>>
>>> of 32-bit data to be written (i.e. lower part of 64-bit data
>>> appears
>>> to be mirrored on the upper and lower 32-bits of the system
>>> bus).
>>> However, 32-bit write/read access to the peripheral passes as
> well
>>> as 64-bit write/read access to the SDRAM memory address space.
>>> Peripheral interface has been verified to be IBM PLB compliant
>>
>>> via IBM bus functional model simulations.
>>>
>>> (iv) The Linux 2.6.26 Xilinx Framebuffer driver on the Xilinx XUPV2P
>>> board
>>>
>>> does not appear to be working - nothing displayed to
>>> screen/console
>>>
>>> not switching to framebuffer device on bootup.
>>>
>>> Just wondering if anybody has seen these issues before and know how
>>to
>>> resolve them?
>>>
>>> Any info. appreciated,
>>> Regards,
>>> Alan.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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-issues-on-Xilinx-XUPV2P-board-tp18262250p18995644.html
>>Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>
>>_______________________________________________
>>Linuxppc-embedded mailing list
>>Linuxppc-embedded@ozlabs.org
>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> _______________________________________________
> 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-issues-on-Xilinx-XUPV2P-board-tp18262250p18997255.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [BUG] fec_mpc52xx: Don't call mpc52xx_fec_reset() in ISR
From: Wolfram Sang @ 2008-08-15 11:45 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, domen.puncer
In-Reply-To: <48A2EBC1.6020708@grandegger.com>
[-- Attachment #1: Type: text/plain, Size: 960 bytes --]
Hello Wolfgang (and all),
On Wed, Aug 13, 2008 at 04:12:17PM +0200, Wolfgang Grandegger wrote:
> ...but I prepared a patch to do the reset in the process context. Would be
> nice if you could give the patch below a try.
Will do later. Thanks!
Still, I think it might be useful to discuss if a complete reset
is not overkill anyhow. The documentation says that only the FIFO
and the Bestcom needs to be reset. Or, if we take the "big hammer"
solution, it would be good to audit if this won't cause any
side-effects (do all related states get updated...).
Remember that there lately have been patches removing some improper
usage of netif_* calls; furthermore, I also found some questionable
areas in this code (mails will be sent later). So, this driver
needs some careful attention IMHO.
All the best,
Wolfram
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Linux issues on Xilinx XUPV2P board
From: Alan Casey @ 2008-08-15 12:34 UTC (permalink / raw)
To: wangyanlong, linuxppc-embedded
In-Reply-To: <18997255.post@talk.nabble.com>
Hi,
I used version 2.6.24. Current version is 2.6.26+ but im
not sure how to download previous versions from the git
tree, there should be some info at http://git.xilinx.com
about how to do this.
Regards,
Alan.
>-- Original Message --
>Date: Fri, 15 Aug 2008 04:35:01 -0700 (PDT)
>From: wangyanlong <killyouatonce@gmail.com>
>To: linuxppc-embedded@ozlabs.org
>Subject: Re: Linux issues on Xilinx XUPV2P board
>
>
>
>Hi Alan
> I dow load the kernel from "
>http://git.xilinx.com/cgi-bin/gitweb.cgi?p=3Dlinux-2.6-xlnx.git;a=3Dsumm=
ary
"
>
>Merge ../../linux-2.6 into 2.6.26-merge master commit | commitdiff | t=
ree
>| snapshot
>
>this version ,but it not work well,which version you downloaded?
>
>Many thanks
>yanlong
>
>
>Alan Casey wrote:
>>
>> Hi,
>>
>> Yes i had a problem with using one of the Linux 2.6.26
>> kernel versions on the XUPV2P board where the VGA
>> display has not driven correctly, not sure why.
>> The Linux 2.6.24 kernel from git.xilinx.com works fine.
>>
>> Regards,
>> Alan.
>>
>>
>>>-- Original Message --
>>>Date: Fri, 15 Aug 2008 01:43:37 -0700 (PDT)
>>>From: wangyanlong <killyouatonce@gmail.com>
>>>To: linuxppc-embedded@ozlabs.org
>>>Subject: Re: Linux issues on Xilinx XUPV2P board
>>>
>>>
>>>
>>>I meet the problem as yours . And my vga's display is not clear , hav=
e
>> you
>>>meet this?
>>>
>>>Alan Casey wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have tried running the Linux 2.6.24 and Linux 2.6.26 kernels fro=
m
>>
>>>
>>>> git.xilinx.com on the Xilinx XUPV2P board but have run into a few
>>>> problems.
>>>>
>>>> Cross-compiler i use to compile applications was built using
>>>> Crosstools
>>>> and
>>>> based on gcc 3.3.4. I use Xilinx EDK 7.1 for integrating hardware
>>>> peripherals
>>>> onto the board.
>>>>
>>>> The problems i've seen are:
>>>>
>>>> (i) gettimeofday software function returns time of 0 all the time.=
>>>>
>>>> (ii) The Linux 2.6.24 kernel's Xilinx Framebuffer driver and/or th=
e
>>>> Xilinx
>>>>
>>>> PLB TFT Controller IP block (plb_tft_cntlr_ref_v1_00_d) does
not
>>>> appear
>>>>
>>>> to centre the display on a VGA screen properly(vertically
>>>> offset).
>>>>
>>>> (iii) 64-bit write/read access to peripheral integrated onto the
>>>> Xilinx
>>>>
>>>> Virtex-II Pro FPGA either causes a system crash or only lowe=
r
>> part
>>>>
>>>> of 32-bit data to be written (i.e. lower part of 64-bit data=
>>>> appears
>>>> to be mirrored on the upper and lower 32-bits of the system
>>>> bus).
>>>> However, 32-bit write/read access to the peripheral passes a=
s
>> well
>>>> as 64-bit write/read access to the SDRAM memory address spac=
e.
>>>> Peripheral interface has been verified to be IBM PLB complia=
nt
>>>
>>>> via IBM bus functional model simulations.
>>>>
>>>> (iv) The Linux 2.6.26 Xilinx Framebuffer driver on the Xilinx XUP=
V2P
>>>> board
>>>>
>>>> does not appear to be working - nothing displayed to
>>>> screen/console
>>>>
>>>> not switching to framebuffer device on bootup.
>>>>
>>>> Just wondering if anybody has seen these issues before and know h=
ow
>>>to
>>>> resolve them?
>>>>
>>>> Any info. appreciated,
>>>> Regards,
>>>> Alan.
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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-issues-on-Xilinx-XUPV2P-board-tp18262250p189=
95644.html
>>>Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>>
>>>_______________________________________________
>>>Linuxppc-embedded mailing list
>>>Linuxppc-embedded@ozlabs.org
>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>> _______________________________________________
>> 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-issues-on-Xili=
nx-XUPV2P-board-tp18262250p18997255.html
>Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] usb: add Freescale QE/CPM USB peripheral controller driver
From: Anton Vorontsov @ 2008-08-15 14:16 UTC (permalink / raw)
To: Li Yang; +Cc: david-b, linuxppc-dev, gregkh, linux-usb, Xie Xiaobo
In-Reply-To: <1218007000-27320-1-git-send-email-leoli@freescale.com>
On Wed, Aug 06, 2008 at 03:16:40PM +0800, Li Yang wrote:
> Some of Freescale SoC chips have a QE or CPM co-processor which
> supports full speed USB. The driver adds device mode support
> of both QE and CPM USB controller to Linux USB gadget. The
> driver is tested with MPC8360 and MPC8272, and should work with
> other models having QE/CPM given minor tweaks.
>
> Signed-off-by: Xie Xiaobo <X.Xie@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
Hi,
Just want to report that the driver works here on MPC8360E-MDS,
with few issues though.
> +/*-------------------------------------------------------------------------
> + Gadget driver register and unregister.
> + --------------------------------------------------------------------------*/
> +int usb_gadget_register_driver(struct usb_gadget_driver *driver)
> +{
> + int retval;
> + unsigned long flags = 0;
> +
> + /* standard operations */
> + if (!udc_controller)
> + return -ENODEV;
> +
> + if (!driver || (driver->speed != USB_SPEED_FULL
> + && driver->speed != USB_SPEED_HIGH)
> + || !driver->bind || !driver->unbind ||
> + !driver->disconnect || !driver->setup)
Usually unbind is assigned via __exit_p() macro, thus the driver
will not able to work with g_ether when it is built in.
Plus I got this with various debugging enabled:
g_ether gadget: high speed config #1: CDC Ethernet (ECM)
BUG: spinlock recursion on CPU#0, swapper/0
lock: cf846c50, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0
Call Trace:
[c0361cb0] [c0008a90] show_stack+0x4c/0x16c (unreliable)
[c0361cf0] [c0175b84] spin_bug+0x7c/0xc4
[c0361d10] [c0175ea8] _raw_spin_lock+0xb4/0xb8
[c0361d20] [c027e5dc] _spin_lock_irqsave+0x30/0x48
[c0361d40] [c01c8450] qe_ep_init+0x80/0x3a4
[c0361d60] [c01c8828] qe_ep_enable+0xb4/0xe4
[c0361d80] [c01cb210] ecm_set_alt+0x88/0x12c
[c0361d90] [c01cbb10] set_config+0xc8/0x1bc
[c0361db0] [c01cbf90] composite_setup+0x20c/0x3a8
[c0361de0] [c01c7f88] setup_received_handle+0x1e4/0x26c
[c0361e00] [c01c807c] ep0_setup_handle+0x6c/0x74
[c0361e10] [c01c81f0] qe_ep0_rx+0x16c/0x17c
[c0361e30] [c01c9140] rx_irq+0x88/0xc0
[c0361e40] [c01c98c8] qe_udc_irq+0x10c/0x134
[c0361e60] [c006083c] handle_IRQ_event+0x5c/0xb0
[c0361e80] [c0062964] handle_level_irq+0xa8/0x144
[c0361ea0] [c0029a9c] qe_ic_cascade_low_ipic+0x58/0x90
[c0361eb0] [c0006820] do_IRQ+0xa4/0xc8
[c0361ec0] [c0013e88] ret_from_except+0x0/0x14
--- Exception: 501 at cpu_idle+0xa0/0x104
LR = cpu_idle+0xa0/0x104
[c0361f80] [c0009d88] cpu_idle+0x50/0x104 (unreliable)
[c0361fa0] [c027f07c] 0xc027f07c
[c0361fc0] [c030d91c] start_kernel+0x1ac/0x230
[c0361ff0] [00003438] 0x3438
BUG: spinlock lockup on CPU#0, swapper/0, cf846c50
Call Trace:
[c0361ca0] [c0008a90] show_stack+0x4c/0x16c (unreliable)
[c0361ce0] [c0175df0] __spin_lock_debug+0xf4/0xf8
[c0361d10] [c0175e80] _raw_spin_lock+0x8c/0xb8
[c0361d20] [c027e5dc] _spin_lock_irqsave+0x30/0x48
[c0361d40] [c01c8450] qe_ep_init+0x80/0x3a4
[c0361d60] [c01c8828] qe_ep_enable+0xb4/0xe4
[c0361d80] [c01cb210] ecm_set_alt+0x88/0x12c
[c0361d90] [c01cbb10] set_config+0xc8/0x1bc
[c0361db0] [c01cbf90] composite_setup+0x20c/0x3a8
[c0361de0] [c01c7f88] setup_received_handle+0x1e4/0x26c
[c0361e00] [c01c807c] ep0_setup_handle+0x6c/0x74
[c0361e10] [c01c81f0] qe_ep0_rx+0x16c/0x17c
[c0361e30] [c01c9140] rx_irq+0x88/0xc0
[c0361e40] [c01c98c8] qe_udc_irq+0x10c/0x134
[c0361e60] [c006083c] handle_IRQ_event+0x5c/0xb0
[c0361e80] [c0062964] handle_level_irq+0xa8/0x144
[c0361ea0] [c0029a9c] qe_ic_cascade_low_ipic+0x58/0x90
[c0361eb0] [c0006820] do_IRQ+0xa4/0xc8
[c0361ec0] [c0013e88] ret_from_except+0x0/0x14
--- Exception: 501 at cpu_idle+0xa0/0x104
LR = cpu_idle+0xa0/0x104
[c0361f80] [c0009d88] cpu_idle+0x50/0x104 (unreliable)
[c0361fa0] [c027f07c] 0xc027f07c
[c0361fc0] [c030d91c] start_kernel+0x1ac/0x230
[c0361ff0] [00003438] 0x3438
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* flash partitioning
From: liran raz @ 2008-08-15 14:23 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]
hi,
Using the following configuration in the
dts file (mpc8272ads.dts):
localbus@f0010100 {
compatible = "fsl,mpc8272-localbus",
"fsl,pq2-localbus";
#address-cells = <2>;
#size-cells = <1>;
reg = <f0010100 40>;
ranges = <0 0 fc000000 04000000>;
};
flash@fc000000 {
device_type = "rom";
compatible = "direct-mapped";
probe-type = "CFI";
reg = <fc000000 04000000>;
bank-width = <4>;
device-width = <2>;
#address-cells = <1>;
#size-cells = <1>;
partitions = <0 200000
2000000 a00000
c000000 a00000
16000000 600000
1c000000 e00000
2a000000 600000
30000000 e00000
3e000000 100000
3f000000 80000
3f800000 40000
3fc00000 40000>;
partition-names =
"part01","part02","part03","part04","part05","part06","part07","part08","part09","part10","part11";
};
I can't see the different partitions linked to the /dev/mtd<x>
devices in the startup messages. When testing the devices
I see that only /dev/mtd0 is actually linked to the beginning
of the flash. (other /dev/mtd1 etc.. can't be opened).
I included below also the relevant startup messages.
Does anyone have any idea what is wrong with my flash
configuration format?
Thanks, Liran.
Linux version: 2.6.24
Processor: mpc8272
Startup messages:
physmap platform flash device: 04000000 at fc000000
physmap-flash.0: Found 2 x16 devices at 0x0 in 32-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
physmap-flash.0: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
[-- Attachment #2: Type: text/html, Size: 4487 bytes --]
^ permalink raw reply
* RE: Linux issues on Xilinx XUPV2P board
From: John Linn @ 2008-08-15 14:30 UTC (permalink / raw)
To: alan.casey5, wangyanlong, linuxppc-embedded
In-Reply-To: <4891711700018E59@hawk.dcu.ie>
Hi Alan,
I'm assuming you must not have Git installed from the question,
otherwise you would be using git clone as the site shows.
On the http://git.xilinx.com, it says the following, =
Users without Git installed may create a tar file by using the snapshot
feature. Select the tree view of the repository (far right side) on this
page, then select snapshot (near the top) and a gziped tar file will be
created and downloaded. =
Is this what you're looking for?
-- John
> -----Original Message-----
> From: =
> linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org =
> [mailto:linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.
> org] On Behalf Of Alan Casey
> Sent: Friday, August 15, 2008 6:34 AM
> To: wangyanlong; linuxppc-embedded@ozlabs.org
> Subject: Re: Linux issues on Xilinx XUPV2P board
> =
> Hi,
> =
> I used version 2.6.24. Current version is 2.6.26+ but im
> not sure how to download previous versions from the git
> tree, there should be some info at http://git.xilinx.com
> about how to do this.
> =
> Regards,
> Alan.
> =
> >-- Original Message --
> >Date: Fri, 15 Aug 2008 04:35:01 -0700 (PDT)
> >From: wangyanlong <killyouatonce@gmail.com>
> >To: linuxppc-embedded@ozlabs.org
> >Subject: Re: Linux issues on Xilinx XUPV2P board
> >
> >
> >
> >Hi Alan =
> > I dow load the kernel from "
> >http://git.xilinx.com/cgi-bin/gitweb.cgi?p=3Dlinux-2.6-xlnx.git
> ;a=3Dsummary
> "
> >
> >Merge ../../linux-2.6 into 2.6.26-merge master commit | =
> commitdiff | tree
> >| snapshot
> > =
> >this version ,but it not work well,which version you downloaded?
> >
> >Many thanks
> >yanlong
> > =
> >
> >Alan Casey wrote:
> >> =
> >> Hi,
> >> =
> >> Yes i had a problem with using one of the Linux 2.6.26
> >> kernel versions on the XUPV2P board where the VGA
> >> display has not driven correctly, not sure why.
> >> The Linux 2.6.24 kernel from git.xilinx.com works fine.
> >> =
> >> Regards,
> >> Alan.
> >> =
> >> =
> >>>-- Original Message --
> >>>Date: Fri, 15 Aug 2008 01:43:37 -0700 (PDT)
> >>>From: wangyanlong <killyouatonce@gmail.com>
> >>>To: linuxppc-embedded@ozlabs.org
> >>>Subject: Re: Linux issues on Xilinx XUPV2P board
> >>>
> >>>
> >>>
> >>>I meet the problem as yours . And my vga's display is not =
> clear , have
> >> you
> >>>meet this?
> >>>
> >>>Alan Casey wrote:
> >>>> =
> >>>> Hi,
> >>>> =
> >>>> I have tried running the Linux 2.6.24 and Linux 2.6.26 =
> kernels from
> >> =
> >>> =
> >>>> git.xilinx.com on the Xilinx XUPV2P board but have run =
> into a few
> >>>> problems.
> >>>> =
> >>>> Cross-compiler i use to compile applications was built using
> >>>> Crosstools
> >>>> and
> >>>> based on gcc 3.3.4. I use Xilinx EDK 7.1 for =
> integrating hardware
> >>>> peripherals
> >>>> onto the board.
> >>>> =
> >>>> The problems i've seen are:
> >>>> =
> >>>> (i) gettimeofday software function returns time of 0 =
> all the time.
> >>>> =
> >>>> (ii) The Linux 2.6.24 kernel's Xilinx Framebuffer =
> driver and/or the
> >>>> Xilinx
> >>>>
> >>>> PLB TFT Controller IP block =
> (plb_tft_cntlr_ref_v1_00_d) does
> not
> >>>> appear
> >>>> =
> >>>> to centre the display on a VGA screen properly(vertically
> >>>> offset).
> >>>> =
> >>>> (iii) 64-bit write/read access to peripheral =
> integrated onto the
> >>>> Xilinx
> >>>> =
> >>>> Virtex-II Pro FPGA either causes a system crash =
> or only lower
> >> part
> >>>> =
> >>>> of 32-bit data to be written (i.e. lower part of =
> 64-bit data
> >>>> appears
> >>>> to be mirrored on the upper and lower 32-bits of =
> the system
> >>>> bus).
> >>>> However, 32-bit write/read access to the =
> peripheral passes as
> >> well
> >>>> as 64-bit write/read access to the SDRAM memory =
> address space.
> >>>> Peripheral interface has been verified to be IBM =
> PLB compliant
> >>>
> >>>> via IBM bus functional model simulations. =
> >>>> =
> >>>> (iv) The Linux 2.6.26 Xilinx Framebuffer driver on =
> the Xilinx XUPV2P
> >>>> board
> >>>> =
> >>>> does not appear to be working - nothing displayed to
> >>>> screen/console
> >>>> =
> >>>> not switching to framebuffer device on bootup. =
> >>>> =
> >>>> Just wondering if anybody has seen these issues =
> before and know how
> >>>to
> >>>> resolve them?
> >>>> =
> >>>> Any info. appreciated,
> >>>> Regards,
> >>>> Alan.
> >>>> =
> >>>> =
> >>>> =
> >>>> =
> >>>> _______________________________________________
> >>>> 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-issues-on-Xilinx-XUPV2P-board-tp1
> 8262250p18995644.html
> >>>Sent from the linuxppc-embedded mailing list archive at Nabble.com.
> >>>
> >>>_______________________________________________
> >>>Linuxppc-embedded mailing list
> >>>Linuxppc-embedded@ozlabs.org
> >>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >> =
> >> =
> >> _______________________________________________
> >> 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-issues-on-Xilinx-XUPV2P-board-tp18
> 262250p18997255.html
> >Sent from the linuxppc-embedded mailing list archive at Nabble.com.
> >
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> =
> =
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> =
> =
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: Linux issues on Xilinx XUPV2P board
From: wangyanlong @ 2008-08-15 14:31 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4891711700018E59@hawk.dcu.ie>
Hi
v2.6.24
v2.6.24-rc8
v2.6.24-rc7
v2.6.24-rc6
v2.6.24-rc5
v2.6.24-rc4
v2.6.24-rc3
v2.6.24-rc2
many versions, which one ???
Thanks :)
v2.6.24-rc1
Hi,
I used version 2.6.24. Current version is 2.6.26+ but im
not sure how to download previous versions from the git
tree, there should be some info at http://git.xilinx.com
about how to do this.
Regards,
Alan.
--
View this message in context: http://www.nabble.com/Linux-issues-on-Xilinx-XUPV2P-board-tp18262250p18999662.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* RE: Linux issues on Xilinx XUPV2P board
From: Alan Casey @ 2008-08-15 14:36 UTC (permalink / raw)
To: John Linn, wangyanlong, linuxppc-embedded
In-Reply-To: <20080815143027.BD038B0004C@mail24-sin.bigfish.com>
Hi John,
Im not having any problems using GIT. I can download
2.6.26 using git no problem - i think wangyanlong
would like to use 2.6.24 or 2.6.26 and he has problems
downloading it using git - hence i replied to him that
he may find more info about how to download the current
or previous version on git.xilinx.com. I think you misread
my email.
The Xilinx Framebuffer driver works fine in Linux 2.6.24
but there appears to be a problem with one of the Linux-2.6.26
versions which i posted about a few weeks/months ago.
Alan.
>-- Original Message --
>Subject: RE: Linux issues on Xilinx XUPV2P board
>Date: Fri, 15 Aug 2008 08:30:25 -0600
>From: John Linn <John.Linn@xilinx.com>
>To: <alan.casey5@mail.dcu.ie>,
> "wangyanlong" <killyouatonce@gmail.com>,
> <linuxppc-embedded@ozlabs.org>
>
>
>Hi Alan,
>
>I'm assuming you must not have Git installed from the question,
>otherwise you would be using git clone as the site shows.
>
>On the http://git.xilinx.com, it says the following,
>
>Users without Git installed may create a tar file by using the snapshot
>feature. Select the tree view of the repository (far right side) on this=
>page, then select snapshot (near the top) and a gziped tar file will be
>created and downloaded.
>
>Is this what you're looking for?
>
>-- John
>
>> -----Original Message-----
>> From:
>> linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org
>> [mailto:linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.
>> org] On Behalf Of Alan Casey
>> Sent: Friday, August 15, 2008 6:34 AM
>> To: wangyanlong; linuxppc-embedded@ozlabs.org
>> Subject: Re: Linux issues on Xilinx XUPV2P board
>>
>> Hi,
>>
>> I used version 2.6.24. Current version is 2.6.26+ but im
>> not sure how to download previous versions from the git
>> tree, there should be some info at http://git.xilinx.com
>> about how to do this.
>>
>> Regards,
>> Alan.
>>
>> >-- Original Message --
>> >Date: Fri, 15 Aug 2008 04:35:01 -0700 (PDT)
>> >From: wangyanlong <killyouatonce@gmail.com>
>> >To: linuxppc-embedded@ozlabs.org
>> >Subject: Re: Linux issues on Xilinx XUPV2P board
>> >
>> >
>> >
>> >Hi Alan
>> > I dow load the kernel from "
>> >http://git.xilinx.com/cgi-bin/gitweb.cgi?p=3Dlinux-2.6-xlnx.git
>> ;a=3Dsummary
>> "
>> >
>> >Merge ../../linux-2.6 into 2.6.26-merge master commit |
>> commitdiff | tree
>> >| snapshot
>> >
>> >this version ,but it not work well,which version you downloaded?
>> >
>> >Many thanks
>> >yanlong
>> >
>> >
>> >Alan Casey wrote:
>> >>
>> >> Hi,
>> >>
>> >> Yes i had a problem with using one of the Linux 2.6.26
>> >> kernel versions on the XUPV2P board where the VGA
>> >> display has not driven correctly, not sure why.
>> >> The Linux 2.6.24 kernel from git.xilinx.com works fine.
>> >>
>> >> Regards,
>> >> Alan.
>> >>
>> >>
>> >>>-- Original Message --
>> >>>Date: Fri, 15 Aug 2008 01:43:37 -0700 (PDT)
>> >>>From: wangyanlong <killyouatonce@gmail.com>
>> >>>To: linuxppc-embedded@ozlabs.org
>> >>>Subject: Re: Linux issues on Xilinx XUPV2P board
>> >>>
>> >>>
>> >>>
>> >>>I meet the problem as yours . And my vga's display is not
>> clear , have
>> >> you
>> >>>meet this?
>> >>>
>> >>>Alan Casey wrote:
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> I have tried running the Linux 2.6.24 and Linux 2.6.26
>> kernels from
>> >>
>> >>>
>> >>>> git.xilinx.com on the Xilinx XUPV2P board but have run
>> into a few
>> >>>> problems.
>> >>>>
>> >>>> Cross-compiler i use to compile applications was built using
>> >>>> Crosstools
>> >>>> and
>> >>>> based on gcc 3.3.4. I use Xilinx EDK 7.1 for
>> integrating hardware
>> >>>> peripherals
>> >>>> onto the board.
>> >>>>
>> >>>> The problems i've seen are:
>> >>>>
>> >>>> (i) gettimeofday software function returns time of 0
>> all the time.
>> >>>>
>> >>>> (ii) The Linux 2.6.24 kernel's Xilinx Framebuffer
>> driver and/or the
>> >>>> Xilinx
>> >>>>
>> >>>> PLB TFT Controller IP block
>> (plb_tft_cntlr_ref_v1_00_d) does
>> not
>> >>>> appear
>> >>>>
>> >>>> to centre the display on a VGA screen properly(vertically
>> >>>> offset).
>> >>>>
>> >>>> (iii) 64-bit write/read access to peripheral
>> integrated onto the
>> >>>> Xilinx
>> >>>>
>> >>>> Virtex-II Pro FPGA either causes a system crash
>> or only lower
>> >> part
>> >>>>
>> >>>> of 32-bit data to be written (i.e. lower part of
>> 64-bit data
>> >>>> appears
>> >>>> to be mirrored on the upper and lower 32-bits of
>> the system
>> >>>> bus).
>> >>>> However, 32-bit write/read access to the
>> peripheral passes as
>> >> well
>> >>>> as 64-bit write/read access to the SDRAM memory
>> address space.
>> >>>> Peripheral interface has been verified to be IBM
>> PLB compliant
>> >>>
>> >>>> via IBM bus functional model simulations.
>> >>>>
>> >>>> (iv) The Linux 2.6.26 Xilinx Framebuffer driver on
>> the Xilinx XUPV2P
>> >>>> board
>> >>>>
>> >>>> does not appear to be working - nothing displayed to
>> >>>> screen/console
>> >>>>
>> >>>> not switching to framebuffer device on bootup.
>> >>>>
>> >>>> Just wondering if anybody has seen these issues
>> before and know how
>> >>>to
>> >>>> resolve them?
>> >>>>
>> >>>> Any info. appreciated,
>> >>>> Regards,
>> >>>> Alan.
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> 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-issues-on-Xilinx-XUPV2P-board-tp1
>> 8262250p18995644.html
>> >>>Sent from the linuxppc-embedded mailing list archive at Nabble.com.=
>> >>>
>> >>>_______________________________________________
>> >>>Linuxppc-embedded mailing list
>> >>>Linuxppc-embedded@ozlabs.org
>> >>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>> >>
>> >>
>> >> _______________________________________________
>> >> 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-issues-on-Xilinx-XUPV2P-board-tp18
>> 262250p18997255.html
>> >Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>> >
>> >_______________________________________________
>> >Linuxppc-embedded mailing list
>> >Linuxppc-embedded@ozlabs.org
>> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>
>This email and any attachments are intended for the sole use of the name=
d
>recipient(s) and contain(s) confidential information that may be proprie=
tary,
>privileged or copyrighted under applicable law. If you are not the inten=
ded
>recipient, do not read, copy, or forward this email message or any attac=
hments.
>Delete this email message and any attachments immediately.
>
>
^ 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