Re: [uClinux-dev] [PATCH] coldfire 5235 using 3 built in UARTS
Hello Greg, On Mittwoch, 25. Juli 2007, Greg Ungerer wrote: And one style issue. Comments in the kernel should not be c89/c++ style, don't use //. See linux-2.6.x/Documentation/CodingStyle. I had a look: Chapter 7: Commenting Comments are good, but there is also a danger of over-commenting. NEVER try to explain HOW your code works in a comment: it's much better to write the code so that the _working_ is obvious, and it's a waste of time to explain badly written code. Generally, you want your comments to tell WHAT your code does, not HOW. Also, try to avoid putting comments inside a function body: if the function is so complex that you need to separately comment parts of it, you should probably go back to chapter 5 for a while. You can make small comments to note or warn about something particularly clever (or ugly), but try to avoid excess. Instead, put the comments at the head of the function, telling people what it does, and possibly WHY it does it. When commenting the kernel API functions, please use the kerneldoc format. See the files Documentation/kernel-doc-nano-HOWTO.txt and scripts/kernel-doc for details. So can you please show me where Linus has disallowed the //? regards Wolfgang -- Das Leben kann nur rückwärts verstanden, muß aber vorwärts gelebt werden. ___ 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] [PATCH] coldfire 5235 using 3 built in UARTS
Hi Wolfgang, Wolfgang Mües wrote: Hello Greg, On Mittwoch, 25. Juli 2007, Greg Ungerer wrote: And one style issue. Comments in the kernel should not be c89/c++ style, don't use //. See linux-2.6.x/Documentation/CodingStyle. I had a look: Chapter 7: Commenting What kernel version did you get this from? Comments are good, but there is also a danger of over-commenting. NEVER try to explain HOW your code works in a comment: it's much better to write the code so that the _working_ is obvious, and it's a waste of time to explain badly written code. Generally, you want your comments to tell WHAT your code does, not HOW. Also, try to avoid putting comments inside a function body: if the function is so complex that you need to separately comment parts of it, you should probably go back to chapter 5 for a while. You can make small comments to note or warn about something particularly clever (or ugly), but try to avoid excess. Instead, put the comments at the head of the function, telling people what it does, and possibly WHY it does it. When commenting the kernel API functions, please use the kerneldoc format. See the files Documentation/kernel-doc-nano-HOWTO.txt and scripts/kernel-doc for details. So can you please show me where Linus has disallowed the //? Yes, from linux-2.6.22/Documentation/CodingStyle: Chapter 8: Commenting Comments are good, but there is also a danger of over-commenting. NEVER try to explain HOW your code works in a comment: it's much better to write the code so that the _working_ is obvious, and it's a waste of time to explain badly written code. Generally, you want your comments to tell WHAT your code does, not HOW. Also, try to avoid putting comments inside a function body: if the function is so complex that you need to separately comment parts of it, you should probably go back to chapter 6 for a while. You can make small comments to note or warn about something particularly clever (or ugly), but try to avoid excess. Instead, put the comments at the head of the function, telling people what it does, and possibly WHY it does it. When commenting the kernel API functions, please use the kernel-doc format. See the files Documentation/kernel-doc-nano-HOWTO.txt and scripts/kernel-doc for details. Linux style for comments is the C89 /* ... */ style. Don't use C99-style // ... comments. ... 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
[uClinux-dev] latest version build failure on fedora 7
When I'm trying to build unlinux as it says in the README file, it failed! It failed at the end of 'make' ( everything goes smoothly prior to it), it complains that ...failed to merge target specific data of file /usr/local/arm/3.3/lib/ gcc-lib/arm-linux/3.3.1/libgcc.a(_ashldi3.oS) uses hardware FP while Linux uses software FP the hardware/software part of orginal message is not in English, and I translate it. Could anybody tell me what is this and how to solve it? Thank you! ___ 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] [nommu] Unable to allocate RAM for process text/data, errno 12
Hello, I am porting linux 2.6.21-uc0 on an ARM946ES based system, thanks to the proc-arm946.S I had on this maling list, but after managing to boot the kernel I have some problems with flat binaries and initramfs init ! Here is the boot log : [0.00] Linux version 2.6.21-uc0 ([EMAIL PROTECTED]) (gcc version 4.2.0 20070413 (prerelease) (CodeSourcery Sourcery G++ Lite 2007q1-10)) #18 PREEMPT Wed Jul 25 11:37:28 CEST 2007 [0.00] CPU: ARM946E [41059461] revision 1 (ARMv5TE), cr=107d [0.00] Machine: Neotion NP4 [0.00] On node 0 totalpages: 1024 [0.00] DMA zone: 8 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 1016 pages, LIFO batch:0 [0.00] Normal zone: 0 pages used for memmap [0.00] CPU0: D VIVT write-back cache [0.00] CPU0: I cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets [0.00] CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets [0.00] Built 1 zonelists. Total pages: 1016 [0.00] Kernel command line: kgdbwait debug initcall_debug [0.00] NP4 IRQ Init: 32 [0.00] PID hash table entries: 16 (order: 4, 64 bytes) [0.00] NP4 Timer 0 Init. : Freq 10800 Prescaler 256 Period 422 HZ 1000 [0.00] Registering basic NP4 UART Console [0.00] NP4 UART Console Setup [0.001000] Console: colour dummy device 80x30 [0.003000] Dentry cache hash table entries: 1024 (order: 0, 4096 bytes) [0.004000] Inode-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.006000] Memory: 4MB = 4MB total [0.009000] Memory: 3244KB available (676K code, 75K data, 52K init) [0.01] Calibrating delay loop... 52.35 BogoMIPS (lpj=26176) [0.029000] Mount-cache hash table entries: 512 [0.033000] Calling initcall 0x80003d10: ptrace_break_init+0x0/0x30() ... [0.148000] Calling initcall 0x80008edc: seqgen_init+0x0/0x1c() [0.151000] Freeing init memory: 52K [0.152000] Warning: unable to open an initial console. [0.154000] Unable to allocate RAM for process text/data, errno 12 [0.155000] Failed to execute /init [0.156000] Kernel panic - not syncing: No init found. Try passing init= option to kernel. I built a simple init binary using the codesourcery uclinuxeabi toolchain, everything seems correct ! Thanks Neil signature.asc Description: OpenPGP digital signature ___ 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] latest version build failure on fedora 7
Am Mittwoch, den 25.07.2007, 15:44 +0800 schrieb Tony Winslow: When I'm trying to build unlinux as it says in the README file, it failed! It failed at the end of 'make' ( everything goes smoothly prior to it), it complains that ...failed to merge target specific data of file /usr/local/arm/3.3/lib/ gcc-lib/arm-linux/3.3.1/libgcc.a(_ashldi3.oS) uses hardware FP while Linux uses software FP the hardware/software part of orginal message is not in English, and I translate it. Could anybody tell me what is this and how to solve it? Thank you! You will need a toolchain that supports software floating point, if your target system uses software fp. Regards, Erwin ___ 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] [PATCH] sl811 reset delay
a long awaited (for us) usb patch ... - 20 - 50 ms reset delay (some deviced was not correctly detected otherwise) From the Cypress manual (just the last version!): When a device is detected, the first thing that to do is to send it a USB Reset to force it into its default address of zero. The USB 2.0 specification states that for a root hub a device must be reset for a minimum of 50 mS. - driver version info added PS: the solution should be correct for sl811.c also driver, but I've no way to test it. -- Daniele Ziglioli Signal S.r.l. ___ 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] [PATCH] sl811 reset delay
Daniele Ziglioli ha scritto: a long awaited (for us) usb patch ... - 20 - 50 ms reset delay (some deviced was not correctly detected otherwise) From the Cypress manual (just the last version!): When a device is detected, the first thing that to do is to send it a USB Reset to force it into its default address of zero. The USB 2.0 specification states that for a root hub a device must be reset for a minimum of 50 mS. - driver version info added PS: the solution should be correct for sl811.c also driver, but I've no way to test it. oops, the patch is here . -- Daniele Ziglioli Signal S.r.l. --- ../../hc_sl811.c.cvs 2007-07-24 10:23:42.0 +0200 +++ linux-2.4.x/drivers/usb/host/hc_sl811.c 2007-07-24 10:26:30.0 +0200 @@ -8,6 +8,15 @@ * * ! This driver have end of live! Please use hcd/sl811.c instead ! * + * + * 24.07.2007 Ver. 1.01 DZ + * - 20 - 50 ms reset delay (some deviced was not correctly detected otherwise) + * From the Cypress manual: + * When a device is detected, the first thing that to do is to send it a USB Reset to force it into + * its default address of zero. The USB 2.0 specification states that for a root hub a device + * must be reset for a minimum of 50 mS. + * - driver version info added + * * 06.05.2005 DZ,LC * - Support COLDFIRE architecture now. * - restore previus Read back SOF counter HIGH in hc_add_trans(), @@ -72,14 +81,15 @@ #include linux/usb.h #define MODNAME HC_SL811 +#define MODVER 1.01 #undef HC_URB_TIMEOUT #undef HC_SWITCH_INT #undef HC_ENABLE_ISOC -// #define SL811_DEBUG +//#define SL811_DEBUG #define SL811_DEBUG_ERR -// #define SL811_DEBUG_IRQ +//#define SL811_DEBUG_IRQ // #define SL811_DEBUG_VERBOSE #ifdef SL811_DEBUG_ERR @@ -341,7 +351,7 @@ // setup master and full speed SL811Write (hci, SL11H_CTLREG1, 0x08); // reset USB - mdelay (20); // 20ms + mdelay (50); // 50ms SL811Write (hci, SL11H_CTLREG1, 0); // remove SE0 /* disable all interrupts (18.09.2003) */ @@ -379,7 +389,7 @@ DBG (USBReset: low speed Device attached %03X\n, hci-hp.hcport); SL811Write (hci, SL11H_CTLREG1, 0x8); - mdelay (20); + mdelay (50); // 50ms // SL811Write (hci, SL11H_SOFTMRREG, 0xee); /* the same, but better reading (hne) */ SL811Write (hci, SL11H_CTLREG2, 0xee); SL811Write (hci, SL11H_CTLREG1, 0x21); @@ -392,7 +402,7 @@ DBG (USBReset: full speed Device attached %03X \n, hci-hp.hcport); SL811Write (hci, SL11H_CTLREG1, 0x8); - mdelay (20); + mdelay (50); // 50ms // SL811Write (hci, SL11H_SOFTMRREG, 0xae); /* the same, but better reading (hne) */ SL811Write (hci, SL11H_CTLREG2, 0xae); SL811Write (hci, SL11H_CTLREG1, 0x01); @@ -1398,7 +1408,7 @@ } hp-irq = irq; - printk (KERN_INFO __FILE__ : USB SL811 at %x,%x, IRQ %d\n, + printk (KERN_INFO __FILE__ : USB SL811 Ver. %s at %x,%x, IRQ %d\n, MODVER, hp-hcport, hp-hcport2, irq); #ifdef SL811_DEBUG_VERBOSE ___ 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] uClinux-dist-20070130 location
Hi David: I am having the same problem and tried what you suggested and it doesn't work. Also, the same applies to uClinux-dist-20070130.tar.gz. When you try it interactively you get the following diagnostic: VDeck 403 forbidden Server configuration does not allow you access to this page Best Regards Paul R. -- Paul Romero RCOM Communications Software Phone/Fax: (510)339-2628 E-Mail: [EMAIL PROTECTED] ___ 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] R_ARM_PC24 unsupported in this context
Can you try with -mlong-calls or equivalent compilation option? Regards, Sai -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jyothi Gudavalli Sent: Saturday, July 28, 2007 10:19 PM To: uclinux-dev@uclinux.org Subject: [uClinux-dev] R_ARM_PC24 unsupported in this context hi there, I am compiling uClinux-dist-20060803 with linux 2.6.17-uc1. I am getting the following error. Can anyone help me with this. ERROR: reloc type R_ARM_PC24 unsupported in this context ERROR: reloc type R_ARM_PC24 unsupported in this context ERROR: reloc type R_ARM_PC24 unsupported in this context ERROR: reloc type R_ARM_PLT32 unsupported in this context 1270 bad relocs collect2: ld returned 1 exit status make[3]: *** [init] Error 1 make[3]: Leaving directory `/home/jyothi/CMPE295A/n-2.6.17/uClinux- dist/user/init' make[2]: *** [init] Error 2 make[2]: Leaving directory `/home/jyothi/CMPE295A/n-2.6.17/uClinux- dist/user' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/jyothi/CMPE295A/n-2.6.17/uClinux- dist/user' make: *** [subdirs] Error 1 Regards- Jyothi ___ 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] uClinux supports shared memory IPC?
Hi, I am using ColdFire MCF5329EVB and uClinux (2.6.17 kernel, uClibc 0.9.27). I am trying to use shared memory IPC in my application. I enabled SYS V IPC when I configured uClinux kernel. I tried semaphore and message queue. They seem to be working. I added shared memory in my application: #include sys/shm.h Key_t MY_SHM_ID; shmid = shmget ( MY_SHM_ID, 1024, (IP_CREAT | 0666) ); The compilation was OK. However, when I downloaded to my board, the shared memory creation always failed. shmid was always -1. Some people said MCF5329 doesn't have MMU so that it doesn't support shared memory IPC. Other people said shared memory IPC can be used even without MMU. Anybody here can verify if MCF5329 without MMU can use shared memory IPC? Thanks in advance, Allen The information contained in this email and attachments to this email are the proprietary and confidential property of Nucomm, Inc. The information is provided in strict confidence and shall not be reproduced, copied, or used (partially or wholly) in any manner without prior, express written authorization of Nucomm, Inc. ___ 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] [PATCH] Fix segmentation fault in elf2flt on amd64
Hello,
elf2flt crashes on Linux/amd64:
(gdb) run -a -o links -p links.gdb links.gdb
Starting program: /home/stsp/dslinux/toolchain/prefix/bin/arm-linux-elf-elf2flt
-a -o links -p links.gdb links.gdb
Program received signal SIGSEGV, Segmentation fault.
_bfd_elf_canonicalize_reloc (abfd=value optimized out, section=0x5f6900,
relptr=0xa6360010, symbols=value optimized out)
at /home/stsp/dslinux/toolchain/src/binutils-2.17/bfd/elf.c:6367
6367*relptr++ = tblptr++;
(gdb) bt
#0 _bfd_elf_canonicalize_reloc (abfd=value optimized out, section=0x5f6900,
relptr=0xa6360010, symbols=value optimized out)
at /home/stsp/dslinux/toolchain/src/binutils-2.17/bfd/elf.c:6367
#1 0x004006dd in output_relocs (abs_bfd=0x5f5570,
symbols=0x2b30a5e99010, number_of_symbols=16585, n_relocs=0x7fff04c0fe58,
text=0x2b30a6102010 , text_len=value optimized out, text_vma=0,
data=0x2b30a627b010 , data_len=934480, data_vma=1541824,
rel_bfd=0x5f4400)
at /home/stsp/dslinux/toolchain/src/elf2flt-20051225/elf2flt.c:587
#2 0x00401180 in main (argc=value optimized out,
argv=value optimized out)
at /home/stsp/dslinux/toolchain/src/elf2flt-20051225/elf2flt.c:1949
The problem seems to be that the one and only call to xmalloc()
in elf2flt.c does not return a valid pointer for some reason.
I'm wondering why xmalloc() is used exactly once in elf2flt.c.
All other heap allocations in elf2flt are done with plain malloc().
The attached patch fixes the segfault by replacing the call to xmalloc()
with a call to malloc(). It also makes elf2flt check for return
values of malloc() calls, providing the equivalent behaviour of
using xmalloc().
--
stefan
http://stsp.name PGP Key: 0xF59D25F0
? elf2flt-fix-amd64-segfault-and-check-malloc-return-values.diff
Index: elf2flt.c
===
RCS file: /var/cvs/elf2flt/elf2flt.c,v
retrieving revision 1.46
diff -u -r1.46 elf2flt.c
--- elf2flt.c 14 Nov 2006 22:20:08 - 1.46
+++ elf2flt.c 24 Jul 2007 10:43:34 -
@@ -236,6 +236,10 @@
return NULL;
symbol_table = (asymbol **) malloc (storage_needed);
+ if (symbol_table == NULL) {
+ perror(malloc);
+ exit(1);
+ }
number_of_symbols = bfd_canonicalize_symtab (abfd, symbol_table);
@@ -492,7 +496,12 @@
}
symb = get_symbols(rel_bfd, nsymb);
- relpp = (arelent **) xmalloc(relsize);
+ relpp = (arelent **) malloc(relsize);
+ if (relpp == NULL) {
+ perror(malloc);
+ exit(1);
+ }
+
relcount = bfd_canonicalize_reloc(rel_bfd, r, relpp, symb);
if (relcount = 0) {
if (verbose)
@@ -1975,6 +1984,10 @@
}
text = malloc(text_len);
+ if (text == NULL) {
+ perror(malloc);
+ exit(1);
+ }
if (verbose)
printf(TEXT - vma=0x%x len=0x%x\n, text_vma, text_len);
@@ -1995,6 +2008,10 @@
exit (2);
}
data = malloc(data_len);
+ if (data == NULL) {
+ perror(malloc);
+ exit(1);
+ }
if (verbose)
printf(DATA - vma=0x%x len=0x%x\n, data_vma, data_len);
@@ -2079,6 +2096,10 @@
if (!ofile) {
ofile = malloc(strlen(fname) + 5 + 1); /* 5 to add suffix */
+if (ofile == NULL) {
+ perror(malloc);
+ exit(1);
+}
strcpy(ofile, fname);
strcat(ofile, .bflt);
}
pgpXyZM4ZjsR7.pgp
Description: PGP signature
___
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-dist-20070130 location
Hi Paul, Paul Romero wrote: I am having the same problem and tried what you suggested and it doesn't work. Also, the same applies to uClinux-dist-20070130.tar.gz. When you try it interactively you get the following diagnostic: VDeck 403 forbidden Server configuration does not allow you access to this page Something does look to be broken. I have notified the sysadmins. 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
Re: [uClinux-dev] [PATCH] Fix segmentation fault in elf2flt on amd64
Resending in one piece because the archive munged my message.
Sorry for the noise.
On Wed, Jul 25, 2007 at 11:51:42PM +0200, Stefan Sperling wrote:
Hello,
elf2flt crashes on Linux/amd64:
(gdb) run -a -o links -p links.gdb links.gdb
Starting program: /home/stsp/dslinux/toolchain/prefix/bin/arm-linux-elf-elf2flt
-a -o links -p links.gdb links.gdb
Program received signal SIGSEGV, Segmentation fault.
_bfd_elf_canonicalize_reloc (abfd=value optimized out, section=0x5f6900,
relptr=0xa6360010, symbols=value optimized out)
at /home/stsp/dslinux/toolchain/src/binutils-2.17/bfd/elf.c:6367
6367*relptr++ = tblptr++;
(gdb) bt
#0 _bfd_elf_canonicalize_reloc (abfd=value optimized out, section=0x5f6900,
relptr=0xa6360010, symbols=value optimized out)
at /home/stsp/dslinux/toolchain/src/binutils-2.17/bfd/elf.c:6367
#1 0x004006dd in output_relocs (abs_bfd=0x5f5570,
symbols=0x2b30a5e99010, number_of_symbols=16585, n_relocs=0x7fff04c0fe58,
text=0x2b30a6102010 , text_len=value optimized out, text_vma=0,
data=0x2b30a627b010 , data_len=934480, data_vma=1541824,
rel_bfd=0x5f4400)
at /home/stsp/dslinux/toolchain/src/elf2flt-20051225/elf2flt.c:587
#2 0x00401180 in main (argc=value optimized out,
argv=value optimized out)
at /home/stsp/dslinux/toolchain/src/elf2flt-20051225/elf2flt.c:1949
The problem seems to be that the one and only call to xmalloc()
in elf2flt.c does not return a valid pointer for some reason.
I'm wondering why xmalloc() is used exactly once in elf2flt.c.
All other heap allocations in elf2flt are done with plain malloc().
The attached patch fixes the segfault by replacing the call to xmalloc()
with a call to malloc(). It also makes elf2flt check for return
values of malloc() calls, providing the equivalent behaviour of
using xmalloc().
Index: elf2flt.c
===
RCS file: /var/cvs/elf2flt/elf2flt.c,v
retrieving revision 1.46
diff -u -r1.46 elf2flt.c
--- elf2flt.c 14 Nov 2006 22:20:08 - 1.46
+++ elf2flt.c 24 Jul 2007 10:43:34 -
@@ -236,6 +236,10 @@
return NULL;
symbol_table = (asymbol **) malloc (storage_needed);
+ if (symbol_table == NULL) {
+ perror(malloc);
+ exit(1);
+ }
number_of_symbols = bfd_canonicalize_symtab (abfd, symbol_table);
@@ -492,7 +496,12 @@
}
symb = get_symbols(rel_bfd, nsymb);
- relpp = (arelent **) xmalloc(relsize);
+ relpp = (arelent **) malloc(relsize);
+ if (relpp == NULL) {
+ perror(malloc);
+ exit(1);
+ }
+
relcount = bfd_canonicalize_reloc(rel_bfd, r, relpp, symb);
if (relcount = 0) {
if (verbose)
@@ -1975,6 +1984,10 @@
}
text = malloc(text_len);
+ if (text == NULL) {
+ perror(malloc);
+ exit(1);
+ }
if (verbose)
printf(TEXT - vma=0x%x len=0x%x\n, text_vma, text_len);
@@ -1995,6 +2008,10 @@
exit (2);
}
data = malloc(data_len);
+ if (data == NULL) {
+ perror(malloc);
+ exit(1);
+ }
if (verbose)
printf(DATA - vma=0x%x len=0x%x\n, data_vma, data_len);
@@ -2079,6 +2096,10 @@
if (!ofile) {
ofile = malloc(strlen(fname) + 5 + 1); /* 5 to add suffix */
+if (ofile == NULL) {
+ perror(malloc);
+ exit(1);
+}
strcpy(ofile, fname);
strcat(ofile, .bflt);
}
--
stefan
http://stsp.name PGP Key: 0xF59D25F0
___
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] [PATCH] BSP for Savant CPU card
Hi Wilson, Wilson Callan wrote: Thank you for applying the BSP patch, and the Encode Chip Select QSPI patch. Sorry about the bad m523xsim.h patch. I've attached a patch just for this, but actually you dont need it because you've applied the qspiCS.patch which contained this file. Yeah, I noticed that after I applied the first patch, but before I had hit the others :-) In fact, this patch will probably now fail against the latest because they differ. I changed it because there was a bad, but harmless, merge in my m5235xsim.h before which i recently fixed. A patch of the fix would look like this below, which may be what you want to run. UART0, PIT1 and QSPI were repeated again below, out of order, with the same numbers. sorry for the confusion. No problem. Patch below applied too. Regards Greg --- uClinux-dist-bsp/linux-2.6.x/include/asm-m68knommu/m523xsim.h 2007-07-16 16:44:53.0 -0400 +++ uClinux-dist-patch-bsp/linux-2.6.x/include/asm-m68knommu/m523xsim.h 2007-07-25 14:18:12.0 -0400 @@ -30,9 +30,6 @@ /* INTC0 */ #defineMCFINT_VECBASE64/* Vector base number */ -#defineMCFINT_UART013/* Interrupt number for UART0 */ -#defineMCFINT_PIT136/* Interrupt number for PIT1 */ -#defineMCFINT_QSPI18/* Interrupt number for QSPI */ #defineMCFINT_EPF22/* Interrupt number for EPORT2 */ #defineMCFINT_EPF33/* Interrupt number for EPORT3 */ #defineMCFINT_EPF44/* Interrupt number for EPORT4 */ Wilson On Jul 25, 2007, at 12:00 PM, [EMAIL PROTECTED] wrote: -- Message: 3 Date: Wed, 25 Jul 2007 14:19:36 +1000 From: Greg Ungerer [EMAIL PROTECTED] Subject: Re: [uClinux-dev] [PATCH] BSP for Savant CPU card To: uClinux development list uclinux-dev@uclinux.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi Wilson, Wilson Callan wrote: Hi, attached is a patch file to support our CPU card on patch 20070718. Changes from my previous submit: 1) removed change in setup.c 2) made a separate function for changes needed in config_BSP() I suspect the bootparm code will not be acceptable to mainline. But I committed it to the uClinux sources. Except m523xsim.h, which didn't patch cleanly: goober patch -p1 /home/gerg/tmp/patches/savantBSP20070718-2.patch patching file linux-2.6.x/arch/m68knommu/defconfig patching file linux-2.6.x/arch/m68knommu/Kconfig patching file linux-2.6.x/arch/m68knommu/Makefile patching file linux-2.6.x/drivers/serial/mcfserial.c patching file linux-2.6.x/include/asm-m68knommu/m523xsim.h patch: malformed patch at line 110: @@ -42,4 +73,122 @@ Can you generate a patch just for this and send please? 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 -- 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] [PATCH] sl811 reset delay
Hi Daniele, I suppose this fix is also applicable to the sl811.c, isn't it? I'll generate a patch to the sl811.c (and also add support for a 5282 board) Regards, Daniel En/na Daniele Ziglioli ha escrit: Daniele Ziglioli ha scritto: a long awaited (for us) usb patch ... - 20 - 50 ms reset delay (some deviced was not correctly detected otherwise) From the Cypress manual (just the last version!): When a device is detected, the first thing that to do is to send it a USB Reset to force it into its default address of zero. The USB 2.0 specification states that for a root hub a device must be reset for a minimum of 50 mS. - driver version info added PS: the solution should be correct for sl811.c also driver, but I've no way to test it. oops, the patch is here . ___ 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 -- Daniel Alomar i Claramonte Research Development Electronic Dept. SERRA SOLDADURA, S.A. WEB Site: http://www.serrasold.com Knowledge Site: http://serratron.serrasold.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-dist-20070130 location
Evnin' You can download from me: http://www.uclinux.net/index.php?option=com_docmantask=cat_viewgid=25Itemid=29 ...although it requires registering due to heavy abuse lately and I have to pay for the bandwidth out my own pocket (o; cheers rick Paul Romero schrieb: Hi David: I am having the same problem and tried what you suggested and it doesn't work. Also, the same applies to uClinux-dist-20070130.tar.gz. When you try it interactively you get the following diagnostic: VDeck 403 forbidden Server configuration does not allow you access to this page Best Regards Paul R. -- Paul Romero RCOM Communications Software Phone/Fax: (510)339-2628 E-Mail: [EMAIL PROTECTED] ___ 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] [PATCH] BSP for Savant CPU card
Hi Greg, Thank you for applying the BSP patch, and the Encode Chip Select QSPI patch. Sorry about the bad m523xsim.h patch. I've attached a patch just for this, but actually you dont need it because you've applied the qspiCS.patch which contained this file. In fact, this patch will probably now fail against the latest because they differ. I changed it because there was a bad, but harmless, merge in my m5235xsim.h before which i recently fixed. A patch of the fix would look like this below, which may be what you want to run. UART0, PIT1 and QSPI were repeated again below, out of order, with the same numbers. sorry for the confusion. --- uClinux-dist-bsp/linux-2.6.x/include/asm-m68knommu/m523xsim.h 2007-07-16 16:44:53.0 -0400 +++ uClinux-dist-patch-bsp/linux-2.6.x/include/asm-m68knommu/ m523xsim.h 2007-07-25 14:18:12.0 -0400 @@ -30,9 +30,6 @@ /* INTC0 */ #define MCFINT_VECBASE 64 /* Vector base number */ -#defineMCFINT_UART013 /* Interrupt number for UART0 */ -#defineMCFINT_PIT1 36 /* Interrupt number for PIT1 */ -#defineMCFINT_QSPI 18 /* Interrupt number for QSPI */ #define MCFINT_EPF2 2 /* Interrupt number for EPORT2 */ #define MCFINT_EPF3 3 /* Interrupt number for EPORT3 */ #define MCFINT_EPF4 4 /* Interrupt number for EPORT4 */ savantInclude.patch Description: Binary data Wilson On Jul 25, 2007, at 12:00 PM, [EMAIL PROTECTED] wrote: -- Message: 3 Date: Wed, 25 Jul 2007 14:19:36 +1000 From: Greg Ungerer [EMAIL PROTECTED] Subject: Re: [uClinux-dev] [PATCH] BSP for Savant CPU card To: uClinux development list uclinux-dev@uclinux.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi Wilson, Wilson Callan wrote: Hi, attached is a patch file to support our CPU card on patch 20070718. Changes from my previous submit: 1) removed change in setup.c 2) made a separate function for changes needed in config_BSP() I suspect the bootparm code will not be acceptable to mainline. But I committed it to the uClinux sources. Except m523xsim.h, which didn't patch cleanly: goober patch -p1 /home/gerg/tmp/patches/savantBSP20070718-2.patch patching file linux-2.6.x/arch/m68knommu/defconfig patching file linux-2.6.x/arch/m68knommu/Kconfig patching file linux-2.6.x/arch/m68knommu/Makefile patching file linux-2.6.x/drivers/serial/mcfserial.c patching file linux-2.6.x/include/asm-m68knommu/m523xsim.h patch: malformed patch at line 110: @@ -42,4 +73,122 @@ Can you generate a patch just for this and send please? 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
