Re: [PATCH 1/3] sh: dynamic ftrace support.

[Paul Mundt]

On Thu, Nov 20, 2008 at 03:34:16PM -0500, Steven Rostedt wrote:
 +} elsif ($arch eq sh) {
 +$section_regex = Disassembly of section\\s+(\\S+):;
 +$function_regex = ^([0-9a-fA-F]+)\\s+(.*?):;
 +$mcount_regex = ^\\s*([0-9a-fA-F]+):.*\\smcount\$;
 +$type = .long;
 +
 +# force flags for this arch
 +$ld .=  -m shlelf_linux;
 +$objcopy .=  -O elf32-sh-linux;
 +$cc .=  -m32;
 +

Note that if the $alignment changes are in this version, you will also
need to add an $alignment = 2; for sh. That was in Matt's original patch,
but I stripped the alignment line out in the commit given that it was not
yet present in the mainline version of the script.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: times(2) sys call bug?

[Joakim Tjernlund]

On Fri, 2008-11-21 at 10:52 +1100, Paul Mackerras wrote:
 Joakim Tjernlund writes:
 
  This little hack changes the kernel sys call handling in an crude
  way and then it works. Apperently the kernel thinks is an error if the
  syscall returns a value between -_LAST_ERRNO and -1.
 
 Try this patch and let me if it fixes it.  If it does I'll push it
 upstream.
 

It does fix the problem, thanks. You might want to do the same
to time(2)?
This workaround lets you get around the times(2) problem. Perhaps
you want to mention it in the commit msg:

static clock_t
our_times(void)/* Make times(2) behave rationally on Linux */
{
clock_t ret;

errno   = 0;
ret = times(NULL);
if (errno != 0)
ret = (clock_t) (-errno);
return ret;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: times(2) sys call bug?

[Gabriel Paubert]

On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote:
 Joakim Tjernlund writes:
 
  This little hack changes the kernel sys call handling in an crude
  way and then it works. Apperently the kernel thinks is an error if the
  syscall returns a value between -_LAST_ERRNO and -1.
 
 Try this patch and let me if it fixes it.  If it does I'll push it
 upstream.

With your patch, you won't get EFAULT if you pass a bad
address, but a constant, time independent value, unless
I miss something. 

Of course there are peoaple who claim that EFAULT is a
bad idea to start with and that you should send a SIGSEGV
instead, and I can see their point. 

But with the current implementation, it is a game that 
you can't win: any syscall that wants to return an
arbitrary integer multiplexed with an error value is
broken beyond repair, by design.

Oh, well. 

Gabriel
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: times(2) sys call bug?

[Joakim Tjernlund]

On Fri, 2008-11-21 at 09:41 +0100, Gabriel Paubert wrote:
 On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote:
  Joakim Tjernlund writes:
  
   This little hack changes the kernel sys call handling in an crude
   way and then it works. Apperently the kernel thinks is an error if the
   syscall returns a value between -_LAST_ERRNO and -1.
  
  Try this patch and let me if it fixes it.  If it does I'll push it
  upstream.
 
 With your patch, you won't get EFAULT if you pass a bad
 address, but a constant, time independent value, unless
 I miss something. 

Not so, look again:

asmlinkage long sys_times(struct tms __user * tbuf)
{
...
if (tbuf) {
...
if (copy_to_user(tbuf, tmp, sizeof(struct tms)))
return -EFAULT;
}
force_successful_syscall_return();
return (long) jiffies_64_to_clock_t(get_jiffies_64());
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: times(2) sys call bug?

[Paul Mackerras]

Gabriel Paubert writes:

 On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote:
  Joakim Tjernlund writes:
  
   This little hack changes the kernel sys call handling in an crude
   way and then it works. Apperently the kernel thinks is an error if the
   syscall returns a value between -_LAST_ERRNO and -1.
  
  Try this patch and let me if it fixes it.  If it does I'll push it
  upstream.
 
 With your patch, you won't get EFAULT if you pass a bad
 address, but a constant, time independent value, unless
 I miss something. 

I think you are missing something, namely that I put the call to
force_successful_syscall_return() AFTER the return -EFAULT.

You should get an EFAULT error if the address is bad, i.e. on return
to userspace with cr0.SO = 1 and r3 = EFAULT (note, not -EFAULT).  On
a non-error return you should get cr0.SO = 0 and r3 containing the
return value (even if it's -EFAULT).  It's possible that glibc will
stuff it up again after that but I hope not.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Kernel completely crashes after accessing an unmapped area.

[Benjamin Herrenschmidt]

On Wed, 2008-11-19 at 13:59 +0100, Ricardo wrote:
 Hello All:
 
   I am using the paulus tree popwerpc linux kernel for a ppc440 cpu
 located in a Virtex5 FPGA.
 
   While developing some drivers (a simple gpio device) I have notice
 that if I try to access an unmapped area (an address without any
 register/device attached), the system completely crashes... I remember
 that doing the same with a ppc400 cpu the system showed a
 Instruction/Data bus error and continue working.
 
   My question: The ppc440 cannot recover from this types of errors or
 is a kernel missing feature/bug?

You may want to look at the patch I posted recently:

powerpc: Fix 460EX/460GT machine check handling

From the look of your log, we aren't using the right type of machine
check handler for your core and it may need a similar treatement as the
above processors.

There are two kind of 440 cores vs. machine checks. On the old kind,
machine checks used to be critical interrupts (and thus used CSRR0 and
CSRR1 to save the context) while on the new kind, machine checks are
their own type of exception with a dedicated pair of context save
registers MCSRR0 and MCSRR1.

It -looks- like the problem might be that the kernel isn't using the
right set for your core. It uses by default the old style unless
you change the machine check IVOR to point to MachineCheckA
which is done by calling __fixup_440A_mcheck() in your CPU init routine
for example, as we do for other 440 cores.

So you would have to hook up a setup_cpu routine in cputable for
those guys (I can see the virtex cores seem to not have any at
this stage) and also change their machine check pointer to 
use machine_check_440A instead of machine_check_4xx so the machine
check details are properly decoded.

Of course check your Virtex user manual to make sure that's indeed
what is happening :-)

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: times(2) sys call bug?

[Joakim Tjernlund]

On Fri, 2008-11-21 at 20:03 +1100, Paul Mackerras wrote:
 Gabriel Paubert writes:
 
  On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote:
   Joakim Tjernlund writes:
   
This little hack changes the kernel sys call handling in an crude
way and then it works. Apperently the kernel thinks is an error if the
syscall returns a value between -_LAST_ERRNO and -1.
   
   Try this patch and let me if it fixes it.  If it does I'll push it
   upstream.
  
  With your patch, you won't get EFAULT if you pass a bad
  address, but a constant, time independent value, unless
  I miss something. 
 
 I think you are missing something, namely that I put the call to
 force_successful_syscall_return() AFTER the return -EFAULT.
 
 You should get an EFAULT error if the address is bad, i.e. on return
 to userspace with cr0.SO = 1 and r3 = EFAULT (note, not -EFAULT).  On
 a non-error return you should get cr0.SO = 0 and r3 containing the
 return value (even if it's -EFAULT).  It's possible that glibc will
 stuff it up again after that but I hope not.

With your patch:

t1 = times((void*) 1);
if (t1 == -1) {
my_err = errno;
printf(Errno:%d, %s\n, my_err, strerror(my_err));
}

prints:
Errno:14, Bad address
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: times(2) sys call bug?

[Joakim Tjernlund]

On Fri, 2008-11-21 at 10:52 +1100, Paul Mackerras wrote:
 Joakim Tjernlund writes:
 
  This little hack changes the kernel sys call handling in an crude
  way and then it works. Apperently the kernel thinks is an error if the
  syscall returns a value between -_LAST_ERRNO and -1.
 
 Try this patch and let me if it fixes it.  If it does I'll push it
 upstream.
 
 Paul.
[SNIP]
 + force_successful_syscall_return();
   return (long) jiffies_64_to_clock_t(get_jiffies_64());

Why is 64 bits ops used here when you only use 32 bits? 

BTW, I think time(2) needs this:

diff --git a/kernel/time.c b/kernel/time.c
index 6a08660..1627910 100644
--- a/kernel/time.c
+++ b/kernel/time.c
@@ -37,6 +37,7 @@
 #include linux/fs.h
 #include linux/slab.h
 #include linux/math64.h
+#include linux/ptrace.h
 
 #include asm/uaccess.h
 #include asm/unistd.h
@@ -65,8 +66,9 @@ asmlinkage long sys_time(time_t __user * tloc)
 
if (tloc) {
if (put_user(i,tloc))
-   i = -EFAULT;
+   return -EFAULT;
}
+   force_successful_syscall_return();
return i;
 }
 

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: times(2) sys call bug?

[Gabriel Paubert]

On Fri, Nov 21, 2008 at 08:03:06PM +1100, Paul Mackerras wrote:
 Gabriel Paubert writes:
 
  On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote:
   Joakim Tjernlund writes:
   
This little hack changes the kernel sys call handling in an crude
way and then it works. Apperently the kernel thinks is an error if the
syscall returns a value between -_LAST_ERRNO and -1.
   
   Try this patch and let me if it fixes it.  If it does I'll push it
   upstream.
  
  With your patch, you won't get EFAULT if you pass a bad
  address, but a constant, time independent value, unless
  I miss something. 
 
 I think you are missing something, namely that I put the call to
 force_successful_syscall_return() AFTER the return -EFAULT.
 

Indeed, it may be time to update the syscall documentation, saying
that you need to clear errno before the syscall and check errno
and not the return value since -1 is valid. 

Who does this? I have spotted some errors in other places on 
my man pages too, especially in the networking area (they were
correct once upon a time, but have not been updated).

Regards,
Gabriel
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: times(2) sys call bug?

[Paul Mackerras]

Joakim Tjernlund writes:

  +   force_successful_syscall_return();
  return (long) jiffies_64_to_clock_t(get_jiffies_64());
 
 Why is 64 bits ops used here when you only use 32 bits? 

If HZ is 1000, jiffies_64_to_clock_t is going to divide jiffies by 10,
so we need to start with 64 bits in order to get the top few bits
of a 32-bit result correct.

 BTW, I think time(2) needs this:

In principle you are correct, but it's only going to matter for a
little over an hour some time in the year 2106. :)

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: times(2) sys call bug?

[Joakim Tjernlund]

On Fri, 2008-11-21 at 10:31 +0100, Joakim Tjernlund wrote:
 On Fri, 2008-11-21 at 10:52 +1100, Paul Mackerras wrote:
  Joakim Tjernlund writes:
  
   This little hack changes the kernel sys call handling in an crude
   way and then it works. Apperently the kernel thinks is an error if the
   syscall returns a value between -_LAST_ERRNO and -1.
  
  Try this patch and let me if it fixes it.  If it does I'll push it
  upstream.
  
  Paul.
 [SNIP]
  +   force_successful_syscall_return();
  return (long) jiffies_64_to_clock_t(get_jiffies_64());
 
 Why is 64 bits ops used here when you only use 32 bits? 
 
 BTW, I think time(2) needs this:
 
 diff --git a/kernel/time.c b/kernel/time.c
[SNIP]

Oh, and compat needs fixing too. 

For both my patches:
Signed-off-by: Joakim Tjernlund [EMAIL PROTECTED]

BTW, why is sys_time() impl. differently in compat:
  do_gettimeofday(tv);
vs.
  get_seconds();

same for sys_times(): 
  compat_jiffies_to_clock_t(jiffies);
vs.
  jiffies_64_to_clock_t(get_jiffies_64());


diff --git a/kernel/compat.c b/kernel/compat.c
index 32c254a..c6346ec 100644
--- a/kernel/compat.c
+++ b/kernel/compat.c
@@ -23,6 +23,7 @@
 #include linux/timex.h
 #include linux/migrate.h
 #include linux/posix-timers.h
+#include linux/ptrace.h
 
 #include asm/uaccess.h
 
@@ -196,6 +197,7 @@ asmlinkage long compat_sys_times(struct compat_tms __user 
*tbuf)
if (copy_to_user(tbuf, tmp, sizeof(tmp)))
return -EFAULT;
}
+   force_successful_syscall_return();
return compat_jiffies_to_clock_t(jiffies);
 }
 
@@ -850,8 +852,9 @@ asmlinkage long compat_sys_time(compat_time_t __user * tloc)
 
if (tloc) {
if (put_user(i,tloc))
-   i = -EFAULT;
+   return -EFAULT;
}
+   force_successful_syscall_return();
return i;
 }
 

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: times(2) sys call bug?

[Paul Mackerras]

Gabriel Paubert writes:

 Who does this? I have spotted some errors in other places on 
 my man pages too, especially in the networking area (they were
 correct once upon a time, but have not been updated).

Michael Kerrisk [EMAIL PROTECTED], I believe.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: times(2) sys call bug?

[Joakim Tjernlund]

On Fri, 2008-11-21 at 20:51 +1100, Paul Mackerras wrote:
 Joakim Tjernlund writes:
 
   + force_successful_syscall_return();
 return (long) jiffies_64_to_clock_t(get_jiffies_64());
  
  Why is 64 bits ops used here when you only use 32 bits? 
 
 If HZ is 1000, jiffies_64_to_clock_t is going to divide jiffies by 10,
 so we need to start with 64 bits in order to get the top few bits
 of a 32-bit result correct.

I see, thanks.

 
  BTW, I think time(2) needs this:
 
 In principle you are correct, but it's only going to matter for a
 little over an hour some time in the year 2106. :)

I know, but I figured it should be fixed to serve as an template for
other similar sys calls(not that I know of any offhand). Perhaps add it
commented?

 Jocke
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: times(2) sys call bug?

[Joakim Tjernlund]

On Fri, 2008-11-21 at 10:50 +0100, Gabriel Paubert wrote:
 On Fri, Nov 21, 2008 at 08:03:06PM +1100, Paul Mackerras wrote:
  Gabriel Paubert writes:
  
   On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote:
Joakim Tjernlund writes:

 This little hack changes the kernel sys call handling in an crude
 way and then it works. Apperently the kernel thinks is an error if the
 syscall returns a value between -_LAST_ERRNO and -1.

Try this patch and let me if it fixes it.  If it does I'll push it
upstream.
   
   With your patch, you won't get EFAULT if you pass a bad
   address, but a constant, time independent value, unless
   I miss something. 
  
  I think you are missing something, namely that I put the call to
  force_successful_syscall_return() AFTER the return -EFAULT.
  
 
 Indeed, it may be time to update the syscall documentation, saying
 that you need to clear errno before the syscall and check errno
 and not the return value since -1 is valid. 

And perhaps mention that times(NULL) never returns an error.
And that times() is broken in 2.6.27 and earlier and needs the
workaround posted earlier.

 Jocke
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/3] sh: dynamic ftrace support.

[Matt Fleming]

On Fri, Nov 21, 2008 at 04:44:29PM +0900, Paul Mundt wrote:
 On Thu, Nov 20, 2008 at 03:34:16PM -0500, Steven Rostedt wrote:
  +} elsif ($arch eq sh) {
  +$section_regex = Disassembly of section\\s+(\\S+):;
  +$function_regex = ^([0-9a-fA-F]+)\\s+(.*?):;
  +$mcount_regex = ^\\s*([0-9a-fA-F]+):.*\\smcount\$;
  +$type = .long;
  +
  +# force flags for this arch
  +$ld .=  -m shlelf_linux;
  +$objcopy .=  -O elf32-sh-linux;
  +$cc .=  -m32;
  +
 
 Note that if the $alignment changes are in this version, you will also
 need to add an $alignment = 2; for sh. That was in Matt's original patch,
 but I stripped the alignment line out in the commit given that it was not
 yet present in the mainline version of the script.

I've sent a patch to steven for his tip/devel branch that adds this line.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

MPC5200B: Trouble with config pins

[Juergen Beisert]

Hi all,

we have trouble with the eth based config pins (ETH0...ETH6) of the MPC5200B 
CPU. These pins act as the interface to an external phy and also act as 
configurations pins to configure the size of the flash and other things. 
While the reset is active these pins should be in their high impedance state 
and the externally connected pull down resistors should define wire's voltage 
level. With the rising edge of the reset signal these levels will be latched 
into internal config registers.
We are in trouble when we want to reboot the system (also watchdog based) or 
the internal watchdog barks and generates the CPU internal reset signal. In 
these cases these config pins will not change their level! So the wrong 
settings are latched in and our CPU is dead (misconfigured), sometimes a 
second reset helps, but most of the time only power cycling helps.

What we see is:
 - at the pins ETH_0 and ETH_3 (both are output only, when used for
   ethernet)

 * With an external 10k pulldown these lines never change their 3.3V level
   even if the reset is active!
 * With an external 1k pulldown these lines change their 3.3V level down to
   something about 2.5V when the falling edge of the reset signal occurs.
 * This level decreases slowly to 1.2V in about 1.2ms and than a falling edge
   to 0V occures. Problem here is, the internal watchdog's generated reset
   signal is much shorter, so the rising edge of this reset signal also
   latches in the wrong settings and the CPU is dead.

Some other things we see. A reset while:
 - a running tftp command in U-Boot with disconnected network
- system is always dead
 - a running tftp command in U-Boot with connected network
- system restarts
   We can see in this case, the ETH_0 and ETH_3 are switching to low
   level *immediatly* with the falling edge of the reset signal
 - an activated interface (ifconfig up) in Linux with *disconnected* network
- system is always dead
 - an activated interface (ifconfig up) in Linux with *connected* network
- system is always dead

Does anybody see a behaviour like ours on his/her MPC5200B based system?
Does anybody have an idea what the difference between U-Boot und Linux could 
be? Bug? Feature?

Regards,
Juergen

-- 
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
    Handelsregister: Amtsgericht Hildesheim, HRA 2686
     Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] ftrace: mcountrecord.pl for arm

[Steven Rostedt]

On Fri, 21 Nov 2008, Russell King - ARM Linux wrote:

 On Thu, Nov 20, 2008 at 02:11:49PM -0800, Jim Radford wrote:
  Ingo and Steven,
  
  Here's an updated version of the arch/arm changes for dynamic ftrace
  based on top of your latest tip/master.
 
 Excuse me if I'm rather confused, but...
 
 When ftrace for ARM was originally merged, neither linux-arm-kernel
 nor myself were copied with the patches.  Now, I'm being sent updates
 to code that I've no understanding of and haven't seen before.
 
 I mean, yes, it's nice to be copied with patches which are relevent.
 It would've been even nicer to have been copied with the patches adding
 ftrace in the first place, so people knew something about it and were
 aware of the changes.
 
 It seems to me like there's been a total breakdown of communication
 when ftrace was initially merged...

Yes I totally agree that in the beginning there was a breakdown of
communication. I myself just learned of the ARM port.

 
 So, questions: has ftrace actually been tested on ARM at all?  Has it
 been reviewed?  Which ARM platforms has it been tried on?  How stable
 is it?  How has it been implemented on ARM?  Does it rely on any CPU
 specific behaviour?
 
 Looking at the git history, ftrace was merged via Ingo, so I assume
 that Ingo has some understanding of this code.  So, for the time being
 if these are urgent updates, I suggest that updates go through Ingo's
 tree rather than mine.

I would suggest that they at least get an ACK from you. The original
code should have too.

 
 And looking at arch/arm/kernel/ftrace.c, it's incompatible with Thumb2
 which we've been working towards supporting.  What about SMP?  ARM is
 a SMP capable architecture now, and I see no locking in there - what
 I do see is static data with pointers to it being returned to other
 code... Yuck.

Some of this code will be redesigned in 29. But as for the locking, this 
code is run under kstop_machine. Which means that even on SMP 
architectures, this acts like a UP box.  Some of the code can be run 
outside of kstop_machine, but it is protected by locks in the module code.
I'll take a look at the ftrace.c arm code and see if there's any problems 
with it. I wrote the x86 version as well as the coming PowerPC port.

Thanks,

-- Steve

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] ftrace: mcountrecord.pl for arm

[Russell King - ARM Linux]

On Thu, Nov 20, 2008 at 02:11:49PM -0800, Jim Radford wrote:
 Ingo and Steven,
 
 Here's an updated version of the arch/arm changes for dynamic ftrace
 based on top of your latest tip/master.

Excuse me if I'm rather confused, but...

When ftrace for ARM was originally merged, neither linux-arm-kernel
nor myself were copied with the patches.  Now, I'm being sent updates
to code that I've no understanding of and haven't seen before.

I mean, yes, it's nice to be copied with patches which are relevent.
It would've been even nicer to have been copied with the patches adding
ftrace in the first place, so people knew something about it and were
aware of the changes.

It seems to me like there's been a total breakdown of communication
when ftrace was initially merged...

So, questions: has ftrace actually been tested on ARM at all?  Has it
been reviewed?  Which ARM platforms has it been tried on?  How stable
is it?  How has it been implemented on ARM?  Does it rely on any CPU
specific behaviour?

Looking at the git history, ftrace was merged via Ingo, so I assume
that Ingo has some understanding of this code.  So, for the time being
if these are urgent updates, I suggest that updates go through Ingo's
tree rather than mine.

And looking at arch/arm/kernel/ftrace.c, it's incompatible with Thumb2
which we've been working towards supporting.  What about SMP?  ARM is
a SMP capable architecture now, and I see no locking in there - what
I do see is static data with pointers to it being returned to other
code... Yuck.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re :Re: [Ltib] ltib error -linux2.6.20.6 with MPC8360E MDS

[nanda]

Hi Stuart,nbsp;nbsp; Thanks for the information.nbsp;nbsp; gpp access was 
resolved. nbsp;nbsp; I was successful in building the linux 2.6.11 using the 
ltib and able to bring up the MPC8360 EMDS.But, I stillnbsp;face the problem 
for linux kernel 2.6.19 and 2.6.20.nbsp;nbsp;nbsp;When I tried using ltib in 
thenbsp;bringing up the board.nbsp;nbsp;nbsp;The MPC 8360 board keeps 
rebooting after downloading the image Power PC Kernel Image(uImage) and Power 
PC RAMDisk Image(rootfs.ext2.gz.uboot)nbsp;nbsp;build by the 
ltibnbsp;nbsp; nbsp; Please clarrify on the same.Thanks in 
advance.Regards,Nandanbsp;nbsp;On Thu, 20 Nov 2008 18:40:36  Stuart 
Hughes wroteHi Nanda,This is happening because you don't have access 
tohttp://www.bitshrine.org/gpp for some reason.If LTIB needs to download 
sources to build a package, it will get themfrom bitshrine.org. Can you check 
that you are able to access this URLfrom the command line with wget.Regards, 
StuartOn Thu, 2008-11-20 
 at 18:30 , nanda wrote:gt; Hi All,gt; Iam forwarding the mail which I 
have posted to powerpc linux listgt; Linuxppc-dev@ozlabs.orggt; 
===gt; gt; Iam getting the 
below error during the generation ofgt; rootfs.ext2.gz.uboot (Power PC Linux 
RAM Disk Image) and uImage (Powergt; PC Linux Kernel Image) for linux-2.6.20.6 
kernel on the power PC MPCgt; 8360E MDS using ltib tool.gt; gt; Testing 
ppp_url connectivity: FAIL, disabling gt; gt; Testing gpp_url connectivity: 
FAIL, disabling gt; gt; No network download connection availablegt; gt; I 
did the following steps, but Iam unable to generate thegt; 
rootfs.ext2.gz.uboot gt; gt; - In the ltib directory gt; gt; ./ltib 
--configuregt; gt; In the configure menu, I specified the following, before 
saving thegt; configsgt; gt; - Tool chain as (gcc-3.4.3/glibc-2.3.3)gt; 
gt; - uboot 1.1.3gt; gt; - Kernel (local linux directory build) which 
refers to the loca
 lgt; directory where linux-2.6.20.6 is placedgt; gt; - Kernel config 
filespecified as mpc8360emds_defconfig, which is thegt; file copiedgt; from 
/home/nanda/linux2.6.20.6/arch/powerpc/configs/mpc8360emds_defconfig to the 
ltib/config/platform/mpc8360epb directory) gt; gt; - Linux Target 
Architecture as powerpcgt; gt; After the above process by saving the 
configuration (it startedgt; building kernel and generated uImage) and failed 
in the below placegt; (Refer also the attached build.txt file)gt; gt; 
gt; gt; Processing: skell gt; gt; 
=== gt; gt; Testing ppp_url connectivity: FAIL, disabling 
gt; gt; Testing gpp_url connectivity: FAIL, disabling gt; gt; No network 
download connection availablegt; gt; Started: Thu Nov 20 14:44:45 2008 gt; 
gt; Ended: Thu Nov 20 14:57:32 2008 gt; gt; Elapsed: 767 seconds gt; gt; 
Build Failedgt; gt; =gt; gt; I have 
attached the 
 below files for boot and build logs with thisgt; mail, gt; gt; 1) 
defconfig.dev - default config generated for ./ltib configuregt; from 
config/platform/mpc8360epb gt; gt; 2) build.txt - Error build during ./ltib 
configure outputgt; gt; 3) mpc8360emds_defconfig - Default config filegt; 
from /home/nanda/linux2.6.20.6/arch/powerpc/configs/ gt; gt; The end result 
was I could only see the uImage generated withoutgt; rootfs.ext2.gz.uboot. 
Please clarify on the same gt; gt; Thanks in advance,gt; gt; Regards,gt; 
gt; Nandagt; ___Linuxppc-dev 
mailing [EMAIL PROTECTED]://ozlabs.org/mailman/listinfo/linuxppc-dev___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Re :Re: [Ltib] ltib error -linux2.6.20.6 with MPC8360E MDS

[Stuart Hughes]

Hi Nanda,

You'll need to get help from the kernel experts with this issue.

Regards, Stuart

On Fri, 2008-11-21 at 14:16 +, nanda wrote:
 Hi Stuart,
Thanks for the information.   gpp access was resolved. 
I was successful in building the linux 2.6.11 using the ltib and
 able to bring up the MPC8360 EMDS.
 But, I still face the problem for linux kernel 2.6.19 and
 2.6.20.   When I tried using ltib in the bringing up the board. 
   The MPC 8360 board keeps rebooting after downloading the image Power
 PC Kernel Image(uImage) and Power PC RAMDisk
 Image(rootfs.ext2.gz.uboot)  build by the ltib 
 Please clarrify on the same.
 
 Thanks in advance.
 
 Regards,
 Nanda
 
  
 
  
 On Thu, 20 Nov 2008 18:40:36  Stuart Hughes wrote
 Hi Nanda,
 
 This is happening because you don't have access to
 http://www.bitshrine.org/gpp for some reason.
 
 If LTIB needs to download sources to build a package, it will get them
 from bitshrine.org. Can you check that you are able to access this URL
 from the command line with wget.
 
 Regards, Stuart
 
 On Thu, 2008-11-20 at 18:30 , nanda wrote:
  Hi All,
  Iam forwarding the mail which I have posted to powerpc linux list
  Linuxppc-dev@ozlabs.org
  ===
  
  Iam getting the below error during the generation of
  rootfs.ext2.gz.uboot (Power PC Linux RAM Disk Image) and uImage
 (Power
  PC Linux Kernel Image) for linux-2.6.20.6 kernel on the power PC MPC
  8360E MDS using ltib tool.
  
  Testing ppp_url connectivity: FAIL, disabling 
  
  Testing gpp_url connectivity: FAIL, disabling 
  
  No network download connection available
  
  I did the following steps, but Iam unable to generate the
  rootfs.ext2.gz.uboot 
  
  - In the ltib directory 
  
  ./ltib --configure
  
  In the configure menu, I specified the following, before saving the
  configs
  
  - Tool chain as (gcc-3.4.3/glibc-2.3.3)
  
  - uboot 1.1.3
  
  - Kernel (local linux directory build) which refers to the local
  directory where linux-2.6.20.6 is placed
  
  - Kernel config filespecified as mpc8360emds_defconfig, which is
 the
  file copied
 
 from /home/nanda/linux2.6.20.6/arch/powerpc/configs/mpc8360emds_defconfig to 
 the ltib/config/platform/mpc8360epb directory) 
  
  - Linux Target Architecture as powerpc
  
  After the above process by saving the configuration (it started
  building kernel and generated uImage) and failed in the below place
  (Refer also the attached build.txt file)
  
  
  
  Processing: skell 
  
  === 
  
  Testing ppp_url connectivity: FAIL, disabling 
  
  Testing gpp_url connectivity: FAIL, disabling 
  
  No network download connection available
  
  Started: Thu Nov 20 14:44:45 2008 
  
  Ended: Thu Nov 20 14:57:32 2008 
  
  Elapsed: 767 seconds 
  
  Build Failed
  
  =
  
  I have attached the below files for boot and build logs with this
  mail, 
  
  1) defconfig.dev - default config generated for ./ltib configure
  from config/platform/mpc8360epb 
  
  2) build.txt - Error build during ./ltib configure output
  
  3) mpc8360emds_defconfig - Default config file
  from /home/nanda/linux2.6.20.6/arch/powerpc/configs/ 
  
  The end result was I could only see the uImage generated without
  rootfs.ext2.gz.uboot. Please clarify on the same 
  
  Thanks in advance,
  
  Regards,
  
  Nanda
  
 
 
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-dev
 
 
 Rediff Shopping

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] powerpc/mpic: don't reset affinity for secondary MPIC on boot

[Arnd Bergmann]

On Friday 21 November 2008, Benjamin Herrenschmidt wrote:
 Oh just that for powermac for example, I know I'm resetting the thing,
 so can't rely on init values, and on some BML embedded boxes too, while
 on things like cell I don't off hand know what the right CPU number is
 to hit the right C3PO interrupt, so I'm better off reading what SLOF
 did :-)

The current code will always use destination 0 for any MPIC, because
mpic_init is run befew smp_init and it currently uses the local CPU.

If an SMP powermac requires a specific destination setting in the
secondary MPIC, either the current mpic_init code is broken there
in the same way as on cell, or more broken if it requires something
other than destination 0.

 But if you think on Cell we can just hard wire in the platform code,
 then I'm ok.

On cell, I know that destination 0 is always correct because of the wiring
inside of Axon.

Arnd 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] IB/ehca: Fix lockdep failures for shca_list_lock

[Joachim Fenkes]

From: Michael Ellerman [EMAIL PROTECTED]

shca_list_lock is taken from softirq context in ehca_poll_eqs, so we need to
lock IRQ safe elsewhere.

Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
Acked-by: Joachim Fenkes [EMAIL PROTECTED]
---
 drivers/infiniband/hw/ehca/ehca_main.c |   17 ++---
 1 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/infiniband/hw/ehca/ehca_main.c 
b/drivers/infiniband/hw/ehca/ehca_main.c
index bb02a86..021c454 100644
--- a/drivers/infiniband/hw/ehca/ehca_main.c
+++ b/drivers/infiniband/hw/ehca/ehca_main.c
@@ -717,6 +717,7 @@ static int __devinit ehca_probe(struct of_device *dev,
const u64 *handle;
struct ib_pd *ibpd;
int ret, i, eq_size;
+   u64 flags;
 
handle = of_get_property(dev-node, ibm,hca-handle, NULL);
if (!handle) {
@@ -830,9 +831,9 @@ static int __devinit ehca_probe(struct of_device *dev,
ehca_err(shca-ib_device,
 Cannot create device attributes  ret=%d, ret);
 
-   spin_lock(shca_list_lock);
+   spin_lock_irqsave(shca_list_lock, flags);
list_add(shca-shca_list, shca_list);
-   spin_unlock(shca_list_lock);
+   spin_unlock_irqrestore(shca_list_lock, flags);
 
return 0;
 
@@ -878,6 +879,7 @@ probe1:
 static int __devexit ehca_remove(struct of_device *dev)
 {
struct ehca_shca *shca = dev-dev.driver_data;
+   u64 flags;
int ret;
 
sysfs_remove_group(dev-dev.kobj, ehca_dev_attr_grp);
@@ -915,9 +917,9 @@ static int __devexit ehca_remove(struct of_device *dev)
 
ib_dealloc_device(shca-ib_device);
 
-   spin_lock(shca_list_lock);
+   spin_lock_irqsave(shca_list_lock, flags);
list_del(shca-shca_list);
-   spin_unlock(shca_list_lock);
+   spin_unlock_irqrestore(shca_list_lock, flags);
 
return ret;
 }
@@ -975,6 +977,7 @@ static int ehca_mem_notifier(struct notifier_block *nb,
 unsigned long action, void *data)
 {
static unsigned long ehca_dmem_warn_time;
+   unsigned long flags;
 
switch (action) {
case MEM_CANCEL_OFFLINE:
@@ -985,12 +988,12 @@ static int ehca_mem_notifier(struct notifier_block *nb,
case MEM_GOING_ONLINE:
case MEM_GOING_OFFLINE:
/* only ok if no hca is attached to the lpar */
-   spin_lock(shca_list_lock);
+   spin_lock_irqsave(shca_list_lock, flags);
if (list_empty(shca_list)) {
-   spin_unlock(shca_list_lock);
+   spin_unlock_irqrestore(shca_list_lock, flags);
return NOTIFY_OK;
} else {
-   spin_unlock(shca_list_lock);
+   spin_unlock_irqrestore(shca_list_lock, flags);
if (printk_timed_ratelimit(ehca_dmem_warn_time,
   30 * 1000))
ehca_gen_err(DMEM operations are not allowed
-- 
1.5.5



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc: udbg based backend for hvc_console

[Milton Miller]

On Nov 20, 2008, at 1:16 PM, Timur Tabi wrote:


Milton Miller wrote:

Stated differently, if your routine (1) fundamently works one 
character

at a time and (2) is not interrupt driven, and (3) only supports one
channel, what avantage is there to an explicit hvc driver?


I think it's because HVC has the ability to use HVC client drivers for 
console
and TTY, but udbg does not.  So if you have a udbg-only driver, it 
will cease to

function when the kernel switches to the normal console.

Perhaps it would make more sense to have the kernel continue to use 
udbg if
there is no normal console driver, instead of relying on David's 
driver.


First, we have that option: just specify udbg-imortal on the command 
line, and the udbg console driver removes CON_BOOT from its flags.


Second, as David said in his reply, that doesn't let your userspace 
have a tty, which means no job control.



I too challanged the necessity of that change.  I carefully designed
the hvc_console layer to find the selected console weither it was
registered before or after the console_initcall of hvc_console.


I'm just pointing out the patch that was committed in 2006 to address 
this
issue.  I discovered the same bug that the patch mentioned, and only 
after a
long time searching did I find this patch.  And sure enough, 
re-arranging the

Makefile made the problem I was seeing go away.

Now, it's possible that this bug in hvc_console no longer exists.  
However, I
have seen nothing to indicate it.  Unfortunately, I don't remember 
enough of the

details to reproduce the problem, so I can't verify it.


As I said, I conceeded then the patch was required the way things 
worked.  There was another propsed patch a few months ago (3-9) that I 
pointed out they needed to be fixing the common console code; I don't 
remember seeing anything related after that but I could have missed it.



However, I think the bottom line was that add_preferred_console is
suppsoed to be called by architecture setup code.   Doing it the
console_initcall is almost abuse.  But if the console_initcall is 
going
to call add_preferred_console, then it must link before the 
hvc_console

driver.   I would have to go back and find the discussion to remember
the exact details.  (maybe it only needed to call
add_preferreed_console before registering itself if its the only hvc
backend).


Well, I can't comment on your theory, but I do know that the
add_preferred_console() call should be made from the HVC client 
driver, or at
least HVC itself.  It should not be in the platform code, because then 
we have a
dependency between the driver and the platform code.  I prefer my 
drivers to
initialize everything on their own, without the help of the platform 
code.


Think about this for a second.

If every console driver said prefer me, what point is there in having 
add_preferred_console?


The second reason is its too late.  We have already started scanning 
for drivers.  We are asking the console layer to adjust its choices 
after it has started scanning.


We want the last console= parameter on the command line to win.  So if 
that implys the last call to add_preferred_console wins, then you have 
code overriding the command line.



We have code that searches the device tree for the stdout that firmware 
used.  That code then tells the console layer which driver to choose 
when it recognises it.   The pSeries platform also has code that says 
when it finds vterm channels under lpar, then it should choose it.


I think we should have the code that sets the udbg method indicate that 
the console should be preferred.  While its not really arch code, it is 
architecture code in that its hooked from early discovrey based not 
cosole_initcall based (which runs before arch_initcall).  This is also 
the point where we know if the udbg method is sharing hardware with a 
full driver and therefore udbg_hvc should not be used.


milton

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] cpm2: Round the baud-rate clock divider to the nearest integer.

[Laurent Pinchart]

Hi Scott,

On Thursday 20 November 2008, Scott Wood wrote:
 On Thu, Nov 20, 2008 at 01:32:23PM +0100, Laurent Pinchart wrote:
  Instead of rounding the divider down, improve the baud-rate generators
  accuracy by rounding to the nearest integer.
 
  Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]

 This makes things worse on mpc8272ads -- the result of the division is
 13.56, but I only get error-free serial output when rounding down.  I
 don't think the remote end has timing problems, as I don't see this with
 any other board.

I get exactly the opposite here with an mpc8248 base board. Rounding down 
makes 115200bds completely unreliable :-/

Could you measure the serial baudrate with and without the patch using an 
oscilloscope ?

 Possibly the crystal is a little off,

That's always possible.

 or maybe it's just better to be a little too fast than a little too slow for
 some reason? 

 Maybe we should change CPM_CLK to be MAIN_CLK/4 rather than MAIN_CLK/16
 when the BRG clock is below a certain frequency.

Isn't that the job of the boot loader ? Accuracy would be improved, but power 
consumption will raise as well :-/

Best regards,

Laurent Pinchart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc: udbg based backend for hvc_console

[Timur Tabi]

Milton Miller wrote:

 We want the last console= parameter on the command line to win.  So if 
 that implys the last call to add_preferred_console wins, then you have 
 code overriding the command line.

Hmm, good point.  However, how likely is it that we'll have more than one
console driver?  Also, without calling add_preferred_console(), the kernel needs
to have a console= on the command line.

In my case, my driver only calls add_preferred_console() if the device tree
contains a specific property that it looks for.  In effect, this property
override the console= line.  However, the console= line goes to the HVC
subsystem, and not my driver, and I can't use it to send the configuration data
the driver needs.

Unfortunately, my driver hasn't been published yet, so it's hard to explain the
details.  I guess I need to think about this more.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] IB/ehca: Fix locking for shca_list_lock

[Joachim Fenkes]

shca_list_lock is taken from softirq context in ehca_poll_eqs, so we need to
lock IRQ safe elsewhere.

Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---

On Friday 21 November 2008 17:02, Johannes Berg wrote:
 On Fri, 2008-11-21 at 16:37 +0100, Joachim Fenkes wrote:
 
  +   u64 flags;
 
  -   spin_lock(shca_list_lock);
  +   spin_lock_irqsave(shca_list_lock, flags);
 
 That's wrong and I think will give a warning on all machines where
 u64 != unsigned long. Might not particularly matter in this case.

Doesn't matter for a ppc64 only driver, but you're right nonetheless. Thanks.
 
 Also, generally it seems wrong to say fix lockdep failure when the
 patch really fixes a bug that lockdep happened to find.

Whatever -- changed.

Here's the updated patch.

Regards,
  Joachim


 drivers/infiniband/hw/ehca/ehca_main.c |   17 ++---
 1 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/infiniband/hw/ehca/ehca_main.c 
b/drivers/infiniband/hw/ehca/ehca_main.c
index bb02a86..169aa1a 100644
--- a/drivers/infiniband/hw/ehca/ehca_main.c
+++ b/drivers/infiniband/hw/ehca/ehca_main.c
@@ -717,6 +717,7 @@ static int __devinit ehca_probe(struct of_device *dev,
const u64 *handle;
struct ib_pd *ibpd;
int ret, i, eq_size;
+   unsigned long flags;
 
handle = of_get_property(dev-node, ibm,hca-handle, NULL);
if (!handle) {
@@ -830,9 +831,9 @@ static int __devinit ehca_probe(struct of_device *dev,
ehca_err(shca-ib_device,
 Cannot create device attributes  ret=%d, ret);
 
-   spin_lock(shca_list_lock);
+   spin_lock_irqsave(shca_list_lock, flags);
list_add(shca-shca_list, shca_list);
-   spin_unlock(shca_list_lock);
+   spin_unlock_irqrestore(shca_list_lock, flags);
 
return 0;
 
@@ -878,6 +879,7 @@ probe1:
 static int __devexit ehca_remove(struct of_device *dev)
 {
struct ehca_shca *shca = dev-dev.driver_data;
+   unsigned long flags;
int ret;
 
sysfs_remove_group(dev-dev.kobj, ehca_dev_attr_grp);
@@ -915,9 +917,9 @@ static int __devexit ehca_remove(struct of_device *dev)
 
ib_dealloc_device(shca-ib_device);
 
-   spin_lock(shca_list_lock);
+   spin_lock_irqsave(shca_list_lock, flags);
list_del(shca-shca_list);
-   spin_unlock(shca_list_lock);
+   spin_unlock_irqrestore(shca_list_lock, flags);
 
return ret;
 }
@@ -975,6 +977,7 @@ static int ehca_mem_notifier(struct notifier_block *nb,
 unsigned long action, void *data)
 {
static unsigned long ehca_dmem_warn_time;
+   unsigned long flags;
 
switch (action) {
case MEM_CANCEL_OFFLINE:
@@ -985,12 +988,12 @@ static int ehca_mem_notifier(struct notifier_block *nb,
case MEM_GOING_ONLINE:
case MEM_GOING_OFFLINE:
/* only ok if no hca is attached to the lpar */
-   spin_lock(shca_list_lock);
+   spin_lock_irqsave(shca_list_lock, flags);
if (list_empty(shca_list)) {
-   spin_unlock(shca_list_lock);
+   spin_unlock_irqrestore(shca_list_lock, flags);
return NOTIFY_OK;
} else {
-   spin_unlock(shca_list_lock);
+   spin_unlock_irqrestore(shca_list_lock, flags);
if (printk_timed_ratelimit(ehca_dmem_warn_time,
   30 * 1000))
ehca_gen_err(DMEM operations are not allowed
-- 
1.5.5



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: MPC5200B: Trouble with config pins

[Andre Schwarz]

Jürgen,

Have a look at the manual chapter 4 (=Reset + Config).
SRESET (issued by gpt0 - watchdog) isn't supposed to do a full hardware 
reset.

Looks like you should make use of the SRESET and trigger HRESET accordingly.

I could solve this with _not_ using the internal watchdog but an 
external one (TPS3828),

i.e. watchdog timeouts and reboots are always issued by PORESET.



regards,
Andre


Juergen Beisert schrieb:

Hi all,

we have trouble with the eth based config pins (ETH0...ETH6) of the MPC5200B 
CPU. These pins act as the interface to an external phy and also act as 
configurations pins to configure the size of the flash and other things. 
While the reset is active these pins should be in their high impedance state 
and the externally connected pull down resistors should define wire's voltage 
level. With the rising edge of the reset signal these levels will be latched 
into internal config registers.
We are in trouble when we want to reboot the system (also watchdog based) or 
the internal watchdog barks and generates the CPU internal reset signal. In 
these cases these config pins will not change their level! So the wrong 
settings are latched in and our CPU is dead (misconfigured), sometimes a 
second reset helps, but most of the time only power cycling helps.


What we see is:
 - at the pins ETH_0 and ETH_3 (both are output only, when used for
   ethernet)

 * With an external 10k pulldown these lines never change their 3.3V level
   even if the reset is active!
 * With an external 1k pulldown these lines change their 3.3V level down to
   something about 2.5V when the falling edge of the reset signal occurs.
 * This level decreases slowly to 1.2V in about 1.2ms and than a falling edge
   to 0V occures. Problem here is, the internal watchdog's generated reset
   signal is much shorter, so the rising edge of this reset signal also
   latches in the wrong settings and the CPU is dead.

Some other things we see. A reset while:
 - a running tftp command in U-Boot with disconnected network
- system is always dead
 - a running tftp command in U-Boot with connected network
- system restarts
   We can see in this case, the ETH_0 and ETH_3 are switching to low
   level *immediatly* with the falling edge of the reset signal
 - an activated interface (ifconfig up) in Linux with *disconnected* network
- system is always dead
 - an activated interface (ifconfig up) in Linux with *connected* network
- system is always dead

Does anybody see a behaviour like ours on his/her MPC5200B based system?
Does anybody have an idea what the difference between U-Boot und Linux could 
be? Bug? Feature?


Regards,
Juergen

  



MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler  - Registergericht: 
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: MPC5200B: Trouble with config pins

[Juergen Beisert]

Hi Andre,

On Freitag, 21. November 2008, Andre Schwarz wrote:
 Have a look at the manual chapter 4 (=Reset + Config).
 SRESET (issued by gpt0 - watchdog) isn't supposed to do a full hardware
 reset.
 Looks like you should make use of the SRESET and trigger HRESET
 accordingly.

 I could solve this with _not_ using the internal watchdog but an
 external one (TPS3828),
 i.e. watchdog timeouts and reboots are always issued by PORESET.

We are using an external watchdog now. But same behaviour. It hurts less, 
because we increase the length of the active reset signal to add more time to 
let the pin find its low level. But I'm not really happy about this 
solution...

Regards,
Juergen

-- 
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
    Handelsregister: Amtsgericht Hildesheim, HRA 2686
     Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] cpm2: Round the baud-rate clock divider to the nearest integer.

[Scott Wood]

Laurent Pinchart wrote:

On Thursday 20 November 2008, Scott Wood wrote:

This makes things worse on mpc8272ads -- the result of the division is
13.56, but I only get error-free serial output when rounding down.  I
don't think the remote end has timing problems, as I don't see this with
any other board.


I get exactly the opposite here with an mpc8248 base board. Rounding down 
makes 115200bds completely unreliable :-/


Hmm...  In that case, I'm OK with the patch as it's technically more 
correct, and clearly what we want if the quotient comes out to something 
like 13.95.  Maybe mpc8272ads board code could apply some sort of tweak 
to the brg frequency.


The right answer is probably that if you want reliable standard baud 
rates, the board designer should ensure a suitable clock is available, 
rather than picking some random clock and hoping it divides nicely.


Could you measure the serial baudrate with and without the patch using an 
oscilloscope ?


Not easily; I'm a software person and would have to track down someone 
to lend me one and show me how to use it.  I may try using ntpdate to 
measure timebase drift, as it should be off by the same percentage.



Maybe we should change CPM_CLK to be MAIN_CLK/4 rather than MAIN_CLK/16
when the BRG clock is below a certain frequency.


Isn't that the job of the boot loader ?


Sure, I didn't necessarily mean linux by we. :-)

Accuracy would be improved, but power 
consumption will raise as well :-/


Granted... though it's actually BRG_CLK and not CPM_CLK that I meant, so 
hopefully it wouldn't make too much of a difference in power.


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [spi-devel-general] [PATCH v4] spi: Add PPC4xx SPI driver

[Stefan Roese]

Dave,

On Friday 21 November 2008, David Brownell wrote:
 On Friday 31 October 2008, Stefan Roese wrote:
  +   dev_dbg(spi-dev, %s: mode %d, %u bpw, %d hz\n,
  +   __FUNCTION__, spi-mode, spi-bits_per_word,
  +   spi-max_speed_hz);

 Oh, and checkpatch.pl would warn about __FUNCTION__ vs __func__ ...

Thanks for the review. I'll address the issues in an updated patch next week.

Best regards,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] IB/ehca: Fix locking for shca_list_lock

[Roland Dreier]

Looks good... I'll add this for 2.6.29, since as far as I can tell this
bug has been there approximately forever already.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc: udbg based backend for hvc_console

[Milton Miller]

On Nov 21, 2008, at 10:13 AM, Timur Tabi wrote:

Milton Miller wrote:

We want the last console= parameter on the command line to win.  So if
that implys the last call to add_preferred_console wins, then you have
code overriding the command line.


Hmm, good point.  However, how likely is it that we'll have more than 
one

console driver?


For anything than custom embedded configs, quite likely.   As I said, I 
have 3 hvc clients, but that is unusual.  But frame buffer, vterm, 
rtas, and serial console would be a typical mix for a distribution.



Also, without calling add_preferred_console(), the kernel needs
to have a console= on the command line.


I'm not arguing against the call, I'm arguing when/from where it should 
be made.


In my case, my driver only calls add_preferred_console() if the device 
tree
contains a specific property that it looks for.  In effect, this 
property

override the console= line.  However, the console= line goes to the HVC
subsystem, and not my driver, and I can't use it to send the 
configuration data

the driver needs.


Discovering the hardware from the device tree and triggering your 
regitration is the right approach.  I think if you discover from an 
early setup then you can go before the command line.


As far as getting parameters, you are talking like ttyS0,9600,8,n,1 ? 
If you go after hvc_console then you could add a patch for hvc_console 
to remember the setup and return it to possible clients.


Unfortunately, my driver hasn't been published yet, so it's hard to 
explain the

details.  I guess I need to think about this more.


I dont' know what details you would want on the console= command line 
that you should not have in the device tree.   If its which hypervisor 
channel, then I would think just choosing your hvc number accordingly 
would work.  But I can only make wild guesses without details.


milton

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc: udbg based backend for hvc_console

[Milton Miller]

On Nov 20, 2008, at 6:35 PM, David Gibson wrote:

On Thu, Nov 20, 2008 at 01:07:11PM -0600, Milton Miller wrote:

David Gibson wrote at 2008-11-18 00:28:28:

On Mon, Nov 17, 2008 at 01:41:24PM -0600, Timur Tabi wrote:

On Thu, Oct 23, 2008 at 9:54 PM, David Gibson
[EMAIL PROTECTED] wrote:

This patch adds a new backend for the hvc console based on the
low-level udbg callbacks.  This effectively implements a working
runtime console in terms of the simple udbg primitives.  This is 
kind

of a hack - since udbg isn't something you really want to be using
routinely - but it's really useful during bringup.


Why is udbg hvc something you want to not use routinely?


Well.. because the udbg methods themselves are not sometimes (not
always, but reasonably often), something you don't really want to use
except during bringup.  A number of them use various hacks that lets
them work very early, and very reliably even when much of the kernel
is borked, but aren't the sort of thing you want to do except during
bringup.  e.g. being mapped by special bolted TLB entries established
very early, rather than using ioremap(); polled access for interrupt
capable devices; hard-coded device addresses, meaning the kernel will
only work on one precise type of system.


You are describing the CONFIG_PPC_DEBUG_EARLY udbg methods, but they 
are far from all of the available methods.  Several methods use the 
standard kernel apis, or do not need them (rtas, vterm).  If we had 
this, would we need hvc_rtas?


Stated differently, if your routine (1) fundamently works one 
character

at a time and (2) is not interrupt driven, and (3) only supports one
channel, what avantage is there to an explicit hvc driver?


Using standard kernel interfaces, instead of random early debug hacks.


I was thinking of the less hackish udbg hooks that registsered in the 
platform setup timeframe.  Not requiring a pinned tlb that you would 
not want for io performance anyways I can see.




Actually it looks remarkably similar to a cleaned up version of a 
patch
i've been using since hvc_console was split to be a hookable shell.  
Or

was it the motivation for adding the hooks?


Heh, ok.


...

Um.. well.. if you have both activated, I think you can select which
HVC console backend will be used by using console=/dev/hvcNN on the
commandline, where values of NN correspond to different backends, in
order depending on link order in some complex fashion.


It doesn't just work that way because of the way the hvc_console shell
implements the console hooks.

If the drivers request different hvc channel numbers, then yes, you 
can

select which hvc backend is used by choosing console=hvcNN.  If all
request 0, then which ever one registers with hvc_console first wins 
the
slot, and the others get a busy error return.   They can still 
register

their tty later, at which point they get a dynamically determined
/dev/hvcN slot, above all registered console slots.


Ah, ok, my mistake.

There are multiple reasons for this design.  The original user, 
pseries

vterm, wants to assign the channel number based on what the hypervisor
tells it the channel should be.  There are two loops though the device
tree, searching for different protocols (and consequently different
backends), so they need to be able to specify the number and not just
use the order they are found.  The platform describes not only the
protocol, but which instance that is, and the backend currently
registers with that number.  Another reason is its a bad idea to have
console=/dev/hvc0 depend on link order instead of knowing which driver
is selected.  If a user is specifing what the console is, it should 
not

depend on other linked drivers.

Until this point, all mainline drivers have been exclusive in that 
only

one will actually register with hvc_console midlayer on any given
platform.  This is the first backend that is not exclusive, and
therefore its coexistence needs special attention.

In my internal tree, I register (my version of) this not as hvc0 but 
as

hvc4.  hvc0 is rtas, hvc1-3 are an internal backend, and this one is
hvc4.  The order I chose is arbitrary, but the main point is it does't
compete with hvc_rtas for slot 0.  (All of these drivers coexist, and 
I
can choose which one I want to use based on my needs for that boot.)  
We
could make it configurable via Kconfig, or just choose a slot.  (I 
think

vterm can have 2 channels on some boxes where they drive real serial
ports on the box.)


Hrm, ok.  Not sure what the sensible way to do this for my case would
be.


But if you already have a working HVC console driver, I don't see why
you'd want to use HVC_UDBG - it's essentially a bringup hack.


As I said, why should we need a fancier hvc_console backend if you are
polling and gain no efficency processing  multiple characters at once.

The udbg drivers know if they are sharing the interface with a
hvc_console some other driver.  If we trigger the registration of this
backend on the 

Re: [PATCH] powerpc/mpic: don't reset affinity for secondary MPIC on boot

[Benjamin Herrenschmidt]

On Fri, 2008-11-21 at 15:40 +0100, Arnd Bergmann wrote:
 On Friday 21 November 2008, Benjamin Herrenschmidt wrote:
  Oh just that for powermac for example, I know I'm resetting the thing,
  so can't rely on init values, and on some BML embedded boxes too, while
  on things like cell I don't off hand know what the right CPU number is
  to hit the right C3PO interrupt, so I'm better off reading what SLOF
  did :-)
 
 The current code will always use destination 0 for any MPIC, because
 mpic_init is run befew smp_init and it currently uses the local CPU.
 
 If an SMP powermac requires a specific destination setting in the
 secondary MPIC, either the current mpic_init code is broken there
 in the same way as on cell, or more broken if it requires something
 other than destination 0.
 
  But if you think on Cell we can just hard wire in the platform code,
  then I'm ok.
 
 On cell, I know that destination 0 is always correct because of the wiring
 inside of Axon.

Ok so -all- existing instances only care about destination 0, we may
just hard code that in MPIC for now :-)

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Nodes with no memory

[Dave Hansen]

I was handed off a bug report about a blade not booting with a, um
newer kernel.  After turning on some debugging messages, I got this
ominous message:

node 1
NODE_DATA() = c000

Which obviously comes from here:

arch/powerpc/mm/numa.c

for_each_online_node(nid) {
unsigned long start_pfn, end_pfn;
unsigned long bootmem_paddr;
unsigned long bootmap_pages;

get_pfn_range_for_nid(nid, start_pfn, end_pfn);

/* Allocate the node structure node local if possible */
NODE_DATA(nid) = careful_allocation(nid,
sizeof(struct pglist_data),
SMP_CACHE_BYTES, end_pfn);
NODE_DATA(nid) = __va(NODE_DATA(nid));
memset(NODE_DATA(nid), 0, sizeof(struct pglist_data));
...

careful_allocation() returns a NULL physical address, but we go ahead
and run __va() on it, stick it in NODE_DATA(), and memset it.  Yay!

I seem to recall that we fixed some issues with memoryless nodes a few
years ago, like around the memory hotplug days, but I don't see the
patches anywhere.

I'm thinking that we need to at least fix careful_allocation() to oops
and not return NULL, or check to make sure all it callers check its
return code.  Plus,  we probably also need to ensure that all ppc code
doing for_each_online_node() does not assume a valid NODE_DATA() for all
those nodes.

Any other thoughts?

I'll have a patch for the above issue sometime soon. 

-- Dave

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Nodes with no memory

[Nathan Lynch]

Dave Hansen wrote:
 I was handed off a bug report about a blade not booting with a, um
 newer kernel.

If you're unable to provide basic information such as the kernel
version then perhaps this isn't the best forum for discussing this.  :)


 I'm thinking that we need to at least fix careful_allocation() to oops
 and not return NULL, or check to make sure all it callers check its
 return code.

Well, careful_allocation() in current mainline tries pretty hard to
panic if it can't satisfy the request.  Why isn't that happening?

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev