* Re: TASK_SIZE default 0x80000000 ?
From: Dan Malek @ 2007-10-06 17:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list, Benjamin Herrenschmidt, Paul Mackerras
In-Reply-To: <C2771B73-A555-4119-AC21-1441D4CC2125@freescale.com>
On Oct 6, 2007, at 6:36 AM, Kumar Gala wrote:
> In a discussion with Hollis over beer he raised the question why
> TASK_SIZE is 0x80000000 on ppc32.
Left over from the old days (2.1) of the PReP port when
things were hard coded. We used some of the space
between 0x80000000 and 0xc0000000 for mapping
IO devices in the kernel.
> I was wondering if anyone know why this was still the case? Seems
> like we have a 1Gb whole between TASK_SIZE & KERNELBASE.
I thought all of this was now configurable in the
advanced options. The configuration files should
set the default to remove this gap.
-- Dan
^ permalink raw reply
* TASK_SIZE default 0x80000000 ?
From: Kumar Gala @ 2007-10-06 13:36 UTC (permalink / raw)
To: PowerPC dev list; +Cc: Benjamin Herrenschmidt, Paul Mackerras
In a discussion with Hollis over beer he raised the question why
TASK_SIZE is 0x80000000 on ppc32.
I was wondering if anyone know why this was still the case? Seems
like we have a 1Gb whole between TASK_SIZE & KERNELBASE.
- k
^ permalink raw reply
* [PATCH 00/15] [POWERPC] TQM5200, CM5200 and Motion-PRO support
From: Marian Balakowicz @ 2007-10-06 10:12 UTC (permalink / raw)
To: linuxppc-dev
Hello,
The following series of patches adds arch/powerpc support for three MPC5200 based boards:
TQM5200, CM5200 and Motion-PRO.
Included are also patches with modifications to common 52xx code. New helper
routine mpc52xx_find_and_map_path() is added, and is being used in LED driver
for Motion-PRO. Another patch adds mpc52xx_restart(), mpc52xx_halt()
and mpc52xx_power_off(). This modification has been around for some time now
and relies on Sascha Hauer's patch.
01/15 [POWERPC] TQM5200 DTS
02/15 [POWERPC] TQM5200 defconfig
03/15 [POWERPC] TQM5200 board support
04/15 [POWERPC] cm5200 DTS
05/15 [POWERPC] cm5200 defconfig
06/15 [POWERPC] cm5200 board support
07/15 [POWERPC] Promess motionpro DTS
08/15 [POWERPC] Promess motionpro defconfig
09/15 [POWERPC] Promess motionpro board support
10/15 [POWERPC] Add mpc52xx_find_and_map_path(), refactor utility functions.
11/15 [POWERPC] Motion-PRO: Add LED support.
12/15 [POWERPC] Add mpc52xx_restart(), mpc52xx_halt(), mpc52xx_power_off().
13/15 [POWERPC] Init restart/halt/power_off machine hooks for tqm5200.
14/15 [POWERPC] Init restart/halt/power_off machine hooks for cm5200.
15/15 [POWERPC] Init restart/halt/power_off machine hooks for motionpro.
Comments and review notes are welcome.
Cheers,
Marian Balakowicz
^ permalink raw reply
* [PATCH] Fix non-terminated PCI match table in PowerMac IDE
From: Benjamin Herrenschmidt @ 2007-10-06 8:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: Bartlomiej Zolnierkiewicz, linuxppc-dev list, Heikki Lindholm,
Paul Mackerras
The PCI device table in the powermac IDE driver isn't properly
terminated. Depending on how your kernel is linked and other random
factors, you can end up with this driver matched against any other PCI
device in your system, possibly crashing at boot.
Thanks to Heikki for tracking this down with me, the bug have been there
for some time, though it rarely hurts due to luck. In this case, the
switch from .22 to .23-rc9 is causing it to show up due to differences
in the resulting layout of .data I suppose.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
If that can still make it in .23, that would be great. I'll also get it
in the various -stable releases.
diff --git a/drivers/ide/ppc/pmac.c b/drivers/ide/ppc/pmac.c
index f19eb6d..2fb047b 100644
--- a/drivers/ide/ppc/pmac.c
+++ b/drivers/ide/ppc/pmac.c
@@ -1546,6 +1546,7 @@ static struct pci_device_id pmac_ide_pci_match[] = {
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{ PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_IPID2_ATA,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {},
};
static struct pci_driver pmac_ide_pci_driver = {
^ permalink raw reply related
* Re: [PATCH 5/6] PowerPC 440EPx: Sequoia board support
From: Benjamin Herrenschmidt @ 2007-10-05 22:17 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <47068433.7060803@ru.mvista.com>
On Fri, 2007-10-05 at 22:36 +0400, Valentine Barshak wrote:
> Benjamin Herrenschmidt wrote:
> >> Depends on interpretation. IIRC currently the same die is used for 440EPx and
> >> 440GRx. I could be wrong here though and it is just a bug in the chip. But
> >> anyway we should support this somehow. Could be that I missed this in the
> >> current 440GRx (Rainier) arch/ppc support too. I have to admit, that no
> >> clever solution comes to my mind right away though.
> >
> > We can always come up with some kind of runtime detection, by turning on
> > MSR:FP, issuing an fp instruction and catching the illegal instruction
> > fault if any :-)
> >
> > Ben.
> >
> >
>
> Is it OK to workaround the GRX/EPX having the same PVR issue using
> device tree?
> Say, check the PVR value and if we have 440EPx PVR, but 440GRX node in
> the device tree, fix the cputable entry and omit FPU initialization code.
Fixing the CPU features based on the tree is definitely legit. We do
that on pseries. In fact, with paulus latest patch, the cputable is
__initdata and the cur CPU features is a -copy- which makes it even more
legitimate to whack it.
Ben.
^ permalink raw reply
* Re: [PATCH respin 0/7] MPC8568E-MDS related patches
From: Kumar Gala @ 2007-10-05 22:09 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071005174015.GA11016@localhost.localdomain>
On Oct 5, 2007, at 12:40 PM, Anton Vorontsov wrote:
> Hello Kumar,
>
> This is respin of MPC8568E-MDS patches, on top of master branch
> as of today.
>
> If there are no objections against SPI patch, please Ack it, thus
> David could pick it up.
I've applied patches 1-5 however I'm not able to get UCC enet working
on my board. Is there something special that has to be done? (I've
got the card standalone, no MDS backplane).
I'm using the 1.3.0-rc2 u-boot w/o any modifications.
Also, I tried a PCIe e1000 card w/the .dts that's in my tree and that
works w/o any issue.
- 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 21:03 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071005173054.GA4295@loki.buserror.net>
On Fri, Oct 05, 2007 at 12:30:54PM -0500, Scott Wood wrote:
> On Thu, Oct 04, 2007 at 06:58:49PM -0700, Mark A. Greer wrote:
> > 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.
>
> Why?
Why? Because its only safe to download a zImage to certain "safe" locations.
Where those "safe" locations are vary by firmware, firmware version, and
zImage size. This is the issue we're discussing.
I've already explained _why_ the link address matters WRT where its downloaded.
> The zImage is relocatable. It doesn't matter where it's linked.
We know...and a zImage running at an address it wasn't linked at is
not the issue.
> > 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.
>
> How is this a u-boot specific solution?
Because the hoops being jumped through in the patch(es) are to make
u-boot happy and no other firmware.
> > 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.
>
> That's not the more general problem; it's the same problem with a different
> file format.
True, I misspoke. I'll restate it this way:
The more general problem is that some firmwares will only download to
the address the zImage is linked at. So, we need to control what that
link address is."
> > 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'd much rather it be automatic than require the user to guess an
> appropriate value (and be aware in the first place that it needs to be set).
Sure, automatic is nice; conjuring up the magic to make it work in all
situations isn't.
Having the link address--and therefore the download address on some
systems--mysteriously and uncontrollably jump around based on the zImage
size is asking for trouble.
Mark
^ permalink raw reply
* Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
From: Kumar Gala @ 2007-10-05 20:58 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071005180553.GA32405@localhost.localdomain>
On Oct 5, 2007, at 1:05 PM, Anton Vorontsov wrote:
> On Fri, Oct 05, 2007 at 09:56:46PM +0400, Sergei Shtylyov wrote:
>> Hello.
>>
>> Anton Vorontsov wrote:
>>
>>> Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
>>> PCI/PCIe nodes, but actually it broke them even harder. ;-)
>>
>> Of course. But shouldn't those be the subnoses of the "soc"
>> type node?
>
> Nope. PCI's ranges = <>; isn't in the SOC address space.
>
> Valentine Barshak posted a patch titled "[RFC] [PATCH] PowerPC: Add
> 64-bit
> phys addr support to 32-bit pci" that started using
> of_translate_address()
> for ranges, and of_translate_address() will not work if PCI placed
> in the
> SOC node. Not sure if that patch applied or not, though.
I'm confused, what's the actual issue with PCI that this patch
addresses?
- k
^ permalink raw reply
* Re: Device tree and external RTC
From: Bruce_Leonard @ 2007-10-05 19:37 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Peter Korsgaard, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.60.0710051242050.5434@poirot.grange>
Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote on 10/05/2007 03:45:27
AM:
> 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, that's what I was starting to think, that I was going to
have to get something newer. Thanks to both you and Peter for the help. I
really appreciate it.
Bruce
^ permalink raw reply
* Re: [PATCH 5/6] PowerPC 440EPx: Sequoia board support
From: Valentine Barshak @ 2007-10-05 18:36 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <1186144536.5981.5.camel@gruick>
Benjamin Herrenschmidt wrote:
>> Depends on interpretation. IIRC currently the same die is used for 440EPx and
>> 440GRx. I could be wrong here though and it is just a bug in the chip. But
>> anyway we should support this somehow. Could be that I missed this in the
>> current 440GRx (Rainier) arch/ppc support too. I have to admit, that no
>> clever solution comes to my mind right away though.
>
> We can always come up with some kind of runtime detection, by turning on
> MSR:FP, issuing an fp instruction and catching the illegal instruction
> fault if any :-)
>
> Ben.
>
>
Is it OK to workaround the GRX/EPX having the same PVR issue using
device tree?
Say, check the PVR value and if we have 440EPx PVR, but 440GRX node in
the device tree, fix the cputable entry and omit FPU initialization code.
Thanks,
Valentine.
^ permalink raw reply
* Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
From: Anton Vorontsov @ 2007-10-05 18:05 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev
In-Reply-To: <47067ADE.9060306@ru.mvista.com>
On Fri, Oct 05, 2007 at 09:56:46PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> Anton Vorontsov wrote:
>
>> Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
>> PCI/PCIe nodes, but actually it broke them even harder. ;-)
>
> Of course. But shouldn't those be the subnoses of the "soc" type node?
Nope. PCI's ranges = <>; isn't in the SOC address space.
Valentine Barshak posted a patch titled "[RFC] [PATCH] PowerPC: Add 64-bit
phys addr support to 32-bit pci" that started using of_translate_address()
for ranges, and of_translate_address() will not work if PCI placed in the
SOC node. Not sure if that patch applied or not, though.
Good luck,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
From: Scott Wood @ 2007-10-05 18:01 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev
In-Reply-To: <47067ADE.9060306@ru.mvista.com>
On Fri, Oct 05, 2007 at 09:56:46PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> Anton Vorontsov wrote:
>
> > Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
> > PCI/PCIe nodes, but actually it broke them even harder. ;-)
>
> Of course. But shouldn't those be the subnoses of the "soc" type node?
No -- the soc node is for immr/ccsr only, and while the PCI control
registers are there, the ranges are not. There was a lengthy discussion on
IRC about this a couple weeks ago. It'd be cleaner to split the control
node from the bus node, and connect them with phandles, but some people
didn't like that, and this is what we compromised on.
-Scott
^ permalink raw reply
* Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
From: Sergei Shtylyov @ 2007-10-05 17:56 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071005174642.GB32145@localhost.localdomain>
Hello.
Anton Vorontsov wrote:
> Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
> PCI/PCIe nodes, but actually it broke them even harder. ;-)
Of course. But shouldn't those be the subnoses of the "soc" type node?
I don't suppose the PCI controllers could hang off the root node... :-/
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
> index b4aa5e7..5439437 100644
> --- a/arch/powerpc/boot/dts/mpc8568mds.dts
> +++ b/arch/powerpc/boot/dts/mpc8568mds.dts
> @@ -410,7 +410,7 @@
>
> };
>
> - pci@8000 {
> + pci@e0008000 {
> interrupt-map-mask = <f800 0 0 7>;
> interrupt-map = <
> /* IDSEL 0x12 AD18 */
> @@ -434,13 +434,13 @@
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> - reg = <8000 1000>;
> + reg = <e0008000 1000>;
> compatible = "fsl,mpc8540-pci";
> device_type = "pci";
> };
>
> /* PCI Express */
> - pcie@a000 {
> + pcie@e000a000 {
> interrupt-map-mask = <f800 0 0 7>;
> interrupt-map = <
>
> @@ -459,7 +459,7 @@
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> - reg = <a000 1000>;
> + reg = <e000a000 1000>;
> compatible = "fsl,mpc8548-pcie";
> device_type = "pci";
> pcie@0 {
WBR, Sergei
^ permalink raw reply
* [PATCH 1/7] [POWERPC] mpc85xx_mds: select QUICC_ENGINE
From: Anton Vorontsov @ 2007-10-05 17:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071005174015.GA11016@localhost.localdomain>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/85xx/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index b8476b2..cf815b2 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -25,7 +25,7 @@ config MPC85xx_CDS
config MPC85xx_MDS
bool "Freescale MPC85xx MDS"
select DEFAULT_UIMAGE
-# select QUICC_ENGINE
+ select QUICC_ENGINE
help
This option enables support for the MPC85xx MDS board
--
1.5.0.6
^ permalink raw reply related
* [PATCH 2/7] [POWERPC] QEIC: Implement pluggable handlers, fix MPIC cascading
From: Anton Vorontsov @ 2007-10-05 17:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071005174015.GA11016@localhost.localdomain>
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 (will waste text size because of
never used handlers, so this option abolished).
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>
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 b8d8c91..972fa85 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 4da0698..fbca336 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 0b18a75..0f3855c 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 00f4c3a..57e840a 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -180,7 +180,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 */
--
1.5.0.6
^ permalink raw reply related
* [PATCH 3/7] [POWERPC] QE pario: support for MPC85xx layout
From: Anton Vorontsov @ 2007-10-05 17:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071005174015.GA11016@localhost.localdomain>
8 bytes padding required to match MPC85xx registers layout.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Reviewed-by: Kim Phillips <kim.phillips@freescale.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 a114cb0..e53ea4d 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_PPC_85xx
+ u8 pad[8];
+#endif
};
static struct port_regs *par_io = NULL;
--
1.5.0.6
^ permalink raw reply related
* [PATCH 4/7] [POWERPC] mpc8568mds: update dts to be able to use UCCs
From: Anton Vorontsov @ 2007-10-05 17:46 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071005174015.GA11016@localhost.localdomain>
1. UCC1's RX_DV pin is 16, not 15;
2. UCC1's phy is at 0x7, not 0x1. Schematics says 0x7, and recent
u-boot also using 0x7.
3. Use gianfar's (eTSEC) mdio bus. This is hardware default setup.
4. tx-clock should be CLK16 (GE125, PB31);
5. phy-connection-type is RGMII-ID;
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8568mds.dts | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index 6ac134a..b4aa5e7 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -104,10 +104,10 @@
device_type = "mdio";
compatible = "gianfar";
reg = <24520 20>;
- phy0: ethernet-phy@0 {
+ phy0: ethernet-phy@7 {
interrupt-parent = <&mpic>;
interrupts = <1 1>;
- reg = <0>;
+ reg = <7>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
@@ -242,7 +242,7 @@
4 1a 2 0 2 0 /* RxD7 */
4 0b 1 0 2 0 /* TX_EN */
4 18 1 0 2 0 /* TX_ER */
- 4 0f 2 0 2 0 /* RX_DV */
+ 4 10 2 0 2 0 /* RX_DV */
4 1e 2 0 2 0 /* RX_ER */
4 11 2 0 2 0 /* RX_CLK */
4 13 1 0 2 0 /* GTX_CLK */
@@ -334,10 +334,10 @@
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = <0>;
- tx-clock = <19>;
- phy-handle = <&qe_phy0>;
- phy-connection-type = "gmii";
+ tx-clock = <20>;
pio-handle = <&pio1>;
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
};
ucc@3000 {
@@ -356,10 +356,10 @@
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = <0>;
- tx-clock = <14>;
- phy-handle = <&qe_phy1>;
- phy-connection-type = "gmii";
+ tx-clock = <20>;
pio-handle = <&pio2>;
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
};
mdio@2120 {
@@ -371,10 +371,10 @@
/* These are the same PHYs as on
* gianfar's MDIO bus */
- qe_phy0: ethernet-phy@00 {
+ qe_phy0: ethernet-phy@07 {
interrupt-parent = <&mpic>;
interrupts = <1 1>;
- reg = <0>;
+ reg = <7>;
device_type = "ethernet-phy";
};
qe_phy1: ethernet-phy@01 {
--
1.5.0.6
^ permalink raw reply related
* [PATCH 5/7] [POWERPC] mpc85xx_mds: reset UCC ethernet properly
From: Anton Vorontsov @ 2007-10-05 17:46 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071005174015.GA11016@localhost.localdomain>
Apart from that the current code doesn't compile it's also
meaningless with regard to the MPC8568E-MDS' BCSR.
This patch used to reset UCCs properly.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 28 ++++++++++++++++------------
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 57e840a..6913e99 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -113,18 +113,22 @@ static void __init mpc85xx_mds_setup_arch(void)
}
if (bcsr_regs) {
- u8 bcsr_phy;
-
- /* Reset the Ethernet PHY */
- bcsr_phy = in_be8(&bcsr_regs[9]);
- bcsr_phy &= ~0x20;
- out_be8(&bcsr_regs[9], bcsr_phy);
-
- udelay(1000);
-
- bcsr_phy = in_be8(&bcsr_regs[9]);
- bcsr_phy |= 0x20;
- out_be8(&bcsr_regs[9], bcsr_phy);
+#define BCSR_UCC1_GETH_EN (0x1 << 7)
+#define BCSR_UCC2_GETH_EN (0x1 << 7)
+#define BCSR_UCC1_MODE_MSK (0x3 << 4)
+#define BCSR_UCC2_MODE_MSK (0x3 << 0)
+
+ /* Turn off UCC1 & UCC2 */
+ clrbits8(&bcsr_regs[8], BCSR_UCC1_GETH_EN);
+ clrbits8(&bcsr_regs[9], BCSR_UCC2_GETH_EN);
+
+ /* Mode is RGMII, all bits clear */
+ clrbits8(&bcsr_regs[11], BCSR_UCC1_MODE_MSK |
+ BCSR_UCC2_MODE_MSK);
+
+ /* Turn UCC1 & UCC2 on */
+ setbits8(&bcsr_regs[8], BCSR_UCC1_GETH_EN);
+ setbits8(&bcsr_regs[9], BCSR_UCC2_GETH_EN);
iounmap(bcsr_regs);
}
--
1.5.0.6
^ permalink raw reply related
* [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
From: Anton Vorontsov @ 2007-10-05 17:46 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071005174015.GA11016@localhost.localdomain>
Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
PCI/PCIe nodes, but actually it broke them even harder. ;-)
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8568mds.dts | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index b4aa5e7..5439437 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -410,7 +410,7 @@
};
- pci@8000 {
+ pci@e0008000 {
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x12 AD18 */
@@ -434,13 +434,13 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <8000 1000>;
+ reg = <e0008000 1000>;
compatible = "fsl,mpc8540-pci";
device_type = "pci";
};
/* PCI Express */
- pcie@a000 {
+ pcie@e000a000 {
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
@@ -459,7 +459,7 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <a000 1000>;
+ reg = <e000a000 1000>;
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
pcie@0 {
--
1.5.0.6
^ permalink raw reply related
* [PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on any processors with QUICC Engine
From: Anton Vorontsov @ 2007-10-05 17:46 UTC (permalink / raw)
To: linuxppc-dev; +Cc: spi-devel-general
In-Reply-To: <20071005174015.GA11016@localhost.localdomain>
Currently, all QE SPI controllers are almost the same comparing to
MPC83xx's, thus let's use that driver for them.
Tested to work on MPC85xx in loopback mode.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
This is respin. Hope this time it will get ack from the
PowerPC team.
drivers/spi/Kconfig | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index b915711..a77ede5 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -124,16 +124,17 @@ config SPI_MPC52xx_PSC
Controller in master SPI mode.
config SPI_MPC83xx
- tristate "Freescale MPC83xx SPI controller"
- depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
+ tristate "Freescale MPC83xx/QUICC Engine SPI controller"
+ depends on SPI_MASTER && (PPC_83xx || QUICC_ENGINE) && EXPERIMENTAL
select SPI_BITBANG
help
- This enables using the Freescale MPC83xx SPI controller in master
- mode.
+ This enables using the Freescale MPC83xx and QUICC Engine SPI
+ controllers in master mode.
Note, this driver uniquely supports the SPI controller on the MPC83xx
- family of PowerPC processors. The MPC83xx uses a simple set of shift
- registers for data (opposed to the CPM based descriptor model).
+ family of PowerPC processors, plus processors with QUICC Engine
+ technology. This driver uses a simple set of shift registers for data
+ (opposed to the CPM based descriptor model).
config SPI_OMAP_UWIRE
tristate "OMAP1 MicroWire"
--
1.5.0.6
^ permalink raw reply related
* [PATCH respin 0/7] MPC8568E-MDS related patches
From: Anton Vorontsov @ 2007-10-05 17:40 UTC (permalink / raw)
To: linuxppc-dev
Hello Kumar,
This is respin of MPC8568E-MDS patches, on top of master branch
as of today.
If there are no objections against SPI patch, please Ack it, thus
David could pick it up.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: Scott Wood @ 2007-10-05 17:30 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:
> 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.
Why? The zImage is relocatable. It doesn't matter where it's linked.
> 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.
How is this 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.
That's not the more general problem; it's the same problem with a different
file format.
> 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'd much rather it be automatic than require the user to guess an
appropriate value (and be aware in the first place that it needs to be set).
-Scott
^ permalink raw reply
* Re: Patch: Fix regression. Make hot unlplug of CPU0 work again.
From: Milton Miller @ 2007-10-05 17:16 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20071005070519.GQ9814@bakeyournoodle.com>
On Fri, Oct 05, 2007 at 05:05:21PM, 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.
Reviewing the first patch, xics_set_affinity no longer looks at the
cpu_mask arg, instead get_irq_server reads it from the irq descriptor.
Signed-off-by: Milton Miller <miltonm@bga.com>
---
On top of tonys patch (13926)
I don't have a system to test hotplug, so this is only compile tested.
A more complete fix might be to pass the cpu_mask struct to get_irq_server,
but kernel/irq/manage.c currently sets the descriptor first.
Index: kernel/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- kernel.orig/arch/powerpc/platforms/pseries/xics.c 2007-10-05 11:37:01.000000000 -0500
+++ kernel/arch/powerpc/platforms/pseries/xics.c 2007-10-05 11:37:16.000000000 -0500
@@ -890,8 +890,8 @@ void xics_migrate_irqs_away(void)
virq, cpu);
/* Reset affinity to all cpus */
- desc->chip->set_affinity(virq, CPU_MASK_ALL);
irq_desc[virq].affinity = CPU_MASK_ALL;
+ desc->chip->set_affinity(virq, CPU_MASK_ALL);
unlock:
spin_unlock_irqrestore(&desc->lock, flags);
}
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Linas Vepstas @ 2007-10-05 16:03 UTC (permalink / raw)
To: Nish Aravamudan; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <29495f1d0710041701g4ed73441ie583058c78f95857@mail.gmail.com>
On Thu, Oct 04, 2007 at 05:01:47PM -0700, Nish Aravamudan wrote:
> 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>
For the reasons explained, I'd really like to nack Tony's patch.
--linas
^ 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