* Best hardware platform for native compiling...
From: David Jander @ 2009-07-21 9:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Wolfgang Denk
Hi all,
This might sound as a stupid question (and maybe sligtly off-topic), but I
have not found an (easy) answer and I suspect many on this list will have a
good suggestion to make:
We are developing (and maintaining) different embedded linux systems based on
different PowerPC processors. From small MPC852T with little RAM and Flash,
up to 400MHz MPC5200- and MPC5121e based systems that resemble more a PC or
netbook than an embedded system in terms of RAM and storage.
For smaller systems we use a customized ELDK-based OS and cross-compile almost
everything on a PC.
For bigger systems we often run a debian-derived OS like Ubuntu, and many
pieces are compiled natively on the target... just because it is easy and
quick to do, and cross-compiling certain packages can be a real pain.
But, a 400 MHz e300 core is not really fast for compiling, so I have been
considering buying some sort of PowerPC-based system with a faster processor,
just as a "build-server" (a G5 would do wonders I guess).
It seems like the only real option is one of the smaller IBM Power servers,
but that seems overkill to me. We also don't feel like buying some old
second-hand Apple gear.
Is there any other available and affordable platform that can be used to run
linux and compile software natively for 32-bit PowerPC?
Any suggestion is welcome!
Best regards,
P.S.: I am writing this while running "dpkg-buildpackage -rfakeroot" on the
package "xserver-xfbdev" from ubuntu 9.04 on a MPC5121e.... it will take 40
minutes ;-)
--
David Jander
Protonic Holland.
^ permalink raw reply
* msgctl10 fails on Powerpc Linux-2.6.29.6
From: srikanth krishnakar @ 2009-07-21 9:33 UTC (permalink / raw)
To: Linuxppc-dev; +Cc: Ltp-list
[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]
The LTP test case *msgctl10.c* fails on linux-2.6.29.6 for PowerPC
architecture (ppc440)
msgctl10 1 B------------[ cut here
]------------
kernel BUG at
arch/powerpc/kernel/traps.c:904!
Oops: Exception in kernel mode, sig: 5
[#9]
PREEMPT LTT NESTING LEVEL :
0
Virtex440
Modules linked
in:
NIP: c038178c LR: c0381640 CTR:
c02650bc
REGS: cafbbe70 TRAP: 0700 Tainted: G D
(2.6.29.6)
MSR: 00029000 <EE,ME,CE> CR: 48004224 XER:
20000008
TASK = cafa17f0[6435] 'msgctl10' THREAD:
cafba000
GPR00: 00000001 cafbbf20 cafa17f0 ffffffda 08000000 00000001 00000037
ffffffff
GPR08: cafa17f0 c04a0000 00021002 c0381594 28004222 1001f4bc bf93d950
100b0000
GPR16: 00000007 bf93d95c 100012a0 10005b84 00000067 100174e8 10017500
100174f8
GPR24: 00000000 00000001 103eaa50 00000000 00000000 00000000 08000000
cafbbf50
NIP [c038178c]
program_check_exception+0x1f8/0x5f4
LR [c0381640]
program_check_exception+0xac/0x5f4
Call
Trace:
[cafbbf20] [c0381640] program_check_exception+0xac/0x5f4
(unreliable)
[cafbbf40] [c000e78c]
ret_from_except_full+0x0/0x4c
Instruction
dump:
7d808120 4bc8ac20 2f830001 41beff38 2f83fff2 419e0024 77c00804
4182004c
3d20c04a 8809207c 2f800000 419e0080 <0fe00000> 48000000 80010024
3ca00003
---[ end trace fd0893c7d8cee1bd
]---
ROK : Unexpected signal 11
received.
msgctl10 1 FAIL : in read # = 21245,key =
533a
msgctl10 0 WARN : Verify error in child 13, *buf = f1, val = 6d, size
= 3
msgctl10 1 BROK : Unexpected signal 11
received.
msgctl10 1 BROK : Msgsnd error in child 14, key = d344 errno =
43
msgctl10 0 WARN : tst_rmdir(): rmobj(/tmp/msgNjyTEb) failed:
lstat(/tmp/msgNjyTEb) failed; errno=2: No such file or directory
msgctl10 0 WARN : tst_rmdir(): rmobj(/tmp/msgNjyTEb) failed:
lstat(/tmp/msgNjyTEb) failed; errno=2: No such file or directory
msgctl10 1 FAIL : in read # = 54260,key =
d46d
msgctl10 1 B------------[ cut here ]------------
Any clue ?
Thanks in Advance !
--
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 4491 bytes --]
^ permalink raw reply
* RE: DMA Engine on MPC8270
From: Li Yang-R58472 @ 2009-07-21 9:32 UTC (permalink / raw)
To: Felix Radensky, linuxppc-dev
In-Reply-To: <4A65887B.8090103@embedded-sol.com>
>Hi,
>
>Can Freescale DMA engine driver can be used on MPC2870 ?
No, the driver is only used on 83xx and 85xx cpus.
- Leo
^ permalink raw reply
* Re: [PATCH] powerpc/cell: strncpy does not null terminate string
From: Ken Kawakami @ 2009-07-21 9:31 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, akpm, roel.kluin, cbe-oss-dev
In-Reply-To: <200907171756.22224.arnd@arndb.de>
Arnd-san, Roel-san,
Thanks for pointing us to the redundant cord portion.
> On Friday 17 July 2009, Roel Kluin wrote:
> >
> > static int __init celleb_machine_type_hack(char *ptr)
> > {
> > - strncpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
> > + strlcpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
> > celleb_machine_type[sizeof(celleb_machine_type)-1] = 0;
> > return 0;
>
> This still is pointless as long as you keep the explicit null-termination
> in the next line, the patch still doesn't change anything significant.
>
> The file is maintained by Ishizaki Kou, if he would prefer to take a
> patch replacing the two lines with one, that's fine with me, otherwise
> I just wouldn't bother. You still only gain a few bytes of inittext, but
> that is discarded at boot time.
We prefer to take the patch which is replacing the two lines with one.
- strncpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
+ strlcpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
- celleb_machine_type[sizeof(celleb_machine_type)-1] = 0;
Thanks,
Ken Kawakami
^ permalink raw reply
* DMA Engine on MPC8270
From: Felix Radensky @ 2009-07-21 9:20 UTC (permalink / raw)
To: linuxppc-dev
Hi,
Can Freescale DMA engine driver can be used on MPC2870 ?
If not, what driver should I use instead ? The goal to to speed up
transfers to some storage device (M-Systems DoC H3).
Thanks a lot.
Felix.
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb()
From: Nick Piggin @ 2009-07-21 7:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linux-Arch, Linux Memory Management, Hugh Dickins, linux-kernel,
linuxppc-dev
In-Reply-To: <1248134546.30899.27.camel@pasglop>
On Tue, Jul 21, 2009 at 10:02:26AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2009-07-20 at 12:38 +0200, Nick Piggin wrote:
> > On Mon, Jul 20, 2009 at 08:00:41PM +1000, Benjamin Herrenschmidt wrote:
> > > On Mon, 2009-07-20 at 10:10 +0200, Nick Piggin wrote:
> > > >
> > > > Maybe I don't understand your description correctly. The TLB contains
> > > > PMDs, but you say the HW still logically performs another translation
> > > > step using entries in the PMD pages? If I understand that correctly,
> > > > then generic mm does not actually care and would logically fit better
> > > > if those entries were "linux ptes".
> > >
> > > They are :-)
> > >
> > > > The pte invalidation routines
> > > > give the virtual address, which you could use to invalidate the TLB.
> > >
> > > For PTEs, yes, but not for those PMD entries. IE. I need the virtual
> > > address when destroying PMDs so that I can invalidate those "indirect"
> > > pages. PTEs are already taken care of by existing mechanisms.
> >
> > Hmm, so even after having invalidated all the pte translations
> > then you still need to invalidate the empty indirect page? (or
> > maybe you don't even invalidate the ptes if they're not cached
> > in a TLB).
>
> The PTEs are cached in the TLB (ie, they turn into normal TLB entries).
>
> We need to invalidate the indirect entries when the PMD value change
> (ie, when the PTE page is freed) or the TLB would potentially continue
> loading PTEs from a stale PTE page :-)
>
> Hence my patch adding the virtual address to pte_free_tlb() which is the
> freeing of a PTE page. I'm adding it to the pmd/pud variants too for
> consistency and because I believe there's no cost.
Yes I think we're on the same page now. So as I said, the
patch is quite OK with me.
^ permalink raw reply
* Re: Simple question about powerpc kernel source.
From: Benjamin Herrenschmidt @ 2009-07-21 0:23 UTC (permalink / raw)
To: HongWoo Lee; +Cc: linuxppc-dev
In-Reply-To: <4A6508AD.6090207@gmail.com>
On Tue, 2009-07-21 at 09:15 +0900, HongWoo Lee wrote:
> First, I aleady understood about @highest, @higher, @h and @l.
> For now, what I want to know is about "##" in the below code.
>
> #define LOADADDR(rn,name) \
> lis rn,name##@highest; \
> ori rn,rn,name##@higher; \
> rldicr rn,rn,32,31; \
> oris rn,rn,name##@h; \
> ori rn,rn,name##@l
>
> And I don't want to ask every detail.
> So I want to know the manual or document which describes the detail.
Well, it's just concatenation...
Ie, if you do LOADADDR(rn, .myfunction) it will turn to
lis rn,.myfunction@highest;
ori rn,rn,.myfunction@higher;
rldicr rn,rn,32,31;
oris rn,rn,.myfunction@h;
ori rn,rn,.myfunction@l
>
Which means putting the address of .myfunction into register rn.
Cheers,
Ben.
^ permalink raw reply
* Re: Simple question about powerpc kernel source.
From: HongWoo Lee @ 2009-07-21 0:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1248084158.30899.8.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]
-------- Original Message --------
Subject: Re: Simple question about powerpc kernel source.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: HongWoo Lee <hongwoo7@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org
Date: Mon Jul 20 2009 19:02:38 GMT+0900
> On Mon, 2009-07-20 at 18:00 +0900, HongWoo Lee wrote:
>
>> Hi all,
>>
>> I have something to ask for the ppc kernel source.
>>
>> #define LOADADDR(rn,name) \
>> lis rn,name##@highest; \
>> ori rn,rn,name##@higher; \
>> rldicr rn,rn,32,31; \
>> oris rn,rn,name##@h; \
>> ori rn,rn,name##@l
>>
>> Is ## used for concatenation. I'm not sure because it is just meaningless.
>> If so what on earth is the result of concatenating ?
>>
>> And is there a good reference to understand powerpc asm ?
>> I'm reading Power ISA, but I can't find @highest, @higher and ##.
>> It would be good to know the reference book.
>>
>
> You already asked pretty much the same question with the subject "Simple
> question about powerpc asm" and it was already replied to.
>
> Cheers,
> Ben.
>
>
>
Thank you, Ben.
First, I aleady understood about @highest, @higher, @h and @l.
For now, what I want to know is about "##" in the below code.
#define LOADADDR(rn,name) \
lis rn,name##@highest; \
ori rn,rn,name##@higher; \
rldicr rn,rn,32,31; \
oris rn,rn,name##@h; \
ori rn,rn,name##@l
And I don't want to ask every detail.
So I want to know the manual or document which describes the detail.
Regards,
HongWoo.
[-- Attachment #2: Type: text/html, Size: 2319 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
From: Benjamin Herrenschmidt @ 2009-07-21 0:02 UTC (permalink / raw)
To: Nick Piggin
Cc: Linux-Arch, Linux Memory Management, Hugh Dickins, linux-kernel,
linuxppc-dev
In-Reply-To: <20090720103835.GB7070@wotan.suse.de>
On Mon, 2009-07-20 at 12:38 +0200, Nick Piggin wrote:
> On Mon, Jul 20, 2009 at 08:00:41PM +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2009-07-20 at 10:10 +0200, Nick Piggin wrote:
> > >
> > > Maybe I don't understand your description correctly. The TLB contains
> > > PMDs, but you say the HW still logically performs another translation
> > > step using entries in the PMD pages? If I understand that correctly,
> > > then generic mm does not actually care and would logically fit better
> > > if those entries were "linux ptes".
> >
> > They are :-)
> >
> > > The pte invalidation routines
> > > give the virtual address, which you could use to invalidate the TLB.
> >
> > For PTEs, yes, but not for those PMD entries. IE. I need the virtual
> > address when destroying PMDs so that I can invalidate those "indirect"
> > pages. PTEs are already taken care of by existing mechanisms.
>
> Hmm, so even after having invalidated all the pte translations
> then you still need to invalidate the empty indirect page? (or
> maybe you don't even invalidate the ptes if they're not cached
> in a TLB).
The PTEs are cached in the TLB (ie, they turn into normal TLB entries).
We need to invalidate the indirect entries when the PMD value change
(ie, when the PTE page is freed) or the TLB would potentially continue
loading PTEs from a stale PTE page :-)
Hence my patch adding the virtual address to pte_free_tlb() which is the
freeing of a PTE page. I'm adding it to the pmd/pud variants too for
consistency and because I believe there's no cost.
> I believe x86 is also allowed to cache higher level page tables
> in non-cache coherent storage, and I think it just avoids this
> issue by flushing the entire TLB when potentially tearing down
> upper levels. So in theory I think your patch could allow x86 to
> use invlpg more often as well (in practice the flush-all case
> and TLB refills are so fast in comparison with invlpg that it
> probably doesn't gain much especially when talking about
> invalidating upper levels). So making the generic VM more
> flexible like that is no problem for me.
Ah that's good to know. I don't know that much about the x86 way of
doing these things :-)
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc/83xx: Fix PCI IO base address on MPC837xE-RDB boards
From: Anton Vorontsov @ 2009-07-20 21:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
U-Boot maps PCI IO at 0xe0300000, while current dts files specify
0xe2000000. This leads to the following oops with CONFIG_8139TOO_PIO=y.
8139too Fast Ethernet driver 0.9.28
Machine check in kernel mode.
Caused by (from SRR1=41000): Transfer error ack signal
Oops: Machine check, sig: 7 [#1]
MPC837x RDB
[...]
NIP [00000900] 0x900
LR [c0439df8] rtl8139_init_board+0x238/0x524
Call Trace:
[cf831d90] [c0439dcc] rtl8139_init_board+0x20c/0x524 (unreliable)
[cf831de0] [c043a15c] rtl8139_init_one+0x78/0x65c
[cf831e40] [c0235250] pci_call_probe+0x20/0x30
[...]
This patch fixes the issue by specifying the correct PCI IO base
address.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8377_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8378_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8379_rdb.dts | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index 224b4f0..4f06dbc 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -410,7 +410,7 @@
bus-range = <0 0>;
ranges = <0x02000000 0x0 0x90000000 0x90000000 0x0 0x10000000
0x42000000 0x0 0x80000000 0x80000000 0x0 0x10000000
- 0x01000000 0x0 0x00000000 0xe2000000 0x0 0x00100000>;
+ 0x01000000 0x0 0x00000000 0xe0300000 0x0 0x00100000>;
sleep = <&pmc 0x00010000>;
clock-frequency = <66666666>;
#interrupt-cells = <1>;
diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts b/arch/powerpc/boot/dts/mpc8378_rdb.dts
index 474ea2f..aabf343 100644
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -394,7 +394,7 @@
bus-range = <0 0>;
ranges = <0x02000000 0x0 0x90000000 0x90000000 0x0 0x10000000
0x42000000 0x0 0x80000000 0x80000000 0x0 0x10000000
- 0x01000000 0x0 0x00000000 0xe2000000 0x0 0x00100000>;
+ 0x01000000 0x0 0x00000000 0xe0300000 0x0 0x00100000>;
sleep = <&pmc 0x00010000>;
clock-frequency = <66666666>;
#interrupt-cells = <1>;
diff --git a/arch/powerpc/boot/dts/mpc8379_rdb.dts b/arch/powerpc/boot/dts/mpc8379_rdb.dts
index d4838af..9b1da86 100644
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -424,7 +424,7 @@
bus-range = <0x0 0x0>;
ranges = <0x02000000 0x0 0x90000000 0x90000000 0x0 0x10000000
0x42000000 0x0 0x80000000 0x80000000 0x0 0x10000000
- 0x01000000 0x0 0x00000000 0xe2000000 0x0 0x00100000>;
+ 0x01000000 0x0 0x00000000 0xe0300000 0x0 0x00100000>;
sleep = <&pmc 0x00010000>;
clock-frequency = <66666666>;
#interrupt-cells = <1>;
--
1.6.3.3
^ permalink raw reply related
* Re: PPCboot and latest kernel
From: Wolfgang Denk @ 2009-07-20 17:40 UTC (permalink / raw)
To: vijay sharma; +Cc: linuxppc-dev
In-Reply-To: <e571380d0907191136j37d341d7k514f46396a38abc3@mail.gmail.com>
Dear vijay sharma,
In message <e571380d0907191136j37d341d7k514f46396a38abc3@mail.gmail.com> you wrote:
>
> I have been woking on upgrading an embedded system based on MPC8241 from
> 2.4.17 linux to 2.6.30 kernel.
Wow, that's a big leap...
You should also consider to update to the latest version of U-Boot;
the time when it was still called PPCBoot is long, long past.
> I am currently struck one point.
>
> Here is the console output where I am struck:
> =================================
> cpboot> bootm
> ## Booting image at 08000000 ...
> Image Name: Linux-2.6.30
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 21729342 Bytes = 21220 kB = 20 MB
> Load Address: 01900000
> Entry Point: 01900570
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Memory <- <0x0 0x10000000> (256MB)
> CPU clock-frequency <- 0xbebc1fe (200MHz)
> CPU timebase-frequency <- 0x17d783f (25MHz)
> CPU bus-frequency <- 0x5f5e0ff (100MHz)
>
> zImage starting: loaded at 0x01900000 (sp: 0x0fdc3a08)
> Allocating 0x165ca04 bytes for kernel ...
> gunzipping (0x00000000 <- 0x0190c000:0x02f58efc)...done 0x1637b54 bytes
You loaded the image at 01900000, but the uncompr4essed image extends
until 02f58efc, i. e. there is a good chance that you will overwrite
parts of the still uncompressed image.
> Linux/PowerPC load:
> Finalizing device tree... flat tree at 0x2f65300 <== Beyond this point no
> output is available.
Your device tree might be wrong, too.
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
Any sufficiently advanced bug is indistinguishable from a feature.
- Rich Kulawiec
^ permalink raw reply
* Re: [RFC/PATCH] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: Grant Likely @ 2009-07-20 14:59 UTC (permalink / raw)
To: Mark Ware; +Cc: netdev, linuxppc-dev
In-Reply-To: <4A646117.1030409@elphinstone.net>
(adding cc:linuxppc-dev@ozlabs.org)
On Mon, Jul 20, 2009 at 6:20 AM, Mark Ware<mware@elphinstone.net> wrote:
> Changes to the fs_enet driver (aa73832c5a80d6c52c69b18af858d88fa595dd3c)
> cause kernel crashes when using the mdio-ofgpio driver.
>
> The following patch is a fairly naive attempt to replicate similar change=
s
> made to the fs_enet mii-bitbang drivers.
For a naive attempt, it's really quite good. However, I'd do it
slightly differently.
You should refactor mdio_gpio_bus_init() to not call
mdiobus_register() at all, and instead just return a pointer to the
unregistered new_bus. Then mdio_gpio_probe() and mdio_ofgpio_probe()
can call the correct register variant directly. Fewer ugly #ifdefs
this way. It also eliminates the need to cast the void* pointer.
Thanks for catching this.
g.
> =A0drivers/net/phy/mdio-gpio.c | =A0 39 +++++++++++++--------------------=
------
> =A01 files changed, 13 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
> index 33984b7..6568176 100644
> --- a/drivers/net/phy/mdio-gpio.c
> +++ b/drivers/net/phy/mdio-gpio.c
> @@ -30,6 +30,7 @@
>
> =A0#ifdef CONFIG_OF_GPIO
> =A0#include <linux/of_gpio.h>
> +#include <linux/of_mdio.h>
> =A0#include <linux/of_platform.h>
> =A0#endif
>
> @@ -83,7 +84,8 @@ static struct mdiobb_ops mdio_gpio_ops =3D {
>
> =A0static int __devinit mdio_gpio_bus_init(struct device *dev,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0struct mdio_gpio_platform_data
> *pdata,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 int bus_id)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 int bus_id,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0void *ofdev)
> =A0{
> =A0 =A0 =A0 =A0struct mii_bus *new_bus;
> =A0 =A0 =A0 =A0struct mdio_gpio_info *bitbang;
> @@ -129,7 +131,14 @@ static int __devinit mdio_gpio_bus_init(struct devic=
e
> *dev,
>
> =A0 =A0 =A0 =A0dev_set_drvdata(dev, new_bus);
>
> - =A0 =A0 =A0 ret =3D mdiobus_register(new_bus);
> +#ifdef CONFIG_OF_GPIO
> + =A0 =A0if (ofdev)
> + =A0 =A0 =A0 =A0ret =3D of_mdiobus_register(new_bus, ((struct of_device =
*)
> ofdev)->node);
> + =A0 =A0else
> +#else
> + =A0 =A0 =A0 =A0 =A0 ret =3D mdiobus_register(new_bus);
> +#endif
> +
> =A0 =A0 =A0 =A0if (ret)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out_free_all;
>
> @@ -168,7 +177,7 @@ static int __devinit mdio_gpio_probe(struct
> platform_device *pdev)
> =A0 =A0 =A0 =A0if (!pdata)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -ENODEV;
>
> - =A0 =A0 =A0 return mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id);
> + =A0 =A0 =A0 return mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id, NULL=
);
> =A0}
>
> =A0static int __devexit mdio_gpio_remove(struct platform_device *pdev)
> @@ -179,28 +188,10 @@ static int __devexit mdio_gpio_remove(struct
> platform_device *pdev)
> =A0}
>
> =A0#ifdef CONFIG_OF_GPIO
> -static void __devinit add_phy(struct mdio_gpio_platform_data *pdata,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct device_n=
ode *np)
> -{
> - =A0 =A0 =A0 const u32 *data;
> - =A0 =A0 =A0 int len, id, irq;
> -
> - =A0 =A0 =A0 data =3D of_get_property(np, "reg", &len);
> - =A0 =A0 =A0 if (!data || len !=3D 4)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
> -
> - =A0 =A0 =A0 id =3D *data;
> - =A0 =A0 =A0 pdata->phy_mask &=3D ~(1 << id);
> -
> - =A0 =A0 =A0 irq =3D of_irq_to_resource(np, 0, NULL);
> - =A0 =A0 =A0 if (irq)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 pdata->irqs[id] =3D irq;
> -}
>
> =A0static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 const struct of_device_id *match)
> =A0{
> - =A0 =A0 =A0 struct device_node *np =3D NULL;
> =A0 =A0 =A0 =A0struct mdio_gpio_platform_data *pdata;
> =A0 =A0 =A0 =A0int ret;
>
> @@ -218,11 +209,7 @@ static int __devinit mdio_ofgpio_probe(struct of_dev=
ice
> *ofdev,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out_free;
> =A0 =A0 =A0 =A0pdata->mdio =3D ret;
>
> - =A0 =A0 =A0 while ((np =3D of_get_next_child(ofdev->node, np)))
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!strcmp(np->type, "ethernet-phy"))
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 add_phy(pdata, np);
> -
> - =A0 =A0 =A0 return mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
> + =A0 =A0 =A0 return mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc, o=
fdev);
>
> =A0out_free:
> =A0 =A0 =A0 =A0kfree(pdata);
> --
> 1.5.6.5
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb()
From: David Howells @ 2009-07-20 12:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linux-Arch, Nick Piggin, linuxppc-dev, Hugh Dickins, linux-kernel,
Linux Memory Management
In-Reply-To: <20090715074952.A36C7DDDB2@ozlabs.org>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Upcoming paches to support the new 64-bit "BookE" powerpc architecture
> will need to have the virtual address corresponding to PTE page when
> freeing it, due to the way the HW table walker works.
>
> Basically, the TLB can be loaded with "large" pages that cover the whole
> virtual space (well, sort-of, half of it actually) represented by a PTE
> page, and which contain an "indirect" bit indicating that this TLB entry
> RPN points to an array of PTEs from which the TLB can then create direct
> entries. Thus, in order to invalidate those when PTE pages are deleted,
> we need the virtual address to pass to tlbilx or tlbivax instructions.
>
> The old trick of sticking it somewhere in the PTE page struct page sucks
> too much, the address is almost readily available in all call sites and
> almost everybody implemets these as macros, so we may as well add the
> argument everywhere. I added it to the pmd and pud variants for consistency.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: David Howells <dhowells@redhat.com> [MN10300 & FRV]
^ permalink raw reply
* Re: ethtool support in ethernet driver
From: Josh Boyer @ 2009-07-20 12:18 UTC (permalink / raw)
To: Mohd Arif; +Cc: linuxppc-dev
In-Reply-To: <0A8CFEC45B7F4C419F7543867C47442303189F8B@mailserver.nechclst.in>
On Sun, Jul 19, 2009 at 05:12:11PM +0530, Mohd Arif wrote:
>Dear All,
> Happy to be a part of this mailing list!!!!!
> The issue is that i want to give support of ethtool in ethernet
>driver.
You didn't say whether this is related to PowerPC or not.
> Where do i need to make changes in the driver?
You didn't say which driver. There are a lot of them.
> I have never been into driver stuff.
> So kindly suggest me accordingly.
If this is just a generic ethernet driver question, you probably want the
netdev mailing list, not this one.
josh
^ permalink raw reply
* [RFC/PATCH] powerpc: Don't use alloc_bootmem in cpm_uart_cpm2.c
From: Mark Ware @ 2009-07-20 11:51 UTC (permalink / raw)
To: Linuxppc-dev Development
This is another alloc_bootmem() -> kzalloc() change, this time to
fix the non-fatal badness caused when booting with a cpm2_uart console.
Signed-Off-By: Mark Ware <mware@elphinstone.net>
---
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
index 141c0a3..a9802e7 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
@@ -132,7 +132,7 @@ int cpm_uart_allocbuf(struct uart_cpm_port *pinfo,
unsigned int is_con)
memsz = L1_CACHE_ALIGN(pinfo->rx_nrfifos * pinfo->rx_fifosize) +
L1_CACHE_ALIGN(pinfo->tx_nrfifos * pinfo->tx_fifosize);
if (is_con) {
- mem_addr = alloc_bootmem(memsz);
+ mem_addr = kzalloc(memsz, GFP_NOWAIT);
dma_addr = virt_to_bus(mem_addr);
}
else
--
1.5.6.5
^ permalink raw reply related
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb()
From: Nick Piggin @ 2009-07-20 10:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linux-Arch, linuxppc-dev, Hugh Dickins, linux-kernel,
Linux Memory Management, Linus Torvalds
In-Reply-To: <1248083961.30899.5.camel@pasglop>
On Mon, Jul 20, 2009 at 07:59:21PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2009-07-20 at 10:05 +0200, Nick Piggin wrote:
> >
> > Unless anybody has other preferences, just send it straight to Linus in
> > the next merge window -- if any conflicts did come up anyway they would
> > be trivial. You could just check against linux-next before doing so, and
> > should see if it is going to cause problems for any arch pull...
>
> Well, the problem is that powerpc-next will need that patch, which means
> that if I don't put it in my tree, Steven won't be able to build
> powerpc-next as part of linux-next until the patch is merged. Hence my
> question, what's the best way to handle that :-) There isn't an mm-next
> is there ? If there was, I could tell Steven to always pull powerpc
> after mm for example. Or I can put it in a git tree of its own with a
> dependency for Steven to pull.
No I don't think there is an mm-next. But Steven will hold individual
patches to correct intermediate issues like this, won't he?
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb()
From: Nick Piggin @ 2009-07-20 10:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linux-Arch, Linux Memory Management, Hugh Dickins, linux-kernel,
linuxppc-dev
In-Reply-To: <1248084041.30899.7.camel@pasglop>
On Mon, Jul 20, 2009 at 08:00:41PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2009-07-20 at 10:10 +0200, Nick Piggin wrote:
> >
> > Maybe I don't understand your description correctly. The TLB contains
> > PMDs, but you say the HW still logically performs another translation
> > step using entries in the PMD pages? If I understand that correctly,
> > then generic mm does not actually care and would logically fit better
> > if those entries were "linux ptes".
>
> They are :-)
>
> > The pte invalidation routines
> > give the virtual address, which you could use to invalidate the TLB.
>
> For PTEs, yes, but not for those PMD entries. IE. I need the virtual
> address when destroying PMDs so that I can invalidate those "indirect"
> pages. PTEs are already taken care of by existing mechanisms.
Hmm, so even after having invalidated all the pte translations
then you still need to invalidate the empty indirect page? (or
maybe you don't even invalidate the ptes if they're not cached
in a TLB).
I believe x86 is also allowed to cache higher level page tables
in non-cache coherent storage, and I think it just avoids this
issue by flushing the entire TLB when potentially tearing down
upper levels. So in theory I think your patch could allow x86 to
use invlpg more often as well (in practice the flush-all case
and TLB refills are so fast in comparison with invlpg that it
probably doesn't gain much especially when talking about
invalidating upper levels). So making the generic VM more
flexible like that is no problem for me.
^ permalink raw reply
* Re: Simple question about powerpc kernel source.
From: Benjamin Herrenschmidt @ 2009-07-20 10:02 UTC (permalink / raw)
To: HongWoo Lee; +Cc: linuxppc-dev
In-Reply-To: <4A643219.3070004@gmail.com>
On Mon, 2009-07-20 at 18:00 +0900, HongWoo Lee wrote:
> Hi all,
>
> I have something to ask for the ppc kernel source.
>
> #define LOADADDR(rn,name) \
> lis rn,name##@highest; \
> ori rn,rn,name##@higher; \
> rldicr rn,rn,32,31; \
> oris rn,rn,name##@h; \
> ori rn,rn,name##@l
>
> Is ## used for concatenation. I'm not sure because it is just meaningless.
> If so what on earth is the result of concatenating ?
>
> And is there a good reference to understand powerpc asm ?
> I'm reading Power ISA, but I can't find @highest, @higher and ##.
> It would be good to know the reference book.
You already asked pretty much the same question with the subject "Simple
question about powerpc asm" and it was already replied to.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
From: Benjamin Herrenschmidt @ 2009-07-20 10:00 UTC (permalink / raw)
To: Nick Piggin
Cc: Linux-Arch, Linux Memory Management, Hugh Dickins, linux-kernel,
linuxppc-dev
In-Reply-To: <20090720081054.GH7298@wotan.suse.de>
On Mon, 2009-07-20 at 10:10 +0200, Nick Piggin wrote:
>
> Maybe I don't understand your description correctly. The TLB contains
> PMDs, but you say the HW still logically performs another translation
> step using entries in the PMD pages? If I understand that correctly,
> then generic mm does not actually care and would logically fit better
> if those entries were "linux ptes".
They are :-)
> The pte invalidation routines
> give the virtual address, which you could use to invalidate the TLB.
For PTEs, yes, but not for those PMD entries. IE. I need the virtual
address when destroying PMDs so that I can invalidate those "indirect"
pages. PTEs are already taken care of by existing mechanisms.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
From: Benjamin Herrenschmidt @ 2009-07-20 9:59 UTC (permalink / raw)
To: Nick Piggin
Cc: Linux-Arch, linuxppc-dev, Hugh Dickins, linux-kernel,
Linux Memory Management, Linus Torvalds
In-Reply-To: <20090720080502.GG7298@wotan.suse.de>
On Mon, 2009-07-20 at 10:05 +0200, Nick Piggin wrote:
>
> Unless anybody has other preferences, just send it straight to Linus in
> the next merge window -- if any conflicts did come up anyway they would
> be trivial. You could just check against linux-next before doing so, and
> should see if it is going to cause problems for any arch pull...
Well, the problem is that powerpc-next will need that patch, which means
that if I don't put it in my tree, Steven won't be able to build
powerpc-next as part of linux-next until the patch is merged. Hence my
question, what's the best way to handle that :-) There isn't an mm-next
is there ? If there was, I could tell Steven to always pull powerpc
after mm for example. Or I can put it in a git tree of its own with a
dependency for Steven to pull.
Cheers,
Ben.
^ permalink raw reply
* Simple question about powerpc kernel source.
From: HongWoo Lee @ 2009-07-20 9:00 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I have something to ask for the ppc kernel source.
#define LOADADDR(rn,name) \
lis rn,name##@highest; \
ori rn,rn,name##@higher; \
rldicr rn,rn,32,31; \
oris rn,rn,name##@h; \
ori rn,rn,name##@l
Is ## used for concatenation. I'm not sure because it is just meaningless.
If so what on earth is the result of concatenating ?
And is there a good reference to understand powerpc asm ?
I'm reading Power ISA, but I can't find @highest, @higher and ##.
It would be good to know the reference book.
Thanks in advance.
Regards,
HongWoo.
^ permalink raw reply
* Re: booting MPC8313 based board with yaffs2 RFS
From: tonyliu @ 2009-07-20 8:38 UTC (permalink / raw)
To: Rupesh Kumar; +Cc: linuxppc-dev
In-Reply-To: <OF2CCFE0B3.51B58673-ON652575F5.001ABC10-652575F5.001C7443@lntemsys.com>
Rupesh Kumar wrote:
> Hi
> Thanks for reply.
> After erasing one of the flash partition, i mounted it as yaffs2 and
> manually created rootfs there.
> Though it (careting RFS in NAND partiton) marked blocks bad, I am able to
> boot with this yaffs2 filesystem.
> When image is created with mkyffs2image binary, board does not boot with
> that and says kernel panic.
>
> 1. What nand flash is on-board? what's the size of the nand flash page
> size, 512/2048?
> Nand Flash used on board is K9F2G08U0M-P from Samsung and page size is
> 2048.
> 2. what's the version of mkyaffs2image you are using?
> mkyaffs2image: image building tool for YAFFS2 built Jan 31 2009
> 3. Can you mount an empty nand flash partition using yaffs2 type,
> mount /dev/mtdblock##x xxx
> Yes, i wrote RFS contents to the nand flash partition and booted with
> that.
> 4. It's better to attatch bootup message.
> Bootup message is attached for both conditions
> 1) booting with manually created RFS on flash drive mounted as
> yaffs2(boot-up_manual_RFS.txt).
> 2) booting with yaffs2 image created by mkyaffs2image tool.
> Note :- below are steps used for writing RFS iamge
> ~ # flash_eraseall /dev/mtd11
> ~ # nandwrite -a -o /dev/mtd11 rootrfs_1.yaffs2
>
After you nandwrite the yaffs2 rootfs image, you should mount the
partition to validate if it's right.
For your situation, there is probably only one "lost+found" dir under
the mounted partition.
You maybe took notice that there is one option "oob_ecc_size" for
mkyaffs2image.Default is 0.
if your mkyaffs2image has no such option, you should update it.
Here are some comments of the patch for adding "oob_ecc_size", hope
helpful for you
" The main problem was that mkyaffs2image was writing YAFFS2 OOB data
into the OOB area that the MTD
driver uses for ECC. Therefore we need to leave room inside the OOB
yaffs2 image space for data ECC.
This is achieved by introducing a new optional parameter called
oob_ecc_size to specify the size of data ECC
(e.g. for 2k page/64bytes OOB, this data ECC is 14 bytes). "
Tony
>
>
>
>
>
>
> Thanks
> Rupesh
>
>
>
>
>
> tonyliu <Bo.Liu@windriver.com>
> 07/17/2009 07:37 AM
>
> To
> Rupesh Kumar <Rupesh.Kumar@Lntemsys.com>
> cc
> linuxppc-dev@lists.ozlabs.org
> Subject
> Re: booting MPC8313 based board with yaffs2 RFS
>
>
>
>
>
>
>
> Rupesh Kumar wrote:
>
>> Hi
>> I am using MPC8313 board which is currently booting with JFFS2 root file
>>
>
>
>> system.
>> I am using linux kernel version 2.6.23 from FreeScale's LTIB for
>>
> MPC8313.
>
>> As, I want it to boot with YAFFS2 root file system, I did compile kernel
>>
>
>
>> with yaffs2 support, craeted yaffs2 rootfile system and passed yaffs2
>> partiton of nand in bootargs. However it didnot work.
>>
>>
>> If any one has done it successfully, can please share the steps to be
>> followed ?
>>
>>
> More detailed info maybe helpful for debugging this issue.
>
> 1. What nand flash is on-board? what's the size of the nand flash page
> size, 512/2048?
> 2. what's the version of mkyaffs2image you are using?
> 3. Can you mount an empty nand flash partition using yaffs2 type,
> mount /dev/mtdblock##x xxx
> 4. It's better to attatch bootup message.
>
> Tony
>
>> Thanks
>> Rupesh
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>>
>>
>
>
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb()
From: Nick Piggin @ 2009-07-20 8:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linux-Arch, Linux Memory Management, Hugh Dickins, linux-kernel,
linuxppc-dev
In-Reply-To: <1247709255.27937.5.camel@pasglop>
On Thu, Jul 16, 2009 at 11:54:15AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-07-15 at 15:56 +0200, Nick Piggin wrote:
> > Interesting arrangement. So are these last level ptes modifieable
> > from userspace or something? If not, I wonder if you could manage
> > them as another level of pointers with the existing pagetable
> > functions?
>
> I don't understand what you mean. Basically, the TLB contains PMD's.
Maybe I don't understand your description correctly. The TLB contains
PMDs, but you say the HW still logically performs another translation
step using entries in the PMD pages? If I understand that correctly,
then generic mm does not actually care and would logically fit better
if those entries were "linux ptes". The pte invalidation routines
give the virtual address, which you could use to invalidate the TLB.
> There's nothing to change to the existing page table layout :-) But
> because they appear as large page TLB entries that cover the virtual
> space covered by a PMD, they need to be invalidated using virtual
> addresses when PMDs are removed.
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb()
From: Nick Piggin @ 2009-07-20 8:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linux-Arch, linuxppc-dev, Hugh Dickins, linux-kernel,
Linux Memory Management, Linus Torvalds
In-Reply-To: <1248073873.13067.31.camel@pasglop>
On Mon, Jul 20, 2009 at 05:11:13PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-07-15 at 15:56 +0200, Nick Piggin wrote:
> > > I would like to merge the new support that depends on this in 2.6.32,
> > > so unless there's major objections, I'd like this to go in early during
> > > the merge window. We can sort out separately how to carry the patch
> > > around in -next until then since the powerpc tree will have a dependency
> > > on it.
> >
> > Can't see any problem with that.
>
> CC'ing Linus here. How do you want to proceed with that merge ? (IE. so
> far nobody objected to the patch itself)
>
> IE. The patch affects all archs, though it's a trivial change every
> time, but I'll have stuff in powerpc-next that depends on it, and so I'm
> not sure what the right approach is here. Should I put it in the powerpc
> tree ?
>
> I also didn't have any formal Ack from anybody, neither mm folks nor
> arch maintainers :-)
Yeah, if you think it helps, Acked-by: Nick Piggin <npiggin@suse.de> is
fine ;)
Unless anybody has other preferences, just send it straight to Linus in
the next merge window -- if any conflicts did come up anyway they would
be trivial. You could just check against linux-next before doing so, and
should see if it is going to cause problems for any arch pull...
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
From: Martin Schwidefsky @ 2009-07-20 7:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Nick Piggin, Linux-Arch, linuxppc-dev, Hugh Dickins, linux-kernel,
Linux Memory Management, Linus Torvalds
In-Reply-To: <1248073873.13067.31.camel@pasglop>
On Mon, 20 Jul 2009 17:11:13 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Wed, 2009-07-15 at 15:56 +0200, Nick Piggin wrote:
> > > I would like to merge the new support that depends on this in 2.6.32,
> > > so unless there's major objections, I'd like this to go in early during
> > > the merge window. We can sort out separately how to carry the patch
> > > around in -next until then since the powerpc tree will have a dependency
> > > on it.
> >
> > Can't see any problem with that.
>
> CC'ing Linus here. How do you want to proceed with that merge ? (IE. so
> far nobody objected to the patch itself)
>
> IE. The patch affects all archs, though it's a trivial change every
> time, but I'll have stuff in powerpc-next that depends on it, and so I'm
> not sure what the right approach is here. Should I put it in the powerpc
> tree ?
>
> I also didn't have any formal Ack from anybody, neither mm folks nor
> arch maintainers :-)
Well the change is trivial, it just adds another unused argument to the
macros. For the records: it still compiles on s390.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ 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