from:"Mirza Krak"

Re: [yocto] [Chicken and Egg problem] Defining RDEPENDS of the package itself!

2018-07-18 Thread Mirza Krak

On Wed, Jul 18, 2018, 13:38 Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> Hello YOCTO community,
>
> Since I need to build the latest and the greatest Github creations
> from the independent contributors, I decided myself to write few YOCTO
> recipes and to get myself to this (un)pleasant learning path.
>
> I did few examples, simplistic ones, before I took more complex
> recipes to write.
>
> And... I need this one, Cannelloni, one defined here:
> https://github.com/mguentner/cannelloni


Recipe for above can be found here,
https://github.com/GENIVI/genivi-dev-platform/blob/master/meta-genivi-dev/meta-genivi-dev/recipes-extended/cannelloni/cannelloni.bb
.

I know that it builds on rocko at least.

/ Mirza
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] sstate error

2018-07-04 Thread Mirza Krak

Hi.

I ran in to a sstate error. This appeared after a sudden power cut during build.

Something sstate.bbclass should be able to recover from? As it is now
I have to clear out my sstate to be able to build.

This is on rocko branch.

Log posted below.


$ bitbake core-image-minimal
Loading cache: 100%
||
Time: 0:00:00
Loaded 3209 entries from dependency cache.
Parsing recipes: 100%
|##|
Time: 0:00:01
Parsing of 2378 .bb files complete (2377 cached, 1 parsed). 3210
targets, 209 skipped, 3 masked, 0 errors.
ERROR: Execution of event handler 'sstate_eventhandler2' failed
Traceback (most recent call last):
  File 
"/home/mirzak/project/src/var-fslc-yocto/sources/poky/meta/classes/sstate.bbclass",
line 1033, in sstate_eventhandler2(e=):
 for l in lines:
>(stamp, manifest, workdir) = l.split()
 if stamp not in stamps and stamp not in preservestamps:
ValueError: need more than 1 value to unpack

ERROR: Command execution failed: Traceback (most recent call last):
  File 
"/home/mirzak/project/src/var-fslc-yocto/sources/poky/bitbake/lib/bb/command.py",
line 113, in runAsyncCommand
self.cooker.updateCache()
  File 
"/home/mirzak/project/src/var-fslc-yocto/sources/poky/bitbake/lib/bb/cooker.py",
line 1539, in updateCache
bb.event.fire(event, self.databuilder.mcdata[mc])
  File 
"/home/mirzak/project/src/var-fslc-yocto/sources/poky/bitbake/lib/bb/event.py",
line 222, in fire
fire_class_handlers(event, d)
  File 
"/home/mirzak/project/src/var-fslc-yocto/sources/poky/bitbake/lib/bb/event.py",
line 134, in fire_class_handlers
execute_handler(name, handler, event, d)
  File 
"/home/mirzak/project/src/var-fslc-yocto/sources/poky/bitbake/lib/bb/event.py",
line 106, in execute_handler
ret = handler(event)
  File 
"/home/mirzak/project/src/var-fslc-yocto/sources/poky/meta/classes/sstate.bbclass",
line 1033, in sstate_eventhandler2
(stamp, manifest, workdir) = l.split()
ValueError: need more than 1 value to unpack


-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
email: mi...@mkrak.org
web: https://mkrak.org
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] YOCTO kernel PF_CAN feature set and socketCAN layer of the shelf?

2018-06-12 Thread Mirza Krak

On 6 June 2018 at 11:35, Zoran Stojsavljevic
 wrote:
> Hello to YOCTO community,
>
> I am looking into the new CAN FD (CAN Flexible Data rate) protocol. It
> is very similar to classical CAN.
>
> I am wondering the following (I'll ask very basic questions, just to
> see if I am on the right tracks):
> [1] Do YOCTO kernels have CAN drivers left as mandatory drivers in the
> drivers/ tree (CAN drivers exist on kernel.org kernels)?
> [2] If YES, are these drivers enabled by default, or I need to enable
> them? Anybody to quickly refresh me how to manipulate make menuconfig
> in YOCTO tree?

SocketCAN is very hardware specific and you do not mention which
hardware you are using.

>
> I also need the feature called: SocketCAN. The following questions arise:
> [3] Do we have in the socket I/Fs added PF_CAN protocol family handling?
>  https://en.wikipedia.org/wiki/SocketCAN
> [4] Does added SocketCAN layer exist, which covers this topic? It'll
> be layer on the top of the YOCTO-BSP layer, my best guess. Any
> examples, using such a layer? Or any Open Source example(s) of such a
> layer?

I am not aware of any layers and I do not believe that there is any.
SocketCAN is a Linux kernel feature and there are a set of utils to
use SocketCAN [1] and there seems to be a recipe for can-utils in
meta-oe [2] which should be enough to get you started.

[1]. https://github.com/linux-can/can-utils
[2]. http://layers.openembedded.org/layerindex/recipe/24252/

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] TEST_IMAGE issues

2018-05-18 Thread Mirza Krak

Hi all!

Found something interesting (perhaps).

So we where thinking about enabling some of the OE QA tests that that
are part of poky.

Seemed pretty straight forward. Added following to local.conf:

INHERIT += "testimage"

Build my image and then tried to run:

bitbake -c testimage 

To my despair it did not work and instead produced an error. Tried
both on "pyro" and "rocko" branches. The error was:

| runqemu started, pid is 45087
| NOTE: runqemu started, pid is 45087
| waiting at most 60 seconds for qemu pid
| NOTE: waiting at most 60 seconds for qemu pid
| runqemu exited with code 1
| NOTE: runqemu exited with code 1
| Output from runqemu:
| runqemu - ERROR - Unknown path arg
/tmp/deploy/images/qemux86-64/genivi-dev-platform-qemux86-64.ext4
| runqemu - ERROR - Try 'runqemu help' on how to use it

Some (a lot) digging later, I finally figured out that error occurs
because the image name does not contain "-image" or "image-". runqemu
is not able to parse it and throws a "unknown" argument error (not
that obvious from the print).

I realize that this is a "problem" in runqemu and not much to do about
it with a large refactoring job on the runqemu application.

But I am looking for suggesting for an appropriate workaround, other
then renaming the image which I have verified works.

Does it say somewhere in the docs that all image files must contain
"-image" or "image-" in their name? If that is the case it makes sense
to rename it, but trying to avoid that.

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
email: mi...@mkrak.org
web: https://mkrak.org
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Configuration network from qt5

2018-05-17 Thread Mirza Krak

On 17 May 2018 at 14:18, Mauro Ziliani <ma...@faresoftware.it> wrote:
> Hi all.
>
> Which the betst choice to perform the network configuration in Yocto Krogoth
> from a qt5 application?
>
> The configuration should be made without external script, using dbus.

Well you probably need to use a network manager that you can control
trough D-Bus. NetworkManager, ConnMan, systemd-networkd etc.

If you are using ConnMan you can use this:
https://git.merproject.org/mer-core/libconnman-qt

There might exist similar libraries for other network managers but I
am not aware of any.

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
email: mi...@mkrak.org
web: https://mkrak.org
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ROOTFS_RPM_DEBUG undocumented

2018-05-07 Thread Mirza Krak

On 4 May 2018 at 14:41, Alexander Kanavin
<alexander.kana...@linux.intel.com> wrote:
> On 05/04/2018 03:42 PM, Paulo Neves wrote:
>>
>> I will propose a patch with a default bb.debug, and always have the
>> verbose on dnf. Let's see how it affects the performance. I cannot
>> test this in a docker container because of the problems described
>> below:
>>
>> In the mean time I found what was happening with my slow do_rootfs. I
>> was running bitbake with RPM packaging in a docker instance. It seems
>> there is a problem with RPM/dnf in bitbake where it is extremely slow
>> inside a docker container (1 file per second). After changing to IPK
>> packages everything went smoothly.
>>
>> Others have had the same problem[1]. I will later report this to
>> openembedded mailing list as this effectively makes RPM unusable in a
>> container. I will also provide a Dockerfile to reproduce this problem.
>>
>> [1] https://github.com/moby/moby/issues/23137#issuecomment-359097008
>
>
> No need to report. We have already fixed this and reported upstream:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/rpm/files/0001-Revert-Set-FD_CLOEXEC-on-opened-files-before-exec-fr.patch

I have also been bitten by rpm performance issues in docker and glad
that I found this. I am in the process of verifying above (on pyro
branch).

Is this patch on its way to pyro and rocko branches?

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] gcc not found

2018-04-25 Thread Mirza Krak

On 25 April 2018 at 11:00, Burton, Ross <ross.bur...@intel.com> wrote:
> Good work Chen, the trailing slash was making me wonder but I didn't
> check.  Best normalise both of those paths before comparing.

Yeah, I will make that change and we will see in a couple of days if
still produces any errors.

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] gcc not found

2018-04-25 Thread Mirza Krak

On 25 April 2018 at 10:39, Burton, Ross <ross.bur...@intel.com> wrote:
> Is the build tree deleted after it fails?  It would be interesting to
> see if the compiler is present in the sysroot, or if it has a
> different name, or something else weird.

Isn't it weird that it does not have a log for "prepare_recipe_sysroot?

Below log is from when the build actually passed, but still I do not
see the "prepare_recipe_sysroot" log which I can find in other
recipes.

brcm-patchram-plus/0.1-r0/temp$ ls
log.do_compile log.do_populate_lic   run.do_devshell.171
run.do_qa_unpack.22258run.package_fixsymlinks.4292
run.sstate_hardcode_path_unpack.22353
log.do_compile.1451 log.do_populate_lic.22353   run.do_install
run.do_terminal.171run.package_get_auto_pr.4292
run.sstate_hardcode_path_unpack.4151
log.do_compile.22289 log.do_populate_sysroot   run.do_install.4121
run.do_unpackrun.package_name_hook.4292
run.sstate_sign_package.22353
log.do_configure log.do_populate_sysroot.4151   run.do_package
run.do_unpack.22258run.patch_do_patch.22269
run.sstate_sign_package.4151
log.do_configure.22278 log.task_order   run.do_package.4292
run.extend_recipe_sysroot.171run.perform_packagecopy.4292
run.sstate_task_postfunc.22353
log.do_devshell run.base_do_unpack.22258   run.do_patch
run.extend_recipe_sysroot.22269run.populate_lic_qa_checksum.22353
run.sstate_task_postfunc.4151
log.do_devshell.171 run.debian_package_name_hook.4292
run.do_patch.22269 run.extend_recipe_sysroot.4121
run.populate_packages.4292 run.sstate_task_prefunc.22353
log.do_install run.do_compile   run.do_populate_lic
run.extend_recipe_sysroot.4151 run.remove_libtool_la.4121
run.sstate_task_prefunc.4151
log.do_install.4121 run.do_compile.1451   run.do_populate_lic.22353
run.extend_recipe_sysroot.4292 run.split_and_strip_files.4292
run.sstate_task_prefunc.4292
log.do_package run.do_compile.22289   run.do_populate_sysroot
run.fixup_perms.4292run.sstate_create_package.22353
run.sysroot_stage_all.4151
log.do_package.4292 run.do_configure   run.do_populate_sysroot.4151
run.package_do_filedeps.4292run.sstate_create_package.4151
run.sysroot_strip.4151
log.do_patch run.do_configure.22278   run.do_qa_configure.22278
run.package_do_shlibs.4292run.sstate_hardcode_path.22353
run.uninative_changeinterp.22353
log.do_patch.22269 run.do_devshell   run.do_qa_staging.4151
run.package_do_split_locales.4292  run.sstate_hardcode_path.4151
run.uninative_changeinterp.4151

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
email: mi...@mkrak.org
web: https://mkrak.org
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] gcc not found

2018-04-25 Thread Mirza Krak

On 25 April 2018 at 10:39, Burton, Ross <ross.bur...@intel.com> wrote:
> Is the build tree deleted after it fails?  It would be interesting to
> see if the compiler is present in the sysroot, or if it has a
> different name, or something else weird.

I have lost the "state" tinkering around, but before I did that
checked the sysroot and it was:


build/tmp/work/cortexa17hf-neon-vfpv4-esp5-linux-gnueabi/brcm-patchram-plus/0.1-r0/recipe-sysroot-native/usr/bin$
ls
guards quilt

So pretty empty and a lot more is expected to be in there

>
> Do you have any global classes that do anything interesting/special?

I do have some global class but nothing that stands out to me. I do
change the TARGET_VENDOR to a custom name.

My build configuration (masked a bit since this is customer data):

Build Configuration:
BB_VERSION= "1.36.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal"
TARGET_SYS= "arm-custom-linux-gnueabi"
MACHINE   = "custom-d1"
DISTRO= "custom-fb"
DISTRO_VERSION= "2.4"
TUNE_FEATURES = "arm armv7ve vfp neon vfpv4 callconvention-hard cortexa17"
TARGET_FPU= "hard"
meta
meta-poky = "HEAD:f7b90ab3eaf832bd81f3efc1dab4dcf6863ac284"
meta-oe
meta-multimedia
meta-python
meta-networking   = "HEAD:6e3fc5b8d904d06e3aa77e9ec9968ab37a798188"
meta-rockchip = "HEAD:495acdb65d14c2d49f6c2dfce4a673f3af4aa1c7"
meta-qt5  = "HEAD:32bb7d18a08d1c48873d7ab6332d4cc3815a4dff"
meta-mender-core  = "HEAD:cb4feead40e48c4ece1a041c995defecd0e7ee96"

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
email: mi...@mkrak.org
web: https://mkrak.org
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] gcc not found

2018-04-25 Thread Mirza Krak

cm-patchram-plus_0.1.bb

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
email: mi...@mkrak.org
web: http://mkrak.org
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Custom image type and CONVERSION_CMD images softlink problem

2018-04-02 Thread Mirza Krak

On 2 April 2018 at 21:29, Mirza Krak <mi...@mkrak.org> wrote:
> On 29 March 2018 at 11:20, Mirza Krak <mi...@mkrak.org> wrote:
>> Hi.
>>
>> I am working with a project that has a custom image type, "sdimg". The
>> image works fine but it is when I try to apply CONVERSION_CMDs that I
>> see some interesting things.
>>
>> The image output is:
>>
>>  ${IMGDEPLOYDIR}/${IMAGE_NAME}.$suffix
>>
>> There is also a soft-link:
>>
>> ln -sfn "${IMAGE_NAME}.$suffix"
>> "${DEPLOY_DIR_IMAGE}/${IMAGE_BASENAME}-${MACHINE}.$suffix"
>>
>> Now the interesting part comes when I try this:
>>
>>  IMAGE_FSTYPES += "sdimg.gz"
>>
>> This results in a empty gz file, but I already know why and that is
>> because the "normal" image does not contain IMAGE_NAME_SUFFIX in the
>> output name, on which the CONVERSION_CMDs rely on [1].
>>
>> So instead of changing the image name I was hoping that this should
>> work (default is ".rootfs" in image_types.bbclass):
>>
>> IMAGE_NAME_SUFFIX_sdimg = ""

Some addition information.

It seems if I if I do this:

   IMAGE_NAME_SUFFIX_sdimg = ""
   do_image_sdimg[imgsuffix] = ""

Then all steps are completed as expected (gz created and symlink is correct)
-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
email: mi...@mkrak.org
web: http://mkrak.org
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Custom image type and CONVERSION_CMD images softlink problem

2018-04-02 Thread Mirza Krak

On 29 March 2018 at 11:20, Mirza Krak <mi...@mkrak.org> wrote:
> Hi.
>
> I am working with a project that has a custom image type, "sdimg". The
> image works fine but it is when I try to apply CONVERSION_CMDs that I
> see some interesting things.
>
> The image output is:
>
>  ${IMGDEPLOYDIR}/${IMAGE_NAME}.$suffix
>
> There is also a soft-link:
>
> ln -sfn "${IMAGE_NAME}.$suffix"
> "${DEPLOY_DIR_IMAGE}/${IMAGE_BASENAME}-${MACHINE}.$suffix"
>
> Now the interesting part comes when I try this:
>
>  IMAGE_FSTYPES += "sdimg.gz"
>
> This results in a empty gz file, but I already know why and that is
> because the "normal" image does not contain IMAGE_NAME_SUFFIX in the
> output name, on which the CONVERSION_CMDs rely on [1].
>
> So instead of changing the image name I was hoping that this should
> work (default is ".rootfs" in image_types.bbclass):
>
> IMAGE_NAME_SUFFIX_sdimg = ""
>
> But above only partly works. It will generate a proper "gz" version of
> "sdimg" but it fails to create a soft-link, that is
> ${IMAGE_BASENAME}-${MACHINE}.sdimg.gz -> ${IMAGE_NAME}.sdimg.gz. And I
> have traced down on why. It is because image.bbclass still reads
> IMAGE_NAME_SUFFIX as ".rootfs" in create_symlinks[2] even though I
> have set it to something else for my specific image type (override).
>
> I have a couple of workarounds for this already but still wanted to
> report this and see what the community thinks about this. I would
> expect what I am trying to do, to work. That is to set
> IMAGE_NAME_SUFFIX to empty for the custom image.
>
> But you might be of another opinion.
>
> [1]. 
> https://github.com/openembedded/openembedded-core/blob/master/meta/classes/image_types.bbclass#L284
> [2]. 
> https://github.com/openembedded/openembedded-core/blob/master/meta/classes/image.bbclass#L592-L614
>

Re-send, because my initial mail got stuck for moderator approval due
to not being registered on the mailing-list with this email, I am now
and bypassing moderators :).

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
email: mi...@mkrak.org
web: http://mkrak.org
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Custom image type and CONVERSION_CMD images softlink problem

2018-04-01 Thread Mirza Krak

Hi.

I am working with a project that has a custom image type, "sdimg". The
image works fine but it is when I try to apply CONVERSION_CMDs that I
see some interesting things.

The image output is:

 ${IMGDEPLOYDIR}/${IMAGE_NAME}.$suffix

There is also a soft-link:

ln -sfn "${IMAGE_NAME}.$suffix"
"${DEPLOY_DIR_IMAGE}/${IMAGE_BASENAME}-${MACHINE}.$suffix"

Now the interesting part comes when I try this:

 IMAGE_FSTYPES += "sdimg.gz"

This results in a empty gz file, but I already know why and that is
because the "normal" image does not contain IMAGE_NAME_SUFFIX in the
output name, on which the CONVERSION_CMDs rely on [1].

So instead of changing the image name I was hoping that this should
work (default is ".rootfs" in image_types.bbclass):

IMAGE_NAME_SUFFIX_sdimg = ""

But above only partly works. It will generate a proper "gz" version of
"sdimg" but it fails to create a soft-link, that is
${IMAGE_BASENAME}-${MACHINE}.sdimg.gz -> ${IMAGE_NAME}.sdimg.gz. And I
have traced down on why. It is because image.bbclass still reads
IMAGE_NAME_SUFFIX as ".rootfs" in create_symlinks[2] even though I
have set it to something else for my specific image type (override).

I have a couple of workarounds for this already but still wanted to
report this and see what the community thinks about this. I would
expect what I am trying to do, to work. That is to set
IMAGE_NAME_SUFFIX to empty for the custom image.

But you might be of another opinion.

[1]. 
https://github.com/openembedded/openembedded-core/blob/master/meta/classes/image_types.bbclass#L284
[2]. 
https://github.com/openembedded/openembedded-core/blob/master/meta/classes/image.bbclass#L592-L614

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
email: mi...@mkrak.org
web: http://mkrak.org
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] wrong distro name in toolchain

2017-12-19 Thread Mirza Krak

2017-12-19 10:42 GMT+01:00 Marek Słomiany <marekslomi...@gmail.com>:
> About mixing branches - I have recreated the problem on new location to
> check that the problem persist. Here is new setup:
> BB_VERSION   = "1.36.0"
> BUILD_SYS= "x86_64-linux"
> NATIVELSBSTRING  = "universal"
> TARGET_SYS   = "arm-poky-linux-gnueabi"
> MACHINE  = "am335x-evm"
> DISTRO   = "poky"
> DISTRO_VERSION   = "2.4.1"
> TUNE_FEATURES= "arm armv7a vfp thumb neon callconvention-hard"
> TARGET_FPU   = "hard"
> meta = "rocko:abec40e5ebc6f1b804cf698e365737224a57c41d"
> meta-oe  = "rocko:6e3fc5b8d904d06e3aa77e9ec9968ab37a798188"
> meta-et  = "rocko:abec40e5ebc6f1b804cf698e365737224a57c41d"
> meta-ti  = "master:8fcd2f60720acf46555b45a1a48ad1fa0c52b75a"
> meta-qt5 = "rocko:d87335a50a9dd35d890786edbd79b8953fdaa11a"
> meta-poky
> meta-yocto-bsp   = "rocko:abec40e5ebc6f1b804cf698e365737224a57c41d"
>
> meta-poky is in rocko too - I don't know why it didn't show but I have
> double checked it.
> meta-ti does'nt have rocko, so it is in master.
>
> This time, as I am using poky, after deploying and sourcing sdk I had to
> copy ./sysroots/x86_64-pokysdk-linux/ to ./sysroots/x86_64-oesdk-linux/ so
> it's basicly the same and it doesn't make difference if I build it with
> "bitbake  -c populate_sdk" or "bitbake meta-toolchain-qt5" - result
> is the same (not counting that second option doesn't give me additional libs
> from my image).
> Recipe with our own applications has same issue as on my previous setup.
> As I have written - the problem is not in generated sdk that I use for
> out-of-yocto build, but it is when I build my code within yocto with recipe
> and image.
> To answer your question about image - on my setup I have my own image
> recipe, now on this test setup i used core-image-minimal with additional qt
> packages added via local.conf file.
>
> To sum up: There are two problems: first is when using generated sdk - the
> problem is that in sdk subdirectories there is x86_64-pokysdk-linux, but
> cmake is looking for x86_64-oesdk-linux. This can by bypassed copying
> *pokysdk* to *oesdk*.
> second problem is when building from recipe - it looks similar, but I can't
> find proper directories to try out solution which I just described in first
> problem.
>
> I hope it is now clearer what my problem is.

Very much so :).

Can you build other Qt applications without error, e.g "bitbake quitbattery".

If above works then you probably have some hardcoded path in your
cmake files of your custom application.

You could also "hack" the SDK name by adjusting the

 SDK_VENDOR

variable, but I believe that there are some assumptions somewhere that
have a hard-coded name of "oesdk" which is wrong to make such
assumptions.

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to disable a linux virtual terminal...

2017-12-18 Thread Mirza Krak

2017-12-14 22:51 GMT+01:00 Greer, Charles (ext) <charles.gr...@bendix.com>:
> Hi all,
>
>
>
> Would anyone know how to disable the virtual terminals in linux?  I am using
> Yocto, Morty version on an i.MX6 processor.  Even though our base
> distribution is Yocto, unfortunately we have diverged from building it with
> recipes, so this is more of a straight linux question than Yocto…
>
>
>
> To give some detail as to my problem:  It is for an embedded device that has
> an HDMI port - when I attach a terminal to the HDMI port it shows the Linux
> Penguin logo, a getty service and blanks out after 600 seconds.  I just want
> to use the hdmi port as an output with nothing displayed on the output and I
> want it to stay on all the time.
>
>
>
> I have found that the hdmi port maps to /dev/tty1 – when I type:  echo
> “asdfasdf” > /dev/tty1 I see the characters output to the monitor.
>
>
>
> Here are a few things I have tried to no avail – a lot of these are not
> needed if I can figure out how to disable it as a virtual terminal…
>
>
>
> · I figured out how to disable the getty service but a cursor still
> blinks.   I don’t even want a cursor to show

Normally you disable the cursor with a kernel argument:

vt.global_cursor_default=0

You probably also need to remove "console=tty1" from kernel arguments
to avoid to getting "boot prints"

< snip >

> Disabling the logo or console blanking would not be necessary if I could
> just figure out how to disable that port as a terminal…
>
>
>
> So does anyone have pointers or things I could try?  I am relatively new
> (returning after 10 years - I worked with DNX 10 years ago v2.6 and it seems
> everything I knew about init is fairly obsolete lol) to linux so I am sure I
> am missing a lot…

Well it sounds to me that you would like to disable the framebuffer
console completely.

Removing (=n) the

CONFIG_FRAMEBUFFER_CONSOLE

config should definitely get rid of most of the things that you
mentioned. But normally you would not disable it completely if you
would like to display a "boot screen" / splashscreen but if you do not
want it you can safely remove that option.

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] linux kernel rt

2017-12-14 Thread Mirza Krak

2017-12-14 9:41 GMT+01:00 Andreas Müller <schnitzelt...@gmail.com>:
> On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran <sherifomran2...@gmail.com>
> wrote:
>>
>> hey guys,
>>
>> any body tried the real time kernel? I get an error, it is snot in the
>> compatibility list.
>> can we skip it?
>>
>> thanks
>>
>> --
>
> Good news: I use RT kernel only together with VC4 graphics and have lots of
> fun on PI2/3.
> Bad news: As far as I know it is not in meta-raspberrypi but in my fork [1].
> There were attempts to land the RT-patches in meta-raspberrypi but that was
> denied for huge patch size :(

If the patch size was the only problem one can pull it by doing the
following in the recipe:

SRC_URI += " \

https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/patch-4.9.65-rt56.patch.gz;name=rt-patch
\
"

SRC_URI[rt-patch.md5sum] = "9caa7b541d8c84c2d5c5f58985982e95"
SRC_URI[rt-patch.sha256sum] =
"47dfb518c78d8cbaafd4ab9130eb26fe0170be9189b580ab26209ef679309539"

Note that above sums are "random" and not the for the actually file
but are there for reference.

That way you do not need to keep a copy of it in meta-raspberrypi.

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Layer documentation for meta-raspberrypi

2017-12-11 Thread Mirza Krak

2017-12-11 12:55 GMT+01:00 Paul Barker <pbar...@toganlabs.com>:
> Hi all,
>
> As a quick announcement, the layer documentation for meta-raspberrypi
> is now available on Read the Docs:
> http://meta-raspberrypi.readthedocs.io/en/latest/
>
> The latest documentation is shown by default and covers the master
> branch. Using the version box in the bottom right corner of the page
> you can also switch to the rocko or pyro versions. This is
> automatically updated whenever changes are pushed to the documentation
> in meta-raspberrypi.
>
> Raspberry Pi seems to be a very common platform for newcomers to
> OE/Yocto and so I think it's really important that this layer is well
> documented and is easy to use. Please submit pull requests or open
> bugs if you think any of the documentation can be improved.
>
> We use Sphinx (http://www.sphinx-doc.org/) plus Read the Docs
> (https://readthedocs.org/) integration for this which I think is a
> pretty good setup for layer documentation in general. If anyone wants
> more details so they can do something similar for another layer then
> please let me know!

Great work and this will definitely be appreciated by all the
meta-raspberrypi users.

One little thing though, the current "theme" used which I assume is
the default Sphinx theme is not optimal IMO.

readthedocs does apply its own default theme [1] if you do not provide
one in your custom conf which looks much better (that is the look that
docs.readthedocs.io has) which is easier to read and navigate. I
believe that most developers are familiar with it as many other
projects that host documentation on readthedocs use this theme
(including the Linux kernel and more).

[1]. http://docs.readthedocs.io/en/latest/theme.html?highlight=theme

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-rockchip] The various rockchip layers

2017-10-08 Thread Mirza Krak

2017-10-08 5:39 GMT+02:00 Trevor Woerner <twoer...@gmail.com>:
> On Sat, Oct 7, 2017 at 7:03 PM, Mirza Krak <mirza.k...@gmail.com> wrote:

Thank you for taking the time and explaining the current and previous
state. It is highly appreciated.


>> As I started digging to check the current state of the different
>> layers it was quite clear to me that there where two different sets.
>> One is maintained by Rockchip [1] and the other one by the community
>> [2].
>
> Don't forget https://github.com/jackmitch/meta-tinker ;-)

Yeah, noticed that one. Neat little layer that the meta-rockchip
should try and consume :).

>
>> And it made sense to me initially. I do not know the full background
>> story with the Rockchip layers (would be nice if someone could tell it
>> :)) on what the intent was with "community" Rockchip layers.
>
> Romain started meta-rockchip initially, then I joined, then people
> from Rockchip joined later.

Ok, that explains it a bit.

>
>> But as I looked in to it further it was quite clear to me that the
>> Rockchip maintained layers are more "up to date" then the community
>> ones. And then I started thinking on why are not these merged and we
>> could focus effort on maintaining one layer.
>
> The main goal Romain and I have is to have a meta-rockchip that helps
> users run upstream code on their rockchip devices. My guess is that
> the main goal of the Rockchip meta-rockchip is to demonstrate the
> performance of the rockchip SoC (usually via vendor kernels, vendor
> bootloaders, binary blobs, etc.)
>
>> There are a couple things that are interesting:
>>
>> - The Rockchip maintained layers state that they do accept
>> contributions trough pull-requests on github. So nothing stopping us
>> there?
>
> They are quite friendly, but they have their goals.
>
>> - The Rockchip maintained layers supports more "community" boards then
>> the community layers does. Bit odd? :)
>
> The rockchip people are paid to maintain meta-rockchip as part of
> their day-jobs, Romain and I aren't. I buy my own boards, I haven't
> received any hardware support, so my contributions tend to focus on
> boards I actually have. I would rather have support for boards I can
> actually test and therefore actually have rather than guessing whether
> stuff will work. Not to mention I have to find time to work on this
> after other "more important" things are done :-)

That is of course fully understandable.
>
>> - The community layers are a bit outdated on older Yocto branches,
>> master branch seems active though.
>
> Mostly a time issue. I build master with firefly-rk3288 every night
> with all the latest master updates and try to fix any issues that come
> up. I don't have the resources, unfortunately, to keep my finger on
> various past releases.

Also understandable.

>
>> - Trevor and Romain (maintainers of the community layers) are listed
>> as maintainers of the Rockchip layers? [4]
>
> Initially the Rockchip people would send pull requests for the one
> meta-rockchip layer. Many of those pull requests were to add recipes
> pointing to vendor kernels/bootloaders and binary blobs. Also they
> would send patches for boards that (at those times) weren't available
> or sometimes weren't even announced! We pushed back on some of the
> contributions, not just for philosophical reasons but sometimes for
> technical reasons as well. They weren't happy with our slow response
> times and push-back so they just forked and went on their own way.
> When they forked they forgot to change some of the boilerplate stuff
> that should have been changed (such as the maintainers). So yes,
> Romain and I are listed as the maintainers of the Rockchip
> meta-rockchip layer, but we're not :-)

This explains a lot thanks.

> It's on my TODO list to send them some patches for things like that :-)
>
>> What I am really after is better understanding the workflow working
>> with Rockchip SOC`s and Yocto and that is why I am raising questions
>> to do so :).
>>
>> My plan was getting involved in one of the Rockchip layers as I have
>> some improvements and I have some ideas for further improvements. And
>> the goal with this email was to figure out where.
>
> Every once in a while I try to carve out some time to try the Rockchip
> meta-rockchip layer and see how things are going. Maybe it's just a
> coincidence, but often they don't build for me. Looking through their
> instructions they seem to want lots of control over a user's
> setup/configuration (i.e. by using repo to pull specific versions of a
> specific set of layers, then using their own setup

[yocto] [meta-rockchip] The various rockchip layers

2017-10-07 Thread Mirza Krak

Hi all.

I recently started working with Rockchip SoC`s and I currently have a
Tinkerboard and a FireFly-RK3288 board. And as I recently enter the
Yocto Rockchip world I have some comments and questions on the current
setup/workflow which I found a bit confusing when starting out.

As I started digging to check the current state of the different
layers it was quite clear to me that there where two different sets.
One is maintained by Rockchip [1] and the other one by the community
[2].

And it made sense to me initially. I do not know the full background
story with the Rockchip layers (would be nice if someone could tell it
:)) on what the intent was with "community" Rockchip layers.

But as I looked in to it further it was quite clear to me that the
Rockchip maintained layers are more "up to date" then the community
ones. And then I started thinking on why are not these merged and we
could focus effort on maintaining one layer.

There are a couple things that are interesting:

- The Rockchip maintained layers state that they do accept
contributions trough pull-requests on github. So nothing stopping us
there?

- The Rockchip maintained layers supports more "community" boards then
the community layers does. Bit odd? :)

- The community layers are a bit outdated on older Yocto branches,
master branch seems active though.

- Trevor and Romain (maintainers of the community layers) are listed
as maintainers of the Rockchip layers? [4]

What I am really after is better understanding the workflow working
with Rockchip SOC`s and Yocto and that is why I am raising questions
to do so :).

My plan was getting involved in one of the Rockchip layers as I have
some improvements and I have some ideas for further improvements. And
the goal with this email was to figure out where.

[1]. https://github.com/rockchip-linux
[2]. http://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/
[3].
http://freescale.github.io/doc/release-notes/2.2/#the-differences-between-project-name-and-freescale-release-name
[4]. https://github.com/rockchip-linux/meta-rockchip/blob/master/README#L65-L66
--
Best Regards
Mirza
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 1/3] raspberrypi2.conf: Make SERIAL_CONSOLE overwritable

2017-04-21 Thread Mirza Krak

2017-04-21 19:37 GMT+02:00 Paul Barker :
> On Fri, Apr 21, 2017 at 5:03 PM, Andrei Gherzan  wrote:
>> On Thu, Apr 20, 2017 at 06:18:14PM +0100, Andrei Gherzan wrote:
>>> Signed-off-by: Andrei Gherzan 
>>> ---
>>>  conf/machine/raspberrypi2.conf | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/conf/machine/raspberrypi2.conf b/conf/machine/raspberrypi2.conf
>>> index 9b4c02a..a17289c 100644
>>> --- a/conf/machine/raspberrypi2.conf
>>> +++ b/conf/machine/raspberrypi2.conf
>>> @@ -7,7 +7,7 @@ DEFAULTTUNE ?= "cortexa7thf-neon-vfpv4"
>>>  require conf/machine/include/tune-cortexa7.inc
>>>  include conf/machine/include/rpi-base.inc
>>>
>>> -SERIAL_CONSOLE = "115200 ttyAMA0"
>>> +SERIAL_CONSOLE ?= "115200 ttyAMA0"
>>>
>>>  UBOOT_MACHINE = "rpi_2_config"
>>>  VC4_CMA_SIZE ?= "cma-256"
>>> --
>>> 2.12.2
>>>
>>
>> Entire patch set merged to master and morty.
>>
>
> This is the sort of thing I'm not keen on applying to stable branches
> as it may change recipe behaviour. For comparison, the stable branch
> policy for oe-core is very strict
> (https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance#Policies).
>
> In my mind, avoiding potential breakage on a stable branch is more
> important than making improvements. I'm even weary of updating the
> raspberrypi firmware as I don't know how careful they are about
> backwards compatibility. For kernel updates I do have an expectation
> of backwards compatibility and an understanding that new stable
> releases often fix security issues so I'm ok with those on stable
> branches.
>
> For example of where I'm concerned, a "raspberrypi2" override was
> previously applied to both raspberrypi2 and raspberrypi3 machines.
> After the third patch in this series it only applies to the
> raspberrypi2 machine. Also, UBOOT_MACHINE is now set differently for
> raspberrypi3 ('=' vs '?='). These changes may affect the value of some
> variables when building for raspberrypi3 if downstream users haven't
> explicitly handled both raspberrypi2 and raspberrypi3 overrides. I
> don't mind these sorts of changes on the master branch but I worry
> about applying them to a stable branch.
>
> What do other meta-raspberrypi stable branch users think? Should we be
> pedantic here or should we keep things open so that improvements can
> be applied to stable branches?

I would have to agree with Paul here since you asked :).

I would apply a more strict policy working with stable branches, and
be be more in line with the Yocto policy. That is only bug fixes,
security updates and make sure that build is stable on supported
distributions. Everything else can wait until the next "release" and
reside in master.

My 2 cents.

Best Regards
Mirza
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi][PATCH] u-boot: drop backported patches

2017-01-24 Thread Mirza Krak

From: Mirza Krak <mirza.k...@gmail.com>

U-boot has been updated to 2017.01 in poky/oe-core which contains these
patches.

Signed-off-by: Mirza Krak <mirza.k...@gmail.com>
---
 ...0001-arm-add-save_boot_params-for-ARM1176.patch |  56 
 ...through-of-the-firmware-provided-FDT-blob.patch | 156 -
 recipes-bsp/u-boot/u-boot_%.bbappend   |   5 -
 3 files changed, 217 deletions(-)
 delete mode 100644 
recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch
 delete mode 100644 
recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch

diff --git 
a/recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch 
b/recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch
deleted file mode 100644
index a5ebff5..000
--- a/recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch
+++ /dev/null
@@ -1,56 +0,0 @@
-From 3e10fcde3f3c24a488866dd33fa3f5d46ff3d7a3 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?C=C3=A9dric=20Schieli?= <cschi...@gmail.com>
-Date: Fri, 11 Nov 2016 11:59:06 +0100
-Subject: [PATCH] arm: add save_boot_params for ARM1176
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Implement a hook to allow boards to save boot-time CPU state for later
-use. When U-Boot is chain-loaded by another bootloader, CPU registers may
-contain useful information such as system configuration information. This
-feature mirrors the equivalent ARMv7 feature.
-
-Signed-off-by: Cédric Schieli <cschi...@gmail.com>
-Acked-by: Stephen Warren <swar...@nvidia.com>
-Signed-off-by: Paul Barker <p...@paulbarker.me.uk>
-Upstream-status: Backport

- arch/arm/cpu/arm1176/start.S | 10 ++
- 1 file changed, 10 insertions(+)
-
-diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S
-index a602d4e..7c00201 100644
 a/arch/arm/cpu/arm1176/start.S
-+++ b/arch/arm/cpu/arm1176/start.S
-@@ -16,6 +16,7 @@
- 
- #include 
- #include 
-+#include 
- 
- #ifndef CONFIG_SYS_PHY_UBOOT_BASE
- #define CONFIG_SYS_PHY_UBOOT_BASE CONFIG_SYS_UBOOT_BASE
-@@ -37,6 +38,11 @@
-   .globl reset
- 
- reset:
-+  /* Allow the board to save important registers */
-+  b   save_boot_params
-+.globlsave_boot_params_ret
-+save_boot_params_ret:
-+
-   /*
-* set the cpu to SVC32 mode
-*/
-@@ -110,3 +116,7 @@ mmu_disable_phys:
- c_runtime_cpu_setup:
- 
-   mov pc, lr
-+
-+WEAK(save_boot_params)
-+  b   save_boot_params_ret/* back to my caller */
-+ENDPROC(save_boot_params)
--- 
-2.1.4
-
diff --git 
a/recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
 
b/recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
deleted file mode 100644
index 323b7ab..000
--- 
a/recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
+++ /dev/null
@@ -1,156 +0,0 @@
-From ade243a211d62327e9ebadce27bbbff7981e37f0 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?C=C3=A9dric=20Schieli?= <cschi...@gmail.com>
-Date: Fri, 11 Nov 2016 11:59:07 +0100
-Subject: [PATCH] rpi: passthrough of the firmware provided FDT blob
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Raspberry firmware used to pass a FDT blob at a fixed address (0x100),
-but this is not true anymore. The address now depends on both the
-memory size and the blob size [1].
-
-If one wants to passthrough this FDT blob to the kernel, the most
-reliable way is to save its address from the r2/x0 register in the
-U-Boot entry point and expose it in a environment variable for
-further processing.
-
-This patch just does this:
-- save the provided address in the global variable fw_dtb_pointer
-- expose it in ${fdt_addr} if it points to a a valid FDT blob
-
-There are many different ways to use it. One can, for example, use
-the following script which will extract from the tree the command
-line built by the firmware, then hand over the blob to a previously
-loaded kernel:
-
-fdt addr ${fdt_addr}
-fdt get value bootargs /chosen bootargs
-bootz ${kernel_addr_r} - ${fdt_addr}
-
-Alternatively, users relying on sysboot/pxe can simply omit any FDT
-statement in their extlinux.conf file, U-Boot will automagically pick
-${fdt_addr} and pass it to the kernel.
-
-[1] https://www.raspberrypi.org/forums//viewtopic.php?f=107=134018
-
-Upstream-Status: Backport
-
-Signed-off-by: Cédric Schieli <cschi...@gmail.com>
-Acked-by: Stephen Warren <swar...@nvidia.com>
-Signed-off-by: Jonathan Liu <net...@gmail.com>

- board/raspberrypi/rpi/Makefile|  1 +
- board/raspberrypi/rpi/lowlevel_init.S | 36 +++
- board/raspberrypi/rpi/rpi.c   | 29 
- 3 files changed, 66 insertions(+)
- create mode 100644 board/raspberrypi/rpi/lowlevel_i

[yocto] [meta-raspberrypi][morty][PATCH V2] Revert "u-boot: drop patch to include lowlevel_init"

2017-01-24 Thread Mirza Krak

From: Mirza Krak <mirza.k...@gmail.com>

Not applicable on U-boot 2016.03 which is used in poky/morty and causes an build
error when KERNEL_IMAGETYPE = "uImage".

This reverts commit 031e26954b95d49a66ea4677b9e867d08441f450.

[Issue #43]

Signed-off-by: Mirza Krak <mirza.k...@gmail.com>
---

Changes in V2:
- Fixed spelling and improved commit message

 .../0003-Include-lowlevel_init.o-for-rpi2.patch| 25 ++
 recipes-bsp/u-boot/u-boot_%.bbappend   |  1 +
 2 files changed, 26 insertions(+)
 create mode 100644 
recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch

diff --git 
a/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch 
b/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
new file mode 100644
index 000..ce0273f
--- /dev/null
+++ b/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
@@ -0,0 +1,25 @@
+From 1eb01436bc57ad32519a4567a1c9ec82d52d60a1 Mon Sep 17 00:00:00 2001
+From: Paul Barker <p...@paulbarker.me.uk>
+Date: Tue, 29 Nov 2016 19:47:49 +
+Subject: [PATCH] Include lowlevel_init.o for rpi2
+
+Signed-off-by: Paul Barker <p...@paulbarker.me.uk>
+Upstream-status: Inappropriate
+(not needed upstream as rpi_2 board directory is removed in latest
+version)
+---
+ board/raspberrypi/rpi_2/Makefile | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/board/raspberrypi/rpi_2/Makefile 
b/board/raspberrypi/rpi_2/Makefile
+index d82cd21..9f865c5 100644
+--- a/board/raspberrypi/rpi_2/Makefile
 b/board/raspberrypi/rpi_2/Makefile
+@@ -5,3 +5,4 @@
+ #
+
+ obj-y := ../rpi/rpi.o
++obj-y += ../rpi/lowlevel_init.o
+--
+2.1.4
+
diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend 
b/recipes-bsp/u-boot/u-boot_%.bbappend
index 0edc8dc..a4545f0 100644
--- a/recipes-bsp/u-boot/u-boot_%.bbappend
+++ b/recipes-bsp/u-boot/u-boot_%.bbappend
@@ -3,4 +3,5 @@ RDEPENDS_${PN}_append_rpi = " rpi-u-boot-scr"
 SRC_URI_append_rpi = " \
 file://0001-arm-add-save_boot_params-for-ARM1176.patch \
 file://0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch \
+file://0003-Include-lowlevel_init.o-for-rpi2.patch \
 "
--
2.1.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi][morty][PATCH] Revert "u-boot: drop patch to include lowlevel_init"

2017-01-24 Thread Mirza Krak

From: Mirza Krak <mirza.k...@gmail.com>

Not applicaple on U-boot 2016.03 which is used in poky/morty.

This reverts commit 031e26954b95d49a66ea4677b9e867d08441f450.

[Issue #43]

Signed-off-by: Mirza Krak <mirza.k...@gmail.com>
---
 .../0003-Include-lowlevel_init.o-for-rpi2.patch| 25 ++
 recipes-bsp/u-boot/u-boot_%.bbappend   |  1 +
 2 files changed, 26 insertions(+)
 create mode 100644 
recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch

diff --git 
a/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch 
b/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
new file mode 100644
index 000..ce0273f
--- /dev/null
+++ b/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
@@ -0,0 +1,25 @@
+From 1eb01436bc57ad32519a4567a1c9ec82d52d60a1 Mon Sep 17 00:00:00 2001
+From: Paul Barker <p...@paulbarker.me.uk>
+Date: Tue, 29 Nov 2016 19:47:49 +
+Subject: [PATCH] Include lowlevel_init.o for rpi2
+
+Signed-off-by: Paul Barker <p...@paulbarker.me.uk>
+Upstream-status: Inappropriate
+(not needed upstream as rpi_2 board directory is removed in latest
+version)
+---
+ board/raspberrypi/rpi_2/Makefile | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/board/raspberrypi/rpi_2/Makefile 
b/board/raspberrypi/rpi_2/Makefile
+index d82cd21..9f865c5 100644
+--- a/board/raspberrypi/rpi_2/Makefile
 b/board/raspberrypi/rpi_2/Makefile
+@@ -5,3 +5,4 @@
+ #
+ 
+ obj-y := ../rpi/rpi.o
++obj-y += ../rpi/lowlevel_init.o
+-- 
+2.1.4
+
diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend 
b/recipes-bsp/u-boot/u-boot_%.bbappend
index 0edc8dc..a4545f0 100644
--- a/recipes-bsp/u-boot/u-boot_%.bbappend
+++ b/recipes-bsp/u-boot/u-boot_%.bbappend
@@ -3,4 +3,5 @@ RDEPENDS_${PN}_append_rpi = " rpi-u-boot-scr"
 SRC_URI_append_rpi = " \
 file://0001-arm-add-save_boot_params-for-ARM1176.patch \
 file://0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch \
+file://0003-Include-lowlevel_init.o-for-rpi2.patch \
 "
-- 
2.1.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] setting up autobuilder on local machine

2016-12-19 Thread Mirza Krak

2016-12-19 16:48 GMT+01:00 Bryan Evenson <beven...@melinkcorp.com>:
> Mirza,
>
>> -Original Message-
>> From: yocto-boun...@yoctoproject.org [mailto:yocto-
>> boun...@yoctoproject.org] On Behalf Of Mirza Krak
>> Sent: Monday, December 19, 2016 8:28 AM
>> To: Bill Randle <bill.ran...@gmail.com>
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] setting up autobuilder on local machine
>>
>> 2016-12-19 7:46 GMT+01:00 Mirza Krak <mirza.k...@gmail.com>:
>> > 2016-12-19 4:33 GMT+01:00 Bill Randle <bill.ran...@gmail.com>:
>> >> On Sun, Dec 18, 2016 at 8:25 AM, Paul Barker <p...@paulbarker.me.uk>
>> wrote:
>> >>> On Sun, 18 Dec 2016 15:46:19 +0100
>> >>> Mirza Krak <mirza.k...@gmail.com> wrote:
>> >>>
>> >>>> Hi.
>> >>>>
>> >>>> I have been looking in to the possibility to utilize yocto autobuilder
>> >>>> for one of my own projects.
>> >>>>
>> >>>> But I am having some problems setting this up and hopefully someone
>> >>>> here can provide some pointers.
>> >>>>
>> >>>> I did the "quickstart part":
>> >>>>
>> >>>> git clone git://git.yoctoproject.org/yocto-autobuilder
>> >>>> cd yocto-autobuilder
>> >>>> . ./yocto-autobuilder-setup
>> >>>> yocto-start-autobuilder both
>> >>>>
>> >>>> Above succeeds without any issues. But now what? :)
>> >>>>
>> >>>> I went to https://localhost:8010. I tried to login using the
>> >>>> information that is in the .htpasswd file but that did not work. Where
>> >>>> are the credentials to login setup?
>> >>>
>> >>> You'll need to create the .htpasswd file yourself. I think the
>> >>> "htpasswd" tool can do this for you, I can't remember the exact
>> >>> commands I used to make mine though sorry.
>> >>>
>> >>>>
>> >>>> I also made an attempt to remove all un-wanted buildsets and now
>> >>>> buildset-config contains (all other directories are removed)
>> >>>>
>> >>>> nightly-mender-rpi.conf  yoctoAB.conf
>> >>>>
>> >>>> Above is parsed correctly on start-up but build is never triggered. I
>> >>>> probably removed to much :). Looking in to nigthly.conf it seem that
>> >>>> is the one that trigger all other nightly builds?
>> >>>>
>> >>>> My fork can be found at [1].
>> >>>>
>> >>>> [1]. https://github.com/mirzak/yocto-autobuilder-mender-rpi
>> >>>
>> >>> This looks good, you just need to setup the scheduler with something
>> >>> like this in nightly-mender-rpi.conf:
>> >>>
>> >>> scheduler:
>> >>> [{'nightly-build':{'type':'Nightly','hour':23,'minute':0}}]
>> >>>
>> >>> You should only need a separate nightly.conf when you want that to
>> >>> trigger multiple builds.
>> >>>
>> >>> I've recently setup an autobuilder for meta-raspberrypi which I'll be
>> >>> publishing once I've got the last bits of setup done. If you're still
>> >>> struggling to get the nightly triggering working let me know and I'll
>> >>> put up the configurations I've used as a git repository.
>> >>
>> >> There is also additional helpful information on the Yocto Autobuilder
>> >> wiki page here:
>> >> https://wiki.yoctoproject.org/wiki/The_Yocto_Autobuilder. Some of the
>> >> information applies to the Yocto Project build cluster, but is still
>> >> applicable to local autobuilders. I followed the same instructions to
>> >> setup a local AB. Be sure to use the htpasswd command that's in the
>> >> autobuilder git tree (in one of the bin directories, as I recall),
>> >> rather than a native system one. The AB version defaults to the
>> >> shorter crypto scheme that buildbot requires.
>> >
>> > Thank you for your fast responses. Generating the htpasswd file my
>> > self did the trick. Now I can login. The full command was (as you
>> > suggested I used the one in autobuilder git repo under ./bin):
>> >
>> > ./htpasswd -b -c   > password>
>> >
>> > F

Re: [yocto] setting up autobuilder on local machine

2016-12-19 Thread Mirza Krak

2016-12-19 15:57 GMT+01:00 Jussi Kukkonen <jussi.kukko...@intel.com>:
> On 19 December 2016 at 15:28, Mirza Krak <mirza.k...@gmail.com> wrote:
>>
>> > Thank you for your fast responses. Generating the htpasswd file my
>> > self did the trick. Now I can login. The full command was (as you
>> > suggested I used the one in autobuilder git repo under ./bin):
>> >
>> > ./htpasswd -b -c   > > password>
>> >
>> > Forced a build of my configuration now and hoping for the best :).
>>
>> And it was not green all the way.
>>
>> I get an error that I do not get how to get around. The error message is:
>>
>> ERROR: Unable to parse
>>
>> /home/mirzak/project/yocto-autobuilder/yocto-autobuilder-mender-rpi/yocto-worker/nightly-mender-rpi/build/meta-mender/conf/layer.conf:
>> [Errno 2] file
>> /home/mirzak/project/yocto-autobuilder/yocto-autobuilder-mender-rpi/yocto-worker/nightly-mender-rpi/build/meta-mender/conf/layer.conf
>> not found
>>
>> The error message I understand. But I do not understand why it adds
>> meta-mender to bblayers files. I did not tell it to do that, because
>> meta-mender contains layers that I want to include. Similar to
>> meta-openembedded (which is also added to bblayers).
>>
>
> I'm not an expert but your nightly-mender-rpi.conf contains this:
> 'layerdirs': ['meta-yocto', 'meta-raspberrypi',
> 'meta-mender/meta-mender-core', 'meta-mender/meta-mender-raspberrypi',
> 'oe-meta-go', 'meta-openembedded/meta-oe']

That is correct. I add following:

   meta-mender/meta-mender-raspberrypi
   meta-mender/meta-mender-core

And they are added to the bblayers.conf correctly.

But I do not add "meta-mender" which is present in my bblayers.conf
and is the cause of my error message. It seems to me like it is picked
up from the "repos" section and hence the "magic" :)

Best Regards
Mirza
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] setting up autobuilder on local machine

2016-12-19 Thread Mirza Krak

2016-12-19 7:46 GMT+01:00 Mirza Krak <mirza.k...@gmail.com>:
> 2016-12-19 4:33 GMT+01:00 Bill Randle <bill.ran...@gmail.com>:
>> On Sun, Dec 18, 2016 at 8:25 AM, Paul Barker <p...@paulbarker.me.uk> wrote:
>>> On Sun, 18 Dec 2016 15:46:19 +0100
>>> Mirza Krak <mirza.k...@gmail.com> wrote:
>>>
>>>> Hi.
>>>>
>>>> I have been looking in to the possibility to utilize yocto autobuilder
>>>> for one of my own projects.
>>>>
>>>> But I am having some problems setting this up and hopefully someone
>>>> here can provide some pointers.
>>>>
>>>> I did the "quickstart part":
>>>>
>>>> git clone git://git.yoctoproject.org/yocto-autobuilder
>>>> cd yocto-autobuilder
>>>> . ./yocto-autobuilder-setup
>>>> yocto-start-autobuilder both
>>>>
>>>> Above succeeds without any issues. But now what? :)
>>>>
>>>> I went to https://localhost:8010. I tried to login using the
>>>> information that is in the .htpasswd file but that did not work. Where
>>>> are the credentials to login setup?
>>>
>>> You'll need to create the .htpasswd file yourself. I think the
>>> "htpasswd" tool can do this for you, I can't remember the exact
>>> commands I used to make mine though sorry.
>>>
>>>>
>>>> I also made an attempt to remove all un-wanted buildsets and now
>>>> buildset-config contains (all other directories are removed)
>>>>
>>>> nightly-mender-rpi.conf  yoctoAB.conf
>>>>
>>>> Above is parsed correctly on start-up but build is never triggered. I
>>>> probably removed to much :). Looking in to nigthly.conf it seem that
>>>> is the one that trigger all other nightly builds?
>>>>
>>>> My fork can be found at [1].
>>>>
>>>> [1]. https://github.com/mirzak/yocto-autobuilder-mender-rpi
>>>
>>> This looks good, you just need to setup the scheduler with something
>>> like this in nightly-mender-rpi.conf:
>>>
>>> scheduler:
>>> [{'nightly-build':{'type':'Nightly','hour':23,'minute':0}}]
>>>
>>> You should only need a separate nightly.conf when you want that to
>>> trigger multiple builds.
>>>
>>> I've recently setup an autobuilder for meta-raspberrypi which I'll be
>>> publishing once I've got the last bits of setup done. If you're still
>>> struggling to get the nightly triggering working let me know and I'll
>>> put up the configurations I've used as a git repository.
>>
>> There is also additional helpful information on the Yocto Autobuilder
>> wiki page here:
>> https://wiki.yoctoproject.org/wiki/The_Yocto_Autobuilder. Some of the
>> information applies to the Yocto Project build cluster, but is still
>> applicable to local autobuilders. I followed the same instructions to
>> setup a local AB. Be sure to use the htpasswd command that's in the
>> autobuilder git tree (in one of the bin directories, as I recall),
>> rather than a native system one. The AB version defaults to the
>> shorter crypto scheme that buildbot requires.
>
> Thank you for your fast responses. Generating the htpasswd file my
> self did the trick. Now I can login. The full command was (as you
> suggested I used the one in autobuilder git repo under ./bin):
>
> ./htpasswd -b -c   
>
> Forced a build of my configuration now and hoping for the best :).

And it was not green all the way.

I get an error that I do not get how to get around. The error message is:

ERROR: Unable to parse
/home/mirzak/project/yocto-autobuilder/yocto-autobuilder-mender-rpi/yocto-worker/nightly-mender-rpi/build/meta-mender/conf/layer.conf:
[Errno 2] file 
/home/mirzak/project/yocto-autobuilder/yocto-autobuilder-mender-rpi/yocto-worker/nightly-mender-rpi/build/meta-mender/conf/layer.conf
not found

The error message I understand. But I do not understand why it adds
meta-mender to bblayers files. I did not tell it to do that, because
meta-mender contains layers that I want to include. Similar to
meta-openembedded (which is also added to bblayers).

Here is the bblayers.conf also for reference:
mirzak@debian:~/project/yocto-autobuilder/yocto-autobuilder-mender-rpi/yocto-worker/nightly-mender-rpi/build/build/conf$
cat bblayers.conf
POKY_BBLAYERS_CONF_VERSION =  "2"
BBPATH = "${TOPDIR}"
BBFILES ?=""
BBLAYERS += " \
/home/mirzak/project/yocto-autobuilder/yocto-autobuilder-mender-rpi/yocto-worker/nightly-mender-rpi/build/meta
\
/home/mir

Re: [yocto] setting up autobuilder on local machine

2016-12-18 Thread Mirza Krak

2016-12-19 4:33 GMT+01:00 Bill Randle <bill.ran...@gmail.com>:
> On Sun, Dec 18, 2016 at 8:25 AM, Paul Barker <p...@paulbarker.me.uk> wrote:
>> On Sun, 18 Dec 2016 15:46:19 +0100
>> Mirza Krak <mirza.k...@gmail.com> wrote:
>>
>>> Hi.
>>>
>>> I have been looking in to the possibility to utilize yocto autobuilder
>>> for one of my own projects.
>>>
>>> But I am having some problems setting this up and hopefully someone
>>> here can provide some pointers.
>>>
>>> I did the "quickstart part":
>>>
>>> git clone git://git.yoctoproject.org/yocto-autobuilder
>>> cd yocto-autobuilder
>>> . ./yocto-autobuilder-setup
>>> yocto-start-autobuilder both
>>>
>>> Above succeeds without any issues. But now what? :)
>>>
>>> I went to https://localhost:8010. I tried to login using the
>>> information that is in the .htpasswd file but that did not work. Where
>>> are the credentials to login setup?
>>
>> You'll need to create the .htpasswd file yourself. I think the
>> "htpasswd" tool can do this for you, I can't remember the exact
>> commands I used to make mine though sorry.
>>
>>>
>>> I also made an attempt to remove all un-wanted buildsets and now
>>> buildset-config contains (all other directories are removed)
>>>
>>> nightly-mender-rpi.conf  yoctoAB.conf
>>>
>>> Above is parsed correctly on start-up but build is never triggered. I
>>> probably removed to much :). Looking in to nigthly.conf it seem that
>>> is the one that trigger all other nightly builds?
>>>
>>> My fork can be found at [1].
>>>
>>> [1]. https://github.com/mirzak/yocto-autobuilder-mender-rpi
>>
>> This looks good, you just need to setup the scheduler with something
>> like this in nightly-mender-rpi.conf:
>>
>> scheduler:
>> [{'nightly-build':{'type':'Nightly','hour':23,'minute':0}}]
>>
>> You should only need a separate nightly.conf when you want that to
>> trigger multiple builds.
>>
>> I've recently setup an autobuilder for meta-raspberrypi which I'll be
>> publishing once I've got the last bits of setup done. If you're still
>> struggling to get the nightly triggering working let me know and I'll
>> put up the configurations I've used as a git repository.
>
> There is also additional helpful information on the Yocto Autobuilder
> wiki page here:
> https://wiki.yoctoproject.org/wiki/The_Yocto_Autobuilder. Some of the
> information applies to the Yocto Project build cluster, but is still
> applicable to local autobuilders. I followed the same instructions to
> setup a local AB. Be sure to use the htpasswd command that's in the
> autobuilder git tree (in one of the bin directories, as I recall),
> rather than a native system one. The AB version defaults to the
> shorter crypto scheme that buildbot requires.

Thank you for your fast responses. Generating the htpasswd file my
self did the trick. Now I can login. The full command was (as you
suggested I used the one in autobuilder git repo under ./bin):

./htpasswd -b -c   

Forced a build of my configuration now and hoping for the best :).

Best Regards
Mirza
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] setting up autobuilder on local machine

2016-12-18 Thread Mirza Krak

Hi.

I have been looking in to the possibility to utilize yocto autobuilder
for one of my own projects.

But I am having some problems setting this up and hopefully someone
here can provide some pointers.

I did the "quickstart part":

git clone git://git.yoctoproject.org/yocto-autobuilder
cd yocto-autobuilder
. ./yocto-autobuilder-setup
yocto-start-autobuilder both

Above succeeds without any issues. But now what? :)

I went to https://localhost:8010. I tried to login using the
information that is in the .htpasswd file but that did not work. Where
are the credentials to login setup?

I also made an attempt to remove all un-wanted buildsets and now
buildset-config contains (all other directories are removed)

nightly-mender-rpi.conf  yoctoAB.conf

Above is parsed correctly on start-up but build is never triggered. I
probably removed to much :). Looking in to nigthly.conf it seem that
is the one that trigger all other nightly builds?

My fork can be found at [1].

[1]. https://github.com/mirzak/yocto-autobuilder-mender-rpi

Best Regards
Mirza
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] u-boot: drop patch to include lowlevel_init

2016-12-09 Thread Mirza Krak

2016-12-09 10:05 GMT+01:00 Paul Barker <p...@paulbarker.me.uk>:
> On Thu,  8 Dec 2016 23:00:19 +0100
> Mirza Krak <mirza.k...@gmail.com> wrote:
>
>> From: Mirza Krak <mirza.k...@gmail.com>
>>
>> U-boot has been updated to 2016.11 in OE-core Which means that we can
>> use the upstream patches instead of the backports and no need for the third
>> patch which causes a build error when used with 2016.11.
>>
>> Signed-off-by: Mirza Krak <mirza.k...@gmail.com>
>> ---
>>  ...0001-arm-add-save_boot_params-for-ARM1176.patch |  4 +---
>>  ...through-of-the-firmware-provided-FDT-blob.patch |  7 ++
>>  .../0003-Include-lowlevel_init.o-for-rpi2.patch| 25 
>> --
>>  recipes-bsp/u-boot/u-boot_%.bbappend   |  1 -
>>  4 files changed, 3 insertions(+), 34 deletions(-)
>>  delete mode 100644 
>> recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
>>
>> diff --git 
>> a/recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch 
>> b/recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch
>> index a5ebff5..97a4144 100644
>> --- 
>> a/recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch
>> +++ 
>> b/recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch
>> @@ -1,7 +1,7 @@
>>  From 3e10fcde3f3c24a488866dd33fa3f5d46ff3d7a3 Mon Sep 17 00:00:00 2001
>>  From: =?UTF-8?q?C=C3=A9dric=20Schieli?= <cschi...@gmail.com>
>>  Date: Fri, 11 Nov 2016 11:59:06 +0100
>> -Subject: [PATCH] arm: add save_boot_params for ARM1176
>> +Subject: [PATCH 1/1] arm: add save_boot_params for ARM1176
>>  MIME-Version: 1.0
>>  Content-Type: text/plain; charset=UTF-8
>>  Content-Transfer-Encoding: 8bit
>> @@ -13,8 +13,6 @@ feature mirrors the equivalent ARMv7 feature.
>>
>>  Signed-off-by: Cédric Schieli <cschi...@gmail.com>
>>  Acked-by: Stephen Warren <swar...@nvidia.com>
>> -Signed-off-by: Paul Barker <p...@paulbarker.me.uk>
>> -Upstream-status: Backport
>>  ---
>>   arch/arm/cpu/arm1176/start.S | 10 ++
>>   1 file changed, 10 insertions(+)
>> diff --git 
>> a/recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
>>  
>> b/recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
>> index 323b7ab..95ad94c 100644
>> --- 
>> a/recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
>> +++ 
>> b/recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
>> @@ -1,7 +1,7 @@
>>  From ade243a211d62327e9ebadce27bbbff7981e37f0 Mon Sep 17 00:00:00 2001
>>  From: =?UTF-8?q?C=C3=A9dric=20Schieli?= <cschi...@gmail.com>
>>  Date: Fri, 11 Nov 2016 11:59:07 +0100
>> -Subject: [PATCH] rpi: passthrough of the firmware provided FDT blob
>> +Subject: [PATCH 1/1] rpi: passthrough of the firmware provided FDT blob
>>  MIME-Version: 1.0
>>  Content-Type: text/plain; charset=UTF-8
>>  Content-Transfer-Encoding: 8bit
>> @@ -34,11 +34,8 @@ ${fdt_addr} and pass it to the kernel.
>>
>>  [1] https://www.raspberrypi.org/forums//viewtopic.php?f=107=134018
>>
>> -Upstream-Status: Backport
>> -
>>  Signed-off-by: Cédric Schieli <cschi...@gmail.com>
>>  Acked-by: Stephen Warren <swar...@nvidia.com>
>> -Signed-off-by: Jonathan Liu <net...@gmail.com>
>>  ---
>>   board/raspberrypi/rpi/Makefile|  1 +
>>   board/raspberrypi/rpi/lowlevel_init.S | 36 
>> +++
>> @@ -152,5 +149,5 @@ index 6245b36..ffd6d31 100644
>>   set_usbethaddr();
>>   #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
>>  --
>> -2.10.2
>> +2.1.4
>>
>
> A 'backport' means the patch was already applied upstream, it's a
> 'backport' whether we need to change the patch or not. We also like to
> have the sign-off from whoever brought the patch into the metadata
> layer.
>
> See the following link for more details:
> http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations

Understood.

>
>> diff --git 
>> a/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch 
>> b/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
>> deleted file mode 100644
>> index ce0273f..000
>> --- a/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
>> +++ /dev/null
>> @@ -1,25 +0,0 @@
>> -From 1eb01436bc57ad32519a4567a1c9ec82d52d60a1 Mon Sep

[yocto] [meta-raspberrypi][PATCH V2] u-boot: drop patch to include lowlevel_init

2016-12-09 Thread Mirza Krak

From: Mirza Krak <mirza.k...@gmail.com>

The patch 0003-Include-lowlevel_init.o-for-rpi2.patch does not apply on
2016.11 and causes an build error.

Patch 0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
provides the inclusion of lowlever_init.o.

Signed-off-by: Mirza Krak <mirza.k...@gmail.com>
---

Changes in V2:
- droped changes to patch 0001 and 0002 to perserve the backport tags, based on 
comments from Paul Barker.

 .../0003-Include-lowlevel_init.o-for-rpi2.patch| 25 --
 recipes-bsp/u-boot/u-boot_%.bbappend   |  1 -
 2 files changed, 26 deletions(-)
 delete mode 100644 
recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch

diff --git 
a/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch 
b/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
deleted file mode 100644
index ce0273f..000
--- a/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
+++ /dev/null
@@ -1,25 +0,0 @@
-From 1eb01436bc57ad32519a4567a1c9ec82d52d60a1 Mon Sep 17 00:00:00 2001
-From: Paul Barker <p...@paulbarker.me.uk>
-Date: Tue, 29 Nov 2016 19:47:49 +
-Subject: [PATCH] Include lowlevel_init.o for rpi2
-
-Signed-off-by: Paul Barker <p...@paulbarker.me.uk>
-Upstream-status: Inappropriate
-(not needed upstream as rpi_2 board directory is removed in latest
-version)

- board/raspberrypi/rpi_2/Makefile | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/board/raspberrypi/rpi_2/Makefile 
b/board/raspberrypi/rpi_2/Makefile
-index d82cd21..9f865c5 100644
 a/board/raspberrypi/rpi_2/Makefile
-+++ b/board/raspberrypi/rpi_2/Makefile
-@@ -5,3 +5,4 @@
- #
-
- obj-y := ../rpi/rpi.o
-+obj-y += ../rpi/lowlevel_init.o
---
-2.1.4
-
diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend 
b/recipes-bsp/u-boot/u-boot_%.bbappend
index a4545f0..0edc8dc 100644
--- a/recipes-bsp/u-boot/u-boot_%.bbappend
+++ b/recipes-bsp/u-boot/u-boot_%.bbappend
@@ -3,5 +3,4 @@ RDEPENDS_${PN}_append_rpi = " rpi-u-boot-scr"
 SRC_URI_append_rpi = " \
 file://0001-arm-add-save_boot_params-for-ARM1176.patch \
 file://0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch \
-file://0003-Include-lowlevel_init.o-for-rpi2.patch \
 "
--
2.1.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi][PATCH] u-boot: drop patch to include lowlevel_init

2016-12-08 Thread Mirza Krak

From: Mirza Krak <mirza.k...@gmail.com>

U-boot has been updated to 2016.11 in OE-core Which means that we can
use the upstream patches instead of the backports and no need for the third
patch which causes a build error when used with 2016.11.

Signed-off-by: Mirza Krak <mirza.k...@gmail.com>
---
 ...0001-arm-add-save_boot_params-for-ARM1176.patch |  4 +---
 ...through-of-the-firmware-provided-FDT-blob.patch |  7 ++
 .../0003-Include-lowlevel_init.o-for-rpi2.patch| 25 --
 recipes-bsp/u-boot/u-boot_%.bbappend   |  1 -
 4 files changed, 3 insertions(+), 34 deletions(-)
 delete mode 100644 
recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch

diff --git 
a/recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch 
b/recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch
index a5ebff5..97a4144 100644
--- a/recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch
+++ b/recipes-bsp/u-boot/files/0001-arm-add-save_boot_params-for-ARM1176.patch
@@ -1,7 +1,7 @@
 From 3e10fcde3f3c24a488866dd33fa3f5d46ff3d7a3 Mon Sep 17 00:00:00 2001
 From: =?UTF-8?q?C=C3=A9dric=20Schieli?= <cschi...@gmail.com>
 Date: Fri, 11 Nov 2016 11:59:06 +0100
-Subject: [PATCH] arm: add save_boot_params for ARM1176
+Subject: [PATCH 1/1] arm: add save_boot_params for ARM1176
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit
@@ -13,8 +13,6 @@ feature mirrors the equivalent ARMv7 feature.

 Signed-off-by: Cédric Schieli <cschi...@gmail.com>
 Acked-by: Stephen Warren <swar...@nvidia.com>
-Signed-off-by: Paul Barker <p...@paulbarker.me.uk>
-Upstream-status: Backport
 ---
  arch/arm/cpu/arm1176/start.S | 10 ++
  1 file changed, 10 insertions(+)
diff --git 
a/recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
 
b/recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
index 323b7ab..95ad94c 100644
--- 
a/recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
+++ 
b/recipes-bsp/u-boot/files/0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch
@@ -1,7 +1,7 @@
 From ade243a211d62327e9ebadce27bbbff7981e37f0 Mon Sep 17 00:00:00 2001
 From: =?UTF-8?q?C=C3=A9dric=20Schieli?= <cschi...@gmail.com>
 Date: Fri, 11 Nov 2016 11:59:07 +0100
-Subject: [PATCH] rpi: passthrough of the firmware provided FDT blob
+Subject: [PATCH 1/1] rpi: passthrough of the firmware provided FDT blob
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit
@@ -34,11 +34,8 @@ ${fdt_addr} and pass it to the kernel.

 [1] https://www.raspberrypi.org/forums//viewtopic.php?f=107=134018

-Upstream-Status: Backport
-
 Signed-off-by: Cédric Schieli <cschi...@gmail.com>
 Acked-by: Stephen Warren <swar...@nvidia.com>
-Signed-off-by: Jonathan Liu <net...@gmail.com>
 ---
  board/raspberrypi/rpi/Makefile|  1 +
  board/raspberrypi/rpi/lowlevel_init.S | 36 +++
@@ -152,5 +149,5 @@ index 6245b36..ffd6d31 100644
set_usbethaddr();
  #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
 --
-2.10.2
+2.1.4

diff --git 
a/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch 
b/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
deleted file mode 100644
index ce0273f..000
--- a/recipes-bsp/u-boot/files/0003-Include-lowlevel_init.o-for-rpi2.patch
+++ /dev/null
@@ -1,25 +0,0 @@
-From 1eb01436bc57ad32519a4567a1c9ec82d52d60a1 Mon Sep 17 00:00:00 2001
-From: Paul Barker <p...@paulbarker.me.uk>
-Date: Tue, 29 Nov 2016 19:47:49 +
-Subject: [PATCH] Include lowlevel_init.o for rpi2
-
-Signed-off-by: Paul Barker <p...@paulbarker.me.uk>
-Upstream-status: Inappropriate
-(not needed upstream as rpi_2 board directory is removed in latest
-version)

- board/raspberrypi/rpi_2/Makefile | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/board/raspberrypi/rpi_2/Makefile 
b/board/raspberrypi/rpi_2/Makefile
-index d82cd21..9f865c5 100644
 a/board/raspberrypi/rpi_2/Makefile
-+++ b/board/raspberrypi/rpi_2/Makefile
-@@ -5,3 +5,4 @@
- #
-
- obj-y := ../rpi/rpi.o
-+obj-y += ../rpi/lowlevel_init.o
---
-2.1.4
-
diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend 
b/recipes-bsp/u-boot/u-boot_%.bbappend
index a4545f0..0edc8dc 100644
--- a/recipes-bsp/u-boot/u-boot_%.bbappend
+++ b/recipes-bsp/u-boot/u-boot_%.bbappend
@@ -3,5 +3,4 @@ RDEPENDS_${PN}_append_rpi = " rpi-u-boot-scr"
 SRC_URI_append_rpi = " \
 file://0001-arm-add-save_boot_params-for-ARM1176.patch \
 file://0002-rpi-passthrough-of-the-firmware-provided-FDT-blob.patch \
-file://0003-Include-lowlevel_init.o-for-rpi2.patch \
 "
--
2.1.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] morty release ?

2016-12-08 Thread Mirza Krak

2016-12-05 23:07 GMT+01:00 Khem Raj <raj.k...@gmail.com>:
>
>> On Dec 5, 2016, at 1:46 PM, Mirza Krak <mirza.k...@gmail.com> wrote:
>>
>> 2016-12-05 19:37 GMT+01:00 Khem Raj <raj.k...@gmail.com>:
>>> On Mon, Dec 5, 2016 at 7:26 AM, Mirza Krak <mirza.k...@gmail.com> wrote:
>>>> Hi.
>>>>
>>>> I have some questions and remarks and hopefully someone here can answer 
>>>> them.
>>>>
>>>> The meta-raspberrpi layer is missing a morty release? Any time frame
>>>> of when this will be added?
>>>
>>> We use master as long as possible, when we have a change that makes master
>>> incompatible with prior releases we branch out for the prior releases
>>> at that point.
>>
>> Thank you for the clarification.
>>
>>>
>>>>
>>>> There is currently a issue when using U-boot due to some updates in
>>>> RPi boot firmware. See [1] and [2]. Which should be noted/resolved
>>>> before a morty release?
>>>>
>>>> To provide some more information about above mentioned problem. If you
>>>> use the current firmware files (20161030 in meta-raspberrypi) together
>>>> with U-boot (2016.03) you lose the console on U-boot and on Linux
>>>> kernel. This is due to the fact that "newer" firmware sets a default
>>>> uart clock to 48 MHz, but U-boot has a hard-coded value of 3 MHz, and
>>>> since we yet do not support to "forward" the patched DTB provided by
>>>> the firmware from U-boot to Linux we also break console on Linux.
>>>>
>>>> The "default" values has been updated in Linux, see [2]. But if you
>>>> use that updated Linux kernel there is a mismatch between u-boot and
>>>> Linux. Should be noted that U-boot 2016.11 does not have this problem
>>>> since it does not try to initialize the UART port at all and only
>>>> relies on firmware to set it up correctly (see [3]).
>>>
>>> We should drop 2016.03 and support 2016.11 for keeping it simple.
>>
>> Should also update Linux which contains the updated default value
>> (since we do not yet support pass-trough of firmware DTB, I know I
>> have seen some patches on the mailing list but nothing in upstream
>> yet).
>>
>> But U-boot is in meta-openembedded, are you suggesting that we update
>> it in meta-raspberry? Or updating it in meta-openembedded?
>
> Yeah I realized that u-boot is coming from OE-Core, it is possible to carry
> patches in meta-raspberrypi to fix the version for morty in bbappends. May
> be we need to branch out morty after we have fixed this if we want to
> drop this version of u-boot beyond morty.

And now u-boot is 2016.11 in OE-core. So no need of bbappends. If the
kernel (4.4) is updated to 4.4.36 it should all be aligned and fixed.

Best Regards
Mirza
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] morty release ?

2016-12-05 Thread Mirza Krak

2016-12-05 22:46 GMT+01:00 Mirza Krak <mirza.k...@gmail.com>:
> 2016-12-05 19:37 GMT+01:00 Khem Raj <raj.k...@gmail.com>:
>> On Mon, Dec 5, 2016 at 7:26 AM, Mirza Krak <mirza.k...@gmail.com> wrote:
>>> Hi.
>>>
>>> I have some questions and remarks and hopefully someone here can answer 
>>> them.
>>>
>>> The meta-raspberrpi layer is missing a morty release? Any time frame
>>> of when this will be added?
>>
>> We use master as long as possible, when we have a change that makes master
>> incompatible with prior releases we branch out for the prior releases
>> at that point.
>
> Thank you for the clarification.
>
>>
>>>
>>> There is currently a issue when using U-boot due to some updates in
>>> RPi boot firmware. See [1] and [2]. Which should be noted/resolved
>>> before a morty release?
>>>
>>> To provide some more information about above mentioned problem. If you
>>> use the current firmware files (20161030 in meta-raspberrypi) together
>>> with U-boot (2016.03) you lose the console on U-boot and on Linux
>>> kernel. This is due to the fact that "newer" firmware sets a default
>>> uart clock to 48 MHz, but U-boot has a hard-coded value of 3 MHz, and
>>> since we yet do not support to "forward" the patched DTB provided by
>>> the firmware from U-boot to Linux we also break console on Linux.
>>>
>>> The "default" values has been updated in Linux, see [2]. But if you
>>> use that updated Linux kernel there is a mismatch between u-boot and
>>> Linux. Should be noted that U-boot 2016.11 does not have this problem
>>> since it does not try to initialize the UART port at all and only
>>> relies on firmware to set it up correctly (see [3]).
>>
>> We should drop 2016.03 and support 2016.11 for keeping it simple.
>
> Should also update Linux which contains the updated default value
> (since we do not yet support pass-trough of firmware DTB, I know I
> have seen some patches on the mailing list but nothing in upstream
> yet).
>
> But U-boot is in meta-openembedded, are you suggesting that we update
> it in meta-raspberry? Or updating it in meta-openembedded?

I mean openembedded-core/poky.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] morty release ?

2016-12-05 Thread Mirza Krak

2016-12-05 19:37 GMT+01:00 Khem Raj <raj.k...@gmail.com>:
> On Mon, Dec 5, 2016 at 7:26 AM, Mirza Krak <mirza.k...@gmail.com> wrote:
>> Hi.
>>
>> I have some questions and remarks and hopefully someone here can answer them.
>>
>> The meta-raspberrpi layer is missing a morty release? Any time frame
>> of when this will be added?
>
> We use master as long as possible, when we have a change that makes master
> incompatible with prior releases we branch out for the prior releases
> at that point.

Thank you for the clarification.

>
>>
>> There is currently a issue when using U-boot due to some updates in
>> RPi boot firmware. See [1] and [2]. Which should be noted/resolved
>> before a morty release?
>>
>> To provide some more information about above mentioned problem. If you
>> use the current firmware files (20161030 in meta-raspberrypi) together
>> with U-boot (2016.03) you lose the console on U-boot and on Linux
>> kernel. This is due to the fact that "newer" firmware sets a default
>> uart clock to 48 MHz, but U-boot has a hard-coded value of 3 MHz, and
>> since we yet do not support to "forward" the patched DTB provided by
>> the firmware from U-boot to Linux we also break console on Linux.
>>
>> The "default" values has been updated in Linux, see [2]. But if you
>> use that updated Linux kernel there is a mismatch between u-boot and
>> Linux. Should be noted that U-boot 2016.11 does not have this problem
>> since it does not try to initialize the UART port at all and only
>> relies on firmware to set it up correctly (see [3]).
>
> We should drop 2016.03 and support 2016.11 for keeping it simple.

Should also update Linux which contains the updated default value
(since we do not yet support pass-trough of firmware DTB, I know I
have seen some patches on the mailing list but nothing in upstream
yet).

But U-boot is in meta-openembedded, are you suggesting that we update
it in meta-raspberry? Or updating it in meta-openembedded?

Best Regards
Mirza
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi] morty release ?

2016-12-05 Thread Mirza Krak

Hi.

I have some questions and remarks and hopefully someone here can answer them.

The meta-raspberrpi layer is missing a morty release? Any time frame
of when this will be added?

There is currently a issue when using U-boot due to some updates in
RPi boot firmware. See [1] and [2]. Which should be noted/resolved
before a morty release?

To provide some more information about above mentioned problem. If you
use the current firmware files (20161030 in meta-raspberrypi) together
with U-boot (2016.03) you lose the console on U-boot and on Linux
kernel. This is due to the fact that "newer" firmware sets a default
uart clock to 48 MHz, but U-boot has a hard-coded value of 3 MHz, and
since we yet do not support to "forward" the patched DTB provided by
the firmware from U-boot to Linux we also break console on Linux.

The "default" values has been updated in Linux, see [2]. But if you
use that updated Linux kernel there is a mismatch between u-boot and
Linux. Should be noted that U-boot 2016.11 does not have this problem
since it does not try to initialize the UART port at all and only
relies on firmware to set it up correctly (see [3]).

Hope I made sense here :).

[1]. https://github.com/agherzan/meta-raspberrypi/issues/36
[2]. https://github.com/raspberrypi/linux/issues/1732#issuecomment-264810083
[3]. 
http://git.denx.de/?p=u-boot.git;a=commit;h=cd0fa5bff8052b19bde6967c2734f323c9848568

Best Regards
Mirza
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] quilt-native fails on tar version 1.27.1

2014-04-29 Thread Mirza Krak


Hi.

I recently updated my Ubuntu PC to 14.04 LTS which broke yocto builds.

From what I can see is that there seems to be an issue with the tar 
command and quilt-native recipe. But I am to newb to fix this. Do you 
guys have any ideas?


uname -a
Linux mirza-hm 3.11.0-20-generic #34-Ubuntu SMP Tue Apr 1 20:40:25 UTC 
2014 x86_64 x86_64 x86_64 GNU/Linux


tar --version
tar (GNU tar) 1.27.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
http://gnu.org/licenses/gpl.html.

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.

Attached log.

--
Med Vänliga Hälsningar / Best Regards

***
Mirza Krak
Host Mobility AB
mirza.k...@hostmobility.com
Anders Personsgatan 12, 416 64 Göteborg
Sweden
http://www.hostmobility.com
Direct: +46 31 31 32 704
Phone: +46 31 31 32 700
Fax: +46 31 80 67 51
Mobile: +46 730 28 06 22
***

Pseudo is not present but is required, building this first before the main build
Loading cache...done.
Loaded 2305 entries from dependency cache.
WARNING: No recipes available for:
  /home/mirza/git/mx4/t20/oe-core/build/../stuff/meta-toradex/recipes-multimedia/webm/libvpx_1.1.0.bbappend

Build Configuration:
BB_VERSION= 1.18.0
BUILD_SYS = x86_64-linux
NATIVELSBSTRING   = Ubuntu-14.04
TARGET_SYS= arm-angstrom-linux-gnueabi
MACHINE   = colibri-t20
DISTRO= angstrom
DISTRO_VERSION= v2013.06
TUNE_FEATURES = armv7a vfp callconvention-hard
TARGET_FPU= vfp
meta-angstrom = (nobranch):7543b99f99592d0c23a5e66007b8631751b9d79c
meta-toradex  = (nobranch):1f28b5dd41ac54410dfaf9a3dc5d9af64ab06037
meta-linaro-toolchain = (nobranch):6321a745aba4fc2ddb559d4606b0a98afc8a1ca2
toolchain-layer   
meta-oe   
meta-efl  
meta-gpe  
meta-gnome
meta-xfce 
meta-initramfs
meta-systemd  
meta-networking   
meta-multimedia   = (nobranch):13ae5105ee30410136beeae66ec41ee4a8a2e2b0
meta-lxde = (nobranch):f69ffe4cebf94f48f02838002dbc3544b3ffb460
meta-browser  = (nobranch):2140f2a114f7009f86479afb12a524bb157cbb0e
meta-java = colibri:9dfb7ecb87e67052e94641d6e02907c582264217
meta  = (nobranch):3549f5f203363302256848bb33c05c4fd4871948
meta-hm   = master:6d5b8beee5db008fca42dddbe8378c8b57fcca8e

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Marking Active Tasks
NOTE: Pruned 357 inactive tasks, 63 left
NOTE: Assign Weightings
NOTE: Compute totals (have 1 endpoint(s))
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 7 of 63 (ID: 10, /home/mirza/git/mx4/t20/oe-core/build/../stuff/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.61.bb, do_populate_sysroot)
NOTE: recipe quilt-native-0.61-r0: task do_populate_sysroot: Started
+ cd /home/mirza/git/mx4/t20/oe-core/build/out-eglibc/work/x86_64-linux/quilt-native/0.61-r0/quilt-0.61
+ sysroot_stage_all
+ sysroot_stage_dirs /home/mirza/git/mx4/t20/oe-core/build/out-eglibc/work/x86_64-linux/quilt-native/0.61-r0/image /home/mirza/git/mx4/t20/oe-core/build/out-eglibc/work/x86_64-linux/quilt-native/0.61-r0/sysroot-destdir/
+ from=/home/mirza/git/mx4/t20/oe-core/build/out-eglibc/work/x86_64-linux/quilt-native/0.61-r0/image
+ to=/home/mirza/git/mx4/t20/oe-core/build/out-eglibc/work/x86_64-linux/quilt-native/0.61-r0/sysroot-destdir/
+ sysroot_stage_dir /home/mirza/git/mx4/t20/oe-core/build/out-eglibc/work/x86_64-linux/quilt-native/0.61-r0/image/home/mirza/git/mx4/t20/oe-core/build/out-eglibc/sysroots/x86_64-linux/usr/include /home/mirza/git/mx4/t20/oe-core/build/out-eglibc/work/x86_64-linux/quilt-native/0.61-r0/sysroot-destdir//home/mirza/git/mx4/t20/oe-core/build/out-eglibc/sysroots/x86_64-linux/usr/include
+ src=/home/mirza/git/mx4/t20/oe-core/build/out-eglibc/work/x86_64-linux/quilt-native/0.61-r0/image/home/mirza/git/mx4/t20/oe-core/build/out-eglibc/sysroots/x86_64-linux/usr/include
+ dest=/home/mirza/git/mx4/t20/oe-core/build/out-eglibc/work/x86_64-linux/quilt-native/0.61-r0/sysroot-destdir//home/mirza/git/mx4/t20/oe-core/build/out-eglibc/sysroots/x86_64-linux/usr/include
+ 
[ ! -d /home/mirza/git/mx4/t20/oe-core/build/out-eglibc/work/x86_64-linux/quilt-native/0.61-r0/image/home/mirza/git/mx4/t20/oe-core/build/out-eglibc/sysroots/x86_64-linux/usr/include ]
+ return
+ [ x86_64-linux = x86_64-linux ]
+ sysroot_stage_dir /home/mirza/git/mx4/t20/oe-core/build/out-eglibc/work/x86_64-linux/quilt-native/0.61-r0/image/home/mirza/git/mx4/t20/oe-core/build/out-eglibc/sysroots/x86_64-linux/usr/bin /home/mirza/git/mx4/t20/oe-core/build/out-eglibc/work/x86_64-linux/quilt-native/0.61-r0/sysroot-destdir//home/mirza/git/mx4/t20/oe-core/build/out-eglibc/sysroots/x86_64-linux/usr/bin
+ src=/home/mirza/git

Re: [yocto] quilt-native fails on tar version 1.27.1

2014-04-29 Thread Mirza Krak


On 2014-04-29 09:53, Jegan Chandru wrote:

Hi,

Only Yocto version 1.6 supports Ubuntu 14.04 LTS. I hope you are using 
that. if you are using 1.6 Ubuntu 14.04 LTS is not in supported distros.

I am actually working with 1.4 so should probably update.


http://www.yoctoproject.org/docs/1.6/ref-manual/ref-manual.html#detailed-supported-distros
http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#detailed-supported-distros
http://www.yoctoproject.org/docs/1.4/ref-manual/ref-manual.html#detailed-supported-distros

Also I found this,
https://lists.yoctoproject.org/pipermail/yocto/2013-October/016540.html
which makes ur problem a known issue.

Great that it is an known problem!


HTH.

-JC

Thank you for the help.



On Tue, Apr 29, 2014 at 11:30 AM, Mirza Krak 
mirza.k...@hostmobility.com mailto:mirza.k...@hostmobility.com wrote:


Hi.

I recently updated my Ubuntu PC to 14.04 LTS which broke yocto builds.

From what I can see is that there seems to be an issue with the
tar command and quilt-native recipe. But I am to newb to fix this.
Do you guys have any ideas?

uname -a
Linux mirza-hm 3.11.0-20-generic #34-Ubuntu SMP Tue Apr 1 20:40:25
UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

tar --version
tar (GNU tar) 1.27.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.

Attached log.

-- 
Med Vänliga Hälsningar / Best Regards


***
Mirza Krak
Host Mobility AB
mirza.k...@hostmobility.com mailto:mirza.k...@hostmobility.com
Anders Personsgatan 12, 416 64 Göteborg
Sweden
http://www.hostmobility.com
Direct: +46 31 31 32 704 tel:%2B46%2031%2031%2032%20704
Phone: +46 31 31 32 700 tel:%2B46%2031%2031%2032%20700
Fax: +46 31 80 67 51 tel:%2B46%2031%2080%2067%2051
Mobile: +46 730 28 06 22 tel:%2B46%20730%2028%2006%2022
***


--
___
yocto mailing list
yocto@yoctoproject.org mailto:yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto




--
JCP


--
Med Vänliga Hälsningar / Best Regards

***
Mirza Krak
Host Mobility AB
mirza.k...@hostmobility.com
Anders Personsgatan 12, 416 64 Göteborg
Sweden
http://www.hostmobility.com
Direct: +46 31 31 32 704
Phone: +46 31 31 32 700
Fax: +46 31 80 67 51
Mobile: +46 730 28 06 22
***

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

37 matches

Mail list logo