On Thu, Oct 06, 2016 at 04:43:09AM -0400, Ian Sutton wrote: > On Wed, Oct 05, 2016 at 12:40:42AM -0400, Ian Sutton wrote: > > My driver needs to recognize cases where the root disk is MMC1 and abort > > as to avoid hanging the system when the kernel tries to init userspace > > on a disk it is no longer pinmuxxed to. I am not sure how to properly > > and reliably do this, or if there is perhaps a better way to go about > > solving this problem. > > This turns out to be a very interesting problem. To reiterate, I am > trying to find a way for my device driver to identify whether the root > disk resides on the onboard eMMC storage or an external uSD card for > this armv7 board. My driver can only sanely attach when booting from > uSD because its pins sit on the same pads that the onboard eMMC chip > does (GREAT design choice) > > I tried comparing 'rootdev' device number (dev_t) exposed by sys/systm.h > with corresponding device numbers of entries in the alldevs LISTQ > exposed by sys/device.h. No dice. That linked list is populated as > scsibus -> sd/wd/cd/st/etc attach long after device drivers > attach. Config suggests userspace-facing drivers attach last (for > obvious reasons).
I think you're going about this the wrong way. Both mmc controllers should be useable if described in the device tree and not disabled. I haven't looked but I suspect linux handles what you are trying to do with some kind of device tree overlay? To do something along those lines at the moment you'd have to mark the emmc hsmmc node as disabled in the device tree, then it won't attach and the emmc specific pinctrl won't be set. > > I tried using the assigned device name+minor (like wd0, sd0) -- > unreliable, MMC1 (the onboard eMMC as hardware docs describe it) does > not always map to sd1. > > I tried using the disk DUID which the bootloader passes via FDT nodes in > /chosen. No, DUIDs are entropy. Only relevant when matched with fstab > entries on the disk that hasn't initialized yet. > > Very interesting. Three ideas: > > - We pass this info from bootloader via FDT node in /chosen. We already > pass root disk DUID like this. But requiring folks to reinstall > bootloader is bush league, distrib/ changes take too long to > propagate. > > - New UEFI 2nd stage bootloader (a la boot(8)) inherits u-boot env > instead of no env which it does currently. Probably best solution. > > - Issue new bootloader MLO setting SYSBOOT bits as to have the device > switch to alternate pins-to-pad table. probably bad idea. > > Since option 2 seems best, would it make sense to have armv7's UEFI > bootloader adopt uboot's environment? The environment in amd64 boot(8) > seems to convey nearly the same information as the u-boot env could > provide. > > Perhaps I've missed something or am making this too hard, but I think > working on a good u-boot->FDT->efiloader interface would help us combat > the ridiculous bullshit issues like this that spontaneously pop up on > all our dissimilar ARM boards. Issues that don't seem to come up on > other archs. > > Ian >
