Subject: Binary file format - msg#00681

Previous Message by Date: click to view message preview

Any body can help me?

Hi, List, I've some problems about uC-libc and uClibc. What IPC resource does uC-libc support IPC when I used uClinux2.4.17? I can only find the source codes about shared memeory in the directory of /lib/libc/shm. How can I update the uClibc? Just replace the files with the newer files or replace the whole directory or anything else? I've downloaded a newer set of uClibc(resource codes) but its structure is different from my old uClibc. I don't know how to use it. Same problem about update uClinux. When I make a new image with IPC, errors occurs. I think I have to update the resource codes in the directory of linux-2.4.x / ipc. Just replace them with newer files, all right? Thanks! This message resent by the uclinux-dev@xxxxxxxxxxx list server http://www.uClinux.org/

Next Message by Date: click to view message preview

RE: Problem using JFFS on 5272C3

Hi, again Now, I have the mtdblockX device with 31 as major number and minor up to 9. I can mount the jffs on the mtdblock, but the acces is only in read-mode. What's append ? /> mount -t jffs /dev/mtdblock9 /tmp/jffs mtdblock_open ok JFFS: Trying to mount device 1f:09. jffs_scan_flash(): start pos = 0x0, end = 0x40000 check_partly_erased_sector():checking sector which contains offset 0x0 for flipp ing bits.. check_partly_erased_sector():checking sector which contains offset 0x1000 for fl ipping bits.. check_partly_erased_sector():checking sector which contains offset 0x2000 for fl ipping bits.. check_partly_erased_sector():checking sector which contains offset 0x3000 for fl ipping bits.. check_partly_erased_sector():checking sector which contains offset 0x4000 for fl ipping bits.. check_partly_erased_sector():checking sector which contains offset 0x5000 for fl ipping bits.. check_partly_erased_sector():checking sector which contains offset 0x6000 for fl ipping bits.. check_partly_erased_sector():checking sector which contains offset 0x7000 for fl ipping bits.. check_partly_erased_sector():checking sector which contains offset 0x8000 for fl ipping bits.. check_partly_erased_sector():checking sector which contains offset 0x9000 for fl ipping bits.. check_partly_erased_sector():checking sector which contains offset 0xa000 for fl ipping bits.. check_partly_erased_sector():checking sector which contains offset 0xb000 for fl ipping bits.. check_partly_erased_sector():checking sector which contains offset 0xc000 for fl ipping bits.. check_partly_erased_sector():checking sector which contains offset 0xd000 for fl ipping bits.. check_partly_erased_sector():checking sector which contains offset 0xe000 for fl ipping bits.. check_partly_erased_sector():checking sector which contains offset 0xf000 for fl ipping bits.. check_partly_erased_sector():checking sector which contains offset 0x10000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x11000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x12000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x13000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x14000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x15000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x16000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x17000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x18000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x19000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x1a000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x1b000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x1c000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x1d000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x1e000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x1f000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x20000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x21000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x22000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x23000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x24000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x25000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x26000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x27000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x28000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x29000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x2a000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x2b000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x2c000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x2d000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x2e000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x2f000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x30000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x31000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x32000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x33000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x34000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x35000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x36000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x37000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x38000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x39000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x3a000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x3b000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x3c000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x3d000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x3e000 for f lipping bits.. check_partly_erased_sector():checking sector which contains offset 0x3f000 for f lipping bits.. jffs_scan_flash(): 0xffffffff at pos 0x0. jffs_scan_flash():0xffffffff ended at pos 0x40000. Free space accepted: Starting 0x0 for 0x40000 bytes JFFS: Dumping the file system's hash table... *** c->hash[1]: "" (ino: 1, pino: 0) / (ino: 1, highest_version: 0, size: 0) JFFS: GC thread pid=3840. JFFS: Successfully mounted device 1f:09. jffs_garbage_collect_thread(): Starting infinite loop. thread_should_wake(): free=262144, dirty=1, blocksize=262144. ls -la /tmp/jffs drwxr-xr-x 1 0 0 0 Nov 30 00:33 . drwxr-xr-x 3 0 0 1024 Nov 30 00:32 .. cp /etc/rc /tmp/jffs jffs_create(): dir: 0x0039f820, name: "rc" jffs_write_node(): filename = "rc", ino = 2, total_size = 64 jffs_create(): jffs_write_node() failed. /tmp/jffs/rc: No space left on device /> ls -la /dev/mt* crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd0 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd1 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd10 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd11 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd12 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd13 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd14 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd15 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd16 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd17 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd18 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd2 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd20 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd21 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd22 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd3 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd4 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd5 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd6 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd7 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd8 crw------- 1 0 0 0, 90 Jan 1 1970 /dev/mtd9 brw------- 1 0 0 0, 31 Jan 1 1970 /dev/mtdblock0 brw------- 1 0 0 0, 31 Jan 1 1970 /dev/mtdblock1 brw------- 1 0 0 0, 31 Jan 1 1970 /dev/mtdblock2 brw------- 1 0 0 0, 31 Jan 1 1970 /dev/mtdblock3 brw------- 1 0 0 0, 31 Jan 1 1970 /dev/mtdblock4 brw------- 1 0 0 0, 31 Jan 1 1970 /dev/mtdblock5 brw------- 1 0 0 0, 31 Jan 1 1970 /dev/mtdblock6 brw------- 1 0 0 0, 31 Jan 1 1970 /dev/mtdblock7 brw------- 1 0 0 0, 31 Jan 1 1970 /dev/mtdblock8 brw------- 1 0 0 0, 31 Jan 1 1970 /dev/mtdblock9 -----Message d'origine----- De : Marcos Lois Bermúdez [mailto:securez@xxxxxxxxxxx] Envoyé : mercredi 25 septembre 2002 10:22 À : uclinux-dev@xxxxxxxxxxx Objet : RE: [uClinux-dev] Problem using JFFS on 5272C3 Its major number 31. Take a look in the MTD howto, are a mtdblock devices only for read, and for r/w, at this point i don't remember what are the odd minor number and what are the even. Regards. At 09:02 25/09/2002 +0200, you wrote: >Ok, thank's for your answere. >But how can I make the mtd block device ? With the mknod command ? And >what's major number for this mtd block device ? > >Sorry for this question, but I'm little bit confused about the use of this >device. > > > >-----Message d'origine----- >De : Marcos Lois Bermúdez [mailto:securez@xxxxxxxxxxx] >Envoyé : mardi 24 septembre 2002 18:54 >À : uclinux-dev@xxxxxxxxxxx >Objet : Re: [uClinux-dev] Problem using JFFS on 5272C3 > > >You need to use the mtd block device >/dev/mtdblock4 insead of /dev/mtd4 >the /dev/mtdX are char devices for RAW i/o. > >Regards. > >At 18:12 24/09/2002 +0200, you wrote: > > > >Hi, > >We are running uClinux 2.4.19 on a Coldfire 5272C3 development board. We > >have Colilo, and kernel stored in flash. Kernel is compressed. Colilo >boots, > >and uncompresses kernel into SDRAM at 0x20000 and starts execution there >and > >everything is fine. > >But now i want to use some unused flash with JFFS. I installed the tarrifa > >patch from Bernhard Kuhn and enabled MTD devices as required and followed > >instructions about "Using blkmem and MTD device driver at the same time" . > >I can erase my flash with the erase command : > >/> erase /dev/mtd4 > >Erase Total 1 Units > >Performing Flash Erase of length 262144 at offset 0x0 done > > > >But when I tri to mount the file system I have an error : > >/> mount -t jffs /dev/mtd4 /mnt > >mount failed: Block device required > > > >Do you have an idea ? > >Thank's for reply. > >--------------------------------------------------------------------------- >- > >-------------------- > >Here is the boot up, (this time from debug with "g 20000" not colilo): > >.uClinux/COLDFIRE(m5272) > >COLDFIRE port done by Greg Ungerer, gerg@xxxxxxxxxxxx > >Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne > >On node 0 totalpages: 1024 > >zone(0): 0 pages. > >zone(1): 1024 pages. > >zone(2): 0 pages. > >Kernel command line: > >Calibrating delay loop... 43.62 BogoMIPS > >Memory available: 2172k/4096k RAM, 0k/0k ROM (669k kernel code, 197k data) > >kmem_create: Forcing size word alignment - vm_area_struct > >kmem_create: Forcing size word alignment - mm_struct > >kmem_create: Forcing size word alignment - filp > >Dentry-cache hash table entries: 512 (order: 0, 4096 bytes) > >Inode-cache hash table entries: 512 (order: 0, 4096 bytes) > >kmem_create: Forcing size word alignment - inode_cache > >Mount-cache hash table entries: 512 (order: 0, 4096 bytes) > >kmem_create: Forcing size word alignment - bdev_cache > >kmem_create: Forcing size word alignment - cdev_cache > >Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) > >Page-cache hash table entries: 1024 (order: 0, 4096 bytes) > >POSIX conformance testing by UNIFIX > >Linux NET4.0 for Linux 2.4 > >Based upon Swansea University Computer Society NET3.039 > >kmem_create: Forcing size word alignment - sock > >Initializing RT netlink socket > >Starting kswapd > >kmem_create: Forcing size word alignment - file lock cache > >JFFS version 1.0, (C) 1999, 2000 Axis Communications AB > >kmem_create: Forcing size word alignment - jffs_node > >ColdFire internal UART serial driver version 1.00 > >ttyS0 at 0x10000100 (irq = 73) is a builtin ColdFire UART > >ttyS1 at 0x10000140 (irq = 74) is a builtin ColdFire UART > >kmem_create: Forcing size word alignment - blkdev_requests > >block: 64 slots per queue, batch=16 > >RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize > >eth0: FEC ENET Version 0.2, 00:d0:cf:00:00:72 > >fec: PHY @ 0x0, ID 0x001378e2 -- LXT971 > >SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256). > >CSLIP: code copyright 1989 Regents of the University of California. > >Blkmem copyright 1998,1999 D. Jeff Dionne > >Blkmem copyright 1998 Kenneth Albanowski > >Blkmem 1 disk images: > >0: F8964-1CC163 [VIRTUAL F8964-1CC163] (RO) > >PPP generic driver version 2.4.1 > >physmap flash device TARIFA.C V1.1: 200000 at ffe00000 > > Amd/Fujitsu Extended Query Table v1.0 at 0x0040 > >number of CFI chips: 1 > >Creating 10 MTD partitions on "Physically mapped flash": > >0x00000000-0x00004000 : "boot (16K)" > >0x00080000-0x00100000 : "kernel (512K)" > >0x00100000-0x00200000 : "rootfs (1024K)" > >0x00004000-0x00006000 : "spare (8K)" > >0x00006000-0x00008000 : "spare (8K)" > >0x00040000-0x00080000 : "spare (256K)" > >0x00000000-0x00200000 : "complete (2048K)" > >0x00100000-0x00140000 : "boot J13 (256K)" > >0x00140000-0x001c0000 : "kernel J13 (512K)" > >0x001c0000-0x00200000 : "rootfs J13 (256K)" > >NET4: Linux TCP/IP 1.0 for NET4.0 > >IP Protocols: ICMP, UDP, TCP > >kmem_create: Forcing size word alignment - ip_dst_cache > >IP: routing cache hash table of 512 buckets, 4Kbytes > >TCP: Hash tables configured (established 512 bind 512) > >NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > >jffs_scan_flash(): Did not find even a single chunk of free space. This is > >BAD! > >jffs_scan_falsh():Free size accounting screwed > >jfffs_scan_flash():free_chunk_size1 == 0x4000, free_chunk_size2 == 0x0, > >fmc->fre > >e_size == 0x0 > >JFFS: Failed to mount device 1f:00. > >VFS: Mounted root (romfs filesystem) readonly. > >Freeing unused kernel memory: 24k freed (0xd2000 - 0xd7000) > >Shell invoked to run file: /etc/rc > >Command: hostname uClinux > >Command: /bin/expand /etc/ramfs.img /dev/ram0 > >Command: mount -t proc proc /proc > >Command: mount -t ext2 /dev/ram0 /var > >Command: mkdir /var/tmp > >Command: mkdir /var/log > >Command: mkdir /var/run > >Command: mkdir /var/lock > >tommaned: ifconfig lo 127.0.0.1 > > Command: route add -net h127.0.0.0 netmask 255.0.00.0 lo > >Command: > >Command:: ifconfig eth0 191.1.4.1 10 > >config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX. > >Command: route add -net 191.1.0.0 netmask 255.255.0.0 eth0 > >Command: > >Command: cat /etc/motd > >Welcome to > > ____ _ _ > > / __| ||_| > > _ _| | | | _ ____ _ _ _ _ > > | | | | | | || | _ \| | | |\ \/ / > > | |_| | |__| || | | | | |_| |/ \ > > | ___\____|_||_|_| |_|\____|\_/\_/ > > | | > > |_| > > > >For further information check: > >http://www.uclinux.org/ > >Execution Finished, Exiting > >Sash command shell (version 1.1.1) > >/> eth0: status: link up, 100MBit Full Duplex, auto-negotiation complete > > > > > > > >This message resent by the uclinux-dev@xxxxxxxxxxx list server > >http://www.uClinux.org/ > >This message resent by the uclinux-dev@xxxxxxxxxxx list server >http://www.uClinux.org/ > >This message resent by the uclinux-dev@xxxxxxxxxxx list server >http://www.uClinux.org/ This message resent by the uclinux-dev@xxxxxxxxxxx list server http://www..uClinux.org/ This message resent by the uclinux-dev@xxxxxxxxxxx list server http://www.uClinux.org/

Previous Message by Thread: click to view message preview

Any body can help me?

Hi, List, I've some problems about uC-libc and uClibc. What IPC resource does uC-libc support IPC when I used uClinux2.4.17? I can only find the source codes about shared memeory in the directory of /lib/libc/shm. How can I update the uClibc? Just replace the files with the newer files or replace the whole directory or anything else? I've downloaded a newer set of uClibc(resource codes) but its structure is different from my old uClibc. I don't know how to use it. Same problem about update uClinux. When I make a new image with IPC, errors occurs. I think I have to update the resource codes in the directory of linux-2.4.x / ipc. Just replace them with newer files, all right? Thanks! This message resent by the uclinux-dev@xxxxxxxxxxx list server http://www.uClinux.org/

Next Message by Thread: click to view message preview

Re: Binary file format

Hi Yannis Which processor are you considering here ?? regards Phil Wilshire Yannis Mitsos wrote: > > Hallo, > > In case that the only available tools for a processor are capable of > producing only COFF file format, would be possible to initiate a porting > procedure ? > I suppose that for the building of the kernel it does not impose any > problem (please comment on this if I am wrong). > > Furthermore, it will be necessary to develop a translator from COFF file > format to FLAT file format if we need to load dynamically applications. > Is this possible ? I think for the case of the m68k such an application > exists. > > BTW, is there any other processor that lacks of ELF support and has been > ported to uClinux ? > > Thanks > > Yannis. > > This message resent by the uclinux-dev@xxxxxxxxxxx list server > http://www.uClinux.org/ -- SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com **uClinux Training in Toronto, Oct 2002, email me for details 630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9765 f: 703 669 9768 This message resent by the uclinux-dev@xxxxxxxxxxx list server http://www.uClinux.org/