Hi Eddie, On Fri 2017-02-17 @ 04:56:28 PM, Eddie Cai wrote: > 2017-02-17 11:33 GMT+08:00 Trevor Woerner <[email protected]>: > > You've put "morty" in the subject lines which to me means you're hoping > > these > > patches will be applied against the morty branch of meta-rockchip. Morty was > > released in October of 2016 which, at this point, is almost 5 months ago. At > > this point patches should only go against morty to fix critical issues. > > These > > patches look more like they're adding functionality, so I'll apply them to > > master instead. The next release is Pyro which is expected around April > > 2017. > I will remove branch next time i send patches.
You're welcome to add a branch name to any patch you send :-) But ideally a patch that adds new functionality would be applied to master and a patch that fixes a serious bug, a security issue, or makes a broken build succeed again could be branch-specific. > > On Tue 2017-02-14 @ 01:54:20 PM, Eddie Cai wrote: > >> This patch set add main line kernel support for meta-rockchip > >> > >> Eddie Cai (6): > >> machine: Use cortexa17hf-neon-vfpv4 as default tune for rk3288.inc > > > > As I've mentioned before, Yocto/OE is a _distribution_ builder, not just an > > image builder. As such most people in the community consider DEFAULTTUNES to > > be a DISTRO-level policy. In other words, this is not something that should > > be > > set by the BSP. One distro might want to use softfloat, while another wants > > hard-float. It will be easier for people who make distributions using > > Yocto/OE > > to use this layer when these types of things are not set at this level. > > Users > > are free to use these distributions (by adding their layers) or they can > > set a > > DEFAULTTUNE in their conf/local.conf file. > > > > I'll add a note to the README pointing this out so people can be aware of > > this > > configuration tweak, but I won't take this patch into the BSP. I've been > > able > > to build and run images where the DEFAULTTUNE is not set and they run just > > fine. Another patch (which I'll be happy to create) will need to look for > > this > > tune in recipes that provide things like mali support. > I found there are many meta using hardfloat. see below for example. I wouldn't say there are many, there are some but that doesn't mean they're correct in doing this :-) The Yocto/OE community is very lax; nobody's going to take down a layer that doesn't play nicely with other layers, but that doesn't mean they're correct :-) > So > i think what meta-xxx(could be rockchip, freescale, allwinner etc) > means building optimized distribution for xxx. I disagree (please see my next response) > If people come to > meta-rockchip. They must want to build a image/distribuition run on > rockchip platform. If not, They should go to meta-debian or other > generic meta rather than meta-rockchip. ie. we won't expect a image > built by meta-amd can run on rockchip platform. right? If you wanted to run debian on your rockchip device then you would include meta-debian in your bblayers. But while bitbake is building your debian image for your rockchip device it will need to know what kernel to use, what kernel configuration to use (device tree, .config, etc) and it will need to know what bootloader to use (e.g. maybe u-boot, and if so, which version? and from where do you clone the repository? denx? or vendor-specific github?) Who is going to answer these questions? Who is going to tell bitbake which bootloader to use for your rockchip device? That's what meta-rockchip is for, and that's why people add it to their bblayers. When people add meta-rockchip to their build it's because their build needs to know which kernel and bootloader to use (and various other bits). But the decision whether the user wants to build an image that will run on as many boards as possible, or whether they want a build that will run as fast as possible on only one board is actually a distro-level decision. If you download an x86, 64-bit version of Fedora, openSUSE, or debian to install on your desktop machine, you won't find different installs that are tweaked for i7, Xeon, or AMD processors. You'll find one generic x86-64 download that works on as many desktop computers as possible. But if you want a Linux distribution that is as tweaked out as possible for exactly the processor you're running, you would look at Arch or Gentoo. The distribution decides whether your code is as generic as possible, or tweaked for exactly your hardware. For many years I too believed exactly the same things you're saying, and I too argued exactly the same arguments you're now making. I hope it doesn't take you as long as it took me to realize that a BSP layer is for informing the build where to find board-specific code (such as vendor kernels and bootloaders) and tuning the build is for distro layers to decide ;-) https://github.com/96boards/meta-rpb/blob/master/conf/distro/include/arm-defaults.inc provides an example of the hoops people have to jump through in order to try to create a distro based on BSP layers that set tunes however they wish. Also https://github.com/Angstrom-distribution/meta-angstrom/blob/master/conf/distro/include/arm-defaults.inc > raspberrypi: > http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/conf/machine/raspberrypi2.conf?h=master > freescale: > http://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/conf/machine/include/imx-base.inc > amd: > http://git.yoctoproject.org/cgit/cgit.cgi/meta-amd/tree/meta-amdfalconx86/conf/machine/include/tune-amdfalconx86.inc > allwinner: > https://github.com/linux-sunxi/meta-sunxi/blob/master/conf/machine/orange-pi-one.conf In the case of the meta-sunxi layer, that layer provides 18 machine configuration files. Only two of them have a DEFAULTTUNE. I think it would be easy to argue that these two files are out of place, rather than to try to argue they represent the common way of doing things ;-) If you read through meta-sunxi's README.md file you'll see that it explicitly talks about how by default this layer allows for the most flexible build, but how if the user wants performance instead, they are welcome to add the DEFAULTTUNE to their build's configuration (i.e. local.conf) themselves. It would be easy to create a list of BSP layers that either don't provide a DEFAULTTUNE or, if they do, provide a tune that is not hf but essentially the same tune you would get by just specifying something like cortexa9 (for example). meta-altera: sets a tune in conf/machine/include to nios and talks about setting hf tunes in its README. meta-cubox: set a generic tune and talks about a hf tune in the README. meta-efikamx: no default tune meta-ettus: provides a generic tune and mentions how a user can set more specific tunes in conf/local.conf.sample meta-exynos: no defaulttunes meta-pine64: no defaulttune meta-qcom: no defaulttune meta-udoo: no defaulttune meta-zync: no defaulttune Best regards, Trevor -- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
