From owner-freebsd-arm@FreeBSD.ORG Sat Apr 14 16:04:05 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DAB2D106566C for ; Sat, 14 Apr 2012 16:04:05 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5B38A8FC0A for ; Sat, 14 Apr 2012 16:04:04 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta01.emeryville.ca.mail.comcast.net with comcast id xrv51i0031smiN4A1s2ysZ; Sat, 14 Apr 2012 16:02:58 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta20.emeryville.ca.mail.comcast.net with comcast id xs2x1i00z4NgCEG8gs2yTv; Sat, 14 Apr 2012 16:02:58 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q3EG2uu8062608; Sat, 14 Apr 2012 10:02:56 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Aleksander Dutkowski In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Sat, 14 Apr 2012 10:02:56 -0600 Message-ID: <1334419376.1082.162.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org Subject: Re: [GSoC] [ARM] arm cleanup - my own proposal X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 16:04:05 -0000 On Sun, 2012-04-01 at 20:19 +0200, Aleksander Dutkowski wrote: > hello! > > after few weeks searching for interesting idea for me, I've decided to > propose my own one. It is already mentioned on IdeasPage: > - ARM cleanup > > Why I have chosen this one? I am very interested in embedded world. > Now I am working on porting FBSD to at91sam9g45 - I will be much more > motivated working on arm fbsd project than any other. > > Why should you let me do that project? While working on freebsd/arm > I've noticed places that could be optimized, or separated, i.e. > at91_samsize() should be declared for each board separately - now, > this function has if-else and checks, which board is he running on. > > I would like to identify and fix that bugs, so the code will be more > efficient and clear. Moreover, I think there should be a > tutorial/framework for adding new boards or SoCs, so I will be > simplier. I am currently reading the code in sys/arm/at91 and > searching for improvements but I will be very pleased, if you send me > your insights. > > The first question is - should I cleanup only at91 branch or more? I > am quite familiar with at91 right now. > The second - how to test the code? Some of boards could be tested in > qemu, I could buy board with at91rm9200 for example, if I'm in. But > maybe I will find here people with their own boards, they could help > me testing? I havs sbc6045 board with at91sam9g45 SoC but it hasn't > fbsd support yet (I'm working on it now :) ) > > I also thought about reducing kernel size for embedded, if arm cleanup > won't fit. > > I'm curious whether you ever got a reply to this privately, since nothing appeared on the list? I meant to reply and offer to do testing of at91 changes on rm9200 hardware, but I was on vacation when you posted originally, and I forgot to reply until just now. It's been my growing impression for about a year that the arm support in FreeBSD has atrophied to the point where it can barely be said that it's supported at all. Now I see this morning that marius@ has committed a set of style cleanups to the at91 code (r234281), so maybe it's not quite as dead as I feared. At Symmetricom we build a variety of products based on the rm9200, and we're maintaining quite a set of diffs from stock FreeBSD. Some are bug fixes, some are enhancements such as allowing the master clock frequency to be changed during kernel init (instead of in the bootloader) and a hints-based system that allows the atmelarm bus to become aware of new child devices that aren't in the stock code and manage their resources. It sure would be nice if some of those diffs could get rolled back in; it would certainly make it easier for me to integrate things like Marius' style cleanups back into our repo. Anyway, if ongoing changes are going to be happening to the at91 code, I'm certainly interested in helping however I can. -- Ian