Re: [uClinux-dev] [PATCH 21/22] m68knommu: simplify the ColdFire 532x GPIO struct setup
Maybe Alex is registered twice. I received only the 23 mails that Greg
mentions.
It's good to see that uCLinux is still alive and kicking :)
Johan.
-Original Message-
From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org]
On Behalf Of Greg Ungerer
Sent: donderdag 26 april 2012 3:08
To: Alex LI
Cc: mohamed nabil; linux-m...@vger.kernel.org; uClinux development list; Greg
Ungerer
Subject: Re: [uClinux-dev] [PATCH 21/22] m68knommu: simplify the ColdFire 532x
GPIO struct setup
Hi Alex,
On 04/26/2012 10:53 AM, Alex LI wrote:
You sent 50 mails in 1 min.
I sent 23. And both list archives (linux-m68k and uclinux-dev) only show the 23
emails.
Maybe the uclinux-dev reflecter is sending dupes to list recpients?
Regards
Greg
Sent from my Sony Ericsson Xperia arc S
Greg Ungererg...@snapgear.com ?:
On 04/26/2012 10:36 AM, mohamed nabil wrote:
that's a Fucking spam man !!
Huh?
Thats how open source development works. If you don't like it don't
subscribe to a developers list.
Regards
Greg
On Thu, Apr 26, 2012 at 2:26 AM,g...@snapgear.com
mailto:g...@snapgear.com wrote:
From: Greg Ungererg...@uclinux.orgmailto:g...@uclinux.org
The GPIO data struct setup is now the only remaining code in the
platform
gpio.c file. So move it to the platform config.c code and remove the
gpio.c
file.
Signed-off-by: Greg Ungererg...@uclinux.orgmailto:g...@uclinux.org
---
arch/m68k/platform/532x/Makefile |2 +-
arch/m68k/platform/532x/config.c | 25 ++
arch/m68k/platform/532x/gpio.c | 43
--
3 files changed, 26 insertions(+), 44 deletions(-)
delete mode 100644 arch/m68k/platform/532x/gpio.c
diff --git a/arch/m68k/platform/532x/Makefile
b/arch/m68k/platform/532x/Makefile
index ce01669..c0d8cf8 100644
--- a/arch/m68k/platform/532x/Makefile
+++ b/arch/m68k/platform/532x/Makefile
@@ -15,4 +15,4 @@
asflags-$(CONFIG_FULLDEBUG) := -DDEBUGGER_COMPATIBLE_CACHE=1
#obj-y := config.o usb-mcf532x.o spi-mcf532x.o
-obj-y := config.o gpio.o
+obj-y := config.o
diff --git a/arch/m68k/platform/532x/config.c
b/arch/m68k/platform/532x/config.c
index 2bec347..a4dd3d8 100644
--- a/arch/m68k/platform/532x/config.c
+++ b/arch/m68k/platform/532x/config.c
@@ -26,10 +26,35 @@
#includeasm/mcfsim.h
#includeasm/mcfuart.h
#includeasm/mcfdma.h
+#includeasm/mcfgpio.h
#includeasm/mcfwdebug.h
/***
/
+struct mcf_gpio_chip mcf_gpio_chips[] = {
+ MCFGPS(PIRQ, 0, 8, MCFEPORT_EPDDR, MCFEPORT_EPDR,
MCFEPORT_EPPDR),
+ MCFGPF(FECH, 8, 8),
+ MCFGPF(FECL, 16, 8),
+ MCFGPF(SSI, 24, 5),
+ MCFGPF(BUSCTL, 32, 4),
+ MCFGPF(BE, 40, 4),
+ MCFGPF(CS, 49, 5),
+ MCFGPF(PWM, 58, 4),
+ MCFGPF(FECI2C, 64, 4),
+ MCFGPF(UART, 72, 8),
+ MCFGPF(QSPI, 80, 6),
+ MCFGPF(TIMER, 88, 4),
+ MCFGPF(LCDDATAH, 96, 2),
+ MCFGPF(LCDDATAM, 104, 8),
+ MCFGPF(LCDDATAL, 112, 8),
+ MCFGPF(LCDCTLH, 120, 1),
+ MCFGPF(LCDCTLL, 128, 8),
+};
+
+unsigned int mcf_gpio_chips_size = ARRAY_SIZE(mcf_gpio_chips);
+
+/***/
+
#ifdef CONFIG_SPI_COLDFIRE_QSPI
static void __init m532x_qspi_init(void)
diff --git a/arch/m68k/platform/532x/gpio.c
b/arch/m68k/platform/532x/gpio.c
deleted file mode 100644
index 3e1b71d..000
--- a/arch/m68k/platform/532x/gpio.c
+++ /dev/null
@@ -1,43 +0,0 @@
-/*
- * Coldfire generic GPIO support
- *
- * (C) Copyright 2009, Steven Kingsfk...@fdwdc.com
mailto:sfk...@fdwdc.com
- *
- * This program is free software; you can redistribute it and/or
modify
- * it under the terms of the GNU General Public License as published
by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
-*/
-
-#includelinux/kernel.h
-#includelinux/init.h
-
-#includeasm/coldfire.h
-#includeasm/mcfsim.h
-#includeasm/mcfgpio.h
-
-struct mcf_gpio_chip mcf_gpio_chips[] = {
- MCFGPS(PIRQ, 0, 8, MCFEPORT_EPDDR, MCFEPORT_EPDR,
MCFEPORT_EPPDR),
- MCFGPF(FECH, 8, 8),
-
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 00/22] m68knommu: simplify ColdFire GPIO init code
On Wednesday 25 April 2012 5:25:40 pm g...@snapgear.com wrote: The GPIO init code for the ColdFire cores is a set of very large tables, one for each ColdFire SoC type. Each SoC type has very different GPIO pin arrangements, so one for each is unavoidable. But there is fundamentaly two types of setup/access that we are trying to support. With some pre-processor macro magic we can reduce the tables significantly, making them easier to read, easier to get correct, and easier to maintain. The following patches implement a set of simplifying changes. What do others think? Overall we remove close to 2000 lines of code, and the end tables are much easier to read and get correct. Hi Greg, This looks fine to me. You can add my Acked-by: Steven King sfk...@fdwdc.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Minor web page updates
Hi Michael, It might not be a state of the art device, but it is running the latest uClinux :) It's a custom made board that I've built using parts that I had around. The CPU is a straight 68000 running at 16MHz. It has 8MB of ram and 4Mb of flash. https://lh4.googleusercontent.com/-cYFzo0T64Mc/T5iDs3cw60I/AXg/8h_N9-31--o/s1029/IMG_20120425_233230.jpg (hope the link works) Regards, Luis Alves On Wed, Apr 25, 2012 at 1:36 PM, Greg Ungerer g...@snapgear.com wrote: Hi Michael, On 04/25/2012 02:57 AM, Michael Durrant wrote: I have recently updated the front page of the www.uClinux.org web site with the links to the your most recent uClinux-dist dates. Do let me know if you have any other updates. Thanks, it looks good. I am finally into a fairly regular release process now. A few weeks after each new v3.x kernel is released I release a new uClinux-dist package. As well if you know of any photos of devices running uClinux do forward me the links / photos and I will post them of the site as well. Will do. I am sure the many happy list readers will be able to give some pointers too :-) Thanks for getting the list back online, and for all the efforts of maintaining it! Regards Greg --**--** Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close,FAX: +61 7 3891 3630 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com __**_ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/**mailman/listinfo/uclinux-devhttp://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-devhttp://mailman.uclinux.org/mailman/options/uclinux-dev ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH 01/22] m68knommu: introduce macros to simplify ColdFire GPIO table initialization
Hi Philippe, On 04/26/2012 05:16 PM, Philippe De Muyter wrote: Hi Greg, On Thu, Apr 26, 2012 at 10:25:41AM +1000, g...@snapgear.com wrote: From: Greg Ungererg...@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. + */ +#defineMCFGPS(mlabel, mbase, mngpio, mpddr, mpodr, mppdr) \ ... +#defineMCFGPF(mlabel, mbase, mngpio) \ ... Maybe a small comment to explain when to use MCFGPS and when to use MCFGPF ? Yep, that sounds like a good idea. I'll do that. Thanks Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close,FAX: +61 7 3891 3630 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH 00/22] m68knommu: simplify ColdFire GPIO init code
Hi Steven, On 04/26/2012 05:28 PM, Steven King wrote: On Wednesday 25 April 2012 5:25:40 pm g...@snapgear.com wrote: The GPIO init code for the ColdFire cores is a set of very large tables, one for each ColdFire SoC type. Each SoC type has very different GPIO pin arrangements, so one for each is unavoidable. But there is fundamentaly two types of setup/access that we are trying to support. With some pre-processor macro magic we can reduce the tables significantly, making them easier to read, easier to get correct, and easier to maintain. The following patches implement a set of simplifying changes. What do others think? Overall we remove close to 2000 lines of code, and the end tables are much easier to read and get correct. Hi Greg, This looks fine to me. You can add my Acked-by: Steven Kingsfk...@fdwdc.com Great, thanks. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close,FAX: +61 7 3891 3630 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Minor web page updates
Hello It is a graphical library called miniGUI (www.minigui.org) It does not look bad ... but the real beauty is in his heart uclinux+coldfire+horus :) Some more photos: http://www.horus.es/ci/didho_cf/EquipoColdFire2.html Best regards, Jose El 26/04/2012 3:39, Mark Bishop escribió: That looks really neat. How did you do the graphics? Quoting Jose Ferreiro jose.ferre...@horus.es: Hello Michael I am not Greg, but I am so happy to receive the list again that I can not wait to write :) This is our device: http://www.horus.es/ci/didho_cf/EquipoColdFire.html (spanish, sorry :o) It has a senTec Cobra 5329 mounted on own our board. We have several versions with programs principally dedicated to weighting and dosage control. Best regards and thank you , Jose El 24/04/2012 18:57, Michael Durrant escribió: Greg, I have recently updated the front page of the www.uClinux.org web site with the links to the your most recent uClinux-dist dates. Do let me know if you have any other updates. As well if you know of any photos of devices running uClinux do forward me the links / photos and I will post them of the site as well. Regards, Michael Durrant ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev ___ uClinux-dev 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 v2 01/22] m68knommu: introduce macros to simplify ColdFire GPIO table initialization
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.
Signed-off-by: Greg Ungerer g...@uclinux.org
Acked-by: Steven King sfk...@fdwdc.com
---
arch/m68k/include/asm/mcfgpio.h | 54 +++
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/m68k/include/asm/mcfgpio.h b/arch/m68k/include/asm/mcfgpio.h
index ee5e4cc..cd28830 100644
--- a/arch/m68k/include/asm/mcfgpio.h
+++ b/arch/m68k/include/asm/mcfgpio.h
@@ -37,4 +37,58 @@ void mcf_gpio_set_value_fast(struct gpio_chip *, unsigned,
int);
int mcf_gpio_request(struct gpio_chip *, unsigned);
void mcf_gpio_free(struct gpio_chip *, unsigned);
+/*
+ * 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.
+ */
+#defineMCFGPS(mlabel, mbase, mngpio, mpddr, mpodr, mppdr)
\
+ { \
+ .gpio_chip = { \
+ .label = #mlabel, \
+ .request= mcf_gpio_request, \
+ .free = mcf_gpio_free,\
+ .direction_input= mcf_gpio_direction_input, \
+ .direction_output = mcf_gpio_direction_output,\
+ .get= mcf_gpio_get_value, \
+ .set= mcf_gpio_set_value, \
+ .base = mbase,\
+ .ngpio = mngpio, \
+ }, \
+ .pddr = (void __iomem *) mpddr, \
+ .podr = (void __iomem *) mpodr, \
+ .ppdr = (void __iomem *) 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.
+ */
+#defineMCFGPF(mlabel, mbase, mngpio)
\
+ { \
+ .gpio_chip = { \
+ .label = #mlabel, \
+ .request= mcf_gpio_request, \
+ .free = mcf_gpio_free,\
+ .direction_input= mcf_gpio_direction_input, \
+ .direction_output = mcf_gpio_direction_output,\
+ .get= mcf_gpio_get_value, \
+ .set= mcf_gpio_set_value_fast, \
+ .base = mbase,\
+ .ngpio = mngpio, \
+ }, \
+ .pddr = (void __iomem *) MCFGPIO_PDDR_##mlabel, \
+ .podr = (void __iomem *) MCFGPIO_PODR_##mlabel, \
+ .ppdr = (void __iomem *) MCFGPIO_PPDSDR_##mlabel, \
+ .setr = (void __iomem *) MCFGPIO_PPDSDR_##mlabel, \
+ .clrr = (void __iomem *) MCFGPIO_PCLRR_##mlabel, \
+ }
+
#endif
--
1.7.0.4
___
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
Hi Ezequiel, On 04/26/2012 11:29 PM, Ezequiel García wrote: Hi Greg, Just some very minor typos On Thu, Apr 26, 2012 at 10:14 AM,g...@snapgear.com wrote: +/* + * á á 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 There *are* two cases? + * á á available ColdFire GPIO hardware. There is of course minor differences There *are* of course minor differences? Thanks, I'll fix those. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close,FAX: +61 7 3891 3630 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH 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 21/22] m68knommu: simplify the ColdFire 532x GPIO struct setup
On Thu, Apr 26, 2012 at 02:36:20AM +0200, mohamed nabil wrote: that's a Fucking spam man !! It was an overview and 22 patch files, sent in standard git email style. Very organized, all in one thread, easy to read. Nothing wrong with it. -- Len Sorensen ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] something is wrong
Hi, something seems to be wrong with this list. I am subscribed for months now an didn't get anything except a monthly (?) password reminder. I guess I set this behaviour in my profile. But now I seem to get everything. Did you change something lately? Martin ___ 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 21/22] m68knommu: simplify the ColdFire 532x GPIO struct setup
can somebody stop this please? Date: Thu, 26 Apr 2012 12:14:17 -0400 To: uclinux-dev@uclinux.org From: lsore...@csclub.uwaterloo.ca CC: linux-m...@vger.kernel.org; g...@uclinux.org Subject: Re: [uClinux-dev] [PATCH 21/22] m68knommu: simplify the ColdFire 532x GPIO struct setup On Thu, Apr 26, 2012 at 02:36:20AM +0200, mohamed nabil wrote: that's a Fucking spam man !! It was an overview and 22 patch files, sent in standard git email style. Very organized, all in one thread, easy to read. Nothing wrong with it. -- Len Sorensen ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev ___ 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/1] Changes for 68000 code integration.
Hi all, This is the first of a pack of patches to support the original 68000 cpu. This adds: -MC68000 cpu as a choice in the config menu. -Alcetronics M68K board (uses this cpu). What I have changed: -CONFIG_M68000 was being used by 68328 CPUs. Renamed to CONFIG_M68XXX. Now the 68000 and all CPU32 CPUs use this flag for common configurations. -Modified all 68[VZ|EZ]328 to select CONFIG_MCPU32 -Modified CONFIG_MCPU32 to select CONFIG_M68XXX. -Modified CONFIG_M68360 to select CONFIG_M68XXX (I think it was missing some settings). -Modified some files to use CONFIG_M68XXX instead of CONFIG_M68000/CONFIG_MCPU32 Regards, Luis Alves --- arch/m68k/Kconfig.cpu | 29 ++--- arch/m68k/Kconfig.machine |6 ++ arch/m68k/Makefile |9 ++--- arch/m68k/include/asm/bitops.h |2 +- arch/m68k/include/asm/delay.h |2 +- arch/m68k/lib/memcpy.c |4 ++-- arch/m68k/lib/memset.c |2 +- arch/m68k/lib/muldi3.c |2 +- 8 files changed, 36 insertions(+), 20 deletions(-) diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu index 8a9c767..2abac0f 100644 --- a/arch/m68k/Kconfig.cpu +++ b/arch/m68k/Kconfig.cpu @@ -32,26 +32,33 @@ endchoice if M68KCLASSIC -config M68000 + +config M68XXX bool select CPU_HAS_NO_BITFIELDS select CPU_HAS_NO_MULDIV64 select GENERIC_CSUM help - The Freescale (was Motorola) 68000 CPU is the first generation of - the well known M68K family of processors. The CPU core as well as - being available as a stand alone CPU was also used in many - System-On-Chip devices (eg 68328, 68302, etc). It does not contain - a paging MMU. + Common features for the first generation of M68K CPUs. It + includes the original MC68000 and CPU32 core. + config MCPU32 bool - select CPU_HAS_NO_BITFIELDS + select M68XXX help The Freescale (was then Motorola) CPU32 is a CPU core that is based on the 68020 processor. For the most part it is used in System-On-Chip parts, and does not contain a paging MMU. +config M68000 + bool MC68000 + select M68XXX + help + The Freescale (was Motorola) 68000 CPU is the first generation of + the well known M68K family of processors. It does not contain + a paging MMU. + config M68020 bool 68020 support depends on MMU @@ -96,28 +103,28 @@ config M68060 config M68328 bool MC68328 depends on !MMU - select M68000 + select MCPU32 help Motorola 68328 processor support. config M68EZ328 bool MC68EZ328 depends on !MMU - select M68000 + select MCPU32 help Motorola 68EX328 processor support. config M68VZ328 bool MC68VZ328 depends on !MMU - select M68000 + select MCPU32 help Motorola 68VZ328 processor support. config M68360 bool MC68360 depends on !MMU - select MCPU32 + select M68XXX help Motorola 68360 processor support. diff --git a/arch/m68k/Kconfig.machine b/arch/m68k/Kconfig.machine index 7cdf6b0..25ce143 100644 --- a/arch/m68k/Kconfig.machine +++ b/arch/m68k/Kconfig.machine @@ -134,6 +134,12 @@ config SUN3 endif # M68KCLASSIC +config ALCE68K + bool Alcetronics M68K board support + depends on M68000 + help + Support for the Alcetronics M68K board. + config PILOT bool diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile index cf318f2..d1d7343 100644 --- a/arch/m68k/Makefile +++ b/arch/m68k/Makefile @@ -32,8 +32,9 @@ cpuflags-$(CONFIG_M68040) := -m68040 endif cpuflags-$(CONFIG_M68030) := cpuflags-$(CONFIG_M68020) := -cpuflags-$(CONFIG_M68360) := -m68332 cpuflags-$(CONFIG_M68000) := -m68000 +cpuflags-$(CONFIG_MCPU32) := -m68000 +cpuflags-$(CONFIG_M68360) := -m68332 cpuflags-$(CONFIG_M54xx) := $(call cc-option,-mcpu=5475,-m5200) cpuflags-$(CONFIG_M5407) := $(call cc-option,-mcpu=5407,-m5200) cpuflags-$(CONFIG_M532x) := $(call cc-option,-mcpu=532x,-m5307) @@ -88,8 +89,9 @@ endif # head-y := arch/m68k/kernel/head.o head-$(CONFIG_SUN3):= arch/m68k/kernel/sun3-head.o +head-$(CONFIG_M68000) := arch/m68k/platform/68000/head.o head-$(CONFIG_M68360) := arch/m68k/platform/68360/head.o -head-$(CONFIG_M68000) := arch/m68k/platform/68328/head.o +head-$(CONFIG_MCPU32) := arch/m68k/platform/68328/head.o head-$(CONFIG_COLDFIRE):= arch/m68k/platform/coldfire/head.o core-y += arch/m68k/kernel/arch/m68k/mm/ @@ -111,7 +113,8 @@ core-$(CONFIG_M68040) += arch/m68k/fpsp040/ core-$(CONFIG_M68060) += arch/m68k/ifpsp060/ core-$(CONFIG_M68KFPU_EMU) +=
Re: [uClinux-dev] something is wrong
Jivin Stuart Small lays it down ... The list used to be a lot more active. Hopefully its renewed interest in the project. The list servers have been broken for a while on and off, thus the lack of traffic. Thanks to Michael Durrant at Arcturus we have things back working again :-) So expect more traffic now things are back working, Cheers, Davidm 2012/4/26 Juan Pablo C?rdova Echeverr?a jpcordo...@gmail.com Same here. JP El abr 26, 2012 4:09 p.m., Martin Mensch martin.men...@gmx.de escribi?: Hi, something seems to be wrong with this list. I am subscribed for months now an didn't get anything except a monthly (?) password reminder. I guess I set this behaviour in my profile. But now I seem to get everything. Did you change something lately? Martin ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev -- David McCullough, david_mccullo...@mcafee.com, Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
