Fastboot USB function과 command dispatch

QUESTION

Fastboot USB function과 command dispatch 단계에서 실제로 바뀌는 상태는 무엇인가?

STRUCTURE

객체와 주소가 놓이는 구조

CALL PATH

실행 흐름

STATE LEDGER

단계별 입력과 출력

각 단계의 입력과 처리 후 바뀌는 상태를 정리한 표다. 사용 중인 소스 버전에서 다른 필드를 변경한다면 그에 맞춰 표도 수정한다.

분석 범위의 전제와 비교해, 다음 단계에 잘못된 입력을 넘긴 부분부터 조사한다.

UPSTREAM SOURCE

원본 코드

아래 코드는 U-Boot v2026.07의 drivers/usb/gadget/f_fastboot.c에서 344-432줄을 그대로 가져온 것이다. 설명을 위해 실제 코드를 가짜 의사 코드로 바꾸지 않았다.

344	ret = usb_ep_enable(f_fb->in_ep, d);
345	if (ret) {
346		puts("failed to enable in ep\n");
347		goto err;
348	}
349
350	f_fb->in_req = fastboot_start_ep(f_fb->in_ep);
351	if (!f_fb->in_req) {
352		puts("failed alloc req in\n");
353		ret = -EINVAL;
354		goto err;
355	}
356	f_fb->in_req->complete = fastboot_complete;
357
358	ret = usb_ep_queue(f_fb->out_ep, f_fb->out_req, 0);
359	if (ret)
360		goto err;
361
362	return 0;
363err:
364	fastboot_disable(f);
365	return ret;
366}
367
368static int fastboot_add(struct usb_configuration *c)
369{
370	struct f_fastboot *f_fb = fastboot_func;
371	int status;
372
373	debug("%s: cdev: 0x%p\n", __func__, c->cdev);
374
375	if (!f_fb) {
376		f_fb = memalign(CONFIG_SYS_CACHELINE_SIZE, sizeof(*f_fb));
377		if (!f_fb)
378			return -ENOMEM;
379
380		fastboot_func = f_fb;
381		memset(f_fb, 0, sizeof(*f_fb));
382	}
383
384	f_fb->usb_function.name = "f_fastboot";
385	f_fb->usb_function.bind = fastboot_bind;
386	f_fb->usb_function.unbind = fastboot_unbind;
387	f_fb->usb_function.set_alt = fastboot_set_alt;
388	f_fb->usb_function.disable = fastboot_disable;
389	f_fb->usb_function.strings = fastboot_strings;
390
391	status = usb_add_function(c, &f_fb->usb_function);
392	if (status) {
393		free(f_fb);
394		fastboot_func = NULL;
395	}
396
397	return status;
398}
399DECLARE_GADGET_BIND_CALLBACK(usb_dnl_fastboot, fastboot_add);
400
401static int fastboot_tx_write(const char *buffer, unsigned int buffer_size)
402{
403	struct usb_request *in_req = fastboot_func->in_req;
404	int ret;
405
406	memcpy(in_req->buf, buffer, buffer_size);
407	in_req->length = buffer_size;
408
409	usb_ep_dequeue(fastboot_func->in_ep, in_req);
410
411	ret = usb_ep_queue(fastboot_func->in_ep, in_req, 0);
412	if (ret)
413		printf("Error %d on queue\n", ret);
414	return 0;
415}
416
417static int fastboot_tx_write_str(const char *buffer)
418{
419	return fastboot_tx_write(buffer, strlen(buffer));
420}
421
422static void compl_do_reset(struct usb_ep *ep, struct usb_request *req)
423{
424	g_dnl_unregister();
425	do_reset(NULL, 0, 0, NULL);
426}
427
428static unsigned int rx_bytes_expected(struct usb_ep *ep)
429{
430	int rx_remain = fastboot_data_remaining();
431	unsigned int rem;
432	unsigned int maxpacket = usb_endpoint_maxp(ep->desc);

READING CONTRACT

발췌 범위와 읽기 기준

원문 344-432줄에는 앞뒤 문맥이 포함됩니다. 기준 구문 static int fastboot_add(struct usb_configuration *c)은 L368에 있습니다. 발췌 첫 줄을 함수 정의의 시작으로 해석하지 않습니다.

USB 전송 완료와 flash 완료는 다른 경계다. download buffer의 크기·수명, command parser의 길이 검증, backend write 결과가 응답 문자열에 반영되는지 본다.

DETAILS

내부 동작을 더 깊게 읽기

IMPLEMENTATION NOTES

구현을 읽을 때 놓치기 쉬운 부분

OBJECT LIFETIME

객체와 수명

FAILURE PATH

실패 지점과 증상

로그가 끊긴 함수뿐 아니라 그 함수에 주소, 크기, 플래그를 전달한 앞 단계도 조사한다. 오류 처리 후 등록된 객체나 하드웨어 설정이 그대로 남아 있는지도 확인한다.

EVIDENCE

소스 밖에서 확인할 증거

소스에서 파악한 동작을 실제 빌드 결과와 대상 보드의 로그로 확인한다. 아래 명령의 보드 이름과 툴체인 접두사는 사용 중인 빌드 환경에 맞게 바꾼다.

LAB

직접 확인할 실험

1. 01
   fastboot getvar all 결과와 partition table 비교

   fastboot function 진입 전후에 USB endpoints의 주소·크기·반환값과 timestamp를 함께 남긴다.

2. 02
   MAX_DOWNLOAD_SIZE 경계값 전송

   OUT request 진입 전후에 download buffer의 주소·크기·반환값과 timestamp를 함께 남긴다.

3. 03
   storage write 오류를 주입해 FAIL 응답 확인

   command parser 진입 전후에 command response의 주소·크기·반환값과 timestamp를 함께 남긴다.

PRIMARY REFERENCES

원문과 다음 글