From owner-freebsd-arm@FreeBSD.ORG Sun May 24 19:31:18 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18FF71065692 for ; Sun, 24 May 2009 19:31:18 +0000 (UTC) (envelope-from ccna.syl@gmail.com) Received: from mail-gx0-f179.google.com (mail-gx0-f179.google.com [209.85.217.179]) by mx1.freebsd.org (Postfix) with ESMTP id CA3538FC1D for ; Sun, 24 May 2009 19:31:17 +0000 (UTC) (envelope-from ccna.syl@gmail.com) Received: by gxk27 with SMTP id 27so1106427gxk.19 for ; Sun, 24 May 2009 12:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type:content-transfer-encoding; bh=1CFmA19k4qxwmQNZ+37exgmQLv/aRgQRO4ln+C0pyRE=; b=qGd6ntzGYR3q23c3q+qtaTdHtrdiKCoUQsxtrvGUFiD4Znl0rbaGOlzyJYqssHFG7W jXFWgCDkTaJNrVWE9aaEpr0UHEp9NKm2HAsYKR49/zCL2q3dz0nNfZQO4vuBAsTOBttX 1Taxx6qcocKNaTKSVgmxyA1HzGwaoPqctUH5k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=tdStOa5UWs2HFg0WO7NU6YJUm7H8BdXhBpkCT2wNndi1/TW+OtJNJL12SMEwwMht0f B+g9au9ALhKiwxxWjKNVPYMzxZ0BQ5QNb9mNTs3RgIFycbHsxUpTz3S8arV4rByntt7W PyfAsxKUfRqRBTZ4c3xXnNQ2PJheiPj5+CvnU= MIME-Version: 1.0 Received: by 10.231.15.7 with SMTP id i7mr1223399iba.43.1243192010448; Sun, 24 May 2009 12:06:50 -0700 (PDT) From: Sylvestre Gallon Date: Sun, 24 May 2009 19:06:30 +0000 Message-ID: <164b4c9c0905241206s570a15b1ob6214e9505329ae@mail.gmail.com> To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: at91 SoC separation 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: Sun, 24 May 2009 19:31:19 -0000 Hi, I am currently working on the at91sam9261ek port for the Google Summer Of Code 2009. Currently I work on how I could implement the at91sam9261ek most efficiently. I notice that all the at91 code could be at91 System On Chip independent with some few changes. The big work is to extract the SoC specific code in a separate file by SoC. It's what I tried to do on my perforce : perforce repo : http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2009/syl_usb/src/sys/arm/at91&HIDEDEL=NO Changes that I've done : http://perforce.freebsd.org/changeList.cgi?FSPC=%2F%2Fdepot%2Fprojects%2Fsoc2009%2Fsyl_usb%2Fsrc%2Fsys%2Farm%2Fat91%2F...&USERS=syl&GROUPS=soc2009&ignore=GO! One thing that continues to disturb me : On At91 SoC, the IPs and their registers are quite the same. The only big change that exists between these SoC are the base addresses for each IPs. The different SoC generic drivers may need IPs base addresses to perform the mapping of registers. For the moment to not have some ugly #ifdef like : #ifdef __AT91RM9200__ #include #elif __AT91SAM9261__ #include #elfi __ANOTHER_SOC__ #include #endif I have created base address accessors in the SoC file. But I'm not sure I like that... Do you have some ideas to handle it in a better way ? When All the code of at91 will be SoC independents It will be very easy to port any other at91 board (1 or 2 days of work by cpu). I have also access to a lot of atmel board, I live near Atmel French R&D and know some people who work there who are ready to lend me boards with these SoC : - at91sam9260 - at91sam9261 - at91sam9263 - at91sam9rl - at91sam9m10 (not officially out, and not yet in Linux ;) ) - at91cap9 - .. I'am open to all suggestions, it is important for me to implement the at91sam9261ek (and perhaps other) port the best way I can to have a chance to see it in current after the Google Summer Of Code :) Cheers, -- Sylvestre Gallon (http://devsyl.blogspot.com) Fifth Grade Student @ Epitech & Researcher @ LSE R&D @ Rathaxes (http://www.rathaxes.org) From owner-freebsd-arm@FreeBSD.ORG Sun May 24 22:39:58 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61EC8106566C for ; Sun, 24 May 2009 22:39:58 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 137BB8FC0C for ; Sun, 24 May 2009 22:39:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n4OMcLb8047665; Sun, 24 May 2009 16:38:22 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 24 May 2009 16:38:38 -0600 (MDT) Message-Id: <20090524.163838.113805925.imp@bsdimp.com> To: ccna.syl@gmail.com From: "M. Warner Losh" In-Reply-To: <164b4c9c0905241206s570a15b1ob6214e9505329ae@mail.gmail.com> References: <164b4c9c0905241206s570a15b1ob6214e9505329ae@mail.gmail.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: at91 SoC separation 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: Sun, 24 May 2009 22:39:58 -0000 In message: <164b4c9c0905241206s570a15b1ob6214e9505329ae@mail.gmail.com> Sylvestre Gallon writes: : Hi, : : I am currently working on the at91sam9261ek port for the : Google Summer Of Code 2009. : : Currently I work on how I could implement the at91sam9261ek : most efficiently. I notice that all the at91 code could be at91 : System On Chip independent with some few changes. : : The big work is to extract the SoC specific code in a separate file : by SoC. It's what I tried to do on my perforce : : : perforce repo : : http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2009/syl_usb/src/sys/arm/at91&HIDEDEL=NO : : Changes that I've done : : http://perforce.freebsd.org/changeList.cgi?FSPC=%2F%2Fdepot%2Fprojects%2Fsoc2009%2Fsyl_usb%2Fsrc%2Fsys%2Farm%2Fat91%2F...&USERS=syl&GROUPS=soc2009&ignore=GO! : : One thing that continues to disturb me : On At91 SoC, the IPs and : their registers are quite the same. The only big change that exists : between these SoC are the base addresses for each IPs. The different : SoC generic drivers may need IPs base addresses to perform the : mapping of registers. For the moment to not have some ugly : #ifdef like : : : #ifdef __AT91RM9200__ : #include : #elif __AT91SAM9261__ : #include : #elfi __ANOTHER_SOC__ : #include : #endif : : I have created base address accessors in the SoC file. But I'm not : sure I like that... Do you have some ideas to handle it in a better : way ? : : When All the code of at91 will be SoC independents It will be very : easy to port any other at91 board (1 or 2 days of work by cpu). : I have also access to a lot of atmel board, I live near Atmel French : R&D and know some people who work there who are ready to lend : me boards with these SoC : : : - at91sam9260 : - at91sam9261 : - at91sam9263 : - at91sam9rl : - at91sam9m10 (not officially out, and not yet in Linux ;) ) : - at91cap9 : - .. : : I'am open to all suggestions, it is important for me to implement : the at91sam9261ek (and perhaps other) port the best way I can : to have a chance to see it in current after the Google Summer Of : Code :) I've been thinking about the issues for a long time. And there's a number of interrelated problems. All of them are related to the fact that we have the core, SoC and board smashed into one file right now. We really need to finish separating out the core support (it is mostly done right now, except for some of the bus space stuff). The SoC and board support is all in at91.c, which really should be about infrastructure not about boards... First, you need to know what board you are on when you boot. uboot and others pass this information into the kernel using register r3, IIRC. So, there would need to be a way for the early boot code to probe for one of a number of different boards. For SoC, this could be just one board compiled into the kernel (eg, you don't have run time select), but Sam has done some work in this area on the xscale parts you may be able to snag. If we assume that there's a board init routine, we can assume that init routine knows what kind of SoC is installed on the board and can populate the atmelbus with the right devices by calling something like at91rm9200_soc_init(). Then, that board routine can also do the proper routing of the pins to the different peripherals as well, possibly calling some generic peripheral init routines as well (although that's a lot harder to arrange than you might otherwise think given just how flexible these things are). The board routine would also be responsible for calling cninit() as well. If we go this route, we can eliminate much of the #ifdef soup that you were otherwise looking at doing. The AT91RM9200 registers would be defined in one place, but we'd try to use the base + offset approach to isolate the number places that need this information. That's one of the problems with the current set of patches for the at91sam boards: they just do ifdefs rather than do the proper refactoring to get us the most amount of support. So the typical board package would look something like: int kb9202_probe() { if (arm_board_id_from_loader() != KB9202_BOARD_ID) return ENXIO; return 0; } int kb9202_init() { at91rm9200_soc_init(); /* * */ /* * Map in the pmap entries needed on this board for flash, CF, * etc */ /* * Create some kind of descriptor to tell the SD card what GPIO * pins are used for different things, what the MAC address * of the board is, etc. Maybe need one per driver and a list * of them for this board */ } ARM_BOARD_TYPE(kb9202_probe, kb9202_init); As an aside, you may also need to make the different boot loaders pluggable as well, or maybe we would do that as part of another pass. You could assume they were all uboot compatible or something... Linux defines a standard here, and we'd be wise to follow it... Obviously, you'd need to rewrite arm_init as well to defer some of the things it does now. You'd need to move pmap init stuff to the at91rm9200_soc_init(), except for the CF/FLASH stuff, which would move to a board-level init. Some of the mappings might need to change that are done currently inline (which may mean we'd have to do some much needed refactoring here). Right now board_init is in a very special place, and we'd likely need to move the cninit() into each board init so that the boards could control which console was used. There's also some ideas going around about being able to load hints dynamically at run time and the foo_soc_init() and board_init routines would just load them up correctly. That's another orthogonal way to move the tables out of at91rm9200_soc_init and into an easier to manage text form, but at the expense of needing to add code to the hints mechanism, and fight the bike-sheds that surround its replacement. So I'd frankly avoid this for the SoC project. Getting good separation is more important than having a perfect mechanism the separation can use. Those are just the top level ideas I have with respect to this port. In fact, we could generalize this to all embedded boards since I believe it scales well. Linux does something similar, and to add a new board is about a hundred lines, and a new SoC maybe ~400 more. I think getting a good separation would be the key element to focus on, as well as picking one or two other SoCs/boards to validate that the design works and scales. Make those the first priority. Once you have them in place and working, then if you've done things right you'll be able to add all those other cool boards quickly, subject to the availability of drivers and quirks for silicon bugs (oh, and free time). Comments? Warner From owner-freebsd-arm@FreeBSD.ORG Mon May 25 07:41:04 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC481106566C for ; Mon, 25 May 2009 07:41:03 +0000 (UTC) (envelope-from ccna.syl@gmail.com) Received: from mail-gx0-f169.google.com (mail-gx0-f169.google.com [209.85.217.169]) by mx1.freebsd.org (Postfix) with ESMTP id A14678FC14 for ; Mon, 25 May 2009 07:41:03 +0000 (UTC) (envelope-from ccna.syl@gmail.com) Received: by gxk17 with SMTP id 17so256906gxk.19 for ; Mon, 25 May 2009 00:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=n7+utWg+OzyxWX2sD8p4ZZex/WbNg8c9ODQtDv8TpJ8=; b=UaHLM7UWMedmeSzA/+8vZq5vp++mdndhaNXQEIq1UTJjyq0mQzTbumohydwU0gh683 6sM2JdnAwfD1AMhd6cvUyU6jv0sKAKnzNxLVC/R5ZiEM5hbN/Mr2kKLMTuTaTJHlHpKH SAX1AVgsSnK2qlqYU28Xmp5R1ZX4+O7YAEwTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=loPsAUxXUpP5W23FNvIbhwUEBkg9XUu11sV2f0iFcBFpz48xN0LPZQdccH0WRbdB8U y8jI1lwFFJwFD/x5Sw0k36u0pcSk1wza1q4MezJv9NYJwkz6d5udcAO4ZBL9VK6ruRtR L9Cpes1D+VDETbqXrfYzB78IuthEd4xDPUuvc= MIME-Version: 1.0 Received: by 10.231.11.77 with SMTP id s13mr1320781ibs.53.1243237262823; Mon, 25 May 2009 00:41:02 -0700 (PDT) In-Reply-To: <20090524.163838.113805925.imp@bsdimp.com> References: <164b4c9c0905241206s570a15b1ob6214e9505329ae@mail.gmail.com> <20090524.163838.113805925.imp@bsdimp.com> From: Sylvestre Gallon Date: Mon, 25 May 2009 09:39:34 +0200 Message-ID: <164b4c9c0905250039o73cd1833xbbe3aeaa9ea0f3a6@mail.gmail.com> To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org Subject: Re: at91 SoC separation 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: Mon, 25 May 2009 07:41:04 -0000 On Mon, May 25, 2009 at 12:38 AM, M. Warner Losh wrote: > > I've been thinking about the issues for a long time. =A0And there's a > number of interrelated problems. =A0All of them are related to the fact > that we have the core, SoC and board smashed into one file right now. > We really need to finish separating out the core support (it is mostly > done right now, except for some of the bus space stuff). =A0The SoC and > board support is all in at91.c, which really should be about > infrastructure not about boards... > > First, you need to know what board you are on when you boot. =A0uboot > and others pass this information into the kernel using register r3, > IIRC. =A0So, there would need to be a way for the early boot code to > probe for one of a number of different boards. =A0For SoC, this could be > just one board compiled into the kernel (eg, you don't have run time > select), but Sam has done some work in this area on the xscale parts > you may be able to snag. It is what I've tried to do for SoC: Each board must have a device with a SoC name : http://perforce.freebsd.org/fileViewer.cgi?FSPC=3D//depot/projects/soc2009/= syl_usb/src/sys/arm/at91/std.bwct&REV=3D2 http://perforce.freebsd.org/fileViewer.cgi?FSPC=3D//depot/projects/soc2009/= syl_usb/src/sys/arm/at91/std.at91sam9261ek&REV=3D1 This allow the compile of the good SoC file : http://perforce.freebsd.org/fileViewer.cgi?FSPC=3D//depot/projects/soc2009/= syl_usb/src/sys/arm/at91/files.at91&REV=3D3 The SoC file contains the code SoC dependent : http://perforce.freebsd.org/fileViewer.cgi?FSPC=3D//depot/projects/soc2009/= syl_usb/src/sys/arm/at91/soc_at91rm9200.c&REV=3D4 http://perforce.freebsd.org/fileViewer.cgi?FSPC=3D//depot/projects/soc2009/= syl_usb/src/sys/arm/at91/soc_at91sam9261.c&REV=3D3 All this changes allow me to move at91.c into a code SoC independent : http://perforce.freebsd.org/fileViewer.cgi?FSPC=3D//depot/projects/soc2009/= syl_usb/src/sys/arm/at91/at91.c&REV=3D3 I think this is important to have a SoC file because there are some big changes between each SoC the at91_master_clock, cpu_devs and the pmap_devmap are not the same on each SoC. > > If we assume that there's a board init routine, we can assume that > init routine knows what kind of SoC is installed on the board and can > populate the atmelbus with the right devices by calling something like > at91rm9200_soc_init(). =A0Then, that board routine can also do the > proper routing of the pins to the different peripherals as well, > possibly calling some generic peripheral init routines as well > (although that's a lot harder to arrange than you might otherwise > think given just how flexible these things are). =A0The board routine > would also be responsible for calling cninit() as well. > > If we go this route, we can eliminate much of the #ifdef soup that you > were otherwise looking at doing. =A0The AT91RM9200 registers would be > defined in one place, but we'd try to use the base + offset approach > to isolate the number places that need this information. =A0That's one > of the problems with the current set of patches for the at91sam > boards: they just do ifdefs rather than do the proper refactoring to > get us the most amount of support. > > So the typical board package would look something like: > > int > kb9202_probe() > { > =A0 =A0 =A0 =A0if (arm_board_id_from_loader() !=3D KB9202_BOARD_ID) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return ENXIO; > =A0 =A0 =A0 =A0return 0; > } > > int > kb9202_init() > { > =A0 =A0 =A0 =A0at91rm9200_soc_init(); > =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 * here> > =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 * Map in the pmap entries needed on this board for flash,= CF, > =A0 =A0 =A0 =A0 * etc > =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 * Create some kind of descriptor to tell the SD card what= GPIO > =A0 =A0 =A0 =A0 * pins are used for different things, what the MAC addres= s > =A0 =A0 =A0 =A0 * of the board is, etc. =A0Maybe need one per driver and = a list > =A0 =A0 =A0 =A0 * of them for this board > =A0 =A0 =A0 =A0 */ > } > > ARM_BOARD_TYPE(kb9202_probe, kb9202_init); > > As an aside, you may also need to make the different boot loaders > pluggable as well, or maybe we would do that as part of another pass. > You could assume they were all uboot compatible or something... =A0Linux > defines a standard here, and we'd be wise to follow it... > > Obviously, you'd need to rewrite arm_init as well to defer some of the > things it does now. =A0You'd need to move pmap init stuff to the > at91rm9200_soc_init(), except for the CF/FLASH stuff, which would move > to a board-level init. =A0Some of the mappings might need to change that > are done currently inline (which may mean we'd have to do some much > needed refactoring here). =A0Right now board_init is in a very special > place, and we'd likely need to move the cninit() into each board init > so that the boards could control which console was used. The cninit has not move now but I have also moved pmap init stuff into the SoC file : http://perforce.freebsd.org/fileViewer.cgi?FSPC=3D//depot/projects/soc2009/= syl_usb/src/sys/arm/at91/soc_at91rm9200.c&REV=3D4 http://perforce.freebsd.org/fileViewer.cgi?FSPC=3D//depot/projects/soc2009/= syl_usb/src/sys/arm/at91/soc_at91sam9261.c&REV=3D3 For that have done some little change in the machedep.c to be SoC independent : http://perforce.freebsd.org/fileViewer.cgi?FSPC=3D//depot/projects/soc2009/= syl_usb/src/sys/arm/at91/at91_machdep.c&REV=3D2 > > There's also some ideas going around about being able to load hints > dynamically at run time and the foo_soc_init() and board_init routines > would just load them up correctly. =A0That's another orthogonal way to > move the tables out of at91rm9200_soc_init and into an easier to > manage text form, but at the expense of needing to add code to the > hints mechanism, and fight the bike-sheds that surround its > replacement. =A0So I'd frankly avoid this for the SoC project. =A0Getting > good separation is more important than having a perfect mechanism the > separation can use. I am totally agree. Thanks for your help :) Cheers, --=20 Sylvestre Gallon (http://devsyl.blogspot.com) Fifth Grade Student @ Epitech & Researcher @ LSE R&D @ Rathaxes (http://www.rathaxes.org) From owner-freebsd-arm@FreeBSD.ORG Mon May 25 11:06:48 2009 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 442B71065672 for ; Mon, 25 May 2009 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 30B808FC26 for ; Mon, 25 May 2009 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4PB6mc8092721 for ; Mon, 25 May 2009 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4PB6lLe092717 for freebsd-arm@FreeBSD.org; Mon, 25 May 2009 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 May 2009 11:06:47 GMT Message-Id: <200905251106.n4PB6lLe092717@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org 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: Mon, 25 May 2009 11:06:48 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From owner-freebsd-arm@FreeBSD.ORG Tue May 26 15:52:01 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D4BE106566C for ; Tue, 26 May 2009 15:52:01 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id 406DB8FC24 for ; Tue, 26 May 2009 15:51:58 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id n4QFptHF084811; Tue, 26 May 2009 10:51:56 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1243353116; bh=J3OPOY84dLSBySVfpAFFRz+w5tDKp9MIdMpJklY3804=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=G1AIvITMm9jX/ZH7xtPHu+Dj1p7nK2LiJw5n5rRRzjj756DQx5mLCM9MZEL+ow85c 2PqE2ZMZrVa6nrITZU1w7KRfxcbCHSjrOSg0zkGBLqnX/H+cu8mQ8oBrYQr8OV0ueD 6KN137rVfWUDwAHzcjFVcNY0f0ujFss3aMC8pyo4= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id n4QFpt1w084810; Tue, 26 May 2009 10:51:55 -0500 (CDT) (envelope-from tinguely) Date: Tue, 26 May 2009 10:51:55 -0500 (CDT) From: Mark Tinguely Message-Id: <200905261551.n4QFpt1w084810@casselton.net> To: ccna.syl@gmail.com, imp@bsdimp.com In-Reply-To: <20090524.163838.113805925.imp@bsdimp.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Tue, 26 May 2009 10:51:56 -0500 (CDT) Cc: freebsd-arm@freebsd.org Subject: Re: at91 SoC separation 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: Tue, 26 May 2009 15:52:01 -0000 As a side, slightly off-topic note, I have been thinking of the whole boot process. The different ARM architecture/board boot sequences are basically the same. I agree that the main difference between the different ARM boards are the difference in the locations of devices map. Right now, the init_arm() manually allocates the "level one" page tables so they are available for the pmap_devmap_bootstrap() call. The devmap bootstrap can be modified to automatically allocate any missing "level one" page tables from the end of the free memory pointer. The updated end of free memory is sent back to the initialation routine. Add a few calls for architecture initialization and ever board can use the same boot routine. I agree this is not a SoC scoped add-on project. --Mark Tinguely From owner-freebsd-arm@FreeBSD.ORG Tue May 26 17:13:23 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FBAC10656AA for ; Tue, 26 May 2009 17:13:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5FA4B8FC08 for ; Tue, 26 May 2009 17:13:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n4QHAaAx081800; Tue, 26 May 2009 11:10:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 26 May 2009 11:10:55 -0600 (MDT) Message-Id: <20090526.111055.1849561573.imp@bsdimp.com> To: tinguely@casselton.net From: "M. Warner Losh" In-Reply-To: <200905261551.n4QFpt1w084810@casselton.net> References: <20090524.163838.113805925.imp@bsdimp.com> <200905261551.n4QFpt1w084810@casselton.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: at91 SoC separation 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: Tue, 26 May 2009 17:13:24 -0000 In message: <200905261551.n4QFpt1w084810@casselton.net> Mark Tinguely writes: : : As a side, slightly off-topic note, I have been thinking of the whole boot : process. : : The different ARM architecture/board boot sequences are basically the same. : I agree that the main difference between the different ARM boards are the : difference in the locations of devices map. : : Right now, the init_arm() manually allocates the "level one" page tables : so they are available for the pmap_devmap_bootstrap() call. : : The devmap bootstrap can be modified to automatically allocate any missing : "level one" page tables from the end of the free memory pointer. The : updated end of free memory is sent back to the initialation routine. : Add a few calls for architecture initialization and ever board can use : the same boot routine. That's another can of worms that we need to detangle :) I rather like this idea. I also like the idea of having different boot loader front ends that drive this rather than having the SoC code drive it. We are a little too tightly coupled between boot loader and soc at the moment as well. The work isn't horribly hard, just tedious because you have to run down a bunch of different boards we support and see why the routines are different and account for those differences, or hopefully, eliminate them. It is the latter that's going to be a challenge. Warner From owner-freebsd-arm@FreeBSD.ORG Wed May 27 10:24:33 2009 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 538B3106566B; Wed, 27 May 2009 10:24:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 294F88FC12; Wed, 27 May 2009 10:24:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4RAOUYj075639; Wed, 27 May 2009 06:24:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4RAOUwp051347; Wed, 27 May 2009 06:24:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 61B2B7302F; Wed, 27 May 2009 06:24:30 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090527102430.61B2B7302F@freebsd-current.sentex.ca> Date: Wed, 27 May 2009 06:24:30 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 10:24:33 -0000 TB --- 2009-05-27 09:40:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-27 09:40:01 - starting HEAD tinderbox run for arm/arm TB --- 2009-05-27 09:40:01 - cleaning the object tree TB --- 2009-05-27 09:40:35 - cvsupping the source tree TB --- 2009-05-27 09:40:35 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-05-27 09:40:46 - building world TB --- 2009-05-27 09:40:46 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-27 09:40:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-27 09:40:46 - TARGET=arm TB --- 2009-05-27 09:40:46 - TARGET_ARCH=arm TB --- 2009-05-27 09:40:46 - TZ=UTC TB --- 2009-05-27 09:40:46 - __MAKE_CONF=/dev/null TB --- 2009-05-27 09:40:46 - cd /src TB --- 2009-05-27 09:40:46 - /usr/bin/make -B buildworld >>> World build started on Wed May 27 09:40:49 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.sbin/dtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.sbin/dtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/lib/libproc/common -I/src/cddl/usr.sbin/dtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.sbin/dtrace/../../../sys/cddl/contrib/opensolaris/compat -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -pthread -L/obj/arm/src/cddl/usr.sbin/dtrace/../../lib/libdtrace -L/obj/arm/src/cddl/usr.sbin/dtrace/../../lib/libproc -L/obj/arm/src/cddl/usr.sbin/dtrace/../../lib/libctf -L/obj/arm/src/cddl/usr.sbin/dtrace/../../../lib/libelf -o dtrace dtrace.o -ldtrace -ly -ll -lproc -lctf -lelf -lz gzip -cn /src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.1 > dtrace.1.gz ===> cddl/usr.sbin/lockstat (all) cc -O -pipe -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.sbin/lockstat/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.sbin/lockstat/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/head -I/src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/lib/libproc/common -I/src/cddl/usr.sbin/lockstat/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.sbin/lockstat/../../../sys/cddl/contrib/opensolaris/compat -I/src/cddl/usr.sbin/lockstat/../../../sys -DNEED_ERRLOC -g -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/cmd/lockstat/lockstat.c cc1: warnings being treated as errors /src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/cmd/lockstat/lockstat.c: In function 'main': /src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/cmd/lockstat/lockstat.c:1095: warning: comparison is always true due to limited range of data type /src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/cmd/lockstat/lockstat.c:1389: warning: comparison is always true due to limited range of data type *** Error code 1 Stop in /src/cddl/usr.sbin/lockstat. *** Error code 1 Stop in /src/cddl/usr.sbin. *** Error code 1 Stop in /src/cddl. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-27 10:24:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-27 10:24:30 - ERROR: failed to build world TB --- 2009-05-27 10:24:30 - 1940.66 user 272.73 system 2669.09 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed May 27 19:24:39 2009 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F2151065670; Wed, 27 May 2009 19:24:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id DA4AF8FC16; Wed, 27 May 2009 19:24:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4RJOaXs058329; Wed, 27 May 2009 15:24:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4RJOa8G091658; Wed, 27 May 2009 15:24:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0CA2D7302F; Wed, 27 May 2009 15:24:35 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090527192436.0CA2D7302F@freebsd-current.sentex.ca> Date: Wed, 27 May 2009 15:24:35 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 19:24:39 -0000 TB --- 2009-05-27 18:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-27 18:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-05-27 18:40:00 - cleaning the object tree TB --- 2009-05-27 18:40:30 - cvsupping the source tree TB --- 2009-05-27 18:40:30 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-05-27 18:40:51 - building world TB --- 2009-05-27 18:40:51 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-27 18:40:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-27 18:40:51 - TARGET=arm TB --- 2009-05-27 18:40:51 - TARGET_ARCH=arm TB --- 2009-05-27 18:40:51 - TZ=UTC TB --- 2009-05-27 18:40:51 - __MAKE_CONF=/dev/null TB --- 2009-05-27 18:40:51 - cd /src TB --- 2009-05-27 18:40:51 - /usr/bin/make -B buildworld >>> World build started on Wed May 27 18:40:53 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.sbin/dtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.sbin/dtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/lib/libproc/common -I/src/cddl/usr.sbin/dtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.sbin/dtrace/../../../sys/cddl/contrib/opensolaris/compat -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -pthread -L/obj/arm/src/cddl/usr.sbin/dtrace/../../lib/libdtrace -L/obj/arm/src/cddl/usr.sbin/dtrace/../../lib/libproc -L/obj/arm/src/cddl/usr.sbin/dtrace/../../lib/libctf -L/obj/arm/src/cddl/usr.sbin/dtrace/../../../lib/libelf -o dtrace dtrace.o -ldtrace -ly -ll -lproc -lctf -lelf -lz gzip -cn /src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.1 > dtrace.1.gz ===> cddl/usr.sbin/lockstat (all) cc -O -pipe -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.sbin/lockstat/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.sbin/lockstat/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/head -I/src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/lib/libproc/common -I/src/cddl/usr.sbin/lockstat/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.sbin/lockstat/../../../sys/cddl/contrib/opensolaris/compat -I/src/cddl/usr.sbin/lockstat/../../../sys -DNEED_ERRLOC -g -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/cmd/lockstat/lockstat.c cc1: warnings being treated as errors /src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/cmd/lockstat/lockstat.c: In function 'main': /src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/cmd/lockstat/lockstat.c:1095: warning: comparison is always true due to limited range of data type /src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/cmd/lockstat/lockstat.c:1389: warning: comparison is always true due to limited range of data type *** Error code 1 Stop in /src/cddl/usr.sbin/lockstat. *** Error code 1 Stop in /src/cddl/usr.sbin. *** Error code 1 Stop in /src/cddl. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-27 19:24:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-27 19:24:35 - ERROR: failed to build world TB --- 2009-05-27 19:24:35 - 1937.95 user 273.95 system 2675.49 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Thu May 28 05:02:16 2009 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3732B106564A; Thu, 28 May 2009 05:02:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id D79038FC16; Thu, 28 May 2009 05:02:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4S52Dlv013363; Thu, 28 May 2009 01:02:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4S52Dik081840; Thu, 28 May 2009 01:02:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5623F7302F; Thu, 28 May 2009 01:02:13 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090528050213.5623F7302F@freebsd-current.sentex.ca> Date: Thu, 28 May 2009 01:02:13 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 05:02:16 -0000 TB --- 2009-05-28 04:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-28 04:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-05-28 04:00:00 - cleaning the object tree TB --- 2009-05-28 04:00:33 - cvsupping the source tree TB --- 2009-05-28 04:00:33 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-05-28 04:00:45 - building world TB --- 2009-05-28 04:00:45 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-28 04:00:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-28 04:00:45 - TARGET=arm TB --- 2009-05-28 04:00:45 - TARGET_ARCH=arm TB --- 2009-05-28 04:00:45 - TZ=UTC TB --- 2009-05-28 04:00:45 - __MAKE_CONF=/dev/null TB --- 2009-05-28 04:00:45 - cd /src TB --- 2009-05-28 04:00:45 - /usr/bin/make -B buildworld >>> World build started on Thu May 28 04:00:49 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc1: warnings being treated as errors /src/usr.bin/ee/../../contrib/ee/ee.c: In function 'out_char': /src/usr.bin/ee/../../contrib/ee/ee.c:957: warning: comparison is always true due to limited range of data type /src/usr.bin/ee/../../contrib/ee/ee.c:961: warning: comparison is always false due to limited range of data type /src/usr.bin/ee/../../contrib/ee/ee.c:967: warning: comparison is always false due to limited range of data type /src/usr.bin/ee/../../contrib/ee/ee.c: In function 'len_char': /src/usr.bin/ee/../../contrib/ee/ee.c:995: warning: comparison is always true due to limited range of data type /src/usr.bin/ee/../../contrib/ee/ee.c:1001: warning: comparison is always false due to limited range of data type *** Error code 1 Stop in /src/usr.bin/ee. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-28 05:02:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-28 05:02:13 - ERROR: failed to build world TB --- 2009-05-28 05:02:13 - 2841.54 user 358.69 system 3732.62 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Thu May 28 23:20:10 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BE24106564A for ; Thu, 28 May 2009 23:20:10 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id F27EE8FC0A for ; Thu, 28 May 2009 23:20:09 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id n4SNK8Sx043402 for ; Thu, 28 May 2009 18:20:08 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1243552808; bh=JN6OEX02TJvqJRbvHXuZo8oPKImHTqdnatjCw6K2LJc=; h=Date:From:Message-Id:To:Subject; b=KQD7LVFas3OOiKcM8roivVbNMlmNN4NDjWjScgZ/IQwPqulFghkYdUc5cRSzuKXsA 5eCmDJnrgNgupNzAFrXFoJh1XK9gImC7iDmNeII/wk3JOt+3Lk7fcuPJRhqqADP/SQ EahlgtN74fgXBE1wxu9xDXc0xgNBWR93s811cLLE= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id n4SNK87M043401 for freebsd-arm@freebsd.org; Thu, 28 May 2009 18:20:08 -0500 (CDT) (envelope-from tinguely) Date: Thu, 28 May 2009 18:20:08 -0500 (CDT) From: Mark Tinguely Message-Id: <200905282320.n4SNK87M043401@casselton.net> To: freebsd-arm@freebsd.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Thu, 28 May 2009 18:20:08 -0500 (CDT) Subject: cache corruption patch 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: Thu, 28 May 2009 23:20:10 -0000 There has been several occurrences of memory corruption in ARM due to caching issues. A couple recent examples are problems with the SATA drive and new USB code. This patch tracks kernel mapped pages and detects when they are shared with existing user mapped pages and other kernel mapped pages. This patch has gone through some refinement in the last couple days with feed back from testers and is getting ready for being committed before the FreeBSD 8.0 freeze. This patch should allow the removal of added cache invalidation commands to the dma. The patch is located at: http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff For those interested, I can give a long explanation of the patch. --Mark Tinguely From owner-freebsd-arm@FreeBSD.ORG Sat May 30 13:24:13 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33294106566B for ; Sat, 30 May 2009 13:24:13 +0000 (UTC) (envelope-from gballet@gmail.com) Received: from mail-fx0-f163.google.com (mail-fx0-f163.google.com [209.85.220.163]) by mx1.freebsd.org (Postfix) with ESMTP id B3AA18FC12 for ; Sat, 30 May 2009 13:24:12 +0000 (UTC) (envelope-from gballet@gmail.com) Received: by mail-fx0-f163.google.com with SMTP id 7so210948fxm.43 for ; Sat, 30 May 2009 06:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/+EKCOvaYVfWlJjyVDhwrVrjnSl1OLpf4uBIDFfvKFY=; b=kRR4zIjv7wodglrjsbUaWL8gj+yZ4j9/0hGYhfOXo73eHGCxHkPMsE2fFSqrR0HSaX Wh/sXjvXU+jzARse4YtDAF7j+NUcBQY5w1zbj1yQ9ene4geGyh4cR0YgzxiDKNRcPhU/ qaUvgcwV87UfXCprBQuSJ99MAmPb9RqS8drBE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AfQ/uzd413wO56KRV9PEsI32rHBuaVZVGsS00ntGRoCBwREfDNG255HYQ/nd9nEpDn /5SpVllRRBU67CbuFnwsQ17VcgylvySOm7qrGUzK5g2ktSkAQR3gM447YnrYaPG2zD+Z LBryewFSpkTC47IYIzYnSgdNyzFItLgwGiHHo= MIME-Version: 1.0 Received: by 10.204.66.135 with SMTP id n7mr3549504bki.155.1243689852325; Sat, 30 May 2009 06:24:12 -0700 (PDT) In-Reply-To: <20090521.145552.410235390.imp@bsdimp.com> References: <20090521.145552.410235390.imp@bsdimp.com> Date: Sat, 30 May 2009 13:24:12 +0000 Message-ID: From: Guillaume Ballet To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: LMA != VMA when compiling a kernel 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, 30 May 2009 13:24:13 -0000 > : Hence, I have been trying to set the ELF file sections' VMAs to > : something starting with 0xC and the LMAs to something starting with > : 0x8. It turns out that just setting KERNPHYSADDR and KERNVIRTADDR is > : not enough >.< If found a way to do this by chaning the script linker > : and adding AT after each section declaration, and it works fine. But > : it's tedious, hacky and lots of hardcoded values only work with my > : platform. > > Want to share? There's not much to share actually: I tried to use the AT keyword in the script linker. What I did was essentially: --- conf/ldscript.arm 2009-05-30 14:05:44.000000000 +0000 +++ conf/ldscript.arm.lma 2009-05-30 14:05:24.000000000 +0000 @@ -8,7 +8,7 @@ { /* Read-only sections, merged into text segment: */ . = KERNVIRTADDR + SIZEOF_HEADERS; - .text : AT(KERNPHYSADDR + SIZEOF_HEADERS) + .text : { *(.text) *(.stub) Doing so, I was able to change the LMA for the text section. The problem is that address arithmetic doesn't seem to work that well inside AT() - so at this moment I am unable to do this for _every_ section. I'm sure it should be possible, but haven't found the time to study this just yet. I don't think I will investigate this any further: Indeed, locore.S sets up a temporary TLB system to be able to access virtual addresses during boot. If someones knows the syntax to do address calculations inside AT(), however, I am interested nonetheless :) I was thinking about using something like MEMORY, but that idea needs some thinking through. > > Also, while a secondary boot loader makes sense in the higher end > booting environment where you have lots of storage (say an SD or CF > card), it doesn't make so much sense for a more constrained boot a > ramdisk from flash setup. I am indeed running from SD card. I face two choices: My first choice is to load everything with u-boot prior to starting the kernel. The other one is to have the whole loader(8) facility. Since the first choice requires some tedious typing in u-boot, I would love to have a loader(8) script to do all the dirty work for me :D But it can wait. Cheers, Guillaume From owner-freebsd-arm@FreeBSD.ORG Sat May 30 13:26:59 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8C46106566B for ; Sat, 30 May 2009 13:26:59 +0000 (UTC) (envelope-from gballet@gmail.com) Received: from mail-fx0-f163.google.com (mail-fx0-f163.google.com [209.85.220.163]) by mx1.freebsd.org (Postfix) with ESMTP id 08F878FC13 for ; Sat, 30 May 2009 13:26:58 +0000 (UTC) (envelope-from gballet@gmail.com) Received: by fxm7 with SMTP id 7so211924fxm.43 for ; Sat, 30 May 2009 06:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nKzgXMaWkTNvoQbd6KOeanbnRFgOjnS2CKz64JGNB80=; b=Yc2amFDEqFu9lvDjpgdV4bEW/uwlTHyOGZZWf7ZmI5803k/tLXBCfvzPUfI0ejoJQB gk45HXaD8X3V+VylvJ+DU7rFZd7pLvNHF/dwPYbb769uymA7Wpiu58IJCgmo8wvnFuWM gAeIe1hZwtB+lhibTAir3vT9nhNf6e/YdfJig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FXx7slHKnv2WndudSD5APcIwkF4m9gHTYtDgCSPdkYoB6LyGiWmHxLk1x/4Mt4RsYb SYEkcSBn549d036VOT9kivRJfZF89aDT22GvrZ6o/WdTG0LWN4Cu7T9imX7fT5H4ww1H 4gGsLwNv3puuGffyTH3vQTtQb+xdCnXs2iU/8= MIME-Version: 1.0 Received: by 10.204.50.195 with SMTP id a3mr3513290bkg.123.1243690017976; Sat, 30 May 2009 06:26:57 -0700 (PDT) In-Reply-To: <20090522010439.1ae3d8c1.stas@FreeBSD.org> References: <20090522010439.1ae3d8c1.stas@FreeBSD.org> Date: Sat, 30 May 2009 13:26:57 +0000 Message-ID: From: Guillaume Ballet To: Stanislav Sedov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: LMA != VMA when compiling a kernel 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, 30 May 2009 13:26:59 -0000 > > Does beagleboard use PXA cpu? I know only one place where the physical > memory location for PXA is hardcoded, and I belive it should work fine > after changing it... > Actually, it's based on the Cortex-A8, not Xscale. Still, my aim is obviously to hardcode as little as possible :) From owner-freebsd-arm@FreeBSD.ORG Sat May 30 13:34:23 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2CE5106566B for ; Sat, 30 May 2009 13:34:23 +0000 (UTC) (envelope-from gballet@gmail.com) Received: from mail-fx0-f163.google.com (mail-fx0-f163.google.com [209.85.220.163]) by mx1.freebsd.org (Postfix) with ESMTP id 46FE28FC17 for ; Sat, 30 May 2009 13:34:23 +0000 (UTC) (envelope-from gballet@gmail.com) Received: by fxm7 with SMTP id 7so214783fxm.43 for ; Sat, 30 May 2009 06:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kkkdYcq/vxMVymEc4COjRYAK6zRA4YruzG2A4K63ELk=; b=kZ8HLYYBSuPfc3rlfsDXY1n2C9Ttmd0NvNUMLMH1rzrU+6LrRyTPRoxMYtw2d0Bb0u Eo6fYPVL1JSpmOIlqSZORnn1DWbMUl4hpxSQvbujLkYEVzk8CQZp5tiTlgX6bQMDeVw+ N0qosf6g75HNZt0wmz39U2Ano24zZvBpr3tZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mrJ3CDdWRHfSXiPPWKRhC7QXMYnI4FnSm9PEBvEtMKvY2uPKBYS+Ev4BTKmAZvt780 HuSqoFY/1BjK2ZCAoBtsI9sejZcdAQicXoPsTzCqQHKwMSXJaDGQNz7js7evOzE8qANA jYDIFKpyKncMU/5IRagk/bjQQZX1aDp7o3XxU= MIME-Version: 1.0 Received: by 10.204.55.200 with SMTP id v8mr3559573bkg.54.1243690462342; Sat, 30 May 2009 06:34:22 -0700 (PDT) In-Reply-To: References: Date: Sat, 30 May 2009 13:34:22 +0000 Message-ID: From: Guillaume Ballet To: Rafal Jaworowski Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: LMA != VMA when compiling a kernel 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, 30 May 2009 13:34:24 -0000 On Sat, May 23, 2009 at 6:43 PM, Rafal Jaworowski wrote: > > On 2009-05-21, at 22:18, Guillaume Ballet wrote: > >> I am still working on a port of FreeBSD to the beagleboard, and am >> currently working on enabling the VM. So far, I have loaded the kernel >> at phys_addr = virt_addr = 0x80000000, because that is where the RAM >> is. However, when enabling the VM, I would like the kernel virtual >> addresses to start with 0xC0000000 as they do on most other platform. >> >> Hence, I have been trying to set the ELF file sections' VMAs to >> something starting with 0xC and the LMAs to something starting with >> 0x8. It turns out that just setting KERNPHYSADDR and KERNVIRTADDR is >> not enough >.< If found a way to do this by chaning the script linker >> and adding AT after each section declaration, and it works fine. But >> it's tedious, hacky and lots of hardcoded values only work with my >> platform. > > What exactly are your problems with getting 0xC0000000 as the KVA base? It > seems that all our current ARM variations follow this route and they all use > a single linker script, so there shouldn't be major problems doing likewise > with yet another port.. The problem is not setting 0xC0000000 as the KVA base, it's that when KVA != KPA, the ELF header creates a file that has KVA == KLA anyway. Now, as I found out, most of the problems can be circumvented by setting up a temporary TLB system so that the startup code can still access its data segments even though the final VM system has not been initialized. The last remaining problem I face is that the loader (not loader(8) at the moment) needs to know the physical address at which the kernel must be loaded. But since KVA==LMA in the ELF header, some information is lost as far as I know. Now, if the loader for other boards is indeed able to extract that piece of information from the ELF header itself, I would love to get some pointers to the solution :) > > The loader(8) entity is separate from how the kernel is linked, so I don't > think that problems with kernel virtual addresses you mention could be > worked around at the loader(8) level. Kernel linking/mapping should be > addressed independently of any booting method involved. > I agree, they should :P I am surely not searching at the right location, but I haven't found anything like a complete loader + boot stages in the source tree. Where should I look? I wonder if most system start in locore.S with the MMU already enabled from the loader, or most of them use the one that is built from scratch in that file?