From owner-freebsd-arm@FreeBSD.ORG Mon Oct 10 06:30:50 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB297106564A for ; Mon, 10 Oct 2011 06:30:50 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from gpo1.cc.swin.edu.au (gpo1.cc.swin.edu.au [136.186.1.30]) by mx1.freebsd.org (Postfix) with ESMTP id 4EAAB8FC14 for ; Mon, 10 Oct 2011 06:30:49 +0000 (UTC) Received: from mrossi.caia.swin.edu.au (mrossi.caia.swin.edu.au [136.186.229.109]) by gpo1.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id p9A6UNw9025773 for ; Mon, 10 Oct 2011 17:30:44 +1100 Message-ID: <4E9290FF.7090306@swin.edu.au> Date: Mon, 10 Oct 2011 17:30:23 +1100 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111004 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Create FAT partition/filesystem on the internal microSD flash of the Dreamplug 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, 10 Oct 2011 06:30:50 -0000 Hi all again, I've now been on to this for quite a while, but just can't get it to work. I've mistakenly blown away the partitioning scheme that the dreamplug came with originally, therefore also the FAT boot partition. I've tried to recreate it using gpart and newfs_msdos, but can't create any new FAT partition that mount_msdosfs would mount. See: dreamplug# gpart create -s mbr da0 da0 created dreamplug# gpart add -t fat32 -i 1 -s 32M da0 da0s1 added dreamplug# newfs_msdos da0s1 /dev/da0s1: 65416 sectors in 8177 FAT16 clusters (4096 bytes/cluster) BytesPerSec=512 SecPerClust=8 ResSectors=1 FATs=2 RootDirEnts=512 Sectors=65520 Media=0xf0 FATsecs=32 SecPerTrack=63 Heads=255 HiddenSecs=0 dreamplug# mount_msdosfs /dev/da0s1 /mnt/usb mount_msdosfs: /dev/da0s1: Invalid argument I've tried to change the partition type to 6 and 4 and to freebsd (165), but didn't help. I also tried to set the start of the partition (-b) to 64, 128 and 192 but nothing there either. Trying to tune newfs_msdos to use FAT 12 or FAT 32 and different bytes/sec or a different mediatype (0xf8) and a variety of tweaks did not help either. It seems that I can't create a mountable FAT partition. I believe the problem is that gpart create -s mbr starts the partitioning scheme at an offset of 63 sectors, while the one on the external SD card I have (pre-partitioned not using FreeBSD) has an offset of 32 sectors. I couldn't find any documentation that tells me how to tell gpart create to use a different offset. Any hints? Mat From owner-freebsd-arm@FreeBSD.ORG Mon Oct 10 08:06:34 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E6CD106566B for ; Mon, 10 Oct 2011 08:06:34 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from outbound.icp-osb-irony-out8.iinet.net.au (outbound.icp-osb-irony-out8.iinet.net.au [203.59.1.134]) by mx1.freebsd.org (Postfix) with ESMTP id 1BFFA8FC08 for ; Mon, 10 Oct 2011 08:06:33 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMBAMWmkk7KoR+Q/2dsb2JhbAAMN6YUhFwBAQEBAzhAEQsNCwkWDwkDAgECAUUTCAEBtSeJAodDBJN3hUmMHQ X-IronPort-AV: E=Sophos;i="4.68,516,1312128000"; d="scan'208";a="157982429" Received: from unknown (HELO [192.168.15.65]) ([202.161.31.144]) by outbound.icp-osb-irony-out8.iinet.net.au with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 10 Oct 2011 16:06:31 +0800 Message-ID: <4E92A78C.7040503@swin.edu.au> Date: Mon, 10 Oct 2011 19:06:36 +1100 From: Mattia Rossi Organization: Swinburne University of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <4E9290FF.7090306@swin.edu.au> In-Reply-To: <4E9290FF.7090306@swin.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Create FAT partition/filesystem on the internal microSD flash of the Dreamplug X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mrossi@swin.edu.au List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 08:06:34 -0000 On 10/10/11 17:30, Mattia Rossi wrote: > Hi all again, > > I've now been on to this for quite a while, but just can't get it to work. > I've mistakenly blown away the partitioning scheme that the dreamplug > came with originally, therefore also the FAT boot partition. > > I've tried to recreate it using gpart and newfs_msdos, but can't create > any new FAT partition that mount_msdosfs would mount. > > See: > > dreamplug# gpart create -s mbr da0 > da0 created > dreamplug# gpart add -t fat32 -i 1 -s 32M da0 > da0s1 added > dreamplug# newfs_msdos da0s1 > /dev/da0s1: 65416 sectors in 8177 FAT16 clusters (4096 bytes/cluster) > BytesPerSec=512 SecPerClust=8 ResSectors=1 FATs=2 RootDirEnts=512 > Sectors=65520 Media=0xf0 FATsecs=32 SecPerTrack=63 Heads=255 HiddenSecs=0 > dreamplug# mount_msdosfs /dev/da0s1 /mnt/usb > mount_msdosfs: /dev/da0s1: Invalid argument > > I've tried to change the partition type to 6 and 4 and to freebsd (165), > but didn't help. > I also tried to set the start of the partition (-b) to 64, 128 and 192 > but nothing there either. > > Trying to tune newfs_msdos to use FAT 12 or FAT 32 and different > bytes/sec or a different mediatype (0xf8) and a variety of tweaks did > not help either. > > It seems that I can't create a mountable FAT partition. > > I believe the problem is that gpart create -s mbr starts the > partitioning scheme at an offset of 63 sectors, while the one on the > external SD card I have (pre-partitioned not using FreeBSD) has an > offset of 32 sectors. > > I couldn't find any documentation that tells me how to tell gpart create > to use a different offset. > > Any hints? > I think something is wrong with newfs_msdos. Might be an issue with FreeBSD-9. I'm using: FreeBSD dreamplug 9.0-BETA3 FreeBSD 9.0-BETA3 #22 r226165 I tried the following: I partitioned the external SD card using gpart, then took the card out and put it in my laptop running Linux. There I formatted it using mkfs.vfat with no options (the card could be mounted properly), and put the card back into the dreamplug which I rebooted before, to make sure that no USB weirdness gets into my way. Then I mounted the card and it worked! dreamplug# mount_msdosfs /dev/da1s1 /mnt/sd/ dreamplug# umount /mnt/sd So I checked the format options: dreamplug# newfs_msdos -N /dev/da1s1 /dev/da1s1: 1994688 sectors in 62334 FAT16 clusters (16384 bytes/cluster) BytesPerSec=512 SecPerClust=32 ResSectors=1 FATs=2 RootDirEnts=512 Media=0xf0 FA Tsecs=244 SecPerTrack=32 Heads=64 HiddenSecs=0 HugeSectors=1995232 Then I reformatted the card using newfs_msdos with the -F16 options to make sure it uses FAT16 as above: dreamplug# newfs_msdos -F16 /dev/da1s1 /dev/da1s1: 1994688 sectors in 62334 FAT16 clusters (16384 bytes/cluster) BytesPerSec=512 SecPerClust=32 ResSectors=1 FATs=2 RootDirEnts=512 Media=0xf0 FA Tsecs=244 SecPerTrack=32 Heads=64 HiddenSecs=0 HugeSectors=1995232 You'll see exactly the same options.. Then I tried to mount the card again... dreamplug# mount_msdosfs /dev/da1s1 /mnt/sd/ mount_msdosfs: /dev/da1s1: Invalid argument So seriously WTF? Mat From owner-freebsd-arm@FreeBSD.ORG Mon Oct 10 09:42:34 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB472106564A for ; Mon, 10 Oct 2011 09:42:34 +0000 (UTC) (envelope-from matthieu.kraus@s2008.tu-chemnitz.de) Received: from cora.hrz.tu-chemnitz.de (cora.hrz.tu-chemnitz.de [134.109.228.40]) by mx1.freebsd.org (Postfix) with ESMTP id 7D1E28FC1F for ; Mon, 10 Oct 2011 09:42:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-chemnitz.de; s=dkim2010; h=Content-Transfer-Encoding:Content-Type:Mime-Version:Date:Subject:Cc:To:From:Message-ID:References; bh=yQyt3yqY+v5k/6xJLFQJloVACdTkFYUJYKnxuyfw6Dc=; b=Fr+ruWLNWZM2sqkLFy/sg2M2Xe0E/ON4lZ5pLzW8Yb0vovysjSa8WQGcVcw/H0GlrGxeGoQ0YGkCb1fWLzhgQjltXyXCtzbB73GjaKZW/eOtASbEkdNhKi/t9l3oI8QSrBg3oOFVvDpjA/25KTs59RXYYiQPu0/0uoOFpaJjN80=; Received: from pat.hrz.tu-chemnitz.de ([134.109.133.4] helo=mailbox.hrz.tu-chemnitz.de) by cora.hrz.tu-chemnitz.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RDCNU-0002GP-Ps; Mon, 10 Oct 2011 11:42:32 +0200 Received: from rlydontknow.csn.tu-chemnitz.de ([134.109.92.98] helo=rlydontknow) by mailbox.hrz.tu-chemnitz.de with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1RDCNU-0007j2-NO; Mon, 10 Oct 2011 11:42:32 +0200 References: <20110930120022.4ABAA10656A7@hub.freebsd.org> <20110930173253.55166lqso9c8zvad@mail.tu-chemnitz.de> <4E86DBCD.6020909@swin.edu.au> <20111001122747.20873v82axd8cq3n@mail.tu-chemnitz.de> <4E8AB87C.7080202@swin.edu.au> <4E8CD2B6.1070909@swin.edu.au> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Matthieu Kraus To: mrossi@swin.edu.au Date: Mon, 10 Oct 2011 09:42:32 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Scan-Signature: c4e529ea06550f8ae756d457c1b9e21b Cc: freebsd-arm@freebsd.org Subject: Re: GlobalScale DreamPlug + FreeBSD 8.2 release 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, 10 Oct 2011 09:42:34 -0000 Mattia Rossi writes: > On 04/10/11 22:38, Matthieu Kraus wrote: >> make sure to issue "usb start" in u-boot prior to booting the kernel, >> else it'll fail to start uhci properly and stalls >> > > Cool! I can boot it now! I wonder how the hell someone should find out > about this tweak though. > > I'm able to boot the kernel via TFTP and world from NFS. I found that my > 1G external SD/MMC card is recognized by the kernel as da1s1 and the > internal NAND flash shows up as da0s1 after formatting. note that it's not a NAND flash as standard boot device in the dreamplug, it's another SD card that can even be exchanged by opening the plug (see the user guide for further instructions on how to do that) > > Currently I'm trying to install world on the internal NAND, but it seems > to be extremely slow for writes, so it's taking ages to untar the tarball. > > I've also tried to get the kernel down to 700KB to be able to put it on > the NOR flash, but no chance. So next step is to find out how to load > loader through u-boot and hopee that it's able to recognize the SD card > or the internal NAND to boot from it. > > Mat > From owner-freebsd-arm@FreeBSD.ORG Mon Oct 10 09:45:05 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B6941065672 for ; Mon, 10 Oct 2011 09:45:05 +0000 (UTC) (envelope-from matthieu.kraus@s2008.tu-chemnitz.de) Received: from nick.hrz.tu-chemnitz.de (nick.hrz.tu-chemnitz.de [134.109.228.11]) by mx1.freebsd.org (Postfix) with ESMTP id 295E38FC0A for ; Mon, 10 Oct 2011 09:45:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-chemnitz.de; s=dkim2010; h=Content-Transfer-Encoding:Content-Type:Mime-Version:Date:Subject:Cc:To:From:Message-ID:References; bh=W7bzkTBk31wsKEsPus3haWyvyL1lxNMIdwG6qIlWJIY=; b=z2C4NKLxc/h8ktk0w+QooPVNCPKqRQPhheANFMg+c2/6yI5643FW5aWEa0hCD+uYaoLXvKK+VLL3YOo9aR8fYRt3PQvNZPX8nUM2wVBFSuumE6XHs3MYviI7eOh/koK7o6AEz+vOpNo40Htapc+g+EeIk61GZHqctFuwDlY5RTI=; Received: from postman.hrz.tu-chemnitz.de ([134.109.133.5] helo=mailbox.hrz.tu-chemnitz.de) by nick.hrz.tu-chemnitz.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RDCPv-0003Bf-JU; Mon, 10 Oct 2011 11:45:03 +0200 Received: from rlydontknow.csn.tu-chemnitz.de ([134.109.92.98] helo=rlydontknow) by mailbox.hrz.tu-chemnitz.de with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1RDCPv-0007rZ-Fy; Mon, 10 Oct 2011 11:45:03 +0200 References: <4E9290FF.7090306@swin.edu.au> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Matthieu Kraus To: Mattia Rossi Date: Mon, 10 Oct 2011 09:45:03 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Scan-Signature: 113af25641a082a643d611852bb712c6 Cc: freebsd-arm@freebsd.org Subject: Re: Create FAT partition/filesystem on the internal microSD flash of the Dreamplug 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, 10 Oct 2011 09:45:05 -0000 Mattia Rossi writes: > Hi all again, > > I've now been on to this for quite a while, but just can't get it to work. > I've mistakenly blown away the partitioning scheme that the dreamplug > came with originally, therefore also the FAT boot partition. > > I've tried to recreate it using gpart and newfs_msdos, but can't create > any new FAT partition that mount_msdosfs would mount. > > See: > > dreamplug# gpart create -s mbr da0 > da0 created > dreamplug# gpart add -t fat32 -i 1 -s 32M da0 > da0s1 added > dreamplug# newfs_msdos da0s1 > /dev/da0s1: 65416 sectors in 8177 FAT16 clusters (4096 bytes/cluster) > BytesPerSec=512 SecPerClust=8 ResSectors=1 FATs=2 RootDirEnts=512 > Sectors=65520 Media=0xf0 FATsecs=32 SecPerTrack=63 Heads=255 HiddenSecs=0 > dreamplug# mount_msdosfs /dev/da0s1 /mnt/usb > mount_msdosfs: /dev/da0s1: Invalid argument > > I've tried to change the partition type to 6 and 4 and to freebsd (165), > but didn't help. > I also tried to set the start of the partition (-b) to 64, 128 and 192 > but nothing there either. > > Trying to tune newfs_msdos to use FAT 12 or FAT 32 and different > bytes/sec or a different mediatype (0xf8) and a variety of tweaks did > not help either. > > It seems that I can't create a mountable FAT partition. > > I believe the problem is that gpart create -s mbr starts the > partitioning scheme at an offset of 63 sectors, while the one on the > external SD card I have (pre-partitioned not using FreeBSD) has an > offset of 32 sectors. > > I couldn't find any documentation that tells me how to tell gpart create > to use a different offset. > > Any hints? > > Mat that's another issue I ran into, however I fixed it the "dirty" way: for some mysterious reason mkfs_msdosfs seems to be a little broken, so I just created the filesystem with a linux and from there on everything worked fine (the msdosfs created under linux can be mounted without issues using mount_msdosfs) From owner-freebsd-arm@FreeBSD.ORG Mon Oct 10 11:07:03 2011 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09D05106566C for ; Mon, 10 Oct 2011 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id ECD688FC17 for ; Mon, 10 Oct 2011 11:07:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9AB72qR032327 for ; Mon, 10 Oct 2011 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9AB72eD032325 for freebsd-arm@FreeBSD.org; Mon, 10 Oct 2011 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Oct 2011 11:07:02 GMT Message-Id: <201110101107.p9AB72eD032325@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 11:07:03 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/161128 arm gcc 4.2.1 ARM produces bad code with -fstack-protector o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/160431 arm [patch] Disable interrupts during busdma cache sync op o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/156814 arm OpenRD Ultimate does not boot on DB-88F6XXX or SHEEVAP o arm/156496 arm [patch] Minor bugfixes and enhancements to mmc and mmc o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) o arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/154189 arm lang/perl5.12 doesn't build on arm o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 p arm/134338 arm [patch] Lock GPIO accesses on ixp425 16 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Oct 10 11:11:18 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1901D106564A for ; Mon, 10 Oct 2011 11:11:18 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from outbound.icp-osb-irony-out7.iinet.net.au (outbound.icp-osb-irony-out7.iinet.net.au [203.59.1.108]) by mx1.freebsd.org (Postfix) with ESMTP id 85E0F8FC13 for ; Mon, 10 Oct 2011 11:11:17 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIBANDRkk7KoR+Q/2dsb2JhbAAMN6YVhFoBAQEBAzhAARALDQsJFg8JAwIBAgFFBg0BBwEBtWiJAodDBJN3hUmMHQ X-IronPort-AV: E=Sophos;i="4.68,516,1312128000"; d="scan'208";a="45394685" Received: from unknown (HELO [192.168.15.65]) ([202.161.31.144]) by outbound.icp-osb-irony-out7.iinet.net.au with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 10 Oct 2011 19:11:15 +0800 Message-ID: <4E92D2D8.8070500@swin.edu.au> Date: Mon, 10 Oct 2011 22:11:20 +1100 From: Mattia Rossi Organization: Swinburne University of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Matthieu Kraus References: <4E9290FF.7090306@swin.edu.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Create FAT partition/filesystem on the internal microSD flash of the Dreamplug X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mrossi@swin.edu.au List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 11:11:18 -0000 On 10/10/11 20:45, Matthieu Kraus wrote: > Mattia Rossi writes: > >> Hi all again, >> >> I've now been on to this for quite a while, but just can't get it to >> work. >> I've mistakenly blown away the partitioning scheme that the dreamplug >> came with originally, therefore also the FAT boot partition. >> >> I've tried to recreate it using gpart and newfs_msdos, but can't >> create any new FAT partition that mount_msdosfs would mount. >> >> See: >> >> dreamplug# gpart create -s mbr da0 >> da0 created >> dreamplug# gpart add -t fat32 -i 1 -s 32M da0 >> da0s1 added >> dreamplug# newfs_msdos da0s1 >> /dev/da0s1: 65416 sectors in 8177 FAT16 clusters (4096 bytes/cluster) >> BytesPerSec=512 SecPerClust=8 ResSectors=1 FATs=2 RootDirEnts=512 >> Sectors=65520 Media=0xf0 FATsecs=32 SecPerTrack=63 Heads=255 HiddenSecs=0 >> dreamplug# mount_msdosfs /dev/da0s1 /mnt/usb >> mount_msdosfs: /dev/da0s1: Invalid argument >> >> I've tried to change the partition type to 6 and 4 and to freebsd >> (165), but didn't help. >> I also tried to set the start of the partition (-b) to 64, 128 and 192 >> but nothing there either. >> >> Trying to tune newfs_msdos to use FAT 12 or FAT 32 and different >> bytes/sec or a different mediatype (0xf8) and a variety of tweaks did >> not help either. >> >> It seems that I can't create a mountable FAT partition. >> >> I believe the problem is that gpart create -s mbr starts the >> partitioning scheme at an offset of 63 sectors, while the one on the >> external SD card I have (pre-partitioned not using FreeBSD) has an >> offset of 32 sectors. >> >> I couldn't find any documentation that tells me how to tell gpart >> create to use a different offset. >> >> Any hints? >> >> Mat > > that's another issue I ran into, however I fixed it the "dirty" way: > > for some mysterious reason mkfs_msdosfs seems to be a little broken, so > I just created the filesystem with a linux and from there on everything > worked fine (the msdosfs created under linux can be mounted without > issues using mount_msdosfs) > Oh, ok so it's not just me :-) This is either an ARM problem or a CURRENT or 9 problem, because today I flawlessly created partitions and filesystems on an other SD card (SDHC though) over a USB card reader using 8.2. I'll give it a go tomorrow with my SD card and that card reader on a CURRENT box. Meanwhile, I think I have to dd the Dreamplug Ubuntu image on to the internal microSD again, which should recreate the partitions as well. And then try not to kill the fs :-). Mat From owner-freebsd-arm@FreeBSD.ORG Tue Oct 11 15:00:17 2011 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB8721065673 for ; Tue, 11 Oct 2011 15:00:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 890778FC15 for ; Tue, 11 Oct 2011 15:00:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9BF0HlN016980 for ; Tue, 11 Oct 2011 15:00:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9BF0HA7016979; Tue, 11 Oct 2011 15:00:17 GMT (envelope-from gnats) Resent-Date: Tue, 11 Oct 2011 15:00:17 GMT Resent-Message-Id: <201110111500.p9BF0HA7016979@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-arm@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Ian Lepore Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5D511065670 for ; Tue, 11 Oct 2011 14:52:32 +0000 (UTC) (envelope-from ilepore@damnhippie.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id BADC08FC1E for ; Tue, 11 Oct 2011 14:52:32 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta02.emeryville.ca.mail.comcast.net with comcast id jR5V1h0091afHeLA2SfFfD; Tue, 11 Oct 2011 14:39:15 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta17.emeryville.ca.mail.comcast.net with comcast id jSTQ1h00a4NgCEG8dSTQdt; Tue, 11 Oct 2011 14:27:24 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id p9BEdK8L013182 for ; Tue, 11 Oct 2011 08:39:20 -0600 (MDT) (envelope-from ilepore@damnhippie.dyndns.org) Received: (from ilepore@localhost) by revolution.hippie.lan (8.14.4/8.14.4/Submit) id p9BEdKIb052251; Tue, 11 Oct 2011 08:39:20 -0600 (MDT) (envelope-from ilepore) Message-Id: <201110111439.p9BEdKIb052251@revolution.hippie.lan> Date: Tue, 11 Oct 2011 08:39:20 -0600 (MDT) From: Ian Lepore To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: arm/161492: [patch] ARM thread-data/RAS page is not properly initialized X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ian Lepore List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 15:00:17 -0000 >Number: 161492 >Category: arm >Synopsis: [patch] ARM thread-data/RAS page is not properly initialized >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Oct 11 15:00:16 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Ian Lepore >Release: FreeBSD 8.2-RC3 arm >Organization: none >Environment: FreeBSD tflex 8.2-STABLE FreeBSD 8.2-STABLE #29: Tue Oct 11 13:32:35 UTC 2011 root@revolution.hippie.lan:/usr/obj/arm/usr/src/sys/TFLEX arm >Description: The global page that holds ARM_TP_ADDRESS and the RAS start/end addresses is allocated using the VM_ALLOC_ZERO flag, but that flag only indicates a preference for a pre-zeroed page if one is available, it doesn't guarantee the returned page has been zeroed. It appears that often (perhaps always?) there are no pre-zeroed pages available early in startup, and the page will contain random values. Some combinations of these random values may be misinterpreted by the RAS code in PUSHFRAMEINSVC, causing it to use the garbage value from RAS_START when returning from the first trap/interrupt, typically causing a panic due to supervisor-mode access fault. >How-To-Repeat: Naturally a failure scenario based on inopportune values of random data is pretty rare and hard to repeat. >Fix: This patch zeroes the page if necessary after allocating it, and also initializes ARM_RAS_END to 0xffffffff, since that's one of the preconditions of the RAS scheme when no atomic sequence is running. --- machdep.c.diff begins here --- --- src/sys/arm/arm/machdep.c.orig Tue Jun 21 12:50:26 2011 -0600 +++ src/sys/arm/arm/machdep.c Tue Oct 11 08:10:43 2011 -0600 @@ -308,10 +308,14 @@ cpu_startup(void *dummy) #ifdef ARM_CACHE_LOCK_ENABLE pmap_kenter_user(ARM_TP_ADDRESS, ARM_TP_ADDRESS); arm_lock_cache_line(ARM_TP_ADDRESS); + bzero((void*)ARM_TP_ADDRESS, PAGE_SIZE); #else m = vm_page_alloc(NULL, 0, VM_ALLOC_NOOBJ | VM_ALLOC_ZERO); pmap_kenter_user(ARM_TP_ADDRESS, VM_PAGE_TO_PHYS(m)); + if ((m->flags & PG_ZERO) == 0) + bzero((void*)ARM_TP_ADDRESS, PAGE_SIZE); #endif + *(uint32_t *)ARM_RAS_END = 0xffffffff; } SYSINIT(cpu, SI_SUB_CPU, SI_ORDER_FIRST, cpu_startup, NULL); --- arm.machdep.c.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Tue Oct 11 17:50:02 2011 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E863B106566B for ; Tue, 11 Oct 2011 17:50:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BC4C68FC1B for ; Tue, 11 Oct 2011 17:50:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9BHo2Q9074404 for ; Tue, 11 Oct 2011 17:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9BHo2Ra074403; Tue, 11 Oct 2011 17:50:02 GMT (envelope-from gnats) Resent-Date: Tue, 11 Oct 2011 17:50:02 GMT Resent-Message-Id: <201110111750.p9BHo2Ra074403@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-arm@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Ian Lepore Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 534E21065674 for ; Tue, 11 Oct 2011 17:42:11 +0000 (UTC) (envelope-from ilepore@damnhippie.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 381188FC08 for ; Tue, 11 Oct 2011 17:42:11 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta05.emeryville.ca.mail.comcast.net with comcast id jTi51h0071bwxycA5Vi4oT; Tue, 11 Oct 2011 17:42:04 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta18.emeryville.ca.mail.comcast.net with comcast id jVrm1h00Y4NgCEG8eVrmPx; Tue, 11 Oct 2011 17:51:47 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id p9BHg8jl013359 for ; Tue, 11 Oct 2011 11:42:08 -0600 (MDT) (envelope-from ilepore@damnhippie.dyndns.org) Received: (from ilepore@localhost) by revolution.hippie.lan (8.14.4/8.14.4/Submit) id p9BHg8kJ070893; Tue, 11 Oct 2011 11:42:08 -0600 (MDT) (envelope-from ilepore) Message-Id: <201110111742.p9BHg8kJ070893@revolution.hippie.lan> Date: Tue, 11 Oct 2011 11:42:08 -0600 (MDT) From: Ian Lepore To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: arm/161498: [patch] ARM RAS code can fail to restart an atomic sequence. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ian Lepore List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 17:50:03 -0000 >Number: 161498 >Category: arm >Synopsis: [patch] ARM RAS code can fail to restart an atomic sequence. >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Oct 11 17:50:02 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Ian Lepore >Release: FreeBSD 8.2-STABLE arm >Organization: Symmetricom, Inc. >Environment: FreeBSD tflex 8.2-STABLE FreeBSD 8.2-STABLE #29: Tue Oct 11 13:32:35 UTC 2011 root@revolution.hippie.lan:/usr/obj/arm/usr/src/sys/TFLEX arm >Description: The RAS implementation for ARM can occasionally fail to restart a sequence after being interrupted, leading to a failure of atomic operations which manifests in ways such as granting the same pthread mutex to multiple threads concurrently. The "normal" RAS sequence goes like this: On entry, RAS_START = 0x00000000, RAS_END = 0xffffffff 1: Set RAS_START to address of Step 1 2: Set RAS_END to address of Step 4 3: Do the atomic operation 4: Set RAS_START to 0x00000000 5: Set RAS_END to 0xffffffff While the normal entry condition is for RAS_START/END to be 0x0/0xffffffff the code in PUSHFRAMEINSVC does not reliably enforce this (it sometimes leaves a stale value in RAS_END), which is the source of one of the two bugs in the current implementation. The other bug is that the PUSHFRAMEINSVC code compares the PC to RAS_END using signed-value logic, but proper operation of the RAS sequence requires that 0xffffffff be interpreted as the highest possible memory address, not -1. The first bug happens with interaction between a pair of threads doing RAS sequences at the same time. Thread 1 runs through step 4 of the sequence and gets interrupted before completing step 5. The PUSHFRAMEINSVC code sees a zero in RAS_START and does nothing; notably it does not change the value in RAS_END because START was zero. Thread 2 begins to run and gets interrupted between steps 1 and 2. Now PUSHFRAMEINSVC sees a non-zero RAS_START, and the RAS_END value is whatever thread 1 left there when it got interrupted. The behavior now depends on whether the RAS sequence in thread 2 is at a higher or lower memory address than the one in thread 1. In one case it accidentally works right, in the other case an interrupt between steps 1 and 2 wouldn't lead to a proper restart because the PC is not between RAS_START and RAS_END. But because RAS_START was non-zero when thread 2 got interrupted, RAS_START/END get reset, so when thread 2 gets resumed at step 2 it never reloads RAS_START, and another interrrupt in the sequence leads to misbehavior. The second bug (signed value logic) is conceptually simpler, here is a sequence that triggers that bug: On entry, RAS_START/END are 0x0/0xffffffff. A thread enters a RAS sequence and completes step 1, then gets interrupted before completing step 2. The PUSHFRAMEINSVC code sees a non-zero RAS_START so it compares the PC to RAS_END. Because of the signed-value logic, the PC will never be between RAS_START and -1, so the PUSHFRAMEINSVC code doesn't set up for a restart at the RAS_START location. When the thread eventually resumes at step 2, RAS_START will be zero, and if it gets interrupted again before the end of the atomic operation it would not get restarted. The attached patch addresses these two conditions as follows: Now the PUSHFRAMEINSVC macro always resets RAS_START to zero if it has a non- zero value, and always sets RAS_END to 0xffffffff if it has a different value. This differs from the original in that the value of RAS_START isn't used to decide whether to reset RAS_END. The two decisions are made independently, which allows them to reliably enforce the entry-condition for the next thread regardless of where in the RAS sequence the current thread was interrupted. The macro now uses conditional execution based on an unsigned compare of the PC against RAS_END to decide whether to set up for a restart (strhi rather than strgt instruction). In the case where RAS_START has been set and RAS_END is still at 0xffffffff, this will result in setting up for a restart at the beginning of the sequence so that an interrupt on the second time through will still result in atomic behavior (I.E. yet another restart for a 3rd attempt at the atomic op). Note that there is some typical ARM conditional-execution trickiness in the new logic: the strhi instruction that changes the saved PC to the RAS_START address will execute only if the carry flag is set and the zero flag is not. If the RAS_START value is zero then the compare with the RAS_END address is skipped and the zero flag is still set from the RAS_START compare, causing the strhi to get skipped based soley on the RAS_START value, regardless of the carry flag. If RAS_START is non-zero then the RAS_END compare happens and the strhi executes based on the zero/carry status of the RAS_END compare. Note also that the patched code assumes that if RAS_START is non-zero, the userland PC in PUSHFRAMEINSVC must be greater than RAS_START. This is implicit in the definition of RAS, which prohibits function calls during a RAS sequence. This allows the code to avoid a specific check for the PC being greater than RAS_START if RAS_START is non-zero, and explains why the series of instructions that used to be conditional on 'gt' are now 'ne'. Thanks go to Symmetricom, Inc, for sponsoring this work, and to my collegue there, Lars Boehnke, for crafting test code to demonstrate the original problem and prove the fix works. >How-To-Repeat: The following small program will demonstrate the problem using the atomic_cmpset_int() function. The failure will be provoked most quickly in the presence of lots of interrupts, so running with a kernel that has HZ set unreasonably high will help demonstrate the problem. --- atomictest.c begins here --- /* * atomictest.c - Demonstrate non-atomicity of ARM RAS code. * * Build using: make LDFLAGS=-pthread atomictest * * Run in an environment with lots of interrupts going on (HZ=4096 does * the trick nicely for me). On a 180mhz rm9200 with HZ=100 it takes * hours-to-months to see a failure; with HZ=4096 it takes minutes. */ #include #include #include #include #include #include static int sStopThreads = 0; static const int sNumThreads = 3; static unsigned int sAtomicLock = 0; // The implementation is defined in a macro because the RAS sections need to // be at different addresses to demonstrate the problem. // CMPSET test - // If a thread is able to "lock" sAtomicLock, it should be able to "release" // it. Failure to release indicates multiple threads were able to change the // value of sAtomicLock at the same time. #define THREAD_IMP(thrIdx) \ unsigned int locked, released; \ \ while (! sStopThreads) \ { \ locked = atomic_cmpset_int(&sAtomicLock, 0, (thrIdx+1)); \ released = atomic_cmpset_int(&sAtomicLock, (thrIdx+1), 0); \ if (locked != released) \ { \ printf("*** ERROR: locked=%u, released=%u\n", locked, released); \ sStopThreads = 1; \ break; \ } \ } \ \ return NULL; \ void* ThreadFunc1(void* varg) { THREAD_IMP(0); } void* ThreadFunc2(void* varg) { THREAD_IMP(1); } void* ThreadFunc3(void* varg) { THREAD_IMP(2); } void SigHandler(int sig) { if (sig == SIGINT) sStopThreads = 1; return; } int main(int argc, const char* argv[]) { pthread_t threads[sNumThreads]; size_t idx; time_t start = time(NULL); signal(SIGINT, SigHandler); pthread_create(&threads[0], NULL, ThreadFunc1, NULL); pthread_create(&threads[1], NULL, ThreadFunc2, NULL); pthread_create(&threads[2], NULL, ThreadFunc3, NULL); while (! sStopThreads) sleep(1); // make sure all threads have stopped for (idx = 0; idx < sNumThreads; idx ++) pthread_join(threads[idx], NULL); printf("Elapsed %lld seconds\n", (int64_t)(time(NULL)-start)); return 0; } --- atomictest.c ends here --- >Fix: The following patch fixes the problems described above. The changes to sysarch.h are just updates to the comments to help future maintainers. These diffs were developed for freebsd 8.x but apply cleanly to -current. These changes have been extensively tested at Symmetricom; we are currently deploying products that include these fixes. --- ras-current.diff begins here --- Index: sys/arm/include/asmacros.h =================================================================== RCS file: /local/base/FreeBSD-CVS/src/sys/arm/include/asmacros.h,v retrieving revision 1.8 diff -u -p -r1.8 asmacros.h --- sys/arm/include/asmacros.h 5 Feb 2008 10:22:33 -0000 1.8 +++ sys/arm/include/asmacros.h 11 Oct 2011 17:02:52 -0000 @@ -71,9 +71,8 @@ ldr r0, =ARM_RAS_START; \ mov r1, #0; \ str r1, [r0]; \ - ldr r0, =ARM_RAS_END; \ mov r1, #0xffffffff; \ - str r1, [r0]; + str r1, [r0, #4]; /* * PULLFRAME - macro to pull a trap frame from the stack in the current mode @@ -118,23 +117,22 @@ stmia sp, {r0-r12}; /* Push the user mode registers */ \ add r0, sp, #(4*13); /* Adjust the stack pointer */ \ stmia r0, {r13-r14}^; /* Push the user mode registers */ \ - mov r0, r0; /* NOP for previous instruction */ \ - ldr r5, =ARM_RAS_START; /* Check if there's any RAS */ \ - ldr r3, [r5]; \ - cmp r3, #0; /* Is the update needed ? */ \ - ldrgt lr, [r0, #16]; \ - ldrgt r1, =ARM_RAS_END; \ - ldrgt r4, [r1]; /* Get the end of the RAS */ \ - movgt r2, #0; /* Reset the magic addresses */ \ - strgt r2, [r5]; \ - movgt r2, #0xffffffff; \ - strgt r2, [r1]; \ - cmpgt lr, r3; /* Were we in the RAS ? */ \ - cmpgt r4, lr; \ - strgt r3, [r0, #16]; /* Yes, update the pc */ \ - mrs r0, spsr_all; /* Put the SPSR on the stack */ \ - str r0, [sp, #-4]! - + mov r0, r0; /* NOP for previous instruction */ \ + ldr r5, =ARM_RAS_START; /* Retrieve global RAS_END and */ \ + ldr r4, [r5, #4]; /* reset it to point at the */ \ + cmp r4, #0xffffffff; /* end of memory if necessary; */ \ + movne r1, #0xffffffff; /* leave value in r4 for later */ \ + strne r1, [r5, #4]; /* comparision against PC. */ \ + ldr r3, [r5]; /* Retrieve global RAS_START */ \ + cmp r3, #0; /* and reset it if non-zero. */ \ + movne r1, #0; /* If non-zero RAS_START and */ \ + strne r1, [r5]; /* PC was lower than RAS_END, */ \ + ldrne r1, [r0, #16]; /* adjust the saved PC so that */ \ + cmpne r4, r1; /* execution later resumes at */ \ + strhi r3, [r0, #16]; /* the RAS_START location. */ \ + mrs r0, spsr_all; \ + str r0, [sp, #-4]! + /* * PULLFRAMEFROMSVCANDEXIT - macro to pull a trap frame from the stack * in SVC32 mode and restore the saved processor mode and PC. Index: sys/arm/include/sysarch.h =================================================================== RCS file: /local/base/FreeBSD-CVS/src/sys/arm/include/sysarch.h,v retrieving revision 1.6 diff -u -p -r1.6 sysarch.h --- sys/arm/include/sysarch.h 12 Feb 2009 23:23:30 -0000 1.6 +++ sys/arm/include/sysarch.h 11 Oct 2011 17:02:56 -0000 @@ -42,9 +42,13 @@ * The ARM_TP_ADDRESS points to a special purpose page, which is used as local * store for the ARM per-thread data and Restartable Atomic Sequences support. * Put it just above the "high" vectors' page. - * the cpu_switch() code assumes ARM_RAS_START is ARM_TP_ADDRESS + 4, and + * The cpu_switch() code assumes ARM_RAS_START is ARM_TP_ADDRESS + 4, and * ARM_RAS_END is ARM_TP_ADDRESS + 8, so if that ever changes, be sure to * update the cpu_switch() (and cpu_throw()) code as well. + * In addition, code in arm/include/atomic.h and arm/include/asmacros.h + * assumes that ARM_RAS_END is at ARM_RAS_START+4, so be sure to update those + * if ARM_RAS_END moves in relation to ARM_RAS_START (look for occurrances + * of ldr/str rm,[rn, #4]). */ #define ARM_TP_ADDRESS (ARM_VECTORS_HIGH + 0x1000) #define ARM_RAS_START (ARM_TP_ADDRESS + 4) --- ras-current.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Tue Oct 11 22:40:13 2011 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 575361065782 for ; Tue, 11 Oct 2011 22:40:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0371B8FC08 for ; Tue, 11 Oct 2011 22:40:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9BMeCF6040748 for ; Tue, 11 Oct 2011 22:40:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9BMeCQ5040747; Tue, 11 Oct 2011 22:40:12 GMT (envelope-from gnats) Date: Tue, 11 Oct 2011 22:40:12 GMT Message-Id: <201110112240.p9BMeCQ5040747@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: Mark Tinguely Cc: Subject: Re: arm/161498: [patch] ARM RAS code can fail to restart an atomic sequence. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Tinguely List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 22:40:13 -0000 The following reply was made to PR arm/161498; it has been noted by GNATS. From: Mark Tinguely To: Ian Lepore Cc: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: arm/161498: [patch] ARM RAS code can fail to restart an atomic sequence. Date: Tue, 11 Oct 2011 17:13:30 -0500 On 10/11/2011 12:42 PM, Ian Lepore wrote: > The "normal" RAS sequence goes like this: > > On entry, RAS_START = 0x00000000, RAS_END = 0xffffffff > > 1: Set RAS_START to address of Step 1 > 2: Set RAS_END to address of Step 4 > 3: Do the atomic operation > 4: Set RAS_START to 0x00000000 > 5: Set RAS_END to 0xffffffff good job! I am looking forward to ARMv6/ARMv7 to replace these with ldrex/strex/clrex calls. Devil's advocate: a person can now put any value in RAS_START and wait for an interrupt. I don't see that doing them any good. In the past they could do this only if the (RAS_START < PC). In a uni-processor, we cannot overlap these critical sections. We are assuming that critical sections are made by an atomic command because we do not check to see if (RAS_START < PC). Does the RAS_END comparison buy us anything? At this point. RAS_END == 0xffff_ffff when interrupt is between step 1 and 2 RAS_END == address of step 5 In both cases, (PC <= RAS_END) --Mark. From owner-freebsd-arm@FreeBSD.ORG Tue Oct 11 22:50:06 2011 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9E2C106566B for ; Tue, 11 Oct 2011 22:50:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C51788FC14 for ; Tue, 11 Oct 2011 22:50:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9BMo6j6049692 for ; Tue, 11 Oct 2011 22:50:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9BMo6AB049691; Tue, 11 Oct 2011 22:50:06 GMT (envelope-from gnats) Date: Tue, 11 Oct 2011 22:50:06 GMT Message-Id: <201110112250.p9BMo6AB049691@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: Ian Lepore Cc: Subject: Re: arm/161498: [patch] ARM RAS code can fail to restart an atomic sequence. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ian Lepore List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 22:50:06 -0000 The following reply was made to PR arm/161498; it has been noted by GNATS. From: Ian Lepore To: Mark Tinguely Cc: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: arm/161498: [patch] ARM RAS code can fail to restart an atomic sequence. Date: Tue, 11 Oct 2011 16:29:08 -0600 On Tue, 2011-10-11 at 17:13 -0500, Mark Tinguely wrote: > On 10/11/2011 12:42 PM, Ian Lepore wrote: > Does the RAS_END comparison buy us anything? At this point. > > RAS_END == 0xffff_ffff when interrupt is between step 1 and 2 > RAS_END == address of step 5 > > In both cases, (PC <= RAS_END) > > --Mark. The RAS_END comparison is still needed to ensure idempotence of the atomic sequence. Once the PC passes the "final store" of the atomic sequence an interrupt must not cause a restart of the sequence, but until the zero is successfully stored into RAS_START the possibility of a restart is still in play, so it's the RAS_END comparison that covers the case of an interrupt while tearing down the RAS mechanism. Oh! I just re-read your quoted text above... an important distinction is that RAS_END is the address of step 4, not step 5. In the asm code it has to be the address of the next instruction after the one that makes the final modification of the memory value being protected by the sequence. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Oct 12 06:38:31 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2269D106566C for ; Wed, 12 Oct 2011 06:38:31 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from gpo4.cc.swin.edu.au (gpo4.cc.swin.edu.au [136.186.1.33]) by mx1.freebsd.org (Postfix) with ESMTP id 97C568FC13 for ; Wed, 12 Oct 2011 06:38:30 +0000 (UTC) Received: from mrossi.caia.swin.edu.au (mrossi.caia.swin.edu.au [136.186.229.109]) by gpo4.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id p9C6c8nP022891 for ; Wed, 12 Oct 2011 17:38:23 +1100 Message-ID: <4E9535D0.2030706@swin.edu.au> Date: Wed, 12 Oct 2011 17:38:08 +1100 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111004 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <4E9290FF.7090306@swin.edu.au> <4E92D2D8.8070500@swin.edu.au> In-Reply-To: <4E92D2D8.8070500@swin.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Create FAT partition/filesystem on the internal microSD flash of the Dreamplug 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, 12 Oct 2011 06:38:31 -0000 -snip- >>> I've tried to recreate it using gpart and newfs_msdos, but can't >>> create any new FAT partition that mount_msdosfs would mount. >>> >>> See: >>> >>> dreamplug# gpart create -s mbr da0 >>> da0 created >>> dreamplug# gpart add -t fat32 -i 1 -s 32M da0 >>> da0s1 added >>> dreamplug# newfs_msdos da0s1 >>> /dev/da0s1: 65416 sectors in 8177 FAT16 clusters (4096 bytes/cluster) >>> BytesPerSec=512 SecPerClust=8 ResSectors=1 FATs=2 RootDirEnts=512 >>> Sectors=65520 Media=0xf0 FATsecs=32 SecPerTrack=63 Heads=255 >>> HiddenSecs=0 >>> dreamplug# mount_msdosfs /dev/da0s1 /mnt/usb >>> mount_msdosfs: /dev/da0s1: Invalid argument >>> -snap- I've tested the newfs_msdos command on a variety of i386 and amd64 based machines using different FreeBSD versions (8.2, 9-BETA2, 9-BETA3) and all of them work properly. FS can be craeed and mounts fine. So this is definitely an ARM problem.. Have no idea why though. If someone tells me where to look for the issue, I'll happily do it and help fixing the bug. Mat From owner-freebsd-arm@FreeBSD.ORG Wed Oct 12 15:10:22 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1850106567B for ; Wed, 12 Oct 2011 15:10:22 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8BB758FC1B for ; Wed, 12 Oct 2011 15:10:22 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p9CF8ZgF022503 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 12 Oct 2011 09:08:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4E9535D0.2030706@swin.edu.au> Date: Wed, 12 Oct 2011 09:06:35 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E9290FF.7090306@swin.edu.au> <4E92D2D8.8070500@swin.edu.au> <4E9535D0.2030706@swin.edu.au> To: Mattia Rossi X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 12 Oct 2011 09:08:36 -0600 (MDT) Cc: freebsd-arm@freebsd.org Subject: Re: Create FAT partition/filesystem on the internal microSD flash of the Dreamplug 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, 12 Oct 2011 15:10:22 -0000 On Oct 12, 2011, at 12:38 AM, Mattia Rossi wrote: > -snip- >>>> I've tried to recreate it using gpart and newfs_msdos, but can't >>>> create any new FAT partition that mount_msdosfs would mount. >>>>=20 >>>> See: >>>>=20 >>>> dreamplug# gpart create -s mbr da0 >>>> da0 created >>>> dreamplug# gpart add -t fat32 -i 1 -s 32M da0 >>>> da0s1 added >>>> dreamplug# newfs_msdos da0s1 >>>> /dev/da0s1: 65416 sectors in 8177 FAT16 clusters (4096 = bytes/cluster) >>>> BytesPerSec=3D512 SecPerClust=3D8 ResSectors=3D1 FATs=3D2 = RootDirEnts=3D512 >>>> Sectors=3D65520 Media=3D0xf0 FATsecs=3D32 SecPerTrack=3D63 = Heads=3D255 >>>> HiddenSecs=3D0 >>>> dreamplug# mount_msdosfs /dev/da0s1 /mnt/usb >>>> mount_msdosfs: /dev/da0s1: Invalid argument >>>>=20 > -snap- >=20 > I've tested the newfs_msdos command on a variety of i386 and amd64 = based machines using different FreeBSD versions (8.2, 9-BETA2, 9-BETA3) = and all of them work properly. FS can be craeed and mounts fine. >=20 > So this is definitely an ARM problem.. Have no idea why though. > If someone tells me where to look for the issue, I'll happily do it = and help fixing the bug. Is there anything in dmesg? Have you tried turning on bootverbose to = get more details about what the kernel part of mount_msdosfs hates? Warner= From owner-freebsd-arm@FreeBSD.ORG Thu Oct 13 05:32:15 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B24F106567A for ; Thu, 13 Oct 2011 05:32:15 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from gpo1.cc.swin.edu.au (gpo1.cc.swin.edu.au [136.186.1.30]) by mx1.freebsd.org (Postfix) with ESMTP id 566928FC08 for ; Thu, 13 Oct 2011 05:32:13 +0000 (UTC) Received: from [136.186.219.107] (dhcp219-107.wl.swin.edu.au [136.186.219.107]) by gpo1.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id p9D5Vlgm012429; Thu, 13 Oct 2011 16:31:48 +1100 Message-ID: <4E9669CB.2060707@swin.edu.au> Date: Thu, 13 Oct 2011 15:32:11 +1100 From: Mattia Rossi Organization: Swinburne University of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Warner Losh References: <4E9290FF.7090306@swin.edu.au> <4E92D2D8.8070500@swin.edu.au> <4E9535D0.2030706@swin.edu.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Create FAT partition/filesystem on the internal microSD flash of the Dreamplug X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mrossi@swin.edu.au List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 05:32:15 -0000 On 13/10/11 02:06, Warner Losh wrote: > > On Oct 12, 2011, at 12:38 AM, Mattia Rossi wrote: > >> -snip- >>>>> I've tried to recreate it using gpart and newfs_msdos, but can't >>>>> create any new FAT partition that mount_msdosfs would mount. >>>>> >>>>> See: >>>>> >>>>> dreamplug# gpart create -s mbr da0 >>>>> da0 created >>>>> dreamplug# gpart add -t fat32 -i 1 -s 32M da0 >>>>> da0s1 added >>>>> dreamplug# newfs_msdos da0s1 >>>>> /dev/da0s1: 65416 sectors in 8177 FAT16 clusters (4096 bytes/cluster) >>>>> BytesPerSec=512 SecPerClust=8 ResSectors=1 FATs=2 RootDirEnts=512 >>>>> Sectors=65520 Media=0xf0 FATsecs=32 SecPerTrack=63 Heads=255 >>>>> HiddenSecs=0 >>>>> dreamplug# mount_msdosfs /dev/da0s1 /mnt/usb >>>>> mount_msdosfs: /dev/da0s1: Invalid argument >>>>> >> -snap- >> >> I've tested the newfs_msdos command on a variety of i386 and amd64 based machines using different FreeBSD versions (8.2, 9-BETA2, 9-BETA3) and all of them work properly. FS can be craeed and mounts fine. >> >> So this is definitely an ARM problem.. Have no idea why though. >> If someone tells me where to look for the issue, I'll happily do it and help fixing the bug. > > Is there anything in dmesg? Have you tried turning on bootverbose to get more details about what the kernel part of mount_msdosfs hates? > Okay, rebootet with bootverbose built into the kernel (no idea how to activate it otherwise through u-boot). Used a preformatted SD card through a USB reader (as the inbuilt slot is used by my other SD card), but that makes no difference. Result: dreamplug# mount_msdosfs /dev/da2s1 /mnt/usb/ dreamplug# umount /mnt/usb/ dreamplug# newfs_msdos -F 32 /dev/da2s1 /dev/da2s1: 7739392 sectors in 120928 FAT32 clusters (32768 bytes/cluster) BytesPerSec=512 SecPerClust=64 ResSectors=32 FATs=2 Media=0xf0 SecPerTrack=63 H2 dreamplug# mount_msdosfs /dev/da2s1 /mnt/usb/ mount_msdosfs: /dev/da2s1: Invalid argument dmesg (all of it - just in case): KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-BETA3 #30 r226271M: Thu Oct 13 13:21:47 EST 2011 root@freebsd82fresh.matnina:/usr/obj/arm.arm/usr/devel/sys/DREAMPLUG arm Preloaded elf kernel "elf kernel" at 0xc0da2280. module mvs already present! CPU: Feroceon 88FR131 rev 1 (Marvell core) DC enabled IC enabled WB enabled EABT branch prediction enabled 16KB/32B 4-way Instruction cache 16KB/32B 4-way write-back-locking-C Data cache real memory = 536870912 (512 MB) Physical memory chunk(s): 00000000 - 0x8fffff, 9437184 bytes (2304 pages) 0xe96000 - 0x1f63bfff, 511336448 bytes (124838 pages) avail memory = 518504448 (494 MB) SOC: (0x6281:0x03) Marvell 88F6281 rev A1, TClock 200MHz wlan: <802.11 Link Layer> snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 f5 null: crypto: random: mem: openfirm: fdtbus0: on motherboard simplebus0: on fdtbus0 ic0: mem 0xf1020200-0xf102023b on sim0 timer0: mem 0xf1020300-0xf102032f irq 1 on simplebus0 Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 gpio0: mem 0xf1010100-0xf101011f irq 35,360 device_attach: gpio0 attach returned 6 rtc0: mem 0xf1010300-0xf1010307 on simplebus0 rtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500) twsi0: mem 0xf1011000-0xf101101f irq 430 iicbus0: on twsi0 iic0: on iicbus0 mge0: mem 0xf1072000-0xf1073fff irq 12,130 mge0: bpf attached mge0: Ethernet address: f0:ad:4e:00:84:c7 miibus0: on mge0 e1000phy0: PHY 0 on miibus0 e1000phy0: OUI 0x000ac2, model 0x0024, rev. 0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 10o mge1: mem 0xf1076000-0xf1077fff irq 16,170 mge1: bpf attached mge1: Ethernet address: f0:ad:4e:00:84:c8 miibus1: on mge1 e1000phy1: PHY 1 on miibus1 e1000phy1: OUI 0x000ac2, model 0x0024, rev. 0 e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 10o uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0 uart0: fast interrupt uart0: console (1056,n,8,1) uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0 uart1: fast interrupt ehci0: mem 0xf1050000-0xf1050fff irq 480 ehci0: 5.24 GL USB-2 workaround enabled usbus0: EHCI version 1.0 usbus0: set host controller mode usbus0: on ehci0 usbus0: bpf attached ehci0: usbpf: Attached sata0: mem 0xf1080000-0xf1085fff irq 21 on0 ata0: on sata0 ata0: hard reset ... ata0: SATA connect timeout status=00000000 ata1: on sata0 ata1: hard reset ... ata1: SATA connect timeout status=00000000 sdio0: mem 0xf1090000-0xf1090133 irq 0 sdio0: mv_gpio_setup_intrhandler failed! device_attach: sdio0 attach returned 6 cryptosoft0: on motherboard crypto: assign cryptosoft0 driver id 0, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 procfs registered Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining lo0: bpf attached ata0: Identifying devices: 00000000 ata0: New devices: 00000000 ata1: Identifying devices: 00000000 ata1: New devices: 00000000 usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 uhub1: on usbus0 Root mount waiting for: usbus0 uhub1: 4 ports with 4 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 umass0: on usbus0 umass0:0:0:-1: Attached to scbus0 (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 pass0: Removable Direct Access SCSI-0 device pass0: Serial Number 000000009910 pass0: 40.000MB/s transfers GEOM: new disk da0 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: Serial Number 000000009910 da0: 40.000MB/s transfers da0: 1876MB (3842048 512 byte sectors: 255H 63S/T 239C) (probe0:umass-sim0:0:0:1): Down reving Protocol Version from 2 to 0? (probe0:umass-sim0:0:0:1): SCSI status error (probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 (probe0:umass-sim0:0:0:1): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:1): SCSI status: Check Condition (probe0:umass-sim0:0:0:1): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to re) (probe0:umass-sim0:0:0:1): Retrying command (per sense data) pass1 at umass-sim0 bus 0 scbus0 target 0 lun 1 pass1: Removable Direct Access SCSI-0 device pass1: Serial Number 000000009910 pass1: 40.000MB/s transfers da1 at umass-sim0 bus 0 scbus0 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: Serial Number 000000009910 da1: 40.000MB/s transfers da1: 974MB (1995264 512 byte sectors: 64H 32S/T 974C) GEOM: new disk da1 Root mount waiting for: usbus0 Root mount waiting for: usbus0 ugen0.4: at usbus0 umass1: on usbu0 umass1:1:1:-1: Attached to scbus1 (probe0:umass-sim1:1:0:0): Down reving Protocol Version from 2 to 0? pass2 at umass-sim1 bus 1 scbus1 target 0 lun 0 pass2: Removable Direct Access SCSI-0 device pass2: Serial Number 058F0O1111B1 pass2: 40.000MB/s transfers GEOM: new disk da2 da2 at umass-sim1 bus 1 scbus1 target 0 lun 0 da2: Removable Direct Access SCSI-0 device da2: Serial Number 058F0O1111B1 da2: 40.000MB/s transfers da2: 3780MB (7741440 512 byte sectors: 255H 63S/T 481C) (da2:umass-sim1:1:0:0): SCSI status error (da2:umass-sim1:1:0:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 (da2:umass-sim1:1:0:0): CAM status: SCSI Status Error (da2:umass-sim1:1:0:0): SCSI status: Check Condition (da2:umass-sim1:1:0:0): SCSI sense: NOT READY asc:ff,ff (Vendor Specific ASC) (da2:umass-sim1:1:0:0): Field Replaceable Unit: 1 (da2:umass-sim1:1:0:0): Command Specific Info: 0xaa5541 (da2:umass-sim1:1:0:0): Polling device for readiness (da2:umass-sim1:1:0:0): SCSI status error (da2:umass-sim1:1:0:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 (da2:umass-sim1:1:0:0): CAM status: SCSI Status Error (da2:umass-sim1:1:0:0): SCSI status: Check Condition (da2:umass-sim1:1:0:0): SCSI sense: NOT READY asc:ff,ff (Vendor Specific ASC) (da2:umass-sim1:1:0:0): Field Replaceable Unit: 1 (da2:umass-sim1:1:0:0): Command Specific Info: 0xaa5541 (da2:umass-sim1:1:0:0): Polling device for readiness (da2:umass-sim1:1:0:0): SCSI status error (da2:umass-sim1:1:0:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 (da2:umass-sim1:1:0:0): CAM status: SCSI Status Error (da2:umass-sim1:1:0:0): SCSI status: Check Condition (da2:umass-sim1:1:0:0): SCSI sense: NOT READY asc:ff,ff (Vendor Specific ASC) (da2:umass-sim1:1:0:0): Field Replaceable Unit: 1 (da2:umass-sim1:1:0:0): Command Specific Info: 0xaa5541 (da2:umass-sim1:1:0:0): Error 16, Retries exhausted (da2:umass-sim1:1:0:0): SCSI status error (da2:umass-sim1:1:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (da2:umass-sim1:1:0:0): CAM status: SCSI Status Error (da2:umass-sim1:1:0:0): SCSI status: Check Condition (da2:umass-sim1:1:0:0): SCSI sense: NOT READY asc:ff,ff (Vendor Specific ASC) (da2:umass-sim1:1:0:0): Field Replaceable Unit: 1 (da2:umass-sim1:1:0:0): Command Specific Info: 0xaa5541 (da2:umass-sim1:1:0:0): Polling device for readiness (da2:umass-sim1:1:0:0): SCSI status error (da2:umass-sim1:1:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (da2:umass-sim1:1:0:0): CAM status: SCSI Status Error (da2:umass-sim1:1:0:0): SCSI status: Check Condition (da2:umass-sim1:1:0:0): SCSI sense: NOT READY asc:ff,ff (Vendor Specific ASC) (da2:umass-sim1:1:0:0): Field Replaceable Unit: 1 (da2:umass-sim1:1:0:0): Command Specific Info: 0xaa5541 (da2:umass-sim1:1:0:0): Polling device for readiness (da2:umass-sim1:1:0:0): SCSI status error (da2:umass-sim1:1:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (da2:umass-sim1:1:0:0): CAM status: SCSI Status Error (da2:umass-sim1:1:0:0): SCSI status: Check Condition (da2:umass-sim1:1:0:0): SCSI sense: NOT READY asc:ff,ff (Vendor Specific ASC) (da2:umass-sim1:1:0:0): Field Replaceable Unit: 1 (da2:umass-sim1:1:0:0): Command Specific Info: 0xaa5541 (da2:umass-sim1:1:0:0): Error 16, Retries exhausted Root mount waiting for: usbus0 ugen0.5: at usbus0 uaudio0: on uaudio0 pcm0: Mixer "vol" -> "none": child=0x00000010 pcm0: Mixer "pcm": parent="vol" pcm0: Mixer "mic": pcm0: clone manager: deadline=750ms flags=0x8000001e uhid0: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78F0B106566B for ; Sat, 15 Oct 2011 01:28:48 +0000 (UTC) (envelope-from ntai@smartfruit.com) Received: from homiemail-a30.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by mx1.freebsd.org (Postfix) with ESMTP id 5383A8FC12 for ; Sat, 15 Oct 2011 01:28:46 +0000 (UTC) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id B277921DE59 for ; Fri, 14 Oct 2011 18:28:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=smartfruit.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=smartfruit.com ; b=bc6NZJoF+cEy0cw0cjc8hFgevwopXYa9wySWxU2K/aSJq1CVq4p29Sf58UiL QjnapYCyqGupz5/e2xvXtXe6vgaTRVV7n0bEMRiyHm8+NMLwFF9x0BSREG75KIuS xXs+j5XDyoUmXJgTZIA2fSEzn6bv+VER4U4QRIfKumIxaOg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=smartfruit.com; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= smartfruit.com; bh=eQOEDTQWR5bL1/QDZSoRAEZ1yXQ=; b=sevd3AGb3/WJf 48dEnVK/C92DiFfRYAM7LeJ9wSBrSebkTqW+GDDIfhYYe3ImZP+4oSUFjgoMOxRz YkbMJW43zY3Y9xTE9A4BST4asyiRfh0l5EcBeVzHbNICas17NYeriw6Vc7xOK4LK IpeAQqWrYRHGLDjtl7lE59c9Va2FBU= Received: from luxor.smartfruit.com (pool-173-76-33-234.bstnma.fios.verizon.net [173.76.33.234]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: smtpguy@smartfruit.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 740FA21DE58 for ; Fri, 14 Oct 2011 18:28:46 -0700 (PDT) Message-ID: <4E98E1CF.2090507@smartfruit.com> Date: Fri, 14 Oct 2011 21:28:47 -0400 From: Naoyuki Tai User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20110202 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <4E782686.6070500@smartfruit.com> In-Reply-To: <4E782686.6070500@smartfruit.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Q about Ethernet - GlobalScale DreamPlug + FreeBSD 8.2 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, 15 Oct 2011 01:28:48 -0000 Hi, I just realized that I get only mge0, one of two ethernet ports. With the linux that came with DreamPlug, both ethernet ports show up as eth0 and eth1. Is there any way to get the mge1 get going? Thanks. -- Tai Naoyuki "Tai" Tai, ntai a t smartfruit d o t com From owner-freebsd-arm@FreeBSD.ORG Sat Oct 15 05:49:47 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFDC7106566C for ; Sat, 15 Oct 2011 05:49:47 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 403D88FC17 for ; Sat, 15 Oct 2011 05:49:46 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with ESMTPSA; Sat, 15 Oct 2011 07:35:32 +0200 id 00033C4B.4E991BA4.000062F0 From: Milan Obuch To: freebsd-arm@freebsd.org Date: Sat, 15 Oct 2011 07:39:34 +0200 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; i386; ; ) References: <4E782686.6070500@smartfruit.com> <4E98E1CF.2090507@smartfruit.com> In-Reply-To: <4E98E1CF.2090507@smartfruit.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110150739.35707.freebsd-arm@dino.sk> Subject: Re: Q about Ethernet - GlobalScale DreamPlug + FreeBSD 8.2 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, 15 Oct 2011 05:49:47 -0000 On Saturday 15 October 2011 03:28:47 Naoyuki Tai wrote: > Hi, > > I just realized that I get only mge0, one of two ethernet > ports. > > With the linux that came with DreamPlug, both ethernet > ports show up as eth0 and eth1. > > Is there any way to get the mge1 get going? > Hi, it looks like you are trying to solve similar issue as I did some time ago... look in this list archives for message from me sent 2010-10-27 22:59 with subject 'Re: Guruplug Server Plus working to some extent... [mge1 problem SOLVED]' with some patches attached. I think at least guruplugplus.dts could be useful. Basically, SoC used in Guruplug Server Plus and, I think, DreamPlug uses the same or at least similar, multiplexes some functions on IO pins and so some initialisation is important. Regards, Milan