keystone2: add support for UART download
PATCH 1/1 keystone2: add support for UART download
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 is complete the boot-loader sets the PC to the first MSMC address 0x0c000000. The u-boot.bin is linked to the address 0x0c001000.
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.
--- Makefile | 6 ++++++ board/ti/ks2_evm/README | 17 +++++++++++++++++ 2 files changed, 23 insertions(+)
Makefile +6 -0
@@ -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 > $@ + +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.
board/ti/ks2_evm/README +17 -0
@@ -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 + + +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 + + Load and Run U-Boot on keystone EVMs using CCS =========================================
Signature · 1 line
1.9.1
PATCH 1/1 keystone2: add support for UART download
Quoted 7 lines · Vitaly Andrianov
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.
Quoted 2 lines
is complete the boot-loader sets the PC to the first MSMC address
0x0c000000. The u-boot.bin is linked to the address0x0c001000.
why not just shift u-boot.bin to start of MSMC address?
Quoted 4 lines
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?
Quoted 14 lines
Signed-off-by Vitaly Andrianov <[email protected]>Acked-by Murali Karicheri <[email protected]>Tested-by Murali Karicheri <[email protected]>--- Makefile | 6 ++++++ board/ti/ks2_evm/README | 17 +++++++++++++++++ 2 files changed, 23 insertions(+)Makefile +0
-0
Makefile u-boot-nand.gph: u-boot.bin FORCE · line 944
Quoted 5 lines
Makefile +2
-0@@ -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?
Quoted 12 lines
Makefile +4
-0+ +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.board/ti/ks2_evm/README +0
-0
board/ti/ks2_evm/README To build u-boot-nand.gph · line 88
Quoted 8 lines
board/ti/ks2_evm/README +5
-0@@ -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?
board/ti/ks2_evm/README To build u-boot-nand.gph · line 98
Quoted 10 lines
board/ti/ks2_evm/README +10
-0+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.
----
board/ti/ks2_evm/README To build u-boot-nand.gph · line 100
Quoted 2 lines
board/ti/ks2_evm/README +2
-0+ +
extra EOL?
Quoted 4 lines
board/ti/ks2_evm/README +0
-0Load and Run U-Boot on keystone EVMs using CCS =========================================
Signature · 2 lines
Regards, Nishanth Menon
PATCH 1/1 keystone2: add support for UART download
Quoted 6 lines · Nishanth Menon
Quoted 5 lines · Vitaly Andrianov
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 2 lines
is complete the boot-loader sets the PC to the first MSMC address
0x0c000000. The u-boot.bin is linked to the address0x0c001000.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.
Quoted 6 lines
Quoted 4 lines
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.
Quoted 18 lines
Quoted 18 lines
Signed-off-by Vitaly Andrianov <[email protected]>Acked-by Murali Karicheri <[email protected]>Tested-by Murali Karicheri <[email protected]>--- Makefile | 6 ++++++ board/ti/ks2_evm/README | 17 +++++++++++++++++ 2 files changed, 23 insertions(+)Makefile +0
-0@@ -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 >> $@
Quoted 5 lines
Makefile u-boot-nand.gph: u-boot.bin FORCE · line 944
Quoted 2 lines
Makefile +2
-0+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.
Quoted 16 lines
Quoted 16 lines
Makefile +4
-0+ +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.board/ti/ks2_evm/README +0
-0@@ -81,6 +81,23 @@ To build u-boot-nand.gph >make k2hk_evm_defconfig >make u-boot-nand.gph
Quoted 8 lines
board/ti/ks2_evm/README To build u-boot-nand.gph · line 88
Quoted 5 lines
board/ti/ks2_evm/README +5
-0+To build u-boot.uart + >make k2hk_evm_defconfig + >make u-boot.uart + +extra EOL?
Will remove
Quoted 6 lines
Quoted 6 lines
board/ti/ks2_evm/README +6
-0+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
Quoted 8 lines
board/ti/ks2_evm/README To build u-boot-nand.gph · line 98
Quoted 4 lines
board/ti/ks2_evm/README +4
-0+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 portThis 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.
Quoted 20 lines
----
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.
----
Quoted 3 lines
board/ti/ks2_evm/README To build u-boot-nand.gph · line 100
Quoted 2 lines
board/ti/ks2_evm/README +2
-0+ +extra EOL?
Will remove
Quoted 7 lines
Quoted 5 lines
board/ti/ks2_evm/README +0
-0Load and Run U-Boot on keystone EVMs using CCS =========================================
PATCH 1/1 keystone2: add support for UART download
Quoted 12 lines · Vitaly Andrianov
Quoted 9 lines · Nishanth Menon
Quoted 7 lines · Vitaly Andrianov
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
Quoted 8 lines
Quoted 5 lines
please explain MSMC.
Quoted 2 lines
is complete the boot-loader sets the PC to the first MSMC address
0x0c000000. The u-boot.bin is linked to the address0x0c001000.why not just shift u-boot.bin to start of MSMC address?
We already have u-boot linked to the
0x0c001000address. 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.
Quoted 10 lines
Quoted 5 lines
Quoted 3 lines
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.
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Signed-off-by Vitaly Andrianov <[email protected]>Acked-by Murali Karicheri <[email protected]>Tested-by Murali Karicheri <[email protected]>--- Makefile | 6 ++++++ board/ti/ks2_evm/README | 17 +++++++++++++++++ 2 files changed, 23 insertions(+)Makefile +0
-0@@ -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 >> $@
Quoted 8 lines
Quoted 5 lines
Makefile u-boot-nand.gph: u-boot.bin FORCE · line 944
Quoted 2 lines
Makefile +2
-0+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?
Quoted 42 lines
Quoted 17 lines
Quoted 17 lines
Makefile +4
-0+ +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.board/ti/ks2_evm/README +0
-0@@ -81,6 +81,23 @@ To build u-boot-nand.gph >make k2hk_evm_defconfig >make u-boot-nand.gphQuoted 8 lines
board/ti/ks2_evm/README To build u-boot-nand.gph · line 88
Quoted 5 lines
board/ti/ks2_evm/README +5
-0+To build u-boot.uart + >make k2hk_evm_defconfig + >make u-boot.uart + +extra EOL?
Will remove
Quoted 6 lines
Quoted 6 lines
board/ti/ks2_evm/README +6
-0+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.uartQuoted 8 lines
board/ti/ks2_evm/README To build u-boot-nand.gph · line 98
Quoted 4 lines
board/ti/ks2_evm/README +4
-0+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 portThis 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:
Quoted 4 lines
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.
Quoted 34 lines
Quoted 21 lines
----
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.
----Quoted 3 lines
board/ti/ks2_evm/README To build u-boot-nand.gph · line 100
Quoted 2 lines
board/ti/ks2_evm/README +2
-0+ +extra EOL?
Will remove
Quoted 7 lines
Quoted 5 lines
board/ti/ks2_evm/README +0
-0Load and Run U-Boot on keystone EVMs using CCS =========================================
Signature · 2 lines
Regards, Nishanth Menon
PATCH 1/1 keystone2: add support for UART download
In reply to Nishanth MenonNishanth,
Quoted 9 lines · Nishanth Menon
Quoted 7 lines · Vitaly Andrianov
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
Quoted 4 lines
Quoted 3 lines
is complete the boot-loader sets the PC to the first MSMC address
0x0c000000. The u-boot.bin is linked to the address0x0c001000.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.
Quoted 4 lines
Quoted 3 lines
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?
Quoted 86 lines
Quoted 13 lines
Signed-off-by Vitaly Andrianov<[email protected]>Acked-by Murali Karicheri<[email protected]>Tested-by Murali Karicheri<[email protected]>--- Makefile | 6 ++++++ board/ti/ks2_evm/README | 17 +++++++++++++++++ 2 files changed, 23 insertions(+)Makefile +0
-0Makefile u-boot-nand.gph: u-boot.bin FORCE · line 944
Quoted 5 lines
Makefile +2
-0@@ -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?Quoted 12 lines
Makefile +4
-0+ +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.board/ti/ks2_evm/README +0
-0board/ti/ks2_evm/README To build u-boot-nand.gph · line 88
Quoted 8 lines
board/ti/ks2_evm/README +5
-0@@ -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?
board/ti/ks2_evm/README To build u-boot-nand.gph · line 98
Quoted 10 lines
board/ti/ks2_evm/README +10
-0+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 portThis 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.
----board/ti/ks2_evm/README To build u-boot-nand.gph · line 100
Quoted 2 lines
board/ti/ks2_evm/README +2
-0+ +extra EOL?
Quoted 4 lines
board/ti/ks2_evm/README +0
-0Load and Run U-Boot on keystone EVMs using CCS =========================================
Signature · 2 lines
Murali Karicheri Linux Kernel, Texas Instruments
PATCH 1/1 keystone2: add support for UART download
Quoted 8 lines · Murali Karicheri
Quoted 4 lines
Quoted 2 lines
is complete the boot-loader sets the PC to the first MSMC address
0x0c000000. The u-boot.bin is linked to the address0x0c001000.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?
Quoted 4 lines
loads it to start of MSMC and adding 1K of NOP just avoid a jump instruction at
the start of the memory to jump to0xc001000. 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.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
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
PATCH 1/1 keystone2: add support for UART download
Quoted 55 lines · Nishanth Menon
Quoted 8 lines · Murali Karicheri
Quoted 4 lines
Quoted 2 lines
is complete the boot-loader sets the PC to the first MSMC address
0x0c000000. The u-boot.bin is linked to the address0x0c001000.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, RBLSo it GPH header has the load address defined, it does mean that we could infact change the start address to
0xc000000(instead of current0xc001000) and appropriately update the GPH headers to point there? that way we can use0xc000000without padding on UART, as well as use the same in NAND/SPI as well? correct?Quoted 4 lines
loads it to start of MSMC and adding 1K of NOP just avoid a jump instruction at
the start of the memory to jump to0xc001000. 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.Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
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.
Quoted 8 lines
---
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
PATCH 1/1 keystone2: add support for UART download
Quoted 75 lines · Vitaly Andrianov
Quoted 72 lines · Nishanth Menon
Quoted 5 lines · Murali Karicheri
Quoted 5 lines
Quoted 3 lines
is complete the boot-loader sets the PC to the first MSMC address
0x0c000000. The u-boot.bin is linked to the address0x0c001000.Quoted 8 lines
Quoted 1 line
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, RBLSo it GPH header has the load address defined, it does mean that we could infact change the start address to
0xc000000(instead of current0xc001000) and appropriately update the GPH headers to point there? that way we can use0xc000000without padding on UART, as well as use the same in NAND/SPI as well? correct?Quoted 6 lines
loads it to start of MSMC and adding 1K of NOP just avoid a jump instruction
at
the start of the memory to jump to0xc001000. 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.Quoted 11 lines
Quoted 8 lines
Quoted 4 lines
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 reaching0xc001000.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.
[...]
Quoted 3 lines
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?
--
Regards,
Nishanth Menon
PATCH 1/1 keystone2: add support for UART download
Quoted 76 lines · menon.nishanth at gmail.com
Quoted 69 lines · Vitaly Andrianov
Quoted 66 lines · Nishanth Menon
Quoted 5 lines · Murali Karicheri
Quoted 5 lines
Quoted 3 lines
is complete the boot-loader sets the PC to the first MSMC address
0x0c000000. The u-boot.bin is linked to the address0x0c001000.Quoted 8 lines
Quoted 1 line
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, RBLSo it GPH header has the load address defined, it does mean that we could infact change the start address to
0xc000000(instead of current0xc001000) and appropriately update the GPH headers to point there? that way we can use0xc000000without padding on UART, as well as use the same in NAND/SPI as well? correct?Quoted 6 lines
loads it to start of MSMC and adding 1K of NOP just avoid a jump instruction
at
the start of the memory to jump to0xc001000. 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.Quoted 11 lines
Quoted 8 lines
Quoted 4 lines
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 reaching0xc001000.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.Quoted 6 lines
Quoted 6 lines
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.
Quoted 8 lines
[...]
Quoted 3 lines
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?
Signature · 2 lines
Regards, Nishanth Menon
PATCH 1/1 keystone2: add support for UART download
Quoted 83 lines · Nishanth Menon
Quoted 82 lines · menon.nishanth at gmail.com
Quoted 75 lines · Vitaly Andrianov
Quoted 72 lines · Nishanth Menon
Quoted 5 lines · Murali Karicheri
Quoted 5 lines
Quoted 3 lines
is complete the boot-loader sets the PC to the first MSMC address
0x0c000000. The u-boot.bin is linked to the address0x0c001000.Quoted 8 lines
Quoted 1 line
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, RBLSo it GPH header has the load address defined, it does mean that we could infact change the start address to
0xc000000(instead of current0xc001000) and appropriately update the GPH headers to point there? that way we can use0xc000000without padding on UART, as well as use the same in NAND/SPI as well? correct?Quoted 6 lines
loads it to start of MSMC and adding 1K of NOP just avoid a jump instruction
at
the start of the memory to jump to0xc001000. 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.Quoted 11 lines
Quoted 8 lines
Quoted 4 lines
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 reaching0xc001000.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.
[...]
Quoted 3 lines
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.
Quoted 8 lines
Quoted 2 lines
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#l37without 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.