* [UPDATED] Please pull from 'for_paulus' branch of powerpc
From: Kumar Gala @ 2006-05-05 5:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for_paulus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
to receive the following updates:
arch/powerpc/kernel/setup-common.c | 17 +++++++++++++++++
arch/powerpc/kernel/setup.h | 2 ++
arch/powerpc/kernel/setup_32.c | 5 +++--
arch/powerpc/kernel/setup_64.c | 18 +-----------------
4 files changed, 23 insertions(+), 19 deletions(-)
Kumar Gala:
powerpc: provide ppc_md.panic() for both ppc32 & ppc64
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 684ab1d..88de557 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -524,3 +524,20 @@ int check_legacy_ioport(unsigned long ba
return ppc_md.check_legacy_ioport(base_port);
}
EXPORT_SYMBOL(check_legacy_ioport);
+
+static int ppc_panic_event(struct notifier_block *this,
+ unsigned long event, void *ptr)
+{
+ ppc_md.panic(ptr); /* May not return */
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block ppc_panic_block = {
+ .notifier_call = ppc_panic_event,
+ .priority = INT_MIN /* may not return; must be done last */
+};
+
+void __init setup_panic(void)
+{
+ atomic_notifier_chain_register(&panic_notifier_list, &ppc_panic_block);
+}
diff --git a/arch/powerpc/kernel/setup.h b/arch/powerpc/kernel/setup.h
index 2ebba75..e67066c 100644
--- a/arch/powerpc/kernel/setup.h
+++ b/arch/powerpc/kernel/setup.h
@@ -2,5 +2,7 @@ #ifndef _POWERPC_KERNEL_SETUP_H
#define _POWERPC_KERNEL_SETUP_H
void check_for_initrd(void);
+void do_init_bootmem(void);
+void setup_panic(void);
#endif /* _POWERPC_KERNEL_SETUP_H */
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 69ac257..88832b3 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -235,8 +235,6 @@ arch_initcall(ppc_init);
/* Warning, IO base is not yet inited */
void __init setup_arch(char **cmdline_p)
{
- extern void do_init_bootmem(void);
-
/* so udelay does something sensible, assume <= 1000 bogomips */
loops_per_jiffy = 500000000 / HZ;
@@ -285,6 +283,9 @@ #endif
/* reboot on panic */
panic_timeout = 180;
+ if (ppc_md.panic)
+ setup_panic();
+
init_mm.start_code = PAGE_OFFSET;
init_mm.end_code = (unsigned long) _etext;
init_mm.end_data = (unsigned long) _edata;
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 4467c49..ab6ea37 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -100,12 +100,6 @@ unsigned long SYSRQ_KEY;
#endif /* CONFIG_MAGIC_SYSRQ */
-static int ppc64_panic_event(struct notifier_block *, unsigned long, void *);
-static struct notifier_block ppc64_panic_block = {
- .notifier_call = ppc64_panic_event,
- .priority = INT_MIN /* may not return; must be done last */
-};
-
#ifdef CONFIG_SMP
static int smt_enabled_cmdline;
@@ -456,13 +450,6 @@ #endif
DBG(" <- setup_system()\n");
}
-static int ppc64_panic_event(struct notifier_block *this,
- unsigned long event, void *ptr)
-{
- ppc_md.panic((char *)ptr); /* May not return */
- return NOTIFY_DONE;
-}
-
#ifdef CONFIG_IRQSTACKS
static void __init irqstack_early_init(void)
{
@@ -517,8 +504,6 @@ static void __init emergency_stack_init(
*/
void __init setup_arch(char **cmdline_p)
{
- extern void do_init_bootmem(void);
-
ppc64_boot_msg(0x12, "Setup Arch");
*cmdline_p = cmd_line;
@@ -535,8 +520,7 @@ void __init setup_arch(char **cmdline_p)
panic_timeout = 180;
if (ppc_md.panic)
- atomic_notifier_chain_register(&panic_notifier_list,
- &ppc64_panic_block);
+ setup_panic();
init_mm.start_code = PAGE_OFFSET;
init_mm.end_code = (unsigned long) _etext;
^ permalink raw reply related
* Re: Please pull from 'for_paulus' branch of powerpc
From: Kumar Gala @ 2006-05-05 4:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <17498.34041.993647.189930@cargo.ozlabs.ibm.com>
On May 4, 2006, at 5:49 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Please pull from 'for_paulus' branch of
>> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
>
>> --- a/arch/powerpc/kernel/setup_32.c
>> +++ b/arch/powerpc/kernel/setup_32.c
>> @@ -236,6 +236,7 @@ arch_initcall(ppc_init);
>> void __init setup_arch(char **cmdline_p)
>> {
>> extern void do_init_bootmem(void);
>> + extern void setup_panic(void);
>
> Urk.
Yeah didn't care for it either. Will move to "setup.h"
>
>> @@ -285,6 +286,9 @@ #endif
>> /* reboot on panic */
>> panic_timeout = 180;
>>
>> + if (ppc_md.panic)
>> + setup_panic();
>
> Since no 32-bit platform sets ppc_md.panic AFAICS, I guess this
> doesn't need to be pushed into 2.6.17. Please redo with setup_panic
> declared in a header file.
Yeah, this was for 2.6.18. (will do on the header change)
- k
^ permalink raw reply
* Re: kernel debugging
From: David H. Lynch Jr. @ 2006-05-04 9:20 UTC (permalink / raw)
To: Steve Iribarne (GMail); +Cc: linuxppc-embedded
In-Reply-To: <b4b98b690605030711q69426a59j28db8e38be73f1f0@mail.gmail.com>
Everyone has their own debugging style.
Engineers seem to like hardware debugging tools. I have used some
very fancy debugging hardware, but except for extremely rare instances
it is more work to get setup
and figure out what you are trying to do than inserting some
debugging and rebuilding.
My idea of debugging hardware is a port with an LED on it I can try
to blink.
I also only rarely use software debuggers.
Most of the time when things go off the rails the critical question
for me is Where did things go wrong. Once I know that usually the
problem is obvious and I do nto need dumps of variables or memory.
I also do development across numerous platforms, OS's and languages.
I need debugging tools and techniques that are broadly portable. A
hardware debugging tool might help with board bringup, but it would be
of little use
for web or perl programming. Investing time and capitol in highly
specialized tools or knowledge requires being narrowly focused to get a
worthwhile payback.
Regardless, I think debugging is a sort of religious preference. You
need to know who you are and what you need. Other peoples experience is
useful but should not be determinative.
Steve Iribarne (GMail) wrote:
> Hello.
>
> This is more a general question to see what others do out here. I am
> begining to get sick of printk debugging. I work on two different PPC
> boards. An 860 and 8260.
>
> I want to get some feedback on the best kernel debugger to use. I
> have been looking at three.
>
> 1. kgdb
> 2. kdb
> 3. UML
>
> I am leaning towards kgdb, but before I jump in I thought I'd put this
> out to the best group I could think of linuxppc. Because I am sure
> most of you are using something! :)
>
> Thanks.
>
> -stv
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
^ permalink raw reply
* Re: [PATCH 1/2] PAL: Support of the fixed PHY
From: Vitaly Bordug @ 2006-05-05 0:51 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-embedded
In-Reply-To: <F785D5DD-4C81-48BE-B63C-FF72E2A648E9@freescale.com>
On Thu, 4 May 2006 19:21:12 -0500
Andy Fleming <afleming@freescale.com> wrote:
> What happened to this patch? It doesn't seem to have been applied to
> any trees. Well, I'm gonna give it a little review now, since I have
> some time.
>
Under final review/updates, gonna to push uptodated shortly...
> On Apr 3, 2006, at 10:26, Vitaly Bordug wrote:
>
> >
> > This makes it possible for HW PHY-less boards to utilize PAL goodies.
> > Generic routines to connect to fixed PHY are provided, as well as
> > ability
> > to specify software callback that fills up link, speed, etc.
> > information
> > into PHY descriptor (the latter feature not tested so far).
> >
> > Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> > ---
>
> [snip]
>
> > +/
> > *---------------------------------------------------------------------
> > --------
> > + * This func is used to create all the necessary stuff, bind
> > + * the fixed phy driver and register all it on the mdio_bus_type.
> > + * speed is either 10 or 100, duplex is boolean.
> > + * number is used to create multiple fixed PHYs, so that several
> > devices can
> > + * utilize them simultaneously.
> > +
> > *---------------------------------------------------------------------
> > --------*/
> > +static int fixed_mdio_register_device(int number, int speed, int
> > duplex)
> > +{
> > + struct mii_bus *new_bus;
> > + struct fixed_info *fixed;
> > + struct phy_device *phydev;
> > + int err = 0;
> > +
> > + struct device* dev = kzalloc(sizeof(struct device), GFP_KERNEL);
> > +
> > + if (NULL == dev)
> > + return -EINVAL;
> > +
> > + new_bus = kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
> > +
> > + if (NULL == new_bus)
> > + return -ENOMEM;
>
> You don't free dev, here
>
> > +
> > + fixed = kzalloc(sizeof(struct fixed_info), GFP_KERNEL);
> > +
> > + if (NULL == fixed) {
> > + kfree(new_bus);
> > + return -ENOMEM;
> > + }
>
> And dev
>
>
> > +
> > + fixed->regs = kzalloc(MII_REGS_NUM*sizeof(int), GFP_KERNEL);
>
> You don't check for failure for regs's allocation.
>
As to upper notes, OK.
> [snip]
>
> > + /* create phy_device and register it on the mdio bus */
> > + phydev = phy_device_create(new_bus, 0, 0);
> > +
> > + /*
> > + Put the phydev pointer into the fixed pack so that bus read/
> > write code could be able
> > + to access for instance attached netdev. Well it doesn't have to
> > do so, only in case
> > + of utilizing user-specified link-update...
> > + */
> > + fixed->phydev = phydev;
> > +
> > + if(NULL == phydev) {
> > + err = -ENOMEM;
> > + goto bus_register_fail;
> > + }
>
> You're going to need to change this, because phydev isn't guaranteed
> to be NULL in the event of a failure to allocate. it will be ERR_PTR
> (-ENOMEM). I know you changed this in phy_device_create(), but I
> have more on that later. You should do:
>
> if (IS_ERR(phydev)) {
> err = PTR_ERR(-ENOMEM);
> goto bus_register_fail;
> }
>
Assuming IS_ERR will shoot on NULL too, the code is not quite right(see below) :)
But I agree this check is odd - will fix.
> [snip]
>
> > +
> > + return 0;
> > +
> > +bus_register_fail:
> > + kfree(new_bus);
>
> You need to free regs and dev, too
>
>
ok
>
> > diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> > index 459443b..c87f89e 100644
> > --- a/drivers/net/phy/mdio_bus.c
> > +++ b/drivers/net/phy/mdio_bus.c
> > @@ -66,7 +66,7 @@ int mdiobus_register(struct mii_bus *bus
> > phydev = get_phy_device(bus, i);
> >
> > if (IS_ERR(phydev))
> > - return PTR_ERR(phydev);
> > + continue;
>
>
> No. Why'd you change that? Now mdiobus_register doesn't return an
> error if memory runs out. Here's how the system works:
> get_phy_device() can return one of three things:
>
> 1) A pointer to a newly allocated phy_device
> 2) a NULL pointer, indicating that there is no PHY at that address
> (indicated by the bus returning all Fs)
> 3) an error (due to bus read failure, or to memory allocation
> failure, as indicated by PTR_ERR(phydev)
>
> This change has several issues:
> 1) due to the change below, IS_ERR(phydev) is never true
> 2) If you continue, mdiobus_register() will not inform its caller
> that it failed.
>
I am not really stick to this change, but it simply does not work otherwise.
I want the whole bus to be scanned, and the code scans until first fail, and returns error when there's no phy. Hereby, having phy's on 0 and 3 I end up with only 0 registered on bus. So maybe check for NULL and continue, check for err and return... Will inquire and fix - no big deal.
> > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/
> > phy_device.c
> > index 7da0e3d..0dffecf 100644
> > --- a/drivers/net/phy/phy_device.c
> > +++ b/drivers/net/phy/phy_device.c
> > @@ -46,6 +46,35 @@ static struct phy_driver genphy_driver;
> > extern int mdio_bus_init(void);
> > extern void mdio_bus_exit(void);
> >
> > +struct phy_device* phy_device_create(struct mii_bus *bus, int
> > addr, int phy_id)
> > +{
> > + struct phy_device *dev;
> > + /* We allocate the device, and initialize the
> > + * default values */
> > + dev = kcalloc(1, sizeof(*dev), GFP_KERNEL);
> > +
> > + if (NULL == dev)
> > + return NULL;
>
> Here's the other change which breaks get_phy_device(). Now it
> doesn't return an error when it fails to allocate memory, it returns
> NULL. Which mdiobus_register doesn't interpret as an error (because
> it isn't. Not every PHY address has a device on it).
>
OK, this part definitely needs a bit attention and a rework. So, phy_device_create should return PTR_ERR if it fail to allocate memory, and we need to keep get_phy_device() return as it was, right?
> > +
> > + dev->speed = 0;
> > + dev->duplex = -1;
> > + dev->pause = dev->asym_pause = 0;
> > + dev->link = 1;
> > +
> > + dev->autoneg = AUTONEG_ENABLE;
> > +
> > + dev->addr = addr;
> > + dev->phy_id = phy_id;
> > + dev->bus = bus;
> > +
> > + dev->state = PHY_DOWN;
> > +
> > + spin_lock_init(&dev->lock);
> > +
> > + return dev;
> > +}
> > +EXPORT_SYMBOL(phy_device_create);
>
> Also, as a side note, I'm not completely convinced you need to go
> through this degree of effort to circumvent the PHY Layer's normal
> operation. I think it should be possible to make it simpler. With
> the right implementation, it should even be possible to do really
> "clever" things, like allow users to change the PHY settings with
> ethtool. However, this code exists and works (I'm assuming), and
> that's good enough for now. I'll be glad to have this capability
> next time someone asks me to boot linux on a simulator.
>
I made it as it is not that complex as it seemed at the first sight,
and may be a proving ground to some incoming PAL feature. Also, if there is fixed PHY,
it often does not mean it is really "fixed" - it may be just far too weird to suite into any known form,
but still able to control the link etc.
So, the main aim is to do: if PAL doesn't know PHY, use fixed phy. If you do not want it fixed and wanna to control the link - ok, just implement the link update callback, pass it to emulated PHY, and here we go...
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: Flash map information in device tree.
From: David Woodhouse @ 2006-05-05 0:33 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1146787262.12254.5.camel@vader.jdub.homelinux.org>
On Thu, 2006-05-04 at 19:01 -0500, Josh Boyer wrote:
> On Fri, 2006-05-05 at 00:34 +0100, David Woodhouse wrote:
> > I'd like to get rid of some of the 'map' drivers in drivers/mtd/maps/
> > and replace them with simple platform devices. On PPC, I'd like to do
> > that with nodes in the device tree, with appropriate properties:
> > - physical address
> > - size
> > - bankwidth
> > - chip probe type (CFI/JEDEC/RAM/ROM/etc)
>
> Hm. How do you deal with NAND, which really isn't any of the above and
> can really depend on things like controllers, etc.
>
> Or was this only for NOR for the time being?
Only NOR. NAND requires a little more than just "where is it?".
--
dwmw2
^ permalink raw reply
* Re: [PATCH 1/2] PAL: Support of the fixed PHY
From: Andy Fleming @ 2006-05-05 0:21 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <20060403152622.26013.14459.stgit@vitb.ru.mvista.com>
What happened to this patch? It doesn't seem to have been applied to
any trees. Well, I'm gonna give it a little review now, since I have
some time.
On Apr 3, 2006, at 10:26, Vitaly Bordug wrote:
>
> This makes it possible for HW PHY-less boards to utilize PAL goodies.
> Generic routines to connect to fixed PHY are provided, as well as
> ability
> to specify software callback that fills up link, speed, etc.
> information
> into PHY descriptor (the latter feature not tested so far).
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> ---
[snip]
> +/
> *---------------------------------------------------------------------
> --------
> + * This func is used to create all the necessary stuff, bind
> + * the fixed phy driver and register all it on the mdio_bus_type.
> + * speed is either 10 or 100, duplex is boolean.
> + * number is used to create multiple fixed PHYs, so that several
> devices can
> + * utilize them simultaneously.
> +
> *---------------------------------------------------------------------
> --------*/
> +static int fixed_mdio_register_device(int number, int speed, int
> duplex)
> +{
> + struct mii_bus *new_bus;
> + struct fixed_info *fixed;
> + struct phy_device *phydev;
> + int err = 0;
> +
> + struct device* dev = kzalloc(sizeof(struct device), GFP_KERNEL);
> +
> + if (NULL == dev)
> + return -EINVAL;
> +
> + new_bus = kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
> +
> + if (NULL == new_bus)
> + return -ENOMEM;
You don't free dev, here
> +
> + fixed = kzalloc(sizeof(struct fixed_info), GFP_KERNEL);
> +
> + if (NULL == fixed) {
> + kfree(new_bus);
> + return -ENOMEM;
> + }
And dev
> +
> + fixed->regs = kzalloc(MII_REGS_NUM*sizeof(int), GFP_KERNEL);
You don't check for failure for regs's allocation.
[snip]
> + /* create phy_device and register it on the mdio bus */
> + phydev = phy_device_create(new_bus, 0, 0);
> +
> + /*
> + Put the phydev pointer into the fixed pack so that bus read/
> write code could be able
> + to access for instance attached netdev. Well it doesn't have to
> do so, only in case
> + of utilizing user-specified link-update...
> + */
> + fixed->phydev = phydev;
> +
> + if(NULL == phydev) {
> + err = -ENOMEM;
> + goto bus_register_fail;
> + }
You're going to need to change this, because phydev isn't guaranteed
to be NULL in the event of a failure to allocate. it will be ERR_PTR
(-ENOMEM). I know you changed this in phy_device_create(), but I
have more on that later. You should do:
if (IS_ERR(phydev)) {
err = PTR_ERR(-ENOMEM);
goto bus_register_fail;
}
[snip]
> +
> + return 0;
> +
> +bus_register_fail:
> + kfree(new_bus);
You need to free regs and dev, too
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 459443b..c87f89e 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -66,7 +66,7 @@ int mdiobus_register(struct mii_bus *bus
> phydev = get_phy_device(bus, i);
>
> if (IS_ERR(phydev))
> - return PTR_ERR(phydev);
> + continue;
No. Why'd you change that? Now mdiobus_register doesn't return an
error if memory runs out. Here's how the system works:
get_phy_device() can return one of three things:
1) A pointer to a newly allocated phy_device
2) a NULL pointer, indicating that there is no PHY at that address
(indicated by the bus returning all Fs)
3) an error (due to bus read failure, or to memory allocation
failure, as indicated by PTR_ERR(phydev)
This change has several issues:
1) due to the change below, IS_ERR(phydev) is never true
2) If you continue, mdiobus_register() will not inform its caller
that it failed.
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/
> phy_device.c
> index 7da0e3d..0dffecf 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -46,6 +46,35 @@ static struct phy_driver genphy_driver;
> extern int mdio_bus_init(void);
> extern void mdio_bus_exit(void);
>
> +struct phy_device* phy_device_create(struct mii_bus *bus, int
> addr, int phy_id)
> +{
> + struct phy_device *dev;
> + /* We allocate the device, and initialize the
> + * default values */
> + dev = kcalloc(1, sizeof(*dev), GFP_KERNEL);
> +
> + if (NULL == dev)
> + return NULL;
Here's the other change which breaks get_phy_device(). Now it
doesn't return an error when it fails to allocate memory, it returns
NULL. Which mdiobus_register doesn't interpret as an error (because
it isn't. Not every PHY address has a device on it).
> +
> + dev->speed = 0;
> + dev->duplex = -1;
> + dev->pause = dev->asym_pause = 0;
> + dev->link = 1;
> +
> + dev->autoneg = AUTONEG_ENABLE;
> +
> + dev->addr = addr;
> + dev->phy_id = phy_id;
> + dev->bus = bus;
> +
> + dev->state = PHY_DOWN;
> +
> + spin_lock_init(&dev->lock);
> +
> + return dev;
> +}
> +EXPORT_SYMBOL(phy_device_create);
Also, as a side note, I'm not completely convinced you need to go
through this degree of effort to circumvent the PHY Layer's normal
operation. I think it should be possible to make it simpler. With
the right implementation, it should even be possible to do really
"clever" things, like allow users to change the PHY settings with
ethtool. However, this code exists and works (I'm assuming), and
that's good enough for now. I'll be glad to have this capability
next time someone asks me to boot linux on a simulator.
Andy Fleming
^ permalink raw reply
* Re: Flash map information in device tree.
From: Josh Boyer @ 2006-05-05 0:01 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1146785683.2885.148.camel@hades.cambridge.redhat.com>
On Fri, 2006-05-05 at 00:34 +0100, David Woodhouse wrote:
> I'd like to get rid of some of the 'map' drivers in drivers/mtd/maps/
> and replace them with simple platform devices. On PPC, I'd like to do
> that with nodes in the device tree, with appropriate properties:
> - physical address
> - size
> - bankwidth
> - chip probe type (CFI/JEDEC/RAM/ROM/etc)
Hm. How do you deal with NAND, which really isn't any of the above and
can really depend on things like controllers, etc.
Or was this only for NOR for the time being?
> - partitioning information
>
> Can we define a format for this so it can be included in the device
> trees which we're presumably going to be generating for the embedded
> boards which are supported by the arch/powerpc kernel?
Platform drivers in general would be a good starting point I think.
Then you can transition those to using the generated flat device tree,
right?
>
> If we can get either an updated u-boot or a boot wrapper which work on
> the Wind River SBC8265 or SBC8560 boards, I might even be able to test
> it myself.
Or if anyone is ambitions and wants to get things working on a bamboo
board... :)
josh
^ permalink raw reply
* Hang in die() when using NMI soft-reset
From: David Wilder @ 2006-05-05 0:25 UTC (permalink / raw)
To: linuxppc-dev
I am debugging problem found in during kdump testing on a power 5 system
2.6.16. Maybe someone has some ideas?
I am generating an NMI from the firmware. Each cpu responds to the NMI
and calls system_reset_exception() ->
die()->show_regs()->show_instructions(). Sometimes the cpu will hang
in show_instructions(). Since the cpu is holding the die_lock() any
cpus that have not already run die() waits on the lock forever. In
show_instructions() a call is made to might_sleep(). The only reason I
can see for it to sleep would be if it takes page or SLB fault?
I have not yet tested other fault paths that call die for the problem.
Oops: System Reset, sig: 6 [#1]
SMP NR_CPUS=128 NUMA PSERIES LPAR
Modules linked in: crasher ipv6 apparmor aamatch_pcre loop dm_mod ide_cd
cdrom e1000 sg ipr firmware_class pdc202xx_new sd_mod scsi_mod
NIP: C000000000028AC0 LR: C000000000028AA0 CTR: 800000000014DCD0
REGS: c0000000e84a3250 TRAP: 0100 Tainted: G U
(2.6.16.9-20060423154214-ppc64)
MSR: 8000000000089032 <EE,ME,IR,DR> CR: 24448428 XER: 00000000
TASK = c00000000f854340[2747] 'hald-addon-stor' THREAD: c0000000e84a0000
CPU: 0
GPR00: 0000000000000002 C0000000E84A34D0 C00000000062ECE8 0000000000000080
GPR04: 0000000000000080 0000000000000080 8000000000C24393 0000000000000002
GPR08: 0000000000000004 C000000000633E88 C000000000634090 000000B1044EAA9E
GPR12: 0000000000004000 C000000000492E80 0000000010000000 0000000010000000
GPR16: 0000000010000000 0000000010002EF0 0000000010000000 0000000010000000
GPR20: 00000000FFF3E15C 0000000000000800 00000000FFF3E1C4 0000000000000001
GPR24: C0000000EA4E8C18 C0000000EA4E8CC0 C0000000E6886380 C0000000EA4E8CC0
GPR28: C0000000EA4E8C00 C0000000EA4E8C00 0000000000000001 0000000000000003
NIP [C000000000028AC0] .smp_call_function+0xd8/0x1c8
LR [C000000000028AA0] .smp_call_function+0xb8/0x1c8
Call Trace:
[C0000000E84A34D0] [C000000000028AA0] .smp_call_function+0xb8/0x1c8
(unreliable)
[C0000000E84A3570] [C0000000000CA00C] .invalidate_bdev+0x30/0x64
[C0000000E84A3600] [C0000000000EAAF8] .__invalidate_device+0x5c/0x80
[C0000000E84A3690] [C0000000000D231C] .check_disk_change+0x68/0xec
[C0000000E84A3720] [D00000000032DBF0] .cdrom_open+0xb14/0xb80 [cdrom]
[C0000000E84A3940] [D0000000002D1700] .idecd_open+0x128/0x19c [ide_cd]
[C0000000E84A39E0] [C0000000000D2940] .do_open+0x11c/0x5c4
[C0000000E84A3AA0] [C0000000000D30B0] .blkdev_open+0x38/0x88
[C0000000E84A3B30] [C0000000000C47D8] .__dentry_open+0x160/0x300
[C0000000E84A3BE0] [C0000000000C4AEC] .do_filp_open+0x50/0x70
[C0000000E84A3D00] [C0000000000C4B80] .do_sys_open+0x74/0x12c
[C0000000E84A3DB0] [C0000000001017A0] .compat_sys_open+0x24/0x38
[C0000000E84A3E30] [C00000000000871C] syscall_exit+0x0/0x40
Instruction dump: pc=0xc000000000028a90
#1 pc = 0xc000000000028a90 i=0
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
dwilder@us.ibm.com
(503)578-3789
^ permalink raw reply
* Flash map information in device tree.
From: David Woodhouse @ 2006-05-04 23:34 UTC (permalink / raw)
To: linuxppc-dev
I'd like to get rid of some of the 'map' drivers in drivers/mtd/maps/
and replace them with simple platform devices. On PPC, I'd like to do
that with nodes in the device tree, with appropriate properties:
- physical address
- size
- bankwidth
- chip probe type (CFI/JEDEC/RAM/ROM/etc)
- partitioning information
Can we define a format for this so it can be included in the device
trees which we're presumably going to be generating for the embedded
boards which are supported by the arch/powerpc kernel?
If we can get either an updated u-boot or a boot wrapper which work on
the Wind River SBC8265 or SBC8560 boards, I might even be able to test
it myself.
--
dwmw2
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch of powerpc
From: Paul Mackerras @ 2006-05-04 22:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0605041622180.3700-100000@gate.crashing.org>
Kumar Gala writes:
> Please pull from 'for_paulus' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
> --- a/arch/powerpc/kernel/setup_32.c
> +++ b/arch/powerpc/kernel/setup_32.c
> @@ -236,6 +236,7 @@ arch_initcall(ppc_init);
> void __init setup_arch(char **cmdline_p)
> {
> extern void do_init_bootmem(void);
> + extern void setup_panic(void);
Urk.
> @@ -285,6 +286,9 @@ #endif
> /* reboot on panic */
> panic_timeout = 180;
>
> + if (ppc_md.panic)
> + setup_panic();
Since no 32-bit platform sets ppc_md.panic AFAICS, I guess this
doesn't need to be pushed into 2.6.17. Please redo with setup_panic
declared in a header file.
Paul.
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch of powerpc
From: Segher Boessenkool @ 2006-05-04 22:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <55C365AA-2BA4-406C-8518-616F8182FAE5@kernel.crashing.org>
>>> void __init setup_arch(char **cmdline_p)
>>> {
>>> extern void do_init_bootmem(void);
>>> + extern void setup_panic(void);
>>
>> Can those two go into a header file please?
>
> any suggestions on which header?
The new one should just go into arch/powerpc/kernel/setup.h;
the bootmem thing could go there as well perhaps.
Segher
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch of powerpc
From: Kumar Gala @ 2006-05-04 22:10 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <6B4D81B3-ECB5-4492-B3EE-16EAAEBF1405@kernel.crashing.org>
On May 4, 2006, at 5:09 PM, Segher Boessenkool wrote:
> Hi Kumar,
>
>> +static int ppc_panic_event(struct notifier_block *this,
>> + unsigned long event, void *ptr)
>> +{
>> + ppc_md.panic((char *)ptr); /* May not return */
>> + return NOTIFY_DONE;
>> +}
>
> Lose the redundant pointer cast while you're there please?
>
>> void __init setup_arch(char **cmdline_p)
>> {
>> extern void do_init_bootmem(void);
>> + extern void setup_panic(void);
>
> Can those two go into a header file please?
any suggestions on which header?
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch of powerpc
From: Segher Boessenkool @ 2006-05-04 22:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0605041622180.3700-100000@gate.crashing.org>
Hi Kumar,
> +static int ppc_panic_event(struct notifier_block *this,
> + unsigned long event, void *ptr)
> +{
> + ppc_md.panic((char *)ptr); /* May not return */
> + return NOTIFY_DONE;
> +}
Lose the redundant pointer cast while you're there please?
> void __init setup_arch(char **cmdline_p)
> {
> extern void do_init_bootmem(void);
> + extern void setup_panic(void);
Can those two go into a header file please?
Segher
^ permalink raw reply
* Re: [openib-general] [PATCH 07/16] ehca: interrupt handling routines
From: Roland Dreier @ 2006-05-04 21:29 UTC (permalink / raw)
To: Heiko J Schick
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <4450A196.2050901@de.ibm.com>
> +void ehca_queue_comp_task(struct ehca_comp_pool *pool, struct ehca_cq *__cq)
> +{
> + int cpu;
> + int cpu_id;
> + struct ehca_cpu_comp_task *cct;
> + unsigned long flags_cct;
> + unsigned long flags_cq;
> +
> + cpu = get_cpu();
> + cpu_id = find_next_online_cpu(pool);
> +
> + EDEB_EN(7, "pool=%p cq=%p cq_nr=%x CPU=%x:%x:%x:%x",
> + pool, __cq, __cq->cq_number,
> + cpu, cpu_id, num_online_cpus(), num_possible_cpus());
> +
> + BUG_ON(!cpu_online(cpu_id));
> +
> + cct = per_cpu_ptr(pool->cpu_comp_tasks, cpu_id);
> +
> + spin_lock_irqsave(&cct->task_lock, flags_cct);
> + spin_lock_irqsave(&__cq->task_lock, flags_cq);
> +
> + if (__cq->nr_callbacks == 0) {
> + __cq->nr_callbacks++;
> + list_add_tail(&__cq->entry, &cct->cq_list);
> + wake_up(&cct->wait_queue);
> + }
> + else
> + __cq->nr_callbacks++;
> +
> + spin_unlock_irqrestore(&__cq->task_lock, flags_cq);
> + spin_unlock_irqrestore(&cct->task_lock, flags_cct);
> +
> + put_cpu();
> +
> + EDEB_EX(7, "cct=%p", cct);
> +
> + return;
> +}
I never read the ehca completion event handling code very carefully
until now. But I was motivated by Shirley's work on IPoIB to take a
closer look.
It seems that you are deferring completion event dispatch into threads
spread across all the CPUs. This seems like a very strange thing to
me -- you are adding latency and possibly causing cacheline pingpong.
It may help throughput in some cases to spread the work across
multiple CPUs but it seems strange to me to do this in the low-level
driver. My intuition would be that it would be better to do this in
the higher levels, and leave open the possibility for protocols that
want the lowest possible latency to be called directly from the
interrupt handler.
What was the thinking that led to this design?
- R.
^ permalink raw reply
* Please pull from 'for_paulus' branch of powerpc
From: Kumar Gala @ 2006-05-04 21:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
Please pull from 'for_paulus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
to receive the following updates:
arch/powerpc/kernel/setup-common.c | 17 +++++++++++++++++
arch/powerpc/kernel/setup_32.c | 4 ++++
arch/powerpc/kernel/setup_64.c | 17 ++---------------
3 files changed, 23 insertions(+), 15 deletions(-)
Kumar Gala:
powerpc: provide ppc_md.panic() for both ppc32 & ppc64
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 684ab1d..7a6a883 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -524,3 +524,20 @@ int check_legacy_ioport(unsigned long ba
return ppc_md.check_legacy_ioport(base_port);
}
EXPORT_SYMBOL(check_legacy_ioport);
+
+static int ppc_panic_event(struct notifier_block *this,
+ unsigned long event, void *ptr)
+{
+ ppc_md.panic((char *)ptr); /* May not return */
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block ppc_panic_block = {
+ .notifier_call = ppc_panic_event,
+ .priority = INT_MIN /* may not return; must be done last */
+};
+
+void __init setup_panic(void)
+{
+ atomic_notifier_chain_register(&panic_notifier_list, &ppc_panic_block);
+}
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 69ac257..9d55234 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -236,6 +236,7 @@ arch_initcall(ppc_init);
void __init setup_arch(char **cmdline_p)
{
extern void do_init_bootmem(void);
+ extern void setup_panic(void);
/* so udelay does something sensible, assume <= 1000 bogomips */
loops_per_jiffy = 500000000 / HZ;
@@ -285,6 +286,9 @@ #endif
/* reboot on panic */
panic_timeout = 180;
+ if (ppc_md.panic)
+ setup_panic();
+
init_mm.start_code = PAGE_OFFSET;
init_mm.end_code = (unsigned long) _etext;
init_mm.end_data = (unsigned long) _edata;
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 4467c49..ff6726f 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -100,12 +100,6 @@ unsigned long SYSRQ_KEY;
#endif /* CONFIG_MAGIC_SYSRQ */
-static int ppc64_panic_event(struct notifier_block *, unsigned long, void *);
-static struct notifier_block ppc64_panic_block = {
- .notifier_call = ppc64_panic_event,
- .priority = INT_MIN /* may not return; must be done last */
-};
-
#ifdef CONFIG_SMP
static int smt_enabled_cmdline;
@@ -456,13 +450,6 @@ #endif
DBG(" <- setup_system()\n");
}
-static int ppc64_panic_event(struct notifier_block *this,
- unsigned long event, void *ptr)
-{
- ppc_md.panic((char *)ptr); /* May not return */
- return NOTIFY_DONE;
-}
-
#ifdef CONFIG_IRQSTACKS
static void __init irqstack_early_init(void)
{
@@ -518,6 +505,7 @@ static void __init emergency_stack_init(
void __init setup_arch(char **cmdline_p)
{
extern void do_init_bootmem(void);
+ extern void setup_panic(void);
ppc64_boot_msg(0x12, "Setup Arch");
@@ -535,8 +523,7 @@ void __init setup_arch(char **cmdline_p)
panic_timeout = 180;
if (ppc_md.panic)
- atomic_notifier_chain_register(&panic_notifier_list,
- &ppc64_panic_block);
+ setup_panic();
init_mm.start_code = PAGE_OFFSET;
init_mm.end_code = (unsigned long) _etext;
^ permalink raw reply related
* Re: kernel debugging
From: Mark Chambers @ 2006-05-04 20:13 UTC (permalink / raw)
To: Steve Iribarne (GMail); +Cc: linuxppc-embedded
In-Reply-To: <b4b98b690605041251s40f88731i1edfdfb324da38b4@mail.gmail.com>
>> >
>> > This is more a general question to see what others do out here. I am
>> > begining to get sick of printk debugging. I work on two different PPC
>> > boards. An 860 and 8260.
>> >
>> > I want to get some feedback on the best kernel debugger to use. I
>> > have been looking at three.
>> >
>> > 1. kgdb
>> > 2. kdb
>> > 3. UML
>> >
For the 860 you can purchase a hardware debugger from www.denx.de for
50 Euros. For the 8260 you must buy the more expensive BDI2000, but
that is Freescale's fault. But the look and feel of BDI2000 is the same as
BDI4GDB, just faster, so you can decide whether it's worth the money for
you.
When you say 'kgdb' you imply 'gdb' which is the standard GNU-world
debugger. kgdb is a means for letting a kernel communicate with a PC based
(or equivalent) gdb and is an alternative to a hardware debugger. Also,
check out ddd, a front end for gdb.
IMHO, these serial debugging ports on PPC are the greatest thing since
sliced
bread and it would be foolish not to take advantage of them.
Mark C.
^ permalink raw reply
* Re: Moving from 2.4 to 2.6 kernel
From: Grant Likely @ 2006-05-04 20:04 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
In-Reply-To: <445A534D.8090800@ics-ltd.com>
On 5/4/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
> I'm looking into getting a BDI 2000 so I can start stepping through and
> see what is going on.
>
> I looked at the ML300 and V2Pro code in the arch/ppc/platforms/4xx
> folder, but I did not use any of that in my code. It looks like this is
> intended to be used with the BSP that is generated by Xilinx Platform
> Studio. I've tried generating the BSP this way, but the generated code
> is obviously not a complete patch to port Linux to your hardware, and I
> figure that by the time I figure out what I do/don't have to add, I
> might as well write the whole thing by myself. Have you had success
> integrating the automatically generated BSP from Xilinx Platform Studio?
No; the stuff in 2.6 is not integrated w/ platform studio. (only 2.4
is). However, you do need to extract the xparameters.h file from the
platform studio BSP. You can generate a Linux BSP w/o actually
telling it where your Linux tree is. Once its generated; pull out
xparameters.h and drop it into arch/ppc/platforms/4xx/xparameters/ in
your source tree. Note: it's important that you generate a LINUX BSP;
not a 'standalone' bsp. If you don't, then you'll be missing a bunch
of #defines.
Let me say that once more for clarity: The only file you need from
platform studio is the generated xparameters.h
This will give you at the very least a serial port driver. Once your
booting with that, you can focus on other device drivers.
Trust me; this is the path of far less pain.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195
^ permalink raw reply
* Re: kernel debugging
From: Steve Iribarne (GMail) @ 2006-05-04 19:51 UTC (permalink / raw)
To: dhlii; +Cc: linuxppc-embedded
In-Reply-To: <4459C774.8000300@dlasys.net>
On 5/4/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> Everyone has their own debugging style.
>
> Engineers seem to like hardware debugging tools. I have used some
> very fancy debugging hardware, but except for extremely rare instances
> it is more work to get setup
> and figure out what you are trying to do than inserting some
> debugging and rebuilding.
>
> My idea of debugging hardware is a port with an LED on it I can try
> to blink.
>
> I also only rarely use software debuggers.
>
> Most of the time when things go off the rails the critical question
> for me is Where did things go wrong. Once I know that usually the
> problem is obvious and I do nto need dumps of variables or memory.
>
> I also do development across numerous platforms, OS's and languages.
> I need debugging tools and techniques that are broadly portable. A
> hardware debugging tool might help with board bringup, but it would be
> of little use
> for web or perl programming. Investing time and capitol in highly
> specialized tools or knowledge requires being narrowly focused to get a
> worthwhile payback.
>
> Regardless, I think debugging is a sort of religious preference. You
> need to know who you are and what you need. Other peoples experience is
> useful but should not be determinative.
>
Yes I am finding this out. It's a long journey! :)
Most of the issues I have to deal with are systems that are already up
and running in the PPC world and I come in afterwords to clean up. So
for example, right now I think I have a DMA problem that is crashing
my PPC and rebooting the system.
To be sure, I would love to step over a few instructions and slow the
world down a bit. That's why I was going to setup kgdb or something
like that.
Thanks.
-stv
> Steve Iribarne (GMail) wrote:
> > Hello.
> >
> > This is more a general question to see what others do out here. I am
> > begining to get sick of printk debugging. I work on two different PPC
> > boards. An 860 and 8260.
> >
> > I want to get some feedback on the best kernel debugger to use. I
> > have been looking at three.
> >
> > 1. kgdb
> > 2. kdb
> > 3. UML
> >
> > I am leaning towards kgdb, but before I jump in I thought I'd put this
> > out to the best group I could think of linuxppc. Because I am sure
> > most of you are using something! :)
> >
> > Thanks.
> >
> > -stv
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
>
> --
> Dave Lynch DLA Systems
> Software Development: Embedded Linux
> 717.627.3770 dhlii@dlasys.net http://www.dlasys.net
> fax: 1.253.369.9244 Cell: 1.717.587.7774
> Over 25 years' experience in platforms, languages, and technologies too n=
umerous to list.
>
>
^ permalink raw reply
* Re: Where to look for CRAMFS
From: Antonio Di Bacco @ 2006-05-04 19:46 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <c359a7c00605031415o545d761cha3a3498c9454f3df@mail.gmail.com>
Your flash is seen by the kernel as sequence of partitions, the size and
offset of each partition (mtd partition) can be specified in two ways:
1) Tipically your board has a specific file in drivers/mtd/maps/yourboard.c
that cares to partition the flash based on a static table that you provide.
2) The kernel can parse command line argument mtdparts (for example
mtdparts=0:384k(boot),1024k(kern),2560k(cramfs),-(jffs2) ) to get the size of
these partitions (this feature should be enabled when compiling the kernel)
Your cramfs will be written in one of this partitions and you can tell the
kernel in which one it resides specifying cmd line argument "root"
On my board I specified 4 partitions on my 8MB flash:
1) /dev/mtd0 -> 256kb for u-boot and its environment
2) /dev/mtd1 -> for the kernel
3) /dev/mtd2 -> for rootfs on a cramfs
4) /dev/mtd3 -> for a jffs2 filesystem
and therefore root=/dev/mtd2
If you want to load your software as a bundle of both kernel and cramfs and
not separately you can also provide your package with an header containing
the size of kernel and cramfs and instruct the kernel to partition the flash
based on this header.
Bye,
Antonio.
On Wednesday 03 May 2006 23:15, Sauro Salomoni wrote:
> Greetings.
>
> I have an embedded board using i.MX21.
>
> What I want to know is: how do I tell the kernel where my CRAMFS root
> file system is?
> I mean, I put it in a specific memory address, but how does the kernel
> know where it is?!
>
> What happens here is that the kernel looks in some address and don't
> find the Magic Number CRAMFS stores in its own start address. I have a
> "bad magic number" msg because my root fs is somewhere else.
> Can anyone help me, plz?
>
> Thanks in advance.
>
>
> Sauro
> Engineer
> Z Tec
> www.ztec.com.br
> +55 61 3322-2544
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] powerpc: add num_pmcs to 970MP cputable entry
From: Anton Blanchard @ 2006-05-04 19:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
Hi,
The 970MP cputable entry needs a num_pmcs entry for oprofile to work.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 39e348a..f618ff4 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -230,6 +230,7 @@ struct cpu_spec cpu_specs[] = {
PPC_FEATURE_HAS_ALTIVEC_COMP,
.icache_bsize = 128,
.dcache_bsize = 128,
+ .num_pmcs = 8,
.cpu_setup = __setup_cpu_ppc970,
.oprofile_cpu_type = "ppc64/970",
.oprofile_type = PPC_OPROFILE_POWER4,
^ permalink raw reply related
* Re: Moving from 2.4 to 2.6 kernel
From: Chris Dumoulin @ 2006-05-04 19:17 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0605041111o1b652d60w3f5847a19abe5c95@mail.gmail.com>
I'm looking into getting a BDI 2000 so I can start stepping through and
see what is going on.
I looked at the ML300 and V2Pro code in the arch/ppc/platforms/4xx
folder, but I did not use any of that in my code. It looks like this is
intended to be used with the BSP that is generated by Xilinx Platform
Studio. I've tried generating the BSP this way, but the generated code
is obviously not a complete patch to port Linux to your hardware, and I
figure that by the time I figure out what I do/don't have to add, I
might as well write the whole thing by myself. Have you had success
integrating the automatically generated BSP from Xilinx Platform Studio?
Regards,
Chris
Grant Likely wrote:
> On 5/4/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
>
>> I am trying to take a working embedded linux system from kernel 2.4 to
>> 2.6. The hardware is a custom board using a Virtex II Pro with PPC405
>> processor.
>> The working system uses u-boot 1.1.1 with linux kernel 2.4.18.
>>
>> I am using the same u-boot and I am trying to port linux kernel 2.6.15
>> to our platform. Using the stuff from the working 2.4 kernel port and
>> other PPC4xx platforms in the 2.6.15 code as examples, I believe I have
>> done everything required to get the kernel booting. However, the kernel
>> seems to hang after being uncompressed. Here is what I see after running
>> bootm from u-boot:
>
>
> The V2pro is already supported in the 2.6 kernel. Are you using that
> code; or starting from scratch? V2Pro (ML300) and V4FX (ML403) are
> both supported in the latest 2.6 kernel.
>
> I had similar problems when I was porting to the V4FX. Do you have a
> JTAG debugger (Like a BDI-2000)? I think your best bet is to get in
> there with a debugger to find out where it goes off into Lala land.
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
> (403) 399-0195
>
>
--
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.
If misdirected, please notify us by telephone and confirm that it has
been deleted from your system and any hard copies destroyed. You are
strictly prohibited from using, printing, distributing or disseminating
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* Re: Moving from 2.4 to 2.6 kernel
From: Andy Gospodarek @ 2006-05-04 19:04 UTC (permalink / raw)
To: Grant Likely; +Cc: Chris Dumoulin, linuxppc-embedded
In-Reply-To: <528646bc0605041111o1b652d60w3f5847a19abe5c95@mail.gmail.com>
On 5/4/06, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 5/4/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
> > I am trying to take a working embedded linux system from kernel 2.4 to
> > 2.6. The hardware is a custom board using a Virtex II Pro with PPC405
> > processor.
> > The working system uses u-boot 1.1.1 with linux kernel 2.4.18.
> >
> > I am using the same u-boot and I am trying to port linux kernel 2.6.15
> > to our platform. Using the stuff from the working 2.4 kernel port and
> > other PPC4xx platforms in the 2.6.15 code as examples, I believe I have
> > done everything required to get the kernel booting. However, the kernel
> > seems to hang after being uncompressed. Here is what I see after runnin=
g
> > bootm from u-boot:
>
> The V2pro is already supported in the 2.6 kernel. Are you using that
> code; or starting from scratch? V2Pro (ML300) and V4FX (ML403) are
> both supported in the latest 2.6 kernel.
>
> I had similar problems when I was porting to the V4FX. Do you have a
> JTAG debugger (Like a BDI-2000)? I think your best bet is to get in
> there with a debugger to find out where it goes off into Lala land.
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
> (403) 399-0195
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
You could also try enabling early printk....sometimes that helps tell
you how far you did or didn't get.
^ permalink raw reply
* Re: Moving from 2.4 to 2.6 kernel
From: Grant Likely @ 2006-05-04 18:11 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
In-Reply-To: <445A3AB1.7040405@ics-ltd.com>
On 5/4/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
> I am trying to take a working embedded linux system from kernel 2.4 to
> 2.6. The hardware is a custom board using a Virtex II Pro with PPC405
> processor.
> The working system uses u-boot 1.1.1 with linux kernel 2.4.18.
>
> I am using the same u-boot and I am trying to port linux kernel 2.6.15
> to our platform. Using the stuff from the working 2.4 kernel port and
> other PPC4xx platforms in the 2.6.15 code as examples, I believe I have
> done everything required to get the kernel booting. However, the kernel
> seems to hang after being uncompressed. Here is what I see after running
> bootm from u-boot:
The V2pro is already supported in the 2.6 kernel. Are you using that
code; or starting from scratch? V2Pro (ML300) and V4FX (ML403) are
both supported in the latest 2.6 kernel.
I had similar problems when I was porting to the V4FX. Do you have a
JTAG debugger (Like a BDI-2000)? I think your best bet is to get in
there with a debugger to find out where it goes off into Lala land.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195
^ permalink raw reply
* Moving from 2.4 to 2.6 kernel
From: Chris Dumoulin @ 2006-05-04 17:32 UTC (permalink / raw)
To: linuxppc-embedded
I am trying to take a working embedded linux system from kernel 2.4 to
2.6. The hardware is a custom board using a Virtex II Pro with PPC405
processor.
The working system uses u-boot 1.1.1 with linux kernel 2.4.18.
I am using the same u-boot and I am trying to port linux kernel 2.6.15
to our platform. Using the stuff from the working 2.4 kernel port and
other PPC4xx platforms in the 2.6.15 code as examples, I believe I have
done everything required to get the kernel booting. However, the kernel
seems to hang after being uncompressed. Here is what I see after running
bootm from u-boot:
## Booting image at 00400000 ...
Image Name: Linux-2.6.15 ICS
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 605592 Bytes = 591.4 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 00800000 ...
Image Name: SELF CRD
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1430581 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 03e5c000, end 03fb9435 ... OK
My first thought was that I was simply not setting up the console
properly, and was not seeing the printk output, but I don't think I'm
even getting that far. I tried flashing an LED in start_kernel (in the
file init/main.c) and also in my platform_init function, but I get
nothing. I think the kernel is hanging somewhere very early on, maybe
when the MMU is enabled. I tried looking at the log buffer by following
the steps in section 14.3.3 of the DULG (Linux Post Mortem Analysis),
but I don't see anything there.
Any ideas would be appreciated.
Regards,
Chris
--
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.
If misdirected, please notify us by telephone and confirm that it has
been deleted from your system and any hard copies destroyed. You are
strictly prohibited from using, printing, distributing or disseminating
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* Re: frequent sig 11 with malloc() on mpc8xx
From: David Jander @ 2006-05-04 15:46 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060504144605.B18B3353BE7@atlas.denx.de>
On Thursday 04 May 2006 16:46, Wolfgang Denk wrote:
> Ummm... I have yet to see a single case where moving to 2.6 improved
> the stability for a MPC8xx system :-(
Our case.
Jffs2's gc thread stopped crashing. This might have more to do with mtd/jffs2
than with the rest of the kernel, but it sure works better now.
Nevertheless I am very interested in hearing about (potential) stability
problems with with 2.6.14, 15 and 16 (besides not booting just because
Marcelo couldn't resist screwing up on the last minute; problem which is
being worked on ;-).
Greetings,
--
David Jander
^ 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