* Re: [PATCH v3] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: David Miller @ 2009-07-22 16:40 UTC (permalink / raw)
To: mware; +Cc: netdev, linuxppc-dev
In-Reply-To: <4A66400F.3090309@elphinstone.net>
From: Mark Ware <mware@elphinstone.net>
Date: Wed, 22 Jul 2009 08:24:15 +1000
> Changes to the fs_enet driver
> (aa73832c5a80d6c52c69b18af858d88fa595dd3c) cause kernel crashes when
> using the mdio-ofgpio driver.
>
> This patch replicates similar changes made to the fs_enet mii-bitbang
> drivers. It has been tested on a custom mpc8280 based board using an
> NFS mounted root.
>
> Signed-off-by: Mark Ware <mware@elphinstone.net>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
Your email client has massively corrupted this patch, I even tried
to fix it up but it's so bad that I just gave up half-way through.
Please use an attachment or whatever is necessary to get this
patch submitted cleanly and without it getting damaged. Read:
linux/Documentation/email-clients.txt
for tips.
Thanks.
^ permalink raw reply
* Re: [LTP] msgctl10 fails on Powerpc Linux-2.6.29.6
From: srikanth krishnakar @ 2009-07-22 16:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev, Ltp-list
In-Reply-To: <578FBC09-589D-4691-82FF-985FCFE8ADC9@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]
On Wed, Jul 22, 2009 at 9:14 PM, Kumar Gala <galak@kernel.crashing.org>wrote:
>
> On Jul 22, 2009, at 10:38 AM, srikanth krishnakar wrote:
>
>
>>
>> On Wed, Jul 22, 2009 at 8:52 PM, Kumar Gala <galak@kernel.crashing.org>
>> wrote:
>> I'm not seeing any BUG* in traps.c @ line 904.
>>
>>
>> On Jul 21, 2009, at 4:33 AM, srikanth krishnakar wrote:
>>
>> 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]
>>
>> I'm not seeing any BUG* in traps.c @ line 904. Do you have some other
>> patches on top of 2.6.29.6?
>>
>> - k
>>
>>
>> I have LTTng patches on top of linux-2.6.29.6.
>>
>
> Does it modify traps.c? Can you see what the code around line 904 looks
> like and post that.
>
> - k
>
896
897 #if defined(CONFIG_XILINX_VIRTEX_5_FXT) && defined(CONFIG_PPC_FPU)
898 if (reason & REASON_ILLEGAL) {
899 if (excep_state < 1) {
900 excep_state++;
901 return;
902 }
903 /* should never get here */
904 BUG();
905 }
906 #endif
907
908 /* Try to emulate it if we should. */
--
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 2104 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
From: Linus Torvalds @ 2009-07-22 16:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Nick Piggin, Linux-Arch, linuxppc-dev, Hugh Dickins, linux-kernel,
Linux Memory Management
In-Reply-To: <1248073873.13067.31.camel@pasglop>
On Mon, 20 Jul 2009, 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)
Maybe you can put it as a separate branch in -next, and have it merged
before the stuff that depends on it, and then just sending it to me (as a
git branch or patch or whatever) in the first day of the merge window?
Linus
^ permalink raw reply
* Re: [PATCH v2 0/4] net: Revive fixed link support
From: David Miller @ 2009-07-22 16:20 UTC (permalink / raw)
To: grant.likely; +Cc: leoli, netdev, afleming, linuxppc-dev
In-Reply-To: <fa686aa40907181137v4a0ed1ednfed3194d1308296a@mail.gmail.com>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Sat, 18 Jul 2009 12:37:34 -0600
> Awesome. Dave, can you please pick up this series?
Sure thing.
^ permalink raw reply
* Re: [LTP] msgctl10 fails on Powerpc Linux-2.6.29.6
From: Kumar Gala @ 2009-07-22 15:44 UTC (permalink / raw)
To: srikanth krishnakar; +Cc: Linuxppc-dev, Ltp-list
In-Reply-To: <6213bc560907220838h49e5c273qa543e538bb37923a@mail.gmail.com>
On Jul 22, 2009, at 10:38 AM, srikanth krishnakar wrote:
>
>
> On Wed, Jul 22, 2009 at 8:52 PM, Kumar Gala
> <galak@kernel.crashing.org> wrote:
> I'm not seeing any BUG* in traps.c @ line 904.
>
>
> On Jul 21, 2009, at 4:33 AM, srikanth krishnakar wrote:
>
> 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]
>
> I'm not seeing any BUG* in traps.c @ line 904. Do you have some
> other patches on top of 2.6.29.6?
>
> - k
>
>
> I have LTTng patches on top of linux-2.6.29.6.
Does it modify traps.c? Can you see what the code around line 904
looks like and post that.
- k
^ permalink raw reply
* Re: [LTP] msgctl10 fails on Powerpc Linux-2.6.29.6
From: srikanth krishnakar @ 2009-07-22 15:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev, Ltp-list
In-Reply-To: <2A0DDADE-5C3C-43F2-9487-98A8A735DC8D@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 702 bytes --]
On Wed, Jul 22, 2009 at 8:52 PM, Kumar Gala <galak@kernel.crashing.org>wrote:
> I'm not seeing any BUG* in traps.c @ line 904.
>
> On Jul 21, 2009, at 4:33 AM, srikanth krishnakar wrote:
>
> 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]
>>
>
> I'm not seeing any BUG* in traps.c @ line 904. Do you have some other
> patches on top of 2.6.29.6?
>
> - k
>
>
I have LTTng patches on top of linux-2.6.29.6.
--
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 1257 bytes --]
^ permalink raw reply
* [PATCH] powerpc: update wrapper to point to the new location of dtc
From: Lucian Adrian Grijincu @ 2009-07-22 15:20 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 334 bytes --]
dtc was moved in 9fffb55f66127b52c937ede5196ebfa0c0d50bce from
arch/powerpc/boot/ to scripts/dtc/
This patch updates the wrapper script to point to the new location of dtc.
Signed-off-by: Lucian Adrian Grijincu <lgrijincu@ixiacom.com>
---
arch/powerpc/boot/wrapper | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
[-- Attachment #2: 0001-powerpc-update-wrapper-to-point-to-the-new-location-.patch --]
[-- Type: text/x-patch, Size: 572 bytes --]
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index e964489..c907540 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -46,6 +46,7 @@ CROSS=
# directory for object and other files used by this script
object=arch/powerpc/boot
objbin=$object
+dtc=scripts/dtc/dtc
# directory for working files
tmpdir=.
@@ -124,7 +125,7 @@ if [ -n "$dts" ]; then
if [ -z "$dtb" ]; then
dtb="$platform.dtb"
fi
- $object/dtc -O dtb -o "$dtb" -b 0 "$dts"
+ $dtc -O dtb -o "$dtb" -b 0 "$dts"
fi
if [ -z "$kernel" ]; then
^ permalink raw reply related
* Re: [LTP] msgctl10 fails on Powerpc Linux-2.6.29.6
From: Kumar Gala @ 2009-07-22 15:22 UTC (permalink / raw)
To: srikanth krishnakar; +Cc: Linuxppc-dev, Ltp-list
In-Reply-To: <6213bc560907210233l17aa3e75pcb7c20e3faa24195@mail.gmail.com>
I'm not seeing any BUG* in traps.c @ line 904.
On Jul 21, 2009, at 4:33 AM, srikanth krishnakar wrote:
> 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]
I'm not seeing any BUG* in traps.c @ line 904. Do you have some other
patches on top of 2.6.29.6?
- k
^ permalink raw reply
* Re: [PATCH] powerpc/cell: replace strncpy by strlcpy
From: Ken Kawakami @ 2009-07-22 4:22 UTC (permalink / raw)
To: roel.kluin; +Cc: linuxppc-dev, akpm, cbe-oss-dev, arnd
In-Reply-To: <4A6595AD.9000209@gmail.com>
Arnd-san, Roel-san,
It works fine. Thanks.
---
Regards,
Ken Kawakami
> Replace strncpy() and explicit null-termination by strlcpy()
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> Arnd-san, Ken-san,
>
> Thanks for reviewing,
>
> > We prefer to take the patch which is replacing the two lines with one.
>
> Doozo.
>
> diff --git a/arch/powerpc/platforms/cell/celleb_setup.c b/arch/powerpc/platforms/cell/celleb_setup.c
> index 07c234f..e538455 100644
> --- a/arch/powerpc/platforms/cell/celleb_setup.c
> +++ b/arch/powerpc/platforms/cell/celleb_setup.c
> @@ -80,8 +80,7 @@ static void celleb_show_cpuinfo(struct seq_file *m)
>
> static int __init celleb_machine_type_hack(char *ptr)
> {
> - strncpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
> - celleb_machine_type[sizeof(celleb_machine_type)-1] = 0;
> + strlcpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
> return 0;
> }
>
>
^ permalink raw reply
* [PATCH 5/7] [powerpc] ARRAY_SIZE changes
From: Stoyan Gaydarov @ 2009-07-22 3:02 UTC (permalink / raw)
To: linux-kernel; +Cc: Stoyan Gaydarov, paulus, linuxppc-dev
In-Reply-To: <1248231753-8344-5-git-send-email-sgayda2@uiuc.edu>
These changes were a direct result of using a semantic patch
More information can be found at http://www.emn.fr/x-info/coccinelle/
Signed-off-by: Stoyan Gaydarov <sgayda2@uiuc.edu>
---
arch/powerpc/platforms/pasemi/idle.c | 2 +-
arch/powerpc/platforms/powermac/feature.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/pasemi/idle.c b/arch/powerpc/platforms/pasemi/idle.c
index 43911d8..75b296b 100644
--- a/arch/powerpc/platforms/pasemi/idle.c
+++ b/arch/powerpc/platforms/pasemi/idle.c
@@ -90,7 +90,7 @@ machine_late_initcall(pasemi, pasemi_idle_init);
static int __init idle_param(char *p)
{
int i;
- for (i = 0; i < sizeof(modes)/sizeof(struct sleep_mode); i++) {
+ for (i = 0; i < ARRAY_SIZE(modes); i++) {
if (!strcmp(modes[i].name, p)) {
current_mode = i;
break;
diff --git a/arch/powerpc/platforms/powermac/feature.c b/arch/powerpc/platforms/powermac/feature.c
index e6c0040..095de32 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -2419,13 +2419,13 @@ static int __init probe_motherboard(void)
dt = of_find_node_by_name(NULL, "device-tree");
if (dt != NULL)
model = of_get_property(dt, "model", NULL);
- for(i=0; model && i<(sizeof(pmac_mb_defs)/sizeof(struct pmac_mb_def)); i++) {
+ for(i=0; model && i<ARRAY_SIZE(pmac_mb_defs); i++) {
if (strcmp(model, pmac_mb_defs[i].model_string) == 0) {
pmac_mb = pmac_mb_defs[i];
goto found;
}
}
- for(i=0; i<(sizeof(pmac_mb_defs)/sizeof(struct pmac_mb_def)); i++) {
+ for(i=0; i<ARRAY_SIZE(pmac_mb_defs); i++) {
if (machine_is_compatible(pmac_mb_defs[i].model_string)) {
pmac_mb = pmac_mb_defs[i];
goto found;
--
1.6.3.3
^ permalink raw reply related
* [PATCH] powerpc/mm: Fix definitions of FORCE_MAX_ZONEORDER in Kconfig
From: Benjamin Herrenschmidt @ 2009-07-22 1:25 UTC (permalink / raw)
To: linuxppc-dev
The current definitions set ranges and defaults for 32 and 64-bit
only using "PPC_STD_MMU" which means hash based MMU. This uselessly
restrict the usefulness for the upcoming 64-bit BookE port, but more
than that, it's broken on 32-bit since the only 32-bit platform
supporting multiple page sizes currently is 44x which does -not-
have PPC_STD_MMU_32 set.
This fixes it by using PPC64 and PPC32 instead.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/Kconfig | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- linux-work.orig/arch/powerpc/Kconfig 2009-07-22 11:22:16.000000000 +1000
+++ linux-work/arch/powerpc/Kconfig 2009-07-22 11:22:39.000000000 +1000
@@ -492,16 +492,16 @@ endchoice
config FORCE_MAX_ZONEORDER
int "Maximum zone order"
- range 9 64 if PPC_STD_MMU_64 && PPC_64K_PAGES
- default "9" if PPC_STD_MMU_64 && PPC_64K_PAGES
- range 13 64 if PPC_STD_MMU_64 && !PPC_64K_PAGES
- default "13" if PPC_STD_MMU_64 && !PPC_64K_PAGES
- range 9 64 if PPC_STD_MMU_32 && PPC_16K_PAGES
- default "9" if PPC_STD_MMU_32 && PPC_16K_PAGES
- range 7 64 if PPC_STD_MMU_32 && PPC_64K_PAGES
- default "7" if PPC_STD_MMU_32 && PPC_64K_PAGES
- range 5 64 if PPC_STD_MMU_32 && PPC_256K_PAGES
- default "5" if PPC_STD_MMU_32 && PPC_256K_PAGES
+ range 9 64 if PPC64 && PPC_64K_PAGES
+ default "9" if PPC64 && PPC_64K_PAGES
+ range 13 64 if PPC64 && !PPC_64K_PAGES
+ default "13" if PPC64 && !PPC_64K_PAGES
+ range 9 64 if PPC32 && PPC_16K_PAGES
+ default "9" if PPC32 && PPC_16K_PAGES
+ range 7 64 if PPC32 && PPC_64K_PAGES
+ default "7" if PPC32 && PPC_64K_PAGES
+ range 5 64 if PPC32 && PPC_256K_PAGES
+ default "5" if PPC32 && PPC_256K_PAGES
range 11 64
default "11"
help
^ permalink raw reply
* [PATCH v3] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: Mark Ware @ 2009-07-21 22:24 UTC (permalink / raw)
To: Grant Likely, netdev, Linuxppc-dev Development
Changes to the fs_enet driver (aa73832c5a80d6c52c69b18af858d88fa595dd3c) cause kernel crashes when using the mdio-ofgpio driver.
This patch replicates similar changes made to the fs_enet mii-bitbang drivers. It has been tested on a custom mpc8280 based board using an NFS
mounted root.
Signed-off-by: Mark Ware <mware@elphinstone.net>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
The only changes in v3 are to the commit message.
drivers/net/phy/mdio-gpio.c | 77 ++++++++++++++++++++-----------------------
1 files changed, 36 insertions(+), 41 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index 33984b7..22cdd45 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -30,6 +30,7 @@
#ifdef CONFIG_OF_GPIO
#include <linux/of_gpio.h>
+#include <linux/of_mdio.h>
#include <linux/of_platform.h>
#endif
@@ -81,13 +82,12 @@ static struct mdiobb_ops mdio_gpio_ops = {
.get_mdio_data = mdio_get,
};
-static int __devinit mdio_gpio_bus_init(struct device *dev,
+static struct mii_bus * __devinit mdio_gpio_bus_init(struct device *dev,
struct mdio_gpio_platform_data *pdata,
int bus_id)
{
struct mii_bus *new_bus;
struct mdio_gpio_info *bitbang;
- int ret = -ENOMEM;
int i;
bitbang = kzalloc(sizeof(*bitbang), GFP_KERNEL);
@@ -104,8 +104,6 @@ static int __devinit mdio_gpio_bus_init(struct device *dev,
new_bus->name = "GPIO Bitbanged MDIO",
- ret = -ENODEV;
-
new_bus->phy_mask = pdata->phy_mask;
new_bus->irq = pdata->irqs;
new_bus->parent = dev;
@@ -129,15 +127,8 @@ static int __devinit mdio_gpio_bus_init(struct device *dev,
dev_set_drvdata(dev, new_bus);
- ret = mdiobus_register(new_bus);
- if (ret)
- goto out_free_all;
-
- return 0;
+ return new_bus;
-out_free_all:
- dev_set_drvdata(dev, NULL);
- gpio_free(bitbang->mdio);
out_free_mdc:
gpio_free(bitbang->mdc);
out_free_bus:
@@ -145,30 +136,47 @@ out_free_bus:
out_free_bitbang:
kfree(bitbang);
out:
- return ret;
+ return NULL;
}
-static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+static void __devinit mdio_gpio_bus_deinit(struct device *dev)
{
struct mii_bus *bus = dev_get_drvdata(dev);
struct mdio_gpio_info *bitbang = bus->priv;
- mdiobus_unregister(bus);
- free_mdio_bitbang(bus);
dev_set_drvdata(dev, NULL);
- gpio_free(bitbang->mdc);
gpio_free(bitbang->mdio);
+ gpio_free(bitbang->mdc);
+ free_mdio_bitbang(bus);
kfree(bitbang);
}
+static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+{
+ struct mii_bus *bus = dev_get_drvdata(dev);
+
+ mdiobus_unregister(bus);
+ mdio_gpio_bus_deinit(dev);
+}
+
static int __devinit mdio_gpio_probe(struct platform_device *pdev)
{
struct mdio_gpio_platform_data *pdata = pdev->dev.platform_data;
+ struct mii_bus *new_bus;
+ int ret;
if (!pdata)
return -ENODEV;
- return mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id);
+ new_bus = mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id);
+ if (!new_bus)
+ return -ENODEV;
+
+ ret = mdiobus_register(new_bus);
+ if (ret)
+ mdio_gpio_bus_deinit(&pdev->dev);
+
+ return ret;
}
static int __devexit mdio_gpio_remove(struct platform_device *pdev)
@@ -179,29 +187,12 @@ static int __devexit mdio_gpio_remove(struct platform_device *pdev)
}
#ifdef CONFIG_OF_GPIO
-static void __devinit add_phy(struct mdio_gpio_platform_data *pdata,
- struct device_node *np)
-{
- const u32 *data;
- int len, id, irq;
-
- data = of_get_property(np, "reg", &len);
- if (!data || len != 4)
- return;
-
- id = *data;
- pdata->phy_mask &= ~(1 << id);
-
- irq = of_irq_to_resource(np, 0, NULL);
- if (irq)
- pdata->irqs[id] = irq;
-}
static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
- struct device_node *np = NULL;
struct mdio_gpio_platform_data *pdata;
+ struct mii_bus *new_bus;
int ret;
pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
@@ -215,14 +206,18 @@ static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
ret = of_get_gpio(ofdev->node, 1);
if (ret < 0)
- goto out_free;
+ goto out_free;
pdata->mdio = ret;
- while ((np = of_get_next_child(ofdev->node, np)))
- if (!strcmp(np->type, "ethernet-phy"))
- add_phy(pdata, np);
+ new_bus = mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
+ if (!new_bus)
+ return -ENODEV;
- return mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
+ ret = of_mdiobus_register(new_bus, ofdev->node);
+ if (ret)
+ mdio_gpio_bus_deinit(&ofdev->dev);
+
+ return ret;
out_free:
kfree(pdata);
--
1.5.6.5
^ permalink raw reply related
* mpc5121 Power Managment errata.
From: Kenneth Johansson @ 2009-07-21 17:16 UTC (permalink / raw)
To: Linuxppc-dev Development
[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]
I have a bit of a problem with arch/powerpc/platforms/512x/mpc512x_pm.c
Since this one is not included in mainline (yet) I have attached it
Now I have a number of questions and one mystery.
1: why relocate the code ?? is there a reason why the code must be
located at address 0
http://www.bitshrine.org/gpp/linux-2.6.24.6-mpc5121-99-PM-alternate-external-int-vector.patch
say that this is due to a bug in the PMC module with status bits. Could
this not be worked around by avoiding modifying the exception handler
and just taken care of by C code in ipic.c
2: does it work ???
I ask since it do self modifying code but no invalidation of the
instruction cache.
Mystery: If I fix the cache issue with the code and force store of data
with dcbst and invalidate with icbi. I get a very unreliable resume
function that often end up in machine check all over the place
This machine check also happens on unmodified version but much much more
seldom. I'm just now running some test on a system that only patch this
in once and thus always run with this workaround without constantly
modifying the exception handler . but I wont know if it makes a
difference until tomorrow.
I have inserted this code in the end of both
mpc5121_copy_pmcclr
mpc5121_reinstall_handler
Is there some reason why this would not work ??
-----------------------------------------
/*
dcbst |update memory
sync |wait for update
icbi |remove (invalidate) copy in instruction cache
isync |remove copy in own instruction buffer
*/
lis r3, CONFIG_KERNEL_START@h
ori r3, r3, CONFIG_KERNEL_START@l
/* flush and invalidate from 0 to 0x600 */
li r5, 0x0
li r4, 0x600/L1_CACHE_BYTES
mtctr r4
1:
dcbst r5,r3
sync
icbi r5,r3
isync
addi r5, r5, L1_CACHE_BYTES /* Next line, please */
bdnz 1b
sync
isync
[-- Attachment #2: mpc512x.S --]
[-- Type: text/x-csrc, Size: 2854 bytes --]
#include <asm/reg.h>
#include <asm/ppc_asm.h>
#include <asm/processor.h>
#include <asm/page.h>
#include <asm/cache.h>
#define NUM_CACHE_LINES (128*8)
/* this variable added to reserve 0x20*4 bytes.
* This value has been derived by counting the
* number of lines of the function "code_atzero".
* In case if the size of this function increases
* the number of bytes have to increased accordi-
* ngly.
*/
.data
mpc5121_data_temp:
.space 0x20*4
.text
.globl mpc5121_copy_pmcclr
mpc5121_copy_pmcclr:
/* Coming here with interrupts disabled */
/* storing the content at 0x0 location
* to mpc512_data_temp space */
lis r6, CONFIG_KERNEL_START@h
mr r4, r6
li r3, (code_atzero_end - code_atzero)/4
mtctr r3
lis r3, mpc5121_data_temp@h
ori r3, r3, mpc5121_data_temp@l
/* loops here till the counter is zero */
loop:
lwz r5, 0(r4)
stw r5, 0(r3)
addi r3, r3, 4
addi r4, r4, 4
bdnz loop
/* Copy code to Location 0x0 */
mr r4, r6
li r3, (code_atzero_end - code_atzero)/4
mtctr r3
lis r3, code_atzero@h
ori r3, r3, code_atzero@l
1:
lwz r5, 0(r3)
stw r5, 0(r4)
addi r3, r3, 4
addi r4, r4, 4
bdnz 1b
/* Copy the jump to 0x0 code at 0x500*/
lwz r5, 0x500(r6)
stw r5, 0(r6)
lwz r5, 8(r6)
stw r5, 0x500(r6)
/* Flush the cache */
lis r3, CONFIG_KERNEL_START@h
ori r3, r3, CONFIG_KERNEL_START@l
/* Let us load data starting from 0x600 loc */
addi r3, r3, 0x600
li r4, NUM_CACHE_LINES
mtctr r4
1:
lwz r4, 0(r3)
addi r3, r3, L1_CACHE_BYTES /* Next line, please */
bdnz 1b
sync; isync
blr
.globl mpc5121_reinstall_handler
mpc5121_reinstall_handler:
/* Rewrite original code at 0x500 */
lis r6, CONFIG_KERNEL_START@h
lwz r5, 0(r6)
stw r5, 0x500(r6)
/* restoring content at 0x0 location */
mr r4, r6
li r3, (code_atzero_end - code_atzero)/4
mtctr r3
lis r3, mpc5121_data_temp@h
ori r3, r3, mpc5121_data_temp@l
/* loops here till the counter is zero */
loop1:
lwz r5, 0(r3)
stw r5, 0(r4)
addi r3, r3, 4
addi r4, r4, 4
bdnz loop1
blr
code_atzero:
.long 0x0 /*Space reserved for copying first word of code from 0x500 */
ba 0x504
ba 0xc /* This code is not executed. This code is copied to 0x500 */
mtspr SPRN_SPRG0, r3
mtspr SPRN_SPRG1, r4
mfspr r3, 311
addi r3, r3, 0x1000 /* Assuming that MBAR is aligned to this size */
lwz r4, 0x4(r3)
stw r4, 0x4(r3)
/* clearing GPIO evnet registers */
mfspr r3, 311
/* getting offset of GPIO */
addi r3, r3,0x1100
lwz r4, 0xC(r3)
stw r4, 0xC(r3)
mfspr r3, SPRN_SPRG0
mfspr r4, SPRN_SPRG1
ba 0x0
code_atzero_end:
b code_atzero_end /* Should never reach here*/
^ permalink raw reply
* Re: [PATCH v2] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: Grant Likely @ 2009-07-21 17:09 UTC (permalink / raw)
To: Mark Ware; +Cc: netdev, David Miller, linuxppc-dev
In-Reply-To: <4A658F69.7020002@elphinstone.net>
On Tue, Jul 21, 2009 at 3:50 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 replicates similar changes made to the fs_enet
> mii-bitbang drivers.
This looks good to me. I've not tested it though (no hardware that
uses it). You should specify the testing you've done in the commit
log. Your signed-off-by: line is also missing.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
David, once the above issues are solved, this one needs to be merged for 2.=
6.31.
Cheers,
g.
> ---
>
> This version attempts to address Grant's comments below:
>
> Grant Likely wrote:
>>
>> 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. =A0Then mdio_gpio_probe() and mdio_ofgpio_probe()
>> can call the correct register variant directly. =A0Fewer ugly #ifdefs
>> this way. =A0It also eliminates the need to cast the void* pointer.
>>
>
> =A0drivers/net/phy/mdio-gpio.c | =A0 77
> ++++++++++++++++++++-----------------------
> =A01 files changed, 36 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
> index 33984b7..22cdd45 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
>
> @@ -81,13 +82,12 @@ static struct mdiobb_ops mdio_gpio_ops =3D {
> =A0 =A0 =A0 =A0.get_mdio_data =3D mdio_get,
> =A0};
>
> -static int __devinit mdio_gpio_bus_init(struct device *dev,
> +static struct mii_bus * __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 =A0int bus_id)
> =A0{
> =A0 =A0 =A0 =A0struct mii_bus *new_bus;
> =A0 =A0 =A0 =A0struct mdio_gpio_info *bitbang;
> - =A0 =A0 =A0 int ret =3D -ENOMEM;
> =A0 =A0 =A0 =A0int i;
>
> =A0 =A0 =A0 =A0bitbang =3D kzalloc(sizeof(*bitbang), GFP_KERNEL);
> @@ -104,8 +104,6 @@ static int __devinit mdio_gpio_bus_init(struct device
> *dev,
>
> =A0 =A0 =A0 =A0new_bus->name =3D "GPIO Bitbanged MDIO",
>
> - =A0 =A0 =A0 ret =3D -ENODEV;
> -
> =A0 =A0 =A0 =A0new_bus->phy_mask =3D pdata->phy_mask;
> =A0 =A0 =A0 =A0new_bus->irq =3D pdata->irqs;
> =A0 =A0 =A0 =A0new_bus->parent =3D dev;
> @@ -129,15 +127,8 @@ 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);
> - =A0 =A0 =A0 if (ret)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out_free_all;
> -
> - =A0 =A0 =A0 return 0;
> + =A0 =A0 =A0 return new_bus;
>
> -out_free_all:
> - =A0 =A0 =A0 dev_set_drvdata(dev, NULL);
> - =A0 =A0 =A0 gpio_free(bitbang->mdio);
> =A0out_free_mdc:
> =A0 =A0 =A0 =A0gpio_free(bitbang->mdc);
> =A0out_free_bus:
> @@ -145,30 +136,47 @@ out_free_bus:
> =A0out_free_bitbang:
> =A0 =A0 =A0 =A0kfree(bitbang);
> =A0out:
> - =A0 =A0 =A0 return ret;
> + =A0 =A0 =A0 return NULL;
> =A0}
>
> -static void __devexit mdio_gpio_bus_destroy(struct device *dev)
> +static void __devinit mdio_gpio_bus_deinit(struct device *dev)
> =A0{
> =A0 =A0 =A0 =A0struct mii_bus *bus =3D dev_get_drvdata(dev);
> =A0 =A0 =A0 =A0struct mdio_gpio_info *bitbang =3D bus->priv;
>
> - =A0 =A0 =A0 mdiobus_unregister(bus);
> - =A0 =A0 =A0 free_mdio_bitbang(bus);
> =A0 =A0 =A0 =A0dev_set_drvdata(dev, NULL);
> - =A0 =A0 =A0 gpio_free(bitbang->mdc);
> =A0 =A0 =A0 =A0gpio_free(bitbang->mdio);
> + =A0 =A0 =A0 gpio_free(bitbang->mdc);
> + =A0 =A0 =A0 free_mdio_bitbang(bus);
> =A0 =A0 =A0 =A0kfree(bitbang);
> =A0}
>
> +static void __devexit mdio_gpio_bus_destroy(struct device *dev)
> +{
> + =A0 =A0 =A0 struct mii_bus *bus =3D dev_get_drvdata(dev);
> +
> + =A0 =A0 =A0 mdiobus_unregister(bus);
> + =A0 =A0 =A0 mdio_gpio_bus_deinit(dev);
> +}
> +
> =A0static int __devinit mdio_gpio_probe(struct platform_device *pdev)
> =A0{
> =A0 =A0 =A0 =A0struct mdio_gpio_platform_data *pdata =3D pdev->dev.platfo=
rm_data;
> + =A0 =A0 =A0 struct mii_bus *new_bus;
> + =A0 =A0 =A0 int ret;
>
> =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 new_bus =3D mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id)=
;
> + =A0 =A0 =A0 if (!new_bus)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
> +
> + =A0 =A0 =A0 ret =3D mdiobus_register(new_bus);
> + =A0 =A0 =A0 if (ret)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mdio_gpio_bus_deinit(&pdev->dev);
> +
> + =A0 =A0 =A0 return ret;
> =A0}
>
> =A0static int __devexit mdio_gpio_remove(struct platform_device *pdev)
> @@ -179,29 +187,12 @@ 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 struct mii_bus *new_bus;
> =A0 =A0 =A0 =A0int ret;
>
> =A0 =A0 =A0 =A0pdata =3D kzalloc(sizeof(*pdata), GFP_KERNEL);
> @@ -215,14 +206,18 @@ static int __devinit mdio_ofgpio_probe(struct
> of_device *ofdev,
>
> =A0 =A0 =A0 =A0ret =3D of_get_gpio(ofdev->node, 1);
> =A0 =A0 =A0 =A0if (ret < 0)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out_free;
> + =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 new_bus =3D mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->m=
dc);
> + =A0 =A0 =A0 if (!new_bus)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
>
> - =A0 =A0 =A0 return mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
> + =A0 =A0 =A0 ret =3D of_mdiobus_register(new_bus, ofdev->node);
> + =A0 =A0 =A0 if (ret)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mdio_gpio_bus_deinit(&ofdev->dev);
> +
> + =A0 =A0 =A0 return ret;
>
> =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: [PATCH] PowerPC 440EPx: Sequoia bootwrapper
From: Stefan Roese @ 2009-07-21 16:52 UTC (permalink / raw)
To: Bob Burke; +Cc: linuxppc-dev
In-Reply-To: <2C7DE72B9BD00F44BAECA5B0CBB873956CDC46@hermes.terascala.com>
On Tuesday 21 July 2009 17:56:40 Bob Burke wrote:
> On Tue, 21 Jul 2009 16:06:53 Stefan Roese wrote:
> > Unfortunately it's not that easy. Earlier Sequoia board revisions are
> > equipped with an 33.333MHz oscillator. This can be detected via a
> > CPLD register though.
>
> Thanks, I didn't realize that. FYI our deployed platform is similar to
> Sequoia,
> but is a custom design. It has a 33 MHz system clock.
OK. Then you should add a new target for your custom board (cuboot-namexyz.c).
> > But why are you using the boot wrapper? If your U-Boot isn't too old,
> > you can boot uImage directly (with dtb of course). No need for the
> > wrapper.
>
> Since we have deployed product, using a non OF kernel, we have made the
> decision not to upgrade U-Boot in the field.
OK, understood.
Thanks,
Stefan
^ permalink raw reply
* RE: [PATCH] PowerPC 440EPx: Sequoia bootwrapper
From: Bob Burke @ 2009-07-21 15:56 UTC (permalink / raw)
To: Stefan Roese, linuxppc-dev
In-Reply-To: <200907211606.52572.sr@denx.de>
On Tue, 21 Jul 2009 16:06:53 Stefan Roese wrote:
> Unfortunately it's not that easy. Earlier Sequoia board revisions are
> equipped with an 33.333MHz oscillator. This can be detected via a
CPLD
> register though.
Thanks, I didn't realize that. FYI our deployed platform is similar to
Sequoia,
but is a custom design. It has a 33 MHz system clock.
> But why are you using the boot wrapper? If your U-Boot isn't too old,
you can
> boot uImage directly (with dtb of course). No need for the wrapper.
Since we have deployed product, using a non OF kernel, we have made the
decision
not to upgrade U-Boot in the field.
Thanks,
Bob
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx: Sequoia bootwrapper
From: Stefan Roese @ 2009-07-21 14:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Bob Burke
In-Reply-To: <2C7DE72B9BD00F44BAECA5B0CBB873956CDC2B@hermes.terascala.com>
On Tuesday 21 July 2009 15:33:20 Bob Burke wrote:
> The system clock frequency on the Sequoia board is 33.000000 MHz not
> 33.333333 MHz; this causes the system time to drift more than 30 seconds
> per hour.
>
> diff -ruN a/arch/powerpc/boot/cuboot-sequoia.c
> b/arch/powerpc/boot/cuboot-sequoia.c
> --- a/arch/powerpc/boot/cuboot-sequoia.c 2009-05-18
> 19:52:34.000000000 -0400
> +++ b/arch/powerpc/boot/cuboot-sequoia.c 2009-07-21
> 09:13:13.000000000 -0400
> @@ -37,7 +37,7 @@
>
> static void sequoia_fixups(void)
> {
> - unsigned long sysclk = 33333333;
> + unsigned long sysclk = 33000000;
>
> ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
> ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
Unfortunately it's not that easy. Earlier Sequoia board revisions are equipped
with an 33.333MHz oscillator. This can be detected via a CPLD register though.
Here the "code" from U-Boot (just as an example):
/* Detect Sequoia PLL input clock automatically via CPLD bit */
#define CONFIG_SYS_BCSR_BASE 0xc0000000
#define CONFIG_SYS_CLK_FREQ ((in8(CONFIG_SYS_BCSR_BASE + 3) & 0x80) ? \
33333333 : 33000000)
But why are you using the boot wrapper? If your U-Boot isn't too old, you can
boot uImage directly (with dtb of course). No need for the wrapper.
Thanks,
Stefan
^ permalink raw reply
* [PATCH] PowerPC 440EPx: Sequoia bootwrapper
From: Bob Burke @ 2009-07-21 13:33 UTC (permalink / raw)
To: linuxppc-dev
The system clock frequency on the Sequoia board is 33.000000 MHz not
33.333333 MHz; this causes the system time to drift more than 30 seconds
per hour.
diff -ruN a/arch/powerpc/boot/cuboot-sequoia.c
b/arch/powerpc/boot/cuboot-sequoia.c
--- a/arch/powerpc/boot/cuboot-sequoia.c 2009-05-18
19:52:34.000000000 -0400
+++ b/arch/powerpc/boot/cuboot-sequoia.c 2009-07-21
09:13:13.000000000 -0400
@@ -37,7 +37,7 @@
static void sequoia_fixups(void)
{
- unsigned long sysclk =3D 33333333;
+ unsigned long sysclk =3D 33000000;
ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
^ permalink raw reply
* Re: Best hardware platform for native compiling...
From: David Jander @ 2009-07-21 13:07 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev
In-Reply-To: <20090721120007.GA23164@iram.es>
On Tuesday 21 July 2009 14:00:07 you wrote:
> On Tue, Jul 21, 2009 at 12:31:36PM +0200, David Jander wrote:
> > On Tuesday 21 July 2009 11:52:51 you wrote:
> > > On Tue, Jul 21, 2009 at 11:16:52AM +0200, David Jander wrote:
> > > > 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?
> > >
> > > Have a look at the YDL PowerStation:
> > >
> > > http://us.fixstars.com/products/powerstation/
> > >
> > > It is more or less a quad G5.
> >
> > This looks great! Thanks a lot for the tip.
> > I still have to figure out how to get one of these delivered to Europe,
> > but that shouldn't be such a big deal...
>
> Well, I got one recently here in Spain. Shipping charges are fairly
> large (it's not exactly a light and compact machine). But the current
> dollar exchange rate helps ;-)
>
> Now I have not yet found the way to install Debian on it
> (it refuses to boot Debian's CDROM), but I have not had
> time to investigate either.
If nothing else helps, try (manually) installing debootstrap from ubuntu
sources and start from there with "debootstrap jaunty /mnt/partition" ;-)
Best regards,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Re: Best hardware platform for native compiling...
From: Benjamin Herrenschmidt @ 2009-07-21 12:47 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, David Jander
In-Reply-To: <20090721120007.GA23164@iram.es>
On Tue, 2009-07-21 at 14:00 +0200, Gabriel Paubert wrote:
> Well, I got one recently here in Spain. Shipping charges are fairly
> large (it's not exactly a light and compact machine). But the current
> dollar exchange rate helps ;-)
>
> Now I have not yet found the way to install Debian on it
> (it refuses to boot Debian's CDROM), but I have not had
> time to investigate either.
It uses SLOF which should be capable of decent netbooting, so it should
be possible to either netboot yaboot and have it load the kernel and
initramfs, or maybe make a zImage with both included and netboot that.
Cheers,
Ben.
^ permalink raw reply
* Re: Best hardware platform for native compiling...
From: Gabriel Paubert @ 2009-07-21 12:00 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-dev
In-Reply-To: <200907211231.37299.david.jander@protonic.nl>
On Tue, Jul 21, 2009 at 12:31:36PM +0200, David Jander wrote:
> On Tuesday 21 July 2009 11:52:51 you wrote:
> > On Tue, Jul 21, 2009 at 11:16:52AM +0200, David Jander wrote:
> > > 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?
> >
> > Have a look at the YDL PowerStation:
> >
> > http://us.fixstars.com/products/powerstation/
> >
> > It is more or less a quad G5.
>
> This looks great! Thanks a lot for the tip.
> I still have to figure out how to get one of these delivered to Europe, but
> that shouldn't be such a big deal...
Well, I got one recently here in Spain. Shipping charges are fairly
large (it's not exactly a light and compact machine). But the current
dollar exchange rate helps ;-)
Now I have not yet found the way to install Debian on it
(it refuses to boot Debian's CDROM), but I have not had
time to investigate either.
Regards,
Gabriel
^ permalink raw reply
* Re: Best hardware platform for native compiling...
From: David Jander @ 2009-07-21 10:31 UTC (permalink / raw)
To: Adrian Reber; +Cc: linuxppc-dev
In-Reply-To: <20090721095251.GG32034@lisas.de>
On Tuesday 21 July 2009 11:52:51 you wrote:
> On Tue, Jul 21, 2009 at 11:16:52AM +0200, David Jander wrote:
> > 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?
>
> Have a look at the YDL PowerStation:
>
> http://us.fixstars.com/products/powerstation/
>
> It is more or less a quad G5.
This looks great! Thanks a lot for the tip.
I still have to figure out how to get one of these delivered to Europe, but
that shouldn't be such a big deal...
Best regards,
--
David Jander
Protonic Holland.
^ permalink raw reply
* [PATCH] powerpc/cell: replace strncpy by strlcpy
From: Roel Kluin @ 2009-07-21 10:17 UTC (permalink / raw)
To: Ken Kawakami; +Cc: linuxppc-dev, Andrew Morton, cbe-oss-dev, arnd
In-Reply-To: <4A607185.6020302@gmail.com>
Replace strncpy() and explicit null-termination by strlcpy()
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Arnd-san, Ken-san,
Thanks for reviewing,
> We prefer to take the patch which is replacing the two lines with one.
Doozo.
diff --git a/arch/powerpc/platforms/cell/celleb_setup.c b/arch/powerpc/platforms/cell/celleb_setup.c
index 07c234f..e538455 100644
--- a/arch/powerpc/platforms/cell/celleb_setup.c
+++ b/arch/powerpc/platforms/cell/celleb_setup.c
@@ -80,8 +80,7 @@ static void celleb_show_cpuinfo(struct seq_file *m)
static int __init celleb_machine_type_hack(char *ptr)
{
- strncpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
- celleb_machine_type[sizeof(celleb_machine_type)-1] = 0;
+ strlcpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
return 0;
}
^ permalink raw reply related
* [PATCH v2] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: Mark Ware @ 2009-07-21 9:50 UTC (permalink / raw)
To: Grant Likely, netdev, linuxppc-dev
In-Reply-To: <fa686aa40907200759h1e4ec8cfh8a35890127a899a1@mail.gmail.com>
Changes to the fs_enet driver (aa73832c5a80d6c52c69b18af858d88fa595dd3c) cause kernel crashes when using the mdio-ofgpio driver.
The following patch replicates similar changes made to the fs_enet mii-bitbang drivers.
---
This version attempts to address Grant's comments below:
Grant Likely wrote:
>
> 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.
>
drivers/net/phy/mdio-gpio.c | 77 ++++++++++++++++++++-----------------------
1 files changed, 36 insertions(+), 41 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index 33984b7..22cdd45 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -30,6 +30,7 @@
#ifdef CONFIG_OF_GPIO
#include <linux/of_gpio.h>
+#include <linux/of_mdio.h>
#include <linux/of_platform.h>
#endif
@@ -81,13 +82,12 @@ static struct mdiobb_ops mdio_gpio_ops = {
.get_mdio_data = mdio_get,
};
-static int __devinit mdio_gpio_bus_init(struct device *dev,
+static struct mii_bus * __devinit mdio_gpio_bus_init(struct device *dev,
struct mdio_gpio_platform_data *pdata,
int bus_id)
{
struct mii_bus *new_bus;
struct mdio_gpio_info *bitbang;
- int ret = -ENOMEM;
int i;
bitbang = kzalloc(sizeof(*bitbang), GFP_KERNEL);
@@ -104,8 +104,6 @@ static int __devinit mdio_gpio_bus_init(struct device *dev,
new_bus->name = "GPIO Bitbanged MDIO",
- ret = -ENODEV;
-
new_bus->phy_mask = pdata->phy_mask;
new_bus->irq = pdata->irqs;
new_bus->parent = dev;
@@ -129,15 +127,8 @@ static int __devinit mdio_gpio_bus_init(struct device *dev,
dev_set_drvdata(dev, new_bus);
- ret = mdiobus_register(new_bus);
- if (ret)
- goto out_free_all;
-
- return 0;
+ return new_bus;
-out_free_all:
- dev_set_drvdata(dev, NULL);
- gpio_free(bitbang->mdio);
out_free_mdc:
gpio_free(bitbang->mdc);
out_free_bus:
@@ -145,30 +136,47 @@ out_free_bus:
out_free_bitbang:
kfree(bitbang);
out:
- return ret;
+ return NULL;
}
-static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+static void __devinit mdio_gpio_bus_deinit(struct device *dev)
{
struct mii_bus *bus = dev_get_drvdata(dev);
struct mdio_gpio_info *bitbang = bus->priv;
- mdiobus_unregister(bus);
- free_mdio_bitbang(bus);
dev_set_drvdata(dev, NULL);
- gpio_free(bitbang->mdc);
gpio_free(bitbang->mdio);
+ gpio_free(bitbang->mdc);
+ free_mdio_bitbang(bus);
kfree(bitbang);
}
+static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+{
+ struct mii_bus *bus = dev_get_drvdata(dev);
+
+ mdiobus_unregister(bus);
+ mdio_gpio_bus_deinit(dev);
+}
+
static int __devinit mdio_gpio_probe(struct platform_device *pdev)
{
struct mdio_gpio_platform_data *pdata = pdev->dev.platform_data;
+ struct mii_bus *new_bus;
+ int ret;
if (!pdata)
return -ENODEV;
- return mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id);
+ new_bus = mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id);
+ if (!new_bus)
+ return -ENODEV;
+
+ ret = mdiobus_register(new_bus);
+ if (ret)
+ mdio_gpio_bus_deinit(&pdev->dev);
+
+ return ret;
}
static int __devexit mdio_gpio_remove(struct platform_device *pdev)
@@ -179,29 +187,12 @@ static int __devexit mdio_gpio_remove(struct platform_device *pdev)
}
#ifdef CONFIG_OF_GPIO
-static void __devinit add_phy(struct mdio_gpio_platform_data *pdata,
- struct device_node *np)
-{
- const u32 *data;
- int len, id, irq;
-
- data = of_get_property(np, "reg", &len);
- if (!data || len != 4)
- return;
-
- id = *data;
- pdata->phy_mask &= ~(1 << id);
-
- irq = of_irq_to_resource(np, 0, NULL);
- if (irq)
- pdata->irqs[id] = irq;
-}
static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
- struct device_node *np = NULL;
struct mdio_gpio_platform_data *pdata;
+ struct mii_bus *new_bus;
int ret;
pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
@@ -215,14 +206,18 @@ static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
ret = of_get_gpio(ofdev->node, 1);
if (ret < 0)
- goto out_free;
+ goto out_free;
pdata->mdio = ret;
- while ((np = of_get_next_child(ofdev->node, np)))
- if (!strcmp(np->type, "ethernet-phy"))
- add_phy(pdata, np);
+ new_bus = mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
+ if (!new_bus)
+ return -ENODEV;
- return mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
+ ret = of_mdiobus_register(new_bus, ofdev->node);
+ if (ret)
+ mdio_gpio_bus_deinit(&ofdev->dev);
+
+ return ret;
out_free:
kfree(pdata);
--
1.5.6.5
^ permalink raw reply related
* 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
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