* Re: Device tree and external RTC
From: Bruce_Leonard @ 2007-10-04 18:17 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.60.0710041046040.4537@poirot.grange>
Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote on 10/04/2007 02:29:06
AM:
> > CONFIG_SENSORS_M41T00=y
>
> It shall not hurt, but do you really have this one?
I turned this on because my clock is a SMT M41T00. Not sure why it's
called a sensor in the .config.
> First, this might be either a userspace or a kernel problem. Do you have
> the correct device nodes? Are you using udev? Should be something like
Ultimatly it was my own stupididty that did me in. You are absolutly
correct, I didn't have the right device nodes and because we're limited on
space we don't want to use udev. Once I created the rtc0 device and
linked rtc to it, hwclock started working correctly.
> > When I dump out ppc_md, all the RTC functions (i.e., get_rtc_time,
> > read_rtc_val, etc.) are all NULL.
>
> Don't think you need those. Those are for powerpc platforms not using
> the generic rtc driver.
Right.
> you need suitable entries in arch/powerpc/sysdev/fsl_soc.c in the
> i2c_devices array. I think, patch at
> http://patchwork.ozlabs.org/linuxppc/patch?id=13624 is exactly what you
> need.
I'll give this a try. I'd really prefer to be using the device tree for
this, but I guess as long as I have it working using configuration options
in the kernel it doesn't really matter. Either way I don't have to write
any special board support code for the kernel.
Thanks for all the information and pointers. It's been a big help!
Bruce
^ permalink raw reply
* Re: Device tree and external RTC
From: Bruce_Leonard @ 2007-10-04 18:25 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: Peter Korsgaard, linuxppc-embedded
In-Reply-To: <87ve9nw2ft.fsf@macbook.be.48ers.dk>
Peter,
Peter Korsgaard <jacmet@gmail.com> wrote on 10/04/2007 04:21:10 AM:
> >>>>> "Bruce" == Bruce Leonard <Bruce_Leonard@selinc.com> writes:
>
>
> You need to add #address/size-cells to the I2C node, E.G.:
> + #address-cells = <1>;
> + #size-cells = <0>;
>
>
> You need to set compatible and reg, E.G.
> rtc@54 {
> device_type = "rtc";
> compatible = "stm,m41t00";
> reg = <54>;
> };
>
> And it should get picked up automatically by
> fsl_soc.c:of_find_i2c_driver().
>
> Notice that you will need to use galak's git tree
Thanks for the info. It's this sort of thing that isn't clearly
documented anywhere, and until I'm REALLY familiar with the kernel knowing
where to look is a challenge.
A follow on question though. I've looked at the patch and it seems to be
just adding 6 lines to an existing array in fsl_soc.c. However, I can't
seem to find any array in fsl_soc.c that contains lines that the patch
indicates should already be there (i.e., there's nothing in fsl_soc.c that
has the word "ricoh" in it which the patch indicates it should). Is my
fsl_soc.c already out of date? Will the patch apply? I've got 2.6.22.
Bruce
^ permalink raw reply
* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Linas Vepstas @ 2007-10-04 18:36 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20071002012730.GO12049@parisc-linux.org>
On Mon, Oct 01, 2007 at 07:27:30PM -0600, Matthew Wilcox wrote:
>
> The thing to remember is that sym2 is in transition from being a dual
> BSD/Linux driver to being a purely Linux driver.
I was wondering about that; couldn't tell if the split in the code
was historical, or being intentionally maintained.
> > My gut instinct is to say "ack", although prudence dictates that
> > I should test first. Which might take a few days...
>
> Fine by me.
I tested the patch, it worked great. It also seemed to recover
much more quickly -- so quickly, in fact, that I thought something
had gone wrong.
I reviewed it one more time, it really does look good. A formal
submission and acked by's at earliest convenience would be good.
--linas
^ permalink raw reply
* Console handover: tty0 instead of ttyCPM0?
From: Alan Bennett @ 2007-10-04 18:46 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
Do you know what would cause this?
I've configured a board to console off of SMC1 (ttyCPM0) and on 1
board it works fine, however a new revision of the board I get the
following result and lose the console. Both boards have "exact"
versions of the kernel and u-boot.
BAD: console handover: boot [udbg0] -> real [tty0]
GOOD: console handover: boot [udbg0] -> real [ttyCPM0]
IMMRBASE is e0000000
CONFIG_PPC_EARLY_DEBUG_CPM=y
CONFIG_PPC_EARLY_DEBUG_CPM_ADDR=0xe0000888
doesn't WORK:
==========================================
zImage starting: loaded at 0x00400000 (sp: 0x07bc19a0)
Allocating 0x309670 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040c000:0x00710448)...done 0x2f0ad4 bytes
Linux/PowerPC load: root=/dev/nfs ip=192.168.10.45:::255.255.255.0::eth0 nfsroow
Finalizing device tree... flat tree at 0x71e3a0
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
Using Embedded Planet EP8248E machine description
Linux version 2.6.23-rc6-VTM-0007-1763 (root@fremont) (gcc version 3.4.5) #5 Th7
console [udbg0] enabled
setup_arch: bootmem
ep8248_setup_arch()
ep8248_setup_arch(), finish
arch: exit
Zone PFN ranges:
DMA 0 -> 32768
Normal 32768 -> 32768
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 32768
Built 1 zonelists in Zone order. Total pages: 32512
Kernel command line: root=/dev/nfs ip=192.168.10.45:::255.255.255.0::eth0 nfsrow
PID hash table entries: 512 (order: 9, 2048 bytes)
Console: colour dummy device 80x25
console handover: boot [udbg0] -> real [tty0]
BOARD THAT WORKS:
==========================================
zImage starting: loaded at 0x00400000 (sp: 0x07bc19a0)
Allocating 0x309670 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040c000:0x00710448)...done 0x2f0ad4 bytes
Linux/PowerPC load: console=ttyCPM0,38400n8 root=/dev/nfs ip=192.168.10.49:::25
Finalizing device tree... flat tree at 0x71e3a0
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
Using Embedded Planet EP8248E machine description
Linux version 2.6.23-rc6-VTM-0007-1763 (root@fremont) (gcc version 3.4.5) #5 Th7
console [udbg0] enabled
setup_arch: bootmem
ep8248_setup_arch()
ep8248_setup_arch(), finish
arch: exit
Zone PFN ranges:
DMA 0 -> 32768
Normal 32768 -> 32768
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 32768
Built 1 zonelists in Zone order. Total pages: 32512
Kernel command line: console=ttyCPM0,38400n8 root=/dev/nfs ip=192.168.10.49:::2
PID hash table entries: 512 (order: 9, 2048 bytes)
Console: colour dummy device 80x25Dentry cache hash table entries: 16384 (order)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 126660k/131072k available (2852k kernel code, 4264k reserved, 132k data)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
Generic PHY: Registered new driver
^ permalink raw reply
* Re: Console handover: tty0 instead of ttyCPM0?
From: Scott Wood @ 2007-10-04 18:50 UTC (permalink / raw)
To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0710041146y2c74b9dcy3dd413934680ab10@mail.gmail.com>
Alan Bennett wrote:
> Do you know what would cause this?
>
> I've configured a board to console off of SMC1 (ttyCPM0) and on 1
> board it works fine, however a new revision of the board I get the
> following result and lose the console. Both boards have "exact"
> versions of the kernel and u-boot.
>
> BAD: console handover: boot [udbg0] -> real [tty0]
> GOOD: console handover: boot [udbg0] -> real [ttyCPM0]
[snip]
> Linux/PowerPC load: root=/dev/nfs ip=192.168.10.45:::255.255.255.0::eth0 nfsroow
You really should turn on line wrap in your serial program...
> console handover: boot [udbg0] -> real [tty0]
[snip]
> Kernel command line: console=ttyCPM0,38400n8 root=/dev/nfs ip=192.168.10.49:::2
This one has console=ttyCPM0. The other one doesn't (unless it was
eaten by the lack of line wrap).
-Scott
^ permalink raw reply
* Re: Device tree and external RTC
From: Guennadi Liakhovetski @ 2007-10-04 19:52 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-embedded
In-Reply-To: <OF6E4972CE.0F54E43B-ON8825736A.00637A7C-8825736A.00646F2A@selinc.com>
On Thu, 4 Oct 2007 Bruce_Leonard@selinc.com wrote:
> Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote on 10/04/2007 02:29:06
> AM:
>
> > > CONFIG_SENSORS_M41T00=y
> >
> > It shall not hurt, but do you really have this one?
>
> I turned this on because my clock is a SMT M41T00. Not sure why it's
> called a sensor in the .config.
It is the deprecated driver for the same rtc chip. But maybe it is this
one that makes your RTC work ATM, see below.
> > First, this might be either a userspace or a kernel problem. Do you have
>
> > the correct device nodes? Are you using udev? Should be something like
>
> Ultimatly it was my own stupididty that did me in. You are absolutly
> correct, I didn't have the right device nodes and because we're limited on
> space we don't want to use udev. Once I created the rtc0 device and
> linked rtc to it, hwclock started working correctly.
It shouldn't. It probably does thanks to the m41t00 driver, but you don't
want it, instead...
> > you need suitable entries in arch/powerpc/sysdev/fsl_soc.c in the
> > i2c_devices array. I think, patch at
> > http://patchwork.ozlabs.org/linuxppc/patch?id=13624 is exactly what you
> > need.
>
> I'll give this a try. I'd really prefer to be using the device tree for
> this, but I guess as long as I have it working using configuration options
> in the kernel it doesn't really matter. Either way I don't have to write
> any special board support code for the kernel.
you need this patch to get ds1307 attach to your rtc chip.
And, besides, linuxppc-embedded is deprecated, linuxppc-dev should be used
instead:-)
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: [PATCH] [POWERPC] update immap_86xx.h for the 8610
From: Timur Tabi @ 2007-10-04 22:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <11913604331348-git-send-email-timur@freescale.com>
Kumar, can you pull this patch into your 2.6.24 tree? It's needed for the 8610.
Timur Tabi wrote:
> Update the definition of the global utilities structure (ccsr_guts) in
> immap_86xx.h and add some related macros for the Freescale 8610 SOC.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>
> This patch is for 2.6.24.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [RFC][PATCH][POWERPC] QEIC: Implement pluggable handlers, fix MPIC cascading
From: Benjamin Herrenschmidt @ 2007-10-04 22:05 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071004130454.GA15448@localhost.localdomain>
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
> Subject: [PATCH] [POWERPC] QEIC: Implement pluggable handlers, fix MPIC cascading
>
> set_irq_chained_handler overwrites MPIC's handle_irq function
> (handle_fasteoi_irq) thus MPIC never gets eoi event from the
> cascaded IRQ. This situation hangs MPIC on MPC8568E.
>
> To solve this problem efficiently, QEIC needs pluggable handlers,
> specific to the underlaying interrupt controller.
>
> Patch extends qe_ic_init() function to accept low and high interrupt
> handlers. To avoid #ifdefs, stack of interrupt handlers specified in
> the header file and functions are marked 'static inline', thus
> handlers are compiled-in only if actually used (in the board file).
> Another option would be to lookup for parent controller and
> automatically detect handlers, but this will waste text size because
> of never used handlers.
>
> qe_ic_init() also changed in regard to support multiplexed high/low
> lines as found in MPC8568E-MDS, plus qe_ic_cascade_muxed_mpic()
> handler implemented appropriately.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Looks allright, if it also works, then ship it :-)
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/platforms/83xx/mpc832x_mds.c | 2 +-
> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 2 +-
> arch/powerpc/platforms/83xx/mpc836x_mds.c | 2 +-
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 2 +-
> arch/powerpc/sysdev/qe_lib/qe_ic.c | 29 +++---------
> include/asm-powerpc/qe_ic.h | 68 ++++++++++++++++++++++++++++-
> 6 files changed, 78 insertions(+), 27 deletions(-)
>
> diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c
> index d494bc4..95f32ca 100644
> --- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
> +++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
> @@ -140,7 +140,7 @@ static void __init mpc832x_sys_init_IRQ(void)
> if (!np)
> return;
>
> - qe_ic_init(np, 0);
> + qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic);
> of_node_put(np);
> #endif /* CONFIG_QUICC_ENGINE */
> }
> diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
> index 24a790c..f842a1c 100644
> --- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
> +++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
> @@ -151,7 +151,7 @@ void __init mpc832x_rdb_init_IRQ(void)
> if (!np)
> return;
>
> - qe_ic_init(np, 0);
> + qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic);
> of_node_put(np);
> #endif /* CONFIG_QUICC_ENGINE */
> }
> diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c
> index db69576..5971fe6 100644
> --- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
> +++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
> @@ -147,7 +147,7 @@ static void __init mpc836x_mds_init_IRQ(void)
> if (!np)
> return;
>
> - qe_ic_init(np, 0);
> + qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic);
> of_node_put(np);
> #endif /* CONFIG_QUICC_ENGINE */
> }
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> index c379286..69c177b 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> @@ -174,7 +174,7 @@ static void __init mpc85xx_mds_pic_init(void)
> if (!np)
> return;
>
> - qe_ic_init(np, 0);
> + qe_ic_init(np, 0, qe_ic_cascade_muxed_mpic, NULL);
> of_node_put(np);
> #endif /* CONFIG_QUICC_ENGINE */
> }
> diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c b/arch/powerpc/sysdev/qe_lib/qe_ic.c
> index 9a2d1ed..e1c0fd6 100644
> --- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
> +++ b/arch/powerpc/sysdev/qe_lib/qe_ic.c
> @@ -321,25 +321,9 @@ unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic)
> return irq_linear_revmap(qe_ic->irqhost, irq);
> }
>
> -void qe_ic_cascade_low(unsigned int irq, struct irq_desc *desc)
> -{
> - struct qe_ic *qe_ic = desc->handler_data;
> - unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
> -
> - if (cascade_irq != NO_IRQ)
> - generic_handle_irq(cascade_irq);
> -}
> -
> -void qe_ic_cascade_high(unsigned int irq, struct irq_desc *desc)
> -{
> - struct qe_ic *qe_ic = desc->handler_data;
> - unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
> -
> - if (cascade_irq != NO_IRQ)
> - generic_handle_irq(cascade_irq);
> -}
> -
> -void __init qe_ic_init(struct device_node *node, unsigned int flags)
> +void __init qe_ic_init(struct device_node *node, unsigned int flags,
> + void (*low_handler)(unsigned int irq, struct irq_desc *desc),
> + void (*high_handler)(unsigned int irq, struct irq_desc *desc))
> {
> struct qe_ic *qe_ic;
> struct resource res;
> @@ -399,11 +383,12 @@ void __init qe_ic_init(struct device_node *node, unsigned int flags)
> qe_ic_write(qe_ic->regs, QEIC_CICR, temp);
>
> set_irq_data(qe_ic->virq_low, qe_ic);
> - set_irq_chained_handler(qe_ic->virq_low, qe_ic_cascade_low);
> + set_irq_chained_handler(qe_ic->virq_low, low_handler);
>
> - if (qe_ic->virq_high != NO_IRQ) {
> + if (qe_ic->virq_high != NO_IRQ &&
> + qe_ic->virq_high != qe_ic->virq_low) {
> set_irq_data(qe_ic->virq_high, qe_ic);
> - set_irq_chained_handler(qe_ic->virq_high, qe_ic_cascade_high);
> + set_irq_chained_handler(qe_ic->virq_high, high_handler);
> }
> }
>
> diff --git a/include/asm-powerpc/qe_ic.h b/include/asm-powerpc/qe_ic.h
> index e386fb7..a779b2c 100644
> --- a/include/asm-powerpc/qe_ic.h
> +++ b/include/asm-powerpc/qe_ic.h
> @@ -56,9 +56,75 @@ enum qe_ic_grp_id {
> QE_IC_GRP_RISCB /* QE interrupt controller RISC group B */
> };
>
> -void qe_ic_init(struct device_node *node, unsigned int flags);
> +void qe_ic_init(struct device_node *node, unsigned int flags,
> + void (*low_handler)(unsigned int irq, struct irq_desc *desc),
> + void (*high_handler)(unsigned int irq, struct irq_desc *desc));
> void qe_ic_set_highest_priority(unsigned int virq, int high);
> int qe_ic_set_priority(unsigned int virq, unsigned int priority);
> int qe_ic_set_high_priority(unsigned int virq, unsigned int priority, int high);
>
> +struct qe_ic;
> +unsigned int qe_ic_get_low_irq(struct qe_ic *qe_ic);
> +unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic);
> +
> +static inline void qe_ic_cascade_low_ipic(unsigned int irq,
> + struct irq_desc *desc)
> +{
> + struct qe_ic *qe_ic = desc->handler_data;
> + unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
> +
> + if (cascade_irq != NO_IRQ)
> + generic_handle_irq(cascade_irq);
> +}
> +
> +static inline void qe_ic_cascade_high_ipic(unsigned int irq,
> + struct irq_desc *desc)
> +{
> + struct qe_ic *qe_ic = desc->handler_data;
> + unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
> +
> + if (cascade_irq != NO_IRQ)
> + generic_handle_irq(cascade_irq);
> +}
> +
> +static inline void qe_ic_cascade_low_mpic(unsigned int irq,
> + struct irq_desc *desc)
> +{
> + struct qe_ic *qe_ic = desc->handler_data;
> + unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
> +
> + if (cascade_irq != NO_IRQ)
> + generic_handle_irq(cascade_irq);
> +
> + desc->chip->eoi(irq);
> +}
> +
> +static inline void qe_ic_cascade_high_mpic(unsigned int irq,
> + struct irq_desc *desc)
> +{
> + struct qe_ic *qe_ic = desc->handler_data;
> + unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
> +
> + if (cascade_irq != NO_IRQ)
> + generic_handle_irq(cascade_irq);
> +
> + desc->chip->eoi(irq);
> +}
> +
> +static inline void qe_ic_cascade_muxed_mpic(unsigned int irq,
> + struct irq_desc *desc)
> +{
> + struct qe_ic *qe_ic = desc->handler_data;
> + unsigned int cascade_irq;
> +
> + cascade_irq = qe_ic_get_high_irq(qe_ic);
> + if (cascade_irq == NO_IRQ)
> + cascade_irq = qe_ic_get_low_irq(qe_ic);
> +
> + if (cascade_irq != NO_IRQ)
> + generic_handle_irq(cascade_irq);
> +
> + desc->chip->eoi(irq);
> +}
> +
> #endif /* _ASM_POWERPC_QE_IC_H */
^ permalink raw reply
* include/asm/cpm2.h:14:21: error: asm/cpm.h: No such file or directory
From: Timur Tabi @ 2007-10-04 22:28 UTC (permalink / raw)
To: Kumar Gala, PowerPC dev list
Kumar, this is what I get when I compile your 2.6.24 branch for the 8610:
CC arch/powerpc/sysdev/fsl_soc.o
In file included from arch/powerpc/sysdev/fsl_soc.c:40:
include/asm/cpm2.h:14:21: error: asm/cpm.h: No such file or directory
make[1]: *** [arch/powerpc/sysdev/fsl_soc.o] Error 1
make: *** [arch/powerpc/sysdev] Error 2
Commenting out the "#include <asm/cpm.h>" in cpm2.h makes the compilation
failure go away, but I don't know if that's the proper fix, since the 8610
doesn't have a CPM.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Nish Aravamudan @ 2007-10-05 0:01 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <20071003011909.GG9814@bakeyournoodle.com>
On 10/2/07, Tony Breeds <tony@bakeyournoodle.com> wrote:
> On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote:
>
> > I realise it'll make the patch bigger, but this doesn't seem like a
> > particularly good name for the variable anymore.
>
> Sure, what about?
>
> Clarify when RTAS logging is enabled.
>
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
For what it's worth, on a different ppc64 box, this resolves a similar
panic for me.
Tested-by: Nishanth Aravamudan <nacc@us.ibm.com>
Thanks,
Nish
^ permalink raw reply
* Re: include/asm/cpm2.h:14:21: error: asm/cpm.h: No such file or directory
From: Kumar Gala @ 2007-10-05 0:57 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <4705691A.9020509@freescale.com>
On Oct 4, 2007, at 5:28 PM, Timur Tabi wrote:
> Kumar, this is what I get when I compile your 2.6.24 branch for the
> 8610:
>
> CC arch/powerpc/sysdev/fsl_soc.o
> In file included from arch/powerpc/sysdev/fsl_soc.c:40:
> include/asm/cpm2.h:14:21: error: asm/cpm.h: No such file or directory
> make[1]: *** [arch/powerpc/sysdev/fsl_soc.o] Error 1
> make: *** [arch/powerpc/sysdev] Error 2
>
> Commenting out the "#include <asm/cpm.h>" in cpm2.h makes the
> compilation failure go away, but I don't know if that's the proper
> fix, since the 8610 doesn't have a CPM.
Scott mentioned this and I've fixed it in my tree.
- k
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: Mark A. Greer @ 2007-10-05 1:58 UTC (permalink / raw)
To: Valentine Barshak, linuxppc-dev
In-Reply-To: <20071003055005.GD18978@localhost.localdomain>
On Wed, Oct 03, 2007 at 03:50:05PM +1000, David Gibson wrote:
> On Fri, Sep 28, 2007 at 06:23:09PM +0400, Valentine Barshak wrote:
> > David Gibson wrote:
> > > On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote:
> > Looking deeper at this I've found that currently u-boot thinks that
> > memory space over 8MB is not reached by Linux kernel (CFG_BOOTMAPSZ
> > defined as (8 << 20)), although all physical memory is identity mapped.
> > That's why it puts command line and board info structure as high as
> > possible within the first 8MB. This worked fine with uImage, since
> > u-boot always unpacked it to 0. Now, cuImage has to be unpacked higher
> > (we need space at the start of the memory to eventually put vmlinux
> > image there). So, if unpacked kernel image crosses 8MB boundary, it gets
> > damaged by u-boot when it prepares cmd_line and bdinfo. The possible
> > workaround for that is to always link zImage at >=8MB base or to have
> > 4MB granularity like this:
> >
> > + . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024));
> >
> > Reserve at least 64K for u-boot cmd_line and bdinfo.
>
> Ah. Right. That makes things a bit tricky. Even this 4MB
> granularity may not be enough (say, if the vmlinux is < 4MB, but the
> zImage has a really big initrd and is > 4MB).
>
> Except... it shouldn't really be the link address that matters. The
> zImage is relocatable, so it should only be the load address specified
> in the uImage header which matters. I think that's currently derived
> from the link address, but it doesn't have to be.
Having the link address jump around depending on the size of the kernel
or zImage is wrong IMHO. It just screams "weird can't boot issues."
We need a way to specify exactly where we want the zImage linked no
matter what the kernel or zImage size.
Also, being able to control the link address (that is, the download
address with some firmwares) is not a u-boot specific issue and we
shouldn't make a u-boot specific solution.
The more general problem is that some firmwares examine the ELF header
and download the zImage to address it was linked at. Some firmwares let
you override this but some don't and those are the problem ones.
We talked about this a bit back in February,
http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031532.html
In that thread Geoff Levand suggested a config option and running it
thru a preprocessor. David Gibson suggested making a replaceable linker
script. I suggested passing the value of a config option to the wrapper
script which would use objcopy/whatever to change the section addresses
in the image (maybe this is what Geoff had in mind, I'm not sure).
I still like my idea best. I haven't coded yet it so I don't have a patch
but this is what I mean:
1) add a config option (default 4MB) for the link address
2) add a parameter to the wrapper script thru which we pass the value in
the config option
3) the wrapper script changes the VMA/LMA to the address specified
(objcopy --change-addresses=<some math to get correct incr> ?).
I'll code it up in the next day or two unless someone doesn't like the idea.
Mark
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: David Gibson @ 2007-10-05 2:25 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20071005015849.GA9862@mag.az.mvista.com>
On Thu, Oct 04, 2007 at 06:58:49PM -0700, Mark A. Greer wrote:
> On Wed, Oct 03, 2007 at 03:50:05PM +1000, David Gibson wrote:
> > On Fri, Sep 28, 2007 at 06:23:09PM +0400, Valentine Barshak wrote:
> > > David Gibson wrote:
> > > > On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote:
>
> > > Looking deeper at this I've found that currently u-boot thinks that
> > > memory space over 8MB is not reached by Linux kernel (CFG_BOOTMAPSZ
> > > defined as (8 << 20)), although all physical memory is identity mapped.
> > > That's why it puts command line and board info structure as high as
> > > possible within the first 8MB. This worked fine with uImage, since
> > > u-boot always unpacked it to 0. Now, cuImage has to be unpacked higher
> > > (we need space at the start of the memory to eventually put vmlinux
> > > image there). So, if unpacked kernel image crosses 8MB boundary, it gets
> > > damaged by u-boot when it prepares cmd_line and bdinfo. The possible
> > > workaround for that is to always link zImage at >=8MB base or to have
> > > 4MB granularity like this:
> > >
> > > + . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024));
> > >
> > > Reserve at least 64K for u-boot cmd_line and bdinfo.
> >
> > Ah. Right. That makes things a bit tricky. Even this 4MB
> > granularity may not be enough (say, if the vmlinux is < 4MB, but the
> > zImage has a really big initrd and is > 4MB).
> >
> > Except... it shouldn't really be the link address that matters. The
> > zImage is relocatable, so it should only be the load address specified
> > in the uImage header which matters. I think that's currently derived
> > from the link address, but it doesn't have to be.
>
> Having the link address jump around depending on the size of the kernel
> or zImage is wrong IMHO. It just screams "weird can't boot issues."
Hrm. Except we already have that - the zImage is linked at a fixed
location, and will just not work if the sizes are wrong.
> We need a way to specify exactly where we want the zImage linked no
> matter what the kernel or zImage size.
>
> Also, being able to control the link address (that is, the download
> address with some firmwares) is not a u-boot specific issue and we
> shouldn't make a u-boot specific solution.
>
> The more general problem is that some firmwares examine the ELF header
> and download the zImage to address it was linked at. Some firmwares let
> you override this but some don't and those are the problem ones.
>
> We talked about this a bit back in February,
> http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031532.html
>
> In that thread Geoff Levand suggested a config option and running it
> thru a preprocessor. David Gibson suggested making a replaceable linker
> script. I suggested passing the value of a config option to the wrapper
> script which would use objcopy/whatever to change the section addresses
> in the image (maybe this is what Geoff had in mind, I'm not sure).
>
> I still like my idea best. I haven't coded yet it so I don't have a patch
> but this is what I mean:
>
> 1) add a config option (default 4MB) for the link address
> 2) add a parameter to the wrapper script thru which we pass the value in
> the config option
> 3) the wrapper script changes the VMA/LMA to the address specified
> (objcopy --change-addresses=<some math to get correct incr> ?).
>
> I'll code it up in the next day or two unless someone doesn't like the idea.
A config option just doesn't seem right to me, except as a
special-circumstances hack. The zImage is already hardware and
firmware specific; we should be able to figure out workable link and
load addresses for a specific zImage (which might need to be different
for different zImages produced by the same config).
Of course, the same objection would apply to CONFIG_DEVICE_TREE which
we have already.
--
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: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: Mark A. Greer @ 2007-10-05 2:59 UTC (permalink / raw)
To: Mark A. Greer, Valentine Barshak, linuxppc-dev
In-Reply-To: <20071005022554.GE25637@localhost.localdomain>
On Fri, Oct 05, 2007 at 12:25:54PM +1000, David Gibson wrote:
> On Thu, Oct 04, 2007 at 06:58:49PM -0700, Mark A. Greer wrote:
> > On Wed, Oct 03, 2007 at 03:50:05PM +1000, David Gibson wrote:
> > > On Fri, Sep 28, 2007 at 06:23:09PM +0400, Valentine Barshak wrote:
> > > > David Gibson wrote:
> > > > > On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote:
> >
> > > > Looking deeper at this I've found that currently u-boot thinks that
> > > > memory space over 8MB is not reached by Linux kernel (CFG_BOOTMAPSZ
> > > > defined as (8 << 20)), although all physical memory is identity mapped.
> > > > That's why it puts command line and board info structure as high as
> > > > possible within the first 8MB. This worked fine with uImage, since
> > > > u-boot always unpacked it to 0. Now, cuImage has to be unpacked higher
> > > > (we need space at the start of the memory to eventually put vmlinux
> > > > image there). So, if unpacked kernel image crosses 8MB boundary, it gets
> > > > damaged by u-boot when it prepares cmd_line and bdinfo. The possible
> > > > workaround for that is to always link zImage at >=8MB base or to have
> > > > 4MB granularity like this:
> > > >
> > > > + . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024));
> > > >
> > > > Reserve at least 64K for u-boot cmd_line and bdinfo.
> > >
> > > Ah. Right. That makes things a bit tricky. Even this 4MB
> > > granularity may not be enough (say, if the vmlinux is < 4MB, but the
> > > zImage has a really big initrd and is > 4MB).
> > >
> > > Except... it shouldn't really be the link address that matters. The
> > > zImage is relocatable, so it should only be the load address specified
> > > in the uImage header which matters. I think that's currently derived
> > > from the link address, but it doesn't have to be.
> >
> > Having the link address jump around depending on the size of the kernel
> > or zImage is wrong IMHO. It just screams "weird can't boot issues."
>
> Hrm. Except we already have that - the zImage is linked at a fixed
> location, and will just not work if the sizes are wrong.
Yes, its an issue now (which is why we're having this discussion) but
at least its predictable ATM. Having it jump around on you because
you happened to set/clear a CONFIG option is worse.
My point is that the address needs to be set manually--no fancy heuristics
or whatever to guess.
> > We need a way to specify exactly where we want the zImage linked no
> > matter what the kernel or zImage size.
> >
> > Also, being able to control the link address (that is, the download
> > address with some firmwares) is not a u-boot specific issue and we
> > shouldn't make a u-boot specific solution.
> >
> > The more general problem is that some firmwares examine the ELF header
> > and download the zImage to address it was linked at. Some firmwares let
> > you override this but some don't and those are the problem ones.
> >
> > We talked about this a bit back in February,
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031532.html
> >
> > In that thread Geoff Levand suggested a config option and running it
> > thru a preprocessor. David Gibson suggested making a replaceable linker
> > script. I suggested passing the value of a config option to the wrapper
> > script which would use objcopy/whatever to change the section addresses
> > in the image (maybe this is what Geoff had in mind, I'm not sure).
> >
> > I still like my idea best. I haven't coded yet it so I don't have a patch
> > but this is what I mean:
> >
> > 1) add a config option (default 4MB) for the link address
> > 2) add a parameter to the wrapper script thru which we pass the value in
> > the config option
> > 3) the wrapper script changes the VMA/LMA to the address specified
> > (objcopy --change-addresses=<some math to get correct incr> ?).
> >
> > I'll code it up in the next day or two unless someone doesn't like the idea.
>
> A config option just doesn't seem right to me, except as a
> special-circumstances hack.
Acutally, I started to hack up the patch and noticed that its already
there. Its 'CONFIG_BOOT_LOAD' which is an "Advanced setup" option
in arch/powerpc/Kconfig (probably migrated from arch/ppc/Kconfig).
Several defconfig's have it set but its not used AFAICS.
> The zImage is already hardware and
> firmware specific;
And [potentially] firmware version and zImage size specific.
> we should be able to figure out workable link and
> load addresses for a specific zImage
I was going to argue with you here until...
> (which might need to be different
> for different zImages produced by the same config).
Oh yeah, I forgot about multiple zImages from the same config. D*mn.
Hmm, I guess I have to think about this more then. (and stop hacking up
the patch I was talking about).
> Of course, the same objection would apply to CONFIG_DEVICE_TREE which
> we have already.
Yep.
Mark
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: Mark A. Greer @ 2007-10-05 3:08 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20071005025930.GA24218@mag.az.mvista.com>
On Thu, Oct 04, 2007 at 07:59:30PM -0700, Mark A. Greer wrote:
> On Fri, Oct 05, 2007 at 12:25:54PM +1000, David Gibson wrote:
> > The zImage is already hardware and
> > firmware specific;
>
> And [potentially] firmware version and zImage size specific.
I meant to add, "which is why it'll be difficult to come up with a
heuristic that will work in all situations."
Mark
^ permalink raw reply
* Re: [PATCH] [POWERPC] update immap_86xx.h for the 8610
From: Kumar Gala @ 2007-10-05 3:24 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <4705634A.9070800@freescale.com>
On Oct 4, 2007, at 5:03 PM, Timur Tabi wrote:
> Kumar, can you pull this patch into your 2.6.24 tree? It's needed
> for the 8610.
applied.
- k
^ permalink raw reply
* Fix regression. Make hot unlplug of CPU0 work again.
From: Tony Breeds @ 2007-10-05 3:52 UTC (permalink / raw)
To: Paul Mackerras, LinuxPPC-dev
Early in the 2.6.23 cycle we broke the ability to offline cpu0
(7ccb4a662462616f6be5053e26b79580e02f1529). This patch fixes that by
ensuring that the (xics) default irq server, will not be 0 when taking
cpu0 offline.
Also catches a use of irq, when virq should be used (I think that the
last one).
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
Unless there is a problem with this patch, it'd be nice to get it into
2.6.23 :)
arch/powerpc/platforms/pseries/xics.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
index f0b5ff1..2fb8fd0 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -837,6 +837,15 @@ void xics_migrate_irqs_away(void)
/* Allow IPIs again... */
xics_set_cpu_priority(cpu, DEFAULT_PRIORITY);
+ /* It would be bad to migrate any IRQs to the CPU we're taking down */
+ if (default_server == cpu) {
+ unsigned int new_server = first_cpu(cpu_online_map);
+
+ default_server = get_hard_smp_processor_id(new_server);
+ printk(KERN_WARNING "%s: default server was %d, reset to %d\n",
+ __func__, cpu, default_server);
+ }
+
for_each_irq(virq) {
struct irq_desc *desc;
int xics_status[2];
@@ -882,7 +891,7 @@ void xics_migrate_irqs_away(void)
/* Reset affinity to all cpus */
desc->chip->set_affinity(virq, CPU_MASK_ALL);
- irq_desc[irq].affinity = CPU_MASK_ALL;
+ irq_desc[virq].affinity = CPU_MASK_ALL;
unlock:
spin_unlock_irqrestore(&desc->lock, flags);
}
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* Re: [PATCH 4/7] [POWERPC] QE pario: support for MPC85xx layout
From: Kumar Gala @ 2007-10-05 5:15 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070925143440.GD5323@localhost.localdomain>
On Sep 25, 2007, at 9:34 AM, Anton Vorontsov wrote:
> 8 bytes padding required to match MPC85xx registers layout.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/sysdev/qe_lib/qe_io.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/qe_lib/qe_io.c b/arch/powerpc/
> sysdev/qe_lib/qe_io.c
> index e32b45b..d566e89 100644
> --- a/arch/powerpc/sysdev/qe_lib/qe_io.c
> +++ b/arch/powerpc/sysdev/qe_lib/qe_io.c
> @@ -36,6 +36,9 @@ struct port_regs {
> __be32 cpdir2; /* Direction register */
> __be32 cppar1; /* Pin assignment register */
> __be32 cppar2; /* Pin assignment register */
> +#ifdef CONFIG_MPC85xx
use CONFIG_PPC_85xx
> + u8 pad[8];
> +#endif
> };
- k
^ permalink raw reply
* Re: [RFC][PATCH][POWERPC] QEIC: Implement pluggable handlers, fix MPIC cascading
From: Kumar Gala @ 2007-10-05 5:18 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: PowerPC dev list
In-Reply-To: <1191535520.28239.2.camel@pasglop>
On Oct 4, 2007, at 5:05 PM, Benjamin Herrenschmidt wrote:
>
>> From: Anton Vorontsov <avorontsov@ru.mvista.com>
>> Subject: [PATCH] [POWERPC] QEIC: Implement pluggable handlers, fix
>> MPIC cascading
>>
>> set_irq_chained_handler overwrites MPIC's handle_irq function
>> (handle_fasteoi_irq) thus MPIC never gets eoi event from the
>> cascaded IRQ. This situation hangs MPIC on MPC8568E.
>>
>> To solve this problem efficiently, QEIC needs pluggable handlers,
>> specific to the underlaying interrupt controller.
>>
>> Patch extends qe_ic_init() function to accept low and high interrupt
>> handlers. To avoid #ifdefs, stack of interrupt handlers specified in
>> the header file and functions are marked 'static inline', thus
>> handlers are compiled-in only if actually used (in the board file).
>> Another option would be to lookup for parent controller and
>> automatically detect handlers, but this will waste text size because
>> of never used handlers.
>>
>> qe_ic_init() also changed in regard to support multiplexed high/low
>> lines as found in MPC8568E-MDS, plus qe_ic_cascade_muxed_mpic()
>> handler implemented appropriately.
>>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
> Looks allright, if it also works, then ship it :-)
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Now that this has been ack'd by Ben if you can respin the patch set
we can get these in for 2.6.24
(I assume you are using a UCC as ethernet for test some of the QE
support on 8568?)
- k
^ permalink raw reply
* Re: Fix regression. Make hot unlplug of CPU0 work again.
From: Tony Breeds @ 2007-10-05 7:05 UTC (permalink / raw)
To: Paul Mackerras, LinuxPPC-dev
In-Reply-To: <20071005035241.GO9814@bakeyournoodle.com>
On Fri, Oct 05, 2007 at 01:52:41PM +1000, Tony Breeds wrote:
> Early in the 2.6.23 cycle we broke the ability to offline cpu0
> (7ccb4a662462616f6be5053e26b79580e02f1529). This patch fixes that by
> ensuring that the (xics) default irq server, will not be 0 when taking
> cpu0 offline.
>
> Also catches a use of irq, when virq should be used (I think that the
> last one).
Hmm testing, this on a JS21 shows that it doesn't work. I guess I'll go
back to the drawing board.
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: Device tree and external RTC
From: Guennadi Liakhovetski @ 2007-10-05 10:45 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: Peter Korsgaard, linuxppc-embedded
In-Reply-To: <OFF5EAF9C9.4E27AE67-ON8825736A.0064875E-8825736A.00652EB0@selinc.com>
On Thu, 4 Oct 2007 Bruce_Leonard@selinc.com wrote:
> A follow on question though. I've looked at the patch and it seems to be
> just adding 6 lines to an existing array in fsl_soc.c. However, I can't
> seem to find any array in fsl_soc.c that contains lines that the patch
> indicates should already be there (i.e., there's nothing in fsl_soc.c that
> has the word "ricoh" in it which the patch indicates it should). Is my
> fsl_soc.c already out of date? Will the patch apply? I've got 2.6.22.
Ok, we both (Peter and myself) have forgotten, that this change has first
aooeared after 2.6.22. So, best try 2.6.23-rc9, or use one of the
git-trees (from Linux or from Paulus, or from Kumar Gala, or...) _plus_
the patch we both pointed at.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: Fix regression. Make hot unlplug of CPU0 work again.
From: Michael Ellerman @ 2007-10-05 12:20 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <20071005070519.GQ9814@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]
On Fri, 2007-10-05 at 17:05 +1000, Tony Breeds wrote:
> On Fri, Oct 05, 2007 at 01:52:41PM +1000, Tony Breeds wrote:
> > Early in the 2.6.23 cycle we broke the ability to offline cpu0
> > (7ccb4a662462616f6be5053e26b79580e02f1529). This patch fixes that by
> > ensuring that the (xics) default irq server, will not be 0 when taking
> > cpu0 offline.
> >
> > Also catches a use of irq, when virq should be used (I think that the
> > last one).
>
> Hmm testing, this on a JS21 shows that it doesn't work. I guess I'll go
> back to the drawing board.
Maybe we should revert the original patch and go back to the drawing
board for 2.6.24? Making sure we address the initial problem (which was
exposed by kexec I think) and that we don't break cpu hotplug on the
way.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH][POWERPC] QEIC: Implement pluggable handlers, fix MPIC cascading
From: Anton Vorontsov @ 2007-10-05 12:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list
In-Reply-To: <E6B4F79B-254F-4273-8E49-D15BCFF6955A@kernel.crashing.org>
On Fri, Oct 05, 2007 at 12:18:58AM -0500, Kumar Gala wrote:
[...]
>>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>>
>> Looks allright, if it also works, then ship it :-)
>>
>> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Now that this has been ack'd by Ben if you can respin the patch set we can
> get these in for 2.6.24
Great, will do.
> (I assume you are using a UCC as ethernet for test some of the QE support
> on 8568?)
Yup, UCC as eth. Plus I've also tested SPI (which is in QE) in
loopback mode.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] fsl_spi_init: Support non-QE processors
From: Kumar Gala @ 2007-10-05 14:11 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: PowerPC dev list, Stephen Rothwell
In-Reply-To: <20071004140126.99c0fab0.sfr@canb.auug.org.au>
On Oct 3, 2007, at 11:01 PM, Stephen Rothwell wrote:
> On Wed, 03 Oct 2007 17:43:50 +0200 Peter Korsgaard
> <jacmet@sunsite.dk> wrote:
>>
>> @@ -1220,14 +1220,17 @@ int __init fsl_spi_init(struct
>> spi_board_info *board_infos,
>> {
>> struct device_node *np;
>> unsigned int i;
>> - const u32 *sysclk;
>> + const u32 *qe_sysclk = 0, *soc_sysclk = 0;
>
> Please use NULL when referring to pointers.
Peter, any chance of getting a respin. I'd like this to go into 2.6.24.
- k
^ permalink raw reply
* jedec probe for AMD/Spansion flash (16 bit) device in 8 bit mode fails
From: Norbert van Bolhuis @ 2007-10-05 15:25 UTC (permalink / raw)
To: linuxppc-embedded, linux-mtd
My board has a regular AMD/Spansion compatible flash device. It's a
Spansion S29AL016D (2MB) which supports 8/16 bit access.
We use it in 8 bit and top boot block mode.
I thought the linux kernel would have no problem recognizing/supporting this
(regular) flash device. I was wrong.
The S29AL016D/AM29LV160DT datasheet says the following:
first second third fourth (read)
addr/data addr/data addr/data addr/data
Manufacturer ID, word 555/AA 2AA/55 555/90 X00/01
byte AAA/AA 555/55 AAA/90 X00/01
Device ID (top boot block), word 555/AA 2AA/55 555/90 X01/22C4
byte AAA/AA 555/55 AAA/90 X02/C4
Unfortunately the linux kernel does not recognize the chip.
The jedec_probe_chip function fails to recognize the chip, even though it's
present in the jedec_table[], the is the entry that represents the S29AL016D
(the S29AL016D is comptabile with AM29LV160DT):
.mfr_id = MANUFACTURER_AMD,
.dev_id = AM29LV160DT,
.name = "AMD AM29LV160DT",
.uaddr = {
[0] = MTD_UADDR_0x0AAA_0x0555, /* x8 */
[1] = MTD_UADDR_0x0555_0x02AA /* x16 */
},
.DevSize = SIZE_2MiB,
.CmdSet = P_ID_AMD_STD,
.NumEraseRegions= 4,
.regions = {
ERASEINFO(0x10000,31),
ERASEINFO(0x08000,1),
ERASEINFO(0x02000,2),
ERASEINFO(0x04000,1)
}
The above jedec_table entry seems to be correct and it should be the one to
find/match.
The problem when probing if "cfi->interleave=1 and cfi->device_type=2 (x16)" is
that the device is not put into autoselect mode properly.
This is because the unlock addresses are multiplied with the cfi->device_type
(this is done by cfi_build_cmd_addr) and thus the autoselect mode
(for MTD_UADDR_0x0AAA_0x0555, /* x8 */) is entered by writing:
address=0x1554, data=0xaa
address=0x0aaa, data=0x55
address=0x1554, data=0x90
This fails to put the chip into autoselect mode.
Here's the kernel corresponding kernel console output:
reset unlock called aaa 555
Search for id:(0a 00) interleave(1) type(2)
Note that 0a 00 is ordinary data.
Other unlock addresses (2aa 555 and 555 aaa) do get the device in autoselect mode,
but now there are two other problems which make jedec_match fail:
-1- the following code from jedec_match makes matching always fail for any x16
device in x8 mode ?
if ( cfi->mfr != mfr) || cfi->id != id ) {
goto match_done;
}
id is 16 bit (0x22c4), so it won't match 0xc4.
-2- the unlock address is wrong. Here's the corresponding kernel console output:
reset unlock called 555 2aa
Search for id:(01 c4) interleave(1) type(2)
MTD jedec_match(): Check fit 0x00000000 + 0x00200000 = 0x00200000
MTD jedec_match(): check unlock addrs 0x0555 0x02aa
MTD jedec_match(): 0x0aaa 0x0555 did not match 0x0555 0x02aa
reset unlock called 555 aaa
Search for id:(01 c4) interleave(1) type(2)
MTD jedec_match(): Check fit 0x00000000 + 0x00200000 = 0x00200000
MTD jedec_match(): check unlock addrs 0x0555 0x0aaa
MTD jedec_match(): 0x0aaa 0x0555 did not match 0x0555 0x0aaa
It wants to match with unlock address 0x0aaa 0x0555 (because this is the one
listed in the jedec_table[] entry for cfi->device_type=2=x16) and both pair
of unlock addresses (which do get the chip in autoselect mode) do not match.
I'm not sure whether the kernel should recognize the chip as 8 or 16 bit, I
guess 16 bit. Let me anyway discuss the 8 bit case also.
The problem when probing if "cfi->interleave=1 and cfi->device_type=1 (x8)" is
twofold:
-1- device id is not read correctly. After putting the device in "Autoselect Mode"
the device id is read from address 1 (it should be 2). This makes the device id
equal to the manufacture id. Here's the corresponding kernel console output:
reset unlock called aaa 555
Search for id:(01 01) interleave(1) type(1)
-2- even if the device id and manufacturer id would be read correctly the
chip won't be recognized anyway since jedec_match has the following code:
/* bjd: it seems that if we do this, we can end up
* detecting 16bit flashes as an 8bit device, even though
* there aren't.
*/
if (finfo->dev_id > 0xff) {
DEBUG( MTD_DEBUG_LEVEL3, "%s(): ID is not 8bit\n",
__func__);
goto match_done;
Because finfo->devid=AM29LV160DT=0x22C4 -> the ID is not 8 bit.
I'm sure I miss something. Our linux kernel is ancient (2.4.25) but more recent
linux kernel seem to have the same mtd/jedec code in this repect.
I anyone could help me pointing out what is wrong it would be great.
BR,
N. van Bolhuis.
Btw. is the linux mtd mailing list (linux-mtd@lists.infradead.org) still alive ?
I couldn't reach the archives at http://lists.infradead.org/pipermail/linux-mtd/
--
This message has been scanned for viruses and is believed to be clean
^ 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