public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Murali Karicheri <m-karicheri2@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [U-boot][PATCH] keystone2: add support for UART download
Date: Tue, 17 Feb 2015 17:27:41 -0500	[thread overview]
Message-ID: <54E3C05D.2040908@ti.com> (raw)
In-Reply-To: <54E24FDB.3070304@ti.com>

Nishanth,

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.


Sorry for late in the discussion. Change MSMC to MSMC SRAM.

README under board/ti/ks2_evm that has links to the device
spec which explains what MSMC is
>
>> 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
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.
>> 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?
>> Signed-off-by: Vitaly Andrianov<vitalya@ti.com>
>> Acked-by: Murali Karicheri<m-karicheri2@ti.com>
>> Tested-by: Murali Karicheri<m-karicheri2@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?
>
>> +
>> +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?
>
>> +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:
> ----
> 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?
>
>>   Load and Run U-Boot on keystone EVMs using CCS
>>   =========================================
>>
>>
>


-- 
Murali Karicheri
Linux Kernel, Texas Instruments

  parent reply	other threads:[~2015-02-17 22:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-16 18:22 [U-Boot] [U-boot][PATCH] keystone2: add support for UART download Vitaly Andrianov
2015-02-16 20:15 ` Nishanth Menon
2015-02-16 20:56   ` Vitaly Andrianov
2015-02-16 21:29     ` Nishanth Menon
2015-02-17 22:27   ` Murali Karicheri [this message]
2015-02-17 22:47     ` Nishanth Menon
2015-02-18 13:12       ` Vitaly Andrianov
2015-02-18 15:35         ` menon.nishanth at gmail.com
2015-03-03 17:27           ` Nishanth Menon
2015-03-03 18:29             ` Vitaly Andrianov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54E3C05D.2040908@ti.com \
    --to=m-karicheri2@ti.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox