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; [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. > > > > 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 -- _______________________________________________ meta-ti mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-ti
