Re: [uClinux-dev] Moving to new kernel distro
Hi Roger, Roger Thornblad wrote: I couldn't get the 2.6.x kernel to work on my 5407C3 yet I did get the 2.4.x up so I'm now doing the work to get one of our platforms up and running on 2.4.x to get familiar with the new distro. It appears the config info is very different between 2.4.x and 2.6.x kernels. Is this correct or did I miss something. Yes. There is a few fundamental config changes for ColdFire, aimed at making the config much more flexible. In particular the memory layout is completely configurable, instead of hard defined in header files. Also the clocking has been made completely flexible. Can anyone suggest a good place for me to start (docs, websites, etc) to get info on configuring the 2.6.x kernel for coldfire? I didn't really document it much outside of the Kconfig help. That would be a good place to start, it describes each of the config options quite well :-) Also look at the example configurations in the kernel sources (at linux-2.6.x/arch/m68knommu/config/*) and also target configs udner vendors in the uClinux-dist. Essentially I need to get the following mem FLASH0x for 16 Megs RAM starts @ 0x0400 for 32 Megs The RAM setup should be easy now with the config options. Depending on your FLASH mapping needs you may need a map driver, or you may be able to just use physmap. Peripherals 1 Quad UART 16550A's In theory this should be setup as a platform device, in the platform config. In theory it should be easy :-) Network 1 SMSC LAN91C111 In the last few days I got the SMSC91c111 running again on the Freescale M5249 dev board. Using the smc91x driver it is reasonably strait forward. I'll send the patch in another email. I intend merging the changes upstream to get them back into mainline. (The setup is a platform device). timer in 2.0.x 2.4.x we run the timer on IRQ 30 instead of 29. I assume I need to do the same for 2.6.x. I just need to track down where this happens. Also in the last couple of weeks I have been reworking the ColdFire interrupt controller code. Making setup and driver use easier. As part of this I was planning to make the old style ColdFire parts that used the timer on IRQ29 use IRQ30. I can't see any reason not too (at least on IRQ30 we don't clash with external IRQ5 on the 5307/5407). The interrupt controller changes are still a work in progress, but if anyone is interested they can get them via git at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git irqs I still have some more changes planned in this area. I'll start looking @ 2.6.x as soon as I have my board running on 2.4.x Be interrested in what is stopping the code as is running on the 5407C3. 1 Question concerning In Circuit Debuggers. I noticed on the 2.4.x kernel there is an idle loop that shuts down the processor (I assume for power savings). Anyway our debugger stops the system every time this happens. To work around this quickly I noop the STOP instruction and things seem OK. My questions are: 1. What impact on operations (if any) does this have on the kernel. Ie is this a bad solution? Not a problem at all. In practice the stop instruction didn't really seem to save us much. The ColdFire isn't really a low power device anyways. 2. Is there a better solution besides letting the idle loop run all the time? Not that I can think of. Regards Greg Last Question Do lots of you out there use In Circuit debuggers/emulators? If so, is there a general favorite out there? I would like to get something that supports trace. -Original Message- From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org] On Behalf Of Roger Thornblad Sent: Friday, May 15, 2009 11:36 AM To: 'uClinux development list' Subject: RE: [uClinux-dev] Moving to new kernel distro Hi Michael, Thanks for the reponse. This all sounds very promising. I'm going ahead with the eval board acquisition and will update when I know more. Regards, -Roger -Original Message- From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org] On Behalf Of Michael Durrant Sent: Thursday, May 14, 2009 2:44 PM To: uClinux development list Subject: Re: [uClinux-dev] Moving to new kernel distro Roger, The MCF5328, MCF53281, MCF5329 processors are all supported in kernels greater than 2.6.21. Freescale's LTIB Kernel release is not in sync with the public kernel. I understand that Freescale has both an OTG and host USB driver written but their released patched for the OTG and the patches for the host mode USB were not accepted by the Kernel USB maintainers. The uClinux-dist kernel release based on 2.6.21 we have used at Arcturus Networks for our uC532x modules does support USB thumb drives. The patches we have tested from Freescale for USB in the newer kernel
Re: [uClinux-dev] driver for TSE MAC or Marvell 88E1111 Ethernet
On 05/21/2009 01:54 PM, Jan Naceradsky wrote: To All, we try to use uCLinux for Altera NIOSII with Stratix III DSP development kit and we want to use Marvell 88E Ethernet transceiver for ethernet communication (in Altera they speek about TSE MAC or Triple Speed Ethernet). Hi Jan, Please check the nios wiki at http://www.nioswiki.com/OperatingSystems/UClinux. There are drivers for Altera TSE. They use platform device, so you will need to check the instant name of TSE components again the file arch/nios2/kernel/config.c. For nios2 specific dicussion, you may subscribe and post on the nios2-dev mailing list. http://sopc.et.ntust.edu.tw/cgi-bin/mailman/listinfo/nios2-dev Cheer, Thomas ___ 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] new uClinux-dist patch
Hi All, I have started an upload of a new uClinux-dist patch, at: http://www.uclinux.org/pub/uClinux/dist/patches/uClinux-dist-20080808-20090520.patch.gz It won't all be there for probably about 24 hours. So hold of downloading 'till tomorrow :-) It includes a linux-2.6.29 kernel, and other various fixes and source updates - nothing major. I think most targets work as well as the did with the 2.6.26 kernel in there. (Excepting ARMulator I think, I haven't had time to look at it yet). As usual please post any patches and fixes here. (I may be a little slow in responding for the next couple of weeks, I'll be away). I haven't released a linux-2.6.29-uc0 patch set as I normally would. Instead I have been pushing my changes into the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git And then promoting them from there. Means less work for me :-) But, are people attached to using the -uc patch series? Does anyone still want me to create them? So far in that git tree in the for-linus branch is a set of changes to clean up the various ColdFire reset/reboot code, it should work much better on all platforms now. There is some more merged include file cleanups in the includes branch. The biggest changes in that git tree and some interrupt controller improvements I am working on. There is now specific support code for each of the various types of interrupt controllers used in the various ColdFire parts. The support for the new parts with the larger more flexible interrupt controllers is clean and nice (so for 5208, 5235, 5271/5275, 5282, 5329 and their type). The code for the older parts (5206, 5249, 5307, 5407, etc) is better, but I am still working to improve it a little more. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +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] Re: errors when linking without XIP
Hi Greg, I have used this a lot for applications without XIP in the meantime, it works fine. I just wanted to note that running elf2flt without the -a option does NOT work. Sorry that I didn't make a neat patch, just not enough time. -Erwin Am Donnerstag, den 21.05.2009, 16:57 +1000 schrieb Greg Ungerer: Hi Erwin, Erwin Authried wrote: Hi, I have solved the reloc type R_ARM_PC24 unsupported in this context error by modifying elf2flt.c: -Erwin ... #elif defined(TARGET_arm) case R_ARM_ABS32: relocation_needed = 1; break; case R_ARM_REL32: case R_ARM_THM_PC11: case R_ARM_THM_PC22: // == add the following 4 lines: case R_ARM_PC24: case R_ARM_PLT32: case R_ARM_GOTPC: case R_ARM_GOT32: relocation_needed = 0; break; default: goto bad_resolved_reloc; Thats looks right to me. I think we can go ahead and push that into the elf2flt CVS? Regards Greg Am Mittwoch, den 20.05.2009, 12:29 -0400 schrieb Jeff Bacon: Hi, I've just started on a uClinux 2.6 port to a custom ARM7TDMI board (we've had a uClinux 2.4 kernel running with no problems for a couple of years now, but decided to take the plunge and upgrade). I just joined the mailing list and am trying to resurrect the thread below from Erwin... First. here is some background on where we are right now We are currently using the same base kernel and toolchain mentioned below(uClinux-dist-20080808, snapgear toolchain arm-linux-tools-20070808.tar.gz) and we're having a ton of issues with getting our XIP ROMFS root filesystem working out of flash (the kernel boots, the filesystem mounts and I get a SASH prompt, but the system is HIGHLY unstable and usually crashes after a couple of commands). In fact, basic things are broken such as cat. I've set the init=/bin/sh kernel parameter to boot immediately into the shell, but if I try cat /etc/motd, I get a ton of output like this(note, ROMFS debugging is turned ON): snip VFS: Mounted root (romfs filesystem) readonly. Freeing init memory: 76K BINFMT_FLAT: ROM mapping of file (we hope) BINFMT_FLAT: Allocated data+bss+stack (21094 bytes): 2b8004 p=2bfffc start_thread(regs=0x1eff08, entry=0x280044, start_stack=0x2bffb8) Sash command shell (version 1.1.1) / ls /etc BINFMT_FLAT: ROM mapping of file (we hope) BINFMT_FLAT: Allocated data+bss+stack (10894 bytes): 2f0004 p=2f3ffc start_thread(regs=0x2c7fb0, entry=0x2e0044, start_stack=0x2f3f80) inittabmodprobe.conf motd passwd ramfs.img rc services version / cat /etc/motd BINFMT_FLAT: ROM mapping of file (we hope) BINFMT_FLAT: Allocated data+bss+stack (11541 bytes): 2cc004 p=2cfffc start_thread(regs=0x2b7fb0, entry=0x2c8044, start_stack=0x2cff78) : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory / Mounting /proc works, but I can't cat any of those files as well, but either way, the system only SOMETIMES makes it this far before dying completely (just stalls, no kernel panics or oops or anything). Anyway, while trying to debug this, the first thing I tried was taking Flash out of the equation. So in my bootloader I restrict system RAM to 4MB (we have an 8MB part) and copy the ROMFS image from flash into the 2nd 4MB of RAM. I add the mem=4MB kernel parameter to restrict uClinux to the 1st 4MB of RAM, then compiled the uclinux MTD driver and gave it the location of the ROMFS in the 2nd half of RAM. The kernel boots and the uclinux mtd driver finds and mounts it and I get the prompt again, but the behavior is exactly the same, highly
Re: [uClinux-dev] driver for TSE MAC or Marvell 88E1111 Ethernet
Hi Thomas, thank you, I believe that the error will be in config.c - different name of TSE component in ptf and in .c file. (today i needed to do something another). Jan --- On Thu, 5/21/09, Thomas Chou tho...@wytron.com.tw wrote: From: Thomas Chou tho...@wytron.com.tw Subject: Re: [uClinux-dev] driver for TSE MAC or Marvell 88E Ethernet To: uClinux development list uclinux-dev@uclinux.org Date: Thursday, May 21, 2009, 8:15 AM On 05/21/2009 01:54 PM, Jan Naceradsky wrote: To All, we try to use uCLinux for Altera NIOSII with Stratix III DSP development kit and we want to use Marvell 88E Ethernet transceiver for ethernet communication (in Altera they speek about TSE MAC or Triple Speed Ethernet). Hi Jan, Please check the nios wiki at http://www.nioswiki.com/OperatingSystems/UClinux. There are drivers for Altera TSE. They use platform device, so you will need to check the instant name of TSE components again the file arch/nios2/kernel/config.c. For nios2 specific dicussion, you may subscribe and post on the nios2-dev mailing list. http://sopc.et.ntust.edu.tw/cgi-bin/mailman/listinfo/nios2-dev Cheer, Thomas ___ 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
Re: [uClinux-dev] RAM disk?
Hello Not thought of it the SD card, but I guess it would be slower and would also have problems doing numerous writings on the same sector. The application consists of an access control has saved many .gif and .avi (3MB) and the sqlite database. The files of the images and videos taken out by another port several times and has processed when inserted into the database file and the id of the id of the user. This may be 2 or 3 times per second, but not always, there will be cases where users have to process 15 can be disposed as 4 hours without any processing. Thank you. Greetings Antony 2009/5/18 Bob Amstadt b...@looperlative.com I´m designing a hardware Coldfire with which I have to save some data, I have thought about using sqlite.He plan to use a 512MB ram memory to store the database and connect to a data bus, had also thought about compact flash but make several writes, I thought that could damage quickly, so thought in RAM. How quickly are you changing data? Have you done any tests with an SD card. You may find that it has a life more than long enough for your application. ___ 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
Re: [uClinux-dev] new uClinux-dist patch
On Thu, May 21, 2009 at 04:53:33PM +1000, Greg Ungerer wrote: I have started an upload of a new uClinux-dist patch, at: http://www.uclinux.org/pub/uClinux/dist/patches/uClinux-dist-20080808-20090520.patch.gz It won't all be there for probably about 24 hours. So hold of downloading 'till tomorrow :-) It includes a linux-2.6.29 kernel, and other various fixes and source updates - nothing major. I think most targets work as well as the did with the 2.6.26 kernel in there. (Excepting ARMulator I think, I haven't had time to look at it yet). As usual please post any patches and fixes here. (I may be a little slow in responding for the next couple of weeks, I'll be away). I haven't released a linux-2.6.29-uc0 patch set as I normally would. Instead I have been pushing my changes into the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git And then promoting them from there. Means less work for me :-) But, are people attached to using the -uc patch series? Does anyone still want me to create them? So far in that git tree in the for-linus branch is a set of changes to clean up the various ColdFire reset/reboot code, it should work much better on all platforms now. There is some more merged include file cleanups in the includes branch. The biggest changes in that git tree and some interrupt controller improvements I am working on. There is now specific support code for each of the various types of interrupt controllers used in the various ColdFire parts. The support for the new parts with the larger more flexible interrupt controllers is clean and nice (so for 5208, 5235, 5271/5275, 5282, 5329 and their type). The code for the older parts (5206, 5249, 5307, 5407, etc) is better, but I am still working to improve it a little more. What kind of improvements does the new interrupt code bring (specifically for the 5271 that I am using)? Faster, more flexible, cleaner code? -- Len Sorensen ___ 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] Re: errors when linking without XIP
All, I wanted to update my situation for anyone who was following this thread. I downloaded the source for the toolchain I was using from the snapgear ftp server and re-built binutils and elf2flt making the mod Erwin suggested(had to re-build bin-utils because libbfd.a was not in the pre-compiled toolchain for whatever reason). I then replaced my versions of arm-linux-elf2flt with the new one and re-compiled everything, turning off XIP in my config.arch directory and I am pleased to say that the system works much smoother now, none of the issues I described below are occurring anymore(at least in my limited testing thus far)! After spending several hours going through the mail history of this list last night, I was able to piece together that XIP for arm7tdmi was busted for the stock 888 source tree, but one David Howells had provided a set of patches for getting MTD+ROMFS+XIP to play well together. I'm going to try out that patchset this evening and see if it does indeed work. Thanks again Erwin (And Greg and Jun and David and all other frequent posters), I almost feel like you're all family after the hours I spent reading many of your posts and discussions (many useful insights came out of this that I intend on following up on). -JB On Thu, May 21, 2009 at 6:00 AM, Erwin Authried ea...@softsys.co.at wrote: Hi Greg, I have used this a lot for applications without XIP in the meantime, it works fine. I just wanted to note that running elf2flt without the -a option does NOT work. Sorry that I didn't make a neat patch, just not enough time. -Erwin Am Donnerstag, den 21.05.2009, 16:57 +1000 schrieb Greg Ungerer: Hi Erwin, Erwin Authried wrote: Hi, I have solved the reloc type R_ARM_PC24 unsupported in this context error by modifying elf2flt.c: -Erwin ... #elif defined(TARGET_arm) case R_ARM_ABS32: relocation_needed = 1; break; case R_ARM_REL32: case R_ARM_THM_PC11: case R_ARM_THM_PC22: // == add the following 4 lines: case R_ARM_PC24: case R_ARM_PLT32: case R_ARM_GOTPC: case R_ARM_GOT32: relocation_needed = 0; break; default: goto bad_resolved_reloc; Thats looks right to me. I think we can go ahead and push that into the elf2flt CVS? Regards Greg Am Mittwoch, den 20.05.2009, 12:29 -0400 schrieb Jeff Bacon: Hi, I've just started on a uClinux 2.6 port to a custom ARM7TDMI board (we've had a uClinux 2.4 kernel running with no problems for a couple of years now, but decided to take the plunge and upgrade). I just joined the mailing list and am trying to resurrect the thread below from Erwin... First. here is some background on where we are right now We are currently using the same base kernel and toolchain mentioned below(uClinux-dist-20080808, snapgear toolchain arm-linux-tools-20070808.tar.gz) and we're having a ton of issues with getting our XIP ROMFS root filesystem working out of flash (the kernel boots, the filesystem mounts and I get a SASH prompt, but the system is HIGHLY unstable and usually crashes after a couple of commands). In fact, basic things are broken such as cat. I've set the init=/bin/sh kernel parameter to boot immediately into the shell, but if I try cat /etc/motd, I get a ton of output like this(note, ROMFS debugging is turned ON): snip VFS: Mounted root (romfs filesystem) readonly. Freeing init memory: 76K BINFMT_FLAT: ROM mapping of file (we hope) BINFMT_FLAT: Allocated data+bss+stack (21094 bytes): 2b8004 p=2bfffc start_thread(regs=0x1eff08, entry=0x280044, start_stack=0x2bffb8) Sash command shell (version 1.1.1) / ls /etc BINFMT_FLAT: ROM mapping of file (we hope) BINFMT_FLAT: Allocated data+bss+stack (10894 bytes): 2f0004 p=2f3ffc start_thread(regs=0x2c7fb0, entry=0x2e0044, start_stack=0x2f3f80) inittab modprobe.conf motd passwd ramfs.img rc services version / cat /etc/motd BINFMT_FLAT: ROM mapping of file (we hope) BINFMT_FLAT: Allocated data+bss+stack (11541 bytes): 2cc004 p=2cfffc start_thread(regs=0x2b7fb0, entry=0x2c8044, start_stack=0x2cff78) : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such
Re: [uClinux-dev] Re: errors when linking without XIP
On Wed, May 20, 2009 at 02:15:57PM -0400, Jeff Bacon wrote:
Thanks! I will try this out and see if it helps. Just curious if you had any
thoughts on the rest of my message (any places I should look to for
troubleshooting)?
Cheers,
JB
Try with this toolchain:
arm-linux-tools-20061213.tar.gz
You also might want to have a look at this:
http://www.mailinglistarchive.com/g...@gcc.gnu.org/msg04571.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28194
I actually run into the same problem and after quite some
debugging I found one of the problems to be in
uClibc/libc/stdlib/_atexit.c.
/*
* Normal program termination
*/
void exit(int rv)
{
/* Perform exit-specific cleanup (atexit and on_exit) */
__UCLIBC_MUTEX_LOCK(__atexit_lock);
if (__exit_cleanup) {
__exit_cleanup(rv);
}
__UCLIBC_MUTEX_UNLOCK(__atexit_lock);
__uClibc_fini();
/* If we are using stdio, try to shut it down. At the very least,
* this will attempt to commit all buffered writes. It may also
* unbuffer all writable files, or close them outright.
* Check the stdio routines for details. */
if (_stdio_term)
_stdio_term();
_exit(rv);
}
The relevant output from objdump -S user/filetuils/cat.gdb looks
like this
0c6c __GI_exit:
snip
cd8: e59f3028 ldr r3, [pc, #40] ; d08 __GI_exit+0x9c
cdc: e09a3003 adds r3, sl, r3
ce0: 11a0e00f movne lr, pc
ce4: 11a0f003 movne pc, r3
ce8: e1a5 mov r0, r5
cec: eb09 bl 544 __GI_abort+0xe8
cf0: 0048 andeq r0, r0, r8, asr #32
cf4: 0024 andeq r0, r0, r4, lsr #32
cf8: 002c andeq r0, r0, ip, lsr #32
cfc: 000c andeq r0, r0, ip
d00: 1c9c muleq r0, ip, ip
d04: 0014 andeq r0, r0, r4, lsl r0
d08: ebe0 undefined instruction 0xebe0
Important to know, that the sl register points to the global
offset table
1420 0 OBJECT LOCAL HIDDEN3 _GLOBAL_OFFSET_TABLE_
So 0x1420 + 0xebe0 is zero, actually saying that
_stdio_term is undefined.
When the code is loaded it gets relocated, and the sl register
contains a value other than 0x1420. Hence it jumps wherever
something + 0xebe0 points to.
Kind regards
Andreas Fenkart
___
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] Re: errors when linking without XIP
Andreas,
Very useful information to know. So it would appear that the long
and short of it is to use the GCC 3.4.4 toolchain for now if I want to
do XIP on my platform. I will give this a try as well and see what the
results are.
Regards,
JB
On Thu, May 21, 2009 at 5:50 PM, Andreas Fenkart
andreas.fenk...@streamunlimited.com wrote:
On Wed, May 20, 2009 at 02:15:57PM -0400, Jeff Bacon wrote:
Thanks! I will try this out and see if it helps. Just curious if you had any
thoughts on the rest of my message (any places I should look to for
troubleshooting)?
Cheers,
JB
Try with this toolchain:
arm-linux-tools-20061213.tar.gz
You also might want to have a look at this:
http://www.mailinglistarchive.com/g...@gcc.gnu.org/msg04571.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28194
I actually run into the same problem and after quite some
debugging I found one of the problems to be in
uClibc/libc/stdlib/_atexit.c.
/*
* Normal program termination
*/
void exit(int rv)
{
/* Perform exit-specific cleanup (atexit and on_exit) */
__UCLIBC_MUTEX_LOCK(__atexit_lock);
if (__exit_cleanup) {
__exit_cleanup(rv);
}
__UCLIBC_MUTEX_UNLOCK(__atexit_lock);
__uClibc_fini();
/* If we are using stdio, try to shut it down. At the very least,
* this will attempt to commit all buffered writes. It may also
* unbuffer all writable files, or close them outright.
* Check the stdio routines for details. */
if (_stdio_term)
_stdio_term();
_exit(rv);
}
The relevant output from objdump -S user/filetuils/cat.gdb looks
like this
0c6c __GI_exit:
snip
cd8: e59f3028 ldr r3, [pc, #40] ; d08 __GI_exit+0x9c
cdc: e09a3003 adds r3, sl, r3
ce0: 11a0e00f movne lr, pc
ce4: 11a0f003 movne pc, r3
ce8: e1a5 mov r0, r5
cec: eb09 bl 544 __GI_abort+0xe8
cf0: 0048 andeq r0, r0, r8, asr #32
cf4: 0024 andeq r0, r0, r4, lsr #32
cf8: 002c andeq r0, r0, ip, lsr #32
cfc: 000c andeq r0, r0, ip
d00: 1c9c muleq r0, ip, ip
d04: 0014 andeq r0, r0, r4, lsl r0
d08: ebe0 undefined instruction 0xebe0
Important to know, that the sl register points to the global
offset table
1420 0 OBJECT LOCAL HIDDEN 3 _GLOBAL_OFFSET_TABLE_
So 0x1420 + 0xebe0 is zero, actually saying that
_stdio_term is undefined.
When the code is loaded it gets relocated, and the sl register
contains a value other than 0x1420. Hence it jumps wherever
something + 0xebe0 points to.
Kind regards
Andreas Fenkart
___
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] flthdr: control the Blackfin L1 stack flag
Jivin Mike Frysinger lays it down ...
From: Bernd Schmidt bernds_...@t-online.de
Add -u/-U options to control the Blackfin L1 stack flag.
Signed-off-by: Bernd Schmidt bernds_...@t-online.de
Signed-off-by: Mike Frysinger vap...@gentoo.org
Applied,
Thanks,
Davidm
---
Not sure if we want to take this patch as is or try and generalize it as
a set arch bit ? or wait until another arch actually utilizes the arch
bit for their own purpose ?
flthdr.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/flthdr.c b/flthdr.c
index cf6fe4d..90f9aa3 100644
--- a/flthdr.c
+++ b/flthdr.c
@@ -51,7 +51,7 @@
char *program_name;
static int print = 0, print_relocs = 0, docompress = 0, ramload = 0,
- stacksize = 0, ktrace = 0;
+ stacksize = 0, ktrace = 0, l1stack = 0;
//
@@ -106,6 +106,11 @@ process_file(char *ifile, char *ofile)
else if (ktrace 0)
new_flags = ~FLAT_FLAG_KTRACE;
+ if (l1stack 0)
+ new_flags |= FLAT_FLAG_L1STK;
+ else if (l1stack 0)
+ new_flags = ~FLAT_FLAG_L1STK;
+
if (stacksize)
new_stack = stacksize;
@@ -139,6 +144,8 @@ process_file(char *ifile, char *ofile)
printf(Gzip-Data-Compressed );
if (old_flags FLAT_FLAG_KTRACE)
printf(Kernel-Traced-Load );
+ if (old_flags FLAT_FLAG_L1STK)
+ printf(L1-Scratch-Stack );
printf()\n);
}
@@ -317,6 +324,8 @@ usage(char *s)
fprintf(stderr,-R : do not RAM load\n);
fprintf(stderr,-k : kernel traced load (for debug)\n);
fprintf(stderr,-K : normal non-kernel traced load\n);
+ fprintf(stderr,-u : place stack in L1 scratchpad
memory\n);
+ fprintf(stderr,-U : place stack in normal SDRAM
memory\n);
fprintf(stderr,-s size : stack size\n);
fprintf(stderr,-o file : output-file\n
(default is to modify input file)\n);
@@ -333,7 +342,7 @@ main(int argc, char *argv[])
program_name = argv[0];
- while ((c = getopt(argc, argv, pPdzZrRkKs:o:)) != EOF) {
+ while ((c = getopt(argc, argv, pPdzZrRuUkKs:o:)) != EOF) {
switch (c) {
case 'p': print = 1;break;
case 'P': print_relocs = 1; break;
@@ -344,6 +353,8 @@ main(int argc, char *argv[])
case 'R': ramload = -1; break;
case 'k': ktrace = 1; break;
case 'K': ktrace = -1; break;
+ case 'u': l1stack = 1; break;
+ case 'U': l1stack = -1; break;
case 'o': ofile = optarg; break;
case 's':
if (sscanf(optarg, %i, stacksize) != 1)
--
1.6.3.1
___
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
--
David McCullough, david_mccullo...@securecomputing.com, Ph:+61 734352815
McAfee - SnapGear http://www.snapgear.comhttp://www.uCdot.org
___
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] add .gitignore
Jivin Mike Frysinger lays it down ... Signed-off-by: Mike Frysinger vap...@gentoo.org Applied, Thanks, Davidm --- .gitignore | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..12b560b --- /dev/null +++ b/.gitignore @@ -0,0 +1,18 @@ +# standard patterns +*.o +*~ +*.orig +*.rej +*.patch + +# autotool files +autom4te.cache +config.log +config.status +Makefile + +# our generated files +elf2flt +elf2flt.ld +flthdr +ld-elf2flt -- 1.6.3.1 ___ 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 -- David McCullough, david_mccullo...@securecomputing.com, Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.comhttp://www.uCdot.org ___ 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] Re: errors when linking without XIP
Hi Erwin, Erwin Authried wrote: I have used this a lot for applications without XIP in the meantime, it works fine. I just wanted to note that running elf2flt without the -a option does NOT work. Sorry that I didn't make a neat patch, just not enough time. No problem, easy to apply. I committed it to the elf2flt CVS. Thanks Greg Am Donnerstag, den 21.05.2009, 16:57 +1000 schrieb Greg Ungerer: Hi Erwin, Erwin Authried wrote: Hi, I have solved the reloc type R_ARM_PC24 unsupported in this context error by modifying elf2flt.c: -Erwin ... #elif defined(TARGET_arm) case R_ARM_ABS32: relocation_needed = 1; break; case R_ARM_REL32: case R_ARM_THM_PC11: case R_ARM_THM_PC22: // == add the following 4 lines: case R_ARM_PC24: case R_ARM_PLT32: case R_ARM_GOTPC: case R_ARM_GOT32: relocation_needed = 0; break; default: goto bad_resolved_reloc; Thats looks right to me. I think we can go ahead and push that into the elf2flt CVS? Regards Greg Am Mittwoch, den 20.05.2009, 12:29 -0400 schrieb Jeff Bacon: Hi, I've just started on a uClinux 2.6 port to a custom ARM7TDMI board (we've had a uClinux 2.4 kernel running with no problems for a couple of years now, but decided to take the plunge and upgrade). I just joined the mailing list and am trying to resurrect the thread below from Erwin... First. here is some background on where we are right now We are currently using the same base kernel and toolchain mentioned below(uClinux-dist-20080808, snapgear toolchain arm-linux-tools-20070808.tar.gz) and we're having a ton of issues with getting our XIP ROMFS root filesystem working out of flash (the kernel boots, the filesystem mounts and I get a SASH prompt, but the system is HIGHLY unstable and usually crashes after a couple of commands). In fact, basic things are broken such as cat. I've set the init=/bin/sh kernel parameter to boot immediately into the shell, but if I try cat /etc/motd, I get a ton of output like this(note, ROMFS debugging is turned ON): snip VFS: Mounted root (romfs filesystem) readonly. Freeing init memory: 76K BINFMT_FLAT: ROM mapping of file (we hope) BINFMT_FLAT: Allocated data+bss+stack (21094 bytes): 2b8004 p=2bfffc start_thread(regs=0x1eff08, entry=0x280044, start_stack=0x2bffb8) Sash command shell (version 1.1.1) / ls /etc BINFMT_FLAT: ROM mapping of file (we hope) BINFMT_FLAT: Allocated data+bss+stack (10894 bytes): 2f0004 p=2f3ffc start_thread(regs=0x2c7fb0, entry=0x2e0044, start_stack=0x2f3f80) inittabmodprobe.conf motd passwd ramfs.img rc services version / cat /etc/motd BINFMT_FLAT: ROM mapping of file (we hope) BINFMT_FLAT: Allocated data+bss+stack (11541 bytes): 2cc004 p=2cfffc start_thread(regs=0x2b7fb0, entry=0x2c8044, start_stack=0x2cff78) : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory : : No such file or directory / Mounting /proc works, but I can't cat any of those files as well, but either way, the system only SOMETIMES makes it this far before dying completely (just stalls, no kernel panics or oops or anything). Anyway, while trying to debug this, the first thing I tried was taking Flash out of the equation. So in my bootloader I restrict system RAM to 4MB (we have an 8MB part) and copy the ROMFS image from flash into the 2nd 4MB of RAM. I add the mem=4MB kernel parameter to restrict uClinux to the 1st 4MB of RAM, then compiled the uclinux MTD driver and gave it the location of the ROMFS in the 2nd half of RAM. The kernel boots and the uclinux mtd driver finds and mounts it and I get the prompt again, but the behavior is exactly the same, highly unstable, things like cat don't work. So next I tried to compile userland WITHOUT XIP to see if that was the
Re: [uClinux-dev] new uClinux-dist patch
Hi Lennart, Lennart Sorensen wrote: On Thu, May 21, 2009 at 04:53:33PM +1000, Greg Ungerer wrote: I have started an upload of a new uClinux-dist patch, at: http://www.uclinux.org/pub/uClinux/dist/patches/uClinux-dist-20080808-20090520.patch.gz It won't all be there for probably about 24 hours. So hold of downloading 'till tomorrow :-) It includes a linux-2.6.29 kernel, and other various fixes and source updates - nothing major. I think most targets work as well as the did with the 2.6.26 kernel in there. (Excepting ARMulator I think, I haven't had time to look at it yet). As usual please post any patches and fixes here. (I may be a little slow in responding for the next couple of weeks, I'll be away). I haven't released a linux-2.6.29-uc0 patch set as I normally would. Instead I have been pushing my changes into the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git And then promoting them from there. Means less work for me :-) But, are people attached to using the -uc patch series? Does anyone still want me to create them? So far in that git tree in the for-linus branch is a set of changes to clean up the various ColdFire reset/reboot code, it should work much better on all platforms now. There is some more merged include file cleanups in the includes branch. The biggest changes in that git tree and some interrupt controller improvements I am working on. There is now specific support code for each of the various types of interrupt controllers used in the various ColdFire parts. The support for the new parts with the larger more flexible interrupt controllers is clean and nice (so for 5208, 5235, 5271/5275, 5282, 5329 and their type). The code for the older parts (5206, 5249, 5307, 5407, etc) is better, but I am still working to improve it a little more. What kind of improvements does the new interrupt code bring (specifically for the 5271 that I am using)? Faster, more flexible, cleaner code? Generally speaking the motivation is to make the ColdFire interrupt support fit into the kernel model. Specifically this means the ability to mask/unmask/ack interrupts directly from the kernels arch independent interrupt code. Currently in ColdFire land we unmask interrupts in pretty much an ad-hoc fashion as required. And for those interrupts that need ack'ing we do that with hacks in drivers and the like. I want to clean this up and make it all work properly. Unfortunately it is not as simple as it sounds. There is quite a few differences in the interrupt controllers used across the various ColdFire parts now. The modern parts are strait forward, the older parts are taking a little more effort. It all seems to be falling out nicely overall though. In terms of external differences you may not see too much on the 5271. Internally it means I can simplify the interrupt setup for the internal devices (timers, UARTs, FEC, etc). On cores that support external interrupts it meands getting drivers going is a much simpler task. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +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
