On Wed, Feb 18, 2015 at 7:12 AM, Vitaly Andrianov vitalya@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@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?
-- Regards, Nishanth Menon