[U-Boot] [PATCH V2 4/4] configs: ti_armv7_keystone2: start using armv7_common

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150717/01a00228/attachment.sig>