On Fri, Jul 17, 2015 at 01:45:42PM -0400, Murali Karicheri wrote:
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?
Yes. But mainline U-Boot doesn't need to support N versions of Y distros. That's the point behind the generic distro work. And this means that yes, a lot of the addr_X things keystone sets get dropped later on. For better or worse there isn't overlap in names between these two choices so the old scripts will still use the old values and the new scripts the new values.
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.
We can drop a bunch of addr_* stuff if you prefer :)
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.
As Nishanth said, we beat this topic to death a long time back. Generic prompt is what we do.