I want to boot from the SD Card. Seems like the easiest way to get started and I can switch to eMMC later. I read (but need to confirm) that in the boot to usb serial downloader it will check SD1 and SD2 for a card and try to use those. There's a specific GPIO for card detect that will be used. One thing in the reference manual is that only SD3 and SD4 can go into very fast mode at boot? > SDR50 and SDR104 boot are not supported on USDHC1 and USDHC2, because there is no reset signal for those ports in the IOMUXC. 8.5.3.3 of the reference manual The table I want is "Table 8-17. SD/MMC IOMUX pin configuration" But I need to read up about SD cards with a focus on: - eSD - boot partition? - SDR50 and SD104 - Voltage signaling - reset Ok, three modes: spi mode, 1 bit mode and 4 bit mode. 4 bit mode is fastest and for OS image, probably what I want to target. microSD has 8 bits total. I'm somewhat confused about the symbols I'm looking at which have 2 card detect pins (which are for the connector not the card) I think here's what I should do: Design so that SD1 is exposed to a microsd card connector and assume that's boot and main disk. Ensure SD2 is routable to eMMC. In the future maybe that's the main storage and that SD1 is a "recovery" thing you can solder to or populate. Route SD3 to a connector to see if we can make it go fast. The only risk is the low voltage stuff. IDK how to get the power working? Found this good wiki reference that has some general embedded linux on sd cards. https://web.archive.org/web/20171025124835/http://developer.toradex.com/knowledge-base/sd-mmc-card-(linux) https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/supporting-SDR104-in-imx6-board-by-yocto/ta-p/1120352?profile.language=en this has a part of a schematic showing UHS-1 with some notes about resistors and emmc The iMX reference manual, section 67.1.1 lists some useful specs now that I understand them. SDXC maxes out at "400 Mbps of data transfer for SDXC card using 4 parallel data lines in DDR(Dual Data Rate) mode", but that's with UHS-1 and thus "low voltage" and not available... during boot. After boot it seems like maybe DDR50 is possible. The other pins are available for eMMC devices, not sure I want to look into that now. > DAT7~DAT4 can also be optional and tied to high. I think if I'm not in an ALT mode then these aren't like "connected" to the chip, but I need to determine which ALT mode I need to use and if you can combine them. > VSELECT is an output signal used to change the voltage of the external power supplier. This might be useful for trying to get the 1.8V stuff for the faster modes, but I don't know how I'd control the power. > Card write protect detect If not used(for the embedded memory), tie low to indicate it's not write protected. I think this is unnecessary because I won't have it in a mode where the writeprotect pin is configured? Gotta get chip detect working too. > SD1_CD_B (CD_B), GPIO_1, tie low to indicate there is a card attached. ALT6 > In the manufacture mode, the SD or MMC card will be scanned on the uSDHC1 and uSDHC2. If a card is detected and a valid boot image is found in the card, the boot image is loaded and executed. Pad of SD1_CD and SD2_CD are used to detect whether a card is inserted or not. > In the manufacture mode, one bit bus width is used despite of the fuse setting Ok, so during boot, if SD1_CD is high, we will try and boot in 1-bit width mode only. This might be... really slow and so we'll probably have to set boot fuses and such. This might mean we should try boot from internal, which maybe falls back to serial mode I read more about alt modes. My understanding is that almost all pins can be **individually** configured to use an ALT mode function. I believe that means I can manually configure certain pins to certain functions. eg: SD1_CD_B is ALT6 (which may be the default in the bootrom) but I can continue to use / set that after the fact. This is controlled via IOMUXC, which consists of 2 registers per pad to select the alt mode, and to configure the pin. https://developer.toradex.com/software/linux-resources/device-tree/pinmuxing-guide/pinmuxing-with-imx66ull-based-modules/ covers some of the details on how this achived in linux with pinctrl-imx6dl. > If an error occurs during the internal boot, the boot code jumps to the Serial Downloader > In {Boot from fuses} mode, the GPIO boot override pins are ignored. The boot ROM code uses the boot eFUSE settings only. ... > If BT_FUSE_SEL = 0, indicating that the boot device (for example, flash, SD/MMC) was not programmed yet, the boot flow jumps directly to the Serial Downloader. Ok, given that we will have the EPDC set up on the boot pins, it seems we **must** use boot from fuses. This falls back to serial downloader until we set an eFUSE. It seems like eFUSES can be set from uboot or using a windows program from NXP. This program is also how we can load something to boot in the serial dowload mode. https://solidrun.atlassian.net/wiki/spaces/developer/pages/287212307/eFuses+for+i.MX6+SOM good overview of the process https://www.imx6rex.com/open-rex/software/how-to-uboot-compile-flash-update-boot covers the process on the imx6rex https://imxdev.gitlab.io/tutorial/Burning_eFuses_on_i.MX/ covers how to write the fuses from uboot, linux and mfgtools, but it's from the imx7 https://github.com/nxp-imx/mfgtools official mfgtools with imx6 support https://github.com/boundarydevices/imx_usb_loader someone else wrote their own protocol implementation. So, with all that said, I think my plan is now: - Set the boot fuses to boot from internal only - plan to boot from SD1 (since it will fall back to that) - route SD3 as well to see if we can make it go fast (and if that even matters) - leave room for future testing of eMMC (maybe on SD2?) - leave room for future testing of a SPI boot rom (recovery / fallback?)