* 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
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
From: Benjamin Herrenschmidt @ 2009-07-20 7:11 UTC (permalink / raw)
To: Nick Piggin
Cc: Linux-Arch, linuxppc-dev, Hugh Dickins, linux-kernel,
Linux Memory Management, Linus Torvalds
In-Reply-To: <20090715135620.GD7298@wotan.suse.de>
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 :-)
Cheers,
Ben.
^ permalink raw reply
* Re: Mounting a USB flash stick based root FS directly.
From: Cristian Axenie @ 2009-07-20 5:14 UTC (permalink / raw)
To: Dushara Jayasinghe; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <DE0CCFFBFF707949BEABD4537A14ACBA0C20DE6983@mailsvr>
Hello !
If you properly set the root fs on your USB flash you should try to
set it up using some uBoot bootargs :
e.g. :
setenv usbstick_args setenv bootargs root=/dev/sdXX ro
rootdelay=$HOW_MANY_SECONDS_TO_WAIT rootfstype=$YOUR_FS_TYPE
init=/sbin/init console=$consoledev,$baudrate;
setenv usbstick 'run usbstick_args;bootm fe500000 - fe700000'
setenv bootcmd run usbstick
Best !
On 7/20/09, Dushara Jayasinghe <DusharaJ@optiscan.com> wrote:
> Hi all,
>
> I'm attempting to mount the root file system directly from a USB flash stick
> (thus avoiding a ram-disk). The init thread is delayed until the USB device
> is enumerated. However, I find the call to sys_mount() in line 218 @
> http://git.denx.de/?p=linux-2.6-denx.git;a=blob;f=init/do_mounts.c;h=8d4ff5afc1d80b56963cbf119b162a3ebce61124;hb=ad2a8c8d0593bf2d1ef163f1ca7574f02b2e770e
> fails. The problem is I can't work out where sys_mount() is implemented.
>
> I'm working off the 2.6.29-DENX kernel (commit id
> ad2a8c8d0593bf2d1ef163f1ca7574f02b2e770e). and My target CPU is an
> mpc8349.
>
>
> Thanks in advance.
>
>
> Dushara Jayasinghe
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Mounting a USB flash stick based root FS directly.
From: Dushara Jayasinghe @ 2009-07-20 2:04 UTC (permalink / raw)
To: 'linuxppc-dev@lists.ozlabs.org'
Hi all,
I'm attempting to mount the root file system directly from a USB flash stic=
k (thus avoiding a ram-disk). The init thread is delayed until the USB devi=
ce is enumerated. However, I find the call to sys_mount() in line 218 @ htt=
p://git.denx.de/?p=3Dlinux-2.6-denx.git;a=3Dblob;f=3Dinit/do_mounts.c;h=3D8=
d4ff5afc1d80b56963cbf119b162a3ebce61124;hb=3Dad2a8c8d0593bf2d1ef163f1ca7574=
f02b2e770e fails. The problem is I can't work out where sys_mount() is impl=
emented.
I'm working off the 2.6.29-DENX kernel (commit id ad2a8c8d0593bf2d1ef163f1c=
a7574f02b2e770e). and My target CPU is an
mpc8349.
Thanks in advance.
Dushara Jayasinghe
^ permalink raw reply
* Re: proper way to reserve a chunk of memory at the top of the kernel?
From: Benjamin Herrenschmidt @ 2009-07-20 1:54 UTC (permalink / raw)
To: Chris Friesen; +Cc: linuxppc-dev, Linux kernel
In-Reply-To: <4A5CF62F.6020102@nortel.com>
On Tue, 2009-07-14 at 15:18 -0600, Chris Friesen wrote:
> I have a powerpc board with 512BM of memory. The BIOS has a chunk of
> memory at the top end of physical memory which it does not zero out over
> a reboot.
>
> What's the proper way to tell linux that this chunk of physical memory
> should be ignored (so that we can access it later without worrying that
> Linux will try to allocate it)? Should I be calling
>
> lmb_reserve(lmb_end_of_DRAM() - size, size);
>
> in early_reserve_mem() or is there a better mechanism?
The device-tree blob contains a special "reserve map" in the header,
which automatically turns into calls to lmb_reserve() early during boot,
so putting your special region in that map should be the right way to do
what you want without special code.
> For comparison, in an older kernel this was done in set_phys_avail(), by
> calling mem_pieces_remove(&phys_avail, total_lowmem - size, size, 1);
Cheers,
Ben.
> Thanks,
>
> Chris
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* PPCboot and latest kernel
From: vijay sharma @ 2009-07-19 18:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <e571380d0907191132u3985423aiacc7ec8c75c0534b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]
Hi ALL,
I have been woking on upgrading an embedded system based on MPC8241 from
2.4.17 linux to 2.6.30 kernel.
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
Linux/PowerPC load:
Finalizing device tree... flat tree at 0x2f65300 <== Beyond this point no
output is available.
(The size of image is 20MB because ramfs embedded inside the image)
==================================
Here are the steps I have taken till now.
1) Defined platform.dts file for my platform. Since I am using MPC8241, I
have taken cuboot-824x.c. Is this file correct.
Do I need to define my own cuboot-*.c file ?
2)Built cuImage and loaded it into memory. I am not seeing any output once
control passes from wrapper to kernel. As you can see from logs mentioned
above.
While going through mail achieves I found two possible reasons for this
1) Wrong entries inside dts file
I am sure serial attributes are correctly defined inside the file. Also it
works for wrapper. It should work for linux also.
2) PPCboot not providing information.
I have built cuImage . Shouldn't kernel be getting its attributes from dtb
file rather then depending on bd_info structure.
I cannot upgrade to uboot. Is there some way I can make my board come up?
Thanks in advance,
Vijay
[-- Attachment #2: Type: text/html, Size: 2603 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/mpic: Fix MPIC_BROKEN_REGREAD on non broken MPICs
From: Olof Johansson @ 2009-07-19 15:08 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <6c9c0889feaceeea55bd2b6fef0c19e408425ef5.1246846125.git.michael@ellerman.id.au>
On Mon, Jul 06, 2009 at 12:08:52PM +1000, Michael Ellerman wrote:
> The workaround enabled by CONFIG_MPIC_BROKEN_REGREAD does not work
> on non-broken MPICs. The symptom is no interrupts being received.
>
> The fix is twofold. Firstly the code was broken for multiple isus,
> we need to index into the shadow array with the src_no, not the idx.
> Secondly, we always do the read, but only use the VECPRI_MASK and
> VECPRI_ACTIVITY bits from the hardware, the rest of "val" comes
> from the shadow.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Olof Johansson <olof@lixom.net>
Tested OK here on an electra. Thanks for fixing this!
-Olof
^ permalink raw reply
* ethtool support in ethernet driver
From: Mohd Arif @ 2009-07-19 11:42 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]
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.
Where do i need to make changes in the driver?
I have never been into driver stuff.
So kindly suggest me accordingly.
Best Regards,
Mohd. Arif
DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended
for the named recipient(s) only.
It shall not attach any liability on the originator or NECHCL or its
affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the
opinions of NECHCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of
this message without the prior written consent of the author of this e-mail is
strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. .
-----------------------------------------------------------------------------------------------------------------------
[-- Attachment #2: Type: text/html, Size: 2329 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/4] net: Revive fixed link support
From: Grant Likely @ 2009-07-18 18:37 UTC (permalink / raw)
To: avorontsov; +Cc: leoli, netdev, linuxppc-dev, afleming, davem
In-Reply-To: <20090718180448.GA3252@oksana.dev.rtsoft.ru>
On Sat, Jul 18, 2009 at 12:04 PM, Anton
Vorontsov<avorontsov@ru.mvista.com> wrote:
> On Fri, Jul 17, 2009 at 01:31:25AM -0600, Grant Likely wrote:
> [...]
>> Part of the problem I think is that the phylib code merges two separate
>> constructs; the construct of an MDIO bus (on which many device may
>> reside, not all of them PHYs), and the construct of an MII link whose
>> speed and configuration need to be manipulated. =A0I've run into problem=
s
>> myself on how best to handle things like Ethernet switches which
>> definitely do not behave like PHYs and the phylib state machine cannot
>> be used on them. =A0It seems to me that the whole 'dummy phy' approach
>> is just an artifact of the phylib model not being quite right yet.
>
> Yep. With a bit of phylib rework we can remove all the MDIO emulation
> stuff from phy/fixed.c driver, and leave there just speed/duplex/pause
> assignments.
>
> Though, I still believe that we should avoid two code paths in the
> drivers. One of the code paths will be constantly broken if we do so.
Yes, I agree. Splitting the concepts also has the added advantage
that non-phy devices will have an interface to manipulate the link
speed without modifying drivers.
>> Anton, once again I don't have hardware to test this, so I rely on you
>> to tell be if I screwed it up. =A0It has been compile tested.
>
> Works fine here, thanks!
Awesome. Dave, can you please pick up this series?
Thanks,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2 0/4] net: Revive fixed link support
From: Anton Vorontsov @ 2009-07-18 18:04 UTC (permalink / raw)
To: Grant Likely; +Cc: leoli, netdev, linuxppc-dev, afleming, davem
In-Reply-To: <20090717065220.15652.93331.stgit@localhost.localdomain>
On Fri, Jul 17, 2009 at 01:31:25AM -0600, Grant Likely wrote:
[...]
> Part of the problem I think is that the phylib code merges two separate
> constructs; the construct of an MDIO bus (on which many device may
> reside, not all of them PHYs), and the construct of an MII link whose
> speed and configuration need to be manipulated. I've run into problems
> myself on how best to handle things like Ethernet switches which
> definitely do not behave like PHYs and the phylib state machine cannot
> be used on them. It seems to me that the whole 'dummy phy' approach
> is just an artifact of the phylib model not being quite right yet.
Yep. With a bit of phylib rework we can remove all the MDIO emulation
stuff from phy/fixed.c driver, and leave there just speed/duplex/pause
assignments.
Though, I still believe that we should avoid two code paths in the
drivers. One of the code paths will be constantly broken if we do so.
> I
> want to investigate the possibility of separating the two concepts, but
> that will require a fair bit of thought and experimentation.
That would be great indeed.
[...]
> Anton, once again I don't have hardware to test this, so I rely on you
> to tell be if I screwed it up. It has been compile tested.
Works fine here, thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Simple question about powerpc asm.
From: Valentine @ 2009-07-18 13:55 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: HongWoo Lee, linuxppc-dev
In-Reply-To: <20090718125452.3760D832E416@gemini.denx.de>
Wolfgang Denk wrote:
> Dear Valentine,
>
> In message <4A61A48D.8060601@ru.mvista.com> you wrote:
>> PowerPC instructions are 32-bit long. So, there are only 16 bits
>> available within the instruction for constant values. Since address can
>> be up to 64 bits, we have to load it a piece at a time. The "@" within
>> the assembler instruct it to give a specially-processed form of a symbol
>> value:
>>
>> @highest -- refers to bits 48-63 of a constant
>> @higher -- refers to bits 32-47 of a constant
>> @h -- refers to bits 16-31 of a constant
>> @l -- refers to bits 0-15 of a constant
>
> Actually these bit numbers are wrong, as bit 0 is the MSB for PowerPC
> ;-)
All right, you got me ;)
Even copy-pasting from the IBM docs, one has to double-check :)
Regards,
Val.
>
> Best regards,
>
> Wolfgang Denk
>
^ 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