Re: [uClinux-dev] ROMFS troubles
Jivin steven taffs lays it down ... > David > > added init=/bin/sh command line and I can now get to the shell and execute > mount -t proc proc /proc after that I can cat meminfo and see that slab is > taking up nearly 500kb if I use slob I think everything will be fine > currently I am using 2.6.11 kernel which does not support slob however the > uclinux-dist 2007 2.6.x does so I will try and copy some file across and see > that happens thanks everyone for being so so helpful ;-) Cool, at least now you know :-) > I think I am missing the bigger picture regarding > > fs/romfs/inode.c > > currently the romfs.img is compiled to run XIP however the FS within the > kernel still copys each binary to ram and then executes it as it dont know > how to XIP the romfs binarys. So I need to change inode.c to get the kernel > to only copy data and bss +stack into ram before it executes a binary within > the romfs is that right ? You need to convince linux-2.6.x/mm/nommu.c that it can do XIP with the use of BDI_CAP_MAP_DIRECT in the right place (if I knew I would tell you ;-) It's possible that 2.6.11 just can't do it. Grep through the kernel source for BDI_CAP_MAP_DIRECT and poke around in linux-2.6.x/mm/nommu.c and see if mmap has comments to the effect of "memory backed" or similar. Cheers, Davidm > David McCullough <[EMAIL PROTECTED]> wrote: > Jivin steven taffs lays it down ... > > David thanks for the reply > > > > ok flthdr romfs/bin/sh reads > > > > Magic:bFLT > > Rev:4 > > Entry:0x44 > > Data start: 0xe720 > > Data end:0x111f0 > > bss end: 0x12750 > > stack size: 0x1000 > > Reloc start:0x111f0 > > reloc count:0x42 > > FLags:0x2(Has-PIC-GOT) > > > > therefore the file system is XIP right? > > Almost, it means your application is XIP capable, which is good. > You also need and XIP capable FS to make it all work. > > > next I added in the bFLT debug code and commented out the line below in rc > > script just to see if that helped > > > > /bin/expand /etc/ramfs.img /dev/ram1 > > > > and I got the output below as you can see the kernel gets a little > > closer however it still kills sh. looking at the output romfs is only > > taking up > > Just a thought, which shell are you using ? sash would be the best > choice. > > The sh above is using 10K of data + 4K of stack. > > > > 80108 bytes > > 20612 bytes > > > > in total 98kb before the kernel crashes. The kernel reports on startup > > > > Memory: 900KB available (690K code, 80K data, 4K init) > > > > > > the romfs takes 98k then the kernel crashes so there should be 900kb - 98Kb > > = 802kb left however the kernel moans saying > > > > Free pages: 172kB (0kB HighMem) > > > > Where is the other 802kb - 172kb = 603kb going ? anyone have any ideas ? > > > > Freeing init memory: 4K > > BINFMT_FLAT: ROM mapping of file (we hope) > > BINFMT_FLAT: Allocated data+bss+stack (80108 bytes): 100a0004 > > p=100bfffc > > start_thread(regs=0x10033f68, entry=0x10040044, start_stack=0x100bffb4) > > BINFMT_FLAT: ROM mapping of file (we hope) > > BINFMT_FLAT: Allocated data+bss+stack (20612 bytes): 100e0004 > > p=100e7ffc > > start_thread(regs=0x10097fb0, entry=0x100d0044, start_stack=0x100e7f9c) > > Shell invoked to run file: /etc/rc > > Command: hostname NXP-LPC2468 > > Command: mount -t proc proc /proc > > Command: cat /etc/motd > > Welcome to > > _ _ > > / __| ||_| > > _ _| | | | _ _ _ _ _ > >| | | | | | || | _ \| | | |\ \/ / > >| |_| | |__| || | | | | |_| |/\ > >| ___\|_||_|_| |_|\|\_/\_/ > >| | > >|_| > > > > For further information check: > > http://www.uclinux.org/ > > > > Command: sh > > > You are doing well here in my opinion. init is running, it has run > /etc/rc in a shell and that has run several commands like mount and > hostname. > > It is quite likely that your memory has become fragmented. Which kernel > memory allocator are you using ? You probably want SLUB or SLOB. > > If you really want to see the command prompt then set your kernel > command line to: > > ... init=/bin/sh > > that will skip all the rc scripting and give you a prompt. From there > you can try things and see what hurts and what doesn't, > > Cheers, > Davidm > > > > BINFMT_FLAT: ROM mapping of file (we hope) > > oom-killer: gfp_mask=0xd0 > > DMA per-cpu: > > cpu 0 hot: low 2, high 6, batch 1 > > cpu 0 cold: low 0, high 2, batch 1 > > Normal per-cpu: empty > > HighMem per-cpu: empty > > > > Free pages: 172kB (0kB HighMem) > > Active:2 inactive:8 dirty:0 writeback:0 unstable:0 free:43 slab:140 > > mapped:0 pag > > etables:0 > > DMA free:172kB min:128kB low:160kB high:192kB active:8kB inactive:32kB > > present:1 > > 024kB pages_scanned:2 all_unreclaimable? no > > lowmem_reserve[]: 0 0 0
Re: [uClinux-dev] ROMFS troubles
David added init=/bin/sh command line and I can now get to the shell and execute mount -t proc proc /proc after that I can cat meminfo and see that slab is taking up nearly 500kb if I use slob I think everything will be fine currently I am using 2.6.11 kernel which does not support slob however the uclinux-dist 2007 2.6.x does so I will try and copy some file across and see that happens thanks everyone for being so so helpful ;-) I think I am missing the bigger picture regarding fs/romfs/inode.c currently the romfs.img is compiled to run XIP however the FS within the kernel still copys each binary to ram and then executes it as it dont know how to XIP the romfs binarys. So I need to change inode.c to get the kernel to only copy data and bss +stack into ram before it executes a binary within the romfs is that right ? thanks again for all the help guys ;-) David McCullough <[EMAIL PROTECTED]> wrote: Jivin steven taffs lays it down ... > David thanks for the reply > > ok flthdr romfs/bin/sh reads > > Magic:bFLT > Rev:4 > Entry:0x44 > Data start: 0xe720 > Data end:0x111f0 > bss end: 0x12750 > stack size: 0x1000 > Reloc start:0x111f0 > reloc count:0x42 > FLags:0x2(Has-PIC-GOT) > > therefore the file system is XIP right? Almost, it means your application is XIP capable, which is good. You also need and XIP capable FS to make it all work. > next I added in the bFLT debug code and commented out the line below in rc > script just to see if that helped > > /bin/expand /etc/ramfs.img /dev/ram1 > > and I got the output below as you can see the kernel gets a little > closer however it still kills sh. looking at the output romfs is only > taking up Just a thought, which shell are you using ? sash would be the best choice. The sh above is using 10K of data + 4K of stack. > 80108 bytes > 20612 bytes > > in total 98kb before the kernel crashes. The kernel reports on startup > > Memory: 900KB available (690K code, 80K data, 4K init) > > > the romfs takes 98k then the kernel crashes so there should be 900kb - 98Kb = > 802kb left however the kernel moans saying > > Free pages: 172kB (0kB HighMem) > > Where is the other 802kb - 172kb = 603kb going ? anyone have any ideas ? > > Freeing init memory: 4K > BINFMT_FLAT: ROM mapping of file (we hope) > BINFMT_FLAT: Allocated data+bss+stack (80108 bytes): 100a0004 > p=100bfffc > start_thread(regs=0x10033f68, entry=0x10040044, start_stack=0x100bffb4) > BINFMT_FLAT: ROM mapping of file (we hope) > BINFMT_FLAT: Allocated data+bss+stack (20612 bytes): 100e0004 > p=100e7ffc > start_thread(regs=0x10097fb0, entry=0x100d0044, start_stack=0x100e7f9c) > Shell invoked to run file: /etc/rc > Command: hostname NXP-LPC2468 > Command: mount -t proc proc /proc > Command: cat /etc/motd > Welcome to > _ _ > / __| ||_| > _ _| | | | _ _ _ _ _ >| | | | | | || | _ \| | | |\ \/ / >| |_| | |__| || | | | | |_| |/\ >| ___\|_||_|_| |_|\|\_/\_/ >| | >|_| > > For further information check: > http://www.uclinux.org/ > > Command: sh You are doing well here in my opinion. init is running, it has run /etc/rc in a shell and that has run several commands like mount and hostname. It is quite likely that your memory has become fragmented. Which kernel memory allocator are you using ? You probably want SLUB or SLOB. If you really want to see the command prompt then set your kernel command line to: ... init=/bin/sh that will skip all the rc scripting and give you a prompt. From there you can try things and see what hurts and what doesn't, Cheers, Davidm > BINFMT_FLAT: ROM mapping of file (we hope) > oom-killer: gfp_mask=0xd0 > DMA per-cpu: > cpu 0 hot: low 2, high 6, batch 1 > cpu 0 cold: low 0, high 2, batch 1 > Normal per-cpu: empty > HighMem per-cpu: empty > > Free pages: 172kB (0kB HighMem) > Active:2 inactive:8 dirty:0 writeback:0 unstable:0 free:43 slab:140 mapped:0 > pag > etables:0 > DMA free:172kB min:128kB low:160kB high:192kB active:8kB inactive:32kB > present:1 > 024kB pages_scanned:2 all_unreclaimable? no > lowmem_reserve[]: 0 0 0 > Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB > pag > es_scanned:0 all_unreclaimable? no > lowmem_reserve[]: 0 0 0 > HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB > present: > 0kB pages_scanned:0 all_unreclaimable? no > lowmem_reserve[]: 0 0 0 > DMA: 1*4kB 3*8kB 3*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB > 0*2048kB > 0*4096kB = 172kB > Normal: empty > HighMem: empty > Out of Memory: Killed process 13 (sh). > BINFMT_FLAT: Allocated data+bss+stack (20603 bytes): 100e8004 > sh: page allocation failure. order:0, mode:0x1d2 > p=100efffc > start_thread(regs=0x10083fb0, entry=0x100f0044, start_stack=0
Re: [uClinux-dev] ROMFS troubles
If you can build busybox you should be able to build little apps easily ? Busybox making is just controlled by "make menuconfig" options. I can make my own application. But I don't have "official" source code for these apps.as stand-alone executables. If you can use lots of little apps you should be able to reduce the load times for each command at least. I do hope so :)= Also see if you can reduce the relocations needed (-fpic might help if the compiler supports it). flthdr will tell you the number of relocations. I don't understand what you are meaning here ... Thanks, -Michael ___ 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
Re: [uClinux-dev] ROMFS troubles
Jivin Michael Schnell lays it down ... > > >It I was to do this today I would look at making my toolchain support > >fdpic (ala blackfin, frv and others). > > > Thanks for letting me know ! > >busybox is not always the best example for XIP, since the busybox > >executable carries a fairly large data/bss segment. > As the toolchain does not provide means to create separate executables > for echo, cat etc., I only have the option to use a quite large busybox If you can build busybox you should be able to build little apps easily ? > file for all of those. I do hope that XIP will speed up the execution of > these small tools. If I find how to do separate executables for these > utilities (MMU-less, from "official" code), this might be an option, too. > >Of course what > >works and what doesn't comes down to your resources (ram/rom) and your > >application. > > > >Suffuce to say that XIP helps you limit the pressure on your memory > >subsystem no matter what you are trying to do, > > > I seem to have no memory limitation right now. I hope to speed up the > shell scripts with this If you can use lots of little apps you should be able to reduce the load times for each command at least. Also see if you can reduce the relocations needed (-fpic might help if the compiler supports it). flthdr will tell you the number of relocations. Cheers, Davidm -- David McCullough, [EMAIL PROTECTED], Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com ___ 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
Re: [uClinux-dev] ROMFS troubles
It I was to do this today I would look at making my toolchain support fdpic (ala blackfin, frv and others). Thanks for letting me know ! busybox is not always the best example for XIP, since the busybox executable carries a fairly large data/bss segment. As the toolchain does not provide means to create separate executables for echo, cat etc., I only have the option to use a quite large busybox file for all of those. I do hope that XIP will speed up the execution of these small tools. If I find how to do separate executables for these utilities (MMU-less, from "official" code), this might be an option, too. Of course what works and what doesn't comes down to your resources (ram/rom) and your application. Suffuce to say that XIP helps you limit the pressure on your memory subsystem no matter what you are trying to do, I seem to have no memory limitation right now. I hope to speed up the shell scripts with this -Michael ___ 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
Re: [uClinux-dev] ROMFS troubles
Jivin Michael Schnell lays it down ... > > >Almost, it means your application is XIP capable, which is good. > >You also need and XIP capable FS to make it all work. > > > Hi Davidm, > > You seem to be knowledgeable, so I ask: > > What can be done to make an architecture XIP-enabled ? Basically it's all in the toolchain. At least all the hard work. You need to make sure your toolchain can generate PIC (position independent code), and it also needs to be able to generate some form of PID (position independant data). How to make the NIOS toolchain do this I don't know, but if you look at the m68k, arm and blackfin toolchains you should be able to learn what is needed. It I was to do this today I would look at making my toolchain support fdpic (ala blackfin, frv and others). > I'm working with NIOS and the current tool-chain does not seem to be > able to create XIP executables. I have no idea on the NIOS compiler and it's capabilities. I know that you can expect to do a lot of learning if you haven't worked on the toolchain before now :-) > I'm hoping for using XIP with the init-RAMFS (most interesting > executable of course is busybox) . Is this a way go ? busybox is not always the best example for XIP, since the busybox executable carries a fairly large data/bss segment. Of course what works and what doesn't comes down to your resources (ram/rom) and your application. Suffuce to say that XIP helps you limit the pressure on your memory subsystem no matter what you are trying to do, Cheers, Davidm -- David McCullough, [EMAIL PROTECTED], Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com ___ 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
Re: [uClinux-dev] ROMFS troubles
Almost, it means your application is XIP capable, which is good. You also need and XIP capable FS to make it all work. Hi Davidm, You seem to be knowledgeable, so I ask: What can be done to make an architecture XIP-enabled ? I'm working with NIOS and the current tool-chain does not seem to be able to create XIP executables. I'm hoping for using XIP with the init-RAMFS (most interesting executable of course is busybox) . Is this a way go ? -Michael ___ 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
Re: [uClinux-dev] ROMFS troubles
Jivin steven taffs lays it down ... > David thanks for the reply > > ok flthdr romfs/bin/sh reads > > Magic:bFLT > Rev:4 > Entry:0x44 > Data start: 0xe720 > Data end:0x111f0 > bss end: 0x12750 > stack size: 0x1000 > Reloc start:0x111f0 > reloc count:0x42 > FLags:0x2(Has-PIC-GOT) > > therefore the file system is XIP right? Almost, it means your application is XIP capable, which is good. You also need and XIP capable FS to make it all work. > next I added in the bFLT debug code and commented out the line below in rc > script just to see if that helped > > /bin/expand /etc/ramfs.img /dev/ram1 > > and I got the output below as you can see the kernel gets a little > closer however it still kills sh. looking at the output romfs is only > taking up Just a thought, which shell are you using ? sash would be the best choice. The sh above is using 10K of data + 4K of stack. > 80108 bytes > 20612 bytes > > in total 98kb before the kernel crashes. The kernel reports on startup > > Memory: 900KB available (690K code, 80K data, 4K init) > > > the romfs takes 98k then the kernel crashes so there should be 900kb - 98Kb = > 802kb left however the kernel moans saying > > Free pages: 172kB (0kB HighMem) > > Where is the other 802kb - 172kb = 603kb going ? anyone have any ideas ? > > Freeing init memory: 4K > BINFMT_FLAT: ROM mapping of file (we hope) > BINFMT_FLAT: Allocated data+bss+stack (80108 bytes): 100a0004 > p=100bfffc > start_thread(regs=0x10033f68, entry=0x10040044, start_stack=0x100bffb4) > BINFMT_FLAT: ROM mapping of file (we hope) > BINFMT_FLAT: Allocated data+bss+stack (20612 bytes): 100e0004 > p=100e7ffc > start_thread(regs=0x10097fb0, entry=0x100d0044, start_stack=0x100e7f9c) > Shell invoked to run file: /etc/rc > Command: hostname NXP-LPC2468 > Command: mount -t proc proc /proc > Command: cat /etc/motd > Welcome to > _ _ > / __| ||_| > _ _| | | | _ _ _ _ _ >| | | | | | || | _ \| | | |\ \/ / >| |_| | |__| || | | | | |_| |/\ >| ___\|_||_|_| |_|\|\_/\_/ >| | >|_| > > For further information check: > http://www.uclinux.org/ > > Command: sh You are doing well here in my opinion. init is running, it has run /etc/rc in a shell and that has run several commands like mount and hostname. It is quite likely that your memory has become fragmented. Which kernel memory allocator are you using ? You probably want SLUB or SLOB. If you really want to see the command prompt then set your kernel command line to: ... init=/bin/sh that will skip all the rc scripting and give you a prompt. From there you can try things and see what hurts and what doesn't, Cheers, Davidm > BINFMT_FLAT: ROM mapping of file (we hope) > oom-killer: gfp_mask=0xd0 > DMA per-cpu: > cpu 0 hot: low 2, high 6, batch 1 > cpu 0 cold: low 0, high 2, batch 1 > Normal per-cpu: empty > HighMem per-cpu: empty > > Free pages: 172kB (0kB HighMem) > Active:2 inactive:8 dirty:0 writeback:0 unstable:0 free:43 slab:140 mapped:0 > pag > etables:0 > DMA free:172kB min:128kB low:160kB high:192kB active:8kB inactive:32kB > present:1 > 024kB pages_scanned:2 all_unreclaimable? no > lowmem_reserve[]: 0 0 0 > Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB > pag > es_scanned:0 all_unreclaimable? no > lowmem_reserve[]: 0 0 0 > HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB > present: > 0kB pages_scanned:0 all_unreclaimable? no > lowmem_reserve[]: 0 0 0 > DMA: 1*4kB 3*8kB 3*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB > 0*2048kB > 0*4096kB = 172kB > Normal: empty > HighMem: empty > Out of Memory: Killed process 13 (sh). > BINFMT_FLAT: Allocated data+bss+stack (20603 bytes): 100e8004 > sh: page allocation failure. order:0, mode:0x1d2 > p=100efffc > start_thread(regs=0x10083fb0, entry=0x100f0044, start_stack=0x100effa4) > Execution Finished, Exiting > > David McCullough <[EMAIL PROTECTED]> wrote: > Jivin steven taffs lays it down ... > > Hi guys > > > > ok when swapping to uClinux-dist-2005 I forgot to add mtd & mtdblocks to > > the vendor makefile I have now added these. However I still get the same > > errors I have been reading a past post and I think the problem is that > > uClinux does not save space after _ebss for the ram mtd drive on a arm7 > > device. I think to use uclinux.c I need to change init.c and maybe more > > files within the mm folder. > > > > I decided to write my own map file actelm7.map and used "map_rom" to probe > > the flash device and split it into partitions. I got the following output > > from the kernel below, as you can see the shell starts up however when it > > tries to load ramfs.img the kernel looks like it runs out of memory. I have > > one meg of ram within my sys
Re: [uClinux-dev] ROMFS troubles
David thanks for the reply ok flthdr romfs/bin/sh reads Magic:bFLT Rev:4 Entry:0x44 Data start: 0xe720 Data end:0x111f0 bss end: 0x12750 stack size: 0x1000 Reloc start:0x111f0 reloc count:0x42 FLags:0x2(Has-PIC-GOT) therefore the file system is XIP right? next I added in the bFLT debug code and commented out the line below in rc script just to see if that helped /bin/expand /etc/ramfs.img /dev/ram1 and I got the output below as you can see the kernel gets a little closer however it still kills sh. looking at the output romfs is only taking up 80108 bytes 20612 bytes in total 98kb before the kernel crashes. The kernel reports on startup Memory: 900KB available (690K code, 80K data, 4K init) the romfs takes 98k then the kernel crashes so there should be 900kb - 98Kb = 802kb left however the kernel moans saying Free pages: 172kB (0kB HighMem) Where is the other 802kb - 172kb = 603kb going ? anyone have any ideas ? Freeing init memory: 4K BINFMT_FLAT: ROM mapping of file (we hope) BINFMT_FLAT: Allocated data+bss+stack (80108 bytes): 100a0004 p=100bfffc start_thread(regs=0x10033f68, entry=0x10040044, start_stack=0x100bffb4) BINFMT_FLAT: ROM mapping of file (we hope) BINFMT_FLAT: Allocated data+bss+stack (20612 bytes): 100e0004 p=100e7ffc start_thread(regs=0x10097fb0, entry=0x100d0044, start_stack=0x100e7f9c) Shell invoked to run file: /etc/rc Command: hostname NXP-LPC2468 Command: mount -t proc proc /proc Command: cat /etc/motd Welcome to _ _ / __| ||_| _ _| | | | _ _ _ _ _ | | | | | | || | _ \| | | |\ \/ / | |_| | |__| || | | | | |_| |/\ | ___\|_||_|_| |_|\|\_/\_/ | | |_| For further information check: http://www.uclinux.org/ Command: sh BINFMT_FLAT: ROM mapping of file (we hope) oom-killer: gfp_mask=0xd0 DMA per-cpu: cpu 0 hot: low 2, high 6, batch 1 cpu 0 cold: low 0, high 2, batch 1 Normal per-cpu: empty HighMem per-cpu: empty Free pages: 172kB (0kB HighMem) Active:2 inactive:8 dirty:0 writeback:0 unstable:0 free:43 slab:140 mapped:0 pag etables:0 DMA free:172kB min:128kB low:160kB high:192kB active:8kB inactive:32kB present:1 024kB pages_scanned:2 all_unreclaimable? no lowmem_reserve[]: 0 0 0 Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pag es_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB present: 0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 DMA: 1*4kB 3*8kB 3*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 172kB Normal: empty HighMem: empty Out of Memory: Killed process 13 (sh). BINFMT_FLAT: Allocated data+bss+stack (20603 bytes): 100e8004 sh: page allocation failure. order:0, mode:0x1d2 p=100efffc start_thread(regs=0x10083fb0, entry=0x100f0044, start_stack=0x100effa4) Execution Finished, Exiting David McCullough <[EMAIL PROTECTED]> wrote: Jivin steven taffs lays it down ... > Hi guys > > ok when swapping to uClinux-dist-2005 I forgot to add mtd & mtdblocks to the > vendor makefile I have now added these. However I still get the same errors I > have been reading a past post and I think the problem is that uClinux does > not save space after _ebss for the ram mtd drive on a arm7 device. I think to > use uclinux.c I need to change init.c and maybe more files within the mm > folder. > > I decided to write my own map file actelm7.map and used "map_rom" to probe > the flash device and split it into partitions. I got the following output > from the kernel below, as you can see the shell starts up however when it > tries to load ramfs.img the kernel looks like it runs out of memory. I have > one meg of ram within my system the kernels data takes up about 100k the rest > of the kernel is XIP therefore I should have about 900k free. The romfs is > also xip so why does the kernel run out of memory ? how much memory do I need > to load the romfs using mtd ? What is the output of: flthdr romfs/bin/sh This will tell you if app is XIP or not. Turn on the debug in binfmt_flat.c to make sure you are getting XIP. Also, make sure that your mtd/system knows that it is in rom. On 2.4 systems there used to be a is_in_rom function that you need to make sure is correct. On 2.6 you need to ensure that the underlying device can support direct mappings. IIRC the BDI_CAP_MAP_DIRECT is needed to provide this functionality, althought only ramfs and char devs seem to implement it. You need romfs (or MTD under romfs to do this or something) under 2.6, expect to spend some time figuring that out :-(. For reference look in: fs/ramfs/inode.c fs/char_dev.c Then work out how to get fs/romfs/inode.c to do it, and post the patch when you do :-) :-) Cheers, Davidm > > CPU: Philips-LP
Re: [uClinux-dev] ROMFS troubles
Jivin steven taffs lays it down ... > Hi guys > > ok when swapping to uClinux-dist-2005 I forgot to add mtd & mtdblocks to the > vendor makefile I have now added these. However I still get the same errors I > have been reading a past post and I think the problem is that uClinux does > not save space after _ebss for the ram mtd drive on a arm7 device. I think to > use uclinux.c I need to change init.c and maybe more files within the mm > folder. > > I decided to write my own map file actelm7.map and used "map_rom" to probe > the flash device and split it into partitions. I got the following output > from the kernel below, as you can see the shell starts up however when it > tries to load ramfs.img the kernel looks like it runs out of memory. I have > one meg of ram within my system the kernels data takes up about 100k the rest > of the kernel is XIP therefore I should have about 900k free. The romfs is > also xip so why does the kernel run out of memory ? how much memory do I need > to load the romfs using mtd ? What is the output of: flthdr romfs/bin/sh This will tell you if app is XIP or not. Turn on the debug in binfmt_flat.c to make sure you are getting XIP. Also, make sure that your mtd/system knows that it is in rom. On 2.4 systems there used to be a is_in_rom function that you need to make sure is correct. On 2.6 you need to ensure that the underlying device can support direct mappings. IIRC the BDI_CAP_MAP_DIRECT is needed to provide this functionality, althought only ramfs and char devs seem to implement it. You need romfs (or MTD under romfs to do this or something) under 2.6, expect to spend some time figuring that out :-(. For reference look in: fs/ramfs/inode.c fs/char_dev.c Then work out how to get fs/romfs/inode.c to do it, and post the patch when you do :-) :-) Cheers, Davidm > > CPU: Philips-LPC22xx [2200] (ARMv3) > Machine: LPC22xx, PHILIPS ELECTRONICS Co., Ltd. > > Built 1 zonelists > Kernel command line: console=ttyS0,115200n8 root=/dev/mtdblock2 > > PID hash table entries: 16 (order: 4, 256 bytes) > > Dentry cache hash table entries: 256 (order: -2, 1024 bytes) > > Inode-cache hash table entries: 128 (order: -3, 512 bytes) > > Memory: 1MB = 1MB total > Memory: 900KB available (690K code, 80K data, 4K init) > > Mount-cache hash table entries: 512 (order: 0, 4096 bytes) > > Linux NoNET1.0 for Linux 2.6 > Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing disabled > > þttyS0 at MMIO 0x0 (irq = 1) is a 16550A > io scheduler noop registered > loop: loaded (max 8 devices) > Probing for flash chips at 0x: > INTEL: Flash at 0x > Creating 4 MTD partitions on "ACTELM7 FLASH": > > 0x-0x0008 : "u-boot" > mtd: Giving out device 0 to u-boot > 0x0008-0x0018 : "Kernel" > mtd: Giving out device 1 to Kernel > 0x0018-0x001fd000 : "Flash FS" > mtd: Giving out device 2 to Flash FS > 0x001fd000-0x0100 : "Not used" > mtd: Giving out device 3 to Not used > * > VFS: test name = > VFS: fs_name = > VFS: fs_name = > VFS: tried fs_name = err -22 > VFS: Mounted root (romfs filesystem) readonly. > > VFS: tried fs_name = err 0 > Freeing init memory: 4K > Shell invoked to run file: /etc/rc > Command: hostname NXP-LPC2468 > Command: /bin/expand /etc/ramfs.img /dev/ram1 > > oom-killer: gfp_mask=0xd0 > > DMA per-cpu: > cpu 0 hot: low 2, high 6, batch 1 > cpu 0 cold: low 0, high 2, batch 1 > Normal per-cpu: empty > HighMem per-cpu: empty > > Free pages: 144kB (0kB HighMem) > Active:0 inactive:27 dirty:0 writeback:0 unstable:0 free:36 slab:137 mapped:0 > pa > get
Re: [uClinux-dev] ROMFS troubles
Hi guys ok when swapping to uClinux-dist-2005 I forgot to add mtd & mtdblocks to the vendor makefile I have now added these. However I still get the same errors I have been reading a past post and I think the problem is that uClinux does not save space after _ebss for the ram mtd drive on a arm7 device. I think to use uclinux.c I need to change init.c and maybe more files within the mm folder. I decided to write my own map file actelm7.map and used "map_rom" to probe the flash device and split it into partitions. I got the following output from the kernel below, as you can see the shell starts up however when it tries to load ramfs.img the kernel looks like it runs out of memory. I have one meg of ram within my system the kernels data takes up about 100k the rest of the kernel is XIP therefore I should have about 900k free. The romfs is also xip so why does the kernel run out of memory ? how much memory do I need to load the romfs using mtd ? CPU: Philips-LPC22xx [2200] (ARMv3) Machine: LPC22xx, PHILIPS ELECTRONICS Co., Ltd. Built 1 zonelists Kernel command line: console=ttyS0,115200n8 root=/dev/mtdblock2 PID hash table entries: 16 (order: 4, 256 bytes) Dentry cache hash table entries: 256 (order: -2, 1024 bytes) Inode-cache hash table entries: 128 (order: -3, 512 bytes) Memory: 1MB = 1MB total Memory: 900KB available (690K code, 80K data, 4K init) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Linux NoNET1.0 for Linux 2.6 Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing disabled þttyS0 at MMIO 0x0 (irq = 1) is a 16550A io scheduler noop registered loop: loaded (max 8 devices) Probing for flash chips at 0x: INTEL: Flash at 0x Creating 4 MTD partitions on "ACTELM7 FLASH": 0x-0x0008 : "u-boot" mtd: Giving out device 0 to u-boot 0x0008-0x0018 : "Kernel" mtd: Giving out device 1 to Kernel 0x0018-0x001fd000 : "Flash FS" mtd: Giving out device 2 to Flash FS 0x001fd000-0x0100 : "Not used" mtd: Giving out device 3 to Not used * VFS: test name = VFS: fs_name = VFS: fs_name = VFS: tried fs_name = err -22 VFS: Mounted root (romfs filesystem) readonly. VFS: tried fs_name = err 0 Freeing init memory: 4K Shell invoked to run file: /etc/rc Command: hostname NXP-LPC2468 Command: /bin/expand /etc/ramfs.img /dev/ram1 oom-killer: gfp_mask=0xd0 DMA per-cpu: cpu 0 hot: low 2, high 6, batch 1 cpu 0 cold: low 0, high 2, batch 1 Normal per-cpu: empty HighMem per-cpu: empty Free pages: 144kB (0kB HighMem) Active:0 inactive:27 dirty:0 writeback:0 unstable:0 free:36 slab:137 mapped:0 pa getables:0 DMA free:144kB min:128kB low:160kB high:192kB active:0kB inactive:108kB present: 1024kB pages_scanned:29 all_unreclaimable? no lowmem_reserve[]: 0 0 0 Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pag es_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB present: 0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 DMA: 2*4kB 3*8kB 1*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 144kB Normal: empty HighMem: empty Out of Memory: Killed process 12 (sh). rwarner <[EMAIL PROTECTED]> wrote: Greg Ungerer wrote: > Hi Steven, > > steven taffs wrote: >> still cant get to ROMFS loaded, I downloaded a uClinux-dist-2005 and >> copyed my linux-2.6.x directory into it and now I can compile jffs2 >> but that still doesnt help me load the ROMFS >> >> I am currently loading the romfs image from flash @ 0x18 into ram >> at 0x1001c26c (_ebss) using the cp.b uboot command and t
Re: [uClinux-dev] ROMFS troubles
Greg Ungerer wrote: Hi Steven, steven taffs wrote: still cant get to ROMFS loaded, I downloaded a uClinux-dist-2005 and copyed my linux-2.6.x directory into it and now I can compile jffs2 but that still doesnt help me load the ROMFS I am currently loading the romfs image from flash @ 0x18 into ram at 0x1001c26c (_ebss) using the cp.b uboot command and then executing the kernel with go 0x8. uclinux.c seems to be working however I get > Kernel panic - not syncing: No init found. Try passing init= option to kernel Booting to this point suggests that your are past mounting the ROMfs. Do you have a valid "/sbin/init", "/etc/init", "/bin/init" or "/bin/sh" in your ROMfs for the kernel to run? if I dont copy ROMFS from flash to ram before executing the kernel VFS fails to mount a file system, so the kernel must be seeing something has anyone get any ideas ? the full kernel output follows RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) uclinux[mtd]: RAM probe address=0x1001c26c size=0x10 Creating 1 MTD partitions on "RAM": 0x-0x0010 : "ROMfs" mtd: Giving out device 0 to ROMfs uclinux[mtd]: set ROMfs to be root filesystem * VFS: test name = VFS: fs_name = mtdblock_open ok mtdblock: read on "ROMfs" at 0x0, size 0x200 mtdblock: read on "ROMfs" at 0x200, size 0x200 VFS: Mounted root (romfs filesystem) readonly. VFS: tried fs_name = err 0 Freeing init memory: 4K mtdblock: read on "ROMfs" at 0x3000, size 0x200 mtdblock: read on "ROMfs" at 0x3200, size 0x200 Warning: unable to open an initial console. Have you created device nodes in your ROMfs? mtdblock: read on "ROMfs" at 0xc00, size 0x200 mtdblock: read on "ROMfs" at 0xe00, size 0x200 Kernel panic - not syncing: No init found. Try passing init= option to kernel. Having just gone through this. You be missing the the poriotn of the Vendor Make file. Example on the AT91 is: DEVICES = \ tty,c,5,0 console,c,5,1 cua0,c,5,64 cua1,c,5,65 \ \ mem,c,1,1 kmem,c,1,2 null,c,1,3 ram0,b,1,0 \ ram1,b,1,1 \ \ ttypc,c,3,12 ttypd,c,3,13 ttype,c,3,14 ttypf,c,3,15 \ \ mtd0,c,90,0mtd1,c,90,2mtd2,c,90,4 \ \ mtdblock0,b,31,0 mtdblock1,b,31,2 mtdblock2,b,31,4 \ \ zero,c,1,5 random,c,1,8 urandom,c,1,9 hths - bob ___ 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
Re: [uClinux-dev] ROMFS troubles
Hi Steven, steven taffs wrote: still cant get to ROMFS loaded, I downloaded a uClinux-dist-2005 and copyed my linux-2.6.x directory into it and now I can compile jffs2 but that still doesnt help me load the ROMFS I am currently loading the romfs image from flash @ 0x18 into ram at 0x1001c26c (_ebss) using the cp.b uboot command and then executing the kernel with go 0x8. uclinux.c seems to be working however I get > Kernel panic - not syncing: No init found. Try passing init= option to kernel Booting to this point suggests that your are past mounting the ROMfs. Do you have a valid "/sbin/init", "/etc/init", "/bin/init" or "/bin/sh" in your ROMfs for the kernel to run? if I dont copy ROMFS from flash to ram before executing the kernel VFS fails to mount a file system, so the kernel must be seeing something has anyone get any ideas ? the full kernel output follows RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) uclinux[mtd]: RAM probe address=0x1001c26c size=0x10 Creating 1 MTD partitions on "RAM": 0x-0x0010 : "ROMfs" mtd: Giving out device 0 to ROMfs uclinux[mtd]: set ROMfs to be root filesystem * VFS: test name = VFS: fs_name = mtdblock_open ok mtdblock: read on "ROMfs" at 0x0, size 0x200 mtdblock: read on "ROMfs" at 0x200, size 0x200 VFS: Mounted root (romfs filesystem) readonly. VFS: tried fs_name = err 0 Freeing init memory: 4K mtdblock: read on "ROMfs" at 0x3000, size 0x200 mtdblock: read on "ROMfs" at 0x3200, size 0x200 Warning: unable to open an initial console. Have you created device nodes in your ROMfs? mtdblock: read on "ROMfs" at 0xc00, size 0x200 mtdblock: read on "ROMfs" at 0xe00, size 0x200 Kernel panic - not syncing: No init found. Try passing init= option to kernel. Regards Greg */steven taffs <[EMAIL PROTECTED]>/* wrote: Greg thanks for the reply I have now created my own MTD mapper file /driver/mtd/maps/actel_m7.c and added some lines to /driver/mtd/maps/Kconfig & Makefile so I can select the new mapper file however when I try to compile the kernel with the following JFFS2 option set Flash systems -> Miscellaneous file system -> JFFS2 support I get the following compiler error In file included from /home/steve/uClinux-dist/lib/uClibc/include/linux/signal.h :4, from /home/steve/uClinux-dist/lib/uClibc/include/linux/sched.h: 27, from /home/steve/uClinux-dist/lib/uClibc/include/linux/module.h :10, from /home/steve/uClinux-dist/lib/uClibc/include/linux/mtd/mtd. h:19, from erase.c:9: /home/steve/uClinux-dist/lib/uClibc/include/linux/list.h:705: warning: #warning"don't include kernel headers in userspace" make[2]: *** [erase] Error 1 make[2]: Leaving directory `/home/steve/uClinux-dist/user/mtd-utils' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/steve/uClinux-dist/user' make: *** [subdirs] Error 1/home/steve/uClinux-dist/lib/uClibc/include/linux/jiffies.h:416: division by zer o in #if /home/steve/uClinux-dist/lib/uClibc/include/linux/jiffies.h:432: division by zer o in #if In file included from /home/steve/uClinux-dist/lib/uClibc/include/linux/signal.h :4, from /home/steve/uClinux-dist/lib/uClibc/include/linux/sched.h: 27, from /home/steve/uClinux-dist/lib/uClibc/include/linux/module.h :10, from /home/steve/uClinux-dist/lib/uClibc/include/linux/mtd/mtd. h:19, from erase.c:9: /home/steve/uClinux-dist/lib/uClibc/include/linux/list.h:705: warning: #warning"don't include kernel headers in userspace" make[2]: *** [erase] Error 1 make[2]: Leaving directory `/home/steve/uClinux-dist/user/mtd-utils' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/steve/uClinux-dist/user' make: *** [subdirs] Error 1 without the JFFS2 options enabled the kernel compiles ok! I am using the following sources / tools Linux version 2.6.11.8-hsc0 ARM-ELF toolchain 20040427 uClinux-dist-20040408 Have you seen or has anyone seen this problem before? would be greatful for any ideas as without the jffs2 kernel support I cant mount the rootfs so I am a bit stuck ;-( */Greg Ungerer <[EMAIL PROTECTED]>/* wrote: Hi Steven, steven taffs wrote: > Ok I have tired changing kernel command line to > > Kernel command line: root=/dev/rom0 initrd=0x0034,289k > console=ttyS0,115200n8 > > however I still get the following errors > > initrd
Re: [uClinux-dev] ROMFS troubles
Hi still cant get to ROMFS loaded, I downloaded a uClinux-dist-2005 and copyed my linux-2.6.x directory into it and now I can compile jffs2 but that still doesnt help me load the ROMFS I am currently loading the romfs image from flash @ 0x18 into ram at 0x1001c26c (_ebss) using the cp.b uboot command and then executing the kernel with go 0x8. uclinux.c seems to be working however I get Kernel panic - not syncing: No init found. Try passing init= option to kernel if I dont copy ROMFS from flash to ram before executing the kernel VFS fails to mount a file system, so the kernel must be seeing something has anyone get any ideas ? the full kernel output follows RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) uclinux[mtd]: RAM probe address=0x1001c26c size=0x10 Creating 1 MTD partitions on "RAM": 0x-0x0010 : "ROMfs" mtd: Giving out device 0 to ROMfs uclinux[mtd]: set ROMfs to be root filesystem * VFS: test name = VFS: fs_name = mtdblock_open ok mtdblock: read on "ROMfs" at 0x0, size 0x200 mtdblock: read on "ROMfs" at 0x200, size 0x200 VFS: Mounted root (romfs filesystem) readonly. VFS: tried fs_name = err 0 Freeing init memory: 4K mtdblock: read on "ROMfs" at 0x3000, size 0x200 mtdblock: read on "ROMfs" at 0x3200, size 0x200 Warning: unable to open an initial console. mtdblock: read on "ROMfs" at 0xc00, size 0x200 mtdblock: read on "ROMfs" at 0xe00, size 0x200 Kernel panic - not syncing: No init found. Try passing init= option to kernel. steven taffs <[EMAIL PROTECTED]> wrote: Greg thanks for the reply I have now created my own MTD mapper file /driver/mtd/maps/actel_m7.c and added some lines to /driver/mtd/maps/Kconfig & Makefile so I can select the new mapper file however when I try to compile the kernel with the following JFFS2 option set Flash systems -> Miscellaneous file system -> JFFS2 support I get the following compiler error In file included from /home/steve/uClinux-dist/lib/uClibc/include/linux/signal.h :4, from /home/steve/uClinux-dist/lib/uClibc/include/linux/sched.h: 27, from /home/steve/uClinux-dist/lib/uClibc/include/linux/module.h :10, from /home/steve/uClinux-dist/lib/uClibc/include/linux/mtd/mtd. h:19, from erase.c:9: /home/steve/uClinux-dist/lib/uClibc/include/linux/list.h:705: warning: #warning"don't include kernel headers in userspace" make[2]: *** [erase] Error 1 make[2]: Leaving directory `/home/steve/uClinux-dist/user/mtd-utils' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/steve/uClinux-dist/user' make: *** [subdirs] Error 1/home/steve/uClinux-dist/lib/uClibc/include/linux/jiffies.h:416: division by zer o in #if /home/steve/uClinux-dist/lib/uClibc/include/linux/jiffies.h:432: division by zer o in #if In file included from /home/steve/uClinux-dist/lib/uClibc/include/linux/signal.h :4, from /home/steve/uClinux-dist/lib/uClibc/include/linux/sched.h: 27, from /home/steve/uClinux-dist/lib/uClibc/include/linux/module.h :10, from /home/steve/uClinux-dist/lib/uClibc/include/linux/mtd/mtd. h:19, from erase.c:9: /home/steve/uClinux-dist/lib/uClibc/include/linux/list.h:705: warning: #warning"don't include kernel headers in userspace" make[2]: *** [erase] Error 1 make[2]: Leaving directory `/home/steve/uClinux-dist/user/mtd-utils' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/steve/uClinux-dist/user' make: *** [subdirs] Error 1 without the JFFS2 options enabled the kernel compiles ok! I am using the following sources / tools Linux version 2.6.11.8-hsc0 ARM-ELF toolchain 20040427 uClinux-dist-20040408 Have you seen or has anyone seen this problem before? would be greatful for any ideas as without the jffs2 kernel support I cant mount the rootfs so I am a bit stuck ;-( Greg Ungerer <[EMAIL PROTECTED]> wrote: Hi Steven, steven taffs wrote: > Ok I have tired changing kernel command line to > > Kernel command line: root=/dev/rom0 initrd=0x0034,289k > console=ttyS0,115200n8 > > however I still get the following errors > > initrd (0x0034 - 0x00388400) extends beyond physical memory - > disabling init A ROMfs filesystem at a fixed address in flash is not a "ramdisk", as suggested by the initrd= option. You need a fixed physical mtd mapping to use that as you root fs. A modern uclinux.c MTD map driver can do this, mapping a ROMfs from a fixed flash address. I don't recall of hand if the uclinux.c driver in 2.6.11 had this support. Look for the config option MTD_UCLINUX_ADDRESS. Using the normal uclinux.c from uClinux-dist then you would not need any boot arg
Re: [uClinux-dev] ROMFS troubles
Greg thanks for the reply I have now created my own MTD mapper file /driver/mtd/maps/actel_m7.c and added some lines to /driver/mtd/maps/Kconfig & Makefile so I can select the new mapper file however when I try to compile the kernel with the following JFFS2 option set Flash systems -> Miscellaneous file system -> JFFS2 support I get the following compiler error In file included from /home/steve/uClinux-dist/lib/uClibc/include/linux/signal.h :4, from /home/steve/uClinux-dist/lib/uClibc/include/linux/sched.h: 27, from /home/steve/uClinux-dist/lib/uClibc/include/linux/module.h :10, from /home/steve/uClinux-dist/lib/uClibc/include/linux/mtd/mtd. h:19, from erase.c:9: /home/steve/uClinux-dist/lib/uClibc/include/linux/list.h:705: warning: #warning"don't include kernel headers in userspace" make[2]: *** [erase] Error 1 make[2]: Leaving directory `/home/steve/uClinux-dist/user/mtd-utils' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/steve/uClinux-dist/user' make: *** [subdirs] Error 1/home/steve/uClinux-dist/lib/uClibc/include/linux/jiffies.h:416: division by zer o in #if /home/steve/uClinux-dist/lib/uClibc/include/linux/jiffies.h:432: division by zer o in #if In file included from /home/steve/uClinux-dist/lib/uClibc/include/linux/signal.h :4, from /home/steve/uClinux-dist/lib/uClibc/include/linux/sched.h: 27, from /home/steve/uClinux-dist/lib/uClibc/include/linux/module.h :10, from /home/steve/uClinux-dist/lib/uClibc/include/linux/mtd/mtd. h:19, from erase.c:9: /home/steve/uClinux-dist/lib/uClibc/include/linux/list.h:705: warning: #warning"don't include kernel headers in userspace" make[2]: *** [erase] Error 1 make[2]: Leaving directory `/home/steve/uClinux-dist/user/mtd-utils' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/steve/uClinux-dist/user' make: *** [subdirs] Error 1 without the JFFS2 options enabled the kernel compiles ok! I am using the following sources / tools Linux version 2.6.11.8-hsc0 ARM-ELF toolchain 20040427 uClinux-dist-20040408 Have you seen or has anyone seen this problem before? would be greatful for any ideas as without the jffs2 kernel support I cant mount the rootfs so I am a bit stuck ;-( Greg Ungerer <[EMAIL PROTECTED]> wrote: Hi Steven, steven taffs wrote: > Ok I have tired changing kernel command line to > > Kernel command line: root=/dev/rom0 initrd=0x0034,289k > console=ttyS0,115200n8 > > however I still get the following errors > > initrd (0x0034 - 0x00388400) extends beyond physical memory - > disabling init A ROMfs filesystem at a fixed address in flash is not a "ramdisk", as suggested by the initrd= option. You need a fixed physical mtd mapping to use that as you root fs. A modern uclinux.c MTD map driver can do this, mapping a ROMfs from a fixed flash address. I don't recall of hand if the uclinux.c driver in 2.6.11 had this support. Look for the config option MTD_UCLINUX_ADDRESS. Using the normal uclinux.c from uClinux-dist then you would not need any boot args at all, or if using the standard main line kernel one then you might need root=/dev/mtd0. Regards Greg > and > > VFS: Cannot open root device "rom0" or unknown-block(0,0) > Please append a correct "root=" boot option > Kernel panic - not syncing: VFS: Unable to mount root fs on > unknown-block(0,0) > > > does anyone have an idea how I can boot the romfs.img from flash ? > > */steven taffs /* wrote: > > Hi all > > I am currently porting the uClinux patch from NXP (LPC22xx) to an > Actel M7 A3P-DEV-KIT-SCS. This demo board is an ARM7TDMI-S enabled > proASIC3. I am making good progress so far however I am a bit > confused about how to mount the ROMFS.img file created within > uClinux-dist. > > The memory map of my system is as follows > > 003F flash > 1000 1010 ram (only one 1MB!) > > I am using xip for the kernel which is loaded into flash at address > 23 and the data and bss areas are relocated to 10008000 and it > all boots ok ;-) however its the next stage that I am having trouble > with. I have loaded ROMFS.img into 34 and hardcoded at > kernel compile time the following command line kernel parameters > > Kernel command line: root=/dev/ram0 initrd=0x0034,289k > console=ttyS0,115200n8 > > However I get the following errors from the kernel at boot up > > initrd (0x0034 - 0x00388400) extends beyond physical memory - > disabling initrd > > and > > Kernel panic - not syncing: VFS: Unable to mount root fs o
Re: [uClinux-dev] ROMFS troubles
Ok I have tired changing kernel command line to Kernel command line: root=/dev/rom0 initrd=0x0034,289k console=ttyS0,115200n8 however I still get the following errors initrd (0x0034 - 0x00388400) extends beyond physical memory - disabling init and VFS: Cannot open root device "rom0" or unknown-block(0,0) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) does anyone have an idea how I can boot the romfs.img from flash ? steven taffs <[EMAIL PROTECTED]> wrote: Hi all I am currently porting the uClinux patch from NXP (LPC22xx) to an Actel M7 A3P-DEV-KIT-SCS. This demo board is an ARM7TDMI-S enabled proASIC3. I am making good progress so far however I am a bit confused about how to mount the ROMFS.img file created within uClinux-dist. The memory map of my system is as follows 003F flash 1000 1010 ram (only one 1MB!) I am using xip for the kernel which is loaded into flash at address 23 and the data and bss areas are relocated to 10008000 and it all boots ok ;-) however its the next stage that I am having trouble with. I have loaded ROMFS.img into 34 and hardcoded at kernel compile time the following command line kernel parameters Kernel command line: root=/dev/ram0 initrd=0x0034,289k console=ttyS0,115200n8 However I get the following errors from the kernel at boot up initrd (0x0034 - 0x00388400) extends beyond physical memory - disabling initrd and Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) I think I need to change the command line somehow to get it to boot the ROMFS xip can anyone help? please Below is the full kernel output => go 23 ## Starting application at 0x0023 ... Linux version 2.6.11.8-hsc0 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010315 (release)(ColdFire patches - 20010318 from http://fiddes.net/coldfire/)(uClinux XIP and shared lib patches from http://www.snapgear.com/)) #3 Fri May 23 00:08:42 BST 2008 CPU: Philips-LPC22xx [2200] (ARMv3) Machine: LPC22xx, PHILIPS ELECTRONICS Co., Ltd. initrd (0x0034 - 0x00388400) extends beyond physical memory - disabling initrd Built 1 zonelists Kernel command line: root=/dev/ram0 initrd=0x0034,289k console=ttyS0,115200n8 PID hash table entries: 16 (order: 4, 256 bytes) Dentry cache hash table entries: 256 (order: -2, 1024 bytes) Inode-cache hash table entries: 128 (order: -3, 512 bytes) Memory: 1MB = 1MB total Memory: 900KB available (574K code, 80K data, 4K init) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Linux NoNET1.0 for Linux 2.6 Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled �ttyS0 at MMIO 0x0 (irq = 1) is a 16550A io scheduler noop registered RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) ___ 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 ___ 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
[uClinux-dev] ROMFS troubles
Hi all I am currently porting the uClinux patch from NXP (LPC22xx) to an Actel M7 A3P-DEV-KIT-SCS. This demo board is an ARM7TDMI-S enabled proASIC3. I am making good progress so far however I am a bit confused about how to mount the ROMFS.img file created within uClinux-dist. The memory map of my system is as follows 003F flash 1000 1010 ram (only one 1MB!) I am using xip for the kernel which is loaded into flash at address 23 and the data and bss areas are relocated to 10008000 and it all boots ok ;-) however its the next stage that I am having trouble with. I have loaded ROMFS.img into 34 and hardcoded at kernel compile time the following command line kernel parameters Kernel command line: root=/dev/ram0 initrd=0x0034,289k console=ttyS0,115200n8 However I get the following errors from the kernel at boot up initrd (0x0034 - 0x00388400) extends beyond physical memory - disabling initrd and Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) I think I need to change the command line somehow to get it to boot the ROMFS xip can anyone help? please Below is the full kernel output => go 23 ## Starting application at 0x0023 ... Linux version 2.6.11.8-hsc0 ([EMAIL PROTECTED]) (gcc version 2.95.3 20010315 (release)(ColdFire patches - 20010318 from http://fiddes.net/coldfire/)(uClinux XIP and shared lib patches from http://www.snapgear.com/)) #3 Fri May 23 00:08:42 BST 2008 CPU: Philips-LPC22xx [2200] (ARMv3) Machine: LPC22xx, PHILIPS ELECTRONICS Co., Ltd. initrd (0x0034 - 0x00388400) extends beyond physical memory - disabling initrd Built 1 zonelists Kernel command line: root=/dev/ram0 initrd=0x0034,289k console=ttyS0,115200n8 PID hash table entries: 16 (order: 4, 256 bytes) Dentry cache hash table entries: 256 (order: -2, 1024 bytes) Inode-cache hash table entries: 128 (order: -3, 512 bytes) Memory: 1MB = 1MB total Memory: 900KB available (574K code, 80K data, 4K init) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Linux NoNET1.0 for Linux 2.6 Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled �ttyS0 at MMIO 0x0 (irq = 1) is a 16550A io scheduler noop registered RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) ___ 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
