UUU 명령 하나로 eMMC 파형과 드라이버 코드까지 연결해 보기

한국어 English

먼저 구분해야 합니다

UUU는 USB로 SoC와 통신하고 명령을 전달하는 도구입니다. eMMC 핀에서 실제 전기 신호를 관찰하는 장비가 아닙니다. 파형을 보려면 UUU와 함께 로직 애널라이저나 오실로스코프를 사용해야 합니다.

부팅이 되지 않는 i.MX 8M Mini 보드를 활용해, PC → UUU → Boot ROM/U-Boot → MMC 드라이버 → eMMC 흐름을 단계별로 살펴보겠습니다.

1. 전체 실습 흐름

PC
 └─ UUU (USB downloader/command tool)
     └─ i.MX Boot ROM: SDP(Serial Download Protocol)
         └─ RAM에 U-Boot 로드 및 실행
             └─ U-Boot mmc 명령
                 └─ MMC subsystem
                     └─ USDHC host controller driver
                         └─ eMMC: CLK / CMD / DAT[7:0]

여기서 SDP(Serial Download Protocol)는 SoC 내부 Boot ROM이 USB를 통해 이미지를 받을 수 있는 복구 모드입니다. 보드가 정상 부팅하지 않아도 이 모드로 진입할 수 있다면, RAM에서 U-Boot를 실행해 진단할 수 있습니다.

2. UUU와 U-Boot의 역할

구성 요소	역할
Boot ROM	부트 모드를 확인하고, USB SDP를 처리하며 초기 이미지를 수신합니다.
UUU	PC에서 이미지를 전송하고 U-Boot 명령을 전달합니다.
U-Boot	메모리·MMC·네트워크 등을 초기화하고 mmc 같은 명령을 실행합니다.
Logic analyzer / oscilloscope	eMMC의 CLK, CMD, DAT 신호를 측정합니다.

따라서 "UUU로 eMMC에 직접 CMD17을 보낸다"기보다, UUU가 실행 중인 U-Boot에 mmc read를 전달하고, U-Boot의 MMC 호스트 드라이버가 eMMC 프로토콜 명령을 생성한다고 이해하는 것이 정확합니다.

3. 실습 전 보드 상태 확인

UUU가 보드를 어떤 상태로 인식하는지 먼저 확인합니다.

uuu -lsusb

SDP 또는 SDPS가 보이면 Boot ROM 단계입니다. FB:가 보이면 이미 U-Boot Fastboot 단계까지 올라온 상태이므로, 다시 RAM 부팅을 시도하기보다 UUU의 FB: ucmd로 U-Boot 명령을 바로 보낼 수 있습니다.

uuu "FB: ucmd printenv emmc_dev"
uuu "FB: ucmd mmc list"
uuu "FB: ucmd mmc dev 2 0"
uuu "FB: ucmd mmc rescan"
uuu "FB: ucmd mmc info"
uuu "FB: ucmd mmc part"
uuu "FB: ucmd mmc partconf 2"

2는 이 실습 보드에서 확인한 eMMC device number의 예시입니다. 다른 보드는 번호가 다를 수 있으므로 mmc list와 printenv emmc_dev 결과로 먼저 확인하고 바꿔야 합니다. mmc partconf 2처럼 장치 번호만 주면 현재 설정을 출력하는 읽기 동작이며, 뒤에 세 개의 숫자를 추가하면 설정을 변경하는 쓰기 동작이 됩니다.

일부 UUU/U-Boot 조합에서는 FB: ucmd가 명령의 성공·실패만 PC에 표시하고 상세 출력은 UART 콘솔에 남길 수 있습니다. 전체 mmc info 결과가 필요하면 보드의 U-Boot UART 로그를 함께 확인합니다.

주의해야 합니다

실습 초기에는 mmc write, mmc erase, 파티션 변경, partconf 쓰기 동작을 실행하지 않습니다. 저장장치 내용을 변경할 수 있으므로 먼저 읽기 명령만 사용합니다.

4. 한 블록 읽기와 CMD17

측정 장비를 먼저 준비(arm)한 뒤, 사용자 영역의 한 블록만 읽습니다.

uuu "FB: ucmd mmc dev 2 0"
uuu "FB: ucmd mmc read 0x42000000 0x0 0x1"
uuu "FB: ucmd md.b 0x42000000 0x40"

여기서 0x42000000은 예시 보드에서 사용 가능하다고 확인한 DRAM 주소입니다. 실제 보드에서는 U-Boot의 relocation 영역, 스택, 다른 다운로드 버퍼와 겹치지 않는 자유 영역인지 확인한 뒤 사용합니다. 주소와 eMMC device number를 다른 보드에 그대로 복사하지 않습니다.

값	의미
0x42000000	읽은 데이터를 저장할 RAM 주소
0x0	읽기 시작 LBA(Logical Block Address)
0x1	읽을 블록 수. U-Boot MMC 블록 인터페이스에서는 보통 한 블록이 512바이트이며, 실제 장치 정보는 mmc info로 확인합니다.

단일 블록 읽기에서는 일반적으로 eMMC의 CMD17(READ_SINGLE_BLOCK)이 핵심 명령으로 관찰됩니다. 여러 블록을 읽으면 CMD18(READ_MULTIPLE_BLOCK)이 사용될 수 있습니다. 초기화나 상태 확인을 위해 앞뒤에 다른 명령이 함께 보이는 것은 정상입니다.

CLK   _|-|_|-|_|-|_|-|_|-|_|-|_|-|_|-|_
CMD   ----[ command index + argument + CRC ]----
DAT0  ----------------[ response / 512-byte data ]--

5. 파형에서 무엇을 확인해야 합니까?

CLK는 호스트가 제공하는 동기 신호, CMD는 명령과 응답이 오가는 선, DAT[7:0]은 데이터 선입니다. 처음에는 CLK, CMD, DAT0 세 채널만 잡아도 읽기 흐름을 파악할 수 있습니다. 가능하면 DAT[7:0] 전체와 RST_n도 추가합니다.

단순 오실로스코프 화면만 보는 것보다 eMMC 프로토콜 디코더가 있는 로직 애널라이저가 학습에 더 편리합니다. 다만 HS200/HS400처럼 속도가 높은 모드에서는 장비의 대역폭, 샘플링 속도, 프로브 부하를 먼저 확인해야 합니다. 학습 목적으로는 가능한 경우 낮은 속도 모드에서 시작하는 것이 좋습니다.

6. U-Boot 명령에서 드라이버까지

소스 코드를 읽을 때는 다음 순서로 내려갑니다.

U-Boot command: mmc read
  → MMC block / core layer
  → host controller .send_cmd callback
  → i.MX USDHC host driver
  → controller registers and DMA setup
  → eMMC CMD17 and data transfer

여기서 호스트 컨트롤러는 SoC 쪽에서 eMMC 버스 신호를 생성하는 하드웨어 블록이고, DMA는 CPU가 모든 바이트를 직접 옮기지 않고 컨트롤러가 메모리와 장치 사이의 데이터를 옮기게 하는 방식입니다.

i.MX 계열 U-Boot에서는 보통 drivers/mmc/ 아래의 FSL eSDHC 계열 드라이버를 확인합니다. 실제 빌드가 SDMA를 선택하는지, ADMA를 선택하는지, 어떤 분기에서 결정되는지는 사용한 U-Boot 소스와 설정을 읽어 확인해야 합니다. 이미지 문자열만으로 DMA 경로를 단정하지 않는 것이 안전합니다.

7. 이 실습이 BSP 공부에 중요한 이유

BSP는 단순히 이미지를 빌드하는 일이 아닙니다. 보드의 핀, 클록, 전원, 메모리, 저장장치가 부트로더와 커널 드라이버에서 어떻게 표현되고 실제 신호로 바뀌는지를 연결하는 작업입니다.

이번 한 번의 mmc read를 다음 질문으로 확장해 보겠습니다.

• 왜 이 보드에서 eMMC가 mmc 2입니까?
• Device Tree의 어느 USDHC 노드가 이 컨트롤러를 설명합니까?
• 현재 버스 폭과 실제 협상된 속도는 무엇입니까?
• 읽은 데이터가 CPU 캐시를 거치지 않고 DMA로 어떻게 RAM에 도착합니까?
• U-Boot에서 관찰한 경로와 Linux 커널의 MMC 블록 장치 경로는 어떻게 이어집니까?

핵심 정리

1. UUU는 명령 전달 도구이고, 파형 측정은 별도의 계측기가 담당합니다.
2. 보드가 부팅되지 않아도 SDP 또는 Fastboot 상태라면 RAM U-Boot와 읽기 전용 MMC 진단을 시도할 수 있습니다.
3. mmc read 한 번은 MMC 계층, USDHC 드라이버, DMA, eMMC CMD17, CLK/CMD/DAT 파형을 연결하는 좋은 실습이 됩니다.
4. 실제 DMA 방식과 속도는 보드의 소스·설정·측정 결과로 확인해야 합니다.

#BSP #EmbeddedLinux #UBoot #UUU #eMMC #DeviceDriver

Keep the roles separate

UUU communicates with the SoC over USB and forwards commands; it does not measure electrical signals on eMMC pins. To observe waveforms, attach a logic analyzer or oscilloscope alongside UUU.

This note uses a non-booting i.MX 8M Mini board as a lab platform to trace the complete path: PC → UUU → Boot ROM/U-Boot → MMC driver → eMMC—connecting each layer to the physical bus signals step by step.

1. The Complete Lab Path

PC
 └─ UUU (USB downloader/command tool)
     └─ i.MX Boot ROM: SDP (Serial Download Protocol)
         └─ Load and run U-Boot from RAM
             └─ U-Boot mmc command
                 └─ MMC subsystem
                     └─ USDHC host controller driver
                         └─ eMMC: CLK / CMD / DAT[7:0]

SDP (Serial Download Protocol) is the recovery mode in which the SoC Boot ROM receives an image over USB. Even when normal boot fails, the board can enter SDP so that U-Boot runs from RAM for diagnosis.

2. What UUU and U-Boot Each Do

Component	Role
Boot ROM	Checks the boot mode, handles USB SDP, and receives the initial image.
UUU	Transfers images and sends commands from the host PC.
U-Boot	Initializes hardware (memory, MMC, network) and executes commands such as mmc.
Logic analyzer / oscilloscope	Measures the electrical CLK, CMD, and DAT signals on the eMMC bus.

It is more accurate to say that UUU asks the running U-Boot to execute mmc read; U-Boot's MMC host driver then generates the eMMC protocol commands. UUU does not send CMD17 directly to the eMMC chip.

3. Checking the Board State Before the Lab

Confirm how UUU recognizes the board before issuing any commands.

uuu -lsusb

An SDP or SDPS entry means the board is at the Boot ROM stage. An FB: entry means U-Boot Fastboot is already running; in that case, use FB: ucmd to issue U-Boot commands without another RAM-boot attempt.

uuu "FB: ucmd printenv emmc_dev"
uuu "FB: ucmd mmc list"
uuu "FB: ucmd mmc dev 2 0"
uuu "FB: ucmd mmc rescan"
uuu "FB: ucmd mmc info"
uuu "FB: ucmd mmc part"
uuu "FB: ucmd mmc partconf 2"

The number 2 is the eMMC device number verified for this specific example board. Other boards may use a different number. Check mmc list and printenv emmc_dev first and substitute accordingly. With only the device number, mmc partconf 2 reads the current configuration; adding three numeric arguments changes it.

Depending on the UUU/U-Boot combination, FB: ucmd may report only success or failure to the PC while the detailed output appears on the U-Boot UART console. Attach a UART terminal when the full mmc info output is needed.

Safety — read-only commands first

Do not run mmc write, mmc erase, partition changes, or the write-side of partconf during the initial lab. These operations modify storage content. Start with read-only commands only.

4. One-Block Read and CMD17

Arm the measurement equipment first, then issue a single-block read from the user area.

uuu "FB: ucmd mmc dev 2 0"
uuu "FB: ucmd mmc read 0x42000000 0x0 0x1"
uuu "FB: ucmd md.b 0x42000000 0x40"

0x42000000 is a DRAM address verified as usable on the example board. On any other board, confirm that the address does not overlap U-Boot relocation, the stack, or another download buffer before using it. Do not copy the address or device number blindly.

Value	Meaning
0x42000000	RAM destination address for the read data.
0x0	First logical block address (LBA) to read from.
0x1	Number of blocks to read. The U-Boot MMC block interface normally uses 512-byte blocks; confirm the device details with mmc info.

A single-block read normally produces CMD17 (READ_SINGLE_BLOCK) as the key eMMC command. A multi-block read may use CMD18 (READ_MULTIPLE_BLOCK). Additional initialization and status commands appearing around the read are expected behavior.

CLK   _|-|_|-|_|-|_|-|_|-|_|-|_|-|_|-|_
CMD   ----[ command index + argument + CRC ]----
DAT0  ----------------[ response / 512-byte data ]--

5. What to Look for on the Waveform

CLK is the host-provided synchronization clock. CMD carries commands and their responses. DAT[7:0] carries the data payload. Start by capturing CLK, CMD, and DAT0 to understand the read flow, then add all data lanes and RST_n when equipment allows.

A logic analyzer with an eMMC protocol decoder is considerably more useful for learning than a raw oscilloscope trace. For HS200 or HS400 modes, verify the analyzer's bandwidth, sample rate, and probe loading before relying on its decode. When the goal is learning the protocol, starting in a lower-speed mode is advisable.

6. From the U-Boot Command Down to the Driver

When reading the source code, follow this call chain downward.

U-Boot command: mmc read
  → MMC block / core layer
  → host controller .send_cmd callback
  → i.MX USDHC host driver
  → controller registers and DMA setup
  → eMMC CMD17 and data transfer

The host controller is the SoC hardware block that generates the eMMC bus signals. DMA lets the controller move data between the device and RAM without a CPU copy per byte.

For i.MX U-Boot, the starting point is the FSL eSDHC-family driver under drivers/mmc/. Whether the build selects SDMA or ADMA, and where that decision is made, must be confirmed from the exact source tree and configuration. Do not infer the DMA path from binary strings alone.

7. Why This Exercise Matters for BSP Work

BSP engineering is more than building an image. It is the discipline of connecting board pins, clocks, power rails, memory, and storage—as described in the bootloader and kernel—to real electrical signals that can be measured and verified.

Use this single mmc read as a starting point for the following questions.

• Why is eMMC mmc 2 on this board?
• Which USDHC node in the Device Tree describes this controller?
• What bus width and negotiated speed are currently in use?
• How does the read data arrive in RAM via DMA without passing through the CPU cache?
• How does the path observed in U-Boot map to the Linux kernel MMC block device path?

Key Takeaways

1. UUU sends commands; a separate instrument measures the eMMC bus signals.
2. Even when normal boot fails, SDP or Fastboot mode enables RAM-loaded U-Boot and read-only MMC diagnostics.
3. A single mmc read traces the full path: MMC subsystem, USDHC driver, DMA engine, CMD17, and the CLK/CMD/DAT waveform.
4. The actual DMA mode and bus speed must be confirmed from the board's source, configuration, and measurement results—not assumed.

#BSP #EmbeddedLinux #UBoot #UUU #eMMC #DeviceDriver