[U-Boot] [U-boot][PATCH] keystone2: add support for UART download

[Nishanth Menon]

On Tue, Feb 17, 2015 at 4:27 PM, Murali Karicheri <m-karicheri2 at ti.com> wrote:
>>> is complete the boot-loader sets the PC to the first MSMC address
>>> 0x0c000000. The u-boot.bin is linked to the address 0x0c001000.
>>
>> why not just shift u-boot.bin to start of MSMC address?
>
> What is wrong with the current implementation? NAND and SPI NOR boot modes
> use the
> GPH headers that has the load address defined. But in the case of UART, RBL

So it GPH header has the load address defined, it does mean that we
could infact change the start address to 0xc000000 (instead of current
0xc001000) and appropriately update the GPH headers to point there?
that way we can use 0xc000000 without padding on UART, as well as use
the same in NAND/SPI as well? correct?

> loads it to start of MSMC and adding 1K of NOP just avoid a jump instruction
> at
> the start of the memory to jump to 0xc001000. This way we can keep the same
> start address across all boot modes.

Padding a 4kbytes (1K NOP at 32bits each) just because there is a
difference between linked address and start address in a specific mode
makes one wonder. This probably is not definitely a uniquely KS2 issue
- we probably have similar behavior on other platforms as well. what
if we chose a link address 2MB away (as an example)? agreed that the
specific usage has no such size story in place, but conceptually we
might be able to do better.

>>> In order to use the u-boot.bin as an image for UART download, we need to
>>> add 4K zeros prefix that act as 1K NOP instructions before reaching
>>> 0xc001000.
>>
>> OR, add a relocation logic which saves the 1k NOP and resultant load time?
>
> What saving are you talking about? Miliseconds? seconds?

Maintainability? lets say we change link address tomorrow, we have to
adjust padding appropriately, further we just dont need padding when
we can just relocate self by being position independent in the first
place!.

we have learnt that over years OMAP3 link address has gone through a
few transitions as we discovered better ways to do things. doing
padding based on link address does, on the first look, seem
unnecessary, makes sense only if all of the following are wrong:
a) cannot change start address to the common start address for all boot modes.
b) cannot add relocation and position independent u-boot code.

And even when we do need to add padding, it is not a good idea to hard
code the pad size, instead do it algorithmically (basically query the
start and add the delta) allowing changes to link address to be
something folks can do at a later point in time without
unintentionally breaking uart boot.

---
Regards,
Nishanth Menon