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

[Nishanth Menon]

On 02/16/2015 02:56 PM, Vitaly Andrianov wrote:
> 
> 
> On 02/16/2015 03:15 PM, Nishanth Menon wrote:
>> On 02/16/2015 12:22 PM, Vitaly Andrianov wrote:
>>> Currently to flash u-boot image onto NAND or SPI NOR flash, very first
>>> time user need to use Code Composer Studio (CCS). This is cumbersome for
>>> an user not familiar with CCS. This patch add simpler procedure using
>>> uart boot mode for K2 EVMs.
>>>
>>> When UART bootmode is set and board is rebooted, the ROM boot loader
>>> transfers the image at the beginning of the MSMC. After the transfer
>>
>> please explain MSMC.
>>
>>> 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?
> 
> We already have u-boot linked to the 0x0c001000 address. Why do we need 
> to build another version for one time process.

Why is it a one time process? consider continuous integration(CI)
model for validating u-boot - UART mode is perfect for such an
automated testing -> flash over uart, test basic boot, reflash over to
SPI and NAND and test that as well. we can do it as frequently as we
want and ensure that any user of k2* board will get the exact
functional experience no matter which u-boot revision they pick.

>>> 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?
> 
> Relocation logic to where? ROM bootloader? I can put a branch 
> instruction at the beginning, but we still need 4k of pad, which will be 
> loaded anyways. So, adding the branch will reduce several microseconds 
> out of ~40 seconds.

I thought u-boot was always position independent code with
relocate_code being invoked to move to position dependent logic.

Was'nt this the standard procedure for u-boot to let u-boot to be
downloaded to any address? I wonder if something is broke or dependent
now...

Anyways, ignore the overall 40 second angle for a moment- that is OS
dependent and there is tons of optimizations at different layers for
the same - and that has nothing to do with the objective of the patch :).

If we do have relocation logic functional, then we should be able to
execute off a proper address and relocate off to a safe location. but
i suspect the link address at 0xc001000 might indicate that there is
no safe way to relocate when loaded up at 0xc000000, given the size of
u-boot.bin. solution must then be to move it linking off 0xc001000 to
somewhere else.


>>>
>>> Signed-off-by: Vitaly Andrianov <vitalya at ti.com>
>>> Acked-by: Murali Karicheri <m-karicheri2 at ti.com>
>>> Tested-by: Murali Karicheri <m-karicheri2 at ti.com>
>>> ---
>>>   Makefile                |  6 ++++++
>>>   board/ti/ks2_evm/README | 17 +++++++++++++++++
>>>   2 files changed, 23 insertions(+)
>>>
>>> diff --git a/Makefile b/Makefile
>>> index 36a9a28..7a86cac 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -940,6 +940,12 @@ u-boot-nand.gph: u-boot.bin FORCE
>>>   	$(call if_changed,mkimage)
>>>   	@dd if=/dev/zero bs=8 count=1 2>/dev/null >> $@
>>>
>>> +u-boot.uart.pad:
>>> +	@dd if=/dev/zero bs=4 count=1024 2>/dev/null > $@
>>
>> How about the cleaning up?
>> is it not better to do this algorithmically?
> 
> Cleaning up what?
> The u-boot.uart.pad is cleaned by the "clean" target.

Uggh.. I missed the following rule and was wondering how did
u-boot.uart.pad (a new file entry) get cleaned up.
CLOBBER_FILES += u-boot* MLO* SPL System.map

do we need to update .gitignore?
> 
>>
>>> +
>>> +u-boot.uart: u-boot.uart.pad u-boot.bin FORCE
>>> +	$(call if_changed,cat)
>>> +
>>>   # x86 uses a large ROM. We fill it with 0xff, put the 16-bit stuff (including
>>>   # reset vector) at the top, Intel ME descriptor at the bottom, and U-Boot in
>>>   # the middle.
>>> diff --git a/board/ti/ks2_evm/README b/board/ti/ks2_evm/README
>>> index 9ee90a4..a1fc943 100644
>>> --- a/board/ti/ks2_evm/README
>>> +++ b/board/ti/ks2_evm/README
>>> @@ -81,6 +81,23 @@ To build u-boot-nand.gph
>>>     >make k2hk_evm_defconfig
>>>     >make u-boot-nand.gph
>>>
>>> +To build u-boot.uart
>>> +  >make k2hk_evm_defconfig
>>> +  >make u-boot.uart
>>> +
>>> +
>>
>> extra EOL?
>>
> Will remove
> 
>>> +Load and Run U-Boot on keystone EVMs using UART download
>>> +========================================================
>>> +
>>> +Open BMC and regular UART terminals.
>>> +
>>> +1. On the regular UART port start xmodem transfer of the u-boot.uart
>>> +2. Using BMC terminal set the ARM-UART bootmode and reboot the EVM
>>> +   BMC> bootmode #4
>>> +   MBC> reboot
>>> +3. When xmodem is complete you should see the u-boot starts on the UART port
>> This is hard to do in practice. At times when one has regular OS
>> running already in uart port, it tends to mess up xmodem before we
>> switch terminal and issue bootmode #4 and reboot to BMC.
>> instead, the only failsafe sequence I could come up with is as follows:
> 
> All point to have uart download is when the flashed u-boot is broken and 
> board doesn't boot up at all. In that case it cannot run regular OS you 
> are talking about. If u-boot can run regular OS, it can also upgrade the 
> u-boot by itself.

Not necessarily - how about me wanting to test latest u-boot without
having to reflash u-boot and make it permanent? it will be good for
instructions such as here NOT to make assumptions on the state of
user's board. infact, consider all the sequences where user might
attempt and provide a consistent result.

> 
>> ----
>> In this method, we use xmodem to download and start the modified
>> version of uart binary to the target over serial port. Open the BCM
>> and regular UART port at 115200n8 configuration. Steps are rather trivial:
>>
>> 1. At the BCM terminal, select the following to configure DSP noboot:
>>         bootmode #15
>>         reboot
>>     This should prevent any existing bootloader OR OS from starting up
>>     on UART
>> 2. Start Xmodem transfer of the file u-boot-uart.gph on the regular
>> UART port
>>     using minicom OR appropriate terminal emulator.
>> 3. At the BCM terminal, Switch over to UART mode and restart.
>>         bootmode #4
>>         reboot
>> 4. At the UART terminal, the transfer completes and u-boot startsup.
>> This may
>>     be used to download and flash u-boot to nand/spi etc.
>> ----
>>> +
>>> +
>> extra EOL?
> 
> Will remove
> 
>>
>>>   Load and Run U-Boot on keystone EVMs using CCS
>>>   =========================================
>>>
>>>
>>
>>


-- 
Regards,
Nishanth Menon