Re: [uClinux-dev] Help with relocation truncation problems on m5235 coldfire target
On Thu, Feb 14, 2013 at 08:52:10AM -0800, Steve deRosier wrote: Hi Larry, On Fri, Feb 8, 2013 at 4:11 PM, Larry Baker ba...@usgs.gov wrote: Steve, I found this at http://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc/M680x0-Options.html. I don't know if gcc 4.3.2 has this option, but it's worth a try. Maybe you only have to use this in certain routines? Maybe not, if there is just one GOT for the entire program. Other google hits for relocation truncated to fit: R_68K_GOT16O said to remove XIP options or shared library, like -msep-data. I'm not sure that is possible on a ColdFire. I noticed you are using -O1. Did you try -Os? My ColdFire distribution uses -Os. Yes, my research came up with the -mxgot option also. Tried that and came up with a problem where the elf2flt doesn't like the larger GOT format. Aparently it's a problem my client has been fighting with for a long time and I was able to define out a log statement and that killed enough strings (5,000 log strings!) in the project to get it to build. Basically I was told: Get it to build and we'll deal with the problem over here. Done. -Os helped some also, but not with the GOT issue. But size-wise it helped. Upgrading to Linux 3.2 from 2.4 (and the other apps) has increased our total image size by nearly 50% and we're starting to bump into size issues. I'm having to kill off some useful technician and debugging utilities now. Some years ago, I have written and submitted, but not pushed hard enough, a patch to gcc for m68k permitting to generate an absolute text segment with only a GOT table for the data and bss segments. Of course you must know the load address at link-time, but that's doable if you do XIP. This was combined with a patch to genromfs providing the load address to the linker when generating the romfs image. This way I had an unique absolute text segment for busybox with a small GOT table. This must be still floating around Hope that helps Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles ___ 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] RS485 serial communication on ColdFire
For those interested, I just noticed the following thread on linux-serial, about rs485 on coldfire : http://marc.info/?l=linux-serialm=135811935518410w=2 Philippe ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH] fs/jfs: Fix typo in comment : 'how may' - 'how many'
Signed-off-by: Philippe De Muyter p...@macqel.be Cc: triv...@kernel.org --- fs/jfs/super.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/jfs/super.c b/fs/jfs/super.c index 1a543be..060ba63 100644 --- a/fs/jfs/super.c +++ b/fs/jfs/super.c @@ -154,7 +154,7 @@ static int jfs_statfs(struct dentry *dentry, struct kstatfs *buf) /* * If we really return the number of allocated free inodes, some * applications will fail because they won't see enough free inodes. -* We'll try to calculate some guess as to how may inodes we can +* We'll try to calculate some guess as to how many inodes we can * really allocate * * buf-f_files = atomic_read(imap-im_numinos); -- 1.7.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
Re: [uClinux-dev] [PATCH] fs/jfs: Fix typo in comment : 'how may' - 'how many'
On Wed, Jan 16, 2013 at 10:55:48PM +0100, Philippe De Muyter wrote: - * We'll try to calculate some guess as to how may inodes we can + * We'll try to calculate some guess as to how many inodes we can Oops. That was not meant for uclinux-dev. :) Philippe ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH] m68k / serial: mcf.c: avoid recomputing 'port' in mcf_console_putc.
Let's `mcf_console_putc' require a `struct uart_port *' instead of a
`struct console *'. This makes cleaner and slightly more efficient
code, and also makes mcf_console_putc easier to use for early debugging.
Signed-off-by: Philippe De Muyter p...@macqel.be
---
drivers/tty/serial/mcf.c | 32
1 files changed, 20 insertions(+), 12 deletions(-)
On Tue, Jan 15, 2013 at 11:28:38PM +1000, Greg Ungerer wrote:
If you are getting into the kernel startup code, then take the trace
up to the C code level. Code up a simple console char output routine
(use the serial driver console routines as an example).
diff --git a/drivers/tty/serial/mcf.c b/drivers/tty/serial/mcf.c
index fcd56ab..5f60382 100644
--- a/drivers/tty/serial/mcf.c
+++ b/drivers/tty/serial/mcf.c
@@ -473,31 +473,39 @@ int __init early_mcf_setup(struct mcf_platform_uart
*platp)
//
-static void mcf_console_putc(struct console *co, const char c)
+static inline void mcf_console_wait(struct uart_port *port, unsigned char
condition)
{
- struct uart_port *port = (mcf_ports + co-index)-port;
int i;
- for (i = 0; (i 0x1); i++) {
- if (readb(port-membase + MCFUART_USR) MCFUART_USR_TXREADY)
+ for (i = 0; i 0x1; i++) {
+ if (readb(port-membase + MCFUART_USR) condition)
break;
}
+}
+
+//
+
+static void mcf_console_putc(struct uart_port *port, const char c)
+{
+
+ mcf_console_wait(port, MCFUART_USR_TXREADY);
writeb(c, port-membase + MCFUART_UTB);
- for (i = 0; (i 0x1); i++) {
- if (readb(port-membase + MCFUART_USR) MCFUART_USR_TXREADY)
- break;
- }
}
//
static void mcf_console_write(struct console *co, const char *s, unsigned int
count)
{
- for (; (count); count--, s++) {
- mcf_console_putc(co, *s);
- if (*s == '\n')
- mcf_console_putc(co, '\r');
+ struct uart_port *port = (mcf_ports + co-index)-port;
+
+ while (count--) {
+ unsigned char c = *s++;
+
+ mcf_console_putc(port, c);
+ if (c == '\n')
+ mcf_console_putc(port, '\r');
}
+ mcf_console_wait(port, MCFUART_USR_TXEMPTY);
}
//
--
1.7.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
Re: [uClinux-dev] [m68k, powerpc, dma, ethernet, freescale RFA] Coldfire m54xx FEC ethernet driver
Hi Greg, On Tue, Oct 16, 2012 at 04:39:05PM +1000, Greg Ungerer wrote: Hi Philippe, On 09/10/12 19:07, Philippe De Muyter wrote: [CCing lkml, linux-ppc, netdev, linux-m68k] Hello kernel sources architects I have a working driver for the m54xx FEC ethernet driver that I would like to integrate in the kernel tree. Problems are that - this driver needs an associated DMA driver (provided by FreeScale) wich is not dma-engine enabled - they're are already many fec drivers in the kernel tree, and at least one, fec_mpc52xx.c, seems to be very similar (information below), to the one for the mcf54xx, except it uses a differently named associated DMA driver (BestComm/SmartDma/SDMA) which is also not dma-engine enabled, and even kept hidden in /arch/powerpc where it is inaccessible when compiling for m68k. The underlying DMA part from Freescale however seems similar to the one used in the m54xx. (again, see information below) So, now I am lost, what should I do ? The current state of my patches [http://mailman.uclinux.org/pipermail/uclinux-dev/2012-September/052147.html] is pushing the freescale provided MCD_DMA dma driver to /drivers/dma, without adding the dma-engine compatibility layer, and adding the specific fec_m54xx ethernet driver to /drivers/net/ethernet/freescale Do you get any responses? I didn't see any... No, and none also about my simpler patch moving arch/powerpc/sysdev/bestcomm to drivers/dma/bestcomm (except a private and useful one telling me how to set '-M' option as default for 'git format-patch'), but at least this simpler patch seems to be in a wait bucket at http://patchwork.ozlabs.org/project/linuxppc-dev/list/. Regards Philippe PS: -M as default for 'git format-patch': put [diff] renames = true in .git/config Regards Greg On Tue, Oct 09, 2012 at 04:12:44PM +1000, Greg Ungerer wrote: Hi Philippe, On 05/10/12 01:03, Philippe De Muyter wrote: On Thu, Oct 04, 2012 at 04:56:01PM +0200, Philippe De Muyter wrote: On Thu, Oct 04, 2012 at 11:33:32PM +1000, Greg Ungerer wrote: My biggest concern is the amount of MCD/DMA support code. And it is all done quite differently to everything else in the kernel. We may get a bit of push back from kernel folk who look after DMA. Actually, there is already a similar code in arch/powerpc/sysdev/bestcomm (also from freescale, maybe an identical part, but I did not find any usable doc), but the powerpc folks kept that hidden in the arch/powerpc tree, instead of installing it in drivers/dma. The MCD DMA or DMA FEC code from freescale has a comment implying that this was first used in the MPC8220 part. And Montavista has a MPC8220 port, but I did not find it, so I do not know where they installed the MCD DMA driver. Ok, looks like there is a bit a variance in all this. I also began to read the mpc5200 user's guide parts about the fec and BestComm/SmartDma/SDMA (not sure which one is the official FreeScale name) and they look very similar, but not identical, to their m54xx counterparts. It seems possible to make the fec_mpc52xx.c driver work for the m54xx but that needs at least: - moving some files or part of them from /arch/powerpc/sysdev and /arch/powerpc/include/asm to /drivers/dma and /include/linux, - renaming the fec_mpc52xx files to a more sensible name, - providing out_be32 and in_be32 in /arch/m68k/include/asm/io.h, - and then unifying the interface to BestComm/SmartDma/SDMA and MCD_DMA in mcf_52xx.c. An additional problem is that the freescale docs for powerpcs and for coldfires do not use the same mnemonics for the same registers. e.g. FEC registers offset MPC5200 MCF5484 == === === 000 FEC_ID n/a 004 IEVENT EIR 008 IMASK EIMR 010 R_DES_ACTIVEn/a 014 X_DES_ACTIVEn/a 024 ECNTRL ECR 040 MII_DATAMDATA 044 MII_SPEED MSCR 064 MIB_CONTROL MIBC 084 R_CNTRL RCR 088 R_HASH RHR 0C4 X_CNTRL TCR 0E4 PADDR1 PALR 0E8 PADDR2 PAHR 0EC OP_PAUSEOPD 118 IADDR1 IAUR 11C IADDR1 IALR 120 GADDR1 GAUR 124 GADDR2 GALR 144 X_WMRK FECTFWR 184 RFIFO_DATA FECRFDR 188 RFIFO_STATUSFECRFSR 18C RFIFO_CONTROL FECRFCR 190 RFIFO_LRF_PTR FECRLRFP 194 RFIFO_LWF_PTR FECRLWFP 198 RFIFO_ALARM FECRFAR 19C RFIFO_RDPTR FECRFRP 1A0 RFIFO_WRPTR FECRFWP 1A4 TFIFO_DATA FECTFDR 1A8 TFIFO_STATUSFECTFSR 1AC TFIFO_CONTROL FECTFCR 1B0 TFIFO_LRF_PTR FECTLRFP 1B4 TFIFO_LWF_PTR FECTLWFP 1B8 TFIFO_ALARM FECTFAR
[uClinux-dev] [m68k, powerpc, dma, ethernet, freescale RFA] Coldfire m54xx FEC ethernet driver
[CCing lkml, linux-ppc, netdev, linux-m68k] Hello kernel sources architects I have a working driver for the m54xx FEC ethernet driver that I would like to integrate in the kernel tree. Problems are that - this driver needs an associated DMA driver (provided by FreeScale) wich is not dma-engine enabled - they're are already many fec drivers in the kernel tree, and at least one, fec_mpc52xx.c, seems to be very similar (information below), to the one for the mcf54xx, except it uses a differently named associated DMA driver (BestComm/SmartDma/SDMA) which is also not dma-engine enabled, and even kept hidden in /arch/powerpc where it is inaccessible when compiling for m68k. The underlying DMA part from Freescale however seems similar to the one used in the m54xx. (again, see information below) So, now I am lost, what should I do ? The current state of my patches [http://mailman.uclinux.org/pipermail/uclinux-dev/2012-September/052147.html] is pushing the freescale provided MCD_DMA dma driver to /drivers/dma, without adding the dma-engine compatibility layer, and adding the specific fec_m54xx ethernet driver to /drivers/net/ethernet/freescale Best regards Philippe On Tue, Oct 09, 2012 at 04:12:44PM +1000, Greg Ungerer wrote: Hi Philippe, On 05/10/12 01:03, Philippe De Muyter wrote: On Thu, Oct 04, 2012 at 04:56:01PM +0200, Philippe De Muyter wrote: On Thu, Oct 04, 2012 at 11:33:32PM +1000, Greg Ungerer wrote: My biggest concern is the amount of MCD/DMA support code. And it is all done quite differently to everything else in the kernel. We may get a bit of push back from kernel folk who look after DMA. Actually, there is already a similar code in arch/powerpc/sysdev/bestcomm (also from freescale, maybe an identical part, but I did not find any usable doc), but the powerpc folks kept that hidden in the arch/powerpc tree, instead of installing it in drivers/dma. The MCD DMA or DMA FEC code from freescale has a comment implying that this was first used in the MPC8220 part. And Montavista has a MPC8220 port, but I did not find it, so I do not know where they installed the MCD DMA driver. Ok, looks like there is a bit a variance in all this. I also began to read the mpc5200 user's guide parts about the fec and BestComm/SmartDma/SDMA (not sure which one is the official FreeScale name) and they look very similar, but not identical, to their m54xx counterparts. It seems possible to make the fec_mpc52xx.c driver work for the m54xx but that needs at least: - moving some files or part of them from /arch/powerpc/sysdev and /arch/powerpc/include/asm to /drivers/dma and /include/linux, - renaming the fec_mpc52xx files to a more sensible name, - providing out_be32 and in_be32 in /arch/m68k/include/asm/io.h, - and then unifying the interface to BestComm/SmartDma/SDMA and MCD_DMA in mcf_52xx.c. An additional problem is that the freescale docs for powerpcs and for coldfires do not use the same mnemonics for the same registers. e.g. FEC registers offset MPC5200 MCF5484 == === === 000 FEC_ID n/a 004 IEVENT EIR 008 IMASK EIMR 010 R_DES_ACTIVEn/a 014 X_DES_ACTIVEn/a 024 ECNTRL ECR 040 MII_DATAMDATA 044 MII_SPEED MSCR 064 MIB_CONTROL MIBC 084 R_CNTRL RCR 088 R_HASH RHR 0C4 X_CNTRL TCR 0E4 PADDR1 PALR 0E8 PADDR2 PAHR 0EC OP_PAUSEOPD 118 IADDR1 IAUR 11C IADDR1 IALR 120 GADDR1 GAUR 124 GADDR2 GALR 144 X_WMRK FECTFWR 184 RFIFO_DATA FECRFDR 188 RFIFO_STATUSFECRFSR 18C RFIFO_CONTROL FECRFCR 190 RFIFO_LRF_PTR FECRLRFP 194 RFIFO_LWF_PTR FECRLWFP 198 RFIFO_ALARM FECRFAR 19C RFIFO_RDPTR FECRFRP 1A0 RFIFO_WRPTR FECRFWP 1A4 TFIFO_DATA FECTFDR 1A8 TFIFO_STATUSFECTFSR 1AC TFIFO_CONTROL FECTFCR 1B0 TFIFO_LRF_PTR FECTLRFP 1B4 TFIFO_LWF_PTR FECTLWFP 1B8 TFIFO_ALARM FECTFAR 1BC TFIFO_RDPTR FECTFRP 1C0 TFIFO_WRPTR FECTFWP 1C4 RESET_CNTRL FECFRST 1C8 XMIT_FSMFECCTCWR Probably the best thing to do is post the patches on the linux kernel mailing list then, asking for direction on a dma driver. I have no problem with it going into the arch/m68k area. So that is always an option. For the dma engines, the similarity is also obvious. For example, find below side by side mpc52xx and m54xx definitions for the main DMA registers : from mpc52xx.h from MCD_dma.h /* SDMA
Re: [uClinux-dev] [PATCH 3/3] m68knommu: Add ethernet driver for MCF547x/MCF548x
Hi Greg, On Thu, Oct 04, 2012 at 04:56:35PM +1000, Greg Ungerer wrote: Hi Philippe, I think this needs to be done as a platform driver. It is really the standard way to deal with platform specifics cleanly. I know this hardware really only exists on one device, but that is no reason not to do it. Follow the example of the other Freescale FEC driver. It won't really change the code too much, it just makes the platform hardware specifics more cleanly separated from the driver proper. A few inline comments below too. Thanks for your comments. I had already started the conversion to the dma_map_single api, but I am worried that those functions are not inlined altough IIRC they often resolve to nothing (for the unmap case) or to a single asm(nop) (for the map case). I'll look at your other comments, and especially the notion of platform driver, that I do not really know. Best regards Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles ___ 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 3/3] m68knommu: Add ethernet driver forMCF547x/MCF548x
On Wed, Sep 26, 2012 at 01:23:21AM +0200, Stany MARCEL wrote: Helo, Flushing all caches for each sent frame might not be a good solution. I think that performances will be very bad. I'll look at this point in my tests. It might be more interesting to use caches in write through mode, or forcing theses explicit data out of cache. I (and the default for M54xx) use the write through mode. Philippe If kmalloc with GFP_DMA returns data that is not write cached (ideally SRAM for performances) there is no need to flush caches. Regards, -Original Message- From: Philippe De Muyter [mailto:p...@macqel.be] Sent: Tue 9/25/2012 10:34 PM To: Stany MARCEL Cc: uclinux-dev@uclinux.org Subject: Re: [uClinux-dev] [PATCH 3/3] m68knommu: Add ethernet driver forMCF547x/MCF548x On Tue, Sep 25, 2012 at 10:20:07PM +0200, Philippe De Muyter wrote: You should rather use 'mcf_cache_push'. I should have written: You should rather use '__flush_cache_all' And that should probably go in arch/m68k/include/asm/cacheflush_mm.h, as long as arch/m68k/include/asm/cacheflush_mm.h and arch/m68k/include/asm/cacheflush_no.h are separate files. Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles ___ 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 3/3] m68knommu: Add ethernet driver for MCF547x/MCF548x
Hello Stany [CCing uclinux-dev] On Tue, Sep 25, 2012 at 06:07:45PM +0200, Stany MARCEL wrote: Hello Philippe, I have to do the following modification to compile your drivers with MMU enabled : diff --git a/drivers/net/ethernet/freescale/fec_m54xx.c b/drivers/net/ethernet/freescale/fec_m54xx.c index 4204a14..f6cafc6 100644 --- a/drivers/net/ethernet/freescale/fec_m54xx.c +++ b/drivers/net/ethernet/freescale/fec_m54xx.c @@ -41,6 +41,10 @@ */ #define flush_and_invalidate_dcache() flush_cache_all() +#ifdef CONFIG_MMU +#defineflush_dcache_range(A, L) flush_cf_dcache(A, L) +#endif + #include fec_m54xx.h #include linux/phy.h Unfortunately, that's wromg. Read the comment in arch/m68k/include/asm/cacheflush_mm.h : /* * Use the ColdFire cpushl instruction to push (and invalidate) cache lines. * The start and end addresses are cache line numbers not memory addresses. */ So IIRC flush_cf_icache, flush_cf_dcache and flush_cf_bcache seemed uselesss to me. You should rather use 'mcf_cache_push'. I'll keep you informed of my results. Thanks Philippe ___ 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 3/3] m68knommu: Add ethernet driver for MCF547x/MCF548x
On Tue, Sep 25, 2012 at 10:20:07PM +0200, Philippe De Muyter wrote: You should rather use 'mcf_cache_push'. I should have written: You should rather use '__flush_cache_all' And that should probably go in arch/m68k/include/asm/cacheflush_mm.h, as long as arch/m68k/include/asm/cacheflush_mm.h and arch/m68k/include/asm/cacheflush_no.h are separate files. Philippe ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH m68knommu] Add the m54xx fec driver
Hello, I have cleaned up and updated to 3.6-rc5 my previous port of the freescale-written driver for the fast Ethernet Controller of the M547x and M548x ColdFires. It seems from comments found in Freescale sources that this uses a MultiChannel DMA controller marketed as MCD and available also in the NPC8220 also from Freescale. Therefore, I have split the submission in three parts : A generic MCD dma driver The M54xx instantiation of the MCD driver The FEC driver for M54xx I know there are still lines above 80 characters, but I feel they must be left that way. There are also parts of an unfinished netpoll interface. Feel free to test and comment. Philippe ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 2/3] m68knommu: Add the m54xx-specific bits for the MultiChannel DMA driver
This driver is not (yet) dmaengine enabled, but is needed by the ethernet fec driver for the ColdFire M54xx processors. Original work was made by Kurt Mahan at Freescale. Signed-off-by: Philippe De Muyter p...@macqel.be --- arch/m68k/include/asm/m54xxdma.h | 67 + arch/m68k/include/asm/m54xxdma_api.h | 62 arch/m68k/include/asm/m54xxsim.h |1 + arch/m68k/include/asm/m54xxsram.h| 11 + drivers/dma/Kconfig | 10 + drivers/dma/fsl_mcd_dma/Makefile |1 + drivers/dma/fsl_mcd_dma/m54xx_dma.c | 519 ++ 7 files changed, 671 insertions(+), 0 deletions(-) create mode 100644 arch/m68k/include/asm/m54xxdma.h create mode 100644 arch/m68k/include/asm/m54xxdma_api.h create mode 100644 arch/m68k/include/asm/m54xxsram.h create mode 100644 drivers/dma/fsl_mcd_dma/m54xx_dma.c diff --git a/arch/m68k/include/asm/m54xxdma.h b/arch/m68k/include/asm/m54xxdma.h new file mode 100644 index 000..cc57872 --- /dev/null +++ b/arch/m68k/include/asm/m54xxdma.h @@ -0,0 +1,67 @@ +/* + * ColdFire 547x/548x DMA controller support. + */ +#ifndef __MCF548X_DMA_H__ +#define __MCF548X_DMA_H__ + + +/* Register read/write macros */ +#define MCF_DMA_DIPR(MCF_MBAR+0x008014) +#define MCF_DMA_DIMR(MCF_MBAR+0x008018) +#define MCF_DMA_IMCR(MCF_MBAR+0x00805C) + +/* Bit definitions and macros for MCF_DMA_DIPR */ +#define MCF_DMA_DIPR_TASK(x) (1 (x)) + +/* Bit definitions and macros for MCF_DMA_DIMR */ +#define MCF_DMA_DIMR_TASK(x) (1 (x)) + +/* Bit definitions and macros for MCF_DMA_IMCR */ +#define MCF_DMA_IMCR_SRC16(x)(((x)0x0003)0) +#define MCF_DMA_IMCR_SRC17(x)(((x)0x0003)2) +#define MCF_DMA_IMCR_SRC18(x)(((x)0x0003)4) +#define MCF_DMA_IMCR_SRC19(x)(((x)0x0003)6) +#define MCF_DMA_IMCR_SRC20(x)(((x)0x0003)8) +#define MCF_DMA_IMCR_SRC21(x)(((x)0x0003)10) +#define MCF_DMA_IMCR_SRC22(x)(((x)0x0003)12) +#define MCF_DMA_IMCR_SRC23(x)(((x)0x0003)14) +#define MCF_DMA_IMCR_SRC24(x)(((x)0x0003)16) +#define MCF_DMA_IMCR_SRC25(x)(((x)0x0003)18) +#define MCF_DMA_IMCR_SRC26(x)(((x)0x0003)20) +#define MCF_DMA_IMCR_SRC27(x)(((x)0x0003)22) +#define MCF_DMA_IMCR_SRC28(x)(((x)0x0003)24) +#define MCF_DMA_IMCR_SRC29(x)(((x)0x0003)26) +#define MCF_DMA_IMCR_SRC30(x)(((x)0x0003)28) +#define MCF_DMA_IMCR_SRC31(x)(((x)0x0003)30) +#define MCF_DMA_IMCR_SRC16_FEC0RX(0x) +#define MCF_DMA_IMCR_SRC17_FEC0TX(0x) +#define MCF_DMA_IMCR_SRC18_FEC0RX(0x0020) +#define MCF_DMA_IMCR_SRC19_FEC0TX(0x0080) +#define MCF_DMA_IMCR_SRC20_FEC1RX(0x0100) +#define MCF_DMA_IMCR_SRC21_DREQ1 (0x) +#define MCF_DMA_IMCR_SRC21_FEC1TX(0x0400) +#define MCF_DMA_IMCR_SRC22_FEC0RX(0x1000) +#define MCF_DMA_IMCR_SRC23_FEC0TX(0x4000) +#define MCF_DMA_IMCR_SRC24_CTM0 (0x0001) +#define MCF_DMA_IMCR_SRC24_FEC1RX(0x0002) +#define MCF_DMA_IMCR_SRC25_CTM1 (0x0004) +#define MCF_DMA_IMCR_SRC25_FEC1TX(0x0008) +#define MCF_DMA_IMCR_SRC26_USBEP4(0x) +#define MCF_DMA_IMCR_SRC26_CTM2 (0x0020) +#define MCF_DMA_IMCR_SRC27_USBEP5(0x) +#define MCF_DMA_IMCR_SRC27_CTM3 (0x0080) +#define MCF_DMA_IMCR_SRC28_USBEP6(0x) +#define MCF_DMA_IMCR_SRC28_CTM4 (0x0100) +#define MCF_DMA_IMCR_SRC28_DREQ1 (0x0200) +#define MCF_DMA_IMCR_SRC28_PSC2RX(0x0300) +#define MCF_DMA_IMCR_SRC29_DREQ1 (0x0400) +#define MCF_DMA_IMCR_SRC29_CTM5 (0x0800) +#define MCF_DMA_IMCR_SRC29_PSC2TX(0x0C00) +#define MCF_DMA_IMCR_SRC30_FEC1RX(0x) +#define MCF_DMA_IMCR_SRC30_CTM6 (0x1000) +#define MCF_DMA_IMCR_SRC30_PSC3RX(0x3000) +#define MCF_DMA_IMCR_SRC31_FEC1TX(0x) +#define MCF_DMA_IMCR_SRC31_CTM7 (0x8000) +#define MCF_DMA_IMCR_SRC31_PSC3TX(0xC000) + +#endif /* __MCF548X_DMA_H__ */ diff --git a/arch/m68k/include/asm/m54xxdma_api.h b/arch/m68k/include/asm/m54xxdma_api.h new file mode 100644 index 000..22bfb23 --- /dev/null +++ b/arch/m68k/include/asm/m54xxdma_api.h @@ -0,0 +1,62 @@ +/ + * Multichannel DMA definitions* + / +#include linux/MCD_dma.h + +struct scatterlist; + +#define MAX_DMA_CHANNELS NCHANNELS +/* + * identifiers for each initiator/requestor + */ +#define DMA_ALWAYS (0) +#define DMA_DSPI_RX (1) +#define DMA_DSPI_TX (2) +#define DMA_DREQ0 (3) +#define DMA_PSC0_RX (4) +#define DMA_PSC0_TX (5) +#define DMA_USBEP0 (6) +#define DMA_USBEP1 (7) +#define DMA_USBEP2 (8) +#define DMA_USBEP3 (9) +#define DMA_PCI_TX (10) +#define DMA_PCI_RX (11) +#define DMA_PSC1_RX (12) +#define DMA_PSC1_TX
[uClinux-dev] [PATCH 3/3] m68knommu: Add ethernet driver for MCF547x/MCF548x
This is a fully functionnal ethernet driver for the MCF547x and MCF548x
processors, tested on the M5484EVB board and on a custom board inpired
by the M5484EVB board. It implements a FEC+DMA driver and a mdio driver.
Original work was made by freescale for 2.6.25, but never submitted for
mainline, but cache support, mdio driver, phylib support, general
cleanup and 2.6.30-3.6 ports are mine.
Signed-off-by: Philippe De Muyter p...@macqel.be
---
arch/m68k/include/asm/m54xxsim.h |2 +
arch/m68k/kernel/setup_no.c|5 +
drivers/net/ethernet/freescale/Kconfig | 26 +-
drivers/net/ethernet/freescale/Makefile|1 +
drivers/net/ethernet/freescale/fec_m54xx.c | 1506
drivers/net/ethernet/freescale/fec_m54xx.h | 144 +++
6 files changed, 1683 insertions(+), 1 deletions(-)
create mode 100644 drivers/net/ethernet/freescale/fec_m54xx.c
create mode 100644 drivers/net/ethernet/freescale/fec_m54xx.h
diff --git a/arch/m68k/include/asm/m54xxsim.h b/arch/m68k/include/asm/m54xxsim.h
index f5531d5..b4c81bf 100644
--- a/arch/m68k/include/asm/m54xxsim.h
+++ b/arch/m68k/include/asm/m54xxsim.h
@@ -46,6 +46,8 @@
#define MCF_IRQ_UART2 (MCFINT_VECBASE + 33)
#define MCF_IRQ_UART3 (MCFINT_VECBASE + 32)
#define MCF_IRQ_DMA(MCFINT_VECBASE + 48) /* DMA */
+#define MCF_IRQ_FEC0 (MCFINT_VECBASE + 39) /* FEC0 */
+#define MCF_IRQ_FEC1 (MCFINT_VECBASE + 38) /* FEC1 */
/*
* Generic GPIO support
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index 71fb299..10131b4 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -261,6 +261,11 @@ void __init setup_arch(char **cmdline_p)
paging_init();
}
+const char *machdep_get_mac_address(int i)
+{
+ return 0;
+}
+
/*
* Get CPU information for use by the procfs.
*/
diff --git a/drivers/net/ethernet/freescale/Kconfig
b/drivers/net/ethernet/freescale/Kconfig
index 3574e14..64d8fc6 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -7,7 +7,7 @@ config NET_VENDOR_FREESCALE
default y
depends on FSL_SOC || QUICC_ENGINE || CPM1 || CPM2 || PPC_MPC512x || \
M523x || M527x || M5272 || M528x || M520x || M532x || \
- ARCH_MXC || ARCH_MXS || (PPC_MPC52xx PPC_BESTCOMM)
+ M54xx || ARCH_MXC || ARCH_MXS || (PPC_MPC52xx
PPC_BESTCOMM)
---help---
If you have a network (Ethernet) card belonging to this class, say Y
and read the Ethernet-HOWTO, available from
@@ -30,6 +30,30 @@ config FEC
Say Y here if you want to use the built-in 10/100 Fast ethernet
controller on some Motorola ColdFire and Freescale i.MX processors.
+config FEC_54xx
+ tristate MCF547x/MCF548x Fast Ethernet Controller support
+ depends on M54xx
+ default y
+ select CRC32
+ select PHYLIB
+ select M54xx_DMA
+ help
+ The MCF547x and MCF548x have a built-in Fast Ethernet Controller.
+ This is not the same FEC controller as on other ColdFire as here
+ the DMA controller is not reserved to the FEC driver, but made
+ available for general DMA work.
+ Saying Y here will include support for this device in the kernel.
+
+config FEC2
+ bool Second FEC ethernet controller (on some ColdFire CPUs)
+ depends on FEC || FEC_54xx
+ default y
+ help
+ Say Y here if you want to use the second built-in 10/100 Fast
+ ethernet controller on some Motorola ColdFire processors. On M54xx,
+ If your second ethernet port is not connected, saying N here will
+ free 2 DMA channels and allow you to use FEC io ports as GPIO's.
+
config FEC_MPC52xx
tristate FEC MPC52xx driver
depends on PPC_MPC52xx PPC_BESTCOMM
diff --git a/drivers/net/ethernet/freescale/Makefile
b/drivers/net/ethernet/freescale/Makefile
index 1752488..05a5022 100644
--- a/drivers/net/ethernet/freescale/Makefile
+++ b/drivers/net/ethernet/freescale/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_FEC) += fec.o
+obj-$(CONFIG_FEC_54xx) += fec_m54xx.o
obj-$(CONFIG_FEC_MPC52xx) += fec_mpc52xx.o
ifeq ($(CONFIG_FEC_MPC52xx_MDIO),y)
obj-$(CONFIG_FEC_MPC52xx) += fec_mpc52xx_phy.o
diff --git a/drivers/net/ethernet/freescale/fec_m54xx.c
b/drivers/net/ethernet/freescale/fec_m54xx.c
new file mode 100644
index 000..b28c89a
--- /dev/null
+++ b/drivers/net/ethernet/freescale/fec_m54xx.c
@@ -0,0 +1,1506 @@
+/*
+ * Performance and stability improvements: (C) Copyright 2008,
+ * Daniel Krueger, SYSTEC electronic GmbH
+ *
+ * Code crunched to get it to work on 2.6.24 -- FEC cleanup coming
+ * soon -- Kurt Mahan
+ *
+ * 2.6.30 and above port, cleanup, cache support, netdev_ops, mdio,
+ * phy ethtool support,
+ * (C) Copyright 2010-2012 Philippe De Muyter p...@macqel.be Macq SA
Re: [uClinux-dev] [PATCH] m68knommu: allow ColdFire CPUs to use unaligned accesses
Hi Greg, On Tue, Jun 12, 2012 at 12:25:44PM +1000, Greg Ungerer wrote: Hi Philippe, On 08/06/12 23:35, Philippe De Muyter wrote: ... I mentionned that only to make you able to soften the commit comment :) Ok, makes sense. I should probably have mentioned that this means the ColdFire processors currently support by Linux :-) Something like: All of the current Linux supported ColdFire CPUs handle unaligned memory accesses. So remove the CONFIG_CPU_HAS_NO_UNALIGNED option selection for ColdFire. If we ever support a specific ColdFire CPU that does not support unaligned accesses then we can insert the CONFIG_CPU_HAS_NO_UNALIGNED for that specific CPU type. That's perfect. The line about dumb copying of the m68knommu settings was too much self-flagellation for you to my eyes :) Philippe ___ 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] m68knommu: allow ColdFire CPUs to use unaligned accesses
On Fri, Jun 08, 2012 at 03:43:00PM +1000, g...@snapgear.com wrote: From: Greg Ungerer g...@uclinux.org All current ColdFire CPUs are able to support unaligned memory accesses. So remove the CONFIG_CPU_HAS_NO_UNALIGNED option selection for ColdFire. It seems that the current restriction was inherrited from the early non-MMU support for the basic 68000 proecssors - which do not support unaligned accesses. It seems that the first ColdFires needed the restriction : I read in the MCF5200 ColdFire Family Programmer’s Reference Manual : The ColdFire processor default configuration supports word- and longword-sized operand references on 0-modulo-2 and 0-modulo-4 addresses, respectively. All other references are defined as misaligned accesses. Any attempt to access a misaligned operand generates an address-error exception, unless the optional hardware module for handling misalignment is present. This misalignment module converts any misaligned operand references into a series of aligned bus cycles to access the data. The existence of the misalignment module is implementation-dependent and is documented in the appropriate ColdFire user’s manual. Philippe ___ 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] m68knommu: allow ColdFire CPUs to use unaligned accesses
Hi Greg, On Fri, Jun 08, 2012 at 10:19:43PM +1000, Greg Ungerer wrote: Hi Philippe, On 06/08/2012 08:39 PM, Philippe De Muyter wrote: On Fri, Jun 08, 2012 at 03:43:00PM +1000, g...@snapgear.com wrote: From: Greg Ungererg...@uclinux.org All current ColdFire CPUs are able to support unaligned memory accesses. So remove the CONFIG_CPU_HAS_NO_UNALIGNED option selection for ColdFire. It seems that the current restriction was inherrited from the early non-MMU support for the basic 68000 proecssors - which do not support unaligned accesses. It seems that the first ColdFires needed the restriction : I read in the MCF5200 ColdFire Family ProgrammerÆs Reference Manual : The ColdFire processor default configuration supports word- and longword-sized operand references on 0-modulo-2 and 0-modulo-4 addresses, respectively. All other references are defined as misaligned accesses. Any attempt to access a misaligned operand generates an address-error exception, unless the optional hardware module for handling misalignment is present. This misalignment module converts any misaligned operand references into a series of aligned bus cycles to access the data. The existence of the misalignment module is implementation-dependent and is documented in the appropriate ColdFire userÆs manual. I mentionned that only to make you able to soften the commit comment :) I wish Freescale really did make that clear within the doco for each part! The oldest (and I assume simplest) part we support is the 5206, and it does explicitly state in the MCF5206UM that it supports unaligned accesses (Section 6.6). It is not as clear as this in some of the other CPU/SoC User Manuals that I looked through. I am pretty confident that all the parts we currently support in Linux do unaligned accesses. I agree. And if some parts did not implement it, we'd see it quickly. Regards Philippe ___ 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] [RFC/PATCH] m68knommu: add support for Coldfire m5441x
On Tue, May 22, 2012 at 07:03:59PM -0700, Steven King wrote: It doesnt include support for the 2 fec controllers, the ones on the 5441x are just slightly different in some non obvious way so they dont quite work yet. Are they identical to the fec's of the 548x ? I have drivers for them (actually they came from the freescale port for 2.6.25, but I have cleaned them up, made them use phylib, and made them current for 2.6.37). I don't know if they still would be compatible with 3.5. Philippe ___ 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] [RFC/PATCH] m68knommu: add support for Coldfire?m5441x
On Wed, May 23, 2012 at 01:32:35AM -0700, Steven King wrote: On Wednesday 23 May 2012 12:38:46 am Philippe De Muyter wrote: On Tue, May 22, 2012 at 07:03:59PM -0700, Steven King wrote: It doesnt include support for the 2 fec controllers, the ones on the 5441x are just slightly different in some non obvious way so they dont quite work yet. Are they identical to the fec's of the 548x ? I have drivers for them (actually they came from the freescale port for 2.6.25, but I have cleaned them up, made them use phylib, and made them current for 2.6.37). I don't know if they still would be compatible with 3.5. It looks like the fecs on the 54xx are different, with a subset of the regular fec registers while the 544xx have a superset; I think from googling the error message I'm seeing it maybe a issue with the lack of kernel support for the phy. I guess it time I learn about writing phy drivers... Ok, the 54xx fec drivers would not help then. Best regards Philippe ___ 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 01/22] m68knommu: introduce macros to simplify ColdFire GPIO table initialization
Hi Greg, On Thu, Apr 26, 2012 at 10:25:41AM +1000, g...@snapgear.com wrote: From: Greg Ungerer g...@uclinux.org We have very large tables in the ColdFire CPU GPIO setup code that essentially boil down to 2 distinct types of GPIO pin initiaization. Using 2 macros we can reduce these large tables to at most a dozen lines of setup code, and in quite a few cases a single table entry. Introduce these 2 macros into the existing mcfgpio.h header. ... +/* + * Define macros to ease the pain of setting up the gpio tables. + */ +#define MCFGPS(mlabel, mbase, mngpio, mpddr, mpodr, mppdr) \ ... +#define MCFGPF(mlabel, mbase, mngpio) \ ... Maybe a small comment to explain when to use MCFGPS and when to use MCFGPF ? Best regards Philippe ___ 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 v2 01/22] m68knommu: introduce macros to simplify ColdFire GPIO table initialization
Hello Greg, On Thu, Apr 26, 2012 at 11:14:51PM +1000, g...@snapgear.com wrote: From: Greg Ungerer g...@uclinux.org ... +/* + * Define macros to ease the pain of setting up the GPIO tables. There + * is two cases we need to deal with here, they cover all currently + * available ColdFire GPIO hardware. There is of course minor differences + * in the layout and number of bits in each ColdFire part, but the macros + * take all that in. + * + * Firstly is the conventional GPIO registers where we toggle individual + * bits in a register, preserving the other bits in the register. For + * lack of a better term I have called this the slow method. + */ +#define MCFGPS(mlabel, mbase, mngpio, mpddr, mpodr, mppdr) \ ... +/* + * Secondly is the faster case, where we have set and clear registers + * that allow us to set or clear a bit with a single write, not having + * to worry about preserving other bits. + */ +#define MCFGPF(mlabel, mbase, mngpio) \ That's perfectly clear. Thanks Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles ___ 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] m68k: merge mmu and non-mmu bitops.h
On Wed, May 18, 2011 at 03:32:27PM +1000, g...@snapgear.com wrote: From: Greg Ungerer g...@uclinux.org The following patch merges the mmu and non-mmu versions of the m68k bitops.h files. Now there is a good deal of difference between the two files, but none of it is actually an mmu specific difference. It is all about the specific m68k/coldfire varient we are targeting. So it makes an awful lot of sense to merge these into a single bitops.h. Thanks for taking care of that. Fork was easy (but ugly), but merge is a tedious job. Philippe ___ 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: [PATCH 5/5] m68k: merge non-mmu and mmu versions of m68k_ksyms.c
On Thu, Apr 21, 2011 at 10:16:01AM +0200, Geert Uytterhoeven wrote: On Thu, Apr 21, 2011 at 02:48, g...@snapgear.com wrote: +#ifndef CONFIG_MMU While we're at it, that should also be a test for not '020-'060/CPU32? You beat me on this :) You're abolutely right, we may not test on CONFIG_MMU for mmu-capable coldfires, but which do lack 32x32-64 mulu and friends. +/* + * Simpler 68k and ColdFire parts also need a few other gcc functions. + */ +extern long long __divsi3(long long, long long); +extern long long __modsi3(long long, long long); +extern long long __mulsi3(long long, long long); +extern long long __udivsi3(long long, long long); +extern long long __umodsi3(long long, long long); + +EXPORT_SYMBOL(__divsi3); +EXPORT_SYMBOL(__modsi3); +EXPORT_SYMBOL(__mulsi3); +EXPORT_SYMBOL(__udivsi3); +EXPORT_SYMBOL(__umodsi3); #endif Philippe ___ 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 v2 1/6] m68k: merge mmu and non-mmu versions of muldi3
On Wed, Apr 20, 2011 at 10:06:09AM +0200, Sam Ravnborg wrote: Hi Greg. + +#if defined(__mc68020__) || defined(__mc68030__) || \ +defined(__mc68040__) || defined(__mc68060__) Why use these to decide if this is MMU or not? This code is not exposed to user-space so we can rely on CONFIG_* symbols. IMO the CONIFG_* symbols is easier to read/maintain. This does not decide about MMU or not MMU, but about the availability of some assembler instructions in the processor. Philippe ___ 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 v2 1/6] m68k: merge mmu and non-mmu versions of muldi3
On Wed, Apr 20, 2011 at 10:55:15AM +0200, Geert Uytterhoeven wrote: On Wed, Apr 20, 2011 at 10:06, Sam Ravnborg s...@ravnborg.org wrote: Hi Greg. + +#if defined(__mc68020__) || defined(__mc68030__) || \ + defined(__mc68040__) || defined(__mc68060__) Why use these to decide if this is MMU or not? This code is not exposed to user-space so we can rely on CONFIG_* symbols. IMO the CONIFG_* symbols is easier to read/maintain. Because technically it doesn't depend on having a MMU or not, but on having the full 32-bit multiplication instruction or not. Does Coldfire-with-MMU (for which we haven't integrated the support yet) have that instruction? Actually, MCF547x MCF548x (CFv4e family) are integrated but without their limited MMU functionality. freescale had even written an mmu port for 2.6.25 but has not pushed it upstream. This port can be found on their site or in the openwrt repository. MCF547x MCF548x do not have that instruction. Philippe ___ 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 v2 1/6] m68k: merge mmu and non-mmu versions of muldi3
On Wed, Apr 20, 2011 at 07:31:33PM +1000, Greg Ungerer wrote: On 20/04/11 19:12, Philippe De Muyter wrote: On Wed, Apr 20, 2011 at 10:55:15AM +0200, Geert Uytterhoeven wrote: On Wed, Apr 20, 2011 at 10:06, Sam Ravnborgs...@ravnborg.org wrote: Hi Greg. + +#if defined(__mc68020__) || defined(__mc68030__) || \ + á ádefined(__mc68040__) || defined(__mc68060__) (*) Why use these to decide if this is MMU or not? This code is not exposed to user-space so we can rely on CONFIG_* symbols. IMO the CONIFG_* symbols is easier to read/maintain. Because technically it doesn't depend on having a MMU or not, but on having the full 32-bit multiplication instruction or not. Does Coldfire-with-MMU (for which we haven't integrated the support yet) have that instruction? Actually, MCF547x MCF548x (CFv4e family) are integrated but without (*) their limited MMU functionality. freescale had even written an mmu port for 2.6.25 but has not pushed it upstream. This port can be found on their site or in the openwrt repository. Part of my plan with the merge of m68k and m68knommu is to make it easy to support the v4e parts with MMU enabled. And certainly as I work through cleaning the individual files up I am doing it with this in mind. Of course most of the code to support the v4e is the same no matter if you have the MMU enabled or not. I have Freescales 2.6.25 kernel, but it is really only a reference point for this work. MCF547x MCF548x do not have that instruction. (*) Thats right. I believe the processors listed in the patch are the only ones that currently support the 64bit mul. The 68340 has it also. (And I have an old linux port for this processor) I surmise the 68360 has it also. Philippe (*) Greg, there must be something with your mail installation : it garbles the messages. (or is it mine, but I noticed that only with replies from you ?) ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH v2 1/6] m68k: merge mmu and non-mmu versions of muldi3
Hi Greg, On Wed, Apr 20, 2011 at 09:01:39PM +1000, Greg Ungerer wrote: Hi Philippe, On 20/04/11 20:38, Philippe De Muyter wrote: Hi Greg, On Wed, Apr 20, 2011 at 08:18:09PM +1000, Greg Ungerer wrote: The 68340 has it also. (And I have an old linux port for this processor) That is just a SoC that contains a 68020 though, so __mc68020__ would be defined for that. No, this is a cpu32 core, which is a subset of a 68020, so gcc does not define __mc68020__, or at least should not (there are old bug reports about that). Modern gcc still does, from a gcc-4.5.1: # m68k-linux-gcc -mcpu32 -dM -E - /dev/null | grep mc68020 #define __mc68020__ 1 #define __mc68020 1 #define mc68020 1 I surmise the 68360 has it also. I believe that is a SoC with a 68040 cpu core, so I would expect that __mc68040__ would be correct for that. This is a cpu32+ core. Same here. Not that it is that important now :) Does cpu32 always support the 64bit mul? Yes AFAIK. If so we can just add __mcpu32__ to the conditional check list. That would be safer. Thanks Philippe ___ 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] m68k: Merge mmu and non-mmu versions of sys_call_table
On Thu, Apr 07, 2011 at 10:29:54AM +0200, Andreas Schwab wrote: Geert Uytterhoeven ge...@linux-m68k.org writes: Isn't there a reason it was read-write on m68k, like the table may be changed at runtime (to install rootkits :-)? Have to check what the other arches do... Initially the syscall_table in Linux has always been writable, bb152f53 (x86/x86_64: mark rodata section read-only: make some datastructures const) made it read-only on x86. Apparently nobody bothered to do the equivalent change on m68k (I don't think anything makes the kernel text segment write protected anyway). Except, of course, ld config files who put text and rodata in ROM/FLASH for XIP on embedded systems. Philippe ___ 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] m68k: Merge mmu and non-mmu versions of sys_call_table
On Wed, Apr 06, 2011 at 10:33:07PM +0200, Geert Uytterhoeven wrote: Impact for m68knommu: - The table is now stored in .data instead of .text, Do you mean .rodata ? - Removed unused padding at the end of the table. Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org --- Not tested on m68knommu Questions: - Why was it .text? Probably because it is constanti (read-only). Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 1/2] m68knommu: fix m548x_wdt.c compilation after headers renaming
m548x headers were renamed to m54xx, but m548x_wdt.c still uses the
old names. Fix that.
Signed-off-by: Philippe De Muyter p...@macqel.be
---
drivers/watchdog/m548x_wdt.c | 50 +-
1 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/watchdog/m548x_wdt.c b/drivers/watchdog/m548x_wdt.c
index cabbcfe..4d43286 100644
--- a/drivers/watchdog/m548x_wdt.c
+++ b/drivers/watchdog/m548x_wdt.c
@@ -1,7 +1,7 @@
/*
- * drivers/watchdog/m548x_wdt.c
+ * drivers/watchdog/m54xx_wdt.c
*
- * Watchdog driver for ColdFire MCF548x processors
+ * Watchdog driver for ColdFire MCF547x MCF548x processors
* Copyright 2010 (c) Philippe De Muyter p...@macqel.be
*
* Adapted from the IXP4xx watchdog driver, which carries these notices:
@@ -29,8 +29,8 @@
#include linux/uaccess.h
#include asm/coldfire.h
-#include asm/m548xsim.h
-#include asm/m548xgpt.h
+#include asm/m54xxsim.h
+#include asm/m54xxgpt.h
static int nowayout = WATCHDOG_NOWAYOUT;
static unsigned int heartbeat = 30;/* (secs) Default is 0.5 minute */
@@ -76,7 +76,7 @@ static void wdt_keepalive(void)
__raw_writel(gms0, MCF_MBAR + MCF_GPT_GMS0);
}
-static int m548x_wdt_open(struct inode *inode, struct file *file)
+static int m54xx_wdt_open(struct inode *inode, struct file *file)
{
if (test_and_set_bit(WDT_IN_USE, wdt_status))
return -EBUSY;
@@ -86,7 +86,7 @@ static int m548x_wdt_open(struct inode *inode, struct file
*file)
return nonseekable_open(inode, file);
}
-static ssize_t m548x_wdt_write(struct file *file, const char *data,
+static ssize_t m54xx_wdt_write(struct file *file, const char *data,
size_t len, loff_t *ppos)
{
if (len) {
@@ -112,10 +112,10 @@ static ssize_t m548x_wdt_write(struct file *file, const
char *data,
static const struct watchdog_info ident = {
.options= WDIOF_MAGICCLOSE | WDIOF_SETTIMEOUT |
WDIOF_KEEPALIVEPING,
- .identity = Coldfire M548x Watchdog,
+ .identity = Coldfire M54xx Watchdog,
};
-static long m548x_wdt_ioctl(struct file *file, unsigned int cmd,
+static long m54xx_wdt_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
int ret = -ENOTTY;
@@ -161,7 +161,7 @@ static long m548x_wdt_ioctl(struct file *file, unsigned int
cmd,
return ret;
}
-static int m548x_wdt_release(struct inode *inode, struct file *file)
+static int m54xx_wdt_release(struct inode *inode, struct file *file)
{
if (test_bit(WDT_OK_TO_CLOSE, wdt_status))
wdt_disable();
@@ -177,45 +177,45 @@ static int m548x_wdt_release(struct inode *inode, struct
file *file)
}
-static const struct file_operations m548x_wdt_fops = {
+static const struct file_operations m54xx_wdt_fops = {
.owner = THIS_MODULE,
.llseek = no_llseek,
- .write = m548x_wdt_write,
- .unlocked_ioctl = m548x_wdt_ioctl,
- .open = m548x_wdt_open,
- .release= m548x_wdt_release,
+ .write = m54xx_wdt_write,
+ .unlocked_ioctl = m54xx_wdt_ioctl,
+ .open = m54xx_wdt_open,
+ .release= m54xx_wdt_release,
};
-static struct miscdevice m548x_wdt_miscdev = {
+static struct miscdevice m54xx_wdt_miscdev = {
.minor = WATCHDOG_MINOR,
.name = watchdog,
- .fops = m548x_wdt_fops,
+ .fops = m54xx_wdt_fops,
};
-static int __init m548x_wdt_init(void)
+static int __init m54xx_wdt_init(void)
{
if (!request_mem_region(MCF_MBAR + MCF_GPT_GCIR0, 4,
- Coldfire M548x Watchdog)) {
+ Coldfire M54xx Watchdog)) {
printk(KERN_WARNING
- Coldfire M548x Watchdog : I/O region busy\n);
+ Coldfire M54xx Watchdog : I/O region busy\n);
return -EBUSY;
}
printk(KERN_INFO ColdFire watchdog driver is loaded.\n);
- return misc_register(m548x_wdt_miscdev);
+ return misc_register(m54xx_wdt_miscdev);
}
-static void __exit m548x_wdt_exit(void)
+static void __exit m54xx_wdt_exit(void)
{
- misc_deregister(m548x_wdt_miscdev);
+ misc_deregister(m54xx_wdt_miscdev);
release_mem_region(MCF_MBAR + MCF_GPT_GCIR0, 4);
}
-module_init(m548x_wdt_init);
-module_exit(m548x_wdt_exit);
+module_init(m54xx_wdt_init);
+module_exit(m54xx_wdt_exit);
MODULE_AUTHOR(Philippe De Muyter p...@macqel.be);
-MODULE_DESCRIPTION(Coldfire M548x Watchdog);
+MODULE_DESCRIPTION(Coldfire M54xx Watchdog);
module_param(heartbeat, int, 0);
MODULE_PARM_DESC(heartbeat, Watchdog heartbeat in seconds (default 30s));
--
1.7.1
___
uClinux-dev
[uClinux-dev] [PATCH 2/2] m68knommu: Rename m548x_wdt.c to m54xx_wdt.c
All m548x files were renamed to m54xx, except m548x_wdt.c. Fix that.
Signed-off-by: Philippe De Muyter p...@macqel.be
---
drivers/watchdog/Kconfig |6 +-
drivers/watchdog/Makefile|2 +-
drivers/watchdog/m548x_wdt.c | 227 --
drivers/watchdog/m54xx_wdt.c | 227 ++
4 files changed, 231 insertions(+), 231 deletions(-)
delete mode 100644 drivers/watchdog/m548x_wdt.c
create mode 100644 drivers/watchdog/m54xx_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 2e2400e..31649b7 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -862,12 +862,12 @@ config SBC_EPX_C3_WATCHDOG
# M68K Architecture
-config M548x_WATCHDOG
- tristate MCF548x watchdog support
+config M54xx_WATCHDOG
+ tristate MCF54xx watchdog support
depends on M548x
help
To compile this driver as a module, choose M here: the
- module will be called m548x_wdt.
+ module will be called m54xx_wdt.
# MIPS Architecture
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index dd77665..20e44c4 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -106,7 +106,7 @@ obj-$(CONFIG_SBC_EPX_C3_WATCHDOG) += sbc_epx_c3.o
# M32R Architecture
# M68K Architecture
-obj-$(CONFIG_M548x_WATCHDOG) += m548x_wdt.o
+obj-$(CONFIG_M54xx_WATCHDOG) += m54xx_wdt.o
# MIPS Architecture
obj-$(CONFIG_ATH79_WDT) += ath79_wdt.o
diff --git a/drivers/watchdog/m548x_wdt.c b/drivers/watchdog/m548x_wdt.c
deleted file mode 100644
index 4d43286..000
--- a/drivers/watchdog/m548x_wdt.c
+++ /dev/null
@@ -1,227 +0,0 @@
-/*
- * drivers/watchdog/m54xx_wdt.c
- *
- * Watchdog driver for ColdFire MCF547x MCF548x processors
- * Copyright 2010 (c) Philippe De Muyter p...@macqel.be
- *
- * Adapted from the IXP4xx watchdog driver, which carries these notices:
- *
- * Author: Deepak Saxena dsax...@plexity.net
- *
- * Copyright 2004 (c) MontaVista, Software, Inc.
- * Based on sa1100 driver, Copyright (C) 2000 Oleg Drokin gr...@crimea.edu
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed as is without any
- * warranty of any kind, whether express or implied.
- */
-
-#include linux/module.h
-#include linux/moduleparam.h
-#include linux/types.h
-#include linux/kernel.h
-#include linux/fs.h
-#include linux/miscdevice.h
-#include linux/watchdog.h
-#include linux/init.h
-#include linux/bitops.h
-#include linux/ioport.h
-#include linux/uaccess.h
-
-#include asm/coldfire.h
-#include asm/m54xxsim.h
-#include asm/m54xxgpt.h
-
-static int nowayout = WATCHDOG_NOWAYOUT;
-static unsigned int heartbeat = 30;/* (secs) Default is 0.5 minute */
-static unsigned long wdt_status;
-
-#defineWDT_IN_USE 0
-#defineWDT_OK_TO_CLOSE 1
-
-static void wdt_enable(void)
-{
- unsigned int gms0;
-
- /* preserve GPIO usage, if any */
- gms0 = __raw_readl(MCF_MBAR + MCF_GPT_GMS0);
- if (gms0 MCF_GPT_GMS_TMS_GPIO)
- gms0 = (MCF_GPT_GMS_TMS_GPIO | MCF_GPT_GMS_GPIO_MASK
- | MCF_GPT_GMS_OD);
- else
- gms0 = MCF_GPT_GMS_TMS_GPIO | MCF_GPT_GMS_OD;
- __raw_writel(gms0, MCF_MBAR + MCF_GPT_GMS0);
- __raw_writel(MCF_GPT_GCIR_PRE(heartbeat*(MCF_BUSCLK/0x)) |
- MCF_GPT_GCIR_CNT(0x), MCF_MBAR + MCF_GPT_GCIR0);
- gms0 |= MCF_GPT_GMS_OCPW(0xA5) | MCF_GPT_GMS_WDEN | MCF_GPT_GMS_CE;
- __raw_writel(gms0, MCF_MBAR + MCF_GPT_GMS0);
-}
-
-static void wdt_disable(void)
-{
- unsigned int gms0;
-
- /* disable watchdog */
- gms0 = __raw_readl(MCF_MBAR + MCF_GPT_GMS0);
- gms0 = ~(MCF_GPT_GMS_WDEN | MCF_GPT_GMS_CE);
- __raw_writel(gms0, MCF_MBAR + MCF_GPT_GMS0);
-}
-
-static void wdt_keepalive(void)
-{
- unsigned int gms0;
-
- gms0 = __raw_readl(MCF_MBAR + MCF_GPT_GMS0);
- gms0 |= MCF_GPT_GMS_OCPW(0xA5);
- __raw_writel(gms0, MCF_MBAR + MCF_GPT_GMS0);
-}
-
-static int m54xx_wdt_open(struct inode *inode, struct file *file)
-{
- if (test_and_set_bit(WDT_IN_USE, wdt_status))
- return -EBUSY;
-
- clear_bit(WDT_OK_TO_CLOSE, wdt_status);
- wdt_enable();
- return nonseekable_open(inode, file);
-}
-
-static ssize_t m54xx_wdt_write(struct file *file, const char *data,
- size_t len, loff_t *ppos)
-{
- if (len) {
- if (!nowayout) {
- size_t i;
-
- clear_bit(WDT_OK_TO_CLOSE, wdt_status);
-
- for (i = 0; i != len; i++) {
- char c;
-
- if (get_user(c, data + i))
- return -EFAULT;
- if (c == 'V
Re: [uClinux-dev] NFS on m5282lite
Hi Eduard, On Fri, Nov 26, 2010 at 10:08:16AM -0800, eduard gavin wrote: FYI I solve this problem, during uclinux configuration, the system only configure 8Mb of RAM for this board, in this case m5282lite have 16Mb, change in Customize Kernel Setting -- Processor type and features --(0x00ff) Size of RAM is needed. If that works for your board, choosing 0 there will give you the ram size known by the boot monitor. Philippe ___ 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 4/8] m68knommu: clean up ColdFire CACHE control code
Hi Greg, On Thu, Nov 11, 2010 at 11:48:42AM +1000, Greg Ungerer wrote: ... +#ifdef CONFIG_COLDFIRE_SW_A7 +#define CACHE_INIT (CACR_CINV + CACR_DISD) +#define CACHE_MODE (CACR_CENB + CACR_DISD + CACR_DCM) +#else +#define CACHE_INIT (CACR_CINV + CACR_DISD + CACR_EUSP) +#define CACHE_MODE (CACR_CENB + CACR_DISD + CACR_DCM + CACR_EUSP) +#endif Wouldn't that be more maintainable as : #ifdef CONFIG_COLDFIRE_SW_A7 #define USERA7_MODE 0 #else #define USERA7_MODE CACR_EUSP #endif #define CACHE_INIT (CACR_CINV + CACR_DISD + USERA7_MODE) #define CACHE_MODE (CACR_CENB + CACR_DISD + CACR_DCM + USERA7_MODE) Philippe ___ 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] Re: [PATCH] m68knommu: make Coldfire 548x support more generic
Hello Greg, On Wed, Nov 03, 2010 at 11:26:37AM +1000, Greg Ungerer wrote: Hi Philippe, I propose that we make the ColdFire 548x support a little more generic, so that it covers the 547x family as well. The two parts are extremely similar. Do you have a handy document describing the differences ? I have both reference manuals, but didn't want to check any page for eventual differences. If that could include the m5407, that would be perfect. Fundamentally I want to change any 548x naming to 54xx. I know the obvious exception of the 5407 here, and this is another example of unfortunate (or at least inconsistent) part naming on Freescale's part. There is plenty of precendence here within our current naming: 527x -- applies to 5270, 5271, 5274, 5275 BUT NOT 5272 520x -- applies to 5207 and 5208 BUT NOT 5206 so we will have as well: 52xx -- applies to 527? and 528? BUT NOT 5407 54xx -- applies to 547? and 548? BUT NOT 5407 Strictly speaking I know this renaming is not a must. But the motivation is to keep the naming as consistent and relevant as possible. Below is an example patch that will do this change. On top of this adding 547x ColdFire support is a trivial config option addition. Do you have any objections? I agree fully. For some files I already started from files from Freescale called m5485* that I renamed to m548x*. And also there is already a m54xxacr.h which applies also to m5407, but nothing is perfect. What about my pending watchdog driver patch ? --- m68knommu: make Coldfire 548x support more generic The ColdFire 547x family of processors is very similar to the ColdFire 548x series. Almost all of the support for them is the same. Make the code supporting the 548x more gneric, so it will be capable of supporting both families. For the most part this is a renaming excerise to make the support code more obviously apply to both families. Signed-off-by: Greg Ungerer g...@uclinux.org --- [...] similarity index 95% [...] similarity index 92% [...] similarity index 74% [...] Could you make that as two or three patches, first changing the contents of the files, and then renaming them, or conversely, to only produce renaming with 100% similarity ? Have a good day Philippe -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ 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] Re: [PATCH] m68knommu: make Coldfire 548x support more generic
Hi Greg, On Wed, Nov 03, 2010 at 10:33:06PM +1000, Greg Ungerer wrote: Hi Philippe, On 03/11/10 19:36, Philippe De Muyter wrote: On Wed, Nov 03, 2010 at 11:26:37AM +1000, Greg Ungerer wrote: I propose that we make the ColdFire 548x support a little more generic, so that it covers the 547x family as well. The two parts are extremely similar. Do you have a handy document describing the differences ? I have both reference manuals, but didn't want to check any page for eventual differences. No, unfortunately I don't have any single document that just describes the difference. The Freescale web site says the two families are pin compatible - and from the doco I can only see a couple of differences. (The main one is that the 548x family all have CAN controllers, the 547x don't). If that could include the m5407, that would be perfect. The 5407 is very different - completely different peripheral set. Different interrupt controller, timers, etc, to the 54xx series. (It was designed to be a faster 5307 - same peripherals, v4 core instead of v3). I don't think we will get too much common code between the 5407 and 54xx. The cache is the same, except for the size, and the m5407 has no ethernet. That's all what I know about the m54xx/m5407 similarities/differences. Fundamentally I want to change any 548x naming to 54xx. I know the obvious exception of the 5407 here, and this is another example of unfortunate (or at least inconsistent) part naming on Freescale's part. There is plenty of precendence here within our current naming: 527x -- applies to 5270, 5271, 5274, 5275 BUT NOT 5272 520x -- applies to 5207 and 5208 BUT NOT 5206 so we will have as well: 52xx -- applies to 527? and 528? BUT NOT 5407 54xx -- applies to 547? and 548? BUT NOT 5407 Oops, :-) Strictly speaking I know this renaming is not a must. But the motivation is to keep the naming as consistent and relevant as possible. Below is an example patch that will do this change. On top of this adding 547x ColdFire support is a trivial config option addition. Do you have any objections? I agree fully. For some files I already started from files from Freescale called m5485* that I renamed to m548x*. And also there is already a m54xxacr.h which applies also to m5407, but nothing is perfect. What about my pending watchdog driver patch? Oh, yes, that is still in my inbox :-) I have no problems with it. But it should probably be reviewed by the watchdog maintainer (I don't mind it going through the m68knommu git tree to Linus if they are ok with that). From the MAINTAINERS file that looks to be: WATCHDOG DEVICE DRIVERS M: Wim Van Sebroeck w...@iguana.be L: linux-watch...@vger.kernel.org W: http://www.linux-watchdog.org/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog.git In light of this 548x -- 54xx change you may want to change the naming to 54xx as well. As it is now, I can only send it unchanged to the watchdog mailing list. Otherwise it won't apply to the tree those people have now. --- m68knommu: make Coldfire 548x support more generic The ColdFire 547x family of processors is very similar to the ColdFire 548x series. Almost all of the support for them is the same. Make the code supporting the 548x more gneric, so it will be capable of supporting both families. For the most part this is a renaming excerise to make the support code more obviously apply to both families. Signed-off-by: Greg Ungererg...@uclinux.org --- [...] similarity index 95% [...] similarity index 92% [...] similarity index 74% [...] Could you make that as two or three patches, first changing the contents of the files, and then renaming them, or conversely, to only produce renaming with 100% similarity ? I could, but you then end with a file named m54xxsim.h which has a comment at the top that reads: * m548xsim.h -- ColdFire 547x/548x System Integration Unit support. Which seems very inconsistent to me. I think it is better to move it and make consistent name changes. I have already found those sort of inconsistencies, and that's not a real problem as long as it does not hurt compilation. Nobody will really read the title in the source files. And here it would only last for one commit. Being able to find renames by searching for only 100% similarity seems to me more usefull, because searching for 100% similarity is a very faster operation than for not 100%. Best regards Philippe -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ 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] [PATCH] m68knommu, watchdog: Add MCF548x watchdog driver.
Signed-off-by: Philippe De Muyter p...@macqel.be
---
arch/m68k/include/asm/m548xgpt.h |2 +
drivers/watchdog/Kconfig |7 +-
drivers/watchdog/Makefile|3 +-
drivers/watchdog/m548x_wdt.c | 227 ++
4 files changed, 236 insertions(+), 3 deletions(-)
create mode 100644 drivers/watchdog/m548x_wdt.c
diff --git a/arch/m68k/include/asm/m548xgpt.h b/arch/m68k/include/asm/m548xgpt.h
index c8ef158..33b2eef 100644
--- a/arch/m68k/include/asm/m548xgpt.h
+++ b/arch/m68k/include/asm/m548xgpt.h
@@ -59,11 +59,13 @@
#define MCF_GPT_GMS_GPIO_INPUT (0x)
#define MCF_GPT_GMS_GPIO_OUTLO (0x0020)
#define MCF_GPT_GMS_GPIO_OUTHI (0x0030)
+#define MCF_GPT_GMS_GPIO_MASK (0x0030)
#define MCF_GPT_GMS_TMS_DISABLE(0x)
#define MCF_GPT_GMS_TMS_INCAPT (0x0001)
#define MCF_GPT_GMS_TMS_OUTCAPT(0x0002)
#define MCF_GPT_GMS_TMS_PWM(0x0003)
#define MCF_GPT_GMS_TMS_GPIO (0x0004)
+#define MCF_GPT_GMS_TMS_MASK (0x0007)
/* Bit definitions and macros for MCF_GPT_GCIR */
#define MCF_GPT_GCIR_CNT(x)(((x)0x)0)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index c356146..1a58eb3 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -828,7 +828,12 @@ config SBC_EPX_C3_WATCHDOG
# M68K Architecture
-# M68KNOMMU Architecture
+config M548x_WATCHDOG
+ tristate MCF548x watchdog support
+ depends on WATCHDOG
+ help
+ To compile this driver as a module, choose M here: the
+ module will be called m548x_wdt.
# MIPS Architecture
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 8374503..3d7b596 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -104,8 +104,7 @@ obj-$(CONFIG_SBC_EPX_C3_WATCHDOG) += sbc_epx_c3.o
# M32R Architecture
# M68K Architecture
-
-# M68KNOMMU Architecture
+obj-$(CONFIG_M548x_WATCHDOG) += m548x_wdt.o
# MIPS Architecture
obj-$(CONFIG_BCM47XX_WDT) += bcm47xx_wdt.o
diff --git a/drivers/watchdog/m548x_wdt.c b/drivers/watchdog/m548x_wdt.c
new file mode 100644
index 000..8983596
--- /dev/null
+++ b/drivers/watchdog/m548x_wdt.c
@@ -0,0 +1,227 @@
+/*
+ * drivers/watchdog/m548x_wdt.c
+ *
+ * Watchdog driver for ColdFire MCF548x processors
+ * Copyright 2010 (c) Philippe De Muyter p...@macqel.be
+ *
+ * Adapted from the IXP4xx watchdog driver, which carries these notices:
+ *
+ * Author: Deepak Saxena dsax...@plexity.net
+ *
+ * Copyright 2004 (c) MontaVista, Software, Inc.
+ * Based on sa1100 driver, Copyright (C) 2000 Oleg Drokin gr...@crimea.edu
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/fs.h
+#include linux/miscdevice.h
+#include linux/watchdog.h
+#include linux/init.h
+#include linux/bitops.h
+#include linux/ioport.h
+
+#include asm/uaccess.h
+#include asm/coldfire.h
+#include asm/m548xsim.h
+#include asm/m548xgpt.h
+
+static int nowayout;
+static unsigned int heartbeat = 30;/* (secs) Default is 0.5 minute */
+static unsigned long wdt_status;
+
+#defineWDT_IN_USE 0
+#defineWDT_OK_TO_CLOSE 1
+
+static void wdt_enable(void)
+{
+ unsigned int gms0;
+
+ /* preserve GPIO usage, if any */
+ gms0 = __raw_readl(MCF_MBAR + MCF_GPT_GMS0);
+ if (gms0 MCF_GPT_GMS_TMS_GPIO)
+ gms0 = (MCF_GPT_GMS_TMS_GPIO | MCF_GPT_GMS_GPIO_MASK |
MCF_GPT_GMS_OD);
+ else
+ gms0 = MCF_GPT_GMS_TMS_GPIO | MCF_GPT_GMS_OD;
+ __raw_writel(gms0, MCF_MBAR + MCF_GPT_GMS0);
+ __raw_writel(MCF_GPT_GCIR_PRE(heartbeat*(MCF_BUSCLK/0x)) |
+ MCF_GPT_GCIR_CNT(0x), MCF_MBAR +
MCF_GPT_GCIR0);
+ gms0 |= MCF_GPT_GMS_OCPW(0xA5) | MCF_GPT_GMS_WDEN | MCF_GPT_GMS_CE;
+ __raw_writel(gms0, MCF_MBAR + MCF_GPT_GMS0);
+}
+
+static void wdt_disable(void)
+{
+ unsigned int gms0;
+
+ /* disable watchdog */
+ gms0 = __raw_readl(MCF_MBAR + MCF_GPT_GMS0);
+ gms0 = ~(MCF_GPT_GMS_WDEN | MCF_GPT_GMS_CE);
+ __raw_writel(gms0, MCF_MBAR + MCF_GPT_GMS0);
+}
+
+static void wdt_keepalive(void)
+{
+ unsigned int gms0;
+
+ gms0 = __raw_readl(MCF_MBAR + MCF_GPT_GMS0);
+ gms0 |= MCF_GPT_GMS_OCPW(0xA5);
+ __raw_writel(gms0, MCF_MBAR + MCF_GPT_GMS0);
+}
+
+static int m548x_wdt_open(struct inode *inode, struct file *file)
+{
+ if (test_and_set_bit(WDT_IN_USE, wdt_status))
+ return -EBUSY;
+
+ clear_bit(WDT_OK_TO_CLOSE, wdt_status);
+ wdt_enable();
+ return nonseekable_open(inode, file);
+}
+
+static ssize_t m548x_wdt_write(struct file *file, const char *data, size_t
len
[uClinux-dev] [PATCH] m68k, m68knommu: Do not include linux/hardirq.h in asm/irqflags.h
Recent changes to header files made kernel compilation for m68k/m68knommu fail with : CC arch/m68knommu/kernel/asm-offsets.s In file included from /archives/linux/git/arch/m68k/include/asm/system.h:2, from include/linux/wait.h:25, from include/linux/mmzone.h:9, from include/linux/gfp.h:4, from include/linux/irq.h:20, from include/asm-generic/hardirq.h:12, from /archives/linux/git/arch/m68k/include/asm/hardirq_no.h:17, from /archives/linux/git/arch/m68k/include/asm/hardirq.h:2, from include/linux/hardirq.h:10, from /archives/linux/git/arch/m68k/include/asm/irqflags.h:5, from include/linux/irqflags.h:15, from include/linux/spinlock.h:53, from include/linux/seqlock.h:29, from include/linux/time.h:8, from include/linux/timex.h:56, from include/linux/sched.h:56, from arch/m68knommu/kernel/asm-offsets.c:12: /archives/linux/git/arch/m68k/include/asm/system_no.h: In function ‘__xchg’: /archives/linux/git/arch/m68k/include/asm/system_no.h:79: error: implicit +declaration of function ‘local_irq_save’ /archives/linux/git/arch/m68k/include/asm/system_no.h:101: error: implicit +declaration of function ‘local_irq_restore’ Fix that Signed-off-by: Philippe De Muyter p...@macqel.be --- Hello Greg, I sent that to lkml, but no-one seems to notice. Could you push it upstream ? Philippe arch/m68k/include/asm/irqflags.h |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/m68k/include/asm/irqflags.h b/arch/m68k/include/asm/irqflags.h index 4a5b284..38b414d 100644 --- a/arch/m68k/include/asm/irqflags.h +++ b/arch/m68k/include/asm/irqflags.h @@ -2,7 +2,6 @@ #define _M68K_IRQFLAGS_H #include linux/types.h -#include linux/hardirq.h #include linux/preempt.h #include asm/thread_info.h #include asm/entry.h -- 1.7.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
[uClinux-dev] [PATCH] m68knommu: Add MCF548x watchdog driver.
Signed-off-by: Philippe De Muyter p...@macqel.be
---
arch/m68k/include/asm/m548xgpt.h |2 +
drivers/watchdog/Kconfig |7 +-
drivers/watchdog/Makefile|3 +-
drivers/watchdog/m548x_wdt.c | 227 ++
4 files changed, 236 insertions(+), 3 deletions(-)
create mode 100644 drivers/watchdog/m548x_wdt.c
diff --git a/arch/m68k/include/asm/m548xgpt.h b/arch/m68k/include/asm/m548xgpt.h
index c8ef158..33b2eef 100644
--- a/arch/m68k/include/asm/m548xgpt.h
+++ b/arch/m68k/include/asm/m548xgpt.h
@@ -59,11 +59,13 @@
#define MCF_GPT_GMS_GPIO_INPUT (0x)
#define MCF_GPT_GMS_GPIO_OUTLO (0x0020)
#define MCF_GPT_GMS_GPIO_OUTHI (0x0030)
+#define MCF_GPT_GMS_GPIO_MASK (0x0030)
#define MCF_GPT_GMS_TMS_DISABLE(0x)
#define MCF_GPT_GMS_TMS_INCAPT (0x0001)
#define MCF_GPT_GMS_TMS_OUTCAPT(0x0002)
#define MCF_GPT_GMS_TMS_PWM(0x0003)
#define MCF_GPT_GMS_TMS_GPIO (0x0004)
+#define MCF_GPT_GMS_TMS_MASK (0x0007)
/* Bit definitions and macros for MCF_GPT_GCIR */
#define MCF_GPT_GCIR_CNT(x)(((x)0x)0)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index c356146..1a58eb3 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -828,7 +828,12 @@ config SBC_EPX_C3_WATCHDOG
# M68K Architecture
-# M68KNOMMU Architecture
+config M548x_WATCHDOG
+ tristate MCF548x watchdog support
+ depends on WATCHDOG
+ help
+ To compile this driver as a module, choose M here: the
+ module will be called m548x_wdt.
# MIPS Architecture
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 8374503..3d7b596 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -104,8 +104,7 @@ obj-$(CONFIG_SBC_EPX_C3_WATCHDOG) += sbc_epx_c3.o
# M32R Architecture
# M68K Architecture
-
-# M68KNOMMU Architecture
+obj-$(CONFIG_M548x_WATCHDOG) += m548x_wdt.o
# MIPS Architecture
obj-$(CONFIG_BCM47XX_WDT) += bcm47xx_wdt.o
diff --git a/drivers/watchdog/m548x_wdt.c b/drivers/watchdog/m548x_wdt.c
new file mode 100644
index 000..8983596
--- /dev/null
+++ b/drivers/watchdog/m548x_wdt.c
@@ -0,0 +1,227 @@
+/*
+ * drivers/watchdog/m548x_wdt.c
+ *
+ * Watchdog driver for ColdFire MCF548x processors
+ * Copyright 2010 (c) Philippe De Muyter p...@macqel.be
+ *
+ * Adapted from the IXP4xx watchdog driver, which carries these notices:
+ *
+ * Author: Deepak Saxena dsax...@plexity.net
+ *
+ * Copyright 2004 (c) MontaVista, Software, Inc.
+ * Based on sa1100 driver, Copyright (C) 2000 Oleg Drokin gr...@crimea.edu
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/fs.h
+#include linux/miscdevice.h
+#include linux/watchdog.h
+#include linux/init.h
+#include linux/bitops.h
+#include linux/ioport.h
+
+#include asm/uaccess.h
+#include asm/coldfire.h
+#include asm/m548xsim.h
+#include asm/m548xgpt.h
+
+static int nowayout;
+static unsigned int heartbeat = 30;/* (secs) Default is 0.5 minute */
+static unsigned long wdt_status;
+
+#defineWDT_IN_USE 0
+#defineWDT_OK_TO_CLOSE 1
+
+static void wdt_enable(void)
+{
+ unsigned int gms0;
+
+ /* preserve GPIO usage, if any */
+ gms0 = __raw_readl(MCF_MBAR + MCF_GPT_GMS0);
+ if (gms0 MCF_GPT_GMS_TMS_GPIO)
+ gms0 = (MCF_GPT_GMS_TMS_GPIO | MCF_GPT_GMS_GPIO_MASK |
MCF_GPT_GMS_OD);
+ else
+ gms0 = MCF_GPT_GMS_TMS_GPIO | MCF_GPT_GMS_OD;
+ __raw_writel(gms0, MCF_MBAR + MCF_GPT_GMS0);
+ __raw_writel(MCF_GPT_GCIR_PRE(heartbeat*(MCF_BUSCLK/0x)) |
+ MCF_GPT_GCIR_CNT(0x), MCF_MBAR +
MCF_GPT_GCIR0);
+ gms0 |= MCF_GPT_GMS_OCPW(0xA5) | MCF_GPT_GMS_WDEN | MCF_GPT_GMS_CE;
+ __raw_writel(gms0, MCF_MBAR + MCF_GPT_GMS0);
+}
+
+static void wdt_disable(void)
+{
+ unsigned int gms0;
+
+ /* disable watchdog */
+ gms0 = __raw_readl(MCF_MBAR + MCF_GPT_GMS0);
+ gms0 = ~(MCF_GPT_GMS_WDEN | MCF_GPT_GMS_CE);
+ __raw_writel(gms0, MCF_MBAR + MCF_GPT_GMS0);
+}
+
+static void wdt_keepalive(void)
+{
+ unsigned int gms0;
+
+ gms0 = __raw_readl(MCF_MBAR + MCF_GPT_GMS0);
+ gms0 |= MCF_GPT_GMS_OCPW(0xA5);
+ __raw_writel(gms0, MCF_MBAR + MCF_GPT_GMS0);
+}
+
+static int m548x_wdt_open(struct inode *inode, struct file *file)
+{
+ if (test_and_set_bit(WDT_IN_USE, wdt_status))
+ return -EBUSY;
+
+ clear_bit(WDT_OK_TO_CLOSE, wdt_status);
+ wdt_enable();
+ return nonseekable_open(inode, file);
+}
+
+static ssize_t m548x_wdt_write(struct file *file, const char *data, size_t
len
[uClinux-dev] [PATCH 1/3] m68knommu: Create new m54xxacr.h from m5407sim.h subpart
The MCF548x have the same cache control registers as the MCF5407. Extract the bit definitions for the ACR and CACR registers from m5407sim.h and move them to a new file m54xxacr.h. Those definitions are not used anywhere yet, so no other file is involved. This is a preparation for m54xx cache support cleanup. Signed-off-by: Philippe De Muyter p...@macqel.be --- arch/m68k/include/asm/m5407sim.h | 34 -- arch/m68k/include/asm/m54xxacr.h | 43 ++ 2 files changed, 43 insertions(+), 34 deletions(-) create mode 100644 arch/m68k/include/asm/m54xxacr.h diff --git a/arch/m68k/include/asm/m5407sim.h b/arch/m68k/include/asm/m5407sim.h index c399abb..2099435 100644 --- a/arch/m68k/include/asm/m5407sim.h +++ b/arch/m68k/include/asm/m5407sim.h @@ -117,39 +117,5 @@ #defineMCF_IRQ_TIMER 30 /* Timer0, Level 6 */ #defineMCF_IRQ_PROFILER31 /* Timer1, Level 7 */ -/* - * Define the Cache register flags. - */ -#defineCACR_DEC0x8000 /* Enable data cache */ -#defineCACR_DWP0x4000 /* Data write protection */ -#defineCACR_DESB 0x2000 /* Enable data store buffer */ -#defineCACR_DDPI 0x1000 /* Disable CPUSHL */ -#defineCACR_DHCLK 0x0800 /* Half data cache lock mode */ -#defineCACR_DDCM_WT0x /* Write through cache*/ -#defineCACR_DDCM_CP0x0200 /* Copyback cache */ -#defineCACR_DDCM_P 0x0400 /* No cache, precise */ -#defineCACR_DDCM_IMP 0x0600 /* No cache, imprecise */ -#defineCACR_DCINVA 0x0100 /* Invalidate data cache */ -#defineCACR_BEC0x0008 /* Enable branch cache */ -#defineCACR_BCINVA 0x0004 /* Invalidate branch cache */ -#defineCACR_IEC0x8000 /* Enable instruction cache */ -#defineCACR_DNFB 0x2000 /* Inhibited fill buffer */ -#defineCACR_IDPI 0x1000 /* Disable CPUSHL */ -#defineCACR_IHLCK 0x0800 /* Intruction cache half lock */ -#defineCACR_IDCM 0x0400 /* Intruction cache inhibit */ -#defineCACR_ICINVA 0x0100 /* Invalidate instr cache */ - -#defineACR_BASE_POS24 /* Address Base */ -#defineACR_MASK_POS16 /* Address Mask */ -#defineACR_ENABLE 0x8000 /* Enable address */ -#defineACR_USER0x /* User mode access only */ -#defineACR_SUPER 0x2000 /* Supervisor mode only */ -#defineACR_ANY 0x4000 /* Match any access mode */ -#defineACR_CM_WT 0x /* Write through mode */ -#defineACR_CM_CP 0x0020 /* Copyback mode */ -#defineACR_CM_OFF_PRE 0x0040 /* No cache, precise */ -#defineACR_CM_OFF_IMP 0x0060 /* No cache, imprecise */ -#defineACR_WPROTECT0x0004 /* Write protect */ - // #endif /* m5407sim_h */ diff --git a/arch/m68k/include/asm/m54xxacr.h b/arch/m68k/include/asm/m54xxacr.h new file mode 100644 index 000..424d4a6 --- /dev/null +++ b/arch/m68k/include/asm/m54xxacr.h @@ -0,0 +1,43 @@ +/* + * Bit definitions for the MCF54xx ACR and CACR registers. + */ + +#ifndefm54xxacr_h +#define m54xxacr_h + +/* + * Define the Cache register flags. + */ +#define CACR_DEC 0x8000 /* Enable data cache */ +#define CACR_DWP 0x4000 /* Data write protection */ +#define CACR_DESB 0x2000 /* Enable data store buffer */ +#define CACR_DDPI 0x1000 /* Disable invalidation by CPUSHL */ +#define CACR_DHCLK 0x0800 /* Half data cache lock mode */ +#define CACR_DDCM_WT 0x /* Write through cache*/ +#define CACR_DDCM_CP 0x0200 /* Copyback cache */ +#define CACR_DDCM_P0x0400 /* No cache, precise */ +#define CACR_DDCM_IMP 0x0600 /* No cache, imprecise */ +#define CACR_DCINVA0x0100 /* Invalidate data cache */ +#define CACR_BEC 0x0008 /* Enable branch cache */ +#define CACR_BCINVA0x0004 /* Invalidate branch cache */ +#define CACR_IEC 0x8000 /* Enable instruction cache */ +#define CACR_DNFB 0x2000 /* Inhibited fill buffer */ +#define CACR_IDPI 0x1000 /* Disable CPUSHL */ +#define CACR_IHLCK 0x0800 /* Intruction cache half lock */ +#define
[uClinux-dev] [PATCH 2/3] m68knommu: Move __flush_cache_all definition for m54xx in m54xxacr.h
__flush_cache_all for m54xx is intrinsically related to the bit
definitions in m54xxacr.h. Move it there from cacheflush_no.h,
for easier maintenance.
Signed-off-by: Philippe De Muyter p...@macqel.be
---
arch/m68k/include/asm/cacheflush_no.h | 28 +---
arch/m68k/include/asm/m54xxacr.h | 31 +++
2 files changed, 36 insertions(+), 23 deletions(-)
diff --git a/arch/m68k/include/asm/cacheflush_no.h
b/arch/m68k/include/asm/cacheflush_no.h
index 7085bd5..8fda331 100644
--- a/arch/m68k/include/asm/cacheflush_no.h
+++ b/arch/m68k/include/asm/cacheflush_no.h
@@ -5,6 +5,9 @@
* (C) Copyright 2000-2004, Greg Ungerer g...@snapgear.com
*/
#include linux/mm.h
+#if defined(CONFIG_M5407) || defined(CONFIG_M548x)
+#include asm/m54xxacr.h
+#endif
#define flush_cache_all() __flush_cache_all()
#define flush_cache_mm(mm) do { } while (0)
@@ -27,31 +30,9 @@
#define copy_from_user_page(vma, page, vaddr, dst, src, len) \
memcpy(dst, src, len)
+#ifndef __flush_cache_all
static inline void __flush_cache_all(void)
{
-#if defined(CONFIG_M5407) || defined(CONFIG_M548x)
- /*
-* Use cpushl to push and invalidate all cache lines.
-* Gas doesn't seem to know how to generate the ColdFire
-* cpushl instruction... Oh well, bit stuff it for now.
-*/
- __asm__ __volatile__ (
- nop\n\t
- clrl %%d0\n\t
- 1:\n\t
- movel %%d0,%%a0\n\t
- 2:\n\t
- .word 0xf468\n\t
- addl #0x10,%%a0\n\t
- cmpl #0x0800,%%a0\n\t
- blt2b\n\t
- addql #1,%%d0\n\t
- cmpil #4,%%d0\n\t
- bne1b\n\t
- movel #0xb6088500,%%d0\n\t
- movec %%d0,%%CACR\n\t
- : : : d0, a0 );
-#endif /* CONFIG_M5407 */
#if defined(CONFIG_M523x) || defined(CONFIG_M527x)
__asm__ __volatile__ (
movel #0x81400100, %%d0\n\t
@@ -88,5 +69,6 @@ static inline void __flush_cache_all(void)
: : : d0 );
#endif /* CONFIG_M532x */
}
+#endif /* __flush_cache_all */
#endif /* _M68KNOMMU_CACHEFLUSH_H */
diff --git a/arch/m68k/include/asm/m54xxacr.h b/arch/m68k/include/asm/m54xxacr.h
index 424d4a6..da713d2 100644
--- a/arch/m68k/include/asm/m54xxacr.h
+++ b/arch/m68k/include/asm/m54xxacr.h
@@ -40,4 +40,35 @@
#define ACR_CM 0x0060 /* Cache mode mask */
#define ACR_WPROTECT 0x0004 /* Write protect */
+#ifndef __ASSEMBLY__
+
+static inline void __m54xx_flush_cache_all(void)
+{
+ /*
+* Use cpushl to push and invalidate all cache lines.
+* Gas doesn't seem to know how to generate the ColdFire
+* cpushl instruction... Oh well, bit stuff it for now.
+*/
+ __asm__ __volatile__ (
+ nop\n\t
+ clrl %%d0\n\t
+ 1:\n\t
+ movel %%d0,%%a0\n\t
+ 2:\n\t
+ .word 0xf468\n\t
+ addl #0x10,%%a0\n\t
+ cmpl #0x0800,%%a0\n\t
+ blt2b\n\t
+ addql #1,%%d0\n\t
+ cmpil #4,%%d0\n\t
+ bne1b\n\t
+ movel #0xb6088500,%%d0\n\t
+ movec %%d0,%%CACR\n\t
+ : : : d0, a0 );
+}
+
+#define __flush_cache_all() __m54xx_flush_cache_all()
+
+#endif /* __ASSEMBLY__ */
+
#endif /* m54xxacr_h */
--
1.7.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
Re: [uClinux-dev] Get RT73 driver to work on 2.4 or try to move to 2.6? ARM7 from Nuvoton
On Wed, Oct 20, 2010 at 11:53:58AM +0200, Sima Baymani wrote: Hi David (and everyone else)! Just to make sure I understand, I have some questions to clarify to myself how it works and what my options are. - the RT73 is a Ralink wifi-unit. According to Ralink, it should work on Linux 2.4 and 2.6. Does that (generally) mean that Linux 2.4 and 2.6 have those vendor patches/fixes but uClinux does not? That could also mean that ralink provides drivers on a CD or on its website that you must compile for your kernel. Philippe ___ 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] Get RT73 driver to work on 2.4 or try to move to 2.6? ARM7 from Nuvoton
On Wed, Oct 20, 2010 at 12:40:47PM +0200, Sima Baymani wrote: On Wed, Oct 20, 2010 at 12:33 PM, Philippe De Muyter p...@macqel.be wrote: On Wed, Oct 20, 2010 at 11:53:58AM +0200, Sima Baymani wrote: Hi David (and everyone else)! Just to make sure I understand, I have some questions to clarify to myself how it works and what my options are. - the RT73 is a Ralink wifi-unit. According to Ralink, it should work on Linux 2.4 and 2.6. Does that (generally) mean that Linux 2.4 and 2.6 have those vendor patches/fixes but uClinux does not? That could also mean that ralink provides drivers on a CD or on its website that you must compile for your kernel. The driver I try to get working is actually the one from Ralink. =/ So the driver compiles and apparently gets registered but the device does not pop up. Has the driver usually anything to do with the device popping up or is it only to make the device work? I am honestly a bit confused here between what is the responsibility of the driver and of the kernel. Without the driver, you won't get a device popping up (if I understand what you mean by popping up), e.g. you won't get a ethX or wlanX for your device. Philippe -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ 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] Wrong exception handling on m68knommu Coldfire 5208?
On Thu, Oct 07, 2010 at 05:27:36PM +1000, Greg Ungerer wrote: Sorry for the really slow response on this... Glad to see you here again :) Problem reported by alexander.st...@systec-electronic.com. I think there is now a standardized keyword for that : Reported-by: Alexander Stein alexander.st...@systec-electronic.com Philippe ___ 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] Re: [PATCH] m68knommu: Use symbolic constants for cache initialisation on M548x
On Tue, Sep 21, 2010 at 05:50:04PM +0200, Philippe De Muyter wrote: The MCF548x have the same cache control registers as the MCF5407. Extract the bit definitions for the ACR and CACR registers from m5407sim.h and move them to a new file m54xxacr.h. Use them instead of hex constants in cacheflush_no.h and mcfcache.h. Signed-off-by: Philippe De Muyter p...@macqel.be Sorry, my patch was not complete (git misunderstanding :() Philippe ___ 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] [PATCHv2] m68knommu: Use symbolic constants for cache initialisation on M548x
The MCF548x have the same cache control registers as the MCF5407.
Extract the bit definitions for the ACR and CACR registers from m5407sim.h
and move them to a new file m54xxacr.h. Use them instead of hex
constants in cacheflush_no.h and mcfcache.h.
Signed-off-by: Philippe De Muyter p...@macqel.be
---
arch/m68k/include/asm/cacheflush_no.h | 29 +---
arch/m68k/include/asm/m5407sim.h | 34 ---
arch/m68k/include/asm/m54xxacr.h | 76 +
arch/m68k/include/asm/mcfcache.h | 22 +
4 files changed, 110 insertions(+), 51 deletions(-)
create mode 100644 arch/m68k/include/asm/m54xxacr.h
diff --git a/arch/m68k/include/asm/cacheflush_no.h
b/arch/m68k/include/asm/cacheflush_no.h
index 7085bd5..a8334f2 100644
--- a/arch/m68k/include/asm/cacheflush_no.h
+++ b/arch/m68k/include/asm/cacheflush_no.h
@@ -5,13 +5,21 @@
* (C) Copyright 2000-2004, Greg Ungerer g...@snapgear.com
*/
#include linux/mm.h
+#if defined(CONFIG_M5407) || defined(CONFIG_M548x)
+#include asm/m54xxacr.h
+#if ((DATA_CACHE_MODE ACR_CM) == ACR_CM_WT)
+#define flush_dcache_range(a, l) do { asm(nop); } while (0)
+#endif
+#endif
#define flush_cache_all() __flush_cache_all()
#define flush_cache_mm(mm) do { } while (0)
#define flush_cache_dup_mm(mm) do { } while (0)
#define flush_cache_range(vma, start, end) __flush_cache_all()
#define flush_cache_page(vma, vmaddr) do { } while (0)
+#ifndef flush_dcache_range
#define flush_dcache_range(start,len) __flush_cache_all()
+#endif
#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
#define flush_dcache_page(page)do { } while (0)
#define flush_dcache_mmap_lock(mapping)do { } while (0)
@@ -30,27 +38,34 @@
static inline void __flush_cache_all(void)
{
#if defined(CONFIG_M5407) || defined(CONFIG_M548x)
+ __asm__ __volatile__ (
+#if ((DATA_CACHE_MODE ACR_CM) == ACR_CM_CP)
/*
* Use cpushl to push and invalidate all cache lines.
* Gas doesn't seem to know how to generate the ColdFire
* cpushl instruction... Oh well, bit stuff it for now.
*/
- __asm__ __volatile__ (
- nop\n\t
clrl %%d0\n\t
1:\n\t
movel %%d0,%%a0\n\t
2:\n\t
.word 0xf468\n\t
- addl #0x10,%%a0\n\t
- cmpl #0x0800,%%a0\n\t
+ addl %0,%%a0\n\t
+ cmpl %1,%%a0\n\t
blt2b\n\t
addql #1,%%d0\n\t
- cmpil #4,%%d0\n\t
+ cmpil %2,%%d0\n\t
bne1b\n\t
- movel #0xb6088500,%%d0\n\t
+#endif
+ movel %3,%%d0\n\t
movec %%d0,%%CACR\n\t
- : : : d0, a0 );
+ nop\n\t /* forces flush of Store Buffer */
+ : /* No output */
+ : i (CACHE_LINE_SIZE),
+ i (DCACHE_SIZE / CACHE_WAYS),
+ i (CACHE_WAYS),
+ i (CACHE_MODE|CACR_DCINVA|CACR_BCINVA|CACR_ICINVA)
+ : d0, a0 );
#endif /* CONFIG_M5407 */
#if defined(CONFIG_M523x) || defined(CONFIG_M527x)
__asm__ __volatile__ (
diff --git a/arch/m68k/include/asm/m5407sim.h b/arch/m68k/include/asm/m5407sim.h
index c399abb..2099435 100644
--- a/arch/m68k/include/asm/m5407sim.h
+++ b/arch/m68k/include/asm/m5407sim.h
@@ -117,39 +117,5 @@
#defineMCF_IRQ_TIMER 30 /* Timer0, Level 6 */
#defineMCF_IRQ_PROFILER31 /* Timer1, Level 7 */
-/*
- * Define the Cache register flags.
- */
-#defineCACR_DEC0x8000 /* Enable data cache */
-#defineCACR_DWP0x4000 /* Data write
protection */
-#defineCACR_DESB 0x2000 /* Enable data store
buffer */
-#defineCACR_DDPI 0x1000 /* Disable CPUSHL */
-#defineCACR_DHCLK 0x0800 /* Half data cache lock
mode */
-#defineCACR_DDCM_WT0x /* Write through cache*/
-#defineCACR_DDCM_CP0x0200 /* Copyback cache */
-#defineCACR_DDCM_P 0x0400 /* No cache, precise */
-#defineCACR_DDCM_IMP 0x0600 /* No cache, imprecise
*/
-#defineCACR_DCINVA 0x0100 /* Invalidate data
cache */
-#defineCACR_BEC0x0008 /* Enable branch cache
*/
-#defineCACR_BCINVA 0x0004 /* Invalidate branch
cache */
-#defineCACR_IEC0x8000 /* Enable instruction
cache */
-#defineCACR_DNFB 0x2000 /* Inhibited fill
buffer */
-#defineCACR_IDPI 0x1000 /* Disable
[uClinux-dev] [PATCH 12/12] m68knommu: Fix MCFUART_TXFIFOSIZE for m548x.
Serial lines on the MCF548x have really big fifos : 512 bytes.
Signed-off-by: Philippe De Muyter p...@macqel.be
---
arch/m68k/include/asm/mcfuart.h |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/m68k/include/asm/mcfuart.h b/arch/m68k/include/asm/mcfuart.h
index af16f3b..db72e2b 100644
--- a/arch/m68k/include/asm/mcfuart.h
+++ b/arch/m68k/include/asm/mcfuart.h
@@ -217,7 +217,9 @@ struct mcf_platform_uart {
#defineMCFUART_URF_RXS 0xc0/* Receiver status */
#endif
-#if defined(CONFIG_M5272)
+#if defined(CONFIG_M548x)
+#define MCFUART_TXFIFOSIZE 512
+#elif defined(CONFIG_M5272)
#define MCFUART_TXFIFOSIZE 25
#else
#define MCFUART_TXFIFOSIZE 1
--
1.6.3.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
[uClinux-dev] [PATCHv5] m68knommu: add basic mmu-less m548x support
Hello Greg,
Resent, now with checkpath.pl suggested changes, except :
WARNING: please, no space for starting a line,
excluding comments
#75: FILE: arch/m68k/include/asm/gpio.h:39:
+defined(CONFIG_M527x) || defined(CONFIG_M528x) || \$
WARNING: please, no space for starting a line,
excluding comments
#76: FILE: arch/m68k/include/asm/gpio.h:40:
+defined(CONFIG_M532x) || defined(CONFIG_M548x)$
WARNING: please write a paragraph that describes the config symbol fully
#355: FILE: arch/m68knommu/Kconfig:176:
+ help
total: 0 errors, 3 warnings, 582 lines checked
0011-m68knommu-add-basic-mmu-less-m548x-support.patch has style problems,
please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Philippe
--
Add a very basic mmu-less support for coldfire m548x family. This is perhaps
also valid for m547x family. The port comprises the serial, tick timer and
reboot support. The gpio part compiles but is empty. This gives a functional
albeit limited linux for the m548x coldfire family. This has been tested
on a Freescale M548xEVB Lite board with a M5484 processor and the default
dbug monitor.
Signed-off-by: Philippe De Muyter p...@macqel.be
---
arch/m68k/include/asm/cacheflush_no.h |2 +-
arch/m68k/include/asm/coldfire.h|4 +-
arch/m68k/include/asm/gpio.h|7 +-
arch/m68k/include/asm/m548xgpt.h| 88
arch/m68k/include/asm/m548xsim.h| 55 ++
arch/m68k/include/asm/mcfcache.h|2 +-
arch/m68k/include/asm/mcfsim.h |2 +
arch/m68k/include/asm/mcfslt.h | 44
arch/m68k/include/asm/mcfuart.h |5 +
arch/m68knommu/Kconfig |7 +-
arch/m68knommu/Makefile |3 +
arch/m68knommu/platform/548x/Makefile | 18
arch/m68knommu/platform/548x/config.c | 115 +
arch/m68knommu/platform/coldfire/Makefile |1 +
arch/m68knommu/platform/coldfire/sltimers.c | 145 +++
15 files changed, 493 insertions(+), 5 deletions(-)
create mode 100644 arch/m68k/include/asm/m548xgpt.h
create mode 100644 arch/m68k/include/asm/m548xsim.h
create mode 100644 arch/m68k/include/asm/mcfslt.h
create mode 100644 arch/m68knommu/platform/548x/Makefile
create mode 100644 arch/m68knommu/platform/548x/config.c
create mode 100644 arch/m68knommu/platform/coldfire/sltimers.c
diff --git a/arch/m68k/include/asm/cacheflush_no.h
b/arch/m68k/include/asm/cacheflush_no.h
index 89f1956..7085bd5 100644
--- a/arch/m68k/include/asm/cacheflush_no.h
+++ b/arch/m68k/include/asm/cacheflush_no.h
@@ -29,7 +29,7 @@
static inline void __flush_cache_all(void)
{
-#ifdef CONFIG_M5407
+#if defined(CONFIG_M5407) || defined(CONFIG_M548x)
/*
* Use cpushl to push and invalidate all cache lines.
* Gas doesn't seem to know how to generate the ColdFire
diff --git a/arch/m68k/include/asm/coldfire.h b/arch/m68k/include/asm/coldfire.h
index 83a9fa4..3b0a34d 100644
--- a/arch/m68k/include/asm/coldfire.h
+++ b/arch/m68k/include/asm/coldfire.h
@@ -32,7 +32,9 @@
*/
#defineMCF_MBAR0x1000
#defineMCF_MBAR2 0x8000
-#if defined(CONFIG_M520x)
+#if defined(CONFIG_M548x)
+#defineMCF_IPSBAR MCF_MBAR
+#elif defined(CONFIG_M520x)
#defineMCF_IPSBAR 0xFC00
#else
#defineMCF_IPSBAR 0x4000
diff --git a/arch/m68k/include/asm/gpio.h b/arch/m68k/include/asm/gpio.h
index 283214d..1b57adb 100644
--- a/arch/m68k/include/asm/gpio.h
+++ b/arch/m68k/include/asm/gpio.h
@@ -36,7 +36,8 @@
*/
#if defined(CONFIG_M5206) || defined(CONFIG_M5206e) || \
defined(CONFIG_M520x) || defined(CONFIG_M523x) || \
-defined(CONFIG_M527x) || defined(CONFIG_M528x) || defined(CONFIG_M532x)
+defined(CONFIG_M527x) || defined(CONFIG_M528x) || \
+defined(CONFIG_M532x) || defined(CONFIG_M548x)
/* These parts have GPIO organized by 8 bit ports */
@@ -136,6 +137,8 @@ static inline u32 __mcf_gpio_ppdr(unsigned gpio)
#endif
else
return MCFGPIO_PPDR + mcfgpio_port(gpio - MCFGPIO_SCR_START);
+#else
+ return 0;
#endif
}
@@ -173,6 +176,8 @@ static inline u32 __mcf_gpio_podr(unsigned gpio)
#endif
else
return MCFGPIO_PODR + mcfgpio_port(gpio - MCFGPIO_SCR_START);
+#else
+ return 0;
#endif
}
diff --git a/arch/m68k/include/asm/m548xgpt.h b/arch/m68k/include/asm/m548xgpt.h
new file mode 100644
index 000..c8ef158
--- /dev/null
+++ b/arch/m68k/include/asm/m548xgpt.h
@@ -0,0 +1,88 @@
+/*
+ * File: m548xgpt.h
+ * Purpose:Register and bit definitions for the MCF548X
+ *
+ * Notes:
+ *
+ */
+
+#ifndef m548xgpt_h
+#define m548xgpt_h
[uClinux-dev] [PATCHv4] m68knommu: add basic mmu-less m548x support
Hello Greg,
Resent, because modified files were missing in v3 (I am not yet a git expert :))
Philippe
--
Add a very basic mmu-less support for coldfire m548x family. This is perhaps
also valid for m547x family. The port comprises the serial, tick timer and
reboot support. The gpio part compiles but is empty. This gives a functional
albeit limited linux for the m548x coldfire family. This has been tested
on a Freescale M548xEVB Lite board with a M5484 processor and the default
dbug monitor.
Signed-off-by: Philippe De Muyter p...@macqel.be
---
arch/m68k/include/asm/cacheflush_no.h |2 +-
arch/m68k/include/asm/coldfire.h|4 +-
arch/m68k/include/asm/gpio.h|7 +-
arch/m68k/include/asm/m548xgpt.h| 88 +++
arch/m68k/include/asm/m548xsim.h| 55 +
arch/m68k/include/asm/mcfcache.h|2 +-
arch/m68k/include/asm/mcfsim.h |2 +
arch/m68k/include/asm/mcfslt.h | 44
arch/m68k/include/asm/mcfuart.h |5 +
arch/m68knommu/Kconfig |7 +-
arch/m68knommu/Makefile |3 +
arch/m68knommu/platform/548x/Makefile | 18 +++
arch/m68knommu/platform/548x/config.c | 111 ++
arch/m68knommu/platform/coldfire/Makefile |1 +
arch/m68knommu/platform/coldfire/sltimers.c | 160 +++
15 files changed, 504 insertions(+), 5 deletions(-)
create mode 100644 arch/m68k/include/asm/m548xgpt.h
create mode 100644 arch/m68k/include/asm/m548xsim.h
create mode 100644 arch/m68k/include/asm/mcfslt.h
create mode 100644 arch/m68knommu/platform/548x/Makefile
create mode 100644 arch/m68knommu/platform/548x/config.c
create mode 100644 arch/m68knommu/platform/coldfire/sltimers.c
diff --git a/arch/m68k/include/asm/cacheflush_no.h
b/arch/m68k/include/asm/cacheflush_no.h
index 89f1956..7085bd5 100644
--- a/arch/m68k/include/asm/cacheflush_no.h
+++ b/arch/m68k/include/asm/cacheflush_no.h
@@ -29,7 +29,7 @@
static inline void __flush_cache_all(void)
{
-#ifdef CONFIG_M5407
+#if defined(CONFIG_M5407) || defined(CONFIG_M548x)
/*
* Use cpushl to push and invalidate all cache lines.
* Gas doesn't seem to know how to generate the ColdFire
diff --git a/arch/m68k/include/asm/coldfire.h b/arch/m68k/include/asm/coldfire.h
index 83a9fa4..3b0a34d 100644
--- a/arch/m68k/include/asm/coldfire.h
+++ b/arch/m68k/include/asm/coldfire.h
@@ -32,7 +32,9 @@
*/
#defineMCF_MBAR0x1000
#defineMCF_MBAR2 0x8000
-#if defined(CONFIG_M520x)
+#if defined(CONFIG_M548x)
+#defineMCF_IPSBAR MCF_MBAR
+#elif defined(CONFIG_M520x)
#defineMCF_IPSBAR 0xFC00
#else
#defineMCF_IPSBAR 0x4000
diff --git a/arch/m68k/include/asm/gpio.h b/arch/m68k/include/asm/gpio.h
index 283214d..1b57adb 100644
--- a/arch/m68k/include/asm/gpio.h
+++ b/arch/m68k/include/asm/gpio.h
@@ -36,7 +36,8 @@
*/
#if defined(CONFIG_M5206) || defined(CONFIG_M5206e) || \
defined(CONFIG_M520x) || defined(CONFIG_M523x) || \
-defined(CONFIG_M527x) || defined(CONFIG_M528x) || defined(CONFIG_M532x)
+defined(CONFIG_M527x) || defined(CONFIG_M528x) || \
+defined(CONFIG_M532x) || defined(CONFIG_M548x)
/* These parts have GPIO organized by 8 bit ports */
@@ -136,6 +137,8 @@ static inline u32 __mcf_gpio_ppdr(unsigned gpio)
#endif
else
return MCFGPIO_PPDR + mcfgpio_port(gpio - MCFGPIO_SCR_START);
+#else
+ return 0;
#endif
}
@@ -173,6 +176,8 @@ static inline u32 __mcf_gpio_podr(unsigned gpio)
#endif
else
return MCFGPIO_PODR + mcfgpio_port(gpio - MCFGPIO_SCR_START);
+#else
+ return 0;
#endif
}
diff --git a/arch/m68k/include/asm/m548xgpt.h b/arch/m68k/include/asm/m548xgpt.h
new file mode 100644
index 000..c8ef158
--- /dev/null
+++ b/arch/m68k/include/asm/m548xgpt.h
@@ -0,0 +1,88 @@
+/*
+ * File: m548xgpt.h
+ * Purpose:Register and bit definitions for the MCF548X
+ *
+ * Notes:
+ *
+ */
+
+#ifndef m548xgpt_h
+#define m548xgpt_h
+
+/*
+*
+* General Purpose Timers (GPT)
+*
+*/
+
+/* Register read/write macros */
+#define MCF_GPT_GMS0 0x000800
+#define MCF_GPT_GCIR0 0x000804
+#define MCF_GPT_GPWM0 0x000808
+#define MCF_GPT_GSR0 0x00080C
+#define MCF_GPT_GMS1 0x000810
+#define MCF_GPT_GCIR1 0x000814
+#define MCF_GPT_GPWM1 0x000818
+#define MCF_GPT_GSR1 0x00081C
+#define MCF_GPT_GMS2 0x000820
+#define MCF_GPT_GCIR2 0x000824
+#define MCF_GPT_GPWM2 0x000828
+#define MCF_GPT_GSR2 0x00082C
+#define MCF_GPT_GMS3 0x000830
+#define MCF_GPT_GCIR3 0x000834
+#define MCF_GPT_GPWM3 0x000838
+#define MCF_GPT_GSR3 0x00083C
+#define
[uClinux-dev] [PATCHv2] m68knommu: add basic mmu-less m548x support
Add a very basic mmu-less support for coldfire m548x family. This is perhaps also valid for m547x family. The port comprises the serial, tick timer and reboot support. The gpio part compiles but is empty. This gives a functional albeit limited linux for the m548x coldfire family. This has been tested on a Freescale M548xEVB Lite board with a M5484 processor and the default dbug monitor. Signed-off-by: Philippe De Muyter p...@macqel.be --- arch/m68k/include/asm/m548xgpt.h| 88 +++ arch/m68k/include/asm/m548xsim.h| 55 + arch/m68k/include/asm/mcfslt.h | 44 arch/m68knommu/platform/548x/Makefile | 18 +++ arch/m68knommu/platform/548x/config.c | 121 arch/m68knommu/platform/coldfire/sltimers.c | 160 +++ 6 files changed, 486 insertions(+), 0 deletions(-) create mode 100644 arch/m68k/include/asm/m548xgpt.h create mode 100644 arch/m68k/include/asm/m548xsim.h create mode 100644 arch/m68k/include/asm/mcfslt.h create mode 100644 arch/m68knommu/platform/548x/Makefile create mode 100644 arch/m68knommu/platform/548x/config.c create mode 100644 arch/m68knommu/platform/coldfire/sltimers.c diff --git a/arch/m68k/include/asm/m548xgpt.h b/arch/m68k/include/asm/m548xgpt.h new file mode 100644 index 000..c8ef158 --- /dev/null +++ b/arch/m68k/include/asm/m548xgpt.h @@ -0,0 +1,88 @@ +/* + * File: m548xgpt.h + * Purpose:Register and bit definitions for the MCF548X + * + * Notes: + * + */ + +#ifndef m548xgpt_h +#define m548xgpt_h + +/* +* +* General Purpose Timers (GPT) +* +*/ + +/* Register read/write macros */ +#define MCF_GPT_GMS0 0x000800 +#define MCF_GPT_GCIR0 0x000804 +#define MCF_GPT_GPWM0 0x000808 +#define MCF_GPT_GSR0 0x00080C +#define MCF_GPT_GMS1 0x000810 +#define MCF_GPT_GCIR1 0x000814 +#define MCF_GPT_GPWM1 0x000818 +#define MCF_GPT_GSR1 0x00081C +#define MCF_GPT_GMS2 0x000820 +#define MCF_GPT_GCIR2 0x000824 +#define MCF_GPT_GPWM2 0x000828 +#define MCF_GPT_GSR2 0x00082C +#define MCF_GPT_GMS3 0x000830 +#define MCF_GPT_GCIR3 0x000834 +#define MCF_GPT_GPWM3 0x000838 +#define MCF_GPT_GSR3 0x00083C +#define MCF_GPT_GMS(x) (0x000800+((x)*0x010)) +#define MCF_GPT_GCIR(x)(0x000804+((x)*0x010)) +#define MCF_GPT_GPWM(x)(0x000808+((x)*0x010)) +#define MCF_GPT_GSR(x) (0x00080C+((x)*0x010)) + +/* Bit definitions and macros for MCF_GPT_GMS */ +#define MCF_GPT_GMS_TMS(x) (((x)0x0007)0) +#define MCF_GPT_GMS_GPIO(x)(((x)0x0003)4) +#define MCF_GPT_GMS_IEN(0x0100) +#define MCF_GPT_GMS_OD (0x0200) +#define MCF_GPT_GMS_SC (0x0400) +#define MCF_GPT_GMS_CE (0x1000) +#define MCF_GPT_GMS_WDEN (0x8000) +#define MCF_GPT_GMS_ICT(x) (((x)0x0003)16) +#define MCF_GPT_GMS_OCT(x) (((x)0x0003)20) +#define MCF_GPT_GMS_OCPW(x)(((x)0x00FF)24) +#define MCF_GPT_GMS_OCT_FRCLOW (0x) +#define MCF_GPT_GMS_OCT_PULSEHI(0x0010) +#define MCF_GPT_GMS_OCT_PULSELO(0x0020) +#define MCF_GPT_GMS_OCT_TOGGLE (0x0030) +#define MCF_GPT_GMS_ICT_ANY(0x) +#define MCF_GPT_GMS_ICT_RISE (0x0001) +#define MCF_GPT_GMS_ICT_FALL (0x0002) +#define MCF_GPT_GMS_ICT_PULSE (0x0003) +#define MCF_GPT_GMS_GPIO_INPUT (0x) +#define MCF_GPT_GMS_GPIO_OUTLO (0x0020) +#define MCF_GPT_GMS_GPIO_OUTHI (0x0030) +#define MCF_GPT_GMS_TMS_DISABLE(0x) +#define MCF_GPT_GMS_TMS_INCAPT (0x0001) +#define MCF_GPT_GMS_TMS_OUTCAPT(0x0002) +#define MCF_GPT_GMS_TMS_PWM(0x0003) +#define MCF_GPT_GMS_TMS_GPIO (0x0004) + +/* Bit definitions and macros for MCF_GPT_GCIR */ +#define MCF_GPT_GCIR_CNT(x)(((x)0x)0) +#define MCF_GPT_GCIR_PRE(x)(((x)0x)16) + +/* Bit definitions and macros for MCF_GPT_GPWM */ +#define MCF_GPT_GPWM_LOAD (0x0001) +#define MCF_GPT_GPWM_PWMOP (0x0100) +#define MCF_GPT_GPWM_WIDTH(x) (((x)0x)16) + +/* Bit definitions and macros for MCF_GPT_GSR */ +#define MCF_GPT_GSR_CAPT (0x0001) +#define MCF_GPT_GSR_COMP (0x0002) +#define MCF_GPT_GSR_PWMP (0x0004) +#define MCF_GPT_GSR_TEXP (0x0008) +#define MCF_GPT_GSR_PIN(0x0100) +#define MCF_GPT_GSR_OVF(x) (((x)0x0007)12) +#define MCF_GPT_GSR_CAPTURE(x) (((x)0x)16) + +// + +#endif /* m548xgpt_h */ diff --git a/arch/m68k/include/asm/m548xsim.h b/arch/m68k/include/asm/m548xsim.h new file mode 100644 index 000..7a3bacc --- /dev/null +++ b/arch
[uClinux-dev] [PATCHv3] m68knommu: add basic mmu-less m548x support
Resent because v2 had some #if 0 left Add a very basic mmu-less support for coldfire m548x family. This is perhaps also valid for m547x family. The port comprises the serial, tick timer and reboot support. The gpio part compiles but is empty. This gives a functional albeit limited linux for the m548x coldfire family. This has been tested on a Freescale M548xEVB Lite board with a M5484 processor and the default dbug monitor. Signed-off-by: Philippe De Muyter p...@macqel.be --- arch/m68k/include/asm/m548xgpt.h| 88 +++ arch/m68k/include/asm/m548xsim.h| 55 + arch/m68k/include/asm/mcfslt.h | 44 arch/m68knommu/platform/548x/Makefile | 18 +++ arch/m68knommu/platform/548x/config.c | 121 arch/m68knommu/platform/coldfire/sltimers.c | 160 +++ 6 files changed, 486 insertions(+), 0 deletions(-) create mode 100644 arch/m68k/include/asm/m548xgpt.h create mode 100644 arch/m68k/include/asm/m548xsim.h create mode 100644 arch/m68k/include/asm/mcfslt.h create mode 100644 arch/m68knommu/platform/548x/Makefile create mode 100644 arch/m68knommu/platform/548x/config.c create mode 100644 arch/m68knommu/platform/coldfire/sltimers.c diff --git a/arch/m68k/include/asm/m548xgpt.h b/arch/m68k/include/asm/m548xgpt.h new file mode 100644 index 000..c8ef158 --- /dev/null +++ b/arch/m68k/include/asm/m548xgpt.h @@ -0,0 +1,88 @@ +/* + * File: m548xgpt.h + * Purpose:Register and bit definitions for the MCF548X + * + * Notes: + * + */ + +#ifndef m548xgpt_h +#define m548xgpt_h + +/* +* +* General Purpose Timers (GPT) +* +*/ + +/* Register read/write macros */ +#define MCF_GPT_GMS0 0x000800 +#define MCF_GPT_GCIR0 0x000804 +#define MCF_GPT_GPWM0 0x000808 +#define MCF_GPT_GSR0 0x00080C +#define MCF_GPT_GMS1 0x000810 +#define MCF_GPT_GCIR1 0x000814 +#define MCF_GPT_GPWM1 0x000818 +#define MCF_GPT_GSR1 0x00081C +#define MCF_GPT_GMS2 0x000820 +#define MCF_GPT_GCIR2 0x000824 +#define MCF_GPT_GPWM2 0x000828 +#define MCF_GPT_GSR2 0x00082C +#define MCF_GPT_GMS3 0x000830 +#define MCF_GPT_GCIR3 0x000834 +#define MCF_GPT_GPWM3 0x000838 +#define MCF_GPT_GSR3 0x00083C +#define MCF_GPT_GMS(x) (0x000800+((x)*0x010)) +#define MCF_GPT_GCIR(x)(0x000804+((x)*0x010)) +#define MCF_GPT_GPWM(x)(0x000808+((x)*0x010)) +#define MCF_GPT_GSR(x) (0x00080C+((x)*0x010)) + +/* Bit definitions and macros for MCF_GPT_GMS */ +#define MCF_GPT_GMS_TMS(x) (((x)0x0007)0) +#define MCF_GPT_GMS_GPIO(x)(((x)0x0003)4) +#define MCF_GPT_GMS_IEN(0x0100) +#define MCF_GPT_GMS_OD (0x0200) +#define MCF_GPT_GMS_SC (0x0400) +#define MCF_GPT_GMS_CE (0x1000) +#define MCF_GPT_GMS_WDEN (0x8000) +#define MCF_GPT_GMS_ICT(x) (((x)0x0003)16) +#define MCF_GPT_GMS_OCT(x) (((x)0x0003)20) +#define MCF_GPT_GMS_OCPW(x)(((x)0x00FF)24) +#define MCF_GPT_GMS_OCT_FRCLOW (0x) +#define MCF_GPT_GMS_OCT_PULSEHI(0x0010) +#define MCF_GPT_GMS_OCT_PULSELO(0x0020) +#define MCF_GPT_GMS_OCT_TOGGLE (0x0030) +#define MCF_GPT_GMS_ICT_ANY(0x) +#define MCF_GPT_GMS_ICT_RISE (0x0001) +#define MCF_GPT_GMS_ICT_FALL (0x0002) +#define MCF_GPT_GMS_ICT_PULSE (0x0003) +#define MCF_GPT_GMS_GPIO_INPUT (0x) +#define MCF_GPT_GMS_GPIO_OUTLO (0x0020) +#define MCF_GPT_GMS_GPIO_OUTHI (0x0030) +#define MCF_GPT_GMS_TMS_DISABLE(0x) +#define MCF_GPT_GMS_TMS_INCAPT (0x0001) +#define MCF_GPT_GMS_TMS_OUTCAPT(0x0002) +#define MCF_GPT_GMS_TMS_PWM(0x0003) +#define MCF_GPT_GMS_TMS_GPIO (0x0004) + +/* Bit definitions and macros for MCF_GPT_GCIR */ +#define MCF_GPT_GCIR_CNT(x)(((x)0x)0) +#define MCF_GPT_GCIR_PRE(x)(((x)0x)16) + +/* Bit definitions and macros for MCF_GPT_GPWM */ +#define MCF_GPT_GPWM_LOAD (0x0001) +#define MCF_GPT_GPWM_PWMOP (0x0100) +#define MCF_GPT_GPWM_WIDTH(x) (((x)0x)16) + +/* Bit definitions and macros for MCF_GPT_GSR */ +#define MCF_GPT_GSR_CAPT (0x0001) +#define MCF_GPT_GSR_COMP (0x0002) +#define MCF_GPT_GSR_PWMP (0x0004) +#define MCF_GPT_GSR_TEXP (0x0008) +#define MCF_GPT_GSR_PIN(0x0100) +#define MCF_GPT_GSR_OVF(x) (((x)0x0007)12) +#define MCF_GPT_GSR_CAPTURE(x) (((x)0x)16) + +// + +#endif /* m548xgpt_h */ diff --git a/arch/m68k/include/asm/m548xsim.h b/arch/m68k/include/asm/m548xsim.h new file mode 100644 index
[uClinux-dev] [PATCH] m68knommu: .gitignore vmlinux.lds
Signed-off-by: Philippe De Muyter p...@macqel.be --- arch/m68knommu/kernel/.gitignore |1 + 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 arch/m68knommu/kernel/.gitignore diff --git a/arch/m68knommu/kernel/.gitignore b/arch/m68knommu/kernel/.gitignore new file mode 100644 index 000..c5f676c --- /dev/null +++ b/arch/m68knommu/kernel/.gitignore @@ -0,0 +1 @@ +vmlinux.lds -- 1.6.3.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
[uClinux-dev] [PATCHv2] m68knommu: add support for Coldfire 547x/548x interrupt controller
Hi Greg,
Defines look good. Probably no point having a separate header
file for these, given the only use is in intc-2.c. I would
suggest putting them directly in intc-2.c
I think that in the long term, we'll need one, e.g. because the profile
timer will want to choose its (high) level+priority.
In the mean time, here is a revised patch.
Best regards
Philippe
---
The Coldfire MCF547x/MCF548x have the same interrupt controller than
the MCF528x e.g., but only one, not two as in the MCF528x. Modify
intc-2.c to support only one interrupt controller if MCFICM_INTC1 is
not defined.
Signed-off-by: Philippe De Muyter p...@macqel.be
diff --git a/arch/m68knommu/platform/coldfire/intc-2.c
b/arch/m68knommu/platform/coldfire/intc-2.c
index a0c72ec..c23046c 100644
--- a/arch/m68knommu/platform/coldfire/intc-2.c
+++ b/arch/m68knommu/platform/coldfire/intc-2.c
@@ -1,9 +1,11 @@
/*
* intc-2.c
*
- * General interrupt controller code for the many ColdFire version 2 cores
- * that use the two region INTC interrupt controller. This includes the
- * 523x family, 5270, 5271, 5274, 5275, and the 528x families.
+ * General interrupt controller code for the many ColdFire cores that use
+ * interrupt controllers with 63 interrupt sources, organized as 56 fully-
+ * programmable + 7 fixed-level interrupt sources. This includes the 523x
+ * family, the 5270, 5271, 5274, 5275, and the 528x family which have two such
+ * controllers, and the 547x and 548x families which have only one of them.
*
* (C) Copyright 2009, Greg Ungerer g...@snapgear.com
*
@@ -23,21 +25,37 @@
#include asm/traps.h
/*
- * Each vector needs a unique priority and level asscoiated with it.
+ * Bit definitions for the ICR family of registers.
+ */
+#define MCFSIM_ICR_LEVEL(l)((l)3)/* Level l intr */
+#define MCFSIM_ICR_PRI(p) (p) /* Priority p intr */
+
+/*
+ * Each vector needs a unique priority and level associated with it.
* We don't really care so much what they are, we don't rely on the
- * tranditional priority interrupt scheme of the m68k/ColdFire.
+ * traditional priority interrupt scheme of the m68k/ColdFire.
*/
-static u8 intc_intpri = 0x36;
+static u8 intc_intpri = MCFSIM_ICR_LEVEL(6) | MCFSIM_ICR_PRI(6);
+
+#ifdef MCFICM_INTC1
+#define NR_VECS128
+#else
+#define NR_VECS64
+#endif
static void intc_irq_mask(unsigned int irq)
{
- if ((irq = MCFINT_VECBASE) (irq = MCFINT_VECBASE + 128)) {
+ if ((irq = MCFINT_VECBASE) (irq = MCFINT_VECBASE + NR_VECS)) {
unsigned long imraddr;
u32 val, imrbit;
irq -= MCFINT_VECBASE;
imraddr = MCF_IPSBAR;
+#ifdef MCFICM_INTC1
imraddr += (irq 0x40) ? MCFICM_INTC1 : MCFICM_INTC0;
+#else
+ imraddr += MCFICM_INTC0;
+#endif
imraddr += (irq 0x20) ? MCFINTC_IMRH : MCFINTC_IMRL;
imrbit = 0x1 (irq 0x1f);
@@ -48,13 +66,17 @@ static void intc_irq_mask(unsigned int irq)
static void intc_irq_unmask(unsigned int irq)
{
- if ((irq = MCFINT_VECBASE) (irq = MCFINT_VECBASE + 128)) {
+ if ((irq = MCFINT_VECBASE) (irq = MCFINT_VECBASE + NR_VECS)) {
unsigned long intaddr, imraddr, icraddr;
u32 val, imrbit;
irq -= MCFINT_VECBASE;
intaddr = MCF_IPSBAR;
+#ifdef MCFICM_INTC1
intaddr += (irq 0x40) ? MCFICM_INTC1 : MCFICM_INTC0;
+#else
+ intaddr += MCFICM_INTC0;
+#endif
imraddr = intaddr + ((irq 0x20) ? MCFINTC_IMRH :
MCFINTC_IMRL);
icraddr = intaddr + MCFINTC_ICR0 + (irq 0x3f);
imrbit = 0x1 (irq 0x1f);
@@ -85,7 +107,9 @@ void __init init_IRQ(void)
/* Mask all interrupt sources */
__raw_writel(0x1, MCF_IPSBAR + MCFICM_INTC0 + MCFINTC_IMRL);
+#ifdef MCFICM_INTC1
__raw_writel(0x1, MCF_IPSBAR + MCFICM_INTC1 + MCFINTC_IMRL);
+#endif
for (irq = 0; (irq NR_IRQS); irq++) {
irq_desc[irq].status = IRQ_DISABLED;
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH] m68knommu: intc-2.c: use symbolic constants for priority and level
Hi Greg, On Mon, Aug 30, 2010 at 11:52:33AM +1000, Greg Ungerer wrote: -static u8 intc_intpri = 0x36; +static u8 intc_intpri = 066; ^^^ Why change this to octal? Because it reflects the organisation of the ICRn registers : 2 bits unused 3 bits for level 3 bits for priority in level Do you want me to add a comment ? I think we should leave it the way it was :-) Irrespective of encoding most headers use hex to define bit fields. Grepping through arch/m68k/include/asm the only exception to this is termbits.h - and that is completely historical. Let's use symbolic constants then (apply on top of preceding patch) : Philippe --- Introduce new mcfintc-2.h file and use it in intc-2.c. Signed-off-by: Philippe De Muyter p...@macqel.be --- arch/m68k/include/asm/mcfintc-2.h | 47 + arch/m68knommu/platform/coldfire/intc-2.c |3 +- 2 files changed, 49 insertions(+), 1 deletions(-) create mode 100644 arch/m68k/include/asm/mcfintc-2.h diff --git a/arch/m68k/include/asm/mcfintc-2.h b/arch/m68k/include/asm/mcfintc-2.h new file mode 100644 index 000..ea5fd4f --- /dev/null +++ b/arch/m68k/include/asm/mcfintc-2.h @@ -0,0 +1,47 @@ +// + +/* + * mcfintc-2.h -- support definitions for the 63 interrupt sources + *ColdFire Interrupt Controller + * + * (C) Copyright 2010, Philippe De Muyter p...@macqel.be + */ + +// +#ifndefmcfintc_2_h +#definemcfintc_2_h +// + +/* + * Definitions for the many ColdFire cores that use interrupt controllers + * with 63 interrupt sources, organized as 56 fully-programmable + 7 + * fixed-level interrupt sources. This includes the 523x family, + * the 5270, 5271, 5274, 5275, and the 528x, 547x and 548x families. + */ + +/* + * Bit definitions for the ICR family of registers. + */ +#defineMCFSIM_ICR_LEVEL0 0x00/* Level 0 intr */ +#defineMCFSIM_ICR_LEVEL1 0x08/* Level 1 intr */ +#defineMCFSIM_ICR_LEVEL2 0x10/* Level 2 intr */ +#defineMCFSIM_ICR_LEVEL3 0x18/* Level 3 intr */ +#defineMCFSIM_ICR_LEVEL4 0x20/* Level 4 intr */ +#defineMCFSIM_ICR_LEVEL5 0x28/* Level 5 intr */ +#defineMCFSIM_ICR_LEVEL6 0x30/* Level 6 intr */ +#defineMCFSIM_ICR_LEVEL7 0x38/* Level 7 intr */ +#defineMCFSIM_ICR_LEVEL(l) ((l)3)/* Level l intr */ + +#defineMCFSIM_ICR_PRI0 0x00/* Priority 0 intr */ +#defineMCFSIM_ICR_PRI1 0x01/* Priority 1 intr */ +#defineMCFSIM_ICR_PRI2 0x02/* Priority 2 intr */ +#defineMCFSIM_ICR_PRI3 0x03/* Priority 3 intr */ +#defineMCFSIM_ICR_PRI4 0x04/* Priority 4 intr */ +#defineMCFSIM_ICR_PRI5 0x05/* Priority 5 intr */ +#defineMCFSIM_ICR_PRI6 0x06/* Priority 6 intr */ +#defineMCFSIM_ICR_PRI7 0x07/* Priority 7 intr */ +#defineMCFSIM_ICR_PRI(p) (p) /* Priority p intr */ + +// +#endif /* mcfintc_2_h */ diff --git a/arch/m68knommu/platform/coldfire/intc-2.c b/arch/m68knommu/platform/coldfire/intc-2.c index 060ff7b..c7b69fa 100644 --- a/arch/m68knommu/platform/coldfire/intc-2.c +++ b/arch/m68knommu/platform/coldfire/intc-2.c @@ -22,6 +22,7 @@ #include linux/io.h #include asm/coldfire.h #include asm/mcfsim.h +#include asm/intc-2.h #include asm/traps.h /* @@ -29,7 +30,7 @@ * We don't really care so much what they are, we don't rely on the * tranditional priority interrupt scheme of the m68k/ColdFire. */ -static u8 intc_intpri = 066; +static u8 intc_intpri = MCFSIM_ICR_LEVEL6 | MCFSIM_ICR_PRI6; #ifdef MCFICM_INTC1 #define NR_VECS128 -- 1.6.3.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] m68knommu: add support for Coldfire MCF547x/MCF548x interrupt controller.
On Fri, Aug 27, 2010 at 04:22:13PM +1000, Greg Ungerer wrote: Hi Philippe, Philippe De Muyter wrote: The Coldfire MCF547x/MCF548x have the same interrupt controller than the MCF528x, e.g., but only one, not two as in the MCF528x. Modify intc-2.c to support only one interrupt controller if MCFICM_INTC1 is not defined. Signed-off-by: Philippe De Muyter p...@macqel.be --- arch/m68knommu/platform/coldfire/intc-2.c | 30 +++- 1 files changed, 24 insertions(+), 6 deletions(-) diff --git a/arch/m68knommu/platform/coldfire/intc-2.c b/arch/m68knommu/platform/coldfire/intc-2.c index a0c72ec..060ff7b 100644 --- a/arch/m68knommu/platform/coldfire/intc-2.c +++ b/arch/m68knommu/platform/coldfire/intc-2.c @@ -1,9 +1,11 @@ /* * intc-2.c * - * General interrupt controller code for the many ColdFire version 2 cores - * that use the two region INTC interrupt controller. This includes the - * 523x family, 5270, 5271, 5274, 5275, and the 528x families. + * General interrupt controller code for the many ColdFire cores that use + * interrupt controllers with 63 interrupt sources, organized as 56 fully- + * programmable + 7 fixed-level interrupt sources. This includes the 523x + * family, the 5270, 5271, 5274, 5275, and the 528x family which have two such + * controllers, and the 547x and 548x families which have only one of them. * * (C) Copyright 2009, Greg Ungerer g...@snapgear.com * @@ -27,17 +29,27 @@ * We don't really care so much what they are, we don't rely on the * tranditional priority interrupt scheme of the m68k/ColdFire. */ -static u8 intc_intpri = 0x36; +static u8 intc_intpri = 066; ^^^ Why change this to octal? Because it reflects the organisation of the ICRn registers : 2 bits unused 3 bits for level 3 bits for priority in level Do you want me to add a comment ? Philippe -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH] m68knommu: add support for Coldfire MCF547x/MCF548x interrupt controller.
The Coldfire MCF547x/MCF548x have the same interrupt controller than
the MCF528x, e.g., but only one, not two as in the MCF528x. Modify
intc-2.c to support only one interrupt controller if MCFICM_INTC1 is
not defined.
Signed-off-by: Philippe De Muyter p...@macqel.be
---
arch/m68knommu/platform/coldfire/intc-2.c | 30 +++-
1 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/m68knommu/platform/coldfire/intc-2.c
b/arch/m68knommu/platform/coldfire/intc-2.c
index a0c72ec..060ff7b 100644
--- a/arch/m68knommu/platform/coldfire/intc-2.c
+++ b/arch/m68knommu/platform/coldfire/intc-2.c
@@ -1,9 +1,11 @@
/*
* intc-2.c
*
- * General interrupt controller code for the many ColdFire version 2 cores
- * that use the two region INTC interrupt controller. This includes the
- * 523x family, 5270, 5271, 5274, 5275, and the 528x families.
+ * General interrupt controller code for the many ColdFire cores that use
+ * interrupt controllers with 63 interrupt sources, organized as 56 fully-
+ * programmable + 7 fixed-level interrupt sources. This includes the 523x
+ * family, the 5270, 5271, 5274, 5275, and the 528x family which have two such
+ * controllers, and the 547x and 548x families which have only one of them.
*
* (C) Copyright 2009, Greg Ungerer g...@snapgear.com
*
@@ -27,17 +29,27 @@
* We don't really care so much what they are, we don't rely on the
* tranditional priority interrupt scheme of the m68k/ColdFire.
*/
-static u8 intc_intpri = 0x36;
+static u8 intc_intpri = 066;
+
+#ifdef MCFICM_INTC1
+#define NR_VECS128
+#else
+#define NR_VECS64
+#endif
static void intc_irq_mask(unsigned int irq)
{
- if ((irq = MCFINT_VECBASE) (irq = MCFINT_VECBASE + 128)) {
+ if ((irq = MCFINT_VECBASE) (irq = MCFINT_VECBASE + NR_VECS)) {
unsigned long imraddr;
u32 val, imrbit;
irq -= MCFINT_VECBASE;
imraddr = MCF_IPSBAR;
+#ifdef MCFICM_INTC1
imraddr += (irq 0x40) ? MCFICM_INTC1 : MCFICM_INTC0;
+#else
+ imraddr += MCFICM_INTC0;
+#endif
imraddr += (irq 0x20) ? MCFINTC_IMRH : MCFINTC_IMRL;
imrbit = 0x1 (irq 0x1f);
@@ -48,13 +60,17 @@ static void intc_irq_mask(unsigned int irq)
static void intc_irq_unmask(unsigned int irq)
{
- if ((irq = MCFINT_VECBASE) (irq = MCFINT_VECBASE + 128)) {
+ if ((irq = MCFINT_VECBASE) (irq = MCFINT_VECBASE + NR_VECS)) {
unsigned long intaddr, imraddr, icraddr;
u32 val, imrbit;
irq -= MCFINT_VECBASE;
intaddr = MCF_IPSBAR;
+#ifdef MCFICM_INTC1
intaddr += (irq 0x40) ? MCFICM_INTC1 : MCFICM_INTC0;
+#else
+ intaddr += MCFICM_INTC0;
+#endif
imraddr = intaddr + ((irq 0x20) ? MCFINTC_IMRH :
MCFINTC_IMRL);
icraddr = intaddr + MCFINTC_ICR0 + (irq 0x3f);
imrbit = 0x1 (irq 0x1f);
@@ -85,7 +101,9 @@ void __init init_IRQ(void)
/* Mask all interrupt sources */
__raw_writel(0x1, MCF_IPSBAR + MCFICM_INTC0 + MCFINTC_IMRL);
+#ifdef MCFICM_INTC1
__raw_writel(0x1, MCF_IPSBAR + MCFICM_INTC1 + MCFINTC_IMRL);
+#endif
for (irq = 0; (irq NR_IRQS); irq++) {
irq_desc[irq].status = IRQ_DISABLED;
--
1.6.3.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
[uClinux-dev] [PATCH] m68knommu: whitespace cleanup in 68328/entry.S
m68knommu: whitespace cleanup in 68328/entry.S Signed-off-by: Philippe De Muyter p...@macqel.be --- diff --git a/arch/m68knommu/platform/68328/entry.S b/arch/m68knommu/platform/68328/entry.S --- a/arch/m68knommu/platform/68328/entry.S +++ b/arch/m68knommu/platform/68328/entry.S @@ -43,7 +43,7 @@ badsys: jra ret_from_exception do_trace: - movel #-ENOSYS,%sp@(PT_OFF_D0)/* needed for strace*/ + movel #-ENOSYS,%sp@(PT_OFF_D0) /* needed for strace*/ subql #4,%sp SAVE_SWITCH_STACK jbsrsyscall_trace @@ -57,7 +57,7 @@ do_trace: lea sys_call_table, %a0 jbsr%a0@(%d1) -1: movel %d0,%sp@(PT_OFF_D0) /* save the return value */ +1: movel %d0,%sp@(PT_OFF_D0) /* save the return value */ subql #4,%sp /* dummy return address */ SAVE_SWITCH_STACK jbsrsyscall_trace @@ -71,9 +71,9 @@ ENTRY(system_call) SAVE_ALL /* save top of frame*/ - pea %sp@ - jbsrset_esp0 - addql #4,%sp + pea %sp@ + jbsrset_esp0 + addql #4,%sp movel %sp@(PT_OFF_ORIG_D0),%d0 @@ -88,10 +88,10 @@ ENTRY(system_call) lea sys_call_table,%a0 movel %a0@(%d0), %a0 jbsr%a0@ - movel %d0,%sp@(PT_OFF_D0) /* save the return value*/ + movel %d0,%sp@(PT_OFF_D0) /* save the return value*/ ret_from_exception: - btst#5,%sp@(PT_OFF_SR) /* check if returning to kernel*/ + btst#5,%sp@(PT_OFF_SR) /* check if returning to kernel*/ jeq Luser_return/* if so, skip resched, signals*/ Lkernel_return: ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH] m68k{nommu}/blackfin : remove old assembler-only flags bit definitions.
Long ago, PT_TRACESYS_OFF and friends were introduced as hard defines to avoid straight constants in assembler parts of linux m68k. They are not used anymore, and were not updated to follow changes in linux kernel. Remove them. When similar constants are needed, they are now generated using asm-offsets.c. Signed-off-by: Philippe De Muyter p...@macqel.be --- arch/blackfin/include/asm/entry.h |8 arch/m68k/include/asm/entry_mm.h |8 arch/m68k/include/asm/entry_no.h | 10 -- 3 files changed, 0 insertions(+), 26 deletions(-) diff --git a/arch/blackfin/include/asm/entry.h b/arch/blackfin/include/asm/entry.h index a6886f6..4104d57 100644 --- a/arch/blackfin/include/asm/entry.h +++ b/arch/blackfin/include/asm/entry.h @@ -15,14 +15,6 @@ #defineLFLUSH_I_AND_D 0x0808 #defineLSIGTRAP5 -/* process bits for task_struct.flags */ -#definePF_TRACESYS_OFF 3 -#definePF_TRACESYS_BIT 5 -#definePF_PTRACED_OFF 3 -#definePF_PTRACED_BIT 4 -#definePF_DTRACE_OFF 1 -#definePF_DTRACE_BIT 5 - /* * NOTE! The single-stepping code assumes that all interrupt handlers * start by saving SYSCFG on the stack with their first instruction. diff --git a/arch/m68k/include/asm/entry_mm.h b/arch/m68k/include/asm/entry_mm.h index 4741258..6f70823 100644 --- a/arch/m68k/include/asm/entry_mm.h +++ b/arch/m68k/include/asm/entry_mm.h @@ -47,14 +47,6 @@ LFLUSH_I_AND_D = 0x0808 -/* process bits for task_struct.ptrace */ -PT_TRACESYS_OFF = 3 -PT_TRACESYS_BIT = 1 -PT_PTRACED_OFF = 3 -PT_PTRACED_BIT = 0 -PT_DTRACE_OFF = 3 -PT_DTRACE_BIT = 2 - #define SAVE_ALL_INT save_all_int #define SAVE_ALL_SYS save_all_sys #define RESTORE_ALL restore_all diff --git a/arch/m68k/include/asm/entry_no.h b/arch/m68k/include/asm/entry_no.h index 907ed03..477d91a 100644 --- a/arch/m68k/include/asm/entry_no.h +++ b/arch/m68k/include/asm/entry_no.h @@ -32,16 +32,6 @@ #ifdef __ASSEMBLY__ -/* process bits for task_struct.flags */ -PF_TRACESYS_OFF = 3 -PF_TRACESYS_BIT = 5 -PF_PTRACED_OFF = 3 -PF_PTRACED_BIT = 4 -PF_DTRACE_OFF = 1 -PF_DTRACE_BIT = 5 - -LENOSYS = 38 - #define SWITCH_STACK_SIZE (6*4+4) /* Includes return address */ /* -- 1.6.3.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
[uClinux-dev] [PATCH] m68knommu: Document supported chips in intc-2.c and intc-simr.c.
The chips lists were in commit logs, but should also be in source files. This way it is easier to choose the right source file for a not yet supported Coldfire. Signed-off-by: Philippe De Muyter p...@macqel.be --- arch/m68knommu/platform/coldfire/intc-2.c|6 +- arch/m68knommu/platform/coldfire/intc-simr.c |2 ++ 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/arch/m68knommu/platform/coldfire/intc-2.c b/arch/m68knommu/platform/coldfire/intc-2.c index 5598c8b..a0c72ec 100644 --- a/arch/m68knommu/platform/coldfire/intc-2.c +++ b/arch/m68knommu/platform/coldfire/intc-2.c @@ -1,5 +1,9 @@ /* - * intc-1.c + * intc-2.c + * + * General interrupt controller code for the many ColdFire version 2 cores + * that use the two region INTC interrupt controller. This includes the + * 523x family, 5270, 5271, 5274, 5275, and the 528x families. * * (C) Copyright 2009, Greg Ungerer g...@snapgear.com * diff --git a/arch/m68knommu/platform/coldfire/intc-simr.c b/arch/m68knommu/platform/coldfire/intc-simr.c index 1b01e79..8435ced 100644 --- a/arch/m68knommu/platform/coldfire/intc-simr.c +++ b/arch/m68knommu/platform/coldfire/intc-simr.c @@ -1,6 +1,8 @@ /* * intc-simr.c * + * Interrupt controller code for the ColdFire 5208, 5207 532x parts. + * * (C) Copyright 2009, Greg Ungerer g...@snapgear.com * * This file is subject to the terms and conditions of the GNU General Public -- 1.6.3.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
[uClinux-dev] [PATCH] m68k{nommu} : Remove unused DEFINE's from asm-offsets.c
m68k{nommu}/asm-offsets.c define many constants which are not used
anymore anywhere; remove IRQ_DEVID, IRQ_HANDLER, IRQ_NEXT, STAT_IRQ,
TASK_ACTIVE_MM, TASK_BLOCKED, TASK_FLAGS, TASK_PTRACE, TASK_STATE,
TASK_THREAD_INFO, TI_CPU, TI_EXECDOMAIN and TI_TASK.
Signed-off-by: Philippe De Muyter p...@macqel.be
---
arch/m68k/kernel/asm-offsets.c | 12
arch/m68knommu/kernel/asm-offsets.c |9 -
2 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/arch/m68k/kernel/asm-offsets.c b/arch/m68k/kernel/asm-offsets.c
index 73e5e58..78e59b8 100644
--- a/arch/m68k/kernel/asm-offsets.c
+++ b/arch/m68k/kernel/asm-offsets.c
@@ -22,13 +22,9 @@
int main(void)
{
/* offsets into the task struct */
- DEFINE(TASK_STATE, offsetof(struct task_struct, state));
- DEFINE(TASK_FLAGS, offsetof(struct task_struct, flags));
- DEFINE(TASK_PTRACE, offsetof(struct task_struct, ptrace));
DEFINE(TASK_THREAD, offsetof(struct task_struct, thread));
DEFINE(TASK_INFO, offsetof(struct task_struct, thread.info));
DEFINE(TASK_MM, offsetof(struct task_struct, mm));
- DEFINE(TASK_ACTIVE_MM, offsetof(struct task_struct, active_mm));
#ifdef CONFIG_MMU
DEFINE(TASK_TINFO, offsetof(struct task_struct, thread.info));
#endif
@@ -64,14 +60,6 @@ int main(void)
/* bitfields are a bit difficult */
DEFINE(PT_OFF_FORMATVEC, offsetof(struct pt_regs, pc) + 4);
- /* offsets into the irq_handler struct */
- DEFINE(IRQ_HANDLER, offsetof(struct irq_node, handler));
- DEFINE(IRQ_DEVID, offsetof(struct irq_node, dev_id));
- DEFINE(IRQ_NEXT, offsetof(struct irq_node, next));
-
- /* offsets into the kernel_stat struct */
- DEFINE(STAT_IRQ, offsetof(struct kernel_stat, irqs));
-
/* offsets into the irq_cpustat_t struct */
DEFINE(CPUSTAT_SOFTIRQ_PENDING, offsetof(irq_cpustat_t,
__softirq_pending));
diff --git a/arch/m68knommu/kernel/asm-offsets.c
b/arch/m68knommu/kernel/asm-offsets.c
index 9a8876f..eca508c 100644
--- a/arch/m68knommu/kernel/asm-offsets.c
+++ b/arch/m68knommu/kernel/asm-offsets.c
@@ -21,14 +21,8 @@
int main(void)
{
/* offsets into the task struct */
- DEFINE(TASK_STATE, offsetof(struct task_struct, state));
- DEFINE(TASK_FLAGS, offsetof(struct task_struct, flags));
- DEFINE(TASK_PTRACE, offsetof(struct task_struct, ptrace));
- DEFINE(TASK_BLOCKED, offsetof(struct task_struct, blocked));
DEFINE(TASK_THREAD, offsetof(struct task_struct, thread));
- DEFINE(TASK_THREAD_INFO, offsetof(struct task_struct, stack));
DEFINE(TASK_MM, offsetof(struct task_struct, mm));
- DEFINE(TASK_ACTIVE_MM, offsetof(struct task_struct, active_mm));
/* offsets into the irq_cpustat_t struct */
DEFINE(CPUSTAT_SOFTIRQ_PENDING, offsetof(irq_cpustat_t,
__softirq_pending));
@@ -77,11 +71,8 @@ int main(void)
DEFINE(THREAD_SIZE, THREAD_SIZE);
/* Offsets in thread_info structure */
- DEFINE(TI_TASK, offsetof(struct thread_info, task));
- DEFINE(TI_EXECDOMAIN, offsetof(struct thread_info, exec_domain));
DEFINE(TI_FLAGS, offsetof(struct thread_info, flags));
DEFINE(TI_PREEMPTCOUNT, offsetof(struct thread_info, preempt_count));
- DEFINE(TI_CPU, offsetof(struct thread_info, cpu));
return 0;
}
--
1.6.3.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
[uClinux-dev] [PATCH] m68knommu : Fix strace support for 68328/68360
strace is enabled using the `flags' field of the `thread_info' struct. 68360 version of entry.S did test a wrong bit in a wrong structure (task_struct). 68328 version of entry.S did test the right bit in the right structure, but wrongly, because the `flags' field is 32 bit wide, while the used assembler insn (btst) only accesses a 8 bit byte in memory. Fix both using code already used in the coldfire version of entry.S Also fix some spaces/tabs issues. Signed-off-by: Philippe De Muyter p...@macqel.be --- arch/m68knommu/platform/68328/entry.S | 16 arch/m68knommu/platform/68360/entry.S |7 ++- 2 files changed, 14 insertions(+), 9 deletions(-) diff --git a/arch/m68knommu/platform/68328/entry.S b/arch/m68knommu/platform/68328/entry.S index 9d80d2c..74229f7 100644 --- a/arch/m68knommu/platform/68328/entry.S +++ b/arch/m68knommu/platform/68328/entry.S @@ -43,7 +43,7 @@ badsys: jra ret_from_exception do_trace: - movel #-ENOSYS,%sp@(PT_OFF_D0)/* needed for strace*/ + movel #-ENOSYS,%sp@(PT_OFF_D0) /* needed for strace*/ subql #4,%sp SAVE_SWITCH_STACK jbsrsyscall_trace @@ -57,7 +57,7 @@ do_trace: lea sys_call_table, %a0 jbsr%a0@(%d1) -1: movel %d0,%sp@(PT_OFF_D0) /* save the return value */ +1: movel %d0,%sp@(PT_OFF_D0) /* save the return value */ subql #4,%sp /* dummy return address */ SAVE_SWITCH_STACK jbsrsyscall_trace @@ -71,16 +71,16 @@ ENTRY(system_call) SAVE_ALL /* save top of frame*/ - pea %sp@ - jbsrset_esp0 - addql #4,%sp + pea %sp@ + jbsrset_esp0 + addql #4,%sp movel %sp@(PT_OFF_ORIG_D0),%d0 movel %sp,%d1 /* get thread_info pointer */ andl#-THREAD_SIZE,%d1 movel %d1,%a2 - btst#TIF_SYSCALL_TRACE,%a2@(TI_FLAGS) + btst#(TIF_SYSCALL_TRACE%8),%a2@(TI_FLAGS+(31-TIF_SYSCALL_TRACE)/8) jne do_trace cmpl#NR_syscalls,%d0 jcc badsys @@ -88,10 +88,10 @@ ENTRY(system_call) lea sys_call_table,%a0 movel %a0@(%d0), %a0 jbsr%a0@ - movel %d0,%sp@(PT_OFF_D0) /* save the return value*/ + movel %d0,%sp@(PT_OFF_D0) /* save the return value*/ ret_from_exception: - btst#5,%sp@(PT_OFF_SR) /* check if returning to kernel*/ + btst#5,%sp@(PT_OFF_SR) /* check if returning to kernel*/ jeq Luser_return/* if so, skip resched, signals*/ Lkernel_return: diff --git a/arch/m68knommu/platform/68360/entry.S b/arch/m68knommu/platform/68360/entry.S index 6d3460a..d5ad408 100644 --- a/arch/m68knommu/platform/68360/entry.S +++ b/arch/m68knommu/platform/68360/entry.S @@ -71,7 +71,12 @@ ENTRY(system_call) jbsrset_esp0 addql #4,%sp - btst#PF_TRACESYS_BIT,%a2@(TASK_FLAGS+PF_TRACESYS_OFF) + movel %sp@(PT_OFF_ORIG_D0),%d0 + + movel %sp,%d1 /* get thread_info pointer */ + andl#-THREAD_SIZE,%d1 + movel %d1,%a2 + btst#(TIF_SYSCALL_TRACE%8),%a2@(TI_FLAGS+(31-TIF_SYSCALL_TRACE)/8) jne do_trace cmpl#NR_syscalls,%d0 jcc badsys -- 1.6.3.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] m68knommu : Fix strace support for 68328/68360
On Tue, Aug 17, 2010 at 11:14:32AM -0400, Mike Frysinger wrote: unless i'm missing something, you're only changing whitespace here. That's true, and these account for more than half the patch. please keep whitespace changes separate from real changes. but that makes comparing the resulting files 68328/entry.S and 68360/entry.S easier. Philippe -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH] m68knommu : Fix strace support for 68328/68360
m68knommu : Fix strace support for 68328/68360 strace enabled is marked using the `flags' field of the `thread_info' struct. 68360 version of entry.S did test a wrong bit in a wrong structure (task_struct). 68328 version of entry.S did test the right bit in the right structure, but wrongly, because the `flags' field is 32 bit wide, while the used assembler insn (btst) only accesses a 8 bit byte in memory. Fix both using code already used in the coldfire version of entry.S Signed-off-by: Philippe De Muyter p...@macqel.be --- diff --git a/arch/m68knommu/platform/68328/entry.S b/arch/m68knommu/platform/68328/entry.S index 9d80d2c..74229f7 100644 --- a/arch/m68knommu/platform/68328/entry.S +++ b/arch/m68knommu/platform/68328/entry.S @@ -80,7 +80,7 @@ ENTRY(system_call) movel %sp,%d1 /* get thread_info pointer */ andl#-THREAD_SIZE,%d1 movel %d1,%a2 - btst#TIF_SYSCALL_TRACE,%a2@(TI_FLAGS) + btst#(TIF_SYSCALL_TRACE%8),%a2@(TI_FLAGS+(31-TIF_SYSCALL_TRACE)/8) jne do_trace cmpl#NR_syscalls,%d0 jcc badsys diff --git a/arch/m68knommu/platform/68360/entry.S b/arch/m68knommu/platform/68360/entry.S index 6d3460a..d5ad408 100644 --- a/arch/m68knommu/platform/68360/entry.S +++ b/arch/m68knommu/platform/68360/entry.S @@ -71,7 +71,12 @@ ENTRY(system_call) jbsrset_esp0 addql #4,%sp - btst#PF_TRACESYS_BIT,%a2@(TASK_FLAGS+PF_TRACESYS_OFF) + movel %sp@(PT_OFF_ORIG_D0),%d0 + + movel %sp,%d1 /* get thread_info pointer */ + andl#-THREAD_SIZE,%d1 + movel %d1,%a2 + btst#(TIF_SYSCALL_TRACE%8),%a2@(TI_FLAGS+(31-TIF_SYSCALL_TRACE)/8) jne do_trace cmpl#NR_syscalls,%d0 jcc badsys -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ 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] (no subject)
On Wed, Jun 23, 2010 at 11:00:59AM +0400, Кононов Андрей wrote: I succesfully compile the uclinux to get linux.bin and romfs.img. But when I looked at the linux.bin size, it's 2.5 GB! What did I do wrong? I think your text and data segement are at very different addresses, or your text segement is at high addresses. a binary file fills the gap with zeroes :( Philippe -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ 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] : Avoid filename TASK_SIZE test in do_getname() when no MMU
On Tue, May 25, 2010 at 12:20:47AM +0100, Jamie Lokier wrote: Philippe De Muyter wrote: On Mon, May 24, 2010 at 06:26:08PM +0100, Jamie Lokier wrote: Philippe De Muyter wrote: On Mon, May 24, 2010 at 04:59:18PM +0100, David Howells wrote: Philippe De Muyter p...@macqel.be wrote: +#else +#define TASK_SIZE(0xUL) +#endif Because of do_getname() : len = TASK_SIZE - (unsigned long) filename; we should rather have #define TASK_SIZE (0x1ull) Do you guarantee that will work everywhere on a 32-bit system, though? Note that it also makes things slower as gcc has to start using 64-bit arithmetic where it could otherwise use 32-bit arithmetic. Except if gcc notices that this simplifies to len = (unsigned long)(-filename); I don't know if it does. It did simplify on the x86 (gcc 4.4) and ARM (gcc 3.4.3) tests I just did. Also the comparison addr TASK_SIZE simplified to 1. However I can imagine some logic like this going awry with that definition: if (addr = TASK_SIZE || len TASK_SIZE - addr) return -EINVAL; Think about the case addr == 0. It would give ( 0 || len (unsigned long)(-addr)) Sorry. I should not have answered that late. Of course, for (addr == 0), it would give ( 0 || len TASK_SIZE) and hence ( 0 || 0) I don't see a problem there. The problem is it would return -EINVAL for any non-zero value of len, which isn't what the code looks like it's meant to do. No, see above. Of course, if one computes the maximum len (TASK_SIZE - addr) separately and stores it in a unsigned 32bit, then there is a design error in the program. Philippe -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ 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] : Avoid filename TASK_SIZE test in do_getname() when no MMU
Hi Greg, On Tue, May 25, 2010 at 11:19:43AM +1000, Greg Ungerer wrote: Hi Philippe, Philippe De Muyter wrote: On Mon, May 24, 2010 at 11:29:50AM +1000, Greg Ungerer wrote: [...] +#else +#define TASK_SIZE (0xUL) +#endif Because of do_getname() : len = TASK_SIZE - (unsigned long) filename; we should rather have #define TASK_SIZE (0x1ull) I see what you mean. But in practice here I don't think it matters. Can no process have its stack allocated in the last block, and hence have some argv[i] put in the last addresses, with the terminating '\0' at 0x ? Philippe -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ 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] : Avoid filename TASK_SIZE test in do_getname() when no MMU
On Mon, May 24, 2010 at 11:29:50AM +1000, Greg Ungerer wrote: [...] +#else +#define TASK_SIZE(0xUL) +#endif Because of do_getname() : len = TASK_SIZE - (unsigned long) filename; we should rather have #define TASK_SIZE (0x1ull) Philippe -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ 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] : Avoid filename TASK_SIZE test in do_getname() when no MMU
On Mon, May 24, 2010 at 04:59:18PM +0100, David Howells wrote: Philippe De Muyter p...@macqel.be wrote: +#else +#define TASK_SIZE(0xUL) +#endif Because of do_getname() : len = TASK_SIZE - (unsigned long) filename; we should rather have #define TASK_SIZE (0x1ull) Do you guarantee that will work everywhere on a 32-bit system, though? Note that it also makes things slower as gcc has to start using 64-bit arithmetic where it could otherwise use 32-bit arithmetic. Except if gcc notices that this simplifies to len = (unsigned long)(-filename); I don't know if it does. Philippe -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ 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] : Avoid filename TASK_SIZE test in do_getname() when no MMU
On Mon, May 24, 2010 at 06:26:08PM +0100, Jamie Lokier wrote: Philippe De Muyter wrote: On Mon, May 24, 2010 at 04:59:18PM +0100, David Howells wrote: Philippe De Muyter p...@macqel.be wrote: +#else +#define TASK_SIZE(0xUL) +#endif Because of do_getname() : len = TASK_SIZE - (unsigned long) filename; we should rather have #define TASK_SIZE (0x1ull) Do you guarantee that will work everywhere on a 32-bit system, though? Note that it also makes things slower as gcc has to start using 64-bit arithmetic where it could otherwise use 32-bit arithmetic. Except if gcc notices that this simplifies to len = (unsigned long)(-filename); I don't know if it does. It did simplify on the x86 (gcc 4.4) and ARM (gcc 3.4.3) tests I just did. Also the comparison addr TASK_SIZE simplified to 1. However I can imagine some logic like this going awry with that definition: if (addr = TASK_SIZE || len TASK_SIZE - addr) return -EINVAL; Think about the case addr == 0. It would give ( 0 || len (unsigned long)(-addr)) I don't see a problem there. I would really rather all uses of TASK_SIZE in generic kernel code were changed to a TASK_SIZE_CHECK macro or something like that. There aren't all that many places where TASK_SIZE is used in generic code (that isn't MMU specific). TASK_SIZE is the wrong kind of check on no-MMU: A better check is that the address is within the userspace mappable address range, whatever that is, which may start at some value and end at some other value, and may have holes. That's the is_in_task_area() helper that Geert suggested. I agree that's the way to go. Philippe -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ 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 m68knommu] Improve short help of m68knommu/Kconfig/RAMSIZE for '0' case
On Fri, May 21, 2010 at 08:01:29AM +0200, Geert Uytterhoeven wrote: On Fri, May 21, 2010 at 07:49, Greg Ungerer g...@snapgear.com wrote: Philippe De Muyter wrote: While it is explained in the long help text, meaning of '0' for RAMSIZE is easily overlooked because is not mentionned in the short help text. Add that. I am reluctant to change that string to something so long. When running menuconfig for example on a normal 80 column window the end is chopped of. I much prefer brief strings in the prompt line. ... or auto-detect? Besides, bootloader-based autodetection is not the same as try to probe the RAM size at runtime. try to probe the RAM size at runtime is the goal, bootloader-based autodetection is the way it is implemented :) Philippe -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH] : Avoid filename TASK_SIZE test in do_getname() when no MMU
Hi Greg,
--
Avoid filename TASK_SIZE test in do_getname() when no MMU.
Without MMU, filenames can be anywhere in memory. It is thus wrong to
check that filename is before TASK_SIZE in do_getname().
Signed-off-by: Philippe De Muyter p...@macqel.be
---
fs/namei.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index b86b96f..658bc1d 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -119,12 +119,14 @@ static int do_getname(const char __user *filename, char
*page)
int retval;
unsigned long len = PATH_MAX;
+#ifdef CONFIG_MMU
if (!segment_eq(get_fs(), KERNEL_DS)) {
if ((unsigned long) filename = TASK_SIZE)
return -EFAULT;
if (TASK_SIZE - (unsigned long) filename PATH_MAX)
len = TASK_SIZE - (unsigned long) filename;
}
+#endif
retval = strncpy_from_user(page, filename, len);
if (retval 0) {
--
Philippe De Muyter phdm at macqel dot be Tel +32 27029044
Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH m68knommu] Improve short help of m68knommu/Kconfig/RAMSIZE for '0' case
Hello Greg, -- While it is explained in the long help text, meaning of '0' for RAMSIZE is easily overlooked because is not mentionned in the short help text. Add that. Signed-off-by: Philippe De Muyter p...@macqel.be --- arch/m68knommu/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/m68knommu/Kconfig b/arch/m68knommu/Kconfig index 064f591..af57ec1 100644 --- a/arch/m68knommu/Kconfig +++ b/arch/m68knommu/Kconfig @@ -566,7 +566,7 @@ config RAMBASE processor address space. config RAMSIZE - hex Size of RAM (in bytes) + hex Size of RAM (in bytes), or 0 for bootloader-based autodetection default 0x40 help Define the size of the system RAM. If you select 0 then the -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ 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] Timekeeping problem: time runs too fast
I have an other question concerning the macro CLOCK_TICK_RATE (include/asm-'arch-name'/timex.h): this macro seems to be architecture dependant. It's generally 1193180. What is this macro used for? For ntp-based time synchronisation. What value should I give to it? CLOCK_TICK_RATE should give the underlying frequency of the tick timer. i.e. the frequency of the hardware input clock of your tick timer Philippe -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ 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] Newbe NOMMU question.
On Wed, Apr 21, 2010 at 04:57:40PM +0100, Jamie Lokier wrote: Jeff Bacon wrote: On 4/21/2010 11:04 AM, Lennart Sorensen wrote: What version of Busybox are you using? I am finding it difficult to make a newer version (1.15.x, 1.16.0) that small. In fact, when I configure it with a single applet, I still somehow get a ~200kB binary. Are there other options you are using in the build process to make your BB binary so small? You don't have to have just one busybox binary containing everything. Ideally, one should have only one XIP (thus shared) busybox with zero-sized data and bss segments (rodata is allowed but moved into text segment). Then each new process needs only to allocate a stack + heap if needed. Philippe ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH ld-elf2flt] unlink temporary linker scripts
Hello Greg, Everytime I recompile uClinux-dist for m68k using the uclinux-tools-20080626 toolchain, my /tmp directory is filled with a new bunch of flt-XX files, which are not unlinked after usage. Here is a fix Philippe --- m68k-uclinux-elf2flt/ld-elf2flt.original2010-04-13 09:57:38.513180832 +0200 +++ m68k-uclinux-elf2flt/ld-elf2flt 2010-04-13 10:10:14.150179220 +0200 @@ -92,6 +92,7 @@ [ $VERBOSE = y ] set -x ARG1=$ARG1 $FINAL_ONLY NEWLDSCRIPT=`mktemp /tmp/flt-XX` + trap rm -f $NEWLDSCRIPT 0 SEDOP= -e s/^R_RODAT// -e /^W_RODAT/d if [ $MOVDAT ] then -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ 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 memory problem!
On Tue, Apr 13, 2010 at 02:47:55PM +0200, Alessandro Guerra wrote: Hi Fabio, I'm using the board COBRA5329 from senTec. For such a board, GET_MEM_SIZE in arch/m68knommu/platform/coldfire/head.S should find the mem size automatically if configured to do so. You must maybe add a #ifdef for your processor type. Philippe -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ 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] Does any of you made an rs485 driver starting from uart?
On Wed, Apr 07, 2010 at 02:59:03PM +0200, Erwin Authried wrote: I have just discovered that there are now 'standard' linux ioctls to work with rs485 lines : TIOCGRS485 TIOCSRS485. (see http://git.kernel.org/?p=linux/kernel/git/gerg/m68knommu.git;a=commitdiff;h=c26c56c0f40e200e61d1390629c806f6adaffbcc) Of course, not all hardware drivers implement them. And also, I do not know how to use them. Philippe I found this example that seems to use those new ioctls: http://foxlx.acmesystems.it/?id=28 If you look into this example, it doesn't look promising because RTS is released by a call from userspace after sending. I can't see much advantage over using tcdrain() and releasing RTS afterwards, if tx_empty is implemented correctly by the serial driver. This example seems closer (at least the name of the ioctl, and some fields in the struct) and more promising : http://wiki.myigep.com/trac/wiki/HowToUseRS485 Philippe -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH] : fix inetd.conf for busybox's inetd
Hello Greg, This complements my recent patch. When using busybox's inetd and telnetd in conjunction, inetd.conf must contain an 'arg0' field. This is not needed either for standalone inetd with busybox's telnetd or for busybox's inetd with standalone telnetd, but by chance or by design, it does work also. Philippe diff -r 32d9ad41adba user/busybox/install-romfs.sh --- a/user/busybox/install-romfs.sh Thu Mar 18 11:26:13 2010 +0100 +++ b/user/busybox/install-romfs.sh Fri Mar 19 11:49:59 2010 +0100 @@ -79,6 +79,6 @@ done romfs-inst.sh -e CONFIG_USER_BUSYBOX_TELNETD \ - -a telnet stream tcp nowait root /bin/telnetd /etc/inetd.conf + -a telnet stream tcp nowait root /bin/telnetd telnetd /etc/inetd.conf exit 0 ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH serial/mcf] Allow 4 ports
Hello Greg, -- Fix driver/serial/mcf.c for 4-ports coldfire's (e.g. MCF5484). Signed-off-by: Philippe De Muyter p...@macqel.be diff -r 32d9ad41adba linux-2.6.x/drivers/serial/mcf.c --- a/linux-2.6.x/drivers/serial/mcf.c Thu Mar 18 11:26:13 2010 +0100 +++ b/linux-2.6.x/drivers/serial/mcf.c Thu Mar 18 11:28:45 2010 +0100 @@ -443,7 +445,7 @@ .verify_port= mcf_verify_port, }; -static struct mcf_uart mcf_ports[3]; +static struct mcf_uart mcf_ports[4]; #defineMCF_MAXPORTSARRAY_SIZE(mcf_ports) ___ 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: [PATCH v2] m68knommu: driver for Freescale Coldfire I2C controller.
Hello all, On Mon, Jan 25, 2010 at 11:56:30AM -0800, Steven King wrote: Add support for the I2C controller used on Freescale/Motorola Coldfire MCUs. Signed-off-by: Steven King sfk...@fdwdc.com What's the status of this ? I need to use i2c for a coldfire uclinux project (with a mcf5484) and I now have 3 different coldfire i2c drivers, none of which is in mainline. i2c-mcf.c (from uClinux-dist-20090618, but not in http://git.kernel.org/?p=linux/kernel/git/gerg/m68knommu.git;a=summary) i2c-mcf548x.c (from ltib-m5475evb-20080808, found as Linux BSP for MCF5484LITE, MCF5475/85EVB at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MCF548Xfpsp=1tab=Design_Tools_Tab) i2c-coldfire.c (from http://lkml.org/lkml/2010/1/11/165) I like to work with mainline sources to be be able to contribute to and benefit from collective work. Which one has the best chances to be put in mainline ? Best regards Philippe ___ 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] Disk Cache overlaying Shared Memory?
On Wed, Jan 27, 2010 at 05:26:25PM -0600, John B Moore wrote: This bug has been found and fixed. The issue was a missing SetPageDirty in ramfs_nommu_expand_for_mapping in fs/ramfs/file-nommu.c. This allowed the ramfs shared memory storage to be considered for being freed from the pagecache in shrink_active_list . This problem appears to have been fixed in later releases in the ramfs driver since the newer driver already has the SetPageDirty call added, but just in case someone else runs into this What's the patch actually ? Philippe ___ 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] ltib vs uclinux-dist
On Wed, Sep 02, 2009 at 10:20:36PM +1000, Greg Ungerer wrote: The arch trees of m68k and m68knommu have different structures. What will the structure of the merged tree look like ? I haven't given that too much thought yet. Most likely it would follow the m68k model, since it is essentially the m68knommu code and support being merged into it. Would you suppress the `platform' level ? Philippe ___ 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] ltib vs uclinux-dist
On Tue, Sep 01, 2009 at 08:22:37AM +0200, Alexander Stein wrote: Hello, Am Friday 14 August 2009 13:22:59 schrieb Philippe De Muyter: After reading this : http://rtg.informatik.tu-chemnitz.de/docs/da-sa-txt/sa-steal.pdf I don't feel anymore it is interesting. I'm the author of this document and as far as I know, Freescale has merged some of the change we made coresponding to my paper. But I don't have any IIRC, systec's name comes in some files distributed with the M5484lite develpoment board. but these are patches against linux-2.6.25 that do not apply anymore to the current version of linux kernel, and I see no sign of ongoing work to merge them into the current kernel. Kurt Mahan sent even some bad news from the freescale team. There is also the problem of the m68knommu/m68k merge : all the coldfire ports are currently in m68knommu, but the m547x/m548x port is in m68k, leading to some code duplication. hint about the current performance as we still use the old code base. Nevertheless I would be interested about current performance values. I prefer to work with mainstream kernel, so I don't think I'll test the freescale port, sorry. I'd be glad. though, to help pushing or push myself a M548x port (perhaps MMU-less) to the current kernel. Best regards Philippe ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] uclinux-dist on Freescale M5475EVB
Hi Greg, On Tue, Aug 18, 2009 at 11:06:13PM +1000, Greg Ungerer wrote: I had uClinux running on the Freescale ColdFire M5475 dev board a few year back. I have a M5484EVB (which I think is very similar to a M5475EVB), and thus compiled uclinux-dist-20090810 for the Freescale M5475EVB target. I also installed dbug on my dev board (which comes with U-boot) because linux seemed to be compiled for dbug-compatible addresses. I try dn image.bin# works fine go 2# no sign of life anymore Does uclinux-dist really contain a working M5475EVB port ? Philippe ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] uclinux-dist on Freescale M5475EVB
Hello Timothée, On Tue, Aug 25, 2009 at 05:47:59PM +0200, Timothée Manaud wrote: Can you make sure the serial terminal is enabled and the port speed is fine? As the D-Bug default is 19200. Device Drivers Character devices Serial drivers Coldfire serial support (new style driver) Default baudrate for Coldfire serial ports: 19200 Yes. Except is not called anymore '(new style driver)' Problem seems to be more fundamental : the offset of the UARTs (called PSCs on MCF547x/MCF548x) in the SIU are wrong, the interrupt controller is different, and maybe more :( Philippe ___ 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] m68k-elf-tools-20061214 incompatible with current linux kernel
Hi Greg,
On Thu, Aug 20, 2009 at 03:26:46PM +1000, Greg Ungerer wrote:
Source here:
http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20080626/
Trying to build that fails with :
STAGE 5 - needs building
cp: cannot stat
`/archives/m68kdev/uclinux-tools-20080626/gcc-4.2.4/../t-uclinux': No such file
or directory
It comes from the following lines in build-uclinux-tools.sh :
cp ${GCC}/../t-uclinux ${GCC}/gcc/config/${_CPU}/t-uclinux
cp ${GCC}/../uclinux.h ${GCC}/gcc/config/${_CPU}/uclinux.h
Philippe
___
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] m68k-elf-tools-20061214 incompatible with current linux kernel
On Thu, Aug 20, 2009 at 03:26:46PM +1000, Greg Ungerer wrote: Hi Philippe, Philippe De Muyter wrote: Does someone have a newer build-uclinux-tools.sh that (s)he can share, or at least recommend some newer versions of gcc and binutils ? The other option is to use the code sourcery toolchains. I prefer using tools that I recompile myself :) clfs could perhaps also be interesting, but they do not provide a one file script, only a collection of well-documented commands. Philippe ___ 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] m68k-elf-tools-20061214 incompatible with current linux kernel
Hello remote friends, starting with a new embedded linux project, I just installed the latest versions of m68k-elf-tools (20061214) and uclinux-dist (20090810). I succesfully compiled m68k-elf-tools, but compiling the linux-2.6.x kernel from uclinux-dist fails with : include/linux/compiler-gcc4.h:8:4: error: #error Your version of gcc miscompiles the __weak directive Does someone have a newer build-uclinux-tools.sh that (s)he can share, or at least recommend some newer versions of gcc and binutils ? Thanks in advance Philippe ___ 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] ltib vs uclinux-dist
On Thu, Aug 13, 2009 at 08:37:07AM +0100, Stuart Hughes wrote: Hi Philippe, I maintain LTIB (the tool). Generally speaking for MMUless platforms I'd recommend using uClinux-dist. However if LTIB has the exact platform you're interested in that may be helpful as it will be known to work out of the box. The compiler used in LTIB should work with uClinux-dist notwithstanding some gcc strictness issues (depends on version). You may also find some of the patches to the kernel that are not yet in mainstream may be useful. For platforms with MMUs I'd recommend LTIB though (no surprise there). The MCF5484 has a MMU, but linux-2.6.30 (even in uclinux-dist flavour) does not seem to use it : I grep'ped for mmubar in the whole source tree without result. Does the ltib-provided kernel use the mmu ? And if that's the case, is there an ongoing effort to merge those mmu patches in the uclinux- or Linus' kernel tree ? Philippe ___ 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] ltib vs uclinux-dist
Hi all, I need to install (uc)linux on a in-house designed MCF5484-based board. I feel comfortable with uc-linux dist, having used it before on m68340 and mcf5272 based boards. I now saw that the MCF5484 development board from freescale comes with ltib. - What's the relation between uclinux-dist and ltib, if any ? - Can I use the compiler provided by ltib to compile uclinux-dist ? Thanks in advance ? Philippe ___ 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] m68k: restore lost coldfire CLOCK_TICK_RATE
On Wed, Aug 12, 2009 at 04:42:27PM +1000, Greg Ungerer wrote: Hi Philippe, Philippe De Muyter wrote: The good definition of CLOCK_TICK_RATE for coldfires has been lost in the merge of m68k and m68knommu include files. Restore it. Culprit : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ebafc17468d58bd903c886175ca84a4edc69ae1d;hp=34055b806a6334624e7e8af6eefc3aee42372a85 Signed-off-by: Philippe De Muyter p...@macqel.be I have added this to the for-linus branch at git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git. Thanks Greg Thanks, Greg Philippe ___ 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] m68k: restore lost coldfire CLOCK_TICK_RATE
Hi Greg, On Mon, Jun 22, 2009 at 01:18:55PM +1000, Greg Ungerer wrote: HI Philippe, Philippe De Muyter wrote: Hello list, The good definition of CLOCK_TICK_RATE for coldfires has been lost in the merge of m68k and m68knommu include files. Restore it. Culprit : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ebafc17468d58bd903c886175ca84a4edc69ae1d;hp=34055b806a6334624e7e8af6eefc3aee42372a85 Signed-off-by: Philippe De Muyter p...@macqel.be Is it needed? What is broken with the existing value? I am no ntp expert, but IIRC kernel/time/ntp.c needs to know the remainder of CLOCK_TICK_RATE / HZ to obtain a good stability of the time. That's probably only needed when you have ntpd running. Philippe ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH] m68k: restore lost coldfire CLOCK_TICK_RATE
Hello list, The good definition of CLOCK_TICK_RATE for coldfires has been lost in the merge of m68k and m68knommu include files. Restore it. Culprit : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ebafc17468d58bd903c886175ca84a4edc69ae1d;hp=34055b806a6334624e7e8af6eefc3aee42372a85 Signed-off-by: Philippe De Muyter p...@macqel.be diff -r 8dcc271a81a8 arch/m68k/include/asm/timex.h --- a/arch/m68k/include/asm/timex.h Thu Jun 18 14:07:46 2009 -0700 +++ b/arch/m68k/include/asm/timex.h Sat Jun 20 21:46:25 2009 +0200 @@ -3,10 +3,23 @@ * * m68k architecture timex specifications */ -#ifndef _ASMm68k_TIMEX_H -#define _ASMm68k_TIMEX_H +#ifndef _ASMm68K_TIMEX_H +#define _ASMm68K_TIMEX_H +#ifdef CONFIG_COLDFIRE +/* + * CLOCK_TICK_RATE should give the underlying frequency of the tick timer + * to make ntp work best. For Coldfires, that's the main clock. + */ +#include asm/coldfire.h +#define CLOCK_TICK_RATEMCF_CLK +#else +/* + * This default CLOCK_TICK_RATE is probably wrong for many 68k boards + * Users of those boards will need to check and modify accordingly + */ #define CLOCK_TICK_RATE1193180 /* Underlying HZ */ +#endif typedef unsigned long cycles_t; ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH] m68knommu: init coldfire timer TRR with n - 1, not n
Hello everybody, The coldfire timer must be initialised to n - 1 if we want it to count n cycles between each tick interrupt. This was already fixed, but has been lost with the conversion to GENERIC_TIMER. Signed-off-by: Philippe De Muyter [EMAIL PROTECTED] diff -r 184e1bb486cf arch/m68knommu/platform/coldfire/timers.c --- a/arch/m68knommu/platform/coldfire/timers.c Mon Jun 9 19:30:13 2008 -0700 +++ b/arch/m68knommu/platform/coldfire/timers.c Tue Jun 10 13:25:22 2008 +0200 @@ -111,7 +111,13 @@ void hw_timer_init(void) __raw_writew(MCFTIMER_TMR_DISABLE, TA(MCFTIMER_TMR)); mcftmr_cycles_per_jiffy = FREQ / HZ; - __raw_writetrr(mcftmr_cycles_per_jiffy, TA(MCFTIMER_TRR)); + /* +* The coldfire timer runs from 0 to TRR included, then 0 +* again and so on. It counts thus actually TRR + 1 steps +* for 1 tick, not TRR. So if you want n cycles, +* initialize TRR with n - 1. +*/ + __raw_writetrr(mcftmr_cycles_per_jiffy - 1, TA(MCFTIMER_TRR)); __raw_writew(MCFTIMER_TMR_ENORI | MCFTIMER_TMR_CLK16 | MCFTIMER_TMR_RESTART | MCFTIMER_TMR_ENABLE, TA(MCFTIMER_TMR)); ___ 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] Hint needed : how to debug sempahore's problem
Hi all, Can someone give me some hint or link for the following question : I have several processes blocked in 'D' state, and I surmise they are waiting for a semaphore (in the `down' routine). How is it possible : - to verify the processes are really blocked on a semaphore, - to see which semaphore they are waiting on, - to find out which process/driver/whatever holds those semaphores. If that matters, I work on a m68k board. Thanks in advance Philippe ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH] typo in 5272 DMA constant
Hi Greg, Fix a small typo in the definition of MCFDMA_DIR_INV (MCF5272 specific) Philippe diff -r bc1b4169da23 include/asm-m68knommu/mcfdma.h --- a/include/asm-m68knommu/mcfdma.hTue Jun 5 02:02:41 2007 + +++ b/include/asm-m68knommu/mcfdma.hWed Jun 6 13:35:47 2007 +0200 @@ -133,7 +133,7 @@ #define MCFDMA_DIR_ASCEN 0x0800 /* Address Sequence Complete (Completion) interrupt enable */ #define MCFDMA_DIR_TEEN 0x0200 /* Transfer Error interrupt enable */ #define MCFDMA_DIR_TCEN 0x0100 /* Transfer Complete (a bus transfer, that is) interrupt enable */ -#define MCFDMA_DIR_INV 0x1000 /* Invalid Combination */ +#define MCFDMA_DIR_INV 0x0010 /* Invalid Combination */ #define MCFDMA_DIR_ASC 0x0008 /* Address Sequence Complete (DMA Completion) */ #define MCFDMA_DIR_TE0x0002 /* Transfer Error */ #define MCFDMA_DIR_TC0x0001 /* Transfer Complete */ ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH] Fix coldfire timer initialisation
Greg Ungerer wrote: Looking at this isn't it mis-handling the case where the TCN reads back as the maximal count (so ticks_per_intr in this case). Well thought :) My understanding is that could occur after it has clocked over to the maximal count value, and after we have serviced the timer interrupt that it will generate (assuming the interrupt was serviced quickly enough). Actually, as we initialize the timer with MCFTIMER_TMR_CLK16, tcn will give back the same value during 16 cycles. The interrupt should thus be faster than 16 cycles for this case to happen. SAVE_ALL+RESTORE_ALL and even SAVE_LOCAL+RESTORE_LOCAL are slower than that (rte alone already takes 10 cycles on MCF5272), so I think that this case can not happen. Agreed, I doubt the interrupt could be that quick. The case on the otherside can happen. Agreed. That is the count reaches the maximal count after locking but before we read the TCN register. So we want that to be correct (which I think your code is). Not only mine :) The previous one was also correct for that. I'll apply as it was. Thanks Philippe ___ 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
