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

[Maupin, Chase]

>-----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.