[yocto] [meta-rockchip][morty][PATHV2 0/6] add main line kernel support

[Eddie Cai]

Hi Trevor

2017-02-17 18:57 GMT+08:00 Trevor Woerner <twoerner at 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 <twoerner at 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