From fredbasset1000 at gmail.com Sun Jul 1 17:48:52 2012 From: fredbasset1000 at gmail.com (fred basset) Date: Sun, 1 Jul 2012 14:48:52 -0700 Subject: [uClinux-dev] Setting the timezone Message-ID: Hi Guys, I'm having trouble with getting the local timezone correct. I have stored the timezone in verified correct format (e.g. PST8). I have an rc.default script which is run as run as part of the startup process, and it exports TZ as PST8. I've verified the variable is being set correctly by running "set" after boot: # set TZ=PST8 PS2=> PS1=# IFS= USER=root SHELL=/bin/sh PATH=/sbin:/usr/sbin:/bin:/usr/bin TERM=vt102 HOME=/ # However, when I run the "date" command I get back: Sun Jul 1 21:46:25 UTC 2012 which is the time right now in UTC, so it looks like it's ignoring TZ. Am I doing something wrong by exporting TZ in my startup script? What is the preferred way of setting the timezone? We're using ucLibc too. Thanks, Fred From JMoore at moreycorp.com Sun Jul 1 23:02:02 2012 From: JMoore at moreycorp.com (John B Moore) Date: Sun, 1 Jul 2012 22:02:02 -0500 Subject: [uClinux-dev] John B Moore is out of the office. Message-ID: An HTML attachment was scrubbed... URL: From gerg at snapgear.com Mon Jul 9 02:08:54 2012 From: gerg at snapgear.com (Greg Ungerer) Date: Mon, 9 Jul 2012 16:08:54 +1000 Subject: [uClinux-dev] [PATCH 1/2] mtd: fix wrong usage of ioremap_nocache() in uclinux.c map driver In-Reply-To: <1341590150.26921.16.camel@shinybook.infradead.org> References: <1336632929-26100-1-git-send-email-gerg@snapgear.com> <1341590150.26921.16.camel@shinybook.infradead.org> Message-ID: <4FFA7576.7050204@snapgear.com> Hi David, On 07/07/12 01:55, David Woodhouse wrote: > On Thu, 2012-05-10 at 16:55 +1000, gerg at snapgear.com wrote: >> But if we want to use the uclinux.c mapping driver on real MMU enabled >> systems we should be using phys_to_virt() for the translation, since >> that is really what we are doing. So change it to do that. > > That seems wrong. On a highmem page, phys_to_virt() isn't valid. So at > the very least, any usage of phys_to_virt() needs a stonking great > comment explaining why it's always safe because it can never be used ona > a highmem page. The only VM based arch this driver can be configured for currently is m68k (actually it is even more specific, only CONFIG_COLDFIRE). And that doesn't support HIGHMEM. Can the kernels data region (and the area immediately after it) be in high memory? Regards Greg ------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: gerg at snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com From gerg at snapgear.com Fri Jul 13 02:25:16 2012 From: gerg at snapgear.com (Greg Ungerer) Date: Fri, 13 Jul 2012 16:25:16 +1000 Subject: [uClinux-dev] [PATCH 1/2] mtd: fix wrong usage of ioremap_nocache() in uclinux.c map driver In-Reply-To: <1342079353.30654.18.camel@shinybook.infradead.org> References: <1336632929-26100-1-git-send-email-gerg@snapgear.com> <1341590150.26921.16.camel@shinybook.infradead.org> <4FFA7576.7050204@snapgear.com> <1342079353.30654.18.camel@shinybook.infradead.org> Message-ID: <4FFFBF4C.9070407@snapgear.com> On 12/07/12 17:49, David Woodhouse wrote: > On Mon, 2012-07-09 at 16:08 +1000, Greg Ungerer wrote: >> >> The only VM based arch this driver can be configured for currently >> is m68k (actually it is even more specific, only CONFIG_COLDFIRE). >> And that doesn't support HIGHMEM. > > OK, can we at least have a comment to that effect in the code, alongside > that phys_to_virt() call so that nobody is tempted to copy it into new > code? And preferably also an '#ifdef CONFIG_HIGHMEM / #error' in the > code or a (redundant) !HIGHMEM dependency in Kconfig just to make sure, > in case it's ever enabled on other architectures or in case HIGHMEM ever > comes to m68k. I'll come up with something and send a patch. >> Can the kernels data region (and the area immediately after it) be in >> high memory? > > No, that'll be in the directly mapped region. Then does it matter whether HIGHMEM is enabled or not? The phys address here is _ebss, the end of the kernels bss section. Regards Greg ------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: gerg at snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com From dedekind1 at gmail.com Wed Jul 18 08:12:22 2012 From: dedekind1 at gmail.com (Artem Bityutskiy) Date: Wed, 18 Jul 2012 15:12:22 +0300 Subject: [uClinux-dev] [PATCH 1/2] mtd: fix wrong usage of ioremap_nocache() in uclinux.c map driver In-Reply-To: <1336632929-26100-1-git-send-email-gerg@snapgear.com> References: <1336632929-26100-1-git-send-email-gerg@snapgear.com> Message-ID: <1342613542.7530.21.camel@brekeke> On Thu, 2012-05-10 at 16:55 +1000, gerg at snapgear.com wrote: > From: Greg Ungerer Hi Greg, I had these 2 patches in my l2-mtd.git tree, but dwmw2 decided to not pick them, so I dropped them as well. Please, re-send new versions, thanks! -- Best Regards, Artem Bityutskiy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From gerg at snapgear.com Thu Jul 19 01:42:45 2012 From: gerg at snapgear.com (gerg at snapgear.com) Date: Thu, 19 Jul 2012 15:42:45 +1000 Subject: [uClinux-dev] [PATCH v2 1/2] mtd: fix wrong usage of ioremap_nocache() in uclinux.c map driver Message-ID: <1342676566-25651-1-git-send-email-gerg@snapgear.com> From: Greg Ungerer The uclinux.c mapping driver uses ioremap_nocache() to map its physical mapping address to a system virtual address. Problem is that the region it is mapping is not device memory. It is ordinary system RAM. On most non-MMU systems this doesn't matter, and the mapping is always a 1:1 translation of the address. On paged memory systems on some architectures the page table mappings are not compatible between normal RAM and device memory. If we want to use the uclinux.c mapping driver on real MMU enabled systems we should be using the kernel virtual address that the mapping is at. For architectures that support the traditional initrd they use phys_to_virt or __va to convert the physical start initrd address to a kernel usable virtual address. The uclinux filesystem mapping is even more restrictive than the typical initrd, it always follows the kernels own bss section (so always in directly mapped memory). Therefore we can use the usual phys_to_virt to translate the physical start address to a virtual address. Signed-off-by: Greg Ungerer --- v2: added comments about use of phys_to_virt drivers/mtd/maps/uclinux.c | 15 +++++++++------ 1 files changed, 9 insertions(+), 6 deletions(-) diff --git a/drivers/mtd/maps/uclinux.c b/drivers/mtd/maps/uclinux.c index cfff454..43400b6 100644 --- a/drivers/mtd/maps/uclinux.c +++ b/drivers/mtd/maps/uclinux.c @@ -68,10 +68,16 @@ static int __init uclinux_mtd_init(void) printk("uclinux[mtd]: RAM probe address=0x%x size=0x%x\n", (int) mapp->phys, (int) mapp->size); - mapp->virt = ioremap_nocache(mapp->phys, mapp->size); + /* + * The filesystem is guaranteed to be in direct mapped memory. It is + * directly following the kernels own bss region. Following the same + * mechanism used by architectures setting up traditional initrds we + * use phys_to_virt to get the virtual address of its start. + */ + mapp->virt = phys_to_virt(mapp->phys); if (mapp->virt == 0) { - printk("uclinux[mtd]: ioremap_nocache() failed\n"); + printk("uclinux[mtd]: no virtual mapping?\n"); return(-EIO); } @@ -80,7 +86,6 @@ static int __init uclinux_mtd_init(void) mtd = do_map_probe("map_ram", mapp); if (!mtd) { printk("uclinux[mtd]: failed to find a mapping?\n"); - iounmap(mapp->virt); return(-ENXIO); } @@ -103,10 +108,8 @@ static void __exit uclinux_mtd_cleanup(void) map_destroy(uclinux_ram_mtdinfo); uclinux_ram_mtdinfo = NULL; } - if (uclinux_ram_map.virt) { - iounmap((void *) uclinux_ram_map.virt); + if (uclinux_ram_map.virt) uclinux_ram_map.virt = 0; - } } /****************************************************************************/ -- 1.7.0.4 From gerg at snapgear.com Thu Jul 19 01:44:38 2012 From: gerg at snapgear.com (Greg Ungerer) Date: Thu, 19 Jul 2012 15:44:38 +1000 Subject: [uClinux-dev] [PATCH 1/2] mtd: fix wrong usage of ioremap_nocache() in uclinux.c map driver In-Reply-To: <1342613542.7530.21.camel@brekeke> References: <1336632929-26100-1-git-send-email-gerg@snapgear.com> <1342613542.7530.21.camel@brekeke> Message-ID: <50079EC6.8050906@snapgear.com> Hi Artem, On 18/07/12 22:12, Artem Bityutskiy wrote: > On Thu, 2012-05-10 at 16:55 +1000, gerg at snapgear.com wrote: >> From: Greg Ungerer > > Hi Greg, I had these 2 patches in my l2-mtd.git tree, but dwmw2 decided > to not pick them, so I dropped them as well. Please, re-send new > versions, thanks! Ok, done. Regards Greg ------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: gerg at snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com From gerg at snapgear.com Thu Jul 19 01:42:46 2012 From: gerg at snapgear.com (gerg at snapgear.com) Date: Thu, 19 Jul 2012 15:42:46 +1000 Subject: [uClinux-dev] [PATCH v2 2/2] mtd: allow uclinux map driver to be used on any ColdFire CPU platform In-Reply-To: <1342676566-25651-1-git-send-email-gerg@snapgear.com> References: <1342676566-25651-1-git-send-email-gerg@snapgear.com> Message-ID: <1342676566-25651-2-git-send-email-gerg@snapgear.com> From: Greg Ungerer The uclinux.c map driver has traditionally been used only on non-MMU based systems. But there is no fundamental reason it can't be used on systems running with virtual memory. Some ColdFire CPU based systems now have full paged MMU hardware and can use the uclinux.c mapping driver, so making the uclinux.c driver configuration depend on !CONFIG_MMU doesn't make sense now. Allow the CONFIG_MTD_UCLINUX option to be enabled if CONFIG_COLDFIRE is enabled. (I have chosen not to just more generally allow uclinux.c for any MMU type to keep this option hidden for most systems that are not interested in setting it). Signed-off-by: Greg Ungerer --- drivers/mtd/maps/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig index 5ba2458..185454a 100644 --- a/drivers/mtd/maps/Kconfig +++ b/drivers/mtd/maps/Kconfig @@ -443,7 +443,7 @@ config MTD_GPIO_ADDR config MTD_UCLINUX bool "Generic uClinux RAM/ROM filesystem support" - depends on MTD_RAM=y && !MMU + depends on MTD_RAM=y && (!MMU || COLDFIRE) help Map driver to support image based filesystems for uClinux. -- 1.7.0.4 From pankaj.dev at stericsson.com Thu Jul 19 23:43:33 2012 From: pankaj.dev at stericsson.com (Pankaj DEV) Date: Fri, 20 Jul 2012 05:43:33 +0200 Subject: [uClinux-dev] elf2flt error with ARM Cortex-R4 toolchain Message-ID: Hello, I am using ARM-Versatile Cortex-R4 platform and I have toolchain build with following components' versions : 1. GNU GCC : 4.6.3 20120301 2. GNU Binutils - 2.20.51.20100809 3. uClibc-nptl-0.9.33-66 To build the user application binary (FLAT), I downloaded the following(latest) version of ELF2FLT package from http://blackfin.uclinux.org/git/?p=users/vapier/elf2flt.git;a=summary 2011-04-04 David McCullough The GNU linker uses -v as a shortcut to --version,... I was able to build the package properly and install it in my existing (above) toolchain, but now when I try to build a simple (hello) C user program using -Wl,-elf2flt options, I am getting following errors : a. /root/distro-armv7r/STLinux-2.4/devkit/armv7r_uclibc/arm-cortex-linux-uclibcgnueabi/bin/ld.real: section .junk loaded at [00000000,0000001f] overlaps section .text loaded at [00000000,0000011f] b. /root/distro-armv7r/STLinux-2.4/devkit/armv7r_uclibc/arm-cortex-linux-uclibcgnueabi/bin/ld.real: BFD (GNU Binutils - STMicroelectronics/Linux Base) 2.20.51.20100809 assertion fail ../../bfd/elf32-arm.c:13377 Any Idea ? My doubt : Is ELF2FLT package compatible with the above mentioned versions of GCC/Binutils/uClibc for ARM-R4 used ? If anybody has tried to build a toolchain for ARM with this ELF2FLT package, can u help us with the versions of GCC/Binutils/uClibc ? Or may be if anyone knows any working ARM-CortexR4 working toolchain containing ELF2FLT ? Regards Pankaj Dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From david_mccullough at mcafee.com Fri Jul 20 00:53:20 2012 From: david_mccullough at mcafee.com (David McCullough) Date: Fri, 20 Jul 2012 14:53:20 +1000 Subject: [uClinux-dev] elf2flt error with ARM Cortex-R4 toolchain In-Reply-To: References: Message-ID: <20120720045320.GA8076@mcafee.com> Jivin Pankaj DEV lays it down ... > Hello, > > I am using ARM-Versatile Cortex-R4 platform and I have toolchain build with following components? versions : > > 1. GNU GCC : 4.6.3 20120301 > 2. GNU Binutils - 2.20.51.20100809 > 3. uClibc-nptl-0.9.33-66 > > To build the user application binary (FLAT), I downloaded the following(latest) version of ELF2FLT package from http://blackfin.uclinux.org/git/?p=users/vapier/elf2flt.git;a=summary > > 2011-04-04 > > David McCullough > > The GNU linker uses -v as a shortcut to --version,... My only question is why you are using the blackfin version of elf2flt for an ARM system ? It may be fine, I don't really know, but its primary purpose would be blackfind support I suspect ;-) I haven't played with elf2flt for a long time, but there are working ARM toolchains out there with elf2flt included. Build your ARM tool chain, then try this version of elf2flt: http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/elf2flt/ Otherwise, hopefully someone on the list is currently using something and can help you, Cheers, Davidm > I was able to build the package properly and install it in my existing (above) toolchain, but now when I try to build a simple (hello) C user program using ?Wl,-elf2flt options, I am getting following errors : > > a. /root/distro-armv7r/STLinux-2.4/devkit/armv7r_uclibc/arm-cortex-linux-uclibcgnueabi/bin/ld.real: section .junk loaded at [00000000,0000001f] overlaps section .text loaded at [00000000,0000011f] > > b. /root/distro-armv7r/STLinux-2.4/devkit/armv7r_uclibc/arm-cortex-linux-uclibcgnueabi/bin/ld.real: BFD (GNU Binutils - STMicroelectronics/Linux Base) 2.20.51.20100809 assertion fail ../../bfd/elf32-arm.c:13377 > > > > Any Idea ? > > > > My doubt : > > Is ELF2FLT package compatible with the above mentioned versions of GCC/Binutils/uClibc for ARM-R4 used ? > > If anybody has tried to build a toolchain for ARM with this ELF2FLT package, can u help us with the versions of GCC/Binutils/uClibc ? > > Or may be if anyone knows any working ARM-CortexR4 working toolchain containing ELF2FLT ? > > > > Regards > > Pankaj Dev > > -- David McCullough, david_mccullough at mcafee.com, Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org From pankaj.dev at stericsson.com Fri Jul 20 03:21:00 2012 From: pankaj.dev at stericsson.com (Pankaj DEV) Date: Fri, 20 Jul 2012 09:21:00 +0200 Subject: [uClinux-dev] elf2flt error with ARM Cortex-R4 toolchain In-Reply-To: <20120720045320.GA8076@mcafee.com> References: <20120720045320.GA8076@mcafee.com> Message-ID: Hey, I downloaded latest sources for elf2flt from http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/elf2flt/ But they are exactly the same as from blackfin. "but there are working ARM toolchains out there with elf2flt included" Could you provide me any link/pointer for any ARM-CortexR4 toolchain with elf2flt included ? Thanks Pankaj Dev -----Original Message----- From: David McCullough [mailto:david_mccullough at mcafee.com] Sent: Friday, July 20, 2012 10:23 AM To: Pankaj DEV Cc: uclinux-dev at uclinux.org Subject: Re: elf2flt error with ARM Cortex-R4 toolchain Jivin Pankaj DEV lays it down ... > Hello, > > I am using ARM-Versatile Cortex-R4 platform and I have toolchain build with following components? versions : > > 1. GNU GCC : 4.6.3 20120301 > 2. GNU Binutils - 2.20.51.20100809 > 3. uClibc-nptl-0.9.33-66 > > To build the user application binary (FLAT), I downloaded the > following(latest) version of ELF2FLT package from > http://blackfin.uclinux.org/git/?p=users/vapier/elf2flt.git;a=summary > > 2011-04-04 > > David McCullough > s=David+McCullough;st=author> > > The GNU linker uses -v as a shortcut to --version,... > h=40f0d175e0847d922faa85cc18ec01f2129bb2b9> My only question is why you are using the blackfin version of elf2flt for an ARM system ? It may be fine, I don't really know, but its primary purpose would be blackfind support I suspect ;-) I haven't played with elf2flt for a long time, but there are working ARM toolchains out there with elf2flt included. Build your ARM tool chain, then try this version of elf2flt: http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/elf2flt/ Otherwise, hopefully someone on the list is currently using something and can help you, Cheers, Davidm > I was able to build the package properly and install it in my existing (above) toolchain, but now when I try to build a simple (hello) C user program using ?Wl,-elf2flt options, I am getting following errors : > > a. /root/distro-armv7r/STLinux-2.4/devkit/armv7r_uclibc/arm-cortex-linux-uclibcgnueabi/bin/ld.real: section .junk loaded at [00000000,0000001f] overlaps section .text loaded at [00000000,0000011f] > > b. /root/distro-armv7r/STLinux-2.4/devkit/armv7r_uclibc/arm-cortex-linux-uclibcgnueabi/bin/ld.real: BFD (GNU Binutils - STMicroelectronics/Linux Base) 2.20.51.20100809 assertion fail ../../bfd/elf32-arm.c:13377 > > > > Any Idea ? > > > > My doubt : > > Is ELF2FLT package compatible with the above mentioned versions of GCC/Binutils/uClibc for ARM-R4 used ? > > If anybody has tried to build a toolchain for ARM with this ELF2FLT package, can u help us with the versions of GCC/Binutils/uClibc ? > > Or may be if anyone knows any working ARM-CortexR4 working toolchain containing ELF2FLT ? > > > > Regards > > Pankaj Dev > > -- David McCullough, david_mccullough at mcafee.com, Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org From gerg at snapgear.com Sun Jul 22 08:15:33 2012 From: gerg at snapgear.com (Greg Ungerer) Date: Sun, 22 Jul 2012 22:15:33 +1000 Subject: [uClinux-dev] elf2flt error with ARM Cortex-R4 toolchain In-Reply-To: References: <20120720045320.GA8076@mcafee.com> Message-ID: <500BEEE5.2020901@snapgear.com> Hi Pankaj, On 07/20/2012 05:21 PM, Pankaj DEV wrote: > I downloaded latest sources for elf2flt from http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/elf2flt/ > But they are exactly the same as from blackfin. > > "but there are working ARM toolchains out there with elf2flt included" > Could you provide me any link/pointer for any ARM-CortexR4 toolchain with elf2flt included ? Try the code sourcery tool chains. They usually work pretty well. Regards Greg > -----Original Message----- > From: David McCullough [mailto:david_mccullough at mcafee.com] > Sent: Friday, July 20, 2012 10:23 AM > To: Pankaj DEV > Cc: uclinux-dev at uclinux.org > Subject: Re: elf2flt error with ARM Cortex-R4 toolchain > > > Jivin Pankaj DEV lays it down ... >> Hello, >> >> I am using ARM-Versatile Cortex-R4 platform and I have toolchain build with following components? versions : >> >> 1. GNU GCC : 4.6.3 20120301 >> 2. GNU Binutils - 2.20.51.20100809 >> 3. uClibc-nptl-0.9.33-66 >> >> To build the user application binary (FLAT), I downloaded the >> following(latest) version of ELF2FLT package from >> http://blackfin.uclinux.org/git/?p=users/vapier/elf2flt.git;a=summary >> >> 2011-04-04 >> >> David McCullough >> > s=David+McCullough;st=author> >> >> The GNU linker uses -v as a shortcut to --version,... >> > h=40f0d175e0847d922faa85cc18ec01f2129bb2b9> > > > My only question is why you are using the blackfin version of elf2flt for an ARM system ? It may be fine, I don't really know, but its primary purpose would be blackfind support I suspect ;-) > > I haven't played with elf2flt for a long time, but there are working ARM toolchains out there with elf2flt included. Build your ARM tool chain, then try this version of elf2flt: > > http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/elf2flt/ > > Otherwise, hopefully someone on the list is currently using something and can help you, > > Cheers, > Davidm > > > > >> I was able to build the package properly and install it in my existing (above) toolchain, but now when I try to build a simple (hello) C user program using ?Wl,-elf2flt options, I am getting following errors : >> >> a. /root/distro-armv7r/STLinux-2.4/devkit/armv7r_uclibc/arm-cortex-linux-uclibcgnueabi/bin/ld.real: section .junk loaded at [00000000,0000001f] overlaps section .text loaded at [00000000,0000011f] >> >> b. /root/distro-armv7r/STLinux-2.4/devkit/armv7r_uclibc/arm-cortex-linux-uclibcgnueabi/bin/ld.real: BFD (GNU Binutils - STMicroelectronics/Linux Base) 2.20.51.20100809 assertion fail ../../bfd/elf32-arm.c:13377 >> >> >> >> Any Idea ? >> >> >> >> My doubt : >> >> Is ELF2FLT package compatible with the above mentioned versions of GCC/Binutils/uClibc for ARM-R4 used ? >> >> If anybody has tried to build a toolchain for ARM with this ELF2FLT package, can u help us with the versions of GCC/Binutils/uClibc ? >> >> Or may be if anyone knows any working ARM-CortexR4 working toolchain containing ELF2FLT ? >> >> >> >> Regards >> >> Pankaj Dev >> >> > -- ------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: gerg at snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close, FAX: +61 7 3891 3630 Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com From paul.chavent at fnac.net Sun Jul 22 16:46:08 2012 From: paul.chavent at fnac.net (Paul Chavent) Date: Sun, 22 Jul 2012 22:46:08 +0200 Subject: [uClinux-dev] elf2flt error with ARM Cortex-R4 toolchain In-Reply-To: References: Message-ID: <500C6690.4020507@fnac.net> Hello Pankaj I've successfully built a toolchain for an arm926ejs that allow me to build an simple c hello world (i haven't tested multithread, c++, or complex project with lot of dependancies, ...) I used the git://sources.blackfin.uclinux.org/git/users/vapier/elf2flt.git sources with the attached patch. The script used for compiling the toolchain is https://gitorious.org/bif/bif/blobs/master/framework/packages/toolchain-uclinux_uclibc/toolchain-uclinux_uclibc.sh It's a personal job that should not be taken as a reference... and perhaps you could also see the sources of busybox, crosstools-ng or openembedded ... Regards. Paul. Le 07/20/2012 05:43 AM, Pankaj DEV a ?crit : > Hello, > > I am using ARM-Versatile Cortex-R4 platform and I have toolchain build with following components' versions : > > 1. GNU GCC : 4.6.3 20120301 > > 2. GNU Binutils - 2.20.51.20100809 > > 3. uClibc-nptl-0.9.33-66 > To build the user application binary (FLAT), I downloaded the following(latest) version of ELF2FLT package from http://blackfin.uclinux.org/git/?p=users/vapier/elf2flt.git;a=summary > 2011-04-04 > > David McCullough > > The GNU linker uses -v as a shortcut to --version,... > > I was able to build the package properly and install it in my existing (above) toolchain, but now when I try to build a simple (hello) C user program using -Wl,-elf2flt options, I am getting following errors : > > a. /root/distro-armv7r/STLinux-2.4/devkit/armv7r_uclibc/arm-cortex-linux-uclibcgnueabi/bin/ld.real: section .junk loaded at [00000000,0000001f] overlaps section .text loaded at [00000000,0000011f] > > b. /root/distro-armv7r/STLinux-2.4/devkit/armv7r_uclibc/arm-cortex-linux-uclibcgnueabi/bin/ld.real: BFD (GNU Binutils - STMicroelectronics/Linux Base) 2.20.51.20100809 assertion fail ../../bfd/elf32-arm.c:13377 > > Any Idea ? > > My doubt : > Is ELF2FLT package compatible with the above mentioned versions of GCC/Binutils/uClibc for ARM-R4 used ? > If anybody has tried to build a toolchain for ARM with this ELF2FLT package, can u help us with the versions of GCC/Binutils/uClibc ? > Or may be if anyone knows any working ARM-CortexR4 working toolchain containing ELF2FLT ? > > Regards > Pankaj Dev > > > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev at uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev at uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > -------------- next part -------------- >From eca469f6946f92035f1ba4463829eb1f0e0fd98d Mon Sep 17 00:00:00 2001 From: Paul Chavent Date: Thu, 17 May 2012 08:10:44 +0200 Subject: [PATCH] Arm support update (exidx sections). --- .gitignore | 1 + elf2flt.c | 27 +++++++++++++++++++++++++++ elf2flt.ld.in | 17 ++++++++++++++--- 3 files changed, 42 insertions(+), 3 deletions(-) diff --git a/.gitignore b/.gitignore index 92ff5f6..e0e0bd5 100644 --- a/.gitignore +++ b/.gitignore @@ -22,3 +22,4 @@ elf2flt elf2flt.ld flthdr ld-elf2flt +ld-elf2flt.sh \ No newline at end of file diff --git a/elf2flt.c b/elf2flt.c index 2fea9b5..1a7ef88 100644 --- a/elf2flt.c +++ b/elf2flt.c @@ -54,6 +54,8 @@ const char *elf2flt_progname; #if defined(TARGET_h8300) #include /* TARGET_* ELF support for the BFD library */ +#elif defined(TARGET_arm) +#include "elf/arm.h" #elif defined(__CYGWIN__) || defined(__MINGW32__) || defined(TARGET_nios) || defined(TARGET_nios2) #include "cygwin-elf.h" /* Cygwin uses a local copy */ #elif defined(TARGET_microblaze) @@ -639,12 +641,16 @@ dump_symbols(symbols, number_of_symbols); relocation_needed = 1; break; case R_ARM_REL32: + case R_ARM_JUMP24: + case R_ARM_CALL: case R_ARM_THM_PC11: case R_ARM_THM_PC22: case R_ARM_PC24: case R_ARM_PLT32: case R_ARM_GOTPC: case R_ARM_GOT32: + case R_ARM_PREL31: + case R_ARM_NONE: relocation_needed = 0; break; default: @@ -1702,6 +1708,27 @@ int main(int argc, char *argv[]) } } + if (verbose) { + printf(" verbose = %d\n" + " load_to_ram = %d\n" + " ktrace = %d\n" + " docompress = %d\n" + " pfile = \"%s\"\n" + " ofile = \"%s\"\n" + " use_resolved = %d\n" + " stack = %d\n" + " rel_file = \"%s\\n", + verbose , + load_to_ram , + ktrace , + docompress , + pfile , + ofile , + use_resolved, + stack , + rel_file ); + } + /* * if neither the -r or -p options was given, default to * a RAM load as that is the only option that makes sense. diff --git a/elf2flt.ld.in b/elf2flt.ld.in index c7e01a6..56b8f96 100644 --- a/elf2flt.ld.in +++ b/elf2flt.ld.in @@ -32,6 +32,8 @@ W_RODAT *(.rodata1) W_RODAT *(.rodata.*) W_RODAT *(.gnu.linkonce.r*) + /* .ARM.extab name sections containing exception unwinding information */ + *(.ARM.extab* .gnu.linkonce.armextab.*) /* This is special code area at the end of the normal text section. It contains a small lookup table at the start followed by the code pointed to by entries @@ -40,11 +42,20 @@ W_RODAT *(.gnu.linkonce.r*) PROVIDE(@SYMBOL_PREFIX at __ctbp = .); *(.call_table_data) *(.call_table_text) - - . = ALIGN(0x20) ; - @SYMBOL_PREFIX at _etext = . ; } > flatmem :text + /* .ARM.exidx name sections containing index entries for section unwinding */ + /* .ARM.exidx is sorted, so has to go in its own output section. */ + @SYMBOL_PREFIX at __exidx_start = .; + .ARM.exidx : + { + *(.ARM.exidx* .gnu.linkonce.armexidx.*) + } > flatmem + @SYMBOL_PREFIX at __exidx_end = .; + + . = ALIGN(0x20) ; + @SYMBOL_PREFIX at _etext = . ; + .data : { . = ALIGN(0x4) ; @SYMBOL_PREFIX at _sdata = . ; -- 1.7.4.4 From david_mccullough at mcafee.com Mon Jul 23 21:58:19 2012 From: david_mccullough at mcafee.com (David McCullough) Date: Tue, 24 Jul 2012 11:58:19 +1000 Subject: [uClinux-dev] elf2flt error with ARM Cortex-R4 toolchain In-Reply-To: References: <20120720045320.GA8076@mcafee.com> Message-ID: <20120724015818.GA3704@mcafee.com> Jivin Pankaj DEV lays it down ... > Hey, > > I downloaded latest sources for elf2flt from http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/elf2flt/ > But they are exactly the same as from blackfin. > > "but there are working ARM toolchains out there with elf2flt included" > Could you provide me any link/pointer for any ARM-CortexR4 toolchain with elf2flt included ? Codesourcery traditionally did this quite well. They have since been bought by Mentor and I have no experience with them myself: http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/ Maybe do some googling ;-) Cheers, Davidm > -----Original Message----- > From: David McCullough [mailto:david_mccullough at mcafee.com] > Sent: Friday, July 20, 2012 10:23 AM > To: Pankaj DEV > Cc: uclinux-dev at uclinux.org > Subject: Re: elf2flt error with ARM Cortex-R4 toolchain > > > Jivin Pankaj DEV lays it down ... > > Hello, > > > > I am using ARM-Versatile Cortex-R4 platform and I have toolchain build with following components? versions : > > > > 1. GNU GCC : 4.6.3 20120301 > > 2. GNU Binutils - 2.20.51.20100809 > > 3. uClibc-nptl-0.9.33-66 > > > > To build the user application binary (FLAT), I downloaded the > > following(latest) version of ELF2FLT package from > > http://blackfin.uclinux.org/git/?p=users/vapier/elf2flt.git;a=summary > > > > 2011-04-04 > > > > David McCullough > > > s=David+McCullough;st=author> > > > > The GNU linker uses -v as a shortcut to --version,... > > > h=40f0d175e0847d922faa85cc18ec01f2129bb2b9> > > > My only question is why you are using the blackfin version of elf2flt for an ARM system ? It may be fine, I don't really know, but its primary purpose would be blackfind support I suspect ;-) > > I haven't played with elf2flt for a long time, but there are working ARM toolchains out there with elf2flt included. Build your ARM tool chain, then try this version of elf2flt: > > http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/elf2flt/ > > Otherwise, hopefully someone on the list is currently using something and can help you, > > Cheers, > Davidm > > > > > > I was able to build the package properly and install it in my existing (above) toolchain, but now when I try to build a simple (hello) C user program using ?Wl,-elf2flt options, I am getting following errors : > > > > a. /root/distro-armv7r/STLinux-2.4/devkit/armv7r_uclibc/arm-cortex-linux-uclibcgnueabi/bin/ld.real: section .junk loaded at [00000000,0000001f] overlaps section .text loaded at [00000000,0000011f] > > > > b. /root/distro-armv7r/STLinux-2.4/devkit/armv7r_uclibc/arm-cortex-linux-uclibcgnueabi/bin/ld.real: BFD (GNU Binutils - STMicroelectronics/Linux Base) 2.20.51.20100809 assertion fail ../../bfd/elf32-arm.c:13377 > > > > > > > > Any Idea ? > > > > > > > > My doubt : > > > > Is ELF2FLT package compatible with the above mentioned versions of GCC/Binutils/uClibc for ARM-R4 used ? > > > > If anybody has tried to build a toolchain for ARM with this ELF2FLT package, can u help us with the versions of GCC/Binutils/uClibc ? > > > > Or may be if anyone knows any working ARM-CortexR4 working toolchain containing ELF2FLT ? > > > > > > > > Regards > > > > Pankaj Dev > > > > > > -- > David McCullough, david_mccullough at mcafee.com, Ph:+61 734352815 > McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org > > -- David McCullough, david_mccullough at mcafee.com, Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org From quiliro at congresolibre.org Tue Jul 24 12:19:46 2012 From: quiliro at congresolibre.org (=?ISO-8859-1?Q?Quiliro_Ord=F3=F1ez?=) Date: Tue, 24 Jul 2012 11:19:46 -0500 Subject: [uClinux-dev] dlink dir-100 Message-ID: <500ECB22.8000102@congresolibre.org> Hi. I understand that dlink dir-100 router has mCLinux on it. Has anyone tried to install a modified version on it? Can all the software have its source code or does some part come in binary only? What is the procedure to install a new version that has the most possible amount of source code available and that can keep the services that the router has and include squid? Thank you for your input. -- Saludos libres, Quiliro Ord??ez Presidente Asociaci?n de Software Libre del Ecuador - ASLE Av de la Prensa N58-219 y Crist?bal Vaca de Castro Quito, Ecuador (593)2-253 5534 (593)2-340 1517 (593)8-454 8078 From acassis at gmail.com Tue Jul 24 15:56:38 2012 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Tue, 24 Jul 2012 16:56:38 -0300 Subject: [uClinux-dev] dlink dir-100 In-Reply-To: <500ECB22.8000102@congresolibre.org> References: <500ECB22.8000102@congresolibre.org> Message-ID: Hi Quiliro, On 7/24/12, Quiliro Ord??ez wrote: > Hi. > > I understand that dlink dir-100 router has mCLinux on it. > Yes, it has: ftp://ftp.dlink.se/Products/dir-products/DIR-100/drivers_firmware/ > Has anyone tried to install a modified version on it? > Can all the software have its source code or does some part come in > binary only? > What is the procedure to install a new version that has the most > possible amount of source code available and that can keep the services > that the router has and include squid? > I suggest you to take a look at OpenWRT, it is tailored to wireless routers. I didn't find OpenWRT port for DIR-100, but there is a port for DIR-120 which uses same processor Realtek RTL8650, then you could use it as a start point. Best Regards, Alan From gerg at snapgear.com Tue Jul 24 19:43:20 2012 From: gerg at snapgear.com (Greg Ungerer) Date: Wed, 25 Jul 2012 09:43:20 +1000 Subject: [uClinux-dev] [git pull] m68knommu arch fixes for 3.6 Message-ID: <201207242343.q6ONhK6t009687@goober.corp.nai.org> Hi Linus, Can you please pull the m68knommu git tree, for-next branch: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next Quite a varied set of changes this time. A little more merge cleanup, this time the assembler entry code. New sub-architecture support for the ColdFire 5251/5253 and 5441x CPU families. Specific clk support code for the ColdFire 520x and 532x CPU familes. Refactoring of the ColdFire GPIO support. PCI bus support for some ColdFire CPUS that have PCI hardware (54xx family). This showed up a few problems with ColdFire cache, allocating coherent memory and bi-directional DMA support. Fixes for those too. Thanks Greg The following changes since commit 84a1caf1453c3d44050bd22db958af4a7f99315c: Linus Torvalds (1): Linux 3.5-rc7 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next Greg Ungerer (12): m68k: use some direct calls to ret_from_exception in entry code m68k: use jbsr to call functions instead of bsrl m68k: merge the MMU and non-MMU versions of the entry.S code m68knommu: platform support for 8390 based ethernet used on some boards m68k: use simpler dma_alloc_coherent() for ColdFire CPUs m68k: fix ColdFire clear cache operation m68k: add support for DMA_BIDIRECTIONAL in dma support functions m68k: common PCI support definitions and code m68k: add PCI bus support definitions for the ColdFire M54xx SoC family m68k: add IO access definitions to support PCI on ColdFire platforms m68k: add PCI bus code support for the ColdFire M54xx SoC family m68k: allow PCI bus to be enabled for ColdFire m54xx CPUs Steven King (9): m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips. m68knommu: Add support for the Coldfire 5251/5253 coldfire-qspi: Add support for the Coldfire 5251/5253. m68knommu: use MCF_IRQ_PIT1 instead of MCFINT_VECBASE + MCFINT_PIT1 m68knommu: Add support for the Coldfire m5441x. m68knommu: add definitions for the third interrupt controller on devices that don't have a third interrupt controller. m68knommu: Add rtc device for m5441x. m68knommu: Add clk definitions for m520x. m68knommu: Add clk definitions for m532x. arch/m68k/Kconfig.bus | 7 + arch/m68k/Kconfig.cpu | 18 ++- arch/m68k/Makefile | 2 + arch/m68k/include/asm/cacheflush_mm.h | 41 +++ arch/m68k/include/asm/dma.h | 8 +- arch/m68k/include/asm/gpio.h | 179 +------------ arch/m68k/include/asm/io_mm.h | 50 ++++- arch/m68k/include/asm/m520xsim.h | 14 + arch/m68k/include/asm/m523xsim.h | 1 + arch/m68k/include/asm/m525xsim.h | 194 +++++++++++++ arch/m68k/include/asm/m527xsim.h | 1 + arch/m68k/include/asm/m528xsim.h | 2 +- arch/m68k/include/asm/m532xsim.h | 17 ++ arch/m68k/include/asm/m5441xsim.h | 276 +++++++++++++++++++ arch/m68k/include/asm/m54xxacr.h | 4 + arch/m68k/include/asm/m54xxpci.h | 138 ++++++++++ arch/m68k/include/asm/m54xxsim.h | 3 + arch/m68k/include/asm/mcfclk.h | 43 +++ arch/m68k/include/asm/mcfgpio.h | 343 +++++++++++++++++++----- arch/m68k/include/asm/mcfsim.h | 5 + arch/m68k/include/asm/mcftimer.h | 2 +- arch/m68k/include/asm/mcfuart.h | 4 +- arch/m68k/include/asm/pci.h | 6 + arch/m68k/include/asm/pinmux.h | 30 -- arch/m68k/kernel/Makefile | 1 + arch/m68k/kernel/dma.c | 5 +- arch/m68k/kernel/entry.S | 452 ++++++++++++++++++++++++++++++- arch/m68k/kernel/entry_mm.S | 419 ---------------------------- arch/m68k/kernel/entry_no.S | 130 --------- arch/m68k/kernel/pcibios.c | 109 ++++++++ arch/m68k/mm/memory.c | 2 +- arch/m68k/platform/coldfire/Makefile | 7 +- arch/m68k/platform/coldfire/clk.c | 108 +++++++- arch/m68k/platform/coldfire/device.c | 57 ++++- arch/m68k/platform/coldfire/gpio.c | 172 ++++++++----- arch/m68k/platform/coldfire/head.S | 6 +- arch/m68k/platform/coldfire/intc-525x.c | 91 ++++++ arch/m68k/platform/coldfire/intc-simr.c | 26 ++- arch/m68k/platform/coldfire/m5206.c | 9 - arch/m68k/platform/coldfire/m520x.c | 103 +++++++- arch/m68k/platform/coldfire/m523x.c | 22 -- arch/m68k/platform/coldfire/m5249.c | 10 - arch/m68k/platform/coldfire/m525x.c | 66 +++++ arch/m68k/platform/coldfire/m5272.c | 11 - arch/m68k/platform/coldfire/m527x.c | 43 --- arch/m68k/platform/coldfire/m528x.c | 33 +--- arch/m68k/platform/coldfire/m5307.c | 9 - arch/m68k/platform/coldfire/m532x.c | 154 +++++++++-- arch/m68k/platform/coldfire/m5407.c | 9 - arch/m68k/platform/coldfire/m5441x.c | 261 ++++++++++++++++++ arch/m68k/platform/coldfire/m54xx.c | 7 - arch/m68k/platform/coldfire/mcf8390.c | 38 +++ arch/m68k/platform/coldfire/pci.c | 327 ++++++++++++++++++++++ arch/m68k/platform/coldfire/pinmux.c | 28 -- arch/m68k/platform/coldfire/pit.c | 4 +- arch/m68k/platform/coldfire/timers.c | 2 +- drivers/spi/Kconfig | 2 +- 57 files changed, 2985 insertions(+), 1126 deletions(-) create mode 100644 arch/m68k/include/asm/m525xsim.h create mode 100644 arch/m68k/include/asm/m5441xsim.h create mode 100644 arch/m68k/include/asm/m54xxpci.h create mode 100644 arch/m68k/include/asm/mcfclk.h delete mode 100644 arch/m68k/include/asm/pinmux.h delete mode 100644 arch/m68k/kernel/entry_mm.S delete mode 100644 arch/m68k/kernel/entry_no.S create mode 100644 arch/m68k/kernel/pcibios.c create mode 100644 arch/m68k/platform/coldfire/intc-525x.c create mode 100644 arch/m68k/platform/coldfire/m525x.c create mode 100644 arch/m68k/platform/coldfire/m5441x.c create mode 100644 arch/m68k/platform/coldfire/mcf8390.c create mode 100644 arch/m68k/platform/coldfire/pci.c delete mode 100644 arch/m68k/platform/coldfire/pinmux.c