From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 13:01:29 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36427106582B for ; Wed, 21 Jan 2009 13:01:29 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 8AF218FC19 for ; Wed, 21 Jan 2009 13:01:28 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 232173098; Wed, 21 Jan 2009 15:01:27 +0200 Message-ID: <49771CA6.7080106@FreeBSD.org> Date: Wed, 21 Jan 2009 15:01:26 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Krassimir Slavchev References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> <4976FB8C.5050209@bulinfo.net> In-Reply-To: <4976FB8C.5050209@bulinfo.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Mount root from SD card? 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, 21 Jan 2009 13:01:30 -0000 Krassimir Slavchev wrote: > This is the output: > > CMD: 0 ARG 0 len 0 > RES: 0 > CMD: 8 ARG 1aa len 0 > RES: 1 > CMD: 37 ARG 0 len 0 > RES: 0 > CMD: 29 ARG 0 len 0 > RES: 0 > CMD: 0 ARG 0 len 0 > RES: 0 > CMD: 8 ARG 1aa len 0 > RES: 1 > CMD: 37 ARG 0 len 0 > RES: 0 > CMD: 29 ARG ff8000 len 0 > RES: 0 > CMD: 37 ARG 0 len 0 > RES: 0 > CMD: 29 ARG ff8000 len 0 > RES: 0 > CMD: 2 ARG 0 len 0 > RES: 0 > CMD: 3 ARG 0 len 0 > RES: 0 > CMD: 9 ARG 10000 len 0 > RES: 0 > CMD: 7 ARG 10000 len 0 > RES: 0 > CMD: 37 ARG 10000 len 0 > RES: 0 > CMD: 33 ARG 0 len 8 > RES: 0 > CMD: 6 ARG ffffff len 64 > RES: 0 > CMD: 37 ARG 10000 len 0 > RES: 0 > CMD: d ARG 0 len 64 > RES: 2 > CMD: 37 ARG 10000 len 0 > RES: 0 > CMD: d ARG 0 len 64 > RES: 0 This part looks fine. Just normal SD detection and initialization. Somewhere here bus frequency and high-speed timings negotiated: > CMD: 7 ARG 0 len 0 > RES: 0 > CMD: 7 ARG 10000 len 0 > RES: 0 > CMD: 7 ARG 0 len 0 > RES: 0 > CMD: 7 ARG 10000 len 0 > RES: 2 > CMD: 6 ARG 80fffff0 len 64 > RES: 0 > CMD: 7 ARG 0 len 0 > RES: 0 > mmcsd0: 1983MB at mmc0 30MHz/1bit Then regular card activity beging: - select the card - error > CMD: 7 ARG 10000 len 0 > RES: 2 - select bus width - normal ?? > CMD: 37 ARG 10000 len 0 > RES: 0 > CMD: 6 ARG 0 len 0 > RES: 0 - read some sectors - normal ?? > CMD: 11 ARG 0 len 512 > RES: 0 > CMD: 11 ARG 0 len 512 > RES: 0 > CMD: 11 ARG 200 len 512 > RES: 0 > Trying to mount root from ufs:/dev/mmcsd0s1 It's a bis strange to me that this card selection request failed, while previous ones during initialization managed fine. May be card or controller unable to handle such speed, or may be bus just hasn't managed to settle new parameters until that command. Also interesting what are the reading command returned after card select command failed. Boot with verbose messages enabled should show when exactly frequency has changed. Do it please. >>> Also sysinstall crashes when trying to create a new slice. >>> May be because: >>> Disk name: mmcsd0 FDISK >>> Partition Editor >>> DISK Geometry: 0 cyls/0 heads/0 sectors = 0 sectors (0MB) >> I don't think it is related. There is no such thing as disk geometry on >> flash card, that's why driver does not announce it. The only places >> where it may be important is when fdisk is trying to align partitions >> with track boundaries for compatibility with legacy BIOS'es. > >> There is no problem to report some fake values, but from one side they >> should better match BIOS assumptions on geometry and from other, they >> should as much as possible to match flash erase sector size. I just have >> no any system which supports SD booting to report something reasonable >> there. Reporting maximal 63 sectors per track as for HDD may result in >> ineffective filesystem alignment and reduced performance. > > At least sysinstall should be fixed. Should I fill a PR for this? Probably yes. I haven't looked into sysinstall. -- Alexander Motin