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

[Hao Zhang]

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?