On Wed, Feb 18, 2015 at 7:12 AM, Vitaly Andrianov <vita...@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-kariche...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
