Date: Sun, 02 Dec 2007 07:21:38 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: mlfbsd@ci0.org Cc: freebsd-arm@FreeBSD.org Subject: Re: ARM arch subdir cleanups Message-ID: <20071202.072138.1723236577.imp@bsdimp.com> In-Reply-To: <20071202140920.GA40640@ci0.org> References: <474FF9BF.8090707@semihalf.com> <20071202140920.GA40640@ci0.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20071202140920.GA40640@ci0.org>
Olivier Houchard <mlfbsd@ci0.org> writes:
: On Fri, Nov 30, 2007 at 12:53:35PM +0100, Rafal Jaworowski wrote:
: > Hi,
: > Attached are two patches with the following cleanups:
: >
: > 1. Convert nexus to standard device since it's mandatory anyway, remove stale
: > nexus_io_asm.S and nexus_io.c
: >
: > 2. Streamline sys/conf/files.arm (and hence the kernel image contents): move
: > asm routines to appropriate sys/arm/<platform>/files.<platform>
: >
: >
: > It seems to me other items in the ARM arch subdirectory would benefit from
: > optimization/cleanups too, for example:
: >
: > - Shared OBIO routines. At least these are nearly identical and could be
: > compressed into one I guess:
: >
: > xscale/i80321/obio_space.c
: > xscale/i8134x/obio_space.c
: > xscale/pxa2x0/pxa2x0_space.c (in P4)
: >
: > - Shared bus space generic methods. A lot of BS methods like *_bs_map(),
: > _bs_subregion() etc. are copied in separate files for different ARM platforms,
: > but most of this could be placed in one file, just like we have a common
: > assembly routines in the arm/arm/bus_space_asm_generic.S.
: >
: > - Others like arm/arm/machdep.c and arm/arm/sys_machdep.c seem akin, could
: > they be merged into one file?
: >
: > I can work on cleaning those up, would such changes be welcome?
: >
: > Rafal
:
:
: Hi Rafal,
:
: I just committed your patches. Yes, this kind of work is very welcome.
Indeed. I've done some work trying to get obio abstracted out across
all architectures.
The other thing that I'd like to see is a better defined board/cpu
initialization sequence. Or to make better use of the one that's
defined now and document it better. I made some bad choices, in
hindsight, for the at91rm9200 port that are only now becoming
apparent.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071202.072138.1723236577.imp>