From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 01:29:28 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F50816A403; Sun, 12 Nov 2006 01:29:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3047043D53; Sun, 12 Nov 2006 01:29:28 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC1TRtn087391; Sat, 11 Nov 2006 20:29:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC1TRoI065805; Sat, 11 Nov 2006 20:29:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5335373068; Sat, 11 Nov 2006 20:29:27 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061112012927.5335373068@freebsd-current.sentex.ca> Date: Sat, 11 Nov 2006 20:29:27 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 01:29:28 -0000 TB --- 2006-11-12 01:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-12 01:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2006-11-12 01:00:00 - cleaning the object tree TB --- 2006-11-12 01:00:20 - checking out the source tree TB --- 2006-11-12 01:00:20 - cd /tinderbox/HEAD/arm/arm TB --- 2006-11-12 01:00:20 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-12 01:11:44 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-12 01:11:44 - cd /src TB --- 2006-11-12 01:11:44 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 12 01:11:45 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_getident.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_hash.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_kind.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_memory.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_next.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_rand.c /src/lib/libelf/elf_rand.c: In function `elf_rand': /src/lib/libelf/elf_rand.c:47: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-12 01:29:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-12 01:29:27 - ERROR: failed to build world TB --- 2006-11-12 01:29:27 - tinderbox aborted TB --- 0.21 user 0.61 system 1766.83 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 06:44:42 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2ED516A583; Sun, 12 Nov 2006 06:44:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5793743D46; Sun, 12 Nov 2006 06:44:42 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kAC6if11073349; Sun, 12 Nov 2006 01:44:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC6ifAT073432; Sun, 12 Nov 2006 01:44:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 28C6473068; Sun, 12 Nov 2006 01:44:41 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061112064441.28C6473068@freebsd-current.sentex.ca> Date: Sun, 12 Nov 2006 01:44:40 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 06:44:42 -0000 TB --- 2006-11-12 06:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-12 06:15:00 - starting HEAD tinderbox run for arm/arm TB --- 2006-11-12 06:15:00 - cleaning the object tree TB --- 2006-11-12 06:15:24 - checking out the source tree TB --- 2006-11-12 06:15:24 - cd /tinderbox/HEAD/arm/arm TB --- 2006-11-12 06:15:24 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-12 06:26:53 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-12 06:26:53 - cd /src TB --- 2006-11-12 06:26:53 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 12 06:26:54 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_getident.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_hash.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_kind.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_memory.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_next.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_rand.c /src/lib/libelf/elf_rand.c: In function `elf_rand': /src/lib/libelf/elf_rand.c:47: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-12 06:44:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-12 06:44:40 - ERROR: failed to build world TB --- 2006-11-12 06:44:40 - tinderbox aborted TB --- 0.16 user 0.65 system 1779.74 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 13:39:51 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96A0A16A417; Sun, 12 Nov 2006 13:39:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4ED3B43DD7; Sun, 12 Nov 2006 13:39:30 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kACDdU8P055959; Sun, 12 Nov 2006 08:39:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id kACDdT5l073883; Sun, 12 Nov 2006 08:39:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9194773068; Sun, 12 Nov 2006 08:39:29 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061112133929.9194773068@freebsd-current.sentex.ca> Date: Sun, 12 Nov 2006 08:39:29 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 13:39:51 -0000 TB --- 2006-11-12 13:10:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-12 13:10:01 - starting HEAD tinderbox run for arm/arm TB --- 2006-11-12 13:10:01 - cleaning the object tree TB --- 2006-11-12 13:10:23 - checking out the source tree TB --- 2006-11-12 13:10:23 - cd /tinderbox/HEAD/arm/arm TB --- 2006-11-12 13:10:23 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-12 13:21:53 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-12 13:21:53 - cd /src TB --- 2006-11-12 13:21:53 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 12 13:21:55 UTC 2006 >>> 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 [...] cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_getident.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_hash.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_kind.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_memory.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_next.c cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_rand.c /src/lib/libelf/elf_rand.c: In function `elf_rand': /src/lib/libelf/elf_rand.c:47: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-12 13:39:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-12 13:39:29 - ERROR: failed to build world TB --- 2006-11-12 13:39:29 - tinderbox aborted TB --- 0.23 user 0.60 system 1768.23 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 14:00:46 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14B0F16A4A7; Sun, 12 Nov 2006 14:00:46 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE17643DB3; Sun, 12 Nov 2006 14:00:09 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 967AC5FA5; Sun, 12 Nov 2006 17:00:06 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 731345EFE; Sun, 12 Nov 2006 17:00:06 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACE0A34049664; Sun, 12 Nov 2006 17:00:10 +0300 (MSK) (envelope-from ru) Date: Sun, 12 Nov 2006 17:00:10 +0300 From: Ruslan Ermilov To: FreeBSD Tinderbox Message-ID: <20061112140010.GA47660@rambler-co.ru> References: <20061112133929.9194773068@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: <20061112133929.9194773068@freebsd-current.sentex.ca> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 14:00:46 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 08:39:29AM -0500, FreeBSD Tinderbox wrote: > >>> stage 4.2: building libraries > [...] > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_H= OOKS=3D1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-para= meter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-typ= e -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-param= eter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/= lib/libelf/elf_getident.c > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_H= OOKS=3D1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-para= meter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-typ= e -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-param= eter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/= lib/libelf/elf_hash.c > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_H= OOKS=3D1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-para= meter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-typ= e -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-param= eter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/= lib/libelf/elf_kind.c > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_H= OOKS=3D1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-para= meter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-typ= e -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-param= eter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/= lib/libelf/elf_memory.c > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_H= OOKS=3D1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-para= meter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-typ= e -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-param= eter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/= lib/libelf/elf_next.c > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_H= OOKS=3D1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-para= meter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-typ= e -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-param= eter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/= lib/libelf/elf_rand.c > /src/lib/libelf/elf_rand.c: In function `elf_rand': > /src/lib/libelf/elf_rand.c:47: warning: cast increases required alignment= of target type > *** Error code 1 >=20 > Stop in /src/lib/libelf. > *** Error code 1 >=20 This looks like a GCC bug to me. The following code snippet, when compiled on FreeBSD/arm, causes a -Wcast-align warning which doesn't look right: %%% $ cat a.c struct foo { char x; }; struct foo * bubu(char *s) { return (struct foo *)s; } $ cc -c -Wcast-align a.c a.c: In function `bubu': a.c:9: warning: cast increases required alignment of target type %%% (None of other supported architecutes see the issue here.) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFVyjqqRfpzJluFF4RAp0yAKCF6pdQIMBN4yr4m2Q/OgScVCDwVQCgllwq n83kSLL032PE6a1jzm3VgwQ= =iePk -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 14:27:25 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 190B716A403; Sun, 12 Nov 2006 14:27:25 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from viefep16-int.chello.at (viefep15-int.chello.at [213.46.255.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A2AC43D7B; Sun, 12 Nov 2006 14:27:13 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from wombat.fafoe.narf.at ([213.47.85.26]) by viefep16-int.chello.at (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with ESMTP id <20061112142711.UUIZ7276.viefep16-int.chello.at@wombat.fafoe.narf.at>; Sun, 12 Nov 2006 15:27:11 +0100 Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id 18FD8BC87; Sun, 12 Nov 2006 15:27:11 +0100 (CET) Date: Sun, 12 Nov 2006 15:27:10 +0100 From: Stefan Farfeleder To: Ruslan Ermilov Message-ID: <20061112142710.GE91556@wombat.fafoe.narf.at> Mail-Followup-To: Ruslan Ermilov , FreeBSD Tinderbox , arm@freebsd.org, current@freebsd.org References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112140010.GA47660@rambler-co.ru> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: arm@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 14:27:25 -0000 On Sun, Nov 12, 2006 at 05:00:10PM +0300, Ruslan Ermilov wrote: > On Sun, Nov 12, 2006 at 08:39:29AM -0500, FreeBSD Tinderbox wrote: > > >>> stage 4.2: building libraries > > [...] > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_getident.c > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_hash.c > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_kind.c > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_memory.c > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_next.c > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_rand.c > > /src/lib/libelf/elf_rand.c: In function `elf_rand': > > /src/lib/libelf/elf_rand.c:47: warning: cast increases required alignment of target type > > *** Error code 1 > > > > Stop in /src/lib/libelf. > > *** Error code 1 > > > This looks like a GCC bug to me. The following code snippet, > when compiled on FreeBSD/arm, causes a -Wcast-align warning > which doesn't look right: > > %%% > $ cat a.c > struct foo { > char x; > }; > > struct foo * > bubu(char *s) > { > > return (struct foo *)s; > } > $ cc -c -Wcast-align a.c > a.c: In function `bubu': > a.c:9: warning: cast increases required alignment of target type > %%% > > (None of other supported architecutes see the issue here.) What is sizeof(struct foo)? If it's > 1 it makes sense. Stefan From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 14:43:12 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2299116A4EB; Sun, 12 Nov 2006 14:43:12 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E43843D67; Sun, 12 Nov 2006 14:43:09 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (host155-42.pool8174.interbusiness.it [81.74.42.155] (may be forged)) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-2) with ESMTP id kACEgaQF032664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 12 Nov 2006 16:42:45 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id kACEgVcj002729; Sun, 12 Nov 2006 15:42:31 +0100 (CET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id kACEgUMi002728; Sun, 12 Nov 2006 15:42:30 +0100 (CET) (envelope-from keramida@freebsd.org) Date: Sun, 12 Nov 2006 15:42:30 +0100 From: Giorgos Keramidas To: Ruslan Ermilov , arm@freebsd.org, current@freebsd.org Message-ID: <20061112144230.GC2331@kobe.laptop> References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112140010.GA47660@rambler-co.ru> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.463, required 5, autolearn=not spam, AWL 0.00, BAYES_00 -2.60, FORGED_RCVD_HELO 0.14, UNPARSEABLE_RELAY 0.00) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 14:43:12 -0000 On 2006-11-12 17:00, Ruslan Ermilov wrote: > > /src/lib/libelf/elf_rand.c: In function `elf_rand': > > /src/lib/libelf/elf_rand.c:47: warning: cast increases required alignment of target type > > *** Error code 1 > > > > Stop in /src/lib/libelf. > > *** Error code 1 > > This looks like a GCC bug to me. The following code snippet, > when compiled on FreeBSD/arm, causes a -Wcast-align warning > which doesn't look right: > > %%% > $ cat a.c > struct foo { > char x; > }; > > struct foo * > bubu(char *s) > { > > return (struct foo *)s; > } > $ cc -c -Wcast-align a.c > a.c: In function `bubu': > a.c:9: warning: cast increases required alignment of target type > %%% > > (None of other supported architecutes see the issue here.) You can't cast any random (char *) pointer to a pointer of a type which is (potentially) larger than 1 byte. It's the same sort of warning you will get if you try to: char ch[] = "\x00\x00\x00\x00"; char *p = &(ch[0]); unsigned long *lptr = (unsigned long *)p; You cannot guarantee that `ch' is stored in an address that is properly aligned for (unsigned long), and this is what GCC warns about here. On 2006-11-12 15:27, Stefan Farfeleder wrote: > What is sizeof(struct foo)? If it's > 1 it makes sense. Exactly :) From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 14:46:19 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C68016A403; Sun, 12 Nov 2006 14:46:19 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F40643D7E; Sun, 12 Nov 2006 14:46:16 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 4D7155F37; Sun, 12 Nov 2006 17:46:15 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 289B95F35; Sun, 12 Nov 2006 17:46:15 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACEkI9M050075; Sun, 12 Nov 2006 17:46:18 +0300 (MSK) (envelope-from ru) Date: Sun, 12 Nov 2006 17:46:18 +0300 From: Ruslan Ermilov To: FreeBSD Tinderbox , arm@freebsd.org, current@freebsd.org Message-ID: <20061112144618.GB49703@rambler-co.ru> References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IiVenqGWf+H9Y6IX" Content-Disposition: inline In-Reply-To: <20061112142710.GE91556@wombat.fafoe.narf.at> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 14:46:19 -0000 --IiVenqGWf+H9Y6IX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 03:27:10PM +0100, Stefan Farfeleder wrote: > On Sun, Nov 12, 2006 at 05:00:10PM +0300, Ruslan Ermilov wrote: > > On Sun, Nov 12, 2006 at 08:39:29AM -0500, FreeBSD Tinderbox wrote: > > > >>> stage 4.2: building libraries > > > [...] > > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TE= ST_HOOKS=3D1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-= parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn= -type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-p= arameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /= src/lib/libelf/elf_getident.c > > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TE= ST_HOOKS=3D1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-= parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn= -type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-p= arameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /= src/lib/libelf/elf_hash.c > > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TE= ST_HOOKS=3D1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-= parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn= -type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-p= arameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /= src/lib/libelf/elf_kind.c > > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TE= ST_HOOKS=3D1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-= parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn= -type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-p= arameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /= src/lib/libelf/elf_memory.c > > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TE= ST_HOOKS=3D1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-= parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn= -type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-p= arameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /= src/lib/libelf/elf_next.c > > > cc -O2 -pipe -I/obj/arm/src/lib/libelf -I/src/lib/libelf -DLIBELF_TE= ST_HOOKS=3D1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-= parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn= -type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-p= arameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /= src/lib/libelf/elf_rand.c > > > /src/lib/libelf/elf_rand.c: In function `elf_rand': > > > /src/lib/libelf/elf_rand.c:47: warning: cast increases required align= ment of target type > > > *** Error code 1 > > >=20 > > > Stop in /src/lib/libelf. > > > *** Error code 1 > > >=20 > > This looks like a GCC bug to me. The following code snippet, > > when compiled on FreeBSD/arm, causes a -Wcast-align warning > > which doesn't look right: > >=20 > > %%% > > $ cat a.c > > struct foo { > > char x; > > }; > >=20 > > struct foo * > > bubu(char *s) > > { > >=20 > > return (struct foo *)s; > > } > > $ cc -c -Wcast-align a.c > > a.c: In function `bubu': > > a.c:9: warning: cast increases required alignment of target type > > %%% > >=20 > > (None of other supported architecutes see the issue here.) >=20 > What is sizeof(struct foo)? If it's > 1 it makes sense. >=20 Yes, it's four bytes on ARM. But why? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --IiVenqGWf+H9Y6IX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFVzO6qRfpzJluFF4RAnW8AJ9XPR3d5tGGAHEkD06xWD07Frw2rACghbIi AssHx2oQOJQ9xso6+MNMaTA= =l4T9 -----END PGP SIGNATURE----- --IiVenqGWf+H9Y6IX-- From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 14:51:50 2006 Return-Path: X-Original-To: arm@FreeBSD.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08BC416A415; Sun, 12 Nov 2006 14:51:50 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B71443D8F; Sun, 12 Nov 2006 14:51:48 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 99F2C5DAE; Sun, 12 Nov 2006 17:51:47 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 533EA5DAB; Sun, 12 Nov 2006 17:51:47 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACEppa0050144; Sun, 12 Nov 2006 17:51:51 +0300 (MSK) (envelope-from ru) Date: Sun, 12 Nov 2006 17:51:51 +0300 From: Ruslan Ermilov To: Giorgos Keramidas Message-ID: <20061112145151.GC49703@rambler-co.ru> References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ABTtc+pdwF7KHXCz" Content-Disposition: inline In-Reply-To: <20061112144230.GC2331@kobe.laptop> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: arm@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 14:51:50 -0000 --ABTtc+pdwF7KHXCz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 03:42:30PM +0100, Giorgos Keramidas wrote: > On 2006-11-12 17:00, Ruslan Ermilov wrote: > > > /src/lib/libelf/elf_rand.c: In function `elf_rand': > > > /src/lib/libelf/elf_rand.c:47: warning: cast increases required align= ment of target type > > > *** Error code 1 > > > > > > Stop in /src/lib/libelf. > > > *** Error code 1 > > > > This looks like a GCC bug to me. The following code snippet, > > when compiled on FreeBSD/arm, causes a -Wcast-align warning > > which doesn't look right: > > > > %%% > > $ cat a.c > > struct foo { > > char x; > > }; > > > > struct foo * > > bubu(char *s) > > { > > > > return (struct foo *)s; > > } > > $ cc -c -Wcast-align a.c > > a.c: In function `bubu': > > a.c:9: warning: cast increases required alignment of target type > > %%% > > > > (None of other supported architecutes see the issue here.) >=20 > You can't cast any random (char *) pointer to a pointer of a type which > is (potentially) larger than 1 byte. It's the same sort of warning you > will get if you try to: >=20 > char ch[] =3D "\x00\x00\x00\x00"; > char *p =3D &(ch[0]); > unsigned long *lptr =3D (unsigned long *)p; >=20 > You cannot guarantee that `ch' is stored in an address that is properly > aligned for (unsigned long), and this is what GCC warns about here. >=20 No, your example I perfectly understand but it is completely different. Note that the first (and only) member in my structure is "char", so it doesn't need to be more than sizeof(char) aligned. > On 2006-11-12 15:27, Stefan Farfeleder wrote: > > What is sizeof(struct foo)? If it's > 1 it makes sense. >=20 > Exactly :) >=20 Still doesn't make much sense to me. If all structure members are chars (like is the case with "struct ar_hdr" from which GCC complains about, and in my example, the required alignment shouldn't be more than sizeof(char). What am I missing? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --ABTtc+pdwF7KHXCz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFVzUHqRfpzJluFF4RAk/2AJ4/N4i6u2+Zz/RRzNDStRX76CV2fgCfXLiX RuNsL3WxU6JxtoI7ZX+Oi34= =Ibh/ -----END PGP SIGNATURE----- --ABTtc+pdwF7KHXCz-- From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 15:11:40 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB86C16A40F for ; Sun, 12 Nov 2006 15:11:40 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 720D143D83 for ; Sun, 12 Nov 2006 15:11:40 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so572630nzh for ; Sun, 12 Nov 2006 07:11:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NROCbYQ8GCfCDvTsupUzN+jMGf7nhFncJlOZ9dX5Zlcxo1LzwtUwgESZSdkD+rydEF/B/mt++JtT1wKFETJ9pdZ0FyDrCKyiac8KISesPPU4nYsghApxxcgjjYkibmL7Eak8vsDcCIA8bCLlEoYwhleWoPSTUZ+A7Y+5ksGXB8o= Received: by 10.65.250.11 with SMTP id c11mr6245342qbs.1163344298550; Sun, 12 Nov 2006 07:11:38 -0800 (PST) Received: by 10.64.204.15 with HTTP; Sun, 12 Nov 2006 07:11:38 -0800 (PST) Message-ID: <84dead720611120711q41d9dbefi5617f2edb03759f1@mail.gmail.com> Date: Sun, 12 Nov 2006 20:41:38 +0530 From: "Joseph Koshy" To: current@freebsd.org In-Reply-To: <20061111202438.CFBC473068@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061111202438.CFBC473068@freebsd-current.sentex.ca> Cc: arm@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 15:11:41 -0000 > /src/lib/libelf/elf_rand.c: In function `elf_rand': > /src/lib/libelf/elf_rand.c:47: warning: cast increases > required alignment of target type > *** Error code 1 This is the offending line: $ sed -ne 47p elf_rand.c arh = (struct ar_hdr *) (ar->e_rawfile + offset); However, 'struct ar_hdr' is a collection of char[] arrays, so I'm puzzled as to why GCC/arm thinks 'struct ar_hdr' has an alignment requirement. __alignof__(struct ar_hdr) appears to be '4' according GCC/arm. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 15:12:35 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DE1616A40F; Sun, 12 Nov 2006 15:12:35 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EC1B43D66; Sun, 12 Nov 2006 15:12:30 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (host155-42.pool8174.interbusiness.it [81.74.42.155] (may be forged)) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-2) with ESMTP id kACFC3Kj002654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 12 Nov 2006 17:12:09 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id kACFBqkf003046; Sun, 12 Nov 2006 16:11:54 +0100 (CET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id kACFBpBo003045; Sun, 12 Nov 2006 16:11:51 +0100 (CET) (envelope-from keramida@freebsd.org) Date: Sun, 12 Nov 2006 16:11:51 +0100 From: Giorgos Keramidas To: Ruslan Ermilov Message-ID: <20061112151150.GA2988@kobe.laptop> References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112145151.GC49703@rambler-co.ru> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.463, required 5, autolearn=not spam, BAYES_00 -2.60, FORGED_RCVD_HELO 0.14, UNPARSEABLE_RELAY 0.00) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 15:12:35 -0000 On 2006-11-12 17:51, Ruslan Ermilov wrote: > On Sun, Nov 12, 2006 at 03:42:30PM +0100, Giorgos Keramidas wrote: > > On 2006-11-12 17:00, Ruslan Ermilov wrote: > > > %%% > > > $ cat a.c > > > struct foo { > > > char x; > > > }; > > > > > > struct foo * > > > bubu(char *s) > > > { > > > > > > return (struct foo *)s; > > > } > > > $ cc -c -Wcast-align a.c > > > a.c: In function `bubu': > > > a.c:9: warning: cast increases required alignment of target type > > > %%% > > > > > > (None of other supported architecutes see the issue here.) > > > > You can't cast any random (char *) pointer to a pointer of a type which > > is (potentially) larger than 1 byte. It's the same sort of warning you > > will get if you try to: > > > > char ch[] = "\x00\x00\x00\x00"; > > char *p = &(ch[0]); > > unsigned long *lptr = (unsigned long *)p; > > > > You cannot guarantee that `ch' is stored in an address that is properly > > aligned for (unsigned long), and this is what GCC warns about here. > > No, your example I perfectly understand but it is completely different. > Note that the first (and only) member in my structure is "char", so it > doesn't need to be more than sizeof(char) aligned. Ah, but the tricky part is that inside bubu() there is no knowledge that `s' may be properly aligned for a (struct foo *) pointer. All the compiler knows is that it is a (char *), possibly misaligned for any pointer whose object has a size > 1. > > On 2006-11-12 15:27, Stefan Farfeleder wrote: > > > What is sizeof(struct foo)? If it's > 1 it makes sense. > > > > Exactly :) > > Still doesn't make much sense to me. If all structure members are chars > (like is the case with "struct ar_hdr" from which GCC complains > about, and in my example, the required alignment shouldn't be more than > sizeof(char). What am I missing? You are missing that inside bubu() the compiler 'believes' that: * The `s' pointer is (char *)-aligned. * The sizeof(struct foo) is >1. * You are trying to assign `s' (with it's possibly misaligned value) to the `return value' place, whose type is (at least, as far as the compiler knows) is (struct foo *). That may break alignment assumptions the compiler is making inside bubu(), especially about the `s' pointer, hence the warning. - Giorgos From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 15:57:55 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E013A16A415; Sun, 12 Nov 2006 15:57:55 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30E9643D9D; Sun, 12 Nov 2006 15:57:21 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 3B6F15EEC; Sun, 12 Nov 2006 18:57:20 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 195A75E9C; Sun, 12 Nov 2006 18:57:20 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACFvNMe050883; Sun, 12 Nov 2006 18:57:23 +0300 (MSK) (envelope-from ru) Date: Sun, 12 Nov 2006 18:57:23 +0300 From: Ruslan Ermilov To: Giorgos Keramidas Message-ID: <20061112155723.GB50349@rambler-co.ru> References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig" Content-Disposition: inline In-Reply-To: <20061112151150.GA2988@kobe.laptop> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 15:57:56 -0000 --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 04:11:51PM +0100, Giorgos Keramidas wrote: > On 2006-11-12 17:51, Ruslan Ermilov wrote: > > On Sun, Nov 12, 2006 at 03:42:30PM +0100, Giorgos Keramidas wrote: > > > On 2006-11-12 17:00, Ruslan Ermilov wrote: > > > > %%% > > > > $ cat a.c > > > > struct foo { > > > > char x; > > > > }; > > > > > > > > struct foo * > > > > bubu(char *s) > > > > { > > > > > > > > return (struct foo *)s; > > > > } > > > > $ cc -c -Wcast-align a.c > > > > a.c: In function `bubu': > > > > a.c:9: warning: cast increases required alignment of target type > > > > %%% > > > > > > > > (None of other supported architecutes see the issue here.) > > >=20 > > > You can't cast any random (char *) pointer to a pointer of a type whi= ch > > > is (potentially) larger than 1 byte. It's the same sort of warning y= ou > > > will get if you try to: > > >=20 > > > char ch[] =3D "\x00\x00\x00\x00"; > > > char *p =3D &(ch[0]); > > > unsigned long *lptr =3D (unsigned long *)p; > > >=20 > > > You cannot guarantee that `ch' is stored in an address that is proper= ly > > > aligned for (unsigned long), and this is what GCC warns about here. > >=20 > > No, your example I perfectly understand but it is completely different. > > Note that the first (and only) member in my structure is "char", so it > > doesn't need to be more than sizeof(char) aligned. >=20 > Ah, but the tricky part is that inside bubu() there is no knowledge that > `s' may be properly aligned for a (struct foo *) pointer. All the > compiler knows is that it is a (char *), possibly misaligned for any > pointer whose object has a size > 1. >=20 I don't think you're right. If I don't declare a structure so that the compiler REALLY doesn't know the alignment requirement, it doesn't even complain (this is on ARM): : $ diff -u20 a.c b.c : --- a.c Sun Nov 12 18:19:34 2006 : +++ b.c Sun Nov 12 18:19:22 2006 : @@ -1,10 +1,12 @@ : #include : =20 : -struct foo; : +struct foo { : + char x; : +}; : =20 : struct foo * : bubu(char *s) : { : =20 : return (struct foo *)s; : } : $ cc -c -Wcast-align a.c : $ cc -c -Wcast-align b.c : b.c: In function `bubu': : b.c:11: warning: cast increases required alignment of target type > > > On 2006-11-12 15:27, Stefan Farfeleder wrote: > > > > What is sizeof(struct foo)? If it's > 1 it makes sense. > > >=20 > > > Exactly :) > >=20 > > Still doesn't make much sense to me. If all structure members are chars > > (like is the case with "struct ar_hdr" from which GCC complains > > about, and in my example, the required alignment shouldn't be more than > > sizeof(char). What am I missing? >=20 > You are missing that inside bubu() the compiler 'believes' that: >=20 > * The `s' pointer is (char *)-aligned. >=20 > * The sizeof(struct foo) is >1. >=20 > * You are trying to assign `s' (with it's possibly misaligned > value) to the `return value' place, whose type is (at > least, as far as the compiler knows) is (struct foo *). >=20 I will assume that under a "misaligned value" you mean a data that the `s' pointer points to. Assigning a pointer to pointer isn't a problem per se, there are no alignment issues here; dereferencing an assigned pointer later might be a problem if it points to an object with more strict alignment requirement. This is all clear and fine, I understand how all this works. :-) What I don't seem to understand (and you didn't tell me) is why the alignment requirement for "struct foo" is >1. From the above it looks like you're thinking that __alignof__(x) >=3D sizeof(x). Fortunately, not all that bad, and compiling the following snippet on sparc64: : #include :=20 : struct foo1 { : char foo[4]; : }; :=20 : struct foo2 { : int foo; : }; :=20 : int : main(char *s) : { : struct foo1 *foo1 =3D (struct foo1 *)s; : struct foo2 *foo2 =3D (struct foo2 *)s; : printf("%jd %jd\n", __alignof__(*foo1), __alignof__(*foo2)); : } Only complains about the second assignment: : a.c: In function `main': : a.c:15: warning: cast increases required alignment of target type Running it outputs: "1 4". Similarly for "struct ar_hdr", whose all members are character arrays, also has the alignment requirement of 1 byte (verified on sparc64). So your sizeof() argument, well... I don't understand it and it doesn't make things clearer at least to me. I still believe this is bug in GCC that the alignment requirement is so high for a "struct foo { char x; }" (there's no real reason for this!). Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --H+4ONPRPur6+Ovig Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV0RjqRfpzJluFF4RAlAOAKCXFEwLbtRFOFq2kvM8B5/Xgu1VJACdEFva Cdzbot64aK6bvxSbXCKw3iI= =/D0P -----END PGP SIGNATURE----- --H+4ONPRPur6+Ovig-- From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 16:00:09 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED8FD16A403 for ; Sun, 12 Nov 2006 16:00:09 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52D4543D45 for ; Sun, 12 Nov 2006 15:58:55 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so577900nzh for ; Sun, 12 Nov 2006 07:58:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hrMMllOgmJrcLHJJhQbDsiUgL2Ea2K7LnqBp3tFRB5anCPsYj1K8VbfILccj78Cgha9/o+EvsyjnW54z/0vqQpW9v7Ryak1WlkV6FvtZYLowKO8TUqIRQIqVTeEXdNWOGIwaxg1LPTcasxkGBUdzuD6Geev17g1VrpIqQ8FldEg= Received: by 10.64.199.2 with SMTP id w2mr6271488qbf.1163347129719; Sun, 12 Nov 2006 07:58:49 -0800 (PST) Received: by 10.64.204.15 with HTTP; Sun, 12 Nov 2006 07:58:49 -0800 (PST) Message-ID: <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com> Date: Sun, 12 Nov 2006 21:28:49 +0530 From: "Joseph Koshy" To: "Giorgos Keramidas" In-Reply-To: <20061112151150.GA2988@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 16:00:10 -0000 ru> Still doesn't make much sense to me. If all structure ru> members are chars (like is the case with "struct ar_hdr" ru> from which GCC complains about, and in my example, ru> the required alignment shouldn't be more than sizeof(char). ru> What am I missing? gk> You are missing that inside bubu() the compiler gk> 'believes' that: gk> * The `s' pointer is (char *)-aligned. gk> * The sizeof(struct foo) is >1. gk> * You are trying to assign `s' (with it's possibly gk> misaligned value) to the `return value' place, gk> whose type is (at least, as far as the compiler gk> knows) is (struct foo *). gk> That may break alignment assumptions the compiler is making gk> inside bubu(), especially about the `s' pointer, hence the gk> warning. The following program prints `1' on the AMD64, i386 and on sparc64. ----- SNIP ---- #include struct foo { char x; }; int main(int c, char **v) { printf("align=%d\n", __alignof__(struct foo)); } ---- SNIP --- I don't have a way of running ARM binaries, but disassembly of the binary shows: 00000000
: ... snip ... 20: e59f0010 ldr r0, [pc, #16] ; 38 <.text+0x38> 24: e3a01004 mov r1, #4 ; 0x4 28: ebfffffe bl 28 2c: e1a00003 mov r0, r3 ... snip ... If I am reading the assembly correctly, GCC thinks that the alignment for struct foo is '4'. However, changing the program print `__alignof__(foo.x)' results in a value of `1' being loaded into R1. And then `sizeof (struct foo)` appears to be 4 with GCC/arm and 1 on the other architectures. GCC/arm also thinks that the alignment requirement for `char a[1]' is `4', even though `sizeof(char a[1])` remains at 1. This doesn't make sense at many levels. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy/ From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 16:27:27 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2916C16A47C; Sun, 12 Nov 2006 16:27:27 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 413E343D46; Sun, 12 Nov 2006 16:27:19 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 1208C5FBB; Sun, 12 Nov 2006 19:27:18 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id E54295FAC; Sun, 12 Nov 2006 19:27:17 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACGRLeV051756; Sun, 12 Nov 2006 19:27:21 +0300 (MSK) (envelope-from ru) Date: Sun, 12 Nov 2006 19:27:21 +0300 From: Ruslan Ermilov To: Joseph Koshy Message-ID: <20061112162721.GD50349@rambler-co.ru> References: <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eheScQNz3K90DVRs" Content-Disposition: inline In-Reply-To: <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: arm@freebsd.org, Giorgos Keramidas , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 16:27:27 -0000 --eheScQNz3K90DVRs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 09:28:49PM +0530, Joseph Koshy wrote: > The following program prints `1' on the AMD64, i386 and on > sparc64. >=20 > ----- SNIP ---- > #include >=20 > struct foo { > char x; > }; >=20 > int > main(int c, char **v) > { > printf("align=3D%d\n", __alignof__(struct foo)); > } > ---- SNIP --- >=20 Yes. > I don't have a way of running ARM binaries, but > disassembly of the binary shows: > 00000000
: > ... snip ... > 20: e59f0010 ldr r0, [pc, #16] ; 38 <.text+0x38> > 24: e3a01004 mov r1, #4 ; 0x4 > 28: ebfffffe bl 28 > 2c: e1a00003 mov r0, r3 > ... snip ... >=20 :-) I cheated differently; if (sizeof(...) =3D=3D 1) printf("1111111111111"); else if (sizeof(...) =3D=3D 2) printf("2222222222222"); and then running strings(1) on the object file to find the answer. > If I am reading the assembly correctly, GCC thinks that > the alignment for struct foo is '4'. However, changing > the program print `__alignof__(foo.x)' results in a value > of `1' being loaded into R1. >=20 __alignof__(foo.x) has nothing to do with __alignof__(foo); here's a relevant snippet from gcc.info: : If the operand of `__alignof__' is an lvalue rather than a type, its : value is the required alignment for its type, taking into account any : minimum alignment specified with GCC's `__attribute__' extension (*note : Variable Attributes::). For example, after this declaration: :=20 : struct foo { int x; char y; } foo1; :=20 : the value of `__alignof__ (foo1.y)' is 1, even though its actual : alignment is probably 2 or 4, the same as `__alignof__ (int)'. > And then `sizeof (struct foo)` appears to be 4 with GCC/arm > and 1 on the other architectures. >=20 Yes, but even with this insane sizeof(), it should not be an alignment problem; see my other email which shows that alignment of a four-byte structure can still be 1 byte (like is the case for "struct ar_hdr" on all other arches). It was always my basic sunderstanding that an alignment of a structure type is a maximum of alignments of its members, so this struct foo { char foo[16]; char x; char bar[32]; }; doesn't have alignment requirements, and this struct foo { char foo[16]; int x; char bar[32]; }; should be 4 bytes aligned assuming sizeof(int) =3D=3D 4. > GCC/arm also thinks that the alignment requirement for > `char a[1]' is `4', even though `sizeof(char a[1])` > remains at 1. >=20 > This doesn't make sense at many levels. >=20 For one thing, such a structure is not "portable" -- you cannot pass it over a network safely without the __attribute__((packed)) which should be redundant here. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --eheScQNz3K90DVRs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV0tpqRfpzJluFF4RAuWPAJ9aKuu3QRgJCcPn/sii6022LKwT2QCfZWZQ tObU0gTNX669NL3oouGWLtY= =TZVZ -----END PGP SIGNATURE----- --eheScQNz3K90DVRs-- From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 16:59:16 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D699116A412; Sun, 12 Nov 2006 16:59:16 +0000 (UTC) (envelope-from nick@flirble.org) Received: from plum.flirble.org (plum.flirble.org [195.40.6.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id D379643D60; Sun, 12 Nov 2006 16:59:05 +0000 (GMT) (envelope-from nick@flirble.org) Received: from nick by plum.flirble.org with local (Exim 4.43) id 1GjIfg-000GU4-BE; Sun, 12 Nov 2006 16:59:04 +0000 Date: Sun, 12 Nov 2006 16:59:04 +0000 From: Nicholas Clark To: Ruslan Ermilov Message-ID: <20061112165904.GP6501@plum.flirble.org> Mail-Followup-To: Ruslan Ermilov , Giorgos Keramidas , arm@freebsd.org, current@freebsd.org References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <20061112155723.GB50349@rambler-co.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112155723.GB50349@rambler-co.ru> User-Agent: Mutt/1.3.25i X-Organisation: Tetrachloromethane Sender: Nicholas Clark Cc: arm@freebsd.org, Giorgos Keramidas , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 16:59:17 -0000 On Sun, Nov 12, 2006 at 06:57:23PM +0300, Ruslan Ermilov wrote: > So your sizeof() argument, well... I don't understand it and it > doesn't make things clearer at least to me. I still believe this > is bug in GCC that the alignment requirement is so high for a > "struct foo { char x; }" (there's no real reason for this!). It is no bug in GCC. ANSI C gives extreme flexibility for the compiler to align (or pad) structures. The assumptions in the code you presented are not portable. The problem tends to be that ARM is the only common platform that does structure alignment this way, so tends to trip up a lot of code that has worked just fine in many other places. There is a lot more detail in http://netwinder.osuosl.org/users/b/brianbr/public_html/alignment.html including how gcc's __packed__ extention can be used to tell gcc to align structures in different ways. Nicholas Clark From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 17:07:22 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE90916A407; Sun, 12 Nov 2006 17:07:22 +0000 (UTC) (envelope-from nick@flirble.org) Received: from plum.flirble.org (plum.flirble.org [195.40.6.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2417743D68; Sun, 12 Nov 2006 17:07:13 +0000 (GMT) (envelope-from nick@flirble.org) Received: from nick by plum.flirble.org with local (Exim 4.43) id 1GjInX-000H6j-Lq; Sun, 12 Nov 2006 17:07:11 +0000 Date: Sun, 12 Nov 2006 17:07:11 +0000 From: Nicholas Clark To: Joseph Koshy Message-ID: <20061112170711.GQ6501@plum.flirble.org> Mail-Followup-To: Joseph Koshy , Giorgos Keramidas , arm@freebsd.org, current@freebsd.org References: <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com> User-Agent: Mutt/1.3.25i X-Organisation: Tetrachloromethane Sender: Nicholas Clark Cc: arm@freebsd.org, Giorgos Keramidas , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 17:07:22 -0000 On Sun, Nov 12, 2006 at 09:28:49PM +0530, Joseph Koshy wrote: > GCC/arm also thinks that the alignment requirement for > `char a[1]' is `4', even though `sizeof(char a[1])` > remains at 1. > > This doesn't make sense at many levels. But is legal for an ANSI C compiler to do so. (As I understand it, the reason for the original ARM ABI on other operating systems choosing to do this alignment was because it was thought that word alignment even of arrays would generate faster code. I think that they now realise that actually this is not the case) I'm not following FreeBSD closely enough to know whether ARM has shipped as a released supported platform yet, but if not then I believe that FreeBSD is free to change its ARM ABI to anything that it feels more suitable. It may be worth talking to the ARM Linux folks to find out what they would have done differently in the ABI had they known. I suspect that the EABI described in http://wiki.debian.org/ArmEabiPort is based on previous pain. Has FreeBSD adopted the wonderful mixed endian IEEE 64 bit representation too? (Yep, that's legal. But catches a lot of code too) Nicholas Clark From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 17:14:44 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 437E416A403; Sun, 12 Nov 2006 17:14:44 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7285843D46; Sun, 12 Nov 2006 17:14:34 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 9347D5E5E; Sun, 12 Nov 2006 20:14:33 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 713D35E5C; Sun, 12 Nov 2006 20:14:33 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACHEbRQ053693; Sun, 12 Nov 2006 20:14:37 +0300 (MSK) (envelope-from ru) Date: Sun, 12 Nov 2006 20:14:37 +0300 From: Ruslan Ermilov To: Giorgos Keramidas , arm@freebsd.org, current@freebsd.org Message-ID: <20061112171436.GF50349@rambler-co.ru> References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <20061112155723.GB50349@rambler-co.ru> <20061112165904.GP6501@plum.flirble.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tMbDGjvJuJijemkf" Content-Disposition: inline In-Reply-To: <20061112165904.GP6501@plum.flirble.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 17:14:44 -0000 --tMbDGjvJuJijemkf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 04:59:04PM +0000, Nicholas Clark wrote: > On Sun, Nov 12, 2006 at 06:57:23PM +0300, Ruslan Ermilov wrote: > > So your sizeof() argument, well... I don't understand it and it > > doesn't make things clearer at least to me. I still believe this > > is bug in GCC that the alignment requirement is so high for a > > "struct foo { char x; }" (there's no real reason for this!). >=20 > It is no bug in GCC. ANSI C gives extreme flexibility for the compiler to > align (or pad) structures. The assumptions in the code you presented are = not > portable. The problem tends to be that ARM is the only common platform th= at > does structure alignment this way, so tends to trip up a lot of code that > has worked just fine in many other places. >=20 > There is a lot more detail in > http://netwinder.osuosl.org/users/b/brianbr/public_html/alignment.html > including how gcc's __packed__ extention can be used to tell gcc to align > structures in different ways. >=20 Thanks! Item 2 at this URL has an answer to my question. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --tMbDGjvJuJijemkf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV1Z8qRfpzJluFF4RAnrMAJsHxnuDRsfSADbZhIuqVaSalcaOdACfZkqZ zHQkfDktO4QwcnjRNJPs1iE= =9vjp -----END PGP SIGNATURE----- --tMbDGjvJuJijemkf-- From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 18:01:17 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BFC216A412; Sun, 12 Nov 2006 18:01:17 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 501F943D7E; Sun, 12 Nov 2006 18:01:10 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (host155-42.pool8174.interbusiness.it [81.74.42.155] (may be forged)) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-2) with ESMTP id kACI0ivr012141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 12 Nov 2006 20:00:49 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id kACI0WGC006785; Sun, 12 Nov 2006 19:00:35 +0100 (CET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id kACI0Wae006784; Sun, 12 Nov 2006 19:00:32 +0100 (CET) (envelope-from keramida@freebsd.org) Date: Sun, 12 Nov 2006 19:00:32 +0100 From: Giorgos Keramidas To: Ruslan Ermilov Message-ID: <20061112180031.GC4237@kobe.laptop> References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <20061112155723.GB50349@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20061112155723.GB50349@rambler-co.ru> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.463, required 5, autolearn=not spam, BAYES_00 -2.60, FORGED_RCVD_HELO 0.14, UNPARSEABLE_RELAY 0.00) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 18:01:17 -0000 On 2006-11-12 18:57, Ruslan Ermilov wrote: > On Sun, Nov 12, 2006 at 04:11:51PM +0100, Giorgos Keramidas wrote: > > Ah, but the tricky part is that inside bubu() there is no knowledge that > > `s' may be properly aligned for a (struct foo *) pointer. All the > > compiler knows is that it is a (char *), possibly misaligned for any > > pointer whose object has a size > 1. > > I don't think you're right. If I don't declare a structure so that the > compiler REALLY doesn't know the alignment requirement, it doesn't even > complain (this is on ARM): > > : $ diff -u20 a.c b.c > : --- a.c Sun Nov 12 18:19:34 2006 > : +++ b.c Sun Nov 12 18:19:22 2006 > : @@ -1,10 +1,12 @@ > : #include > : > : -struct foo; > : +struct foo { > : + char x; > : +}; > : > : struct foo * > : bubu(char *s) > : { > : > : return (struct foo *)s; > : } > : $ cc -c -Wcast-align a.c > : $ cc -c -Wcast-align b.c > : b.c: In function `bubu': > : b.c:11: warning: cast increases required alignment of target type The type of (struct foo) in a.c is an "incomplete type" (a type for which the compiler has no size information yet, c.f. ISO/IEC 9899:1999 §6.2.5 (1)). This is probably it doesn't complain about the same problem in `a.c'. What I *don't* know and I can't explain is why sizeof(struct foo) in `b.c' is larger than 1 byte. >>On 2006-11-12 17:00, Ruslan Ermilov wrote: >>> %%% >>> $ cat a.c >>> struct foo { >>> char x; >>> }; >>> >>> struct foo * >>> bubu(char *s) >>> { >>> >>> return (struct foo *)s; >>> } >>> $ cc -c -Wcast-align a.c >>> a.c: In function `bubu': >>> a.c:9: warning: cast increases required alignment of target type >>> %%% >> >> You are missing that inside bubu() the compiler 'believes' that: >> >> * The `s' pointer is (char *)-aligned. >> >> * The sizeof(struct foo) is >1. >> >> * You are trying to assign `s' (with it's possibly misaligned >> value) to the `return value' place, whose type is (at >> least, as far as the compiler knows) is (struct foo *). > > I will assume that under a "misaligned value" you mean a data that the > `s' pointer points to. Assigning a pointer to pointer isn't a problem > per se, there are no alignment issues here; dereferencing an assigned > pointer later might be a problem if it points to an object with more > strict alignment requirement. Right. But the compiler can't really tell if you *are* dereferencing the return value of bubu() somewhere else, just by looking at the definition of bubu()'s body. So it warns you about a potentially problematic cast. > This is all clear and fine, I understand how all this works. :-) > What I don't seem to understand (and you didn't tell me) is why the > alignment requirement for "struct foo" is >1. From the above it looks > like you're thinking that __alignof__(x) >= sizeof(x). Fortunately, > not all that bad, and compiling the following snippet on sparc64: > > : #include > : > : struct foo1 { > : char foo[4]; > : }; > : > : struct foo2 { > : int foo; > : }; > : > : int > : main(char *s) > : { > : struct foo1 *foo1 = (struct foo1 *)s; > : struct foo2 *foo2 = (struct foo2 *)s; > : printf("%jd %jd\n", __alignof__(*foo1), __alignof__(*foo2)); > : } > > Only complains about the second assignment: > > : a.c: In function `main': > : a.c:15: warning: cast increases required alignment of target type > > Running it outputs: "1 4". Similarly for "struct ar_hdr", whose all > members are character arrays, also has the alignment requirement of > 1 byte (verified on sparc64). > > So your sizeof() argument, well... I don't understand it and it > doesn't make things clearer at least to me. I still believe this > is bug in GCC that the alignment requirement is so high for a > "struct foo { char x; }" (there's no real reason for this!). I tried accessing panther.freebsd.org to test this on sparc64 earlier, but it doesn't seem to work from here. I can't really explain why on ARM the alignment requirements seem odd, though. From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 18:08:35 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AFFB16A403; Sun, 12 Nov 2006 18:08:35 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CB8A43D5A; Sun, 12 Nov 2006 18:08:33 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (host155-42.pool8174.interbusiness.it [81.74.42.155] (may be forged)) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-2) with ESMTP id kACI84Mt013458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 12 Nov 2006 20:08:08 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id kACI7wXu006837; Sun, 12 Nov 2006 19:07:59 +0100 (CET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id kACI7waS006836; Sun, 12 Nov 2006 19:07:58 +0100 (CET) (envelope-from keramida@freebsd.org) Date: Sun, 12 Nov 2006 19:07:58 +0100 From: Giorgos Keramidas To: Ruslan Ermilov Message-ID: <20061112180758.GD4237@kobe.laptop> References: <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <20061112155723.GB50349@rambler-co.ru> <20061112165904.GP6501@plum.flirble.org> <20061112171436.GF50349@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112171436.GF50349@rambler-co.ru> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.463, required 5, autolearn=not spam, BAYES_00 -2.60, FORGED_RCVD_HELO 0.14, UNPARSEABLE_RELAY 0.00) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 18:08:35 -0000 On 2006-11-12 20:14, Ruslan Ermilov wrote: >On Sun, Nov 12, 2006 at 04:59:04PM +0000, Nicholas Clark wrote: >>On Sun, Nov 12, 2006 at 06:57:23PM +0300, Ruslan Ermilov wrote: >>> So your sizeof() argument, well... I don't understand it and it >>> doesn't make things clearer at least to me. I still believe this >>> is bug in GCC that the alignment requirement is so high for a >>> "struct foo { char x; }" (there's no real reason for this!). >> >> It is no bug in GCC. ANSI C gives extreme flexibility for the compiler to >> align (or pad) structures. The assumptions in the code you presented are not >> portable. The problem tends to be that ARM is the only common platform that >> does structure alignment this way, so tends to trip up a lot of code that >> has worked just fine in many other places. >> >> There is a lot more detail in >> http://netwinder.osuosl.org/users/b/brianbr/public_html/alignment.html >> including how gcc's __packed__ extention can be used to tell gcc to align >> structures in different ways. > > Thanks! Item 2 at this URL has an answer to my question. Perfect! Now it's obvious why GCC prefers '4-byte accesses' on ARM. Nicholas, thank you so much :) From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 18:21:20 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D7AE16A4E5 for ; Sun, 12 Nov 2006 18:21:20 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E63543D5E for ; Sun, 12 Nov 2006 18:21:17 +0000 (GMT) (envelope-from kabaev@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so896317wxc for ; Sun, 12 Nov 2006 10:21:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=mTYpcOafrAiWxpFLvW8igWaTBUOJLLFMu4BlLO300fxAyC4cNjJrGdlWWc+/mQBK6EhwCZJCX+a51KPlkULgGSjbTBJqCSxxsgxFj2hdu7gn0mSKxERTDCian37JLJ4wrJTL6Xk2tjkAl/xprWc9gNWSbWhlBvGyyeT17HooLNo= Received: by 10.70.113.13 with SMTP id l13mr7938392wxc.1163355675526; Sun, 12 Nov 2006 10:21:15 -0800 (PST) Received: from kan.dnsalias.net ( [24.34.98.164]) by mx.google.com with ESMTP id h38sm8741641wxd.2006.11.12.10.21.14; Sun, 12 Nov 2006 10:21:14 -0800 (PST) Date: Sun, 12 Nov 2006 13:21:05 -0500 From: Alexander Kabaev To: Giorgos Keramidas Message-ID: <20061112132105.6bac38d6@kan.dnsalias.net> In-Reply-To: <20061112180758.GD4237@kobe.laptop> References: <20061112140010.GA47660@rambler-co.ru> <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <20061112155723.GB50349@rambler-co.ru> <20061112165904.GP6501@plum.flirble.org> <20061112171436.GF50349@rambler-co.ru> <20061112180758.GD4237@kobe.laptop> X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.10.6; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_CjRMC7u8sQyTRrKNY83VXXE; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 18:21:20 -0000 --Sig_CjRMC7u8sQyTRrKNY83VXXE Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 12 Nov 2006 19:07:58 +0100 Giorgos Keramidas wrote: > On 2006-11-12 20:14, Ruslan Ermilov wrote: > >On Sun, Nov 12, 2006 at 04:59:04PM +0000, Nicholas Clark wrote: > >>On Sun, Nov 12, 2006 at 06:57:23PM +0300, Ruslan Ermilov wrote: > >>> So your sizeof() argument, well... I don't understand it and it > >>> doesn't make things clearer at least to me. I still believe this > >>> is bug in GCC that the alignment requirement is so high for a > >>> "struct foo { char x; }" (there's no real reason for this!). > >> > >> It is no bug in GCC. ANSI C gives extreme flexibility for the > >> compiler to align (or pad) structures. The assumptions in the code > >> you presented are not portable. The problem tends to be that ARM > >> is the only common platform that does structure alignment this > >> way, so tends to trip up a lot of code that has worked just fine > >> in many other places. > >> > >> There is a lot more detail in > >> http://netwinder.osuosl.org/users/b/brianbr/public_html/alignment.html > >> including how gcc's __packed__ extention can be used to tell gcc > >> to align structures in different ways. > > > > Thanks! Item 2 at this URL has an answer to my question. >=20 > Perfect! >=20 > Now it's obvious why GCC prefers '4-byte accesses' on ARM. > Nicholas, thank you so much :) >=20 GCC expects 4-byte aligned structured on ARM but does not necessarily have to. We can change the default at the expense of possible more inefficient code generated and lost binary compatibility with other ARM OSes out there. So this is trade off between unclear performance penalty and an unspecified but certainly sizable number of other landmines like this lurking on the code. We should decide what evil we regard as lesser. --=20 Alexander Kabaev --Sig_CjRMC7u8sQyTRrKNY83VXXE Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV2YYQ6z1jMm+XZYRAiv6AJwI+6bO6xIP6qnbAnx+V3R4zg0Z/wCgnzGw THSY8Ry1ncgrGhqV+CoECNY= =zjot -----END PGP SIGNATURE----- --Sig_CjRMC7u8sQyTRrKNY83VXXE-- From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 19:28:22 2006 Return-Path: X-Original-To: arm@FreeBSD.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F55D16A4C9; Sun, 12 Nov 2006 19:28:22 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59E1D43DA2; Sun, 12 Nov 2006 19:28:09 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 07FDE6046; Sun, 12 Nov 2006 22:28:07 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id D852D5EDD; Sun, 12 Nov 2006 22:28:06 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACJSAj6027872; Sun, 12 Nov 2006 22:28:10 +0300 (MSK) (envelope-from ru) Date: Sun, 12 Nov 2006 22:28:10 +0300 From: Ruslan Ermilov To: Alexander Kabaev Message-ID: <20061112192810.GC1173@rambler-co.ru> References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <20061112155723.GB50349@rambler-co.ru> <20061112165904.GP6501@plum.flirble.org> <20061112171436.GF50349@rambler-co.ru> <20061112180758.GD4237@kobe.laptop> <20061112132105.6bac38d6@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ALfTUftag+2gvp1h" Content-Disposition: inline In-Reply-To: <20061112132105.6bac38d6@kan.dnsalias.net> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: arm@FreeBSD.org, Giorgos Keramidas , current@FreeBSD.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 19:28:22 -0000 --ALfTUftag+2gvp1h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 01:21:05PM -0500, Alexander Kabaev wrote: > GCC expects 4-byte aligned structured on ARM but does not necessarily > have to. We can change the default at the expense of possible more > inefficient code generated and lost binary compatibility with other ARM > OSes out there. So this is trade off between unclear performance > penalty and an unspecified but certainly sizable number of other > landmines like this lurking on the code. >=20 > We should decide what evil we regard as lesser. >=20 This is the only buildworld problem so far on FreeBSD/ARM, so my feeling is that we can actually benefit from leaving it "as is", as it has a potential of making our code more portable. Of course if binary compatibility for structs across platforms is an issue, a structure should be "packed", because otherwise the C standard says that "Each non-bit-field member of a structure or union object is aligned in an implementation-defined manner appropriate to its type." On the other hand, having GCC align "struct foo { char x[11]; }" on a four-byte boundary (other than for backward compatibility) doesn't make too much sense to me. I don't know GCC rules for alignment of structure members. For example, if it's guaranteed (in GCC) that offsetof(struct foo, bar) is always 1 for "struct foo { char foo; char bar; }" (without the "packed" attribute) on all platforms and OSes GCC supports? I'd expect the latter to be "4" for FreeBSD/ARM but fortunately it stays "1", i.e., only the structure alignment is affected, and not of structure members (which is POLA but makes the 4 byte for structure alignment questionable). Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --ALfTUftag+2gvp1h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV3XKqRfpzJluFF4RAkf+AJ9iKs5nW9ORpNQnI4vQUWSAHMFMWACfdLsB aBsZvSlKNYnR6XkANypmCdg= =CPYa -----END PGP SIGNATURE----- --ALfTUftag+2gvp1h-- From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 20:19:34 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE10816A47E; Sun, 12 Nov 2006 20:19:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50B6543D60; Sun, 12 Nov 2006 20:19:33 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kACKJWmf040690; Sun, 12 Nov 2006 15:19:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kACKJWJd047604; Sun, 12 Nov 2006 15:19:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 42C9773068; Sun, 12 Nov 2006 15:19:32 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061112201932.42C9773068@freebsd-current.sentex.ca> Date: Sun, 12 Nov 2006 15:19:32 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 20:19:34 -0000 TB --- 2006-11-12 19:50:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-12 19:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2006-11-12 19:50:00 - cleaning the object tree TB --- 2006-11-12 19:50:24 - checking out the source tree TB --- 2006-11-12 19:50:24 - cd /tinderbox/HEAD/arm/arm TB --- 2006-11-12 19:50:24 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-12 20:01:48 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-12 20:01:48 - cd /src TB --- 2006-11-12 20:01:48 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 12 20:01:49 UTC 2006 >>> 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 [...] cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_getident.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_hash.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_kind.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_memory.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_next.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_rand.c /src/lib/libelf/elf_rand.c: In function `elf_rand': /src/lib/libelf/elf_rand.c:47: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-12 20:19:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-12 20:19:32 - ERROR: failed to build world TB --- 2006-11-12 20:19:32 - tinderbox aborted TB --- 0.24 user 0.59 system 1771.83 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 20:22:05 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0C0B16A407; Sun, 12 Nov 2006 20:22:05 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B1B943DA8; Sun, 12 Nov 2006 20:21:52 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id kACKLonu029896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Nov 2006 12:21:51 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <4557825E.3070009@errno.com> Date: Sun, 12 Nov 2006 12:21:50 -0800 From: Sam Leffler User-Agent: Thunderbird 1.5.0.7 (X11/20060920) MIME-Version: 1.0 To: Ruslan Ermilov References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <20061112155723.GB50349@rambler-co.ru> <20061112165904.GP6501@plum.flirble.org> <20061112171436.GF50349@rambler-co.ru> <20061112180758.GD4237@kobe.laptop> <20061112132105.6bac38d6@kan.dnsalias.net> <20061112192810.GC1173@rambler-co.ru> In-Reply-To: <20061112192810.GC1173@rambler-co.ru> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, current@freebsd.org, Alexander Kabaev , Giorgos Keramidas Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 20:22:06 -0000 Ruslan Ermilov wrote: > On Sun, Nov 12, 2006 at 01:21:05PM -0500, Alexander Kabaev wrote: >> GCC expects 4-byte aligned structured on ARM but does not necessarily >> have to. We can change the default at the expense of possible more >> inefficient code generated and lost binary compatibility with other ARM >> OSes out there. So this is trade off between unclear performance >> penalty and an unspecified but certainly sizable number of other >> landmines like this lurking on the code. >> >> We should decide what evil we regard as lesser. >> > This is the only buildworld problem so far on FreeBSD/ARM, so my > feeling is that we can actually benefit from leaving it "as is", > as it has a potential of making our code more portable. Of course > if binary compatibility for structs across platforms is an issue, > a structure should be "packed", because otherwise the C standard > says that "Each non-bit-field member of a structure or union object > is aligned in an implementation-defined manner appropriate to its > type." > > On the other hand, having GCC align "struct foo { char x[11]; }" > on a four-byte boundary (other than for backward compatibility) > doesn't make too much sense to me. > > I don't know GCC rules for alignment of structure members. For > example, if it's guaranteed (in GCC) that offsetof(struct foo, bar) > is always 1 for "struct foo { char foo; char bar; }" (without the > "packed" attribute) on all platforms and OSes GCC supports? > I'd expect the latter to be "4" for FreeBSD/ARM but fortunately > it stays "1", i.e., only the structure alignment is affected, > and not of structure members (which is POLA but makes the 4 byte > for structure alignment questionable). This issue appears to have broken if_bridge. On my avila board I align rx packets to be aligned s.t. the ip header lands on a 32-bit boundary. This results in the ethernet header being 2-byte aligned which is ok on other platforms. But the compiler takes this code in bridge_forward: /* * If the interface is learning, and the source * address is valid and not multicast, record * the address. */ if ((bif->bif_flags & IFBIF_LEARNING) != 0 && ETHER_IS_MULTICAST(eh->ether_shost) == 0 && (eh->ether_shost[0] == 0 && eh->ether_shost[1] == 0 && eh->ether_shost[2] == 0 && eh->ether_shost[3] == 0 && eh->ether_shost[4] == 0 && eh->ether_shost[5] == 0) == 0) { (void) bridge_rtupdate(sc, eh->ether_shost, src_if, 0, IFBAF_DYNAMIC); } and converts the 6 byte compares to a 32-bit and 16-bit compare. Since the data is only 16-bit aligned the 32-bit load faults. So the point is that just because things compile doesn't necessarily mean they work. And worse code that works on many/most other architectures may not work. Sam From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 22:48:43 2006 Return-Path: X-Original-To: arm@FreeBSD.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B055B16A4A0; Sun, 12 Nov 2006 22:48:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id B640D43D5E; Sun, 12 Nov 2006 22:48:34 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kACMkwDG081266; Sun, 12 Nov 2006 15:46:58 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 12 Nov 2006 15:47:33 -0700 (MST) Message-Id: <20061112.154733.-432839119.imp@bsdimp.com> To: ru@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20061112192810.GC1173@rambler-co.ru> References: <20061112180758.GD4237@kobe.laptop> <20061112132105.6bac38d6@kan.dnsalias.net> <20061112192810.GC1173@rambler-co.ru> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 12 Nov 2006 15:46:58 -0700 (MST) Cc: arm@FreeBSD.org, current@FreeBSD.org, kabaev@gmail.com, keramida@FreeBSD.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 22:48:43 -0000 In message: <20061112192810.GC1173@rambler-co.ru> Ruslan Ermilov writes: : On Sun, Nov 12, 2006 at 01:21:05PM -0500, Alexander Kabaev wrote: : > GCC expects 4-byte aligned structured on ARM but does not necessarily : > have to. We can change the default at the expense of possible more : > inefficient code generated and lost binary compatibility with other ARM : > OSes out there. So this is trade off between unclear performance : > penalty and an unspecified but certainly sizable number of other : > landmines like this lurking on the code. : > : > We should decide what evil we regard as lesser. : > : This is the only buildworld problem so far on FreeBSD/ARM, so my : feeling is that we can actually benefit from leaving it "as is", : as it has a potential of making our code more portable. Of course : if binary compatibility for structs across platforms is an issue, : a structure should be "packed", because otherwise the C standard : says that "Each non-bit-field member of a structure or union object : is aligned in an implementation-defined manner appropriate to its : type." : : On the other hand, having GCC align "struct foo { char x[11]; }" : on a four-byte boundary (other than for backward compatibility) : doesn't make too much sense to me. It does for me. People shouldn't think of structs as being packed. The standard is very clear about the allowed type punning and the disallowed. Many platforms pad structures to the size of a word, and we have to cope. In this specific case, it should be __packed__ because the structure is intended to be packed. : I don't know GCC rules for alignment of structure members. For : example, if it's guaranteed (in GCC) that offsetof(struct foo, bar) : is always 1 for "struct foo { char foo; char bar; }" (without the : "packed" attribute) on all platforms and OSes GCC supports? : I'd expect the latter to be "4" for FreeBSD/ARM but fortunately : it stays "1", i.e., only the structure alignment is affected, : and not of structure members (which is POLA but makes the 4 byte : for structure alignment questionable). It is all up to the compiler. Trying to figure it out is not possible. There's no POLA to violate, unless you expect the whole world to behave like a i386 :-). Warner From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 23:07:00 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 199B616A415; Sun, 12 Nov 2006 23:07:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5F8143D8C; Sun, 12 Nov 2006 23:06:26 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kACN5313081507; Sun, 12 Nov 2006 16:05:03 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 12 Nov 2006 16:05:39 -0700 (MST) Message-Id: <20061112.160539.-1350496508.imp@bsdimp.com> To: sam@errno.com From: "M. Warner Losh" In-Reply-To: <4557825E.3070009@errno.com> References: <20061112132105.6bac38d6@kan.dnsalias.net> <20061112192810.GC1173@rambler-co.ru> <4557825E.3070009@errno.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 12 Nov 2006 16:05:04 -0700 (MST) Cc: arm@freebsd.org, current@freebsd.org, keramida@freebsd.org, kabaev@gmail.com Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 23:07:00 -0000 In message: <4557825E.3070009@errno.com> Sam Leffler writes: : Ruslan Ermilov wrote: : > On Sun, Nov 12, 2006 at 01:21:05PM -0500, Alexander Kabaev wrote: : >> GCC expects 4-byte aligned structured on ARM but does not necessarily : >> have to. We can change the default at the expense of possible more : >> inefficient code generated and lost binary compatibility with other ARM : >> OSes out there. So this is trade off between unclear performance : >> penalty and an unspecified but certainly sizable number of other : >> landmines like this lurking on the code. : >> : >> We should decide what evil we regard as lesser. : >> : > This is the only buildworld problem so far on FreeBSD/ARM, so my : > feeling is that we can actually benefit from leaving it "as is", : > as it has a potential of making our code more portable. Of course : > if binary compatibility for structs across platforms is an issue, : > a structure should be "packed", because otherwise the C standard : > says that "Each non-bit-field member of a structure or union object : > is aligned in an implementation-defined manner appropriate to its : > type." : > : > On the other hand, having GCC align "struct foo { char x[11]; }" : > on a four-byte boundary (other than for backward compatibility) : > doesn't make too much sense to me. : > : > I don't know GCC rules for alignment of structure members. For : > example, if it's guaranteed (in GCC) that offsetof(struct foo, bar) : > is always 1 for "struct foo { char foo; char bar; }" (without the : > "packed" attribute) on all platforms and OSes GCC supports? : > I'd expect the latter to be "4" for FreeBSD/ARM but fortunately : > it stays "1", i.e., only the structure alignment is affected, : > and not of structure members (which is POLA but makes the 4 byte : > for structure alignment questionable). : : This issue appears to have broken if_bridge. On my avila board I align : rx packets to be aligned s.t. the ip header lands on a 32-bit boundary. : This results in the ethernet header being 2-byte aligned which is ok on : other platforms. But the compiler takes this code in bridge_forward: : : /* : * If the interface is learning, and the source : * address is valid and not multicast, record : * the address. : */ : if ((bif->bif_flags & IFBIF_LEARNING) != 0 && : ETHER_IS_MULTICAST(eh->ether_shost) == 0 && : (eh->ether_shost[0] == 0 && : eh->ether_shost[1] == 0 && : eh->ether_shost[2] == 0 && : eh->ether_shost[3] == 0 && : eh->ether_shost[4] == 0 && : eh->ether_shost[5] == 0) == 0) { : (void) bridge_rtupdate(sc, eh->ether_shost, : src_if, 0, IFBAF_DYNAMIC); : } : : and converts the 6 byte compares to a 32-bit and 16-bit compare. Since : the data is only 16-bit aligned the 32-bit load faults. Yea, that's clearly bogus of it. It does this because it thinks that eh is going to be 4-byte aligned, which it isn't in this case. I think that we may need to change: /* * Structure of a 10Mb/s Ethernet header. */ struct ether_header { u_char ether_dhost[ETHER_ADDR_LEN]; u_char ether_shost[ETHER_ADDR_LEN]; u_short ether_type; }; to be struct ether_header { u_char ether_dhost[ETHER_ADDR_LEN]; u_char ether_shost[ETHER_ADDR_LEN]; u_short ether_type; } __packed; since that would fit. There's one caveat that I'd caution people about. NetBSD had lots of issues with gcc4 and packed when the struct doesn't need to be packed. But, I must say, that they do flag these as packed: /* * Ethernet address - 6 octets * this is only used by the ethers(3) functions. */ struct ether_addr { u_int8_t ether_addr_octet[ETHER_ADDR_LEN]; } __attribute__((__packed__)); /* * Structure of a 10Mb/s Ethernet header. */ struct ether_header { u_int8_t ether_dhost[ETHER_ADDR_LEN]; u_int8_t ether_shost[ETHER_ADDR_LEN]; u_int16_t ether_type; } __attribute__((__packed__)); (note: in FreeBSD we have #define in sys/cdefs.h: #define __packed __attribute__((__packed__)) ) : So the point is that just because things compile doesn't necessarily : mean they work. And worse code that works on many/most other : architectures may not work. I've fought this same issue in the boot code (look at boot2 for how I worked around it). The arm really really hates unaligned accesses... Warner From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 23:21:13 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E63116A407; Sun, 12 Nov 2006 23:21:13 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DD9843D70; Sun, 12 Nov 2006 23:21:05 +0000 (GMT) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.7/8.13.4) with ESMTP id kACNYZud012922; Mon, 13 Nov 2006 00:34:35 +0100 (CET) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.7/8.13.4/Submit) id kACNYYmR012921; Mon, 13 Nov 2006 00:34:34 +0100 (CET) (envelope-from mlfbsd) Date: Mon, 13 Nov 2006 00:34:34 +0100 From: Olivier Houchard To: Nicholas Clark Message-ID: <20061112233434.GA12739@ci0.org> References: <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com> <20061112170711.GQ6501@plum.flirble.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112170711.GQ6501@plum.flirble.org> User-Agent: Mutt/1.4.1i Cc: arm@freebsd.org, Giorgos Keramidas , Joseph Koshy , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 23:21:13 -0000 On Sun, Nov 12, 2006 at 05:07:11PM +0000, Nicholas Clark wrote: > On Sun, Nov 12, 2006 at 09:28:49PM +0530, Joseph Koshy wrote: > > > GCC/arm also thinks that the alignment requirement for > > `char a[1]' is `4', even though `sizeof(char a[1])` > > remains at 1. > > > > This doesn't make sense at many levels. > > But is legal for an ANSI C compiler to do so. > (As I understand it, the reason for the original ARM ABI on other operating > systems choosing to do this alignment was because it was thought that word > alignment even of arrays would generate faster code. I think that they now > realise that actually this is not the case) > > I'm not following FreeBSD closely enough to know whether ARM has shipped as > a released supported platform yet, but if not then I believe that FreeBSD > is free to change its ARM ABI to anything that it feels more suitable. > > It may be worth talking to the ARM Linux folks to find out what they would > have done differently in the ABI had they known. I suspect that the EABI > described in http://wiki.debian.org/ArmEabiPort is based on previous pain. > > Has FreeBSD adopted the wonderful mixed endian IEEE 64 bit representation too? > (Yep, that's legal. But catches a lot of code too) > > Nicholas Clark It was my choice to align structures on a word boundary, because of what you pointed, and because of that little comment in gcc/config/arm/netbsd-elf.h : 2. A potential performance penalty may exist if strings are no longer word aligned. GCC will not be able to use word load/stores to copy short strings. I may just not have given enough though to the issue, if the EABI folks chose to switch from word-aligned to no restriction, they certainly have their reasons. I consider we can still do the switch if we should, it will force people to rebuild all their arm apps, but for now as far as I know all users of FreeBSD/arm are FreeBSD developers, so a heads up should be enough. It has to be done now, however. No, we're not using the mixed endian IEEE 64bits representation. We're defaulting to softfloat VFP. What would be te point of switching ? Cheers, Olivier From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 23:28:06 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D73F416A47E; Sun, 12 Nov 2006 23:28:06 +0000 (UTC) (envelope-from nick@flirble.org) Received: from plum.flirble.org (plum.flirble.org [195.40.6.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0734543DBA; Sun, 12 Nov 2006 23:27:54 +0000 (GMT) (envelope-from nick@flirble.org) Received: from nick by plum.flirble.org with local (Exim 4.43) id 1GjOjm-000KAE-I5; Sun, 12 Nov 2006 23:27:42 +0000 Date: Sun, 12 Nov 2006 23:27:42 +0000 From: Nicholas Clark To: Olivier Houchard Message-ID: <20061112232742.GU6501@plum.flirble.org> Mail-Followup-To: Olivier Houchard , Joseph Koshy , Giorgos Keramidas , arm@freebsd.org, current@freebsd.org References: <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com> <20061112170711.GQ6501@plum.flirble.org> <20061112233434.GA12739@ci0.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112233434.GA12739@ci0.org> User-Agent: Mutt/1.3.25i X-Organisation: Tetrachloromethane Sender: Nicholas Clark Cc: arm@freebsd.org, Giorgos Keramidas , Joseph Koshy , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 23:28:07 -0000 On Mon, Nov 13, 2006 at 12:34:34AM +0100, Olivier Houchard wrote: > No, we're not using the mixed endian IEEE 64bits representation. We're > defaulting to softfloat VFP. What would be te point of switching ? >From my limited understanding of these things (mostly observing on the ARM Linux lists) absolutely none. The mixed endian IEEE representation is a complete pain, I'm unaware of any reason why it was chosen over a conventional little endian representation (probably back some time in 1987). Nicholas Clark From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 23:31:40 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63D0316A4F8; Sun, 12 Nov 2006 23:31:40 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDF1B43DEA; Sun, 12 Nov 2006 23:30:37 +0000 (GMT) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.7/8.13.4) with ESMTP id kACNiCPP013043; Mon, 13 Nov 2006 00:44:12 +0100 (CET) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.7/8.13.4/Submit) id kACNiC6T013042; Mon, 13 Nov 2006 00:44:12 +0100 (CET) (envelope-from mlfbsd) Date: Mon, 13 Nov 2006 00:44:12 +0100 From: Olivier Houchard To: Nicholas Clark Message-ID: <20061112234412.GA12998@ci0.org> References: <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com> <20061112170711.GQ6501@plum.flirble.org> <20061112233434.GA12739@ci0.org> <20061112232742.GU6501@plum.flirble.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112232742.GU6501@plum.flirble.org> User-Agent: Mutt/1.4.1i Cc: arm@freebsd.org, Giorgos Keramidas , Joseph Koshy , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 23:31:40 -0000 On Sun, Nov 12, 2006 at 11:27:42PM +0000, Nicholas Clark wrote: > On Mon, Nov 13, 2006 at 12:34:34AM +0100, Olivier Houchard wrote: > > > No, we're not using the mixed endian IEEE 64bits representation. We're > > defaulting to softfloat VFP. What would be te point of switching ? > > >From my limited understanding of these things (mostly observing on the > ARM Linux lists) absolutely none. The mixed endian IEEE representation > is a complete pain, I'm unaware of any reason why it was chosen over a > conventional little endian representation (probably back some time in > 1987). > I thought so :) I think FPA is used for historical reasons, because that's what some older arm cpus used when they had a FPU. And of course using a kernel FPE was a great idea for linux too. Olivier From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 23:31:52 2006 Return-Path: X-Original-To: arm@FreeBSD.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A19D216A4D2; Sun, 12 Nov 2006 23:31:52 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7894243E2A; Sun, 12 Nov 2006 23:31:02 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 2F02560B9; Mon, 13 Nov 2006 02:30:55 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 43EAA5D3B; Mon, 13 Nov 2006 02:28:50 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACNSshA048101; Mon, 13 Nov 2006 02:28:54 +0300 (MSK) (envelope-from ru) Date: Mon, 13 Nov 2006 02:28:54 +0300 From: Ruslan Ermilov To: "M. Warner Losh" , Joseph Koshy Message-ID: <20061112232854.GC45238@rambler-co.ru> References: <20061112132105.6bac38d6@kan.dnsalias.net> <20061112192810.GC1173@rambler-co.ru> <4557825E.3070009@errno.com> <20061112.160539.-1350496508.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MW5yreqqjyrRcusr" Content-Disposition: inline In-Reply-To: <20061112.160539.-1350496508.imp@bsdimp.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: arm@FreeBSD.org, sam@errno.com, keramida@FreeBSD.org, current@FreeBSD.org, kabaev@gmail.com Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 23:31:52 -0000 --MW5yreqqjyrRcusr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 04:05:39PM -0700, M. Warner Losh wrote: > Yea, that's clearly bogus of it. It does this because it thinks that > eh is going to be 4-byte aligned, which it isn't in this case. I > think that we may need to change: >=20 > /* > * Structure of a 10Mb/s Ethernet header. > */ > struct ether_header { > u_char ether_dhost[ETHER_ADDR_LEN]; > u_char ether_shost[ETHER_ADDR_LEN]; > u_short ether_type; > }; >=20 > to be >=20 > struct ether_header { > u_char ether_dhost[ETHER_ADDR_LEN]; > u_char ether_shost[ETHER_ADDR_LEN]; > u_short ether_type; > } __packed; >=20 > since that would fit. >=20 "fit" =3D=3D avoid 32-bit loads (I've similarly checked adding __packed to "struct ar_hdr" here, and it indeed stops using 32-bit loads instructions now): %%% Index: ar.h =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 RCS file: /home/ncvs/src/include/ar.h,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 ar.h --- ar.h 24 May 1994 09:57:26 -0000 1.1.1.1 +++ ar.h 12 Nov 2006 23:26:38 -0000 @@ -44,6 +44,8 @@ #ifndef _AR_H_ #define _AR_H_ =20 +#include + /* Pre-4BSD archives had these magic numbers in them. */ #define OARMAG1 0177555 #define OARMAG2 0177545 @@ -62,6 +64,6 @@ struct ar_hdr { char ar_size[10]; /* size in bytes */ #define ARFMAG "`\n" char ar_fmag[2]; /* consistency check */ -}; +} __packed; =20 #endif /* !_AR_H_ */ %%% > There's one caveat that I'd caution people about. NetBSD had lots of > issues with gcc4 and packed when the struct doesn't need to be packed. >=20 We don't have a lot of packed structs yet, and we should certainly have more of them. :-) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --MW5yreqqjyrRcusr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV642qRfpzJluFF4RAvxsAJsHxNw7Xu078RVRV7gZUGmpWnvSaACfbZ5G psteO64afQgekuYrzw6kJu8= =MhYA -----END PGP SIGNATURE----- --MW5yreqqjyrRcusr-- From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 23:38:28 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3F5016A4D0; Sun, 12 Nov 2006 23:38:28 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id B867443D8E; Sun, 12 Nov 2006 23:38:08 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id C809E5E07; Mon, 13 Nov 2006 02:38:02 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 8D8FC5DF3; Mon, 13 Nov 2006 02:38:02 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACNc7fN049795; Mon, 13 Nov 2006 02:38:07 +0300 (MSK) (envelope-from ru) Date: Mon, 13 Nov 2006 02:38:07 +0300 From: Ruslan Ermilov To: Sam Leffler Message-ID: <20061112233806.GD45238@rambler-co.ru> References: <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <20061112155723.GB50349@rambler-co.ru> <20061112165904.GP6501@plum.flirble.org> <20061112171436.GF50349@rambler-co.ru> <20061112180758.GD4237@kobe.laptop> <20061112132105.6bac38d6@kan.dnsalias.net> <20061112192810.GC1173@rambler-co.ru> <4557825E.3070009@errno.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E13BgyNx05feLLmH" Content-Disposition: inline In-Reply-To: <4557825E.3070009@errno.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 23:38:28 -0000 --E13BgyNx05feLLmH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 12:21:50PM -0800, Sam Leffler wrote: > Ruslan Ermilov wrote: > > On Sun, Nov 12, 2006 at 01:21:05PM -0500, Alexander Kabaev wrote: > >> GCC expects 4-byte aligned structured on ARM but does not necessarily > >> have to. We can change the default at the expense of possible more > >> inefficient code generated and lost binary compatibility with other ARM > >> OSes out there. So this is trade off between unclear performance > >> penalty and an unspecified but certainly sizable number of other > >> landmines like this lurking on the code. > >> > >> We should decide what evil we regard as lesser. > >> > > This is the only buildworld problem so far on FreeBSD/ARM, so my > > feeling is that we can actually benefit from leaving it "as is", > > as it has a potential of making our code more portable. Of course > > if binary compatibility for structs across platforms is an issue, > > a structure should be "packed", because otherwise the C standard > > says that "Each non-bit-field member of a structure or union object > > is aligned in an implementation-defined manner appropriate to its > > type." > >=20 > > On the other hand, having GCC align "struct foo { char x[11]; }" > > on a four-byte boundary (other than for backward compatibility) > > doesn't make too much sense to me. > >=20 > > I don't know GCC rules for alignment of structure members. For > > example, if it's guaranteed (in GCC) that offsetof(struct foo, bar) > > is always 1 for "struct foo { char foo; char bar; }" (without the > > "packed" attribute) on all platforms and OSes GCC supports? > > I'd expect the latter to be "4" for FreeBSD/ARM but fortunately > > it stays "1", i.e., only the structure alignment is affected, > > and not of structure members (which is POLA but makes the 4 byte > > for structure alignment questionable). >=20 > This issue appears to have broken if_bridge. On my avila board I align > rx packets to be aligned s.t. the ip header lands on a 32-bit boundary. > This results in the ethernet header being 2-byte aligned which is ok on > other platforms. But the compiler takes this code in bridge_forward: >=20 > /* > * If the interface is learning, and the source > * address is valid and not multicast, record > * the address. > */ > if ((bif->bif_flags & IFBIF_LEARNING) !=3D 0 && > ETHER_IS_MULTICAST(eh->ether_shost) =3D=3D 0 && > (eh->ether_shost[0] =3D=3D 0 && > eh->ether_shost[1] =3D=3D 0 && > eh->ether_shost[2] =3D=3D 0 && > eh->ether_shost[3] =3D=3D 0 && > eh->ether_shost[4] =3D=3D 0 && > eh->ether_shost[5] =3D=3D 0) =3D=3D 0) { > (void) bridge_rtupdate(sc, eh->ether_shost, > src_if, 0, IFBAF_DYNAMIC); > } >=20 > and converts the 6 byte compares to a 32-bit and 16-bit compare. Since > the data is only 16-bit aligned the 32-bit load faults. >=20 > So the point is that just because things compile doesn't necessarily > mean they work. And worse code that works on many/most other > architectures may not work. >=20 No, this is only because our kernels are compiled without -Wcast-align. Otherwise it notices that mtod() casts "char *" into "struct ether_header *= ": $ pwd =20 /home/ru/w/freebsd/src/sys/modules/if_bridge $ make WARNS=3D6 2>&1 |grep -A1 forward /home/ru/w/freebsd/src/sys/modules/if_bridge/../../net/if_bridge.c: In func= tion `bridge_forward': /home/ru/w/freebsd/src/sys/modules/if_bridge/../../net/if_bridge.c:1888: wa= rning: cast increases required alignment of target type Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --E13BgyNx05feLLmH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFV7BeqRfpzJluFF4RAkKgAJ983jddAbAprxVnOPJiouzXozTMmwCaAjGN n1Mu+nBMZUMsWhyS8loG/cI= =EgaF -----END PGP SIGNATURE----- --E13BgyNx05feLLmH-- From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 23:53:15 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3302C16A40F; Sun, 12 Nov 2006 23:53:15 +0000 (UTC) (envelope-from nick@flirble.org) Received: from plum.flirble.org (plum.flirble.org [195.40.6.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id C784A43D53; Sun, 12 Nov 2006 23:53:13 +0000 (GMT) (envelope-from nick@flirble.org) Received: from nick by plum.flirble.org with local (Exim 4.43) id 1GjP8S-000MHd-UN; Sun, 12 Nov 2006 23:53:12 +0000 Date: Sun, 12 Nov 2006 23:53:12 +0000 From: Nicholas Clark To: Olivier Houchard Message-ID: <20061112235312.GV6501@plum.flirble.org> Mail-Followup-To: Olivier Houchard , Joseph Koshy , Giorgos Keramidas , arm@freebsd.org References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com> <20061112170711.GQ6501@plum.flirble.org> <20061112233434.GA12739@ci0.org> <20061112232742.GU6501@plum.flirble.org> <20061112234412.GA12998@ci0.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112234412.GA12998@ci0.org> User-Agent: Mutt/1.3.25i X-Organisation: Tetrachloromethane Sender: Nicholas Clark Cc: arm@freebsd.org, Giorgos Keramidas , Joseph Koshy Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 23:53:15 -0000 On Mon, Nov 13, 2006 at 12:44:12AM +0100, Olivier Houchard wrote: > On Sun, Nov 12, 2006 at 11:27:42PM +0000, Nicholas Clark wrote: > > On Mon, Nov 13, 2006 at 12:34:34AM +0100, Olivier Houchard wrote: > > > > > No, we're not using the mixed endian IEEE 64bits representation. We're > > > defaulting to softfloat VFP. What would be te point of switching ? > > > > >From my limited understanding of these things (mostly observing on the > > ARM Linux lists) absolutely none. The mixed endian IEEE representation > > is a complete pain, I'm unaware of any reason why it was chosen over a > > conventional little endian representation (probably back some time in > > 1987). > > > > I thought so :) > I think FPA is used for historical reasons, because that's what some older > arm cpus used when they had a FPU. And of course using a kernel FPE was a > great idea for linux too. But I think that the FPA (the external floating point unit) only was only actually produced to used with the 25 Mhz ARM 3s (*), which I think was 1990 or so, which I think would be the first time that mixed endian layout was set in silicon. But the mixed endian layout would have had to have been chosen before RISC OS 2 shipped in 1989, as it had bundled applications written in C, which uses the (emulated) floating point instructions. Hence as far as I know there was no hardware reason to choose that layout - hardware came later. Nicholas Clark * because at the time I upgraded my parents' Archimedes to an ARM 3, I asked about this, and the 30 Mhz CPU-on-a-daughterboards then available would not suitable for adding an FPA, not that it mattered, as the run of FPAs was now all sold) From owner-freebsd-arm@FreeBSD.ORG Mon Nov 13 01:40:22 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1338816A47B for ; Mon, 13 Nov 2006 01:40:22 +0000 (UTC) (envelope-from brewer.doug@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BC0D43D55 for ; Mon, 13 Nov 2006 01:40:21 +0000 (GMT) (envelope-from brewer.doug@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so822945uge for ; Sun, 12 Nov 2006 17:40:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=GFPByWX04OYUlgkaOhU7oKvgGLT63AEc8xnP/eR9JClX9B+uSJLRvOBCKYXVkheKM8mjuI8sS6PFHsbnKRlJGuO8e/aDBlImfDDMOpUKh9cWlnEGiHUIy73G/xtx0jDs/JjmD6I10xZ4UygtGSXpjZYQO4yHxNBbKdHuIWaFzJk= Received: by 10.78.178.5 with SMTP id a5mr5669674huf.1163382019798; Sun, 12 Nov 2006 17:40:19 -0800 (PST) Received: by 10.78.140.7 with HTTP; Sun, 12 Nov 2006 17:40:19 -0800 (PST) Message-ID: Date: Mon, 13 Nov 2006 09:40:19 +0800 From: "Doug Brewer" To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: FreeBSD/arm image question X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 01:40:22 -0000 Hello, I have an i80321 customized board and I'm new to FreeBSD/arm. My bootloader loads Linux zImage. My question is FreeBSD kernel.bin = Linux zImage? I think FreeBSD kernel.bin is a raw binary with no program headers. Warm regards, Doug. From owner-freebsd-arm@FreeBSD.ORG Mon Nov 13 01:45:25 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BC7F16A403 for ; Mon, 13 Nov 2006 01:45:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 533F943D45 for ; Mon, 13 Nov 2006 01:45:24 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kAD1jBIG083383; Sun, 12 Nov 2006 18:45:11 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 12 Nov 2006 18:45:46 -0700 (MST) Message-Id: <20061112.184546.514366287.imp@bsdimp.com> To: brewer.doug@gmail.com From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 12 Nov 2006 18:45:11 -0700 (MST) Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD/arm image question X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 01:45:25 -0000 In message: "Doug Brewer" writes: : Hello, : : I have an i80321 customized board and I'm new to FreeBSD/arm. : My bootloader loads Linux zImage. My question is FreeBSD kernel.bin = : Linux zImage? : I think FreeBSD kernel.bin is a raw binary with no program headers. That is correct. You can do a 'make kernel.tramp' and get a kernel.gz.bin as well, which more closely matches zImage. Warner From owner-freebsd-arm@FreeBSD.ORG Mon Nov 13 02:06:02 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06CD216A407 for ; Mon, 13 Nov 2006 02:06:02 +0000 (UTC) (envelope-from brewer.doug@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A02F43D58 for ; Mon, 13 Nov 2006 02:06:00 +0000 (GMT) (envelope-from brewer.doug@gmail.com) Received: by nf-out-0910.google.com with SMTP id l23so315308nfc for ; Sun, 12 Nov 2006 18:05:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ANwWVG8SBO5emdJA9f+3sPpW89ZNd73gax3fU98OJUoayWMz7vHr1wQAoYUU7SYnel3SW0b+LRPqVgpisZN4yE27b1eZpDvD9PJOXJdRcN9pwOh67KHav5Hb9syW5UnYxdm9X9QUIiTqHsqGIStTAztvGBp3hZaaAlq5WoXTbZg= Received: by 10.78.48.16 with SMTP id v16mr5453697huv.1163383543523; Sun, 12 Nov 2006 18:05:43 -0800 (PST) Received: by 10.78.140.7 with HTTP; Sun, 12 Nov 2006 18:05:43 -0800 (PST) Message-ID: Date: Mon, 13 Nov 2006 10:05:43 +0800 From: "Doug Brewer" To: "M. Warner Losh" In-Reply-To: <20061112.184546.514366287.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061112.184546.514366287.imp@bsdimp.com> Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD/arm image question X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 02:06:02 -0000 On 11/13/06, M. Warner Losh wrote: > In message: > "Doug Brewer" writes: > : Hello, > : > : I have an i80321 customized board and I'm new to FreeBSD/arm. > : My bootloader loads Linux zImage. My question is FreeBSD kernel.bin = > : Linux zImage? > : I think FreeBSD kernel.bin is a raw binary with no program headers. > > That is correct. > > You can do a 'make kernel.tramp' and get a kernel.gz.bin as well, > which more closely matches zImage. You mean I can run "make kernel.tramp KERNCONF=mykernel" ? I used gzip -c kernel.bin > kernel.bin.gz to generate compressed raw binary. Thank you very much. > Warner Warm regards, Doug. From owner-freebsd-arm@FreeBSD.ORG Mon Nov 13 02:10:47 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7077016A40F; Mon, 13 Nov 2006 02:10:47 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CED543D67; Mon, 13 Nov 2006 02:10:46 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.221] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id kAD2Ak24079878; Sun, 12 Nov 2006 18:10:46 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <4557D425.40101@freebsd.org> Date: Sun, 12 Nov 2006 18:10:45 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20061112180758.GD4237@kobe.laptop> <20061112132105.6bac38d6@kan.dnsalias.net> <20061112192810.GC1173@rambler-co.ru> <20061112.154733.-432839119.imp@bsdimp.com> In-Reply-To: <20061112.154733.-432839119.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, current@freebsd.org, keramida@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 02:10:47 -0000 In message: <20061112192810.GC1173@rambler-co.ru> Ruslan Ermilov writes: : On the other hand, having GCC align "struct foo { char x[11]; }" : on a four-byte boundary (other than for backward compatibility) : doesn't make too much sense to me. It makes a lot of sense, actually, even on i386, which is why the standard allows the compiler a lot of leeway to pad and align such structure. For example, consider this structure assignment: struct foo a,b; a = b; The structure copy here is a LOT faster if the structures are always suitably aligned and padded. If the compiler pads your sample struct to 12 bytes and 4-aligns, the structure copy here can be done with 3 aligned 32-bit moves. Even on i386, aligned operations are a lot faster than unaligned ones. The code mentioned in the original post is simply broken; it does not comply with the ISO C Standard. Tim Kientzle From owner-freebsd-arm@FreeBSD.ORG Mon Nov 13 02:59:40 2006 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD7DB16A412; Mon, 13 Nov 2006 02:59:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57C9943D58; Mon, 13 Nov 2006 02:59:40 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kAD2xdwF063610; Sun, 12 Nov 2006 21:59:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAD2xduE012787; Sun, 12 Nov 2006 21:59:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5386E73068; Sun, 12 Nov 2006 21:59:39 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061113025939.5386E73068@freebsd-current.sentex.ca> Date: Sun, 12 Nov 2006 21:59:39 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 02:59:41 -0000 TB --- 2006-11-13 02:30:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-11-13 02:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2006-11-13 02:30:00 - cleaning the object tree TB --- 2006-11-13 02:30:22 - checking out the source tree TB --- 2006-11-13 02:30:22 - cd /tinderbox/HEAD/arm/arm TB --- 2006-11-13 02:30:22 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-11-13 02:41:50 - building world (CFLAGS=-O2 -pipe) TB --- 2006-11-13 02:41:50 - cd /src TB --- 2006-11-13 02:41:50 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 13 02:41:52 UTC 2006 >>> 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 [...] cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_getident.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_hash.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_kind.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_memory.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_next.c cc -O2 -pipe -I. -I/src/lib/libelf -DLIBELF_TEST_HOOKS=1 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libelf/elf_rand.c /src/lib/libelf/elf_rand.c: In function `elf_rand': /src/lib/libelf/elf_rand.c:47: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libelf. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-11-13 02:59:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-11-13 02:59:39 - ERROR: failed to build world TB --- 2006-11-13 02:59:39 - tinderbox aborted TB --- 0.17 user 0.64 system 1778.32 real http://tinderbox.des.no//tinderbox/logs/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon Nov 13 04:30:26 2006 Return-Path: X-Original-To: arm@FreeBSD.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 293FF16A403 for ; Mon, 13 Nov 2006 04:30:26 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from omta01ps.mx.bigpond.com (omta01ps.mx.bigpond.com [144.140.82.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A88143D49 for ; Mon, 13 Nov 2006 04:30:25 +0000 (GMT) (envelope-from andrew@areilly.bpa.nu) Received: from oaamta01ps.mx.bigpond.com ([141.168.2.3]) by omta01ps.mx.bigpond.com with ESMTP id <20061113043021.EMFQ24786.omta01ps.mx.bigpond.com@oaamta01ps.mx.bigpond.com> for ; Mon, 13 Nov 2006 04:30:21 +0000 Received: from areilly.bpa.nu ([141.168.2.3]) by oaamta01ps.mx.bigpond.com with ESMTP id <20061113043016.CINX13696.oaamta01ps.mx.bigpond.com@areilly.bpa.nu> for ; Mon, 13 Nov 2006 04:30:16 +0000 Received: (qmail 80213 invoked by uid 501); 13 Nov 2006 04:27:29 -0000 Date: Mon, 13 Nov 2006 15:27:29 +1100 From: Andrew Reilly To: Ruslan Ermilov Message-ID: <20061113042729.GA79796@duncan.reilly.home> References: <20061112132105.6bac38d6@kan.dnsalias.net> <20061112192810.GC1173@rambler-co.ru> <4557825E.3070009@errno.com> <20061112.160539.-1350496508.imp@bsdimp.com> <20061112232854.GC45238@rambler-co.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061112232854.GC45238@rambler-co.ru> User-Agent: Mutt/1.4.2.2i Cc: current@FreeBSD.org, Joseph Koshy , keramida@FreeBSD.org, arm@FreeBSD.org, sam@errno.com, kabaev@gmail.com Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 04:30:26 -0000 On Mon, Nov 13, 2006 at 02:28:54AM +0300, Ruslan Ermilov wrote: > We don't have a lot of packed structs yet, and we should certainly > have more of them. :-) Well, packed structs is one (non-portable) way to work around the fact that C doesn't really support the use of structs for parsing external (wire, file) data structures. They're internal-use, abstract devices. If you want the code to be portable now and into the future, then you'll use accessor macros that access the byte-stream explicitly, to build larger data types. Won't even have to do anything special for endian-compatability, that way. Yes, I realize that that's not the /traditional way/, and that there's a hell of a lot of inappropriate struct code in there. Cheers, -- Andrew From owner-freebsd-arm@FreeBSD.ORG Mon Nov 13 12:03:15 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C617416A407 for ; Mon, 13 Nov 2006 12:03:15 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08E3D43D45 for ; Mon, 13 Nov 2006 12:03:14 +0000 (GMT) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.7/8.13.4) with ESMTP id kADCGpEC020782; Mon, 13 Nov 2006 13:16:51 +0100 (CET) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.7/8.13.4/Submit) id kADCGoqp020781; Mon, 13 Nov 2006 13:16:50 +0100 (CET) (envelope-from mlfbsd) Date: Mon, 13 Nov 2006 13:16:50 +0100 From: Olivier Houchard To: Doug Brewer Message-ID: <20061113121650.GA20731@ci0.org> References: <20061112.184546.514366287.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD/arm image question X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 12:03:15 -0000 On Mon, Nov 13, 2006 at 10:05:43AM +0800, Doug Brewer wrote: > On 11/13/06, M. Warner Losh wrote: > >In message: > > "Doug Brewer" writes: > >: Hello, > >: > >: I have an i80321 customized board and I'm new to FreeBSD/arm. > >: My bootloader loads Linux zImage. My question is FreeBSD kernel.bin = > >: Linux zImage? > >: I think FreeBSD kernel.bin is a raw binary with no program headers. > > > >That is correct. > > > >You can do a 'make kernel.tramp' and get a kernel.gz.bin as well, > >which more closely matches zImage. > > You mean I can run "make kernel.tramp KERNCONF=mykernel" ? > I used gzip -c kernel.bin > kernel.bin.gz to generate compressed raw binary. > > Thank you very much. > > >Warner > Hi Doug, The real target is "make trampoline", which will generate kernel.tramp, kernel.tramp.bin, kernel.gz.tramp and kernel.gz.tramp.bin. kernel.gz.tramp.bin will be I think what look the most like zImage, as it's a raw binary, able to uncompress the gzipped kernel embedded. Unfortunately, you can't, afaik, do it with the "buildkernel/installkernel" method, so you'll have to use the old config + make depend all method. Cheers, Olivier From owner-freebsd-arm@FreeBSD.ORG Mon Nov 13 14:01:27 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED34416A407 for ; Mon, 13 Nov 2006 14:01:27 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 469A243D58 for ; Mon, 13 Nov 2006 14:01:21 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id B208F33C82; Mon, 13 Nov 2006 16:01:11 +0200 (SAST) Date: Mon, 13 Nov 2006 16:01:11 +0200 From: John Hay To: Olivier Houchard Message-ID: <20061113140111.GA63047@zibbi.meraka.csir.co.za> References: <20061023163650.GA30024@zibbi.meraka.csir.co.za> <20061023211342.GA75533@ci0.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061023211342.GA75533@ci0.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 any experience with it? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 14:01:28 -0000 Hi Olivier, > > I have been lurking on -arm for a while and have been reading the > > archives and some of the web sites: > > > > http://www.freebsd.org/platforms/arm.html > > http://www.embeddedfreebsd.org/boards.html > > > > But I'm still not sure how far / useable the FreeBSD arm port is. Anybody > > care to comment? > > > > It works. It's still not perfect, and has still a few glitches, but it works. > > > We are looking at ways to build a 3 radio wifi system and have been > > wondering if I can consider an arm system and how much work will > > have to be done. We have been using Soekris and Wrap boards for a > > long time, so I am used to the small i386 part of FreeBSD. > > > > One of the boards I have been looking at is the Gateworks 2348, which > > is a 533MHz IXP425 with 64M Ram, 4 x Mini-pci slots and a CF Socket. > > > > http://www.gateworks.com/avila_gw2348_4.htm > > > > So will I be able to just use it or how much work will still have to > > be done and on which parts? > > > > You won't be able to use it yet, however ongoing work is done to support it. > So far the PCI bus works, and hopefully the embedded ethernet controller will > work soon, too. Other things on the board such as the i2c bus isn't supported > yet, but if you need it it shouldn't be too hard to get it. So how unusable is it at the moment? I managed to get the work to buy a couple and will take it home to play with. Where do one start? I see the docs that come with the board says that it has redboot on, so does that mean I can boot it over the ethernet? And is the mini-install guide that the FreeBSD arm web site take about (http://people.freebsd.org/~cognet/freebsd_arm.txt) still how it should be done? I have noticed that a lot of arm code found its way into the FreeBSD cvs tree. Is it possible to start from there yet? Who is working on the ethernet driver? Is that code available somewhere yet? Thanks. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-arm@FreeBSD.ORG Mon Nov 13 14:25:16 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39C3916A407 for ; Mon, 13 Nov 2006 14:25:16 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80F2C43D58 for ; Mon, 13 Nov 2006 14:25:14 +0000 (GMT) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.7/8.13.4) with ESMTP id kADEcxwP022167; Mon, 13 Nov 2006 15:38:59 +0100 (CET) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.7/8.13.4/Submit) id kADEcsie022166; Mon, 13 Nov 2006 15:38:54 +0100 (CET) (envelope-from mlfbsd) Date: Mon, 13 Nov 2006 15:38:53 +0100 From: Olivier Houchard To: John Hay Message-ID: <20061113143853.GA22089@ci0.org> References: <20061023163650.GA30024@zibbi.meraka.csir.co.za> <20061023211342.GA75533@ci0.org> <20061113140111.GA63047@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061113140111.GA63047@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.4.1i Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 any experience with it? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 14:25:16 -0000 On Mon, Nov 13, 2006 at 04:01:11PM +0200, John Hay wrote: > Hi Olivier, > > > > I have been lurking on -arm for a while and have been reading the > > > archives and some of the web sites: > > > > > > http://www.freebsd.org/platforms/arm.html > > > http://www.embeddedfreebsd.org/boards.html > > > > > > But I'm still not sure how far / useable the FreeBSD arm port is. Anybody > > > care to comment? > > > > > > > It works. It's still not perfect, and has still a few glitches, but it works. > > > > > We are looking at ways to build a 3 radio wifi system and have been > > > wondering if I can consider an arm system and how much work will > > > have to be done. We have been using Soekris and Wrap boards for a > > > long time, so I am used to the small i386 part of FreeBSD. > > > > > > One of the boards I have been looking at is the Gateworks 2348, which > > > is a 533MHz IXP425 with 64M Ram, 4 x Mini-pci slots and a CF Socket. > > > > > > http://www.gateworks.com/avila_gw2348_4.htm > > > > > > So will I be able to just use it or how much work will still have to > > > be done and on which parts? > > > > > > > You won't be able to use it yet, however ongoing work is done to support it. > > So far the PCI bus works, and hopefully the embedded ethernet controller will > > work soon, too. Other things on the board such as the i2c bus isn't supported > > yet, but if you need it it shouldn't be too hard to get it. > > So how unusable is it at the moment? I managed to get the work to buy > a couple and will take it home to play with. Where do one start? I see > the docs that come with the board says that it has redboot on, so does > that mean I can boot it over the ethernet? > It's quite usable. We know have support for the ethernet controller. Work is going on, and CF IDE support is almost there. Yes, you can boot it over the thernet. > And is the mini-install guide that the FreeBSD arm web site take about > (http://people.freebsd.org/~cognet/freebsd_arm.txt) still how it should > be done? I have noticed that a lot of arm code found its way into the > FreeBSD cvs tree. Is it possible to start from there yet? > Yes, except you don't need the to apply the patches anymore. However, the code for gateway support is not in CVS yet, only perforce, it will go into CVS very soon, however. > Who is working on the ethernet driver? Is that code available somewhere > yet? > Sam Leffler did most on the work on the ethernet driver. You can browse the perforce repo by http here : http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/arm/src/sys/arm/xscale/ixp425&HIDEDEL=NO Cheers, Olivier From owner-freebsd-arm@FreeBSD.ORG Wed Nov 15 09:10:10 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20EB816A407 for ; Wed, 15 Nov 2006 09:10:10 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2887643D4C for ; Wed, 15 Nov 2006 09:10:08 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 6B30D33CA7; Wed, 15 Nov 2006 11:10:05 +0200 (SAST) Date: Wed, 15 Nov 2006 11:10:05 +0200 From: John Hay To: Olivier Houchard Message-ID: <20061115091005.GA72236@zibbi.meraka.csir.co.za> References: <20061023163650.GA30024@zibbi.meraka.csir.co.za> <20061023211342.GA75533@ci0.org> <20061113140111.GA63047@zibbi.meraka.csir.co.za> <20061113143853.GA22089@ci0.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061113143853.GA22089@ci0.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 any experience with it? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 09:10:10 -0000 > > > > > > > > One of the boards I have been looking at is the Gateworks 2348, which > > > > is a 533MHz IXP425 with 64M Ram, 4 x Mini-pci slots and a CF Socket. > > > > > > > > http://www.gateworks.com/avila_gw2348_4.htm ... > It's quite usable. We know have support for the ethernet controller. Work > is going on, and CF IDE support is almost there. > Yes, you can boot it over the thernet. > > > And is the mini-install guide that the FreeBSD arm web site take about > > (http://people.freebsd.org/~cognet/freebsd_arm.txt) still how it should > > be done? I have noticed that a lot of arm code found its way into the > > FreeBSD cvs tree. Is it possible to start from there yet? > > > > Yes, except you don't need the to apply the patches anymore. However, the > code for gateway support is not in CVS yet, only perforce, it will go into > CVS very soon, however. > > > Who is working on the ethernet driver? Is that code available somewhere > > yet? > > > > Sam Leffler did most on the work on the ethernet driver. You can browse the > perforce repo by http here : > http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/arm/src/sys/arm/xscale/ixp425&HIDEDEL=NO > Ok, I built cross tools (cc and binutils) from cvs -current source and then checked out the perforce projects/arm code. I then tried to build a kernel using the AVILA config file but it breaks at the end when trying to link the hal.o file. Did I do something wrong? ############################ dolphin:~/fbsd/p4/arm/src/sys/arm/compile/AVILA > make ATH_HAL_CPU=`echo -mcpu=xscale|sed 's/.*-mcpu=\([a-zA-Z0-9]*\).*/\1/'`; ATH_ENDIAN=`if (echo /home/jhay/cross/usr/bin/gcc -mbig-endian|grep mbig-endian>/dev/null); then echo be; else echo le; fi;`; uudecode < ../../../contrib/dev/ath/public/$ATH_HAL_CPU-$ATH_ENDIAN-elf.hal.o.uu MAKE=make sh ../../../conf/newvers.sh AVILA /home/jhay/cross/usr/bin/gcc -mbig-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I../../.. -I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror vers.c linking kernel.debug /home/jhay/cross/usr/bin/ld: ERROR: hal.o uses FPA instructions, whereas kernel.debug does not /home/jhay/cross/usr/bin/ld: failed to merge target specific data of file hal.o *** Error code 1 Stop in /home/jhay/fbsd/p4/arm/src/sys/arm/compile/AVILA. dolphin:~/fbsd/p4/arm/src/sys/arm/compile/AVILA > ############################ John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-arm@FreeBSD.ORG Wed Nov 15 11:02:22 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 628CB16A412 for ; Wed, 15 Nov 2006 11:02:22 +0000 (UTC) (envelope-from jim@netgate.com) Received: from netgate.com (mail.netgate.com [64.62.194.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A26943D6E for ; Wed, 15 Nov 2006 11:02:17 +0000 (GMT) (envelope-from jim@netgate.com) Received: from [192.168.2.189] (rrcs-67-52-77-54.west.biz.rr.com [67.52.77.54]) by netgate.com (Postfix) with ESMTP id 70246280033; Wed, 15 Nov 2006 03:02:00 -0800 (PST) In-Reply-To: <20061115091005.GA72236@zibbi.meraka.csir.co.za> References: <20061023163650.GA30024@zibbi.meraka.csir.co.za> <20061023211342.GA75533@ci0.org> <20061113140111.GA63047@zibbi.meraka.csir.co.za> <20061113143853.GA22089@ci0.org> <20061115091005.GA72236@zibbi.meraka.csir.co.za> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Thompson Date: Wed, 15 Nov 2006 01:01:59 -1000 To: John Hay X-Mailer: Apple Mail (2.752.3) Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 any experience with it? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 11:02:22 -0000 On Nov 14, 2006, at 11:10 PM, John Hay wrote: > ERROR: hal.o uses FPA instructions, whereas kernel.debug does not > /home/jhay/cross/usr/bin/ld: failed to merge target specific data > of file hal.o You can't mix the two FP models. See these lines in contrib-arm.diff: +#undef TARGET_DEFAULT +#define TARGET_DEFAULT \ + (ARM_FLAG_APCS_32 \ + | ARM_FLAG_SOFT_FLOAT \ + | ARM_FLAG_APCS_FRAME \ + | ARM_FLAG_ATPCS \ + | ARM_FLAG_VFP \ + | ARM_FLAG_MMU_TRAPS \ + | TARGET_ENDIAN_DEFAULT) + [...] + /* Default floating point model is soft-VFP. + * FIXME: -mhard-float currently implies FPA. */ +#undef SUBTARGET_ASM_FLOAT_SPEC +#define SUBTARGET_ASM_FLOAT_SPEC \ + "%{mhard-float:-mfpu=fpa} \ + %{msoft-float:-mfpu=softvfp} \ + %{!mhard-float: \ + %{!msoft-float:-mfpu=softvfp}}" [...] + tdep->fp_model = ARM_FLOAT_SOFT_VFP; If you want the gory details, then I think they are as follows: - With no CPU specified the assembler assumes -msoft-fpa as a default, but it incorrectly marks the objects as being hard-fpa - With -mcpu=xscale the assembler defaults to -msoft-vfp and correctly marks the objects as such. - There's then no way to switch back to 'soft-fpa, but with the hard- fpa marking used by the default configuration. Did you add "--with-cpu=xscale" when you configured the (cross) compiler? If you do, you can drop the -mcpu=xscale when compiling. Its likely that Sam compiled the (uuencoded) xscale-be-elf.hal.o with the cross-compiler setup differently. Damn, I wish I had perforce access... Jim From owner-freebsd-arm@FreeBSD.ORG Wed Nov 15 12:01:08 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F38216A416; Wed, 15 Nov 2006 12:01:08 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A7A543D4C; Wed, 15 Nov 2006 12:01:06 +0000 (GMT) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.7/8.13.4) with ESMTP id kAFCFMUS039066; Wed, 15 Nov 2006 13:15:22 +0100 (CET) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.7/8.13.4/Submit) id kAFCFLpi039065; Wed, 15 Nov 2006 13:15:21 +0100 (CET) (envelope-from mlfbsd) Date: Wed, 15 Nov 2006 13:15:21 +0100 From: Olivier Houchard To: Jim Thompson Message-ID: <20061115121521.GA38995@ci0.org> References: <20061023163650.GA30024@zibbi.meraka.csir.co.za> <20061023211342.GA75533@ci0.org> <20061113140111.GA63047@zibbi.meraka.csir.co.za> <20061113143853.GA22089@ci0.org> <20061115091005.GA72236@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: freebsd-arm@freebsd.org, Sam Leffler Subject: Re: Gateworks 2348 any experience with it? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 12:01:08 -0000 On Wed, Nov 15, 2006 at 01:01:59AM -1000, Jim Thompson wrote: > > On Nov 14, 2006, at 11:10 PM, John Hay wrote: > > >ERROR: hal.o uses FPA instructions, whereas kernel.debug does not > >/home/jhay/cross/usr/bin/ld: failed to merge target specific data > >of file hal.o > > You can't mix the two FP models. See these lines in contrib-arm.diff: > > +#undef TARGET_DEFAULT > +#define TARGET_DEFAULT \ > + (ARM_FLAG_APCS_32 \ > + | ARM_FLAG_SOFT_FLOAT \ > + | ARM_FLAG_APCS_FRAME \ > + | ARM_FLAG_ATPCS \ > + | ARM_FLAG_VFP \ > + | ARM_FLAG_MMU_TRAPS \ > + | TARGET_ENDIAN_DEFAULT) > + > [...] > > + /* Default floating point model is soft-VFP. > + * FIXME: -mhard-float currently implies FPA. */ > +#undef SUBTARGET_ASM_FLOAT_SPEC > +#define SUBTARGET_ASM_FLOAT_SPEC \ > + "%{mhard-float:-mfpu=fpa} \ > + %{msoft-float:-mfpu=softvfp} \ > + %{!mhard-float: \ > + %{!msoft-float:-mfpu=softvfp}}" > > [...] > + tdep->fp_model = ARM_FLOAT_SOFT_VFP; > > > If you want the gory details, then I think they are as follows: > > - With no CPU specified the assembler assumes -msoft-fpa as a > default, but it incorrectly marks the objects as being hard-fpa > - With -mcpu=xscale the assembler defaults to -msoft-vfp and > correctly marks the objects as such. > - There's then no way to switch back to 'soft-fpa, but with the hard- > fpa marking used by the default configuration. > > Did you add "--with-cpu=xscale" when you configured the (cross) > compiler? If you do, you can drop the -mcpu=xscale > when compiling. > > Its likely that Sam compiled the (uuencoded) xscale-be-elf.hal.o with > the cross-compiler setup differently. > > Damn, I wish I had perforce access... > > Jim > Hi, This is not John's fault, unfortunately right now the ath hal modules in the src directory are compiled using FPA, while FreeBSD is compiled using VFP. You can use the small application at http://people.freebsd.org/~sam/wackelf.c to hack the ELF headers to make the hal binary VFP (it doesn't matter, because it doesn't actually use FP). Sam should update the hal modules soon. Cheers, Olivier From owner-freebsd-arm@FreeBSD.ORG Wed Nov 15 15:51:22 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C43B16A407 for ; Wed, 15 Nov 2006 15:51:22 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D1E243D5F for ; Wed, 15 Nov 2006 15:51:21 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id kAFFpFDC010473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Nov 2006 07:51:17 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <455B3772.2020403@errno.com> Date: Wed, 15 Nov 2006 07:51:14 -0800 From: Sam Leffler User-Agent: Thunderbird 1.5.0.7 (X11/20060920) MIME-Version: 1.0 To: John Hay References: <20061023163650.GA30024@zibbi.meraka.csir.co.za> <20061023211342.GA75533@ci0.org> <20061113140111.GA63047@zibbi.meraka.csir.co.za> <20061113143853.GA22089@ci0.org> <20061115091005.GA72236@zibbi.meraka.csir.co.za> <20061115121521.GA38995@ci0.org> In-Reply-To: <20061115121521.GA38995@ci0.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 any experience with it? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 15:51:22 -0000 Olivier Houchard wrote: > On Wed, Nov 15, 2006 at 01:01:59AM -1000, Jim Thompson wrote: >> On Nov 14, 2006, at 11:10 PM, John Hay wrote: >> >>> ERROR: hal.o uses FPA instructions, whereas kernel.debug does not >>> /home/jhay/cross/usr/bin/ld: failed to merge target specific data >>> of file hal.o >> You can't mix the two FP models. See these lines in contrib-arm.diff: >> >> +#undef TARGET_DEFAULT >> +#define TARGET_DEFAULT \ >> + (ARM_FLAG_APCS_32 \ >> + | ARM_FLAG_SOFT_FLOAT \ >> + | ARM_FLAG_APCS_FRAME \ >> + | ARM_FLAG_ATPCS \ >> + | ARM_FLAG_VFP \ >> + | ARM_FLAG_MMU_TRAPS \ >> + | TARGET_ENDIAN_DEFAULT) >> + >> [...] >> >> + /* Default floating point model is soft-VFP. >> + * FIXME: -mhard-float currently implies FPA. */ >> +#undef SUBTARGET_ASM_FLOAT_SPEC >> +#define SUBTARGET_ASM_FLOAT_SPEC \ >> + "%{mhard-float:-mfpu=fpa} \ >> + %{msoft-float:-mfpu=softvfp} \ >> + %{!mhard-float: \ >> + %{!msoft-float:-mfpu=softvfp}}" >> >> [...] >> + tdep->fp_model = ARM_FLOAT_SOFT_VFP; >> >> >> If you want the gory details, then I think they are as follows: >> >> - With no CPU specified the assembler assumes -msoft-fpa as a >> default, but it incorrectly marks the objects as being hard-fpa >> - With -mcpu=xscale the assembler defaults to -msoft-vfp and >> correctly marks the objects as such. >> - There's then no way to switch back to 'soft-fpa, but with the hard- >> fpa marking used by the default configuration. >> >> Did you add "--with-cpu=xscale" when you configured the (cross) >> compiler? If you do, you can drop the -mcpu=xscale >> when compiling. >> >> Its likely that Sam compiled the (uuencoded) xscale-be-elf.hal.o with >> the cross-compiler setup differently. >> >> Damn, I wish I had perforce access... >> >> Jim >> > > Hi, > > This is not John's fault, unfortunately right now the ath hal modules in > the src directory are compiled using FPA, while FreeBSD is compiled using > VFP. > You can use the small application at > http://people.freebsd.org/~sam/wackelf.c > to hack the ELF headers to make the hal binary VFP (it doesn't matter, because > it doesn't actually use FP). > Sam should update the hal modules soon. Correct. Newer versions of the hal will come ready for use but for now you need to patch the ELF header. I'll work on getting a newer hal together than can be dropped in in-place. The rest of the avila support code should appear in HEAD this week. I'm trying to cleanup some stuff beforehand to avoid churning the repo once it hits CVS. Sam From owner-freebsd-arm@FreeBSD.ORG Wed Nov 15 19:42:55 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96FAE16A4C2; Wed, 15 Nov 2006 19:42:55 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9B8C43E15; Wed, 15 Nov 2006 19:41:59 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 7033033CAA; Wed, 15 Nov 2006 21:41:41 +0200 (SAST) Date: Wed, 15 Nov 2006 21:41:41 +0200 From: John Hay To: Olivier Houchard Message-ID: <20061115194141.GB98910@zibbi.meraka.csir.co.za> References: <20061023163650.GA30024@zibbi.meraka.csir.co.za> <20061023211342.GA75533@ci0.org> <20061113140111.GA63047@zibbi.meraka.csir.co.za> <20061113143853.GA22089@ci0.org> <20061115091005.GA72236@zibbi.meraka.csir.co.za> <20061115121521.GA38995@ci0.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061115121521.GA38995@ci0.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@freebsd.org, Sam Leffler Subject: Re: Gateworks 2348 any experience with it? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 19:42:55 -0000 > > This is not John's fault, unfortunately right now the ath hal modules in > the src directory are compiled using FPA, while FreeBSD is compiled using > VFP. > You can use the small application at > http://people.freebsd.org/~sam/wackelf.c > to hack the ELF headers to make the hal binary VFP (it doesn't matter, because > it doesn't actually use FP). > Sam should update the hal modules soon. Ok, I got the kernel compiled with this and then my next step was to get the kernel in a shape that I can load it, so I tried the "make trampoline" that was mentioned on the list. That resulted in some errors because it couldn't find some include files. I ended up hacking the Makefile a bit until it compiled: ########################################### --- ../../../conf/Makefile.arm Wed Nov 15 07:56:35 2006 +++ Makefile Wed Nov 15 20:07:23 2006 @@ -77,10 +82,10 @@ -g --strip-symbol '$$t' ${FULLKERNEL} ${KERNEL_KO}.tmp eval $$(stat -s ${KERNEL_KO}.tmp) && \ echo "#define KERNSIZE $$st_size" >>opt_kernname.h - ${CC} -O -nostdlib -I. -Xlinker -T -Xlinker ldscript.$M.tramp \ + ${CC} -O -nostdlib -I. -I${S} -I/usr/include -Xlinker -T -Xlinker ldscript.$M.tramp \ $S/$M/$M/elf_trampoline.c $S/$M/$M/inckern.S ${FILES_CPU_FUNC} \ -o ${KERNEL_KO}.tramp - ${CC} -O -nostdlib -I. -Xlinker -T -Xlinker ldscript.$M.tramp.noheader \ + ${CC} -O -nostdlib -I. -I${S} -I/usr/include -Xlinker -T -Xlinker ldscript.$M.tramp.noheader \ $S/$M/$M/elf_trampoline.c $S/$M/$M/inckern.S ${FILES_CPU_FUNC} -o \ ${KERNEL_KO}.tramp.noheader ${OBJCOPY} -S -O binary ${KERNEL_KO}.tramp.noheader \ @@ -93,11 +98,11 @@ gzip -9 ${KERNEL_KO}.tmp eval $$(stat -s ${KERNEL_KO}.tmp.gz) && \ echo "#define KERNCOMPSIZE $$st_size" >>opt_kernname.h - ${CC} -O2 -DKZIP -I. -c $S/kern/inflate.c -o inflate-tramp.o - ${CC} -O -nostdlib -I. -Xlinker -T -Xlinker ldscript.$M.tramp \ + ${CC} -O2 -DKZIP -I. -I${S} -c $S/kern/inflate.c -o inflate-tramp.o + ${CC} -O -nostdlib -I. -I${S} -I/usr/include -Xlinker -T -Xlinker ldscript.$M.tramp \ -DKZIP $S/$M/$M/elf_trampoline.c inflate-tramp.o $S/$M/$M/inckern.S \ ${FILES_CPU_FUNC} -o ${KERNEL_KO}.gz.tramp - ${CC} -O -nostdlib -I. -Xlinker -T -Xlinker ldscript.$M.tramp.noheader \ + ${CC} -O -nostdlib -I. -I${S} -I/usr/include -Xlinker -T -Xlinker ldscript.$M.tramp.noheader \ -DKZIP $S/$M/$M/elf_trampoline.c inflate-tramp.o $S/$M/$M/inckern.S \ ${FILES_CPU_FUNC} -o ${KERNEL_KO}.tramp.noheader ${OBJCOPY} -S -O binary ${KERNEL_KO}.tramp.noheader \ ########################################### I didn't rewrap the lines, so that it is easier to see what I did. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-arm@FreeBSD.ORG Wed Nov 15 19:50:43 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55F9916A412 for ; Wed, 15 Nov 2006 19:50:43 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E4D943D5C for ; Wed, 15 Nov 2006 19:50:42 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id kAFJobRB012119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Nov 2006 11:50:39 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <455B6F8D.90307@errno.com> Date: Wed, 15 Nov 2006 11:50:37 -0800 From: Sam Leffler User-Agent: Thunderbird 1.5.0.7 (X11/20060920) MIME-Version: 1.0 To: John Hay References: <20061023163650.GA30024@zibbi.meraka.csir.co.za> <20061023211342.GA75533@ci0.org> <20061113140111.GA63047@zibbi.meraka.csir.co.za> <20061113143853.GA22089@ci0.org> <20061115091005.GA72236@zibbi.meraka.csir.co.za> <20061115121521.GA38995@ci0.org> <20061115194141.GB98910@zibbi.meraka.csir.co.za> In-Reply-To: <20061115194141.GB98910@zibbi.meraka.csir.co.za> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 any experience with it? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 19:50:43 -0000 John Hay wrote: >> This is not John's fault, unfortunately right now the ath hal modules in >> the src directory are compiled using FPA, while FreeBSD is compiled using >> VFP. >> You can use the small application at >> http://people.freebsd.org/~sam/wackelf.c >> to hack the ELF headers to make the hal binary VFP (it doesn't matter, because >> it doesn't actually use FP). >> Sam should update the hal modules soon. > > Ok, I got the kernel compiled with this and then my next step was to > get the kernel in a shape that I can load it, so I tried the "make > trampoline" that was mentioned on the list. That resulted in some > errors because it couldn't find some include files. I ended up > hacking the Makefile a bit until it compiled: > > ########################################### > --- ../../../conf/Makefile.arm Wed Nov 15 07:56:35 2006 > +++ Makefile Wed Nov 15 20:07:23 2006 > @@ -77,10 +82,10 @@ > -g --strip-symbol '$$t' ${FULLKERNEL} ${KERNEL_KO}.tmp > eval $$(stat -s ${KERNEL_KO}.tmp) && \ > echo "#define KERNSIZE $$st_size" >>opt_kernname.h > - ${CC} -O -nostdlib -I. -Xlinker -T -Xlinker ldscript.$M.tramp \ > + ${CC} -O -nostdlib -I. -I${S} -I/usr/include -Xlinker -T -Xlinker ldscript.$M.tramp \ > $S/$M/$M/elf_trampoline.c $S/$M/$M/inckern.S ${FILES_CPU_FUNC} \ > -o ${KERNEL_KO}.tramp > - ${CC} -O -nostdlib -I. -Xlinker -T -Xlinker ldscript.$M.tramp.noheader \ > + ${CC} -O -nostdlib -I. -I${S} -I/usr/include -Xlinker -T -Xlinker ldscript.$M.tramp.noheader \ > $S/$M/$M/elf_trampoline.c $S/$M/$M/inckern.S ${FILES_CPU_FUNC} -o \ > ${KERNEL_KO}.tramp.noheader > ${OBJCOPY} -S -O binary ${KERNEL_KO}.tramp.noheader \ > @@ -93,11 +98,11 @@ > gzip -9 ${KERNEL_KO}.tmp > eval $$(stat -s ${KERNEL_KO}.tmp.gz) && \ > echo "#define KERNCOMPSIZE $$st_size" >>opt_kernname.h > - ${CC} -O2 -DKZIP -I. -c $S/kern/inflate.c -o inflate-tramp.o > - ${CC} -O -nostdlib -I. -Xlinker -T -Xlinker ldscript.$M.tramp \ > + ${CC} -O2 -DKZIP -I. -I${S} -c $S/kern/inflate.c -o inflate-tramp.o > + ${CC} -O -nostdlib -I. -I${S} -I/usr/include -Xlinker -T -Xlinker ldscript.$M.tramp \ > -DKZIP $S/$M/$M/elf_trampoline.c inflate-tramp.o $S/$M/$M/inckern.S \ > ${FILES_CPU_FUNC} -o ${KERNEL_KO}.gz.tramp > - ${CC} -O -nostdlib -I. -Xlinker -T -Xlinker ldscript.$M.tramp.noheader \ > + ${CC} -O -nostdlib -I. -I${S} -I/usr/include -Xlinker -T -Xlinker ldscript.$M.tramp.noheader \ > -DKZIP $S/$M/$M/elf_trampoline.c inflate-tramp.o $S/$M/$M/inckern.S \ > ${FILES_CPU_FUNC} -o ${KERNEL_KO}.tramp.noheader > ${OBJCOPY} -S -O binary ${KERNEL_KO}.tramp.noheader \ > ########################################### > > I didn't rewrap the lines, so that it is easier to see what I did. John, if you can be patient a little longer you'll be able to build working systems from CVS HEAD w/o any hacks. I've been booting with an NFS-mounted root over the onboard Ethernet for a while. The ath driver is known to work and I've recently gotten the CF-IDE slot and several other bits and pieces working. I was waiting to commit to CVS before posting about things but the main parts that are not yet working are: 1. 2nd Ethernet port. 2. Flash. 3. RTC (working on that now) 4. I2C sensors for temp and voltage (trivial once we have i2c working properly). 5. NPE crypto acceleration (may be a while; still waiting for Intel to release stuff to me). Past that we haven't ironed out how to boot from CF. We can either stick a bootstrap in flash and have redboot load that or we can stick a kernel in flash. Once flash can be r/w from freebsd I have a tool for reading and writing redboot config parameters that can be used to simplify some of this. Sam From owner-freebsd-arm@FreeBSD.ORG Thu Nov 16 08:17:31 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EBF416A403 for ; Thu, 16 Nov 2006 08:17:31 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 368F243D58 for ; Thu, 16 Nov 2006 08:17:31 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kAG8H1cn002738; Thu, 16 Nov 2006 01:17:04 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 16 Nov 2006 01:17:40 -0700 (MST) Message-Id: <20061116.011740.1973602549.imp@bsdimp.com> To: sam@errno.com From: "M. Warner Losh" In-Reply-To: <455B6F8D.90307@errno.com> References: <20061115121521.GA38995@ci0.org> <20061115194141.GB98910@zibbi.meraka.csir.co.za> <455B6F8D.90307@errno.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 16 Nov 2006 01:17:05 -0700 (MST) Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 any experience with it? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 08:17:31 -0000 In message: <455B6F8D.90307@errno.com> Sam Leffler writes: : Past that we haven't ironed out how to boot from CF. We can either : stick a bootstrap in flash and have redboot load that or we can stick a : kernel in flash. Once flash can be r/w from freebsd I have a tool for : reading and writing redboot config parameters that can be used to : simplify some of this. I'm guessing that the boot2 work I did for the atmel part may be relevant here. Place it in a small area redboot can load, and have it do the rest. Should be ballpark 12k depending on what all is needed from it. Flash should be read/write soonish. After man snags, I'm getting two of the xscale boards... the 2 port that Sam has been working on and the cheaper 4 port version... Warner From owner-freebsd-arm@FreeBSD.ORG Thu Nov 16 15:56:20 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2BC616A40F for ; Thu, 16 Nov 2006 15:56:20 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A17443D60 for ; Thu, 16 Nov 2006 15:56:18 +0000 (GMT) (envelope-from bounces@nabble.com) Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1Gkjb7-0000nQ-SK for freebsd-arm@freebsd.org; Thu, 16 Nov 2006 07:56:17 -0800 Message-ID: <7380637.post@talk.nabble.com> Date: Thu, 16 Nov 2006 07:56:17 -0800 (PST) From: Zuy To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: zaitsevbros@mail.ru Subject: At91rm9200 how to start with FreeBSD X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 15:56:20 -0000 Hello, How I'm soldering board based on AT91RM9200 with 16mb SDRAM and othe standartpPeripherals(USB, SD, UART ...). I'm going to run FreeBSD on this board, but unfortunately I do not know how to start. I havn't found any files connected with AT91RM9200 in FreeBSD6.0 Stable source files directory. I found from this board that freebsd works on at91rm9200. I will deeply appreciate if someone could give me any information how to start working with freebsd on this controller. May any type of tutorial is available. I also interesting in main spets I have to do to get freeBSD working on at91rm9200. Thank you. -- View this message in context: http://www.nabble.com/At91rm9200-how-to-start-with-FreeBSD-tf2643928.html#a7380637 Sent from the freebsd-arm mailing list archive at Nabble.com. From owner-freebsd-arm@FreeBSD.ORG Thu Nov 16 16:38:44 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A36316A47E for ; Thu, 16 Nov 2006 16:38:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2228243D5F for ; Thu, 16 Nov 2006 16:38:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kAGGZxBd013605; Thu, 16 Nov 2006 09:36:00 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 16 Nov 2006 09:36:38 -0700 (MST) Message-Id: <20061116.093638.63053940.imp@bsdimp.com> To: zaitsevbros@mail.ru From: "M. Warner Losh" In-Reply-To: <7380637.post@talk.nabble.com> References: <7380637.post@talk.nabble.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 16 Nov 2006 09:36:00 -0700 (MST) Cc: freebsd-arm@freebsd.org Subject: Re: At91rm9200 how to start with FreeBSD X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 16:38:44 -0000 In message: <7380637.post@talk.nabble.com> Zuy writes: : How I'm soldering board based on AT91RM9200 with 16mb SDRAM and othe : standartpPeripherals(USB, SD, UART ...). I'm going to run FreeBSD on this : board, but unfortunately I do not know how to start. : I havn't found any files connected with AT91RM9200 in FreeBSD6.0 Stable : source files directory. : I found from this board that freebsd works on at91rm9200. Yes. It does. FreeBSD-current has the most up to date tested code for this platform. FreeBSD 6.2 will contain the tools you need to build it, as well as a slightly less advanced version (the freeze date for 6.2 was a while ago). 6.3 is likely to have even more advanced support. : I will deeply appreciate if someone could give me any information how to : start working with freebsd on this controller. May any type of tutorial is : available. : I also interesting in main spets I have to do to get freeBSD working on : at91rm9200. At this point there's no "how to" tutorial. Each of the different boards based on the at91rm9200 seem to have different boot processes. This makes it hard to write something that's generic, but I may try. Here's the broad outlines. First, your board will need to have some kind of bootstrap media. The atmel part supports parallel flash, iic flash, and spi flash. Once you have the basic bootstrap loaded, you will need to load a kernel and file system from somewhere. Given that your board is small, and that you have only 16MB of SDRAM, I'd recommend using the SD card for your main storage. If you do this, then all you need in your bootstrap is enough storage to load from the SD card, as well as storing the MAC address. The bootloader is responsible for progarmming the NIC's MAC address. The 'boot2' program allows for one to customize how things are done with it and load off of an SD card. It takes about 9kB of space right now. The Kwikbyte KB9202 board that I used has a 16kB IIC EEPROM that this loader will fit into. I use the upper part (last 256bytes) of the IIC to store the MAC address. This program should be fairly easy to modify and adapt to your needs. I've tried to make it as generic possible, but some custom work might be needed. There's some bootstrap tools called boot0, boot0iic and boot0spi that will load and run a program, load and burn to iic an image and load and burn to spi flash respectively. The AT91RM9200 goes into 'baby bird' mode if none of its boot images are good. This is nothing more than xmodem. When I bring a board up, I usually load boot0iic and boot2 using xmodem. It turns out to be quiet simple. Each board has some low-level init that is the hardest part to get right since you have to know the base clock frequency as well as the organization of the SDRAM. Once you have 'boot2' loading from some media, then you need to get it loading a kernel from an SD card. Today, you have to load a kernel linked to be loaded at a physical address (cognet sent me patches to allow virtual too, but my KB9202's iic eeprom is dead). There's a special kernel target call 'trampoline' or 'kernel.tramp' that will create a compressed image suitable for booting (use kernel.gz.tramp). An alternative is to use bootiic or bootspi to load a kernel image from somewhere and jump to it. To make the bootable SD card, I've been using some custom scripts that I've had laying around forever for some semi-embedded FreeBSD/i386 work that my company has been doing for the past 10 or so years. Most other people I know do some variation on: # plug in the SD card to a usb whatsit and load umass % fdisk -I da0 % disklabel -w -r da0s1 auto % newfs /dev/da0s1a % mount /dev/da0s1a /mnt % cd /usr/src % setenv TARGET arm % setenv TARGET_ARCH arm % make buildworld % make distribution DESTDIR=/mnt % make installworld DESTDIR=/mnt # hack /etc/rc.conf, /etc/fstab and /etc/ttys % umount /mnt But others have also used NanoBSD to automate things somewhat. Freesbie also has some basic cross compilation support. FreeBSD -current will give you the most support, but 6.2-release will have most of the basics, including the build tools. After the RELENG_6 branch is unfrozen, I'll be doing another merge of all the goodies that I've done. One caveat. The usb support is minimal at this stage. There's some issues that we're trying to track down that keep it from working. My company doesn't need usb (but that may change after the latest hardware review), so I've spent no energy there. Feel free to ask questions. the more people that ask, the bigger my collection of email on the topic gets, and the easier it will be for me to synthesize a tutorial. Also, if there are areas that I've been vague, please don't hesitate to let me know. Warner From owner-freebsd-arm@FreeBSD.ORG Fri Nov 17 08:30:19 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B62F16A403 for ; Fri, 17 Nov 2006 08:30:19 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1589B43D55 for ; Fri, 17 Nov 2006 08:30:18 +0000 (GMT) (envelope-from bounces@nabble.com) Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1Gkz74-0005Qt-AY for freebsd-arm@freebsd.org; Fri, 17 Nov 2006 00:30:18 -0800 Message-ID: <7395689.post@talk.nabble.com> Date: Fri, 17 Nov 2006 00:30:18 -0800 (PST) From: Zuy To: freebsd-arm@freebsd.org In-Reply-To: <20061116.093638.63053940.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: zaitsevbros@mail.ru References: <7380637.post@talk.nabble.com> <20061116.093638.63053940.imp@bsdimp.com> Subject: Re: At91rm9200 how to start with FreeBSD X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 08:30:19 -0000 Thank you very much. I was realy impressed to get such a quick and detailed answer. My board includes SD card and 1mb Serial DataFlash. I'm going to use dataflash to store bootstrap tools which will load kernel from SD card. But your board has 16 MB parallel NOR Flash and 32 MB parallel NAND Flash. Why you do not use this flash memory for storing and runing bootstrap tools? You mentioned bootstrap tools such as boot0, boot0iic, boot0spi and boot2. Where can I get them? Boot0 and boot2 I found in /usr/src/sys/boot but there is no folder for ARM. I use FreeBSD 6.0 (6.2 is downloading now) may be that is the reason. And the last question about compilation process. As you wrote, following sequence will give the compiled OS for arm architecture: % setenv TARGET arm % setenv TARGET_ARCH arm % make buildworld % make distribution DESTDIR=/mnt % make installworld DESTDIR=/mnt But how the system will know that I need compilation for ARM9. Where it will get drivers for basic internal peripherals of AR91RM9200? I think that I have to prepare configuration file like I do for compiling kernel for I386, but I cannot find it. It looks like they are in the /usr/src/sys/arm/conf. I found there two files IQ31244 and SIMICS. Probably they are configuration files for IQ31244 and SIMICS development boards. So I think I have to make the same file for AT91RM9200. May be you can give me the idea where to get such file like an example? Best regards, Ivan Zaitsev. M. Warner Losh wrote: > > In message: <7380637.post@talk.nabble.com> > Zuy writes: > : How I'm soldering board based on AT91RM9200 with 16mb SDRAM and othe > : standartpPeripherals(USB, SD, UART ...). I'm going to run FreeBSD on > this > : board, but unfortunately I do not know how to start. > : I havn't found any files connected with AT91RM9200 in FreeBSD6.0 Stable > : source files directory. > : I found from this board that freebsd works on at91rm9200. > > Yes. It does. FreeBSD-current has the most up to date tested code > for this platform. FreeBSD 6.2 will contain the tools you need to > build it, as well as a slightly less advanced version (the freeze date > for 6.2 was a while ago). 6.3 is likely to have even more advanced > support. > > : I will deeply appreciate if someone could give me any information how to > : start working with freebsd on this controller. May any type of tutorial > is > : available. > : I also interesting in main spets I have to do to get freeBSD working on > : at91rm9200. > > At this point there's no "how to" tutorial. Each of the different > boards based on the at91rm9200 seem to have different boot processes. > This makes it hard to write something that's generic, but I may try. > > Here's the broad outlines. > > First, your board will need to have some kind of bootstrap media. > The atmel part supports parallel flash, iic flash, and spi flash. > Once you have the basic bootstrap loaded, you will need to load a > kernel and file system from somewhere. > > Given that your board is small, and that you have only 16MB of SDRAM, > I'd recommend using the SD card for your main storage. If you do > this, then all you need in your bootstrap is enough storage to load > from the SD card, as well as storing the MAC address. The bootloader > is responsible for progarmming the NIC's MAC address. The 'boot2' > program allows for one to customize how things are done with it and > load off of an SD card. It takes about 9kB of space right now. The > Kwikbyte KB9202 board that I used has a 16kB IIC EEPROM that this > loader will fit into. I use the upper part (last 256bytes) of the IIC > to store the MAC address. This program should be fairly easy to > modify and adapt to your needs. I've tried to make it as generic > possible, but some custom work might be needed. > > There's some bootstrap tools called boot0, boot0iic and boot0spi that > will load and run a program, load and burn to iic an image and load > and burn to spi flash respectively. The AT91RM9200 goes into 'baby > bird' mode if none of its boot images are good. This is nothing more > than xmodem. When I bring a board up, I usually load boot0iic and > boot2 using xmodem. It turns out to be quiet simple. Each board has > some low-level init that is the hardest part to get right since you > have to know the base clock frequency as well as the organization of > the SDRAM. > > Once you have 'boot2' loading from some media, then you need to get it > loading a kernel from an SD card. Today, you have to load a kernel > linked to be loaded at a physical address (cognet sent me patches to > allow virtual too, but my KB9202's iic eeprom is dead). There's a > special kernel target call 'trampoline' or 'kernel.tramp' that will > create a compressed image suitable for booting (use kernel.gz.tramp). > > An alternative is to use bootiic or bootspi to load a kernel image > from somewhere and jump to it. > > To make the bootable SD card, I've been using some custom scripts that > I've had laying around forever for some semi-embedded FreeBSD/i386 > work that my company has been doing for the past 10 or so years. Most > other people I know do some variation on: > > # plug in the SD card to a usb whatsit and load umass > % fdisk -I da0 > % disklabel -w -r da0s1 auto > % newfs /dev/da0s1a > % mount /dev/da0s1a /mnt > % cd /usr/src > % setenv TARGET arm > % setenv TARGET_ARCH arm > % make buildworld > % make distribution DESTDIR=/mnt > % make installworld DESTDIR=/mnt > # hack /etc/rc.conf, /etc/fstab and /etc/ttys > % umount /mnt > > But others have also used NanoBSD to automate things somewhat. > Freesbie also has some basic cross compilation support. FreeBSD > -current will give you the most support, but 6.2-release will have > most of the basics, including the build tools. After the RELENG_6 > branch is unfrozen, I'll be doing another merge of all the goodies > that I've done. > > One caveat. The usb support is minimal at this stage. There's some > issues that we're trying to track down that keep it from working. My > company doesn't need usb (but that may change after the latest > hardware review), so I've spent no energy there. > > Feel free to ask questions. the more people that ask, the bigger my > collection of email on the topic gets, and the easier it will be for > me to synthesize a tutorial. Also, if there are areas that I've been > vague, please don't hesitate to let me know. > > Warner > _______________________________________________ > 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" > > -- View this message in context: http://www.nabble.com/At91rm9200-how-to-start-with-FreeBSD-tf2643928.html#a7395689 Sent from the freebsd-arm mailing list archive at Nabble.com. From owner-freebsd-arm@FreeBSD.ORG Fri Nov 17 10:39:13 2006 Return-Path: X-Original-To: freebsd-arm@FreeBSD.org Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 573FD16A412 for ; Fri, 17 Nov 2006 10:39:13 +0000 (UTC) (envelope-from Offers@LetsGoHoliday.com) Received: from krypton2.melitacable.com (smtp.onvol.net [212.56.128.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEC8443D82 for ; Fri, 17 Nov 2006 10:39:10 +0000 (GMT) (envelope-from Offers@LetsGoHoliday.com) Received: from smtp.arrigogroup.com.mt ([212.56.143.66]) by krypton2.melitacable.com (8.13.6/8.13.6) with SMTP id kAHAg1GK078497 for ; Fri, 17 Nov 2006 11:42:01 +0100 (CET) Organization: LetsGoHoliday.com Message-ID: <50846c416b4b25d1fb75f1a0001ed0be@letsgoholiday.com> From: "LetsGoHoliday.com" To: Date: Fri, 17 Nov 2006 07:22:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: New Year Abroad from Lm99 - LetsGoHoliday.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Offers@LetsGoHoliday.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 10:39:13 -0000 BOOK ONLINE NOW and SAVE 10% on World-Wide Hotels! Go to: http://www.letsgohotels.com=20 ------------------------------------------------------------------- CELEBRATE THE NEW YEAR IN BUDAPEST! - 27 December - 01 January 2007 Package from: Lm 99.00 - BOOK NOW... SEATS ARE LIMITED!!! http://www.letsgoholiday.com/holidays/budapest/index.asp ------------------------------------------------------------------- SKIING IN BANKSO (BULGARIA) 22 - 29 January & 08 - 15 March From: Lm 194.00 per person in triple sharing http://www.letsgoholiday.com/holidays/bansko/group/ SKIING IN KRANJSKA GORA (SLOVENIA) 02 - 09 January >From : Lm 233.00 per person in triple sharing http://www.letsgoholiday.com/holidays/kranjska/groups/ Other individual ski packages also available=2E ------------------------------------------------------------------- LETSGOHOLIDAY.COM http://www.letsgoholiday.com - Your one stop travel shop E-mail: info@letsgoholiday.com Call Center: +356 23492204/5 Address: ATV Travel, 250 Tower Rd, Sliema SLM05 MALTA ------------------------------------------------------------------- Kindly inform us should you not, or no longer, wish to receive any = marketing or promotional information from LetsGoHoliday.com. You have the = right to require that LetsGoHoliday.com provide you with access to your = personal data as well as the right to rectify, or, in appropriate = circumstances, erase any inaccurate, incomplete or immaterial personal = data which is being processed. However, kindly inform LetsGoHoliday.com of = any alterations relating to your personal data which is being processed. = LetsGoHoliday.com undertakes to implement appropriate measures and = safeguards for the purpose of protecting the confidentiality, integrity = and availability of all data processed=2E ------------------------------------------------------------------- To unsubscribe from our mailing list, please click here and enter your e-mail: http://www.letsgoholiday.com/subscribe From owner-freebsd-arm@FreeBSD.ORG Sat Nov 18 08:27:46 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AEA3716A417 for ; Sat, 18 Nov 2006 08:27:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 700B343D53 for ; Sat, 18 Nov 2006 08:27:44 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kAI8QHrW001821; Sat, 18 Nov 2006 01:26:18 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 18 Nov 2006 01:26:59 -0700 (MST) Message-Id: <20061118.012659.-1876864065.imp@bsdimp.com> To: zaitsevbros@mail.ru From: "M. Warner Losh" In-Reply-To: <7395689.post@talk.nabble.com> References: <7380637.post@talk.nabble.com> <20061116.093638.63053940.imp@bsdimp.com> <7395689.post@talk.nabble.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 18 Nov 2006 01:26:18 -0700 (MST) Cc: freebsd-arm@freebsd.org Subject: Re: At91rm9200 how to start with FreeBSD X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 08:27:46 -0000 In message: <7395689.post@talk.nabble.com> Zuy writes: : Thank you very much. : I was realy impressed to get such a quick and detailed answer. : : My board includes SD card and 1mb Serial DataFlash. I'm going to use : dataflash to store bootstrap tools which will load kernel from SD card. But : your board has 16 MB parallel NOR Flash and 32 MB parallel NAND Flash. : Why you do not use this flash memory for storing and runing bootstrap tools? Well, the KB9202B has the 16MB of NOR Flash. The A does not. The 32MB parallel NAND flash isn't available on the custom board that my company is building. In fact, I was told initially that I'd be lucky to get a 256kB part, and 240kB would be for an FPGA image... : You mentioned bootstrap tools such as boot0, boot0iic, boot0spi and boot2. : Where can I get them? : Boot0 and boot2 I found in /usr/src/sys/boot but there is no folder for ARM. : I use FreeBSD 6.0 (6.2 is downloading now) may be that is the reason. In -current, they can be found in /usr/src/sys/boot/arm/at91, as well as on 6.2. I believe that the 6.2 versions are less advanced. : And the last question about compilation process. As you wrote, following : sequence will give the compiled OS for arm architecture: : % setenv TARGET arm : % setenv TARGET_ARCH arm : % make buildworld : % make distribution DESTDIR=/mnt : % make installworld DESTDIR=/mnt : : But how the system will know that I need compilation for ARM9. Where it will : get drivers for basic internal peripherals of AR91RM9200? I think that I : have to prepare configuration file like I do for compiling kernel for I386, : but I cannot find it. It looks like they are in the /usr/src/sys/arm/conf. I : found there two files IQ31244 and SIMICS. Probably they are configuration : files for IQ31244 and SIMICS development boards. So I think I have to make : the same file for AT91RM9200. May be you can give me the idea where to get : such file like an example? You are correct in that you need a config file. In 6.2 and current there is a KB920X file that can be used as a basis for this support. Warner : Best regards, : Ivan Zaitsev. : : : M. Warner Losh wrote: : > : > In message: <7380637.post@talk.nabble.com> : > Zuy writes: : > : How I'm soldering board based on AT91RM9200 with 16mb SDRAM and othe : > : standartpPeripherals(USB, SD, UART ...). I'm going to run FreeBSD on : > this : > : board, but unfortunately I do not know how to start. : > : I havn't found any files connected with AT91RM9200 in FreeBSD6.0 Stable : > : source files directory. : > : I found from this board that freebsd works on at91rm9200. : > : > Yes. It does. FreeBSD-current has the most up to date tested code : > for this platform. FreeBSD 6.2 will contain the tools you need to : > build it, as well as a slightly less advanced version (the freeze date : > for 6.2 was a while ago). 6.3 is likely to have even more advanced : > support. : > : > : I will deeply appreciate if someone could give me any information how to : > : start working with freebsd on this controller. May any type of tutorial : > is : > : available. : > : I also interesting in main spets I have to do to get freeBSD working on : > : at91rm9200. : > : > At this point there's no "how to" tutorial. Each of the different : > boards based on the at91rm9200 seem to have different boot processes. : > This makes it hard to write something that's generic, but I may try. : > : > Here's the broad outlines. : > : > First, your board will need to have some kind of bootstrap media. : > The atmel part supports parallel flash, iic flash, and spi flash. : > Once you have the basic bootstrap loaded, you will need to load a : > kernel and file system from somewhere. : > : > Given that your board is small, and that you have only 16MB of SDRAM, : > I'd recommend using the SD card for your main storage. If you do : > this, then all you need in your bootstrap is enough storage to load : > from the SD card, as well as storing the MAC address. The bootloader : > is responsible for progarmming the NIC's MAC address. The 'boot2' : > program allows for one to customize how things are done with it and : > load off of an SD card. It takes about 9kB of space right now. The : > Kwikbyte KB9202 board that I used has a 16kB IIC EEPROM that this : > loader will fit into. I use the upper part (last 256bytes) of the IIC : > to store the MAC address. This program should be fairly easy to : > modify and adapt to your needs. I've tried to make it as generic : > possible, but some custom work might be needed. : > : > There's some bootstrap tools called boot0, boot0iic and boot0spi that : > will load and run a program, load and burn to iic an image and load : > and burn to spi flash respectively. The AT91RM9200 goes into 'baby : > bird' mode if none of its boot images are good. This is nothing more : > than xmodem. When I bring a board up, I usually load boot0iic and : > boot2 using xmodem. It turns out to be quiet simple. Each board has : > some low-level init that is the hardest part to get right since you : > have to know the base clock frequency as well as the organization of : > the SDRAM. : > : > Once you have 'boot2' loading from some media, then you need to get it : > loading a kernel from an SD card. Today, you have to load a kernel : > linked to be loaded at a physical address (cognet sent me patches to : > allow virtual too, but my KB9202's iic eeprom is dead). There's a : > special kernel target call 'trampoline' or 'kernel.tramp' that will : > create a compressed image suitable for booting (use kernel.gz.tramp). : > : > An alternative is to use bootiic or bootspi to load a kernel image : > from somewhere and jump to it. : > : > To make the bootable SD card, I've been using some custom scripts that : > I've had laying around forever for some semi-embedded FreeBSD/i386 : > work that my company has been doing for the past 10 or so years. Most : > other people I know do some variation on: : > : > # plug in the SD card to a usb whatsit and load umass : > % fdisk -I da0 : > % disklabel -w -r da0s1 auto : > % newfs /dev/da0s1a : > % mount /dev/da0s1a /mnt : > % cd /usr/src : > % setenv TARGET arm : > % setenv TARGET_ARCH arm : > % make buildworld : > % make distribution DESTDIR=/mnt : > % make installworld DESTDIR=/mnt : > # hack /etc/rc.conf, /etc/fstab and /etc/ttys : > % umount /mnt : > : > But others have also used NanoBSD to automate things somewhat. : > Freesbie also has some basic cross compilation support. FreeBSD : > -current will give you the most support, but 6.2-release will have : > most of the basics, including the build tools. After the RELENG_6 : > branch is unfrozen, I'll be doing another merge of all the goodies : > that I've done. : > : > One caveat. The usb support is minimal at this stage. There's some : > issues that we're trying to track down that keep it from working. My : > company doesn't need usb (but that may change after the latest : > hardware review), so I've spent no energy there. : > : > Feel free to ask questions. the more people that ask, the bigger my : > collection of email on the topic gets, and the easier it will be for : > me to synthesize a tutorial. Also, if there are areas that I've been : > vague, please don't hesitate to let me know. : > : > Warner : > _______________________________________________ : > 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" : > : > : : -- : View this message in context: http://www.nabble.com/At91rm9200-how-to-start-with-FreeBSD-tf2643928.html#a7395689 : Sent from the freebsd-arm mailing list archive at Nabble.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 Sat Nov 18 21:30:38 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 46C9316A513 for ; Sat, 18 Nov 2006 21:30:38 +0000 (UTC) (envelope-from modified@opsec.com) Received: from [83.31.24.223] (cia223.neoplus.adsl.tpnet.pl [83.31.24.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id 774A443E1C for ; Sat, 18 Nov 2006 21:29:44 +0000 (GMT) (envelope-from modified@opsec.com) Message-ID: <000f01c70b58$a9976f50$00000000@star> From: "details registered" To: freebsd-arm@freebsd.org Date: Sat, 18 Nov 2006 22:29:43 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01C70B61.0B5BD750" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: date youre getting X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 21:30:38 -0000 ------=_NextPart_000_000B_01C70B61.0B5BD750 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Stocks Quotes in attachement Bishop am Comments am metal? During monthtonys required graduate am. Triangle icon usually activates. Likes ereader isilo is essential or downloads. Change Gonna in Comea Christmas! Candidates get Handy Learning a share probeware reference programs help. ------=_NextPart_000_000B_01C70B61.0B5BD750--