[uClinux-dev] Busybox who Applet

[Doug Kehn]

Hi David/Greg,

Attached is a patch, for review, which allows the
Busybox who applet to be selected from the menu
system.

Regards,
...doug


 

The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

busybox-who-uClinux-dist-20070130.patch
Description: 1381074225-busybox-who-uClinux-dist-20070130.patch
___
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] add ROMfs in RAM at the end of kernel (_ebss)

[Lance Spaulding]

Hi Shaunglin,

I've attached the kernel config and the console log during boot for one
of the platforms where I use a ram-based rom filesystem (an ARM Realview
EB board with an mpcore tile in this case).  This should show you how to
coniigure MTD to get things working.  Note that using a  ram disk is
unrelated to placing a romfs filesystem in ram.

Hope this helps,
Lance



Shuanglin Wang wrote:
> Hi Lance,
>
> Thanks for your help. I tried both ways remove "root=/dev/ram0" and
> add "rootfstype=romfs". But I got exactly same error result:
>
> // kernel log
> ---//
>
> RAMDISK driver initialized: 1 RAM disks of 1024K size 1024 blocksize
> uclinux[mtd]: RAM probe address=0xf2450 size=0x1e000
> Creating 1 MTD partitions on "RAM":
> 0x-0x0001e000 : "ROMfs"
> mtd: Giving out device 0 to ROMfs
> uclinux[mtd]: set ROMfs to be root filesystem
> VFS: Cannot open root device "" or unknown-block(31,0)
> Please append a correct "root=" boot option
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(31,0)
>
> ////
>
>
> Would you please help me clarify several questions:
>
> 1. What should "root=?" be, if I remove "root=/dev/ram0" from kernel
> command line?
>
> 2. If romfs is located in main memory, should the kernel include the
> ramdisk module?
>
> 3. ROOT_DEV is (31,0), set in uclinux.c, do you think that should be
> correct one for mounting funciton?
>
> 4. There are several global variables defined in uclinux.c, like
> uclinux_ram_mtdinfo, uclinux_ram_map and uclinux_romfs. They are
> initialized in uclinux.c, but I can't find where and how they have
> been used directly or indirectly in later mounting procedure.
>
> BTW, can you send me a kernel configure file you have? I guess i
> didn't config the kernel coreectly.
>
> Thanks,
> Shuanglin
>
>
>
> Lance Spaulding wrote:
>
>> Hi Shaunglin,
>>
>> Try removing the 'root=/dev/ram0' from your command line.  You can add
>> 'rootfstype=romfs' if you want but it should work w/o it.
>>
>> Thanks,
>> Lance
>>
>> Shuanglin Wang wrote:
>>  
>>
>>> Hi Lance,
>>>
>>> I'm doing similar things. I patched the kernel with your code, but i
>>> got an kernel panic. The boot log is:
>>>
>>> /-/
>>> Kernel command line: root=/dev/ram0
>>> ...
>>> io scheduler noop registered (default)
>>> atmel_usart.0: ttyS0 at MMIO 0xf800f000 (irq = 11) is a ATMEL_SERIAL
>>> RAMDISK driver initialized: 1 RAM disks of 1024K size 1024 blocksize
>>> uclinux[mtd]: RAM probe address=0xf02f0 size=0x1e000
>>> Creating 1 MTD partitions on "RAM":
>>> 0x-0x0001e000 : "ROMfs"
>>> mtd: Giving out device 0 to ROMfs
>>> uclinux[mtd]: set ROMfs to be root filesystem
>>> Generic platform RAM MTD, (c) 2004 Simtec Electronics
>>> VFS: Can't find a romfs filesystem on dev ram0.
>>> No filesystem could mount root, tried:  romfs
>>> Kernel panic - not syncing: VFS: Unable to mount root fs on
>>> unknown-block(1,0)
>>> /-/
>>>
>>> I made further test on it. And it seems it get an empty super inode
>>> from romfs.
>>>
>>> Did I miss something in kernel configuration or kernel command line?
>>>
>>> Thansk a lot.
>>>
>>> Shuanglin
>>>
>>>
>>>
>>>
>>> Lance Spaulding wrote:
>>>
>>>   
 Mickael Sergent wrote:


 
> Hello,
>
> I'm trying to port uclinux 2.6.x on dev. board based on
> ARM946-E-S. (I
> use uClinux-dist 20070130)
>
> I would like to have kernel and ROMfs entirely in RAM but it seems to
> be impossible on ARM architecture.
>
> On uclinux 2.4 version a switch (CONFIG_RAM_ATTACHED_ROMFS) can be
> used to do this.
>
> Does an equivalent exist in 2.6 version ?
>
>
> I tried to use CONFIG_MTD_UCLINUX_EBSS (after having defined _ebss
> symbol in the end of kernel) but it doesn't solve problem (because
> RAM
> where is stored ROMfs is used by uclinux), so a patch is needed to
> reserve ROMfs memory
>
> Do you know another solution to put ROMfs at the end of kernel ?
>
> Thanks a lot !
>
> Best regards,
>
> Mickael.
>
> 
>
>
>
> ___
> 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
>  
>   
 Hi Mickael,

 We use a ram based rom filesystem on our ARM products (including ones
 using an arm946).  I've attached a small patch of the changes I
 made to
 get this to work.  Note that we use littl

[uClinux-dev] Insert tcpdump in uClinux

[Roger Feltrin Escanhola]

Hi,
 
I am trying to insert tcpdump to my uClinux image but I am not being
successful.
I go in the vendor settings>network options and I set tcpdump, but when
I do the “make” command I have the following error at the end of
compilation:
 
checking for gcc... ucfront-gcc m68k-elf-gcc -m5307 -DCONFIG_COLDFIRE
checking for C compiler default output file name... inftrees.c: In
function �huft_build’:
inftrees.c:122: warning: �r.base’ may be used uninitialized in this
function
ucfront-gcc m68k-elf-gcc -m5307 -DCONFIG_COLDFIRE -O2 -g
-fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall   -DEMBED
-msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__   -c -o infcodes.o
infcodes.c
rm -f libdes.a
m68k-elf-ar crs libdes.a cbc_enc.o ecb_enc.o des_enc.o  fcrypt_b.o
fcrypt.o set_key.o
make[3]: Leaving directory `/home/roger/uClinux-dist/lib/libdes'
ucfront-gcc m68k-elf-gcc -m5307 -DCONFIG_COLDFIRE -O2 -g
-fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall   -DEMBED
-msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__   -c -o infutil.o
infutil.c
ucfront-gcc m68k-elf-gcc -m5307 -DCONFIG_COLDFIRE -O2 -g
-fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall   -DEMBED
-msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__   -c -o inffast.o
inffast.c
m68k-elf-ar rc libz.a adler32.o compress.o crc32.o gzio.o uncompr.o
deflate.o trees.o zutil.o inflate.o infblock.o inftrees.o infcodes.o
infutil.o inffast.o
make[3]: Leaving directory `/home/roger/uClinux-dist/lib/zlib'
a.out
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[3]: *** [build/build] Error 1
make[3]: Leaving directory `/home/roger/uClinux-dist/lib/libpcap'
make[2]: *** [libpcap] Error 2
make[2]: Leaving directory `/home/roger/uClinux-dist/lib'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/roger/uClinux-dist/lib'
make: *** [subdirs] Error 1
[EMAIL PROTECTED] uClinux-dist]#
 
I am using a Coldfire M5208EVB, m68k-uclinux-tools-20060615 and
uClinux-dist-20060803 and I use uClinux 2.4.x to make my kernel image.
Does any one know what I am doing wrong? How could I fix it?
I also would like to know how I know if I have the NAT (iptables)
activated in my uClinux.
 
Thanks
Roger
 
 
  
Roger Feltrin Escanhola
55 11 3094.3939
 
<>___
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] kernel module and static

[Stéphane]

Hi,

Thanks a lot everybody, the "-m68000" was missing and require!


Greg Ungerer a écrit :
> Hi Stephane,
>
> Stéphane wrote:
>> In Makefile:
>>
>> //
>>
>> INCLUDE := -isystem ../uClinux-dist-20060803/linux-2.4.x/include
>> CFLAGS  := -DMODULE -D__KERNEL__ ${WARN} ${INCLUDE}
>> CC  := /opt/uClinux-m68k-elf/bin/m68k-elf-gcc
>>${TARGET}.o: ${TARGET}.c
>
> What CPU are you running on?
> What is the actual compile line?
>
> From the ensuing discussion I would guess that you are not
> compiling with the appropriate CPU class passed to gcc.
>
> If you are using a ColdFire you should at least have an
> -m5200 (or equivalent) gcc option. If a base 68k (like
> 68328 or similar) then -m68000. Otherwise you won't get
> instructions generated appropriate to your CPU.
>
> Regards
> Greg
>
>
>
>> //
>>
>> and with -S  :
>>
>> /*/
>>
>> .file   "ucAsserv.c"
>> gcc2_compiled.:
>> .section.modinfo,"a",@progbits
>> .type__module_kernel_version,@object
>> .size__module_kernel_version,33
>> __module_kernel_version:
>> .string "kernel_version=2.4.31-uc0-ANI-10"
>> .section.rodata
>> .LC0:
>> .string "<6>Bug:\n"
>> .LC1:
>> .string "<6>Never Reach\n"
>> .text
>> .align  2
>> .globl init_module
>> .typeinit_module,@function
>> init_module:
>> link.w %a6,#0
>> clr.l VitL
>> clr.l global_left_encoder
>> clr.l global_right_encoder
>> pea .LC0
>> jsr printk
>> addq.l #4,%sp
>> move.l global_left_encoder,%d0
>> muls.l global_right_encoder,%d0
>> move.l %d0,VitL
>> pea .LC1
>> jsr printk
>> addq.l #4,%sp
>> clr.l %d0
>> jbra .L95
>> .align  2
>> .L95:
>> unlk %a6
>> rts
>> .Lfe1:
>> .sizeinit_module,.Lfe1-init_module
>> .align  2
>> .globl cleanup_module
>> .typecleanup_module,@function
>> cleanup_module:
>> link.w %a6,#0
>> .L96:
>> unlk %a6
>> rts
>> .Lfe2:
>> .sizecleanup_module,.Lfe2-cleanup_module
>> .globl __module_author
>> .section.modinfo
>> .type__module_author,@object
>> .size__module_author,24
>> __module_author:
>> .string "author=Stephane Germain"
>> .type__module_license,@object
>> .size__module_license,12
>> __module_license:
>> .string "license=GPL"
>> .local  global_right_encoder
>> .comm   global_right_encoder,4,2
>> .local  global_left_encoder
>> .comm   global_left_encoder,4,2
>> .local  VitL
>> .comm   VitL,4,2
>> .ident  "GCC: (GNU) 2.95.3 20010315 (release)(ColdFire patches -
>> 20010318 from
>> http://fiddes.net/coldfire/)(uClinux XIP and shared lib patches from
>> http://www.snapgear.com/)"
>>
>> /***/
>>
>>
>> I use the default toolchain
>>
>> /opt/uClinux-m68k-elf/bin/m68k-elf-gcc -v :
>> Reading specs from
>> /opt/uClinux-m68k-elf/lib/gcc-lib/m68k-elf/2.95.3/specs
>> 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/)
>>
>> thanks
>>
>>
>> Wolfgang Reissnegger a écrit :
>>> Hi Stéphane,
>>>
>>> looks like you are compiling your code with compiler flags that
>>> generate instructions that the processor does not support. That's why
>>> you see the illegal instruction trap.
>>>
>>> The reason that it all works if the variables are local is probably
>>> that you also use an optimization flag (e.g. -O3) that causes the
>>> compiler to optimize the whole multiplication away in main because it
>>> has no effect on the function's result and is local to the function.
>>>
>>> You should try to compile the code with gcc -S to generate assembler
>>> output. Then you can identify the instruction that causes the problem.
>>>
>>> Cheers,
>>>Wolfgang
>>>
>>> Stéphane wrote:
 Hi,

 I have a bug that I can be resume as:

 /***/
 #include // Needed by all modules
 #include // Needed for KERN_INFO

 static long global_right_encoder;
 static long global_left_encoder;
 static long VitL;

 int init_module(void)
 {
 VitL = 0;
 global_left_encoder = 0;
 global_right_encoder = 0;

 printk(KERN_INFO "Bug:\n");
VitL = global_left_encoder*global_right_encoder;
printk(KERN_INFO "Never Reach\n");
return 0;
 }


 void cleanup_module(void)
 {
 }

 MODULE_AUTHOR("Stephane Germain");
 MODULE_LICENSE("GPL");
 /**/

 result:

 insmod xxx.o:
 SIGSEGV

 dmesg:
 Bug:
 *** ILLEGAL INSTRUCTION ***  

Re: [uClinux-dev] Bad Frame Format

[Praveen Chandrasekharaiah]

I did double check on the application looking for null pointers memory 
leaks. It runs perfectly fine on a linux machine but fails to run on 
uClinux when cross compiled for m68k.

Gavin Lambert wrote:

Bad Frame Format usually means your app is accessing invalid memory,
whether through a null pointer or an invalid pointer or something else
along those lines, and is typically caused by a bug in the app code.  So
it would make sense that a different app isn't experiencing that problem
:)

  

___
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] Bad Frame Format

[Gavin Lambert]

Quoth Praveen Chandrasekharaiah [EMAIL PROTECTED]:
> I did double check on the application looking for null
> pointers memory leaks. It runs perfectly fine on a linux machine 
> but fails to run on uClinux when cross compiled for m68k.

Are you checking for errors from library functions?  Don't forget that
NOMMU systems have additional restrictions on memory allocation, mmap,
fork etc.

You'll either need to step through the code (which can be a bit tricky
since gdb/gdbserver can be quite flaky) or add extra diagnostic output.

___
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] Busybox who Applet

[Greg Ungerer]

Hi Doug,

Doug Kehn wrote:

Attached is a patch, for review, which allows the
Busybox who applet to be selected from the menu
system.


Looks good, applied.

Thanks
Greg




Greg Ungerer  --  Chief Software Dude   EMAIL: [EMAIL PROTECTED]
Secure Computing CorporationPHONE:   +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: 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] uClinux 2.6 S3c44b0x

[Greg Ungerer]

Hi Jyothi,

Jyothi Gudavalli wrote:
I am trying to port uClinux 2.6 onto ARM s3C44B0X. I was wondering 
someone has done that.

If so can you send me the instructions on how to do it.
many many thanks,


It appears to be part of the patches that Hyok did for the 2.6.x
series sometime back. So support for it is in the uClinux-dist
packages linux-2.6.x kernel.

Regards
Greg




Greg Ungerer  --  Chief Software Dude   EMAIL: [EMAIL PROTECTED]
Secure Computing CorporationPHONE:   +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: 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