Hi Trevor 2017-02-17 18:57 GMT+08:00 Trevor Woerner <twoer...@gmail.com>: > Hi Eddie, > > On Fri 2017-02-17 @ 04:56:28 PM, Eddie Cai wrote: >> 2017-02-17 11:33 GMT+08:00 Trevor Woerner <twoer...@gmail.com>: >> > 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 ;-)
OK, So We have to set DEFAULTTUNE in conf/local.conf file when we want to get a optimized build. > > 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 yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
