After replacing any eMMC-flasher card with a normal Debian boot image, the BeagleBone Green can run from microSD while leaving the eMMC overlay disabled for reuse of the associated pins. Treat boot selection, operating-system pin ownership, and electrical pin sharing as three separate checks.
Boot approach comparison
| Approach | Purpose | Expected behavior | Decision criterion |
|---|---|---|---|
| Normal microSD image | Run Debian directly from the removable card | The board starts the operating system from microSD without copying it to eMMC | Use this approach when every board must operate from a cloned card |
| eMMC-flasher image | Copy an image from microSD into onboard eMMC | A sustained LED sequence and a long write interval can occur while eMMC is programmed | Reject this approach when the card must remain the runtime device |
| Normal image with eMMC overlay disabled | Run from microSD and release the default operating-system assignment of eMMC-related pins | The system boots from microSD without loading the eMMC overlay | Recommended for this requirement, followed by boot-device and GPIO verification |
The required configuration is the third approach. Use a normal image rather than an image prepared to flash eMMC, then edit the copy of uEnv.txt on that microSD card. The tested image name was bone-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz. A matching Debian version does not by itself distinguish a runtime image from a flasher image; image purpose is the deciding property.
Commissioning prerequisites
- Prepare one known-good microSD card with the normal Debian image. Do not move on until the imaging process completes without an error and the card can be read again.
- Open the microSD card's
uEnv.txt. Change#disable_uboot_overlay_emmc=1todisable_uboot_overlay_emmc=1. Removing the leading comment marker activates the setting. - Connect a serial console through
J1with a suitable adapter. LED activity provides a useful indication of progress, but it does not identify the executing storage device or prove that eMMC is being written. - Keep external circuits off the eMMC-associated pins during the first boot. Release and test those pins only after confirming that the system did not initialize or mount eMMC.
- For a fleet of boards, preserve the verified card as the master image. Duplicate the complete card rather than copying only
uEnv.txt, then validate each copy on its target board.
Recommended microSD boot procedure
- Power down the BeagleBone Green and insert the prepared microSD card.
- Connect the
J1serial adapter and start terminal capture before applying power. The capture must show the bootloader and kernel messages, not only an application login reached over USB. - Apply power and watch the console for the device from which the bootloader reads the kernel, device tree, and root filesystem. Do not move on until the root filesystem resolves to the microSD card rather than eMMC.
- Allow the first normal boot to finish. If LEDs
D2,D3,D4, andD5operate synchronously and the board takes about 10 minutes on every restart, stop and recheck whether the card contains an eMMC-flasher image. Do not infer a flash operation from the LED pattern alone. - After login, inspect the mounted root device and storage inventory. Confirm that the root filesystem belongs to the removable card and that no required filesystem is mounted from eMMC.
- Power-cycle the board with the same card installed. A repeatable boot from microSD, without a recurring programming interval, confirms that the card is functioning as runtime media.
Boot-selection and overlay mechanism
The setting disable_uboot_overlay_emmc=1 controls loading of the eMMC-related overlay. It does not transform a flasher image into a normal image, erase eMMC, or by itself prove which device supplied the bootloader and root filesystem. Boot media selection happens before the operating system applies its normal peripheral ownership.
Once Linux starts, the active device tree determines which controller claims the multiplexed processor pins. Disabling the eMMC overlay prevents the default eMMC configuration from reserving those signals, allowing a later pin configuration to assign them as GPIO. The change does not physically disconnect the onboard eMMC device. Never operate eMMC and drive its shared signals as GPIO at the same time.
This separation explains the confusing symptom: a board can read early boot components from one storage device, mount a root filesystem from another, and apply an overlay configuration that changes peripheral ownership. Confirm all three layers instead of treating an illuminated LED or an edited file as proof of the complete configuration.
Diagnostic decision path
| Observation | Likely decision | Check before continuing |
|---|---|---|
Approximately 10-minute startup with synchronous D2-D5 activity on every restart |
Treat the card as a possible eMMC flasher | Read the J1 console for copy, write, or flashing activity and verify the image type |
LEDs remain illuminated after editing uEnv.txt
|
LED state alone is inconclusive | Confirm that the serial log advances through boot and identifies the root device |
| System reaches login, but eMMC-related pins cannot be configured | The overlay change may not have been read, or another device-tree assignment owns the pins | Inspect the effective boot configuration and runtime pin ownership |
| System boots only when eMMC remains enabled | Some boot component or filesystem may still come from eMMC | Trace the bootloader source, kernel source, and mounted root filesystem separately |
| One cloned card works while another does not | The copies or media differ | Compare the complete card images and repeat the boot-device checks on each board |
The decisive diagnostic is the serial log. A USB connection that becomes available only after Linux starts can confirm that the operating system is alive, but it can miss bootloader messages and early failures. Capture from power-on through login, and retain that record as the commissioning baseline.
GPIO release and final verification
- Confirm that the running root filesystem is on microSD.
- Confirm that eMMC is not mounted, being initialized for storage, or used by an application.
- Confirm that the effective boot configuration contains
disable_uboot_overlay_emmc=1, without the leading#. - Inspect runtime pin ownership before assigning any eMMC-associated signal as GPIO. Another enabled peripheral can still claim a multiplexed pin.
- Configure one required signal at a time and verify its direction and level at the header. Account for the onboard eMMC connection as an electrical load even though its overlay is disabled.
- Repeat a cold start and confirm the same microSD root device, the absence of eMMC activity, and correct GPIO operation before duplicating the master card.
FAQ
Can I force BeagleBone Green to boot from microSD by editing uEnv.txt?
disable_uboot_overlay_emmc=1 disables the eMMC overlay; it does not independently force boot-media selection. Confirm the actual bootloader and root devices through the J1 serial log.
Does synchronous D2-D5 activity mean eMMC is being flashed?
No. The LED pattern alone cannot distinguish a normal microSD boot from an eMMC write operation. A repeated interval of about 10 minutes warrants checking the image type and serial output for copy or write activity.
Can I clone one microSD card for several BeagleBone Green boards?
Yes. Build and verify a normal runtime image, duplicate the complete card, and confirm on every board that the mounted root filesystem is on microSD and the edited uEnv.txt is active.
Does disabling the eMMC overlay make its pins ready for GPIO?
It releases the default software assignment but does not physically isolate onboard eMMC. Final verification is a cold boot followed by confirmation of the microSD root device, no eMMC use, and correct direction and level on every repurposed GPIO.