From christiangieseler at yahoo.de Mon Mar 4 06:07:12 2013 From: christiangieseler at yahoo.de (Christian Gieseler) Date: Mon, 4 Mar 2013 12:07:12 +0100 Subject: [uClinux-dev] ROMFS: bad initial checksum In-Reply-To: <5100DB17.8090605@westnet.com.au> References: <000001cdf946$1197a430$34c6ec90$@yahoo.de> <50FFD4B0.6050804@westnet.com.au> <000201cdf96d$166d5d70$43481850$@yahoo.de> <50FFE909.9010507@westnet.com.au> <000501cdf973$9ca114d0$d5e33e70$@yahoo.de> <5100DB17.8090605@westnet.com.au> Message-ID: <000001ce18c8$6c0adc60$44209520$@yahoo.de> Hi Greg, i just wanted to give some feedback about this, so that other people don?t run in the same issue. The initial checksum gets corrupted because of variables from m532x.c are placed in the area where romfs is placed before it is mounted/copied to the final position. The two commands sys_clk_khz = clock_pll(0, 0); sys_clk_mhz = sys_clk_khz/1000; overwrite the romfs contents. Commenting the stuff out solves the romfs problem. You find these variables only in m532x.c and I don?t see what they are good for. They also don?t exist for other coldfire platforms. They are in the sources for quite a while now and we did not have the problem with earlier kernels. Has something changed in the compiling/linking process, so that addresses have moved? Regards Christian Hi Christian, On 24/01/13 00:12, Christian Gieseler wrote: >>>> Or is the checksum >>>> tested on a wrong value because I misconfigured an address. >>>> Does someone have a hint how to solve this or where to look for a >> solution? >>>> The bootmessages are attached for reference. >>> >>> Can you send the entire boot sequence? >>> I want to see all the load segment addresses that are earlier in the >>> boot >> output. > > Ok, this didn't have the information I was looking for after all :-( > Can you send the output of: > > m68k-linux-objdump --headers vmlinux > > Not sure what your toolchain prefix is, but substitute in place of > m68k-linux-objdump for whatever the Code Sourcery name is. > > m68k-uclinux-objdump --headers vmlinux > > vmlinux: file format elf32-m68k > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 001c9f70 40020000 40020000 00002000 2**2 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 1 .rodata 00026640 401ea000 401ea000 001cc000 2**4 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 2 __ksymtab 000045d8 40210640 40210640 001f2640 2**1 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 3 __ksymtab_gpl 00002318 40214c18 40214c18 001f6c18 2**1 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 4 __kcrctab 000022ec 40216f30 40216f30 001f8f30 2**1 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 5 __kcrctab_gpl 0000118c 4021921c 4021921c 001fb21c 2**1 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 6 __ksymtab_strings 0000dfea 4021a3a8 4021a3a8 001fc3a8 2**0 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 7 __param 00000330 40228394 40228394 0020a394 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 8 __modver 0000193c 402286c4 402286c4 0020a6c4 2**1 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 9 .data 0001de40 4022a000 4022a000 0020c000 2**4 > CONTENTS, ALLOC, LOAD, DATA > 10 .init.text 0000d57c 40248000 40248000 0022a000 2**1 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 11 .init.data 00004a84 4025557c 4025557c 0023757c 2**2 > CONTENTS, ALLOC, LOAD, DATA > 12 .bss 0000f24c 4025a000 4025a000 0023c000 2**4 > ALLOC > 13 .comment 00000030 00000000 00000000 0023c000 2**0 > CONTENTS, READONLY Ok, that looks good too. The romfs start address from you console boot log: uclinux[mtd]: RAM probe address=0x4026924c size=0x19c000 matches up with the end of the bss segment. Which is what I would expect. I would suggest putting some printk trace around the ROMS checksum error that dumps out what the memory contents of that first romfs block is. Compare that with your original and see exactly what has changed. Is it just a few bytes off, or has the whole thing been corrupted in some way? Regards Greg From gregungerer at westnet.com.au Tue Mar 5 06:54:39 2013 From: gregungerer at westnet.com.au (Greg Ungerer) Date: Tue, 05 Mar 2013 21:54:39 +1000 Subject: [uClinux-dev] ROMFS: bad initial checksum In-Reply-To: <000001ce18c8$6c0adc60$44209520$@yahoo.de> References: <000001cdf946$1197a430$34c6ec90$@yahoo.de> <50FFD4B0.6050804@westnet.com.au> <000201cdf96d$166d5d70$43481850$@yahoo.de> <50FFE909.9010507@westnet.com.au> <000501cdf973$9ca114d0$d5e33e70$@yahoo.de> <5100DB17.8090605@westnet.com.au> <000001ce18c8$6c0adc60$44209520$@yahoo.de> Message-ID: <5135DCFF.3010605@westnet.com.au> Hi Christian, On 04/03/13 21:07, Christian Gieseler wrote: > i just wanted to give some feedback about this, so that other people don?t > run in the same issue. > The initial checksum gets corrupted because of variables from m532x.c are > placed in the area where romfs is placed before it is mounted/copied to the > final position. > > The two commands > sys_clk_khz = clock_pll(0, 0); > sys_clk_mhz = sys_clk_khz/1000; > > overwrite the romfs contents. Commenting the stuff out solves the romfs > problem. You find these variables only in m532x.c and I don?t see what they > are good for. They also don?t exist for other coldfire platforms. > They are in the sources for quite a while now and we did not have the > problem with earlier kernels. Has something changed in the compiling/linking > process, so that addresses have moved? Well, not so long ago I changed the linker scripts to make them more like the general m68k scripts. That we we can use the linux common linker script definitions (which greatly simplifies maintenance). Not sure if this may have caused this. Anyway, if all that early clock and pll code is not needed I would like to remove it. I have never liked how that is so different to startup than all the other ColdFire parts. I think this code originally came from Freescale. I don't have a 532x board, so I have never been able to change to much of that code and test it. What sort of board do you have? Is it the Freescale 5329EVB or your own design? Regards Greg > Hi Christian, > > On 24/01/13 00:12, Christian Gieseler wrote: >>>>> Or is the checksum >>>>> tested on a wrong value because I misconfigured an address. >>>>> Does someone have a hint how to solve this or where to look for a >>> solution? >>>>> The bootmessages are attached for reference. >>>> >>>> Can you send the entire boot sequence? >>>> I want to see all the load segment addresses that are earlier in the >>>> boot >>> output. >> >> Ok, this didn't have the information I was looking for after all :-( >> Can you send the output of: >> >> m68k-linux-objdump --headers vmlinux >> >> Not sure what your toolchain prefix is, but substitute in place of >> m68k-linux-objdump for whatever the Code Sourcery name is. >> >> m68k-uclinux-objdump --headers vmlinux >> >> vmlinux: file format elf32-m68k >> >> Sections: >> Idx Name Size VMA LMA File off Algn >> 0 .text 001c9f70 40020000 40020000 00002000 2**2 >> CONTENTS, ALLOC, LOAD, READONLY, CODE >> 1 .rodata 00026640 401ea000 401ea000 001cc000 2**4 >> CONTENTS, ALLOC, LOAD, READONLY, DATA >> 2 __ksymtab 000045d8 40210640 40210640 001f2640 2**1 >> CONTENTS, ALLOC, LOAD, READONLY, DATA >> 3 __ksymtab_gpl 00002318 40214c18 40214c18 001f6c18 2**1 >> CONTENTS, ALLOC, LOAD, READONLY, DATA >> 4 __kcrctab 000022ec 40216f30 40216f30 001f8f30 2**1 >> CONTENTS, ALLOC, LOAD, READONLY, DATA >> 5 __kcrctab_gpl 0000118c 4021921c 4021921c 001fb21c 2**1 >> CONTENTS, ALLOC, LOAD, READONLY, DATA >> 6 __ksymtab_strings 0000dfea 4021a3a8 4021a3a8 001fc3a8 2**0 >> CONTENTS, ALLOC, LOAD, READONLY, DATA >> 7 __param 00000330 40228394 40228394 0020a394 2**2 >> CONTENTS, ALLOC, LOAD, READONLY, DATA >> 8 __modver 0000193c 402286c4 402286c4 0020a6c4 2**1 >> CONTENTS, ALLOC, LOAD, READONLY, DATA >> 9 .data 0001de40 4022a000 4022a000 0020c000 2**4 >> CONTENTS, ALLOC, LOAD, DATA >> 10 .init.text 0000d57c 40248000 40248000 0022a000 2**1 >> CONTENTS, ALLOC, LOAD, READONLY, CODE >> 11 .init.data 00004a84 4025557c 4025557c 0023757c 2**2 >> CONTENTS, ALLOC, LOAD, DATA >> 12 .bss 0000f24c 4025a000 4025a000 0023c000 2**4 >> ALLOC >> 13 .comment 00000030 00000000 00000000 0023c000 2**0 >> CONTENTS, READONLY > > Ok, that looks good too. The romfs start address from you console boot > log: > > uclinux[mtd]: RAM probe address=0x4026924c size=0x19c000 > > matches up with the end of the bss segment. Which is what I would expect. > > I would suggest putting some printk trace around the ROMS checksum error > that dumps out what the memory contents of that first romfs block is. > Compare that with your original and see exactly what has changed. Is it just > a few bytes off, or has the whole thing been corrupted in some way? > > Regards > Greg > > > From christiangieseler at yahoo.de Tue Mar 5 09:58:35 2013 From: christiangieseler at yahoo.de (Christian Gieseler) Date: Tue, 5 Mar 2013 15:58:35 +0100 Subject: [uClinux-dev] ROMFS: bad initial checksum In-Reply-To: <5135DCFF.3010605@westnet.com.au> References: <000001cdf946$1197a430$34c6ec90$@yahoo.de> <50FFD4B0.6050804@westnet.com.au> <000201cdf96d$166d5d70$43481850$@yahoo.de> <50FFE909.9010507@westnet.com.au> <000501cdf973$9ca114d0$d5e33e70$@yahoo.de> <5100DB17.8090605@westnet.com.au> <000001ce18c8$6c0adc60$44209520$@yahoo.de> <5135DCFF.3010605@westnet.com.au> Message-ID: <000601ce19b1$e9729730$bc57c590$@yahoo.de> Hi Greg, >-----Original Message----- >From: Greg Ungerer [mailto:gregungerer at westnet.com.au] >Sent: Tuesday, March 05, 2013 12:55 PM >To: Christian Gieseler >Cc: 'uClinux development list' >Subject: Re: [uClinux-dev] ROMFS: bad initial checksum > >Hi Christian, > >On 04/03/13 21:07, Christian Gieseler wrote: >> i just wanted to give some feedback about this, so that other people >> don?t run in the same issue. >> The initial checksum gets corrupted because of variables from m532x.c >> are placed in the area where romfs is placed before it is >> mounted/copied to the final position. >> >> The two commands >> sys_clk_khz = clock_pll(0, 0); >> sys_clk_mhz = sys_clk_khz/1000; >> >> overwrite the romfs contents. Commenting the stuff out solves the >> romfs problem. You find these variables only in m532x.c and I don?t >> see what they are good for. They also don?t exist for other coldfire platforms. >> They are in the sources for quite a while now and we did not have the >> problem with earlier kernels. Has something changed in the >> compiling/linking process, so that addresses have moved? > >Well, not so long ago I changed the linker scripts to make them more like the general m68k scripts. That we we can use the linux common linker >script definitions (which greatly simplifies maintenance). >Not sure if this may have caused this. > >Anyway, if all that early clock and pll code is not needed I would like to remove it. I have never liked how that is so different to startup than all the >other ColdFire parts. I think this code originally came from Freescale. I don't have a 532x board, so I have never been able to change to much of >that code and test it. > >What sort of board do you have? Is it the Freescale 5329EVB or your own design? The board is derived from the Sentec COBRA5329 Board. > >Regards >Greg Regards Christian From jose.ferreiro at horus.es Tue Mar 5 11:25:19 2013 From: jose.ferreiro at horus.es (=?windows-1252?Q?Jose_M=AA_Ferreiro?=) Date: Tue, 05 Mar 2013 17:25:19 +0100 Subject: [uClinux-dev] Register Access In-Reply-To: <5087467C.2020501@snapgear.com> References: <000301cdb12f$fc6ec6f0$f54c54d0$@yahoo.de> <5087467C.2020501@snapgear.com> Message-ID: <51361C6F.9020101@horus.es> Hello I found a similar problem to Christian's, but using the PWM module from the 5329. I have solved it creating a driver to access the PWM registers from the kernel. But I am yet intrigued by it. I was not able to found why these user registers were not accesible from userspace. I am using an old 2.16.17 uclinux. I revised SCM PACRx registers and they are all filled with 0 (giving user access, I think). Someone suggested me a cache entry restriction, but I only can see SDRAM caching at the start code. What other thing can limit that access? Thank you, Jose El 24/10/2012 3:38, Greg Ungerer escribi?: > Hi Christian, > > On 24/10/12 01:06, Christian Gieseler wrote: >> We have to activate dithering in our Coldfire 5329 device. But it >> seams, >> that I cant even read the register values of PLL Control Register >> (PCR) and >> PLL Modulation Divider Register (PMDR). The registers should be user >> readable and writable. > > Why do you think they should be user space read/write? > > >> But it seems that I get a bus error because the >> values do not match the written ones or the reset values if I don???t >> write >> something. > > That would seem to indicate that those registers are not user space > read/write. > > Check your settings of the PACRx registers (Peripheral Access Control > Registers). They power up with the supervisor only access bit set, > so unless you have changed them you won't get user access. > > Regards > Greg > > >> #define GT_REG_READ_SHORT(Reg, pData) >> \ >> *pData = ((volatile unsigned short)*((unsigned short *) (Reg))); >> >> #define GT_REG_WRITE(Reg, >> data) \ >> (*(volatile unsigned long *)(Reg)) =data >> >> #define PLL_PODR 0xFC0C0000 >> #define PLL_PLLCR 0xFC0C0004 >> #define PLL_PMDR 0xFC0C0008 >> int main(int argc, char *argv[]) >> { >> unsigned int RegVal=0; >> >> //GT_REG_WRITE(MCF_PLL_PLLCR,0x0); >> GT_REG_WRITE (PLL_PLLCR ,0); >> GT_REG_WRITE (PLL_PMDR ,0x5); >> //Setze PLL Control Register >> GT_REG_WRITE (PLL_PLLCR ,0x87); >> >> >> GT_REG_READ_SHORT (PLL_PLLCR,(unsigned int*)&RegVal); >> printf ("PLLCR has Value=%x\n",RegVal); >> >> >> return 0; >> } >> >> Does someone have a hint how to write and read these registers? Is >> something >> wrong in my code? >> >> Best regards >> Christian >> >> _______________________________________________ >> uClinux-dev mailing list >> uClinux-dev at uclinux.org >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by uclinux-dev at uclinux.org >> To unsubscribe see: >> http://mailman.uclinux.org/mailman/options/uclinux-dev >> >> >> > > From christiangieseler at yahoo.de Tue Mar 5 12:00:13 2013 From: christiangieseler at yahoo.de (Christian Gieseler) Date: Tue, 5 Mar 2013 18:00:13 +0100 Subject: [uClinux-dev] migration issue scheduling while atomic Message-ID: <000001ce19c2$e7ca0790$b75e16b0$@yahoo.de> Hi list, I ran in another issue while updating our coldfire 5329 board from linux 2.6.25 to linux 3.6. Romfs is mounted as root and then the system says BUG: scheduling while atomic: swapper/0/0x00000000 and is finally crashing after some trace output. The system is configured to behave a preemptive system (low latency desktop) but the system also crashes without preemption activated. Does somebody know in which direction to look and how to tackle this issue? What is the best way to track it down and fix this? Let me know if there is more information needed than the boot up messages below show. Best Regards Christian dBUG> dn Downloading Image 'image.bin' from 192.168.10.254 TFTP transfer completed Read 4647940 bytes (9079 blocks) dBUG> go 0x40020000 Linux version 3.6.11 (christian at cglinux.eks-engel.local) (gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-23) ) #72 PREEMPT Tue Mar 5 17:32:05 CET 2013 uClinux/COLDFIRE(m532x) COLDFIRE port done by Greg Ungerer, gerg at snapgear.com Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne Built 1 zonelists in Zone order, mobility grouping off. Total pages: 2024 Kernel command line: rootfstype=romfs console=tty1 console=ttyS0,115200 root=/dev/mtdblock0 PID hash table entries: 64 (order: -5, 256 bytes) Dentry cache hash table entries: 2048 (order: 0, 8192 bytes) Inode-cache hash table entries: 2048 (order: 0, 8192 bytes) Memory available: 11392k/16256k RAM, (1736k kernel code, 631k data) NR_IRQS:256 Calibrating delay loop... HZ=100 15.46 BogoMIPS (lpj=77312) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 1024 NET: Registered protocol family 16 bio: create slab at 0 Switching to clocksource tmr NET: Registered protocol family 2 TCP established hash table entries: 1024 (order: 0, 8192 bytes) TCP bind hash table entries: 1024 (order: -1, 4096 bytes) TCP: Hash tables configured (established 1024 bind 1024) TCP: reno registered UDP hash table entries: 512 (order: 0, 8192 bytes) UDP-Lite hash table entries: 512 (order: 0, 8192 bytes) NET: Registered protocol family 1 jffs2: version 2.2. (NAND) C 2001-2006 Red Hat, Inc. ROMFS MTD (C) 2007 Red Hat, Inc. msgmni has been set to 22 io scheduler noop registered io scheduler deadline registered io scheduler cfq registered (default) ColdFire internal UART serial driver ttyS0 at MMIO 0xfc060000 (irq = 90) is a ColdFire UART console [ttyS0] enabled ttyS1 at MMIO 0xfc064000 (irq = 91) is a ColdFire UART ttyS2 at MMIO 0xfc068000 (irq = 92) is a ColdFire UART brd: module loaded uclinux[mtd]: RAM probe address=0x4026fd40 size=0x22c000 Creating 1 MTD partitions on "RAM": 0x000000000000-0x00000022c000 : "ROMfs" el5329 flash device: 1000000 at 0 el5329 flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002101 Amd/Fujitsu Extended Query Table at 0x0040 Amd/Fujitsu Extended Query version 1.3. number of CFI chips: 1 Creating 7 MTD partitions on " el5329 flash": 0x000000000000-0x000000020000 : "vectors" 0x000000020000-0x000000040000 : "user_parameters" 0x000000040000-0x000000060000 : "system_parameters" 0x000000060000-0x000000100000 : "bootloader" 0x000000100000-0x000000700000 : "kernel_partition1" 0x000000700000-0x000000d00000 : "partition2" 0x000000d00000-0x000001000000 : "user_data" BUG: scheduling while atomic: swapper/0/0x00000000 Modules linked in: Call Trace: [<401cf054>] __schedule_bug+0x40/0x52 [<401d160e>] __schedule+0x33e/0x3c0 [<401d1bf0>] schedule+0x38/0x54 [<401d1d90>] schedule_preempt_disabled+0x18/0x24 [<401cdd62>] rest_init+0x72/0x82 [<401ced70>] printk+0x0/0x20 [<40252678>] start_kernel+0x2e8/0x2f4 [<400200da>] _exit+0x0/0x6 ------------[ cut here ]------------ WARNING: at kernel/rcutiny.c:135 rcu_idle_exit_common.part.8+0x56/0x66() Current pid: 45 comm: kworker/u:1 / Idle pid: 0 comm: swapper Modules linked in: Call Trace: [<400260f8>] warn_slowpath_common+0x50/0x6a [<40026190>] warn_slowpath_fmt+0x2a/0x32 [<40060474>] rcu_idle_exit_common.part.8+0x56/0x66 [<40060474>] rcu_idle_exit_common.part.8+0x56/0x66 [<400607ea>] rcu_irq_enter+0x62/0x98 [<4002dbf4>] irq_enter+0xa/0x60 [<4002081c>] do_IRQ+0x1c/0x3c [<400233ea>] inthandler+0x2a/0x34 [<40041e40>] exit_itimers+0x8/0x16e [<4002b778>] do_exit+0x524/0x888 [<4002be26>] sys_exit+0x0/0x16 [<4003ac12>] wait_for_helper+0x0/0x96 [<4002be3c>] do_group_exit+0x0/0xf8 [<400232d8>] system_call+0x48/0x86 [<4003ac12>] wait_for_helper+0x0/0x96 [<40020a90>] kernel_thread+0x3a/0x42 ---[ end trace 6786da2dfad7182c ]--- ------------[ cut here ]------------ WARNING: at kernel/rcutiny.c:75 rcu_idle_enter_common.isra.9.part.10+0x6c/0x88() Current pid: 45 comm: kworker/u:1 / Idle pid: 0 comm: swapper Modules linked in: Call Trace: [<400260f8>] warn_slowpath_common+0x50/0x6a [<40026190>] warn_slowpath_fmt+0x2a/0x32 [<40060922>] rcu_idle_enter_common.isra.9.part.10+0x6c/0x88 [<40060922>] rcu_idle_enter_common.isra.9.part.10+0x6c/0x88 [<4006098c>] rcu_irq_exit+0x4e/0x98 [<4002dc7c>] irq_exit+0x32/0x60 [<4002082c>] do_IRQ+0x2c/0x3c [<400233ea>] inthandler+0x2a/0x34 [<40041e40>] exit_itimers+0x8/0x16e [<4002b778>] do_exit+0x524/0x888 [<4002be26>] sys_exit+0x0/0x16 [<4003ac12>] wait_for_helper+0x0/0x96 [<4002be3c>] do_group_exit+0x0/0xf8 [<400232d8>] system_call+0x48/0x86 [<4003ac12>] wait_for_helper+0x0/0x96 [<40020a90>] kernel_thread+0x3a/0x42 ---[ end trace 6786da2dfad7182d ]--- libphy: fec_enet_mii_bus: probed TCP: cubic registered NET: Registered protocol family 17 Name=/dev/root, fs=romfs, flags=32769, data=0 VFS: Mounted root (romfs filesystem) readonly on device 31:0. Freeing unused kernel memory: 64k freed (0x40252000 - 0x40260000) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ljalvs at gmail.com Tue Mar 5 12:18:53 2013 From: ljalvs at gmail.com (Luis Alves) Date: Tue, 5 Mar 2013 17:18:53 +0000 Subject: [uClinux-dev] migration issue scheduling while atomic In-Reply-To: <000001ce19c2$e7ca0790$b75e16b0$@yahoo.de> References: <000001ce19c2$e7ca0790$b75e16b0$@yahoo.de> Message-ID: Hi, With preemption disabled, you shouldn't see that message. In your current kernel config, under "Kernel hacking" what is the state of the "Sleep inside atomic section checking" option? Regards, Luis On Tue, Mar 5, 2013 at 5:00 PM, Christian Gieseler wrote: > Hi list, > > > > I ran in another issue while updating our coldfire 5329 board from linux > 2.6.25 to linux 3.6. > > > > Romfs is mounted as root and then the system says BUG: scheduling while > atomic: swapper/0/0x00000000 and is finally crashing after some trace > output. > > The system is configured to behave a preemptive system (low latency desktop) > but the system also crashes without preemption activated. > > Does somebody know in which direction to look and how to tackle this issue? > What is the best way to track it down and fix this? > > Let me know if there is more information needed than the boot up messages > below show. > > Best Regards > > Christian > > > > dBUG> dn > > Downloading Image 'image.bin' from 192.168.10.254 > > TFTP transfer completed > > Read 4647940 bytes (9079 blocks) > > dBUG> go 0x40020000 > > Linux version 3.6.11 (christian at cglinux.eks-engel.local) (gcc version 4.6.1 > (Sourcery CodeBench Lite 2011.09-23) ) #72 PREEMPT Tue Mar 5 17:32:05 CET > 2013 > > > > > > uClinux/COLDFIRE(m532x) > > COLDFIRE port done by Greg Ungerer, gerg at snapgear.com > > Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne > > Built 1 zonelists in Zone order, mobility grouping off. Total pages: 2024 > > Kernel command line: rootfstype=romfs console=tty1 console=ttyS0,115200 > root=/dev/mtdblock0 > > PID hash table entries: 64 (order: -5, 256 bytes) > > Dentry cache hash table entries: 2048 (order: 0, 8192 bytes) > > Inode-cache hash table entries: 2048 (order: 0, 8192 bytes) > > Memory available: 11392k/16256k RAM, (1736k kernel code, 631k data) > > NR_IRQS:256 > > Calibrating delay loop... HZ=100 > > 15.46 BogoMIPS (lpj=77312) > > pid_max: default: 32768 minimum: 301 > > Mount-cache hash table entries: 1024 > > NET: Registered protocol family 16 > > bio: create slab at 0 > > Switching to clocksource tmr > > NET: Registered protocol family 2 > > TCP established hash table entries: 1024 (order: 0, 8192 bytes) > > TCP bind hash table entries: 1024 (order: -1, 4096 bytes) > > TCP: Hash tables configured (established 1024 bind 1024) > > TCP: reno registered > > UDP hash table entries: 512 (order: 0, 8192 bytes) > > UDP-Lite hash table entries: 512 (order: 0, 8192 bytes) > > NET: Registered protocol family 1 > > jffs2: version 2.2. (NAND) ? 2001-2006 Red Hat, Inc. > > ROMFS MTD (C) 2007 Red Hat, Inc. > > msgmni has been set to 22 > > io scheduler noop registered > > io scheduler deadline registered > > io scheduler cfq registered (default) > > ColdFire internal UART serial driver > > ttyS0 at MMIO 0xfc060000 (irq = 90) is a ColdFire UART > > console [ttyS0] enabled > > ttyS1 at MMIO 0xfc064000 (irq = 91) is a ColdFire UART > > ttyS2 at MMIO 0xfc068000 (irq = 92) is a ColdFire UART > > brd: module loaded > > uclinux[mtd]: RAM probe address=0x4026fd40 size=0x22c000 > > Creating 1 MTD partitions on "RAM": > > 0x000000000000-0x00000022c000 : "ROMfs" > > el5329 flash device: 1000000 at 0 > > el5329 flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID > 0x000001 Chip ID 0x002101 > > Amd/Fujitsu Extended Query Table at 0x0040 > > Amd/Fujitsu Extended Query version 1.3. > > number of CFI chips: 1 > > Creating 7 MTD partitions on " el5329 flash": > > 0x000000000000-0x000000020000 : "vectors" > > 0x000000020000-0x000000040000 : "user_parameters" > > 0x000000040000-0x000000060000 : "system_parameters" > > 0x000000060000-0x000000100000 : "bootloader" > > 0x000000100000-0x000000700000 : "kernel_partition1" > > 0x000000700000-0x000000d00000 : "partition2" > > 0x000000d00000-0x000001000000 : "user_data" > > BUG: scheduling while atomic: swapper/0/0x00000000 > > Modules linked in: > > Call Trace: [<401cf054>] __schedule_bug+0x40/0x52 > > [<401d160e>] __schedule+0x33e/0x3c0 > > [<401d1bf0>] schedule+0x38/0x54 > > [<401d1d90>] schedule_preempt_disabled+0x18/0x24 > > [<401cdd62>] rest_init+0x72/0x82 > > [<401ced70>] printk+0x0/0x20 > > [<40252678>] start_kernel+0x2e8/0x2f4 > > [<400200da>] _exit+0x0/0x6 > > > > ------------[ cut here ]------------ > > WARNING: at kernel/rcutiny.c:135 rcu_idle_exit_common.part.8+0x56/0x66() > > Current pid: 45 comm: kworker/u:1 / Idle pid: 0 comm: swapper > > Modules linked in: > > Call Trace: [<400260f8>] warn_slowpath_common+0x50/0x6a > > [<40026190>] warn_slowpath_fmt+0x2a/0x32 > > [<40060474>] rcu_idle_exit_common.part.8+0x56/0x66 > > [<40060474>] rcu_idle_exit_common.part.8+0x56/0x66 > > [<400607ea>] rcu_irq_enter+0x62/0x98 > > [<4002dbf4>] irq_enter+0xa/0x60 > > [<4002081c>] do_IRQ+0x1c/0x3c > > [<400233ea>] inthandler+0x2a/0x34 > > [<40041e40>] exit_itimers+0x8/0x16e > > [<4002b778>] do_exit+0x524/0x888 > > [<4002be26>] sys_exit+0x0/0x16 > > [<4003ac12>] wait_for_helper+0x0/0x96 > > [<4002be3c>] do_group_exit+0x0/0xf8 > > [<400232d8>] system_call+0x48/0x86 > > [<4003ac12>] wait_for_helper+0x0/0x96 > > [<40020a90>] kernel_thread+0x3a/0x42 > > > > ---[ end trace 6786da2dfad7182c ]--- > > ------------[ cut here ]------------ > > WARNING: at kernel/rcutiny.c:75 > rcu_idle_enter_common.isra.9.part.10+0x6c/0x88() > > Current pid: 45 comm: kworker/u:1 / Idle pid: 0 comm: swapper > > Modules linked in: > > Call Trace: [<400260f8>] warn_slowpath_common+0x50/0x6a > > [<40026190>] warn_slowpath_fmt+0x2a/0x32 > > [<40060922>] rcu_idle_enter_common.isra.9.part.10+0x6c/0x88 > > [<40060922>] rcu_idle_enter_common.isra.9.part.10+0x6c/0x88 > > [<4006098c>] rcu_irq_exit+0x4e/0x98 > > [<4002dc7c>] irq_exit+0x32/0x60 > > [<4002082c>] do_IRQ+0x2c/0x3c > > [<400233ea>] inthandler+0x2a/0x34 > > [<40041e40>] exit_itimers+0x8/0x16e > > [<4002b778>] do_exit+0x524/0x888 > > [<4002be26>] sys_exit+0x0/0x16 > > [<4003ac12>] wait_for_helper+0x0/0x96 > > [<4002be3c>] do_group_exit+0x0/0xf8 > > [<400232d8>] system_call+0x48/0x86 > > [<4003ac12>] wait_for_helper+0x0/0x96 > > [<40020a90>] kernel_thread+0x3a/0x42 > > > > ---[ end trace 6786da2dfad7182d ]--- > > libphy: fec_enet_mii_bus: probed > > TCP: cubic registered > > NET: Registered protocol family 17 > > Name=/dev/root, fs=romfs, flags=32769, data=0 > > VFS: Mounted root (romfs filesystem) readonly on device 31:0. > > Freeing unused kernel memory: 64k freed (0x40252000 - 0x40260000) > > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev From winfeng_hs at 163.com Tue Mar 5 20:20:16 2013 From: winfeng_hs at 163.com (winfeng_hs) Date: Wed, 6 Mar 2013 09:20:16 +0800 (CST) Subject: [uClinux-dev] Uart2any V1.3 -->a FREE debug tool for Serial Port, Support serial port, modbus, can, lin, 38kHz infrared, dl645.. Message-ID: <50010135.16bd4.13d3d48d792.Coremail.winfeng_hs@163.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Uart2anyV1.3.zip Type: application/x-zip-compressed Size: 83352 bytes Desc: not available URL: From christiangieseler at yahoo.de Wed Mar 6 03:18:58 2013 From: christiangieseler at yahoo.de (Christian Gieseler) Date: Wed, 6 Mar 2013 09:18:58 +0100 Subject: [uClinux-dev] migration issue scheduling while atomic In-Reply-To: References: <000001ce19c2$e7ca0790$b75e16b0$@yahoo.de> Message-ID: <000601ce1a43$40a21c60$c1e65520$@yahoo.de> Hi Luis, Yes you are right i was generalizing too much. With preemption disabled The Boot Trace with preemption disabled does not show the scheduling while atomic, but shows a lot of other output with "*** ILLEGAL INSTRUCTION *** FORMAT=4" and kernel panic in the end. The "Sleep inside atomic section checking" option was disabled. If it is enabled it gives a slightly longer trace (see below). But still I am not really sure how to tackle this. As we need preemption in the end it seems better to me to debug with preemption enabled. Or is it easier to get the kernel running first switch on preemption afterwards to separate possible issues? Regards Christian Bootup with "Sleep inside atomic section checking" enabled: BUG: scheduling while atomic: swapper/0/0x00000000 Modules linked in: Call Trace: [<401d04b4>] __schedule_bug+0x40/0x52 [<401d2b0c>] __schedule+0x33e/0x3c0 [<401d3104>] schedule+0x38/0x54 [<401d32a4>] schedule_preempt_disabled+0x18/0x24 [<401cf1c2>] rest_init+0x72/0x82 [<401d01d0>] printk+0x0/0x20 [<40252678>] start_kernel+0x2e8/0x2f4 [<400200da>] _exit+0x0/0x6 ------------[ cut here ]------------ WARNING: at kernel/rcutiny.c:135 rcu_idle_exit_common.part.7+0x56/0x66() Current pid: 45 comm: kworker/u:1 / Idle pid: 0 comm: swapper Modules linked in: Call Trace: [<4002610c>] warn_slowpath_common+0x50/0x6a [<4004665a>] hrtimer_try_to_cancel+0x0/0xbc [<400261a4>] warn_slowpath_fmt+0x2a/0x32 [<400606be>] rcu_idle_exit_common.part.7+0x56/0x66 [<400606be>] rcu_idle_exit_common.part.7+0x56/0x66 [<40060a34>] rcu_irq_enter+0x62/0x98 [<4002dc52>] irq_enter+0xa/0x60 [<4002081c>] do_IRQ+0x1c/0x3c [<400233ea>] inthandler+0x2a/0x34 [<4004665a>] hrtimer_try_to_cancel+0x0/0xbc [<40046668>] hrtimer_try_to_cancel+0xe/0xbc [<4004672a>] hrtimer_cancel+0x14/0x30 [<4002b79a>] do_exit+0x51a/0x888 [<4002be52>] sys_exit+0x0/0x16 [<4003ac72>] wait_for_helper+0x0/0x96 [<4002be68>] do_group_exit+0x0/0xf8 [<400232d8>] system_call+0x48/0x86 [<4003ac72>] wait_for_helper+0x0/0x96 [<40020a90>] kernel_thread+0x3a/0x42 ---[ end trace d05fe4c5ce0089d4 ]--- ------------[ cut here ]------------ WARNING: at kernel/rcutiny.c:75 rcu_idle_enter_common.isra.8.part.9+0x6c/0x88() Current pid: 45 comm: kworker/u:1 / Idle pid: 0 comm: swapper Modules linked in: Call Trace: [<4002610c>] warn_slowpath_common+0x50/0x6a [<400261a4>] warn_slowpath_fmt+0x2a/0x32 [<40060b6c>] rcu_idle_enter_common.isra.8.part.9+0x6c/0x88 [<40060b6c>] rcu_idle_enter_common.isra.8.part.9+0x6c/0x88 [<4004665a>] hrtimer_try_to_cancel+0x0/0xbc [<40060bd6>] rcu_irq_exit+0x4e/0x98 [<4002dcda>] irq_exit+0x32/0x60 [<4002082c>] do_IRQ+0x2c/0x3c [<400233ea>] inthandler+0x2a/0x34 [<4004665a>] hrtimer_try_to_cancel+0x0/0xbc [<40046668>] hrtimer_try_to_cancel+0xe/0xbc [<4004672a>] hrtimer_cancel+0x14/0x30 [<4002b79a>] do_exit+0x51a/0x888 [<4002be52>] sys_exit+0x0/0x16 [<4003ac72>] wait_for_helper+0x0/0x96 [<4002be68>] do_group_exit+0x0/0xf8 [<400232d8>] system_call+0x48/0x86 [<4003ac72>] wait_for_helper+0x0/0x96 [<40020a90>] kernel_thread+0x3a/0x42 ---[ end trace d05fe4c5ce0089d5 ]--- libphy: fec_enet_mii_bus: probed TCP: cubic registered NET: Registered protocol family 17 VFS: Mounted root (romfs filesystem) readonly on device 31:0. Freeing unused kernel memory: 64k freed (0x40252000 - 0x40260000) -----Original Message----- From: uclinux-dev-bounces at uclinux.org [mailto:uclinux-dev-bounces at uclinux.org] On Behalf Of Luis Alves Sent: Tuesday, March 05, 2013 6:19 PM To: uClinux development list Subject: Re: [uClinux-dev] migration issue scheduling while atomic Hi, With preemption disabled, you shouldn't see that message. In your current kernel config, under "Kernel hacking" what is the state of the "Sleep inside atomic section checking" option? Regards, Luis On Tue, Mar 5, 2013 at 5:00 PM, Christian Gieseler wrote: > Hi list, > > > > I ran in another issue while updating our coldfire 5329 board from > linux > 2.6.25 to linux 3.6. > > > > Romfs is mounted as root and then the system says BUG: scheduling > while > atomic: swapper/0/0x00000000 and is finally crashing after some trace > output. > > The system is configured to behave a preemptive system (low latency > desktop) but the system also crashes without preemption activated. > > Does somebody know in which direction to look and how to tackle this issue? > What is the best way to track it down and fix this? > > Let me know if there is more information needed than the boot up > messages below show. > > Best Regards > > Christian > > > > dBUG> dn > > Downloading Image 'image.bin' from 192.168.10.254 > > TFTP transfer completed > > Read 4647940 bytes (9079 blocks) > > dBUG> go 0x40020000 > > Linux version 3.6.11 (christian at cglinux.eks-engel.local) (gcc version > 4.6.1 (Sourcery CodeBench Lite 2011.09-23) ) #72 PREEMPT Tue Mar 5 > 17:32:05 CET > 2013 > > > > > > uClinux/COLDFIRE(m532x) > > COLDFIRE port done by Greg Ungerer, gerg at snapgear.com > > Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne > > Built 1 zonelists in Zone order, mobility grouping off. Total pages: > 2024 > > Kernel command line: rootfstype=romfs console=tty1 > console=ttyS0,115200 > root=/dev/mtdblock0 > > PID hash table entries: 64 (order: -5, 256 bytes) > > Dentry cache hash table entries: 2048 (order: 0, 8192 bytes) > > Inode-cache hash table entries: 2048 (order: 0, 8192 bytes) > > Memory available: 11392k/16256k RAM, (1736k kernel code, 631k data) > > NR_IRQS:256 > > Calibrating delay loop... HZ=100 > > 15.46 BogoMIPS (lpj=77312) > > pid_max: default: 32768 minimum: 301 > > Mount-cache hash table entries: 1024 > > NET: Registered protocol family 16 > > bio: create slab at 0 > > Switching to clocksource tmr > > NET: Registered protocol family 2 > > TCP established hash table entries: 1024 (order: 0, 8192 bytes) > > TCP bind hash table entries: 1024 (order: -1, 4096 bytes) > > TCP: Hash tables configured (established 1024 bind 1024) > > TCP: reno registered > > UDP hash table entries: 512 (order: 0, 8192 bytes) > > UDP-Lite hash table entries: 512 (order: 0, 8192 bytes) > > NET: Registered protocol family 1 > > jffs2: version 2.2. (NAND) C 2001-2006 Red Hat, Inc. > > ROMFS MTD (C) 2007 Red Hat, Inc. > > msgmni has been set to 22 > > io scheduler noop registered > > io scheduler deadline registered > > io scheduler cfq registered (default) > > ColdFire internal UART serial driver > > ttyS0 at MMIO 0xfc060000 (irq = 90) is a ColdFire UART > > console [ttyS0] enabled > > ttyS1 at MMIO 0xfc064000 (irq = 91) is a ColdFire UART > > ttyS2 at MMIO 0xfc068000 (irq = 92) is a ColdFire UART > > brd: module loaded > > uclinux[mtd]: RAM probe address=0x4026fd40 size=0x22c000 > > Creating 1 MTD partitions on "RAM": > > 0x000000000000-0x00000022c000 : "ROMfs" > > el5329 flash device: 1000000 at 0 > > el5329 flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer > ID > 0x000001 Chip ID 0x002101 > > Amd/Fujitsu Extended Query Table at 0x0040 > > Amd/Fujitsu Extended Query version 1.3. > > number of CFI chips: 1 > > Creating 7 MTD partitions on " el5329 flash": > > 0x000000000000-0x000000020000 : "vectors" > > 0x000000020000-0x000000040000 : "user_parameters" > > 0x000000040000-0x000000060000 : "system_parameters" > > 0x000000060000-0x000000100000 : "bootloader" > > 0x000000100000-0x000000700000 : "kernel_partition1" > > 0x000000700000-0x000000d00000 : "partition2" > > 0x000000d00000-0x000001000000 : "user_data" > > BUG: scheduling while atomic: swapper/0/0x00000000 > > Modules linked in: > > Call Trace: [<401cf054>] __schedule_bug+0x40/0x52 > > [<401d160e>] __schedule+0x33e/0x3c0 > > [<401d1bf0>] schedule+0x38/0x54 > > [<401d1d90>] schedule_preempt_disabled+0x18/0x24 > > [<401cdd62>] rest_init+0x72/0x82 > > [<401ced70>] printk+0x0/0x20 > > [<40252678>] start_kernel+0x2e8/0x2f4 > > [<400200da>] _exit+0x0/0x6 > > > > ------------[ cut here ]------------ > > WARNING: at kernel/rcutiny.c:135 > rcu_idle_exit_common.part.8+0x56/0x66() > > Current pid: 45 comm: kworker/u:1 / Idle pid: 0 comm: swapper > > Modules linked in: > > Call Trace: [<400260f8>] warn_slowpath_common+0x50/0x6a > > [<40026190>] warn_slowpath_fmt+0x2a/0x32 > > [<40060474>] rcu_idle_exit_common.part.8+0x56/0x66 > > [<40060474>] rcu_idle_exit_common.part.8+0x56/0x66 > > [<400607ea>] rcu_irq_enter+0x62/0x98 > > [<4002dbf4>] irq_enter+0xa/0x60 > > [<4002081c>] do_IRQ+0x1c/0x3c > > [<400233ea>] inthandler+0x2a/0x34 > > [<40041e40>] exit_itimers+0x8/0x16e > > [<4002b778>] do_exit+0x524/0x888 > > [<4002be26>] sys_exit+0x0/0x16 > > [<4003ac12>] wait_for_helper+0x0/0x96 > > [<4002be3c>] do_group_exit+0x0/0xf8 > > [<400232d8>] system_call+0x48/0x86 > > [<4003ac12>] wait_for_helper+0x0/0x96 > > [<40020a90>] kernel_thread+0x3a/0x42 > > > > ---[ end trace 6786da2dfad7182c ]--- > > ------------[ cut here ]------------ > > WARNING: at kernel/rcutiny.c:75 > rcu_idle_enter_common.isra.9.part.10+0x6c/0x88() > > Current pid: 45 comm: kworker/u:1 / Idle pid: 0 comm: swapper > > Modules linked in: > > Call Trace: [<400260f8>] warn_slowpath_common+0x50/0x6a > > [<40026190>] warn_slowpath_fmt+0x2a/0x32 > > [<40060922>] rcu_idle_enter_common.isra.9.part.10+0x6c/0x88 > > [<40060922>] rcu_idle_enter_common.isra.9.part.10+0x6c/0x88 > > [<4006098c>] rcu_irq_exit+0x4e/0x98 > > [<4002dc7c>] irq_exit+0x32/0x60 > > [<4002082c>] do_IRQ+0x2c/0x3c > > [<400233ea>] inthandler+0x2a/0x34 > > [<40041e40>] exit_itimers+0x8/0x16e > > [<4002b778>] do_exit+0x524/0x888 > > [<4002be26>] sys_exit+0x0/0x16 > > [<4003ac12>] wait_for_helper+0x0/0x96 > > [<4002be3c>] do_group_exit+0x0/0xf8 > > [<400232d8>] system_call+0x48/0x86 > > [<4003ac12>] wait_for_helper+0x0/0x96 > > [<40020a90>] kernel_thread+0x3a/0x42 > > > > ---[ end trace 6786da2dfad7182d ]--- > > libphy: fec_enet_mii_bus: probed > > TCP: cubic registered > > NET: Registered protocol family 17 > > Name=/dev/root, fs=romfs, flags=32769, data=0 > > VFS: Mounted root (romfs filesystem) readonly on device 31:0. > > Freeing unused kernel memory: 64k freed (0x40252000 - 0x40260000) > > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev _______________________________________________ uClinux-dev mailing list uClinux-dev at uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev at uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev From ljalvs at gmail.com Wed Mar 6 06:55:23 2013 From: ljalvs at gmail.com (Luis Alves) Date: Wed, 6 Mar 2013 11:55:23 +0000 Subject: [uClinux-dev] migration issue scheduling while atomic In-Reply-To: <000601ce1a43$40a21c60$c1e65520$@yahoo.de> References: <000001ce19c2$e7ca0790$b75e16b0$@yahoo.de> <000601ce1a43$40a21c60$c1e65520$@yahoo.de> Message-ID: Hi, I'm not an expert on this but I've lost some time not long ago trying to understand what was causing that bug message "scheduling while atomic". My 'short' story: I was trying to trace an issue that I had on my board, so I've enabled the check for 'sleep inside atomic' and I got the spam of 'scheduling while atomic' messages. Without thinking much, I remembered that the gcc toolchain I use doesn't have atomic builtins (it has only been added in gcc-4.7.x for the m68k) so I switched back to the old gcc-4.2.4 toolchain that uses the old m68k ABI (later I realized that kernel has its own code for atomic access), but to my surprise the 'scheduling while atomic' spam was fixed with gcc-4.2.4. After loosing a lot of time comparing the asm from kernel generated with gcc-4.2.4 and gcc-4.5.1, I found nothing that explained the spam. I still don't know what the hell is going on with both gcc's (but is definitively related to it). Maybe something related to memory barriers has changed (or broken ?). Anyway... Digging in the kernel sources and reading some stuff, I concluded that "Sleep inside atomic section checking" doesn't make sense since the m68k arch doesn't support SMP or preemption. >From what I could understand this check looks for scheduling inside spinlocks (that should disable preemption). In my case, since I don't have preemption enabled in the first place, then spinlocks do absolutely nothing (the ones that don't disable irqs). I never bothered again with this, since my kernel works fine and the issue that made me enabled this stupid check, is fixed now. I'm using the latest kernel from Greg m68knommu git (3.8 last time I checked) and my board is based on a dusty (and the father of all) 68000 cpu, not coldfire. TLDR: Searching in the arch/m68k tree I did find some traces of preemption code for coldfire but it seems to be incomplete. Googling also gives me some threads that mention the 'unfinished' preemption support for coldfires. Regards, Luis On Wed, Mar 6, 2013 at 8:18 AM, Christian Gieseler wrote: > Hi Luis, > > Yes you are right i was generalizing too much. With preemption disabled The > Boot Trace with preemption disabled does not show the scheduling while > atomic, but shows a lot of other output with "*** ILLEGAL INSTRUCTION *** > FORMAT=4" and kernel panic in the end. > > The "Sleep inside atomic section checking" option was disabled. If it is > enabled it gives a slightly longer trace (see below). But still I am not > really sure how to tackle this. As we need preemption in the end it seems > better to me to debug with preemption enabled. Or is it easier to get the > kernel running first switch on preemption afterwards to separate possible > issues? > > Regards > Christian > > Bootup with "Sleep inside atomic section checking" enabled: > > BUG: scheduling while atomic: swapper/0/0x00000000 > Modules linked in: > Call Trace: [<401d04b4>] __schedule_bug+0x40/0x52 > [<401d2b0c>] __schedule+0x33e/0x3c0 > [<401d3104>] schedule+0x38/0x54 > [<401d32a4>] schedule_preempt_disabled+0x18/0x24 > [<401cf1c2>] rest_init+0x72/0x82 > [<401d01d0>] printk+0x0/0x20 > [<40252678>] start_kernel+0x2e8/0x2f4 > [<400200da>] _exit+0x0/0x6 > > ------------[ cut here ]------------ > WARNING: at kernel/rcutiny.c:135 rcu_idle_exit_common.part.7+0x56/0x66() > Current pid: 45 comm: kworker/u:1 / Idle pid: 0 comm: swapper > Modules linked in: > Call Trace: [<4002610c>] warn_slowpath_common+0x50/0x6a > [<4004665a>] hrtimer_try_to_cancel+0x0/0xbc > [<400261a4>] warn_slowpath_fmt+0x2a/0x32 > [<400606be>] rcu_idle_exit_common.part.7+0x56/0x66 > [<400606be>] rcu_idle_exit_common.part.7+0x56/0x66 > [<40060a34>] rcu_irq_enter+0x62/0x98 > [<4002dc52>] irq_enter+0xa/0x60 > [<4002081c>] do_IRQ+0x1c/0x3c > [<400233ea>] inthandler+0x2a/0x34 > [<4004665a>] hrtimer_try_to_cancel+0x0/0xbc > [<40046668>] hrtimer_try_to_cancel+0xe/0xbc > [<4004672a>] hrtimer_cancel+0x14/0x30 > [<4002b79a>] do_exit+0x51a/0x888 > [<4002be52>] sys_exit+0x0/0x16 > [<4003ac72>] wait_for_helper+0x0/0x96 > [<4002be68>] do_group_exit+0x0/0xf8 > [<400232d8>] system_call+0x48/0x86 > [<4003ac72>] wait_for_helper+0x0/0x96 > [<40020a90>] kernel_thread+0x3a/0x42 > > ---[ end trace d05fe4c5ce0089d4 ]--- > ------------[ cut here ]------------ > WARNING: at kernel/rcutiny.c:75 > rcu_idle_enter_common.isra.8.part.9+0x6c/0x88() > Current pid: 45 comm: kworker/u:1 / Idle pid: 0 comm: swapper > Modules linked in: > Call Trace: [<4002610c>] warn_slowpath_common+0x50/0x6a > [<400261a4>] warn_slowpath_fmt+0x2a/0x32 > [<40060b6c>] rcu_idle_enter_common.isra.8.part.9+0x6c/0x88 > [<40060b6c>] rcu_idle_enter_common.isra.8.part.9+0x6c/0x88 > [<4004665a>] hrtimer_try_to_cancel+0x0/0xbc > [<40060bd6>] rcu_irq_exit+0x4e/0x98 > [<4002dcda>] irq_exit+0x32/0x60 > [<4002082c>] do_IRQ+0x2c/0x3c > [<400233ea>] inthandler+0x2a/0x34 > [<4004665a>] hrtimer_try_to_cancel+0x0/0xbc > [<40046668>] hrtimer_try_to_cancel+0xe/0xbc > [<4004672a>] hrtimer_cancel+0x14/0x30 > [<4002b79a>] do_exit+0x51a/0x888 > [<4002be52>] sys_exit+0x0/0x16 > [<4003ac72>] wait_for_helper+0x0/0x96 > [<4002be68>] do_group_exit+0x0/0xf8 > [<400232d8>] system_call+0x48/0x86 > [<4003ac72>] wait_for_helper+0x0/0x96 > [<40020a90>] kernel_thread+0x3a/0x42 > > ---[ end trace d05fe4c5ce0089d5 ]--- > libphy: fec_enet_mii_bus: probed > TCP: cubic registered > NET: Registered protocol family 17 > VFS: Mounted root (romfs filesystem) readonly on device 31:0. > Freeing unused kernel memory: 64k freed (0x40252000 - 0x40260000) > > > > -----Original Message----- > From: uclinux-dev-bounces at uclinux.org > [mailto:uclinux-dev-bounces at uclinux.org] On Behalf Of Luis Alves > Sent: Tuesday, March 05, 2013 6:19 PM > To: uClinux development list > Subject: Re: [uClinux-dev] migration issue scheduling while atomic > > Hi, > > With preemption disabled, you shouldn't see that message. > In your current kernel config, under "Kernel hacking" what is the state of > the "Sleep inside atomic section checking" option? > > Regards, > Luis > > > On Tue, Mar 5, 2013 at 5:00 PM, Christian Gieseler > wrote: >> Hi list, >> >> >> >> I ran in another issue while updating our coldfire 5329 board from >> linux >> 2.6.25 to linux 3.6. >> >> >> >> Romfs is mounted as root and then the system says BUG: scheduling >> while >> atomic: swapper/0/0x00000000 and is finally crashing after some trace >> output. >> >> The system is configured to behave a preemptive system (low latency >> desktop) but the system also crashes without preemption activated. >> >> Does somebody know in which direction to look and how to tackle this > issue? >> What is the best way to track it down and fix this? >> >> Let me know if there is more information needed than the boot up >> messages below show. >> >> Best Regards >> >> Christian >> >> >> >> dBUG> dn >> >> Downloading Image 'image.bin' from 192.168.10.254 >> >> TFTP transfer completed >> >> Read 4647940 bytes (9079 blocks) >> >> dBUG> go 0x40020000 >> >> Linux version 3.6.11 (christian at cglinux.eks-engel.local) (gcc version >> 4.6.1 (Sourcery CodeBench Lite 2011.09-23) ) #72 PREEMPT Tue Mar 5 >> 17:32:05 CET >> 2013 >> >> >> >> >> >> uClinux/COLDFIRE(m532x) >> >> COLDFIRE port done by Greg Ungerer, gerg at snapgear.com >> >> Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne >> >> Built 1 zonelists in Zone order, mobility grouping off. Total pages: >> 2024 >> >> Kernel command line: rootfstype=romfs console=tty1 >> console=ttyS0,115200 >> root=/dev/mtdblock0 >> >> PID hash table entries: 64 (order: -5, 256 bytes) >> >> Dentry cache hash table entries: 2048 (order: 0, 8192 bytes) >> >> Inode-cache hash table entries: 2048 (order: 0, 8192 bytes) >> >> Memory available: 11392k/16256k RAM, (1736k kernel code, 631k data) >> >> NR_IRQS:256 >> >> Calibrating delay loop... HZ=100 >> >> 15.46 BogoMIPS (lpj=77312) >> >> pid_max: default: 32768 minimum: 301 >> >> Mount-cache hash table entries: 1024 >> >> NET: Registered protocol family 16 >> >> bio: create slab at 0 >> >> Switching to clocksource tmr >> >> NET: Registered protocol family 2 >> >> TCP established hash table entries: 1024 (order: 0, 8192 bytes) >> >> TCP bind hash table entries: 1024 (order: -1, 4096 bytes) >> >> TCP: Hash tables configured (established 1024 bind 1024) >> >> TCP: reno registered >> >> UDP hash table entries: 512 (order: 0, 8192 bytes) >> >> UDP-Lite hash table entries: 512 (order: 0, 8192 bytes) >> >> NET: Registered protocol family 1 >> >> jffs2: version 2.2. (NAND) C 2001-2006 Red Hat, Inc. >> >> ROMFS MTD (C) 2007 Red Hat, Inc. >> >> msgmni has been set to 22 >> >> io scheduler noop registered >> >> io scheduler deadline registered >> >> io scheduler cfq registered (default) >> >> ColdFire internal UART serial driver >> >> ttyS0 at MMIO 0xfc060000 (irq = 90) is a ColdFire UART >> >> console [ttyS0] enabled >> >> ttyS1 at MMIO 0xfc064000 (irq = 91) is a ColdFire UART >> >> ttyS2 at MMIO 0xfc068000 (irq = 92) is a ColdFire UART >> >> brd: module loaded >> >> uclinux[mtd]: RAM probe address=0x4026fd40 size=0x22c000 >> >> Creating 1 MTD partitions on "RAM": >> >> 0x000000000000-0x00000022c000 : "ROMfs" >> >> el5329 flash device: 1000000 at 0 >> >> el5329 flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer >> ID >> 0x000001 Chip ID 0x002101 >> >> Amd/Fujitsu Extended Query Table at 0x0040 >> >> Amd/Fujitsu Extended Query version 1.3. >> >> number of CFI chips: 1 >> >> Creating 7 MTD partitions on " el5329 flash": >> >> 0x000000000000-0x000000020000 : "vectors" >> >> 0x000000020000-0x000000040000 : "user_parameters" >> >> 0x000000040000-0x000000060000 : "system_parameters" >> >> 0x000000060000-0x000000100000 : "bootloader" >> >> 0x000000100000-0x000000700000 : "kernel_partition1" >> >> 0x000000700000-0x000000d00000 : "partition2" >> >> 0x000000d00000-0x000001000000 : "user_data" >> >> BUG: scheduling while atomic: swapper/0/0x00000000 >> >> Modules linked in: >> >> Call Trace: [<401cf054>] __schedule_bug+0x40/0x52 >> >> [<401d160e>] __schedule+0x33e/0x3c0 >> >> [<401d1bf0>] schedule+0x38/0x54 >> >> [<401d1d90>] schedule_preempt_disabled+0x18/0x24 >> >> [<401cdd62>] rest_init+0x72/0x82 >> >> [<401ced70>] printk+0x0/0x20 >> >> [<40252678>] start_kernel+0x2e8/0x2f4 >> >> [<400200da>] _exit+0x0/0x6 >> >> >> >> ------------[ cut here ]------------ >> >> WARNING: at kernel/rcutiny.c:135 >> rcu_idle_exit_common.part.8+0x56/0x66() >> >> Current pid: 45 comm: kworker/u:1 / Idle pid: 0 comm: swapper >> >> Modules linked in: >> >> Call Trace: [<400260f8>] warn_slowpath_common+0x50/0x6a >> >> [<40026190>] warn_slowpath_fmt+0x2a/0x32 >> >> [<40060474>] rcu_idle_exit_common.part.8+0x56/0x66 >> >> [<40060474>] rcu_idle_exit_common.part.8+0x56/0x66 >> >> [<400607ea>] rcu_irq_enter+0x62/0x98 >> >> [<4002dbf4>] irq_enter+0xa/0x60 >> >> [<4002081c>] do_IRQ+0x1c/0x3c >> >> [<400233ea>] inthandler+0x2a/0x34 >> >> [<40041e40>] exit_itimers+0x8/0x16e >> >> [<4002b778>] do_exit+0x524/0x888 >> >> [<4002be26>] sys_exit+0x0/0x16 >> >> [<4003ac12>] wait_for_helper+0x0/0x96 >> >> [<4002be3c>] do_group_exit+0x0/0xf8 >> >> [<400232d8>] system_call+0x48/0x86 >> >> [<4003ac12>] wait_for_helper+0x0/0x96 >> >> [<40020a90>] kernel_thread+0x3a/0x42 >> >> >> >> ---[ end trace 6786da2dfad7182c ]--- >> >> ------------[ cut here ]------------ >> >> WARNING: at kernel/rcutiny.c:75 >> rcu_idle_enter_common.isra.9.part.10+0x6c/0x88() >> >> Current pid: 45 comm: kworker/u:1 / Idle pid: 0 comm: swapper >> >> Modules linked in: >> >> Call Trace: [<400260f8>] warn_slowpath_common+0x50/0x6a >> >> [<40026190>] warn_slowpath_fmt+0x2a/0x32 >> >> [<40060922>] rcu_idle_enter_common.isra.9.part.10+0x6c/0x88 >> >> [<40060922>] rcu_idle_enter_common.isra.9.part.10+0x6c/0x88 >> >> [<4006098c>] rcu_irq_exit+0x4e/0x98 >> >> [<4002dc7c>] irq_exit+0x32/0x60 >> >> [<4002082c>] do_IRQ+0x2c/0x3c >> >> [<400233ea>] inthandler+0x2a/0x34 >> >> [<40041e40>] exit_itimers+0x8/0x16e >> >> [<4002b778>] do_exit+0x524/0x888 >> >> [<4002be26>] sys_exit+0x0/0x16 >> >> [<4003ac12>] wait_for_helper+0x0/0x96 >> >> [<4002be3c>] do_group_exit+0x0/0xf8 >> >> [<400232d8>] system_call+0x48/0x86 >> >> [<4003ac12>] wait_for_helper+0x0/0x96 >> >> [<40020a90>] kernel_thread+0x3a/0x42 >> >> >> >> ---[ end trace 6786da2dfad7182d ]--- >> >> libphy: fec_enet_mii_bus: probed >> >> TCP: cubic registered >> >> NET: Registered protocol family 17 >> >> Name=/dev/root, fs=romfs, flags=32769, data=0 >> >> VFS: Mounted root (romfs filesystem) readonly on device 31:0. >> >> Freeing unused kernel memory: 64k freed (0x40252000 - 0x40260000) >> >> >> _______________________________________________ >> uClinux-dev mailing list >> uClinux-dev at uclinux.org >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by uclinux-dev at uclinux.org To unsubscribe see: >> http://mailman.uclinux.org/mailman/options/uclinux-dev > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev From geert at linux-m68k.org Wed Mar 6 08:05:18 2013 From: geert at linux-m68k.org (Geert Uytterhoeven) Date: Wed, 6 Mar 2013 14:05:18 +0100 Subject: [uClinux-dev] migration issue scheduling while atomic In-Reply-To: References: <000001ce19c2$e7ca0790$b75e16b0$@yahoo.de> <000601ce1a43$40a21c60$c1e65520$@yahoo.de> Message-ID: On Wed, Mar 6, 2013 at 12:55 PM, Luis Alves wrote: > Anyway... Digging in the kernel sources and reading some stuff, I > concluded that "Sleep inside atomic section checking" doesn't make > sense since the m68k arch doesn't support SMP or preemption. > From what I could understand this check looks for scheduling inside > spinlocks (that should disable preemption). > In my case, since I don't have preemption enabled in the first place, > then spinlocks do absolutely nothing (the ones that don't disable > irqs). Isn't this message also printed while scheduling with interrupts disabled? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From mobile.parmenides at gmail.com Wed Mar 6 21:01:07 2013 From: mobile.parmenides at gmail.com (Parmenides) Date: Thu, 7 Mar 2013 10:01:07 +0800 Subject: [uClinux-dev] How to write to screen with framebuffer? Message-ID: <001201ce1ad7$a4492170$ecdb6450$@gmail.com> Hi, all I have compiled the uClinux and run it on my board successfully. Now I need run a program which is to write some picture to LCD screen. So, I recompiled the uClinux with the following kernel configuration: Character devices --> Virtual Terminals Console drivers --> Support Frame buffer devices --> Frame-buffer support --> Support for frame buffer devices --> S3C44B0X LCD support --> Advanced low level driver options --> 2 bpp packed pixels support --> 4 bpp packed pixels support --> 8 bpp packed pixels support --> 16 bpp packed pixels support --> 32 bpp packed pixels support --> Select compiled-in fonts --> VGA 8*8 font --> VGA 8*16 font After the uClinux booting, a penguin logo displayed on the LCD screen. So, I think the framebuffer driver must work well. But, when I run a program to write the LCD screen directly, there is no picture displayed at all. I think when the LCD is used as virtual terminal, the picture may not be displayed. So, I want to use the framebuffer driver without the virtual terminal support. Is there any way to achieve the goal? Thanks! From amarayya.hiremath at solus.in Fri Mar 8 00:10:28 2013 From: amarayya.hiremath at solus.in (amar) Date: Fri, 8 Mar 2013 05:10:28 +0000 (UTC) Subject: [uClinux-dev] implement WEB-SERVICE with uclinux using c programming. Message-ID: Hi, To implement WEB-SERVICE with uclinux using c programming. I have googled and got some tools to use such like gSOAP and axis2c-2.8 to implement web service,and succeed building WEB-service in host machine(PC). I have implemented the simple add operation in web service with using gsoap,now I want to run and implement the same on the target board LPC1788 with uclinux running, how to achieve this please guide me on this. Is it possible to give the out of gcc compiler to arm crass compiler..? if We can how .? how can I compile the .o or executable(out of gcc on host machine) using arm-uclinuxeabi...? The out of the gsoap with gcc giving me an executable file. that in oder to run on target I need to crass compile it. Please help Us how to achieve this.? From iguffick at iee.org Fri Mar 8 15:37:08 2013 From: iguffick at iee.org (Ian Guffick) Date: Fri, 8 Mar 2013 20:37:08 +0000 Subject: [uClinux-dev] How to write to screen with framebuffer? In-Reply-To: <001201ce1ad7$a4492170$ecdb6450$@gmail.com> References: <001201ce1ad7$a4492170$ecdb6450$@gmail.com> Message-ID: Have a look at 'ezfb' at http://www.akrobiz.com/ezfb/index.html It is a 'Linux Framebuffer API', you should be able to get a simple demo running pretty quickly. Regards, Ian. On 7 March 2013 02:01, Parmenides wrote: > Hi, all > > I have compiled the uClinux and run it on my board successfully. Now I need > run a program which is to write some picture to LCD screen. So, I recompiled > the uClinux with the following kernel configuration: > > Character devices > --> Virtual Terminals > > Console drivers > --> Support Frame buffer devices > --> Frame-buffer support > --> Support for frame buffer devices > --> S3C44B0X LCD support > --> Advanced low level driver options > --> 2 bpp packed pixels support > --> 4 bpp packed pixels support > --> 8 bpp packed pixels support > --> 16 bpp packed pixels support > --> 32 bpp packed pixels support > --> Select compiled-in fonts > --> VGA 8*8 font > --> VGA 8*16 font > > After the uClinux booting, a penguin logo displayed on the LCD screen. So, I > think the framebuffer driver must work well. But, when I run a program to > write the LCD screen directly, there is no picture displayed at all. I think > when the LCD is used as virtual terminal, the picture may not be displayed. > > So, I want to use the framebuffer driver without the virtual terminal > support. Is there any way to achieve the goal? Thanks! > > > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev From amarayya.hiremath at solus.in Mon Mar 11 01:12:39 2013 From: amarayya.hiremath at solus.in (amar) Date: Mon, 11 Mar 2013 05:12:39 +0000 (UTC) Subject: [uClinux-dev] port of user app onto arm References: Message-ID: I do have same problem, I am unable to solve this can any one help on this Marek Bykowski klasonline.com> writes: > > Hello All,It's my first post so wanted to say hello to everybody. I'm doing a port of user app "opennhrp" onto an arm platform and seems to be running into a c-ares library problem (Ubuntu package: libc-ares-dev). Part of my Makefile where I replace standard gcc with arm gcc looks as below:#CC???????????? := $(CROSS_COMPILE)gcc#LD???????????? := $(CROSS_COMPILE)ld# !!!!!!!!!!!!!! snapgear replacements !!!!!!!!!!!!!!!!!!!!!!!!!! > ## snapgear cross-compilationCC????????????? := ucfront-gcc arm-linux-gcc -mbig-endian? # ucfront and arm c compiler and big endianLD????????????? := ucfront-ld arm-linux-ld???????????????? # ucfront and arm linker > AR????????????? := arm-linux-ar r????????????????????????? # binary utilities for subroutines in archived libsSTRIP?????????? := arm-linux-strip????????????????????? # strips the symbols from object fileswhen compiling the following error apears: > CC????? nhrp/admin.o? CC????? nhrp/libev.o? CC????? nhrp/nhrp_address.onhrp/nhrp_address.c:22:26: ares_version.h: No such file or directorynhrp/nhrp_address.c: In function `ares_io_cb':nhrp/nhrp_address.c:63: error: `ares_socket_t' undeclared (first use in this function) > nhrp/nhrp_address.c:63: error: (Each undeclared identifier is reported only oncenhrp/nhrp_address.c:63: error: for each function it appears in.)nhrp/nhrp_address.c:63: error: parse error before "rfd" > nhrp/nhrp_address.c:66: error: `rfd' undeclared (first use in this function)nhrp/nhrp_address.c:68: error: `wfd' undeclared (first use in this function)nhrp/nhrp_address.c:70: warning: implicit declaration of function `ares_process_fd' > nhrp/nhrp_address.c: At top level:nhrp/nhrp_address.c:73: error: parse error before "ares_socket_t"nhrp/nhrp_address.c:75: warning: function declaration isn't a prototypenhrp/nhrp_address.c: In function `ares_socket_cb': > nhrp/nhrp_address.c:76: error: `data' undeclared (first use in this function)nhrp/nhrp_address.c:79: error: `readable' undeclared (first use in this function)nhrp/nhrp_address.c:81: error: `writable' undeclared (first use in this function) > nhrp/nhrp_address.c:85: error: `fd' undeclared (first use in this function)nhrp/nhrp_address.c: In function `nhrp_address_resolve_cancel':nhrp/nhrp_address.c:258: warning: implicit declaration of function `ares_cancel' > nhrp/nhrp_address.c: In function `nhrp_address_init':nhrp/nhrp_address.c:427: error: structure has no member named `sock_state_cb'nhrp/nhrp_address.c:428: error: structure has no member named `sock_state_cb_data' > nhrp/nhrp_address.c:432: error: `ARES_OPT_SOCK_STATE_CB' undeclared (first use in this function)Have anybody of you came across this problem before?Thanks a million,Marek > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev From engineerphogat at gmail.com Tue Mar 12 10:41:07 2013 From: engineerphogat at gmail.com (Ashish Phogat) Date: Tue, 12 Mar 2013 10:41:07 -0400 Subject: [uClinux-dev] Rsyslog Daemon Message-ID: Hey Folks, Anyone succeded in building rsyslog daemon in uclinux Network applications for architectures which are MMU less. I am struggling with Coldfire M5272C3 which is MMU less. I know rsyslog is full of pthreads, which I enabled in uClibc library configuration. But still I am getting errors related to undefined references in file "net.c". Actually the functions that "net.c" is looking for are present in "parser.c" file. I am not sure what I am missing. Is it that all applications which are coded using pthreads will not be compiled for MMU less achitectures? Thanks in advance for replying. Thanks Phogat -------------- next part -------------- An HTML attachment was scrubbed... URL: From baker at usgs.gov Tue Mar 12 17:26:44 2013 From: baker at usgs.gov (Larry Baker) Date: Tue, 12 Mar 2013 14:26:44 -0700 Subject: [uClinux-dev] Rsyslog Daemon In-Reply-To: References: Message-ID: <71683CED-AB0E-439F-ADD6-3B1422FEF39D@usgs.gov> Ashish, My uClinux builds apps with the following command, e.g., for config.c: # ucfront-gcc m68k-uclinux-gcc -mcpu=5208 -DCONFIG_COLDFIRE -fomit-frame-pointer -pipe -fno-common -fno-builtin -fno-dwarf2-cfi-asm -msep-data -D__linux__ -Dunix -D__uClinux__ -DEMBED -Os -g -Os -g -fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall -DEMBED -fno-dwarf2-cfi-asm -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -c dbug-config.c The makefile for rsyslog (linux/user/rsyslog/makefile) is: [root at atompc linux]# cat user/rsyslog/makefile PREFIX= DESTDIR=$(shell pwd)/install CONFOPTS = --prefix=$(PREFIX) --disable-klog #--disable-shared all: build/build $(MAKE) -C build $(MAKE) -C build install DESTDIR=$(DESTDIR) build/build: makefile rm -rf build install mkdir build (cd build; sh ../configure $(CONFIGURE_OPTS) $(CONFOPTS)) touch build/build clean: rm -rf build install romfs: $(ROMFSINST) -f $(DESTDIR)/sbin /sbin $(ROMFSINST) -f $(DESTDIR)/lib /lib I didn't configure rsyslogd on my system (Lantronix EDS2100), so this is all I can tell you. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov On 12 Mar 2013, at 7:41 AM, Ashish Phogat wrote: > Hey Folks, > > Anyone succeded in building rsyslog daemon in uclinux Network applications for architectures which are MMU less. I am struggling with Coldfire M5272C3 which is MMU less. I know rsyslog is full of pthreads, which I enabled in uClibc library configuration. But still I am getting errors related to undefined references in file "net.c". Actually the functions that "net.c" is looking for are present in "parser.c" file. > > I am not sure what I am missing. > > > Is it that all applications which are coded using pthreads will not be compiled for MMU less achitectures? > > Thanks in advance for replying. > > Thanks > Phogat > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev From uclinux at schoeldgen.de Thu Mar 14 02:01:03 2013 From: uclinux at schoeldgen.de (Matthias Schoeldgen) Date: Thu, 14 Mar 2013 07:01:03 +0100 Subject: [uClinux-dev] How to write to screen with framebuffer? In-Reply-To: References: <001201ce1ad7$a4492170$ecdb6450$@gmail.com> Message-ID: <5141679F.5000905@schoeldgen.de> Parmenides, the splash logo on the LCD is a good start as it shows that you configured timings and dimensions correctly but it doesn't use the frambuffer device yet. To use your display you need to create a /dev/fb/fb0 device (or simply /dev/fb0 if you're using an 2.0 or 2.4 kernel) and use that for your graphic application. Make sure you create that (typically in the Makefile) before building your image. Its is also a good help to enable the build for one of the small graphical applcations like 'lissa' and include that as it will show the functionality of the fb0 device. Ian Guffick schrieb: > Have a look at 'ezfb' at http://www.akrobiz.com/ezfb/index.html > It is a 'Linux Framebuffer API', you should be able to get a simple > demo running pretty quickly. > > Regards, > Ian. > > > On 7 March 2013 02:01, Parmenides wrote: >> Hi, all >> >> I have compiled the uClinux and run it on my board successfully. Now I need >> run a program which is to write some picture to LCD screen. So, I recompiled >> the uClinux with the following kernel configuration: >> >> Character devices >> --> Virtual Terminals >> >> Console drivers >> --> Support Frame buffer devices >> --> Frame-buffer support >> --> Support for frame buffer devices >> --> S3C44B0X LCD support >> --> Advanced low level driver options >> --> 2 bpp packed pixels support >> --> 4 bpp packed pixels support >> --> 8 bpp packed pixels support >> --> 16 bpp packed pixels support >> --> 32 bpp packed pixels support >> --> Select compiled-in fonts >> --> VGA 8*8 font >> --> VGA 8*16 font >> >> After the uClinux booting, a penguin logo displayed on the LCD screen. So, I >> think the framebuffer driver must work well. But, when I run a program to >> write the LCD screen directly, there is no picture displayed at all. I think >> when the LCD is used as virtual terminal, the picture may not be displayed. >> >> So, I want to use the framebuffer driver without the virtual terminal >> support. Is there any way to achieve the goal? Thanks! >> >> >> >> _______________________________________________ >> uClinux-dev mailing list >> uClinux-dev at uclinux.org >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by uclinux-dev at uclinux.org >> To unsubscribe see: >> http://mailman.uclinux.org/mailman/options/uclinux-dev > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > From engineerphogat at gmail.com Fri Mar 22 09:28:18 2013 From: engineerphogat at gmail.com (Ashish Phogat) Date: Fri, 22 Mar 2013 09:28:18 -0400 Subject: [uClinux-dev] RAM based filesystem in uclinux Message-ID: Hi folks, I have some basic problem: I have my uclinux currently running on Coldfire board from RAM. I have romfs as my file system but that is read only file system.I donot enable MTD support, blckmem is also disabled. I enabled a RAM disk(CONFIG_BLK_DEV_RAM) and initrd(CONFIG_BLK_DEV_INITRD) and choose rootfs as my filesystem. Now I want to change my configuration so that I have a writable filesystem in RAM. I am confused with the configurations I need to set to choose a writable file system for uclinux running from RAM. What uclinux configuration I need to select to boot uclinux in RAM with writeable filesystem? I guess I donot need MTD because that is used for FLASH memory, Neither I need blckmen that is also for FLASH memory. I need to just create a block on RAM and just put a filesystem on that block. Please correct me if I am wrong. Please also proivde the reason which and why a particular configuration is enabled. What role the config is playing in writeable filesystem? Thanks a lot for replying -------------- next part -------------- An HTML attachment was scrubbed... URL: From lsorense at csclub.uwaterloo.ca Fri Mar 22 09:41:27 2013 From: lsorense at csclub.uwaterloo.ca (Lennart Sorensen) Date: Fri, 22 Mar 2013 09:41:27 -0400 Subject: [uClinux-dev] RAM based filesystem in uclinux In-Reply-To: References: Message-ID: <20130322134127.GO1271@csclub.uwaterloo.ca> On Fri, Mar 22, 2013 at 09:28:18AM -0400, Ashish Phogat wrote: > Hi folks, > I have some basic problem: > > I have my uclinux currently running on Coldfire board from RAM. I have > romfs as my file system but that is read only file system.I donot enable > MTD support, blckmem is also disabled. > > I enabled a RAM disk(CONFIG_BLK_DEV_RAM) and initrd(CONFIG_BLK_DEV_INITRD) > and choose rootfs as my filesystem. > > > Now I want to change my configuration so that I have a writable filesystem > in RAM. > > I am confused with the configurations I need to set to choose a writable > file system for uclinux running from RAM. > > What uclinux configuration I need to select to boot uclinux in RAM with > writeable filesystem? > > I guess I donot need MTD because that is used for FLASH memory, Neither I > need blckmen that is also for FLASH memory. I need to just create a block > on RAM and just put a filesystem on that block. > > Please correct me if I am wrong. > > Please also proivde the reason which and why a particular configuration is > enabled. What role the config is playing in writeable filesystem? > Thanks a lot for replying We use initramfs and a cpio archive joined with the kernel in a multipart uImage. Works great. In the case of busybox and other multicall binaries, using hardlinks uses vastly less ram than symlinks (each symlink uses one page of ram to store the symlink file). The fact we can recreate the cpio archive and update the uImage from the kernel and cpio archive is great. No recompile crap to deal with the way romfs and such have tended to need. For us building the kernel and the filesystem are totally seperate issues. -- Len Sorensen From engineerphogat at gmail.com Fri Mar 22 10:06:03 2013 From: engineerphogat at gmail.com (Ashish Phogat) Date: Fri, 22 Mar 2013 10:06:03 -0400 Subject: [uClinux-dev] RAM based filesystem in uclinux In-Reply-To: <20130322134127.GO1271@csclub.uwaterloo.ca> References: <20130322134127.GO1271@csclub.uwaterloo.ca> Message-ID: I am using Linux kernel version 2.4...Whether initramfs is available in that kernel version 2.4 with cpio archieve. DO I need to select initrd or ramdisk with initramfs? I am sorry I am new to uclinux/linux. I am building myself in uclinux Thanks Ashish Phogat On Fri, Mar 22, 2013 at 9:41 AM, Lennart Sorensen < lsorense at csclub.uwaterloo.ca> wrote: > On Fri, Mar 22, 2013 at 09:28:18AM -0400, Ashish Phogat wrote: > > Hi folks, > > I have some basic problem: > > > > I have my uclinux currently running on Coldfire board from RAM. I have > > romfs as my file system but that is read only file system.I donot enable > > MTD support, blckmem is also disabled. > > > > I enabled a RAM disk(CONFIG_BLK_DEV_RAM) and > initrd(CONFIG_BLK_DEV_INITRD) > > and choose rootfs as my filesystem. > > > > > > Now I want to change my configuration so that I have a writable > filesystem > > in RAM. > > > > I am confused with the configurations I need to set to choose a writable > > file system for uclinux running from RAM. > > > > What uclinux configuration I need to select to boot uclinux in RAM with > > writeable filesystem? > > > > I guess I donot need MTD because that is used for FLASH memory, Neither I > > need blckmen that is also for FLASH memory. I need to just create a block > > on RAM and just put a filesystem on that block. > > > > Please correct me if I am wrong. > > > > Please also proivde the reason which and why a particular configuration > is > > enabled. What role the config is playing in writeable filesystem? > > Thanks a lot for replying > > We use initramfs and a cpio archive joined with the kernel in a multipart > uImage. Works great. In the case of busybox and other multicall binaries, > using hardlinks uses vastly less ram than symlinks (each symlink uses > one page of ram to store the symlink file). > > The fact we can recreate the cpio archive and update the uImage from > the kernel and cpio archive is great. No recompile crap to deal with > the way romfs and such have tended to need. For us building the kernel > and the filesystem are totally seperate issues. > > -- > Len Sorensen > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lsorense at csclub.uwaterloo.ca Fri Mar 22 11:02:37 2013 From: lsorense at csclub.uwaterloo.ca (Lennart Sorensen) Date: Fri, 22 Mar 2013 11:02:37 -0400 Subject: [uClinux-dev] RAM based filesystem in uclinux In-Reply-To: References: <20130322134127.GO1271@csclub.uwaterloo.ca> Message-ID: <20130322150237.GP1271@csclub.uwaterloo.ca> On Fri, Mar 22, 2013 at 10:06:03AM -0400, Ashish Phogat wrote: > I am using Linux kernel version 2.4...Whether initramfs is available in > that kernel version 2.4 with cpio archieve. > DO I need to select initrd or ramdisk with initramfs? > > I am sorry I am new to uclinux/linux. I am building myself in uclinux Oh we are using 2.6.29. I would not want to go back to 2.4. I am not aware of any good options for 2.4 kernels, although given I stopped bothering with 2.4 8 years ago I might just have forgotten. -- Len Sorensen From engineerphogat at gmail.com Fri Mar 22 16:47:24 2013 From: engineerphogat at gmail.com (Ashish Phogat) Date: Fri, 22 Mar 2013 16:47:24 -0400 Subject: [uClinux-dev] RAM based filesystem in uclinux In-Reply-To: <20130322150237.GP1271@csclub.uwaterloo.ca> References: <20130322134127.GO1271@csclub.uwaterloo.ca> <20130322150237.GP1271@csclub.uwaterloo.ca> Message-ID: Anyone Else having Idea about my query related to RAM based filesystem. On Fri, Mar 22, 2013 at 11:02 AM, Lennart Sorensen < lsorense at csclub.uwaterloo.ca> wrote: > On Fri, Mar 22, 2013 at 10:06:03AM -0400, Ashish Phogat wrote: > > I am using Linux kernel version 2.4...Whether initramfs is available in > > that kernel version 2.4 with cpio archieve. > > DO I need to select initrd or ramdisk with initramfs? > > > > I am sorry I am new to uclinux/linux. I am building myself in uclinux > > Oh we are using 2.6.29. I would not want to go back to 2.4. > > I am not aware of any good options for 2.4 kernels, although given I > stopped bothering with 2.4 8 years ago I might just have forgotten. > > -- > Len Sorensen > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregungerer at westnet.com.au Fri Mar 22 18:49:37 2013 From: gregungerer at westnet.com.au (Greg Ungerer) Date: Sat, 23 Mar 2013 08:49:37 +1000 Subject: [uClinux-dev] RAM based filesystem in uclinux In-Reply-To: <20130322134127.GO1271@csclub.uwaterloo.ca> References: <20130322134127.GO1271@csclub.uwaterloo.ca> Message-ID: <514CE001.8030408@westnet.com.au> Hi Lennart, On 22/03/13 23:41, Lennart Sorensen wrote: > The fact we can recreate the cpio archive and update the uImage from > the kernel and cpio archive is great. No recompile crap to deal with > the way romfs and such have tended to need. For us building the kernel > and the filesystem are totally seperate issues. I don't follow you here. How does using a ROMfs mean that building the kernel and filesystem are not separate? Regards Greg From engineerphogat at gmail.com Sat Mar 23 19:14:54 2013 From: engineerphogat at gmail.com (Ashish Phogat) Date: Sun, 24 Mar 2013 04:44:54 +0530 Subject: [uClinux-dev] RAM based filesystem in uclinux In-Reply-To: <514CE001.8030408@westnet.com.au> References: <20130322134127.GO1271@csclub.uwaterloo.ca> <514CE001.8030408@westnet.com.au> Message-ID: Hi, Could someone provide me the mechanism/configuration to have a RAM based filesystem which is writable? My kernel is 2.4. Thanks for replying On Sat, Mar 23, 2013 at 4:19 AM, Greg Ungerer wrote: > Hi Lennart, > > On 22/03/13 23:41, Lennart Sorensen wrote: > > The fact we can recreate the cpio archive and update the uImage from > > the kernel and cpio archive is great. No recompile crap to deal with > > the way romfs and such have tended to need. For us building the kernel > > and the filesystem are totally seperate issues. > > I don't follow you here. How does using a ROMfs mean that building > the kernel and filesystem are not separate? > > Regards > Greg > > > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From derosier at gmail.com Sat Mar 23 22:25:00 2013 From: derosier at gmail.com (Steve deRosier) Date: Sat, 23 Mar 2013 19:25:00 -0700 Subject: [uClinux-dev] RAM based filesystem in uclinux In-Reply-To: References: <20130322134127.GO1271@csclub.uwaterloo.ca> <514CE001.8030408@westnet.com.au> Message-ID: Ashish, With respect, people here have already mentioned a couple of ways. The most common for non-embedded systems is a initramfs or initrd via a cpio archive. There's extensive documentation on this in Documentation/initrd.txt. Embedded systems typically _don't_ want a writable root filesystem. uClinux is typically setup with a romfs, and then a writeable ramfs located at /var. If you're looking for a space to write temporary files during runtime, you'd probably want to do so there. Be aware of course that those go away at reboot. And for that matter, typically the way the initramfs or initrd work is you may be able to write to them, but on reboot any changes aren't persisted anyway. In my rc file: /bin/expand /etc/ramfs.img /dev/ram1 mount -t ext2 /dev/ram1 /var There's also tmpfs. You can set one of those up (exist in 2.4??) and mount on some arbitrary mount point. For writable and persisting, you're going to need to use a real filesystem on some real media, either disk or flash. And if you don't need persistance, then I don't see why directing your temp files to an already writable space in /var or /tmp won't work. As for the exact configuration settings and all that... well, you're on a 2.4 kernel and nearly no one is bothering with that kernel anymore. Heck, I'm working on a 3.2 kernel and someone told me the other day that I'm way out-of-date. Anyway, since you're on a 2.4 kernel, I certainly don't remember the specific settings anymore, nor do I have one setup that way lying around to check for you. You're going to do some looking and some trial-and-error to figure out the correct settings. But I'd be shocked if there isn't some legacy how-to out there. And the aforementioned documentation should be sufficient. If you don't have a very compelling reason to stay on a 2.4 kernel you might want to consider upgrading. Especially if you're starting a new project. I hope that helps, - Steve On Sat, Mar 23, 2013 at 4:14 PM, Ashish Phogat wrote: > Hi, > Could someone provide me the mechanism/configuration to have a RAM based > filesystem which is writable? My kernel is 2.4. > > Thanks for replying > > > On Sat, Mar 23, 2013 at 4:19 AM, Greg Ungerer wrote: > >> Hi Lennart, >> >> On 22/03/13 23:41, Lennart Sorensen wrote: >> > The fact we can recreate the cpio archive and update the uImage from >> > the kernel and cpio archive is great. No recompile crap to deal with >> > the way romfs and such have tended to need. For us building the kernel >> > and the filesystem are totally seperate issues. >> >> I don't follow you here. How does using a ROMfs mean that building >> the kernel and filesystem are not separate? >> >> Regards >> Greg >> >> >> >> _______________________________________________ >> uClinux-dev mailing list >> uClinux-dev at uclinux.org >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by uclinux-dev at uclinux.org >> To unsubscribe see: >> http://mailman.uclinux.org/mailman/options/uclinux-dev >> > > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From engineerphogat at gmail.com Sat Mar 23 23:30:08 2013 From: engineerphogat at gmail.com (Ashish Phogat) Date: Sun, 24 Mar 2013 09:00:08 +0530 Subject: [uClinux-dev] RAM based filesystem in uclinux In-Reply-To: References: <20130322134127.GO1271@csclub.uwaterloo.ca> <514CE001.8030408@westnet.com.au> Message-ID: Thanks that helps a lot..Thanks again.. On Sun, Mar 24, 2013 at 7:55 AM, Steve deRosier wrote: > Ashish, > > With respect, people here have already mentioned a couple of ways. The > most common for non-embedded systems is a initramfs or initrd via a cpio > archive. There's extensive documentation on this in > Documentation/initrd.txt. > > Embedded systems typically _don't_ want a writable root filesystem. > uClinux is typically setup with a romfs, and then a writeable ramfs located > at /var. If you're looking for a space to write temporary files during > runtime, you'd probably want to do so there. Be aware of course that those > go away at reboot. And for that matter, typically the way the initramfs or > initrd work is you may be able to write to them, but on reboot any changes > aren't persisted anyway. > > In my rc file: > /bin/expand /etc/ramfs.img /dev/ram1 > mount -t ext2 /dev/ram1 /var > > There's also tmpfs. You can set one of those up (exist in 2.4??) and mount > on some arbitrary mount point. > > For writable and persisting, you're going to need to use a real filesystem > on some real media, either disk or flash. And if you don't need > persistance, then I don't see why directing your temp files to an already > writable space in /var or /tmp won't work. > > As for the exact configuration settings and all that... well, you're on a > 2.4 kernel and nearly no one is bothering with that kernel anymore. Heck, > I'm working on a 3.2 kernel and someone told me the other day that I'm way > out-of-date. Anyway, since you're on a 2.4 kernel, I certainly don't > remember the specific settings anymore, nor do I have one setup that way > lying around to check for you. You're going to do some looking and some > trial-and-error to figure out the correct settings. But I'd be shocked if > there isn't some legacy how-to out there. And > the aforementioned documentation should be sufficient. > > If you don't have a very compelling reason to stay on a 2.4 kernel you > might want to consider upgrading. Especially if you're starting a new > project. > > I hope that helps, > - Steve > > > > > > On Sat, Mar 23, 2013 at 4:14 PM, Ashish Phogat wrote: > >> Hi, >> Could someone provide me the mechanism/configuration to have a RAM based >> filesystem which is writable? My kernel is 2.4. >> >> Thanks for replying >> >> >> On Sat, Mar 23, 2013 at 4:19 AM, Greg Ungerer > > wrote: >> >>> Hi Lennart, >>> >>> On 22/03/13 23:41, Lennart Sorensen wrote: >>> > The fact we can recreate the cpio archive and update the uImage from >>> > the kernel and cpio archive is great. No recompile crap to deal with >>> > the way romfs and such have tended to need. For us building the kernel >>> > and the filesystem are totally seperate issues. >>> >>> I don't follow you here. How does using a ROMfs mean that building >>> the kernel and filesystem are not separate? >>> >>> Regards >>> Greg >>> >>> >>> >>> _______________________________________________ >>> uClinux-dev mailing list >>> uClinux-dev at uclinux.org >>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >>> This message was resent by uclinux-dev at uclinux.org >>> To unsubscribe see: >>> http://mailman.uclinux.org/mailman/options/uclinux-dev >>> >> >> >> _______________________________________________ >> uClinux-dev mailing list >> uClinux-dev at uclinux.org >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by uclinux-dev at uclinux.org >> To unsubscribe see: >> http://mailman.uclinux.org/mailman/options/uclinux-dev >> > > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregungerer at westnet.com.au Mon Mar 25 03:07:40 2013 From: gregungerer at westnet.com.au (Greg Ungerer) Date: Mon, 25 Mar 2013 17:07:40 +1000 Subject: [uClinux-dev] RAM based filesystem in uclinux In-Reply-To: References: Message-ID: <514FF7BC.9020800@westnet.com.au> Hi Ashish, On 22/03/13 23:28, Ashish Phogat wrote: > Hi folks, > I have some basic problem: > > I have my uclinux currently running on Coldfire board from RAM. I have romfs as my file system but that is read only file system.I donot enable MTD support, blckmem is also disabled. > > I enabled a RAM disk(CONFIG_BLK_DEV_RAM) and initrd(CONFIG_BLK_DEV_INITRD) and choose rootfs as my filesystem. > > > Now I want to change my configuration so that I have a writable filesystem in RAM. > > I am confused with the configurations I need to set to choose a writable file system for uclinux running from RAM. > > What uclinux configuration I need to select to boot uclinux in RAM with writeable filesystem? > > I guess I donot need MTD because that is used for FLASH memory, Neither I need blckmen that is also for FLASH memory. I need to just create a block on RAM and just put a filesystem on that block. > > Please correct me if I am wrong. > > Please also proivde the reason which and why a particular configuration is enabled. What role the config is playing in writeable filesystem? I have done this in the past, using a RAM disk as the root on a ColdFire board. But it has been quite a few years since I last did it. All you should need in the kernel is: CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4192 CONFIG_BLK_DEV_INITRD=y Adjust the CONFIG_BLK_DEV_RAM_SIZE to something that makes sense for you. And you need to enable the filesystem type of course too. So if you are using an ext2 then enable CONFIG_EXT2_FS. You do not require MTD or blkmem drivers in the kernel, do not enable them. The next thing you need to do create your base root filesystem. If using EXT2 for example you will use the genext2fs tool. There is plenty of examples in the uClinux-dist if you grep for it. After all this you need to modify your boot args to pass in the address of the rootfs image in RAM too. From memory you want something like: initrd=0x400000,4M root=/dev/ram0 Regards Greg From lsorense at csclub.uwaterloo.ca Mon Mar 25 12:14:06 2013 From: lsorense at csclub.uwaterloo.ca (Lennart Sorensen) Date: Mon, 25 Mar 2013 12:14:06 -0400 Subject: [uClinux-dev] RAM based filesystem in uclinux In-Reply-To: <514CE001.8030408@westnet.com.au> References: <20130322134127.GO1271@csclub.uwaterloo.ca> <514CE001.8030408@westnet.com.au> Message-ID: <20130325161406.GQ1271@csclub.uwaterloo.ca> On Sat, Mar 23, 2013 at 08:49:37AM +1000, Greg Ungerer wrote: > Hi Lennart, > > On 22/03/13 23:41, Lennart Sorensen wrote: > > The fact we can recreate the cpio archive and update the uImage from > > the kernel and cpio archive is great. No recompile crap to deal with > > the way romfs and such have tended to need. For us building the kernel > > and the filesystem are totally seperate issues. > > I don't follow you here. How does using a ROMfs mean that building > the kernel and filesystem are not separate? Well the way I saw it done when I looked at romfs, was that it was part of the kernel image so you had to do the linking with the romfs files in place to get the kernel image. Can you replace the romfs without using the kernel source tree, with just a vmlinux (or equivelant) file around? -- Len Sorensen From engineerphogat at gmail.com Mon Mar 25 17:47:50 2013 From: engineerphogat at gmail.com (Ashish Phogat) Date: Mon, 25 Mar 2013 17:47:50 -0400 Subject: [uClinux-dev] RAM based filesystem in uclinux In-Reply-To: <20130325161406.GQ1271@csclub.uwaterloo.ca> References: <20130322134127.GO1271@csclub.uwaterloo.ca> <514CE001.8030408@westnet.com.au> <20130325161406.GQ1271@csclub.uwaterloo.ca> Message-ID: hey Thanks Greg, I succeded in doing that. Thank you for your Superb help. Thank you very much again. Thanks Ashish phogat On Mon, Mar 25, 2013 at 12:14 PM, Lennart Sorensen < lsorense at csclub.uwaterloo.ca> wrote: > On Sat, Mar 23, 2013 at 08:49:37AM +1000, Greg Ungerer wrote: > > Hi Lennart, > > > > On 22/03/13 23:41, Lennart Sorensen wrote: > > > The fact we can recreate the cpio archive and update the uImage from > > > the kernel and cpio archive is great. No recompile crap to deal with > > > the way romfs and such have tended to need. For us building the kernel > > > and the filesystem are totally seperate issues. > > > > I don't follow you here. How does using a ROMfs mean that building > > the kernel and filesystem are not separate? > > Well the way I saw it done when I looked at romfs, was that it was part > of the kernel image so you had to do the linking with the romfs files > in place to get the kernel image. > > Can you replace the romfs without using the kernel source tree, with > just a vmlinux (or equivelant) file around? > > -- > Len Sorensen > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From engineerphogat at gmail.com Mon Mar 25 18:03:05 2013 From: engineerphogat at gmail.com (Ashish Phogat) Date: Mon, 25 Mar 2013 18:03:05 -0400 Subject: [uClinux-dev] Ehernet FEC problem in Coldfire M5272C3 Message-ID: Hi, I am facing a very old problem with my Ethernet connection on M5272C3 coldfire board. As soon as my uclinux boots I got the following logs shown below: Command: cat /etc/motd Welcome to ____ _ _ / __| ||_| _ _| | | | _ ____ _ _ _ _ | | | | | | || | _ \| | | |\ \/ / | |_| | |__| || | | | | |_| |/ \ | ___\____|_||_|_| |_|\____|\_/\_/ | | |_| For further information check: http://www.uclinux.org/ Execution Finished, Exiting Sash command shell (version 1.1.1) /> NETDEV WATCHDOG: eth0: transmit timed out eth0: transmit timed out. Ring data dump: cur_tx 321100, dirty_tx 321100 cur_rx: 321000 tx: 16 buffers 00321100: 0000 0012 00000000 00321108: 0000 0816 00000000 00321110: 0000 001a 00000000 00321118: 0000 0c1e 00000000 00321120: 0000 0432 00000000 00321128: 0000 40a6 00000000 00321130: 0000 002a 00000000 00321138: 0000 002e 00000000 00321140: 0000 0032 00000000 00321148: 0000 0036 00000000 00321150: 0000 003a 00000000 rx: 32 buffers 00321000: 8000 0440 00320000 00321008: 8000 0c70 00320800 00321010: 8000 092b 0037f000 00321018: 8000 ff9a 0037f800 00321020: 8000 7fa2 0037e000 00321028: 8000 eda6 0037e800 00321030: 8000 ffa2 0037d000 00321038: 8000 ffa6 0037d800 00321040: 8000 ffb2 0037c000 00321048: 8000 ffb6 0037c800 0032 Spurious interrupt 1 uclinux simply hangs there. I found that there is a large amount of people who are getting the same problem in past couple of years. But I did not get any solution for the problem. Please let me know whether this problem still exists in uclinux source code for M5272C3. where I will find the solution for that? My Ethernet Hardware Info: fec.c: Probe number 1 with 0x0000 eth0: FEC ENET Version 0.2, 00:e0:0c:bc:e5:60 fec: PHY @ 0x1, ID 0x0022561b -- AM79C874 Thanks and Appreciated for your help. Thanks Ashish Phogat -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregungerer at westnet.com.au Mon Mar 25 21:45:57 2013 From: gregungerer at westnet.com.au (Greg Ungerer) Date: Tue, 26 Mar 2013 11:45:57 +1000 Subject: [uClinux-dev] RAM based filesystem in uclinux In-Reply-To: <20130325161406.GQ1271@csclub.uwaterloo.ca> References: <20130322134127.GO1271@csclub.uwaterloo.ca> <514CE001.8030408@westnet.com.au> <20130325161406.GQ1271@csclub.uwaterloo.ca> Message-ID: <5150FDD5.90605@westnet.com.au> On 26/03/13 02:14, Lennart Sorensen wrote: > On Sat, Mar 23, 2013 at 08:49:37AM +1000, Greg Ungerer wrote: >> Hi Lennart, >> >> On 22/03/13 23:41, Lennart Sorensen wrote: >>> The fact we can recreate the cpio archive and update the uImage from >>> the kernel and cpio archive is great. No recompile crap to deal with >>> the way romfs and such have tended to need. For us building the kernel >>> and the filesystem are totally seperate issues. >> >> I don't follow you here. How does using a ROMfs mean that building >> the kernel and filesystem are not separate? > > Well the way I saw it done when I looked at romfs, was that it was part > of the kernel image so you had to do the linking with the romfs files > in place to get the kernel image. > > Can you replace the romfs without using the kernel source tree, with > just a vmlinux (or equivelant) file around? Yes. On many occasions I have mixed various kernel binary and romfs images when testing regressions. It's so easy the way we do this on ColdFire, I just "cat" them together. Regards Greg From gregungerer at westnet.com.au Mon Mar 25 21:48:18 2013 From: gregungerer at westnet.com.au (Greg Ungerer) Date: Tue, 26 Mar 2013 11:48:18 +1000 Subject: [uClinux-dev] Ehernet FEC problem in Coldfire M5272C3 In-Reply-To: References: Message-ID: <5150FE62.1070904@westnet.com.au> Hi Ashish, On 26/03/13 08:03, Ashish Phogat wrote: > I am facing a very old problem with my Ethernet connection on M5272C3 coldfire board. As soon as my uclinux boots I got the following logs shown below: What version of kernel? What version of uClinux-dist? Regards Greg > Command: cat /etc/motd > Welcome to > ____ _ _ > / __| ||_| > _ _| | | | _ ____ _ _ _ _ > | | | | | | || | _ \| | | |\ \/ / > | |_| | |__| || | | | | |_| |/ \ > | ___\____|_||_|_| |_|\____|\_/\_/ > | | > |_| > > For further information check: > http://www.uclinux.org/ > > Execution Finished, Exiting > > Sash command shell (version 1.1.1) > > /> NETDEV WATCHDOG: eth0: transmit timed out > eth0: transmit timed out. > Ring data dump: cur_tx 321100, dirty_tx 321100 cur_rx: 321000 > tx: 16 buffers > 00321100: 0000 0012 00000000 > 00321108: 0000 0816 00000000 > 00321110: 0000 001a 00000000 > 00321118: 0000 0c1e 00000000 > 00321120: 0000 0432 00000000 > 00321128: 0000 40a6 00000000 > 00321130: 0000 002a 00000000 > 00321138: 0000 002e 00000000 > 00321140: 0000 0032 00000000 > 00321148: 0000 0036 00000000 > 00321150: 0000 003a 00000000 > > rx: 32 buffers > 00321000: 8000 0440 00320000 > 00321008: 8000 0c70 00320800 > 00321010: 8000 092b 0037f000 > 00321018: 8000 ff9a 0037f800 > 00321020: 8000 7fa2 0037e000 > 00321028: 8000 eda6 0037e800 > 00321030: 8000 ffa2 0037d000 > 00321038: 8000 ffa6 0037d800 > 00321040: 8000 ffb2 0037c000 > 00321048: 8000 ffb6 0037c800 > 0032 > > Spurious interrupt 1 > > > uclinux simply hangs there. I found that there is a large amount of people who are getting the same problem in past couple of years. But I did not get any solution for the problem. > > Please let me know whether this problem still exists in uclinux source code for M5272C3. where I will find the solution for that? > > My Ethernet Hardware Info: > fec.c: Probe number 1 with 0x0000 > eth0: FEC ENET Version 0.2, 00:e0:0c:bc:e5:60 > fec: PHY @ 0x1, ID 0x0022561b -- AM79C874 > > Thanks and Appreciated for your help. > > Thanks > Ashish Phogat > > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > From christiangieseler at yahoo.de Tue Mar 26 02:54:30 2013 From: christiangieseler at yahoo.de (Christian Gieseler) Date: Tue, 26 Mar 2013 07:54:30 +0100 Subject: [uClinux-dev] Initial Timer on m5329 not running Message-ID: <000f01ce29ee$c43165d0$4c943170$@yahoo.de> Hi List, Coldfire 5329 seems not be used with latest kernels. The Main Timer is not running, so the scheduler won?t behave like expected. To change this the following change has to be done in m532x.c arch setup. There is probably more to be fixed. diff git a/Linux3.6.11/arch/m68k/platform/coldfire/m532x.c b/Linux3.6.11/arch/m68k/platform/coldfire/m532x.c --- a/Linux3.6.11/arch/m68k/platform/coldfire/m532x.c +++ b/Linux3.6.11/arch/m68k/platform/coldfire/m532x.c @@ 120,6 +120,8 @@ static struct clk * const enable_clks[] __initconst = { &__clk_0_25, /* mcfuart.1 */ &__clk_0_26, /* mcfuart.2 */ + &__clk_0_28, /* mcftmr.0 */ + &__clk_0_29, /* mcftmr.1 */ &__clk_0_32, /* mcfpit.0 */ &__clk_0_33, /* mcfpit.1 */ &__clk_0_37, /* mcfeport.0 */ @@ 135,8 +137,6 @@ static struct clk * const disable_clks[] __initconst = { &__clk_0_17, /* edma */ &__clk_0_22, /* mcfi2c.0 */ &__clk_0_23, /* mcfqspi.0 */ - &__clk_0_28, /* mcftmr.0 */ - &__clk_0_29, /* mcftmr.1 */ &__clk_0_30, /* mcftmr.2 */ &__clk_0_31, /* mcftmr.3 */ &__clk_0_34, /* mcfpit.2 */ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lsorense at csclub.uwaterloo.ca Tue Mar 26 10:08:10 2013 From: lsorense at csclub.uwaterloo.ca (Lennart Sorensen) Date: Tue, 26 Mar 2013 10:08:10 -0400 Subject: [uClinux-dev] RAM based filesystem in uclinux In-Reply-To: <5150FDD5.90605@westnet.com.au> References: <20130322134127.GO1271@csclub.uwaterloo.ca> <514CE001.8030408@westnet.com.au> <20130325161406.GQ1271@csclub.uwaterloo.ca> <5150FDD5.90605@westnet.com.au> Message-ID: <20130326140810.GU1271@csclub.uwaterloo.ca> On Tue, Mar 26, 2013 at 11:45:57AM +1000, Greg Ungerer wrote: > Yes. On many occasions I have mixed various kernel binary and romfs > images when testing regressions. It's so easy the way we do this on > ColdFire, I just "cat" them together. Well that does sound pretty easy. The kernel config for romfs made it sound a lot more complicated than that. I will stick with initramfs though since it works nicely, and having r/w access is sometimes useful when debuging things. initramfs does seem to lack execute in place which I highly suspect works on romfs, even though there doesn't appear to be any reason it shouldn't work for initramfs. -- Len Sorensen From engineerphogat at gmail.com Tue Mar 26 16:12:09 2013 From: engineerphogat at gmail.com (Ashish Phogat) Date: Tue, 26 Mar 2013 16:12:09 -0400 Subject: [uClinux-dev] Fwd: Ehernet FEC problem in Coldfire M5272C3 In-Reply-To: References: <5150FE62.1070904@westnet.com.au> Message-ID: ---------- Forwarded message ---------- From: Ashish Phogat Date: Tue, Mar 26, 2013 at 8:46 AM Subject: Re: [uClinux-dev] Ehernet FEC problem in Coldfire M5272C3 To: Greg Ungerer Hi, My Kernel is 2.4.34.5 and uClinux-dist is uClinux-dist-20120401.tar.bz2. Thanks for Replying. Thanks Ashish Phogat On Mon, Mar 25, 2013 at 9:48 PM, Greg Ungerer wrote: > Hi Ashish, > > On 26/03/13 08:03, Ashish Phogat wrote: > > I am facing a very old problem with my Ethernet connection on M5272C3 > coldfire board. As soon as my uclinux boots I got the following logs shown > below: > > What version of kernel? > What version of uClinux-dist? > > Regards > Greg > > > > > Command: cat /etc/motd > > Welcome to > > ____ _ _ > > / __| ||_| > > _ _| | | | _ ____ _ _ _ _ > > | | | | | | || | _ \| | | |\ \/ / > > | |_| | |__| || | | | | |_| |/ \ > > | ___\____|_||_|_| |_|\____|\_/\_/ > > | | > > |_| > > > > For further information check: > > http://www.uclinux.org/ > > > > Execution Finished, Exiting > > > > Sash command shell (version 1.1.1) > > > > /> NETDEV WATCHDOG: eth0: transmit timed out > > eth0: transmit timed out. > > Ring data dump: cur_tx 321100, dirty_tx 321100 cur_rx: 321000 > > tx: 16 buffers > > 00321100: 0000 0012 00000000 > > 00321108: 0000 0816 00000000 > > 00321110: 0000 001a 00000000 > > 00321118: 0000 0c1e 00000000 > > 00321120: 0000 0432 00000000 > > 00321128: 0000 40a6 00000000 > > 00321130: 0000 002a 00000000 > > 00321138: 0000 002e 00000000 > > 00321140: 0000 0032 00000000 > > 00321148: 0000 0036 00000000 > > 00321150: 0000 003a 00000000 > > > > rx: 32 buffers > > 00321000: 8000 0440 00320000 > > 00321008: 8000 0c70 00320800 > > 00321010: 8000 092b 0037f000 > > 00321018: 8000 ff9a 0037f800 > > 00321020: 8000 7fa2 0037e000 > > 00321028: 8000 eda6 0037e800 > > 00321030: 8000 ffa2 0037d000 > > 00321038: 8000 ffa6 0037d800 > > 00321040: 8000 ffb2 0037c000 > > 00321048: 8000 ffb6 0037c800 > > 0032 > > > > Spurious interrupt 1 > > > > > > uclinux simply hangs there. I found that there is a large amount of > people who are getting the same problem in past couple of years. But I did > not get any solution for the problem. > > > > Please let me know whether this problem still exists in uclinux source > code for M5272C3. where I will find the solution for that? > > > > My Ethernet Hardware Info: > > fec.c: Probe number 1 with 0x0000 > > eth0: FEC ENET Version 0.2, 00:e0:0c:bc:e5:60 > > fec: PHY @ 0x1, ID 0x0022561b -- AM79C874 > > > > Thanks and Appreciated for your help. > > > > Thanks > > Ashish Phogat > > > > > > _______________________________________________ > > uClinux-dev mailing list > > uClinux-dev at uclinux.org > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > > This message was resent by uclinux-dev at uclinux.org > > To unsubscribe see: > > http://mailman.uclinux.org/mailman/options/uclinux-dev > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From engineerphogat at gmail.com Wed Mar 27 08:54:14 2013 From: engineerphogat at gmail.com (Ashish Phogat) Date: Wed, 27 Mar 2013 08:54:14 -0400 Subject: [uClinux-dev] Fwd: Ehernet FEC problem in Coldfire M5272C3 In-Reply-To: <5152DE4F.2080504@gmail.com> References: <5150FE62.1070904@westnet.com.au> <5152DE4F.2080504@gmail.com> Message-ID: Hi Greg, When I did cat proc/interrupts: /> cat /proc/interrupts 66: 0 fec(MII) 72: 3393 ColdFire Timer 73: 1084 ColdFire UART 74: 0 ColdFire UART 77: 0 ColdFire USB (EP0) 78: 0 ColdFire USB (EP1) 79: 0 ColdFire USB (EP2) 80: 0 ColdFire USB (EP3) 81: 0 ColdFire USB (EP4) 82: 0 ColdFire USB (EP5) 83: 0 ColdFire USB (EP6) 84: 0 ColdFire USB (EP7) 86: 0 fec(RX) 87: 0 fec(TX) 88: 13 fec(OTHER) 89: 0 ColdFire QSPI Thanks Ashish phogat On Wed, Mar 27, 2013 at 7:55 AM, Greg Ungerer wrote: > Hi Ashish, > > On 27/03/13 06:12, Ashish Phogat wrote: > > My Kernel is 2.4.34.5 and uClinux-dist is uClinux-dist-20120401.tar.bz2. > > Ok. I haven't run 2.4 kernels for a long time... but some comments > below. > > > > > /> NETDEV WATCHDOG: eth0: transmit timed out > > > eth0: transmit timed out. > > > Ring data dump: cur_tx 321100, dirty_tx 321100 cur_rx: 321000 > > > tx: 16 buffers > > > 00321100: 0000 0012 00000000 > > > 00321108: 0000 0816 00000000 > > > 00321110: 0000 001a 00000000 > > > 00321118: 0000 0c1e 00000000 > > > 00321120: 0000 0432 00000000 > > > 00321128: 0000 40a6 00000000 > > > 00321130: 0000 002a 00000000 > > > 00321138: 0000 002e 00000000 > > > 00321140: 0000 0032 00000000 > > > 00321148: 0000 0036 00000000 > > > 00321150: 0000 003a 00000000 > > > > > > rx: 32 buffers > > > 00321000: 8000 0440 00320000 > > > 00321008: 8000 0c70 00320800 > > > 00321010: 8000 092b 0037f000 > > > 00321018: 8000 ff9a 0037f800 > > > 00321020: 8000 7fa2 0037e000 > > > 00321028: 8000 eda6 0037e800 > > > 00321030: 8000 ffa2 0037d000 > > > 00321038: 8000 ffa6 0037d800 > > > 00321040: 8000 ffb2 0037c000 > > > 00321048: 8000 ffb6 0037c800 > > > 0032 > > > > > > Spurious interrupt 1 > > Together this looks like an interrupt issue. What do you see > if you "cat /proc/interrupts"? > > Regards > Greg > > > > > > > > uclinux simply hangs there. I found that there is a large amount > > of people who are getting the same problem in past couple of years. > > But I did not get any solution for the problem. > > > > > > Please let me know whether this problem still exists in uclinux > > source code for M5272C3. where I will find the solution for that? > > > > > > My Ethernet Hardware Info: > > > fec.c: Probe number 1 with 0x0000 > > > eth0: FEC ENET Version 0.2, 00:e0:0c:bc:e5:60 > > > fec: PHY @ 0x1, ID 0x0022561b -- AM79C874 > > > > > > Thanks and Appreciated for your help. > > > > > > Thanks > > > Ashish Phogat > > > > > > > > > _______________________________________________ > > > uClinux-dev mailing list > > > uClinux-dev at uclinux.org > > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > > > This message was resent by uclinux-dev at uclinux.org > > > > > To unsubscribe see: > > > http://mailman.uclinux.org/mailman/options/uclinux-dev > > > > > > > > > > > > > > > _______________________________________________ > > uClinux-dev mailing list > > uClinux-dev at uclinux.org > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > > This message was resent by uclinux-dev at uclinux.org > > To unsubscribe see: > > http://mailman.uclinux.org/mailman/options/uclinux-dev > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From natarajan.naga at gmail.com Wed Mar 27 23:13:23 2013 From: natarajan.naga at gmail.com (Natarajan BLR) Date: Thu, 28 Mar 2013 08:43:23 +0530 Subject: [uClinux-dev] Fwd: Ehernet FEC problem in Coldfire M5272C3 In-Reply-To: References: <5150FE62.1070904@westnet.com.au> <5152DE4F.2080504@gmail.com> Message-ID: hat yourself, Mami and children are doing good. How is Mahesh doing? I await zawaiting the dispatch of this book . I will come back to you soon after reading. You may send me the file (WORD???) should you want me do DTP Work. Regards Natarajan On Wed, Mar 27, 2013 at 6:24 PM, Ashish Phogat wrote: > Hi Greg, > When I did cat proc/interrupts: > > /> cat /proc/interrupts > 66: 0 fec(MII) > 72: 3393 ColdFire Timer > 73: 1084 ColdFire UART > 74: 0 ColdFire UART > 77: 0 ColdFire USB (EP0) > 78: 0 ColdFire USB (EP1) > 79: 0 ColdFire USB (EP2) > 80: 0 ColdFire USB (EP3) > 81: 0 ColdFire USB (EP4) > 82: 0 ColdFire USB (EP5) > 83: 0 ColdFire USB (EP6) > 84: 0 ColdFire USB (EP7) > 86: 0 fec(RX) > 87: 0 fec(TX) > 88: 13 fec(OTHER) > 89: 0 ColdFire QSPI > > Thanks > Ashish phogat > > On Wed, Mar 27, 2013 at 7:55 AM, Greg Ungerer wrote: > >> Hi Ashish, >> >> On 27/03/13 06:12, Ashish Phogat wrote: >> > My Kernel is 2.4.34.5 and uClinux-dist is uClinux-dist-20120401.tar.bz2. >> >> Ok. I haven't run 2.4 kernels for a long time... but some comments >> below. >> >> >> > > /> NETDEV WATCHDOG: eth0: transmit timed out >> > > eth0: transmit timed out. >> > > Ring data dump: cur_tx 321100, dirty_tx 321100 cur_rx: 321000 >> > > tx: 16 buffers >> > > 00321100: 0000 0012 00000000 >> > > 00321108: 0000 0816 00000000 >> > > 00321110: 0000 001a 00000000 >> > > 00321118: 0000 0c1e 00000000 >> > > 00321120: 0000 0432 00000000 >> > > 00321128: 0000 40a6 00000000 >> > > 00321130: 0000 002a 00000000 >> > > 00321138: 0000 002e 00000000 >> > > 00321140: 0000 0032 00000000 >> > > 00321148: 0000 0036 00000000 >> > > 00321150: 0000 003a 00000000 >> > > >> > > rx: 32 buffers >> > > 00321000: 8000 0440 00320000 >> > > 00321008: 8000 0c70 00320800 >> > > 00321010: 8000 092b 0037f000 >> > > 00321018: 8000 ff9a 0037f800 >> > > 00321020: 8000 7fa2 0037e000 >> > > 00321028: 8000 eda6 0037e800 >> > > 00321030: 8000 ffa2 0037d000 >> > > 00321038: 8000 ffa6 0037d800 >> > > 00321040: 8000 ffb2 0037c000 >> > > 00321048: 8000 ffb6 0037c800 >> > > 0032 >> > > >> > > Spurious interrupt 1 >> >> Together this looks like an interrupt issue. What do you see >> if you "cat /proc/interrupts"? >> >> Regards >> Greg >> >> >> > > >> > > uclinux simply hangs there. I found that there is a large amount >> > of people who are getting the same problem in past couple of years. >> > But I did not get any solution for the problem. >> > > >> > > Please let me know whether this problem still exists in uclinux >> > source code for M5272C3. where I will find the solution for that? >> > > >> > > My Ethernet Hardware Info: >> > > fec.c: Probe number 1 with 0x0000 >> > > eth0: FEC ENET Version 0.2, 00:e0:0c:bc:e5:60 >> > > fec: PHY @ 0x1, ID 0x0022561b -- AM79C874 >> > > >> > > Thanks and Appreciated for your help. >> > > >> > > Thanks >> > > Ashish Phogat >> > > >> > > >> > > _______________________________________________ >> > > uClinux-dev mailing list >> > > uClinux-dev at uclinux.org >> > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> > > This message was resent by uclinux-dev at uclinux.org >> > >> > > To unsubscribe see: >> > > http://mailman.uclinux.org/mailman/options/uclinux-dev >> > > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > uClinux-dev mailing list >> > uClinux-dev at uclinux.org >> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> > This message was resent by uclinux-dev at uclinux.org >> > To unsubscribe see: >> > http://mailman.uclinux.org/mailman/options/uclinux-dev >> > >> >> > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > -- N Natarajan http://science-of-good-living.blogspot.com/ http://science-of-spirituality.blogspot.com/ http://sprituality-is-knowledge.blogspot.in/2011/09/stories-that-explain-knowledge.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.pluess at stud.hslu.ch Thu Mar 28 04:27:44 2013 From: tobias.pluess at stud.hslu.ch (=?iso-8859-1?Q?Pl=FCss_Tobias_TA=2EE=2E1001?=) Date: Thu, 28 Mar 2013 08:27:44 +0000 Subject: [uClinux-dev] Porting uClinux to a specific board Message-ID: <38F83949ED76A946BE17B6F2F98F362E0B32A7@MX33.campus.intern> Hi guys I would like to use uClinux on an ARM7 board which I built by myself. It contains a NXP LPC2468 processor and uses external FLASH (8M) and SDRAM (64M), which I think should be enough memory for uClinux. Okay, what I did so far is to download the Kernel sources (3.8.4, I would like to use recent Kernel). Then, I created my mach-lpc2468 folder and created various C-files for my hardware specific stuff. I also created a machine record, but I don't exactly know, what data has to be in there, and I don't exactly know what to do with the interrupt controller and stuff. Anyway, my Kernel compiles now, but of course, it does not yet work correctly, but I hope somebody can help me with the machine record and the device tree. Many thanks in advance! From engineerphogat at gmail.com Thu Mar 28 07:57:37 2013 From: engineerphogat at gmail.com (Ashish Phogat) Date: Thu, 28 Mar 2013 07:57:37 -0400 Subject: [uClinux-dev] Fwd: Ehernet FEC problem in Coldfire M5272C3 In-Reply-To: References: <5150FE62.1070904@westnet.com.au> <5152DE4F.2080504@gmail.com> Message-ID: Hi Greg, I had a look at all the patches made for M5272C3 in cvs.org for kernel 2.4.x in last couple of years. It seems all patches are included in my distribution (uClinux-dist-20120401.tar.bz2). I don't have idea why this error NETDEV WATCHDOG is still coming. I am running at 50Mhz clock frequency. Is there any problem with frequency? Thanks Ashish Phogat > On Wed, Mar 27, 2013 at 6:24 PM, Ashish Phogat wrote: > >> Hi Greg, >> When I did cat proc/interrupts: >> >> /> cat /proc/interrupts >> 66: 0 fec(MII) >> 72: 3393 ColdFire Timer >> 73: 1084 ColdFire UART >> 74: 0 ColdFire UART >> 77: 0 ColdFire USB (EP0) >> 78: 0 ColdFire USB (EP1) >> 79: 0 ColdFire USB (EP2) >> 80: 0 ColdFire USB (EP3) >> 81: 0 ColdFire USB (EP4) >> 82: 0 ColdFire USB (EP5) >> 83: 0 ColdFire USB (EP6) >> 84: 0 ColdFire USB (EP7) >> 86: 0 fec(RX) >> 87: 0 fec(TX) >> 88: 13 fec(OTHER) >> 89: 0 ColdFire QSPI >> >> Thanks >> Ashish phogat >> >> On Wed, Mar 27, 2013 at 7:55 AM, Greg Ungerer wrote: >> >>> Hi Ashish, >>> >>> On 27/03/13 06:12, Ashish Phogat wrote: >>> > My Kernel is 2.4.34.5 and uClinux-dist is >>> uClinux-dist-20120401.tar.bz2. >>> >>> Ok. I haven't run 2.4 kernels for a long time... but some comments >>> below. >>> >>> >>> > > /> NETDEV WATCHDOG: eth0: transmit timed out >>> > > eth0: transmit timed out. >>> > > Ring data dump: cur_tx 321100, dirty_tx 321100 cur_rx: 321000 >>> > > tx: 16 buffers >>> > > 00321100: 0000 0012 00000000 >>> > > 00321108: 0000 0816 00000000 >>> > > 00321110: 0000 001a 00000000 >>> > > 00321118: 0000 0c1e 00000000 >>> > > 00321120: 0000 0432 00000000 >>> > > 00321128: 0000 40a6 00000000 >>> > > 00321130: 0000 002a 00000000 >>> > > 00321138: 0000 002e 00000000 >>> > > 00321140: 0000 0032 00000000 >>> > > 00321148: 0000 0036 00000000 >>> > > 00321150: 0000 003a 00000000 >>> > > >>> > > rx: 32 buffers >>> > > 00321000: 8000 0440 00320000 >>> > > 00321008: 8000 0c70 00320800 >>> > > 00321010: 8000 092b 0037f000 >>> > > 00321018: 8000 ff9a 0037f800 >>> > > 00321020: 8000 7fa2 0037e000 >>> > > 00321028: 8000 eda6 0037e800 >>> > > 00321030: 8000 ffa2 0037d000 >>> > > 00321038: 8000 ffa6 0037d800 >>> > > 00321040: 8000 ffb2 0037c000 >>> > > 00321048: 8000 ffb6 0037c800 >>> > > 0032 >>> > > >>> > > Spurious interrupt 1 >>> >>> Together this looks like an interrupt issue. What do you see >>> if you "cat /proc/interrupts"? >>> >>> Regards >>> Greg >>> >>> >>> > > >>> > > uclinux simply hangs there. I found that there is a large amount >>> > of people who are getting the same problem in past couple of years. >>> > But I did not get any solution for the problem. >>> > > >>> > > Please let me know whether this problem still exists in uclinux >>> > source code for M5272C3. where I will find the solution for that? >>> > > >>> > > My Ethernet Hardware Info: >>> > > fec.c: Probe number 1 with 0x0000 >>> > > eth0: FEC ENET Version 0.2, 00:e0:0c:bc:e5:60 >>> > > fec: PHY @ 0x1, ID 0x0022561b -- AM79C874 >>> > > >>> > > Thanks and Appreciated for your help. >>> > > >>> > > Thanks >>> > > Ashish Phogat >>> > > >>> > > >>> > > _______________________________________________ >>> > > uClinux-dev mailing list >>> > > uClinux-dev at uclinux.org >>> > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >>> > > This message was resent by uclinux-dev at uclinux.org >>> > >>> > > To unsubscribe see: >>> > > http://mailman.uclinux.org/mailman/options/uclinux-dev >>> > > >>> > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > uClinux-dev mailing list >>> > uClinux-dev at uclinux.org >>> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >>> > This message was resent by uclinux-dev at uclinux.org >>> > To unsubscribe see: >>> > http://mailman.uclinux.org/mailman/options/uclinux-dev >>> > >>> >>> >> >> _______________________________________________ >> uClinux-dev mailing list >> uClinux-dev at uclinux.org >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by uclinux-dev at uclinux.org >> To unsubscribe see: >> http://mailman.uclinux.org/mailman/options/uclinux-dev >> > > > > -- > N Natarajan > http://science-of-good-living.blogspot.com/ > http://science-of-spirituality.blogspot.com/ > > http://sprituality-is-knowledge.blogspot.in/2011/09/stories-that-explain-knowledge.html > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregungerer at westnet.com.au Thu Mar 28 08:22:51 2013 From: gregungerer at westnet.com.au (Greg Ungerer) Date: Thu, 28 Mar 2013 22:22:51 +1000 Subject: [uClinux-dev] Fwd: Ehernet FEC problem in Coldfire M5272C3 In-Reply-To: References: <5150FE62.1070904@westnet.com.au> <5152DE4F.2080504@gmail.com> Message-ID: <5154361B.6080508@westnet.com.au> Hi Ashish, On 28/03/13 21:57, Ashish Phogat wrote: > I had a look at all the patches made for M5272C3 in cvs.org > for kernel 2.4.x in last couple of years. It seems all > patches are included in my distribution (uClinux-dist-20120401.tar.bz2). > I don't have idea why this error NETDEV WATCHDOG is still coming. I am > running at 50Mhz clock frequency. Is there any problem with frequency? No, I don't think that will cause you any problems. >From the interrupt count it doesn't look like you are getting any TX interrupts from the FEC. This will cause the NETDEV WATCHDOG to eventually timeout and you get the kernel trace you see. You are getting "other" interrupts from the FEC - I think you should add some trace and see what those are. Maybe they will give some clues. Regards Greg > On Wed, Mar 27, 2013 at 6:24 PM, Ashish Phogat > > wrote: > > Hi Greg, > When I did cat proc/interrupts: > > /> cat /proc/interrupts > 66: 0 fec(MII) > 72: 3393 ColdFire Timer > 73: 1084 ColdFire UART > 74: 0 ColdFire UART > 77: 0 ColdFire USB (EP0) > 78: 0 ColdFire USB (EP1) > 79: 0 ColdFire USB (EP2) > 80: 0 ColdFire USB (EP3) > 81: 0 ColdFire USB (EP4) > 82: 0 ColdFire USB (EP5) > 83: 0 ColdFire USB (EP6) > 84: 0 ColdFire USB (EP7) > 86: 0 fec(RX) > 87: 0 fec(TX) > 88: 13 fec(OTHER) > 89: 0 ColdFire QSPI > > Thanks > Ashish phogat > > On Wed, Mar 27, 2013 at 7:55 AM, Greg Ungerer > > wrote: > > Hi Ashish, > > On 27/03/13 06:12, Ashish Phogat wrote: > > My Kernel is 2.4.34.5 and uClinux-dist is > uClinux-dist-20120401.tar.bz2. > > Ok. I haven't run 2.4 kernels for a long time... but some > comments > below. > > > > > /> NETDEV WATCHDOG: eth0: transmit timed out > > > eth0: transmit timed out. > > > Ring data dump: cur_tx 321100, dirty_tx 321100 > cur_rx: 321000 > > > tx: 16 buffers > > > 00321100: 0000 0012 00000000 > > > 00321108: 0000 0816 00000000 > > > 00321110: 0000 001a 00000000 > > > 00321118: 0000 0c1e 00000000 > > > 00321120: 0000 0432 00000000 > > > 00321128: 0000 40a6 00000000 > > > 00321130: 0000 002a 00000000 > > > 00321138: 0000 002e 00000000 > > > 00321140: 0000 0032 00000000 > > > 00321148: 0000 0036 00000000 > > > 00321150: 0000 003a 00000000 > > > > > > rx: 32 buffers > > > 00321000: 8000 0440 00320000 > > > 00321008: 8000 0c70 00320800 > > > 00321010: 8000 092b 0037f000 > > > 00321018: 8000 ff9a 0037f800 > > > 00321020: 8000 7fa2 0037e000 > > > 00321028: 8000 eda6 0037e800 > > > 00321030: 8000 ffa2 0037d000 > > > 00321038: 8000 ffa6 0037d800 > > > 00321040: 8000 ffb2 0037c000 > > > 00321048: 8000 ffb6 0037c800 > > > 0032 > > > > > > Spurious interrupt 1 > > Together this looks like an interrupt issue. What do you see > if you "cat /proc/interrupts"? > > Regards > Greg > > > > > > > > uclinux simply hangs there. I found that there is a > large amount > > of people who are getting the same problem in past > couple of years. > > But I did not get any solution for the problem. > > > > > > Please let me know whether this problem still exists > in uclinux > > source code for M5272C3. where I will find the > solution for that? > > > > > > My Ethernet Hardware Info: > > > fec.c: Probe number 1 with 0x0000 > > > eth0: FEC ENET Version 0.2, 00:e0:0c:bc:e5:60 > > > fec: PHY @ 0x1, ID 0x0022561b -- AM79C874 > > > > > > Thanks and Appreciated for your help. > > > > > > Thanks > > > Ashish Phogat > > > > > > > > > _______________________________________________ > > > uClinux-dev mailing list > > > uClinux-dev at uclinux.org > > > > > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > > > This message was resent by uclinux-dev at uclinux.org > > > > > > > To unsubscribe see: > > > http://mailman.uclinux.org/mailman/options/uclinux-dev > > > > > > > > > > > > > > > _______________________________________________ > > uClinux-dev mailing list > > uClinux-dev at uclinux.org > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > > This message was resent by uclinux-dev at uclinux.org > > > To unsubscribe see: > > http://mailman.uclinux.org/mailman/options/uclinux-dev > > > > > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > > > > > -- > N Natarajan > http://science-of-good-living.blogspot.com/ > http://science-of-spirituality.blogspot.com/ > http://sprituality-is-knowledge.blogspot.in/2011/09/stories-that-explain-knowledge.html > > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > > > > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > From lsorense at csclub.uwaterloo.ca Thu Mar 28 10:23:40 2013 From: lsorense at csclub.uwaterloo.ca (Lennart Sorensen) Date: Thu, 28 Mar 2013 10:23:40 -0400 Subject: [uClinux-dev] Porting uClinux to a specific board In-Reply-To: <38F83949ED76A946BE17B6F2F98F362E0B32A7@MX33.campus.intern> References: <38F83949ED76A946BE17B6F2F98F362E0B32A7@MX33.campus.intern> Message-ID: <20130328142340.GC21768@csclub.uwaterloo.ca> On Thu, Mar 28, 2013 at 08:27:44AM +0000, Pl?ss Tobias TA.E.1001 wrote: > I would like to use uClinux on an ARM7 board which I built by myself. It contains a NXP LPC2468 processor and uses external FLASH (8M) and SDRAM (64M), which I think should be enough memory for uClinux. > Okay, what I did so far is to download the Kernel sources (3.8.4, I would like to use recent Kernel). Then, I created my mach-lpc2468 folder and created various C-files for my hardware specific stuff. > I also created a machine record, but I don't exactly know, what data has to be in there, and I don't exactly know what to do with the interrupt controller and stuff. > Anyway, my Kernel compiles now, but of course, it does not yet work correctly, but I hope somebody can help me with the machine record and the device tree. It looks like someone already did uclinux for that CPU some years ago: http://mailman.uclinux.org/pipermail/uclinux-dev/2007-May/042858.html Maybe those patches would be helpful. -- Len Sorensen From engineerphogat at gmail.com Thu Mar 28 13:15:31 2013 From: engineerphogat at gmail.com (Ashish Phogat) Date: Thu, 28 Mar 2013 13:15:31 -0400 Subject: [uClinux-dev] Fwd: Ehernet FEC problem in Coldfire M5272C3 In-Reply-To: <5154361B.6080508@westnet.com.au> References: <5150FE62.1070904@westnet.com.au> <5152DE4F.2080504@gmail.com> <5154361B.6080508@westnet.com.au> Message-ID: Hi Greg, I am sorry I am new to linux...I donot know how to add traces. Could you please help me with that? Meanwhile I am trying to add few utilities in my uclinux such as mii-tool-fec, traceroute or ethtool. Lets see how much I am able to debug or get more information. Thanks for your help. Thanks Ashish Phogat On Thu, Mar 28, 2013 at 8:22 AM, Greg Ungerer wrote: > Hi Ashish, > > On 28/03/13 21:57, Ashish Phogat wrote: > > I had a look at all the patches made for M5272C3 in cvs.org > > for kernel 2.4.x in last couple of years. It seems all > > patches are included in my distribution (uClinux-dist-20120401.tar.bz2). > > I don't have idea why this error NETDEV WATCHDOG is still coming. I am > > running at 50Mhz clock frequency. Is there any problem with frequency? > > No, I don't think that will cause you any problems. > > From the interrupt count it doesn't look like you are getting any TX > interrupts from the FEC. This will cause the NETDEV WATCHDOG to > eventually timeout and you get the kernel trace you see. > > You are getting "other" interrupts from the FEC - I think you should > add some trace and see what those are. Maybe they will give some > clues. > > Regards > Greg > > > > On Wed, Mar 27, 2013 at 6:24 PM, Ashish Phogat > > > wrote: > > > > Hi Greg, > > When I did cat proc/interrupts: > > > > /> cat /proc/interrupts > > 66: 0 fec(MII) > > 72: 3393 ColdFire Timer > > 73: 1084 ColdFire UART > > 74: 0 ColdFire UART > > 77: 0 ColdFire USB (EP0) > > 78: 0 ColdFire USB (EP1) > > 79: 0 ColdFire USB (EP2) > > 80: 0 ColdFire USB (EP3) > > 81: 0 ColdFire USB (EP4) > > 82: 0 ColdFire USB (EP5) > > 83: 0 ColdFire USB (EP6) > > 84: 0 ColdFire USB (EP7) > > 86: 0 fec(RX) > > 87: 0 fec(TX) > > 88: 13 fec(OTHER) > > 89: 0 ColdFire QSPI > > > > Thanks > > Ashish phogat > > > > On Wed, Mar 27, 2013 at 7:55 AM, Greg Ungerer > > > > wrote: > > > > Hi Ashish, > > > > On 27/03/13 06:12, Ashish Phogat wrote: > > > My Kernel is 2.4.34.5 and uClinux-dist is > > uClinux-dist-20120401.tar.bz2. > > > > Ok. I haven't run 2.4 kernels for a long time... but some > > comments > > below. > > > > > > > > /> NETDEV WATCHDOG: eth0: transmit timed out > > > > eth0: transmit timed out. > > > > Ring data dump: cur_tx 321100, dirty_tx 321100 > > cur_rx: 321000 > > > > tx: 16 buffers > > > > 00321100: 0000 0012 00000000 > > > > 00321108: 0000 0816 00000000 > > > > 00321110: 0000 001a 00000000 > > > > 00321118: 0000 0c1e 00000000 > > > > 00321120: 0000 0432 00000000 > > > > 00321128: 0000 40a6 00000000 > > > > 00321130: 0000 002a 00000000 > > > > 00321138: 0000 002e 00000000 > > > > 00321140: 0000 0032 00000000 > > > > 00321148: 0000 0036 00000000 > > > > 00321150: 0000 003a 00000000 > > > > > > > > rx: 32 buffers > > > > 00321000: 8000 0440 00320000 > > > > 00321008: 8000 0c70 00320800 > > > > 00321010: 8000 092b 0037f000 > > > > 00321018: 8000 ff9a 0037f800 > > > > 00321020: 8000 7fa2 0037e000 > > > > 00321028: 8000 eda6 0037e800 > > > > 00321030: 8000 ffa2 0037d000 > > > > 00321038: 8000 ffa6 0037d800 > > > > 00321040: 8000 ffb2 0037c000 > > > > 00321048: 8000 ffb6 0037c800 > > > > 0032 > > > > > > > > Spurious interrupt 1 > > > > Together this looks like an interrupt issue. What do you see > > if you "cat /proc/interrupts"? > > > > Regards > > Greg > > > > > > > > > > > > uclinux simply hangs there. I found that there is a > > large amount > > > of people who are getting the same problem in past > > couple of years. > > > But I did not get any solution for the problem. > > > > > > > > Please let me know whether this problem still exists > > in uclinux > > > source code for M5272C3. where I will find the > > solution for that? > > > > > > > > My Ethernet Hardware Info: > > > > fec.c: Probe number 1 with 0x0000 > > > > eth0: FEC ENET Version 0.2, 00:e0:0c:bc:e5:60 > > > > fec: PHY @ 0x1, ID 0x0022561b -- AM79C874 > > > > > > > > Thanks and Appreciated for your help. > > > > > > > > Thanks > > > > Ashish Phogat > > > > > > > > > > > > _______________________________________________ > > > > uClinux-dev mailing list > > > > uClinux-dev at uclinux.org > > > > > > > > > > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > > > > This message was resent by uclinux-dev at uclinux.org > > > > > > > > > > > To unsubscribe see: > > > > > http://mailman.uclinux.org/mailman/options/uclinux-dev > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > uClinux-dev mailing list > > > uClinux-dev at uclinux.org > > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > > > This message was resent by uclinux-dev at uclinux.org > > > > > To unsubscribe see: > > > http://mailman.uclinux.org/mailman/options/uclinux-dev > > > > > > > > > > > _______________________________________________ > > uClinux-dev mailing list > > uClinux-dev at uclinux.org > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > > This message was resent by uclinux-dev at uclinux.org > > > > To unsubscribe see: > > http://mailman.uclinux.org/mailman/options/uclinux-dev > > > > > > > > > > -- > > N Natarajan > > http://science-of-good-living.blogspot.com/ > > http://science-of-spirituality.blogspot.com/ > > > http://sprituality-is-knowledge.blogspot.in/2011/09/stories-that-explain-knowledge.html > > > > > > _______________________________________________ > > uClinux-dev mailing list > > uClinux-dev at uclinux.org > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > > This message was resent by uclinux-dev at uclinux.org > > > > To unsubscribe see: > > http://mailman.uclinux.org/mailman/options/uclinux-dev > > > > > > > > > > _______________________________________________ > > uClinux-dev mailing list > > uClinux-dev at uclinux.org > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > > This message was resent by uclinux-dev at uclinux.org > > To unsubscribe see: > > http://mailman.uclinux.org/mailman/options/uclinux-dev > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.pluess at stud.hslu.ch Fri Mar 29 07:45:47 2013 From: tobias.pluess at stud.hslu.ch (=?iso-8859-1?Q?Pl=FCss_Tobias_TA=2EE=2E1001?=) Date: Fri, 29 Mar 2013 11:45:47 +0000 Subject: [uClinux-dev] Porting uClinux to a specific board In-Reply-To: <20130328142340.GC21768@csclub.uwaterloo.ca> References: <38F83949ED76A946BE17B6F2F98F362E0B32A7@MX33.campus.intern>, <20130328142340.GC21768@csclub.uwaterloo.ca> Message-ID: <38F83949ED76A946BE17B6F2F98F362E0B32F9@MX33.campus.intern> Hi Len, thanks for your reply. Yes, I know this project. The source code is now available in Google Code, and I checked out the SVN repository. I studied the code, and try to adopt it for the Kernel 3.8.4, but this is not very easy since many things have changed since this port was written (and it is unmaintained since 2007). I have now a Kernel that compiles for my board, but what I don't exactly know is a) where are the interrupt vectors for the ARM7TDMI processor? b) what shall I do with the interrupt controller, the UARTs and stuff, since there is now this "device tree" thing, which I don't understand completely (until now, at least). Bye Tobias ________________________________________ Von: uclinux-dev-bounces at uclinux.org [uclinux-dev-bounces at uclinux.org]" im Auftrag von "Lennart Sorensen [lsorense at csclub.uwaterloo.ca] Gesendet: Donnerstag, 28. M?rz 2013 15:23 An: uClinux development list Betreff: Re: [uClinux-dev] Porting uClinux to a specific board On Thu, Mar 28, 2013 at 08:27:44AM +0000, Pl?ss Tobias TA.E.1001 wrote: > I would like to use uClinux on an ARM7 board which I built by myself. It contains a NXP LPC2468 processor and uses external FLASH (8M) and SDRAM (64M), which I think should be enough memory for uClinux. > Okay, what I did so far is to download the Kernel sources (3.8.4, I would like to use recent Kernel). Then, I created my mach-lpc2468 folder and created various C-files for my hardware specific stuff. > I also created a machine record, but I don't exactly know, what data has to be in there, and I don't exactly know what to do with the interrupt controller and stuff. > Anyway, my Kernel compiles now, but of course, it does not yet work correctly, but I hope somebody can help me with the machine record and the device tree. It looks like someone already did uclinux for that CPU some years ago: http://mailman.uclinux.org/pipermail/uclinux-dev/2007-May/042858.html Maybe those patches would be helpful. -- Len Sorensen _______________________________________________ uClinux-dev mailing list uClinux-dev at uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev at uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev From engineerphogat at gmail.com Fri Mar 29 10:58:55 2013 From: engineerphogat at gmail.com (Ashish Phogat) Date: Fri, 29 Mar 2013 10:58:55 -0400 Subject: [uClinux-dev] Fwd: Ehernet FEC problem in Coldfire M5272C3 In-Reply-To: References: <5150FE62.1070904@westnet.com.au> <5152DE4F.2080504@gmail.com> <5154361B.6080508@westnet.com.au> Message-ID: Hi greg, I debug fec.c file in linux 2.4.x/drivers/net......................Here are my observations: When uclinux boots: dhcp daemon is intiated from rc file: "*dhcpcd -p -a eth0 &*" which tries to open the ethernet port by calling: *"fec_enet_open*" function. In that function I found that *"fep->link*" variable is never initiated to *1* Based on my PHY as "*AM79C874" *and config options shown below: #if defined(CONFIG_M5272) #define M5272_PHY_STAT_INT # if defined(CONFIG_BOARD_UC5272) #define PHY_INT MCF_INT_INT6 #define PHY_START_ADDR 1 #define ICR_PHY_REG (MCF_MBAR + MCFSIM_ICR4) #define ICR_PHY_MASK_IPL 0x77777777 # if defined(CONFIG_UC5272_PHY_INT) #define ICR_PHY_MASK 0xFF0FFFFF #define ICR_PHY_SETUP 0x00d00000 #define ICR_MASK_IP 0x00800000 # else /* CONFIG_UC5272_PHY_INT */ #undef M5272_PHY_STAT_INT #define ICR_PHY_MASK 0xFFFFFFFF #define ICR_PHY_SETUP 0x00000000 #define ICR_MASK_IP 0x00000000 # endif /* CONFIG_UC5272_PHY_INT */ # else /* CONFIG_BOARD_UC5272 */ # if defined(CONFIG_FEC_KS8995M) #undef M5272_PHY_STAT_INT #define PHY_START_ADDR 5 #define ICR_PHY_MASK 0xFFFFFFFF #define ICR_PHY_SETUP 0x00000000 #define ICR_MASK_IP 0x00000000 # else /*CONFIG_FEC_KS8995M */ // These are values for ColdFire 5272 SIM #define PHY_INT MCF_INT_INT2 #define PHY_START_ADDR 0 #define ICR_PHY_REG (MCF_MBAR + MCFSIM_ICR1) #define ICR_PHY_MASK_IPL 0x77777777 #define ICR_PHY_MASK 0x70777777 #define ICR_MASK_IP 0x08000000 #define ICR_PHY_SETUP 0x0d000000 # endif /* CONFIG_FEC_KS8995M */ # endif /* CONFIG_BOARD_UC5272 */ #endif /* CONFIG_M5272 */ * fep->link *is blocked by * * #if !defined( M5272_PHY_STAT_INT) fep->link = 1; /* Always assume we are connected (no interrupt to turn on/off link) */ #endif It seems my link is never up. Next Step I rebuild uclinux by initializing fep->link to 1 always irrespective of any configuration. But this time uclinux keep on starting transimission forever by calling *"fec_enet_start_xmit" *function* * So I simply kill my "*dhcpcd -p -a eth0 &*" process and up my ethernet connection by calling *ifconfig eth0 192.168.0.5 netmask 255.255.255.0 up* after that everything works fine. I am able to ping my Linux machine. I don't know whether some configuration is missed for AM79C874. I am not sure how link is supposed to be up. Whether I should assume to be up always or I have to wait for some interrupt/event which will make my link up. If you have anything on your side please let me know. Thanks Ashish Phogat On Thu, Mar 28, 2013 at 1:15 PM, Ashish Phogat wrote: > Hi Greg, > I am sorry I am new to linux...I donot know how to add traces. Could you > please help me with that? > > Meanwhile I am trying to add few utilities in my uclinux such as > mii-tool-fec, traceroute or ethtool. > > Lets see how much I am able to debug or get more information. > > Thanks for your help. > > Thanks > Ashish Phogat > > > On Thu, Mar 28, 2013 at 8:22 AM, Greg Ungerer wrote: > >> Hi Ashish, >> >> On 28/03/13 21:57, Ashish Phogat wrote: >> > I had a look at all the patches made for M5272C3 in cvs.org >> > for kernel 2.4.x in last couple of years. It seems all >> > patches are included in my distribution (uClinux-dist-20120401.tar.bz2). >> > I don't have idea why this error NETDEV WATCHDOG is still coming. I am >> > running at 50Mhz clock frequency. Is there any problem with frequency? >> >> No, I don't think that will cause you any problems. >> >> From the interrupt count it doesn't look like you are getting any TX >> interrupts from the FEC. This will cause the NETDEV WATCHDOG to >> eventually timeout and you get the kernel trace you see. >> >> You are getting "other" interrupts from the FEC - I think you should >> add some trace and see what those are. Maybe they will give some >> clues. >> >> Regards >> Greg >> >> >> > On Wed, Mar 27, 2013 at 6:24 PM, Ashish Phogat >> > > wrote: >> > >> > Hi Greg, >> > When I did cat proc/interrupts: >> > >> > /> cat /proc/interrupts >> > 66: 0 fec(MII) >> > 72: 3393 ColdFire Timer >> > 73: 1084 ColdFire UART >> > 74: 0 ColdFire UART >> > 77: 0 ColdFire USB (EP0) >> > 78: 0 ColdFire USB (EP1) >> > 79: 0 ColdFire USB (EP2) >> > 80: 0 ColdFire USB (EP3) >> > 81: 0 ColdFire USB (EP4) >> > 82: 0 ColdFire USB (EP5) >> > 83: 0 ColdFire USB (EP6) >> > 84: 0 ColdFire USB (EP7) >> > 86: 0 fec(RX) >> > 87: 0 fec(TX) >> > 88: 13 fec(OTHER) >> > 89: 0 ColdFire QSPI >> > >> > Thanks >> > Ashish phogat >> > >> > On Wed, Mar 27, 2013 at 7:55 AM, Greg Ungerer >> > > >> wrote: >> > >> > Hi Ashish, >> > >> > On 27/03/13 06:12, Ashish Phogat wrote: >> > > My Kernel is 2.4.34.5 and uClinux-dist is >> > uClinux-dist-20120401.tar.bz2. >> > >> > Ok. I haven't run 2.4 kernels for a long time... but some >> > comments >> > below. >> > >> > >> > > > /> NETDEV WATCHDOG: eth0: transmit timed out >> > > > eth0: transmit timed out. >> > > > Ring data dump: cur_tx 321100, dirty_tx 321100 >> > cur_rx: 321000 >> > > > tx: 16 buffers >> > > > 00321100: 0000 0012 00000000 >> > > > 00321108: 0000 0816 00000000 >> > > > 00321110: 0000 001a 00000000 >> > > > 00321118: 0000 0c1e 00000000 >> > > > 00321120: 0000 0432 00000000 >> > > > 00321128: 0000 40a6 00000000 >> > > > 00321130: 0000 002a 00000000 >> > > > 00321138: 0000 002e 00000000 >> > > > 00321140: 0000 0032 00000000 >> > > > 00321148: 0000 0036 00000000 >> > > > 00321150: 0000 003a 00000000 >> > > > >> > > > rx: 32 buffers >> > > > 00321000: 8000 0440 00320000 >> > > > 00321008: 8000 0c70 00320800 >> > > > 00321010: 8000 092b 0037f000 >> > > > 00321018: 8000 ff9a 0037f800 >> > > > 00321020: 8000 7fa2 0037e000 >> > > > 00321028: 8000 eda6 0037e800 >> > > > 00321030: 8000 ffa2 0037d000 >> > > > 00321038: 8000 ffa6 0037d800 >> > > > 00321040: 8000 ffb2 0037c000 >> > > > 00321048: 8000 ffb6 0037c800 >> > > > 0032 >> > > > >> > > > Spurious interrupt 1 >> > >> > Together this looks like an interrupt issue. What do you see >> > if you "cat /proc/interrupts"? >> > >> > Regards >> > Greg >> > >> > >> > > > >> > > > uclinux simply hangs there. I found that there is a >> > large amount >> > > of people who are getting the same problem in past >> > couple of years. >> > > But I did not get any solution for the problem. >> > > > >> > > > Please let me know whether this problem still exists >> > in uclinux >> > > source code for M5272C3. where I will find the >> > solution for that? >> > > > >> > > > My Ethernet Hardware Info: >> > > > fec.c: Probe number 1 with 0x0000 >> > > > eth0: FEC ENET Version 0.2, 00:e0:0c:bc:e5:60 >> > > > fec: PHY @ 0x1, ID 0x0022561b -- AM79C874 >> > > > >> > > > Thanks and Appreciated for your help. >> > > > >> > > > Thanks >> > > > Ashish Phogat >> > > > >> > > > >> > > > _______________________________________________ >> > > > uClinux-dev mailing list >> > > > uClinux-dev at uclinux.org >> > >> > > > > >> > > > >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> > > > This message was resent by uclinux-dev at uclinux.org >> > >> > > > > > >> > > > To unsubscribe see: >> > > > >> http://mailman.uclinux.org/mailman/options/uclinux-dev >> > > > >> > > >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > uClinux-dev mailing list >> > > uClinux-dev at uclinux.org >> > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> > > This message was resent by uclinux-dev at uclinux.org >> > >> > > To unsubscribe see: >> > > http://mailman.uclinux.org/mailman/options/uclinux-dev >> > > >> > >> > >> > >> > _______________________________________________ >> > uClinux-dev mailing list >> > uClinux-dev at uclinux.org >> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> > This message was resent by uclinux-dev at uclinux.org >> > >> > To unsubscribe see: >> > http://mailman.uclinux.org/mailman/options/uclinux-dev >> > >> > >> > >> > >> > -- >> > N Natarajan >> > http://science-of-good-living.blogspot.com/ >> > http://science-of-spirituality.blogspot.com/ >> > >> http://sprituality-is-knowledge.blogspot.in/2011/09/stories-that-explain-knowledge.html >> > >> > >> > _______________________________________________ >> > uClinux-dev mailing list >> > uClinux-dev at uclinux.org >> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> > This message was resent by uclinux-dev at uclinux.org >> > >> > To unsubscribe see: >> > http://mailman.uclinux.org/mailman/options/uclinux-dev >> > >> > >> > >> > >> > _______________________________________________ >> > uClinux-dev mailing list >> > uClinux-dev at uclinux.org >> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> > This message was resent by uclinux-dev at uclinux.org >> > To unsubscribe see: >> > http://mailman.uclinux.org/mailman/options/uclinux-dev >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: