Hi guys,
I was hoping to have gotten some form of comment by now...
Can anyone help out here, please?
Daniel
On Fri, Feb 20, 2009 at 4:01 PM, Daniel Ng wrote:
>
> Now, I'm seeing these boot messages:
>
> f0010d40:00 not found
> eth0: Could not attach to PHY
> IP-Config: Failed to open eth0
> I
On Tue, 24 Feb 2009 05:38:37 pm Sachin P. Sant wrote:
> Jan Kara wrote:
> > Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
> > somehow got beyond end of the page referenced by bh->b_data. So it means
> > that le16_to_cpu(entry->e_value_offs) + size > page_size. But
> > ext3
On Wed, Feb 25, 2009 at 06:47:07AM +0100, Sam Ravnborg wrote:
> > On ppc64 (at least) gcc-4.4 is defaulting to generating .eh_frame
> > sections, which are, for the kernel, fairly pointless. Additionally, on
> > ppc64 this generates a relocation format which the kernel module loader
> > does not cu
On Tue, Feb 24, 2009 at 01:51:12AM -0500, Kyle McMartin wrote:
> From: Kyle McMartin
>
> On ppc64 (at least) gcc-4.4 is defaulting to generating .eh_frame
> sections, which are, for the kernel, fairly pointless. Additionally, on
> ppc64 this generates a relocation format which the kernel module l
I am trying to understand more about how to talk to different spi
chips using the MPC8313. The documentation that comes with the
development board is really lacking and I am relying on the
/usr/src/linux/Documentaion/spi. However, I still can't seem to
answer my questions.
1) Which devi
On Wed, 25 Feb 2009 05:01:59 am Geert Uytterhoeven wrote:
> On Mon, 23 Feb 2009, Paul Mackerras wrote:
> > Andrew Morton writes:
> > > It looks like we died in ext3_xattr_block_get():
> > >
> > > memcpy(buffer, bh->b_data + le16_to_cpu(entry->e_value_offs),
> > > size);
On Wed, 25 Feb 2009 02:51:20 am Jan Kara wrote:
> Hello,
>
> On Tue 24-02-09 12:08:37, Sachin P. Sant wrote:
> > Jan Kara wrote:
> >> Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
> >> somehow got beyond end of the page referenced by bh->b_data. So it means
> >> that le
On Tue, Feb 24, 2009 at 07:37:08PM +0100, Alessandro Zummo wrote:
> On Tue, 24 Feb 2009 18:56:03 +0100 (CET)
> Geert Uytterhoeven wrote:
> > Converting all (ca. 20?) ppc and m68k RTC support code into individual RTC
> > class drivers would add ca. 100+ lines of code for each individual driver.
>
The patch is right though the log entry and comment are perhaps misleading.
The effect of the patch is to restore the compiler behavior to what it was
before. What it was before includes cases of producing .eh_frame and cases
of not producing it. The default behavior of a gcc-4.4 that was built
a
On Tue, 2009-02-24 at 23:11 +0100, Alessandro Zummo wrote:
> On Wed, 25 Feb 2009 06:35:27 +0900
> David Woodhouse wrote:
>
> > > So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk()
> > > [m68k],
> > > mach_gettod() [m68knommu] (and probably a few other) abstractions, and
> >
On Wed, 25 Feb 2009 06:35:27 +0900
David Woodhouse wrote:
> > So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk()
> > [m68k],
> > mach_gettod() [m68knommu] (and probably a few other) abstractions, and move
> > all
> > RTC code out of arch/ into seperate drivers under drivers
On Mon, 2009-02-23 at 13:34 +0100, Geert Uytterhoeven wrote:
> >my opinion on this kind of stuff is that I want to avoid the layering
> > of implementations under the rtc subsystem. I'd rather prefer that each
> > rtc device had its own driver.
> >
> > I've made error in the past, by acc
On Tue, 24 Feb 2009 13:58:26 -0600
"Serge E. Hallyn" wrote:
> Quoting Nathan Lynch (n...@pobox.com):
> > Nathan Lynch wrote:
> > >
> > > Oren Laadan wrote:
> > > >
> > > > Nathan Lynch wrote:
> > > > >
> > > > > What doesn't work:
> > > > > * restarting a 32-bit task from a 64-bit task and vic
Hi guys,
I have the Rev B board and I have it working quite well. I'll share what I
have
discovered so far.
In Eric's case, the board seems suspect. There is already a Rev C of this
board, but
I am not sure if it is actually available yet. You may want to check on
that.
Regarding U-Boot, mine sh
Geert Uytterhoeven wrote:
> I've been looking into problems with auto-loading the RTC driver on PPC (more
> specifically on PS3):
> - The recent "rtc-ppc" RTC class driver is not autoloaded by udev because
> it's an old style platform driver that contains its own platform device.
> - The al
Quoting Nathan Lynch (n...@pobox.com):
> Nathan Lynch wrote:
> >
> > Oren Laadan wrote:
> > >
> > > Nathan Lynch wrote:
> > > >
> > > > What doesn't work:
> > > > * restarting a 32-bit task from a 64-bit task and vice versa
> > >
> > > Is there a test to bail if we attempt to checkpoint such ta
On Tue, 24 Feb 2009 18:56:03 +0100 (CET)
Geert Uytterhoeven wrote:
>
> On Mon, 23
> >
> > I'd start writing a working driver and then see how we should eventually
> > adapt the rtc subsystem to cope with your needs.
>
> OK, so here's a first example: rtc-ps3.
>
> Note that this single patch
On Mon, 23 Feb 2009, Paul Mackerras wrote:
> Andrew Morton writes:
> > It looks like we died in ext3_xattr_block_get():
> >
> > memcpy(buffer, bh->b_data + le16_to_cpu(entry->e_value_offs),
> >size);
> >
> > Perhaps entry->e_value_offs is no good. I wonder if the
On Mon, 23 Feb 2009, Alessandro Zummo wrote:
> On Mon, 23 Feb 2009 13:34:49 +0100 (CET)
> Geert Uytterhoeven wrote:
> > >my opinion on this kind of stuff is that I want to avoid the layering
> > > of implementations under the rtc subsystem. I'd rather prefer that each
> > > rtc device had it
On Tue, Feb 24, 2009 at 09:40:34AM +0100, Sam Ravnborg wrote:
> x86 has a specific ".section .eh_frame,"a",@progbits" in vdso32/int80.S as
> one example.
>
> Have you analyzed all these hits?
>
These aren't effected by the patch. All the occurances of it inside the
kernel are explicitly written
I found out the problem...it was somewhere in my code...actually the
link register was getting over-written...
Thanks for help...
Regards,
Sumedh
On Tue, Feb 24, 2009 at 5:23 PM, sumedh tirodkar
wrote:
> The reason that i m using bla is that i am writing the interrupt
> handler from dec_start: t
Dai,
> I am not so sure about your PHY, but if you access to PHY while
packet
> transmission through MDIO bus, the packet might be corrupted. Do you
> have "phy_interrupt" in the /proc/interrupts? What is your dmesg
around
> the eTSEC look like (there is phy driver info surrounded).
With some p
Hello,
It never booted properly out of the box.
I raised the issue with the Distributor but have not heard back yet.
73 Eric
- Start Original Message -
Sent: Tue, 24 Feb 2009 17:29:15 +0100
From: Norbert van Bolhuis
To: Eric Cottrell
Subject: Re: Can not get "new" MPC8313e-RDB to boot
Hi Eric,
So it never ever booted properly ?
Hmm, it certainly looks like your distributor (or whoever you got the
MPC8313E-RDB
from) lend it out and got a messed up board back. Or maybe they messed it up
themselfes.
Go complain and send it back.
indeed, rev 2.x is better (much less TSEC bugs)
> Andrew Morton wrote:
> >hm, I wonder what could have caused that - we haven't altered
> >fs/ext3/xattr.c in ages.
> >
> >What is the most recent kernel version you know of which didn't do
> >this? Bear in mind that this crash might be triggered by the
> >current contents of the filesystem, so if
Hello,
On Tue 24-02-09 12:08:37, Sachin P. Sant wrote:
> Jan Kara wrote:
>> Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
>> somehow got beyond end of the page referenced by bh->b_data. So it means
>> that le16_to_cpu(entry->e_value_offs) + size > page_size. But
>> ext3
On Feb 24, 2009, Sam Ravnborg wrote:
> On Tue, Feb 24, 2009 at 01:51:12AM -0500, Kyle McMartin wrote:
>> From: Kyle McMartin
>>
>> On ppc64 (at least) gcc-4.4 is defaulting to generating .eh_frame
>> sections, which are, for the kernel, fairly pointless. Additionally, on
>> ppc64 this generates
On Tue, 24 Feb 2009, Geert Uytterhoeven wrote:
> On Tue, 24 Feb 2009, Josh Boyer wrote:
> > Please pull the next branch of the 4xx tree. It has a few small commits
>
> Any chance we can get the fix for PCI on e.g. Sequoia in?
> This is a regression from 2.6.28.
BTW, I don't see the patch on
http
Hello,
Thanks for the help. I will look into that. It is confusing as the latest
ltib appears not to have the aliases. This is my first venture into Embedded
Linux as our existing PowerPC products use PSOS. Most of my Linux experience
is on the Intel PC platform.
Yes, the 1.3.3 version was
On Tue, 24 Feb 2009, Josh Boyer wrote:
> Please pull the next branch of the 4xx tree. It has a few small commits
Any chance we can get the fix for PCI on e.g. Sequoia in?
This is a regression from 2.6.28.
> for 2.6.30, as well as the 256K page size patch for 44x.
(Oops, this is for 2.6.30. What
Hi Ben,
Please pull the next branch of the 4xx tree. It has a few small commits
for 2.6.30, as well as the 256K page size patch for 44x.
josh
The following changes since commit 6071ed0487c6ea8dcfadd9844b9b90944cd9de1e:
Michael Ellerman (1):
powerpc/pseries: Return the number of MSIs w
Hi Eric,
I have the same board and same problem. It's just an incompatibility between the
DTB and u-boot.
Recent u-boots (and without a doubt also your u-boot 1.3.3) expect aliases
in the DTB, these ones I guess:
.
.
aliases {
ethernet0 = &enet0;
ethernet1
>> static int oprofile_running;
>> -static u32 mmcr0_val, mmcr1_val, mmcr2_val;
>> +static u32 mmcr0_val, mmcr1_val, mmcr2_val, ctrs;
>
>This may be static but it's still a global scope as far as kernel
>symbols are concerned. Care to give it a slightly better name ? num_pmcs
>would probably be al
Signed-off-by: Octavian Purdila
---
arch/powerpc/kernel/cputable.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 923f87a..4e20cfb 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/ke
For ppc750 processors which use 4 performance counters instead of the
6 G4 uses but otherwise is compatible with G4.
Signed-off-by: Octavian Purdila
---
arch/powerpc/oprofile/op_model_7450.c | 21 +++--
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/power
The reason that i m using bla is that i am writing the interrupt
handler from dec_start: to dec_end:
then i am relocating this code to its corresponding vector
location(0x900)...As this relocated code is gonna be executed on
occurrence of interrupt, i cant use bl instruction...i have to go for
Sumedh,
I've just noticed you are using the "bla" instruction, which use absolute
target address: are you sure the C code gets even be executed ?
I don't know how the compiler successfully assemble your code because the
binary is supposed to be position independant code (PIC): you should rather
us
On Tue, Feb 24, 2009 at 01:51:12AM -0500, Kyle McMartin wrote:
> From: Kyle McMartin
>
> On ppc64 (at least) gcc-4.4 is defaulting to generating .eh_frame
> sections, which are, for the kernel, fairly pointless. Additionally, on
> ppc64 this generates a relocation format which the kernel module l
38 matches
Mail list logo
