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

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

[Eddie Cai]

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

[meta-rockchip][morty][PATHV2 1/6] machine: Use cortexa17hf-neon-vfpv4 as default tune for rk3288.inc

[Eddie Cai]

RK3288 support hard float and vfpv4. So we should use cortexa17hf-neon-vfpv4
as default tune.

Reviewed-by: Romain Perier <romain.perier@collabora.com>
Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
---
 conf/machine/include/rk3288.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
index e6c19a2..6d4affd 100644
--- a/conf/machine/include/rk3288.inc
+++ b/conf/machine/include/rk3288.inc
@@ -3,7 +3,7 @@
 
 require conf/machine/include/tune-cortexa17.inc
 
-DEFAULTTUNE="cortexa17-neon"
+DEFAULTTUNE="cortexa17hf-neon-vfpv4"
 PREFERRED_PROVIDER_virtual/kernel = "linux"
 SERIAL_CONSOLES = "115200;ttyS2"
 KERNEL_IMAGETYPE = "zImage"
-- 
2.7.4

[meta-rockchip][morty][PATHV2 2/6] machine: Use SOC specific assignements

[Eddie Cai]

From: Eddie Cai <eddie.cai@rock-chips.com>

In this way the modifications will be used on all RK3288 boards.

Reviewed-by: Romain Perier <romain.perier@collabora.com>
Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
---
 conf/machine/include/rk3288.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
index 6d4affd..b3726ee 100644
--- a/conf/machine/include/rk3288.inc
+++ b/conf/machine/include/rk3288.inc
@@ -1,7 +1,10 @@
 # Copyright (C) 2015 Romain Perier
 # Released under the MIT license (see COPYING.MIT for the terms)
 
+SOC_FAMILY  = "rk3288"
+
 require conf/machine/include/tune-cortexa17.inc
+require conf/machine/include/soc-family.inc
 
 DEFAULTTUNE="cortexa17hf-neon-vfpv4"
 PREFERRED_PROVIDER_virtual/kernel = "linux"
-- 
2.7.4

[meta-rockchip][morty][PATHV2 3/6] machine: separate rk3188 inc file from rk3066

[Eddie Cai]

Every SoC should have their own inc file. So separate it.

Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
---
 conf/machine/include/rk3188.inc | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/conf/machine/include/rk3188.inc b/conf/machine/include/rk3188.inc
index 428392b..72255a0 100644
--- a/conf/machine/include/rk3188.inc
+++ b/conf/machine/include/rk3188.inc
@@ -1,4 +1,22 @@
 # Copyright (C) 2015 Romain Perier
 # Released under the MIT license (see COPYING.MIT for the terms)
 
-require conf/machine/include/rk3066.inc
+DEFAULTTUNE = "cortexa9-neon"
+require conf/machine/include/tune-cortexa9.inc
+
+PREFERRED_PROVIDER_virtual/xserver = "xserver-xorg"
+
+XSERVER = "xserver-xorg \
+           xf86-video-fbturbo \
+           xf86-input-evdev \
+           xf86-input-mouse \
+           xf86-input-keyboard"
+
+PREFERRED_PROVIDER_virtual/kernel = "linux-rockchip-3.0"
+
+KERNEL_IMAGETYPE = "zImage"
+
+IMAGE_FSTYPES += "ext4"
+
+SERIAL_CONSOLES ?= "115200;ttyFIQ0"
+KBUILD_DEFCONFIG = "multi_v7_defconfig"
-- 
2.7.4

[meta-rockchip][morty][PATHV2 4/6] machine: Use SOC specific assignements

[Eddie Cai]

In this way the modifications will be used on all RK3188 boards.

Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
---
 conf/machine/include/rk3188.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/conf/machine/include/rk3188.inc b/conf/machine/include/rk3188.inc
index 72255a0..6a18a6f 100644
--- a/conf/machine/include/rk3188.inc
+++ b/conf/machine/include/rk3188.inc
@@ -1,9 +1,10 @@
 # Copyright (C) 2015 Romain Perier
 # Released under the MIT license (see COPYING.MIT for the terms)
 
+SOC_FAMILY  = "rk3188"
 DEFAULTTUNE = "cortexa9-neon"
 require conf/machine/include/tune-cortexa9.inc
-
+require conf/machine/include/soc-family.inc
 PREFERRED_PROVIDER_virtual/xserver = "xserver-xorg"
 
 XSERVER = "xserver-xorg \
-- 
2.7.4

[meta-rockchip][morty][PATHV2 5/6] machine: Use SOC specific assignements

[Eddie Cai]

In this way the modifications will be used on all RK3066 boards.

Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
---
 conf/machine/include/rk3066.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/conf/machine/include/rk3066.inc b/conf/machine/include/rk3066.inc
index d43a88c..e454b08 100644
--- a/conf/machine/include/rk3066.inc
+++ b/conf/machine/include/rk3066.inc
@@ -1,9 +1,10 @@
 # Copyright (C) 2014 NEO-Technologies
 # Released under the MIT license (see COPYING.MIT for the terms)
 
+SOC_FAMILY  = "rk3066"
 DEFAULTTUNE = "cortexa9-neon"
 require conf/machine/include/tune-cortexa9.inc
-
+require conf/machine/include/soc-family.inc
 PREFERRED_PROVIDER_virtual/xserver = "xserver-xorg"
 
 XSERVER = "xserver-xorg \
-- 
2.7.4

[meta-rockchip][morty][PATHV2 6/6] recipes-kernel: linux: Add mainline kernel

[Eddie Cai]

Add mainline kervel support. Now the version is 4.10.-rc8.

Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
---
 recipes-kernel/linux/linux_4.10.bb | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 recipes-kernel/linux/linux_4.10.bb

diff --git a/recipes-kernel/linux/linux_4.10.bb b/recipes-kernel/linux/linux_4.10.bb
new file mode 100644
index 0000000..d4cae27
--- /dev/null
+++ b/recipes-kernel/linux/linux_4.10.bb
@@ -0,0 +1,18 @@
+# Copyright (C) 2017 Eddie Cai
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+require recipes-kernel/linux/linux-yocto.inc
+
+SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"
+
+SRCREV = "7089db84e356562f8ba737c29e472cc42d530dbc"
+LINUX_VERSION = "4.10"
+# Override local version in order to use the one generated by linux build system
+# And not "yocto-standard"
+LINUX_VERSION_EXTENSION = ""
+PR = "r1"
+PV = "${LINUX_VERSION}-rc8"
+
+# Include only supported boards for now
+COMPATIBLE_MACHINE = "(rk3066|rk3188|rk3288)"
+deltask kernel_configme
-- 
2.7.4

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

[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).

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

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

[Eddie Cai]

Hi Trevor

2017-02-17 11:33 GMT+08:00 Trevor Woerner <twoerner@gmail.com>:
> 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

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

[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 <twoerner@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 ;-)

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

Re: [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@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@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

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

[Trevor Woerner]

Hi Eddie,

On Sat, Feb 18, 2017 at 8:42 AM, Eddie Cai <eddie.cai.linux@gmail.com> 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 :-)