* Re: [PATCH] ppc: add support for new powerbooks
From: Andrew Morton @ 2005-11-10 6:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17266.58346.798470.79283@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> wrote:
>
> > And, given the amount of shared infrastructure, I suspect it would have to
> > be a single git tree for both architectures.
> >
> > I'd still sweep up random ppc patches, but those will go into mainline via the
> > originator->mm->git-powerpc->linus route.
> >
> > Possible?
>
> Yes. Good idea, in fact. I'll create a powerpc.git tree once the
> current merge window closes.
OK.
> Do I need to grep the -mm releases for ppc patches or will you mail
> them to me?
If I see a ppc patch I will:
- merge it into -mm, add you guys to the cc on the mm-commits email.
- stage the patch after git-powerpc.patch in the -mm lineup.
- if I see the patch appear in git-powerpc.patch, I just drop it. I sync
with the git trees maybe twice per day.
- time passes
- if it still hasn't been merged into git-powerpc, I start spamming you
with the patch.
So no, you don't need to grep -mm and I won't bypass the git-powerpc tree
and the patch won't get lost. All you need to do is to either merge or
nack the patch at some stage.
Easy as pie ;)
^ permalink raw reply
* Re: [PATCH] ppc: add support for new powerbooks
From: Paul Mackerras @ 2005-11-10 6:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <20051109213837.47c8dce7.akpm@osdl.org>
Andrew Morton writes:
> I don't think I'm adding much value handling ppc/ppc64 patches, really.
> I'd prefer to get out of that business.
>
> It would be better to have an arch maintainer who runs a git tree, same as
> ia64, arm, etc.
My powerpc-merge.git tree is sort-of de-facto that at the moment.
> And, given the amount of shared infrastructure, I suspect it would have to
> be a single git tree for both architectures.
>
> I'd still sweep up random ppc patches, but those will go into mainline via the
> originator->mm->git-powerpc->linus route.
>
> Possible?
Yes. Good idea, in fact. I'll create a powerpc.git tree once the
current merge window closes.
Do I need to grep the -mm releases for ppc patches or will you mail
them to me?
Regards,
Paul.
^ permalink raw reply
* Re: [PATCH] ppc: add support for new powerbooks
From: Benjamin Herrenschmidt @ 2005-11-10 6:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <20051109220022.264437f8.akpm@osdl.org>
> Well yes, that's a generic problem with subsystem trees. I suppose one
> could enforce processes which prevent it from happening.
I think the right process is to go through the linuxppc[64]-dev list(s)
first, maybe CC lkml when it's not strictly arch gore, and then hop from
there to -git. We also have a nice patch tracking system scanning those
lists, I suppose I need to fix my own habits of bypassing all of that
stuff :)
> OK, well please think about it. It's not a ton of work at this end at
> present, but a) you lazy bums don't ack most of the things I cc you on, so
> it's rather open-loop and I don't know whether I'm merging wrong patches
> and b) there's now increasing potential for patches in -mm to clash with
> patches in Paul's git tree.
>
> The latter can be solved easily enough: I add Paul's git tree to the -mm
> lineup.
I think going through the -git tree always makes sense and I've doing
doing that for my own production, I'll route patches that I'm acking
that way too from now on.
I'm keeping the liberty of bombing you & linus directly when I think
it's an important bug fix late in the rc cycle though :)
Ben.
^ permalink raw reply
* Re: [PATCH] ppc: add support for new powerbooks
From: Andrew Morton @ 2005-11-10 6:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1131601224.24637.155.camel@gaston>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>
> > I don't think I'm adding much value handling ppc/ppc64 patches, really.
> > I'd prefer to get out of that business.
> >
> > It would be better to have an arch maintainer who runs a git tree, same as
> > ia64, arm, etc.
> >
> > And, given the amount of shared infrastructure, I suspect it would have to
> > be a single git tree for both architectures.
> >
> > I'd still sweep up random ppc patches, but those will go into mainline via the
> > originator->mm->git-powerpc->linus route.
> >
> > Possible?
>
> Well, I'm personally no fan of the git route as it causes us to have
> less review on the list imho
Well yes, that's a generic problem with subsystem trees. I suppose one
could enforce processes which prevent it from happening.
> (too easy also for me to just bounce a
> patch to paulus to shove in his git tree :) though that's what I've been
> doing for the last few days at least. But if you prefer that way, yes,
> it's certainly possible.
OK, well please think about it. It's not a ton of work at this end at
present, but a) you lazy bums don't ack most of the things I cc you on, so
it's rather open-loop and I don't know whether I'm merging wrong patches
and b) there's now increasing potential for patches in -mm to clash with
patches in Paul's git tree.
The latter can be solved easily enough: I add Paul's git tree to the -mm
lineup. Gimme.
^ permalink raw reply
* Re: [PATCH] ppc: add support for new powerbooks
From: Benjamin Herrenschmidt @ 2005-11-10 5:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <20051109213837.47c8dce7.akpm@osdl.org>
> I don't think I'm adding much value handling ppc/ppc64 patches, really.
> I'd prefer to get out of that business.
>
> It would be better to have an arch maintainer who runs a git tree, same as
> ia64, arm, etc.
>
> And, given the amount of shared infrastructure, I suspect it would have to
> be a single git tree for both architectures.
>
> I'd still sweep up random ppc patches, but those will go into mainline via the
> originator->mm->git-powerpc->linus route.
>
> Possible?
Well, I'm personally no fan of the git route as it causes us to have
less review on the list imho (too easy also for me to just bounce a
patch to paulus to shove in his git tree :) though that's what I've been
doing for the last few days at least. But if you prefer that way, yes,
it's certainly possible.
Ben.
^ permalink raw reply
* Re: [PATCH] ppc: add support for new powerbooks
From: Andrew Morton @ 2005-11-10 5:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1131526855.24637.67.camel@gaston>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
I don't think I'm adding much value handling ppc/ppc64 patches, really.
I'd prefer to get out of that business.
It would be better to have an arch maintainer who runs a git tree, same as
ia64, arm, etc.
And, given the amount of shared infrastructure, I suspect it would have to
be a single git tree for both architectures.
I'd still sweep up random ppc patches, but those will go into mainline via the
originator->mm->git-powerpc->linus route.
Possible?
^ permalink raw reply
* "Now booting the kernel"
From: Nitesh Guinde @ 2005-11-10 4:57 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]
Hello all,
I am loading a linux kernel onto ML310 board .I want networking support and
hence I have a pci enabled design.
I am using linux 2.4 powerpc devel kernel. I have also tried the montavista
previewkit
But I end up with the same problem. I have enabled the option " support for
early boot texts: in the kernel debugging.
Now once run the kernel program in powerpc I get the following essages in
the serial minicom terminal
Enter Desired System ACE CF Configuration <0-7>.
0: ACE-loader.
1: Linux w/PCI.
2: VxWorks w/PCI.
3: QNX Demo.
4: Linux EDK Base Build.
5: VxWorks EDK Base Build.
6: User Configuration A.
7: User Configuration B.
Select:
loaded at: 00400000 008CB1E0
board data at: 008C8138 008C8150
relocated to: 00405308 00405320
zimage at: 00405813 004DE42A
initrd at: 004DF000 008C7382
avail ram: 008CC000 10000000
Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part2 rw
Uncompressing Linux...done.
Now booting the kernel
The prompt goes dead at this point.The board details is available at
www.xilinx.com/ml310 <http://www.xilinx.com/ml310>
Any workarounds?
Thanks,
Nitesh
[-- Attachment #2: Type: text/html, Size: 1518 bytes --]
^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Benjamin Herrenschmidt @ 2005-11-10 1:51 UTC (permalink / raw)
To: Eddy Petrişor; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <60381eeb0511091712u115979f2jf92717a3641f7952@mail.gmail.com>
On Thu, 2005-11-10 at 03:12 +0200, Eddy Petrişor wrote:
> On 11/7/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > > i've applied your patch and it seems that when i put my powerbook to
> > > sleep ( by closing the lid ) the kernel just crashes since everytime i
> > > come back, the machine is turned off. I had a look at the logs and i see
> > > that i'm having a reboot almost immediateley after the lid is closed.
> > > However i've got no trace of a kernel panic .....
> > > my conf:
> >
> > What about this patch ?
>
> I tried to apply this patch and the previous one over 2.6.14, but they failed.
> I also tied to apply the second patch over the first, also the third
> over the first, but I had the same result.
>
> Over which version should these pacthes be applied?
2.6.14 :) (But not some git checkout from after 2.6.14 release)
Ben.
^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Eddy Petrişor @ 2005-11-10 1:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1131397208.4652.41.camel@gaston>
On 11/7/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > i've applied your patch and it seems that when i put my powerbook to
> > sleep ( by closing the lid ) the kernel just crashes since everytime i
> > come back, the machine is turned off. I had a look at the logs and i se=
e
> > that i'm having a reboot almost immediateley after the lid is closed.
> > However i've got no trace of a kernel panic .....
> > my conf:
>
> What about this patch ?
I tried to apply this patch and the previous one over 2.6.14, but they fail=
ed.
I also tied to apply the second patch over the first, also the third
over the first, but I had the same result.
Over which version should these pacthes be applied?
--
Regards,
EddyP
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
"Imagination is more important than knowledge" A.Einstein
^ permalink raw reply
* Re: u-boot + kernel (help required)
From: Wolfgang Denk @ 2005-11-09 22:58 UTC (permalink / raw)
To: srideep.devireddy; +Cc: linuxppc-embedded
In-Reply-To: <6AD9F6A5F6E096408F0B703773355A075BB210@CHN-SNR-MBX01.wipro.com>
In message <6AD9F6A5F6E096408F0B703773355A075BB210@CHN-SNR-MBX01.wipro.com> you wrote:
>
> we were able to get the u-boot up on MPC8272ADS board . We are just
...
Arghh... Why are you posting the same message 3 times?????
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"There's only one kind of woman ..." "Or man, for that matter. You
either believe in yourself or you don't."
-- Kirk and Harry Mudd, "Mudd's Women", stardate 1330.1
^ permalink raw reply
* Re: FW: U-boot linux kernel
From: Wolfgang Denk @ 2005-11-09 22:57 UTC (permalink / raw)
To: srideep.devireddy; +Cc: linuxppc-embedded
In-Reply-To: <6AD9F6A5F6E096408F0B703773355A075BB03B@CHN-SNR-MBX01.wipro.com>
In message <6AD9F6A5F6E096408F0B703773355A075BB03B@CHN-SNR-MBX01.wipro.com> you wrote:
>
> I am right now working on MPC 8272 Ads board to bring up the u-boot
> and the linux kernel on it . As I am success full in bringing up the
> u-boot . but I am finding it difficult in getting the linux up . As I
> downloaded the vmlinux image from montavista linux site for 8272Ads
Are you sure this image is configured for use with U-Boot?
> board and they tried to tftp to 100000 at u-boot prompt I am not able
And did you read the FAQ, for example
http://www.denx.de/wiki/view/DULG/LinuxUncompressingError ???
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Alliance: In international politics, the union of two thieves who
have their hands so deeply inserted in each other's pocket that they
cannot separately plunder a third. - Ambrose Bierce
^ permalink raw reply
* Re: [patch 2.6.14 (take #2)] fec_8xx: make CONFIG_FEC_8XX depend on CONFIG_8xx
From: John W. Linville @ 2005-11-09 21:52 UTC (permalink / raw)
To: Pantelis Antoniou, linuxppc-embedded, netdev, linux-kernel
In-Reply-To: <20051107182459.GD13797@tuxdriver.com>
On Mon, Nov 07, 2005 at 01:24:59PM -0500, John W. Linville wrote:
> Change CONFIG_FEC_8XX to depend on CONFIG_8xx instead of CONFIG_FEC.
> CONFIG_FEC depends on ColdFire CPUs, which does not apply for the
> PPC 8xx processors.
FWIW, I have this patch available on the linville-fec_8xx branch of
netdev-jwl as described below.
Thanks,
John
---
The following changes since commit 330d57fb98a916fa8e1363846540dd420e99499a:
Al Viro:
Fix sysctl unregistration oops (CVE-2005-2709)
are found in the git repository at:
git://git.tuxdriver.com/git/netdev-jwl.git linville-fec_8xx
John W. Linville:
fec_8xx: make CONFIG_FEC_8XX depend on CONFIG_8xx
drivers/net/fec_8xx/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fec_8xx/Kconfig b/drivers/net/fec_8xx/Kconfig
index 94e7a9a..a84c232 100644
--- a/drivers/net/fec_8xx/Kconfig
+++ b/drivers/net/fec_8xx/Kconfig
@@ -1,6 +1,6 @@
config FEC_8XX
tristate "Motorola 8xx FEC driver"
- depends on NET_ETHERNET && FEC
+ depends on NET_ETHERNET && 8xx
select MII
config FEC_8XX_GENERIC_PHY
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply related
* Need test: 2.6.14: Fix IRQ race in USB sleep/wakeup code]
From: Benjamin Herrenschmidt @ 2005-11-09 21:50 UTC (permalink / raw)
To: Linux Kernel list; +Cc: linuxppc-dev list
Here's a patch that fixes a race in the USB code with sleep/wakeup.
It's against 2.6.14 and I'd like to see it in the stable series as
powerbook sleep crashes without it, but it needs a little bit of
field testing first. So I would appreciate if ppl could give it a
go and let me know if it doesn't seem to cause any regression (or
if it does of course ;)
Ben.
Index: 2.6.14-ben/drivers/usb/core/hcd-pci.c
===================================================================
--- 2.6.14-ben.orig/drivers/usb/core/hcd-pci.c
+++ 2.6.14-ben/drivers/usb/core/hcd-pci.c
@@ -32,6 +32,13 @@
#include <linux/usb.h>
#include "hcd.h"
+#ifdef CONFIG_PPC_PMAC
+#include <asm/machdep.h>
+#include <asm/pmac_feature.h>
+#include <asm/pci-bridge.h>
+#include <asm/prom.h>
+#endif
+
/* PCI-based HCs are common, but plenty of non-PCI HCs are used too */
@@ -278,6 +285,18 @@ int usb_hcd_pci_suspend (struct pci_dev
break;
}
+#ifdef CONFIG_PPC_PMAC
+ if (retval == 0 && _machine == _MACH_Pmac) {
+ struct device_node *of_node;
+
+ /* Disable USB PAD & cell clock */
+ of_node = pci_device_to_OF_node (to_pci_dev(hcd->self.
+ controller));
+ if (of_node)
+ pmac_call_feature(PMAC_FTR_USB_ENABLE, of_node, 0, 0);
+ }
+#endif /* CONFIG_PPC_PMAC */
+
/* update power_state **ONLY** to make sysfs happier */
if (retval == 0)
dev->dev.power.power_state = message;
@@ -303,6 +322,18 @@ int usb_hcd_pci_resume (struct pci_dev *
return 0;
}
+#ifdef CONFIG_PPC_PMAC
+ if (_machine == _MACH_Pmac) {
+ struct device_node *of_node;
+
+ /* Re-enable USB PAD & cell clock */
+ of_node = pci_device_to_OF_node (to_pci_dev(hcd->self.
+ controller));
+ if (of_node)
+ pmac_call_feature(PMAC_FTR_USB_ENABLE, of_node, 0, 1);
+ }
+#endif /* CONFIG_PPC_PMAC */
+
/* NOTE: chip docs cover clean "real suspend" cases (what Linux
* calls "standby", "suspend to RAM", and so on). There are also
* dirty cases when swsusp fakes a suspend in "shutdown" mode.
Index: 2.6.14-ben/drivers/usb/core/hcd.c
===================================================================
--- 2.6.14-ben.orig/drivers/usb/core/hcd.c
+++ 2.6.14-ben/drivers/usb/core/hcd.c
@@ -1600,7 +1600,8 @@ irqreturn_t usb_hcd_irq (int irq, void *
struct usb_hcd *hcd = __hcd;
int start = hcd->state;
- if (start == HC_STATE_HALT)
+ if (start == HC_STATE_HALT ||
+ !test_bit(HC_FLAG_IRQ_ON, &hcd->bitflags))
return IRQ_NONE;
if (hcd->driver->irq (hcd, r) == IRQ_NONE)
return IRQ_NONE;
@@ -1736,6 +1737,9 @@ int usb_add_hcd(struct usb_hcd *hcd,
if (hcd->driver->irq) {
char buf[8], *bufp = buf;
+ set_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+ mb();
+
#ifdef __sparc__
bufp = __irq_itoa(irqnum);
#else
Index: 2.6.14-ben/drivers/usb/core/hcd.h
===================================================================
--- 2.6.14-ben.orig/drivers/usb/core/hcd.h
+++ 2.6.14-ben/drivers/usb/core/hcd.h
@@ -71,6 +71,9 @@ struct usb_hcd { /* usb_bus.hcpriv point
/*
* hardware info/state
*/
+ unsigned long bitflags; /* various single-bit flags */
+#define HC_FLAG_IRQ_ON 0
+
const struct hc_driver *driver; /* hw-specific hooks */
unsigned saw_irq : 1;
unsigned can_wakeup:1; /* hw supports wakeup? */
Index: 2.6.14-ben/drivers/usb/host/ehci-hcd.c
===================================================================
--- 2.6.14-ben.orig/drivers/usb/host/ehci-hcd.c
+++ 2.6.14-ben/drivers/usb/host/ehci-hcd.c
@@ -750,6 +750,12 @@ static int ehci_suspend (struct usb_hcd
if (time_before (jiffies, ehci->next_statechange))
msleep (100);
+ /* Disable emission of interrupts during suspend */
+ writel(0, &ehci->regs->intr_enable);
+ mb();
+ clear_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+ synchronize_irq(to_pci_dev(hcd->self.controller)->irq);
+
#ifdef CONFIG_USB_SUSPEND
(void) usb_suspend_device (hcd->self.root_hub, message);
#else
@@ -776,6 +782,8 @@ static int ehci_resume (struct usb_hcd *
if (time_before (jiffies, ehci->next_statechange))
msleep (100);
+ set_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+
/* If any port is suspended (or owned by the companion),
* we know we can/must resume the HC (and mustn't reset it).
*/
Index: 2.6.14-ben/drivers/usb/host/ehci-q.c
===================================================================
--- 2.6.14-ben.orig/drivers/usb/host/ehci-q.c
+++ 2.6.14-ben/drivers/usb/host/ehci-q.c
@@ -926,6 +926,11 @@ submit_async (
#endif
spin_lock_irqsave (&ehci->lock, flags);
+ if (HC_IS_SUSPENDED(ehci_to_hcd(ehci)->state)) {
+ spin_unlock_irqrestore (&ehci->lock, flags);
+ return -ESHUTDOWN;
+ }
+
qh = qh_append_tds (ehci, urb, qtd_list, epnum, &ep->hcpriv);
/* Control/bulk operations through TTs don't need scheduling,
Index: 2.6.14-ben/drivers/usb/host/ehci-sched.c
===================================================================
--- 2.6.14-ben.orig/drivers/usb/host/ehci-sched.c
+++ 2.6.14-ben/drivers/usb/host/ehci-sched.c
@@ -602,6 +602,11 @@ static int intr_submit (
spin_lock_irqsave (&ehci->lock, flags);
+ if (HC_IS_SUSPENDED(ehci_to_hcd(ehci)->state)) {
+ spin_unlock_irqrestore (&ehci->lock, flags);
+ return -ESHUTDOWN;
+ }
+
/* get qh and force any scheduling errors */
INIT_LIST_HEAD (&empty);
qh = qh_append_tds (ehci, urb, &empty, epnum, &ep->hcpriv);
@@ -1456,6 +1461,11 @@ static int itd_submit (struct ehci_hcd *
/* schedule ... need to lock */
spin_lock_irqsave (&ehci->lock, flags);
+ if (HC_IS_SUSPENDED(ehci_to_hcd(ehci)->state)) {
+ spin_unlock_irqrestore (&ehci->lock, flags);
+ status = -ESHUTDOWN;
+ goto done;
+ }
status = iso_stream_schedule (ehci, urb, stream);
if (likely (status == 0))
itd_link_urb (ehci, urb, ehci->periodic_size << 3, stream);
@@ -1815,6 +1825,11 @@ static int sitd_submit (struct ehci_hcd
/* schedule ... need to lock */
spin_lock_irqsave (&ehci->lock, flags);
+ if (HC_IS_SUSPENDED(ehci_to_hcd(ehci)->state)) {
+ spin_unlock_irqrestore (&ehci->lock, flags);
+ status = -ESHUTDOWN;
+ goto done;
+ }
status = iso_stream_schedule (ehci, urb, stream);
if (status == 0)
sitd_link_urb (ehci, urb, ehci->periodic_size << 3, stream);
Index: 2.6.14-ben/drivers/usb/host/ohci-hcd.c
===================================================================
--- 2.6.14-ben.orig/drivers/usb/host/ohci-hcd.c
+++ 2.6.14-ben/drivers/usb/host/ohci-hcd.c
@@ -252,6 +252,10 @@ static int ohci_urb_enqueue (
spin_lock_irqsave (&ohci->lock, flags);
+ if (HC_IS_SUSPENDED(hcd->state)) {
+ retval = -ESHUTDOWN;
+ goto fail;
+ }
/* don't submit to a dead HC */
if (!HC_IS_RUNNING(hcd->state)) {
retval = -ENODEV;
Index: 2.6.14-ben/drivers/usb/host/ohci-hub.c
===================================================================
--- 2.6.14-ben.orig/drivers/usb/host/ohci-hub.c
+++ 2.6.14-ben/drivers/usb/host/ohci-hub.c
@@ -219,13 +219,6 @@ static int ohci_hub_resume (struct usb_h
/* Sometimes PCI D3 suspend trashes frame timings ... */
periodic_reinit (ohci);
- /* interrupts might have been disabled */
- ohci_writel (ohci, OHCI_INTR_INIT, &ohci->regs->intrenable);
- if (ohci->ed_rm_list)
- ohci_writel (ohci, OHCI_INTR_SF, &ohci->regs->intrenable);
- ohci_writel (ohci, ohci_readl (ohci, &ohci->regs->intrstatus),
- &ohci->regs->intrstatus);
-
/* Then re-enable operations */
ohci_writel (ohci, OHCI_USB_OPER, &ohci->regs->control);
(void) ohci_readl (ohci, &ohci->regs->control);
@@ -241,6 +234,13 @@ static int ohci_hub_resume (struct usb_h
/* TRSMRCY */
msleep (10);
+ /* interrupts might have been disabled */
+ ohci_writel (ohci, OHCI_INTR_INIT, &ohci->regs->intrenable);
+ if (ohci->ed_rm_list)
+ ohci_writel (ohci, OHCI_INTR_SF, &ohci->regs->intrenable);
+ ohci_writel (ohci, ohci_readl (ohci, &ohci->regs->intrstatus),
+ &ohci->regs->intrstatus);
+
/* keep it alive for ~5x suspend + resume costs */
ohci->next_statechange = jiffies + msecs_to_jiffies (250);
Index: 2.6.14-ben/drivers/usb/host/ohci-pci.c
===================================================================
--- 2.6.14-ben.orig/drivers/usb/host/ohci-pci.c
+++ 2.6.14-ben/drivers/usb/host/ohci-pci.c
@@ -14,13 +14,6 @@
* This file is licenced under the GPL.
*/
-#ifdef CONFIG_PPC_PMAC
-#include <asm/machdep.h>
-#include <asm/pmac_feature.h>
-#include <asm/pci-bridge.h>
-#include <asm/prom.h>
-#endif
-
#ifndef CONFIG_PCI
#error "This file is PCI bus glue. CONFIG_PCI must be defined."
#endif
@@ -118,6 +111,12 @@ static int ohci_pci_suspend (struct usb_
if (time_before (jiffies, ohci->next_statechange))
msleep (100);
+ /* Disable emission of interrupts during suspend */
+ ohci_writel(ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
+ mb();
+ clear_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+ synchronize_irq(to_pci_dev(hcd->self.controller)->irq);
+
#ifdef CONFIG_USB_SUSPEND
(void) usb_suspend_device (hcd->self.root_hub, message);
#else
@@ -129,16 +128,6 @@ static int ohci_pci_suspend (struct usb_
/* let things settle down a bit */
msleep (100);
-#ifdef CONFIG_PPC_PMAC
- if (_machine == _MACH_Pmac) {
- struct device_node *of_node;
-
- /* Disable USB PAD & cell clock */
- of_node = pci_device_to_OF_node (to_pci_dev(hcd->self.controller));
- if (of_node)
- pmac_call_feature(PMAC_FTR_USB_ENABLE, of_node, 0, 0);
- }
-#endif /* CONFIG_PPC_PMAC */
return 0;
}
@@ -148,20 +137,11 @@ static int ohci_pci_resume (struct usb_h
struct ohci_hcd *ohci = hcd_to_ohci (hcd);
int retval = 0;
-#ifdef CONFIG_PPC_PMAC
- if (_machine == _MACH_Pmac) {
- struct device_node *of_node;
-
- /* Re-enable USB PAD & cell clock */
- of_node = pci_device_to_OF_node (to_pci_dev(hcd->self.controller));
- if (of_node)
- pmac_call_feature (PMAC_FTR_USB_ENABLE, of_node, 0, 1);
- }
-#endif /* CONFIG_PPC_PMAC */
-
/* resume root hub */
if (time_before (jiffies, ohci->next_statechange))
msleep (100);
+ set_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+
#ifdef CONFIG_USB_SUSPEND
/* get extra cleanup even if remote wakeup isn't in use */
retval = usb_resume_device (hcd->self.root_hub);
Index: 2.6.14-ben/drivers/usb/host/uhci-hcd.c
===================================================================
--- 2.6.14-ben.orig/drivers/usb/host/uhci-hcd.c
+++ 2.6.14-ben/drivers/usb/host/uhci-hcd.c
@@ -797,6 +797,11 @@ static int uhci_suspend(struct usb_hcd *
done:
spin_unlock_irq(&uhci->lock);
+ if (rc == 0) {
+ mb();
+ clear_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+ synchronize_irq(hcd->irq);
+ }
return rc;
}
@@ -818,6 +823,8 @@ static int uhci_resume(struct usb_hcd *h
* system wakeup. Check it and reconfigure to avoid problems.
*/
check_and_reset_hc(uhci);
+ set_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+ mb();
configure_hc(uhci);
#ifndef CONFIG_USB_SUSPEND
^ permalink raw reply
* [PATCH] ppc32: Add support for handling PCI interrupts on MPC834x PCI expansion card
From: Kumar Gala @ 2005-11-09 20:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-embedded
The MPC8349 PIBs system has a expansion board with 6 PCI slots. We needed
to update the IDSEL interrupt mapping for it to work properly. However,
only PCI1 is supported as the first revision of this expansion board doesn't
function properly for PCI2. For the time being we have zero'd out the entries
for the IDSELs related to PCI2. When a functioning expansion board exists
we can fix the table.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit b23f8a20b85440d4bebf1a2ddea5830ca85ff655
tree c60902116ecca2880d12d15350fed1e5d780bc79
parent 35003e02e33939b7359635f3cf7b424723ffd4b0
author Kumar Gala <galak@kernel.crashing.org> Wed, 09 Nov 2005 14:33:30 -0600
committer Kumar Gala <galak@kernel.crashing.org> Wed, 09 Nov 2005 14:33:30 -0600
arch/ppc/platforms/83xx/mpc834x_sys.c | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.c b/arch/ppc/platforms/83xx/mpc834x_sys.c
index 98edc75..763777c 100644
--- a/arch/ppc/platforms/83xx/mpc834x_sys.c
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.c
@@ -73,12 +73,19 @@ mpc83xx_map_irq(struct pci_dev *dev, uns
* A B C D
*/
{
- {PIRQA, PIRQB, PIRQC, PIRQD}, /* idsel 0x11 */
- {PIRQC, PIRQD, PIRQA, PIRQB}, /* idsel 0x12 */
- {PIRQD, PIRQA, PIRQB, PIRQC} /* idsel 0x13 */
+ {PIRQA, PIRQB, PIRQC, PIRQD}, /* idsel 0x11 */
+ {PIRQC, PIRQD, PIRQA, PIRQB}, /* idsel 0x12 */
+ {PIRQD, PIRQA, PIRQB, PIRQC}, /* idsel 0x13 */
+ {0, 0, 0, 0},
+ {PIRQA, PIRQB, PIRQC, PIRQD}, /* idsel 0x15 */
+ {PIRQD, PIRQA, PIRQB, PIRQC}, /* idsel 0x16 */
+ {PIRQC, PIRQD, PIRQA, PIRQB}, /* idsel 0x17 */
+ {PIRQB, PIRQC, PIRQD, PIRQA}, /* idsel 0x18 */
+ {0, 0, 0, 0}, /* idsel 0x19 */
+ {0, 0, 0, 0}, /* idsel 0x20 */
};
- const long min_idsel = 0x11, max_idsel = 0x13, irqs_per_slot = 4;
+ const long min_idsel = 0x11, max_idsel = 0x20, irqs_per_slot = 4;
return PCI_IRQ_TABLE_LOOKUP;
}
^ permalink raw reply related
* [PATCH] gianfar mii needs to zero out the mii_bus structure
From: Kumar Gala @ 2005-11-09 18:13 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-embedded
To ensure that phy_mask and any future elements of the mii_bus
structure are initialized use kzalloc() instead of kmalloc().
This fixes an issue in which phy_mask was not being initialized
and we would skip random phy addresses when scanning.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 35003e02e33939b7359635f3cf7b424723ffd4b0
tree 386160e32c51e8f1e662811738e79571c7218fdb
parent d0876a2748ddc33ca9ed1ea26cf958726c50c7b9
author Kumar Gala <galak@kernel.crashing.org> Wed, 09 Nov 2005 12:11:40 -0600
committer Kumar Gala <galak@kernel.crashing.org> Wed, 09 Nov 2005 12:11:40 -0600
drivers/net/gianfar_mii.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/gianfar_mii.c b/drivers/net/gianfar_mii.c
index 5a74d3d..ee1a77a 100644
--- a/drivers/net/gianfar_mii.c
+++ b/drivers/net/gianfar_mii.c
@@ -134,7 +134,7 @@ int gfar_mdio_probe(struct device *dev)
if (NULL == dev)
return -EINVAL;
- new_bus = kmalloc(sizeof(struct mii_bus), GFP_KERNEL);
+ new_bus = kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
if (NULL == new_bus)
return -ENOMEM;
^ permalink raw reply related
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Marcelo Tosatti @ 2005-11-09 12:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-embedded, Dan Malek
In-Reply-To: <1131396000.4652.24.camel@gaston>
On Tue, Nov 08, 2005 at 07:39:59AM +1100, Benjamin Herrenschmidt wrote:
<snip>
> I think the current code, even with your fix, is sub-optimal. But of
> course, the only way to be sure is to do real measurements
Hi folks,
I've written a simple app to estimate pagefault latency using gettimeofday().
Can be found at http://hera.kernel.org/~marcelo/measurefault/
/* This simple program attemps to estimate how long a pagefault takes.
* It does that by mmaping() /tmp/latency-test, and touching a page.
* Time measurement is done with gettimeofday() before and after the
* data touch.
*
* In the hope to have a more precise measurement two values are subtracted
* from the pagefault time delta:
*
* - Estimated time between two subsequent gettimeofday() calls, average
* of 100 runs (this average is around 8ms on 48Mhz PPC 8xx,
* 0ms on 1Ghz Pegasos G4)
*
* - Time taken to touch the data after its TLB cached, aka second run.
* This takes 1 and 2ms on 8xx (it varies) and 0ms on 1Ghz Pegasos.
*/
And results with 48Mhz 855T, comparing internal v2.4.17, vanilla v2.6.14
and v2.6.14-jump-direct (jumping directly to handle_page_fault if the
pte is zeroed).
Each "avg:" entry is an average of 100 "measure-fault-latency.c" runs.
2.6's root is mounted on NFS.
** 2.6.14 DataTLBHandler jump direct ("two exceptions"):
first batch:
avg: 287ms
avg: 287ms
avg: 287ms
avg: 287ms
avg: 287ms
second batch:
avg: 287ms
avg: 287ms
avg: 287ms
avg: 287ms
avg: 287ms
** 2.6.14 vanilla ("three exceptions"):
first batch:
avg: 288ms
avg: 285ms
avg: 287ms
avg: 287ms
avg: 288ms
second batch:
avg: 288ms
avg: 288ms
avg: 287ms
avg: 287ms
avg: 287ms
** 2.4.17 (root on RAMDISK):
avg: 309ms
avg: 313ms
avg: 312ms
avg: 311ms
avg: 310ms
The v2.6.14's kernel jump-direct is more consistent at 287ms,
while vanilla 2.6.14 oscillates between 285 and 288ms, but
no significant difference between the two.
v2.6's fault handling is clearly faster than 2.4's (note that the compiler
is also different, 2.4 uses gcc 2.95 and 2.6 gcc 3.3).
^ permalink raw reply
* Re: fix swapping on 8xx?
From: Marcelo Tosatti @ 2005-11-09 11:21 UTC (permalink / raw)
To: Tom Rini; +Cc: David Jander, linuxppc-embedded
In-Reply-To: <20051108175658.GO3839@smtp.west.cox.net>
On Tue, Nov 08, 2005 at 10:56:58AM -0700, Tom Rini wrote:
> On Tue, Nov 08, 2005 at 01:59:26PM +0200, David Jander wrote:
> > On Tuesday 08 November 2005 01:55, Dan Malek wrote:
> > > On Nov 7, 2005, at 10:10 AM, Marcelo Tosatti wrote:
> > > > The following is an attempt to fix swapping on 8xx by not touching
> > > > _PAGE_ACCESSED bit if the page is not present.
> > >
> > > Ugh .... I suppose. I hate assembler code macros .......
> > > Somehow, "swapping" and "8xx" just don't belong together.
> >
> > Well, at least it sounds ugly together, but it is also at least conceiveable.
> > There seem to be people who use PCMCIA for an IDE interface, so swapping may
> > become desireable in some cases.
>
> I think Dan might be in the camp that says a properly designed embedded
> system won't need to swap. And when I hear about how people do try and
> swap on systems like this, I really start agreeing. Maybe we could make
> 8xx just select SWAP=n? :)
TimeSys shipped their kernel with swapping fix as far as I know (Jason
plyed with it recently).
We'd better not assume what people try to do with their old 8xx's :)
> > > I'm tempted to add a configuration option that is the complete
> > > opposite of this and assumes are really embedded system.
> > > Mark pages as always accessed, data pages as always dirty,
> > > and you can eliminate lots of TLB faults in systems that are
> > > fairly static.
> >
> > It sounds tempting indeed, but should you really notice a performance increase
> > out of this?
>
> Compared to 8xx in 2.6 today? Absolutely.
>
> --
> Tom Rini
> http://gate.crashing.org/~trini/
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: 440EP FPU support missing
From: Josh Boyer @ 2005-11-09 16:50 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-dev, Stefan Roese, linuxppc64-dev
In-Reply-To: <20051108160200.I27232@cox.net>
On Tue, 2005-11-08 at 16:02 -0700, Matt Porter wrote:
> On Tue, Nov 08, 2005 at 04:32:54PM -0600, Josh Boyer wrote:
> > On Tue, 2005-11-08 at 15:30 -0700, Matt Porter wrote:
> > > On Tue, Nov 08, 2005 at 06:38:11PM +0100, Stefan Roese wrote:
> > > > In the current linux version, Bamboo (440EP) won't compile anymore, because of
> > > > missing fpu support:
> > > >
> > > > make uImage
> > > > ...
> > > > LD init/built-in.o
> > > > LD .tmp_vmlinux1
> > > > arch/ppc/kernel/head_44x.o(.text+0x868): In function `_start':
> > > > : undefined reference to `KernelFP'
> > > > make: *** [.tmp_vmlinux1] Error 1
> > > >
> > > > Somehow arch/ppc/kernel/fpu.S has disappeared. :-( I assume, this happened in
> > > > the ppc/ppc64 -> powerpc merge. Any thoughts, why this file disappeared and
> > > > how to solve this problem (just restore the original file)?
> > >
> > > arch/powerpc/kernel/fpu.S is being used now which doesn't have KernelFP.
> > > I don't know why the 44x fpu support wasn't using
> > > kernel_fp_unavailable_exception() before but I must have missed that
> > > reviewing it.
> > >
> > > Try this patch.
> >
> > Doesn't this render the 440EP's FPU useless?
>
> Does what render the 440EP's FPU useless? The supplied patch? I
> don't think so, the path should be the same as classic PPC.
>
> The patch simply replaces the KernelFP routine that used to be in
> arch/ppc/kernel/fpu.S (and was removed inadvertently in the arch/powerpc/
> merge) with a kernel_fp_unavailable_exception() call which does the
> equivalent and is shared by others.
>
> The exception still loads up the fpu is coming from userspace and
> only goes down this path when getting an FP unavailable exception from
> kernel space.
Yes, you're obviously right. I blame my idiocy on lack of coffee.
Sorry for the noise.
josh
^ permalink raw reply
* [PATCH] ppc32: fix ppc44x fpu build
From: Matt Porter @ 2005-11-09 13:42 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-dev
Fixes ppc44x fpu support that broke from a bad arch/powerpc merge.
Instead of adding KernelFP back in (which duplicates code) we use
the same kernel fpu unavailable handler as classic PPC processors.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
diff --git a/arch/ppc/kernel/head_booke.h b/arch/ppc/kernel/head_booke.h
index aeb349b..f3d274c 100644
--- a/arch/ppc/kernel/head_booke.h
+++ b/arch/ppc/kernel/head_booke.h
@@ -358,6 +358,6 @@ label:
NORMAL_EXCEPTION_PROLOG; \
bne load_up_fpu; /* if from user, just load it up */ \
addi r3,r1,STACK_FRAME_OVERHEAD; \
- EXC_XFER_EE_LITE(0x800, KernelFP)
+ EXC_XFER_EE_LITE(0x800, kernel_fp_unavailable_exception)
#endif /* __HEAD_BOOKE_H__ */
^ permalink raw reply related
* Re: u-boot + kernel (help required)
From: Vitaly Bordug @ 2005-11-09 13:21 UTC (permalink / raw)
To: srideep.devireddy; +Cc: linuxppc-embedded
In-Reply-To: <6AD9F6A5F6E096408F0B703773355A075BB210@CHN-SNR-MBX01.wipro.com>
srideep.devireddy@wipro.com wrote:
>
>
> Hi ,
>
>
>
> we were able to get the u-boot up on MPC8272ADS board . We are just
> struck up in bringing up the Linux... we get the following errors ..
> actually we made a uImage from vmlinux and tried to tftp and used bootm
> 100000 , we eneded up with these errors ...actually after the message
> Uncompressing Kernel Image ... OK board gets reset .Any help would be
> thankfull.
>
I can suggest to try the current 2.6, on which 8272 is supported and
known to work. A problem with binary you got is possibly because of
configuration incompatibility of your u-boot and kernel binary.
>
>
>
>
> *=> tftp 100000 vmlinux.72*
>
> *Using FCC1 ETHERNET device*
>
> *TFTP from server 10.0.0.1; our IP address is 10.0.0.2*
>
> *Filename 'vmlinux.72'.*
>
> *Load address: 0x100000*
>
> *Loading: #################################################################*
>
> * #################################################################*
>
> * #######################*
>
> *done*
>
> *Bytes transferred = 782424 (bf058 hex)*
>
> *=> bootm 100000*
>
> *## Booting image at 00100000 ...*
>
> * Image Name: Linux-2.4.22*
>
> * Image Type: PowerPC Linux Kernel Image (gzip compressed)*
>
> * Data Size: 782360 Bytes = 764 kB*
>
> * Load Address: 00000000*
>
> * Entry Point: 00000000*
>
> * Verifying Checksum ... OK*
>
> * Uncompressing Kernel Image ... OK*
>
> *
> *
>
> *
> *
>
> *U-Boot 1.1.1 (Nov 8 2005 - 16:19:13)*
>
> *
> *
>
> *MPC8272 Reset Status: Check Stop, External Soft, External Hard*
>
> *
> *
>
> *MPC8272 Clock Configuration*
>
> * - Bus-to-Core Mult 3.5x, VCO Div 2, 60x Bus Freq 30-85 , Core Freq
> 100-300*
>
> * - dfbrg 1, corecnf 0x1e, busdf 3, cpmdf 1, plldf 0, pllmf 3*
>
> * - vco_out 400000000, scc_clk 100000000, brg_clk 25000000*
>
> * - cpu_clk 350000000, cpm_clk 200000000, bus_clk 100000000*
>
> * - pci_clk 66666666*
>
> *
> *
>
> *CPU: MPC8272 (HiP7 Rev 14, Mask A.0 1K50M) at 350 MHz*
>
> *Board: Motorola MPC8272ADS*
>
> *DRAM: 64 MB*
>
> *FLASH: 8 MB*
>
> *In: serial*
>
> *Out: serial*
>
> *Err: serial*
>
> *Net: FCC1 ETHERNET*
>
> *Hit any key to stop autoboot: 0*
>
> *=>*
>
>
>
>
>
> Best Regards
>
>
>
> Srideep
>
>
>
>
> Confidentiality Notice
>
> The information contained in this electronic message and any attachments
> to this message are intended
> for the exclusive use of the addressee(s) and may contain confidential
> or privileged information. If
> you are not the intended recipient, please notify the sender at Wipro or
> Mailadmin@wipro.com immediately
> and destroy all copies of this message and any attachments.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: Using SMC on MPC8272 based board
From: Vitaly Bordug @ 2005-11-09 13:12 UTC (permalink / raw)
To: Mike Rapoport; +Cc: linuxppc-embedded list
In-Reply-To: <4371A513.6040409@compulab.co.il>
Mike Rapoport wrote:
> I have a custom board based on MPC8272 and I don't succeed to enable SMC
> serial port. I'm running Linux 2.6.12.3 with CPM serial drivers from
> 2.6.13.2.
> When I configure the kernel to use one or two SCCs, with or without
> serial console everything works fine. But if I configure the kernel to
> support SMC serial port, I see nothing at the SMC port.
> I've noticed that SMC1 pins are configured at port D (as in MPC8260),
> but MPC8272 has the SMC1 on the port C. I've changed the pins assignment
> to use the port C pins, but it didn't help.
> When I enable support for serial console on SCC/SMC port, the system
> hangs when the SMC is enabled.
> When I don't enable support for serial console on SCC/SMC port, the
> system boots OK, but there's nothing on the SMC port.
>
That is because (at least if you use "pure" 8272) the board does have
SCC1 and SCC4 for UART0 and UART1 respectively. SMC could not be used as
serial port on this board.
--
Sincerely,
Vitaly
^ permalink raw reply
* State of SPI for 2.4.25 kernel?
From: Ron Kellam @ 2005-11-09 6:55 UTC (permalink / raw)
To: linuxppc-embedded
Help! I was hoping to use SPI on an MPC8247 running the EDLK 2.4.25
kernel, but as I look into the code, I'm not hopeful...
Can someone fill me in on the state of SPI in the 2.24.xx kernels.
What about under 2.6.xx? (although I haven't yet brought 2.6.xx up on
the custom board I've got).
I've currently resorted to bit-banging for I2C, as the MPC8260 algo
driver didn't seem to behave on an 8272 family CPU. I was intending
on also going bit-banging for the SPI, but spi-algo-bit.c seems to be
in a half complete state and won't even compile.
Any info appreciated.
Thanks,
Ron Kellam.
^ permalink raw reply
* Possible improvements for CPM UART
From: Joakim Tjernlund @ 2005-11-09 11:07 UTC (permalink / raw)
To: linuxppc-embedded
Parts of these fixes in 2.4 doesn't seem to be in 2.6.
Maybe these are solved diffrently in 2.6 but I can't tell.
At least cpm_uart_console_write could use this.
http://linux.bkbits.net:8080/linux-2.4/diffs/arch/ppc/8xx_io/uart.c@1.23
?nav=3Dindex.html|src/.|src/arch|src/arch/ppc|src/arch/ppc/8xx_io|hist/ar=
c
h/ppc/8xx_io/uart.c
Another small improvement would to change:
#define RX_NUM_FIFO 4
#define RX_BUF_SIZE 32
#define TX_NUM_FIFO 4
#define TX_BUF_SIZE 32
to
#ifndef RX_NUM_FIFO
#define RX_NUM_FIFO 4
#endif
#ifndef RX_BUF_SIZE
#define RX_BUF_SIZE 32
#endif
#ifndef TX_NUM_FIFO
#define TX_NUM_FIFO 4
#endif
#ifndef TX_BUF_SIZE
#define TX_BUF_SIZE 32
#endif
This will allow custom changes to these constants
Jocke
^ permalink raw reply
* u-boot + kernel (help required)
From: srideep.devireddy @ 2005-11-09 10:55 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]
Hi ,
we were able to get the u-boot up on MPC8272ADS board . We are just
struck up in bringing up the Linux... we get the following errors ..
actually we made a uImage from vmlinux and tried to tftp and used bootm
100000 , we eneded up with these errors ...actually after the message
Uncompressing Kernel Image ... OK board gets reset .Any help would be
thankfull.
=> tftp 100000 vmlinux.72
Using FCC1 ETHERNET device
TFTP from server 10.0.0.1; our IP address is 10.0.0.2
Filename 'vmlinux.72'.
Load address: 0x100000
Loading:
#################################################################
#################################################################
#######################
done
Bytes transferred = 782424 (bf058 hex)
=> bootm 100000
## Booting image at 00100000 ...
Image Name: Linux-2.4.22
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 782360 Bytes = 764 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
U-Boot 1.1.1 (Nov 8 2005 - 16:19:13)
MPC8272 Reset Status: Check Stop, External Soft, External Hard
MPC8272 Clock Configuration
- Bus-to-Core Mult 3.5x, VCO Div 2, 60x Bus Freq 30-85 , Core Freq
100-300
- dfbrg 1, corecnf 0x1e, busdf 3, cpmdf 1, plldf 0, pllmf 3
- vco_out 400000000, scc_clk 100000000, brg_clk 25000000
- cpu_clk 350000000, cpm_clk 200000000, bus_clk 100000000
- pci_clk 66666666
CPU: MPC8272 (HiP7 Rev 14, Mask A.0 1K50M) at 350 MHz
Board: Motorola MPC8272ADS
DRAM: 64 MB
FLASH: 8 MB
In: serial
Out: serial
Err: serial
Net: FCC1 ETHERNET
Hit any key to stop autoboot: 0
=>
Best Regards
Srideep
Confidentiality Notice
The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
[-- Attachment #2: Type: text/html, Size: 15645 bytes --]
^ permalink raw reply
* u-boot + kernel (help required)
From: srideep.devireddy @ 2005-11-09 10:50 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 6514 bytes --]
Hi ,
we were able to get the u-boot up on MPC8272ADS board . We are just
struck up in bringing up the Linux... we get the following errors ..
actually we made a uImage from vmlinux and tried to tftp and used bootm
100000 , we eneded up with these errors ...actually after the message
Uncompressing Kernel Image ... OK board gets reset .Any help would be
thankfull.
=> tftp 100000 vmlinux.72
Using FCC1 ETHERNET device
TFTP from server 10.0.0.1; our IP address is 10.0.0.2
Filename 'vmlinux.72'.
Load address: 0x100000
Loading:
#################################################################
#################################################################
#######################
done
Bytes transferred = 782424 (bf058 hex)
=> bootm 100000
## Booting image at 00100000 ...
Image Name: Linux-2.4.22
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 782360 Bytes = 764 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
U-Boot 1.1.1 (Nov 8 2005 - 16:19:13)
MPC8272 Reset Status: Check Stop, External Soft, External Hard
MPC8272 Clock Configuration
- Bus-to-Core Mult 3.5x, VCO Div 2, 60x Bus Freq 30-85 , Core Freq
100-300
- dfbrg 1, corecnf 0x1e, busdf 3, cpmdf 1, plldf 0, pllmf 3
- vco_out 400000000, scc_clk 100000000, brg_clk 25000000
- cpu_clk 350000000, cpm_clk 200000000, bus_clk 100000000
- pci_clk 66666666
CPU: MPC8272 (HiP7 Rev 14, Mask A.0 1K50M) at 350 MHz
Board: Motorola MPC8272ADS
DRAM: 64 MB
FLASH: 8 MB
In: serial
Out: serial
Err: serial
Net: FCC1 ETHERNET
Hit any key to stop autoboot: 0
=>
Best Regards
Srideep
-----Original Message-----
From: Sakethan Kotta (WT01 - Broadband Networks)
Sent: Tuesday, November 08, 2005 9:45 AM
To: Srideep DeviReddy (WT01 - Broadband Networks)
Cc: sundar raman (WT01 - Broadband Networks)
Subject: RE: Emailing: u-boot
Hi Srideep,
Nice to here this. Congrats. What was the problem? Please do reply for
this.
U can use "bootp or tftp". We have used "bootp". It has 2 options, one
is loading address & the other one is source file name. If you are not
giving the source address in the command line, bootp will take the
default address. If you don't supply the file name at the command line,
then bootp will take the file from the "DHCP server".
Before doing the TFTP, you need to get the IP Address for the board. For
that you need to run a DHCP server. Board also takes the TFTP server IP
from DHCP and will do the TFTP to down load the file. Make sure that
some 15MB from the starting of the SDRAM should not be used for the
Bootp, as that space will be used for the kernel booting.
Once the file is transferred, u have to execute the "bootm <Address>".
It will boot the kernel.
Regards,
saketh
-----Original Message-----
From: Srideep DeviReddy (WT01 - Broadband Networks)
Sent: Monday, November 07, 2005 4:29 PM
To: Sakethan Kotta (WT01 - Broadband Networks)
Subject: RE: Emailing: u-boot
Hi Saketh ,
We got u-boot up on MPC8272ADS board, thanks for your help. Right
now we are trying to get linux kernel and get the os up. As suggestion
from you , before we start this . I have a doubt at what location
(address) do we need to do a TFTP .so that when we do a go.. It starts
executing...
Best Regards
Srideep
-----Original Message-----
From: Sakethan Kotta (WT01 - Broadband Networks)
Sent: Friday, October 28, 2005 10:29 AM
To: Srideep DeviReddy (WT01 - Broadband Networks)
Cc: sundar raman (WT01 - Broadband Networks)
Subject: RE: Emailing: u-boot
Hi,
I have changed the source code and compiled. So you may need the
latest source or map file to sync the GDB with the executable.
With thanks & regards,
saketh
-----Original Message-----
From: Srideep DeviReddy (WT01 - Broadband Networks)
Sent: Friday, October 28, 2005 10:19 AM
To: Sakethan Kotta (WT01 - Broadband Networks)
Cc: sundar raman (WT01 - Broadband Networks)
Subject: RE: Emailing: u-boot
Hi sakethan,
I tried programming the U-boot.bin on to the flash at 0xfff00000
keeping the jumper pins to 2&3(BCSR) . After programming I changed them
to 1&2(flash) , and tried connecting to serial but still not able to get
u-boot prompt .
When I try to used gdb and debug we get an error like given below
(gdb) target remote 10.145.102.120:2001
Remote debugging using 10.145.102.120:2001
0xfff00100 in _start () at /u-boot-1.1.3/cpu/mpc8260/start.S:1046
warning: Source file is more recent than executable.
1046 blr
(gdb) cont
Continuing.
Program received signal SIGSTOP, Stopped (signal).
0xfff00128 in boot_warm () at /u-boot-1.1.3/cpu/mpc8260/start.S:1046
1046 blr
(gdb) d
(gdb) b relocate_code
Breakpoint 1 at 0xff803558: file /u-boot-1.1.3/cpu/mpc8260/start.S, line
1046.
(gdb) cont
Continuing.
Program received signal SIGSTOP, Stopped (signal).
0xfff00124 in boot_warm () at /u-boot-1.1.3/cpu/mpc8260/start.S:1046
1046 blr
I am getting an error in 1046 line of start.S file .
Regards
Srideep
-----Original Message-----
From: Sakethan Kotta (WT01 - Broadband Networks)
Sent: Thursday, October 27, 2005 2:40 PM
To: Srideep DeviReddy (WT01 - Broadband Networks)
Cc: sundar raman (WT01 - Broadband Networks)
Subject: Emailing: u-boot
Hi Srideep & Sunadar,
I have attached a U-Boot.Bin file. Please program this on the ADS
board at address location 0xFFF00000 & keep the jumper J9 for 2&3 pins.
Please do this and let me know the results. This should work fine.
With thanks & regards,
saketh
Confidentiality Notice
The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
[-- Attachment #2: Type: text/html, Size: 32449 bytes --]
^ 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