* [PATCH 3/3 v3] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Roy Zang @ 2010-09-16 6:41 UTC (permalink / raw)
To: linux-mtd; +Cc: B07421, dedekind1, B25806, linuxppc-dev, akpm, dwmw2, B11780
In-Reply-To: <1284619284-23614-2-git-send-email-tie-fei.zang@freescale.com>
From: Lan Chunhe-B25806 <b25806@freescale.com>
When system uses 36bit physical address, res.start is 36bit
physical address. But the function of in_be32 returns 32bit
physical address. Then both of them compared each other is
wrong. So by converting the address of res.start into
the right format fixes this issue.
Signed-off-by: Lan Chunhe-B25806 <b25806@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
arch/powerpc/include/asm/fsl_lbc.h | 1 +
arch/powerpc/sysdev/fsl_lbc.c | 23 ++++++++++++++++++++++-
drivers/mtd/nand/fsl_elbc_nand.c | 2 +-
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_lbc.h b/arch/powerpc/include/asm/fsl_lbc.h
index db94698..5638b1e 100644
--- a/arch/powerpc/include/asm/fsl_lbc.h
+++ b/arch/powerpc/include/asm/fsl_lbc.h
@@ -246,6 +246,7 @@ struct fsl_upm {
int width;
};
+extern unsigned int fsl_lbc_addr(phys_addr_t addr_base);
extern int fsl_lbc_find(phys_addr_t addr_base);
extern int fsl_upm_find(phys_addr_t addr_base, struct fsl_upm *upm);
diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
index edd6d95..8a835ef 100644
--- a/arch/powerpc/sysdev/fsl_lbc.c
+++ b/arch/powerpc/sysdev/fsl_lbc.c
@@ -34,6 +34,27 @@ struct fsl_lbc_ctrl *fsl_lbc_ctrl_dev;
EXPORT_SYMBOL(fsl_lbc_ctrl_dev);
/**
+ * fsl_lbc_addr - convert the base address
+ * @addr_base: base address of the memory bank
+ *
+ * This function converts a base address of lbc into the right format for the
+ * BR register. If the SOC has eLBC then it returns 32bit physical address
+ * else it convers a 34bit local bus physical address to correct format of
+ * 32bit address for BR register (Example: MPC8641).
+ */
+u32 fsl_lbc_addr(phys_addr_t addr_base)
+{
+ struct device_node *np = fsl_lbc_ctrl_dev->dev->of_node;
+ u32 addr = addr_base & 0xffff8000;
+
+ if (of_device_is_compatible(np, "fsl,elbc"))
+ return addr;
+
+ return addr | ((addr_base & 0x300000000ull) >> 19);
+}
+EXPORT_SYMBOL(fsl_lbc_addr);
+
+/**
* fsl_lbc_find - find Localbus bank
* @addr_base: base address of the memory bank
*
@@ -55,7 +76,7 @@ int fsl_lbc_find(phys_addr_t addr_base)
__be32 br = in_be32(&lbc->bank[i].br);
__be32 or = in_be32(&lbc->bank[i].or);
- if (br & BR_V && (br & or & BR_BA) == addr_base)
+ if (br & BR_V && (br & or & BR_BA) == fsl_lbc_addr(addr_base))
return i;
}
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 91c5c05..85858e3 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -865,7 +865,7 @@ static int __devinit fsl_elbc_nand_probe(struct platform_device *dev)
(in_be32(&lbc->bank[bank].br) & BR_MSEL) == BR_MS_FCM &&
(in_be32(&lbc->bank[bank].br) &
in_be32(&lbc->bank[bank].or) & BR_BA)
- == res.start)
+ == fsl_lbc_addr(res.start))
break;
if (bank >= MAX_BANKS) {
--
1.5.6.5
^ permalink raw reply related
* [PATCH] spi_mpc8xxx: fix writing to adress 0
From: christophe leroy @ 2010-09-16 7:04 UTC (permalink / raw)
To: David Brownell, Grant Likely, spi-devel-general, linux-kernel,
linuxppc-dev
This patch applies to 2.6.34.7 (already included in 2.6.35.4)
It fixes an issue when sending only or receiving only (mspi->tx-dma was reset as when no tx_buf is defined, tx_dma is 0)
Signed-off-by: christophe leroy <christophe.leroy@c-s.fr>
diff -urN a/drivers/spi/spi_mpc8xxx.c b/drivers/spi/spi_mpc8xxx.c
--- a/drivers/spi/spi_mpc8xxx.c 2010-09-08 16:42:30.000000000 +0200
+++ b/drivers/spi/spi_mpc8xxx.c 2010-09-08 16:43:50.000000000 +0200
@@ -438,7 +438,7 @@
dev_err(dev, "unable to map tx dma\n");
return -ENOMEM;
}
- } else {
+ } else if (t->tx_buf) {
mspi->tx_dma = t->tx_dma;
}
@@ -449,7 +449,7 @@
dev_err(dev, "unable to map rx dma\n");
goto err_rx_dma;
}
- } else {
+ } else if (t->rx_buf) {
mspi->rx_dma = t->rx_dma;
}
^ permalink raw reply
* [PATCH] spi_mpc8xxx: issue with using definition of pram in Device Tree
From: christophe leroy @ 2010-09-16 7:05 UTC (permalink / raw)
To: David Brownell, Grant Likely, spi-devel-general, linux-kernel,
linuxppc-dev
This patch applies to 2.6.34.7 and 2.6.35.4
It fixes an issue during the probe for CPM1 with definition of parameter ram from DTS
Signed-off-by: christophe leroy <christophe.leroy@c-s.fr>
diff -urN b/drivers/spi/spi_mpc8xxx.c c/drivers/spi/spi_mpc8xxx.c
--- b/drivers/spi/spi_mpc8xxx.c 2010-09-08 16:43:50.000000000 +0200
+++ c/drivers/spi/spi_mpc8xxx.c 2010-09-08 16:44:03.000000000 +0200
@@ -822,7 +822,7 @@
if (!iprop || size != sizeof(*iprop) * 4)
return -ENOMEM;
- spi_base_ofs = cpm_muram_alloc_fixed(iprop[2], 2);
+ spi_base_ofs = iprop[2];
if (IS_ERR_VALUE(spi_base_ofs))
return -ENOMEM;
@@ -844,7 +844,6 @@
return spi_base_ofs;
}
- cpm_muram_free(spi_base_ofs);
return pram_ofs;
}
^ permalink raw reply
* [PATCH] spi_mpc8xxx: fix buffer overrun when sending only/receiving only more than PAGE_SIZE bytes
From: christophe leroy @ 2010-09-16 7:05 UTC (permalink / raw)
To: David Brownell, Grant Likely, spi-devel-general, linux-kernel,
linuxppc-dev
This patch applies to 2.6.34.7 and 2.6.35.4
It fixes an issue when sending only or receiving only more than PAGE_SIZE bytes
Signed-off-by: christophe leroy <christophe.leroy@c-s.fr>
diff -urN c/drivers/spi/spi_mpc8xxx.c d/drivers/spi/spi_mpc8xxx.c
--- c/drivers/spi/spi_mpc8xxx.c 2010-09-08 16:44:03.000000000 +0200
+++ d/drivers/spi/spi_mpc8xxx.c 2010-09-08 16:44:14.000000000 +0200
@@ -393,11 +393,17 @@
xfer_ofs = mspi->xfer_in_progress->len - mspi->count;
- out_be32(&rx_bd->cbd_bufaddr, mspi->rx_dma + xfer_ofs);
+ if (mspi->rx_dma == mspi->dma_dummy_rx)
+ out_be32(&rx_bd->cbd_bufaddr, mspi->rx_dma);
+ else
+ out_be32(&rx_bd->cbd_bufaddr, mspi->rx_dma + xfer_ofs);
out_be16(&rx_bd->cbd_datlen, 0);
out_be16(&rx_bd->cbd_sc, BD_SC_EMPTY | BD_SC_INTRPT | BD_SC_WRAP);
- out_be32(&tx_bd->cbd_bufaddr, mspi->tx_dma + xfer_ofs);
+ if (mspi->tx_dma == mspi->dma_dummy_tx)
+ out_be32(&tx_bd->cbd_bufaddr, mspi->tx_dma);
+ else
+ out_be32(&tx_bd->cbd_bufaddr, mspi->tx_dma + xfer_ofs);
out_be16(&tx_bd->cbd_datlen, xfer_len);
out_be16(&tx_bd->cbd_sc, BD_SC_READY | BD_SC_INTRPT | BD_SC_WRAP |
BD_SC_LAST);
^ permalink raw reply
* Re: Generating elf kernel ?
From: Guillaume Dargaud @ 2010-09-16 7:25 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4C9188DC.2040300@windriver.com>
> >> Please use simpleImage.<your target dts name>.elf.
> >
> > Great, that seems to be it...
> > Except that nothing happens when I jump to 0x40000, no message from the
>
> 0x40000? I recalled the entry point should be 0x400000 for
> simepleImage.*.elf. So you have to change this on the file,
> arch/powerpc/boot/wrapper.
Correct, I skipped a zero, the address is indeed 0x400000
> And also you should confirm if the upstream kernel support your board.
Our board is a custom derivative from a ML405.
My previous project uses ARCH=PPC and has been working fine for 2 years.
I'm currently trying to go to ARCH=PowerPC and understand dts files in order to
boot my first kernel.
I assume I shouldn't have to change anything in my bootloader.
After I jump to the kernel address, I don't even get the usual:
loaded at: 00400000 004F559C
board data at: 004F3520 004F359C
relocated to: 0040505C 004050D8
zimage at: 00405E48 004F211C
avail ram: 004F6000 08000000
Linux/PPC load: console=ttyUL0,115200 rw root=/dev/nfs ip=bootp
Uncompressing Linux...done.
Now booting the kernel
Something wrong with my serial console ?
> Additionally let's assume your bootloader create the map between the
> virtual address and the physical address as 1:1. If so you want to execute
> from 0x40000. But the actual PC address should be the loader address +
> offset. You can get this by readelf. Here if your loader address is zero,
> the offset will be pc address, not 0x40000. You can dump your memory to
> check this.
The bootloader has no concept of virtual address, right ?
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* Re: [PATCH 1/3 v3] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Anton Vorontsov @ 2010-09-16 7:27 UTC (permalink / raw)
To: Roy Zang
Cc: B07421, dedekind1, B25806, linuxppc-dev, linux-mtd, akpm, dwmw2,
B11780
In-Reply-To: <1284619284-23614-1-git-send-email-tie-fei.zang@freescale.com>
On Thu, Sep 16, 2010 at 02:41:22PM +0800, Roy Zang wrote:
[...]
> +static const struct platform_device_id fsl_lbc_match[] = {
> + { "fsl,elbc", },
> + { "fsl,pq3-localbus", },
> + { "fsl,pq2-localbus", },
> + { "fsl,pq2pro-localbus", },
> + {},
> +};
> +
> +static struct platform_driver fsl_lbc_ctrl_driver = {
> + .driver = {
> + .name = "fsl-lbc",
> + },
> + .probe = fsl_lbc_ctrl_probe,
> + .id_table = fsl_lbc_match,
> +};
No, it won't work that way (at least not w/o a device constructor
somewhere in fsl_soc.c). Instead, you should write something like
static const struct of_device_id fsl_lbc_match[] = {
...
};
static struct platform_driver fsl_lbc_ctrl_driver = {
.driver = {
.name = "fsl-lbc",
.of_match_table = fsl_lbc_match;
}
...
};
(Note that platform_driver.driver has of_match_table nowadays --
that's what makes it possible to seamlessly transit from
of_platform_driver to platform_driver.)
The same applies for the second patch as well.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: cuImage and multi image?
From: tiejun.chen @ 2010-09-16 7:30 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev, uboot
In-Reply-To: <AANLkTinhvh+G1Q8yU0y5bMDVi5Sc=pYqSfAbXCeuHvBH@mail.gmail.com>
Shawn Jin wrote:
> Hi,
>
> I have a cuImage kernel in order to support legacy u-boot and a
> ramdisk image. Kernel boots fine if these two images are separate and
> "bootm $kernel $ramdisk" is used. But I can not make it to work using
> a single multi image that contains the kernel and ramdisk images. Is
> it even technically possible to boot a multi-image with cuboot
> wrapper?
Try the following steps:
------
1. cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
2. make cuImage.initrd.<your target>
You can get one Image, cuImage.initrd.<your target>, including kernel and ramdisk.
Cheers
Tiejun
>
> On the cuImage kernel I have load address set to 0x400000 and the
> entry address set to 0x400554 due to the cuboot wrapper. But to make a
> multi image, both the load and the entry addresses should be set to
> zero. And u-boot (1.1.2) bootm takes the entry address of the multi
> image (i.e. 0x0) as the kernel entry address. 0x0 is certainly not the
> entry address for a cuImage kernel.
>
> Is there a possible workaround other than using two separate images?
>
> Thanks,
> -Shawn.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH 3/3 v3] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Anton Vorontsov @ 2010-09-16 7:31 UTC (permalink / raw)
To: Roy Zang
Cc: B07421, dedekind1, B25806, linuxppc-dev, linux-mtd, akpm, dwmw2,
B11780
In-Reply-To: <1284619284-23614-3-git-send-email-tie-fei.zang@freescale.com>
On Thu, Sep 16, 2010 at 02:41:24PM +0800, Roy Zang wrote:
> From: Lan Chunhe-B25806 <b25806@freescale.com>
>
> When system uses 36bit physical address, res.start is 36bit
> physical address. But the function of in_be32 returns 32bit
> physical address. Then both of them compared each other is
> wrong. So by converting the address of res.start into
> the right format fixes this issue.
>
> Signed-off-by: Lan Chunhe-B25806 <b25806@freescale.com>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
> arch/powerpc/include/asm/fsl_lbc.h | 1 +
> arch/powerpc/sysdev/fsl_lbc.c | 23 ++++++++++++++++++++++-
> drivers/mtd/nand/fsl_elbc_nand.c | 2 +-
> 3 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/fsl_lbc.h b/arch/powerpc/include/asm/fsl_lbc.h
> index db94698..5638b1e 100644
> --- a/arch/powerpc/include/asm/fsl_lbc.h
> +++ b/arch/powerpc/include/asm/fsl_lbc.h
> @@ -246,6 +246,7 @@ struct fsl_upm {
> int width;
> };
>
> +extern unsigned int fsl_lbc_addr(phys_addr_t addr_base);
u32 here.
Other than that, the patch looks good.
Reviewed-by: Anton Vorontsov <cbouatmailru@gmail.com>
Thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* RE: [PATCH 3/3 v3] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Zang Roy-R61911 @ 2010-09-16 7:36 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <20100916073135.GA5431@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIFNlcHRl
bWJlciAxNiwgMjAxMCAxNTozMiBQTQ0KPiBUbzogWmFuZyBSb3ktUjYxOTExDQo+IENjOiBsaW51
eC1tdGRAbGlzdHMuaW5mcmFkZWFkLm9yZzsgZHdtdzJAaW5mcmFkZWFkLm9yZzsgZGVkZWtpbmQx
QGdtYWlsLmNvbTsNCj4gYWtwbUBsaW51eC1mb3VuZGF0aW9uLm9yZzsgTGFuIENodW5oZS1CMjU4
MDY7IFdvb2QgU2NvdHQtQjA3NDIxOyBHYWxhIEt1bWFyLQ0KPiBCMTE3ODA7IGxpbnV4cHBjLWRl
dkBvemxhYnMub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMy8zIHYzXSBQNDA4MC9tdGQ6IEZp
eCB0aGUgZnJlZXNjYWxlIGxiYyBpc3N1ZSB3aXRoIDM2Yml0DQo+IG1vZGUNCj4gDQo+IE9uIFRo
dSwgU2VwIDE2LCAyMDEwIGF0IDAyOjQxOjI0UE0gKzA4MDAsIFJveSBaYW5nIHdyb3RlOg0KPiA+
IEZyb206IExhbiBDaHVuaGUtQjI1ODA2IDxiMjU4MDZAZnJlZXNjYWxlLmNvbT4NCj4gPg0KPiA+
IFdoZW4gc3lzdGVtIHVzZXMgMzZiaXQgcGh5c2ljYWwgYWRkcmVzcywgcmVzLnN0YXJ0IGlzIDM2
Yml0DQo+ID4gcGh5c2ljYWwgYWRkcmVzcy4gQnV0IHRoZSBmdW5jdGlvbiBvZiBpbl9iZTMyIHJl
dHVybnMgMzJiaXQNCj4gPiBwaHlzaWNhbCBhZGRyZXNzLiBUaGVuIGJvdGggb2YgdGhlbSBjb21w
YXJlZCBlYWNoIG90aGVyIGlzDQo+ID4gd3JvbmcuIFNvIGJ5IGNvbnZlcnRpbmcgdGhlIGFkZHJl
c3Mgb2YgcmVzLnN0YXJ0IGludG8NCj4gPiB0aGUgcmlnaHQgZm9ybWF0IGZpeGVzIHRoaXMgaXNz
dWUuDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBMYW4gQ2h1bmhlLUIyNTgwNiA8YjI1ODA2QGZy
ZWVzY2FsZS5jb20+DQo+ID4gU2lnbmVkLW9mZi1ieTogUm95IFphbmcgPHRpZS1mZWkuemFuZ0Bm
cmVlc2NhbGUuY29tPg0KPiA+IC0tLQ0KPiA+ICBhcmNoL3Bvd2VycGMvaW5jbHVkZS9hc20vZnNs
X2xiYy5oIHwgICAgMSArDQo+ID4gIGFyY2gvcG93ZXJwYy9zeXNkZXYvZnNsX2xiYy5jICAgICAg
fCAgIDIzICsrKysrKysrKysrKysrKysrKysrKystDQo+ID4gIGRyaXZlcnMvbXRkL25hbmQvZnNs
X2VsYmNfbmFuZC5jICAgfCAgICAyICstDQo+ID4gIDMgZmlsZXMgY2hhbmdlZCwgMjQgaW5zZXJ0
aW9ucygrKSwgMiBkZWxldGlvbnMoLSkNCj4gPg0KPiA+IGRpZmYgLS1naXQgYS9hcmNoL3Bvd2Vy
cGMvaW5jbHVkZS9hc20vZnNsX2xiYy5oDQo+IGIvYXJjaC9wb3dlcnBjL2luY2x1ZGUvYXNtL2Zz
bF9sYmMuaA0KPiA+IGluZGV4IGRiOTQ2OTguLjU2MzhiMWUgMTAwNjQ0DQo+ID4gLS0tIGEvYXJj
aC9wb3dlcnBjL2luY2x1ZGUvYXNtL2ZzbF9sYmMuaA0KPiA+ICsrKyBiL2FyY2gvcG93ZXJwYy9p
bmNsdWRlL2FzbS9mc2xfbGJjLmgNCj4gPiBAQCAtMjQ2LDYgKzI0Niw3IEBAIHN0cnVjdCBmc2xf
dXBtIHsNCj4gPiAgCWludCB3aWR0aDsNCj4gPiAgfTsNCj4gPg0KPiA+ICtleHRlcm4gdW5zaWdu
ZWQgaW50IGZzbF9sYmNfYWRkcihwaHlzX2FkZHJfdCBhZGRyX2Jhc2UpOw0KPiANCj4gdTMyIGhl
cmUuDQo+IA0KPiBPdGhlciB0aGFuIHRoYXQsIHRoZSBwYXRjaCBsb29rcyBnb29kLg0KPiANCj4g
UmV2aWV3ZWQtYnk6IEFudG9uIFZvcm9udHNvdiA8Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbT4NCkkg
d2lsbCBjb3JyZWN0IHRoaXMgdG9nZXRoZXIgd2l0aCBwcmV2aW91cyBwYXRjaGVzLg0KRG8geW91
IGhhdmUgYW55IG1vcmUgY29tbWVudHMgZm9yIHRoZSBwcmV2aW91cyB0d28gcGF0Y2hlcz8NClRo
YW5rcy4NClJveQ0K
^ permalink raw reply
* Re: [PATCH] spi_mpc8xxx: fix buffer overrun when sending only/receiving only more than PAGE_SIZE bytes
From: Joakim Tjernlund @ 2010-09-16 7:40 UTC (permalink / raw)
To: christophe leroy
Cc: spi-devel-general, David Brownell, linuxppc-dev, linux-kernel
In-Reply-To: <20100916070525.4882CC7391@messagerie.si.c-s.fr>
> From: christophe leroy <christophe.leroy@c-s.fr>
> To: David Brownell <dbrownell@users.sourceforge.net>, Grant Likely
> <grant.likely@secretlab.ca>, spi-devel-general@lists.sourceforge.net, linux-
> kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
> Date: 2010/09/16 09:07
> Subject: [PATCH] spi_mpc8xxx: fix buffer overrun when sending only/receiving
> only more than PAGE_SIZE bytes
> Sent by: linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org
>
> This patch applies to 2.6.34.7 and 2.6.35.4
> It fixes an issue when sending only or receiving only more than PAGE_SIZE bytes
>
> Signed-off-by: christophe leroy <christophe.leroy@c-s.fr>
Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
^ permalink raw reply
* Re: [PATCH] spi_mpc8xxx: fix writing to adress 0
From: Joakim Tjernlund @ 2010-09-16 7:39 UTC (permalink / raw)
To: christophe leroy
Cc: spi-devel-general, David Brownell, linuxppc-dev, linux-kernel
In-Reply-To: <20100916070420.95083C7391@messagerie.si.c-s.fr>
> From: christophe leroy <christophe.leroy@c-s.fr>
> To: David Brownell <dbrownell@users.sourceforge.net>, Grant Likely
> <grant.likely@secretlab.ca>, spi-devel-general@lists.sourceforge.net, linux-
> kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
> Date: 2010/09/16 09:06
> Subject: [PATCH] spi_mpc8xxx: fix writing to adress 0
> Sent by: linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org
>
> This patch applies to 2.6.34.7 (already included in 2.6.35.4)
> It fixes an issue when sending only or receiving only (mspi->tx-dma was reset
> as when no tx_buf is defined, tx_dma is 0)
>
> Signed-off-by: christophe leroy <christophe.leroy@c-s.fr>
Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
^ permalink raw reply
* Re: cuImage and multi image?
From: Shawn Jin @ 2010-09-16 7:49 UTC (permalink / raw)
To: tiejun.chen; +Cc: ppcdev, uboot
In-Reply-To: <4C91C77B.8080501@windriver.com>
> Try the following steps:
> ------
> 1. cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
> 2. make cuImage.initrd.<your target>
>
> You can get one Image, cuImage.initrd.<your target>, including kernel and ramdisk.
Cool! Thanks a lot, Tiejun.
-Shawn.
^ permalink raw reply
* Re: Generating elf kernel ?
From: tiejun.chen @ 2010-09-16 7:51 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <201009160925.50082.dargaud@lpsc.in2p3.fr>
Guillaume Dargaud wrote:
>>>> Please use simpleImage.<your target dts name>.elf.
>>> Great, that seems to be it...
>>> Except that nothing happens when I jump to 0x40000, no message from the
>> 0x40000? I recalled the entry point should be 0x400000 for
>> simepleImage.*.elf. So you have to change this on the file,
>> arch/powerpc/boot/wrapper.
>
> Correct, I skipped a zero, the address is indeed 0x400000
>
>> And also you should confirm if the upstream kernel support your board.
>
> Our board is a custom derivative from a ML405.
Understood.
So I recommend you use the kernel tree from xilinx. You can refer to the
following website:
http://xilinx.wikidot.com/powerpc-linux
I hope you can skip many issues to accelerate your progress based on the xilinx
kernel.
> My previous project uses ARCH=PPC and has been working fine for 2 years.
> I'm currently trying to go to ARCH=PowerPC and understand dts files in order to
> boot my first kernel.
> I assume I shouldn't have to change anything in my bootloader.
> After I jump to the kernel address, I don't even get the usual:
> loaded at: 00400000 004F559C
> board data at: 004F3520 004F359C
> relocated to: 0040505C 004050D8
> zimage at: 00405E48 004F211C
> avail ram: 004F6000 08000000
> Linux/PPC load: console=ttyUL0,115200 rw root=/dev/nfs ip=bootp
> Uncompressing Linux...done.
> Now booting the kernel
>
> Something wrong with my serial console ?
You have to check if you go the correct PC address. Note please check the real
pc address according to the previous comments.
If yes you can check where your kernel stop. Certainly if you have some tools,
such as JTAG debug tools it's convenient to track this. But if no it will be
difficult to go no next.
But you still have ways to do, such as display LED, early printk, and dump
__log_buf.
>
>> Additionally let's assume your bootloader create the map between the
>> virtual address and the physical address as 1:1. If so you want to execute
>> from 0x40000. But the actual PC address should be the loader address +
>> offset. You can get this by readelf. Here if your loader address is zero,
>> the offset will be pc address, not 0x40000. You can dump your memory to
>> check this.
>
> The bootloader has no concept of virtual address, right ?
This should be depend on the given PPC core. For example, we cannot disable MMU
on e500. Bur for ML405 we can disable MMU to run real mode on 405.
Cheers
Tiejun
>
^ permalink raw reply
* Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Anton Vorontsov @ 2010-09-16 8:21 UTC (permalink / raw)
To: Roy Zang
Cc: B07421, dedekind1, B25806, linuxppc-dev, linux-mtd, akpm, dwmw2,
B11780
In-Reply-To: <1284619284-23614-2-git-send-email-tie-fei.zang@freescale.com>
On Thu, Sep 16, 2010 at 02:41:23PM +0800, Roy Zang wrote:
[...]
> -static int __devinit fsl_elbc_chip_probe(struct fsl_elbc_ctrl *ctrl,
> - struct device_node *node)
> +/*
> + * Currently only one elbc probe is supported.
> + */
> +static int __devinit fsl_elbc_nand_probe(struct platform_device *dev)
> {
> - struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
> + struct fsl_lbc_regs __iomem *lbc;
> struct fsl_elbc_mtd *priv;
> struct resource res;
> + struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = NULL;
[...]
> - ctrl->chips[bank] = priv;
> + if (fsl_lbc_ctrl_dev->nand == NULL) {
> + elbc_fcm_ctrl = kzalloc(sizeof(*elbc_fcm_ctrl), GFP_KERNEL);
> + if (!elbc_fcm_ctrl) {
[...]
> + goto err;
> + }
> + fsl_lbc_ctrl_dev->nand = elbc_fcm_ctrl;
> + }
> +
> + elbc_fcm_ctrl->chips[bank] = priv;
Again, this will oops on the second probe. And you still don't
lock fsl_lbc_ctrl_dev->nand during check-then-assignment, so
with parallel probing there will be a race. :-(
We do have boards with several NAND chips (e.g.
arch/powerpc/boot/dts/mpc8610_hpcd.dts), so these issues
are all legitimate.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* RE: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Zang Roy-R61911 @ 2010-09-16 8:50 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <20100916082141.GA10978@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIFNlcHRl
bWJlciAxNiwgMjAxMCAxNjoyMiBQTQ0KPiBUbzogWmFuZyBSb3ktUjYxOTExDQo+IENjOiBsaW51
eC1tdGRAbGlzdHMuaW5mcmFkZWFkLm9yZzsgZHdtdzJAaW5mcmFkZWFkLm9yZzsgZGVkZWtpbmQx
QGdtYWlsLmNvbTsNCj4gYWtwbUBsaW51eC1mb3VuZGF0aW9uLm9yZzsgTGFuIENodW5oZS1CMjU4
MDY7IFdvb2QgU2NvdHQtQjA3NDIxOyBHYWxhIEt1bWFyLQ0KPiBCMTE3ODA7IGxpbnV4cHBjLWRl
dkBvemxhYnMub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi8zIHYzXSBQNDA4MC9tdGQ6IE9u
bHkgbWFrZSBlbGJjIG5hbmQgZHJpdmVyIGRldGVjdCBuYW5kDQo+IGZsYXNoIHBhcnRpdGlvbnMN
Cj4gDQo+IE9uIFRodSwgU2VwIDE2LCAyMDEwIGF0IDAyOjQxOjIzUE0gKzA4MDAsIFJveSBaYW5n
IHdyb3RlOg0KPiBbLi4uXQ0KPiA+IC1zdGF0aWMgaW50IF9fZGV2aW5pdCBmc2xfZWxiY19jaGlw
X3Byb2JlKHN0cnVjdCBmc2xfZWxiY19jdHJsICpjdHJsLA0KPiA+IC0gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBkZXZpY2Vfbm9kZSAqbm9kZSkNCj4gPiArLyoN
Cj4gPiArICogQ3VycmVudGx5IG9ubHkgb25lIGVsYmMgcHJvYmUgaXMgc3VwcG9ydGVkLg0KPiA+
ICsgKi8NCj4gPiArc3RhdGljIGludCBfX2RldmluaXQgZnNsX2VsYmNfbmFuZF9wcm9iZShzdHJ1
Y3QgcGxhdGZvcm1fZGV2aWNlICpkZXYpDQo+ID4gIHsNCj4gPiAtICAgICBzdHJ1Y3QgZnNsX2xi
Y19yZWdzIF9faW9tZW0gKmxiYyA9IGN0cmwtPnJlZ3M7DQo+ID4gKyAgICAgc3RydWN0IGZzbF9s
YmNfcmVncyBfX2lvbWVtICpsYmM7DQo+ID4gICAgICAgc3RydWN0IGZzbF9lbGJjX210ZCAqcHJp
djsNCj4gPiAgICAgICBzdHJ1Y3QgcmVzb3VyY2UgcmVzOw0KPiA+ICsgICAgIHN0cnVjdCBmc2xf
ZWxiY19mY21fY3RybCAqZWxiY19mY21fY3RybCA9IE5VTEw7DQo+IFsuLi5dDQo+ID4gLSAgICAg
Y3RybC0+Y2hpcHNbYmFua10gPSBwcml2Ow0KPiA+ICsgICAgIGlmIChmc2xfbGJjX2N0cmxfZGV2
LT5uYW5kID09IE5VTEwpIHsNCj4gPiArICAgICAgICAgICAgIGVsYmNfZmNtX2N0cmwgPSBremFs
bG9jKHNpemVvZigqZWxiY19mY21fY3RybCksIEdGUF9LRVJORUwpOw0KPiA+ICsgICAgICAgICAg
ICAgaWYgKCFlbGJjX2ZjbV9jdHJsKSB7DQo+IFsuLi5dDQo+ID4gKyAgICAgICAgICAgICAgICAg
ICAgIGdvdG8gZXJyOw0KPiA+ICsgICAgICAgICAgICAgfQ0KPiA+ICsgICAgICAgICAgICAgZnNs
X2xiY19jdHJsX2Rldi0+bmFuZCA9IGVsYmNfZmNtX2N0cmw7DQo+ID4gKyAgICAgfQ0KPiA+ICsN
Cj4gPiArICAgICBlbGJjX2ZjbV9jdHJsLT5jaGlwc1tiYW5rXSA9IHByaXY7DQo+IA0KPiBBZ2Fp
biwgdGhpcyB3aWxsIG9vcHMgb24gdGhlIHNlY29uZCBwcm9iZS4NCldoeT8NCg0KPiBBbmQgeW91
IHN0aWxsIGRvbid0DQo+IGxvY2sgZnNsX2xiY19jdHJsX2Rldi0+bmFuZCBkdXJpbmcgY2hlY2st
dGhlbi1hc3NpZ25tZW50LCBzbw0KPiB3aXRoIHBhcmFsbGVsIHByb2JpbmcgdGhlcmUgd2lsbCBi
ZSBhIHJhY2UuIDotKA0KPiANCj4gV2UgZG8gaGF2ZSBib2FyZHMgd2l0aCBzZXZlcmFsIE5BTkQg
Y2hpcHMgKGUuZy4NCj4gYXJjaC9wb3dlcnBjL2Jvb3QvZHRzL21wYzg2MTBfaHBjZC5kdHMpLCBz
byB0aGVzZSBpc3N1ZXMNCj4gYXJlIGFsbCBsZWdpdGltYXRlLg0KT0suIEkgY2FuIGFkZCBhIG11
dGV4IGhlcmUuDQpUaGFua3MuDQpSb3kNCg0K
^ permalink raw reply
* Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Anton Vorontsov @ 2010-09-16 9:25 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60A1FC6B8@zch01exm23.fsl.freescale.net>
On Thu, Sep 16, 2010 at 04:50:05PM +0800, Zang Roy-R61911 wrote:
> > On Thu, Sep 16, 2010 at 02:41:23PM +0800, Roy Zang wrote:
> > [...]
> > > -static int __devinit fsl_elbc_chip_probe(struct fsl_elbc_ctrl *ctrl,
> > > - struct device_node *node)
> > > +/*
> > > + * Currently only one elbc probe is supported.
> > > + */
> > > +static int __devinit fsl_elbc_nand_probe(struct platform_device *dev)
> > > {
> > > - struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
> > > + struct fsl_lbc_regs __iomem *lbc;
> > > struct fsl_elbc_mtd *priv;
> > > struct resource res;
> > > + struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = NULL;
> > [...]
> > > - ctrl->chips[bank] = priv;
> > > + if (fsl_lbc_ctrl_dev->nand == NULL) {
> > > + elbc_fcm_ctrl = kzalloc(sizeof(*elbc_fcm_ctrl), GFP_KERNEL);
> > > + if (!elbc_fcm_ctrl) {
> > [...]
> > > + goto err;
> > > + }
> > > + fsl_lbc_ctrl_dev->nand = elbc_fcm_ctrl;
> > > + }
> > > +
> > > + elbc_fcm_ctrl->chips[bank] = priv;
> >
> > Again, this will oops on the second probe.
> Why?
Because of a NULL dereference ("elbc_fcm_ctrl->").
I understand that you don't have to believe me, but will you believe
a compiler?
oksana:~$ cat a.c
#include <stdio.h>
#include <malloc.h>
char *foo;
void probe(void)
{
char *bar = NULL;
if (!foo) {
bar = malloc(sizeof(*bar));
if (!bar)
return;
foo = bar;
}
*bar = 'a';
}
int main(void)
{
probe();
probe();
return 0;
}
oksana:~$ gcc a.c && ./a.out
Segmentation fault
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Reserved pages in PowerPC
From: Benjamin Herrenschmidt @ 2010-09-16 10:04 UTC (permalink / raw)
To: Ankita Garg; +Cc: linuxppc-dev, linux-mm
In-Reply-To: <20100916052311.GC2332@in.ibm.com>
On Thu, 2010-09-16 at 10:53 +0530, Ankita Garg wrote:
>
> With some debugging I found that that section has reserved pages. On
> instrumenting the memblock_reserve() and reserve_bootmem() routines, I can see
> that many of the memory areas are reserved for kernel and initrd by the
> memblock reserve() itself. reserve_bootmem then looks at the pages already
> reserved and marks them reserved. However, for the very last section, I see
> that bootmem reserves it but I am unable to find a corresponding reservation
> by the memblock code.
It's probably RTAS (firmware runtime services). I'ts instanciated at
boot from prom_init and we do favor high addresses for it below 1G iirc.
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Zang Roy-R61911 @ 2010-09-16 10:08 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <20100916092551.GA17548@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIFNlcHRl
bWJlciAxNiwgMjAxMCAxNzoyNiBQTQ0KPiBUbzogWmFuZyBSb3ktUjYxOTExDQo+IENjOiBsaW51
eC1tdGRAbGlzdHMuaW5mcmFkZWFkLm9yZzsgZHdtdzJAaW5mcmFkZWFkLm9yZzsgZGVkZWtpbmQx
QGdtYWlsLmNvbTsNCj4gYWtwbUBsaW51eC1mb3VuZGF0aW9uLm9yZzsgTGFuIENodW5oZS1CMjU4
MDY7IFdvb2QgU2NvdHQtQjA3NDIxOyBHYWxhIEt1bWFyLQ0KPiBCMTE3ODA7IGxpbnV4cHBjLWRl
dkBvemxhYnMub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi8zIHYzXSBQNDA4MC9tdGQ6IE9u
bHkgbWFrZSBlbGJjIG5hbmQgZHJpdmVyIGRldGVjdCBuYW5kDQo+IGZsYXNoIHBhcnRpdGlvbnMN
Cj4gDQo+IE9uIFRodSwgU2VwIDE2LCAyMDEwIGF0IDA0OjUwOjA1UE0gKzA4MDAsIFphbmcgUm95
LVI2MTkxMSB3cm90ZToNCj4gPiA+IE9uIFRodSwgU2VwIDE2LCAyMDEwIGF0IDAyOjQxOjIzUE0g
KzA4MDAsIFJveSBaYW5nIHdyb3RlOg0KPiA+ID4gWy4uLl0NCj4gPiA+ID4gLXN0YXRpYyBpbnQg
X19kZXZpbml0IGZzbF9lbGJjX2NoaXBfcHJvYmUoc3RydWN0IGZzbF9lbGJjX2N0cmwgKmN0cmws
DQo+ID4gPiA+IC0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBk
ZXZpY2Vfbm9kZSAqbm9kZSkNCj4gPiA+ID4gKy8qDQo+ID4gPiA+ICsgKiBDdXJyZW50bHkgb25s
eSBvbmUgZWxiYyBwcm9iZSBpcyBzdXBwb3J0ZWQuDQo+ID4gPiA+ICsgKi8NCj4gPiA+ID4gK3N0
YXRpYyBpbnQgX19kZXZpbml0IGZzbF9lbGJjX25hbmRfcHJvYmUoc3RydWN0IHBsYXRmb3JtX2Rl
dmljZSAqZGV2KQ0KPiA+ID4gPiAgew0KPiA+ID4gPiAtICAgICBzdHJ1Y3QgZnNsX2xiY19yZWdz
IF9faW9tZW0gKmxiYyA9IGN0cmwtPnJlZ3M7DQo+ID4gPiA+ICsgICAgIHN0cnVjdCBmc2xfbGJj
X3JlZ3MgX19pb21lbSAqbGJjOw0KPiA+ID4gPiAgICAgICBzdHJ1Y3QgZnNsX2VsYmNfbXRkICpw
cml2Ow0KPiA+ID4gPiAgICAgICBzdHJ1Y3QgcmVzb3VyY2UgcmVzOw0KPiA+ID4gPiArICAgICBz
dHJ1Y3QgZnNsX2VsYmNfZmNtX2N0cmwgKmVsYmNfZmNtX2N0cmwgPSBOVUxMOw0KPiA+ID4gWy4u
Ll0NCj4gPiA+ID4gLSAgICAgY3RybC0+Y2hpcHNbYmFua10gPSBwcml2Ow0KPiA+ID4gPiArICAg
ICBpZiAoZnNsX2xiY19jdHJsX2Rldi0+bmFuZCA9PSBOVUxMKSB7DQo+ID4gPiA+ICsgICAgICAg
ICAgICAgZWxiY19mY21fY3RybCA9IGt6YWxsb2Moc2l6ZW9mKCplbGJjX2ZjbV9jdHJsKSwNCj4g
R0ZQX0tFUk5FTCk7DQo+ID4gPiA+ICsgICAgICAgICAgICAgaWYgKCFlbGJjX2ZjbV9jdHJsKSB7
DQo+ID4gPiBbLi4uXQ0KPiA+ID4gPiArICAgICAgICAgICAgICAgICAgICAgZ290byBlcnI7DQo+
ID4gPiA+ICsgICAgICAgICAgICAgfQ0KPiA+ID4gPiArICAgICAgICAgICAgIGZzbF9sYmNfY3Ry
bF9kZXYtPm5hbmQgPSBlbGJjX2ZjbV9jdHJsOw0KPiA+ID4gPiArICAgICB9DQo+ID4gPiA+ICsN
Cj4gPiA+ID4gKyAgICAgZWxiY19mY21fY3RybC0+Y2hpcHNbYmFua10gPSBwcml2Ow0KPiA+ID4N
Cj4gPiA+IEFnYWluLCB0aGlzIHdpbGwgb29wcyBvbiB0aGUgc2Vjb25kIHByb2JlLg0KPiA+IFdo
eT8NCj4gDQo+IEJlY2F1c2Ugb2YgYSBOVUxMIGRlcmVmZXJlbmNlICgiZWxiY19mY21fY3RybC0+
IikuDQo+IA0KPiBJIHVuZGVyc3RhbmQgdGhhdCB5b3UgZG9uJ3QgaGF2ZSB0byBiZWxpZXZlIG1l
LCBidXQgd2lsbCB5b3UgYmVsaWV2ZQ0KPiBhIGNvbXBpbGVyPw0KPiANCj4gb2tzYW5hOn4kIGNh
dCBhLmMNCj4gI2luY2x1ZGUgPHN0ZGlvLmg+DQo+ICNpbmNsdWRlIDxtYWxsb2MuaD4NCj4gDQo+
IGNoYXIgKmZvbzsNCj4gDQo+IHZvaWQgcHJvYmUodm9pZCkNCj4gew0KPiAgICAgICAgIGNoYXIg
KmJhciA9IE5VTEw7DQo+IA0KPiAgICAgICAgIGlmICghZm9vKSB7DQo+ICAgICAgICAgICAgICAg
ICBiYXIgPSBtYWxsb2Moc2l6ZW9mKCpiYXIpKTsNCj4gICAgICAgICAgICAgICAgIGlmICghYmFy
KQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICByZXR1cm47DQo+ICAgICAgICAgICAgICAgICBm
b28gPSBiYXI7DQo+ICAgICAgICAgfQ0KPiAgICAgICAgICpiYXIgPSAnYSc7DQo+IH0NCj4gDQo+
IGludCBtYWluKHZvaWQpDQo+IHsNCj4gICAgICAgICBwcm9iZSgpOw0KPiAgICAgICAgIHByb2Jl
KCk7DQo+ICAgICAgICAgcmV0dXJuIDA7DQo+IH0NCj4gb2tzYW5hOn4kIGdjYyBhLmMgJiYgLi9h
Lm91dA0KPiBTZWdtZW50YXRpb24gZmF1bHQNCkludGVyZXN0aW5nLg0KSG93IGFib3V0IHRoaXM/
DQojaW5jbHVkZSA8c3RkaW8uaD4NCiNpbmNsdWRlIDxtYWxsb2MuaD4NCg0KY2hhciAqZm9vOw0K
DQp2b2lkIHByb2JlKHZvaWQpDQp7DQogICAgICAgIGNoYXIgKmJhciA9IE5VTEw7DQoNCiAgICAg
ICAgaWYgKCFmb28pIHsNCiAgICAgICAgICAgICAgICBiYXIgPSBtYWxsb2Moc2l6ZW9mKCpiYXIp
KTsNCiAgICAgICAgICAgICAgICBpZiAoIWJhcikNCiAgICAgICAgICAgICAgICAgICAgICAgIHJl
dHVybjsNCiAgICAgICAgICAgICAgICBmb28gPSBiYXI7DQogICAgICAgIH0gZWxzZQ0KCQkgICBi
YXIgPSBmb287CSAgDQogICAgICAgICpiYXIgPSAnYSc7DQp9DQoNCmludCBtYWluKHZvaWQpDQp7
DQogICAgICAgIHByb2JlKCk7DQogICAgICAgIHByb2JlKCk7DQogICAgICAgIHJldHVybiAwOw0K
fQ0KDQo=
^ permalink raw reply
* Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Anton Vorontsov @ 2010-09-16 10:14 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60A1FC6DB@zch01exm23.fsl.freescale.net>
On Thu, Sep 16, 2010 at 06:08:14PM +0800, Zang Roy-R61911 wrote:
[...]
> Interesting.
> How about this?
> #include <stdio.h>
> #include <malloc.h>
>
> char *foo;
>
> void probe(void)
> {
> char *bar = NULL;
>
> if (!foo) {
> bar = malloc(sizeof(*bar));
> if (!bar)
> return;
> foo = bar;
> } else
> bar = foo;
This willl work of course; but I'd write it as
foo_lock();
if (!foo)
foo = alloc();
foo_unlock();
bar = foo;
bar->baz;
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* RE: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Zang Roy-R61911 @ 2010-09-16 10:39 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <20100916101429.GA27393@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIFNlcHRl
bWJlciAxNiwgMjAxMCAxODoxNCBQTQ0KPiBUbzogWmFuZyBSb3ktUjYxOTExDQo+IENjOiBXb29k
IFNjb3R0LUIwNzQyMTsgZGVkZWtpbmQxQGdtYWlsLmNvbTsgTGFuIENodW5oZS1CMjU4MDY7IGxp
bnV4cHBjLQ0KPiBkZXZAb3psYWJzLm9yZzsgbGludXgtbXRkQGxpc3RzLmluZnJhZGVhZC5vcmc7
IGFrcG1AbGludXgtZm91bmRhdGlvbi5vcmc7DQo+IGR3bXcyQGluZnJhZGVhZC5vcmc7IEdhbGEg
S3VtYXItQjExNzgwDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi8zIHYzXSBQNDA4MC9tdGQ6IE9u
bHkgbWFrZSBlbGJjIG5hbmQgZHJpdmVyIGRldGVjdCBuYW5kDQo+IGZsYXNoIHBhcnRpdGlvbnMN
Cj4gDQo+IE9uIFRodSwgU2VwIDE2LCAyMDEwIGF0IDA2OjA4OjE0UE0gKzA4MDAsIFphbmcgUm95
LVI2MTkxMSB3cm90ZToNCj4gWy4uLl0NCj4gPiBJbnRlcmVzdGluZy4NCj4gPiBIb3cgYWJvdXQg
dGhpcz8NCj4gPiAjaW5jbHVkZSA8c3RkaW8uaD4NCj4gPiAjaW5jbHVkZSA8bWFsbG9jLmg+DQo+
ID4NCj4gPiBjaGFyICpmb287DQo+ID4NCj4gPiB2b2lkIHByb2JlKHZvaWQpDQo+ID4gew0KPiA+
ICAgICAgICAgY2hhciAqYmFyID0gTlVMTDsNCj4gPg0KPiA+ICAgICAgICAgaWYgKCFmb28pIHsN
Cj4gPiAgICAgICAgICAgICAgICAgYmFyID0gbWFsbG9jKHNpemVvZigqYmFyKSk7DQo+ID4gICAg
ICAgICAgICAgICAgIGlmICghYmFyKQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgIHJldHVy
bjsNCj4gPiAgICAgICAgICAgICAgICAgZm9vID0gYmFyOw0KPiA+ICAgICAgICAgfSBlbHNlDQo+
ID4gCQkgICBiYXIgPSBmb287DQo+IA0KPiBUaGlzIHdpbGxsIHdvcmsgb2YgY291cnNlOyBidXQg
SSdkIHdyaXRlIGl0IGFzDQo+IA0KPiBmb29fbG9jaygpOw0KPiBpZiAoIWZvbykNCj4gCWZvbyA9
IGFsbG9jKCk7DQo+IGZvb191bmxvY2soKTsNCj4gDQo+IGJhciA9IGZvbzsNCj4gYmFyLT5iYXo7
DQpCdXQgbXkgY29kZSBoYXMgc29tZSBhc3NpZ25tZW50IGZvciAiZm9vIiBpbnN0ZWFkIG9mIGEg
c2ltcGxlDQphbGxvY2F0aW9uLCBob3cgYWJvdXQgdGhpcyB3YXkgZm9yIG15IGNvZGU6DQpERUZJ
TkVfTVVURVgoZnNsX2VsYmNfbXV0ZXgpOw0KLi4uDQpzdGF0aWMgaW50IF9fZGV2aW5pdCBmc2xf
ZWxiY19uYW5kX3Byb2JlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKmRldikNCnsNCi4uLg0KICAg
ICAgICBtdXRleF9sb2NrKCZmc2xfbGJjX211dGV4KTsNCiAgICAgICAgaWYgKCFmc2xfbGJjX2N0
cmxfZGV2LT5uYW5kKSB7DQogICAgICAgICAgICAgICAgZWxiY19mY21fY3RybCA9IGt6YWxsb2Mo
c2l6ZW9mKCplbGJjX2ZjbV9jdHJsKSwgR0ZQX0tFUk5FTCk7DQogICAgICAgICAgICAgICAgaWYg
KCFlbGJjX2ZjbV9jdHJsKSB7DQogICAgICAgICAgICAgICAgICAgICAgICBkZXZfZXJyKGZzbF9s
YmNfY3RybF9kZXYtPmRldiwgImZhaWxlZCB0byBhbGxvY2F0ZSAiDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIm1lbW9yeVxuIik7DQogICAgICAgICAgICAgICAgICAg
ICAgICByZXQgPSAtRU5PTUVNOw0KICAgICAgICAgICAgICAgICAgICAgICAgZ290byBlcnI7DQog
ICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgZWxiY19mY21fY3RybC0+cmVhZF9i
eXRlcyA9IDA7DQogICAgICAgICAgICAgICAgZWxiY19mY21fY3RybC0+aW5kZXggPSAwOw0KICAg
ICAgICAgICAgICAgIGVsYmNfZmNtX2N0cmwtPmFkZHIgPSBOVUxMOw0KDQogICAgICAgICAgICAg
ICAgc3Bpbl9sb2NrX2luaXQoJmVsYmNfZmNtX2N0cmwtPmNvbnRyb2xsZXIubG9jayk7DQogICAg
ICAgICAgICAgICAgaW5pdF93YWl0cXVldWVfaGVhZCgmZWxiY19mY21fY3RybC0+Y29udHJvbGxl
ci53cSk7DQogICAgICAgICAgICAgICAgZnNsX2xiY19jdHJsX2Rldi0+bmFuZCA9IGVsYmNfZmNt
X2N0cmw7DQogICAgICAgIH0gZWxzZQ0KICAgICAgICAgICAgICAgIGVsYmNfZmNtX2N0cmwgPSBm
c2xfbGJjX2N0cmxfZGV2LT5uYW5kOw0KICAgICAgICBtdXRleF91bmxvY2soJmZzbF9sYmNfbXV0
ZXgpOw0KDQogICAgICAgIGVsYmNfZmNtX2N0cmwtPmNoaXBzW2JhbmtdID0gcHJpdjsNCi4uLg0K
fQ0KDQpBbnkgY29tbWVudD8NClRoYW5rcy4NClJveQ0KDQoNCg0K
^ permalink raw reply
* Re: [PATCH 11/15] ppc/cell: beat dma ops cleanup
From: Arnd Bergmann @ 2010-09-16 11:23 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: cbe-oss-dev, Milton Miller, Paul Mackerras, linuxppc-dev,
David S. Miller
In-Reply-To: <1284573958-8397-12-git-send-email-nacc@us.ibm.com>
On Wednesday 15 September 2010, Nishanth Aravamudan wrote:
> direct_dma_ops is the default pci dma ops.
>
> No need to call a function to get the pci dma ops, we know they are the
> dma_direct_ops.
>
> Signed-off-by: Milton Miller <miltonm@bga.com>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Anton Vorontsov @ 2010-09-16 11:26 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60A1FC6E1@zch01exm23.fsl.freescale.net>
On Thu, Sep 16, 2010 at 06:39:40PM +0800, Zang Roy-R61911 wrote:
[...]
> But my code has some assignment for "foo" instead of a simple
> allocation, how about this way for my code:
This will surely work, and all the rest is just a matter of
taste. So, I'm fine with it. But see below, I think I found
some new, quite serious issues.
> DEFINE_MUTEX(fsl_elbc_mutex);
I'd place the mutex inside the fsl_lbc_ctrl_dev,
i.e. fsl_lbc_ctrl_dev->nand_lock. This is to avoid more
global variables.
> ...
> static int __devinit fsl_elbc_nand_probe(struct platform_device *dev)
> {
> ...
> mutex_lock(&fsl_lbc_mutex);
> if (!fsl_lbc_ctrl_dev->nand) {
> elbc_fcm_ctrl = kzalloc(sizeof(*elbc_fcm_ctrl), GFP_KERNEL);
> if (!elbc_fcm_ctrl) {
> dev_err(fsl_lbc_ctrl_dev->dev, "failed to allocate "
> "memory\n");
> ret = -ENOMEM;
> goto err;
> }
>
> elbc_fcm_ctrl->read_bytes = 0;
> elbc_fcm_ctrl->index = 0;
> elbc_fcm_ctrl->addr = NULL;
I guess these variables should be per chip select, as
otherwise there will be tons of races when somebody try
to access two or more NAND chips simultaneously.
(Plus, you don't need these = 0 and = NULL as you used
kzalloc() for allocation.)
>
> spin_lock_init(&elbc_fcm_ctrl->controller.lock);
> init_waitqueue_head(&elbc_fcm_ctrl->controller.wq);
Some of these may need to be per chip select too.
So, I'd suggest to redo the whole thing this way: don't allocate
elbc_fcm_ctrl in this driver, but make an array inside the
fsl_lbc_ctrl_dev. I.e.
fsl_lbc_ctrl_dev->nand_ctrl[MAX_CHIP_SELECTS]
or something like that.
Btw, even before this patch, it seems that the driver had
all these bugs/races, i.e. ctrl->controller.lock was not
used at all. Ugh.
> fsl_lbc_ctrl_dev->nand = elbc_fcm_ctrl;
> } else
> elbc_fcm_ctrl = fsl_lbc_ctrl_dev->nand;
Per coding style this should be
} else {
elbc_fcm_ctrl = fsl_lbc_ctrl_dev->nand;
}
> mutex_unlock(&fsl_lbc_mutex);
>
> elbc_fcm_ctrl->chips[bank] = priv;
> ...
> }
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Reserved pages in PowerPC
From: Ankita Garg @ 2010-09-16 12:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-mm
In-Reply-To: <1284631464.30449.85.camel@pasglop>
Hi Ben,
On Thu, Sep 16, 2010 at 08:04:24PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2010-09-16 at 10:53 +0530, Ankita Garg wrote:
> >
> > With some debugging I found that that section has reserved pages. On
> > instrumenting the memblock_reserve() and reserve_bootmem() routines, I can see
> > that many of the memory areas are reserved for kernel and initrd by the
> > memblock reserve() itself. reserve_bootmem then looks at the pages already
> > reserved and marks them reserved. However, for the very last section, I see
> > that bootmem reserves it but I am unable to find a corresponding reservation
> > by the memblock code.
>
> It's probably RTAS (firmware runtime services). I'ts instanciated at
> boot from prom_init and we do favor high addresses for it below 1G iirc.
>
Thanks Ben for taking a look at this. So I checked the rtas messages on
the serial console and see the following:
instantiating rtas at 0x000000000f632000... done
Which does not correspond to the higher addresses that I see as reserved
(observation on a 16G machine).
--
Regards,
Ankita Garg (ankita@in.ibm.com)
Linux Technology Center
IBM India Systems & Technology Labs,
Bangalore, India
^ permalink raw reply
* Re: 2.6.35-stable/ppc64/p7: suspicious rcu_dereference_check() usage detected during 2.6.35-stable boot
From: Valdis.Kletnieks @ 2010-09-16 15:12 UTC (permalink / raw)
To: paulmck
Cc: sachinp, Peter Zijlstra, Li Zefan, linux-kernel, Linuxppc-dev,
Subrata Modak, DIVYA PRAKASH
In-Reply-To: <20100809161200.GC3026@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 974 bytes --]
On Mon, 09 Aug 2010 09:12:00 PDT, "Paul E. McKenney" said:
> On Mon, Aug 02, 2010 at 02:22:12PM +0530, Subrata Modak wrote:
> > Hi,
> >
> > The following suspicious rcu_dereference_check() usage is detected
> > during 2.6.35-stable boot on my ppc64/p7 machine:
> >
> > =========================
> > [ INFO: suspicious rcu_dereference_check() usage. ]
> > ---------------------------------------------------
> > kernel/sched.c:616 invoked rcu_dereference_check() without protection!
> > other info that might help us debug this:
> Thank you for locating this one! This looks like the same issue that
> Ilia Mirkin located. Please see below for my analysis -- no fix yet,
> as I need confirmation from cgroups experts. I can easily create a
> patch that suppresses the warning, but I don't yet know whether this is
> the right thing to do.
Ping? I just hit it on 2.6.36-rc4-mmotm0915. Just wanted to make sure the
issue hadn't been lost/forgotten.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: 2.6.35-stable/ppc64/p7: suspicious rcu_dereference_check() usage detected during 2.6.35-stable boot
From: Peter Zijlstra @ 2010-09-16 15:50 UTC (permalink / raw)
To: paulmck
Cc: sachinp, Valdis.Kletnieks, Li Zefan, linux-kernel, Linuxppc-dev,
Subrata Modak, DIVYA PRAKASH
In-Reply-To: <20100809161200.GC3026@linux.vnet.ibm.com>
On Mon, 2010-08-09 at 09:12 -0700, Paul E. McKenney wrote:
> > [ 0.051203] CPU0: AMD QEMU Virtual CPU version 0.12.4 stepping 03
> > [ 0.052999] lockdep: fixing up alternatives.
> > [ 0.054105]
> > [ 0.054106] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
> > [ 0.054999] [ INFO: suspicious rcu_dereference_check() usage. ]
> > [ 0.054999] ---------------------------------------------------
> > [ 0.054999] kernel/sched.c:616 invoked rcu_dereference_check() witho=
ut protection!
> > [ 0.054999]
> > [ 0.054999] other info that might help us debug this:
> > [ 0.054999]
> > [ 0.054999]
> > [ 0.054999] rcu_scheduler_active =3D 1, debug_locks =3D 1
> > [ 0.054999] 3 locks held by swapper/1:
> > [ 0.054999] #0: (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff814be=
933>] cpu_up+0x42/0x6a
> > [ 0.054999] #1: (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff810400d8=
>] cpu_hotplug_begin+0x2a/0x51
> > [ 0.054999] #2: (&rq->lock){-.-...}, at: [<ffffffff814be2f7>] init=
_idle+0x2f/0x113
> > [ 0.054999]
> > [ 0.054999] stack backtrace:
> > [ 0.054999] Pid: 1, comm: swapper Not tainted 2.6.35 #1
> > [ 0.054999] Call Trace:
> > [ 0.054999] [<ffffffff81068054>] lockdep_rcu_dereference+0x9b/0xa3
> > [ 0.054999] [<ffffffff810325c3>] task_group+0x7b/0x8a
> > [ 0.054999] [<ffffffff810325e5>] set_task_rq+0x13/0x40
> > [ 0.054999] [<ffffffff814be39a>] init_idle+0xd2/0x113
> > [ 0.054999] [<ffffffff814be78a>] fork_idle+0xb8/0xc7
> > [ 0.054999] [<ffffffff81068717>] ? mark_held_locks+0x4d/0x6b
> > [ 0.054999] [<ffffffff814bcebd>] do_fork_idle+0x17/0x2b
> > [ 0.054999] [<ffffffff814bc89b>] native_cpu_up+0x1c1/0x724
> > [ 0.054999] [<ffffffff814bcea6>] ? do_fork_idle+0x0/0x2b
> > [ 0.054999] [<ffffffff814be876>] _cpu_up+0xac/0x127
> > [ 0.054999] [<ffffffff814be946>] cpu_up+0x55/0x6a
> > [ 0.054999] [<ffffffff81ab562a>] kernel_init+0xe1/0x1ff
> > [ 0.054999] [<ffffffff81003854>] kernel_thread_helper+0x4/0x10
> > [ 0.054999] [<ffffffff814c353c>] ? restore_args+0x0/0x30
> > [ 0.054999] [<ffffffff81ab5549>] ? kernel_init+0x0/0x1ff
> > [ 0.054999] [<ffffffff81003850>] ? kernel_thread_helper+0x0/0x10
> > [ 0.056074] Booting Node 0, Processors #1lockdep: fixing up alter=
natives.
> > [ 0.130045] #2lockdep: fixing up alternatives.
> > [ 0.203089] #3 Ok.
> > [ 0.275286] Brought up 4 CPUs
> > [ 0.276005] Total of 4 processors activated (16017.17 BogoMIPS).
>=20
> This does look like a new one, thank you for reporting it!
>=20
> Here is my analysis, which should at least provide some humor value to
> those who understand the code better than I do. ;-)
>=20
> So the corresponding rcu_dereference_check() is in
> task_subsys_state_check(), and is fetching the cpu_cgroup_subsys_id
> element of the newly created task's task->cgroups->subsys[] array.
> The "git grep" command finds only three uses of cpu_cgroup_subsys_id,
> but no definition.
>=20
> Now, fork_idle() invokes copy_process(), which invokes cgroup_fork(),
> which sets the child process's ->cgroups pointer to that of the parent,
> also invoking get_css_set(), which increments the corresponding reference
> count, doing both operations under task_lock() protection (->alloc_lock).
> Because fork_idle() does not specify any of CLONE_NEWNS, CLONE_NEWUTS,
> CLONE_NEWIPC, CLONE_NEWPID, or CLONE_NEWNET, copy_namespaces() should
> not create a new namespace, and so there should be no ns_cgroup_clone().
> We should thus retain the parent's ->cgroups pointer. And copy_process()
> installs the new task in the various lists, so that the task is externall=
y
> accessible upon return.
>=20
> After a non-error return from copy_process(), fork_init() invokes
> init_idle_pid(), which does not appear to affect the task's cgroup
> state. Next fork_init() invokes init_idle(), which in turn invokes
> __set_task_cpu(), which invokes set_task_rq(), which calls task_group()
> several times, which calls task_subsys_state_check(), which calls the
> rcu_dereference_check() that complained above.
>=20
> However, the result returns by rcu_dereference_check() is stored into
> the task structure:
>=20
> p->se.cfs_rq =3D task_group(p)->cfs_rq[cpu];
> p->se.parent =3D task_group(p)->se[cpu];
>=20
> This means that the corresponding structure must have been tied down with
> a reference count or some such. If such a reference has been taken, then
> this complaint is a false positive, and could be suppressed by putting
> rcu_read_lock() and rcu_read_unlock() around the call to init_idle()
> from fork_idle(). However, although, reference to the enclosing ->cgroup=
s
> struct css_set is held, it is not clear to me that this reference applies
> to the structures pointed to by the ->subsys[] array, especially given
> that the cgroup_subsys_state structures referenced by this array have
> their own reference count, which does not appear to me to be acquired
> by this code path.
>=20
> Or are the cgroup_subsys_state structures referenced by idle tasks
> never freed or some such?
I would hope so!, the idle tasks should be part of the root cgroup,
which is not removable.
The problem is that while we do in-fact hold rq->lock, the newly spawned
idle thread's cpu is not yet set to the correct cpu so the lockdep check
in task_group():
lockdep_is_held(&task_rq(p)->lock)
will fail.
But of a chicken and egg problem. Setting the cpu needs to have the cpu
set ;-)
Ingo, why do we have rq->lock there at all? The CPU isn't up and running
yet, nothing should be touching it.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
kernel/sched.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/kernel/sched.c b/kernel/sched.c
index bd8b487..6241049 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -5332,7 +5332,19 @@ void __cpuinit init_idle(struct task_struct *idle, i=
nt cpu)
idle->se.exec_start =3D sched_clock();
=20
cpumask_copy(&idle->cpus_allowed, cpumask_of(cpu));
+ /*
+ * We're having a chicken and egg problem, even though we are
+ * holding rq->lock, the cpu isn't yet set to this cpu so the
+ * lockdep check in task_group() will fail.
+ *
+ * Similar case to sched_fork(). / Alternatively we could
+ * use task_rq_lock() here and obtain the other rq->lock.
+ *
+ * Silence PROVE_RCU
+ */
+ rcu_read_lock();
__set_task_cpu(idle, cpu);
+ rcu_read_unlock();
=20
rq->curr =3D rq->idle =3D idle;
#if defined(CONFIG_SMP) && defined(__ARCH_WANT_UNLOCKED_CTXSW)
^ permalink raw reply related
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