From mboxrd@z Thu Jan 1 00:00:00 1970 From: Murali Karicheri Date: Fri, 17 Jul 2015 13:45:42 -0400 Subject: [U-Boot] [PATCH V2 4/4] configs: ti_armv7_keystone2: start using armv7_common In-Reply-To: <55A93AA7.3050501@ti.com> References: <1437073738-25289-1-git-send-email-nm@ti.com> <1437073738-25289-5-git-send-email-nm@ti.com> <55A927A3.7080806@ti.com> <55A932EA.3040306@ti.com> <55A93746.70905@ti.com> <55A93AA7.3050501@ti.com> Message-ID: <55A93F46.6060006@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 07/17/2015 01:25 PM, Nishanth Menon wrote: > On 07/17/2015 12:11 PM, Murali Karicheri wrote: >> On 07/17/2015 12:52 PM, Nishanth Menon wrote: >>> On 07/17/2015 11:04 AM, Murali Karicheri wrote: >>>> On 07/16/2015 03:08 PM, Nishanth Menon wrote: >>>>> Try to maintain as much commonality by conditionally including stuff >>>>> in armv7_common as necessary and removing the common defines from >>>>> keystone2 header. >>>>> >>>> Including the common ti_armv7_common.h for keystone also add duplication >>>> of the various addresses >>>> >>>> #define DEFAULT_LINUX_BOOT_ENV \ >>>> "loadaddr=0x82000000\0" \ >>>> "kernel_addr_r=0x82000000\0" \ >>>> "fdtaddr=0x88000000\0" \ >>>> "fdt_addr_r=0x88000000\0" \ >>>> "rdaddr=0x88080000\0" \ >>>> "ramdisk_addr_r=0x88080000\0" \ >>>> "bootm_size=0x10000000\0" >>>> >>>> Some of these are also defined in keystone common file. The env scripts >>>> for keystone to be reworked to use the common variable above. >>>> >>>> Rework the CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS to include common as >>>> well. >>> >>> we need to cleanup all the variables once we get the distro config >> >> What do you mean by distro config? Could you explain? > > include/config_distro* - both will eventually get integrated into > armv7_common.h to benefit all TI SoC platforms. Ok I see. But that doesn't mean we can accept duplicate env variables. Do you see my point? > >> >>> included in anyways... I had decided not to rock the apple cart too much >>> with this patch -> just the basic consolidation with as minimal changes >>> as necessary. inclusion of DEFAULT_LINUX_BOOT_ENV into keystone2.h can >>> be done as a follow on patch. >> >> Probably not this one. User would see both these variables and will >> cause confusion and should be fixed. >> > > they are no variables, they are defines. they will eventually be fixed. The defines finally create env variables on NAND or any other medium :) So my comment stays. > I am leery to make a huge jump on a single series. lets do consolidation > in small baby steps please. > > as I have already shown in my reply - the status quo is being maintained > and we are one step closer to an common framework. Ok. If this happens soon (within a month) I am fine with this. Otherwise, this could go under the radar and cause maintenance issue. > >>> >>>>> >>>>> diff --git a/include/configs/k2e_evm.h b/include/configs/k2e_evm.h >>>>> index ac50a01b2980..f1e650141ae1 100644 >>>>> --- a/include/configs/k2e_evm.h >>>>> +++ b/include/configs/k2e_evm.h >>>>> @@ -15,8 +15,6 @@ >>>>> #define CONFIG_K2E_EVM >>>>> >>>>> /* U-Boot general configuration */ >>>>> -#define CONFIG_SYS_PROMPT "K2E EVM # " >>>> >>>> Why remove this? >>> >>> arm_v7_common defines just "u-boot#" for all SoC and boards. So, we dont >>> need this. >> >> Sorry, this may be needed from the automation perspective. Also for >> backward compatibility for users. Would like to keep for K2. > > This has been beaten to death in the past as well (I think some 3/4 > years ago.. i think it should be in the archives, just too lazy to dig > through multi-year old discussions).. > > I will let Tom comment more here. My understanding is that the > convention followed by all other TI SoCs will imply not having custom > sys_prompt.. > > > That said, custom sys_prompt is NOT a need from automation perspective - > we have all our boards in automation farm for years now with and without > custom boot prompt. board identification can be done in other ways. From a users perspective as well, it is good to know which board I am working with when I work with multiple boards. Not sure what is the argument not to have a board specific prompt at u-boot level. Definitely like to hear from Tom. Murali > > -- Murali Karicheri Linux Kernel, Keystone