Date: Wed, 18 Mar 2015 08:23:00 +0100 From: Hellmuth Michaelis <hm@hellmuth-michaelis.de> To: freebsd-arm@freebsd.org Subject: Re: beaglebone boot from eMMC Message-ID: <3EF47A05-60B2-4BB0-8688-018E50CF7D4A@hellmuth-michaelis.de> In-Reply-To: <A3E0A638-450D-4B83-90F7-090D45FF4420@bsdimp.com> References: <3DF08C65-20E3-4524-B0E1-C5C096AA0FE8@hellmuth-michaelis.de> <54BA6DB9-DC61-4A6F-B948-777BB9800F54@bocal.org> <A923E8B5-72DC-4C19-B5CA-7729C7E16A5C@hellmuth-michaelis.de> <20150312132739.GA28385@cicely7.cicely.de> <A3E0A638-450D-4B83-90F7-090D45FF4420@bsdimp.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Am 12.03.2015 um 14:33 schrieb Warner Losh <imp@bsdimp.com>: > > >> On Mar 12, 2015, at 10:27 PM, Bernd Walter <ticso@cicely7.cicely.de> wrote: >> >> On Wed, Mar 11, 2015 at 11:38:39AM +0100, Hellmuth Michaelis wrote: >>> Further investigation shows, if i dd the local image from /dev/mmcsd0 or a fresh image from remote to /dev/mmcsd1 i get sooner or later >>> >>> GEOM_PART: integrity check failed (mmcsd1, MBR) >>> GEOM_PART: integrity check failed (diskid/DISK-5F817AAF, MBR) >>> >>> on the serial console. Is the internal SD broken ? >>> >>> I got similar messages when i used the copy script and during probing while start of the kernel. >> >> I remember having seen similar problems when I tried using the eMMC last >> year. >> I also used crochet and the copy script, but IIRC ended when it didn't boot. >> Details should be on this list somewhere. > > Last time I looked into issues like this it was due to gpart putting too much stock > in the BIOS returned geometry. usb devices rarely match each-other, let alone > the fake geometry we return from mmcsd. I suspect the root of these weird to > diagnose issues lies here. > > Warner 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 „BIOS“ geometries (because Linux and FreeBSD have a rather different sight on this) to produce the partitions. 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’d, tested, checked - after the next powercycle it simply disappeared. 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: HEADER=$(hexdump -e '8/1 "%c"' /sys/bus/i2c/devices/0-0050/eeprom -s 5 -n 3) and possibly write to an eeprom - has someone an idea why this is needed ? Hellmuth [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVCSfUAAoJEDc16e0fOQ8Bw9UH/2yVzk8+TCOsWlM7qN2EXK0f cb5IqQPr6nWZYMdvNkncTrYyhAqhmYZm8URSupFI2HKFgif6fiAvG4wO8AjIAuSD ZoLy2/wYKKWxKn/HULyQidUEkOBlbxEiGb97ZOwhTV+/96J8rO2pHWlxnuWRYwzu 7PsEIj1RSf/gq+UzBme10m6TmEGGaepuBtpuC2TYjlsIAbIapmrGpKf8dbqg2CWG MxM0GuzI/iiFElKL53peuK9ibYeqiEKPHwctlaDpP7VBLJ2Vem9StbM6ldJomRH7 7DvNNfyMN5glxrF5fV945l8WwT9gWDln1saMMaimfMZKMy8b7kGNom+M3WNBiP0= =Y9Gl -----END PGP SIGNATURE-----home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EF47A05-60B2-4BB0-8688-018E50CF7D4A>