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

[Vitaly Andrianov]

On 02/17/2015 05:47 PM, Nishanth Menon wrote:
> 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
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
As I've already mentioned this patch is not about improving or changing 
current u-boot.bin, but just providing a way to download it over UART 
port. Any improvements, if they are required, shall be done in other 
patches.

Regards,
-Vitaly