Re: [yocto] [meta-rockchip][morty][PATHV2 0/6] add main line kernel support
Hi Eddie, On Sat, Feb 18, 2017 at 8:42 AM, Eddie Cai wrote: > OK, So We have to set DEFAULTTUNE in conf/local.conf file when we want > to get a optimized build. Absolutely, there's nothing wrong with having that setting :-) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-rockchip][morty][PATHV2 0/6] add main line kernel support
Hi Trevor 2017-02-17 18:57 GMT+08:00 Trevor Woerner : > Hi Eddie, > > On Fri 2017-02-17 @ 04:56:28 PM, Eddie Cai wrote: >> 2017-02-17 11:33 GMT+08:00 Trevor Woerner : >> > 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-spec
Re: [yocto] [meta-rockchip][morty][PATHV2 0/6] add main line kernel support
Hi Eddie, On Fri 2017-02-17 @ 04:56:28 PM, Eddie Cai wrote: > 2017-02-17 11:33 GMT+08:00 Trevor Woerner : > > 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
Re: [yocto] [meta-rockchip][morty][PATHV2 0/6] add main line kernel support
Hi Trevor 2017-02-17 11:33 GMT+08:00 Trevor Woerner : > Hi Eddie (and the rest of the Rockchip team), > > First let me reiterate how happy I am to see that Rockchip is interested in > supporting Yocto/OE builds, this is great! I hope this trend continues. > > Second, thank you so much for your patience while I reviewed these patches. I > don't like my review to be only visual, I want to see the code running on my > device(s), so reviewing is going to take a bit of time. In this case I hadn't > flashed my firefly board in a long time, and the flashing procedure was quite > a bit different now from what I last remember. > > For future reference, these patches have the string "PATH" in the subject line > instead of "PATCH". Also, if you're creating a v2 or a v3 etc please put a > space between "PATCH" and "v2". But I won't ask you for a "PATCH v3", I'll > just fix these things up as I apply the patches (I hope you don't mind). Thanks for reminding and sorry about the typo. > > 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. > > 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. So i think what meta-xxx(could be rockchip, freescale, allwinner etc) means building optimized distribution for xxx. 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? 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 > >> machine: Use SOC specific assignements > > The above patch is fine, but I am going to adjust the synopsis line to include > the machine to which this patch refers. I.e. instead of: > > machine: Use SOC specific assignments > > I'll say: > > rk3288: Use SOC specific assignments > >> machine: separate rk3188 inc file from rk3066 > > The above patch is okay, but I'm going to remove the DEFAULTTUNE line. > >> machine: Use SOC specific assignements > > Adjusted to specify machine (rk3188). > >> machine: Use SOC specific assignements > > Adjusted to specify machine (rk3066). > >> recipes-kernel: linux: Add mainline kernel > > If Romain is happy with this patch I will apply it. > > Best regards, > Trevor -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-rockchip][morty][PATHV2 0/6] add main line kernel support
Hi Eddie (and the rest of the Rockchip team), First let me reiterate how happy I am to see that Rockchip is interested in supporting Yocto/OE builds, this is great! I hope this trend continues. Second, thank you so much for your patience while I reviewed these patches. I don't like my review to be only visual, I want to see the code running on my device(s), so reviewing is going to take a bit of time. In this case I hadn't flashed my firefly board in a long time, and the flashing procedure was quite a bit different now from what I last remember. For future reference, these patches have the string "PATH" in the subject line instead of "PATCH". Also, if you're creating a v2 or a v3 etc please put a space between "PATCH" and "v2". But I won't ask you for a "PATCH v3", I'll just fix these things up as I apply the patches (I hope you don't mind). 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. 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. > machine: Use SOC specific assignements The above patch is fine, but I am going to adjust the synopsis line to include the machine to which this patch refers. I.e. instead of: machine: Use SOC specific assignments I'll say: rk3288: Use SOC specific assignments > machine: separate rk3188 inc file from rk3066 The above patch is okay, but I'm going to remove the DEFAULTTUNE line. > machine: Use SOC specific assignements Adjusted to specify machine (rk3188). > machine: Use SOC specific assignements Adjusted to specify machine (rk3066). > recipes-kernel: linux: Add mainline kernel If Romain is happy with this patch I will apply it. Best regards, Trevor -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-rockchip][morty][PATHV2 0/6] add main line kernel support
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 machine: Use SOC specific assignements machine: separate rk3188 inc file from rk3066 machine: Use SOC specific assignements machine: Use SOC specific assignements recipes-kernel: linux: Add mainline kernel conf/machine/include/rk3066.inc| 3 ++- conf/machine/include/rk3188.inc| 21 - conf/machine/include/rk3288.inc| 5 - recipes-kernel/linux/linux_4.10.bb | 18 ++ 4 files changed, 44 insertions(+), 3 deletions(-) create mode 100644 recipes-kernel/linux/linux_4.10.bb -- 2.7.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
