Hi
2017-02-09 17:18 GMT+08:00 Jacob Chen <jacob2.c...@rock-chips.com>: > Hi, > > > > Eddie Cai wrote on 2017年02月09日 16:20: >> >> HI >> >> 2017-02-09 14:49 GMT+08:00 Jacob Chen <jacob2.c...@rock-chips.com>: >>> >>> Hi >>> >>> >>> Trevor Woerner wrote on 2017年01月28日 03:41: >>> >>> On Fri, Jan 27, 2017 at 9:37 AM, Romain Perier <romain.per...@gmail.com> >>> wrote: >>> >>> Could you: >>> - Make one patch per new machine file and not one patch for all new added >>> machine >>> >>> Agreed. >>> >>> Are all of these machines actual devices? The evb one doesn't sound real. >>> >>> Are all of these machines released and available for purchase? I've >>> heard of the tinkerboard (although I can't seem to find one I can >>> actually buy) but I haven't heard of the fennec. >>> >>> >>> I think i should only leave tinker board here. >>> We have a lot of boards which are not open to the public, it's not >>> suitable >>> to push them to the community. >>> >>> - Add a clear @DESCRIPTION for each board, see an example here: >>> >>> https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/tree/conf/machine/firefly-rk3288.conf >>> - Write a clear and an understandable commit message for your new patches >>> >>> @Trevor: What do you think about this rk-linux.inc ? I don't like this, >>> either its name and what it contains. >>> >>> First off, I think it's really great to see people contributing to >>> meta-rockchip! :-) >>> >>> This entire set of patches seems to be adding "official" support for >>> the rockchip devices; in other words, these recipes will help you to >>> create builds that use the official rockchip sources. That is great. >>> But I think a good BSP gives a user all the possibilities but then >>> leaves the final decision up to them. >>> >>> >>> : ) That's the reason why we try to push patches to here, we want that >>> "meta-rockchip" can >>> build between vendor old kernel/new kernel/old u-boot/new u-boot and >>> mainline kernel/u-boot >>> well. Community people might help develop mainline things. >>> >>> So I agree with Romain, I think the name could use more work. It would >>> be nice if this set of patches included something in the name that let >>> the user know these build from official sources. Then the user could >>> decide whether they want to use the official rockchip sources, or >>> whether they want to build from upstream. So I'm not opposed to the >>> idea of adding recipes for official sources, I'd like like to see them >>> added in a way that leaves the decision with the user. >>> >>> >>> >>> I added rk-linux.inc because i need a place to set up verndor-BSP default >>> settings. >>> I want that the user can choose various combinations by change the >>> include >>> file in machine file. >>> e.g: >>> rk-linux.inc for linux-rockchip 4.4 + u-boot-rockchip-nex-dev >>> rk-linux.inc + rk-uboot.inc for linux-rockchip + u-boot-rockchip >>> >>> rk-linux.inc for linux-mainline + u-boot-mainline > > I send the wrong draft due to the poor network... Please ignore the e.g... > > What i think it's that the users should always get image with all features > enabled with default settings. > I will be killed if i let them to set each settings one by one in local.conf > to enable features.... > ok to change name and split file, but i think the things it contianed is > needed. > >>> BTW, which name you think is better? >> >> What about follow raspberrypi? >> ├── include >> │ ├── rpi-base.inc >> │ ├── rpi-default-providers.inc >> │ ├── rpi-default-settings.inc >> │ ├── rpi-default-versions.inc >> │ └── tune-arm1176jzf-s.inc >> ├── raspberrypi0.conf >> ├── raspberrypi2.conf >> ├── raspberrypi3.conf >> └── raspberrypi.conf >> > > split rk-linux.inc into > rk-base.inc > rk-vendor-providers.inc > rk-vendor-settings.inc > rk-vendor-versions.inc > rk-community-providers.inc > rk-community-settings.inc > rk-community-versions.inc Why we need a vendor version and a community version? > > ? > > Hmmm, it look more clearly than rk-linux.inc. > > >>> >>> That's it for now. >>> Thanks for your patches >>> >>> +1 :-) >>> >>> >>> >>> -- >>> _______________________________________________ >>> yocto mailing list >>> yocto@yoctoproject.org >>> https://lists.yoctoproject.org/listinfo/yocto >>> > -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
