From owner-freebsd-arm@FreeBSD.ORG Thu Mar 19 03:41:48 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 7B43D6E2 for ; Thu, 19 Mar 2015 03:41:48 +0000 (UTC) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47804C9A for ; Thu, 19 Mar 2015 03:41:47 +0000 (UTC) Received: by pdnc3 with SMTP id c3so62919954pdn.0 for ; Wed, 18 Mar 2015 20:41:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Eb6bLoWkBgn9gTilPS9nngW6LtANKGYrll6YhTCmj70=; b=DDXtMrxgfqUBLAXZIkqhRfV35gxlgsxKdPM/MhHjP8c20BXDVNgXPhaEg6WachclE3 rY2jcT+pgd7fsogMXAF5zLGiJdRb1UnowVYufHOFmW6kL/L5tMKE2/dWewOjq988rzRk QzLxX1bYJdbUQEIFfSzf/M161FV3HHklcVqVZITEcwQMqWhJtB3zVE6wWVtJj8Yauo+8 5jmNq1RbLS3y48ZGjXKwyIJ56GFozFsheR6UCawxhnh2luHrwXzvXujjJzXOtBOiawnE cu47Wt5WlCFktQoiqlhaKoCgjpssqaph3jlkh0vK+Ad1NqItjzkElAdWePBCJ8h3Wi+z Q14Q== X-Gm-Message-State: ALoCoQm+d5tW1Y5C/0CVXsIRWd+/bcT1VGkN2SbRRMYpfHlgO7uTlU25gTjxKKxoHKmlbdXz9jLe X-Received: by 10.66.218.129 with SMTP id pg1mr170043102pac.65.1426736506568; Wed, 18 Mar 2015 20:41:46 -0700 (PDT) Received: from [192.168.1.100] (c-24-6-220-224.hsd1.ca.comcast.net. [24.6.220.224]) by mx.google.com with ESMTPSA id di10sm127459pad.41.2015.03.18.20.41.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 20:41:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: beaglebone boot from eMMC From: Tim Kientzle In-Reply-To: Date: Wed, 18 Mar 2015 20:41:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: Guy Yur , Hellmuth Michaelis X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-arm 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 03:41:48 -0000 > 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 = original 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 = pretty OK and legal. I reordered files on the MSDOS partition. I played = with different =E2=80=9EBIOS=E2=80=9C 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 = Partition. The only thing which made a difference was, when i used the = Linux-generated MSDOS partition, removed the files in it and populated = it with the FreeBSD-generated MLO and things - then it booted from it. I = failed completely to add an UFS partition after the Linux-generated = MSDOS partition, tried gpart, fdisk, bsdlabel. The UFS mmcsd1s2a can be = generated, populated, fsck=E2=80=99d, tested, checked - after the next = powercycle it simply disappeared. >>=20 >> It seems to me that there is a bit more magic involved than only = generate 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 = needed ? >>=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 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=E2=80=99t need to guess; you can compare a hex dump of your disk = with the docs and see exactly what=E2=80=99s gone wrong. As I recall, the ROM is very unforgiving: * The CHS geometry used in the MBR has to exactly match the MSDOS format = geometry. Attempts to align the partition on round boundaries can screw = this up badly. * The FAT format type (12, 16, or 32) has to match the ROM expectations 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). The corresponding code in Crochet uses $ gpart add -a 63 -b 63 -s 2m -t =E2=80=98!12=E2=80=99 to create the MSDOS partition and then uses $ newfs_msdos -L