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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
