From owner-freebsd-arm@FreeBSD.ORG Thu Mar 19 13:37:42 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F822301 for ; Thu, 19 Mar 2015 13:37:42 +0000 (UTC) Received: from relay.mailchannels.net (ar-005-i192.relay.mailchannels.net [162.253.144.74]) by mx1.freebsd.org (Postfix) with ESMTP id D0E7F13D for ; Thu, 19 Mar 2015 13:37:35 +0000 (UTC) Received: from smtp4.ore.mailhop.org (ip-10-213-14-133.us-west-2.compute.internal [10.213.14.133]) by relay.mailchannels.net (Postfix) with ESMTPA id F02B94875; Thu, 19 Mar 2015 13:12:38 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp4.ore.mailhop.org (smtp4.ore.mailhop.org [10.83.15.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Thu, 19 Mar 2015 13:12:42 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1426770761843:3173512612 X-MC-Ingress-Time: 1426770761843 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp4.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YYaFT-0003om-TB; Thu, 19 Mar 2015 13:12:32 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t2JDCPXm030144; Thu, 19 Mar 2015 07:12:25 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1+QuJd+Vo+lijqT+gMmXZ2x Message-ID: <1426770745.9902.7.camel@freebsd.org> Subject: Re: beaglebone boot from eMMC From: Ian Lepore To: Tim Kientzle Date: Thu, 19 Mar 2015 07:12:25 -0600 In-Reply-To: <40A94DE3-36A6-4E85-8B59-15329D00E89C@kientzle.com> References: <3DF08C65-20E3-4524-B0E1-C5C096AA0FE8@hellmuth-michaelis.de> <54BA6DB9-DC61-4A6F-B948-777BB9800F54@bocal.org> <20150312132739.GA28385@cicely7.cicely.de> <3EF47A05-60B2-4BB0-8688-018E50CF7D4A@hellmuth-michaelis.de> <40A94DE3-36A6-4E85-8B59-15329D00E89C@kientzle.com> Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 X-AuthUser: hippie Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm , Hellmuth Michaelis X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 13:37:42 -0000 On Wed, 2015-03-18 at 20:41 -0700, Tim Kientzle wrote: > > On Mar 18, 2015, at 11:16 AM, Guy Yur wrote: > >=20 > > Hi, > >=20 > > On Wed, Mar 18, 2015 at 9:23 AM, Hellmuth Michaelis > > wrote: > >>=20 > >> Its really weird. I fetched the Angstroem flasher to put back an ori= ginal image onto the eMMC and that worked. I dumped the MBR for Linux and= the MBR which was generated by the install script and they are both pret= ty OK and legal. I reordered files on the MSDOS partition. I played with = different =84BIOS=93 geometries (because Linux and FreeBSD have a rather = different sight on this) to produce the partitions. > >>=20 > >> Nothing helps - it does not boot FreeBSD from the eMMC MSDOS Partiti= on. The only thing which made a difference was, when i used the Linux-gen= erated MSDOS partition, removed the files in it and populated it with the= FreeBSD-generated MLO and things - then it booted from it. I failed comp= letely to add an UFS partition after the Linux-generated MSDOS partition,= tried gpart, fdisk, bsdlabel. The UFS mmcsd1s2a can be generated, popula= ted, fsck=92d, tested, checked - after the next powercycle it simply disa= ppeared. > >>=20 > >> It seems to me that there is a bit more magic involved than only gen= erate the partitions. In the Linux script to generate the image onto the = eMMC, they check for: > >>=20 > >> HEADER=3D$(hexdump -e '8/1 "%c"' /sys/bus/i2c/devices/0-0050/eeprom = -s 5 -n 3) > >>=20 > >> and possibly write to an eeprom - has someone an idea why this is ne= eded ? > >>=20 > >> Hellmuth > >>=20 > >>=20 > >=20 > > Is your msdosfs slice on the eMMC aligned to 1 MB? > >=20 > > I had the same "CCC" problem when I aligned the partition > > and used newfs_msdos. > > Removing the sector count adjustment calculation in newfs_msdos > > as was done in NetBSD worked for me. > >=20 > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D183234 >=20 > Fortunately, the AM335x TRM from TI documents the exact checks made by = the ROM before it will recognize a valid MSDOS partition. So you don=92t= need to guess; you can compare a hex dump of your disk with the docs and= see exactly what=92s gone wrong. >=20 > As I recall, the ROM is very unforgiving: >=20 > * The CHS geometry used in the MBR has to exactly match the MSDOS forma= t geometry. Attempts to align the partition on round boundaries can scre= w this up badly. >=20 > * The FAT format type (12, 16, or 32) has to match the ROM expectations >=20 > If any of the ROM checks fail, it will assume the device is not usable = and try a different device (ultimately ending up with CCCC on the serial = port). >=20 > The corresponding code in Crochet uses >=20 > $ gpart add -a 63 -b 63 -s 2m -t =91!12=92 >=20 > to create the MSDOS partition and then uses >=20 > $ newfs_msdos -L