From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 09:50:39 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 785281065670 for ; Wed, 21 Jan 2009 09:50:39 +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 EFC918FC08 for ; Wed, 21 Jan 2009 09:50:38 +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 232151477; Wed, 21 Jan 2009 11:50:38 +0200 Message-ID: <4976EFED.4010706@FreeBSD.org> Date: Wed, 21 Jan 2009 11:50:37 +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> In-Reply-To: <4976E9DB.3000803@bulinfo.net> X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------020403090708080602000605" 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 09:50:39 -0000 This is a multi-part message in MIME format. --------------020403090708080602000605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Krassimir Slavchev wrote: > I've tried the attached patch but the problem still exist. Then it is something different. It would be easier if I have some arm hardware to play with, but I have no. Try to apply this debugging patch. It should tell us what's going on there. > I see another strange things which may be related: > On 7.1-STABLE: > > #fdisk -BI mmcsd0 > > ******* Working on device /dev/mmcsd0 ******* > fdisk: Geom not found: "mmcsd0" > > #geom disk list > Geom name: ad4 > Providers: > 1. Name: ad4 > Mediasize: 250059350016 (233G) > Sectorsize: 512 > Mode: r5w5e6 > fwsectors: 63 > fwheads: 16 > > Geom name: mmcsd0 > Providers: > 1. Name: mmcsd0 > Mediasize: 2012217344 (1.9G) > Sectorsize: 512 > Mode: r0w0e0 > fwsectors: 0 > fwheads: 0 > > 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. -- Alexander Motin --------------020403090708080602000605 Content-Type: text/plain; name="mmc.c.debug.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mmc.c.debug.patch" --- mmc.c.prev 2008-12-25 11:50:18.000000000 +0200 +++ mmc.c 2009-01-21 11:39:31.000000000 +0200 @@ -315,11 +315,14 @@ mmc_wait_for_req(struct mmc_softc *sc, s req->done = mmc_wakeup; req->done_data = sc; + printf("CMD: %x ARG %x len %d\n", req->cmd->opcode, req->cmd->arg, + (int)(req->cmd->data)?req->cmd->data->len:0); MMCBR_REQUEST(device_get_parent(sc->dev), sc->dev, req); MMC_LOCK(sc); while ((req->flags & MMC_REQ_DONE) == 0) msleep(req, &sc->sc_mtx, 0, "mmcreq", 0); MMC_UNLOCK(sc); + printf("RES: %d\n", req->cmd->error); return (0); } --------------020403090708080602000605--