relocation 이후 board_init_r | U-Boot

QUESTION

relocation 이후 board_init_r 단계에서 실제로 바뀌는 상태는 무엇인가?

relocation은 memcpy 하나가 아니다. absolute relocation, gd 교체, BSS, malloc, driver model 재초기화가 어느 주소 기준으로 수행되는지 분리한다.

board_init_r에 들어왔을 때 PC, SP, gd와 relocation table이 모두 새 주소 체계를 가리켜야 한다. 이 문장을 기준으로 코드를 위에서 아래로 읽으면, 함수 이름을 외우는 대신 어느 시점에 어떤 상태를 신뢰할 수 있는지 판단할 수 있다.

STRUCTURE

객체와 주소가 놓이는 구조

그림 1. relocation 이후 board_init_r에서 입력, 내부 상태, 출력의 경계

입력과 전제내부 상태외부로 공개되는 결과

01old image

02relocated image

03runtime heap

04devices and CLI

INVARIANT

board_init_r에 들어왔을 때 PC, SP, gd와 relocation table이 모두 새 주소 체계를 가리켜야 한다.

gd_t after relocation / init_sequence_r[]를 중심에 놓고 왼쪽의 입력이 어떤 검사를 거쳐 오른쪽 결과로 공개되는지 표시했다. 실제 디버깅에서는 각 블록의 주소와 크기를 로그에 대입한다.

CALL PATH

실행 흐름

그림 2. 정상 경로의 주요 호출과 상태 전달

relocate_code

fix relocations

new gd

board_init_r

main_loop

화살표는 단순 호출 순서만 뜻하지 않는다. 각 단계가 성공을 반환할 때 다음 단계가 읽을 수 있는 상태가 무엇인지 함께 확인한다. 오류 반환이 발생하면 바로 다음 화살표로 진행하지 않고 해당 단계의 정리 경로를 따라간다.

STATE LEDGER

단계별 입력과 출력

호출 순서를 함수 이름으로만 외우지 않고, 각 단계가 무엇을 받아 무엇을 공개하는지 적은 표다. 실제 소스에서 생산 필드가 다르면 표를 고치는 방식으로 사용한다.

#	단계	진입 시 신뢰할 상태	성공 뒤 남아야 할 상태	다음 소비자
01	`relocate_code`	부트 CPU의 동기 실행 문맥	old image	fix relocations
02	`fix relocations`	relocate_code 완료 상태	relocated image	new gd
03	`new gd`	fix relocations 완료 상태	runtime heap	board_init_r
04	`board_init_r`	new gd 완료 상태	devices and CLI	main_loop
05	`main_loop`	board_init_r 완료 상태	devices and CLI	최종 최종 부트로더 이미지 또는 다음 stage

공통 불변 조건: board_init_r에 들어왔을 때 PC, SP, gd와 relocation table이 모두 새 주소 체계를 가리켜야 한다. 한 단계의 출력이 다음 단계의 입력 조건을 만족하지 않으면 오류가 실제로 드러난 위치보다 앞의 생산 단계부터 조사한다.

VISUAL WALKTHROUGH

주소와 객체의 이동을 그림으로 읽기

아래 그림은 호출 이름보다 주소, 객체 수명과 handoff 경계를 먼저 볼 수 있도록 구성했다. 실제 주소와 크기는 사용 중인 보드의 bdinfo, map과 linker symbol을 대입한다.

그림 3. 옛 image에서 새 DRAM image로 제어권이 이동하는 과정

copy, pointer fixup, register 전환과 runtime 초기화는 서로 다른 단계다.

01old PC에서 실행

02새 DRAM 주소로 image copy

03relocation entry 적용

04D-cache clean

05I-cache invalidate

06새 SP·gd 선택

07새 PC로 분기

08board_init_r

그림 4. link-time symbol과 runtime 주소의 관계

image 내부 symbol을 새 base로 옮길 때 사용하는 기본 관계다.

01offsetnew_base - link_base

gd->reloc_off의 개념

02symbollink_symbol + offset

새 image 안의 symbol 주소

03pointerold_image_pointer + offset

fixup 대상 pointer

04stackreserved_stack_top

단순 offset이 아니라 예약 결과 사용

05gdreserved_new_gd

내용을 복사한 뒤 register 교체

그림 5. relocation 전후에 같은 이름이 가리키는 객체

이름은 같아도 주소와 수명이 달라진다.

Pre-relocation

01old text/data

02초기 gd

03초기 stack

04early malloc

05원래 FDT

06pre-reloc device

Post-relocation

01new text/data

02new gd

03new stack

04runtime malloc

05relocated FDT

06다시 bind/probe된 device

UPSTREAM SOURCE

원본 코드

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

commitece349ade2973e220f524ce59e59711cc919263fsymbolvoid board_init_r(gd_t *new_gd, ulong dest_addr)

755	INITCALL(initr_boot_led_blink);
756	/* PPC has a udelay(20) here dating from 2002. Why? */
757#if CONFIG_IS_ENABLED(BOARD_LATE_INIT)
758	INITCALL(board_late_init);
759#endif
760#if CONFIG_IS_ENABLED(PCI_ENDPOINT)
761	INITCALL(pci_ep_init);
762#endif
763#if CONFIG_IS_ENABLED(NET)
764	WATCHDOG_RESET();
765	INITCALL(initr_net);
766#endif
767#if CONFIG_IS_ENABLED(POST)
768	INITCALL(initr_post);
769#endif
770	WATCHDOG_RESET();
771	INITCALL_EVT(EVT_LAST_STAGE_INIT);
772#if defined(CFG_PRAM)
773	INITCALL(initr_mem);
774#endif
775	INITCALL(initr_boot_led_on);
776	INITCALL(run_main_loop);
777}
778
779void board_init_r(gd_t *new_gd, ulong dest_addr)
780{
781	/*
782	 * The pre-relocation drivers may be using memory that has now gone
783	 * away. Mark serial as unavailable - this will fall back to the debug
784	 * UART if available.
785	 *
786	 * Do the same with log drivers since the memory may not be available.
787	 */
788	gd->flags &= ~(GD_FLG_SERIAL_READY | GD_FLG_LOG_READY);
789
790	/*
791	 * Set up the new global data pointer. So far only x86 does this
792	 * here.
793	 * TODO(sjg@chromium.org): Consider doing this for all archs, or
794	 * dropping the new_gd parameter.
795	 */
796	if (CONFIG_IS_ENABLED(X86_64) && !IS_ENABLED(CONFIG_EFI_APP))
797		arch_setup_gd(new_gd);
798
799#if defined(CONFIG_RISCV)
800	set_gd(new_gd);
801#elif !defined(CONFIG_X86) && !defined(CONFIG_ARM) && !defined(CONFIG_ARM64)
802	gd = new_gd;
803#endif
804	gd->flags &= ~GD_FLG_LOG_READY;
805
806	initcall_run_r();
807
808	/* NOTREACHED - run_main_loop() does not return */
809	hang();
810}
811

LINE BY LINE

755-811줄 해설

원본에 보이는 모든 줄을 순서대로 설명한다. 빈 줄도 block 경계로 남겨, 코드와 설명의 위치가 어긋나지 않게 했다.

755INITCALL(initr_boot_led_blink);

initr_boot_led_blink()을 실행한다. 성공은 0 반환이며, 실패하면 INITCALL 매크로가 함수 이름을 남기고 hang()으로 진행을 중단한다.

756/* PPC has a udelay(20) here dating from 2002. Why? */

원본 주석이 'PPC has a udelay(20) here dating from 2002. Why?'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

757#if CONFIG_IS_ENABLED(BOARD_LATE_INIT)

#if 전처리 지시문으로 이 줄 아래의 code가 binary에 존재할지를 결정한다. 관련 설정은 CONFIG_IS_ENABLED이다. 현재 .config와 compiler의 -dD -E 출력에서 실제로 남은 branch를 확인한 뒤 line-by-line 흐름에 포함한다.

758INITCALL(board_late_init);

board_late_init()을 실행한다. 성공은 0 반환이며, 실패하면 INITCALL 매크로가 함수 이름을 남기고 hang()으로 진행을 중단한다.

759#endif

#endif 전처리 지시문으로 이 줄 아래의 code가 binary에 존재할지를 결정한다. architecture 또는 build stage 조건을 여닫는다. 현재 .config와 compiler의 -dD -E 출력에서 실제로 남은 branch를 확인한 뒤 line-by-line 흐름에 포함한다.

760#if CONFIG_IS_ENABLED(PCI_ENDPOINT)

761INITCALL(pci_ep_init);

pci_ep_init()을 실행한다. 성공은 0 반환이며, 실패하면 INITCALL 매크로가 함수 이름을 남기고 hang()으로 진행을 중단한다.

762#endif

763#if CONFIG_IS_ENABLED(NET)

764WATCHDOG_RESET();

WATCHDOG_RESET(인자 없음)를 호출한다. 반환값을 직접 사용하지 않으므로 이 함수가 실패를 내부 처리하는지 확인해야 한다. pointer 인자는 gd_t after relocation / init_sequence_r[]의 소유권을 넘기는지 호출 동안만 빌리는지 구분하고, 호출 뒤 공개되는 상태를 devices and CLI 항목과 대조한다.

765INITCALL(initr_net);

initr_net()을 실행한다. 성공은 0 반환이며, 실패하면 INITCALL 매크로가 함수 이름을 남기고 hang()으로 진행을 중단한다.

766#endif

767#if CONFIG_IS_ENABLED(POST)

768INITCALL(initr_post);

initr_post()을 실행한다. 성공은 0 반환이며, 실패하면 INITCALL 매크로가 함수 이름을 남기고 hang()으로 진행을 중단한다.

769#endif

770WATCHDOG_RESET();

771INITCALL_EVT(EVT_LAST_STAGE_INIT);

INITCALL_EVT(EVT_LAST_STAGE_INIT)를 호출한다. 반환값을 직접 사용하지 않으므로 이 함수가 실패를 내부 처리하는지 확인해야 한다. pointer 인자는 gd_t after relocation / init_sequence_r[]의 소유권을 넘기는지 호출 동안만 빌리는지 구분하고, 호출 뒤 공개되는 상태를 devices and CLI 항목과 대조한다.

772#if defined(CFG_PRAM)

#if 전처리 지시문으로 이 줄 아래의 code가 binary에 존재할지를 결정한다. architecture 또는 build stage 조건을 여닫는다. 현재 .config와 compiler의 -dD -E 출력에서 실제로 남은 branch를 확인한 뒤 line-by-line 흐름에 포함한다.

773INITCALL(initr_mem);

initr_mem()을 실행한다. 성공은 0 반환이며, 실패하면 INITCALL 매크로가 함수 이름을 남기고 hang()으로 진행을 중단한다.

774#endif

775INITCALL(initr_boot_led_on);

initr_boot_led_on()을 실행한다. 성공은 0 반환이며, 실패하면 INITCALL 매크로가 함수 이름을 남기고 hang()으로 진행을 중단한다.

776INITCALL(run_main_loop);

run_main_loop()을 실행한다. 성공은 0 반환이며, 실패하면 INITCALL 매크로가 함수 이름을 남기고 hang()으로 진행을 중단한다.

777}

현재 block, initializer 또는 호출의 경계를 닫는다. 이 지점까지 획득한 resource가 성공 경로와 실패 경로에서 대칭인지 점검한다.

778(빈 줄)

}까지의 동작과 void board_init_r(gd_t *new_gd, ulong dest_addr)에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 devices and CLI 상태가 아래 블록의 입력으로 사용되는 경계다.

779void board_init_r(gd_t *new_gd, ulong dest_addr)

board_init_r 함수 정의가 시작된다. 입력은 gd_t *new_gd, ulong dest_addr이며, 부트 CPU의 동기 실행 문맥에서 호출된다는 전제로 반환 전까지의 상태 변화를 읽는다.

780{

바로 위 함수·조건·초기화의 block이 열린다. 이 scope 안에서 만들어지는 지역 객체와 오류 이동 지점을 gd_t after relocation / init_sequence_r[]의 수명에 맞춰 묶어 읽는다.

781/*

원본 주석이 'block boundary'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

782* The pre-relocation drivers may be using memory that has now gone

원본 주석이 'The pre-relocation drivers may be using memory that has now gone'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

783* away. Mark serial as unavailable - this will fall back to the debug

원본 주석이 'away. Mark serial as unavailable - this will fall back to the debug'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

784* UART if available.

원본 주석이 'UART if available.'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

785*

원본 주석이 'block boundary'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

786* Do the same with log drivers since the memory may not be available.

원본 주석이 'Do the same with log drivers since the memory may not be available.'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

787*/

원본 주석이 'block boundary'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

788gd->flags &= ~(GD_FLG_SERIAL_READY | GD_FLG_LOG_READY);

gd->flags에 ~(GD_FLG_SERIAL_READY | GD_FLG_LOG_READY)를 &= 연산으로 반영해 gd_t after relocation / init_sequence_r[]와 연결된 field를 갱신한다. 이후 main_loop 단계가 이 값을 처음 소비하는 지점을 찾는다. 실패 경로가 이 field를 이전 값으로 되돌리거나 객체 전체를 폐기하는지도 확인한다.

789(빈 줄)

gd->flags &= ~(GD_FLG_SERIAL_READY | GD_FLG_LOG_READY);까지의 동작과 /*에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 devices and CLI 상태가 아래 블록의 입력으로 사용되는 경계다.

790/*

원본 주석이 'block boundary'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

791* Set up the new global data pointer. So far only x86 does this

원본 주석이 'Set up the new global data pointer. So far only x86 does this'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

792* here.

원본 주석이 'here.'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

793* TODO(sjg@chromium.org): Consider doing this for all archs, or

원본 주석이 'TODO(sjg@chromium.org): Consider doing this for all archs, or'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

794* dropping the new_gd parameter.

원본 주석이 'dropping the new_gd parameter.'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

795*/

원본 주석이 'block boundary'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

796if (CONFIG_IS_ENABLED(X86_64) && !IS_ENABLED(CONFIG_EFI_APP))

CONFIG_IS_ENABLED(X86_64) && !IS_ENABLED(CONFIG_EFI_APP)를 검사해 진행 여부를 가른다. 거짓 경로와 참 경로 중 어느 쪽이 'board_init_r에 들어왔을 때 PC, SP, gd와 relocation table이 모두 새 주소 체계를 가리켜야 한다' 조건을 보존하는지 다음 return 또는 goto까지 따라간다.

797arch_setup_gd(new_gd);

arch_setup_gd(new_gd)를 호출한다. 반환값을 직접 사용하지 않으므로 이 함수가 실패를 내부 처리하는지 확인해야 한다. pointer 인자는 gd_t after relocation / init_sequence_r[]의 소유권을 넘기는지 호출 동안만 빌리는지 구분하고, 호출 뒤 공개되는 상태를 devices and CLI 항목과 대조한다.

798(빈 줄)

arch_setup_gd(new_gd);까지의 동작과 #if defined(CONFIG_RISCV)에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 devices and CLI 상태가 아래 블록의 입력으로 사용되는 경계다.

799#if defined(CONFIG_RISCV)

#if 전처리 지시문으로 이 줄 아래의 code가 binary에 존재할지를 결정한다. 관련 설정은 CONFIG_RISCV이다. 현재 .config와 compiler의 -dD -E 출력에서 실제로 남은 branch를 확인한 뒤 line-by-line 흐름에 포함한다.

800set_gd(new_gd);

set_gd(new_gd)를 호출한다. 반환값을 직접 사용하지 않으므로 이 함수가 실패를 내부 처리하는지 확인해야 한다. pointer 인자는 gd_t after relocation / init_sequence_r[]의 소유권을 넘기는지 호출 동안만 빌리는지 구분하고, 호출 뒤 공개되는 상태를 devices and CLI 항목과 대조한다.

801#elif !defined(CONFIG_X86) && !defined(CONFIG_ARM) && !defined(CONFIG_ARM64)

#elif 전처리 지시문으로 이 줄 아래의 code가 binary에 존재할지를 결정한다. 관련 설정은 CONFIG_X86, CONFIG_ARM, CONFIG_ARM64이다. 현재 .config와 compiler의 -dD -E 출력에서 실제로 남은 branch를 확인한 뒤 line-by-line 흐름에 포함한다.

802gd = new_gd;

gd에 new_gd를 = 연산으로 반영해 현재 scope의 계산 결과를 저장한다. 이후 main_loop 단계가 이 값을 처음 소비하는 지점을 찾는다. 실패 경로가 이 field를 이전 값으로 되돌리거나 객체 전체를 폐기하는지도 확인한다.

803#endif

804gd->flags &= ~GD_FLG_LOG_READY;

gd->flags에 ~GD_FLG_LOG_READY를 &= 연산으로 반영해 gd_t after relocation / init_sequence_r[]와 연결된 field를 갱신한다. 이후 main_loop 단계가 이 값을 처음 소비하는 지점을 찾는다. 실패 경로가 이 field를 이전 값으로 되돌리거나 객체 전체를 폐기하는지도 확인한다.

805(빈 줄)

gd->flags &= ~GD_FLG_LOG_READY;까지의 동작과 initcall_run_r();에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 devices and CLI 상태가 아래 블록의 입력으로 사용되는 경계다.

806initcall_run_r();

initcall_run_r(인자 없음)를 호출한다. 반환값을 직접 사용하지 않으므로 이 함수가 실패를 내부 처리하는지 확인해야 한다. pointer 인자는 gd_t after relocation / init_sequence_r[]의 소유권을 넘기는지 호출 동안만 빌리는지 구분하고, 호출 뒤 공개되는 상태를 devices and CLI 항목과 대조한다.

807(빈 줄)

initcall_run_r();까지의 동작과 /* NOTREACHED - run_main_loop() does not return */에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 devices and CLI 상태가 아래 블록의 입력으로 사용되는 경계다.

808/* NOTREACHED - run_main_loop() does not return */

원본 주석이 'NOTREACHED - run_main_loop() does not return'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

809hang();

hang(인자 없음)를 호출한다. 반환값을 직접 사용하지 않으므로 이 함수가 실패를 내부 처리하는지 확인해야 한다. pointer 인자는 gd_t after relocation / init_sequence_r[]의 소유권을 넘기는지 호출 동안만 빌리는지 구분하고, 호출 뒤 공개되는 상태를 devices and CLI 항목과 대조한다.

810}

현재 block, initializer 또는 호출의 경계를 닫는다. 이 지점까지 획득한 resource가 성공 경로와 실패 경로에서 대칭인지 점검한다.

811(빈 줄)

}까지의 동작과 다음 block 경계에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 devices and CLI 상태가 아래 블록의 입력으로 사용되는 경계다.

DETAILS

내부 동작을 더 깊게 읽기

진입 조건을 먼저 고정한다

relocate_code에서 들어온 실행은 부트 CPU의 동기 실행 문맥에 놓여 있다. 이때 interrupt, MMU/cache, stack, heap 중 무엇이 이미 준비되었는지 소스의 호출자까지 올라가 확인한다. 같은 함수라도 SPL, relocation 전후, app thread처럼 호출 문맥이 달라지면 허용되는 API와 지연 시간이 달라진다.

relocation은 memcpy 하나가 아니다. absolute relocation, gd 교체, BSS, malloc, driver model 재초기화가 어느 주소 기준으로 수행되는지 분리한다.

중심 객체의 생성과 공개를 나눈다

이 글의 중심 객체는 gd_t after relocation / init_sequence_r[]다. 메모리를 확보한 시점, 필드를 채운 시점, 전역 list나 다른 subsystem에 공개한 시점을 구분한다. 공개 뒤 오류가 발생한다면 목록에서 제거하고 child, buffer, reference를 역순으로 정리하는지 확인한다.

빌드 산출물 관점에서는 최종 부트로더 이미지 안에 해당 symbol과 section이 실제로 포함되었는지도 map과 objdump로 검증한다.

주소, 크기와 정렬을 계산한다

부트 코드의 오류는 논리보다 주소 계산에서 먼저 드러나는 경우가 많다. source range, destination range, header가 말하는 payload size, block 또는 page 단위를 표로 적고 각 구간의 끝 주소를 직접 계산한다. 끝 주소는 start + size - 1인지 exclusive end인지 API 계약을 확인한다.

board_init_r에 들어왔을 때 PC, SP, gd와 relocation table이 모두 새 주소 체계를 가리켜야 한다.

성공 flag와 실제 완료 시점을 맞춘다

fix relocations → new gd → board_init_r 구간에서는 부분 초기화 상태가 생길 수 있다. flag, list insertion, callback 등록, storage write 완료 중 무엇이 성공의 기준인지 찾는다. hardware write나 DMA가 포함되면 함수 반환과 장치 완료가 같은 시점인지도 확인한다.

다른 CPU, interrupt handler, USB completion 또는 shell command가 상태를 관찰할 수 있다면 memory ordering과 lock 범위도 함께 읽는다.

마지막 handoff의 계약을 적는다

정상 경로는 main_loop에서 끝난다. 이 단계가 함수 반환인지, scheduler 전환인지, 다른 image로의 비복귀 분기인지 구분한다. 비복귀 handoff라면 cache clean/invalidate, interrupt disable, 장치 quiesce, argument register와 FDT 또는 image address가 최종 점검 항목이다.

반환하는 경로라면 caller가 오류와 부분 성공을 구분하고 다음 후보 또는 복구 경로를 선택하는지 확인한다.

IMPLEMENTATION NOTES

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

코드 복사와 relocation fixup은 별개의 작업이다

image byte를 새 DRAM 주소로 복사해도 absolute pointer와 relocation entry가 옛 link 주소를 가리킬 수 있다. architecture별 relocation loop가 어떤 relocation type을 지원하고 gd->reloc_off를 어디에 더하는지 ELF relocation table과 대조한다.

instruction cache와 data cache가 켜져 있다면 copy 완료, cache clean, instruction invalidate, 새 PC 분기의 순서도 실행 계약이다. debugger가 memory를 읽어 새 코드가 보인다는 사실만으로 CPU가 그 명령을 fetch한다고 단정할 수 없다.

board_init_r은 새 주소 세계의 첫 C 경계다

board_init_r(new_gd, dest_addr)에 들어오면 SP, PC와 gd가 모두 DRAM 쪽을 가리켜야 한다. init_sequence_r는 runtime malloc, driver model 재초기화, storage와 console, environment를 열기 때문에 pre-relocation 객체를 그대로 재사용하는 코드가 가장 쉽게 드러난다.

pre-relocation device는 flag에 따라 다시 bind/probe되며 cyclic callback도 새 객체에서 재등록된다. old gd와 old device pointer가 list에 남지 않았는지 주소 범위로 검사한다.

relocation 전후 로그는 같은 symbol의 주소가 다르다

함수 이름만 기록하면 두 실행 단계를 구분하기 어렵다. 현재 PC, gd, SP와 reloc_off를 함께 출력하고 map의 link-time symbol에 offset을 더한 값이 runtime PC와 일치하는지 확인한다.

BSS clear 시점이 architecture와 configuration에 따라 다를 수 있으므로 무조건 relocation 직후 0이라고 가정하지 않는다. 초기화 flag가 사라지는 문제는 BSS clear와 object copy 순서를 먼저 본다.

OBJECT LIFETIME

객체와 수명

대상	만들어지는 시점	유효 범위	확인할 조건
`gd_t after relocation / init_sequence_r[]`	fix relocations	main_loop 또는 오류 정리 완료까지	board_init_r에 들어왔을 때 PC, SP, gd와 relocation table이 모두 새 주소 체계를 가리켜야 한다.
입력 buffer / metadata	relocate_code	parse와 검증이 끝날 때까지	길이, 정렬, 소유권, 변조 가능성
등록된 list / descriptor	new gd	subsystem 종료 또는 image handoff까지	이중 등록, dangling pointer, 오류 unwind
hardware 또는 persistent state	실제 write/probe가 완료된 뒤	reset 또는 명시적 해제·갱신까지	flush, timeout, 전원 차단, rollback
`최종 부트로더 이미지`	link/image 생성 시점	다음 stage가 새 image로 교체할 때까지	load address, entry, section과 header 일치

FAILURE PATH

실패 지점과 증상

#	조건	관찰되는 증상	먼저 볼 단계
01	relocation fixup 누락	함수 포인터 오분기	fix relocations
02	old gd 참조	임의 상태 읽기	new gd
03	cache 정리 누락	옛 instruction 실행	board_init_r

로그가 끊긴 마지막 함수만 고치지 않는다. 그 함수가 받은 주소, size, flag가 만들어진 앞 단계까지 올라가고, 오류 뒤 등록 객체와 hardware 상태가 남았는지도 확인한다.

EVIDENCE

소스 밖에서 확인할 증거

소스 해석은 실제 빌드 산출물과 target 로그로 닫아야 한다. 아래 명령의 보드 이름과 toolchain prefix는 사용 중인 빌드 환경에 맞게 바꾼다.

#	목적	명령 또는 계측	판정 기준
01	전처리 결과	`make <board>_defconfig && make V=1`	선택된 CONFIG와 실제 compile/link 명령을 보관한다.
02	symbol과 section	`${CROSS_COMPILE}nm -n u-boot \| grep 'void board_init_r'`	symbol 주소가 기대한 stage와 image에 들어갔는지 확인한다.
03	어셈블리 대조	`${CROSS_COMPILE}objdump -drS u-boot`	C 한 줄이 실제 branch, relocation, memory access로 어떻게 바뀌었는지 본다.
04	주소 배치	`bdinfo`	relocaddr, malloc, FDT, stack과 DRAM bank 주소를 한 번에 기록한다.
05	runtime 관찰	`dm tree; dm uclass; printenv`	driver model과 환경이 이 단계에서 실제로 공개되었는지 확인한다.

LAB

직접 확인할 실험

01
reloc_off와 심볼 실주소 비교
fix relocations 진입 전후에 old image의 주소·크기·반환값과 timestamp를 함께 남긴다. 결과는 정상 부팅 여부로 끝내지 말고 board_init_r에 들어왔을 때 PC, SP, gd와 relocation table이 모두 새 주소 체계를 가리켜야 한다. 조건이 처음 깨지는 줄을 기록한다.
02
relocation table entry 하나를 objdump로 추적
new gd 진입 전후에 relocated image의 주소·크기·반환값과 timestamp를 함께 남긴다. 결과는 정상 부팅 여부로 끝내지 말고 board_init_r에 들어왔을 때 PC, SP, gd와 relocation table이 모두 새 주소 체계를 가리켜야 한다. 조건이 처음 깨지는 줄을 기록한다.
03
I-cache invalidate 전후 fault 차이 확인
board_init_r 진입 전후에 runtime heap의 주소·크기·반환값과 timestamp를 함께 남긴다. 결과는 정상 부팅 여부로 끝내지 말고 board_init_r에 들어왔을 때 PC, SP, gd와 relocation table이 모두 새 주소 체계를 가리켜야 한다. 조건이 처음 깨지는 줄을 기록한다.

PRIMARY REFERENCES

원문과 다음 글

common/board_r.cv2026.07 원본 파일 U-Boot source tree기준 commit ece349ade297