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 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
