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

[Denys Dmytriyenko]

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.

-- 
Denys