From owner-freebsd-arm@freebsd.org Thu Feb 16 09:48:20 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1505ECE127E for ; Thu, 16 Feb 2017 09:48:20 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7F11169 for ; Thu, 16 Feb 2017 09:48:19 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1487238496; l=9727; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=H5Az4iIF4RGpJVUG6r5TXUal2N4v1ieLJ962BY+aCPw=; b=pUNdENdYZ6EQbgT9966G1hW3qlfrowycIXm8dWZ0ZjtRhZ3WqAdCLaPsucB+iT8qH0 rTPULoGR7rPJUwMoeI8q0bvyOVYTGKlNCcUtQN2yNTjsNHCnrrH+c4pFdJ+oxGUkyGlQ dVERa01NsYf7KsehARbHHcnJhmL0xV24XILZU= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0i99HgKKA= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b584.virtua.com.br [187.2.181.132]) by smtp.strato.de (RZmta 39.12 DYNA|AUTH) with ESMTPSA id 30b190t1G9mFfTq (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Thu, 16 Feb 2017 10:48:15 +0100 (CET) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id C04867506DA1 for ; Thu, 16 Feb 2017 07:48:12 -0200 (BRST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: BeagleBone Black MMC ordering clashes From: "Dr. Rolf Jansen" In-Reply-To: Date: Thu, 16 Feb 2017 07:48:11 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6A97EEB3-6B24-48E7-959F-67F4275AFEC8@obsigna.com> References: <7D750433-59FC-4999-AC24-041683E17310@obsigna.com> <1483718084.96230.5.camel@freebsd.org> <0D800E14-799A-4926-AEF8-CD698D647E40@obsigna.com> <1483722560.96230.10.camel@freebsd.org> <1483928120.96230.61.camel@freebsd.org> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 09:48:20 -0000 Am 09.01.2017 um 00:32 schrieb Dr. Rolf Jansen : >> Am 09.01.2017 um 00:15 schrieb Ian Lepore : >> On Fri, 2017-01-06 at 16:40 -0200, Dr. Rolf Jansen wrote: >>>> Am 06.01.2017 um 15:09 schrieb Ian Lepore : >>>> On Fri, 2017-01-06 at 14:33 -0200, Dr. Rolf Jansen wrote: >>>>>> Am 06.01.2017 um 13:54 schrieb Ian Lepore : >>>>>> On Fri, 2017-01-06 at 12:37 -0200, Dr. Rolf Jansen wrote: >>>>>>>=20 >>>>>>> The BeagleBone Black comes with 2 MMC facilities, one built- >>>>>>> in >>>>>>> (internal 4 GB) and one provided by a removable SD card. For >>>>>>> unknown >>>>>>> reasons the BBB defined on the removable SD card to be MMC0 >>>>>>> and >>>>>>> the >>>>>>> internal flash memory is MMC0. >>>>>>>=20 >>>>>>> 1) In the first go, I dd'd the FreeBSD-12 BBB snapshot >>>>>>> (20161221) >>>>>>> onto a SD card and I was able to start the device from that >>>>>>> card. >>>>>>> gpart showed me that the device identifier of the SD card is >>>>>>> mmcsd0 >>>>>>> and that of the internal flash memory is mmcsd1. OK, that >>>>>>> matches >>>>>>> the >>>>>>> already mentioned definitions. >>>>>>>=20 >>>>>>> 2) Now, I destroyed the partition of the internal mmcsd1 >>>>>>> and >>>>>>> created a new one: >>>>>>>=20 >>>>>>> =3D> 63 7552961 mmcsd1 MBR (3.6G) >>>>>>> 63 8129 - free - (4.0M) >>>>>>> 8192 8192 1 fat32 [active] (4.0M) >>>>>>> 16384 7536640 2 freebsd (3.6G) >>>>>>>=20 >>>>>>> =3D> 0 7536640 mmcsd1s2 BSD (3.6G) >>>>>>> 0 7536640 1 freebsd-ufs (3.6G) >>>>>>>=20 >>>>>>> 3) I copied over the contents of /boot/msdos from the >>>>>>> external >>>>>>> SD >>>>>>> card to the msdosfs on mmcsd1s1 and I installed the FreeBSD >>>>>>> 12 >>>>>>> snapshot on mmcsd1s1a. Restarting the device from the >>>>>>> internal >>>>>>> flash >>>>>>> and no external SD inserted with FreeBSD 12-CURRENT works >>>>>>> well at >>>>>>> the >>>>>>> first glance. >>>>>>>=20 >>>>>>> 4) However, the internal flash got now the device >>>>>>> identifier >>>>>>> mmcsd0: >>>>>>>=20 >>>>>>> ... >>>>>>> mmc0: No compatible cards found on bus >>>>>>> ... >>>>>>> mmcsd0: 4GB >>>>>> 112 >>>>>>> 0x0000> at mmc1 48.0MHz/8bit/65535-block >>>>>>> ... >>>>>>>=20 >>>>>>> I know, this is how FreeBSD deals with the device numbering, >>>>>>> i.e. >>>>>>> serial numbers starting at zero without particular meaning, >>>>>>> and I >>>>>>> know that we should not rely on the number ordering. >>>>>>>=20 >>>>>>> But it seems that the MMC device driver does cont on the >>>>>>> external >>>>>>> SD >>>>>>> card is at MMC0 when I insert it into the BBB once it has >>>>>>> been >>>>>>> started from the internal flash. It seems to insist to assign >>>>>>> the >>>>>>> device ID mmcsd0, which results in the device ordering clash >>>>>>> because >>>>>>> mmcsd0 has been assigned to the internal flash at MMC1 (s. >>>>>>> above). >>>>>>>=20 >>>>>>> In the moment, I can have both flash device active at the >>>>>>> same >>>>>>> time >>>>>>> only when I start the BBB from the external SD. >>>>>>>=20 >>>>>>> I would be glad to hear suggestions on how to deal with the >>>>>>> issue. At >>>>>>> the end of the day, I want to start the device from the >>>>>>> mostly >>>>>>> static >>>>>>> OS file system on the internal flash and keep the volatile >>>>>>> data >>>>>>> on >>>>>>> the external SD. >>>>>>>=20 >>>>>>> Best regards >>>>>>>=20 >>>>>>> Rolf >>>>>> The mmcsd0 identifier will be assigned to the first mmc device >>>>>> found >>>>>> that has a valid mmc or sd card. If the external slot has a >>>>>> card >>>>>> in >>>>>> it, it will become mmcsd0 because it gets probed first. If it >>>>>> has >>>>>> no >>>>>> card in it, the onboard eMMC becomes mmcsd0 because the sd slot >>>>>> didn't >>>>>> claim that device id. There is no way to change the order of >>>>>> probing; >>>>>> probing happens in order of the devices in the chip. The BBB >>>>>> makers >>>>>> decided to connect the external sd to the first device and the >>>>>> onboard >>>>>> eMMC to the second one. >>>>> Thank you for rephrasing of what I wanted to say in my initial >>>>> post: >>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I know, this is how FreeBSD deals with the device numbering, >>>>>>> i.e. >>>>>>> serial numbers starting at zero without particular meaning, >>>>>>> and I >>>>>>> know that we should not rely on the number ordering. >>>>> So, yes, this part is absolutely clear and understood. >>>>>>=20 >>>>>> If you want the eMMC to be the root filesystem whether there is >>>>>> an >>>>>> external sd card installed or not, the only solution is to use >>>>>> UFS >>>>>> or >>>>>> GPT labels instead of device names to refer to partitions in >>>>>> fstab. >>>>> I do not rely on device identifiers in fstab on non of my >>>>> numerous >>>>> FreeBSD boxes, instead, I use the various sorts of labels ever >>>>> since, >>>>> and I continue to do it also with the BBB installation(s). >>>>>=20 >>>>> # df -h >>>>> Filesystem Size Used Avail Capacity Mounted on >>>>> /dev/ufs/SYSTEM 13G 875M 11G 7% / >>>>> devfs 1.0K 1.0K 0B 100% /dev >>>>> /dev/label/BOOT 4.0M 924K 3.1M 23% /boot/msdos >>>>> tmpfs 50M 4.0K 50M 0% /tmp >>>>>=20 >>>>> However, this does not help in the given case, because the MMC >>>>> device >>>>> driver refuses to enumerate the SD card when inserted into a BBB >>>>> that >>>>> has been already started-up from the internal flash. So the >>>>> question >>>>> is, how can I get the SD card activated once inserted into a >>>>> running >>>>> system, and I would happily live with any device identifier for >>>>> it, >>>>> even let it mmcsd77 if only the device would be accessible by >>>>> this. >>>>>=20 >>>>> Best regards >>>>>=20 >>>>> Rolf >>>> Oh, you mean you boot from eMMC without an sd card, then later when >>>> you >>>> insert an sd card it's not detected? I've never tried that (I've >>>> never >>>> used the onboard eMMC at all), but it wouldn't surprise me that >>>> it's >>>> broken. >>> Yes, that is the problem. >>>=20 >>>>=20 >>>> It would imply we're not handling the card-detect properly, >>>> probably because it's a gpio pin, and we didn't have good gpio >>>> support >>>> back when I was working on the TI sdcard driver. >>> Well, this might be related to an issues with the U-Boot/MLO >>> facility. Remember that I replaced the factory one on the eMMC by = the >>> one from the FreeBSD 12.0-CURRENT(Beaglebone) image. Actually this >>> allows me to boot FreeBSD from the internal eMMC without an SD card, >>> however with a remarkable notice at the very beginning of the boot >>> sequence: >>>=20 >>> U-Boot SPL 2016.05 (Dec 21 2016 - 18:05:07) >>> Trying to boot from MMC2 >>> Card did not respond to voltage select! >>> *** Warning - MMC init failed, using default environment >>>=20 >>> The "Card did not respond" notice and the consecutive warning does >>> not appear when I boot from the SD card, instead I see another one >>> about a not supported property by the SD card:=20 >>>=20 >>> U-Boot SPL 2016.05 (Dec 21 2016 - 18:05:07) >>> Trying to boot from MMC1 >>> Card doesn't support part_switch >>> MMC partition switch failed >>> *** Warning - MMC partition switch failed, using default >>> environment >>>=20 >>> Perhaps U-Boot disables/deactivates/turns-off something on the board >>> already in the very early stage. Perhaps I need to adapt the U-Boot >>> image for internal eMMC booting. >>>=20 >>>>=20 >>>> Yep, I just looked at the source, and there's no handling for gpio- >>>> based sd card detect in the TI driver. Maybe I can find some time >>>> this >>>> weekend to add it, now that we have a better gpio infrastructure >>>> for >>>> drivers to use. >>> Many thanks in advance for spending your time. >>>=20 >>> Best regards >>>=20 >>> Rolf >>=20 >> Okay, I got this all done and tested this weekend, and just committed >> all the changes for am335x (beaglebone) and imx6 (wandboard, cubox, >> etc). It's pretty easy to convert an existing driver, so I expect >> other boards with sdhci-compatible hardware to get updated soon too. >>=20 >> If you are set up to build custom kernels, you just need to update = your >> sources to r311736 or later and rebuild. Otherwise you can wait = until >> the next 12-current snapshot is available (I think those still come = out >> weekly). >=20 > Ian, >=20 > thank you very much for all you efforts. >=20 > My x86-machines are running custom kernels and personally I am set = building it, however, I am in the course of porting my own software to = the BeagleBone, and I learned already that compiling huge code bases on = it is not fun at all. >=20 > At some point in time in the near future, I need to setup ARM cross = building on one of my faster x86 machines. For the time being, I will = wait for the next snapshot, and of course I will report my findings. I tried the FreeBSD 12 snapshot for the BeagleBone from 2017-02-10, and = it does not work at all. The new u-boot is complaining that it cannot find a configured device = and drops into the console, and I needed to revert to the previous = u-boot, i.e. the one that was on the snapshot from 2017-01-05. With that the new kernel loaded, however, when trying to mount root, = kernel's vfs complained that the indicated device /dev/mmcsd0s2a is = read-only, and booting was not finished. I gave up with = FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170210-r313561, and I will = try again with the next snapshot. Best regards Rolf=