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

[Vitaly Andrianov]

On 03/03/2015 12:27 PM, Nishanth Menon wrote:
> On 02/18/2015 09:35 AM, menon.nishanth at gmail.com wrote:
>> On Wed, Feb 18, 2015 at 7:12 AM, Vitaly Andrianov <vitalya at ti.com> wrote:
>>>
>>>
>>> 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.
>>>>
>> [...]
>>> 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.
>>
>>
>> We would not need a u-boot.uart if current u-boot.bin can do the job, do we?
>>
>
> I just noticed this:
> http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.arm-relocation;h=645b3746c8a88fe25f7c9a33cd9b8b17aa7b5a57;hb=HEAD#l37
>
> without relocation capability, a board might be liable for removal?
>
The k2 u-boot is relocatable. It just simply cannot work w/o all 
required memory segments and its first instruction cannot be placed at 
the beginning of the available memory. You may want to look to common 
u-boot code for the reason.