>-----Original Message----- >From: Shilimkar, Santosh >Sent: Thursday, May 15, 2014 11:14 AM >To: Dmytriyenko, Denys >Cc: Maupin, Chase; Zhang, Hao; Rini, Tom; [email protected] >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; [email protected] >>>>> 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. -- _______________________________________________ meta-ti mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-ti
