An error occurred fetching the project authors.
- 25 Mar, 2011 1 commit
-
-
Greg Ungerer authored
There is a lot of common code that could be shared between the m68k and m68knommu arch branches. It makes sense to merge the two branches into a single directory structure so that we can more easily share that common code. This is a brute force merge, based on a script from Stephen King <sfking@fdwdc.com>, which was originally written by Arnd Bergmann <arnd@arndb.de>. > The script was inspired by the script Sam Ravnborg used to merge the > includes from m68knommu. For those files common to both arches but > differing in content, the m68k version of the file is renamed to > <file>_mm.<ext> and the m68knommu version of the file is moved into the > corresponding m68k directory and renamed <file>_no.<ext> and a small > wrapper file <file>.<ext> is used to select between the two version. Files > that are common to both but don't differ are removed from the m68knommu > tree and files and directories that are unique to the m68knommu tree are > moved to the m68k tree. Finally, the arch/m68knommu tree is removed. > > To select between the the versions of the files, the wrapper uses > > #ifdef CONFIG_MMU > #include <file>_mm.<ext> > #else > #include <file>_no.<ext> > #endif On top of this file merge I have done a simplistic merge of m68k and m68knommu Kconfig, which primarily attempts to keep existing options and menus in place. Other than a handful of options being moved it produces identical .config outputs on m68k and m68knommu targets I tested it on. With this in place there is now quite a bit of scope for merge cleanups in future patches. Signed-off-by:
Greg Ungerer <gerg@uclinux.org>
-
- 15 Mar, 2011 1 commit
-
-
Greg Ungerer authored
The FireBee is a ColdFire 5475 based board. Add a configuration option to support it, and the basic platform flash layout code. Signed-off-by:
Greg Ungerer <gerg@uclinux.org>
-
- 05 Jan, 2011 1 commit
-
-
Greg Ungerer authored
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 <gerg@uclinux.org>
-
- 21 Oct, 2010 1 commit
-
-
Philippe De Muyter authored
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 <phdm@macqel.be> Signed-off-by:
Greg Ungerer <gerg@uclinux.org>
-
- 10 Sep, 2009 1 commit
-
-
sfking@fdwdc.com authored
Add support for the 5407. Signed-off-by:
Steven King <sfking@fdwdc.com> Signed-off-by:
Greg Ungerer <gerg@uclinux.org>
-
- 15 Feb, 2008 1 commit
-
-
Greg Ungerer authored
Modify the extra asm flags for debugger capabilities, use asflags instead for EXTRA_AFLAGS. Suggestion from Sam Ravnborg. Signed-off-by:
Greg Ungerer <gerg@uclinux.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 15 Oct, 2007 1 commit
-
-
Sam Ravnborg authored
In most cases when AFALGS is manipuled direct this is a bug and EXTRA_AFLAGS should have been used. Fix the obvious candidates. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Greg Ungerer <gerg@uclinux.org> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
-
- 16 Apr, 2005 1 commit
-
-
Linus Torvalds authored
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-