Early driver development resources
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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