* Re: [PATCH 06/12] mpc5121: Added NAND Flash Controller driver.
From: David Jander @ 2009-05-07 8:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-mtd, Wolfgang Denk, Piotr Ziecik
In-Reply-To: <1241640919-4650-7-git-send-email-wd@denx.de>
On Wednesday 06 May 2009 22:15:13 Wolfgang Denk wrote:
> --- /dev/null
> +++ b/drivers/mtd/nand/mpc5121_nfc.c
>[...]
> +/* Init external chip select logic on ADS5121 board */
> +static int ads5121_chipselect_init(struct mtd_info *mtd)
> +{
> + struct nand_chip *chip = mtd->priv;
> + struct mpc5121_nfc_prv *prv = chip->priv;
> + struct device_node *dn;
> +
> + dn = of_find_compatible_node(NULL, NULL, "fsl,mpc5121ads-cpld");
> + if (dn) {
> + prv->csreg = of_iomap(dn, 0);
> + of_node_put(dn);
> + if (!prv->csreg)
> + return -ENOMEM;
> +
> + /* CPLD Register 9 controls NAND /CE Lines */
> + prv->csreg += 9;
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +
> +/* Control chips select signal on ADS5121 board */
> +static void ads5121_select_chip(struct mtd_info *mtd, int chip)
> +{
> + struct nand_chip *nand = mtd->priv;
> + struct mpc5121_nfc_prv *prv = nand->priv;
> + u8 v;
> +
> + v = in_8(prv->csreg);
> + v |= 0x0F;
> +
> + if (chip >= 0) {
> + mpc5121_nfc_select_chip(mtd, 0);
> + v &= ~(1 << chip);
> + } else
> + mpc5121_nfc_select_chip(mtd, -1);
> +
> + out_8(prv->csreg, v);
> +}
I am just a humble beginner, but isn't this platform dependend code supposed
to be in /arch/powerpc/platforms/.... ?
>[...]
> +static int __init mpc5121_nfc_probe(struct of_device *op,
> + const struct of_device_id *match)
> +{
> + struct device_node *rootnode, *dn = op->node;
> + struct device *dev = &op->dev;
> + struct mpc5121_nfc_prv *prv;
> + struct resource res;
> + struct mtd_info *mtd;
> +#ifdef CONFIG_MTD_PARTITIONS
> + struct mtd_partition *parts;
> +#endif
> + struct nand_chip *chip;
> + unsigned long regs_paddr, regs_size;
> + const uint *chips_no;
> + int resettime = 0;
> + int retval = 0;
> + int rev, len;
> +
> + /*
> + * Check SoC revision. This driver supports only NFC
> + * in MPC5121 revision 2.
> + */
> + rev = (mfspr(SPRN_SVR) >> 4) & 0xF;
> + if (rev != 2) {
> + printk(KERN_ERR DRV_NAME
> + ": SoC revision %u is not supported!\n", rev);
> + return -ENXIO;
> + }
> +
> + prv = devm_kzalloc(dev, sizeof(*prv), GFP_KERNEL);
> + if (!prv) {
> + printk(KERN_ERR DRV_NAME ": Memory exhausted!\n");
> + return -ENOMEM;
> + }
> +
> + mtd = &prv->mtd;
> + chip = &prv->chip;
> +
> + mtd->priv = chip;
> + chip->priv = prv;
> +
> + /* Read NFC configuration from Reset Config Word */
> + retval = mpc5121_nfc_read_hw_config(mtd);
> + if (retval) {
> + printk(KERN_ERR DRV_NAME ": Unable to read NFC config!\n");
> + return retval;
> + }
> +
> + prv->irq = irq_of_parse_and_map(dn, 0);
> + if (prv->irq == NO_IRQ) {
> + printk(KERN_ERR DRV_NAME ": Error mapping IRQ!\n");
> + return -EINVAL;
> + }
> +
> + retval = of_address_to_resource(dn, 0, &res);
> + if (retval) {
> + printk(KERN_ERR DRV_NAME ": Error parsing memory region!\n");
> + return retval;
> + }
> +
> + chips_no = of_get_property(dn, "chips", &len);
> + if (!chips_no || len != sizeof(*chips_no)) {
> + printk(KERN_ERR DRV_NAME ": Invalid/missing 'chips' "
> + "property!\n");
> + return -EINVAL;
> + }
> +
> + regs_paddr = res.start;
> + regs_size = res.end - res.start + 1;
> +
> + if (!devm_request_mem_region(dev, regs_paddr, regs_size, DRV_NAME)) {
> + printk(KERN_ERR DRV_NAME ": Error requesting memory region!\n");
> + return -EBUSY;
> + }
> +
> + prv->regs = devm_ioremap(dev, regs_paddr, regs_size);
> + if (!prv->regs) {
> + printk(KERN_ERR DRV_NAME ": Error mapping memory region!\n");
> + return -ENOMEM;
> + }
> +
> + mtd->name = "MPC5121 NAND";
> + chip->dev_ready = mpc5121_nfc_dev_ready;
> + chip->cmdfunc = mpc5121_nfc_command;
> + chip->read_byte = mpc5121_nfc_read_byte;
> + chip->read_word = mpc5121_nfc_read_word;
> + chip->read_buf = mpc5121_nfc_read_buf;
> + chip->write_buf = mpc5121_nfc_write_buf;
> + chip->verify_buf = mpc5121_nfc_verify_buf;
> + chip->select_chip = mpc5121_nfc_select_chip;
> + chip->options = NAND_NO_AUTOINCR | NAND_USE_FLASH_BBT;
> + chip->ecc.mode = NAND_ECC_SOFT;
> +
> + /* Support external chip-select logic on ADS5121 board */
> + rootnode = of_find_node_by_path("/");
> + if (of_device_is_compatible(rootnode, "fsl,mpc5121ads")) {
> + retval = ads5121_chipselect_init(mtd);
> + if (retval) {
> + printk(KERN_ERR DRV_NAME ": Chipselect init error!\n");
> + of_node_put(rootnode);
> + return retval;
> + }
> +
> + chip->select_chip = ads5121_select_chip;
> + }
Hmmm, I guess it would be overkill to build some sort of generic framework for
providing special chip-select functions here.... but it just doesn't look
clean like this.... oh well.
Best regards,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
From: Roland McGrath @ 2009-05-07 7:31 UTC (permalink / raw)
To: markus
Cc: linux-mips, Andrew Morton, x86, linux-kernel, linuxppc-dev,
sparclinux, Ingo Molnar, Linus Torvalds, stable
In-Reply-To: <904b25810905061446m73c42040nfff47c9b8950bcfa@mail.gmail.com>
> Ptrace has performance and/or reliability problems when used to
> sandbox threaded applications due to potential race conditions when
> inspecting system call arguments. We hope that we can avoid this
> problem with seccomp.
ptrace certainly has performance issues. I take it the only "reliability
problems" you are talking about are MT races with modifications to user
memory that is relevant to a system call. (Is there something else?)
That is not a "ptrace problem" per se at all. It's an intrinsic problem
with any method based on "generic" syscall interception, if the filtering
and enforcement decisions depend on examining user memory. By the same
token, no such method has a "reliability problem" if the filtering checks
only examine the registers (or other thread-synchronous state).
In the sense that I mean, seccomp is "generic syscall interception" too.
(That is, the checks/enforcement are "around" the call, rather than inside
it with direct atomicity controls binding the checks and uses together.)
The only reason seccomp does not have this "reliability problem" is that
its filtering is trivial and depends only on registers (in fact, only on
one register, the syscall number).
If you want to do checks that depend on shared or volatile state, then
syscall interception is really not the proper mechanism for you. (Likely
examples include user memory, e.g. for file names in open calls, or ioctl
struct contents, etc., fd tables or filesystem details, etc.) For that
you need mechanisms that look at stable kernel copies of user data that
are what the syscall will actually use, such as is done by audit, LSM, etc.
If you only have checks confined to thread-synchronous state such as the
user registers, then you don't have any "reliability problem" regardless
of the the particular syscall interception mechanism you use. (ptrace has
many problems for this or any other purpose, but this is not one of them.)
That's unless you are referring to some other "reliability problem" that
I'm not aware of. (And I'll leave aside the "is it registers or is it
user memory?" issue on ia64 as irrelevant, since, you know, it's ia64.)
If syscall interception is indeed an appropriate mechanism for your needs
and you want something tailored more specifically to your exact use in
future kernels, a module doing this would be easy to implement using the
utrace API. (That might be a "compelling use" of utrace by virtue of the
Midas brand name effect, if nothing else. ;-)
Thanks,
Roland
^ permalink raw reply
* Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
From: Roland McGrath @ 2009-05-07 7:30 UTC (permalink / raw)
To: markus
Cc: linux-mips, Andrew Morton, x86, linux-kernel, linuxppc-dev,
sparclinux, Ingo Molnar, Linus Torvalds, stable
In-Reply-To: <904b25810905061446m73c42040nfff47c9b8950bcfa@mail.gmail.com>
> Ptrace has performance and/or reliability problems when used to
> sandbox threaded applications due to potential race conditions when
> inspecting system call arguments. We hope that we can avoid this
> problem with seccomp.
ptrace certainly has performance issues. I take it the only "reliability
problems" you are talking about are MT races with modifications to user
memory that is relevant to a system call. (Is there something else?)
That is not a "ptrace problem" per se at all. It's an intrinsic problem
with any method based on "generic" syscall interception, if the filtering
and enforcement decisions depend on examining user memory. By the same
token, no such method has a "reliability problem" if the filtering checks
only examine the registers (or other thread-synchronous state).
In the sense that I mean, seccomp is "generic syscall interception" too.
(That is, the checks/enforcement are "around" the call, rather than inside
it with direct atomicity controls binding the checks and uses together.)
The only reason seccomp does not have this "reliability problem" is that
its filtering is trivial and depends only on registers (in fact, only on
one register, the syscall number).
If you want to do checks that depend on shared or volatile state, then
syscall interception is really not the proper mechanism for you. (Likely
examples include user memory, e.g. for file names in open calls, or ioctl
struct contents, etc., fd tables or filesystem details, etc.) For that
you need mechanisms that look at stable kernel copies of user data that
are what the syscall will actually use, such as is done by audit, LSM, etc.
If you only have checks confined to thread-synchronous state such as the
user registers, then you don't have any "reliability problem" regardless
of the the particular syscall interception mechanism you use. (ptrace has
many problems for this or any other purpose, but this is not one of them.)
That's unless you are referring to some other "reliability problem" that
I'm not aware of. (And I'll leave aside the "is it registers or is it
user memory?" issue on ia64 as irrelevant, since, you know, it's ia64.)
If syscall interception is indeed an appropriate mechanism for your needs
and you want something tailored more specifically to your exact use in
future kernels, a module doing this would be easy to implement using the
utrace API. (That might be a "compelling use" of utrace by virtue of the
Midas brand name effect, if nothing else. ;-)
Thanks,
Roland
^ permalink raw reply
* Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
From: Roland McGrath @ 2009-05-07 7:03 UTC (permalink / raw)
To: Markus Gutschke (顧孟勤)
Cc: linux-mips, Andrew Morton, x86, linux-kernel, linuxppc-dev,
sparclinux, Ingo Molnar, Linus Torvalds, stable
In-Reply-To: <904b25810905061446m73c42040nfff47c9b8950bcfa@mail.gmail.com>
> Ptrace has performance and/or reliability problems when used to
> sandbox threaded applications due to potential race conditions when
> inspecting system call arguments. We hope that we can avoid this
> problem with seccomp.
ptrace certainly has performance issues. I take it the only "reliability
problems" you are talking about are MT races with modifications to user
memory that is relevant to a system call. (Is there something else?)
That is not a "ptrace problem" per se at all. It's an intrinsic problem
with any method based on "generic" syscall interception, if the filtering
and enforcement decisions depend on examining user memory. By the same
token, no such method has a "reliability problem" if the filtering checks
only examine the registers (or other thread-synchronous state).
In the sense that I mean, seccomp is "generic syscall interception" too.
(That is, the checks/enforcement are "around" the call, rather than inside
it with direct atomicity controls binding the checks and uses together.)
The only reason seccomp does not have this "reliability problem" is that
its filtering is trivial and depends only on registers (in fact, only on
one register, the syscall number).
If you want to do checks that depend on shared or volatile state, then
syscall interception is really not the proper mechanism for you. (Likely
examples include user memory, e.g. for file names in open calls, or ioctl
struct contents, etc., fd tables or filesystem details, etc.) For that
you need mechanisms that look at stable kernel copies of user data that
are what the syscall will actually use, such as is done by audit, LSM, etc.
If you only have checks confined to thread-synchronous state such as the
user registers, then you don't have any "reliability problem" regardless
of the the particular syscall interception mechanism you use. (ptrace has
many problems for this or any other purpose, but this is not one of them.)
That's unless you are referring to some other "reliability problem" that
I'm not aware of. (And I'll leave aside the "is it registers or is it
user memory?" issue on ia64 as irrelevant, since, you know, it's ia64.)
If syscall interception is indeed an appropriate mechanism for your needs
and you want something tailored more specifically to your exact use in
future kernels, a module doing this would be easy to implement using the
utrace API. (That might be a "compelling use" of utrace by virtue of the
Midas brand name effect, if nothing else. ;-)
Thanks,
Roland
^ permalink raw reply
* Re: [PATCH 09/12] mpc5121ads: Added I2C RTC node to mpc5121ads DTS.
From: Wolfgang Grandegger @ 2009-05-07 6:45 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Piotr Ziecik
In-Reply-To: <1241640919-4650-10-git-send-email-wd@denx.de>
Wolfgang Denk wrote:
> From: Piotr Ziecik <kosmo@semihalf.com>
>
> Signed-off-by: Piotr Ziecik <kosmo@semihalf.com>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: John Rigby <jcrigby@gmail.com>
> ---
> arch/powerpc/boot/dts/mpc5121ads.dts | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts b/arch/powerpc/boot/dts/mpc5121ads.dts
> index 93fe12a..c2d9de9 100644
> --- a/arch/powerpc/boot/dts/mpc5121ads.dts
> +++ b/arch/powerpc/boot/dts/mpc5121ads.dts
> @@ -210,6 +210,11 @@
> interrupts = <9 0x8>;
> interrupt-parent = < &ipic >;
> fsl5200-clocking;
The above line is obsolete since -rc4. Please check the revised bindings
in Documentation/powerpc/dts-bindings/fsl/i2c.txt. You may even want:
clock-frequency = <100000>;
Wolfgang.
^ permalink raw reply
* Re: [PATCH 08/12] mpc5121: Added I2C support.
From: Wolfgang Grandegger @ 2009-05-07 6:36 UTC (permalink / raw)
To: Grant Likely
Cc: linux-i2c, linuxppc-dev, Wolfgang Denk, Detlev Zundel,
Piotr Ziecik
In-Reply-To: <fa686aa40905061941p6fd4b03dt1097cf4d16bdd665@mail.gmail.com>
Grant Likely wrote:
> On Wed, May 6, 2009 at 4:51 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
>> On Wed, May 6, 2009 at 4:19 PM, Wolfgang Denk <wd@denx.de> wrote:
>>> Dear Grant Likely,
>>>
>>> In message <fa686aa40905061401k319313c5q89fd3e245c30808f@mail.gmail.com> you wrote:
>>>> On Wed, May 6, 2009 at 2:15 PM, Wolfgang Denk <wd@denx.de> wrote:
>>>>> From: Piotr Ziecik <kosmo@semihalf.com>
>>>>>
>>>>> - Enabled I2C interrupts on MPC5121.
>>>>> - Updated Kconfig for i2c-mpc driver.
>>>> I think this workaround belongs in the driver itself.
>>> Sorry, I don't get it. Which workaround? What exactly should I change?
>> Sorry, I misread the patch. Never mind.
>
> Actually, on 3rd reading, I think my first impression was correct
> (even if I was wrong about it being a workaround). This code in
> mpc512x_init_i2c() is only relevant for i2c busses (it isn't shared
> with any other drivers). Therefore, it belongs with the i2c bus
> itself. It does not belong in platform code.
Right. Furthermore, the i2c-mpc.c should be extened to support bus speed
setting for the MPC512x, which has been merged recently (see commit id
f2bd5efe).
Wolfgang.
^ permalink raw reply
* Re: Trouble using with Kegel cross tool chain
From: Chris Plasun @ 2009-05-07 6:07 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <407093.53240.qm@web58102.mail.re3.yahoo.com>
Wow guys, thank you for all the responses. Looks like this mad dive into
embedded Linux programming from ASP.NET is not futile.
I will take a look at the responses and reply tomorrow.
Chris Plasun
^ permalink raw reply
* Re: [PATCH] powerpc: Fix oprofile sampling of marked events on POWER7
From: Stephen Rothwell @ 2009-05-07 6:11 UTC (permalink / raw)
To: mjw; +Cc: linuxppc-dev
In-Reply-To: <1241641546.7044.20.camel@mx3>
[-- Attachment #1: Type: text/plain, Size: 442 bytes --]
Hi Mike,
Just a couple of meta things:
On Wed, 06 May 2009 15:25:46 -0500 Mike Wolf <mjw@linux.vnet.ibm.com> wrote:
>
> From Maynard Johnson <maynardj@us.ibm.com>
This would normally be "From:"
> Signed-off-by: Michael Wolf <mjw@linux.vnet.ibm.com>
It would be good if you had a Signed-off-by from Maynard as well.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Trouble using with Kegel cross tool chain
From: Wolfgang Denk @ 2009-05-07 5:32 UTC (permalink / raw)
To: Chris Plasun; +Cc: linuxppc-dev
In-Reply-To: <407093.53240.qm@web58102.mail.re3.yahoo.com>
Dear Chris,
In message <407093.53240.qm@web58102.mail.re3.yahoo.com> you wrote:
>
> I'm getting a bit desperate trying to build a gcc / glibc cross-toolchainfor
> use on a Freescale MPC8313 but am having problems.
Try using ELDK (see http://www.denx.de/wiki/view/DULG/ELDK resp.
ftp://ftp.denx.de/pub/eldk/4.2/); it's based on crosstool but has
these issues already solved for you.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
There are bugs and then there are bugs. And then there are bugs.
- Karl Lehenbauer
^ permalink raw reply
* Re: Trouble using with Kegel cross tool chain
From: Michael Neuling @ 2009-05-07 4:50 UTC (permalink / raw)
To: Chris Plasun; +Cc: linuxppc-dev
In-Reply-To: <407093.53240.qm@web58102.mail.re3.yahoo.com>
In message <407093.53240.qm@web58102.mail.re3.yahoo.com> you wrote:
>
> Hi,
>
> I'm getting a bit desperate trying to build a gcc / glibc cross-toolchainfor
> use on a Freescale MPC8313 but am having problems.
>
> I follow the Quick Start instructions at
> http://www.kegel.com/crosstool/crosstool-0.43/doc/crosstool-howto.html and
> run demo-powerpc-603.sh (is that the correct script for the MPC8313?)
>
> I check the /opt/crosstool directory and there is nothing there.
>
> Below are the results of running the above script:
>
> =================
>
> linux-66oa:~/work/crosstool-0.43 # sh demo-powerpc-603.sh
> + TARBALLS_DIR=/root/downloads
> + RESULT_TOP=/opt/crosstool
> + export TARBALLS_DIR RESULT_TOP
> + GCC_LANGUAGES=c,c++
> + export GCC_LANGUAGES
> + mkdir -p /opt/crosstool
> ++ cat powerpc-603.dat gcc-4.1.0-glibc-2.3.6-tls.dat
> +
> eval TARGET=powerpc-603-linux-gnu 'TARGET_CFLAGS="-O' '-mcpu=603"'
> 'GCC_EXTRA_CONFIG="--with-cpu=603' '--enable-cxx-flags=-mcpu=603"'
> BINUTILS_DIR=binutils-2.16.1 GCC_CORE_DIR=gcc-3.3.6 GCC_DIR=gcc-4.1.0
> GLIBC_DIR=glibc-2.3.6 LINUX_DIR=linux-2.6.15.4 LINUX_SANITIZED_HEADER_DIR=lin
ux-libc-headers-2.6.12.0
> GLIBCTHREADS_FILENAME=glibc-linuxthreads-2.3.6 GDB_DIR=gdb-6.5
> 'GLIBC_EXTRA_CONFIG="$GLIBC_EXTRA_CONFIG' --with-tls --with-__thread
> '--enable-kernel=2.4.18"' sh all.sh --notest
> ++ TARGET=powerpc-603-linux-gnu
> ++ TARGET_CFLAGS='-O -mcpu=603'
> ++ GCC_EXTRA_CONFIG='--with-cpu=603 --enable-cxx-flags=-mcpu=603'
> ++ BINUTILS_DIR=binutils-2.16.1
> ++ GCC_CORE_DIR=gcc-3.3.6
> ++ GCC_DIR=gcc-4.1.0
> ++ GLIBC_DIR=glibc-2.3.6
> ++ LINUX_DIR=linux-2.6.15.4
> ++ LINUX_SANITIZED_HEADER_DIR=linux-libc-headers-2.6.12.0
> ++ GLIBCTHREADS_FILENAME=glibc-linuxthreads-2.3.6
> ++ GDB_DIR=gdb-6.5
> ++ GLIBC_EXTRA_CONFIG=' --with-tls --with-__thread --enable-kernel=2.4.18'
> ++ sh all.sh --notest
> You set both LINUX_DIR and LINUX_SANITIZED_HEADER_DIR - ignoring LINUX_DIR fo
r the build
> DEJAGNU not set, so not running any regression tests
> GLIBC_ADDON_OPTIONS not set, so building all glibc add-on's
> KERNELCONFIG not set, so not configuring linux kernel
> + TOOLCOMBO=gcc-4.1.0-glibc-2.3.6
> ++ pwd
> + BUILD_DIR=/root/work/crosstool-0.43/build/powerpc-603-linux-gnu/gcc-4.1.0-g
libc-2.3.6
> ++ pwd
> + TOP_DIR=/root/work/crosstool-0.43
> + test -z ''
> + SRC_DIR=/root/work/crosstool-0.43/build/powerpc-603-linux-gnu/gcc-4.1.0-gli
bc-2.3.6
> + echo 'SRC_DIR not set, so source tarballs will be unpacked in the build dir
ectory'
> SRC_DIR not set, so source tarballs will be unpacked in the build directory
> + case x$PREFIX in
> + case x$USER in
> + abort 'Don'\''t run all.sh or crosstool.sh as root, it'\''s dangerous'
> + echo 'Don'\''t' run all.sh or crosstool.sh as root, 'it'\''s' dangerous
> Don't run all.sh or crosstool.sh as root, it's dangerous
> + exec false
Are you running as root? If so, don't.
Mikey
>
> =================
>
> The point of this exercise is to build a compiler to build Mono so that
> I can run .NET programs on the MPC8313.
>
> I would really appreciate any help.
>
> Thanks,
> Chris Plasun
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
From: Nicholas Miell @ 2009-05-07 4:23 UTC (permalink / raw)
To: Markus Gutschke (顧孟勤)
Cc: linux-mips, x86, linux-kernel, stable, linuxppc-dev, sparclinux,
Ingo Molnar, Linus Torvalds, Andrew Morton, Roland McGrath
In-Reply-To: <904b25810905061521v62b3ddd6l14deb614d203385a@mail.gmail.com>
On Wed, 2009-05-06 at 15:21 -0700, Markus Gutschke (顧孟勤) wrote:
> On Wed, May 6, 2009 at 15:13, Ingo Molnar <mingo@elte.hu> wrote:
> > doing a (per arch) bitmap of harmless syscalls and replacing the
> > mode1_syscalls[] check with that in kernel/seccomp.c would be a
> > pretty reasonable extension. (.config controllable perhaps, for
> > old-style-seccomp)
> >
> > It would probably be faster than the current loop over
> > mode1_syscalls[] as well.
>
> This would be a great option to improve performance of our sandbox. I
> can detect the availability of the new kernel API dynamically, and
> then not intercept the bulk of the system calls. This would allow the
> sandbox to work both with existing and with newer kernels.
>
> We'll post a kernel patch for discussion in the next few days,
>
I suspect the correct thing to do would be to leave seccomp mode 1 alone
and introduce a mode 2 with a less restricted set of system calls -- the
interface was designed to be extended in this way, after all.
--
Nicholas Miell <nmiell@comcast.net>
^ permalink raw reply
* Trouble using with Kegel cross tool chain
From: Chris Plasun @ 2009-05-07 2:50 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm getting a bit desperate trying to build a gcc / glibc cross-toolchainfor
use on a Freescale MPC8313 but am having problems.
I follow the Quick Start instructions at
http://www.kegel.com/crosstool/crosstool-0.43/doc/crosstool-howto.html and
run demo-powerpc-603.sh (is that the correct script for the MPC8313?)
I check the /opt/crosstool directory and there is nothing there.
Below are the results of running the above script:
=================
linux-66oa:~/work/crosstool-0.43 # sh demo-powerpc-603.sh
+ TARBALLS_DIR=/root/downloads
+ RESULT_TOP=/opt/crosstool
+ export TARBALLS_DIR RESULT_TOP
+ GCC_LANGUAGES=c,c++
+ export GCC_LANGUAGES
+ mkdir -p /opt/crosstool
++ cat powerpc-603.dat gcc-4.1.0-glibc-2.3.6-tls.dat
+
eval TARGET=powerpc-603-linux-gnu 'TARGET_CFLAGS="-O' '-mcpu=603"'
'GCC_EXTRA_CONFIG="--with-cpu=603' '--enable-cxx-flags=-mcpu=603"'
BINUTILS_DIR=binutils-2.16.1 GCC_CORE_DIR=gcc-3.3.6 GCC_DIR=gcc-4.1.0
GLIBC_DIR=glibc-2.3.6 LINUX_DIR=linux-2.6.15.4 LINUX_SANITIZED_HEADER_DIR=linux-libc-headers-2.6.12.0
GLIBCTHREADS_FILENAME=glibc-linuxthreads-2.3.6 GDB_DIR=gdb-6.5
'GLIBC_EXTRA_CONFIG="$GLIBC_EXTRA_CONFIG' --with-tls --with-__thread
'--enable-kernel=2.4.18"' sh all.sh --notest
++ TARGET=powerpc-603-linux-gnu
++ TARGET_CFLAGS='-O -mcpu=603'
++ GCC_EXTRA_CONFIG='--with-cpu=603 --enable-cxx-flags=-mcpu=603'
++ BINUTILS_DIR=binutils-2.16.1
++ GCC_CORE_DIR=gcc-3.3.6
++ GCC_DIR=gcc-4.1.0
++ GLIBC_DIR=glibc-2.3.6
++ LINUX_DIR=linux-2.6.15.4
++ LINUX_SANITIZED_HEADER_DIR=linux-libc-headers-2.6.12.0
++ GLIBCTHREADS_FILENAME=glibc-linuxthreads-2.3.6
++ GDB_DIR=gdb-6.5
++ GLIBC_EXTRA_CONFIG=' --with-tls --with-__thread --enable-kernel=2.4.18'
++ sh all.sh --notest
You set both LINUX_DIR and LINUX_SANITIZED_HEADER_DIR - ignoring LINUX_DIR for the build
DEJAGNU not set, so not running any regression tests
GLIBC_ADDON_OPTIONS not set, so building all glibc add-on's
KERNELCONFIG not set, so not configuring linux kernel
+ TOOLCOMBO=gcc-4.1.0-glibc-2.3.6
++ pwd
+ BUILD_DIR=/root/work/crosstool-0.43/build/powerpc-603-linux-gnu/gcc-4.1.0-glibc-2.3.6
++ pwd
+ TOP_DIR=/root/work/crosstool-0.43
+ test -z ''
+ SRC_DIR=/root/work/crosstool-0.43/build/powerpc-603-linux-gnu/gcc-4.1.0-glibc-2.3.6
+ echo 'SRC_DIR not set, so source tarballs will be unpacked in the build directory'
SRC_DIR not set, so source tarballs will be unpacked in the build directory
+ case x$PREFIX in
+ case x$USER in
+ abort 'Don'\''t run all.sh or crosstool.sh as root, it'\''s dangerous'
+ echo 'Don'\''t' run all.sh or crosstool.sh as root, 'it'\''s' dangerous
Don't run all.sh or crosstool.sh as root, it's dangerous
+ exec false
=================
The point of this exercise is to build a compiler to build Mono so that
I can run .NET programs on the MPC8313.
I would really appreciate any help.
Thanks,
Chris Plasun
^ permalink raw reply
* Re: [PATCH 08/12] mpc5121: Added I2C support.
From: Grant Likely @ 2009-05-07 2:41 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Piotr Ziecik, Detlev Zundel, linux-i2c
In-Reply-To: <fa686aa40905061551l8cf5940sf4d4cbf34331cf9a@mail.gmail.com>
On Wed, May 6, 2009 at 4:51 PM, Grant Likely <grant.likely@secretlab.ca> wr=
ote:
> On Wed, May 6, 2009 at 4:19 PM, Wolfgang Denk <wd@denx.de> wrote:
>> Dear Grant Likely,
>>
>> In message <fa686aa40905061401k319313c5q89fd3e245c30808f@mail.gmail.com>=
you wrote:
>>> On Wed, May 6, 2009 at 2:15 PM, Wolfgang Denk <wd@denx.de> wrote:
>>> > From: Piotr Ziecik <kosmo@semihalf.com>
>>> >
>>> > - Enabled I2C interrupts on MPC5121.
>>> > - Updated Kconfig for i2c-mpc driver.
>>>
>>> I think this workaround belongs in the driver itself.
>>
>> Sorry, I don't get it. Which workaround? What exactly should I change?
>
> Sorry, I misread the patch. =A0Never mind.
Actually, on 3rd reading, I think my first impression was correct
(even if I was wrong about it being a workaround). This code in
mpc512x_init_i2c() is only relevant for i2c busses (it isn't shared
with any other drivers). Therefore, it belongs with the i2c bus
itself. It does not belong in platform code.
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: MPC8349E's DMA controller like ISA controller but with more feature?
From: lhthanh @ 2009-05-07 1:59 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <49F1CF7B.2080703@freescale.com>
lhthanh wrote:
>
>> Thanks for your explaination! So if I want to transfer a buffer of data
>> from a single I/O port, will not DMA framework
>> also be able ?
>>
>
> No.
>
>
>> Have I to write aother driver?
>>
>
> Yes.
>
>
>> Actually, I don't want write all because there are serveral DMA code at
>> hand. I only want to use a framework instead of re-writing.
>>
>
> There is no framework for what you want to do. There is only one other
> driver that does what you want (sound/soc/fsl/fsl_dma.c), and that is a
> complicated driver that does many things besides transferring data to an
> I/O port.
>
>
>> And I afraid that I can not write code which assure sharing DMA channels.
>>
>
> Look at arch/powerpc/boot/dts/mpc8610_hpcd.dts. The DMA channels that
> are needed by the 8610 audio driver have a different 'compatible'
> property. This is how you prevent the generic DMA driver from using a
> channel that you want.
>
> I'm afraid that you're going to have to study the DMA programming model,
> and my device driver, and write a brand new driver from scratch.
>
>
Thank Scott and Timur very much! I will study more DMA driver and come
back later. :)
Regard!
^ permalink raw reply
* Re: [PATCH] powerpc/pci: clean up direct access to sysdata by iseries platform
From: Stephen Rothwell @ 2009-05-07 0:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <20090506231338.ea3e280d.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]
Hi Kumar,
On Wed, 6 May 2009 23:13:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Tue, 5 May 2009 07:04:55 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
> >
> > We shouldn't directly access sysdata to get the device node. We should
> > be calling pci_device_to_OF_node().
> >
> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> It looks ok, but all I can say for now is that it doesn not make things
> worse. During 2.6.28, the iSeries PCI code was broken. I am working on
> a fix and after that I will be able to properly test this patch.
With my fix for the old PCI breakage, I have tested your "pci" tree for
iseries_defconfig. Built and booted with and without CONFIG_PCI.
Tested-by: Stephen Rothwell <sfr@canb.auug.og.au>
Acked-by: Stephen Rothwell <sfr@canb.auug.og.au>
My patch, however, will probably need your attention once Ben takes
it. :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] powerpc/iseries; fix pci breakage
From: Stephen Rothwell @ 2009-05-07 0:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras; +Cc: ppc-dev, Becky Bruce
Commit 4fc665b88a79a45bae8bbf3a05563c27c7337c3d "powerpc: Merge 32 and
64-bit dma code" made changes to the PCI initialisation code that added
an assignment to archdata.dma_data but only for 32 bit code. Commit
7eef440a545c7f812ed10b49d4a10a351df9cad6 "powerpc/pci: Cosmetic cleanups
of pci-common.c" removed the conditional compilation. Unfortunately,
the iSeries code setup the archdata.dma_data before that assignment was
done - effectively overwriting the dma_data with NULL.
Fix this up by moving the iSeries setup of dma_data into a
pci_dma_dev_setup callback.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/include/asm/iseries/iommu.h | 4 ----
arch/powerpc/platforms/iseries/iommu.c | 6 +++++-
arch/powerpc/platforms/iseries/pci.c | 1 -
3 files changed, 5 insertions(+), 6 deletions(-)
Built and booted iseries_defconfig with and without CONFIG_PCI.
This is a regression in v2.6.29 from v2.6.28, so I guess we need to send this to the stable team (backported if necessary) after it is upstream.
diff --git a/arch/powerpc/include/asm/iseries/iommu.h b/arch/powerpc/include/asm/iseries/iommu.h
index c59ee7e..1b9692c 100644
--- a/arch/powerpc/include/asm/iseries/iommu.h
+++ b/arch/powerpc/include/asm/iseries/iommu.h
@@ -26,10 +26,6 @@ struct vio_dev;
struct device_node;
struct iommu_table;
-/* Creates table for an individual device node */
-extern void iommu_devnode_init_iSeries(struct pci_dev *pdev,
- struct device_node *dn);
-
/* Get table parameters from HV */
extern void iommu_table_getparms_iSeries(unsigned long busno,
unsigned char slotno, unsigned char virtbus,
diff --git a/arch/powerpc/platforms/iseries/iommu.c b/arch/powerpc/platforms/iseries/iommu.c
index ff43f1f..4021982 100644
--- a/arch/powerpc/platforms/iseries/iommu.c
+++ b/arch/powerpc/platforms/iseries/iommu.c
@@ -174,9 +174,10 @@ static struct iommu_table *iommu_table_find(struct iommu_table * tbl)
}
-void iommu_devnode_init_iSeries(struct pci_dev *pdev, struct device_node *dn)
+static void pci_dma_dev_setup_iseries(struct pci_dev *pdev)
{
struct iommu_table *tbl;
+ struct device_node *dn = pdev->sysdata;
struct pci_dn *pdn = PCI_DN(dn);
const u32 *lsn = of_get_property(dn, "linux,logical-slot-number", NULL);
@@ -194,6 +195,8 @@ void iommu_devnode_init_iSeries(struct pci_dev *pdev, struct device_node *dn)
kfree(tbl);
pdev->dev.archdata.dma_data = pdn->iommu_table;
}
+#else
+#define pci_dma_dev_setup_iseries NULL
#endif
static struct iommu_table veth_iommu_table;
@@ -251,5 +254,6 @@ void iommu_init_early_iSeries(void)
ppc_md.tce_build = tce_build_iSeries;
ppc_md.tce_free = tce_free_iSeries;
+ ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_iseries;
set_pci_dma_ops(&dma_iommu_ops);
}
diff --git a/arch/powerpc/platforms/iseries/pci.c b/arch/powerpc/platforms/iseries/pci.c
index 02a634f..21cddc3 100644
--- a/arch/powerpc/platforms/iseries/pci.c
+++ b/arch/powerpc/platforms/iseries/pci.c
@@ -444,7 +444,6 @@ void __init iSeries_pcibios_fixup_resources(struct pci_dev *pdev)
pdev->sysdata = node;
allocate_device_bars(pdev);
iseries_device_information(pdev, bus, *sub_bus);
- iommu_devnode_init_iSeries(pdev, node);
}
/*
--
1.6.2.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* RE: Unable to boot 2.6.29 (and tot kernel) with 256k page size on katmai.
From: Shubhada Pugaonkar @ 2009-05-06 22:53 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
I am using ELDK4.2 that came with the katmai board.=20
Yes that is all I get. If I use 64k page size then I get following log
if that helps determine anything.=20
=3D> tftp 1000000 uImage-2.6.29-denx
Waiting for PHY auto negotiation to complete.. done
ENET Speed is 100 Mbps - FULL duplex connection (EMAC0)
Using ppc_4xx_eth0 device
TFTP from server 10.192.165.106; our IP address is 10.192.164.166
Filename 'uImage-2.6.29-denx'.
Load address: 0x1000000
Loading:
#################################################################
############################################################
done
Bytes transferred =3D 1822193 (1bcdf1 hex)
=3D> tftp 4000000 katmai.dts.256k
Using ppc_4xx_eth0 device
TFTP from server 10.192.165.106; our IP address is 10.192.164.166
Filename 'katmai.dts.256k'.
Load address: 0x4000000
Loading: ##
done
Bytes transferred =3D 16384 (4000 hex)
=3D> bootm 1000000 - 4000000
## Booting image at 01000000 ...
Image Name: Linux-2.6.29-rc8-01447-g3bf8ce5-
Created: 2009-05-06 0:34:46 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1822129 Bytes =3D 1.7 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0x4000000
Loading Device Tree to 007fb000, end 007fefff ... OK
Using PowerPC 44x Platform machine description
Linux version 2.6.29-rc8-01447-g3bf8ce5-dirty (root@california) (gcc
version 4.2.2) #2 Tue May 5 17:34:41 PDT 2009
console [udbg0] enabled
setup_arch: bootmem
arch: exit
Zone PFN ranges:
DMA 0x00000000 -> 0x00003000
Normal 0x00003000 -> 0x00003000
HighMem 0x00003000 -> 0x00008000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00008000
MMU: Allocated 1088 bytes of context maps for 255 contexts
Built 1 zonelists in Zone order, mobility grouping on. Total pages:
32752
Kernel command line:
UIC0 (32 IRQ sources) at DCR 0xc0
UIC1 (32 IRQ sources) at DCR 0xd0
UIC2 (32 IRQ sources) at DCR 0xe0
UIC3 (32 IRQ sources) at DCR 0xf0
PID hash table entries: 4096 (order: 12, 16384 bytes)
clocksource: timebase mult[500000] shift[22] registered
Dentry cache hash table entries: 131072 (order: 3, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 2, 262144 bytes)
Memory: 2089472k/2097152k available (3776k kernel code, 7040k reserved,
192k data, 736k bss, 384k init)
SLUB: Genslabs=3D14, HWalign=3D32, Order=3D0-3, MinObjects=3D0, =
CPUs=3D1, Nodes=3D1
Calibrating delay loop... 1597.44 BogoMIPS (lpj=3D3194880)
Mount-cache hash table entries: 8192
net_namespace: 296 bytes
xor: measuring software checksum speed
8regs : 112.000 MB/sec
8regs_prefetch: 144.000 MB/sec
32regs : 112.000 MB/sec
32regs_prefetch: 144.000 MB/sec
xor: using function: 32regs_prefetch (144.000 MB/sec)
NET: Registered protocol family 16
PCIE0: Checking link...
PCIE0: Device detected, waiting for link...
PCIE0: link is up !
PCI host bridge /plb/pciex@d00000000 (primary) ranges:
MEM 0x0000000e00000000..0x0000000e7fffffff -> 0x0000000080000000
IO 0x0000000f80000000..0x0000000f8000ffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCIE0: successfully set as root-complex
PCIE1: Checking link...
PCIE1: Device detected, waiting for link...
PCIE1: link is up !
PCI host bridge /plb/pciex@d20000000 (primary) ranges:
MEM 0x0000000e80000000..0x0000000effffffff -> 0x0000000080000000
IO 0x0000000f80010000..0x0000000f8001ffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCIE1: successfully set as root-complex
PCIE2: Checking link...
PCIE2: Device detected, waiting for link...
PCIE2: link is up !
PCI host bridge /plb/pciex@d40000000 (primary) ranges:
MEM 0x0000000f00000000..0x0000000f7fffffff -> 0x0000000080000000
IO 0x0000000f80020000..0x0000000f8002ffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCIE2: successfully set as root-complex
PCI host bridge /plb/pci@c0ec00000 (primary) ranges:
MEM 0x0000000d80000000..0x0000000dffffffff -> 0x0000000080000000
IO 0x0000000c08000000..0x0000000c0800ffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCI: Probing PCI hardware
PCI: Hiding 4xx host bridge resources 0000:10:00.0
pci 0000:11:00.0: PME# supported from D0 D3hot
pci 0000:11:00.0: PME# disabled
PCI: Hiding 4xx host bridge resources 0001:20:00.0
PCI: Hiding 4xx host bridge resources 0002:30:00.0
pci 0000:10:00.0: PCI bridge, secondary bus 0000:11
pci 0000:10:00.0: IO window: disabled
pci 0000:10:00.0: MEM window: 0x80000000-0x80bfffff
pci 0000:10:00.0: PREFETCH window: 0x00000080c00000-0x00000080cfffff
pci 0001:20:00.0: PCI bridge, secondary bus 0001:21
pci 0001:20:00.0: IO window: 0x1000-0x1fff
pci 0001:20:00.0: MEM window: 0x80200000-0x802fffff
pci 0001:20:00.0: PREFETCH window: 0x00000080000000-0x000000801fffff
pci 0002:30:00.0: PCI bridge, secondary bus 0002:31
pci 0002:30:00.0: IO window: 0x1000-0x1fff
pci 0002:30:00.0: MEM window: 0x80200000-0x802fffff
pci 0002:30:00.0: PREFETCH window: 0x00000080000000-0x000000801fffff
bio: create slab <bio-0> at 0
SCSI subsystem initialized
NET: Registered protocol family 2
Switched to NOHz mode on CPU #0
IP route cache hash table entries: 16384 (order: 0, 65536 bytes)
TCP established hash table entries: 32768 (order: 2, 262144 bytes)
TCP bind hash table entries: 32768 (order: 1, 131072 bytes)
TCP: Hash tables configured (established 32768 bind 32768)
TCP reno registered
NET: Registered protocol family 1
highmem bounce pool size: 64 pages
msgmni has been set to 1520
alg: No test for stdrng (krng)
async_tx: api initialized (sync-only)
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x4f0000200 (irq =3D 21) is a 16550A
console
handover: boot [udbg0] -> real [ttyS0]
serial8250.0: ttyS1 at MMIO 0x4f0000300 (irq =3D 22) is a 16550A
serial8250.0: ttyS2 at MMIO 0x4f0000600 (irq =3D 23) is a 16550A
4f0000200.serial: ttyS0 at MMIO 0x4f0000200 (irq =3D 21) is a 16550A
4f0000300.serial: ttyS1 at MMIO 0x4f0000300 (irq =3D 22) is a 16550A
4f0000600.serial: ttyS2 at MMIO 0x4f0000600 (irq =3D 23) is a 16550A
brd: module loaded
Xilinx SystemACE device driver, major=3D253
PPC 4xx OCP EMAC driver, version 3.54
MAL v2 /plb/mcmal, 2 TX channels, 1 RX channels
eth0 (emac): not using net_device_ops yet
eth0: EMAC-0 /plb/opb/ethernet@10000800, MAC 00:01:73:77:56:64
eth0: found Generic MII PHY (0x01)
Driver 'sd' needs updating - please use bus_type methods
Fusion MPT base driver 3.04.07
Copyright (c) 1999-2008 LSI Corporation
Fusion MPT SAS Host driver 3.04.07
mptsas 0001:21:00.0: enabling device (0000 -> 0002)
mptbase: ioc0: Initiating bringup
ioc0: LSISAS1068E B3: Capabilities=3D{Initiator}
scsi0 : ioc0: LSISAS1068E B3, FwRev=3D01170200h, Ports=3D1, MaxQ=3D286, =
IRQ=3D19
scsi 0:0:0:0: Direct-Access SEAGATE ST336754SS S410 PQ: 0
ANSI: 5
sd 0:0:0:0: [sda] 71132959 512-byte hardware sectors: (36.4 GB/33.9 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports
DPO and FUA
sd 0:0:0:0: [sda] 71132959 512-byte hardware sectors: (36.4 GB/33.9 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports
DPO and FUA
sda: sda1
.
.
.
=20
Thanks
Shubhada
-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]=20
Sent: Wednesday, May 06, 2009 3:34 PM
To: Shubhada Pugaonkar
Cc: linuxppc-dev@ozlabs.org
Subject: Re: Unable to boot 2.6.29 (and tot kernel) with 256k page size
on katmai.
Dear Shubhada,
In message
<8A71B368A89016469F72CD08050AD33402D575FA@maui.asicdesigners.com> you
wrote:
>=20
> I am unable to boot the 2.6.29-rc8 denx kernel (and 2.6.30-rc4 tot
> kernel) when I enable the 256k page size. My config file is attached.
> The *same* config works fine with 64k page size. I have 2GB memory on
> this board.=20
Which root file system are you using?
> ## Booting image at 01000000 ...
> Image Name: Linux-2.6.29-rc8-01447-g3bf8ce5-
> Created: 2009-05-05 0:31:36 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 2138773 Bytes =3D 2 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Booting using the fdt at 0x4000000
> Loading Device Tree to 007fb000, end 007fefff ... OK
Is this all you get? Nothing else?
Best regards,
Wolfgang Denk
--=20
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Nobody will ever need more than 640k RAM!" -- Bill Gates, 1981
"Windows 95 needs at least 8 MB RAM." -- Bill Gates, 1996
"Nobody will ever need Windows 95." -- logical conclusion
^ permalink raw reply
* Re: [PATCH 08/12] mpc5121: Added I2C support.
From: Grant Likely @ 2009-05-06 22:51 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Piotr Ziecik, Detlev Zundel, linux-i2c
In-Reply-To: <20090506221908.3927583420E8@gemini.denx.de>
On Wed, May 6, 2009 at 4:19 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Grant Likely,
>
> In message <fa686aa40905061401k319313c5q89fd3e245c30808f@mail.gmail.com> you wrote:
>> On Wed, May 6, 2009 at 2:15 PM, Wolfgang Denk <wd@denx.de> wrote:
>> > From: Piotr Ziecik <kosmo@semihalf.com>
>> >
>> > - Enabled I2C interrupts on MPC5121.
>> > - Updated Kconfig for i2c-mpc driver.
>>
>> I think this workaround belongs in the driver itself.
>
> Sorry, I don't get it. Which workaround? What exactly should I change?
Sorry, I misread the patch. Never mind.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 12/12] mpc5121: Added default config for MPC5121.
From: Grant Likely @ 2009-05-06 22:48 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Piotr Ziecik
In-Reply-To: <20090506222351.C0C8183420E8@gemini.denx.de>
On Wed, May 6, 2009 at 4:23 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Grant Likely,
>
> In message <fa686aa40905061408s3360b774y756262e3e15d17bd@mail.gmail.com> you wrote:
>>
>> Wait till about -rc2 time to do defconfig patches.
>
> Would it offend you if I continue to include these (and you have to
> ignore them)? Posting a "complete" patch set that includs a defconfig
> allows users much easier testing...
Yes, that's fine. My preference is if they appear at the end of the series.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 05/12] mpc5121ads: Added Reset Module node to DTS.
From: Grant Likely @ 2009-05-06 22:46 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Piotr Ziecik, Detlev Zundel
In-Reply-To: <20090506221648.E98A683420E8@gemini.denx.de>
On Wed, May 6, 2009 at 4:16 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Grant Likely,
>
> In message <fa686aa40905061340s212385b1r8be4e2f7505bd0a0@mail.gmail.com> =
you wrote:
>> On Wed, May 6, 2009 at 2:15 PM, Wolfgang Denk <wd@denx.de> wrote:
>> > From: Piotr Ziecik <kosmo@semihalf.com>
>> >
>> > Signed-off-by: Piotr Ziecik <kosmo@semihalf.com>
>> > Signed-off-by: Wolfgang Denk <wd@denx.de>
>> > Cc: Grant Likely <grant.likely@secretlab.ca>
>> > Cc: John Rigby <jcrigby@gmail.com>
>>
>> Missing patch description. =A0Otherwise looks okay.
>
> This is a repeating complaint. Do I really need an extra =A0description
> for a trivial patch that does exactly what the Subject: says?
Fair enough. I was going through your series pretty quickly and this
one doesn't really need it.
However, in this particular case, I think I would rather see both .dts
rework patches put into the same patch so it can be reviewed all at
once.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 03/12] fs_enet: Add FEC TX Alignment workaround for MPC5121.
From: Grant Likely @ 2009-05-06 22:42 UTC (permalink / raw)
To: Wolfgang Denk
Cc: Piotr Ziecik, Detlev Zundel, netdev, linuxppc-dev, John Rigby
In-Reply-To: <20090506221250.C977183420E8@gemini.denx.de>
On Wed, May 6, 2009 at 4:12 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Grant Likely,
>
> In message <fa686aa40905061337w6aa82f5aj787618ba108e528f@mail.gmail.com> =
you wrote:
>>
>> > The FEC on 5121 has problems with misaligned tx buffers.
>> > The RM says any alignment is ok but empirical results
>> > show that packet buffers ending in 0x1E will sometimes
>> > hang the FEC. Other bad alignment does not hang but will
>> > cause silent TX failures resulting in about a 1% packet
>> > loss as tested by ping -f from a remote host.
>> >
>> > This patch is a work around that copies every tx packet
>> > to an aligned skb before sending.
>>
>> OUCH!
>
> Yes :-(
>
>> > +#else
>> > +#define tx_skb_align_workaround(dev, skb) (skb)
>> > +#endif
>>
>> Another use of #ifdef blocks. =A0What is the multiplatform impact?
>
> Hm... Can you recommend a better way to solve the problem? Suggestions
> are welcome.
I'd rather see a runtime selectable workaround. ie. enable it based
on the compatible property.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 01/12] fs_enet: Use defines to set driver tunables.
From: Grant Likely @ 2009-05-06 22:41 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Piotr Ziecik, Detlev Zundel, netdev
In-Reply-To: <20090506220225.A013583420E8@gemini.denx.de>
On Wed, May 6, 2009 at 4:02 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Grant,
>
> In message <fa686aa40905061335q3a3c4cc7r33d77df655100531@mail.gmail.com> you wrote:
>> On Wed, May 6, 2009 at 2:15 PM, Wolfgang Denk <wd@denx.de> wrote:
>> > From: Piotr Ziecik <kosmo@semihalf.com>
>> >
>> > Signed-off-by: Piotr Ziecik <kosmo@semihalf.com>
>> > Signed-off-by: Wolfgang Denk <wd@denx.de>
>> > Cc: <netdev@vger.kernel.org>
>> > Cc: Grant Likely <grant.likely@secretlab.ca>
>> > Cc: John Rigby <jcrigby@gmail.com>
>>
>> Not seeing much benefit to this patch, and the (non-existant) patch
>> description doesn't really help me here either.
>
> Please see next patch which then uses the ability to change the
> defaults.
Please state that in the patch description when you repost it. :-P
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
From: Wolfgang Denk @ 2009-05-06 22:41 UTC (permalink / raw)
To: Grant Likely
Cc: Piotr Ziecik, Detlev Zundel, netdev, linuxppc-dev, John Rigby
In-Reply-To: <fa686aa40905061529u11b231afle3b5bb10a2334ad0@mail.gmail.com>
Dear Grant,
In message <fa686aa40905061529u11b231afle3b5bb10a2334ad0@mail.gmail.com> you wrote:
>
> > Agreed that it's ugly, but duplicatio9ng the code would have been even
> > worse. I don't think that it has multiplatform - at least not as long
> > as you don't ask for one image that runs on 83xx and on 512x.
>
> Actually, I *am* asking for one image that runs on 83xx, 52xx and
> 521x. I already can and do build and test a single image which boots
> on all my 52xx boards, on my 8349 board, and on my G4 Mac.
He. I was afraid you'd say that ;-)
In this case I need a helping hand as I can't figure out how to make
this work. Any suggestions?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Here's a fish hangs in the net like a poor man's right in the law.
'Twill hardly come out." - Shakespeare, Pericles, Act II, Scene 1
^ permalink raw reply
* Re: [PATCH 10/12] mpc5121: Add MPC5121 Real time clock driver.
From: Grant Likely @ 2009-05-06 22:40 UTC (permalink / raw)
To: Wolfram Sang
Cc: John Rigby, linuxppc-dev, Wolfgang Denk, rtc-linux, Piotr Ziecik
In-Reply-To: <20090506210644.GA17311@pengutronix.de>
On Wed, May 6, 2009 at 3:06 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> On Wed, May 06, 2009 at 10:15:17PM +0200, Wolfgang Denk wrote:
>> From: John Rigby <jrigby@freescale.com>
>>
>> Based on Domen Puncer's rtc driver for 5200 posted to
>> the ppclinux mailing list:
>> =A0 =A0 =A0 http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=3D116=
75
>> but never commited anywhere.
>>
>> Changes to Domen's original:
>>
>> =A0 =A0 Changed filenames/routine names from mpc5200* to mpc5121*
>
> Why not changing it to mpc5xxx? From a glimpse, it should still work on
> MPC5200, too.
If this is true, the I heartily agree with Wolfram. :-)
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
From: Grant Likely @ 2009-05-06 22:39 UTC (permalink / raw)
To: Wolfgang Denk
Cc: Piotr Ziecik, Detlev Zundel, John Rigby, netdev, linuxppc-dev,
Scott Wood
In-Reply-To: <20090506220954.5D3AF83420E8@gemini.denx.de>
On Wed, May 6, 2009 at 4:09 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Scott,
>
> in message <4A01F602.2010601@freescale.com> you wrote:
>>
>> All of the above is duplicative (with even the same names) of stuff in
>> asm/cpm.h. =A0Beyond just the duplication, what happens if both CPM2 and
>
> OK, I can try to reuse the definitions from that file.
>
>> 512x are enabled in the same kernel?
>
> Hm... both architectures look sufficiently different to me that I
> don't see sense in trying such a thing. Do you think that needs to be
> supported?
Yes! :-) It's not hard to do and it keeps the driver cleaner
(IMNSHO). I don't think it is quite possible at the moment due to
cache coherency issues, but with Becky's recently merged dma ops
changes it should be fixable.
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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