From owner-freebsd-arm@FreeBSD.ORG Sun Feb 24 17:56:49 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E4DD34A9; Sun, 24 Feb 2013 17:56:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A01A6B4C; Sun, 24 Feb 2013 17:56:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1OHugmW046678; Sun, 24 Feb 2013 12:56:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1OHugiE046665; Sun, 24 Feb 2013 17:56:42 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Feb 2013 17:56:42 GMT Message-Id: <201302241756.r1OHugiE046665@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 17:56:50 -0000 TB --- 2013-02-24 16:20:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-24 16:20:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-24 16:20:19 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-24 16:20:19 - cleaning the object tree TB --- 2013-02-24 16:20:19 - /usr/local/bin/svn stat /src TB --- 2013-02-24 16:20:23 - At svn revision 247223 TB --- 2013-02-24 16:20:24 - building world TB --- 2013-02-24 16:20:24 - CROSS_BUILD_TESTING=YES TB --- 2013-02-24 16:20:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-24 16:20:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-24 16:20:24 - SRCCONF=/dev/null TB --- 2013-02-24 16:20:24 - TARGET=arm TB --- 2013-02-24 16:20:24 - TARGET_ARCH=arm TB --- 2013-02-24 16:20:24 - TZ=UTC TB --- 2013-02-24 16:20:24 - __MAKE_CONF=/dev/null TB --- 2013-02-24 16:20:24 - cd /src TB --- 2013-02-24 16:20:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Feb 24 16:20:29 UTC 2013 >>> 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 [...] mkdep -f .depend -a -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 /src/sbin/fsck_ffs/dir.c /src/sbin/fsck_ffs/ea.c /src/sbin/fsck_ffs/fsutil.c /src/sbin/fsck_ffs/inode.c /src/sbin/fsck_ffs/main.c /src/sbin/fsck_ffs/pass1.c /src/sbin/fsck_ffs/pass1b.c /src/sbin/fsck_ffs/pass2.c /src/sbin/fsck_ffs/pass3.c /src/sbin/fsck_ffs/pass4.c /src/sbin/fsck_ffs/pass5.c /src/sbin/fsck_ffs/setup.c /src/sbin/fsck_ffs/suj.c /src/sbin/fsck_ffs/utilities.c /src/sbin/fsck_ffs/gjournal.c /src/sbin/fsck_ffs/../mount/getmntopts.c echo fsck_ffs: /obj/arm.arm/src/tmp/usr/lib/libc.a /obj/arm.arm/src/tmp/usr/lib/libufs.a >> .depend cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:452: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/arm.arm/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-24 17:56:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-24 17:56:42 - ERROR: failed to build world TB --- 2013-02-24 17:56:42 - 4685.55 user 828.98 system 5782.79 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Feb 24 23:01:37 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 72BD3F49; Sun, 24 Feb 2013 23:01:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4469BB69; Sun, 24 Feb 2013 23:01:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1ON1aDk049499; Sun, 24 Feb 2013 18:01:36 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1ON1aDG049495; Sun, 24 Feb 2013 23:01:36 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Feb 2013 23:01:36 GMT Message-Id: <201302242301.r1ON1aDG049495@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 23:01:37 -0000 TB --- 2013-02-24 21:20:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-24 21:20:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-24 21:20:19 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-24 21:20:19 - cleaning the object tree TB --- 2013-02-24 21:24:35 - /usr/local/bin/svn stat /src TB --- 2013-02-24 21:24:38 - At svn revision 247237 TB --- 2013-02-24 21:24:39 - building world TB --- 2013-02-24 21:24:39 - CROSS_BUILD_TESTING=YES TB --- 2013-02-24 21:24:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-24 21:24:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-24 21:24:39 - SRCCONF=/dev/null TB --- 2013-02-24 21:24:39 - TARGET=arm TB --- 2013-02-24 21:24:39 - TARGET_ARCH=arm TB --- 2013-02-24 21:24:39 - TZ=UTC TB --- 2013-02-24 21:24:39 - __MAKE_CONF=/dev/null TB --- 2013-02-24 21:24:39 - cd /src TB --- 2013-02-24 21:24:39 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Feb 24 21:24:44 UTC 2013 >>> 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 [...] mkdep -f .depend -a -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 /src/sbin/fsck_ffs/dir.c /src/sbin/fsck_ffs/ea.c /src/sbin/fsck_ffs/fsutil.c /src/sbin/fsck_ffs/inode.c /src/sbin/fsck_ffs/main.c /src/sbin/fsck_ffs/pass1.c /src/sbin/fsck_ffs/pass1b.c /src/sbin/fsck_ffs/pass2.c /src/sbin/fsck_ffs/pass3.c /src/sbin/fsck_ffs/pass4.c /src/sbin/fsck_ffs/pass5.c /src/sbin/fsck_ffs/setup.c /src/sbin/fsck_ffs/suj.c /src/sbin/fsck_ffs/utilities.c /src/sbin/fsck_ffs/gjournal.c /src/sbin/fsck_ffs/../mount/getmntopts.c echo fsck_ffs: /obj/arm.arm/src/tmp/usr/lib/libc.a /obj/arm.arm/src/tmp/usr/lib/libufs.a >> .depend cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:452: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/arm.arm/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-24 23:01:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-24 23:01:36 - ERROR: failed to build world TB --- 2013-02-24 23:01:36 - 4686.91 user 840.68 system 6076.77 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon Feb 25 02:31:05 2013 Return-Path: Delivered-To: FreeBSD-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4EED9B37 for ; Mon, 25 Feb 2013 02:31:05 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id EEA456D0 for ; Mon, 25 Feb 2013 02:31:01 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r1P2Ui9B043322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 25 Feb 2013 03:30:44 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id r1P2UfGb092388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Feb 2013 03:30:41 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id r1P2Ufkt039802; Mon, 25 Feb 2013 03:30:41 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r1P2Uf09039801; Mon, 25 Feb 2013 03:30:41 +0100 (CET) (envelope-from ticso) Date: Mon, 25 Feb 2013 03:30:41 +0100 From: Bernd Walter To: FreeBSD-arm@freebsd.org Subject: Re: TFT Panel trouble with Raspi Message-ID: <20130225023041.GB39037@cicely7.cicely.de> References: <20130221041011.GB12189@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130221041011.GB12189@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Bernd Walter X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 02:31:05 -0000 On Thu, Feb 21, 2013 at 05:10:12AM +0100, Bernd Walter wrote: > I'm using the folloging Image: > http://www.peach.ne.jp/archives/rpi/freebsd-pi-clang-20130210.img.gz > With this Panel: > http://www.chalk-elec.com/?page_id=1280#!/~/product/category=3094861&id=14647630 > > Resolution is 1024x600 pixel with an HDMI adapter. > > Under Linux at first it didn't display anything at all. > The following config.txt was required: > hdmi_ignore_edid=0xa5000080 > hdmi_group=2 > hdmi_mode=16 > overscan_top=-40 > overscan_bottom=125 > > This sets 1024x768 and tunes overscan area. > Nice HDMI crap only knows defined resolutions... > Without overscan values the display starts at the right top postion, but > the 168 excessive bottom lines are missing on display - no surprise. > Descriptions claims those to be pixels, so those values don't make 100% > sense to me as math says the result to be 683 pixel, but basicly the > result looks good. > Considering the description it doesn't make sense to tamper with top > values as it is correctly aligned without overscan. > > With FreeBSD however those values won't work. > The result is that at top there is empty space and missing lines at > the bottom. > If I set 800x600 resolution everything looks good, but width isn't used > completely. > With description I would assume that setting bottom to 168 should give > the right result, but setting bottom to 168 cuts 84 lines at > bottom and 84 lines at top. > With bottom to 336 the bottom is alligned correctly but missing 168 > lines on top. > With bottom to 336 and top to -168 the result is the same as with > bottom at 168 and top at 0. > > Under Linux the result is different. > Setting bottom to 168 cuts many more pixel at bottom and less pixel > at top - sigh, so much about their documentation. > I would guess it cuts about 3x at bottom and 1x at top. > Adding top=-10 seems to add symetrical pixel at top and bottom. > Strange enough - booting Linux with the above vendor supplied config > shows this: > [ 0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1024 bcm2708_fb.fbheight=683 bcm2708.boardrev=0x3 bcm2708.serial=0xda48bc18 smsc95xx.macaddr=B8:27:EB:48:BC:18 sdhci-bcm2708.emmc_clock_freq=100000000 vc_mem.mem_base=0xec00000 vc_mem.mem_size=0x10000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait > fbheigh = 683, but I would say that I would have noticed 83 missing > pixels, although it agrees with my math about those values to be pixels. > > Btw - on my LG TV with 1366x768 pixel (it announces as 1360x768 and > scales to 1366 sigh) FreeBSD was missing bottom lines as well. > I know because I plugged it into my TV to boot the FreeBSD for the first > time, didn't get a login and thought there was only a getty running on > serial console. > I didn't debug there any further. > Today with the TFT-Panel I saw that it is indeed running a getty. > Whatever bad magic there is - Linux knows it and FreeBSD has problems. This point was wrong. Everthing looks Ok on the LG TV. But setting overscan_bottom also reduces same amount of pixel on top as on bottom and not just at the bottom as expected. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Feb 25 08:50:39 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8A43EDD5; Mon, 25 Feb 2013 08:50:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 62CDA74A; Mon, 25 Feb 2013 08:50:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1P8ocND030666; Mon, 25 Feb 2013 03:50:38 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1P8ocFf030661; Mon, 25 Feb 2013 08:50:38 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 25 Feb 2013 08:50:38 GMT Message-Id: <201302250850.r1P8ocFf030661@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 08:50:39 -0000 TB --- 2013-02-25 07:10:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-25 07:10:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-25 07:10:16 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-25 07:10:16 - cleaning the object tree TB --- 2013-02-25 07:12:20 - /usr/local/bin/svn stat /src TB --- 2013-02-25 07:12:23 - At svn revision 247251 TB --- 2013-02-25 07:12:24 - building world TB --- 2013-02-25 07:12:24 - CROSS_BUILD_TESTING=YES TB --- 2013-02-25 07:12:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-25 07:12:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-25 07:12:24 - SRCCONF=/dev/null TB --- 2013-02-25 07:12:24 - TARGET=arm TB --- 2013-02-25 07:12:24 - TARGET_ARCH=arm TB --- 2013-02-25 07:12:24 - TZ=UTC TB --- 2013-02-25 07:12:24 - __MAKE_CONF=/dev/null TB --- 2013-02-25 07:12:24 - cd /src TB --- 2013-02-25 07:12:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Feb 25 07:12:28 UTC 2013 >>> 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 [...] mkdep -f .depend -a -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 /src/sbin/fsck_ffs/dir.c /src/sbin/fsck_ffs/ea.c /src/sbin/fsck_ffs/fsutil.c /src/sbin/fsck_ffs/inode.c /src/sbin/fsck_ffs/main.c /src/sbin/fsck_ffs/pass1.c /src/sbin/fsck_ffs/pass1b.c /src/sbin/fsck_ffs/pass2.c /src/sbin/fsck_ffs/pass3.c /src/sbin/fsck_ffs/pass4.c /src/sbin/fsck_ffs/pass5.c /src/sbin/fsck_ffs/setup.c /src/sbin/fsck_ffs/suj.c /src/sbin/fsck_ffs/utilities.c /src/sbin/fsck_ffs/gjournal.c /src/sbin/fsck_ffs/../mount/getmntopts.c echo fsck_ffs: /obj/arm.arm/src/tmp/usr/lib/libc.a /obj/arm.arm/src/tmp/usr/lib/libufs.a >> .depend cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:452: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/arm.arm/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-25 08:50:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-25 08:50:38 - ERROR: failed to build world TB --- 2013-02-25 08:50:38 - 4695.34 user 834.30 system 6021.73 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon Feb 25 11:06:43 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E3C6D109 for ; Mon, 25 Feb 2013 11:06:43 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id D709AE62 for ; Mon, 25 Feb 2013 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1PB6hFa066520 for ; Mon, 25 Feb 2013 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1PB6hPL066518 for freebsd-arm@FreeBSD.org; Mon, 25 Feb 2013 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Feb 2013 11:06:43 GMT Message-Id: <201302251106.r1PB6hPL066518@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 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 11:06:43 -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/175803 arm building xdev for arm failing o arm/175605 arm please fix build binutils-2.23.1 in raspberry pi o arm/174461 arm [patch] Fix off-by-one in arm9/arm10 cache maintenance o arm/173617 arm Dreamplug exhibits eSATA file corruption using network o kern/171096 arm [arm][xscale][ixp]Allow 16bit access on PCI bus o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) p arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on p arm/134338 arm [patch] Lock GPIO accesses on ixp425 18 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Feb 25 18:40:01 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A53088AA for ; Mon, 25 Feb 2013 18:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 73262E3C for ; Mon, 25 Feb 2013 18:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1PIe1w1071760 for ; Mon, 25 Feb 2013 18:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1PIe1Ax071759; Mon, 25 Feb 2013 18:40:01 GMT (envelope-from gnats) Resent-Date: Mon, 25 Feb 2013 18:40:01 GMT Resent-Message-Id: <201302251840.r1PIe1Ax071759@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-arm@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Josef Larsson Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9BC84786 for ; Mon, 25 Feb 2013 18:32:12 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 8CC07DEE for ; Mon, 25 Feb 2013 18:32:12 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.5/8.14.5) with ESMTP id r1PIWBZl086570 for ; Mon, 25 Feb 2013 18:32:11 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.5/8.14.5/Submit) id r1PIWBqO086569; Mon, 25 Feb 2013 18:32:11 GMT (envelope-from nobody) Message-Id: <201302251832.r1PIWBqO086569@red.freebsd.org> Date: Mon, 25 Feb 2013 18:32:11 GMT From: Josef Larsson To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: arm/176424: Compiler warning, TARGET_ARCH=armv6, make MALLOC_PRODUCTION=yes buildworld X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 18:40:01 -0000 >Number: 176424 >Category: arm >Synopsis: Compiler warning, TARGET_ARCH=armv6, make MALLOC_PRODUCTION=yes buildworld >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Feb 25 18:40:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Josef Larsson >Release: FreeBSD server 9.1-RELEASE >Organization: >Environment: FreeBSD server 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: When doing make MALLOC_PRODUCTION=yes buildworld, a compiler warning will be issued which halts compilation. The warning is issued because line 463 of head/sbin/fsck_ffs/fsutil.c uses "%ld" and "%lld", for variables of type time_t, which I think are of the type int in this case when compiling for armv6. >How-To-Repeat: Following this guide to step 13 should do the trick: http://ogris.de/howtos/freebsd-raspberry.html >Fix: Typecasting like this solved the problem: printf("%21s:%8ld %2ld.%ld%% %8lld msec %2lld.%lld%%\n", buftype[i], (long)readcnt[i], (long) readcnt[i] * 100 / diskreads, (long) (readcnt[i] * 1000 / diskreads) % 10, (long long) msec, (long long) msec * 100 / totalmsec, (long long) (msec * 1000 / totalmsec) % 10); >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Mon Feb 25 19:10:01 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8DFB89CD for ; Mon, 25 Feb 2013 19:10:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 64E1BFD2 for ; Mon, 25 Feb 2013 19:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1PJA17q076872 for ; Mon, 25 Feb 2013 19:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1PJA1rI076871; Mon, 25 Feb 2013 19:10:01 GMT (envelope-from gnats) Date: Mon, 25 Feb 2013 19:10:01 GMT Message-Id: <201302251910.r1PJA1rI076871@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: Ian Lepore Subject: Re: arm/176424: Compiler warning, TARGET_ARCH=armv6, make MALLOC_PRODUCTION=yes buildworld X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Ian Lepore List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 19:10:01 -0000 The following reply was made to PR arm/176424; it has been noted by GNATS. From: Ian Lepore To: Josef Larsson Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: arm/176424: Compiler warning, TARGET_ARCH=armv6, make MALLOC_PRODUCTION=yes buildworld Date: Mon, 25 Feb 2013 12:08:22 -0700 On Mon, 2013-02-25 at 18:32 +0000, Josef Larsson wrote: > >Number: 176424 > >Category: arm > >Synopsis: Compiler warning, TARGET_ARCH=armv6, make MALLOC_PRODUCTION=yes buildworld > >Confidential: no > >Severity: non-critical > >Priority: low > >Responsible: freebsd-arm > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Mon Feb 25 18:40:00 UTC 2013 > >Closed-Date: > >Last-Modified: > >Originator: Josef Larsson > >Release: FreeBSD server 9.1-RELEASE > >Organization: > >Environment: > FreeBSD server 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > >Description: > When doing make MALLOC_PRODUCTION=yes buildworld, a compiler warning will be issued which halts compilation. The warning is issued because line 463 of head/sbin/fsck_ffs/fsutil.c uses "%ld" and "%lld", for variables of type time_t, which I think are of the type int in this case when compiling for armv6. > >How-To-Repeat: > Following this guide to step 13 should do the trick: > http://ogris.de/howtos/freebsd-raspberry.html > >Fix: > Typecasting like this solved the problem: > > printf("%21s:%8ld %2ld.%ld%% %8lld msec %2lld.%lld%%\n", buftype[i], (long)readcnt[i], (long) readcnt[i] * 100 / diskreads, (long) (readcnt[i] * 1000 / diskreads) % 10, (long long) msec, (long long) msec * 100 / totalmsec, (long long) (msec * 1000 / totalmsec) % 10); FYI, this was fixed with r247269. Also, there's no need to use MALLOC_PRODUCTION anymore, a change about a month ago fixed the performance and memory-hogging problems. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Feb 26 16:02:40 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 324905FD for ; Tue, 26 Feb 2013 16:02:40 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by mx1.freebsd.org (Postfix) with ESMTP id C2A38CCF for ; Tue, 26 Feb 2013 16:02:39 +0000 (UTC) Received: by mail-qe0-f51.google.com with SMTP id nd7so1801633qeb.38 for ; Tue, 26 Feb 2013 08:02:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=PybeTEiZMnbtGyVqsfg0DL154H6lAQ6pjZRp5fy2EIg=; b=k/cON1SWUH2Z102K4EmAMBix9n7vuDuN9dSpteF2QBbWVsAUqUbbyZQXaoTTnwTUjK wJGTttGx/gP2ItEDdxLP8bT7qaGmrzt8Hr2ReRzqikRIHfK8a+yLx45sQHLxdYmBjSnR QezqqYDT4yYjEGmCgigxmROHvcagdrLegDFDrzS+zR3CRoLZsPr6fh3wl52V+EZxsV7Z QMi/dxhiPpqoV5Be/o+KYjgRO7mJWoKa0vTLovMn+3QwQis5Q6umxz8KBwZGptjxHXkN rna83VVv3OkBewMTBqpKCwbY+G6V6xDQ8w5rWaj4OrPG21eEFeMyVLVgso0i43uQWggo qS1A== MIME-Version: 1.0 X-Received: by 10.224.33.208 with SMTP id i16mr2699115qad.45.1361894553490; Tue, 26 Feb 2013 08:02:33 -0800 (PST) Received: by 10.49.87.193 with HTTP; Tue, 26 Feb 2013 08:02:33 -0800 (PST) In-Reply-To: References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> Date: Wed, 27 Feb 2013 00:02:33 +0800 Message-ID: Subject: Re: Unable to copy DTB into module directory From: Alie Tan To: Tim Kientzle X-Gm-Message-State: ALoCoQnTz1pkNRXTAACpMp5Sz9Q/uguY9SLWrETnJwKMhW9oMmYyS1IGQ9cknZfYf2nXoOsts3US Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 16:02:40 -0000 I have tested this with my own script, your script and gonzo's script, all works fine. On Sunday, February 24, 2013, Tim Kientzle wrote: >> >> >> >> I just built RasPi image and keeps getting this message: >> >> >> >> "unable to copy DTB into module directory" >> >> >> >> then the raspi reboot again and again. >> > >> > Try backing out r247045 and see if that fixes >> > it for you. >> > >> >> Fyi, Reverting r247045 didn't help my proble :-( >> Sorry for incomplete information. Reverting r247045 removes "unable to copy DTB into module directory" error message but my raspi still keeps rebooting after boot loader > > I believe that r247201 fixes the bug I introduced > with r247045 and should allow RPi to boot cleanly > again. (Though I seem to have some other problem > locally that I need to track down=85) > > This should also make it possible to have U-Boot > pick up the FDT from the RPi boot code > (by adding "fdt addr 0x100" to the right place in uEnv.txt > or the u-boot loader script) and remove that command > from loader.rc. If U-Boot knows about the FDT, then > ubldr should pick it up automatically now. > I've made the necessary adjustment to my build scripts; > it should be a very small tweak to Oleksandr's > as well. > > Let me know if this works for you. > > Tim > > From owner-freebsd-arm@FreeBSD.ORG Tue Feb 26 17:10:03 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 338DE382 for ; Tue, 26 Feb 2013 17:10:03 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id ECF9010BE for ; Tue, 26 Feb 2013 17:10:00 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1QH3ZH1094143 for ; Tue, 26 Feb 2013 12:03:35 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Tue, 26 Feb 2013 12:03:35 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: Raspberry Pi Network Data Message-ID: <20130226120335.6928b473@ivory.wynn.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 17:10:03 -0000 Greeting- For a couple of days I have been building software from ports. Mostly these builds are for things I just want to try on the Pi, or Bone, but the secondary reason is to put some pre-compiled packages up for those that do not have the patience to build them. While my Pi has been stable for a couple of weeks I have noted that sometimes it stops talking on the network. At those times if I get on the console and ifconfig down and back up the interface it starts talking on the net just fine again. Last night I believe I found a link between disk i/o and network non-responsiveness. During a period of high disk i/o to the USB connected flash drive I lost network. The console had messages about retrys to the disk and the console was slow to respond. It took me for ever to get logged in because the console kept dropping characters while I typed. I am using usb-keyboard and composite video for the console. When I got logged in I still had trouble typing ifconfig ue0 down ; ifconfig ue0 up, but once I did everything went back to normal. Keyboard response was fine, disk i/o no longer seemed to be reporting errors and of course the network came back on line. I went to sleep with zoneminder building. Now 6 hours later I find the machine in the same state. Since the disk, keyboard, and ethernet are all usb devices could we have a bug in the usb sub-system? As soon as the ifconfig ue0 down happens the console keyboard becomes properly responsive again. Could we have some sort of interrupt problem going on here? This is food for thought for you kernel hackers. If there is anything you want me to specifically try or do the next time I have this problem, probably in the next 24 hours, please let me know. Your fellow ARM hacker, -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 April 19, 1775 An English attempt to confiscate guns from Americans triggered a successful revolution...... Dear Congress, that's a hint. From owner-freebsd-arm@FreeBSD.ORG Tue Feb 26 17:14:26 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8E7063F6 for ; Tue, 26 Feb 2013 17:14:26 +0000 (UTC) (envelope-from renato.golin@linaro.org) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by mx1.freebsd.org (Postfix) with ESMTP id 19C4210E4 for ; Tue, 26 Feb 2013 17:14:25 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id gm6so3251809lbb.40 for ; Tue, 26 Feb 2013 09:14:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=UcrULXqdd71WJLJObfwHtthnhWFV7wyk2tl1ioooi+k=; b=JKhMbI4CzxC4KM50czwi4yxWZ6BPp/wUrY0dDq76WstnGGI7GXlDZF6ydSan/bx1TM LGRUqdUutf7M5aV6+Karnf6uiNbGeVXznTafSb5dSvvgmZuiOJ9bl/15vx2R3fCLD17t aEMxBztijrhbVHOV9sOpPyg179TzxneCxnQwDoKv9dLEbVqMW5yA0mtT7uFu/4pqdFHP Kd8m32HlsR1YIO9x615Xq4y6e0Uous0x316Xg58ni/GZfs3wlQAsRfKBoB7HERt13wAT jrxAxwusvUoMjjJR9K7/1ZinPEjJiXxcg8IohGrdnKg+cA4iWmsV9eAthMCm+Xp3Tyg8 0ogg== MIME-Version: 1.0 X-Received: by 10.112.43.137 with SMTP id w9mr866928lbl.77.1361898859146; Tue, 26 Feb 2013 09:14:19 -0800 (PST) Received: by 10.112.99.38 with HTTP; Tue, 26 Feb 2013 09:14:19 -0800 (PST) Date: Tue, 26 Feb 2013 17:14:19 +0000 Message-ID: Subject: LLVM tests on FreeBSD+ARM From: Renato Golin To: freebsd-arm@freebsd.org X-Gm-Message-State: ALoCoQlK8nHh1kaNUi7PaQET/P768+CmJaaWVC9B5e6ijH5/VlNaN2IxdTdweg6Qmey5EG7nJe1i Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 17:14:26 -0000 Hi folks, I'm updating the LLVM docs to add the information that LLVM is, indeed, supported on ARM, Linux and FreeBSD. But I don't know how well tested LLVM is on FreeBSD. Does anyone run LLVM's check-all regularly on FreeBSD+ARM? Did anyone ever ran LLVM's test-suite (via LNT or otherwise) and have the report so I can compare with the Linux results? It should look like this: http://lab.llvm.org:8011/builders/clang-native-arm-lnt I'm mainly interested in ARMv7, Cortex-A9 and/or A15, but older info is also appreciated. Thanks, --renato From owner-freebsd-arm@FreeBSD.ORG Tue Feb 26 18:19:04 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 150C0277 for ; Tue, 26 Feb 2013 18:19:04 +0000 (UTC) (envelope-from millenia2000@hotmail.com) Received: from bay0-omc2-s21.bay0.hotmail.com (bay0-omc2-s21.bay0.hotmail.com [65.54.190.96]) by mx1.freebsd.org (Postfix) with ESMTP id 0362C15CA for ; Tue, 26 Feb 2013 18:19:03 +0000 (UTC) Received: from BAY165-DS19 ([65.54.190.124]) by bay0-omc2-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Feb 2013 10:17:58 -0800 X-EIP: [aQpsAQUrbhNVljd9hj8nZZbMNmYZs67UerWeZI140l4=] X-Originating-Email: [millenia2000@hotmail.com] Message-ID: From: Sean Cavanaugh To: "'Brett Wynkoop'" , References: <20130226120335.6928b473@ivory.wynn.com> In-Reply-To: <20130226120335.6928b473@ivory.wynn.com> Subject: RE: Raspberry Pi Network Data Date: Tue, 26 Feb 2013 13:17:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIdKWGla0Br0uh+m8ai259hszGCtJfuR/ug Content-Language: en-us X-OriginalArrivalTime: 26 Feb 2013 18:17:58.0274 (UTC) FILETIME=[9AD0DE20:01CE144D] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 18:19:04 -0000 > -----Original Message----- > From: owner-freebsd-arm@freebsd.org [mailto:owner-freebsd- > arm@freebsd.org] On Behalf Of Brett Wynkoop > Sent: Tuesday, February 26, 2013 12:04 PM > To: freebsd-arm@freebsd.org > Subject: Raspberry Pi Network Data > > Greeting- > > For a couple of days I have been building software from ports. Mostly these > builds are for things I just want to try on the Pi, or Bone, but the secondary > reason is to put some pre-compiled packages up for those that do not have > the patience to build them. > > While my Pi has been stable for a couple of weeks I have noted that > sometimes it stops talking on the network. At those times if I get on the > console and ifconfig down and back up the interface it starts talking on the > net just fine again. > > Last night I believe I found a link between disk i/o and network non- > responsiveness. During a period of high disk i/o to the USB connected flash > drive I lost network. The console had messages about retrys to the disk and > the console was slow to respond. It took me for ever to get logged in > because the console kept dropping characters while I typed. I am using usb- > keyboard and composite video for the console. > > When I got logged in I still had trouble typing ifconfig ue0 down ; ifconfig ue0 > up, but once I did everything went back to normal. > Keyboard response was fine, disk i/o no longer seemed to be reporting > errors and of course the network came back on line. > > I went to sleep with zoneminder building. Now 6 hours later I find the > machine in the same state. Since the disk, keyboard, and ethernet are all usb > devices could we have a bug in the usb sub-system? > > As soon as the ifconfig ue0 down happens the console keyboard becomes > properly responsive again. Could we have some sort of interrupt problem > going on here? > > This is food for thought for you kernel hackers. If there is anything you want > me to specifically try or do the next time I have this problem, probably in the > next 24 hours, please let me know. > > Your fellow ARM hacker, > > -Brett > Keep in mind that the network port, the SD card slot, and obviously the USB ports themselves are all on the same USB bus. That may be part of the issue. Definitely agree that it should be able to swap between them easier than manually shunting it. From owner-freebsd-arm@FreeBSD.ORG Tue Feb 26 18:52:16 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BA982925 for ; Tue, 26 Feb 2013 18:52:16 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 7155218CF for ; Tue, 26 Feb 2013 18:52:16 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UAPdK-0006uW-5k; Tue, 26 Feb 2013 18:52:10 +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 r1QIq7oX082417; Tue, 26 Feb 2013 11:52:07 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19Il/uXpzoc6hVEb+oMXSyj Subject: RE: Raspberry Pi Network Data From: Ian Lepore To: Sean Cavanaugh In-Reply-To: References: <20130226120335.6928b473@ivory.wynn.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Feb 2013 11:52:07 -0700 Message-ID: <1361904727.16937.133.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, 'Brett Wynkoop' X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 18:52:16 -0000 On Tue, 2013-02-26 at 13:17 -0500, Sean Cavanaugh wrote: > > > -----Original Message----- > > From: owner-freebsd-arm@freebsd.org [mailto:owner-freebsd- > > arm@freebsd.org] On Behalf Of Brett Wynkoop > > Sent: Tuesday, February 26, 2013 12:04 PM > > To: freebsd-arm@freebsd.org > > Subject: Raspberry Pi Network Data > > > > Greeting- > > > > For a couple of days I have been building software from ports. Mostly > these > > builds are for things I just want to try on the Pi, or Bone, but the > secondary > > reason is to put some pre-compiled packages up for those that do not have > > the patience to build them. > > > > While my Pi has been stable for a couple of weeks I have noted that > > sometimes it stops talking on the network. At those times if I get on the > > console and ifconfig down and back up the interface it starts talking on > the > > net just fine again. > > > > Last night I believe I found a link between disk i/o and network non- > > responsiveness. During a period of high disk i/o to the USB connected > flash > > drive I lost network. The console had messages about retrys to the disk > and > > the console was slow to respond. It took me for ever to get logged in > > because the console kept dropping characters while I typed. I am using > usb- > > keyboard and composite video for the console. > > > > When I got logged in I still had trouble typing ifconfig ue0 down ; > ifconfig ue0 > > up, but once I did everything went back to normal. > > Keyboard response was fine, disk i/o no longer seemed to be reporting > > errors and of course the network came back on line. > > > > I went to sleep with zoneminder building. Now 6 hours later I find the > > machine in the same state. Since the disk, keyboard, and ethernet are all > usb > > devices could we have a bug in the usb sub-system? > > > > As soon as the ifconfig ue0 down happens the console keyboard becomes > > properly responsive again. Could we have some sort of interrupt problem > > going on here? > > > > This is food for thought for you kernel hackers. If there is anything you > want > > me to specifically try or do the next time I have this problem, probably > in the > > next 24 hours, please let me know. > > > > Your fellow ARM hacker, > > > > -Brett > > > > Keep in mind that the network port, the SD card slot, and obviously the USB > ports themselves are all on the same USB bus. That may be part of the issue. > Definitely agree that it should be able to swap between them easier than > manually shunting it. Not the sd card, it has its own dedicated sdhci controller in the SoC. The only usb thing active on my rpi is the onboard hardware (hub and network interface) and it has a tendency to occasionally drop off the bus and return. Actually, it's not just the ethernet, the whole hub (onboard hub, not external) disappears and reappears. This happens intermittantly, sometimes several times a day. Twice it has failed to recover -- the hub never reattached until I rebooted. smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy ugen0.2: at usbus0 (disconnected) uhub1: at uhub0, port 1, addr 2 (disconnected) ugen0.3: at usbus0 (disconnected) smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: at uhub1, port 1, addr 3 (disconnected) smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy ukphy0: detached miibus0: detached Feb 26 03:13:05 rpi dhclient[246]: connection closed Feb 26 03:13:05 rpi dhclient[246]: exiting. Feb 26 03:13:05 rpi ntpd[519]: sendto(172.22.42.240) (fd=22): No route to host ugen0.2: at usbus0 uhub1: on usbus0 uhub1: MTT enabled uhub1: 3 ports with 2 removable, self powered Feb 26 03:13:06 rpi ntpd[519]: sendto(172.22.42.254) (fd=22): No route to host ugen0.3: at usbus0 smsc0: on usbus0 smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:33:7c:02 smsc0: chip 0xec00, rev. 0002 -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Feb 26 20:49:26 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5B1BC9B7; Tue, 26 Feb 2013 20:49:26 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id A40511EA3; Tue, 26 Feb 2013 20:49:25 +0000 (UTC) Received: from rnote.ddteam.net (206-62-135-95.pool.ukrtel.net [95.135.62.206]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 16AECC493A; Tue, 26 Feb 2013 22:49:17 +0200 (EET) Date: Tue, 26 Feb 2013 22:49:01 +0200 From: Aleksandr Rybalko To: Ian Lepore Subject: Re: Raspberry Pi Network Data Message-Id: <20130226224901.04164f9d.ray@freebsd.org> In-Reply-To: <1361904727.16937.133.camel@revolution.hippie.lan> References: <20130226120335.6928b473@ivory.wynn.com> <1361904727.16937.133.camel@revolution.hippie.lan> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, 'Brett Wynkoop' X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 20:49:26 -0000 On Tue, 26 Feb 2013 11:52:07 -0700 Ian Lepore wrote: > On Tue, 2013-02-26 at 13:17 -0500, Sean Cavanaugh wrote: > > > > > -----Original Message----- > > > From: owner-freebsd-arm@freebsd.org [mailto:owner-freebsd- > > > arm@freebsd.org] On Behalf Of Brett Wynkoop > > > Sent: Tuesday, February 26, 2013 12:04 PM > > > To: freebsd-arm@freebsd.org > > > Subject: Raspberry Pi Network Data > > > > > > Greeting- > > > > > > For a couple of days I have been building software from ports. > > > Mostly > > these > > > builds are for things I just want to try on the Pi, or Bone, but > > > the > > secondary > > > reason is to put some pre-compiled packages up for those that do > > > not have the patience to build them. > > > > > > While my Pi has been stable for a couple of weeks I have noted > > > that sometimes it stops talking on the network. At those times > > > if I get on the console and ifconfig down and back up the > > > interface it starts talking on > > the > > > net just fine again. > > > > > > Last night I believe I found a link between disk i/o and network > > > non- responsiveness. During a period of high disk i/o to the USB > > > connected > > flash > > > drive I lost network. The console had messages about retrys to > > > the disk > > and > > > the console was slow to respond. It took me for ever to get > > > logged in because the console kept dropping characters while I > > > typed. I am using > > usb- > > > keyboard and composite video for the console. > > > > > > When I got logged in I still had trouble typing ifconfig ue0 > > > down ; > > ifconfig ue0 > > > up, but once I did everything went back to normal. > > > Keyboard response was fine, disk i/o no longer seemed to be > > > reporting errors and of course the network came back on line. > > > > > > I went to sleep with zoneminder building. Now 6 hours later I > > > find the machine in the same state. Since the disk, keyboard, and > > > ethernet are all > > usb > > > devices could we have a bug in the usb sub-system? > > > > > > As soon as the ifconfig ue0 down happens the console keyboard > > > becomes properly responsive again. Could we have some sort of > > > interrupt problem going on here? > > > > > > This is food for thought for you kernel hackers. If there is > > > anything you > > want > > > me to specifically try or do the next time I have this problem, > > > probably > > in the > > > next 24 hours, please let me know. > > > > > > Your fellow ARM hacker, > > > > > > -Brett > > > > > > > Keep in mind that the network port, the SD card slot, and > > obviously the USB ports themselves are all on the same USB bus. > > That may be part of the issue. Definitely agree that it should be > > able to swap between them easier than manually shunting it. > > Not the sd card, it has its own dedicated sdhci controller in the SoC. > > The only usb thing active on my rpi is the onboard hardware (hub and > network interface) and it has a tendency to occasionally drop off the > bus and return. Actually, it's not just the ethernet, the whole hub > (onboard hub, not external) disappears and reappears. This happens > intermittantly, sometimes several times a day. Twice it has failed to > recover -- the hub never reattached until I rebooted. > > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > ugen0.2: at usbus0 (disconnected) > uhub1: at uhub0, port 1, addr 2 (disconnected) > ugen0.3: at usbus0 (disconnected) > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > smsc0: at uhub1, port 1, addr 3 (disconnected) > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > smsc0: warning: Failed to read register 0x114 > smsc0: warning: MII is busy > ukphy0: detached > miibus0: detached > Feb 26 03:13:05 rpi dhclient[246]: connection closed > Feb 26 03:13:05 rpi dhclient[246]: exiting. > Feb 26 03:13:05 rpi ntpd[519]: sendto(172.22.42.240) (fd=22): No route > to host > ugen0.2: at usbus0 > uhub1: 2> on usbus0 > uhub1: MTT enabled > uhub1: 3 ports with 2 removable, self powered > Feb 26 03:13:06 rpi ntpd[519]: sendto(172.22.42.254) (fd=22): No route > to host > ugen0.3: at usbus0 > smsc0: on usbus0 > smsc0: chip 0xec00, rev. 0002 > miibus0: on smsc0 > ukphy0: PHY 1 on miibus0 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue0: on smsc0 > ue0: Ethernet address: b8:27:eb:33:7c:02 > smsc0: chip 0xec00, rev. 0002 > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" Hello ARM hackers! Guys, connect please RPi to good, standalone 5V powers supply (1-2A will be enough) instead of USB port of something. That will close most problems, at least Ian's problem :-D WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Tue Feb 26 21:56:44 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BC192B16; Tue, 26 Feb 2013 21:56:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by mx1.freebsd.org (Postfix) with ESMTP id 7CF632A8; Tue, 26 Feb 2013 21:56:44 +0000 (UTC) Received: by mail-pb0-f51.google.com with SMTP id un15so2616911pbc.24 for ; Tue, 26 Feb 2013 13:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=d4s0YigLq5mABysAm9U8mv7oNQd/yOBUgndjtv7h1ws=; b=IlcRY6a/lOrLRUmmZrydbX+bSVTCn+sLi7FhsG6I+fiXNTbDwiVyOVIyD+uYxfS6jj TIDT5jEkcxn+GuZBq/HELHui1sHjADozgbI/u6uxsOUCFR3eLS2moiKFc2hC+Q8jnhSt qS6RmzTewg8bjBnMaY56e/R3xcOsmWXOuCM9stvDjSdvT072inlDWs0AtYMW43DQIKSI rhUfr/jD9+1A0LAVFIF0BsZayxfQ6KAjizSc1/hjpUXm87uw8IwAhMhMMzU4t2x2bmZR HjKbMmhm/3lenobaUTssSrAkFXwtBdA+Ew7UqfM6+bAEKEEbt1ywMAHjWsFKUwi67tlS unNQ== MIME-Version: 1.0 X-Received: by 10.68.143.133 with SMTP id se5mr25739778pbb.189.1361915803790; Tue, 26 Feb 2013 13:56:43 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.70.5.36 with HTTP; Tue, 26 Feb 2013 13:56:43 -0800 (PST) In-Reply-To: <20130226224901.04164f9d.ray@freebsd.org> References: <20130226120335.6928b473@ivory.wynn.com> <1361904727.16937.133.camel@revolution.hippie.lan> <20130226224901.04164f9d.ray@freebsd.org> Date: Tue, 26 Feb 2013 13:56:43 -0800 X-Google-Sender-Auth: NYPPa7AKPjIeLDo_gvz3-UyDg7c Message-ID: Subject: Re: Raspberry Pi Network Data From: Adrian Chadd To: Aleksandr Rybalko Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org, Brett Wynkoop , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 21:56:44 -0000 On 26 February 2013 12:49, Aleksandr Rybalko wrote: > Hello ARM hackers! > > Guys, connect please RPi to good, standalone 5V powers supply (1-2A > will be enough) instead of USB port of something. That will close most > problems, at least Ian's problem :-D Sure! But the side question is - can the error handling be improved? It's coming/going and that's fine; but can the reattach be made more reliable? Adrian From owner-freebsd-arm@FreeBSD.ORG Tue Feb 26 22:59:40 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9D30BC9E; Tue, 26 Feb 2013 22:59:40 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 62B4C7C7; Tue, 26 Feb 2013 22:59:39 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1QMxcdW098007; Tue, 26 Feb 2013 17:59:38 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Tue, 26 Feb 2013 17:59:38 -0500 From: Brett Wynkoop To: Aleksandr Rybalko Subject: Re: Raspberry Pi Network Data Message-ID: <20130226175938.6b16971f@ivory.wynn.com> In-Reply-To: <20130226224901.04164f9d.ray@freebsd.org> References: <20130226120335.6928b473@ivory.wynn.com> <1361904727.16937.133.camel@revolution.hippie.lan> <20130226224901.04164f9d.ray@freebsd.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 22:59:40 -0000 On Tue, 26 Feb 2013 22:49:01 +0200 Aleksandr Rybalko wrote: > Hello ARM hackers! > > Guys, connect please RPi to good, standalone 5V powers supply (1-2A > will be enough) instead of USB port of something. That will close most > problems, at least Ian's problem :-D > > WBW Greeting- My power supply is a mains powered 1.6 amp supply. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 Gun Control: The theory that a woman found dead in an alley, raped and strangled with her own pantyhose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound From owner-freebsd-arm@FreeBSD.ORG Tue Feb 26 23:20:18 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 069E0540; Tue, 26 Feb 2013 23:20:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 979A68C4; Tue, 26 Feb 2013 23:20:17 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r1QNKG5u033465; Tue, 26 Feb 2013 23:20:16 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r1QNKGGT033420; Tue, 26 Feb 2013 23:20:16 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 26 Feb 2013 23:20:16 GMT Message-Id: <201302262320.r1QNKGGT033420@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 23:20:18 -0000 TB --- 2013-02-26 21:23:55 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-02-26 21:23:55 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-02-26 21:23:55 - starting RELENG_9 tinderbox run for arm/arm TB --- 2013-02-26 21:23:55 - cleaning the object tree TB --- 2013-02-26 21:23:55 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-02-26 21:23:55 - cd /tinderbox/RELENG_9/arm/arm TB --- 2013-02-26 21:23:55 - /usr/local/bin/svn cleanup /src TB --- 2013-02-26 21:24:58 - /usr/local/bin/svn update /src TB --- 2013-02-26 21:25:12 - building world TB --- 2013-02-26 21:25:12 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 21:25:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 21:25:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 21:25:12 - SRCCONF=/dev/null TB --- 2013-02-26 21:25:12 - TARGET=arm TB --- 2013-02-26 21:25:12 - TARGET_ARCH=arm TB --- 2013-02-26 21:25:12 - TZ=UTC TB --- 2013-02-26 21:25:12 - __MAKE_CONF=/dev/null TB --- 2013-02-26 21:25:12 - cd /src TB --- 2013-02-26 21:25:12 - /usr/bin/make -B buildworld >>> World build started on Tue Feb 26 21:25:13 UTC 2013 >>> 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 >>> World build completed on Tue Feb 26 22:36:41 UTC 2013 TB --- 2013-02-26 22:36:42 - cd /src/sys/arm/conf TB --- 2013-02-26 22:36:42 - /usr/sbin/config -m AVILA TB --- 2013-02-26 22:36:42 - building AVILA kernel TB --- 2013-02-26 22:36:42 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 22:36:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 22:36:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 22:36:42 - SRCCONF=/dev/null TB --- 2013-02-26 22:36:42 - TARGET=arm TB --- 2013-02-26 22:36:42 - TARGET_ARCH=arm TB --- 2013-02-26 22:36:42 - TZ=UTC TB --- 2013-02-26 22:36:42 - __MAKE_CONF=/dev/null TB --- 2013-02-26 22:36:42 - cd /src TB --- 2013-02-26 22:36:42 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Tue Feb 26 22:36:42 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AVILA completed on Tue Feb 26 22:41:00 UTC 2013 TB --- 2013-02-26 22:41:00 - cd /src/sys/arm/conf TB --- 2013-02-26 22:41:00 - /usr/sbin/config -m BWCT TB --- 2013-02-26 22:41:00 - building BWCT kernel TB --- 2013-02-26 22:41:00 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 22:41:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 22:41:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 22:41:00 - SRCCONF=/dev/null TB --- 2013-02-26 22:41:00 - TARGET=arm TB --- 2013-02-26 22:41:00 - TARGET_ARCH=arm TB --- 2013-02-26 22:41:00 - TZ=UTC TB --- 2013-02-26 22:41:00 - __MAKE_CONF=/dev/null TB --- 2013-02-26 22:41:00 - cd /src TB --- 2013-02-26 22:41:00 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Tue Feb 26 22:41:00 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Tue Feb 26 22:43:51 UTC 2013 TB --- 2013-02-26 22:43:51 - cd /src/sys/arm/conf TB --- 2013-02-26 22:43:51 - /usr/sbin/config -m CAMBRIA TB --- 2013-02-26 22:43:51 - building CAMBRIA kernel TB --- 2013-02-26 22:43:51 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 22:43:51 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 22:43:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 22:43:51 - SRCCONF=/dev/null TB --- 2013-02-26 22:43:51 - TARGET=arm TB --- 2013-02-26 22:43:51 - TARGET_ARCH=arm TB --- 2013-02-26 22:43:51 - TZ=UTC TB --- 2013-02-26 22:43:51 - __MAKE_CONF=/dev/null TB --- 2013-02-26 22:43:51 - cd /src TB --- 2013-02-26 22:43:51 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Tue Feb 26 22:43:51 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CAMBRIA completed on Tue Feb 26 22:47:13 UTC 2013 TB --- 2013-02-26 22:47:13 - cd /src/sys/arm/conf TB --- 2013-02-26 22:47:13 - /usr/sbin/config -m CNS11XXNAS TB --- 2013-02-26 22:47:13 - building CNS11XXNAS kernel TB --- 2013-02-26 22:47:13 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 22:47:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 22:47:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 22:47:13 - SRCCONF=/dev/null TB --- 2013-02-26 22:47:13 - TARGET=arm TB --- 2013-02-26 22:47:13 - TARGET_ARCH=arm TB --- 2013-02-26 22:47:13 - TZ=UTC TB --- 2013-02-26 22:47:13 - __MAKE_CONF=/dev/null TB --- 2013-02-26 22:47:13 - cd /src TB --- 2013-02-26 22:47:13 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Tue Feb 26 22:47:13 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Tue Feb 26 22:50:17 UTC 2013 TB --- 2013-02-26 22:50:17 - cd /src/sys/arm/conf TB --- 2013-02-26 22:50:17 - /usr/sbin/config -m CRB TB --- 2013-02-26 22:50:17 - building CRB kernel TB --- 2013-02-26 22:50:17 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 22:50:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 22:50:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 22:50:17 - SRCCONF=/dev/null TB --- 2013-02-26 22:50:17 - TARGET=arm TB --- 2013-02-26 22:50:17 - TARGET_ARCH=arm TB --- 2013-02-26 22:50:17 - TZ=UTC TB --- 2013-02-26 22:50:17 - __MAKE_CONF=/dev/null TB --- 2013-02-26 22:50:17 - cd /src TB --- 2013-02-26 22:50:17 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Tue Feb 26 22:50:17 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CRB completed on Tue Feb 26 22:54:27 UTC 2013 TB --- 2013-02-26 22:54:27 - cd /src/sys/arm/conf TB --- 2013-02-26 22:54:27 - /usr/sbin/config -m DB-78XXX TB --- 2013-02-26 22:54:27 - building DB-78XXX kernel TB --- 2013-02-26 22:54:27 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 22:54:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 22:54:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 22:54:27 - SRCCONF=/dev/null TB --- 2013-02-26 22:54:27 - TARGET=arm TB --- 2013-02-26 22:54:27 - TARGET_ARCH=arm TB --- 2013-02-26 22:54:27 - TZ=UTC TB --- 2013-02-26 22:54:27 - __MAKE_CONF=/dev/null TB --- 2013-02-26 22:54:27 - cd /src TB --- 2013-02-26 22:54:27 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Tue Feb 26 22:54:27 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Tue Feb 26 22:57:35 UTC 2013 TB --- 2013-02-26 22:57:35 - cd /src/sys/arm/conf TB --- 2013-02-26 22:57:35 - /usr/sbin/config -m DB-88F5XXX TB --- 2013-02-26 22:57:35 - building DB-88F5XXX kernel TB --- 2013-02-26 22:57:35 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 22:57:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 22:57:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 22:57:35 - SRCCONF=/dev/null TB --- 2013-02-26 22:57:35 - TARGET=arm TB --- 2013-02-26 22:57:35 - TARGET_ARCH=arm TB --- 2013-02-26 22:57:35 - TZ=UTC TB --- 2013-02-26 22:57:35 - __MAKE_CONF=/dev/null TB --- 2013-02-26 22:57:35 - cd /src TB --- 2013-02-26 22:57:35 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Tue Feb 26 22:57:35 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Tue Feb 26 23:00:49 UTC 2013 TB --- 2013-02-26 23:00:49 - cd /src/sys/arm/conf TB --- 2013-02-26 23:00:49 - /usr/sbin/config -m DB-88F6XXX TB --- 2013-02-26 23:00:49 - building DB-88F6XXX kernel TB --- 2013-02-26 23:00:49 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 23:00:49 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 23:00:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 23:00:49 - SRCCONF=/dev/null TB --- 2013-02-26 23:00:49 - TARGET=arm TB --- 2013-02-26 23:00:49 - TARGET_ARCH=arm TB --- 2013-02-26 23:00:49 - TZ=UTC TB --- 2013-02-26 23:00:49 - __MAKE_CONF=/dev/null TB --- 2013-02-26 23:00:49 - cd /src TB --- 2013-02-26 23:00:49 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Tue Feb 26 23:00:49 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Tue Feb 26 23:04:01 UTC 2013 TB --- 2013-02-26 23:04:01 - cd /src/sys/arm/conf TB --- 2013-02-26 23:04:01 - /usr/sbin/config -m DOCKSTAR TB --- 2013-02-26 23:04:01 - building DOCKSTAR kernel TB --- 2013-02-26 23:04:01 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 23:04:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 23:04:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 23:04:01 - SRCCONF=/dev/null TB --- 2013-02-26 23:04:01 - TARGET=arm TB --- 2013-02-26 23:04:01 - TARGET_ARCH=arm TB --- 2013-02-26 23:04:01 - TZ=UTC TB --- 2013-02-26 23:04:01 - __MAKE_CONF=/dev/null TB --- 2013-02-26 23:04:01 - cd /src TB --- 2013-02-26 23:04:01 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Tue Feb 26 23:04:01 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Tue Feb 26 23:07:27 UTC 2013 TB --- 2013-02-26 23:07:27 - cd /src/sys/arm/conf TB --- 2013-02-26 23:07:27 - /usr/sbin/config -m EP80219 TB --- 2013-02-26 23:07:27 - building EP80219 kernel TB --- 2013-02-26 23:07:27 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 23:07:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 23:07:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 23:07:27 - SRCCONF=/dev/null TB --- 2013-02-26 23:07:27 - TARGET=arm TB --- 2013-02-26 23:07:27 - TARGET_ARCH=arm TB --- 2013-02-26 23:07:27 - TZ=UTC TB --- 2013-02-26 23:07:27 - __MAKE_CONF=/dev/null TB --- 2013-02-26 23:07:27 - cd /src TB --- 2013-02-26 23:07:27 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Tue Feb 26 23:07:27 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EP80219 completed on Tue Feb 26 23:11:10 UTC 2013 TB --- 2013-02-26 23:11:10 - cd /src/sys/arm/conf TB --- 2013-02-26 23:11:10 - /usr/sbin/config -m ETHERNUT5 TB --- 2013-02-26 23:11:10 - building ETHERNUT5 kernel TB --- 2013-02-26 23:11:10 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 23:11:10 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 23:11:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 23:11:10 - SRCCONF=/dev/null TB --- 2013-02-26 23:11:10 - TARGET=arm TB --- 2013-02-26 23:11:10 - TARGET_ARCH=arm TB --- 2013-02-26 23:11:10 - TZ=UTC TB --- 2013-02-26 23:11:10 - __MAKE_CONF=/dev/null TB --- 2013-02-26 23:11:10 - cd /src TB --- 2013-02-26 23:11:10 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Tue Feb 26 23:11:10 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ===> mxge (all) ===> mxge/mxge (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c cc1: warnings being treated as errors /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c: In function 'mxge_intr': /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c:3105: warning: large integer implicitly truncated to unsigned type [-Woverflow] /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c: In function 'mxge_attach': /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c:4897: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/mxge/mxge. *** Error code 1 Stop in /src/sys/modules/mxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/ETHERNUT5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-26 23:20:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-26 23:20:16 - ERROR: failed to build ETHERNUT5 kernel TB --- 2013-02-26 23:20:16 - 4746.88 user 816.72 system 6981.29 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Feb 27 01:12:18 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 185A8634 for ; Wed, 27 Feb 2013 01:12:18 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by mx1.freebsd.org (Postfix) with ESMTP id C3B88EF9 for ; Wed, 27 Feb 2013 01:12:17 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id bs12so2973712qab.0 for ; Tue, 26 Feb 2013 17:12:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=xms/3wXB/0t3IM2tbSprItftCXs2SspSRUFnZEn/aEE=; b=NY21dUMaTtM7BH/aPTHixt6+ftD8xWBhXbbOh5AnaDjzn0SVIhHYJLsLGEORq3DNJI KI8APADQFJ4BMlgvW6xP4mbgZQbobjZcmbKqYbvyoNsIa7D8DWA2fnib02DTnH6DSb70 E7DUDDemJLPgtqmwe/Wf+r02gGFOfW9jB67HCd3FMCyxCIrICBT/yfb4Ppy+FOwukzpo kzAqYwn342O5l/FywKjh9VCssr184MaA/3bSGO1ml4DI+mdLMjc1mWzKs3KPTjn0zZgV 6SzoRfi1LQUqYKfnEzYYSf4pG01ZSb571IXv/mL2xT8HFLzzUUSF3w1Hc0B/4RpNmlys O5Dw== MIME-Version: 1.0 X-Received: by 10.224.221.145 with SMTP id ic17mr5160418qab.34.1361927110109; Tue, 26 Feb 2013 17:05:10 -0800 (PST) Received: by 10.49.87.193 with HTTP; Tue, 26 Feb 2013 17:05:10 -0800 (PST) Date: Wed, 27 Feb 2013 09:05:10 +0800 Message-ID: Subject: How to use VFP for Raspberry Pi From: Alie Tan To: "freebsd-arm@freebsd.org" X-Gm-Message-State: ALoCoQkho/Rok3Hg5rNcOpVfIJHw2cLGtHO+h2yQMwFEtnxDSUzdV58YJvZ/hjknHk7kDlB6o5OD Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 01:12:18 -0000 Hi, Does Raspberry Pi for FreeBSD support VFP or hardfloat? If yes, how to compile the image/kernel with it? Regards, Alie T From owner-freebsd-arm@FreeBSD.ORG Wed Feb 27 01:22:27 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0502A725 for ; Wed, 27 Feb 2013 01:22:27 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by mx1.freebsd.org (Postfix) with ESMTP id BABBEF52 for ; Wed, 27 Feb 2013 01:22:26 +0000 (UTC) Received: by mail-qe0-f47.google.com with SMTP id q19so22306qeb.34 for ; Tue, 26 Feb 2013 17:22:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=20XmCLJ7nR9VV9rPQFCatfjkFKYGNK6Emw66PQMPuNE=; b=Fn4iT9F4yH7ToJyCOhuOxCLxjg/QfehD+xW7ukUSI27tnoYtTAGk7PE5stxx/nBJO1 HKtCEsykheaKo5cTxLi5H4My7DZml6nAwOD/LxqSVfJBen14vuicWlT9ACLw6dazzQY0 Qz4ghvYvD7qtTEavu6wDGm+BX5XVW1Y/cTGk5e6PehQfXHPbJZoTwLyuB+aR/HNDYC7v 1ByOyusv27VroiotKXG1rNQ0edD82TKP+KtORW6QjryNoWcY++a8FDwVdfzu4Pj4Gj6i 9AGwXhm+HE1/dBBHAePTE1NKg481rjezLQ1XzNICjG9eGg5UzIe//9sF9yggDHINrjHY JLyA== MIME-Version: 1.0 X-Received: by 10.49.84.104 with SMTP id x8mr749052qey.5.1361927709568; Tue, 26 Feb 2013 17:15:09 -0800 (PST) Received: by 10.49.87.193 with HTTP; Tue, 26 Feb 2013 17:15:09 -0800 (PST) Date: Wed, 27 Feb 2013 09:15:09 +0800 Message-ID: Subject: RPI rebooted when i plug USB keyboard/wifi From: Alie Tan To: "freebsd-arm@freebsd.org" X-Gm-Message-State: ALoCoQnWw22fWiOI86FT7xA4hxgLjufCwfL8GstHaeObTIB3NnRYUGhRwccttMjqEQyivysnnDxE Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 01:22:27 -0000 Hi, Is there any good way to debug this issue? Is this due to power issue since i have 750mA power only? Regards, Alie T From owner-freebsd-arm@FreeBSD.ORG Wed Feb 27 06:27:35 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A7E4C69D for ; Wed, 27 Feb 2013 06:27:35 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from newton.metanet.ch (newton.metanet.ch [80.74.158.130]) by mx1.freebsd.org (Postfix) with ESMTP id E1D40C32 for ; Wed, 27 Feb 2013 06:27:34 +0000 (UTC) Received: (qmail 26521 invoked from network); 27 Feb 2013 07:27:26 +0100 Received: from 217-071-083-008.ip-tech.ch (HELO ?192.168.11.88?) (217.71.83.8) by newton.metanet.ch with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Feb 2013 07:27:26 +0100 Message-ID: <512DA752.8080409@thieprojects.ch> Date: Wed, 27 Feb 2013 07:27:30 +0100 From: Werner Thie User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Raspberry Pi Network Data References: <20130226120335.6928b473@ivory.wynn.com> In-Reply-To: <20130226120335.6928b473@ivory.wynn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 06:27:35 -0000 Hi all > While my Pi has been stable for a couple of weeks I have noted that > sometimes it stops talking on the network. At those times if I get on > the console and ifconfig down and back up the interface it starts > talking on the net just fine again. My 256MB RPi came up and stayed up with an ssh session now for 5 days, after building svn, git, python, twisted then patched python ctypes (does abort/core on import - see bug follow up ports/149167) brought in a few python modules and a web application, ssh port forwarding a couchdb on a remote server as db, sitting on my desk and now serving the web app happily ever since. No stability problems, I'm on the power supply with the RPi FTDI serial cable. My 2cts, cheers Werner PS: The Bbone does the same work right now, both systems on slightly different images FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r246947M: Tue Feb 19 15:40:49 CET 2013 FreeBSD beagie 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r246901M: Sun Feb 17 10:49:03 CET 2013 From owner-freebsd-arm@FreeBSD.ORG Wed Feb 27 06:42:40 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 82BDE946 for ; Wed, 27 Feb 2013 06:42:40 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 43D80D2E for ; Wed, 27 Feb 2013 06:42:39 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1R6gcW0003001 for ; Wed, 27 Feb 2013 01:42:38 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 27 Feb 2013 01:42:38 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: 84 packages and counting Message-ID: <20130227014238.04c71d4c@ivory.wynn.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 06:42:40 -0000 Greeting- Well in my quest to build zoneminder on my Pi I have 84 packages built as of this writing. The Pi mostly just keeps churning away with /usr/ports on a usb flash drive. When I have finished the build I will put what ever packages I have in /usr/src/packages on the net for everyone. zoneminder needs a large number of perl and php bits it seems. I did not remember that from last time I built it, but that was on a very fast amd64 with I think 8 cores and 24 GB of memory, so I pretty much left for lunch and had zoneminder when I got back so I did not look at everything it built. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 April 19, 1775 An English attempt to confiscate guns from Americans triggered a successful revolution...... Dear Congress, that's a hint. From owner-freebsd-arm@FreeBSD.ORG Wed Feb 27 06:49:43 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8E80E9AA for ; Wed, 27 Feb 2013 06:49:43 +0000 (UTC) (envelope-from mats@exmandato.se) Received: from ext.mellstrand.net (ext.mellstrand.net [IPv6:2001:2040:4:2::51]) by mx1.freebsd.org (Postfix) with ESMTP id F0507D56 for ; Wed, 27 Feb 2013 06:49:42 +0000 (UTC) Received: by ext.mellstrand.net Wed, 27 Feb 2013 06:49:23 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Subject: Re: RPI rebooted when i plug USB keyboard/wifi From: Mats Mellstrand In-Reply-To: Date: Wed, 27 Feb 2013 07:49:24 +0100 Content-Transfer-Encoding: 7bit Message-Id: <5C5BBBF4-1C76-4CE6-9BFA-25500BBB7451@exmandato.se> References: To: Alie Tan Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 06:49:43 -0000 Hi On 27 feb 2013, at 02:15, Alie Tan wrote: > Hi, > > Is there any good way to debug this issue? Is this due to power issue since > i have 750mA power only? It's a hardware problem. The voltage drops when you attach a USB wifi dongle. A work around is to us an USB hub. /mm > > Regards, > Alie T > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Wed Feb 27 07:14:28 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7D3AEFB6 for ; Wed, 27 Feb 2013 07:14:28 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4096AE02 for ; Wed, 27 Feb 2013 07:14:27 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1R7EQgM003359; Wed, 27 Feb 2013 02:14:26 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 27 Feb 2013 02:14:26 -0500 From: Brett Wynkoop To: Werner Thie Subject: Re: Raspberry Pi Network Data Message-ID: <20130227021426.0ef759c2@ivory.wynn.com> In-Reply-To: <512DA752.8080409@thieprojects.ch> References: <20130226120335.6928b473@ivory.wynn.com> <512DA752.8080409@thieprojects.ch> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 07:14:28 -0000 On Wed, 27 Feb 2013 07:27:30 +0100 Werner Thie wrote: > > FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r246947M: > Tue Feb 19 15:40:49 CET 2013 > > FreeBSD beagie 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r246901M: Sun Feb > 17 10:49:03 CET 2013 > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" FreeBSD fbsd-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #1: Tue Feb 19 05:34:32 UTC 2013 root@fbsd-pi:/export/src/sys/arm/compile/RPI-B-TMPFS arm So why is my uname output missing the release info? -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 April 19, 1775 An English attempt to confiscate guns from Americans triggered a successful revolution...... Dear Congress, that's a hint. From owner-freebsd-arm@FreeBSD.ORG Wed Feb 27 07:28:18 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8DA4C11F for ; Wed, 27 Feb 2013 07:28:18 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from newton.metanet.ch (newton.metanet.ch [80.74.158.130]) by mx1.freebsd.org (Postfix) with ESMTP id DF69DE50 for ; Wed, 27 Feb 2013 07:28:17 +0000 (UTC) Received: (qmail 25984 invoked from network); 27 Feb 2013 08:28:16 +0100 Received: from 217-071-083-008.ip-tech.ch (HELO ?192.168.11.88?) (217.71.83.8) by newton.metanet.ch with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Feb 2013 08:28:16 +0100 Message-ID: <512DB591.5080007@thieprojects.ch> Date: Wed, 27 Feb 2013 08:28:17 +0100 From: Werner Thie User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Brett Wynkoop Subject: Re: Raspberry Pi Network Data References: <20130226120335.6928b473@ivory.wynn.com> <512DA752.8080409@thieprojects.ch> <20130227021426.0ef759c2@ivory.wynn.com> In-Reply-To: <20130227021426.0ef759c2@ivory.wynn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 07:28:18 -0000 Hi Brett > So why is my uname output missing the release info? uname -v should produce this info FreeBSD 10.0-CURRENT #0 r246947M: Tue Feb 19 15:40:49 CET 2013 root@xtools:/usr/home/wthie/proj/freebsd/work/obj/arm.armv6/usr/local/src/sys/RPI-B as is sysctl kern.version Try sysctl kern for a list of all kern related entries My images produced on FreeBSD VM uname -a FreeBSD xtools 9.1-RC2 FreeBSD 9.1-RC2 #0 r241133: Tue Oct 2 17:11:45 UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 with Tim Kientzle's scripts Cheers, Werner From owner-freebsd-arm@FreeBSD.ORG Wed Feb 27 08:47:25 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C815BA44 for ; Wed, 27 Feb 2013 08:47:25 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 8C2E01AB for ; Wed, 27 Feb 2013 08:47:25 +0000 (UTC) Received: from mail.bitfrost.no (mail.bitfrost.no [46.29.221.36]) by mta.bitpro.no (Postfix) with ESMTP id 34B427A121; Wed, 27 Feb 2013 09:47:18 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bitfrost.no Received: from smtp.bitfrost.no (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hanspetter) by mail.bitfrost.no (Postfix) with ESMTPSA id 7BB7E2062E; Wed, 27 Feb 2013 09:47:16 +0100 (CET) From: Hans Petter Selasky To: freebsd-arm@freebsd.org Subject: Re: Raspberry Pi Network Data Date: Wed, 27 Feb 2013 09:48:32 +0100 References: <20130226120335.6928b473@ivory.wynn.com> In-Reply-To: <20130226120335.6928b473@ivory.wynn.com> X-Face: ?p&W)c( =?iso-8859-1?q?+80hU=3B=27=7B=2E=245K+zq=7BoC6y=7C=0A=09/D=27an*6mw?=>j'f:eBsex\Gi, Cc: Brett Wynkoop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 08:47:25 -0000 On Tuesday 26 February 2013 18:03:35 Brett Wynkoop wrote: > As soon as the ifconfig ue0 down happens the console keyboard becomes > properly responsive again. Could we have some sort of interrupt > problem going on here? Hi, I won't rule out a USB bug. Can you check the output from "vmstat -i" ? --HPS From owner-freebsd-arm@FreeBSD.ORG Wed Feb 27 13:05:50 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4843B3EC for ; Wed, 27 Feb 2013 13:05:50 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 082F4ECA for ; Wed, 27 Feb 2013 13:05:49 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1RD5mIC010711; Wed, 27 Feb 2013 08:05:48 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 27 Feb 2013 08:05:48 -0500 From: Brett Wynkoop To: Werner Thie Subject: Re: Raspberry Pi Network Data Message-ID: <20130227080548.7dd111b0@ivory.wynn.com> In-Reply-To: <512DB591.5080007@thieprojects.ch> References: <20130226120335.6928b473@ivory.wynn.com> <512DA752.8080409@thieprojects.ch> <20130227021426.0ef759c2@ivory.wynn.com> <512DB591.5080007@thieprojects.ch> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 13:05:50 -0000 On Wed, 27 Feb 2013 08:28:17 +0100 Werner Thie wrote: > Hi Brett > > > So why is my uname output missing the release info? > > uname -v > > should produce this info > > FreeBSD 10.0-CURRENT #0 r246947M: Tue Feb 19 15:40:49 CET 2013 > root@xtools:/usr/home/wthie/proj/freebsd/work/obj/arm.armv6/usr/local/src/sys/RPI-B > > as is > > sysctl kern.version > > Try sysctl kern for a list of all kern related entries > > My images produced on FreeBSD VM > > uname -a > FreeBSD xtools 9.1-RC2 FreeBSD 9.1-RC2 #0 r241133: Tue Oct 2 > 17:11:45 UTC 2012 > root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > with Tim Kientzle's scripts Well my kernel was not built with Tim's script. It was built on the box in the standard way. root@fbsd-pi:/usr/ports/packages/All # sysctl kern.version kern.version: FreeBSD 10.0-CURRENT #1: Tue Feb 19 05:34:32 UTC 2013 root@fbsd-pi:/export/src/sys/arm/compile/RPI-B-TMPFS root@fbsd-pi:/usr/ports/packages/All # uname -v FreeBSD 10.0-CURRENT #1: Tue Feb 19 05:34:32 UTC 2013 root@fbsd-pi:/export/src/sys/arm/compile/RPI-B-TMPFS root@fbsd-pi:/usr/ports/packages/All # -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 I would never invade the United States. There would be a gun behind every blade of grass. --Isoroku Yamamoto From owner-freebsd-arm@FreeBSD.ORG Wed Feb 27 13:17:36 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AC1956A2 for ; Wed, 27 Feb 2013 13:17:36 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC0DF5F for ; Wed, 27 Feb 2013 13:17:35 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1RDHW8t010864; Wed, 27 Feb 2013 08:17:33 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 27 Feb 2013 08:17:32 -0500 From: Brett Wynkoop To: Hans Petter Selasky Subject: Re: Raspberry Pi Network Data Message-ID: <20130227081732.0c45d87c@ivory.wynn.com> In-Reply-To: <201302270948.32272.hps@bitfrost.no> References: <20130226120335.6928b473@ivory.wynn.com> <201302270948.32272.hps@bitfrost.no> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 13:17:36 -0000 On Wed, 27 Feb 2013 09:48:32 +0100 Hans Petter Selasky wrote: > On Tuesday 26 February 2013 18:03:35 Brett Wynkoop wrote: > > As soon as the ifconfig ue0 down happens the console keyboard > > becomes properly responsive again. Could we have some sort of > > interrupt problem going on here? > > Hi, > > I won't rule out a USB bug. Can you check the output from "vmstat > -i" ? > > --HPS I will try to get that info next time it acts up. It seems to be fine for the last 12 hours. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 Gun Control: The theory that a woman found dead in an alley, raped and strangled with her own pantyhose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound From owner-freebsd-arm@FreeBSD.ORG Wed Feb 27 16:36:13 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B1890E27 for ; Wed, 27 Feb 2013 16:36:13 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 6D86FD77 for ; Wed, 27 Feb 2013 16:36:12 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1RGaBm3036883; Wed, 27 Feb 2013 16:36:11 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 5x8az63u7ey72wedzsu7n9vim6; Wed, 27 Feb 2013 16:36:11 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Raspberry Pi Network Data Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20130227021426.0ef759c2@ivory.wynn.com> Date: Wed, 27 Feb 2013 08:36:10 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <20130226120335.6928b473@ivory.wynn.com> <512DA752.8080409@thieprojects.ch> <20130227021426.0ef759c2@ivory.wynn.com> To: Brett Wynkoop X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 16:36:13 -0000 > FreeBSD fbsd-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #1: Tue Feb 19 > 05:34:32 UTC 2013 > root@fbsd-pi:/export/src/sys/arm/compile/RPI-B-TMPFS arm > > So why is my uname output missing the release info? Release info comes from SVN tools and assumes you built from an SVN checkout. If you didn't get the source through SVN, you won't have the SVN checkout info. Tim From owner-freebsd-arm@FreeBSD.ORG Wed Feb 27 16:48:01 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CFFF4FF for ; Wed, 27 Feb 2013 16:48:01 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id AEBACDFD for ; Wed, 27 Feb 2013 16:48:01 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1RGm18g036952 for freebsd-arm@freebsd.org; Wed, 27 Feb 2013 16:48:01 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id gv5qtrrbvt6yr7jrg64svst2g2; for freebsd-arm@freebsd.org; Wed, 27 Feb 2013 16:48:01 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: multipart/signed; boundary="Apple-Mail=_D9719AAA-93B7-4E52-8F6C-F4D02BD74C5A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Dual-boot Proof-of-Concept Date: Wed, 27 Feb 2013 08:47:59 -0800 Message-Id: <476CC481-A00E-4B19-BA58-60074CC816B3@freebsd.org> To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 16:48:01 -0000 --Apple-Mail=_D9719AAA-93B7-4E52-8F6C-F4D02BD74C5A Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Over the weekend, I tinkered with my build scripts a bit and added the ability to build a single image that includes both RPi and BBone boot bits. This will load the FreeBSD kernel and give it the appropriate FDT for the platform it's booting on. The configuration looks something like this: # config.sh board_setup BeagleBonePlusRaspberryPi SD_SIZE=$((1950 * MB)) Obvious problem: We don't (yet) have a kernel that will properly boot on either platform. The configuration above is using RPI-B kernel right now, but I'll be switching that around as I do more experiments. If anyone wants to start mixing all of RPI-B and BEAGLEBONE kernel configs into a single GENERIC ARM kernel config, that would be a start. (But not sufficient, as there are a few other differences between those two kernels that will need to be resolved.) Tim --Apple-Mail=_D9719AAA-93B7-4E52-8F6C-F4D02BD74C5A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQEcBAEBAgAGBQJRLjjAAAoJEGMNyGo0rfFBrDEIAJrt4OTW8O0Gu6l9nyI9csmb 4PqFomuEgDzCgxtagieyxVxbuMEmGceb/iuKxzXnQ8BtGqnLwYsMHnOPsOZw96ON ZJDjqEnAQ60MIvy9tw0hWMhW03eNrGBbUgQKzX2oD8mKGog9b5M28vOXqI+cFxBa JpPmP/QPMjk5dQlwBpenKX4MNZP+BKiDEHDNBSzuCQ99UwCscGKWzpFaiOjVgK6I wmaIFz7N5+V/TGQUXmaBwqxSHBXaEz8f9kC7AkPAlUf+BHPlEHVmuiiLwBUTrsgn g6J5Wjx2rXY0m/bI9fzP0AYiKgsDwl0EhmqK6j8j4hnHeIT26Xyf+NjZU2871u8= =j2oo -----END PGP SIGNATURE----- --Apple-Mail=_D9719AAA-93B7-4E52-8F6C-F4D02BD74C5A-- From owner-freebsd-arm@FreeBSD.ORG Wed Feb 27 18:27:01 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 63FB39E3 for ; Wed, 27 Feb 2013 18:27:01 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2882E692 for ; Wed, 27 Feb 2013 18:27:00 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1RIQrQ6014337; Wed, 27 Feb 2013 13:26:53 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 27 Feb 2013 13:26:54 -0500 From: Brett Wynkoop To: Tim Kientzle Subject: Re: Raspberry Pi Network Data Message-ID: <20130227132654.76e8565e@ivory.wynn.com> In-Reply-To: References: <20130226120335.6928b473@ivory.wynn.com> <512DA752.8080409@thieprojects.ch> <20130227021426.0ef759c2@ivory.wynn.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:27:01 -0000 On Wed, 27 Feb 2013 08:36:10 -0800 Tim Kientzle wrote: > > FreeBSD fbsd-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #1: Tue Feb 19 > > 05:34:32 UTC 2013 > > root@fbsd-pi:/export/src/sys/arm/compile/RPI-B-TMPFS arm > > > > So why is my uname output missing the release info? > > Release info comes from SVN tools and assumes you built > from an SVN checkout. > > If you didn't get the source through SVN, you won't have the > SVN checkout info. > > Tim > Thanks Tim.....no svn on the ARMs yet. Now all is clear! -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 Gun Control: The theory that a woman found dead in an alley, raped and strangled with her own pantyhose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound From owner-freebsd-arm@FreeBSD.ORG Wed Feb 27 20:51:36 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0537EF4E; Wed, 27 Feb 2013 20:51:36 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id AC039E79; Wed, 27 Feb 2013 20:51:35 +0000 (UTC) Received: from rnote.ddteam.net (187-24-135-95.pool.ukrtel.net [95.135.24.187]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 7A735C4927; Wed, 27 Feb 2013 22:51:27 +0200 (EET) Date: Wed, 27 Feb 2013 22:51:12 +0200 From: Aleksandr Rybalko To: Adrian Chadd Subject: Re: Raspberry Pi Network Data Message-Id: <20130227225112.b480823a.ray@freebsd.org> In-Reply-To: References: <20130226120335.6928b473@ivory.wynn.com> <1361904727.16937.133.camel@revolution.hippie.lan> <20130226224901.04164f9d.ray@freebsd.org> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Brett Wynkoop , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 20:51:36 -0000 On Tue, 26 Feb 2013 13:56:43 -0800 Adrian Chadd wrote: > On 26 February 2013 12:49, Aleksandr Rybalko wrote: > > > Hello ARM hackers! > > > > Guys, connect please RPi to good, standalone 5V powers supply (1-2A > > will be enough) instead of USB port of something. That will close > > most problems, at least Ian's problem :-D > > Sure! But the side question is - can the error handling be improved? > It's coming/going and that's fine; but can the reattach be made more > reliable? It will be very nice, but I have only one idea which may help somehow, it is check current and voltage on all ports if hub or phy support that. But there is too much troubles: * Most embedded devices connect USB +5V line directly to main supply bus; * Most controllers have only OVER_CURRENT flag, so you can't calculate total power consumption or get voltage level on rail; * We need to know power source parameters. So we don't know how that consumption affect system as result we have voltage lower than minimum required in main system (lost bits, then fault and reboot) or in attached USB device (just device lost). So I see no way to detect that properly :( Maybe Hans can give some hints? > > > > Adrian -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Wed Feb 27 20:53:33 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 05FCAFCF; Wed, 27 Feb 2013 20:53:33 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id B6A3AE9E; Wed, 27 Feb 2013 20:53:32 +0000 (UTC) Received: from rnote.ddteam.net (187-24-135-95.pool.ukrtel.net [95.135.24.187]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 832A1C4927; Wed, 27 Feb 2013 22:53:31 +0200 (EET) Date: Wed, 27 Feb 2013 22:53:15 +0200 From: Aleksandr Rybalko To: Brett Wynkoop Subject: Re: Raspberry Pi Network Data Message-Id: <20130227225315.18182e05.ray@freebsd.org> In-Reply-To: <20130226175938.6b16971f@ivory.wynn.com> References: <20130226120335.6928b473@ivory.wynn.com> <1361904727.16937.133.camel@revolution.hippie.lan> <20130226224901.04164f9d.ray@freebsd.org> <20130226175938.6b16971f@ivory.wynn.com> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 20:53:33 -0000 On Tue, 26 Feb 2013 17:59:38 -0500 Brett Wynkoop wrote: > On Tue, 26 Feb 2013 22:49:01 +0200 > Aleksandr Rybalko wrote: > > > > Hello ARM hackers! > > > > Guys, connect please RPi to good, standalone 5V powers supply (1-2A > > will be enough) instead of USB port of something. That will close > > most problems, at least Ian's problem :-D > > > > WBW > > Greeting- > > My power supply is a mains powered 1.6 amp supply. Then you have weird problem which will require weird solution :) > > -Brett > > -- > > wynkoop@wynn.com > http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 > 718-717-5435 > > Gun Control: The theory that a woman found dead in an alley, raped and > strangled with her own pantyhose, is somehow morally superior to a > woman explaining to police how her attacker got that fatal bullet > wound > -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 00:05:16 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D0DDEF3D for ; Thu, 28 Feb 2013 00:05:16 +0000 (UTC) (envelope-from dave@turneris.com) Received: from mail-da0-f43.google.com (mail-da0-f43.google.com [209.85.210.43]) by mx1.freebsd.org (Postfix) with ESMTP id 7EB25B38 for ; Thu, 28 Feb 2013 00:05:14 +0000 (UTC) Received: by mail-da0-f43.google.com with SMTP id u36so554894dak.30 for ; Wed, 27 Feb 2013 16:05:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:to:message-id:subject:x-mailer:mime-version :content-type:x-gm-message-state; bh=JygWfOseFBy5TQ3M1g6cHfAoMKbl6r6ywC4TaZ5QDnc=; b=ThElb8i+vuyEzuzoxDatAOAY5Mp+nNsr6uA8KLx/GxpfY9U9j/4vLpaCv3hAxBp7kb a7odHEpKE4Sdjjs63A6cm+y41I9dMOzPFMCYukh+dT13eAf2S4EDyKqH+B70HwYROpBK B8t8lez6LuoReMF0w/RsQXMeshfj4biBSZrdO7B9zYtsKi7m/XxSiK2RQX/Tf/XKqMp+ Fo+TnripZQo6aUaeNVBCS5uYlw7Akmblhd9kRoZX57ADdUNJHgmbuXMZ6dASJ3UV9TDo H+NheH3zcv1ngKeePYmhukNKiUxj1XicoElw+90Wbqtw899D8p9ZLKElLg2dZvqo1/5U ZU4Q== X-Received: by 10.68.117.3 with SMTP id ka3mr6020556pbb.81.1362009907900; Wed, 27 Feb 2013 16:05:07 -0800 (PST) Received: from [10.1.1.142] (d173-180-192-194.bchsia.telus.net. [173.180.192.194]) by mx.google.com with ESMTPS id qb10sm6157335pbb.43.2013.02.27.16.05.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 27 Feb 2013 16:05:06 -0800 (PST) Date: Wed, 27 Feb 2013 16:05:04 -0800 From: Dave Turner To: freebsd-arm@freebsd.org Message-ID: Subject: panic: Address offset bigger than size X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 X-Gm-Message-State: ALoCoQmSfoVhIoPZ9RHKjy9C245h87u1Svqtf1K5PFGOUNoahA/+x05xN7Qcuw1D4CYz7c3P8gHS Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 00:05:16 -0000 Curious if anyone can help with this=3F I am using Gonzo's to build images for raspberry pi and trying to build i= n the ability to add swap space too. When I add swap, I get this: -----------------------------8<----------------------- =46reeBSD/armv6 U-Boot loader, Revision 1.2 (root=40machine.mydomain.local, date time blah blah) DRAM: 480M Device: disk /boot/kernel/kernel data 0x3a10b8+0x42950 syms=3D=5B0x4+0x80400+0x4+0x61f= 89=5D Hit =5BEnter=5D to boot immediately, or any other key for command prompt.= Booting =5B/boot/kernel/kernel=5D=E2=80=A6 Using DTB from memory address 0x00000100. panic: Address offset 0xC0100100 bigger than size 0x1E000000 --> Press a key on the console to reboot <-- ----------------------------->8----------------------- -Dave From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 00:11:23 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 36EC6FA5 for ; Thu, 28 Feb 2013 00:11:23 +0000 (UTC) (envelope-from ThomasSkibo@sbcglobal.net) Received: from nm19.access.bullet.mail.mud.yahoo.com (nm19.access.bullet.mail.mud.yahoo.com [66.94.237.220]) by mx1.freebsd.org (Postfix) with ESMTP id EA41BB5E for ; Thu, 28 Feb 2013 00:11:22 +0000 (UTC) Received: from [66.94.237.201] by nm19.access.bullet.mail.mud.yahoo.com with NNFMP; 28 Feb 2013 00:11:22 -0000 Received: from [98.139.221.49] by tm12.access.bullet.mail.mud.yahoo.com with NNFMP; 28 Feb 2013 00:11:22 -0000 Received: from [127.0.0.1] by smtp102.sbc.mail.bf1.yahoo.com with NNFMP; 28 Feb 2013 00:11:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1362010282; bh=ggsng6Nlp2AUfxYIBsLeJWQUB2MO/X0FopPAKPWGjbQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=2XVYRR9pnBs0v0wLTrKRTR99Ay8WRX0YlUbXoaRvi1KZWMFH/YmTWMgth1GchmVwDQ17H6GH2OoYIS7hBQ2o0FyInaQxqurqfwyUmHIrPwBj7j63QXBLUlbSzrZSCzK1Tkd3S0L5L3PQw+d7tLTsU/jkGBCmIaX5x1s9OLpfyZE= X-Yahoo-Newman-Id: 135756.75250.bm@smtp102.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 1XXdEzcVM1lm8vhivs1NvBOJJZN9wJmyWRhCVeTvIxWWfiO Af0ViofU8IpBXhdeOPhhs3qBGEYeNtBCZbZtXsCQePe3.3Xs5pPeZtdSFAtg TLG4b4xMIIVplmtnpwnO0QfCJIKcqEUxCa.uX2baY6Sh8zJ5SYXrV2YSIylM acEG.FPtqk8I5jTya3DtX5dSYksQqDYtzEzr1ptVslzo8cZMITO2JtTWjM21 5LEgw02HQPW2ehKW8sUsKwj0v_Fauez0x4U_c7ftC2KqyJ4x2ZRWC7RMwb.q VyIxcoTBYm_de25eEAj0RQFEcSnOQPWOUtKYS3rS7LyLfPNNKVR9VXnyeVjL C96XaNrj6c4cua0BJArYYBpNqqAH5mNytl38vO_PA8gzKGubKay0TjvfDJPO P4_fHcBtL7Rje2Ie.Vqy1d1DEU_B1RFeKGTWldybOoC9NeJ4fSSaZ3iuqhNN xx9lvOxhAPU8eMbzR2teJFS4IZ7nbxVL.2UD5hK6oR7.kWa0E4Eb4b3NxbEa .gyQL0PAe8SzTGdF9aYQbU4gC6r5Zyjg.MYr3JiEfVLgHQxLwwW4_pA8QZn7 3 X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- Received: from [192.168.1.9] (ThomasSkibo@71.139.174.219 with plain) by smtp102.sbc.mail.bf1.yahoo.com with SMTP; 27 Feb 2013 16:11:22 -0800 PST Message-ID: <512EA0A8.5040103@sbcglobal.net> Date: Wed, 27 Feb 2013 16:11:20 -0800 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: FreeBSD on Zedboard (Xilinx Zynq-7000) SD card image Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 00:11:23 -0000 Hello. I've created an SD card image to make it easy to test-drive FreeBSD on the Zedboard. The 150MB (compressed) image is on my zedbsd site at http://www.thomasskibo.com/zedbsd. The caveat is that the kernel crashes occasionally when the Zedboard tries to ftp a file to a local filesystem. I might post here again soon soliciting help on that one (it looks like a stale TLB entry causes a fault when copying user data to a file buffer). But, I thought it might be worth releasing this image anyway. Let me know if it (otherwise) works or doesn't work for you. --Thomas -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 00:44:58 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9DD772A2 for ; Thu, 28 Feb 2013 00:44:58 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 76FA8DBD for ; Thu, 28 Feb 2013 00:44:58 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UArcC-0009ah-0d; Thu, 28 Feb 2013 00:44:52 +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 r1S0inXx084376; Wed, 27 Feb 2013 17:44:49 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+3/u3MrA7cQdkvebJvLe7c Subject: Re: panic: Address offset bigger than size From: Ian Lepore To: Dave Turner In-Reply-To: References: Content-Type: text/plain; charset="windows-1251" Date: Wed, 27 Feb 2013 17:44:49 -0700 Message-ID: <1362012289.1168.8.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id r1S0inXx084376 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 00:44:58 -0000 On Wed, 2013-02-27 at 16:05 -0800, Dave Turner wrote: > Curious if anyone can help with this? >=20 > I am using Gonzo's to build images for raspberry pi and trying to build= in the ability to add swap space too. When I add swap, I get this: >=20 > -----------------------------8<----------------------- > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@machine.mydomain.local, date time blah blah) > DRAM: 480M >=20 > Device: disk >=20 > /boot/kernel/kernel data 0x3a10b8+0x42950 syms=3D[0x4+0x80400+0x4+0x61f= 89] > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]=85 > Using DTB from memory address 0x00000100. > panic: Address offset 0xC0100100 bigger than size 0x1E000000 >=20 > --> Press a key on the console to reboot <-- >=20 > ----------------------------->8----------------------- >=20 >=20 > -Dave My bad, I committed a typo yesterday, fixed in r247413. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 00:45:56 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 88DD8449 for ; Thu, 28 Feb 2013 00:45:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7F7DCA for ; Thu, 28 Feb 2013 00:45:56 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id s43so1007999wey.7 for ; Wed, 27 Feb 2013 16:45:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ydC38S+ahKuLQDLKsmpi+ydbwWQazuRjBjbRyOnOf90=; b=jI+6uQuKbBeX8gs4J2aGlOsgKdmDRq92xSju4Nj8LemouvCkzp3jKuQAxXlSGb9O3U qz5cc8HtnTOVRpoBzzrHm5rmnOkhzuZFWwYJSvhBKy785n7Y/oaHG5c71SpU89h9+Fzx 93Zqg4uoWJ5zRfpJkOULqrdzg1FHJM+6KRRI6W28XFJFxfioWQt9GkLdKAwuzW0/QI9P OHLKtW6s9dFxMve0xpDZcvsvA2smicobr+1Wbl2i+QiLol/Pgs+/37gbLV3rUNF4Ot8x 64/hjmb5hOVgRsUkHAFVRX/VWjIrd7Q+RN1l6yKCGT0LF58ELhTOvKw0fSokXR2iJ42K 7XrA== MIME-Version: 1.0 X-Received: by 10.180.81.42 with SMTP id w10mr7293579wix.28.1362012354620; Wed, 27 Feb 2013 16:45:54 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.114.201 with HTTP; Wed, 27 Feb 2013 16:45:54 -0800 (PST) In-Reply-To: <20130227014238.04c71d4c@ivory.wynn.com> References: <20130227014238.04c71d4c@ivory.wynn.com> Date: Wed, 27 Feb 2013 16:45:54 -0800 X-Google-Sender-Auth: gZf5FEtnxTMA_3KouyUIQywQvZE Message-ID: Subject: Re: 84 packages and counting From: Adrian Chadd To: Brett Wynkoop Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 00:45:56 -0000 HAve you thought about buying a USB 2.0 hard disk enclosure and hard disk; then powering it all from a USB powered hub? Adrian On 26 February 2013 22:42, Brett Wynkoop wrote: > Greeting- > > Well in my quest to build zoneminder on my Pi I have 84 packages built > as of this writing. The Pi mostly just keeps churning away > with /usr/ports on a usb flash drive. > > When I have finished the build I will put what ever packages I have > in /usr/src/packages on the net for everyone. > > zoneminder needs a large number of perl and php bits it seems. I did > not remember that from last time I built it, but that was on a very > fast amd64 with I think 8 cores and 24 GB of memory, so I pretty much > left for lunch and had zoneminder when I got back so I did not look at > everything it built. > > -Brett > > -- > > wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt > 917-642-6925 > 718-717-5435 > > April 19, 1775 An English attempt to confiscate guns from Americans > triggered a successful revolution...... > > Dear Congress, that's a hint. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 00:50:54 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F185B73A; Thu, 28 Feb 2013 00:50:54 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id B7DFFE14; Thu, 28 Feb 2013 00:50:54 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1S0oqMJ021927; Wed, 27 Feb 2013 19:50:53 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 27 Feb 2013 19:50:52 -0500 From: Brett Wynkoop To: Adrian Chadd Subject: Re: 84 packages and counting Message-ID: <20130227195052.0b112d2c@ivory.wynn.com> In-Reply-To: References: <20130227014238.04c71d4c@ivory.wynn.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 00:50:55 -0000 On Wed, 27 Feb 2013 16:45:54 -0800 Adrian Chadd wrote: > HAve you thought about buying a USB 2.0 hard disk enclosure and hard > disk; then powering it all from a USB powered hub? > Greeting- Yes I could do that, but one goal here is to see if I can stand using the flash operationally as I want to power my ARM-Farm from my 50 watt solar panel. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 I would never invade the United States. There would be a gun behind every blade of grass. --Isoroku Yamamoto From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 04:51:03 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 14951977 for ; Thu, 28 Feb 2013 04:51:03 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id E90BA9C5 for ; Thu, 28 Feb 2013 04:51:02 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1S4p1AS041641 for freebsd-arm@freebsd.org; Thu, 28 Feb 2013 04:51:01 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id qf6zq45wjma8ieesxxhxuzh42s; for freebsd-arm@freebsd.org; Thu, 28 Feb 2013 04:51:01 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: multipart/signed; boundary="Apple-Mail=_EF653C18-DCA9-4F13-8004-6CBF89EAF946"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: X.org on RaspberryPi? Date: Wed, 27 Feb 2013 20:51:00 -0800 Message-Id: <60404D53-7691-42D3-A0F7-729FCF2CD62E@freebsd.org> To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 04:51:03 -0000 --Apple-Mail=_EF653C18-DCA9-4F13-8004-6CBF89EAF946 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Has anyone tried getting X.org running on FreeBSD on RaspberryPi? Seems like a worthwhile project=85 Tim --Apple-Mail=_EF653C18-DCA9-4F13-8004-6CBF89EAF946 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQEcBAEBAgAGBQJRLuI1AAoJEGMNyGo0rfFBh7MIAOcgXTBfvYz3QghNi1dp1KVT rI5QXsE4uEjhR3rYpk7IN8cj/pRnH2ljE6a7d9rbLEdR2lkOsxdhP+cjksRqXELY IL6U16USZmKJwiQRgezWb2SOfYCSyqeMLi1XvWaNJQF8JundqQL1K0dhnyJNlpCG mj9zlBhkrUL7ds1nCcLJECdSWP4AWzA+E1bYZzXVYrdgmeoKGO5cBxS5D//kLD63 CQlW3FmnJfYW5bR6Ndhk40xos9py58ilDuoi0BXe/y95ARFqXZIhsYcq2xozzR5R F0NwqxNgUOC2sJUmqilCW2rkXBjYbPujF45J8rxWoUXWg3OQq7uItzeVCV8inmY= =GAT2 -----END PGP SIGNATURE----- --Apple-Mail=_EF653C18-DCA9-4F13-8004-6CBF89EAF946-- From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 05:09:02 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0550FF5C; Thu, 28 Feb 2013 05:09:02 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 921C0A7B; Thu, 28 Feb 2013 05:09:01 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.67]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UAvjm-000KQv-4I; Wed, 27 Feb 2013 21:09:00 -0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: X.org on RaspberryPi? From: Oleksandr Tymoshenko In-Reply-To: <60404D53-7691-42D3-A0F7-729FCF2CD62E@freebsd.org> Date: Wed, 27 Feb 2013 21:08:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <921741D8-D7AC-4C8B-95C9-1FDD7387E9FB@bluezbox.com> References: <60404D53-7691-42D3-A0F7-729FCF2CD62E@freebsd.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1499) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2013-02-27, at 8:51 PM, Tim Kientzle wrote: > Has anyone tried getting X.org running on FreeBSD on RaspberryPi? > > Seems like a worthwhile project… I believe this should work on RPi too (haven't tried it yet): http://raybsd.blogspot.ca/2013/02/i-hate-to-wait-so-much-time-while-ports.html [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 05:09:02 -0000 On 2013-02-27, at 8:51 PM, Tim Kientzle wrote: > Has anyone tried getting X.org running on FreeBSD on RaspberryPi? >=20 > Seems like a worthwhile project=85 I believe this should work on RPi too (haven't tried it yet): = http://raybsd.blogspot.ca/2013/02/i-hate-to-wait-so-much-time-while-ports.= html From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 06:02:54 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C18C4278 for ; Thu, 28 Feb 2013 06:02:54 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 6C53CD23 for ; Thu, 28 Feb 2013 06:02:54 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.67]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UAwZu-000B0S-Gi; Wed, 27 Feb 2013 22:02:53 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: FreeBSD on Zedboard (Xilinx Zynq-7000) SD card image From: Oleksandr Tymoshenko In-Reply-To: <512EA0A8.5040103@sbcglobal.net> Date: Wed, 27 Feb 2013 22:02:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <41A62BB3-10E3-4BC4-A4A2-82DD04072386@bluezbox.com> References: <512EA0A8.5040103@sbcglobal.net> To: Thomas Skibo X-Mailer: Apple Mail (2.1499) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2013-02-27, at 4:11 PM, Thomas Skibo wrote: > > Hello. > > I've created an SD card image to make it easy to test-drive FreeBSD on the Zedboard. The 150MB (compressed) image is on my zedbsd site at > http://www.thomasskibo.com/zedbsd. > > The caveat is that the kernel crashes occasionally when the Zedboard tries to ftp a file to a local filesystem. I might post here again soon soliciting help on that one (it looks like a stale TLB entry causes a fault when copying user data to a file buffer). But, I thought it might be worth releasing this image anyway. > > Let me know if it (otherwise) works or doesn't work for you. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 06:02:54 -0000 On 2013-02-27, at 4:11 PM, Thomas Skibo = wrote: >=20 > Hello. >=20 > I've created an SD card image to make it easy to test-drive FreeBSD on = the Zedboard. The 150MB (compressed) image is on my zedbsd site at > http://www.thomasskibo.com/zedbsd. >=20 > The caveat is that the kernel crashes occasionally when the Zedboard = tries to ftp a file to a local filesystem. I might post here again soon = soliciting help on that one (it looks like a stale TLB entry causes a = fault when copying user data to a file buffer). But, I thought it might = be worth releasing this image anyway. >=20 > Let me know if it (otherwise) works or doesn't work for you. Awesome! Thanks, Thomas.=20 Do you have any plans to work on interfacing FPGA part of the board = with FreeBSD? From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 06:27:11 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A349D4EA for ; Thu, 28 Feb 2013 06:27:11 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 48D9CDB3 for ; Thu, 28 Feb 2013 06:27:10 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1S6R9KB042115 for freebsd-arm@freebsd.org; Thu, 28 Feb 2013 06:27:09 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 4ib47fp559kfmeftpr3az9xrse; for freebsd-arm@freebsd.org; Thu, 28 Feb 2013 06:27:09 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: multipart/signed; boundary="Apple-Mail=_2781E653-7090-4675-87D1-DADE99D8603C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: PHYSADDR Date: Wed, 27 Feb 2013 22:27:06 -0800 Message-Id: To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 06:27:11 -0000 --Apple-Mail=_2781E653-7090-4675-87D1-DADE99D8603C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Starting to look at what is needed for a Generic ARM kernel. There's a lot here; I sincerely hope I'm not the only one=85 ;-) First up: Can we get rid of PHYSADDR? I think we can always compute it at runtime from PC. For example, I think this works in several places: and r0, pc, #0xF0000000 And I've found at least one reference that I think can be simply eliminated: Index: arm/elf_trampoline.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- arm/elf_trampoline.c (revision 247250) +++ arm/elf_trampoline.c (working copy) @@ -169,7 +169,7 @@ void _startC(void) { - int physaddr =3D KERNPHYSADDR; + unsigned int physaddr =3D (unsigned int)&_start & 0xfffff000; int tmp1; unsigned int sp =3D ((unsigned int)&_end & ~3) + 4; #if defined(FLASHADDR) && defined(LOADERRAMADDR) @@ -189,10 +189,9 @@ */ unsigned int target_addr; unsigned int tmp_sp; - uint32_t src_addr =3D (uint32_t)&_start - PHYSADDR + = FLASHADDR - + (pc - FLASHADDR - ((uint32_t)&_startC - PHYSADDR)) = & 0xfffff000; + uint32_t src_addr =3D (uint32_t)&_start; =20 - target_addr =3D (unsigned int)&_start - PHYSADDR + = LOADERRAMADDR; + target_addr =3D (unsigned int)&_start - (pc & = 0xf0000000) + LOADERRAMADDR; tmp_sp =3D target_addr + 0x100000 + (unsigned int)&_end - (unsigned int)&_start; memcpy((char *)target_addr, (char *)src_addr, Tim --Apple-Mail=_2781E653-7090-4675-87D1-DADE99D8603C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQEcBAEBAgAGBQJRLvi7AAoJEGMNyGo0rfFBdMwIAL3EPXt8BlsCYTnt3/c3tpPW E4k6S06Nx9Q1YlQeO/mHV97WMJJ/zmbD0lKvFT6TIOAgbOqRiC2cq+AXRZLxwYLO ypzgHQz8wjvqOjwSgsKBzGymOpNwNdPYTgCCGLwv4VwM7Mlq7Hj8ZSVk00sbB26z O3e37u4YWYS8n8aIe8mNbnZDbj4QKM5OkTJ/NwcjS2Lj9108EB0VqcENcmITFo+U 9XnRaTOrbVQYy683iVLp7D7YHzrSjUQNPo0ik7SQ0ep0FIKixEpVoCBriAOwqn+e CSfKRgEj0+w5AeyjhR2aZQ4cAE2uxNzvpz9OPxe+KS0u8VXDSWqor7rMlYSi5IA= =uTxh -----END PGP SIGNATURE----- --Apple-Mail=_2781E653-7090-4675-87D1-DADE99D8603C-- From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 06:35:02 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3F89F60E; Thu, 28 Feb 2013 06:35:02 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id EF1C0DF4; Thu, 28 Feb 2013 06:35:01 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1S6Yt1O025739; Thu, 28 Feb 2013 01:34:55 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Thu, 28 Feb 2013 01:34:55 -0500 From: Brett Wynkoop To: Oleksandr Tymoshenko Subject: Re: X.org on RaspberryPi? Message-ID: <20130228013455.064819da@ivory.wynn.com> In-Reply-To: <921741D8-D7AC-4C8B-95C9-1FDD7387E9FB@bluezbox.com> References: <60404D53-7691-42D3-A0F7-729FCF2CD62E@freebsd.org> <921741D8-D7AC-4C8B-95C9-1FDD7387E9FB@bluezbox.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 06:35:02 -0000 On Wed, 27 Feb 2013 21:08:41 -0800 Oleksandr Tymoshenko wrote: >=20 > On 2013-02-27, at 8:51 PM, Tim Kientzle wrote: >=20 > > Has anyone tried getting X.org running on FreeBSD on RaspberryPi? > >=20 > > Seems like a worthwhile project=E2=80=A6 Greeting- Since X.org is the same between all platforms and the Linux folks have X on Pi why would we have problems getting X on Pi? -Brett --=20 wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 Gun Control: The theory that a woman found dead in an alley, raped and strangled with her own pantyhose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 06:41:22 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A526767F for ; Thu, 28 Feb 2013 06:41:22 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id 57EC1E15 for ; Thu, 28 Feb 2013 06:41:22 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id 16so1640802iea.8 for ; Wed, 27 Feb 2013 22:41:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=9pN/l4jgPCUT8qP4Ti7/n1qeSG8tWSaax2Ba3SQdbt8=; b=Uk+JUiht0u/+E99ha8GAEeZ20RdmOs73ig5odJxgcDJ0k2MLJ8sqeUvH9NifAP0tBo IgdfTlgPA36whnYxXy2OR9lz/Ccu2wQxZjaVk/01jOSWC1GTcfU7EjwdqWPBVSfDq5Kp QmUDV/EvsVQ2Hw5HGqpKQfG+ol+Nar8nFDcx1yIUVy7G2JNZQong3iCMeOPJ+ECmaaVQ ehYDAlbdidRGSgTLJvfxT/j0S7f5RhnhMJtjmIa+e3StKxzULEehASFYVNmfsu0Y4sqo CR0UqeUoV6qDTfcYAJAXeDo547G1TY9r/47QGnRnrIcfv4bB2xpNzPeZr8RorIlDOMCV x0Wg== X-Received: by 10.50.46.197 with SMTP id x5mr9019699igm.7.1362033681715; Wed, 27 Feb 2013 22:41:21 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id z1sm10345804igc.1.2013.02.27.22.41.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 22:41:20 -0800 (PST) Sender: Warner Losh Subject: Re: PHYSADDR Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: Date: Wed, 27 Feb 2013 23:41:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1A428660-39FB-45EB-979B-103F7E83BC4A@bsdimp.com> References: To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmiRR02FstLAMkvwclnqJV5zirSRKjXJziZzwfOzSRjRvAAm1N/y/MWFqwA12o8vG5O6fav Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 06:41:22 -0000 On Feb 27, 2013, at 11:27 PM, Tim Kientzle wrote: > Starting to look at what is needed for a Generic ARM kernel. > There's a lot here; I sincerely hope I'm not the only one=85 ;-) >=20 > First up: Can we get rid of PHYSADDR? There's lots of places in the tree that use it, but not so many that a = whack-a-mole approach wouldn't work. > I think we can always compute it at runtime from PC. >=20 > For example, I think this works in several places: > and r0, pc, #0xF0000000 This only works early in boot before we've turned on the MMU, right? > And I've found at least one reference that I think can be simply > eliminated: >=20 > Index: arm/elf_trampoline.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- arm/elf_trampoline.c (revision 247250) > +++ arm/elf_trampoline.c (working copy) > @@ -169,7 +169,7 @@ > void > _startC(void) > { > - int physaddr =3D KERNPHYSADDR; > + unsigned int physaddr =3D (unsigned int)&_start & 0xfffff000; How'd you come up with this? Perhaps we should just define KERNPHYSADDR = as this gross expression :) But isn't _start a virtual address, not a physical address? > int tmp1; > unsigned int sp =3D ((unsigned int)&_end & ~3) + 4; > #if defined(FLASHADDR) && defined(LOADERRAMADDR) > @@ -189,10 +189,9 @@ > */ > unsigned int target_addr; > unsigned int tmp_sp; > - uint32_t src_addr =3D (uint32_t)&_start - PHYSADDR + = FLASHADDR > - + (pc - FLASHADDR - ((uint32_t)&_startC - PHYSADDR)) = & 0xfffff000; > + uint32_t src_addr =3D (uint32_t)&_start; I'm not sure how this works... > - target_addr =3D (unsigned int)&_start - PHYSADDR + = LOADERRAMADDR; > + target_addr =3D (unsigned int)&_start - (pc & = 0xf0000000) + LOADERRAMADDR; This might work, but I'd suggest a PC_TO_PHYSADDR(pc) macro or something = similar... > tmp_sp =3D target_addr + 0x100000 + > (unsigned int)&_end - (unsigned int)&_start; > memcpy((char *)target_addr, (char *)src_addr, >=20 >=20 > Tim >=20 From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 07:55:27 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 913AE2C6 for ; Thu, 28 Feb 2013 07:55:27 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 54636108F for ; Thu, 28 Feb 2013 07:55:27 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1S7tQnV026764 for ; Thu, 28 Feb 2013 02:55:26 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Thu, 28 Feb 2013 02:55:25 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: Stuck at the 88 package mark Message-ID: <20130228025525.272a7e92@ivory.wynn.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 07:55:27 -0000 Greeting- My build of zoneminder died in /usr/ports/devel/binutils. Before I dig too deep has someone already solved this one? checking for lwpstatus_t.pr_reg in sys/procfs.h... no checking for lwpstatus_t.pr_fpreg in sys/procfs.h... no checking for win32_pstatus_t in sys/procfs.h... no checking linker --as-needed support... yes checking for cos in -lm... yes *** BFD does not support target armv6-portbld-freebsd10.0. *** Look in bfd/config.bfd for supported targets. *** [configure-bfd] Error code 1 Stop in /export/ports/devel/binutils/work/binutils-2.23.1. *** [all] Error code 1 Stop in /export/ports/devel/binutils/work/binutils-2.23.1. I suspect it is just a matter of putting the right thing in for the supported target, but I am not sure what to put there? There is some arm stuff in bfd/config.bfd. So if someone has solved this let me know. If someone knows what I might want to put in the config file that would be good too. I am looking for something that will be generic to Pi/Bone/Plug/You-get-me! Thanks! -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 I would never invade the United States. There would be a gun behind every blade of grass. --Isoroku Yamamoto From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 09:23:58 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4185C73D for ; Thu, 28 Feb 2013 09:23:58 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id E8C6216E9 for ; Thu, 28 Feb 2013 09:23:56 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UAziU-0007gg-3S for freebsd-arm@freebsd.org; Thu, 28 Feb 2013 10:23:55 +0100 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UAziU-0000Lm-2p for freebsd-arm@freebsd.org; Thu, 28 Feb 2013 10:23:54 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: X.org on RaspberryPi? References: <60404D53-7691-42D3-A0F7-729FCF2CD62E@freebsd.org> <921741D8-D7AC-4C8B-95C9-1FDD7387E9FB@bluezbox.com> <20130228013455.064819da@ivory.wynn.com> Date: Thu, 28 Feb 2013 10:23:53 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <20130228013455.064819da@ivory.wynn.com> User-Agent: Opera Mail/12.14 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: a8ecdd0179e5342c74548fafd5461917 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 09:23:58 -0000 On Thu, 28 Feb 2013 07:34:55 +0100, Brett Wynkoop wrote: > On Wed, 27 Feb 2013 21:08:41 -0800 > Oleksandr Tymoshenko wrote: > >> >> On 2013-02-27, at 8:51 PM, Tim Kientzle wrote: >> >> > Has anyone tried getting X.org running on FreeBSD on RaspberryPi? >> > >> > Seems like a worthwhile project… > > Greeting- > > Since X.org is the same between all platforms and the Linux folks have > X on Pi why would we have problems getting X on Pi? > > -Brett > Because X also depends on working drivers. Ronald. From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 10:24:00 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8BB767F8 for ; Thu, 28 Feb 2013 10:24:00 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 4B24B19B6 for ; Thu, 28 Feb 2013 10:24:00 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 8B930C492D; Thu, 28 Feb 2013 12:23:58 +0200 (EET) Date: Thu, 28 Feb 2013 12:24:39 +0200 From: Aleksandr Rybalko To: "Ronald Klop" Subject: Re: X.org on RaspberryPi? Message-Id: <20130228122439.abe7feeb18d838ebfc8222c1@ddteam.net> In-Reply-To: References: <60404D53-7691-42D3-A0F7-729FCF2CD62E@freebsd.org> <921741D8-D7AC-4C8B-95C9-1FDD7387E9FB@bluezbox.com> <20130228013455.064819da@ivory.wynn.com> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 10:24:00 -0000 On Thu, 28 Feb 2013 10:23:53 +0100 "Ronald Klop" wrote: > On Thu, 28 Feb 2013 07:34:55 +0100, Brett Wynkoop wrote: > > > On Wed, 27 Feb 2013 21:08:41 -0800 > > Oleksandr Tymoshenko wrote: > > > >> > >> On 2013-02-27, at 8:51 PM, Tim Kientzle wrote: > >> > >> > Has anyone tried getting X.org running on FreeBSD on RaspberryPi? > >> > > >> > Seems like a worthwhile project… > > > > Greeting- > > > > Since X.org is the same between all platforms and the Linux folks have > > X on Pi why would we have problems getting X on Pi? > > > > -Brett > > > > Because X also depends on working drivers. > And as gonzo said we already have it. Correct link to XOrg article: http://raybsd.blogspot.com/2013/01/hope-you-like-it.html Video driver for Efika MX similar to RPi and both syscons based. So I made small change to RPi driver (commited) which is allow to use same driver. But it's still not tested. Wait for your tests and comments! :) > Ronald. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 12:07:56 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F08F995A for ; Thu, 28 Feb 2013 12:07:56 +0000 (UTC) (envelope-from ghw@7axu.com) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx1.freebsd.org (Postfix) with ESMTP id 602361EB2 for ; Thu, 28 Feb 2013 12:07:55 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hi8so7574459wib.7 for ; Thu, 28 Feb 2013 04:07:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=rmUG+E4O8XfxZbsYBDXNb9FkCTpNssPiEV1SK8EwoQ4=; b=VynswGoD1TZmwAfyYEdtAzrv0ORSj6eVEQTVy1X9Q8eSnN5mJ1DVoIwETRdlNFHmyg fs0XaJu9Bb/0l/M85a09CaDgWjGdbQc9Au6ip13XJpPo8kOb1h8wb7biu3Hr30YcTKPI M5VgBMGGqUBDnDuvXubZCq+fd2B3Mkpi8hlHitHadLNwhQwkLAdrXMQDopJr7WrZDAre 4z8trdOGKRFm+TJwqlL43iJR5rZj6a14O/v1NPPP88mQTpbPwJSjckzPT21r7UkZhOIk dU7zZ3WHkYR45Dw5rwVmas1sRGdXMbGwT2dvsUd5rW6/Aq+lty5pxU5U03Bhq8yQMZGM 5zjw== X-Received: by 10.181.13.175 with SMTP id ez15mr32263606wid.8.1362053274438; Thu, 28 Feb 2013 04:07:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.0.67 with HTTP; Thu, 28 Feb 2013 04:07:14 -0800 (PST) X-Originating-IP: [124.90.147.181] From: XiaoQI Ge Date: Thu, 28 Feb 2013 20:07:14 +0800 Message-ID: Subject: I u-boot fails to compile To: freebsd-arm@freebsd.org X-Gm-Message-State: ALoCoQk+KJRFu8US5HX4ow72+9IHfqtA5W5F42UajUN8z97aAalJntZHTxq/+3tps6CEWwYPdJFD Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 12:07:57 -0000 I tried to compile U-BOOT (https://github.com/linux-sunxi/u-boot-sunxi), but failed, suggesting: gmake [1]: *** [u-boot] Segmentation fault: 11 I do not know how to solve. === cat /dev/null .depend.board >.depend gmake[2]: Leaving directory `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/board/allwinner/a10-evb' gmake[2]: Entering directory `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/board/allwinner/a10-evb' arm-freebsd-gcc -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x4A000000 -DCONFIG_SPL_TEXT_BASE=0x30 -I/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/arm-freebsd/usr/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -march=armv5 -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -o board.o board.c -c In file included from /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include/common.h:840, from board.c:27: /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include/net.h:359: warning: declaration does not declare anything arm-freebsd-ld -r -o liba10-evb.o board.o gmake[2]: Leaving directory `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/board/allwinner/a10-evb' gmake -C /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu/ u-boot.lds gmake[2]: Entering directory `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu' gmake[2]: Nothing to be done for `u-boot.lds'. gmake[2]: Leaving directory `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu' arm-freebsd-gcc -E -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x4A000000 -DCONFIG_SPL_TEXT_BASE=0x30 -I/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/arm-freebsd/usr/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -march=armv5 -include /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include/u-boot/u-boot.lds.h -DCPUDIR=arch/arm/cpu/armv7 -ansi -D__ASSEMBLY__ -P - u-boot.lds UNDEF_SYM=`arm-freebsd-objdump -x board/allwinner/a10-evb/liba10-evb.o api/libapi.o arch/arm/cpu/armv7/libarmv7.o arch/arm/cpu/armv7/sunxi/libsunxi.o arch/arm/lib/libarm.o board/allwinner/common/liballwinner.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dfu/libdfu.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o drivers/usb/ulpi/libusb_ulpi.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext4/libext4fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o fs/zfs/libzfs.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o test/libtest.o | sed -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`; cd /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi && arm-freebsd-ld -pie -T u-boot.lds -Bstatic -Ttext 0x4A000000 $UNDEF_SYM arch/arm/cpu/armv7/start.o --start-group api/libapi.o arch/arm/cpu/armv7/libarmv7.o arch/arm/cpu/armv7/sunxi/libsunxi.o arch/arm/lib/libarm.o board/allwinner/common/liballwinner.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dfu/libdfu.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o drivers/usb/ulpi/libusb_ulpi.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext4/libext4fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o fs/zfs/libzfs.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o test/libtest.o board/allwinner/a10-evb/liba10-evb.o --end-group /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/lib/eabi_compat.o -L /usr/arm-freebsd/usr/lib -lgcc -L /usr/arm-freebsd/usr/lib -lgcc -Map u-boot.map -o u-boot arch/arm/cpu/armv7/sunxi/libsunxi.o: In function `get_timer_masked': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu/armv7/sunxi/timer.c:70: undefined reference to `__udivsi3' arch/arm/cpu/armv7/sunxi/libsunxi.o: In function `__udelay': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu/armv7/sunxi/timer.c:83: undefined reference to `__udivsi3' arch/arm/cpu/armv7/sunxi/libsunxi.o: In function `mctl_setup_dram_clock': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu/armv7/sunxi/dram.c:279: undefined reference to `__udivsi3' common/libcommon.o: In function `do_mem_md': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/cmd_mem.c:139: undefined reference to `__divsi3' common/libcommon.o: In function `memalign': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/dlmalloc.c:2805: undefined reference to `__umodsi3' common/libcommon.o: In function `read_env': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/env_mmc.c:163: undefined reference to `__udivsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/env_mmc.c:165: undefined reference to `__udivsi3' common/libcommon.o: In function `write_env': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/env_mmc.c:107: undefined reference to `__udivsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/env_mmc.c:109: undefined reference to `__udivsi3' disk/libdisk.o: In function `dev_print': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/disk/part.c:213: undefined reference to `__udivsi3' disk/libdisk.o:/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/disk/part.c:217: more undefined references to `__udivsi3' follow drivers/mmc/libmmc.o: In function `mmc_berase': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/mmc.c:337: undefined reference to `__umodsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/mmc.c:337: undefined reference to `__umodsi3' drivers/mmc/libmmc.o: In function `mmc_config_clock': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/sunxi_mmc.c:282: undefined reference to `__udivsi3' drivers/mmc/libmmc.o: In function `mmc_clk_io_on': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/sunxi_mmc.c:236: undefined reference to `__udivsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/sunxi_mmc.c:242: undefined reference to `__udivsi3' drivers/power/libpower.o: In function `axp209_set_ldo3': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/power/axp209.c:107: undefined reference to `__divsi3' drivers/power/libpower.o: In function `axp209_set_ldo2': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/power/axp209.c:87: undefined reference to `__divsi3' drivers/power/libpower.o: In function `axp209_set_dcdc3': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/power/axp209.c:72: undefined reference to `__divsi3' drivers/power/libpower.o: In function `axp209_set_dcdc2': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/power/axp209.c:48: undefined reference to `__divsi3' drivers/serial/libserial.o: In function `calc_divisor': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/serial/serial.c:149: undefined reference to `__udivsi3' fs/ext4/libext4fs.o: In function `ext4fs_read_file': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4fs.c:84: undefined reference to `__udivsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4fs.c:86: undefined reference to `__divsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4fs.c:99: undefined reference to `__umodsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4fs.c:88: undefined reference to `__modsi3' fs/ext4/libext4fs.o: In function `ext4fs_read_inode': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1482: undefined reference to `__udivsi3' fs/ext4/libext4fs.o: In function `ext4fs_blockgroup': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1466: undefined reference to `__udivsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1466: undefined reference to `__umodsi3' fs/ext4/libext4fs.o: In function `ext4fs_read_inode': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1487: undefined reference to `__udivsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1492: undefined reference to `__umodsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1492: undefined reference to `__udivsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1492: undefined reference to `__modsi3' fs/ext4/libext4fs.o: In function `read_allocated_block': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1676: undefined reference to `__divsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1695: undefined reference to `__modsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1766: undefined reference to `__divsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1810: undefined reference to `__divsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1814: undefined reference to `__modsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1833: undefined reference to `__modsi3' fs/fat/libfat.o: In function `get_fatent': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat.c:191: undefined reference to `__udivsi3' fs/fat/libfat.o: In function `check_overflow': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:792: undefined reference to `__udivsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:793: undefined reference to `__umodsi3' fs/fat/libfat.o: In function `set_fatent_value': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:486: undefined reference to `__udivsi3' fs/fat/libfat.o: In function `get_fatent_value': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:168: undefined reference to `__udivsi3' fs/fat/libfat.o: In function `set_cluster': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:574: undefined reference to `__udivsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:579: undefined reference to `__umodsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:582: undefined reference to `__udivsi3' fs/fat/libfat.o: In function `get_cluster': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat.c:304: undefined reference to `__udivsi3' fs/fat/libfat.o: In function `do_fat_write': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:968: undefined reference to `__udivsi3' fs/fat/libfat.o: In function `find_directory_entry': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:826: undefined reference to `__divsi3' fs/fat/libfat.o: In function `do_fat_read_at': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat.c:873: undefined reference to `__udivsi3' fs/zfs/libzfs.o: In function `fzap_iterate': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/zfs/zfs.c:1004: undefined reference to `__divsi3' fs/zfs/libzfs.o: In function `zap_leaf_lookup': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/zfs/zfs.c:850: undefined reference to `__divsi3' fs/zfs/libzfs.o: In function `zfs_read': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/zfs/zfs.c:2163: undefined reference to `__umodsi3' lib/libgeneric.o: In function `print_buffer': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/display_options.c:112: undefined reference to `__udivsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/display_options.c:114: undefined reference to `__udivsi3' lib/libgeneric.o: In function `__div64_32': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/div64.c:31: undefined reference to `__udivsi3' lib/libgeneric.o: In function `isprime': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/hashtable.c:91: undefined reference to `__umodsi3' lib/libgeneric.o: In function `hcreate_r': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/hashtable.c:120: undefined reference to `__umodsi3' lib/libgeneric.o: In function `hsearch_r': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/hashtable.c:274: undefined reference to `__umodsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/hashtable.c:314: undefined reference to `__umodsi3' lib/libgeneric.o: In function `ldiv': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/ldiv.c:29: undefined reference to `__divsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/ldiv.c:30: undefined reference to `__modsi3' lib/libgeneric.o: In function `qsort': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/qsort.c:35: undefined reference to `__udivsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/qsort.c:63: undefined reference to `__udivsi3' lib/libgeneric.o: In function `strmhz': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/strmhz.c:30: undefined reference to `__udivsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/strmhz.c:34: undefined reference to `__udivsi3' lib/libgeneric.o: In function `simple_itoa': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/vsprintf.c:813: undefined reference to `__umodsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/vsprintf.c:814: undefined reference to `__udivsi3' lib/libgeneric.o: In function `put_dec': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/vsprintf.c:258: undefined reference to `__umodsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/vsprintf.c:258: undefined reference to `__udivsi3' lib/zlib/libz.o: In function `adler32': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:93: undefined reference to `__umodsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:104: undefined reference to `__umodsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:105: undefined reference to `__umodsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:119: undefined reference to `__umodsi3' /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:120: undefined reference to `__umodsi3' lib/zlib/libz.o:/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/inflate.c:390: more undefined references to `__umodsi3' follow arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-arm.c:8911 arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-arm.c:8911 arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-arm.c:8911 arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-arm.c:8911 arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-arm.c:9138 gmake[1]: *** [u-boot] Segmentation fault: 11 gmake[1]: *** Deleting file `u-boot' gmake[1]: Leaving directory `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi' gmake: *** [sun4i] Error 2 [ghw@7axu.pts/5] ~/CNPROJ/CubieBoard/u-boot-sunxi % Thanks === Welcome to Ge, XiaoQI's Homepage! Gtalk/E-Mail :ghw@7axu.com From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 12:54:07 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1F259508 for ; Thu, 28 Feb 2013 12:54:07 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by mx1.freebsd.org (Postfix) with ESMTP id C1A98267 for ; Thu, 28 Feb 2013 12:54:06 +0000 (UTC) Received: by mail-ia0-f174.google.com with SMTP id u20so1457876iag.5 for ; Thu, 28 Feb 2013 04:54:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CQ/bdeAllddFoIA/DiGNSemZSnxMIDH/XjvseFPHYK4=; b=IG/SwfTQEld59GdJ/V4N3m96mAIoa0dzxjrl1IMW/vwF44cF1Ngq019j/N/F+VXlCT yeW0NEKGNvvqXeD6Qk5QNkQn9R1szuNn2ykN6hHT0ZrH4AncDpFAlJ5ei3Dyn95fVPTV VEdB17K1eC9iijJl5QeggKffLZw9pbQs6uWE8BrlZZ7Gixcfx7JoAHcBSEwUBIG95jcG 2/t4pD2uZALkvIFmtXmKLzy6ysPC+kMTenadizCzPD4Xby0kpXdcuh7an4Fcoff/jLJW 9uiYVvklO16jpZmPhASrpgwfTAh7sl2u2DwL3kkTliu/KN/02UGOTbSX6ozgyC9xOUCY MiPw== MIME-Version: 1.0 X-Received: by 10.50.196.169 with SMTP id in9mr2012528igc.47.1362056045785; Thu, 28 Feb 2013 04:54:05 -0800 (PST) Received: by 10.64.6.230 with HTTP; Thu, 28 Feb 2013 04:54:05 -0800 (PST) In-Reply-To: References: Date: Thu, 28 Feb 2013 20:54:05 +0800 Message-ID: Subject: Re: I u-boot fails to compile From: Ganbold Tsagaankhuu To: XiaoQI Ge Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 12:54:07 -0000 On Thu, Feb 28, 2013 at 8:07 PM, XiaoQI Ge wrote: > I tried to compile U-BOOT (https://github.com/linux-sunxi/u-boot-sunxi), > but failed, suggesting: > > gmake [1]: *** [u-boot] Segmentation fault: 11 > > I do not know how to solve. > === > > cat /dev/null .depend.board >.depend > gmake[2]: Leaving directory > `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/board/allwinner/a10-evb' > gmake[2]: Entering directory > `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/board/allwinner/a10-evb' > arm-freebsd-gcc -g -Os -fno-common -ffixed-r8 -msoft-float > -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x4A000000 -DCONFIG_SPL_TEXT_BASE=0x30 > -I/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include -fno-builtin > -ffreestanding -nostdinc -isystem /usr/arm-freebsd/usr/include -pipe > -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux > -march=armv5 -Wall -Wstrict-prototypes -fno-stack-protector > -Wno-format-nonliteral -Wno-format-security -o board.o board.c -c > In file included from > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include/common.h:840, > from board.c:27: > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include/net.h:359: warning: > declaration does not declare anything > arm-freebsd-ld -r -o liba10-evb.o board.o > gmake[2]: Leaving directory > `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/board/allwinner/a10-evb' > gmake -C /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu/ u-boot.lds > gmake[2]: Entering directory > `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu' > gmake[2]: Nothing to be done for `u-boot.lds'. > gmake[2]: Leaving directory > `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu' > arm-freebsd-gcc -E -g -Os -fno-common -ffixed-r8 -msoft-float > -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x4A000000 -DCONFIG_SPL_TEXT_BASE=0x30 > -I/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include -fno-builtin > -ffreestanding -nostdinc -isystem /usr/arm-freebsd/usr/include -pipe > -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux > -march=armv5 -include > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include/u-boot/u-boot.lds.h > -DCPUDIR=arch/arm/cpu/armv7 -ansi -D__ASSEMBLY__ -P - > >u-boot.lds > UNDEF_SYM=`arm-freebsd-objdump -x board/allwinner/a10-evb/liba10-evb.o > api/libapi.o arch/arm/cpu/armv7/libarmv7.o > arch/arm/cpu/armv7/sunxi/libsunxi.o arch/arm/lib/libarm.o > board/allwinner/common/liballwinner.o common/libcommon.o disk/libdisk.o > drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o > drivers/dfu/libdfu.o drivers/dma/libdma.o drivers/fpga/libfpga.o > drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o > drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o > drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o > drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o > drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o > drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o > drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o > drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o > drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o > drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o > drivers/usb/ulpi/libusb_ulpi.o drivers/video/libvideo.o > drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext4/libext4fs.o > fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o > fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o > fs/zfs/libzfs.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o > lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o test/libtest.o > | sed -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`; cd > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi && arm-freebsd-ld -pie -T > u-boot.lds -Bstatic -Ttext 0x4A000000 $UNDEF_SYM arch/arm/cpu/armv7/start.o > --start-group api/libapi.o arch/arm/cpu/armv7/libarmv7.o > arch/arm/cpu/armv7/sunxi/libsunxi.o arch/arm/lib/libarm.o > board/allwinner/common/liballwinner.o common/libcommon.o disk/libdisk.o > drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o > drivers/dfu/libdfu.o drivers/dma/libdma.o drivers/fpga/libfpga.o > drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o > drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o > drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o > drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o > drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o > drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o > drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o > drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o > drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o > drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o > drivers/usb/ulpi/libusb_ulpi.o drivers/video/libvideo.o > drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext4/libext4fs.o > fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o > fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o > fs/zfs/libzfs.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o > lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o test/libtest.o > board/allwinner/a10-evb/liba10-evb.o --end-group > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/lib/eabi_compat.o -L > /usr/arm-freebsd/usr/lib -lgcc -L /usr/arm-freebsd/usr/lib -lgcc -Map > u-boot.map -o u-boot > arch/arm/cpu/armv7/sunxi/libsunxi.o: In function `get_timer_masked': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu/armv7/sunxi/timer.c:70: > undefined reference to `__udivsi3' > arch/arm/cpu/armv7/sunxi/libsunxi.o: In function `__udelay': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu/armv7/sunxi/timer.c:83: > undefined reference to `__udivsi3' > arch/arm/cpu/armv7/sunxi/libsunxi.o: In function `mctl_setup_dram_clock': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu/armv7/sunxi/dram.c:279: > undefined reference to `__udivsi3' > common/libcommon.o: In function `do_mem_md': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/cmd_mem.c:139: undefined > reference to `__divsi3' > common/libcommon.o: In function `memalign': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/dlmalloc.c:2805: undefined > reference to `__umodsi3' > common/libcommon.o: In function `read_env': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/env_mmc.c:163: undefined > reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/env_mmc.c:165: undefined > reference to `__udivsi3' > common/libcommon.o: In function `write_env': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/env_mmc.c:107: undefined > reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/env_mmc.c:109: undefined > reference to `__udivsi3' > disk/libdisk.o: In function `dev_print': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/disk/part.c:213: undefined > reference to `__udivsi3' > disk/libdisk.o:/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/disk/part.c:217: > more undefined references to `__udivsi3' follow > drivers/mmc/libmmc.o: In function `mmc_berase': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/mmc.c:337: undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/mmc.c:337: undefined > reference to `__umodsi3' > drivers/mmc/libmmc.o: In function `mmc_config_clock': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/sunxi_mmc.c:282: > undefined reference to `__udivsi3' > drivers/mmc/libmmc.o: In function `mmc_clk_io_on': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/sunxi_mmc.c:236: > undefined reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/sunxi_mmc.c:242: > undefined reference to `__udivsi3' > drivers/power/libpower.o: In function `axp209_set_ldo3': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/power/axp209.c:107: > undefined reference to `__divsi3' > drivers/power/libpower.o: In function `axp209_set_ldo2': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/power/axp209.c:87: > undefined reference to `__divsi3' > drivers/power/libpower.o: In function `axp209_set_dcdc3': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/power/axp209.c:72: > undefined reference to `__divsi3' > drivers/power/libpower.o: In function `axp209_set_dcdc2': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/power/axp209.c:48: > undefined reference to `__divsi3' > drivers/serial/libserial.o: In function `calc_divisor': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/serial/serial.c:149: > undefined reference to `__udivsi3' > fs/ext4/libext4fs.o: In function `ext4fs_read_file': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4fs.c:84: undefined > reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4fs.c:86: undefined > reference to `__divsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4fs.c:99: undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4fs.c:88: undefined > reference to `__modsi3' > fs/ext4/libext4fs.o: In function `ext4fs_read_inode': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1482: > undefined reference to `__udivsi3' > fs/ext4/libext4fs.o: In function `ext4fs_blockgroup': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1466: > undefined reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1466: > undefined reference to `__umodsi3' > fs/ext4/libext4fs.o: In function `ext4fs_read_inode': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1487: > undefined reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1492: > undefined reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1492: > undefined reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1492: > undefined reference to `__modsi3' > fs/ext4/libext4fs.o: In function `read_allocated_block': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1676: > undefined reference to `__divsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1695: > undefined reference to `__modsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1766: > undefined reference to `__divsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1810: > undefined reference to `__divsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1814: > undefined reference to `__modsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1833: > undefined reference to `__modsi3' > fs/fat/libfat.o: In function `get_fatent': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat.c:191: undefined > reference to `__udivsi3' > fs/fat/libfat.o: In function `check_overflow': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:792: undefined > reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:793: undefined > reference to `__umodsi3' > fs/fat/libfat.o: In function `set_fatent_value': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:486: undefined > reference to `__udivsi3' > fs/fat/libfat.o: In function `get_fatent_value': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:168: undefined > reference to `__udivsi3' > fs/fat/libfat.o: In function `set_cluster': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:574: undefined > reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:579: undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:582: undefined > reference to `__udivsi3' > fs/fat/libfat.o: In function `get_cluster': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat.c:304: undefined > reference to `__udivsi3' > fs/fat/libfat.o: In function `do_fat_write': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:968: undefined > reference to `__udivsi3' > fs/fat/libfat.o: In function `find_directory_entry': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:826: undefined > reference to `__divsi3' > fs/fat/libfat.o: In function `do_fat_read_at': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat.c:873: undefined > reference to `__udivsi3' > fs/zfs/libzfs.o: In function `fzap_iterate': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/zfs/zfs.c:1004: undefined > reference to `__divsi3' > fs/zfs/libzfs.o: In function `zap_leaf_lookup': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/zfs/zfs.c:850: undefined > reference to `__divsi3' > fs/zfs/libzfs.o: In function `zfs_read': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/zfs/zfs.c:2163: undefined > reference to `__umodsi3' > lib/libgeneric.o: In function `print_buffer': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/display_options.c:112: > undefined reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/display_options.c:114: > undefined reference to `__udivsi3' > lib/libgeneric.o: In function `__div64_32': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/div64.c:31: undefined > reference to `__udivsi3' > lib/libgeneric.o: In function `isprime': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/hashtable.c:91: undefined > reference to `__umodsi3' > lib/libgeneric.o: In function `hcreate_r': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/hashtable.c:120: undefined > reference to `__umodsi3' > lib/libgeneric.o: In function `hsearch_r': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/hashtable.c:274: undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/hashtable.c:314: undefined > reference to `__umodsi3' > lib/libgeneric.o: In function `ldiv': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/ldiv.c:29: undefined reference > to `__divsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/ldiv.c:30: undefined reference > to `__modsi3' > lib/libgeneric.o: In function `qsort': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/qsort.c:35: undefined > reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/qsort.c:63: undefined > reference to `__udivsi3' > lib/libgeneric.o: In function `strmhz': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/strmhz.c:30: undefined > reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/strmhz.c:34: undefined > reference to `__udivsi3' > lib/libgeneric.o: In function `simple_itoa': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/vsprintf.c:813: undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/vsprintf.c:814: undefined > reference to `__udivsi3' > lib/libgeneric.o: In function `put_dec': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/vsprintf.c:258: undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/vsprintf.c:258: undefined > reference to `__udivsi3' > lib/zlib/libz.o: In function `adler32': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:93: undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:104: undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:105: undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:119: undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:120: undefined > reference to `__umodsi3' > lib/zlib/libz.o:/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/inflate.c:390: > more undefined references to `__umodsi3' follow > arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail > /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-arm.c:8911 > arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail > /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-arm.c:8911 > arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail > /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-arm.c:8911 > arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail > /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-arm.c:8911 > arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail > /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-arm.c:9138 > gmake[1]: *** [u-boot] Segmentation fault: 11 > gmake[1]: *** Deleting file `u-boot' > gmake[1]: Leaving directory `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi' > gmake: *** [sun4i] Error 2 > [ghw@7axu.pts/5] ~/CNPROJ/CubieBoard/u-boot-sunxi % I think you can check Tim's repo for uboot patches: https://github.com/kientzle/freebsd-beaglebone Specially like: https://github.com/kientzle/freebsd-beaglebone/blob/master/board/BeagleBone/files/uboot_patch1_add_libc_to_link_on_FreeBSD.patch Ganbold > > > Thanks > > === > Welcome to Ge, XiaoQI's Homepage! > Gtalk/E-Mail :ghw@7axu.com > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 15:12:01 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 834B626C for ; Thu, 28 Feb 2013 15:12:01 +0000 (UTC) (envelope-from ThomasSkibo@sbcglobal.net) Received: from nm7-vm0.access.bullet.mail.mud.yahoo.com (nm7-vm0.access.bullet.mail.mud.yahoo.com [66.94.237.189]) by mx1.freebsd.org (Postfix) with ESMTP id 404D0AA9 for ; Thu, 28 Feb 2013 15:12:01 +0000 (UTC) Received: from [66.94.237.200] by nm7.access.bullet.mail.mud.yahoo.com with NNFMP; 28 Feb 2013 15:11:54 -0000 Received: from [68.142.198.104] by tm11.access.bullet.mail.mud.yahoo.com with NNFMP; 28 Feb 2013 15:11:53 -0000 Received: from [127.0.0.1] by smtp106.sbc.mail.mud.yahoo.com with NNFMP; 28 Feb 2013 15:11:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1362064313; bh=5L70Tti+OcP/bQlNF8RMp72OBjgNMN3I7u+GlLOD91o=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ftmgKUY2Dj4mzign1D5Q+PA/oLnR5btlNaj+xxrgDr5Tthj80Y2Q0qE+WtB9t5RXtUJPw3g3VGCZHpr5bzbGPF7Sk1SMjyWyWoY1S0xIzjenWqRRXJYKLYXScDZmm9lT0iC3WYUj0MkDnr7Ua7YpaI9CV9IePvsxIMqT/n6HuE4= X-Yahoo-Newman-Id: 339518.85474.bm@smtp106.sbc.mail.mud.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: o.ZzWlgVM1nLFt.cQA_NXJmecz_mb8G0SH1ZEi69yHYfJii 1vzl8.D38wzd0LpK1roU6t_L8J086ARMd9BUq.8qNtV_fNJlNIWQzNQmF_p3 Op5L8U98NbSKvKYUuWhrZG0kjntqrMgGjm5fc_B5U6Vzjkzupvp0CWFmDOpn wNL4euz7QErE5qsAwx2ID4TlMjwC_stgPP3yik0u5ZuSX3brOFO9HcuClUXZ btZ7.1__CnZDrqVZ3mGmL_e2osYfr9SosF1BsbbTxpoSW8dNybhZxWI9Nblt k3tzrzgTwbhCRKFvBEnUVMyYvMSjVSHOJ18s61nEOEiZjZibaKnw6e7h8UqB Ocjq1OvNIjrWTy5uXR4nDCYWbCKO4aI4E.cguWMci4WfNSPqV0eJ3KTzKt.n pmTUjTp768HYeA2gpAXnlSS18hS4cBGHH9B_5Jl7vbC0KXCdsyCh8rwIlxMM mv5XIAA28cPpTK4ZQEah0QPj5nKU.rxO8TVjK4uo- X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- Received: from [192.168.1.9] (ThomasSkibo@71.139.174.219 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 28 Feb 2013 15:11:53 +0000 UTC Message-ID: <512F73B7.50404@sbcglobal.net> Date: Thu, 28 Feb 2013 07:11:51 -0800 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Oleksandr Tymoshenko Subject: Re: FreeBSD on Zedboard (Xilinx Zynq-7000) SD card image References: <512EA0A8.5040103@sbcglobal.net> <41A62BB3-10E3-4BC4-A4A2-82DD04072386@bluezbox.com> In-Reply-To: <41A62BB3-10E3-4BC4-A4A2-82DD04072386@bluezbox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 15:12:01 -0000 I don't have anything specific in mind but I hope I can wind down kernel hacking and do some FPGA hacking. I've developed a device config driver so you can reprogram the PL (FPGA) section with "cat system.bit.bin > /dev/devcfg0". On 2/27/13 10:02 PM, Oleksandr Tymoshenko wrote: > > Awesome! Thanks, Thomas. > Do you have any plans to work on interfacing FPGA part of the board with FreeBSD? > > -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 16:21:01 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E5DCF281; Thu, 28 Feb 2013 16:21:01 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id BE0F9F17; Thu, 28 Feb 2013 16:21:01 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UB6E3-000Nor-Di; Thu, 28 Feb 2013 16:20:55 +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 r1SGKrHB085392; Thu, 28 Feb 2013 09:20:53 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+y7uHwWzH2Q2Y928Xe5te3 Subject: Re: PHYSADDR From: Ian Lepore To: Tim Kientzle In-Reply-To: References: Content-Type: text/plain; charset="windows-1251" Date: Thu, 28 Feb 2013 09:20:53 -0700 Message-ID: <1362068453.1195.40.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id r1SGKrHB085392 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 16:21:02 -0000 On Wed, 2013-02-27 at 22:27 -0800, Tim Kientzle wrote: > Starting to look at what is needed for a Generic ARM kernel. > There's a lot here; I sincerely hope I'm not the only one=85 ;-) >=20 > First up: Can we get rid of PHYSADDR? >=20 If you mean, can we get rid of it within the runtime kernel, I'd say yes, because we can use a global variable instead which is easily settable in the entry code. On the other hand, I've been working towards getting that value set correctly in the kernel elf headers at link time. Where to physically load the kernel has to be specified somewhere. Often what does the loading right now is code that could be standard elf loader code, but it's full of "the header values are wrong, so do these bit manipulations to the virtual addresses instead" which I think is horrible, and on top of that the code that does so is often wrong (but works by accident with the chips we support). I'd like to preserve the ability for the kernel elf headers to be properly interpretted by a standard elf loader, at least as an option. A loader would always be free to ignore the values in the header and use its own empirical knowledge of the SoC to choose a load address. So how would something like ubldr decide on a physical load address for a generic kernel that had, say, zeroes in the paddr and e_entry fields? The trampoline code replicates the "loader has empirical knowledge" problem, because it is in effect another loader. The address at which the external loader loads the kernel.gz.tramp has nothing to do with the address at which the trampoline places the decompressed kernel. Right now it's another case of the loader (trampoline) bit-twiddling the virtual addresses from the kernel's elf headers. The trampoline is relatively horrible for performance as well, it decompresses the kernel to one place, then copies it to another. I'm curious whether anyone uses it at all, except us at Symmetricom? I'm not even sure there's any advantage to us using it. I suspect it was at one time better for performance to load a smaller image from sdcard (because that's slow) and take the hit on the decompress time. Recently I enabled the MMU and caches in our low-level bootloader, and I have a feeling that plus other changes to the boot sd code may mean it's faster to load an uncompressed kernel now. I need to do some testing. I'm not sure we can completely wish away the trampoline, but I think we can define some conventions that ensure its existance is not a barrier to having a generic kernel, pretty much just by saying so. For example, we could require that a kernel have valid physical addresses in the elf headers for the trampoline to operate on, and simply state that generic kernels designed to be loaded anywhere can't use the trampoline. I had to put some effort recently into figuring out some of the perverse details of how an at91 SoC gets from first-electrons to a running kernel, and I took notes at the time. I started formatting the notes into a wiki page, but only got the first half of them cleaned up. Still, there may be some useful info even if the formatting is rough: https://wiki.freebsd.org/FreeBSD/arm/BootProcess -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 16:57:03 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7416142B for ; Thu, 28 Feb 2013 16:57:03 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 47E3E19C for ; Thu, 28 Feb 2013 16:57:02 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1SGus6E044986; Thu, 28 Feb 2013 16:56:54 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id hfe6p3ud2mdx8n9w63a2ref7t6; Thu, 28 Feb 2013 16:56:54 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: PHYSADDR Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <1A428660-39FB-45EB-979B-103F7E83BC4A@bsdimp.com> Date: Thu, 28 Feb 2013 08:56:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1F9B0ED4-7FAF-43D8-BECD-1D42792E81DF@freebsd.org> References: <1A428660-39FB-45EB-979B-103F7E83BC4A@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 16:57:03 -0000 On Feb 27, 2013, at 10:41 PM, Warner Losh wrote: >=20 > On Feb 27, 2013, at 11:27 PM, Tim Kientzle wrote: >=20 >> Starting to look at what is needed for a Generic ARM kernel. >> There's a lot here; I sincerely hope I'm not the only one=85 ;-) >>=20 >> First up: Can we get rid of PHYSADDR? >=20 > There's lots of places in the tree that use it, but not so many that a = whack-a-mole approach wouldn't work. It's mostly only used in locore.S and machdep.c (and, of course, the many copies of machdep.c). >> I think we can always compute it at runtime from PC. >>=20 >> For example, I think this works in several places: >> and r0, pc, #0xF0000000 >=20 > This only works early in boot before we've turned on the MMU, right? I'm still pretty new to this section of the code, so might have missed something, but I don't think we need PHYSADDR after the kernel has relocated itself. Do we? >=20 >> And I've found at least one reference that I think can be simply >> eliminated: >>=20 >> Index: arm/elf_trampoline.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- arm/elf_trampoline.c (revision 247250) >> +++ arm/elf_trampoline.c (working copy) >> @@ -169,7 +169,7 @@ >> void >> _startC(void) >> { >> - int physaddr =3D KERNPHYSADDR; >> + unsigned int physaddr =3D (unsigned int)&_start & 0xfffff000; >=20 > How'd you come up with this? Perhaps we should just define = KERNPHYSADDR as this gross expression :) >=20 > But isn't _start a virtual address, not a physical address? Honestly, I'm still trying to figure that part out. ;-) Disassembling the compiler output, taking the address of the current function always uses a PC-relative address. So &_startC here would give the current address of the function as it's executing. >=20 >> int tmp1; >> unsigned int sp =3D ((unsigned int)&_end & ~3) + 4; >> #if defined(FLASHADDR) && defined(LOADERRAMADDR) >> @@ -189,10 +189,9 @@ >> */ >> unsigned int target_addr; >> unsigned int tmp_sp; >> - uint32_t src_addr =3D (uint32_t)&_start - PHYSADDR + = FLASHADDR >> - + (pc - FLASHADDR - ((uint32_t)&_startC - PHYSADDR)) = & 0xfffff000; >> + uint32_t src_addr =3D (uint32_t)&_start; >=20 > I'm not sure how this works=85 Here's my reasoning: FLASHADDR and PHYSADDR are always multiples of 4k, so you can pull those out of the parentheses to get: _start - PHYSADDR + FLASHADDR - FLASHADD + PHYSADDR + (pc - _startC) = & 0xffffff000 And since pc was sampled early in _startC, the last expression should always be zero. I was a little surprised by this myself, so I might have missed something. >> - target_addr =3D (unsigned int)&_start - PHYSADDR + = LOADERRAMADDR; >> + target_addr =3D (unsigned int)&_start - (pc & = 0xf0000000) + LOADERRAMADDR; >=20 > This might work, but I'd suggest a PC_TO_PHYSADDR(pc) macro or = something similar=85 I'll try that later on. I suspect some of these PHYSADDRs will simply go away, since I think what we really want in the early bootstrap stage is just "what address is the kernel currently executing at". I still need to piece together some more things before I understand that. As with the above, at least some of the expressions using PHYSADDR seem more complex than necessary. >> tmp_sp =3D target_addr + 0x100000 + >> (unsigned int)&_end - (unsigned int)&_start; >> memcpy((char *)target_addr, (char *)src_addr, >>=20 >>=20 >> Tim >>=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 16:58:21 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9E04C54A; Thu, 28 Feb 2013 16:58:21 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 724DC1BA; Thu, 28 Feb 2013 16:58:21 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1SGwLXE045001; Thu, 28 Feb 2013 16:58:21 GMT (envelope-from kientzle@FreeBSD.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id rx2vkwj6pqjrkizzud5jivht4a; Thu, 28 Feb 2013 16:58:21 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Subject: Re: PHYSADDR Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1251 From: Tim Kientzle In-Reply-To: <1362068453.1195.40.camel@revolution.hippie.lan> Date: Thu, 28 Feb 2013 08:58:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> References: <1362068453.1195.40.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 16:58:21 -0000 On Feb 28, 2013, at 8:20 AM, Ian Lepore wrote: > On Wed, 2013-02-27 at 22:27 -0800, Tim Kientzle wrote: >> Starting to look at what is needed for a Generic ARM kernel. >> There's a lot here; I sincerely hope I'm not the only one=85 ;-) >>=20 >> First up: Can we get rid of PHYSADDR? >>=20 >=20 > If you mean, can we get rid of it within the runtime kernel, I'd say > yes, because we can use a global variable instead which is easily > settable in the entry code. It doesn't seem to be used in the runtime kernel. As far as I can see, it's purely a bootstrap concept. > On the other hand, I've been working > towards getting that value set correctly in the kernel elf headers at > link time. My question really boils down to whether PIC techniques are sufficient for the early bootstrap stage to determine where the kernel is currently executing and use that to drive the initial MMU bring up. I've just started, but the PHYSADDR uses I've examined can be replaced with PIC techniques. But this part of the code is pretty involved and riddled with conditional compilations, so it will be slow going. I was impressed to find that ubldr seems to be PIC. I've run the same binary at different load addresses and so far it "just works." (I didn't think it would work, so I was surprised by this. I haven't dug through to figure out why it works yet.) > Where to physically load the kernel has to be specified somewhere. Yes, in the loader. Once the kernel is running, it can look at the PC and see where it was loaded. I'm doubtless oversimplifying, though. ;-) > So how would something like ubldr decide on a physical load address = for > a generic kernel that had, say, zeroes in the paddr and e_entry = fields? I'm not sure yet. > The trampoline code replicates the "loader has empirical knowledge" > problem, because it is in effect another loader. The address at which > the external loader loads the kernel.gz.tramp has nothing to do with = the > address at which the trampoline places the decompressed kernel. Right > now it's another case of the loader (trampoline) bit-twiddling the > virtual addresses from the kernel's elf headers. I'm focusing on the non-trampoline case first. I agree that the trampoline is trickier. > I'm not sure we can completely wish away the trampoline, but I think = we > can define some conventions that ensure its existance is not a barrier > to having a generic kernel, pretty much just by saying so. For = example, > we could require that a kernel have valid physical addresses in the = elf > headers for the trampoline to operate on, and simply state that = generic > kernels designed to be loaded anywhere can't use the trampoline. I would be happy with this if we can't do any better. > I had to put some effort recently into figuring out some of the = perverse > details of how an at91 SoC gets from first-electrons to a running > kernel, and I took notes at the time. I started formatting the notes > into a wiki page, but only got the first half of them cleaned up. > Still, there may be some useful info even if the formatting is rough: >=20 > https://wiki.freebsd.org/FreeBSD/arm/BootProcess Thanks, I'll take a careful look at this. I have a lot of notes about the BeagleBone and RPi boot processes as well. Tim From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 17:00:56 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 483C16D3 for ; Thu, 28 Feb 2013 17:00:56 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 22E5F1E1 for ; Thu, 28 Feb 2013 17:00:55 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1SH0rLp045047; Thu, 28 Feb 2013 17:00:53 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 4iruuew6jz7xpsimy7u48kpdiw; Thu, 28 Feb 2013 17:00:53 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: I u-boot fails to compile Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Thu, 28 Feb 2013 09:00:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <154A3BF6-C851-41B7-9E75-2DC1BEA34219@kientzle.com> References: To: XiaoQI Ge X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 17:00:56 -0000 On FreeBSD, you have to link against libc, since a bunch of the core math functions are not in the compiler support library for FreeBSD/ARM. (They should be.) Tim On Feb 28, 2013, at 4:07 AM, XiaoQI Ge wrote: > I tried to compile U-BOOT = (https://github.com/linux-sunxi/u-boot-sunxi), > but failed, suggesting: >=20 > gmake [1]: *** [u-boot] Segmentation fault: 11 >=20 > I do not know how to solve. > =3D=3D=3D >=20 > cat /dev/null .depend.board >.depend > gmake[2]: Leaving directory > `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/board/allwinner/a10-evb' > gmake[2]: Entering directory > `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/board/allwinner/a10-evb' > arm-freebsd-gcc -g -Os -fno-common -ffixed-r8 -msoft-float > -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=3D0x4A000000 = -DCONFIG_SPL_TEXT_BASE=3D0x30 > -I/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include -fno-builtin > -ffreestanding -nostdinc -isystem /usr/arm-freebsd/usr/include -pipe > -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=3Daapcs-linux > -march=3Darmv5 -Wall -Wstrict-prototypes -fno-stack-protector > -Wno-format-nonliteral -Wno-format-security -o board.o board.c -c > In file included from > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include/common.h:840, > from board.c:27: > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include/net.h:359: warning: > declaration does not declare anything > arm-freebsd-ld -r -o liba10-evb.o board.o > gmake[2]: Leaving directory > `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/board/allwinner/a10-evb' > gmake -C /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu/ = u-boot.lds > gmake[2]: Entering directory > `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu' > gmake[2]: Nothing to be done for `u-boot.lds'. > gmake[2]: Leaving directory > `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu' > arm-freebsd-gcc -E -g -Os -fno-common -ffixed-r8 -msoft-float > -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=3D0x4A000000 = -DCONFIG_SPL_TEXT_BASE=3D0x30 > -I/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include -fno-builtin > -ffreestanding -nostdinc -isystem /usr/arm-freebsd/usr/include -pipe > -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=3Daapcs-linux > -march=3Darmv5 -include > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include/u-boot/u-boot.lds.h > -DCPUDIR=3Darch/arm/cpu/armv7 -ansi -D__ASSEMBLY__ -P - > > u-boot.lds > UNDEF_SYM=3D`arm-freebsd-objdump -x = board/allwinner/a10-evb/liba10-evb.o > api/libapi.o arch/arm/cpu/armv7/libarmv7.o > arch/arm/cpu/armv7/sunxi/libsunxi.o arch/arm/lib/libarm.o > board/allwinner/common/liballwinner.o common/libcommon.o = disk/libdisk.o > drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o > drivers/dfu/libdfu.o drivers/dma/libdma.o drivers/fpga/libfpga.o > drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o > drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o > drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o > drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o > drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o > drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o = drivers/power/libpower.o > drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o > drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o > drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o > drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o > drivers/usb/ulpi/libusb_ulpi.o drivers/video/libvideo.o > drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o = fs/ext4/libext4fs.o > fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o > fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o > fs/zfs/libzfs.o lib/libfdt/libfdt.o lib/libgeneric.o = lib/lzma/liblzma.o > lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o = test/libtest.o > | sed -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`; cd > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi && arm-freebsd-ld -pie -T > u-boot.lds -Bstatic -Ttext 0x4A000000 $UNDEF_SYM = arch/arm/cpu/armv7/start.o > --start-group api/libapi.o arch/arm/cpu/armv7/libarmv7.o > arch/arm/cpu/armv7/sunxi/libsunxi.o arch/arm/lib/libarm.o > board/allwinner/common/liballwinner.o common/libcommon.o = disk/libdisk.o > drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o > drivers/dfu/libdfu.o drivers/dma/libdma.o drivers/fpga/libfpga.o > drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o > drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o > drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o > drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o > drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o > drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o = drivers/power/libpower.o > drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o > drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o > drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o > drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o > drivers/usb/ulpi/libusb_ulpi.o drivers/video/libvideo.o > drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o = fs/ext4/libext4fs.o > fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o > fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o > fs/zfs/libzfs.o lib/libfdt/libfdt.o lib/libgeneric.o = lib/lzma/liblzma.o > lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o = test/libtest.o > board/allwinner/a10-evb/liba10-evb.o --end-group > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/lib/eabi_compat.o -L > /usr/arm-freebsd/usr/lib -lgcc -L /usr/arm-freebsd/usr/lib -lgcc -Map > u-boot.map -o u-boot > arch/arm/cpu/armv7/sunxi/libsunxi.o: In function `get_timer_masked': > = /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu/armv7/sunxi/timer.c:= 70: > undefined reference to `__udivsi3' > arch/arm/cpu/armv7/sunxi/libsunxi.o: In function `__udelay': > = /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu/armv7/sunxi/timer.c:= 83: > undefined reference to `__udivsi3' > arch/arm/cpu/armv7/sunxi/libsunxi.o: In function = `mctl_setup_dram_clock': > = /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu/armv7/sunxi/dram.c:2= 79: > undefined reference to `__udivsi3' > common/libcommon.o: In function `do_mem_md': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/cmd_mem.c:139: = undefined > reference to `__divsi3' > common/libcommon.o: In function `memalign': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/dlmalloc.c:2805: = undefined > reference to `__umodsi3' > common/libcommon.o: In function `read_env': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/env_mmc.c:163: = undefined > reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/env_mmc.c:165: = undefined > reference to `__udivsi3' > common/libcommon.o: In function `write_env': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/env_mmc.c:107: = undefined > reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/env_mmc.c:109: = undefined > reference to `__udivsi3' > disk/libdisk.o: In function `dev_print': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/disk/part.c:213: undefined > reference to `__udivsi3' > = disk/libdisk.o:/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/disk/part.c:217: > more undefined references to `__udivsi3' follow > drivers/mmc/libmmc.o: In function `mmc_berase': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/mmc.c:337: = undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/mmc.c:337: = undefined > reference to `__umodsi3' > drivers/mmc/libmmc.o: In function `mmc_config_clock': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/sunxi_mmc.c:282: > undefined reference to `__udivsi3' > drivers/mmc/libmmc.o: In function `mmc_clk_io_on': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/sunxi_mmc.c:236: > undefined reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/sunxi_mmc.c:242: > undefined reference to `__udivsi3' > drivers/power/libpower.o: In function `axp209_set_ldo3': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/power/axp209.c:107: > undefined reference to `__divsi3' > drivers/power/libpower.o: In function `axp209_set_ldo2': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/power/axp209.c:87: > undefined reference to `__divsi3' > drivers/power/libpower.o: In function `axp209_set_dcdc3': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/power/axp209.c:72: > undefined reference to `__divsi3' > drivers/power/libpower.o: In function `axp209_set_dcdc2': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/power/axp209.c:48: > undefined reference to `__divsi3' > drivers/serial/libserial.o: In function `calc_divisor': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/serial/serial.c:149: > undefined reference to `__udivsi3' > fs/ext4/libext4fs.o: In function `ext4fs_read_file': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4fs.c:84: = undefined > reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4fs.c:86: = undefined > reference to `__divsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4fs.c:99: = undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4fs.c:88: = undefined > reference to `__modsi3' > fs/ext4/libext4fs.o: In function `ext4fs_read_inode': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1482: > undefined reference to `__udivsi3' > fs/ext4/libext4fs.o: In function `ext4fs_blockgroup': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1466: > undefined reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1466: > undefined reference to `__umodsi3' > fs/ext4/libext4fs.o: In function `ext4fs_read_inode': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1487: > undefined reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1492: > undefined reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1492: > undefined reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1492: > undefined reference to `__modsi3' > fs/ext4/libext4fs.o: In function `read_allocated_block': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1676: > undefined reference to `__divsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1695: > undefined reference to `__modsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1766: > undefined reference to `__divsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1810: > undefined reference to `__divsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1814: > undefined reference to `__modsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1833: > undefined reference to `__modsi3' > fs/fat/libfat.o: In function `get_fatent': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat.c:191: undefined > reference to `__udivsi3' > fs/fat/libfat.o: In function `check_overflow': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:792: = undefined > reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:793: = undefined > reference to `__umodsi3' > fs/fat/libfat.o: In function `set_fatent_value': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:486: = undefined > reference to `__udivsi3' > fs/fat/libfat.o: In function `get_fatent_value': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:168: = undefined > reference to `__udivsi3' > fs/fat/libfat.o: In function `set_cluster': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:574: = undefined > reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:579: = undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:582: = undefined > reference to `__udivsi3' > fs/fat/libfat.o: In function `get_cluster': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat.c:304: undefined > reference to `__udivsi3' > fs/fat/libfat.o: In function `do_fat_write': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:968: = undefined > reference to `__udivsi3' > fs/fat/libfat.o: In function `find_directory_entry': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:826: = undefined > reference to `__divsi3' > fs/fat/libfat.o: In function `do_fat_read_at': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat.c:873: undefined > reference to `__udivsi3' > fs/zfs/libzfs.o: In function `fzap_iterate': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/zfs/zfs.c:1004: undefined > reference to `__divsi3' > fs/zfs/libzfs.o: In function `zap_leaf_lookup': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/zfs/zfs.c:850: undefined > reference to `__divsi3' > fs/zfs/libzfs.o: In function `zfs_read': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/zfs/zfs.c:2163: undefined > reference to `__umodsi3' > lib/libgeneric.o: In function `print_buffer': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/display_options.c:112: > undefined reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/display_options.c:114: > undefined reference to `__udivsi3' > lib/libgeneric.o: In function `__div64_32': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/div64.c:31: undefined > reference to `__udivsi3' > lib/libgeneric.o: In function `isprime': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/hashtable.c:91: undefined > reference to `__umodsi3' > lib/libgeneric.o: In function `hcreate_r': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/hashtable.c:120: = undefined > reference to `__umodsi3' > lib/libgeneric.o: In function `hsearch_r': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/hashtable.c:274: = undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/hashtable.c:314: = undefined > reference to `__umodsi3' > lib/libgeneric.o: In function `ldiv': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/ldiv.c:29: undefined = reference > to `__divsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/ldiv.c:30: undefined = reference > to `__modsi3' > lib/libgeneric.o: In function `qsort': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/qsort.c:35: undefined > reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/qsort.c:63: undefined > reference to `__udivsi3' > lib/libgeneric.o: In function `strmhz': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/strmhz.c:30: undefined > reference to `__udivsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/strmhz.c:34: undefined > reference to `__udivsi3' > lib/libgeneric.o: In function `simple_itoa': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/vsprintf.c:813: undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/vsprintf.c:814: undefined > reference to `__udivsi3' > lib/libgeneric.o: In function `put_dec': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/vsprintf.c:258: undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/vsprintf.c:258: undefined > reference to `__udivsi3' > lib/zlib/libz.o: In function `adler32': > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:93: = undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:104: = undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:105: = undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:119: = undefined > reference to `__umodsi3' > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:120: = undefined > reference to `__umodsi3' > = lib/zlib/libz.o:/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/inflate.= c:390: > more undefined references to `__umodsi3' follow > arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail > = /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutil= s/bfd/elf32-arm.c:8911 > arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail > = /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutil= s/bfd/elf32-arm.c:8911 > arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail > = /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutil= s/bfd/elf32-arm.c:8911 > arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail > = /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutil= s/bfd/elf32-arm.c:8911 > arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail > = /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutil= s/bfd/elf32-arm.c:9138 > gmake[1]: *** [u-boot] Segmentation fault: 11 > gmake[1]: *** Deleting file `u-boot' > gmake[1]: Leaving directory `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi' > gmake: *** [sun4i] Error 2 > [ghw@7axu.pts/5] ~/CNPROJ/CubieBoard/u-boot-sunxi % >=20 >=20 > Thanks >=20 > =3D=3D=3D > Welcome to Ge, XiaoQI's Homepage! > Gtalk/E-Mail :ghw@7axu.com > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 17:02:20 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E8DC77E3 for ; Thu, 28 Feb 2013 17:02:20 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id CB889201 for ; Thu, 28 Feb 2013 17:02:20 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1SH2KMl045063; Thu, 28 Feb 2013 17:02:20 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id gnkzu3axkhep8e5rzbqt4nq8fa; Thu, 28 Feb 2013 17:02:19 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Stuck at the 88 package mark Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20130228025525.272a7e92@ivory.wynn.com> Date: Thu, 28 Feb 2013 09:02:19 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <20130228025525.272a7e92@ivory.wynn.com> To: Brett Wynkoop X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 17:02:21 -0000 "armv6" is not a standard architecture recognized by GNU binutils. You probably just need to override that to use "arm". Tim On Feb 27, 2013, at 11:55 PM, Brett Wynkoop wrote: > Greeting- > > My build of zoneminder died in /usr/ports/devel/binutils. Before I dig > too deep has someone already solved this one? > > checking for lwpstatus_t.pr_reg in sys/procfs.h... no > checking for lwpstatus_t.pr_fpreg in sys/procfs.h... no > checking for win32_pstatus_t in sys/procfs.h... no > checking linker --as-needed support... yes > checking for cos in -lm... yes > *** BFD does not support target armv6-portbld-freebsd10.0. > *** Look in bfd/config.bfd for supported targets. > *** [configure-bfd] Error code 1 > > Stop in /export/ports/devel/binutils/work/binutils-2.23.1. > *** [all] Error code 1 > > Stop in /export/ports/devel/binutils/work/binutils-2.23.1. > > I suspect it is just a matter of putting the right thing in for the > supported target, but I am not sure what to put there? There is some > arm stuff in bfd/config.bfd. > > So if someone has solved this let me know. If someone knows what I > might want to put in the config file that would be good too. I am > looking for something that will be generic to Pi/Bone/Plug/You-get-me! > > Thanks! > > -Brett > -- > > wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt > 917-642-6925 > 718-717-5435 > > I would never invade the United States. There would be a gun behind > every blade of grass. --Isoroku Yamamoto > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 17:44:53 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4D696180; Thu, 28 Feb 2013 17:44:53 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 2CB8469E; Thu, 28 Feb 2013 17:44:52 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1SHiqFQ045344; Thu, 28 Feb 2013 17:44:52 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id zvw5avkge3s3wicwgpzqdimp56; Thu, 28 Feb 2013 17:44:52 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: PHYSADDR Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1251 From: Tim Kientzle In-Reply-To: <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> Date: Thu, 28 Feb 2013 09:44:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 17:44:53 -0000 On Feb 28, 2013, at 8:58 AM, Tim Kientzle wrote: >=20 > On Feb 28, 2013, at 8:20 AM, Ian Lepore wrote: >=20 >> On Wed, 2013-02-27 at 22:27 -0800, Tim Kientzle wrote: >>> Starting to look at what is needed for a Generic ARM kernel. >>> There's a lot here; I sincerely hope I'm not the only one=85 ;-) >>>=20 >>> First up: Can we get rid of PHYSADDR? >>>=20 >>=20 >> If you mean, can we get rid of it within the runtime kernel, I'd say >> yes, because we can use a global variable instead which is easily >> settable in the entry code. >=20 > It doesn't seem to be used in the runtime kernel. As far as > I can see, it's purely a bootstrap concept. >=20 >> On the other hand, I've been working >> towards getting that value set correctly in the kernel elf headers at >> link time. A-ha! I think I just figured something out. How would the following work: * Rename PHYSADDR to KERNPHYSADDR_BASE * in the top of locore.s, we have a single conditional: #ifdef KERNPHYSADDR_BASE _kpa_base =3D KERNPHYSADDR_BASE; #else _kpa_base =3D pc & 0xF0000000; #endif I think this would DTRT on all of the configurations we currently have in SVN. * We redefine KERNPHYSADDR to be an *offset* against _kpa_base. Then we could negotiate a single offset (64k?) that works well on many platforms and use that for the GENERIC kernel. Boot loaders would be responsible for loading the kernel at an address that preserves the KPA_OFFSET. The KPA_OFFSET would be used in the ELF headers. Then there are routine code transformations to use _kpa_base instead of the compile-time symbol and to use _kpa_base + KERNPHYSADDR instead of KERNPHYSADDR. Does this sound reasonable as a starting point? It doesn't solve the trampoline problem, but I'm willing to defer that. Tim From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 20:19:28 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4222F281 for ; Thu, 28 Feb 2013 20:19:28 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 504A5FE4 for ; Thu, 28 Feb 2013 20:19:27 +0000 (UTC) Received: from rnote.ddteam.net (12-60-135-95.pool.ukrtel.net [95.135.60.12]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 3283AC4927; Thu, 28 Feb 2013 22:19:25 +0200 (EET) Date: Thu, 28 Feb 2013 22:19:09 +0200 From: Aleksandr Rybalko To: Tim Kientzle Subject: Re: I u-boot fails to compile Message-Id: <20130228221909.bcc4a8a3.ray@freebsd.org> In-Reply-To: <154A3BF6-C851-41B7-9E75-2DC1BEA34219@kientzle.com> References: <154A3BF6-C851-41B7-9E75-2DC1BEA34219@kientzle.com> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 20:19:28 -0000 On Thu, 28 Feb 2013 09:00:53 -0800 Tim Kientzle wrote: > On FreeBSD, you have to link against libc, since a bunch > of the core math functions are not in the compiler support > library for FreeBSD/ARM. (They should be.) > > Tim > # Path to toolchain binaries CROSS=/usr/obj/arm.armv6/usr/src/tmp/usr/bin/ gmake ARCH=arm CROSS_COMPILE=${CROSS} USE_PRIVATE_LIBGCC=yes May help also :) > > On Feb 28, 2013, at 4:07 AM, XiaoQI Ge wrote: > > > I tried to compile U-BOOT > > (https://github.com/linux-sunxi/u-boot-sunxi), but failed, > > suggesting: > > > > gmake [1]: *** [u-boot] Segmentation fault: 11 > > > > I do not know how to solve. > > === > > > > cat /dev/null .depend.board >.depend > > gmake[2]: Leaving directory > > `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/board/allwinner/a10-evb' > > gmake[2]: Entering directory > > `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/board/allwinner/a10-evb' > > arm-freebsd-gcc -g -Os -fno-common -ffixed-r8 -msoft-float > > -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x4A000000 > > -DCONFIG_SPL_TEXT_BASE=0x30 > > -I/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include -fno-builtin > > -ffreestanding -nostdinc -isystem /usr/arm-freebsd/usr/include > > -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork > > -mabi=aapcs-linux -march=armv5 -Wall -Wstrict-prototypes > > -fno-stack-protector -Wno-format-nonliteral > > -Wno-format-security -o board.o board.c -c In file included > > from /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include/common.h:840, > > from > > board.c:27: /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include/net.h:359: > > warning: declaration does not declare anything arm-freebsd-ld -r > > -o liba10-evb.o board.o gmake[2]: Leaving directory > > `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/board/allwinner/a10-evb' > > gmake -C /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu/ > > u-boot.lds gmake[2]: Entering directory > > `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu' > > gmake[2]: Nothing to be done for `u-boot.lds'. > > gmake[2]: Leaving directory > > `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu' > > arm-freebsd-gcc -E -g -Os -fno-common -ffixed-r8 -msoft-float > > -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x4A000000 > > -DCONFIG_SPL_TEXT_BASE=0x30 > > -I/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include -fno-builtin > > -ffreestanding -nostdinc -isystem /usr/arm-freebsd/usr/include > > -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork > > -mabi=aapcs-linux -march=armv5 > > -include /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/include/u-boot/u-boot.lds.h > > -DCPUDIR=arch/arm/cpu/armv7 -ansi -D__ASSEMBLY__ -P - > > >> u-boot.lds > > UNDEF_SYM=`arm-freebsd-objdump -x > > board/allwinner/a10-evb/liba10-evb.o api/libapi.o > > arch/arm/cpu/armv7/libarmv7.o arch/arm/cpu/armv7/sunxi/libsunxi.o > > arch/arm/lib/libarm.o board/allwinner/common/liballwinner.o > > common/libcommon.o disk/libdisk.o > > drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o > > drivers/dfu/libdfu.o drivers/dma/libdma.o drivers/fpga/libfpga.o > > drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o > > drivers/i2c/libi2c.o drivers/input/libinput.o > > drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o > > drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o > > drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o > > drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o > > drivers/pcmcia/libpcmcia.o drivers/power/libpower.o > > drivers/rtc/librtc.o drivers/serial/libserial.o > > drivers/spi/libspi.o drivers/twserial/libtws.o > > drivers/usb/eth/libusb_eth.o drivers/usb/gadget/libusb_gadget.o > > drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o > > drivers/usb/phy/libusb_phy.o drivers/usb/ulpi/libusb_ulpi.o > > drivers/video/libvideo.o drivers/watchdog/libwatchdog.o > > fs/cramfs/libcramfs.o fs/ext4/libext4fs.o fs/fat/libfat.o > > fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o > > fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o fs/zfs/libzfs.o > > lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o > > lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o > > test/libtest.o > > | sed -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`; cd > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi && arm-freebsd-ld -pie -T > > u-boot.lds -Bstatic -Ttext 0x4A000000 $UNDEF_SYM > > arch/arm/cpu/armv7/start.o > > --start-group api/libapi.o arch/arm/cpu/armv7/libarmv7.o > > arch/arm/cpu/armv7/sunxi/libsunxi.o arch/arm/lib/libarm.o > > board/allwinner/common/liballwinner.o common/libcommon.o > > disk/libdisk.o drivers/bios_emulator/libatibiosemu.o > > drivers/block/libblock.o drivers/dfu/libdfu.o drivers/dma/libdma.o > > drivers/fpga/libfpga.o drivers/gpio/libgpio.o > > drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o > > drivers/input/libinput.o drivers/misc/libmisc.o > > drivers/mmc/libmmc.o drivers/mtd/libmtd.o > > drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o > > drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o > > drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o > > drivers/pcmcia/libpcmcia.o drivers/power/libpower.o > > drivers/rtc/librtc.o drivers/serial/libserial.o > > drivers/spi/libspi.o drivers/twserial/libtws.o > > drivers/usb/eth/libusb_eth.o drivers/usb/gadget/libusb_gadget.o > > drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o > > drivers/usb/phy/libusb_phy.o drivers/usb/ulpi/libusb_ulpi.o > > drivers/video/libvideo.o drivers/watchdog/libwatchdog.o > > fs/cramfs/libcramfs.o fs/ext4/libext4fs.o fs/fat/libfat.o > > fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o > > fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o fs/zfs/libzfs.o > > lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o > > lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o > > test/libtest.o board/allwinner/a10-evb/liba10-evb.o > > --end-group /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/lib/eabi_compat.o > > -L /usr/arm-freebsd/usr/lib -lgcc -L /usr/arm-freebsd/usr/lib -lgcc > > -Map u-boot.map -o u-boot arch/arm/cpu/armv7/sunxi/libsunxi.o: In > > function > > `get_timer_masked': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu/armv7/sunxi/timer.c:70: > > undefined reference to `__udivsi3' > > arch/arm/cpu/armv7/sunxi/libsunxi.o: In function > > `__udelay': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu/armv7/sunxi/timer.c:83: > > undefined reference to `__udivsi3' > > arch/arm/cpu/armv7/sunxi/libsunxi.o: In function > > `mctl_setup_dram_clock': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/arch/arm/cpu/armv7/sunxi/dram.c:279: > > undefined reference to `__udivsi3' common/libcommon.o: In function > > `do_mem_md': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/cmd_mem.c:139: > > undefined reference to `__divsi3' common/libcommon.o: In function > > `memalign': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/dlmalloc.c:2805: > > undefined reference to `__umodsi3' common/libcommon.o: In function > > `read_env': /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/env_mmc.c:163: > > undefined reference to `__udivsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/env_mmc.c:165: > > undefined reference to `__udivsi3' > > common/libcommon.o: In function `write_env': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/env_mmc.c:107: > > undefined reference to `__udivsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/common/env_mmc.c:109: > > undefined reference to `__udivsi3' > > disk/libdisk.o: In function `dev_print': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/disk/part.c:213: undefined > > reference to `__udivsi3' > > disk/libdisk.o:/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/disk/part.c:217: > > more undefined references to `__udivsi3' follow > > drivers/mmc/libmmc.o: In function `mmc_berase': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/mmc.c:337: > > undefined reference to `__umodsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/mmc.c:337: > > undefined reference to `__umodsi3' > > drivers/mmc/libmmc.o: In function `mmc_config_clock': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/sunxi_mmc.c:282: > > undefined reference to `__udivsi3' > > drivers/mmc/libmmc.o: In function `mmc_clk_io_on': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/sunxi_mmc.c:236: > > undefined reference to `__udivsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/mmc/sunxi_mmc.c:242: > > undefined reference to `__udivsi3' > > drivers/power/libpower.o: In function `axp209_set_ldo3': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/power/axp209.c:107: > > undefined reference to `__divsi3' > > drivers/power/libpower.o: In function `axp209_set_ldo2': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/power/axp209.c:87: > > undefined reference to `__divsi3' > > drivers/power/libpower.o: In function `axp209_set_dcdc3': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/power/axp209.c:72: > > undefined reference to `__divsi3' > > drivers/power/libpower.o: In function `axp209_set_dcdc2': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/power/axp209.c:48: > > undefined reference to `__divsi3' > > drivers/serial/libserial.o: In function `calc_divisor': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/drivers/serial/serial.c:149: > > undefined reference to `__udivsi3' > > fs/ext4/libext4fs.o: In function `ext4fs_read_file': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4fs.c:84: > > undefined reference to `__udivsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4fs.c:86: > > undefined reference to `__divsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4fs.c:99: > > undefined reference to `__umodsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4fs.c:88: > > undefined reference to `__modsi3' > > fs/ext4/libext4fs.o: In function `ext4fs_read_inode': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1482: > > undefined reference to `__udivsi3' > > fs/ext4/libext4fs.o: In function `ext4fs_blockgroup': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1466: > > undefined reference to `__udivsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1466: > > undefined reference to `__umodsi3' > > fs/ext4/libext4fs.o: In function `ext4fs_read_inode': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1487: > > undefined reference to `__udivsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1492: > > undefined reference to `__umodsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1492: > > undefined reference to `__udivsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1492: > > undefined reference to `__modsi3' > > fs/ext4/libext4fs.o: In function `read_allocated_block': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1676: > > undefined reference to `__divsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1695: > > undefined reference to `__modsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1766: > > undefined reference to `__divsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1810: > > undefined reference to `__divsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1814: > > undefined reference to `__modsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/ext4/ext4_common.c:1833: > > undefined reference to `__modsi3' > > fs/fat/libfat.o: In function `get_fatent': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat.c:191: undefined > > reference to `__udivsi3' > > fs/fat/libfat.o: In function `check_overflow': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:792: > > undefined reference to `__udivsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:793: > > undefined reference to `__umodsi3' > > fs/fat/libfat.o: In function `set_fatent_value': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:486: > > undefined reference to `__udivsi3' > > fs/fat/libfat.o: In function `get_fatent_value': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:168: > > undefined reference to `__udivsi3' > > fs/fat/libfat.o: In function `set_cluster': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:574: > > undefined reference to `__udivsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:579: > > undefined reference to `__umodsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:582: > > undefined reference to `__udivsi3' > > fs/fat/libfat.o: In function `get_cluster': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat.c:304: undefined > > reference to `__udivsi3' > > fs/fat/libfat.o: In function `do_fat_write': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:968: > > undefined reference to `__udivsi3' > > fs/fat/libfat.o: In function `find_directory_entry': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat_write.c:826: > > undefined reference to `__divsi3' > > fs/fat/libfat.o: In function `do_fat_read_at': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/fat/fat.c:873: undefined > > reference to `__udivsi3' > > fs/zfs/libzfs.o: In function `fzap_iterate': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/zfs/zfs.c:1004: > > undefined reference to `__divsi3' > > fs/zfs/libzfs.o: In function `zap_leaf_lookup': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/zfs/zfs.c:850: undefined > > reference to `__divsi3' > > fs/zfs/libzfs.o: In function `zfs_read': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/fs/zfs/zfs.c:2163: > > undefined reference to `__umodsi3' > > lib/libgeneric.o: In function `print_buffer': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/display_options.c:112: > > undefined reference to `__udivsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/display_options.c:114: > > undefined reference to `__udivsi3' > > lib/libgeneric.o: In function `__div64_32': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/div64.c:31: undefined > > reference to `__udivsi3' > > lib/libgeneric.o: In function `isprime': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/hashtable.c:91: > > undefined reference to `__umodsi3' > > lib/libgeneric.o: In function `hcreate_r': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/hashtable.c:120: > > undefined reference to `__umodsi3' > > lib/libgeneric.o: In function `hsearch_r': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/hashtable.c:274: > > undefined reference to `__umodsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/hashtable.c:314: > > undefined reference to `__umodsi3' > > lib/libgeneric.o: In function `ldiv': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/ldiv.c:29: undefined > > reference to `__divsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/ldiv.c:30: undefined > > reference to `__modsi3' > > lib/libgeneric.o: In function `qsort': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/qsort.c:35: undefined > > reference to `__udivsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/qsort.c:63: undefined > > reference to `__udivsi3' > > lib/libgeneric.o: In function `strmhz': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/strmhz.c:30: undefined > > reference to `__udivsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/strmhz.c:34: undefined > > reference to `__udivsi3' > > lib/libgeneric.o: In function `simple_itoa': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/vsprintf.c:813: > > undefined reference to `__umodsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/vsprintf.c:814: > > undefined reference to `__udivsi3' > > lib/libgeneric.o: In function `put_dec': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/vsprintf.c:258: > > undefined reference to `__umodsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/vsprintf.c:258: > > undefined reference to `__udivsi3' > > lib/zlib/libz.o: In function `adler32': > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:93: > > undefined reference to `__umodsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:104: > > undefined reference to `__umodsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:105: > > undefined reference to `__umodsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:119: > > undefined reference to `__umodsi3' > > /home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/adler32.c:120: > > undefined reference to `__umodsi3' > > lib/zlib/libz.o:/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi/lib/zlib/inflate.c:390: > > more undefined references to `__umodsi3' follow > > arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail > > /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-arm.c:8911 > > arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail > > /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-arm.c:8911 > > arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail > > /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-arm.c:8911 > > arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail > > /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-arm.c:8911 > > arm-freebsd-ld: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail > > /home/freebsd-head/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-arm.c:9138 > > gmake[1]: *** [u-boot] Segmentation fault: 11 > > gmake[1]: *** Deleting file `u-boot' > > gmake[1]: Leaving directory > > `/home/ghw/CNPROJ/CubieBoard/u-boot-sunxi' gmake: *** [sun4i] Error > > 2 [ghw@7axu.pts/5] ~/CNPROJ/CubieBoard/u-boot-sunxi % > > > > > > Thanks > > > > === > > Welcome to Ge, XiaoQI's Homepage! > > Gtalk/E-Mail :ghw@7axu.com > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to > > "freebsd-arm-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 20:24:21 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1D501320; Thu, 28 Feb 2013 20:24:21 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id B913D71; Thu, 28 Feb 2013 20:24:20 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1SKOD6q038452; Thu, 28 Feb 2013 15:24:13 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Thu, 28 Feb 2013 15:24:13 -0500 From: Brett Wynkoop To: Tim Kientzle Subject: Re: PHYSADDR Message-ID: <20130228152413.5aa303e8@ivory.wynn.com> In-Reply-To: <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 20:24:21 -0000 On Thu, 28 Feb 2013 09:44:51 -0800 Tim Kientzle wrote: > It doesn't solve the trampoline problem, but I'm willing to > defer that. Trampoline problem? I presume this has nothing to do with sport equipment. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 April 19, 1775 An English attempt to confiscate guns from Americans triggered a successful revolution...... Dear Congress, that's a hint. From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 21:02:27 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E9EA0895; Thu, 28 Feb 2013 21:02:27 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 6B70A1F6; Thu, 28 Feb 2013 21:02:27 +0000 (UTC) Received: from rnote.ddteam.net (12-60-135-95.pool.ukrtel.net [95.135.60.12]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 87EE4C4930; Thu, 28 Feb 2013 23:02:19 +0200 (EET) Date: Thu, 28 Feb 2013 23:02:03 +0200 From: Aleksandr Rybalko To: Tim Kientzle Subject: Re: PHYSADDR Message-Id: <20130228230203.e6228ff1.ray@freebsd.org> In-Reply-To: <1F9B0ED4-7FAF-43D8-BECD-1D42792E81DF@freebsd.org> References: <1A428660-39FB-45EB-979B-103F7E83BC4A@bsdimp.com> <1F9B0ED4-7FAF-43D8-BECD-1D42792E81DF@freebsd.org> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 21:02:28 -0000 On Thu, 28 Feb 2013 08:56:54 -0800 Tim Kientzle wrote: > > On Feb 27, 2013, at 10:41 PM, Warner Losh wrote: > > > > > On Feb 27, 2013, at 11:27 PM, Tim Kientzle wrote: > > > >> Starting to look at what is needed for a Generic ARM kernel. > >> There's a lot here; I sincerely hope I'm not the only one… ;-) > >> > >> First up: Can we get rid of PHYSADDR? > > > > There's lots of places in the tree that use it, but not so many > > that a whack-a-mole approach wouldn't work. > > It's mostly only used in locore.S and machdep.c (and, of course, > the many copies of machdep.c). > > >> I think we can always compute it at runtime from PC. > >> > >> For example, I think this works in several places: > >> and r0, pc, #0xF0000000 > > > > This only works early in boot before we've turned on the MMU, right? > > I'm still pretty new to this section of the code, so might have > missed something, but I don't think we need PHYSADDR > after the kernel has relocated itself. > > Do we? > > > > >> And I've found at least one reference that I think can be simply > >> eliminated: > >> > >> Index: arm/elf_trampoline.c > >> =================================================================== > >> --- arm/elf_trampoline.c (revision 247250) > >> +++ arm/elf_trampoline.c (working copy) > >> @@ -169,7 +169,7 @@ > >> void > >> _startC(void) > >> { > >> - int physaddr = KERNPHYSADDR; > >> + unsigned int physaddr = (unsigned int)&_start & > >> 0xfffff000; > > > > How'd you come up with this? Perhaps we should just define > > KERNPHYSADDR as this gross expression :) > > > > But isn't _start a virtual address, not a physical address? > > Honestly, I'm still trying to figure that part out. ;-) > > Disassembling the compiler output, taking the > address of the current function always uses a > PC-relative address. So &_startC here would > give the current address of the function as it's > executing. > > > > >> int tmp1; > >> unsigned int sp = ((unsigned int)&_end & ~3) + 4; > >> #if defined(FLASHADDR) && defined(LOADERRAMADDR) > >> @@ -189,10 +189,9 @@ > >> */ > >> unsigned int target_addr; > >> unsigned int tmp_sp; > >> - uint32_t src_addr = (uint32_t)&_start - PHYSADDR > >> + FLASHADDR > >> - + (pc - FLASHADDR - ((uint32_t)&_startC - > >> PHYSADDR)) & 0xfffff000; > >> + uint32_t src_addr = (uint32_t)&_start; > > > > I'm not sure how this works… > > Here's my reasoning: > FLASHADDR and PHYSADDR are always multiples of 4k, > so you can pull those out of the parentheses to get: > > _start - PHYSADDR + FLASHADDR - FLASHADD + PHYSADDR + (pc - > _startC) & 0xffffff000 > > And since pc was sampled early in _startC, the last expression > should always be zero. > > I was a little surprised by this myself, so I might have missed > something. > > >> - target_addr = (unsigned int)&_start - PHYSADDR + > >> LOADERRAMADDR; > >> + target_addr = (unsigned int)&_start - (pc & > >> 0xf0000000) + LOADERRAMADDR; > > > > This might work, but I'd suggest a PC_TO_PHYSADDR(pc) macro or > > something similar… > > I'll try that later on. I suspect some of these PHYSADDRs > will simply go away, since I think what we really want in > the early bootstrap stage is just "what address is the > kernel currently executing at". I still need to piece together > some more things before I understand that. > > As with the above, at least some of the expressions > using PHYSADDR seem more complex than necessary. > > > >> tmp_sp = target_addr + 0x100000 + > >> (unsigned int)&_end - (unsigned int)&_start; > >> memcpy((char *)target_addr, (char *)src_addr, > >> > >> > >> Tim > >> > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" We will have problems sometime with pc & 0xf0000000, because a lot of hardware already on market with RAM size more than 256M. So if loader load kernel higher than 256M with 0xf0000000 mask we will assume wrong segment start address. IMO we need to get such info from DTB and better to parse it with loader(8), then pass it with kenv to kernel. Since FDT already have info about physical RAM location you can calculate difference and make decision to move kernel lower, like trampoline do. Thanks! WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 22:02:23 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4AF1FD2F for ; Thu, 28 Feb 2013 22:02:23 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id C476866C for ; Thu, 28 Feb 2013 22:02:22 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UBBYQ-000DMU-3S; Thu, 28 Feb 2013 14:02:20 -0800 Message-ID: <512FD3E8.4000307@bluezbox.com> Date: Thu, 28 Feb 2013 14:02:16 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Daisuke Aoyama Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 1/29/2013 10:10 AM, Daisuke Aoyama wrote: > I've updated clang RPI code based on SVN r246066. > This is OABI version. I plan to try EABI next if possible. > > major change: > o update base tree to SVN r246066. > o implement -mload-store-multiple/-mno-load-store-multiple option in > clang/llvm. (workaround only) > o re-enable __clear_cache() in libgcc. > o bugfix bcm2835_dma inline asm code, etc. > o use bcm2835_dma_wb/wbinv in SDHCI. > o add USB LAN and wireless LAN driver module. (loaded by devd > automatically) > o move swap to head of partition. > o use label mount instead of /dev/mmcsd0s2a, /dev/mmcsd0s2b. > o add wireless lan, quota, ipfw and IPv6 to kernel config. > o change default HS mode is enabled. > > To prevent a fault on ldm/stm generated by clang, all files are > complied with: > CFLAGS=-O2 -mno-global-merge -mno-load-store-multiple > -fno-strict-aliasing -pipe -mabi=apcs-gnu -march=armv6z > -mtune=arm1176jzf-s -mfloat-abi=soft > > To reduce time in DMA intr, it uses bcm2835_dma_wb/wbinv directly. > Now it gets 20.7MB/s DMA transfer rate on class 10 SD card. (depend on > card spec) > It's 30% faster than bus_space_XXX/bus_dmamap_XXX. > >> root@raspberry-pi:~ # dd if=/dev/mmcsd0 of=/dev/null bs=1m count=32 >> 32+0 records in >> 32+0 records out >> 33554432 bytes transferred in 1.617316 secs (20746986 bytes/sec) > > Known issue: > DMA intr might be delayed by slow interrupt handler. > (arm/intr.c:arm_handler_execute specific, should be remapped DMA IRQ > to low number) [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 22:02:23 -0000 On 1/29/2013 10:10 AM, Daisuke Aoyama wrote: > I've updated clang RPI code based on SVN r246066. > This is OABI version. I plan to try EABI next if possible. > > major change: > o update base tree to SVN r246066. > o implement -mload-store-multiple/-mno-load-store-multiple option in > clang/llvm. (workaround only) > o re-enable __clear_cache() in libgcc. > o bugfix bcm2835_dma inline asm code, etc. > o use bcm2835_dma_wb/wbinv in SDHCI. > o add USB LAN and wireless LAN driver module. (loaded by devd > automatically) > o move swap to head of partition. > o use label mount instead of /dev/mmcsd0s2a,/dev/mmcsd0s2b. > o add wireless lan, quota, ipfw and IPv6 to kernel config. > o change default HS mode is enabled. > > To prevent a fault on ldm/stm generated by clang, all files are > complied with: > CFLAGS=-O2 -mno-global-merge -mno-load-store-multiple > -fno-strict-aliasing -pipe -mabi=apcs-gnu -march=armv6z > -mtune=arm1176jzf-s -mfloat-abi=soft > > To reduce time in DMA intr, it uses bcm2835_dma_wb/wbinv directly. > Now it gets 20.7MB/s DMA transfer rate on class 10 SD card. (depend on > card spec) > It's 30% faster than bus_space_XXX/bus_dmamap_XXX. > >> root@raspberry-pi:~ # dd if=/dev/mmcsd0 of=/dev/null bs=1m count=32 >> 32+0 records in >> 32+0 records out >> 33554432 bytes transferred in 1.617316 secs (20746986 bytes/sec) > > Known issue: > DMA intr might be delayed by slow interrupt handler. > (arm/intr.c:arm_handler_execute specific, should be remapped DMA IRQ > to low number) Hi Daisuke, I'd like to thank you again for your outstanding work. I've just committed three patches based on your code: - Platform DMA support for SDHCI - DMA engine driver - DMA support for BCM2835 SDHCI driver I made some architectural changes to them in order to make code compatible with FreeBSD codebase style. Namely: - Replaced direct access to DMA control blocks with calls to API - Make both DMA and SDHCI driver use bus_dma and bus_space interface. You've pinpointed several pain points with bus_space and bus_dma but I believe they should be addressed in more general fashion, for as many ARM platforms as possible that's why I left them in the committed version. From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 22:13:29 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 95B5DE9D for ; Thu, 28 Feb 2013 22:13:29 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 3D7106AB for ; Thu, 28 Feb 2013 22:13:29 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UBBjC-000DUZ-6C; Thu, 28 Feb 2013 14:13:28 -0800 Message-ID: <512FD685.8070009@bluezbox.com> Date: Thu, 28 Feb 2013 14:13:25 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: I u-boot fails to compile References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2/28/2013 4:07 AM, XiaoQI Ge wrote: > I tried to compile U-BOOT (https://github.com/linux-sunxi/u-boot-sunxi), > but failed, suggesting: > > gmake [1]: *** [u-boot] Segmentation fault: 11 > > I do not know how to solve. > [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 22:13:29 -0000 On 2/28/2013 4:07 AM, XiaoQI Ge wrote: > I tried to compile U-BOOT (https://github.com/linux-sunxi/u-boot-sunxi), > but failed, suggesting: > > gmake [1]: *** [u-boot] Segmentation fault: 11 > > I do not know how to solve. > In addition to Tim's patches for libc and static you'll also need to use gsed instead of sed with later versions of u-boot repo. Install textproc/gsed and rename sed to gsed in helper.mk. I have patch for using user-defined sed name but haven't pushed it to upstream yet. From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 22:28:38 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4A74D1FB for ; Thu, 28 Feb 2013 22:28:38 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id F39AD720 for ; Thu, 28 Feb 2013 22:28:37 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UBBxr-000Dcx-Fl; Thu, 28 Feb 2013 14:28:37 -0800 Message-ID: <512FDA12.50900@bluezbox.com> Date: Thu, 28 Feb 2013 14:28:34 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Thomas Skibo Subject: Re: FreeBSD on Zedboard (Xilinx Zynq-7000) SD card image References: <512EA0A8.5040103@sbcglobal.net> <41A62BB3-10E3-4BC4-A4A2-82DD04072386@bluezbox.com> <512F73B7.50404@sbcglobal.net> In-Reply-To: <512F73B7.50404@sbcglobal.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2/28/2013 7:11 AM, Thomas Skibo wrote: > > I don't have anything specific in mind but I hope I can wind down > kernel hacking and do some FPGA hacking. I've developed a device > config driver so you can reprogram the PL (FPGA) section with "cat > system.bit.bin > /dev/devcfg0". [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 22:28:38 -0000 On 2/28/2013 7:11 AM, Thomas Skibo wrote: > > I don't have anything specific in mind but I hope I can wind down > kernel hacking and do some FPGA hacking. I've developed a device > config driver so you can reprogram the PL (FPGA) section with "cat > system.bit.bin > /dev/devcfg0". Yeah, that's what I meant by "interfacing" - ability to upload bitstream to FPGA directly from FreeBSD. Although I think ioctl interface seems more fool-proof than simple raw access to device. > > On 2/27/13 10:02 PM, Oleksandr Tymoshenko wrote: >> >> Awesome! Thanks, Thomas. >> Do you have any plans to work on interfacing FPGA part of the board >> with FreeBSD? >> >> > From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 22:48:47 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BD1FC792; Thu, 28 Feb 2013 22:48:47 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 22E1C7F0; Thu, 28 Feb 2013 22:48:46 +0000 (UTC) Received: from rnote.ddteam.net (12-60-135-95.pool.ukrtel.net [95.135.60.12]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id DDA49C492D; Fri, 1 Mar 2013 00:48:44 +0200 (EET) Date: Fri, 1 Mar 2013 00:48:28 +0200 From: Aleksandr Rybalko To: Ian Lepore Subject: Re: SPI, _sz fields in struct spi_command Message-Id: <20130301004828.e0727064.ray@freebsd.org> In-Reply-To: <1361488675.1185.42.camel@revolution.hippie.lan> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> <20130221163003.GC12189@cicely7.cicely.de> <20130222000207.d1478231.ray@freebsd.org> <1361486385.1185.38.camel@revolution.hippie.lan> <20130222005926.2aa6db7f.ray@freebsd.org> <1361488675.1185.42.camel@revolution.hippie.lan> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Aleksandr Rybalko , Bernd Walter , freebsd-arm@FreeBSD.org, freebsd-mips@FreeBSD.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 22:48:47 -0000 On Thu, 21 Feb 2013 16:17:55 -0700 Ian Lepore wrote: > On Fri, 2013-02-22 at 00:59 +0200, Aleksandr Rybalko wrote: > > On Thu, 21 Feb 2013 15:39:45 -0700 > > Ian Lepore wrote: > > > > > On Fri, 2013-02-22 at 00:02 +0200, Aleksandr Rybalko wrote: > > > > On Thu, 21 Feb 2013 17:30:03 +0100 > > > > Bernd Walter wrote: > > > > > > > > > On Thu, Feb 21, 2013 at 10:21:00AM -0500, Patrick Kelsey > > > > > wrote: > > > > > > >On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko > > > > > > > wrote: > > > > > > >> On Thu, 21 Feb 2013 02:44:33 +0100 > > > > > > >> Bernd Walter wrote: > > > > > > >> > > > > > > >> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr > > > > > > >> Rybalko wrote: > > > > > > >> > 2. teach consumers to give only correct numbers (very > > > > > > >> > nice we have only two SPI devices in tree) > > > > > > >> > > > > > > > >> > After that we will be able to make drivers for some > > > > > > >> > (potential) devices which will require bidirectional > > > > > > >> > communication. And controllers which can't do that, > > > > > > >> > will just report error in that. I believe peoples > > > > > > >> > thinks before attach such devices to controllers, so > > > > > > >> > we will not have such incompatibility. > > > > > > >> > > > > > > >> I don't think there are many devices requiring RX/TX at > > > > > > >> the same time. > > > > > > > > > > > > > > Anyway, we will be able to do that, and we don't care now > > > > > > > because don't have such drivers yet. > > > > > > > > > > > > > > > > > > > Taking the view that "RX/TX at the same time" means that one > > > > > > wants to send meaningful data to the slave device at the > > > > > > same time one is interested in what data is returned during > > > > > > that transmission, there are such devices in use out > > > > > > there. Linear Technologies has several ADCs, such as the > > > > > > LTC2446, for which you obtain the previous conversion > > > > > > result while sending the configuration bits for the next > > > > > > conversion to be performed. > > > > > > > > > > Forgot about ADC with channel selection. > > > > > > > > > > > Although this is slightly out of focus for the specific > > > > > > issue originally raised, while on the topic of things that > > > > > > need to get done on SPI in real systems, there are also > > > > > > devices out there that require specific data or some number > > > > > > of clocks to be provided while chip select is deasserted. > > > > > > One example of the former is the LTC2404, which is a > > > > > > multichannel ADC for which the input channel for the next > > > > > > conversion is selected by the last four bits clocked in > > > > > > *before* chip select is asserted. One example of the latter > > > > > > is the spec for SPI access to MMC/SD cards, which requires > > > > > > a certain number of clocks to be applied with chip select > > > > > > deasserted in order to initialize the card. If you ever > > > > > > find yourself wondering why an SPI software interface > > > > > > provides independent bus acquisition and chip select > > > > > > control, the reason is to support these types of devices. > > > > > > > > > > With many ADC you also want probing support. > > > > > Assign CS and GPIO-read MISO for ready without clocking. > > > > > Some flash chips also work this way. > > > > > Not sure if AT45DB support this and how our driver works. > > > > > With own projects I usually ask AT45DB about ready state by > > > > > transfering a status word. > > > > > > > > > > -- > > > > > B.Walter http://www.bwct.de > > > > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD > > > > > Rechner uvm. > > > > > > > > Guys, I don't said it will not be supported. :) > > > > I said drivers of controllers who can't will return error in > > > > that case, but other might be ok. > > > > > > > > So, conclusion: go-go-go ray! do it please! > > > > :-D > > > > > > > > > > One other little thought to consider... since tx and rx size must > > > be the same if they're both non-zero, then could we change to > > > having a single io_size field, and pass a NULL pointer for rx or > > > tx buffer if that part of the transfer isn't needed? > > > > > > -- Ian > > > > > > > > > > Yeah, very-very good idea! That how my uncommited driver for i.MX515 > > SPI works :) > > > > Objections? > > > > WBW > > So just to be clear... if a device driver passes a NULL tx pointer to > the controller driver, it's saying "My device doesn't care what it > receives during this transfer." If the device needs zeroes or ones > then the buffer full of them has to be provided, right? > > I'm thinking for the controller that does dma, this simplifies things > down to making a bus_dmamem_alloc() call (which is fast these days > because of the zone allocator) and it doesn't bother to set the > contents of that buffer to anything before starting the dma. > > -- Ian > > Hi hackers! Instead of implementation, new thoughts is coming :) Well, after few days of stabilization of ideas I'm beginning new round of talks. :) So, two days ago we had discussion with Ian on IRC. Things we decide: 1. Don't remove current transfer method 2. Add acquire/release methods 3. Add cs control methods 4. Add new transfer method, it will do only one xfer, and as described previously will have only size/txbuf/rxbuf fields in transfer struct. Tx and/or rx can be NULL, so even clocking without data possible. 5. Update old transfer method(spibus_transfer) to do: * acquire * enable cs * transfer cmd * transfer data * disable cs * release bus 6. Add some method which will expose hw ability (one direction at a time, independent cs control, etc.) 7. Maybe some other special methods (Ian said for SD on spi we need ability to xfer w/o CS asserted) That how I see new xfer structure: struct spi_xfer { size_t size; /* Transfer size (bytes) */ void *tx_buf; /* Buffer with TX data (NULL to not tx) */ void *rx_buf; /* Buffer for RX data (NULL for ignore) */ }; Simple and clear :) WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 23:36:02 2013 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DA66BE15; Thu, 28 Feb 2013 23:36:02 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 873AA95B; Thu, 28 Feb 2013 23:36:02 +0000 (UTC) Received: from rnote.ddteam.net (12-60-135-95.pool.ukrtel.net [95.135.60.12]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 35EB5C4930; Fri, 1 Mar 2013 01:36:01 +0200 (EET) Date: Fri, 1 Mar 2013 01:35:45 +0200 From: Aleksandr Rybalko To: arm@FreeBSD.org, mips@freebsd.org, ppc@freebsd.org Subject: [CFT + RFC] FDT resource management (patch) Message-Id: <20130301013545.3d438d8e.ray@freebsd.org> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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 Feb 2013 23:36:02 -0000 Hi, at first sorry for cross post, but IIRC we have no FDT list yet and I don't want to break even single ppc/MPC85XX. Now we have: fdtbus get physical address from the blob, map address (panic on SPI CS "address" :) ) to virtual and return it as resource to child bus (f.e. simplebus), but all other, not FDT based, ARCHes delegate this work to parent of device who request resource. As result we have virtual addresses in boot log + rman and it's try to map address for not mapable buses. Two month ago I made the patch: http://people.freebsd.org/~ray/2012-12-25_fdt_correct_resource.diff but testing give good results for i.MX515(Efika), BCM2835(RPi), OMAPxxx(Pandaboard), but fail on Beagleboard. Patch is simple, and I was surprised by BB problem, so I have to ask help with testing on everything using fdtbus/simplebus. Please help/test/comment! Many thanks! WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 00:24:57 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CD11787E for ; Fri, 1 Mar 2013 00:24:57 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 374A0AC2 for ; Fri, 1 Mar 2013 00:24:56 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r210OLrn098214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Mar 2013 01:24:21 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id r210NWdu015191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Mar 2013 01:23:32 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id r210NWjU064618; Fri, 1 Mar 2013 01:23:32 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r210NWZw064617; Fri, 1 Mar 2013 01:23:32 +0100 (CET) (envelope-from ticso) Date: Fri, 1 Mar 2013 01:23:31 +0100 From: Bernd Walter To: Oleksandr Tymoshenko Subject: Re: FreeBSD on Zedboard (Xilinx Zynq-7000) SD card image Message-ID: <20130301002331.GA64366@cicely7.cicely.de> References: <512EA0A8.5040103@sbcglobal.net> <41A62BB3-10E3-4BC4-A4A2-82DD04072386@bluezbox.com> <512F73B7.50404@sbcglobal.net> <512FDA12.50900@bluezbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <512FDA12.50900@bluezbox.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@freebsd.org, Thomas Skibo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 00:24:57 -0000 On Thu, Feb 28, 2013 at 02:28:34PM -0800, Oleksandr Tymoshenko wrote: > On 2/28/2013 7:11 AM, Thomas Skibo wrote: > > > >I don't have anything specific in mind but I hope I can wind down > >kernel hacking and do some FPGA hacking. I've developed a device > >config driver so you can reprogram the PL (FPGA) section with "cat > >system.bit.bin > /dev/devcfg0". > > Yeah, that's what I meant by "interfacing" - ability to > upload bitstream to FPGA directly from FreeBSD. Although > I think ioctl interface seems more fool-proof than simple raw access > to device. Amazing. I have a zedboard since a couple of weeks, but didn't find time to boot FreeBSD yet. Great to see that it is save to reload the FPGA from OS and no PL is required for basic functionality. > >On 2/27/13 10:02 PM, Oleksandr Tymoshenko wrote: > >> > >>Awesome! Thanks, Thomas. > >>Do you have any plans to work on interfacing FPGA part of the board > >>with FreeBSD? > >> > >> > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 00:35:09 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 57F2C9BC for ; Fri, 1 Mar 2013 00:35:09 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id D37E8AF6 for ; Fri, 1 Mar 2013 00:35:08 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UBDwH-000EWj-J6; Thu, 28 Feb 2013 16:35:07 -0800 Message-ID: <512FF7B9.4070700@bluezbox.com> Date: Thu, 28 Feb 2013 16:35:05 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: XiaoQI Ge Subject: Re: I u-boot fails to compile References: <512FD685.8070009@bluezbox.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2/28/2013 4:28 PM, XiaoQI Ge wrote: > I compiled the file size of 22, 016 Byte / occupied space of 24, 576 > Byte is rather http://people.freebsd.org/ ~~ ganbold / cubieboard / > sunxi-spl.bin size and space are 20,480 Byte is not where Iwrong ah? > > These files produced the SD card can not start > === > dd if = / dev / zero of = a10.img bs = 1m count = 1 > dd if = sunxi-spl.bin conv = notrunc of = a10.img bs = 1024 seek = 8 > dd if = u-boot.bin conv = notrunc of = a10.img bs = 1024 seek = 32 > dd if = a10.img of = $ {DEVNAME} bs = 1m > === [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 00:35:09 -0000 On 2/28/2013 4:28 PM, XiaoQI Ge wrote: > I compiled the file size of 22,016 Byte / occupied space of 24,576 > Byte is rather http://people.freebsd.org/ ~~ ganbold / cubieboard / > sunxi-spl.bin size and space are 20,480 Byte is not where Iwrong ah? > > These files produced the SD card can not start > === > dd if = / dev / zero of = a10.img bs = 1m count = 1 > dd if = sunxi-spl.bin conv = notrunc of = a10.img bs = 1024 seek = 8 > dd if = u-boot.bin conv = notrunc of = a10.img bs = 1024 seek = 32 > dd if = a10.img of = $ {DEVNAME} bs = 1m > === Which commands did you use to compile u-boot? What's printed on serial console when you're trying to boot device? From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 00:36:56 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 80F61A0E for ; Fri, 1 Mar 2013 00:36:56 +0000 (UTC) (envelope-from ghw@7axu.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id 07E38B0A for ; Fri, 1 Mar 2013 00:36:55 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so2004095wgh.7 for ; Thu, 28 Feb 2013 16:36:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=+CfmP03DnkC6xan8aCvmBKjt9rN9iLxPP4WH4uHEeQ8=; b=HIdxgrdcvJh/HgSId9K98/KnucsK987ap74n0Ry0pivUsx7aEkUCJDWcx7tWJuZdKc bSG8lC2ZBFzuQ4gscWqrvBmKXUuckuo4wIO+Psz2sb/uVHbT14/LQy1HAvdGF3sJm6xG TtQ0I3CpjGoro5WCEjNT6fzNzdVqHQG1eyigTLcLEuB8tqEqKhJOESnCNMyYwnd5BUeF hk5EkB0ZLyVzf7X6IWf8z27Q1evdM4Ik46N1liNbr/taBkMNXFaRNBfJv07PnkkJzSg+ iO079wVxArE1asRxOaEtbrWseHH8k+xf8qV/1ORQz17mbGQmX9OYjDDS5sN/uhGmslVi R7sA== X-Received: by 10.194.173.167 with SMTP id bl7mr14335735wjc.50.1362097751837; Thu, 28 Feb 2013 16:29:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.0.67 with HTTP; Thu, 28 Feb 2013 16:28:31 -0800 (PST) X-Originating-IP: [74.63.212.29] In-Reply-To: <512FD685.8070009@bluezbox.com> References: <512FD685.8070009@bluezbox.com> From: XiaoQI Ge Date: Fri, 1 Mar 2013 08:28:31 +0800 Message-ID: Subject: Re: I u-boot fails to compile To: Oleksandr Tymoshenko X-Gm-Message-State: ALoCoQlX9rV7DMhqJyiMKex0to1ohHqmCU4YZfiRvyrbpjC4d4zJcZk8KD1eWYug3OCfiy3h6y47 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 00:36:56 -0000 I compiled the file size of 22,016 Byte / occupied space of 24,576 Byte is rather http://people.freebsd.org/ ~~ ganbold / cubieboard / sunxi-spl.bin size and space are 20,480 Byte is not where Iwrong ah? These files produced the SD card can not start === dd if = / dev / zero of = a10.img bs = 1m count = 1 dd if = sunxi-spl.bin conv = notrunc of = a10.img bs = 1024 seek = 8 dd if = u-boot.bin conv = notrunc of = a10.img bs = 1024 seek = 32 dd if = a10.img of = $ {DEVNAME} bs = 1m === === Welcome to Ge, XiaoQI's Homepage! Gtalk/E-Mail :ghw@7axu.com 2013/3/1 Oleksandr Tymoshenko > On 2/28/2013 4:07 AM, XiaoQI Ge wrote: > >> I tried to compile U-BOOT (https://github.com/linux-**sunxi/u-boot-sunxi >> ), >> but failed, suggesting: >> >> gmake [1]: *** [u-boot] Segmentation fault: 11 >> >> I do not know how to solve. >> >> > In addition to Tim's patches for libc and static you'll also need to use > gsed instead of > sed with later versions of u-boot repo. > Install textproc/gsed and rename sed to gsed in helper.mk. > I have patch for using user-defined sed name but haven't pushed it to > upstream yet. > From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 00:37:13 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B7726A5B for ; Fri, 1 Mar 2013 00:37:13 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 6C466B0C for ; Fri, 1 Mar 2013 00:37:13 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UBDyJ-000EXW-02; Thu, 28 Feb 2013 16:37:12 -0800 Message-ID: <512FF836.2080007@bluezbox.com> Date: Thu, 28 Feb 2013 16:37:10 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: ticso@cicely.de Subject: Re: FreeBSD on Zedboard (Xilinx Zynq-7000) SD card image References: <512EA0A8.5040103@sbcglobal.net> <41A62BB3-10E3-4BC4-A4A2-82DD04072386@bluezbox.com> <512F73B7.50404@sbcglobal.net> <512FDA12.50900@bluezbox.com> <20130301002331.GA64366@cicely7.cicely.de> In-Reply-To: <20130301002331.GA64366@cicely7.cicely.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2/28/2013 4:23 PM, Bernd Walter wrote: > On Thu, Feb 28, 2013 at 02:28:34PM -0800, Oleksandr Tymoshenko wrote: >> On 2/28/2013 7:11 AM, Thomas Skibo wrote: >>> I don't have anything specific in mind but I hope I can wind down >>> kernel hacking and do some FPGA hacking. I've developed a device >>> config driver so you can reprogram the PL (FPGA) section with "cat >>> system.bit.bin > /dev/devcfg0". >> Yeah, that's what I meant by "interfacing" - ability to >> upload bitstream to FPGA directly from FreeBSD. Although >> I think ioctl interface seems more fool-proof than simple raw access >> to device. > Amazing. > I have a zedboard since a couple of weeks, but didn't find time to > boot FreeBSD yet. > Great to see that it is save to reload the FPGA from OS and no PL is > required for basic functionality. > [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 00:37:13 -0000 On 2/28/2013 4:23 PM, Bernd Walter wrote: > On Thu, Feb 28, 2013 at 02:28:34PM -0800, Oleksandr Tymoshenko wrote: >> On 2/28/2013 7:11 AM, Thomas Skibo wrote: >>> I don't have anything specific in mind but I hope I can wind down >>> kernel hacking and do some FPGA hacking. I've developed a device >>> config driver so you can reprogram the PL (FPGA) section with "cat >>> system.bit.bin > /dev/devcfg0". >> Yeah, that's what I meant by "interfacing" - ability to >> upload bitstream to FPGA directly from FreeBSD. Although >> I think ioctl interface seems more fool-proof than simple raw access >> to device. > Amazing. > I have a zedboard since a couple of weeks, but didn't find time to > boot FreeBSD yet. > Great to see that it is save to reload the FPGA from OS and no PL is > required for basic functionality. > Any suggestions where to get one? Do you know if AVNET the only non-academic source for them? From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 00:42:02 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 710BDAF1; Fri, 1 Mar 2013 00:42:02 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id D9179B2F; Fri, 1 Mar 2013 00:42:01 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r210g0X0098406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Mar 2013 01:42:00 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id r210fwfa015472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Mar 2013 01:41:58 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id r210fvW8064691; Fri, 1 Mar 2013 01:41:57 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r210fvBa064690; Fri, 1 Mar 2013 01:41:57 +0100 (CET) (envelope-from ticso) Date: Fri, 1 Mar 2013 01:41:57 +0100 From: Bernd Walter To: Ian Lepore Subject: Re: PHYSADDR Message-ID: <20130301004157.GB64366@cicely7.cicely.de> References: <1362068453.1195.40.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1362068453.1195.40.camel@revolution.hippie.lan> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 00:42:02 -0000 On Thu, Feb 28, 2013 at 09:20:53AM -0700, Ian Lepore wrote: > > The trampoline is relatively horrible for performance as well, it > decompresses the kernel to one place, then copies it to another. I'm > curious whether anyone uses it at all, except us at Symmetricom? I'm > not even sure there's any advantage to us using it. I suspect it was at > one time better for performance to load a smaller image from sdcard > (because that's slow) and take the hit on the decompress time. Recently > I enabled the MMU and caches in our low-level bootloader, and I have a > feeling that plus other changes to the boot sd code may mean it's faster > to load an uncompressed kernel now. I need to do some testing. I think it is from early days when the kernel was loaded from space limited SPI flash before Warner did the SD support. I have a 2MB SPI flash on my RM9200 board (Warner did with larger, but also had placed something else inside) Without compression it wouldn't have fit: [54]beaver.cicely.de# ls -al /boot/kernel* /boot/kernel: total 5044 drwxr-xr-x 2 root wheel 512 Nov 22 2009 . drwxr-xr-x 8 root wheel 512 Nov 22 2009 .. -r-xr-xr-x 1 root wheel 3661569 Nov 22 2009 kernel -r-xr-xr-x 1 root wheel 1453672 Nov 22 2009 kernel.gz.tramp Not sure about actual kernel size, but I don't expect them to be any smaller. Btw. In case anyone have doubts that FreeBSD-arm can be running solid: [55]beaver.cicely.de# uptime 1:32AM up 797 days, 4:42, 1 user, load averages: 0.02, 0.03, 0.00 [56]beaver.cicely.de# uname -a FreeBSD beaver.cicely.de 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Nov 22 07:52:33 CET 2009 ticso@beaver.cicely.de:/mnt2/arm-2009-04-17/head/sys/arm/compile/BEAVER arm The system is running my home automation. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 00:46:49 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1B836E01 for ; Fri, 1 Mar 2013 00:46:49 +0000 (UTC) (envelope-from ghw@7axu.com) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by mx1.freebsd.org (Postfix) with ESMTP id B02CBBED for ; Fri, 1 Mar 2013 00:46:48 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id fg15so1927413wgb.25 for ; Thu, 28 Feb 2013 16:46:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=WdM6FVh3Z/jy2Hjf0wP/LvooL6g5aXo3sSOolEB8+R8=; b=QGzapgRMJVWK7rYM8pHZMakaGPfgGwIUfjubuMm5RqUn+wLi62xnpM3nIGL/AMKrca IuejyJRC5l03u1O4zybKqp7xo3ZpgEjW3oupL7d7qJQLx/j0J83O97K8eiTdfIt9Hgoz 4rI47XYvArk5mCugcMQ001bZNvbAKjphTquENR0nWs+srcjWL/B23rZXoEzWGZZSkNBq 7fIUfTr0NbUP/yKYLBDa8gSvaXKQ4W9V5g6UcFVbtsUJaWoNUbPCXO8cE+rd2k3BL9g+ eS+21OKxQzarn234LI17tNThA76BqIRgxq7KuhXtKyWIUAxL0+b6Fscz6aJqAgjlX7Cv 1u3A== X-Received: by 10.194.120.169 with SMTP id ld9mr14373870wjb.24.1362098801368; Thu, 28 Feb 2013 16:46:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.0.67 with HTTP; Thu, 28 Feb 2013 16:46:01 -0800 (PST) X-Originating-IP: [74.63.212.29] In-Reply-To: <512FF7B9.4070700@bluezbox.com> References: <512FD685.8070009@bluezbox.com> <512FF7B9.4070700@bluezbox.com> From: XiaoQI Ge Date: Fri, 1 Mar 2013 08:46:01 +0800 Message-ID: Subject: Re: I u-boot fails to compile To: Oleksandr Tymoshenko X-Gm-Message-State: ALoCoQk04AEcePXP+zjFr/XCW9BLTZwBMHP1bZKn9vf1eikQi+ynpJ1SN3EisCjbZ1hs3R9uiRKJ Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 00:46:49 -0000 === Command: sh gmake cubieboard SED=sed CROSS_COMPILE=arm-freebsd- === serial console echo Skip SD equipment Boot from NAND === Welcome to Ge, XiaoQI's Homepage! Gtalk/E-Mail :ghw@7axu.com 2013/3/1 Oleksandr Tymoshenko > On 2/28/2013 4:28 PM, XiaoQI Ge wrote: > >> I compiled the file size of 22,016 Byte / occupied space of 24,576 Byte >> is rather http://people.freebsd.org/ ~~ ganbold / cubieboard / >> sunxi-spl.bin size and space are 20,480 Byte is not where Iwrong ah? >> >> These files produced the SD card can not start >> === >> dd if = / dev / zero of = a10.img bs = 1m count = 1 >> dd if = sunxi-spl.bin conv = notrunc of = a10.img bs = 1024 seek = 8 >> dd if = u-boot.bin conv = notrunc of = a10.img bs = 1024 seek = 32 >> dd if = a10.img of = $ {DEVNAME} bs = 1m >> === >> > > Which commands did you use to compile u-boot? > What's printed on serial console when you're trying to boot device? > > > From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 00:58:46 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D2964848 for ; Fri, 1 Mar 2013 00:58:46 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 82C85CF5 for ; Fri, 1 Mar 2013 00:58:46 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UBEJ8-000EoG-KE; Thu, 28 Feb 2013 16:58:44 -0800 Message-ID: <512FFD42.4090304@bluezbox.com> Date: Thu, 28 Feb 2013 16:58:42 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: XiaoQI Ge Subject: Re: I u-boot fails to compile References: <512FD685.8070009@bluezbox.com> <512FF7B9.4070700@bluezbox.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2/28/2013 4:46 PM, XiaoQI Ge wrote: > === > Command: > sh > gmake cubieboard SED=sed CROSS_COMPILE=arm-freebsd- > === > serial console echo > > Skip SD equipment > Boot from NAND Looks like problem with toolchain, I'll try to reproduce it and see how it goes. Last question: how did you connect SD card to FreeBSD host system. AFAIR I had more success using USB reader for dd'ing u-boot than when I used SD card slot (seen as an mmcsd device) on laptop. Haven't looked further though - device was quirky in general so I just wrote the stuff off to its quirkiness. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 00:58:46 -0000 On 2/28/2013 4:46 PM, XiaoQI Ge wrote: > === > Command: > sh > gmake cubieboard SED=sed CROSS_COMPILE=arm-freebsd- > === > serial console echo > > Skip SD equipment > Boot from NAND Looks like problem with toolchain, I'll try to reproduce it and see how it goes. Last question: how did you connect SD card to FreeBSD host system. AFAIR I had more success using USB reader for dd'ing u-boot than when I used SD card slot (seen as an mmcsd device) on laptop. Haven't looked further though - device was quirky in general so I just wrote the stuff off to its quirkiness. FWIW, if you're not adding specific options to the build you might want to use pre-built binaries for time being and modify boot.scr/uEnv.txt to your needs: http://people.freebsd.org/~gonzo/arm/hackberry/ > > === > Welcome to Ge, XiaoQI's Homepage! > Gtalk/E-Mail :ghw@7axu.com > > > > 2013/3/1 Oleksandr Tymoshenko > > > On 2/28/2013 4:28 PM, XiaoQI Ge wrote: > > I compiled the file size of 22,016 Byte / occupied space of > 24,576 Byte is rather http://people.freebsd.org/ ~~ ganbold / > cubieboard / sunxi-spl.bin size and space are 20,480 Byte is > not where Iwrong ah? > > These files produced the SD card can not start > === > dd if = / dev / zero of = a10.img bs = 1m count = 1 > dd if = sunxi-spl.bin conv = notrunc of = a10.img bs = 1024 > seek = 8 > dd if = u-boot.bin conv = notrunc of = a10.img bs = 1024 seek = 32 > dd if = a10.img of = $ {DEVNAME} bs = 1m > === > > > Which commands did you use to compile u-boot? > What's printed on serial console when you're trying to boot device? > > > From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 01:00:32 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AC35CAD0 for ; Fri, 1 Mar 2013 01:00:32 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 3FFB0D27 for ; Fri, 1 Mar 2013 01:00:31 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r2110SoV098663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Mar 2013 02:00:29 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id r2110QMb015738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Mar 2013 02:00:26 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id r2110Qok064806; Fri, 1 Mar 2013 02:00:26 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r2110Qgt064805; Fri, 1 Mar 2013 02:00:26 +0100 (CET) (envelope-from ticso) Date: Fri, 1 Mar 2013 02:00:26 +0100 From: Bernd Walter To: Oleksandr Tymoshenko Subject: Re: FreeBSD on Zedboard (Xilinx Zynq-7000) SD card image Message-ID: <20130301010026.GC64366@cicely7.cicely.de> References: <512EA0A8.5040103@sbcglobal.net> <41A62BB3-10E3-4BC4-A4A2-82DD04072386@bluezbox.com> <512F73B7.50404@sbcglobal.net> <512FDA12.50900@bluezbox.com> <20130301002331.GA64366@cicely7.cicely.de> <512FF836.2080007@bluezbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <512FF836.2080007@bluezbox.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@freebsd.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 01:00:32 -0000 On Thu, Feb 28, 2013 at 04:37:10PM -0800, Oleksandr Tymoshenko wrote: > On 2/28/2013 4:23 PM, Bernd Walter wrote: > >On Thu, Feb 28, 2013 at 02:28:34PM -0800, Oleksandr Tymoshenko wrote: > >>On 2/28/2013 7:11 AM, Thomas Skibo wrote: > >>>I don't have anything specific in mind but I hope I can wind down > >>>kernel hacking and do some FPGA hacking. I've developed a device > >>>config driver so you can reprogram the PL (FPGA) section with "cat > >>>system.bit.bin > /dev/devcfg0". > >>Yeah, that's what I meant by "interfacing" - ability to > >>upload bitstream to FPGA directly from FreeBSD. Although > >>I think ioctl interface seems more fool-proof than simple raw access > >>to device. > >Amazing. > >I have a zedboard since a couple of weeks, but didn't find time to > >boot FreeBSD yet. > >Great to see that it is save to reload the FPGA from OS and no PL is > >required for basic functionality. > > > > Any suggestions where to get one? Do you know if AVNET the only > non-academic > source for them? So far I didn't find any other source. There is a german supplier (Trenz Electronic), which have a good bunch of Digilent boards and add ons, but they only have the academic in their webshop. Maybe they sell it on request, got mine directly from AVNET USA. European AVNET asked about twice the price. But Trenz is also about to sell their own Zynq-7020 based board, which looks like a promissing design. And I participated at kickstarter project for the parallella board, which I maybe get sometime this year - they use the PL to connect to their own developed multicore (16 and 64-core with 1024 planned) chip. So far they have shipped some devkits with zedboard and FMC card containing their multicore chip to high price backers. Wonder how the final prices for the Trenz and the parallella boards will be - the kickstarter price for a parallella board was 99 USD. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 01:10:23 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0259117D; Fri, 1 Mar 2013 01:10:22 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id C08F4D76; Fri, 1 Mar 2013 01:10:22 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UBEUK-00008Z-JI; Fri, 01 Mar 2013 01:10:16 +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 r211ADP6086025; Thu, 28 Feb 2013 18:10:13 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/O0IxqJuhMQq3dMVVfbw3J Subject: Re: PHYSADDR From: Ian Lepore To: Tim Kientzle In-Reply-To: <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> Content-Type: text/plain; charset="windows-1251" Date: Thu, 28 Feb 2013 18:10:13 -0700 Message-ID: <1362100213.1195.88.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id r211ADP6086025 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 01:10:23 -0000 On Thu, 2013-02-28 at 08:58 -0800, Tim Kientzle wrote: > On Feb 28, 2013, at 8:20 AM, Ian Lepore wrote: >=20 > > On Wed, 2013-02-27 at 22:27 -0800, Tim Kientzle wrote: > >> Starting to look at what is needed for a Generic ARM kernel. > >> There's a lot here; I sincerely hope I'm not the only one=85 ;-) > >>=20 > >> First up: Can we get rid of PHYSADDR? > >>=20 > >=20 > > If you mean, can we get rid of it within the runtime kernel, I'd say > > yes, because we can use a global variable instead which is easily > > settable in the entry code. >=20 > It doesn't seem to be used in the runtime kernel. As far as > I can see, it's purely a bootstrap concept. >=20 > > On the other hand, I've been working > > towards getting that value set correctly in the kernel elf headers at > > link time. >=20 > My question really boils down to whether PIC techniques > are sufficient for the early bootstrap stage to determine > where the kernel is currently executing and use that to > drive the initial MMU bring up. I've just started, but > the PHYSADDR uses I've examined can be replaced > with PIC techniques. But this part of the code is > pretty involved and riddled with conditional compilations, > so it will be slow going. >=20 > I was impressed to find that ubldr seems to be PIC. > I've run the same binary at different load addresses > and so far it "just works." (I didn't think it would work, > so I was surprised by this. I haven't dug through to > figure out why it works yet.) >=20 I was suprised by this paragraph, and I've just done some testing and I wonder if it's really running at different addresses, because I can't make it do so without relinking it at that address. To test, I saved the entry PC in uboot/start.S and printed it in main (patch below). No matter where I tell u-boot to load ubldr, it seems to ignore the command line and honor the elf headers: TFTP from server 172.22.42.240; our IP address is 172.22.42.233 Filename '/rpi/boot/ubldr'. Load address: 0x200000 Loading: ############## done Bytes transferred =3D 199412 (30af4 hex) U-Boot> bootelf ## Starting application at 0x01000054 ... Consoles: U-Boot console =20 Compatible API signature found @17b662a8; entry_phys 1000064 =20 TFTP from server 172.22.42.240; our IP address is 172.22.42.233 Filename '/rpi/boot/ubldr'. Load address: 0x900900 Loading: ############## done Bytes transferred =3D 199412 (30af4 hex) U-Boot> bootelf ## Starting application at 0x01000054 ... Consoles: U-Boot console =20 Compatible API signature found @17b662a8; entry_phys 1000064 So I just learned that the load address printed by dhcp / tftp loading is in fact where the bits get copied to initially. The bootelf command must read the elf headers and copy the bits to the location in the headers. We know the entry point is at offset 0x54. If I load to 200000 and do "go 200054" it fails to run, because it's not linked to run at that address. If I first do "cp 200000 1000000 30af4" then "go 1000054" ubldr launches and runs. It also works to load directly to 1000000 and then "go 1000054'. -- Ian Index: arm/uboot/start.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- arm/uboot/start.S (revision 247421) +++ arm/uboot/start.S (working copy) @@ -37,6 +37,7 @@ _start: /* Hint where to look for the API signature */ ldr ip, =3Duboot_address str sp, [ip] + str pc, [ip, #4] =20 /* Save U-Boot's r8 */ ldr ip, =3Dsaved_regs @@ -80,6 +81,9 @@ syscall_ptr: uboot_address: .long 0 =20 + .globl entry_phys +entry_phys: + .long 0 saved_regs: .long 0 /* U-Boot's r8 */ .long 0 /* Loader's r8 */ Index: uboot/common/main.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- uboot/common/main.c (revision 247421) +++ uboot/common/main.c (working copy) @@ -116,6 +116,7 @@ meminfo(void) } } =20 +extern uint32_t entry_phys; int main(void) { @@ -142,7 +143,8 @@ main(void) */ cons_probe(); =20 - printf("Compatible API signature found @%x\n", (uint32_t)sig); + printf("Compatible API signature found @%x; entry_phys %x\n",=20 + (uint32_t)sig, entry_phys); =20 dump_sig(sig); dump_addr_info(); From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 01:24:16 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6E899289 for ; Fri, 1 Mar 2013 01:24:16 +0000 (UTC) (envelope-from ghw@7axu.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 0CEF5DCF for ; Fri, 1 Mar 2013 01:24:15 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id k14so2013022wer.25 for ; Thu, 28 Feb 2013 17:24:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=Hw0nqFnQyqjOKvfx+VFE79u48p18yhOFCgNeMaiecqU=; b=ouKLs4mkQYlsptjKVWyk0Q++OR0zyZOEfJuk+osobVQc/QLrBKKIGapHoVvJAA9Hl0 ikM3gEhwRaVyJODVgYagea5BE3NTq1i94ZZVdq9PK+pjc3pDWzI8s6KqdXgNGwh3Ofnv abhvRdUSZft48Zpr4qV1kfHkeMpNZDvPlcwqiSsew+fPrPtvwUcbs0y3MvUhuxZmY3xV hN8ZqE7KgJZoQGXAh1bOzTiKE2WyWrRDiUgGy95fOvNDgPFSzFNDawGMRtKACL5WHg+m 0SPLyoh+II8p3RpLLtizqvypdaAyxTNy0g8k8dxTZsd6RQ5WutGQYMCyPFjNNkd+I7sN ue/A== X-Received: by 10.180.14.233 with SMTP id s9mr935557wic.25.1362101053592; Thu, 28 Feb 2013 17:24:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.0.67 with HTTP; Thu, 28 Feb 2013 17:23:33 -0800 (PST) X-Originating-IP: [74.63.212.29] In-Reply-To: <512FFD42.4090304@bluezbox.com> References: <512FD685.8070009@bluezbox.com> <512FF7B9.4070700@bluezbox.com> <512FFD42.4090304@bluezbox.com> From: XiaoQI Ge Date: Fri, 1 Mar 2013 09:23:33 +0800 Message-ID: Subject: Re: I u-boot fails to compile To: Oleksandr Tymoshenko X-Gm-Message-State: ALoCoQlc2AkRJh30vr6b9I/FXv1sXw7tBkqp0JirG50agsqR8zszl6k8NnUjmWdZswE4m+Zwu2nA Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 01:24:16 -0000 sunxi-spl.bin u-boot.bin from http://people.freebsd.org/ ~ gonzo / arm / hackberry / Can not start from my own compiled u-boot 1, I is the kernel of the SD card fatload mmc 0 0x40200000 kernel go 0x40200000 So start (SD Carry only the kernel to a file) 2, outside a USB storage disk Inside it (da0s2, ufs, freebsd_base) === dmesg === https://www.7axu.com/dmesg.log.txt === Welcome to Ge, XiaoQI's Homepage! Gtalk/E-Mail :ghw@7axu.com 2013/3/1 Oleksandr Tymoshenko > On 2/28/2013 4:46 PM, XiaoQI Ge wrote: > >> === >> Command: >> sh >> gmake cubieboard SED=sed CROSS_COMPILE=arm-freebsd- >> === >> serial console echo >> >> Skip SD equipment >> Boot from NAND >> > > Looks like problem with toolchain, I'll try to reproduce it and see how it > goes. > Last question: how did you connect SD card to FreeBSD host system. AFAIR > I had more success using USB reader for dd'ing u-boot than when I used > SD card slot (seen as an mmcsd device) on laptop. Haven't looked further > though - device was quirky in general so I just wrote the stuff off to its > quirkiness. > > FWIW, if you're not adding specific options to the build you might want to > use pre-built binaries for time being and modify boot.scr/uEnv.txt to > your needs: > > http://people.freebsd.org/~**gonzo/arm/hackberry/ > > > >> === >> Welcome to Ge, XiaoQI's Homepage! >> Gtalk/E-Mail :ghw@**7axu.com > ghw@7axu.com> >> >> >> >> 2013/3/1 Oleksandr Tymoshenko > gonzo@bluezbox.com>> >> >> >> On 2/28/2013 4:28 PM, XiaoQI Ge wrote: >> >> I compiled the file size of 22,016 Byte / occupied space of >> 24,576 Byte is rather http://people.freebsd.org/ ~~ ganbold / >> cubieboard / sunxi-spl.bin size and space are 20,480 Byte is >> not where Iwrong ah? >> >> These files produced the SD card can not start >> === >> dd if = / dev / zero of = a10.img bs = 1m count = 1 >> dd if = sunxi-spl.bin conv = notrunc of = a10.img bs = 1024 >> seek = 8 >> dd if = u-boot.bin conv = notrunc of = a10.img bs = 1024 seek = 32 >> dd if = a10.img of = $ {DEVNAME} bs = 1m >> === >> >> >> Which commands did you use to compile u-boot? >> What's printed on serial console when you're trying to boot device? >> >> >> >> > From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 01:28:05 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5DF192EC for ; Fri, 1 Mar 2013 01:28:05 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 2CB0CDEB for ; Fri, 1 Mar 2013 01:28:05 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id c11so2958827ieb.1 for ; Thu, 28 Feb 2013 17:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dLV6ygqzU+UnZYHqsEFEveS8EyLpTec2SMEwuIRPxuw=; b=qCcKbSeFrAYl020Zhf4zgOMFCz7uNjyPSphMeV4rhnLl7L0IeWVJ0i9XM+dNxYEX/z tM7wutf9mqyI2kUhfNBF4bBAtL58UU0lrlhtB9wGy1whLRVGTimLUtoJ9pf7MJLPYOYH iAc6OJ1LH0Guv/BL2yc5ObLCE5Q4pfkMCcb7qiagrnsZeqtsKj9R7ScSeKqUI7kb7W1Q L7iBVYYHXxq36nD1QAHdCGN/O/QE0uF0N7ZVmbJpxXzEt5zFLtpPU9tv5iItNRnKUjRl caDIfqpfBoE88l9uiVJ1kYDfJzjGyrkD/a+4tGs1C13J4I7Ijrux78mxu2vnMFS01Lvo GCsA== MIME-Version: 1.0 X-Received: by 10.50.47.168 with SMTP id e8mr5510127ign.50.1362101284891; Thu, 28 Feb 2013 17:28:04 -0800 (PST) Received: by 10.64.6.230 with HTTP; Thu, 28 Feb 2013 17:28:04 -0800 (PST) In-Reply-To: References: <512FD685.8070009@bluezbox.com> Date: Fri, 1 Mar 2013 09:28:04 +0800 Message-ID: Subject: Re: I u-boot fails to compile From: Ganbold Tsagaankhuu To: XiaoQI Ge Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 01:28:05 -0000 On Fri, Mar 1, 2013 at 8:28 AM, XiaoQI Ge wrote: > I compiled the file size of 22,016 Byte / occupied space of 24,576 Byte is > rather http://people.freebsd.org/ ~~ ganbold / cubieboard / sunxi-spl.bin > size and space are 20,480 Byte is not where Iwrong ah? I observed that in my side too, and I just decided to use prebuilt sunxi-spl.bin. Ganbold > > These files produced the SD card can not start > === > dd if = / dev / zero of = a10.img bs = 1m count = 1 > dd if = sunxi-spl.bin conv = notrunc of = a10.img bs = 1024 seek = 8 > dd if = u-boot.bin conv = notrunc of = a10.img bs = 1024 seek = 32 > dd if = a10.img of = $ {DEVNAME} bs = 1m > === > > === > Welcome to Ge, XiaoQI's Homepage! > Gtalk/E-Mail :ghw@7axu.com > > > > 2013/3/1 Oleksandr Tymoshenko > >> On 2/28/2013 4:07 AM, XiaoQI Ge wrote: >> >>> I tried to compile U-BOOT (https://github.com/linux-**sunxi/u-boot-sunxi >>> ), >>> but failed, suggesting: >>> >>> gmake [1]: *** [u-boot] Segmentation fault: 11 >>> >>> I do not know how to solve. >>> >>> >> In addition to Tim's patches for libc and static you'll also need to use >> gsed instead of >> sed with later versions of u-boot repo. >> Install textproc/gsed and rename sed to gsed in helper.mk. >> I have patch for using user-defined sed name but haven't pushed it to >> upstream yet. >> > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 02:08:53 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B75EDC1E for ; Fri, 1 Mar 2013 02:08:53 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 8BD0CF21 for ; Fri, 1 Mar 2013 02:08:53 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id k10so2934707iea.5 for ; Thu, 28 Feb 2013 18:08:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=seKaikhulaKc3t1frvVr+xAnV0ULV21kAjIVN2GBSIs=; b=iELxzA+HclPlpmSwCEjUeRyW0QrpyCtvi6RflHVDAIGbVy7yJE+RG7mF0YmtlCZBWL +CBt7kHaHh7zZT+imtzSBX+Ou1TTRvxFi4d6RHShDl2UVYwIck+d+sqxj8yPRysdMEnk HjqFu3FIxSn51aqqVWxUA6asiWS/cLgPUqf92gL+YLo5S7vM/tOhpvBAMzWHhD2zoLCS THYCc2EPLgUjahqgSpV4GRqYVEeLPkE5c/jDH3R6443ryCn/+dky8d2/PrGhM3o0BefV XzqYrLz6A6bOcv++TiAYSPbrkfnLz/72YhbucB1lJE7oIEvCq5m4riiCf4ymHPMAkQx5 euGg== MIME-Version: 1.0 X-Received: by 10.50.100.201 with SMTP id fa9mr11262185igb.28.1362103732751; Thu, 28 Feb 2013 18:08:52 -0800 (PST) Received: by 10.64.6.230 with HTTP; Thu, 28 Feb 2013 18:08:52 -0800 (PST) In-Reply-To: <312FDF71-E393-41CB-B148-37FF271F6CAA@macdevshanghai.com> References: <201301042002.04400.hselasky@c2i.net> <201301050832.36489.hselasky@c2i.net> <312FDF71-E393-41CB-B148-37FF271F6CAA@macdevshanghai.com> Date: Fri, 1 Mar 2013 10:08:52 +0800 Message-ID: Subject: Re: Allwinner A10 From: Ganbold Tsagaankhuu To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 02:08:53 -0000 Just some update, My latest commit brings basic functionality support of A10 SoC (cubieboard) to HEAD. Now it should be in good shape to start hacking on it. Thanks for all who helped me to get the code bits go in to the tree. best regards, Ganbold From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 06:30:03 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1B9044F9; Fri, 1 Mar 2013 06:30:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id DF2EDA3A; Fri, 1 Mar 2013 06:30:02 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r216U18Q016166; Fri, 1 Mar 2013 06:30:01 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r215TpLv028723; Fri, 1 Mar 2013 05:29:51 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 1 Mar 2013 05:29:51 GMT Message-Id: <201303010529.r215TpLv028723@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 06:30:03 -0000 TB --- 2013-03-01 05:21:46 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-03-01 05:21:46 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-03-01 05:21:46 - starting RELENG_9 tinderbox run for arm/arm TB --- 2013-03-01 05:21:46 - cleaning the object tree TB --- 2013-03-01 05:21:46 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-03-01 05:21:46 - cd /tinderbox/RELENG_9/arm/arm TB --- 2013-03-01 05:21:46 - /usr/local/bin/svn cleanup /src TB --- 2013-03-01 05:22:25 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:22:55 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:22:55 - WARNING: sleeping 30 s and retrying... TB --- 2013-03-01 05:23:25 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:23:51 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:23:51 - WARNING: sleeping 60 s and retrying... TB --- 2013-03-01 05:24:51 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:25:21 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:25:21 - WARNING: sleeping 90 s and retrying... TB --- 2013-03-01 05:26:51 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:27:21 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:27:21 - WARNING: sleeping 120 s and retrying... TB --- 2013-03-01 05:29:21 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:29:51 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:29:51 - ERROR: unable to check out the source tree TB --- 2013-03-01 05:29:51 - 3.95 user 4.98 system 484.98 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 07:05:46 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DD5668AF; Fri, 1 Mar 2013 07:05:46 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 9EEBDC48; Fri, 1 Mar 2013 07:05:46 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r2175jRX049846; Fri, 1 Mar 2013 07:05:45 GMT (envelope-from kientzle@FreeBSD.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id it6hr6mgwswg9ne9t59zfvwwj6; Fri, 01 Mar 2013 07:05:45 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Subject: Re: PHYSADDR Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1251 From: Tim Kientzle In-Reply-To: <1362100213.1195.88.camel@revolution.hippie.lan> Date: Thu, 28 Feb 2013 23:05:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6B8ECEA1-AC69-4B42-B866-266B8B5208DF@FreeBSD.org> References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <1362100213.1195.88.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 07:05:46 -0000 On Feb 28, 2013, at 5:10 PM, Ian Lepore wrote: > On Thu, 2013-02-28 at 08:58 -0800, Tim Kientzle wrote: >> On Feb 28, 2013, at 8:20 AM, Ian Lepore wrote: >>=20 >>> On Wed, 2013-02-27 at 22:27 -0800, Tim Kientzle wrote: >>>> Starting to look at what is needed for a Generic ARM kernel. >>>> There's a lot here; I sincerely hope I'm not the only one=85 ;-) >>>>=20 >>>> First up: Can we get rid of PHYSADDR? >>>>=20 >>>=20 >>> If you mean, can we get rid of it within the runtime kernel, I'd say >>> yes, because we can use a global variable instead which is easily >>> settable in the entry code. >>=20 >> It doesn't seem to be used in the runtime kernel. As far as >> I can see, it's purely a bootstrap concept. >>=20 >>> On the other hand, I've been working >>> towards getting that value set correctly in the kernel elf headers = at >>> link time. >>=20 >> My question really boils down to whether PIC techniques >> are sufficient for the early bootstrap stage to determine >> where the kernel is currently executing and use that to >> drive the initial MMU bring up. I've just started, but >> the PHYSADDR uses I've examined can be replaced >> with PIC techniques. But this part of the code is >> pretty involved and riddled with conditional compilations, >> so it will be slow going. >>=20 >> I was impressed to find that ubldr seems to be PIC. >> I've run the same binary at different load addresses >> and so far it "just works." (I didn't think it would work, >> so I was surprised by this. I haven't dug through to >> figure out why it works yet.) >>=20 >=20 > I was suprised by this paragraph, and I've just done some testing and = I > wonder if it's really running at different addresses, because I can't > make it do so without relinking it at that address. To test, I saved > the entry PC in uboot/start.S and printed it in main (patch below). = No > matter where I tell u-boot to load ubldr, it seems to ignore the = command > line and honor the elf headers: I'm testing on Raspberry Pi, whose initial memory map is from 0x000000000 - 0x20000000 and BeagleBone, whose initial memory map is 0x80000000 - 0x90000000, so there's no way that ubldr can be getting copied to the same address on both platforms. I'll have to go back and repeat my tests, because something is clearly not making sense here. Tim From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 08:57:20 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7E7CBF52 for ; Fri, 1 Mar 2013 08:57:20 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id B4C6C124 for ; Fri, 1 Mar 2013 08:57:19 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 5576939E09; Fri, 1 Mar 2013 17:57:10 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id 4012839D62; Fri, 1 Mar 2013 17:57:10 +0900 (JST) Message-ID: <2D2EAE5B346840A49A5D99A9BFD1DA1D@ad.peach.ne.jp> From: "Daisuke Aoyama" To: "Oleksandr Tymoshenko" References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <512FD3E8.4000307@bluezbox.com> In-Reply-To: <512FD3E8.4000307@bluezbox.com> Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Fri, 1 Mar 2013 17:57:12 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 08:57:20 -0000 > I'd like to thank you again for your outstanding work. > I've just committed three patches based on your code: > > - Platform DMA support for SDHCI > - DMA engine driver > - DMA support for BCM2835 SDHCI driver Thank you. I checked the code and found some bug. I don't check why bus_dma and bus_space is slow. But using generic code is good. ---------------------------------------------------------------------- o INFO_WAIT_RESP is cleared when reset. o dreq is overwritten by next call. o should reset DMA when error. quick fix is like this: --- bcm2835_dma.c (revision 247518) +++ bcm2835_dma.c (working copy) @@ -199,6 +199,7 @@ /* Reset control block */ cb = sc->sc_dma_ch[ch].cb; bzero(cb, sizeof(cb)); + cb->info = INFO_WAIT_RESP; /* XXX */ } static int @@ -409,8 +410,10 @@ return (-1); info = sc->sc_dma_ch[ch].cb->info; - info &= ~INFO_PERMAP_MASK; - info |= (dreq << INFO_PERMAP_SHIFT) & INFO_PERMAP_MASK; + if (dreq) { + info &= ~INFO_PERMAP_MASK; + info |= (dreq << INFO_PERMAP_SHIFT) & INFO_PERMAP_MASK; + } if (dreq) info |= INFO_S_DREQ; @@ -459,8 +462,10 @@ return (-1); info = sc->sc_dma_ch[ch].cb->info; - info &= ~INFO_PERMAP_MASK; - info |= (dreq << INFO_PERMAP_SHIFT) & INFO_PERMAP_MASK; + if (dreq) { + info &= ~INFO_PERMAP_MASK; + info |= (dreq << INFO_PERMAP_SHIFT) & INFO_PERMAP_MASK; + } if (dreq) info |= INFO_D_DREQ; @@ -615,6 +693,7 @@ debug & DEBUG_ERROR_MASK, ch->ch); bus_write_4(sc->sc_mem, BCM_DMA_DEBUG(ch->ch), debug & DEBUG_ERROR_MASK); + bcm_dma_reset(sc->sc_dev, ch->ch); } if (cs & CS_INT) { ---------------------------------------------------------------------- -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 15:04:59 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3B78C558 for ; Fri, 1 Mar 2013 15:04:59 +0000 (UTC) (envelope-from meschoyez@gmail.com) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by mx1.freebsd.org (Postfix) with ESMTP id EDA33228 for ; Fri, 1 Mar 2013 15:04:58 +0000 (UTC) Received: by mail-ia0-f171.google.com with SMTP id z13so2719871iaz.16 for ; Fri, 01 Mar 2013 07:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=LpBeunCmTBrR0wfDp8LRsDpLOQiOu/AxoJ2GCMJj9XM=; b=ei7bRG78hMzS+vdOkp2xIAe9r5l0jJEkpV/1xD9FI0rR2PLNCo4fjds2RnGqrWbMiv TlJLjOe+ldQlgkLpqcQg8eg30fbVEUyY7EpTGAElrba/NPEfemV9JP7xao3spvMk2+jn Fq2wRLfD6Y9jiBjyIJNAGkh48+nXrbWh9ZB2urKGyYvT7cSDEC8+oV9g3VZ6lVWB/cM5 XClbIe0ZMTuE0t+q+sM2GOgoidYYTRnfju1Ry0AH4XheP7I6SPELlML3SfFKcT0Lxmp7 g8OYsemMTIXEdIVrMaKxOhtqG29Zkdd5F3ksll7bwVZvnyW9j/AIb1+um4l39uyrNSI1 ts5g== MIME-Version: 1.0 X-Received: by 10.50.195.137 with SMTP id ie9mr6492328igc.46.1362150298468; Fri, 01 Mar 2013 07:04:58 -0800 (PST) Received: by 10.64.23.169 with HTTP; Fri, 1 Mar 2013 07:04:58 -0800 (PST) Date: Fri, 1 Mar 2013 12:04:58 -0300 Message-ID: Subject: Is there someone working with Mele A100/A1000? From: Maximiliano Eschoyez To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 15:04:59 -0000 Hi all, I'm interested in porting FreeBSD to Mele A100/A1000, but I didn't find any post on that. Mele products works fine with Android and Ubuntu, but I would be very happy to have a FreeBSB available. Now we are working with Ubuntu because we need to have a prototype working, but in a short time we wil try to boot FreeBSD. Every help/ideas/links would be appreciated!!! -- Saludos cordiales, Maximiliano Eschoyez From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 15:12:00 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BA3E7856 for ; Fri, 1 Mar 2013 15:12:00 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 7DCD128F for ; Fri, 1 Mar 2013 15:12:00 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UBRcs-0003Tm-6p; Fri, 01 Mar 2013 16:11:59 +0100 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UBRcr-0007BM-Nb; Fri, 01 Mar 2013 16:11:58 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org, "Maximiliano Eschoyez" Subject: Re: Is there someone working with Mele A100/A1000? References: Date: Fri, 01 Mar 2013 16:11:56 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.14 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.5 X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05 autolearn=disabled version=3.3.1 X-Scan-Signature: 919fae14bc17c74543a025539baad412 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 15:12:00 -0000 On Fri, 01 Mar 2013 16:04:58 +0100, Maximiliano Eschoyez wrote: > Hi all, > > I'm interested in porting FreeBSD to Mele A100/A1000, but I didn't > find any post on that. > > Mele products works fine with Android and Ubuntu, but I would be very > happy to have a FreeBSB available. > > Now we are working with Ubuntu because we need to have a prototype > working, but in a short time we wil try to boot FreeBSD. > > Every help/ideas/links would be appreciated!!! > http://archlinuxarm.org/platforms/armv7/mele-a100 gives: "It is powered by the Allwinner A10 SoC" About the allwinner A10 there were a all kinds of e-mails on this list and commits in FreeBSD. I don't know if that will give you a working system at once for this specific board. See also: http://lists.freebsd.org/pipermail/freebsd-arm/2013-March/005105.html Ronald. From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 15:47:35 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 99B4236D; Fri, 1 Mar 2013 15:47:35 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 5ECED66B; Fri, 1 Mar 2013 15:47:34 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UBSBK-000O1w-5c; Fri, 01 Mar 2013 15:47:34 +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 r21FlVEm086995; Fri, 1 Mar 2013 08:47:31 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+72menvMZLYT7uz3wq0Q37 Subject: Re: PHYSADDR From: Ian Lepore To: Tim Kientzle In-Reply-To: <6B8ECEA1-AC69-4B42-B866-266B8B5208DF@FreeBSD.org> References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <1362100213.1195.88.camel@revolution.hippie.lan> <6B8ECEA1-AC69-4B42-B866-266B8B5208DF@FreeBSD.org> Content-Type: text/plain; charset="windows-1251" Date: Fri, 01 Mar 2013 08:47:31 -0700 Message-ID: <1362152851.1195.102.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id r21FlVEm086995 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 15:47:35 -0000 On Thu, 2013-02-28 at 23:05 -0800, Tim Kientzle wrote: > On Feb 28, 2013, at 5:10 PM, Ian Lepore wrote: >=20 > > On Thu, 2013-02-28 at 08:58 -0800, Tim Kientzle wrote: > >> On Feb 28, 2013, at 8:20 AM, Ian Lepore wrote: > >>=20 > >>> On Wed, 2013-02-27 at 22:27 -0800, Tim Kientzle wrote: > >>>> Starting to look at what is needed for a Generic ARM kernel. > >>>> There's a lot here; I sincerely hope I'm not the only one=85 ;-) > >>>>=20 > >>>> First up: Can we get rid of PHYSADDR? > >>>>=20 > >>>=20 > >>> If you mean, can we get rid of it within the runtime kernel, I'd sa= y > >>> yes, because we can use a global variable instead which is easily > >>> settable in the entry code. > >>=20 > >> It doesn't seem to be used in the runtime kernel. As far as > >> I can see, it's purely a bootstrap concept. > >>=20 > >>> On the other hand, I've been working > >>> towards getting that value set correctly in the kernel elf headers = at > >>> link time. > >>=20 > >> My question really boils down to whether PIC techniques > >> are sufficient for the early bootstrap stage to determine > >> where the kernel is currently executing and use that to > >> drive the initial MMU bring up. I've just started, but > >> the PHYSADDR uses I've examined can be replaced > >> with PIC techniques. But this part of the code is > >> pretty involved and riddled with conditional compilations, > >> so it will be slow going. > >>=20 > >> I was impressed to find that ubldr seems to be PIC. > >> I've run the same binary at different load addresses > >> and so far it "just works." (I didn't think it would work, > >> so I was surprised by this. I haven't dug through to > >> figure out why it works yet.) > >>=20 > >=20 > > I was suprised by this paragraph, and I've just done some testing and= I > > wonder if it's really running at different addresses, because I can't > > make it do so without relinking it at that address. To test, I saved > > the entry PC in uboot/start.S and printed it in main (patch below). = No > > matter where I tell u-boot to load ubldr, it seems to ignore the comm= and > > line and honor the elf headers: >=20 > I'm testing on Raspberry Pi, whose initial memory map is > from 0x000000000 - 0x20000000 and BeagleBone, whose > initial memory map is 0x80000000 - 0x90000000, so there's > no way that ubldr can be getting copied to the same address > on both platforms. >=20 > I'll have to go back and repeat my tests, because something > is clearly not making sense here. Yeah, something's not right. I've never gotten ubldr to work on my BB at all, I just directly load the kernel from u-boot. Getting ubldr going was on my to-do list, so I just played with it now. u-boot says it loads ubldr to 0x82000000, then when I 'bootelf' it just hangs. If I re-link ubldr for an address in the 0x80000000+ range it loads and launches just fine (but then fails to load the kernel via the network, but that's just an unrelated problem I think). What does a "readelf -l" show for your ubldr? Is there any difference in what it shows between the ones built for rpi and bb in your setup? (I don't use your build scripts.) -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 16:19:58 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A9461393 for ; Fri, 1 Mar 2013 16:19:58 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by mx1.freebsd.org (Postfix) with ESMTP id 7EF077FD for ; Fri, 1 Mar 2013 16:19:58 +0000 (UTC) Received: by mail-ia0-f182.google.com with SMTP id w21so832992iac.41 for ; Fri, 01 Mar 2013 08:19:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MfLmKkJbxrlXQMOQaAxr5iMZVxU2yOsPuHMR7lWbF94=; b=PoXoInLGIcsin9vSm/Nb3C4ihjH8OLiaDa0LQ8p0IXXe8fXoeXKWuUY9W27qnIXdvQ UN37X+tXyDebLQWuH19YaX2X87DF9XKq1EOrh/WP8psCrQLukhQJAMLawmanf4LCbsz9 Vlhc2j08AoKoMgh3TZwB0U9ltlzjUwvmnmJE5RPclrtACIaq4RpeAaQznDgjA1gNOgCZ X3KHRm1YKYRGMkAdiciP2ZshK/2G+XKBGd8hOzMRrdrMjArYl47+jnRkceSdcDWHF280 XpYzLbyGJLvVEYf9QbPysC5bB97VS5d/czA0mktHWqIgOdbc1Ch2Wj2SPrnyag6GXseD kjSA== MIME-Version: 1.0 X-Received: by 10.50.100.201 with SMTP id fa9mr12748927igb.28.1362154798156; Fri, 01 Mar 2013 08:19:58 -0800 (PST) Received: by 10.64.6.230 with HTTP; Fri, 1 Mar 2013 08:19:58 -0800 (PST) In-Reply-To: References: Date: Sat, 2 Mar 2013 00:19:58 +0800 Message-ID: Subject: Re: Is there someone working with Mele A100/A1000? From: Ganbold Tsagaankhuu To: Maximiliano Eschoyez Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 16:19:58 -0000 On Fri, Mar 1, 2013 at 11:04 PM, Maximiliano Eschoyez wrote: > Hi all, > > I'm interested in porting FreeBSD to Mele A100/A1000, but I didn't > find any post on that. > > Mele products works fine with Android and Ubuntu, but I would be very > happy to have a FreeBSB available. > > Now we are working with Ubuntu because we need to have a prototype > working, but in a short time we wil try to boot FreeBSD. > > Every help/ideas/links would be appreciated!!! > Allwinner A10 SoC's basic support is in tree, so you can start hacking on it :) Ganbold > -- > Saludos cordiales, > > Maximiliano Eschoyez > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 16:33:56 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 497178E4 for ; Fri, 1 Mar 2013 16:33:56 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 064C78B5 for ; Fri, 1 Mar 2013 16:33:55 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UBSuB-0000gL-6p; Fri, 01 Mar 2013 16:33:55 +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 r21GXq6R087047; Fri, 1 Mar 2013 09:33:52 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/g9aovBJweD1zQR9izm1En Subject: Re: PHYSADDR From: Ian Lepore To: Tim Kientzle In-Reply-To: <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> Content-Type: text/plain; charset="windows-1251" Date: Fri, 01 Mar 2013 09:33:52 -0700 Message-ID: <1362155632.1195.120.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id r21GXq6R087047 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 16:33:56 -0000 On Thu, 2013-02-28 at 09:44 -0800, Tim Kientzle wrote: > On Feb 28, 2013, at 8:58 AM, Tim Kientzle wrote: >=20 > >=20 > > On Feb 28, 2013, at 8:20 AM, Ian Lepore wrote: > >=20 > >> On Wed, 2013-02-27 at 22:27 -0800, Tim Kientzle wrote: > >>> Starting to look at what is needed for a Generic ARM kernel. > >>> There's a lot here; I sincerely hope I'm not the only one=85 ;-) > >>>=20 > >>> First up: Can we get rid of PHYSADDR? > >>>=20 > >>=20 > >> If you mean, can we get rid of it within the runtime kernel, I'd say > >> yes, because we can use a global variable instead which is easily > >> settable in the entry code. > >=20 > > It doesn't seem to be used in the runtime kernel. As far as > > I can see, it's purely a bootstrap concept. > >=20 Well, it's used to set up the early-init page tables in locore.s then again to set up the real page tables and related things in initarm() and then I think it isn't used after that, so I should have said "within the kernel init". The main point I was getting at is that I don't think we need a compile-time constant of any sort related to the physical address at which the kernel is loaded. We can get the physical address of the entry point (_start) using pc-relative math, and we can get the linker to give us a constant symbol which is the offset of the _start symbol within the load image. So we can get the load address at runtime without guessing what low-order bits to mask. > >> On the other hand, I've been working > >> towards getting that value set correctly in the kernel elf headers a= t > >> link time. >=20 > A-ha! I think I just figured something out. >=20 > How would the following work: >=20 > * Rename PHYSADDR to KERNPHYSADDR_BASE >=20 > * in the top of locore.s, we have a single conditional: >=20 > #ifdef KERNPHYSADDR_BASE > _kpa_base =3D KERNPHYSADDR_BASE; > #else > _kpa_base =3D pc & 0xF0000000; > #endif >=20 > I think this would DTRT on all of the configurations > we currently have in SVN. Hmm, so the basic assumption is that every SoC will have some physical memory aligned to a 256mb boundary. E.G., there'll never be a SoC with memory at 0xN1000000 that doesn't have memory at 0xN0000000. I'm not sure that's a safe assumption given things like the rpi where the gpu carves off some memory for itself and gives the rest to the arm. It works with the way rpi carves up the ram, but I could see similar designs that wouldn't work. >=20 > * We redefine KERNPHYSADDR to be an *offset* > against _kpa_base. Then we could negotiate a single > offset (64k?) that works well on many platforms and use > that for the GENERIC kernel. Boot loaders would be > responsible for loading the kernel at an address that > preserves the KPA_OFFSET. The KPA_OFFSET would > be used in the ELF headers. >=20 > Then there are routine code transformations to use _kpa_base > instead of the compile-time symbol and to use > _kpa_base + KERNPHYSADDR instead of KERNPHYSADDR. >=20 > Does this sound reasonable as a starting point? >=20 There are even more assumptions here about what would work in every case. Given the basic sequence of boot2->u-boot->ubldr->kernel, every one of those components has to load the next component at the physical address it's linked for, and that has to not overlap the addresses being used by the thing doing the loading. The MMU is off during all of this so we can't just map our way out of any conflicts. Whatever arbitrary address we pick for the kernel is sure to conflict eventually with the memory occupied by u-boot on some random system. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 17:19:57 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 58BDA7FE; Fri, 1 Mar 2013 17:19:57 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 3767EAA1; Fri, 1 Mar 2013 17:19:56 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r21HJnbg052706; Fri, 1 Mar 2013 17:19:49 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id wvzgcmweu8cuijhnzwyavu86je; Fri, 01 Mar 2013 17:19:49 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: PHYSADDR Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1251 From: Tim Kientzle In-Reply-To: <1362155632.1195.120.camel@revolution.hippie.lan> Date: Fri, 1 Mar 2013 09:19:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5B622D1B-4EAE-4184-A194-DD14083A48B6@kientzle.com> References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> <1362155632.1195.120.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 17:19:57 -0000 On Mar 1, 2013, at 8:33 AM, Ian Lepore wrote: > On Thu, 2013-02-28 at 09:44 -0800, Tim Kientzle wrote: >> On Feb 28, 2013, at 8:58 AM, Tim Kientzle wrote: >>=20 >>>=20 >>> On Feb 28, 2013, at 8:20 AM, Ian Lepore wrote: >>>=20 >>>> On Wed, 2013-02-27 at 22:27 -0800, Tim Kientzle wrote: >>>>> Starting to look at what is needed for a Generic ARM kernel. >>>>> There's a lot here; I sincerely hope I'm not the only one=85 ;-) >>>>>=20 >>>>> First up: Can we get rid of PHYSADDR? >>>>>=20 >>>>=20 >>>> If you mean, can we get rid of it within the runtime kernel, I'd = say >>>> yes, because we can use a global variable instead which is easily >>>> settable in the entry code. >>>=20 >>> It doesn't seem to be used in the runtime kernel. As far as >>> I can see, it's purely a bootstrap concept. >>>=20 >=20 > Well, it's used to set up the early-init page tables in locore.s then > again to set up the real page tables and related things in initarm() = and > then I think it isn't used after that, so I should have said "within = the > kernel init". The main point I was getting at is that I don't think = we > need a compile-time constant of any sort related to the physical = address > at which the kernel is loaded. We can get the physical address of the > entry point (_start) using pc-relative math, and we can get the linker > to give us a constant symbol which is the offset of the _start symbol > within the load image. So we can get the load address at runtime > without guessing what low-order bits to mask. Good. That's the approach I've been eyeing as well; I'm glad you agree that makes sense. >=20 >>>> On the other hand, I've been working >>>> towards getting that value set correctly in the kernel elf headers = at >>>> link time. >>=20 >> A-ha! I think I just figured something out. >>=20 >> How would the following work: >>=20 >> * Rename PHYSADDR to KERNPHYSADDR_BASE >>=20 >> * in the top of locore.s, we have a single conditional: >>=20 >> #ifdef KERNPHYSADDR_BASE >> _kpa_base =3D KERNPHYSADDR_BASE; >> #else >> _kpa_base =3D pc & 0xF0000000; >> #endif >>=20 >> I think this would DTRT on all of the configurations >> we currently have in SVN. >=20 > Hmm, so the basic assumption is that every SoC will have some physical > memory aligned to a 256mb boundary. I'm assuming this only for ARM systems supported by the GENERIC kernel. Ss far as I can tell, the 256mb boundary assumption works for everything currently in SVN. But the code above does allow you to custom-build a kernel for a system that doesn't satisfy that; you just won't be able to run the GENERIC kernel there. Eventually, it seems we might pull this information out of the FDT, but I'm not yet ready to tackle FDT parsing in locore.S. ;-) Of course, I'm not certain that it will matter when we're done. If we only need PHYSADDR to set up the MMU paging, then we just need to round the _start address down to the next page boundary, don't we? > E.G., there'll never be a SoC with > memory at 0xN1000000 that doesn't have memory at 0xN0000000. I'm not > sure that's a safe assumption given things like the rpi where the gpu > carves off some memory for itself and gives the rest to the arm. It > works with the way rpi carves up the ram, but I could see similar > designs that wouldn't work. >=20 >>=20 >> * We redefine KERNPHYSADDR to be an *offset* >> against _kpa_base. Then we could negotiate a single >> offset (64k?) that works well on many platforms and use >> that for the GENERIC kernel. Boot loaders would be >> responsible for loading the kernel at an address that >> preserves the KPA_OFFSET. The KPA_OFFSET would >> be used in the ELF headers. >>=20 >> Then there are routine code transformations to use _kpa_base >> instead of the compile-time symbol and to use >> _kpa_base + KERNPHYSADDR instead of KERNPHYSADDR. >>=20 >> Does this sound reasonable as a starting point? >>=20 >=20 > There are even more assumptions here about what would work in every > case. Given the basic sequence of boot2->u-boot->ubldr->kernel, every > one of those components has to load the next component at the physical > address it's linked for, and that has to not overlap the addresses = being > used by the thing doing the loading. The MMU is off during all of = this > so we can't just map our way out of any conflicts. I've given up entirely on the first two of these being generic. I think we have a shot at making the kernel itself generic, and maybe ubldr could be made truly PIC, but the earlier boot stages are always going to be highly board-specific. So conflicts between the various pieces aren't really my primary worry at the moment. Since we'll have to customize the early boot pieces anyway, we can resolve those on a case-by-case basis. The ELF load address vs. where physical memory is located seems the sticky point. Any ideas for getting around that? I feel like I have enough ideas to start chipping away at locore.S if I could just figure out a strategy for the ELF load address issue. (Of course, I still don't understand why the test image I've been playing with seems able to load the same ubldr on both RPi and BBone and that ubldr seems to have no trouble loading a kernel into memory.) Tim From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 04:26:03 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1486039E for ; Sat, 2 Mar 2013 04:26:03 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp5.clear.net.nz (smtp5.clear.net.nz [203.97.33.68]) by mx1.freebsd.org (Postfix) with ESMTP id C6DF791B for ; Sat, 2 Mar 2013 04:26:02 +0000 (UTC) Received: from mxin3-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp5.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MJ000EUPMZ3W810@smtp5.clear.net.nz> for freebsd-arm@freebsd.org; Sat, 02 Mar 2013 17:25:55 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin32.paradise.net.nz with ESMTP; Sat, 02 Mar 2013 17:25:55 +1300 Date: Sat, 02 Mar 2013 17:25:56 +1300 From: Andrew Turner Subject: ARM EABI test image To: freebsd-arm@freebsd.org Message-id: <20130302172556.5b59e122@bender> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 04:26:03 -0000 Hello, I have built an updated ARM EABI test image for Raspberry Pi [1]. The only known issue is c++ exception handling is broken when using in a dynamically linked executable. Static executables should work with c++ exceptions. To test it you will have to extract it using unxz and dd it to an sd card, for example, with a USB to SD adapter on /dev/da0: $ unxz bsd-pi-eabi-r247609.img.xz $ dd if=bsd-pi-eabi-r247609.img of=/dev/da0 If you don't have a Raspberry Pi but would like to try it on your board you can add -DWITH_ARM_EABI to the make commands you use to build and install world and the kernel. Can people try this as I would like to know if anything else is broken as this will become the default ABI for 10. Andrew [1] http://people.freebsd.org/~andrew/rpi/bsd-pi-eabi-r247609.img.xz From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 17:17:01 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F0336F71 for ; Sat, 2 Mar 2013 17:17:01 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id C99B788B for ; Sat, 2 Mar 2013 17:17:01 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id bn7so4658465ieb.39 for ; Sat, 02 Mar 2013 09:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=RIgXUpk2170Gd4s8V3H3aBrLUy3nvcLJFYbo9uORNRM=; b=J9mCC1/Lk778VUTMUAJfDz4xtBlyZbVrCLAvMlgOwbrqzJkpxfdKKi/qPecSWvspBA QJ5bW0Nr+r8QDpkALXz1BSQuPE1veh+2utuS31Br+7pp2QapXzSn8XUCBdsgVCkOxp6/ lZDjWV6KCUtoR/QJb2yiiBgoKCFHyecQlscZG3bQeJqcNutTMiwdX1azPi2XSW/jadaC eYY0zI4kzFS/Tlc225/GCJWYkvD0dW+Ic7rtRurR2BMUYlm5e7oY8pkkw62/Mh9X6yGE OiEPnuySjy6dbQT61pjkVV2y52cNPF9BZXi91qjd5RTBiSiSK3wE9qck0s9RZ/5VR63Z Fmtw== MIME-Version: 1.0 X-Received: by 10.43.65.145 with SMTP id xm17mr15454189icb.35.1362244621439; Sat, 02 Mar 2013 09:17:01 -0800 (PST) Received: by 10.64.6.230 with HTTP; Sat, 2 Mar 2013 09:17:01 -0800 (PST) In-Reply-To: <20130302172556.5b59e122@bender> References: <20130302172556.5b59e122@bender> Date: Sun, 3 Mar 2013 01:17:01 +0800 Message-ID: Subject: Re: ARM EABI test image From: Ganbold Tsagaankhuu To: Andrew Turner Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 17:17:02 -0000 Andrew, On Sat, Mar 2, 2013 at 12:25 PM, Andrew Turner wrote: > Hello, > > I have built an updated ARM EABI test image for Raspberry Pi [1]. > > The only known issue is c++ exception handling is broken when > using in a dynamically linked executable. Static executables should > work with c++ exceptions. > > To test it you will have to extract it using unxz and dd it to an sd > card, for example, with a USB to SD adapter on /dev/da0: > $ unxz bsd-pi-eabi-r247609.img.xz > $ dd if=bsd-pi-eabi-r247609.img of=/dev/da0 > > If you don't have a Raspberry Pi but would like to try it on your board > you can add -DWITH_ARM_EABI to the make commands you use to build and > install world and the kernel. > > Can people try this as I would like to know if anything else is broken > as this will become the default ABI for 10. > Just tried the image. Seems work but observed for instance gpart shows big numbers for 2GB SD: root@raspberry-pi:/home/pi # uname -an FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r247609: Sat Mar 2 16:43:25 NZDT 2013 andrew@bender:/usr/obj/arm.armv6/usr/home/andrew/freebsd/anon/head/sys/RPI-B arm root@raspberry-pi:/home/pi # gpart show => 4294967296 16800529082482689 mmcsd0 MBR (20G) 4294967296 266287972352 - free - (124T) 270582939648 281401962266625 1 !12 [active] (0B) 281672545206273 4294967295 - free - (2T) 281676840173568 8725483759861761 2 freebsd (8.0G) 9007160600035329 4294967295 - free - (2T) 9007164895002624 7793325532774401 3 freebsd (4.0G) 16800490427777025 42949672960 - free - (20T) => 0 8725483759861761 mmcsd0s2 BSD (8.0G) 0 8725483759861761 1 freebsd-ufs (4.0G) Ganbold > Andrew > > [1] http://people.freebsd.org/~andrew/rpi/bsd-pi-eabi-r247609.img.xz > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 17:21:30 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A31D52E6 for ; Sat, 2 Mar 2013 17:21:30 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 6758E8CC for ; Sat, 2 Mar 2013 17:21:29 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UBq7h-0008VL-9E; Sat, 02 Mar 2013 18:21:26 +0100 Received: from h253044.upc-h.chello.nl ([62.194.253.44] helo=pinky) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UBq7h-0002OG-4x; Sat, 02 Mar 2013 18:21:25 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org, "Andrew Turner" Subject: Re: ARM EABI test image References: <20130302172556.5b59e122@bender> Date: Sat, 02 Mar 2013 18:21:28 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <20130302172556.5b59e122@bender> User-Agent: Opera Mail/12.14 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.5 X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05 autolearn=disabled version=3.3.1 X-Scan-Signature: 9090f8a1960d7f777b94d17b6f36e747 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 17:21:30 -0000 On Sat, 02 Mar 2013 05:25:56 +0100, Andrew Turner wrote: > Hello, > > I have built an updated ARM EABI test image for Raspberry Pi [1]. > > The only known issue is c++ exception handling is broken when > using in a dynamically linked executable. Static executables should > work with c++ exceptions. > > To test it you will have to extract it using unxz and dd it to an sd > card, for example, with a USB to SD adapter on /dev/da0: > $ unxz bsd-pi-eabi-r247609.img.xz > $ dd if=bsd-pi-eabi-r247609.img of=/dev/da0 > > If you don't have a Raspberry Pi but would like to try it on your board > you can add -DWITH_ARM_EABI to the make commands you use to build and > install world and the kernel. Is this also interesing on the older SHEEVAPLUG? If yes, I can test it somewhere next week. Ronald. > > Can people try this as I would like to know if anything else is broken > as this will become the default ABI for 10. > > Andrew > > [1] http://people.freebsd.org/~andrew/rpi/bsd-pi-eabi-r247609.img.xz > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 17:45:13 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 34C2E79C for ; Sat, 2 Mar 2013 17:45:13 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 17CFD9D0 for ; Sat, 2 Mar 2013 17:45:12 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r22Hj6ZC059440; Sat, 2 Mar 2013 17:45:06 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id qzetrc32jcwrq5cp58k2qi2yh6; Sat, 02 Mar 2013 17:45:06 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: ARM EABI test image Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <20130302172556.5b59e122@bender> Date: Sat, 2 Mar 2013 09:45:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130302172556.5b59e122@bender> To: Andrew Turner X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 17:45:13 -0000 On Mar 1, 2013, at 8:25 PM, Andrew Turner wrote: > Hello, >=20 > I have built an updated ARM EABI test image for Raspberry Pi [1]. >=20 > The only known issue is c++ exception handling is broken when > using in a dynamically linked executable. Static executables should > work with c++ exceptions. >=20 > To test it you will have to extract it using unxz and dd it to an sd > card, for example, with a USB to SD adapter on /dev/da0: > $ unxz bsd-pi-eabi-r247609.img.xz > $ dd if=3Dbsd-pi-eabi-r247609.img of=3D/dev/da0 >=20 > If you don't have a Raspberry Pi but would like to try it on your = board > you can add -DWITH_ARM_EABI to the make commands you use to build and > install world and the kernel. For people working with my build scripts, it should suffice to add this to your config.sh: FREEBSD_WORLD_EXTRA_ARGS=3D"-DWITH_ARM_EABI" FREEBSD_KERNEL_EXTRA_ARGS=3D"-DWITH_ARM_EABI" I'm starting some builds right now=85. Tim From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 17:50:38 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CA08080B for ; Sat, 2 Mar 2013 17:50:38 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 8D7929EC for ; Sat, 2 Mar 2013 17:50:38 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UBqZx-0008HR-JV; Sat, 02 Mar 2013 17:50:37 +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 r22HoZfq088735; Sat, 2 Mar 2013 10:50:35 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/ihffNoxpjoJ8MJ5wYmv2Q Subject: Re: PHYSADDR From: Ian Lepore To: Tim Kientzle In-Reply-To: <5B622D1B-4EAE-4184-A194-DD14083A48B6@kientzle.com> References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> <1362155632.1195.120.camel@revolution.hippie.lan> <5B622D1B-4EAE-4184-A194-DD14083A48B6@kientzle.com> Content-Type: text/plain; charset="windows-1251" Date: Sat, 02 Mar 2013 10:50:34 -0700 Message-ID: <1362246634.1195.178.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id r22HoZfq088735 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 17:50:38 -0000 On Fri, 2013-03-01 at 09:19 -0800, Tim Kientzle wrote: > On Mar 1, 2013, at 8:33 AM, Ian Lepore wrote: >=20 > > On Thu, 2013-02-28 at 09:44 -0800, Tim Kientzle wrote: > >> On Feb 28, 2013, at 8:58 AM, Tim Kientzle wrote: > >>=20 > >>>=20 > >>> On Feb 28, 2013, at 8:20 AM, Ian Lepore wrote: > >>>=20 > >>>> On Wed, 2013-02-27 at 22:27 -0800, Tim Kientzle wrote: > >>>>> Starting to look at what is needed for a Generic ARM kernel. > >>>>> There's a lot here; I sincerely hope I'm not the only one=85 ;-) > >>>>>=20 > >>>>> First up: Can we get rid of PHYSADDR? > >>>>>=20 > >>>>=20 > >>>> If you mean, can we get rid of it within the runtime kernel, I'd s= ay > >>>> yes, because we can use a global variable instead which is easily > >>>> settable in the entry code. > >>>=20 > >>> It doesn't seem to be used in the runtime kernel. As far as > >>> I can see, it's purely a bootstrap concept. > >>>=20 > >=20 > > Well, it's used to set up the early-init page tables in locore.s then > > again to set up the real page tables and related things in initarm() = and > > then I think it isn't used after that, so I should have said "within = the > > kernel init". The main point I was getting at is that I don't think = we > > need a compile-time constant of any sort related to the physical addr= ess > > at which the kernel is loaded. We can get the physical address of th= e > > entry point (_start) using pc-relative math, and we can get the linke= r > > to give us a constant symbol which is the offset of the _start symbol > > within the load image. So we can get the load address at runtime > > without guessing what low-order bits to mask. >=20 > Good. That's the approach I've been eyeing as well; I'm > glad you agree that makes sense. >=20 > >=20 > >>>> On the other hand, I've been working > >>>> towards getting that value set correctly in the kernel elf headers= at > >>>> link time. > >>=20 > >> A-ha! I think I just figured something out. > >>=20 > >> How would the following work: > >>=20 > >> * Rename PHYSADDR to KERNPHYSADDR_BASE > >>=20 > >> * in the top of locore.s, we have a single conditional: > >>=20 > >> #ifdef KERNPHYSADDR_BASE > >> _kpa_base =3D KERNPHYSADDR_BASE; > >> #else > >> _kpa_base =3D pc & 0xF0000000; > >> #endif > >>=20 > >> I think this would DTRT on all of the configurations > >> we currently have in SVN. > >=20 > > Hmm, so the basic assumption is that every SoC will have some physica= l > > memory aligned to a 256mb boundary. >=20 > I'm assuming this only for ARM systems supported by the GENERIC > kernel. >=20 > Ss far as I can tell, the 256mb boundary assumption works for > everything currently in SVN. But the code above does allow you > to custom-build a kernel for a system that doesn't satisfy that; > you just won't be able to run the GENERIC kernel there. >=20 > Eventually, it seems we might pull this information out of the > FDT, but I'm not yet ready to tackle FDT parsing in locore.S. ;-) >=20 > Of course, I'm not certain that it will matter when we're done. > If we only need PHYSADDR to set up the MMU paging, > then we just need to round the _start address down to > the next page boundary, don't we? >=20 > > E.G., there'll never be a SoC with > > memory at 0xN1000000 that doesn't have memory at 0xN0000000. I'm not > > sure that's a safe assumption given things like the rpi where the gpu > > carves off some memory for itself and gives the rest to the arm. It > > works with the way rpi carves up the ram, but I could see similar > > designs that wouldn't work. > >=20 > >>=20 > >> * We redefine KERNPHYSADDR to be an *offset* > >> against _kpa_base. Then we could negotiate a single > >> offset (64k?) that works well on many platforms and use > >> that for the GENERIC kernel. Boot loaders would be > >> responsible for loading the kernel at an address that > >> preserves the KPA_OFFSET. The KPA_OFFSET would > >> be used in the ELF headers. > >>=20 > >> Then there are routine code transformations to use _kpa_base > >> instead of the compile-time symbol and to use > >> _kpa_base + KERNPHYSADDR instead of KERNPHYSADDR. > >>=20 > >> Does this sound reasonable as a starting point? > >>=20 > >=20 > > There are even more assumptions here about what would work in every > > case. Given the basic sequence of boot2->u-boot->ubldr->kernel, ever= y > > one of those components has to load the next component at the physica= l > > address it's linked for, and that has to not overlap the addresses be= ing > > used by the thing doing the loading. The MMU is off during all of th= is > > so we can't just map our way out of any conflicts. >=20 > I've given up entirely on the first two of these being generic. >=20 > I think we have a shot at making the kernel itself generic, > and maybe ubldr could be made truly PIC, but the earlier > boot stages are always going to be highly board-specific. >=20 > So conflicts between the various pieces aren't really > my primary worry at the moment. Since we'll have to > customize the early boot pieces anyway, we can resolve > those on a case-by-case basis. >=20 > The ELF load address vs. where physical memory is located > seems the sticky point. Any ideas for getting around that? > I feel like I have enough ideas to start chipping away at > locore.S if I could just figure out a strategy for the ELF > load address issue. >=20 > (Of course, I still don't understand why the test image I've > been playing with seems able to load the same ubldr on > both RPi and BBone and that ubldr seems to have no trouble > loading a kernel into memory.) We may not have control over anything before ubldr. Not everything is an eval board that you can easily build a custom u-boot for. =20 I'm not sure its safe to assume that (entry-pc & 0xfffff000) is the beginning of the kernel; it's true now but need not be so. But that's no big deal, we can tweak the linker script to give us the offset of the _start symbol so it'll work no matter what. The more I ponder the fixed offset concept for a generic kernel the more it seems that it might be viable, providing that we require the use of ubldr. Then we can make sure that ubldr is always linked at an offset that doesn't overlap the kernel load offset. An offset number like 1mb or 4mb might work well for the kernel; it leaves lots of space for ubldr to be loaded down low in memory. I think putting the loader at a lower address than the kernel is required, because there's no upper bound on the kernel size (I did a 27MB kernel last month -- it contains a huge embedded md filesystem image). This just pushes the real problem into ubldr, though, and that becomes the non-generic component that has to be linked at a different physical address for each SoC. A kernel could still be loaded without ubldr, but it may need to be built in a non-generic way for some platforms. So if we declare that this scheme is for generic kernels loaded by a loader (ubldr or other) that is aware of the generic kernel scheme, there's no need for the physical address fields in the elf headers to be interpretted as a real physical address that would work for a standard elf loader. You can build kernels that work with a standard elf loader, but the generic kernel is not such a thing. =20 In that case, the physical address and entry address fields in the headers are all offsets. If physical ram on a given chip starts at zero, then the headers would accidentally be right for a standard elf loader. Otherwise the generic-aware loader is responsible for filling in some high-order bits when interpretting the headers. The PHYSADDR symbol (and its several name variations) at build time now becomes zero for a generic kernel or non-zero to generate a SoC-specific kernel that can be loaded by a standard elf loader. The symbol doesn't exist at all in the compilation, it's used only by the build system and is passed as a parameter to the linker. There's another problem constant we haven't talked about yet: STARTUP_PAGETABLE_ADDR, used by locore to build the early page tables. It's the absolute physical address of an area of memory that doesn't have any other important data in it, and won't get overwritten by something before initarm() builds the real page tables. I think most SoCs now put it way up high in memory "safely out of the way", but that won't work generically. We need 16K aligned to a 16K boundary, and maybe it would work to use the area immediately preceeding the start of the kernel. We could require the kernel to be linked on a 16k boundary so that we can just blindly subtract 16K from the starting physaddr we calculate; nice and easy. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 17:53:57 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3A9FEBCD for ; Sat, 2 Mar 2013 17:53:57 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id 12D84A28 for ; Sat, 2 Mar 2013 17:53:56 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UBqdA-000Oo6-21; Sat, 02 Mar 2013 17:53:56 +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 r22Hrogn088749; Sat, 2 Mar 2013 10:53:50 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18RieNFBNvFFpZqQZlvaDgh Subject: Re: ARM EABI test image From: Ian Lepore To: Ronald Klop In-Reply-To: References: <20130302172556.5b59e122@bender> Content-Type: text/plain; charset="us-ascii" Date: Sat, 02 Mar 2013 10:53:50 -0700 Message-ID: <1362246830.1195.181.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 17:53:57 -0000 On Sat, 2013-03-02 at 18:21 +0100, Ronald Klop wrote: > On Sat, 02 Mar 2013 05:25:56 +0100, Andrew Turner > wrote: > > > Hello, > > > > I have built an updated ARM EABI test image for Raspberry Pi [1]. > > > > The only known issue is c++ exception handling is broken when > > using in a dynamically linked executable. Static executables should > > work with c++ exceptions. > > > > To test it you will have to extract it using unxz and dd it to an sd > > card, for example, with a USB to SD adapter on /dev/da0: > > $ unxz bsd-pi-eabi-r247609.img.xz > > $ dd if=bsd-pi-eabi-r247609.img of=/dev/da0 > > > > If you don't have a Raspberry Pi but would like to try it on your board > > you can add -DWITH_ARM_EABI to the make commands you use to build and > > install world and the kernel. > > Is this also interesing on the older SHEEVAPLUG? > If yes, I can test it somewhere next week. > > Ronald. As I understand it, the plan is that eventually everything is EABI, including the older armv4/5 stuff, so that needs testing too. You know what I haven't stumbled across yet is a simple explanation of why EABI is better then OABI. I tried to search for some info the other day, but there are so many noise hits on the search I didn't find a simple synopsis of differences or advantages. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 18:00:11 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B3EFEC60; Sat, 2 Mar 2013 18:00:11 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 68CC3A59; Sat, 2 Mar 2013 18:00:11 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UBqjA-0004Ix-H7; Sat, 02 Mar 2013 19:00:09 +0100 Received: from h253044.upc-h.chello.nl ([62.194.253.44] helo=pinky) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UBqjA-000499-G2; Sat, 02 Mar 2013 19:00:08 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Ian Lepore" Subject: Re: ARM EABI test image References: <20130302172556.5b59e122@bender> <1362246830.1195.181.camel@revolution.hippie.lan> Date: Sat, 02 Mar 2013 19:00:11 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <1362246830.1195.181.camel@revolution.hippie.lan> User-Agent: Opera Mail/12.14 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 12f61b0c8dc8dcc8c992b8e1fde77987 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 18:00:11 -0000 On Sat, 02 Mar 2013 18:53:50 +0100, Ian Lepore wrote: > On Sat, 2013-03-02 at 18:21 +0100, Ronald Klop wrote: >> On Sat, 02 Mar 2013 05:25:56 +0100, Andrew Turner >> wrote: >> >> > Hello, >> > >> > I have built an updated ARM EABI test image for Raspberry Pi [1]. >> > >> > The only known issue is c++ exception handling is broken when >> > using in a dynamically linked executable. Static executables should >> > work with c++ exceptions. >> > >> > To test it you will have to extract it using unxz and dd it to an sd >> > card, for example, with a USB to SD adapter on /dev/da0: >> > $ unxz bsd-pi-eabi-r247609.img.xz >> > $ dd if=bsd-pi-eabi-r247609.img of=/dev/da0 >> > >> > If you don't have a Raspberry Pi but would like to try it on your >> board >> > you can add -DWITH_ARM_EABI to the make commands you use to build and >> > install world and the kernel. >> >> Is this also interesing on the older SHEEVAPLUG? >> If yes, I can test it somewhere next week. >> >> Ronald. > > As I understand it, the plan is that eventually everything is EABI, > including the older armv4/5 stuff, so that needs testing too. > > You know what I haven't stumbled across yet is a simple explanation of > why EABI is better then OABI. I tried to search for some info the other > day, but there are so many noise hits on the search I didn't find a > simple synopsis of differences or advantages. Googling on 'eabi vs oabi' gives me this http://wiki.embeddedarm.com/wiki/EABI_vs_OABI. Ronald. From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 18:05:27 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5BA46D62 for ; Sat, 2 Mar 2013 18:05:27 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 1B782A85 for ; Sat, 2 Mar 2013 18:05:26 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UBqoI-000F0g-Es; Sat, 02 Mar 2013 18:05:26 +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 r22I5NF9088764; Sat, 2 Mar 2013 11:05:23 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19kcY1H7HvVC4WBOXOcWpq7 Subject: Re: ARM EABI test image From: Ian Lepore To: Ronald Klop In-Reply-To: References: <20130302172556.5b59e122@bender> <1362246830.1195.181.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sat, 02 Mar 2013 11:05:23 -0700 Message-ID: <1362247523.1195.183.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 18:05:27 -0000 On Sat, 2013-03-02 at 19:00 +0100, Ronald Klop wrote: > On Sat, 02 Mar 2013 18:53:50 +0100, Ian Lepore wrote: > > > On Sat, 2013-03-02 at 18:21 +0100, Ronald Klop wrote: > >> On Sat, 02 Mar 2013 05:25:56 +0100, Andrew Turner > >> wrote: > >> > >> > Hello, > >> > > >> > I have built an updated ARM EABI test image for Raspberry Pi [1]. > >> > > >> > The only known issue is c++ exception handling is broken when > >> > using in a dynamically linked executable. Static executables should > >> > work with c++ exceptions. > >> > > >> > To test it you will have to extract it using unxz and dd it to an sd > >> > card, for example, with a USB to SD adapter on /dev/da0: > >> > $ unxz bsd-pi-eabi-r247609.img.xz > >> > $ dd if=bsd-pi-eabi-r247609.img of=/dev/da0 > >> > > >> > If you don't have a Raspberry Pi but would like to try it on your > >> board > >> > you can add -DWITH_ARM_EABI to the make commands you use to build and > >> > install world and the kernel. > >> > >> Is this also interesing on the older SHEEVAPLUG? > >> If yes, I can test it somewhere next week. > >> > >> Ronald. > > > > As I understand it, the plan is that eventually everything is EABI, > > including the older armv4/5 stuff, so that needs testing too. > > > > You know what I haven't stumbled across yet is a simple explanation of > > why EABI is better then OABI. I tried to search for some info the other > > day, but there are so many noise hits on the search I didn't find a > > simple synopsis of differences or advantages. > > Googling on 'eabi vs oabi' gives me this > http://wiki.embeddedarm.com/wiki/EABI_vs_OABI. I saw that, but that's a linux-specific answer to a linux-specific problem that freebsd never had: we use OABI without assuming hardware fp and emulating it in the kernel via traps. I hope there's more advantage to EABI than just that, since that part of it gets us nothing. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 18:10:45 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 87528411; Sat, 2 Mar 2013 18:10:45 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 6B134AE5; Sat, 2 Mar 2013 18:10:45 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r22IAj8C059639; Sat, 2 Mar 2013 18:10:45 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 5rcehu2f3kjgh26nzqx3geuerw; Sat, 02 Mar 2013 18:10:44 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: PHYSADDR Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1251 From: Tim Kientzle In-Reply-To: <1362246634.1195.178.camel@revolution.hippie.lan> Date: Sat, 2 Mar 2013 10:10:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> <1362155632.1195.120.camel@revolution.hippie.lan> <5B622D1B-4EAE-4184-A194-DD14083A48B6@kientzle.com> <1362246634.1195.178.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 18:10:45 -0000 On Mar 2, 2013, at 9:50 AM, Ian Lepore wrote: > On Fri, 2013-03-01 at 09:19 -0800, Tim Kientzle wrote: >> On Mar 1, 2013, at 8:33 AM, Ian Lepore wrote: >>=20 >>> On Thu, 2013-02-28 at 09:44 -0800, Tim Kientzle wrote: >>>> On Feb 28, 2013, at 8:58 AM, Tim Kientzle wrote: >>>>=20 >>>>>=20 >>>>> On Feb 28, 2013, at 8:20 AM, Ian Lepore wrote: >>>>>=20 >>>>>> On Wed, 2013-02-27 at 22:27 -0800, Tim Kientzle wrote: >>>>>>> Starting to look at what is needed for a Generic ARM kernel. >>>>>>> There's a lot here; I sincerely hope I'm not the only one=85 ;-) >>>>>>>=20 >>>>>>> First up: Can we get rid of PHYSADDR? >>>>>>>=20 >>>>>>=20 >>>>>> If you mean, can we get rid of it within the runtime kernel, I'd = say >>>>>> yes, because we can use a global variable instead which is easily >>>>>> settable in the entry code. >>>>>=20 >>>>> It doesn't seem to be used in the runtime kernel. As far as >>>>> I can see, it's purely a bootstrap concept. >>>>>=20 >>>=20 >>> Well, it's used to set up the early-init page tables in locore.s = then >>> again to set up the real page tables and related things in initarm() = and >>> then I think it isn't used after that, so I should have said "within = the >>> kernel init". The main point I was getting at is that I don't think = we >>> need a compile-time constant of any sort related to the physical = address >>> at which the kernel is loaded. We can get the physical address of = the >>> entry point (_start) using pc-relative math, and we can get the = linker >>> to give us a constant symbol which is the offset of the _start = symbol >>> within the load image. So we can get the load address at runtime >>> without guessing what low-order bits to mask. >>=20 >> Good. That's the approach I've been eyeing as well; I'm >> glad you agree that makes sense. >>=20 >>>=20 >>>>>> On the other hand, I've been working >>>>>> towards getting that value set correctly in the kernel elf = headers at >>>>>> link time. >>>>=20 >>>> A-ha! I think I just figured something out. >>>>=20 >>>> How would the following work: >>>>=20 >>>> * Rename PHYSADDR to KERNPHYSADDR_BASE >>>>=20 >>>> * in the top of locore.s, we have a single conditional: >>>>=20 >>>> #ifdef KERNPHYSADDR_BASE >>>> _kpa_base =3D KERNPHYSADDR_BASE; >>>> #else >>>> _kpa_base =3D pc & 0xF0000000; >>>> #endif >>>>=20 >>>> I think this would DTRT on all of the configurations >>>> we currently have in SVN. >>>=20 >>> Hmm, so the basic assumption is that every SoC will have some = physical >>> memory aligned to a 256mb boundary. >>=20 >> I'm assuming this only for ARM systems supported by the GENERIC >> kernel. >>=20 >> Ss far as I can tell, the 256mb boundary assumption works for >> everything currently in SVN. But the code above does allow you >> to custom-build a kernel for a system that doesn't satisfy that; >> you just won't be able to run the GENERIC kernel there. >>=20 >> Eventually, it seems we might pull this information out of the >> FDT, but I'm not yet ready to tackle FDT parsing in locore.S. ;-) >>=20 >> Of course, I'm not certain that it will matter when we're done. >> If we only need PHYSADDR to set up the MMU paging, >> then we just need to round the _start address down to >> the next page boundary, don't we? >>=20 >>> E.G., there'll never be a SoC with >>> memory at 0xN1000000 that doesn't have memory at 0xN0000000. I'm = not >>> sure that's a safe assumption given things like the rpi where the = gpu >>> carves off some memory for itself and gives the rest to the arm. It >>> works with the way rpi carves up the ram, but I could see similar >>> designs that wouldn't work. >>>=20 >>>>=20 >>>> * We redefine KERNPHYSADDR to be an *offset* >>>> against _kpa_base. Then we could negotiate a single >>>> offset (64k?) that works well on many platforms and use >>>> that for the GENERIC kernel. Boot loaders would be >>>> responsible for loading the kernel at an address that >>>> preserves the KPA_OFFSET. The KPA_OFFSET would >>>> be used in the ELF headers. >>>>=20 >>>> Then there are routine code transformations to use _kpa_base >>>> instead of the compile-time symbol and to use >>>> _kpa_base + KERNPHYSADDR instead of KERNPHYSADDR. >>>>=20 >>>> Does this sound reasonable as a starting point? >>>>=20 >>>=20 >>> There are even more assumptions here about what would work in every >>> case. Given the basic sequence of boot2->u-boot->ubldr->kernel, = every >>> one of those components has to load the next component at the = physical >>> address it's linked for, and that has to not overlap the addresses = being >>> used by the thing doing the loading. The MMU is off during all of = this >>> so we can't just map our way out of any conflicts. >>=20 >> I've given up entirely on the first two of these being generic. >>=20 >> I think we have a shot at making the kernel itself generic, >> and maybe ubldr could be made truly PIC, but the earlier >> boot stages are always going to be highly board-specific. >>=20 >> So conflicts between the various pieces aren't really >> my primary worry at the moment. Since we'll have to >> customize the early boot pieces anyway, we can resolve >> those on a case-by-case basis. >>=20 >> The ELF load address vs. where physical memory is located >> seems the sticky point. Any ideas for getting around that? >> I feel like I have enough ideas to start chipping away at >> locore.S if I could just figure out a strategy for the ELF >> load address issue. >>=20 >> (Of course, I still don't understand why the test image I've >> been playing with seems able to load the same ubldr on >> both RPi and BBone and that ubldr seems to have no trouble >> loading a kernel into memory.) I finally figured this out. RPi echoes memory (so 0x80000000-0xA0000000 is another window on 0x00000000-0x20000000), so my BeagleBone boot bits linked for the 0x80000000-0x90000000 range actually did work on RPi. (Which is annoying; I was hoping the different memory ranges on these two boards would help me to catch memory layout problems.) > We may not have control over anything before ubldr. Not everything is > an eval board that you can easily build a custom u-boot for. =20 Yep. Full agreement here. > I'm not sure its safe to assume that (entry-pc & 0xfffff000) is the > beginning of the kernel; it's true now but need not be so. But that's > no big deal, we can tweak the linker script to give us the offset of = the > _start symbol so it'll work no matter what. Patches? ;-) > The more I ponder the fixed offset concept for a generic kernel the = more > it seems that it might be viable, providing that we require the use of > ubldr. Then we can make sure that ubldr is always linked at an offset > that doesn't overlap the kernel load offset. An offset number like = 1mb > or 4mb might work well for the kernel; it leaves lots of space for = ubldr > to be loaded down low in memory. I think putting the loader at a = lower > address than the kernel is required, because there's no upper bound on > the kernel size (I did a 27MB kernel last month -- it contains a huge > embedded md filesystem image). Thanks for pointing this out. I've been consistently putting ubldr in high memory but hadn't realized kernels varied that much in size. I'll rethink that. > This just pushes the real problem into ubldr, though, and that becomes > the non-generic component that has to be linked at a different = physical > address for each SoC. A kernel could still be loaded without ubldr, = but > it may need to be built in a non-generic way for some platforms. Among the many things I'd like to try: see if there's a way to build ubldr as a PIC raw binary (instead of an ELF image). That might help in a lot of case. Tim From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 18:19:16 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6B50A707; Sat, 2 Mar 2013 18:19:16 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 32CBDB2A; Sat, 2 Mar 2013 18:19:16 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r22IJFEx059708; Sat, 2 Mar 2013 18:19:15 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id b2rd8jhqkm5pzgztn6mwiud7vs; Sat, 02 Mar 2013 18:19:15 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: ARM EABI test image Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <1362247523.1195.183.camel@revolution.hippie.lan> Date: Sat, 2 Mar 2013 10:19:15 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <20130302172556.5b59e122@bender> <1362246830.1195.181.camel@revolution.hippie.lan> <1362247523.1195.183.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org, Ronald Klop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 18:19:16 -0000 On Mar 2, 2013, at 10:05 AM, Ian Lepore wrote: > On Sat, 2013-03-02 at 19:00 +0100, Ronald Klop wrote: >> On Sat, 02 Mar 2013 18:53:50 +0100, Ian Lepore wrote: >> >>> On Sat, 2013-03-02 at 18:21 +0100, Ronald Klop wrote: >>>> On Sat, 02 Mar 2013 05:25:56 +0100, Andrew Turner >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> I have built an updated ARM EABI test image for Raspberry Pi [1]. >>>>> >>>>> The only known issue is c++ exception handling is broken when >>>>> using in a dynamically linked executable. Static executables should >>>>> work with c++ exceptions. >>>>> >>>>> To test it you will have to extract it using unxz and dd it to an sd >>>>> card, for example, with a USB to SD adapter on /dev/da0: >>>>> $ unxz bsd-pi-eabi-r247609.img.xz >>>>> $ dd if=bsd-pi-eabi-r247609.img of=/dev/da0 >>>>> >>>>> If you don't have a Raspberry Pi but would like to try it on your >>>> board >>>>> you can add -DWITH_ARM_EABI to the make commands you use to build and >>>>> install world and the kernel. >>>> >>>> Is this also interesing on the older SHEEVAPLUG? >>>> If yes, I can test it somewhere next week. >>>> >>>> Ronald. >>> >>> As I understand it, the plan is that eventually everything is EABI, >>> including the older armv4/5 stuff, so that needs testing too. >>> >>> You know what I haven't stumbled across yet is a simple explanation of >>> why EABI is better then OABI. I tried to search for some info the other >>> day, but there are so many noise hits on the search I didn't find a >>> simple synopsis of differences or advantages. I wondered about that too, did some searching, and likewise came up with nothing informative. The only "big wins" I've seen quoted in the Linux community was an improvement in FP performance. >> Googling on 'eabi vs oabi' gives me this >> http://wiki.embeddedarm.com/wiki/EABI_vs_OABI. > > I saw that, but that's a linux-specific answer to a linux-specific > problem that freebsd never had: we use OABI without assuming hardware fp > and emulating it in the kernel via traps. I hope there's more advantage > to EABI than just that, since that part of it gets us nothing. I think the only real advantage for us is that EABI is the ARM-specified calling convention that will be supported by all new toolchains going forward. It's not so much that EABI brings us big wins but that OABI was already starting to become a liability. Tim From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 18:25:33 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 96A81937 for ; Sat, 2 Mar 2013 18:25:33 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id 49C93B6B for ; Sat, 2 Mar 2013 18:25:32 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UBr7k-000DUR-Ef; Sat, 02 Mar 2013 18:25:32 +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 r22IPTX1088808; Sat, 2 Mar 2013 11:25:29 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19kyyBcgRSnWP3WXJmPCqke Subject: Re: PHYSADDR From: Ian Lepore To: Tim Kientzle In-Reply-To: References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> <1362155632.1195.120.camel@revolution.hippie.lan> <5B622D1B-4EAE-4184-A194-DD14083A48B6@kientzle.com> <1362246634.1195.178.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sat, 02 Mar 2013 11:25:29 -0700 Message-ID: <1362248729.1195.189.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 18:25:33 -0000 On Sat, 2013-03-02 at 10:10 -0800, Tim Kientzle wrote: > On Mar 2, 2013, at 9:50 AM, Ian Lepore wrote: > [...] > > > We may not have control over anything before ubldr. Not everything is > > an eval board that you can easily build a custom u-boot for. > > Yep. Full agreement here. > > > > I'm not sure its safe to assume that (entry-pc & 0xfffff000) is the > > beginning of the kernel; it's true now but need not be so. But that's > > no big deal, we can tweak the linker script to give us the offset of the > > _start symbol so it'll work no matter what. > > Patches? ;-) > Forthcoming, if I could stop talking on irc and email long enough to finish them. :) I started playing with it yesterday enough to be sure it was doable. > > The more I ponder the fixed offset concept for a generic kernel the more > > it seems that it might be viable, providing that we require the use of > > ubldr. Then we can make sure that ubldr is always linked at an offset > > that doesn't overlap the kernel load offset. An offset number like 1mb > > or 4mb might work well for the kernel; it leaves lots of space for ubldr > > to be loaded down low in memory. I think putting the loader at a lower > > address than the kernel is required, because there's no upper bound on > > the kernel size (I did a 27MB kernel last month -- it contains a huge > > embedded md filesystem image). > > Thanks for pointing this out. I've been consistently putting ubldr > in high memory but hadn't realized kernels varied that much in > size. I'll rethink that. > > > This just pushes the real problem into ubldr, though, and that becomes > > the non-generic component that has to be linked at a different physical > > address for each SoC. A kernel could still be loaded without ubldr, but > > it may need to be built in a non-generic way for some platforms. > > Among the many things I'd like to try: see if there's a way to build > ubldr as a PIC raw binary (instead of an ELF image). That might > help in a lot of case. > I think the only way this works is to write a relocation-fixup trampoline for ubldr. I'm 15 years outdated on toolchain stuff, but I think the two ways this could go would be something like a small custom runtime loader and the bulk of ubldr is a .so file that it loads (they could be bound together in a multi-segment elf file I think), or we continue with the current -static link but do a partial link or prelink that leaves relocation info in the image so that some trampoline code could walk the reloc list patching up offsets into absolute addresses. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 21:05:34 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DFFE7858 for ; Sat, 2 Mar 2013 21:05:34 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 869FE256 for ; Sat, 2 Mar 2013 21:05:33 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r22L5XtI060397 for freebsd-arm@freebsd.org; Sat, 2 Mar 2013 21:05:33 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id vdqdmqphfafjv2ri7m5ixjp77s; for freebsd-arm@freebsd.org; Sat, 02 Mar 2013 21:05:33 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: multipart/signed; boundary="Apple-Mail=_C7E73846-5F7B-4D27-B3C6-E6592BD3BEBD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: About board-specific files.* Date: Sat, 2 Mar 2013 13:05:26 -0800 Message-Id: To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 21:05:34 -0000 --Apple-Mail=_C7E73846-5F7B-4D27-B3C6-E6592BD3BEBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Now that I think I understand some of the issues in building a GENERIC arm kernel, I'm starting to piece together a kernel that has both RPi and BBone bits that I can use as a testbed. Next Problem: A lot of the boards are using board-specific files.* to control what files get linked into the kernel. This seems like a real problem for a GENERIC kernel, so I propose merging them into sys/conf/files.arm. Here's how I'm doing it right now for my current experiments. If anyone has a better idea, I'm definitely interested. Basically, I'm using "device bcm2835" to represent all of the basic support for that particular SoC. (An SoC is, after all, just another piece of hardware.) Then the files marked "standard" in arm/bcm2835/files.bcm2835 move to files.arm as "optional bcm2835". With this approach, the GENERIC arm kernel will list the SoCs as devices: device bcm2835 device am335x device omap4 =85 etc =85 That will bring in the basic support for those SoCs (e.g., interrupt handler, gpio, clock management, etc). Additional drivers (SDHCI, UART, USB, etc) will be separate devices. I think this makes sense, but I'm open to other ideas. Tim --Apple-Mail=_C7E73846-5F7B-4D27-B3C6-E6592BD3BEBD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQEcBAEBAgAGBQJRMmmXAAoJEGMNyGo0rfFBRP4H/0yljEtP+/DSjXBRVA4Zeel7 mpedLt5ct+XzZuVyDaBcHkAVCzxJQy9JsmfoCv4FhYpnVxa9aXJ7db2n4bm/SyVN p2Tidsbvnsm9Cf0GaKQQV51rnKCvbuT4Qy3ZnJTmup4Z93OWJluh2zpE6EV6/vng 4VOhnOiwSeQbAql7nE0MIUZy2TNaWgxhcNMd7Ua7B3dpG7Jjxuiu2fMnpWtnaIfl /wYLBu7aad+3F5NE258P6TrAcmK/RJYYB5vgQP8joiFO3Na/6iDNOs0pMkGtUC/D qduy1NqOqL2eIu+Gn2LmcKC3uEv0d1Hw1Buf9mvbYRxJu5IJ8gDP+is8vSSOgqc= =oSfM -----END PGP SIGNATURE----- --Apple-Mail=_C7E73846-5F7B-4D27-B3C6-E6592BD3BEBD-- From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 21:14:09 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9D2D4BDC for ; Sat, 2 Mar 2013 21:14:09 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 10F89293 for ; Sat, 2 Mar 2013 21:14:08 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id er20so3972044lab.18 for ; Sat, 02 Mar 2013 13:14:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=fvxArvoJ0pDWzUAeUwSVFx1EwGw9gHWYL2sv0GTDyfI=; b=jlp5IOtVI9d2xFerYpTzCwXn7PrN8XRNfwVwSMhHAGruECLaixD016FnC+daDONe3t XIt7irn5AYMn6w9kwAVd/LCeZd4eZhjS66pxk57I0XwebZLBm9b27n7WnIOHKuiwxXa7 8ac44EXFwxvXGURmPPxJggnEdGAcLVK2iEREFuJFO2iaMo6NwqJd4un8xUpCPtM1shA9 kgDS2CROJdG8l9ROwFqn0IvUSnmzpb/V9sB5stlW444q4QALiMgKrkgyln3xPn+08q53 vYSGrxxn4Hgml4WOiD34DiehsVcSLbwJp3j+C7UycR8d6LhHyNEDU/AFVPVhPEcVQOWP zWrA== X-Received: by 10.152.46.17 with SMTP id r17mr13193869lam.47.1362258846629; Sat, 02 Mar 2013 13:14:06 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id tm10sm9034077lab.10.2013.03.02.13.14.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Mar 2013 13:14:05 -0800 (PST) Sender: Alexander Motin Message-ID: <51326B9A.4010500@FreeBSD.org> Date: Sat, 02 Mar 2013 23:14:02 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130125 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: PXA event timer Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 21:14:09 -0000 Hi. While testing in QEMU calloutng on ARM platforms not ported to new eventtimers, I've ported to them timer of PXA. I works reasonably in QEMU, but would be nice to check it on real hardware. If somebody have one, could you please try this patch on top of projects/calloutng branch sources: http://people.freebsd.org/~mav/pxa_eventtimer.patch This tool should help to test how good system works with different time intervals: http://people.freebsd.org/~mav/testsleep.c Thank you. -- Alexander Motin From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 21:53:25 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B6538296; Sat, 2 Mar 2013 21:53:25 +0000 (UTC) (envelope-from Daan@vitsch.nl) Received: from Prakkezator.VEHosting.nl (Prakkezator6.VEHosting.nl [IPv6:2001:1af8:2100:b020::142]) by mx1.freebsd.org (Postfix) with ESMTP id 39FA8396; Sat, 2 Mar 2013 21:53:24 +0000 (UTC) Received: from [192.168.45.11] (Alk01.VEHosting.nl [85.17.51.130]) (authenticated bits=0) by Prakkezator.VEHosting.nl (8.14.2/8.14.2) with ESMTP id r22LrKSd066765; Sat, 2 Mar 2013 22:53:20 +0100 (CET) (envelope-from Daan@vitsch.nl) From: Daan Vreeken Organization: Vitsch Electronics To: Ian Lepore Subject: Re: PHYSADDR Date: Sat, 2 Mar 2013 22:53:21 +0100 User-Agent: KMail/1.9.10 References: <1362155645-2157952719.da2bf251f6@bliksem.vehosting.nl> <1362155632.1195.120.camel@revolution.hippie.lan> In-Reply-To: <1362155632.1195.120.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201303022253.21210.Daan@vitsch.nl> x-ve-auth-version: mi-1.1.7 2011-02-21 - Copyright (c) 2008, 2011 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on Prakkezator.VEHosting.nl Cc: Tim Kientzle , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 21:53:25 -0000 Hi all, On Friday 01 March 2013 17:33:52 Ian Lepore wrote: > On Thu, 2013-02-28 at 09:44 -0800, Tim Kientzle wrote: > > On Feb 28, 2013, at 8:58 AM, Tim Kientzle wrote: > > > On Feb 28, 2013, at 8:20 AM, Ian Lepore wrote: > > >> On Wed, 2013-02-27 at 22:27 -0800, Tim Kientzle wrote: > > >>> Starting to look at what is needed for a Generic ARM kernel. > > >>> There's a lot here; I sincerely hope I'm not the only one=85 ;-) > > >>> > > >>> First up: Can we get rid of PHYSADDR? > > >> > > >> If you mean, can we get rid of it within the runtime kernel, I'd say > > >> yes, because we can use a global variable instead which is easily > > >> settable in the entry code. > > > > > > It doesn't seem to be used in the runtime kernel. As far as > > > I can see, it's purely a bootstrap concept. > > Well, it's used to set up the early-init page tables in locore.s then > again to set up the real page tables and related things in initarm() and > then I think it isn't used after that, so I should have said "within the > kernel init". The main point I was getting at is that I don't think we > need a compile-time constant of any sort related to the physical address > at which the kernel is loaded. We can get the physical address of the > entry point (_start) using pc-relative math, and we can get the linker > to give us a constant symbol which is the offset of the _start symbol > within the load image. So we can get the load address at runtime > without guessing what low-order bits to mask. I like this approach. We have a board on which the bootloader loads a small= =20 binary blob that's in front of the kernel together with the kernel, all in= =20 one go. This results in the kernel living at an offset of a number of pages= =20 from the start of RAM. This means that this : > > _kpa_base =3D pc & 0xF0000000; wouldn't work. Calculating the exact location of the start of the kernel im= age=20 would work on all boards and memory/loader configurations. Regards, =2D-=20 Daan Vreeken Vitsch Electronics http://Vitsch.nl/ http://VitschVPN.nl/ tel: +31-(0)40-7113051 KvK nr: 17174380 =2D- Machines en netwerken op afstand beheren? Vitsch VPN oplossing! Kijk voor meer informatie op: http://www.VitschVPN.nl/ From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 22:58:47 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B7F4066E for ; Sat, 2 Mar 2013 22:58:47 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 780477F7 for ; Sat, 2 Mar 2013 22:58:47 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r22Mwkod060897 for freebsd-arm@freebsd.org; Sat, 2 Mar 2013 22:58:46 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id w8pqdjbv2e2hmf73yf3ir35sis; for freebsd-arm@freebsd.org; Sat, 02 Mar 2013 22:58:46 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: multipart/signed; boundary="Apple-Mail=_A53DBB79-9DC6-4BF8-8B8F-BE333CF14EFA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Multiple MMU support broken for armv6. Date: Sat, 2 Mar 2013 14:58:44 -0800 Message-Id: <5BC0642C-0574-4579-9C4D-EFE49E1361B0@freebsd.org> To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 22:58:47 -0000 --Apple-Mail=_A53DBB79-9DC6-4BF8-8B8F-BE333CF14EFA Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Tried building an ARM kernel with two CPUs defined: cpu CPU_ARM1176 cpu CPU_CORTEXA and see a lot of build breakage in pmap-v6.c. It looks like this code doesn't correctly support the multiple-MMU case. Tim --Apple-Mail=_A53DBB79-9DC6-4BF8-8B8F-BE333CF14EFA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQEcBAEBAgAGBQJRMoQkAAoJEGMNyGo0rfFB+YsIAKPxxjsbRNboyQR0uQi5U/Gr BSRQzaK4JZY/dq06xjz0idMl/eDdNrD4AwYGl5dqqs32akGuwO6j2ZZS3QHByrKy SA+iFotWMalJS6ILmM3Vjk9K7ZfU1GaEAwBuoYeCLBdg68a6JSgRJmLywtHqg3NW Le25U3BGSSqaPDBaasAPVfp0QLXZaRQZWdru7nrhTU2yyH97o6Q/g30zqyNP8vzN gb/PaL0Dg3Q8Jh9Cb4htDi9+1bRwPcbA/XUepn6pSja4qsBi534ei8RPgBBgL3jk mTr0/9/qcO7brHtvT9qxNGCfZ6hNkCvQ/KacJy2VjWggoPAfbJ1mvl1fPC+elk8= =2Hy9 -----END PGP SIGNATURE----- --Apple-Mail=_A53DBB79-9DC6-4BF8-8B8F-BE333CF14EFA-- From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 23:10:23 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 404B5898 for ; Sat, 2 Mar 2013 23:10:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x235.google.com (mail-ia0-x235.google.com [IPv6:2607:f8b0:4001:c02::235]) by mx1.freebsd.org (Postfix) with ESMTP id F0721862 for ; Sat, 2 Mar 2013 23:10:22 +0000 (UTC) Received: by mail-ia0-f181.google.com with SMTP id w33so3771874iag.12 for ; Sat, 02 Mar 2013 15:10:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=eHiywVJzlWgZHUi2sHJ9Pnj/1ubOFNwJTRcmWK6lUdU=; b=icDgCPzEmjqmAY4gx24XrTLd6JW0Or5NagmHr9Rt9WO66N71AlKjI+r6Oju+DnrfWx 9OchwWKvYr/kELBOTjGiJqhP2KQ6Qa/4wtd65n+VvX9s2PW3y+6fgzBTk2BFNFenNMJK VhFJAMkEmG2PDqhblBqr1mnOaFCPc73XKzH1xeU8g6OL+eoQd+ZCtODHA65yVG4mGWr7 dUcc6dwz12qSLFb7jIAZp8D+7Npr2TKdcQt78vBeKi5Yr5dwRxW0Wdc3Pl9JW8dkEbD/ Hu/9bYzbGrHPFgPRrPQv/vBgCWQKROY0r04Y+uDiJ7tfuMo49d6bjjSSn7EzbaBpJgiZ 6gyw== X-Received: by 10.42.92.72 with SMTP id s8mr17484629icm.0.1362265821055; Sat, 02 Mar 2013 15:10:21 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id wx2sm4474190igb.4.2013.03.02.15.10.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Mar 2013 15:10:20 -0800 (PST) Sender: Warner Losh Subject: Re: ARM EABI test image Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: Date: Sat, 2 Mar 2013 16:10:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A610A50-59AD-4236-9955-29E608857820@bsdimp.com> References: <20130302172556.5b59e122@bender> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlaNz5OCIfk+5vP4gXo5xa8KvJD4PbUpUUHqoKtoBitSdYj8wwfUmbOdxa8rJDwmolhQ/CR Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 23:10:23 -0000 On Mar 2, 2013, at 10:45 AM, Tim Kientzle wrote: >=20 > On Mar 1, 2013, at 8:25 PM, Andrew Turner wrote: >=20 >> Hello, >>=20 >> I have built an updated ARM EABI test image for Raspberry Pi [1]. >>=20 >> The only known issue is c++ exception handling is broken when >> using in a dynamically linked executable. Static executables should >> work with c++ exceptions. >>=20 >> To test it you will have to extract it using unxz and dd it to an sd >> card, for example, with a USB to SD adapter on /dev/da0: >> $ unxz bsd-pi-eabi-r247609.img.xz >> $ dd if=3Dbsd-pi-eabi-r247609.img of=3D/dev/da0 >>=20 >> If you don't have a Raspberry Pi but would like to try it on your = board >> you can add -DWITH_ARM_EABI to the make commands you use to build and >> install world and the kernel. >=20 > For people working with my build scripts, it should suffice > to add this to your config.sh: >=20 > FREEBSD_WORLD_EXTRA_ARGS=3D"-DWITH_ARM_EABI" > FREEBSD_KERNEL_EXTRA_ARGS=3D"-DWITH_ARM_EABI" >=20 > I'm starting some builds right now=85. We've gotta get that fixed :( Warner From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 23:15:12 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 517E4C27 for ; Sat, 2 Mar 2013 23:15:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 222518B3 for ; Sat, 2 Mar 2013 23:15:12 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id c13so4992423ieb.9 for ; Sat, 02 Mar 2013 15:15:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=RE2/nGtqrUyvRRBT3mb+5rZT3961THfJpkch4R5zqk0=; b=bVw02NUURFNKE0PJhNG72TlqZsi/2HXAmopRgDuyjxPOPEC+QVVS/N2XyhTmgHmytO WOcGzR9QLa1sDZqHzxWOa9NYqb0PqMan7P6pFq712/5vv6/dgxdFsTojd1VS7uEvw5Ap rI+njchynw+iowpsVtITYvVf3PLOMK8tne3wh01i+MGNW1Oe5l1jOjuRT1fbSO7vLni2 RgO6Uqoe1qRzW6tjzeVNyGfYGTuWBKbqEzqVF7NKjQ0IH0nMRF67kzxsT5IB/l/tZxjS EVe2ff5rrp5NvNJYcU8m4XNe9mnHZCrwWG7S8nnbKUljpGrCAqgy6hkrLLyI4UroXEUU RNqw== X-Received: by 10.43.125.199 with SMTP id gt7mr17324575icc.48.1362266111487; Sat, 02 Mar 2013 15:15:11 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id l2sm3963608igb.1.2013.03.02.15.15.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Mar 2013 15:15:10 -0800 (PST) Sender: Warner Losh Subject: Re: PHYSADDR Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1362246634.1195.178.camel@revolution.hippie.lan> Date: Sat, 2 Mar 2013 16:15:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <07E4A3AF-DC56-4BD6-B564-3370C9716329@bsdimp.com> References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> <1362155632.1195.120.camel@revolution.hippie.lan> <5B622D1B-4EAE-4184-A194-DD14083A48B6@kientzle.com> <1362246634.1195.178.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQk8WBCJSX2pyip1Rx02gSOojzSU0JURNDyxQHsBuCFPLsZu5VL1afHQpfcy8PnBjNj2C0SF Cc: Tim Kientzle , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 23:15:12 -0000 On Mar 2, 2013, at 10:50 AM, Ian Lepore wrote: > I'm not sure its safe to assume that (entry-pc & 0xfffff000) is the > beginning of the kernel; it's true now but need not be so. But that's > no big deal, we can tweak the linker script to give us the offset of = the > _start symbol so it'll work no matter what. We have total control over this, since we control the linker script that = puts locore.S at the front. > The more I ponder the fixed offset concept for a generic kernel the = more > it seems that it might be viable, providing that we require the use of > ubldr. Then we can make sure that ubldr is always linked at an offset > that doesn't overlap the kernel load offset. An offset number like = 1mb > or 4mb might work well for the kernel; it leaves lots of space for = ubldr > to be loaded down low in memory. I think putting the loader at a = lower > address than the kernel is required, because there's no upper bound on > the kernel size (I did a 27MB kernel last month -- it contains a huge > embedded md filesystem image). >=20 > This just pushes the real problem into ubldr, though, and that becomes > the non-generic component that has to be linked at a different = physical > address for each SoC. A kernel could still be loaded without ubldr, = but > it may need to be built in a non-generic way for some platforms. Why not compile ubldr -pic? Then it wouldn't matter where we get loaded, = we'll work... > So if we declare that this scheme is for generic kernels loaded by a > loader (ubldr or other) that is aware of the generic kernel scheme, > there's no need for the physical address fields in the elf headers to = be > interpretted as a real physical address that would work for a standard > elf loader. You can build kernels that work with a standard elf = loader, > but the generic kernel is not such a thing. =20 Correct. BTW, what do latter-day universal-boot linux kernels do? > In that case, the physical address and entry address fields in the > headers are all offsets. If physical ram on a given chip starts at > zero, then the headers would accidentally be right for a standard elf > loader. Otherwise the generic-aware loader is responsible for filling > in some high-order bits when interpretting the headers. >=20 > The PHYSADDR symbol (and its several name variations) at build time = now > becomes zero for a generic kernel or non-zero to generate a = SoC-specific > kernel that can be loaded by a standard elf loader. The symbol = doesn't > exist at all in the compilation, it's used only by the build system = and > is passed as a parameter to the linker. >=20 > There's another problem constant we haven't talked about yet: > STARTUP_PAGETABLE_ADDR, used by locore to build the early page tables. > It's the absolute physical address of an area of memory that doesn't > have any other important data in it, and won't get overwritten by > something before initarm() builds the real page tables. I think most > SoCs now put it way up high in memory "safely out of the way", but = that > won't work generically. We need 16K aligned to a 16K boundary, and > maybe it would work to use the area immediately preceeding the start = of > the kernel. We could require the kernel to be linked on a 16k = boundary > so that we can just blindly subtract 16K from the starting physaddr we > calculate; nice and easy. Maybe have ubldr responsible for this? And if you aren't booting with = ubldr using a custom loader, you're already into the land of unique = kernel build anyway, and can wire it there... Warner= From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 23:16:26 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 22DD3D6D for ; Sat, 2 Mar 2013 23:16:26 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by mx1.freebsd.org (Postfix) with ESMTP id E76578D5 for ; Sat, 2 Mar 2013 23:16:25 +0000 (UTC) Received: by mail-ia0-f171.google.com with SMTP id z13so3764195iaz.16 for ; Sat, 02 Mar 2013 15:16:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=sAlPPdsk+bQ36Eun7Y0gXzVuEqBaIyV+hxfIBuKnUjk=; b=dqLzynhOJiuyH5UXUhBUOcNPfejMFjexM/lXH6CSrMqqB4ivGnCXO8i4POGpJkezSp 16Umobjz9UnU2oIbkXH8p/2tKcyz6t1Jm332+cqkrhIZRrRx0ITyd5iAW7BdQOfD9WlP dDvUjOJWIVGPIKR1+wAMYvcQ/svC8H5g/sFPLSWqQKfmBvnWIru1sRQXyyFX4XaC2HSy aF5HQX/+B7pUL/+Dh/Fbz5ck2f0Sg6c0JjdRmp1DaEq7Z2bkvRKB7NgHLqfIU6nE8YO9 7xMnzGTsNPS8ndgSiWV4FoSq+68Jan4S2aF6K+uanCWuYbZb1PiyQZmwqGViblmbNv/1 4H4w== X-Received: by 10.42.145.137 with SMTP id f9mr17635919icv.52.1362266185417; Sat, 02 Mar 2013 15:16:25 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id wo8sm4485378igb.6.2013.03.02.15.16.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Mar 2013 15:16:24 -0800 (PST) Sender: Warner Losh Subject: Re: ARM EABI test image Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1362246830.1195.181.camel@revolution.hippie.lan> Date: Sat, 2 Mar 2013 16:16:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130302172556.5b59e122@bender> <1362246830.1195.181.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnUGNHu91CzYPjqS+KdrvVpO716TtRZYwHAHf+tBt0ZgtAryD8Sfps8ZNkO7bMIObV/Kn2i Cc: freebsd-arm@FreeBSD.org, Ronald Klop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 23:16:26 -0000 On Mar 2, 2013, at 10:53 AM, Ian Lepore wrote: > On Sat, 2013-03-02 at 18:21 +0100, Ronald Klop wrote: >> On Sat, 02 Mar 2013 05:25:56 +0100, Andrew Turner = =20 >> wrote: >>=20 >>> Hello, >>>=20 >>> I have built an updated ARM EABI test image for Raspberry Pi [1]. >>>=20 >>> The only known issue is c++ exception handling is broken when >>> using in a dynamically linked executable. Static executables should >>> work with c++ exceptions. >>>=20 >>> To test it you will have to extract it using unxz and dd it to an sd >>> card, for example, with a USB to SD adapter on /dev/da0: >>> $ unxz bsd-pi-eabi-r247609.img.xz >>> $ dd if=3Dbsd-pi-eabi-r247609.img of=3D/dev/da0 >>>=20 >>> If you don't have a Raspberry Pi but would like to try it on your = board >>> you can add -DWITH_ARM_EABI to the make commands you use to build = and >>> install world and the kernel. >>=20 >> Is this also interesing on the older SHEEVAPLUG? >> If yes, I can test it somewhere next week. >>=20 >> Ronald. >=20 > As I understand it, the plan is that eventually everything is EABI, > including the older armv4/5 stuff, so that needs testing too. >=20 > You know what I haven't stumbled across yet is a simple explanation of > why EABI is better then OABI. I tried to search for some info the = other > day, but there are so many noise hits on the search I didn't find a > simple synopsis of differences or advantages. Alignment of structures is more like x86. This makes all the weird hacks = we have in the tree to support the old ABI obsolete, and makes all the = broken ones that we don't know about fixed. I'm sure there's a bunch more, but that's the main reason I want it :) Warner= From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 23:17:23 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9D903DA9 for ; Sat, 2 Mar 2013 23:17:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x230.google.com (mail-ia0-x230.google.com [IPv6:2607:f8b0:4001:c02::230]) by mx1.freebsd.org (Postfix) with ESMTP id 508578DD for ; Sat, 2 Mar 2013 23:17:23 +0000 (UTC) Received: by mail-ia0-f176.google.com with SMTP id i18so3672724iac.7 for ; Sat, 02 Mar 2013 15:17:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=gIpVL7zcvtbIPI0p7t0Q+KOzGD2/LyUtu6Jnr4uAMj8=; b=asIVJKqetPB2QWrl/RGoWZJAAiXFo8ijm2zGFQHX1abpddM15whgJk6rhZSN2LFesn HQTpg0WNcK55ZvqYPycB9ay3QYIoNncZvkVyVK4vEiGwf8LogyRYu1zUOIAYbWBgXA8S y+7+2sQavrLWckQ3LgaI56R3XQJOcs3xZ9LyeItBeZOrhlp+oLjY4Q3gq+0seeSDB+6J VwU0CwYzWgjpdvL6dI4ZZwPRxlTE2MhHYEeNny+2poVq2uWK63FG7Z6ozH18JYki29vo bz0NL0PsmDemQ/Nc2x7oTbJ4wbgPXFvMhLhHPmNJoYt2Xri5ICN/18c032r87C5YBXLs YZbw== X-Received: by 10.43.9.137 with SMTP id ow9mr17462679icb.32.1362266242800; Sat, 02 Mar 2013 15:17:22 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id wo8sm4485378igb.6.2013.03.02.15.17.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Mar 2013 15:17:21 -0800 (PST) Sender: Warner Losh Subject: Re: ARM EABI test image Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 2 Mar 2013 16:17:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130302172556.5b59e122@bender> <1362246830.1195.181.camel@revolution.hippie.lan> <1362247523.1195.183.camel@revolution.hippie.lan> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmiEnbWGrqUplK73wyYRsmHTw6FXJ/y29YcDYv1rIwaWk3UT2UZydfLZWFDxNEyIkrPWloq Cc: freebsd-arm@freebsd.org, Ian Lepore , Ronald Klop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 23:17:23 -0000 On Mar 2, 2013, at 11:19 AM, Tim Kientzle wrote: >=20 > On Mar 2, 2013, at 10:05 AM, Ian Lepore wrote: >=20 >> On Sat, 2013-03-02 at 19:00 +0100, Ronald Klop wrote: >>> On Sat, 02 Mar 2013 18:53:50 +0100, Ian Lepore = wrote: >>>=20 >>>> On Sat, 2013-03-02 at 18:21 +0100, Ronald Klop wrote: >>>>> On Sat, 02 Mar 2013 05:25:56 +0100, Andrew Turner = >>>>> wrote: >>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> I have built an updated ARM EABI test image for Raspberry Pi [1]. >>>>>>=20 >>>>>> The only known issue is c++ exception handling is broken when >>>>>> using in a dynamically linked executable. Static executables = should >>>>>> work with c++ exceptions. >>>>>>=20 >>>>>> To test it you will have to extract it using unxz and dd it to an = sd >>>>>> card, for example, with a USB to SD adapter on /dev/da0: >>>>>> $ unxz bsd-pi-eabi-r247609.img.xz >>>>>> $ dd if=3Dbsd-pi-eabi-r247609.img of=3D/dev/da0 >>>>>>=20 >>>>>> If you don't have a Raspberry Pi but would like to try it on your = =20 >>>>> board >>>>>> you can add -DWITH_ARM_EABI to the make commands you use to build = and >>>>>> install world and the kernel. >>>>>=20 >>>>> Is this also interesing on the older SHEEVAPLUG? >>>>> If yes, I can test it somewhere next week. >>>>>=20 >>>>> Ronald. >>>>=20 >>>> As I understand it, the plan is that eventually everything is EABI, >>>> including the older armv4/5 stuff, so that needs testing too. >>>>=20 >>>> You know what I haven't stumbled across yet is a simple explanation = of >>>> why EABI is better then OABI. I tried to search for some info the = other >>>> day, but there are so many noise hits on the search I didn't find a >>>> simple synopsis of differences or advantages. >=20 > I wondered about that too, did some searching, and likewise > came up with nothing informative. The only "big wins" I've > seen quoted in the Linux community was an improvement > in FP performance. >=20 >>> Googling on 'eabi vs oabi' gives me this =20 >>> http://wiki.embeddedarm.com/wiki/EABI_vs_OABI. >>=20 >> I saw that, but that's a linux-specific answer to a linux-specific >> problem that freebsd never had: we use OABI without assuming hardware = fp >> and emulating it in the kernel via traps. I hope there's more = advantage >> to EABI than just that, since that part of it gets us nothing. >=20 > I think the only real advantage for us is that EABI is the > ARM-specified calling convention that will be supported > by all new toolchains going forward. >=20 > It's not so much that EABI brings us big wins but that > OABI was already starting to become a liability. Part of the ABI is the alignment rules for structures is saner, which is = also a big win. Warner= From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 23:20:57 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DCBADDFF for ; Sat, 2 Mar 2013 23:20:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by mx1.freebsd.org (Postfix) with ESMTP id 96E748F4 for ; Sat, 2 Mar 2013 23:20:57 +0000 (UTC) Received: by mail-ia0-f182.google.com with SMTP id w21so1806779iac.27 for ; Sat, 02 Mar 2013 15:20:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=R3L3KZCDLLkmIUetmWxNUkCDR5mxQuAUbrSJVuFrc0E=; b=PMW4X2qYdKNkaSpuH9ENJq+/XWog6whJ0tOCzHncq11be4aK4RMHN7edCv2SoHru6F HBdBe2sYVU/l91agNS6gbB9sBzISalO8Tto3Tc6KfZGGrS11/XtW155gyaThh4BNs7/V fbb+nh90B/IXUFC2lT63G2i2iriGu6h9XocqMTL5siXK+qHOTjoOyFZNjFzRAoEAts/O QB2/lYV1sPOwNbDNNFqTp9wKN9IB0mhGD01Fek4nQsuHsLQwtoHv872koJXYVwQkEimJ 5S8dVm1/VlUE9gb1oIO3oMyLJ2QPfYEtO12SUrm0/KwG4jC1K5SAKYwr1cUHK68GqQHh /g4Q== X-Received: by 10.42.126.133 with SMTP id e5mr17469452ics.17.1362266456949; Sat, 02 Mar 2013 15:20:56 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ua6sm3990671igb.0.2013.03.02.15.20.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Mar 2013 15:20:56 -0800 (PST) Sender: Warner Losh Subject: Re: About board-specific files.* Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: Date: Sat, 2 Mar 2013 16:20:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <58FF3A9F-2782-429F-BE82-27728E8D209D@bsdimp.com> References: To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQm+j9bkC7jQQa7XP5s+MG2UW2MVkYd4c7D6sig657xr25ienKs9lKCgPXFbyFuhg+v9gdFa Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Mar 2013 23:20:57 -0000 On Mar 2, 2013, at 2:05 PM, Tim Kientzle wrote: > Now that I think I understand some of the issues in building > a GENERIC arm kernel, I'm starting to piece together > a kernel that has both RPi and BBone bits that I can > use as a testbed. >=20 > Next Problem: A lot of the boards are using > board-specific files.* to control what files get > linked into the kernel. >=20 > This seems like a real problem for a GENERIC kernel, > so I propose merging them into sys/conf/files.arm. >=20 > Here's how I'm doing it right now for my current > experiments. If anyone has a better idea, I'm > definitely interested. >=20 > Basically, I'm using "device bcm2835" to represent > all of the basic support for that particular SoC. > (An SoC is, after all, just another piece of hardware.) >=20 > Then the files marked "standard" in > arm/bcm2835/files.bcm2835 move to > files.arm as "optional bcm2835". >=20 > With this approach, the GENERIC arm kernel will > list the SoCs as devices: >=20 > device bcm2835 > device am335x > device omap4 > =85 etc =85 >=20 > That will bring in the basic support for those SoCs > (e.g., interrupt handler, gpio, clock management, etc). > Additional drivers (SDHCI, UART, USB, etc) will > be separate devices. >=20 > I think this makes sense, but I'm open to other ideas. I think this is perfect. It is what atmel uses to bring in different = atmel things. I don't think there are any atmel files specified as std = any more, and if there are they could transition to this. I know this = isn't an issue for a GENERIC for armv6, since there is not way an armv4 = and an armv6 kernel could be built today... Warner=