From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vitaly Andrianov Date: Tue, 3 Mar 2015 13:29:53 -0500 Subject: [U-Boot] [U-boot][PATCH] keystone2: add support for UART download In-Reply-To: <54F5EEFB.8030602@ti.com> References: <1424110975-1153-1-git-send-email-vitalya@ti.com> <54E24FDB.3070304@ti.com> <54E3C05D.2040908@ti.com> <54E48FC4.9010505@ti.com> <54F5EEFB.8030602@ti.com> Message-ID: <54F5FDA1.4090205@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 03/03/2015 12:27 PM, Nishanth Menon wrote: > On 02/18/2015 09:35 AM, menon.nishanth at gmail.com wrote: >> On Wed, Feb 18, 2015 at 7:12 AM, Vitaly Andrianov wrote: >>> >>> >>> On 02/17/2015 05:47 PM, Nishanth Menon wrote: >>>> >>>> On Tue, Feb 17, 2015 at 4:27 PM, Murali Karicheri >>>> 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? >> > > 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? > 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.