[meta-ti] [PATCH] boot-monitor: add K2L and K2E boot monitor build support

[Denys Dmytriyenko]

On Thu, May 15, 2014 at 12:26:13PM -0400, Hao Zhang wrote:
> On 5/15/2014 12:22 PM, Maupin, Chase wrote:
> >> -----Original Message-----
> >> From: Shilimkar, Santosh
> >> Sent: Thursday, May 15, 2014 11:14 AM
> >> To: Dmytriyenko, Denys
> >> Cc: Maupin, Chase; Zhang, Hao; Rini, Tom; meta-ti at yoctoproject.org
> >> Subject: Re: [meta-ti] [PATCH] boot-monitor: add K2L and K2E boot
> >> monitor build support
> >>
> >> On Thursday 15 May 2014 12:11 PM, Denys Dmytriyenko wrote:
> >>> On Thu, May 15, 2014 at 12:06:15PM -0400, Santosh Shilimkar
> >> wrote:
> >>>> On Thursday 15 May 2014 11:56 AM, Maupin, Chase wrote:
> >>>>>> -----Original Message-----
> >>>>>> From: Shilimkar, Santosh
> >>>>>> Sent: Thursday, May 15, 2014 10:39 AM
> >>>>>> To: Zhang, Hao; Dmytriyenko, Denys
> >>>>>> Cc: Maupin, Chase; Rini, Tom; meta-ti at yoctoproject.org
> >>>>>> Subject: Re: [meta-ti] [PATCH] boot-monitor: add K2L and K2E
> >> boot
> >>>>>> monitor build support
> >>>>>>
> >>>>>> On Thursday 15 May 2014 11:07 AM, Hao Zhang wrote:
> >>>>>>> On 5/15/2014 10:54 AM, Denys Dmytriyenko wrote:
> >>>>>>>> On Thu, May 15, 2014 at 10:41:52AM -0400, Hao Zhang wrote:
> >>>>>>
> >>>>>> [..]
> >>>>>>
> >>>>>>>>>> Can you clarify if you really want all 3 devices
> >> installed
> >>>>>> all the time or
> >>>>>>>>>> do you really want a recipe that installs the boot
> >> monitor
> >>>>>> per device?  I
> >>>>>>>>>> know you don't currently have 3 machine types so maybe
> >> that
> >>>>>> is what is
> >>>>>>>>>> feeding your issue here, but my question is whether you
> >> need
> >>>>>> to have
> >>>>>>>>>> separate builds per device.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I want all the 3 boot monitors built and installed all the
> >>>>>> time in one
> >>>>>>>>> recipe, since MCSDK 3.1 supports all the 3 Keystone II
> >> devices
> >>>>>> in the
> >>>>>>>>> same release package. This applies to the U-boot (3 U-boot
> >>>>>> build for all
> >>>>>>>>> the 3 Keystone II devices) and Linux kernel DTB.
> >>>>>>>>
> >>>>>>>> Linux kernel has support for board variations through DTBs,
> >>>>>> obviously.
> >>>>>>>>
> >>>>>>>> As of U-boot, in Sitara world we had to manage board
> >> variations
> >>>>>> by detecting
> >>>>>>>> the board at runtime. So, the same single binary would work
> >> on
> >>>>>> AM335x-EVM,
> >>>>>>>> AM335x-SK, BeagleBone White and BeagleBone Black.
> >>>>>>>>
> >>>>>>>> I would recommend you working with Tom Rini and doing it
> >>>>>> similarly, so you
> >>>>>>>> don't have to build 3 different binaries for 3 slightly
> >>>>>> different Keystone
> >>>>>>>> baords...
> >>>>>>>>
> >>>>>>>>
> >>>>>> Three boars for same SOC is different than 3 different SOCs
> >> with
> >>>>>> their
> >>>>>> own boards. We need to support different u-boot configs for
> >> that.
> >>>>>> And
> >>>>>> upstream of the patches work is already in progress with Tom
> >>>>>> reviewing
> >>>>>> the patches.
> >>>>>
> >>>>> So which one is it?  Is this a case of three boards for a
> >> single SoC or 3 SoCs with their own boards?
> >>>>>
> >>>> I was just saying you AM example was multiple board for 1 SOC.
> >> What Hao is talking
> >>>> '3 SOCs with their own boards.
> >>>
> >>> If those are 3 different SOCs (not just spins or diff part #s),
> >> then we should
> >>> consider creating 3 different OE machine configs.
> >>>
> >> yes they are 3 different SOCs with different capabilities
> > 
> > Then Denys is right.  We should have 3 different OE machine configs which all share an SOC_FAMILY of "keystone".  That way they can re-use as much as possible, but unique differences such as the bootloader, example apps, etc can be easily handled.
> > 
> 
> Can you show me an example how to do that?

meta-ti layer, conf/machine for machine configs and conf/machine/include for 
SOC configs.

examples would be:

- am335x-evm.conf and beaglebone.conf both use ti33x.inc SOC definition
- dra7xx-evm.conf and omap5-evm.conf both use omap-a15.inc SOC

-- 
Denys