Early driver development resources

2008-01-21 Thread Benedict, Michael
Hello,
I wrote a driver for a 4 segment digital display device.  I have
a requirement that this device be used as early as possible to report
kernel bootup state.  The driver itself is pretty simple, just using
in/out_be32() and udelay().  The problem is that I don't know how to use
hardware resources in the early stages of booting, before I can call
request_mem_region() and friends.
Can anyone recommend a book / documentation / reference code /
anything that demonstrates this, or at least could improve my
understanding enough to accomplish this?
Many thanks,
Michael

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


LED heartbeat trigger - in_atomic() while allocs

2007-11-26 Thread Benedict, Michael
I was playing around with the LED heartbeat trigger and it caught the
BUG() code when trying to activate.  Does anyone know why this call
stack would be in_atomic()?  Or any ideas for a patch that would allow
the heartbeat trigger to allocate when it is not in atomic context?

BUG: sleeping function called from invalid context at mm/slab.c:3024
in_atomic():1, irqs_disabled():0
Call Trace:
[def3dd90] [c0008e60] show_stack+0x48/0x194 (unreliable)
[def3ddc0] [c0014160] __might_sleep+0xd0/0xdc
[def3dde0] [c0063e60] kmem_cache_zalloc+0xdc/0x12c
[def3de00] [c01975c0] heartbeat_trig_activate+0x24/0x80
[def3de20] [c0196844] led_trigger_set+0x128/0x160
[def3de40] [c0196988] led_trigger_store+0x10c/0x1a8
[def3deb0] [c0162f40] class_device_attr_store+0x44/0x5c
[def3dec0] [c00ae614] sysfs_write_file+0x114/0x1dc
[def3def0] [c0068ea4] vfs_write+0x9c/0x110
[def3df10] [c0068ff4] sys_write+0x4c/0x90
[def3df40] [c000fc00] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xfe83818
LR = 0xfe35448

Kernel 2.6.22-4, powerpc, targeting an MPC 8347.  I don't think this
issue is PowerPC specific but I was hoping other embedded people might
have experience with the LED class driver.

Thank you,
Michael

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


RE: LED heartbeat trigger - in_atomic() while allocs

2007-11-26 Thread Benedict, Michael
Thanks, yeah I see that now.  I just changed the alloc to be GPF_ATOMIC
for now, but I don't really know how this was intended to work.
-Michael 

 -Original Message-
 From: 
 [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED]
rg] On Behalf Of Nathan Lynch
 Sent: Monday, November 26, 2007 2:37 PM
 To: Benedict, Michael
 Cc: linuxppc-embedded@ozlabs.org
 Subject: Re: LED heartbeat trigger - in_atomic() while allocs
 
 Benedict, Michael wrote:
  I was playing around with the LED heartbeat trigger and it 
 caught the
  BUG() code when trying to activate.  Does anyone know why this call
  stack would be in_atomic()?  Or any ideas for a patch that 
 would allow
  the heartbeat trigger to allocate when it is not in atomic context?
  
  BUG: sleeping function called from invalid context at mm/slab.c:3024
  in_atomic():1, irqs_disabled():0
  Call Trace:
  [def3dd90] [c0008e60] show_stack+0x48/0x194 (unreliable)
  [def3ddc0] [c0014160] __might_sleep+0xd0/0xdc
  [def3dde0] [c0063e60] kmem_cache_zalloc+0xdc/0x12c
  [def3de00] [c01975c0] heartbeat_trig_activate+0x24/0x80
  [def3de20] [c0196844] led_trigger_set+0x128/0x160
  [def3de40] [c0196988] led_trigger_store+0x10c/0x1a8
  [def3deb0] [c0162f40] class_device_attr_store+0x44/0x5c
  [def3dec0] [c00ae614] sysfs_write_file+0x114/0x1dc
  [def3def0] [c0068ea4] vfs_write+0x9c/0x110
  [def3df10] [c0068ff4] sys_write+0x4c/0x90
  [def3df40] [c000fc00] ret_from_syscall+0x0/0x38
  --- Exception: c01 at 0xfe83818
  LR = 0xfe35448
  
  Kernel 2.6.22-4, powerpc, targeting an MPC 8347.
 
 From a brief glance at the code, looks like led_trigger_store is
 holding a rwlock while calling led_trigger_set.
 ___
 Linuxppc-embedded mailing list
 Linuxppc-embedded@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-embedded
 
 

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


RE: futex priority based wakeup

2007-09-10 Thread Benedict, Michael
Ilya Lipovsky wrote:
 Yes, I am uncertain. If it isn't a major headache, I think
 you can try the
 newest version (I think it's 2.6.1) and see if you get some
 resolution. 
snip
 Please do share the outcome!!
 
 -Ilya

No luck with 2.6.1:

~ $ /lib/libc.so.6
GNU C Library stable release version 2.6.1, by Roland McGrath et al.
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.1.1.
Compiled on a Linux 2.6.12 system on 2007-09-10.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
http://www.gnu.org/software/libc/bugs.html.
~ $ ./bar
unimportant waiting for mutex
important waiting for mutex
main unlocking mutex
unimportant got mutex!
important got mutex!


I will continue investigating and follow up on this thread if I come
across anything.
-Michael

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


RE: futex priority based wakeup

2007-09-10 Thread Benedict, Michael
Ilya Lipovsky wrote:
 Your code looks correct to me, so if the kernel developers
 did their job
 correctly, the only potentially weak link is glibc.
 

Well, either the kernel developers didn't do their job, or I am missing
something.  The following also fails, and it should be bypassing glibc:

#define _XOPEN_SOURCE 600

#include linux/futex.h
#include sys/time.h
#include asm/atomic.h

#include sys/syscall.h
#include unistd.h

#include sched.h
#include stdint.h
#include stdio.h
#include stdlib.h

int myfutex = 0;

void *important(void *ign)
{
sleep(1);
printf(important waiting for futex\n);
fflush(stdout);
if(syscall(SYS_futex, myfutex, FUTEX_WAIT, 0, NULL)) {
perror(futex);
exit(1);
} else {
printf(important got futex!\n);
fflush(stdout);
syscall(SYS_futex, myfutex, FUTEX_WAKE, 1, NULL);
}

return NULL;
}


void *unimportant(void *ign)
{
printf(unimportant waiting for futex\n);
fflush(stdout);
if(syscall(SYS_futex, myfutex, FUTEX_WAIT, 0, NULL)) {
perror(futex);
exit(1);
} else {
printf(unimportant got futex!\n);
fflush(stdout);
syscall(SYS_futex, myfutex, FUTEX_WAKE, 1, NULL);
}

return NULL;
}

int main()
{
struct sched_param p;
pthread_attr_t attr;
pthread_t i, u;

p.__sched_priority = sched_get_priority_min(SCHED_FIFO);
if(-1 == p.__sched_priority) {
perror(sched_get_priority_min);
return 1;
}
pthread_attr_init(attr);
pthread_attr_setschedpolicy(attr, SCHED_FIFO);
pthread_attr_setschedparam(attr, p);
pthread_create(u, attr, unimportant, NULL);

p.__sched_priority = sched_get_priority_max(SCHED_FIFO);
pthread_attr_setschedparam(attr, p);
pthread_create(i, attr, important, NULL);

sleep(5);
printf(futex FUTEX_WAKE\n);
fflush(stdout);
syscall(SYS_futex, myfutex, FUTEX_WAKE, 1, NULL);

pthread_join(u, NULL);
pthread_join(i, NULL);

return 0;
}

Which produces:
unimportant waiting for futex
important waiting for futex
futex FUTEX_WAKE
unimportant got futex!
important got futex!


Could someone with 2.6.22 please verify?  

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


futex priority based wakeup

2007-09-07 Thread Benedict, Michael
I recently upgraded to 2.6.22 to get the priority based futex wakeup
behavior.  However, when I run a simple program (see below), based on
either a pthread_mutex_t or a sem_t, it seems that threads are woken up
in FIFO order.  I am using glibc 2.3.6 with NPTL and TLS, based off
crossdev-0.43.  Could someone help me get priority-based wakeup or point
me to a better place to get this question answered?
Thank you,
Michael

Code:

pthread_mutex_t mymutex = PTHREAD_MUTEX_INITIALIZER;

void *important(void *ign)
{
sleep(1);
printf(important waiting for mutex\n);
if(pthread_mutex_lock(mymutex)) {
perror(sem_wait);
exit(1);
} else {
printf(important got mutex!\n);
pthread_mutex_unlock(mymutex);
}

return NULL;
}


void *unimportant(void *ign)
{
printf(unimportant waiting for mutex\n);
if(pthread_mutex_lock(mymutex)) {
perror(sem_wait);
exit(1);
} else {
printf(unimportant got mutex!\n);
pthread_mutex_unlock(mymutex);
}

return NULL;
}

int main()
{
struct sched_param p;
pthread_attr_t attr;
pthread_t i, u;

pthread_mutex_lock(mymutex);

p.__sched_priority = sched_get_priority_min(SCHED_FIFO);
if(-1 == p.__sched_priority) {
perror(sched_get_priority_min);
return 1;
}
pthread_attr_init(attr);
pthread_attr_setschedpolicy(attr, SCHED_FIFO);
pthread_attr_setschedparam(attr, p);
pthread_create(u, attr, unimportant, NULL);

p.__sched_priority = sched_get_priority_max(SCHED_FIFO);
pthread_attr_setschedparam(attr, p);
pthread_create(i, attr, important, NULL);

sleep(5);
printf(main unlocking mutex\n);
pthread_mutex_unlock(mymutex);

pthread_join(u, NULL);
pthread_join(i, NULL);

return 0;
}

Which produces:
unimportant waiting for mutex
important waiting for mutex
main unlocking mutex
unimportant got mutex!
important got mutex!

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


RE: futex priority based wakeup

2007-09-07 Thread Benedict, Michael
Thank you for the help!

Same result with fflush :(.

Are you maybe wrong because you have tested 2.5 and it doesn't work?  Or
just uncertain?

The only thing I have read that mentions glibc version is the work Ingo
did against 2.4 glibc and in the 2.6.16-mm1 patches...
http://people.redhat.com/mingo/PI-futex-patches/.  I can not detrmine
how this relates to the 2.6.22 priority based futex wakeup commit.

I am currently fighting crosstool-0.43 to build a newer glibc and I will
share results if/when I get that to work.
-Michael

Ilya Lipovsky wrote:
 ...Or maybe I am wrong :). Could you put fflush(stdout) after
 each printf,
 just to be completely certain that it misbehaves?
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] g] On
 Behalf Of Ilya Lipovsky Sent: Friday, September 07, 2007 12:41 PM
 To: 'Benedict, Michael'; linuxppc-embedded@ozlabs.org
 Subject: RE: futex priority based wakeup
 
 Looks like it is a libc issue. Apparently, GNU libc supports priority
 futexes only in version 2.5 and higher.
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] g] On
 Behalf Of Benedict, Michael Sent: Friday, September 07, 2007 11:02 AM
 To: linuxppc-embedded@ozlabs.org
 Subject: futex priority based wakeup
 
 I recently upgraded to 2.6.22 to get the priority based futex wakeup
 behavior.  However, when I run a simple program (see below), based on
 either a pthread_mutex_t or a sem_t, it seems that threads
 are woken up
 in FIFO order.  I am using glibc 2.3.6 with NPTL and TLS, based off
 crossdev-0.43.  Could someone help me get priority-based
 wakeup or point
 me to a better place to get this question answered?   Thank you,
   Michael
 
 Code:
 
 pthread_mutex_t mymutex = PTHREAD_MUTEX_INITIALIZER;
 
 void *important(void *ign)
 {
 sleep(1);
 printf(important waiting for mutex\n);
 if(pthread_mutex_lock(mymutex)) {
 perror(sem_wait);
 exit(1);
 } else {
 printf(important got mutex!\n);
 pthread_mutex_unlock(mymutex);
 }
 
 return NULL;
 }
 
 
 void *unimportant(void *ign)
 {
 printf(unimportant waiting for mutex\n);
 if(pthread_mutex_lock(mymutex)) {
 perror(sem_wait);
 exit(1);
 } else {
 printf(unimportant got mutex!\n);
 pthread_mutex_unlock(mymutex);
 }
 
 return NULL;
 }
 
 int main()
 {
 struct sched_param p;
 pthread_attr_t attr;
 pthread_t i, u;
 
 pthread_mutex_lock(mymutex);
 
 p.__sched_priority = sched_get_priority_min(SCHED_FIFO);
 if(-1 == p.__sched_priority) {
 perror(sched_get_priority_min);
 return 1;
 }
 pthread_attr_init(attr);
 pthread_attr_setschedpolicy(attr, SCHED_FIFO);
 pthread_attr_setschedparam(attr, p);
 pthread_create(u, attr, unimportant, NULL);
 
 p.__sched_priority = sched_get_priority_max(SCHED_FIFO);
 pthread_attr_setschedparam(attr, p);
 pthread_create(i, attr, important, NULL);
 
 sleep(5);
 printf(main unlocking mutex\n);
 pthread_mutex_unlock(mymutex);
 
 pthread_join(u, NULL);
 pthread_join(i, NULL);
 
 return 0;
 }
 
 Which produces:
 unimportant waiting for mutex
 important waiting for mutex
 main unlocking mutex
 unimportant got mutex!
 important got mutex!
 
 ___
 Linuxppc-embedded mailing list
 Linuxppc-embedded@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-embedded
 
 ___
 Linuxppc-embedded mailing list
 Linuxppc-embedded@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-embedded


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


RE: futex priority based wakeup

2007-09-07 Thread Benedict, Michael
I am trying to build 2.6.1 as we speak.

I don't think I said priority inheritance?  If I did, sorry, must have
been confused.

As far as crosstool-0.43 and NTPL... I hate to be anti-climactic, but I
didn't really have any issues.  I build with
gcc-3.4.5-glibc-2.3.6-nptl.dat, which contained:
BINUTILS_DIR=binutils-2.15
GCC_DIR=gcc-3.4.5
GLIBC_DIR=glibc-2.3.6
LINUX_DIR=linux-2.6.15.4
LINUX_SANITIZED_HEADER_DIR=linux-libc-headers-2.6.12.0
GLIBCTHREADS_FILENAME=glibc-linuxthreads-2.3.6
GLIBC_EXTRA_CONFIG=$GLIBC_EXTRA_CONFIG --with-tls --with-__thread
--enable-kernel=2.4.18
GLIBC_ADDON_OPTIONS==nptl =nptlonly

I will continue with updates as they happen.
Thank you again,
Michael

Ilya Lipovsky wrote:
 Yes, I am uncertain. If it isn't a major headache, I think
 you can try the
 newest version (I think it's 2.6.1) and see if you get some
 resolution. 
 
 Your code looks correct to me, so if the kernel developers
 did their job
 correctly, the only potentially weak link is glibc.
 
 I think pthread priority inheritance is an independent
 concept, but you
 shouldn't care since you explicitly set priorities.
 
 My kernel is 2.6.21, so I am of no help here, unfortunately.
 
 By the way, kudos to you for making crosstool compile glibc with NPTL
 support, I had issues getting there (I have 2.4 with NPTL, but it is
 natively installed)! How did you manage to get around the
 intermediate's compiler's lack of __thread support issue?
 
 Please do share the outcome!!
 
 -Ilya
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] g] On
 Behalf Of Benedict, Michael Sent: Friday, September 07, 2007 1:25 PM
 To: linuxppc-embedded@ozlabs.org
 Subject: RE: futex priority based wakeup
 
 Thank you for the help!
 
 Same result with fflush :(.
 
 Are you maybe wrong because you have tested 2.5 and it
 doesn't work?  Or
 just uncertain?
 
 The only thing I have read that mentions glibc version is the
 work Ingo
 did against 2.4 glibc and in the 2.6.16-mm1 patches...
 http://people.redhat.com/mingo/PI-futex-patches/.  I can not detrmine
 how this relates to the 2.6.22 priority based futex wakeup commit.
 
 I am currently fighting crosstool-0.43 to build a newer glibc
 and I will
 share results if/when I get that to work.
   -Michael
 
 Ilya Lipovsky wrote:
 ...Or maybe I am wrong :). Could you put fflush(stdout) after
 each printf,
 just to be completely certain that it misbehaves?
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] g] On
 Behalf Of Ilya Lipovsky Sent: Friday, September 07, 2007 12:41 PM
 To: 'Benedict, Michael'; linuxppc-embedded@ozlabs.org
 Subject: RE: futex priority based wakeup
 
 Looks like it is a libc issue. Apparently, GNU libc supports priority
 futexes only in version 2.5 and higher.
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] g] On
 Behalf Of Benedict, Michael Sent: Friday, September 07, 2007 11:02 AM
 To: linuxppc-embedded@ozlabs.org
 Subject: futex priority based wakeup
 
 I recently upgraded to 2.6.22 to get the priority based futex wakeup
 behavior.  However, when I run a simple program (see below), based on
 either a pthread_mutex_t or a sem_t, it seems that threads
 are woken up
 in FIFO order.  I am using glibc 2.3.6 with NPTL and TLS, based off
 crossdev-0.43.  Could someone help me get priority-based
 wakeup or point
 me to a better place to get this question answered? Thank you,
 Michael 
 
 Code:
 
 pthread_mutex_t mymutex = PTHREAD_MUTEX_INITIALIZER;
 
 void *important(void *ign)
 {
 sleep(1);
 printf(important waiting for mutex\n);
 if(pthread_mutex_lock(mymutex)) {
 perror(sem_wait);
 exit(1);
 } else {
 printf(important got mutex!\n);
 pthread_mutex_unlock(mymutex);
 }
 
 return NULL;
 }
 
 
 void *unimportant(void *ign)
 {
 printf(unimportant waiting for mutex\n);
 if(pthread_mutex_lock(mymutex)) {
 perror(sem_wait);
 exit(1);
 } else {
 printf(unimportant got mutex!\n);
 pthread_mutex_unlock(mymutex);
 }
 
 return NULL;
 }
 
 int main()
 {
 struct sched_param p;
 pthread_attr_t attr;
 pthread_t i, u;
 
 pthread_mutex_lock(mymutex);
 
 p.__sched_priority = sched_get_priority_min(SCHED_FIFO);
 if(-1 == p.__sched_priority) {
 perror(sched_get_priority_min);
 return 1;
 }
 pthread_attr_init(attr);
 pthread_attr_setschedpolicy(attr, SCHED_FIFO);
 pthread_attr_setschedparam(attr, p);
 pthread_create(u, attr, unimportant, NULL);
 
 p.__sched_priority = sched_get_priority_max(SCHED_FIFO);
 pthread_attr_setschedparam(attr, p);
 pthread_create(i, attr, important, NULL);
 
 sleep(5);
 printf(main unlocking

RE: random panic and freezes on mpc8349 itx

2007-09-07 Thread Benedict, Michael
What version of U-boot are you using?  Could it be RAM initialization?
There was a RAM initialization bug in the ITX for u-boot git sources
until April 2007.
Good luck,
Michael

[EMAIL PROTECTED] wrote:
 Hi,
 
 I am currently working with an MPC8349ITX board and I have
 some trouble with
 the kernel as soon as it reaches userland.
 
 If I boot the kernel with all the memory (256MB) available (no
 mem=... on the command line), I get random freezes or random kernel
 panics. 
 Some times it
 won't even run init. Some times it will panic badly if I try
 to put some
 pressure to the system (stress --cpu 256). Some times it will hang
 immediately after logging in, ...
 
 If I boot the kernel with mem=64M, these freeze and random
 panic disapear and
 I am able to run the stress program without any problems.
 
 I have had this strange behaviour on both kernel 2.6.20 and
 2.6.22 with
 mpc834x_itx_defconfig (both from kernel.org) (ARCH=powerpc).
 
 I am inclined to say that it is not a broken RAM chip problem because
 if I use a 2.6.17 from kernel.org with all the RAM available
 (ARCH=ppc) configured with mpc834x_sys_defconfig (there was no
 defconfig for the 
 itx board on this
 version) everything runs fine and I am able to run the stress program
 without any problems.
 
 The panic does not happen very often, 90% of the time, the
 board hangs and
 stops responding to ping. When a panic do happen it is almost always
 in a different place.
 
 Does any of you have met this problem before ? If you have
 any clues about
 what is hapenning I'd be glad to hear about it :)
 
 Thank you for your attention,
 
 Regards,


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


powersave-nap

2007-08-23 Thread Benedict, Michael
I was curious what the common setting was for
/proc/sysctl/kernel/powersave-nap.

For what its worth, we are running an MPC8347 and we are not counting on
powersaving for our power or heat budget.  We are not running off of
batteries and are much more concerned about responsiveness over power
saving.

From what I have read, it seems that both nap and doze require a couple
instructions to wake up.  If the responsiveness is the same, is there
any reason to use doze?  Why is doze the default?
Thank you,
Michael

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


RE: no output to serial console from /init process on ml405

2007-08-08 Thread Benedict, Michael
Just a guess, but do you have stdout and friends defined as recommended
in the Compulsory links section of Documentation/devices.txt?
-Michael

 -Original Message-
 From: 
 [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED]
rg] On Behalf Of Anton Kowalski
 Sent: Wednesday, August 08, 2007 6:28 AM
 To: linuxppc-embedded@ozlabs.org
 Subject: no output to serial console from /init process on ml405
 
 Hi All:
 
 I'm trying to bring up linux 2.6.21.1 on an ml405 board. The kernel
 boots fine but the init process does not produce any output. The /init
 program resides in an initramfs file system and I believe the /dev
 device files have been set up correctly. Here's an excerpt from my
 initramfs specification:
 
 dir /dev 755 0 0
 nod /dev/console 644 0 0 c 5 1
 nod /dev/ttyS0 644 0 0 c 4 64
 
 (I am able to open these files from the init program. I tested this by
 sleeping for a specified time on success.)
 
 Also, printk continues to function after /init terminates and before
 the kernel panics.
 
 Here are the last few lines of the console output:
 
 [0.507478] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports,
 IRQ sharing disabled
 [0.513862] serial8250.0: ttyS0 at MMIO 0x80201003 (irq = 
 3) is a 16550A
 [2.927509] RAMDISK driver initialized: 1 RAM disks of 8192K size
 1024 blocksize
 [3.018391] tun: Universal TUN/TAP device driver, 1.6
 [3.079115] tun: (C) 1999-2004 Max Krasnyansky [EMAIL PROTECTED]
 [3.154919] mice: PS/2 mouse device common for all mice
 [3.218021] TCP cubic registered
 [3.257034] NET: Registered protocol family 1
 [3.309405] NET: Registered protocol family 17
 [3.363462] Freeing unused kernel memory: 300k init
 [   23.488277] Kernel panic - not syncing: Attempted to kill init!
 [   23.559517] Rebooting in 180 seconds..NULL
 
 I'm using the plb uart and the 8250.c driver. (The obp uartlite driver
 didn't work so I switched.) The kernel and the init program were
 compiled with eldk.
 
 Any insights into resolving this problem are greatly appreciated.
 
 
 Anton
 ___
 Linuxppc-embedded mailing list
 Linuxppc-embedded@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-embedded
 
 

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


RE: MPC 8349e-mITX and MTD/Flash

2007-04-10 Thread Benedict, Michael
Ben,
I assume that you intended to CC the list but accidently hit
reply instead.  If not, I apologize.  Thank you for all your help so
far.

-Original Message-
From: Ben Warren [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 09, 2007 4:30 PM
To: Benedict, Michael
Subject: Re: MPC 8349e-mITX and MTD/Flash

I suspect that MTD doesn't know anything about how
your flash chip is organized.  Probably the easiest
thing to use is CONFIG_MTD_PHYSMAP.  Using this, you
can either pass the MTD partitioning info via kernel
command line, via static physmap structures in your
board code or, I believe, via device tree (I haven't
tried the last one).

The following is from my .config
snip
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=0x800
CONFIG_MTD_PHYSMAP_LEN=0x0
CONFIG_MTD_PHYSMAP_BANKWIDTH=2
# CONFIG_MTD_PHYSMAP_OF is not set
CONFIG_MTD_PLATRAM=y
snip

Is this what you are referring to?  Does something look obviously wrong
with it?  I have taken that configuration from Freescale's reference
.config that came with the platform.  I am using the latest kernel.org
flat device tree for my platform, but the flash is not configured there.

After reading a little more, I suppose I am not expecting any
partitions, but I would still think I should be able to `mtd_debug info`
the block and char devices.  When I try, I get No such device or
address errors.  Also, I would still expect something in my /proc/mtd,
correct?  Any ideas are greatly appreciated.
Thank you again,
Michael

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


RE: MPC 8349e-mITX and MTD/Flash

2007-04-10 Thread Benedict, Michael
Your settings for CONFIG_MTD_PHYSMAP_START and 
CONFIG_MTD_PHYSMAP_LEN are wrong.  And 
frankly, I can't understand where you got those values from, 
unless you created your 
.config from scratch.  The defconfig that's in the kernel is 
specifically intended for the 
Freescale MPC8349E-mITX.  I should know, because I wrote the 
code and the defconfig.

I didn't even know about the defconfig until I started looking into this
issue.  I tried to upgrade the .config that came with the CD but I
can't tell you how I introduced these values.  That said, I was able to
change my configuration to the values in the defconfig and...

# mtd_debug info /dev/mtd0
mtd.type = MTD_NORFLASH
mtd.flags =
mtd.size = 16777216 (16M)
mtd.erasesize = 65536 (64K)
mtd.oobblock = 1
mtd.oobsize = 0
mtd.ecctype = MTD_ECC_NONE
regions = 4

region[0].offset = 0x
region[0].erasesize = 65536 (64K)
region[0].numblocks = 127
region[0].regionindex = 0
region[1].offset = 0x007f
region[1].erasesize = 8192 (8K)
region[1].numblocks = 8
region[1].regionindex = 1
region[2].offset = 0x0080
region[2].erasesize = 65536 (64K)
region[2].numblocks = 127
region[2].regionindex = 2
region[3].offset = 0x00ff
region[3].erasesize = 8192 (8K)
region[3].numblocks = 8
region[3].regionindex = 3

Its working!  Thank you everyone for helping me figure this out.


Having said that, it seems that the kernel now supports 
defining the physmap via the OF 
tree.  Is that true?


Initially I was going to try and define this via the OF tree.  However,
the documentation indicated that the only supported device_type was
rom so I did not persue that route.
-Michael

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


MPC 8349e-mITX and MTD/Flash

2007-04-09 Thread Benedict, Michael
Hello,
Quite simply, I am trying to access the attached flash devices
for this platform from linux.  I tried to select all the appropriate MTD
settings that I thought could apply.  However, nothing shows up in
/proc/mtd.  Can someone point me in the right direction for accessing
these?  

From the documentation: The two Flash memory banks are MX29LV640MTTC-90
top boot Flash memory devices

Thank you!
Michael

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


RE: Unable to boot kernel on MPC8349ITX eval board

2007-04-05 Thread Benedict, Michael
I have a similar problem with Gentoo NFS root.  I wasn't fortunate
enough to get an oops though, just a hang.  I wish I had a fix for you,
but here are some things that have worked for us:

1) init=/bin/sh (obviously sub-optimal)
2) rootfs from Freescale
3) rootfs built from buildroot

I wish I had tracked this down further and could be more helpful, but
maybe that is a start or can get you a step further.
Cheers,
Michael

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Thursday, April 05, 2007 1:33 PM
To: linuxppc-embedded@ozlabs.org
Subject: Unable to boot kernel on MPC8349ITX eval board

Hi,

I'm trying to bring up the 2.6.20.4 kernel on a MPC8349ITX eval board
and not having any success.  The root FS is ubuntu/dapper via NFS.
U-boot is 1.2.0.  I'm not a kernel hacker (though I'm learning :)  ) and
I want to learn, but I don't understand enough about the kernel to
understand what is happening.  There is an engineer in the next room who
is a kernel hacker, but he's not sure what the problem is either.
Following I've put the dump from the boot process and my .config file.
I'm using the default 

DTS file (./arch/powerpc/boot/dts/mpc8349emitx.dts) from the 2.6.20.4
tree.  Any thoughts/pointers where to look?  Thanks

Bruce


MPC8349E-mITX run bdlboot2
Speed: 100, half duplex
Using TSEC0 device
TFTP from server 10.202.10.161; our IP address is 10.202.10.165 Filename
'8349.blob'.
Load address: 0x40
Loading: #
done
Bytes transferred = 4050 (fd2 hex)
Speed: 100, half duplex
Using TSEC0 device
TFTP from server 10.202.10.161; our IP address is 10.202.10.165 Filename
'/8349-brucle/uImage'.
Load address: 0x100
Loading:
#
 
#
 
#
 
done
Bytes transferred = 1239360 (12e940 hex) ## Booting image at 0100
...
   Image Name:   Linux-2.6.20.4
   Created:  2007-04-05  17:04:52 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:1239296 Bytes =  1.2 MB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
   Booting using flat device tree at 0x40 Using MPC834x ITX machine
description Linux version 2.6.20.4 ([EMAIL PROTECTED]) (gcc
version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) #9 Thu Apr 5 10:04:36 PDT 2007
setup_arch: bootmem
mpc834x_itx_setup_arch()
Found MPC83xx PCI host bridge at 0xe0008500. Firmware bus
number: 
0-0
Found MPC83xx PCI host bridge at 0xe0008600. Firmware bus
number: 
1-1
arch: exit
Zone PFN ranges:
  DMA 0 -65536
  Normal  65536 -65536
early_node_map[1] active PFN ranges
0:0 -65536
Built 1 zonelists.  Total pages: 65024
Kernel command line: root=/dev/nfs rw
nfsroot=10.202.10.161:/SEL3500/home/brucle/vobs/bob ip=dhcp
console=ttyS0,115200 IPIC (128 IRQ sources) at fbffb700 PID hash table
entries: 1024 (order: 10, 4096 bytes)

Using MPC834x ITX machine description
Linux version 2.6.20.4 ([EMAIL PROTECTED]) (gcc version 4.0.3
(Ubuntu 4.0.3-1ubuntu5)) #9 Thu Apr 5 10:04:36 PDT 2007 Found MPC83xx
PCI host bridge at 0xe0008500. Firmware bus number: 
0-0
Found MPC83xx PCI host bridge at 0xe0008600. Firmware bus
number: 
1-1
Zone PFN ranges:
  DMA 0 -65536
  Normal  65536 -65536
early_node_map[1] active PFN ranges
0:0 -65536
Built 1 zonelists.  Total pages: 65024
Kernel command line: root=/dev/nfs rw
nfsroot=10.202.10.161:/SEL3500/home/brucle/vobs/bob ip=dhcp
console=ttyS0,115200 IPIC (128 IRQ sources) at fbffb700 PID hash table
entries: 1024 (order: 10, 4096 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256896k/262144k available (2396k kernel code, 4976k reserved,
112k 

data, 93k bss, 120k init)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
Generic PHY: Registered new driver
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP
established hash table entries: 8192 (order: 3, 32768 bytes) TCP bind
hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 8192 bind 4096) TCP reno
registered io scheduler noop registered io scheduler anticipatory
registered io scheduler deadline registered io scheduler cfq registered
(default)
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A Gianfar
MII Bus: probed
eth0: Gianfar Ethernet Controller Version 

U-boot with flat device tree

2007-03-14 Thread Benedict, Michael
Hello,
Sorry, I realize this was discussed a month ago: device tree /
how to build/compile  use with u-boot to boot uImage?  However, I
wasn't on the list at the time.  I read through it and I thought I
understood everything.

I am trying to get an mpc8349e-mITX to boot a recent kernel.  I
have tried all permutations of:

dtc- development snapshot dtc-20060419.tar.gz and recent git
sources
U-boot - 1.2.0, git sources from denx.de, and git sources from freescale
Kernel - 2.6.20.1, 2.6.20.2, and freescale git sources

Everytime I boot U-boot will tell me the kernel uncompress find and
then... Nothing.  I passed initcall_debug to the kernel and didn't get
anything printed to the serial console.  Note that if I do not specify
the flat device tree, the kernel progresses up to the point of mounting
root.  It can't mount root because it is an NFS root and the ethernet
drivers aren't working:

0:00 not found
eth0: Could not attach to PHY

Just as you would expect (since eth0 is defined in the dts).

Just to be sure I start be building the device tree, eg:
$ dtc -I dts -O dtb -f -V 16
linux/arch/powerpc/boot/dts/mpc8349emitx.dts -o mpc8349emitx.dtb

Then, from u-Boot, download the dtb and kernel and boot:

MPC8349E-mITX tftp 0100 mpc8349emitx.dtb
Speed: 100, full duplex
Using TSEC0 device
TFTP from server 10.100.10.74; our IP address is 10.100.10.83
Filename 'mpc8349emitx.dtb'.
Load address: 0x100
Loading: #
done
Bytes transferred = 3976 (f88 hex)
MPC8349E-mITX tftp 01001000 uImage
Speed: 100, full duplex
Using TSEC0 device
TFTP from server 10.100.10.74; our IP address is 10.100.10.83
Filename 'uImage'.
Load address: 0x1001000
Loading:
#
 
#
 
#
 
#
 #
done
Bytes transferred = 1499510 (16e176 hex)
MPC8349E-mITX bootm 1001000 - 100
## Booting image at 01001000 ...
   Image Name:   Linux-2.6.21-rc3-gb5d99e64
   Created:  2007-03-12  19:28:43 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:1499446 Bytes =  1.4 MB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
   Booting using flat device tree at 0x100



stuck

Any ideas?
Thank you!
Michael

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