[U-Boot] [RFC][PATCH 0/3] New i386 board (includes code relocation)

[Graeme Russ]

Hi All,

I have managed to get the initial port of U-Boot to my custom sc520
(x86) based board built and running and even managed (I think) to get
the fundamentals of the code relocation working (really happy about
that) and I would like some feedback on my mods - specifically the
relocation methodology I am using does not, I think, quite fit that
used on other boards.

When the i386 code was originally written, start.S calls
start_i386boot (). Other boards seem to call board_init_f () which
calls relocate_code () which performs the actual relocation and calls
board_init_r (). Whats more, I have defined CFG_RELOC_ADDR which
specifies the destination in RAM of the relocated code whereas other
boards seem to dynamically calculate the relocation address based on
stack, data, bss etc segment sizes. My relocation code performs the
code relocation before the first C function is called rather than
between board_init_f and board_init_r.

Q. Should I spend a some more time and implement board_init_f /
relocate_code / board_init_r as per other boards or is the approach
I have taken acceptable?

I am concerned about the size of the relocation copy - If you take a
look at /board/eNET/u-boot.lds

	. = 0x38040000;                     /* Where bootcode in the flash is mapped */
	.text  : { *(.text); }

	. = ALIGN(4);
	.rodata : { *(.rodata) *(.rodata.str1.1) *(.rodata.str1.32) }

	_i386boot_text_size = SIZEOF(.text) + SIZEOF(.rodata);

I only copy _i386boot_text_size bytes (adjusted up to the nearest
4-byte boundary.

Q. Will _i386boot_text_size take into account the . = ALIGN(4)
between .text and .rodata or should I add some further adjustments?

Finally a quick warning about [PATCH 3/3] - I've broken a cardinal
rule and combined implementing a new feature with removing an old
(test printf()'s)

Regards,

Graeme