Re: [uClinux-dev] ARM support
Hi thanks for the info, I will try and download the source code from the codesourcery website so I can see which version of gcc / bin / libc they are using and then use your instructions in the text file to hopefully build a new toolchain. I think its important to update the ARM toolchain as ARM are moving to the newer cortex devices, and I for one would like to see uClinux up and running on these new devices. I will email my progress. regards steve --- On Tue, 11/24/09, Greg Ungerer g...@snapgear.com wrote: From: Greg Ungerer g...@snapgear.com Subject: Re: [uClinux-dev] ARM support To: uClinux development list uclinux-dev@uclinux.org Date: Tuesday, November 24, 2009, 7:22 AM Hi Steven, steven taffs wrote: arm-linux-tools-20070808 looks like it was built with glibc-2.3.6 does that mean uClibc cant be selected / used within uClinux make menuconfig when using this tool chain ? The libc in the toolchain does't matter when compiling the uClinux-dist. It is completely self contained. you can (and should) select uClibc when compiling for non-MMU targets. (With no uClibc built into the toolchain though it does mean you can't build uClinux apps stand alone outside of a build framework like the uClinux-dist). Regards Greg --- On Tue, 11/24/09, Greg Ungerer g...@snapgear.com wrote: From: Greg Ungerer g...@snapgear.com Subject: Re: [uClinux-dev] ARM support To: uClinux development list uclinux-dev@uclinux.org Date: Tuesday, November 24, 2009, 12:49 AM Hi Steven, steven taffs wrote: I guess I don't follow that logic. Why would someone unfamiliar with uClinux not choose a toolchain from the links on that page? If you go to the arm website and look for uclinux you find the following page http://www.arm.com/products/os/linux_download.html Which references codesourcery 'Source and binary versions of the GNU GCC compiler are available from www.codesourcery.com' so I guess people download the uclinux source from you and then try and compile with codesourcery, I was thinking about doing the same thing. I would like to try and port uclinux to a Actel cortex-M1 FPGA to make a start on this I need a gcc compiler with the -mcpu=cortex-m1 target switch (ie gcc 4.4.2). Anyone how needs / wants to run uclinux on Arms new cortex chips needs to use a newer compile (minimum 4.3.0). How much work would it be to upgrade the uClinux Arm tool chain to use a newer version of gcc? Its not overly difficult. The arm-linux- toolchains linked from uclinux.org are reasonably basic builds. (There is a text file in the download directory with instructions on how that one was built). Regards Greg (sorry if this question is a bit basic never really played around with tool chains before) --- On Mon, 11/23/09, Greg Ungerer g...@snapgear.com wrote: From: Greg Ungerer g...@snapgear.com Subject: Re: [uClinux-dev] ARM support To: uClinux development list uclinux-dev@uclinux.org Date: Monday, November 23, 2009, 5:36 AM Hi, ucli...@browserseal.com wrote: On 11/18/2009, Greg Ungerer g...@snapgear.com wrote: ucli...@browserseal.com wrote: I'm trying to compile the latest version of uClinux on ARM and the multitude of errors that I'm getting leads me to believe that this architecture simply is not supported anymore, hence the first question - what happened to ARM support and uClinux in general ? Last time I checked, i.e. about two years ago, it was probably the most popular embedded distro, at least for ARM - and now it does not even compile ! You are wrong, it does compile. I have an automated build system that builds approximately 150 board/kernel/lib combinations(*) each night. Every release is run through this. It compiles GDB/ARMulator with linux-2.4.x and linux-2.6.x kernels and both little and big endian and the GDB/Skyeye target with 2.4.x and 2.6.x kernels (using my arm-linux- toolchains). (* of course the whole uClinux-dist tree has way more than 150 possible combinations of board/kernel/lib. With the resources I have that is about as much as I can cover in a single day. I have just chosen a variety of interesting targets on a variety of CPU types to test compile for). I will send a separate email with compilation errors, I just think that it would be better to have a separate thread for this general discussion. Provided there is anybody out there interested in discussing ARM, which I seriously doubt. Are you serious? The only conclusion I can draw from your problems is that people who choose to use various other toolchains with the uClinux-dist don't choose to send patches back to make them work properly with the dist. I believe I did provide a complete list of the changes
Re: [uClinux-dev] ARM support
ok if I go to the codesourcery web site and choose the following toolchain ARM uClinux and then choose cortex-m1 or cortex-m3 the versions within their tool chain (currently) are GNU Binary utilities 2.19.51-sg++ GNU C C++ Compilers 4.4.1-sg++ GNU Debugger 6.8.50-sg++ uClibc C Library 0.9.30-sg++ They use gcc 4.4.1 because it fully supports the latest and greatest ARMv7 cores (ie cortex). Will try to use buildroot / manual build with the versions above to and get a working tool chain going. --- On Tue, 11/24/09, steven taffs steventa...@yahoo.com wrote: From: steven taffs steventa...@yahoo.com Subject: Re: [uClinux-dev] ARM support To: uClinux development list uclinux-dev@uclinux.org Date: Tuesday, November 24, 2009, 9:52 AM Hi thanks for the info, I will try and download the source code from the codesourcery website so I can see which version of gcc / bin / libc they are using and then use your instructions in the text file to hopefully build a new toolchain. I think its important to update the ARM toolchain as ARM are moving to the newer cortex devices, and I for one would like to see uClinux up and running on these new devices. I will email my progress. regards steve --- On Tue, 11/24/09, Greg Ungerer g...@snapgear.com wrote: From: Greg Ungerer g...@snapgear.com Subject: Re: [uClinux-dev] ARM support To: uClinux development list uclinux-dev@uclinux.org Date: Tuesday, November 24, 2009, 7:22 AM Hi Steven, steven taffs wrote: arm-linux-tools-20070808 looks like it was built with glibc-2.3.6 does that mean uClibc cant be selected / used within uClinux make menuconfig when using this tool chain ? The libc in the toolchain does't matter when compiling the uClinux-dist. It is completely self contained. you can (and should) select uClibc when compiling for non-MMU targets. (With no uClibc built into the toolchain though it does mean you can't build uClinux apps stand alone outside of a build framework like the uClinux-dist). Regards Greg --- On Tue, 11/24/09, Greg Ungerer g...@snapgear.com wrote: From: Greg Ungerer g...@snapgear.com Subject: Re: [uClinux-dev] ARM support To: uClinux development list uclinux-dev@uclinux.org Date: Tuesday, November 24, 2009, 12:49 AM Hi Steven, steven taffs wrote: I guess I don't follow that logic. Why would someone unfamiliar with uClinux not choose a toolchain from the links on that page? If you go to the arm website and look for uclinux you find the following page http://www.arm.com/products/os/linux_download.html Which references codesourcery 'Source and binary versions of the GNU GCC compiler are available from www.codesourcery.com' so I guess people download the uclinux source from you and then try and compile with codesourcery, I was thinking about doing the same thing. I would like to try and port uclinux to a Actel cortex-M1 FPGA to make a start on this I need a gcc compiler with the -mcpu=cortex-m1 target switch (ie gcc 4.4.2). Anyone how needs / wants to run uclinux on Arms new cortex chips needs to use a newer compile (minimum 4.3.0). How much work would it be to upgrade the uClinux Arm tool chain to use a newer version of gcc? Its not overly difficult. The arm-linux- toolchains linked from uclinux.org are reasonably basic builds. (There is a text file in the download directory with instructions on how that one was built). Regards Greg (sorry if this question is a bit basic never really played around with tool chains before) --- On Mon, 11/23/09, Greg Ungerer g...@snapgear.com wrote: From: Greg Ungerer g...@snapgear.com Subject: Re: [uClinux-dev] ARM support To: uClinux development list uclinux-dev@uclinux.org Date: Monday, November 23, 2009, 5:36 AM Hi, ucli...@browserseal.com wrote: On 11/18/2009, Greg Ungerer g...@snapgear.com wrote: ucli...@browserseal.com wrote: I'm trying to compile the latest version of uClinux on ARM and the multitude of errors that I'm getting leads me to believe that this architecture simply is not supported anymore, hence the first question - what happened to ARM support and uClinux in general ? Last time I checked, i.e. about two years ago, it was probably the most popular embedded distro, at least for ARM - and now it does not even compile ! You are wrong, it does compile. I have an automated build system that builds approximately 150 board/kernel/lib combinations(*) each night. Every release is run through this. It compiles GDB/ARMulator with linux-2.4.x and linux-2.6.x kernels and both little and big endian and the GDB/Skyeye
[uClinux-dev] [PATCH] NOMMU: use copy_*_user_page() in access_process_vm()
From: Jie Zhang jie.zh...@analog.com
The mmu code uses the copy_*_user_page() variants in access_process_vm()
rather than copy_*_user() as the former includes an icache flush. This is
important when doing things like setting software breakpoints with gdb.
So switch the nommu code over to do the same.
Signed-off-by: Jie Zhang jie.zh...@analog.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
mm/nommu.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index 9876fa0..51ae9be 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1889,9 +1889,11 @@ int access_process_vm(struct task_struct *tsk, unsigned
long addr, void *buf, in
/* only read or write mappings where it is permitted */
if (write vma-vm_flags VM_MAYWRITE)
- len -= copy_to_user((void *) addr, buf, len);
+ copy_to_user_page(vma, NULL, NULL,
+ (void *) addr, buf, len);
else if (!write vma-vm_flags VM_MAYREAD)
- len -= copy_from_user(buf, (void *) addr, len);
+ copy_from_user_page(vma, NULL, NULL,
+ buf, (void *) addr, len);
else
len = 0;
} else {
--
1.6.5.3
___
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] NOMMU: use copy_*_user_page() in access_process_vm()
Mike Frysinger wrote:
From: Jie Zhang jie.zh...@analog.com
The mmu code uses the copy_*_user_page() variants in access_process_vm()
rather than copy_*_user() as the former includes an icache flush. This is
important when doing things like setting software breakpoints with gdb.
So switch the nommu code over to do the same.
Reasonable, but it's a bit subtle don't you think?
How about a one-line comment saying why it's using copy_*_user_page()?
(If it was called copy_*_user_flush_icache() I wouldn't say anything,
but it isn't).
Signed-off-by: Jie Zhang jie.zh...@analog.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
mm/nommu.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index 9876fa0..51ae9be 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1889,9 +1889,11 @@ int access_process_vm(struct task_struct *tsk,
unsigned long addr, void *buf, in
/* only read or write mappings where it is permitted */
if (write vma-vm_flags VM_MAYWRITE)
- len -= copy_to_user((void *) addr, buf, len);
+ copy_to_user_page(vma, NULL, NULL,
+ (void *) addr, buf, len);
else if (!write vma-vm_flags VM_MAYREAD)
- len -= copy_from_user(buf, (void *) addr, len);
+ copy_from_user_page(vma, NULL, NULL,
+ buf, (void *) addr, len);
else
len = 0;
} else {
___
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] NOMMU: use copy_*_user_page() in access_process_vm()
Jivin Mike Frysinger lays it down ...
From: Jie Zhang jie.zh...@analog.com
The mmu code uses the copy_*_user_page() variants in access_process_vm()
rather than copy_*_user() as the former includes an icache flush. This is
important when doing things like setting software breakpoints with gdb.
So switch the nommu code over to do the same.
Signed-off-by: Jie Zhang jie.zh...@analog.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
Acked-by: David McCullough david_mccullo...@mcafee.com
Cheers,
Davidm
---
mm/nommu.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index 9876fa0..51ae9be 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1889,9 +1889,11 @@ int access_process_vm(struct task_struct *tsk,
unsigned long addr, void *buf, in
/* only read or write mappings where it is permitted */
if (write vma-vm_flags VM_MAYWRITE)
- len -= copy_to_user((void *) addr, buf, len);
+ copy_to_user_page(vma, NULL, NULL,
+ (void *) addr, buf, len);
else if (!write vma-vm_flags VM_MAYREAD)
- len -= copy_from_user(buf, (void *) addr, len);
+ copy_from_user_page(vma, NULL, NULL,
+ buf, (void *) addr, len);
else
len = 0;
} else {
--
1.6.5.3
___
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] Controlling GPIO on coldfire
Hi Dan, Dan Snyder wrote: I am attempting to use the hardware encryption support provided by the 5271 and am running into this problem. (Access Error Exception when attempting to read/write from userspace). How can I modify the kernel to allow access to 0x4000 through 0x401b009f ? Section 11.4 of the 5271 RM seems to be what you are looking for. It describes the access control implemented on this part. I have been poking through the kernel headers for hours now and I am still clueless. You probably won't find anything associated with this in the headers, since the kernel doesn't generally support any of these types of features. I believe I need to add the address range to /arch/m68knommu/platform/527x/config.c but I am not sure if this is correct or exactly how to do so. config.c would be an ok place to set this. I suspect you want to add something like: writeb(0x04, 0x4030) which sets the GPACR0 register to allows kernel and user modes to have read/write access. Any guidance would be much appreciated. Thank you Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: 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] NOMMU: use copy_*_user_page() in access_process_vm()
On Wed, Nov 25, 2009 at 02:27:22PM +0800, Jie Zhang wrote: On 11/25/2009 02:16 PM, Jamie Lokier wrote: Mike Frysinger wrote: From: Jie Zhangjie.zh...@analog.com The mmu code uses the copy_*_user_page() variants in access_process_vm() rather than copy_*_user() as the former includes an icache flush. This is important when doing things like setting software breakpoints with gdb. So switch the nommu code over to do the same. Reasonable, but it's a bit subtle don't you think? How about a one-line comment saying why it's using copy_*_user_page()? (If it was called copy_*_user_flush_icache() I wouldn't say anything, but it isn't). But I think it's well known in Linux kernel developers that copy_to_user_page and copy_from_user_page should do cache flushing. It's documented in Documentation/cachetlb.txt. I don't think it's necessary to replicate it here. Documenting it in the changelog is sufficient I think. Platforms that need the I-cache flush can deal with it there, and those that don't aren't going to notice any difference regardless. The change in semantics is subtle, but as it's bringing it in line with MMU behaviour it's not really worth noting the fact that NOMMU behaviour used to be different for no particular reason. Acked-by: Paul Mundt let...@linux-sh.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
