Re: [yocto] :how to solve the basehash value changed from 'xxx' to 'aaaa' ?

[Mike Looijmans]

Without your recipe source code, no one can tell for sure, but I suspect you 
have something like a "DATE" in there that evaulates to a different value if 
you run it a second later.


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
Postbus 440, 5680 AK Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 13-11-19 04:09, www wrote:
> Dear all,
> 
> When I modify the os-release file in my yocto project, it appear some error, 
> and how can I solve it ? Who can give me some help or advice? Thank you！
> I carried out the recommended order and it didn't work.
> 
> /ERROR: os-release-1.0-r0 do_compile: Taskhash mismatch 
> ce133f0458608e03aa55224df28156e523e54903115efbbcd62946f84a867201 versus 
> 7269881f0eb1759ed420a2db4c04fb477cd8c1288bc5f82df5c8161bb926ea1f for 
> /home/temp/wanghp/wsp/git_s/local-source/obmc-sugon/entity_fruu/meta/recipes-core/os-release/os-release.bb.do_compile/
> /ERROR: Taskhash mismatch 
> ce133f0458608e03aa55224df28156e523e54903115efbbcd62946f84a867201 versus 
> 7269881f0eb1759ed420a2db4c04fb477cd8c1288bc5f82df5c8161bb926ea1f for 
> /home/temp/wanghp/wsp/git_s/local-source/obmc-sugon/entity_fruu/meta/recipes-core/os-release/os-release.bb.do_compile/
> /ERROR: When reparsing 
> /home/temp/wanghp/wsp/git_s/local-source/obmc-sugon/entity_fruu/meta/recipes-core/os-release/os-release.bb.do_compile,
>  
> //the basehash value changed from 
> 99a42a1a3b1a151de604267b159558ecaf1031a3bec8917df132c81302e729a5 to 
> 4f3288a8763e2e1af78e4b3cdd9c0c0ccb3b0d5c78a3073c188b22200df2a9b0. //The 
> metadata is not deterministic and this needs to be fixed./
> /ERROR: The following commands may help:/
> /ERROR: $ bitbake os-release -cdo_compile -Snone/
> /ERROR: Then:/
> /ERROR: $ bitbake os-release -cdo_compile -Sprintdiff/
> 
> /ERROR: When reparsing 
> /home/temp/wanghp/wsp/git_s/local-source/obmc-sugon/entity_fruu/meta/recipes-core/os-release/os-release.bb.do_compile,
>  
> //the basehash value changed from 
> 99a42a1a3b1a151de604267b159558ecaf1031a3bec8917df132c81302e729a5 to 
> 47c30012daa6aa77be09a93fe21e66995361ef26b4487111005617db8cb4de59. The 
> metadata 
> is not deterministic and this needs to be fixed./
> /ERROR: The following commands may help:/
> /ERROR: $ bitbake os-release -cdo_compile -Snone/
> /ERROR: Then:/
> /ERROR: $ bitbake os-release -cdo_compile -Sprintdiff/
> 
> thanks,
> Byron
> 
> 
> 

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

Re: [yocto] [warrior] [meta-qt4] 3rdparty: javascriptcore: JITStubs.cpp: allow builds of JavaScriptCore with gcc v8

[Mike Looijmans]

I ran into this issue yesterday, and this patch solves the compilation on 
warrior. However, it's a patch for Qt itself, and not for OE.

Is there already a warrior patch in the making, or should I submit one?


On 19-11-19 13:37, Quentin Schulz wrote:
> At least since gcc v8, source code with asm volatile won't compile
> anymore.
> 
> The volatile qualifier anyway is a no-op since asm blocks are implicitly
> volatile as written in the documentation[1].
> 
> Let's get rid of this redundant qualifier so we can build with newer
> GCCs.
> 
> The resulting error message is the following (note that there is a
> bunch of them):
> ../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:617:5: error: 
> expected '(' before 'volatile'
> asm volatile (
>   ^~~~
>   (
> ../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:618:1: error: 
> expected unqualified-id before string constant
> ".text\n"
> ^
> ../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:617:15: error: 
> expected ')' before string constant
> asm volatile (
> ~^
>  )
> ".text\n"
> ~
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm
> 
> Upstream-Status: Inappropriate
> Signed-off-by: Quentin Schulz 
> ---
>   .../JavaScriptCore/jit/JITStubs.cpp   | 48 +--
>   1 file changed, 24 insertions(+), 24 deletions(-)
> 
> diff --git a/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp 
> b/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
> index d8027ff2..dcead6d0 100644
> --- a/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
> +++ b/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
> @@ -116,7 +116,7 @@ COMPILE_ASSERT(offsetof(struct JITStackFrame, savedEBX) 
> == 0x3c, JITStackFrame_s
>   COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x58, 
> JITStackFrame_callFrame_offset_matches_ctiTrampoline);
>   COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x50, 
> JITStackFrame_code_offset_matches_ctiTrampoline);
>   
> -asm volatile (
> +asm (
>   ".text\n"
>   ".globl " SYMBOL_STRING(ctiTrampoline) "\n"
>   HIDE_SYMBOL(ctiTrampoline) "\n"
> @@ -138,7 +138,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
>   "ret" "\n"
>   );
>   
> -asm volatile (
> +asm (
>   ".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
>   HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
>   SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
> @@ -154,7 +154,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
>   "ret" "\n"
>   );
>   
> -asm volatile (
> +asm (
>   ".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
>   HIDE_SYMBOL(ctiOpThrowNotCaught) "\n"
>   SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
> @@ -179,7 +179,7 @@ COMPILE_ASSERT(offsetof(struct JITStackFrame, savedRBX) 
> == 0x48, JITStackFrame_s
>   COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x90, 
> JITStackFrame_callFrame_offset_matches_ctiTrampoline);
>   COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x80, 
> JITStackFrame_code_offset_matches_ctiTrampoline);
>   
> -asm volatile (
> +asm (
>   ".globl " SYMBOL_STRING(ctiTrampoline) "\n"
>   HIDE_SYMBOL(ctiTrampoline) "\n"
>   SYMBOL_STRING(ctiTrampoline) ":" "\n"
> @@ -206,7 +206,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
>   "ret" "\n"
>   );
>   
> -asm volatile (
> +asm (
>   ".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
>   HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
>   SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
> @@ -222,7 +222,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
>   "ret" "\n"
>   );
>   
> -asm volatile (
> +asm (
>   ".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
>   HIDE_SYMBOL(ctiOpThrowNotCaught) "\n"
>   SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
> @@ -242,7 +242,7 @@ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
>   #error "JIT_STUB_ARGUMENT_VA_LIST not supported on ARMv7."
>   #endif
>   
> -asm volatile (
> +asm (
>   ".text" "\n"
>   ".align 2" "\n"
>   ".globl " SYMBOL_STRING(ctiTrampoline) "\n"
> @@ -269,7 +269,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
>   "bx lr" "\n"
>   );
>   
> -asm volatile (
> +asm (
>   ".text" "\n"
>   ".align 2" "\n"
>   ".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
> @@ -287,7 +287,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
>   "bx lr" "\n"
>   );
>   
> -asm volatile (
> +asm (
>   ".text" "\n"
>   ".align 2" "\n"
>   ".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
> @@ -305,7 +305,7 @@ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
>   
>   #elif COMPILER(GCC) && CPU(ARM_TRADITIONAL)
>   
> -asm volatile (
> +asm (
>   ".globl " SYMBOL_STRING(ctiTrampoline) "\n"
>   HIDE_SYMBOL(ctiTrampoline) "\n"
>   SYMBOL_STRING(ctiTrampoline) ":" "\n"
> @@ -323,7 +323,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
>   "mov pc, lr" "\n"
>   );
>   
> -asm volatile (
> +asm (
>   ".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
>   HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
>   SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
> @@ 

Re: [yocto] Reducing the size of the image by optimizing python

[Mike Looijmans]

> Optimising to just pyc files is an optimisation further than most
> people find they need and will be much harder to do.

It's actually quite simple, just add a bbappend to the python recipe that puts 
all .py files into the "dbg" or newly created "src" package. Or simply delete 
all .py files in a do_install_append.


Here's an example of the "src" approach:

https://github.com/OpenPLi/openpli-oe-core/blob/develop/meta-openpli/recipes-devtools/python/python_2.7.13.bbappend


Simply doing this in the bbappend might also work (untested):

do_install_append() {
find ${D}${libdir}/python${PYTHON_MAJMIN}/ -name '*.py' -remove
}


Removing the ".py" files roughly cuts the disk space in half.


The "src" approach works on any package, and has the advantage that you can 
still install the source files for debugging and development.

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
Postbus 440, 5680 AK Best
The Netherlands

T: +31 (0) 499 33 69 69
E: {E-mail
W: www.topicproducts.com

Please consider the environment before printing this e-mail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Getting a package PV from another

[Mike Looijmans]

The version of your OE layer is all the version that you'll ever (technically) 
need. That version (usually a git hash) dictates all other versions.

When asked for version numbers of included packages, I always just dump the 
manifest file into their lap.

You can also ask and report the version numbers at runtime (e.g. using opkg or 
dpkg). That also prevents lying to your users :)

On 01-07-19 11:28, Gabriele Zampieri wrote:
> Up, with more details:
> 
> I have a top recipe that depends on *my-image:do_build*. I'd like to retrieve 
> the PV of a couple of packages (from that top recipe) that are used to mark 
> our custom software. Any suggestions?
> 
> Gabriele
> 
> Il giorno ven 28 giu 2019 alle ore 11:25 Gabriele Zampieri 
> mailto:gabbla.mal...@gmail.com>> ha scritto:
> 
> Hi all,
> 
> is there a way to get a specific package version from another?
> 
> Best regards,
> Gabriele
> 
> 

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

Re: [yocto] Yocto Project support for Numeric/Scientific Python

[Mike Looijmans]

Just attempting to revive this dead horse again...

Anyone made any proress here?

Since cross-compiling turned out to be really really painful, I tried if 
compiling on the board would be an option. No such luck, apparently the 
Fortran compiler isn't being crosscompiled either.


On 26-01-19 20:01, Philip Balister wrote:
> Sounds like we need a layer for packages that needs fortran enabled and
> collect out work there.
> 
> Philip
> 
> On 01/24/2019 05:31 AM, Mike Looijmans wrote:
>> +1
>>
>> Got lapack to compile, but no such luck with any "blas" package (like
>> openblas). And that's a requirement for octave, which was what I was aiming 
>> at.
>>
>> I'll share some recipes, tomorrow or so (today is stuffed with other work).
>>
>>
>> On 23-01-19 22:39, Philip Balister wrote:
>>> I care :)
>>>
>>> On 01/23/2019 04:28 PM, Randy MacLeod wrote:
>>>> On 1/23/19 2:54 PM, Smith, Virgil (US) wrote:
>>>>> Is there a current or relatively recent recipe for SciPy and related
>>>>> libraries?
>>>>
>>>> People have worked on it at least once before but found some problems
>>>> with blas and atlas:
>>>>
>>>> https://lists.yoctoproject.org/pipermail/yocto/2018-March/thread.html#40348
>>>>
>>>> I'd say that there is interest.
>>>> I CCed Peter who started one of the threads
>>>> and BCCed 5 other people who seemed to be interested
>>>> since I didn't want to drag them all into the thread.
>>>>
>>>>
>>>>>
>>>>> Further and more importantly, is having a maintainer for (recipes for)
>>>>> those libraries a priority for the active members of the Project?
>>>>> (i.e. does interest rise above the general welcoming of participants
>>>>> to periodically asking “Hey has anyone put out a call to fill this
>>>>> slot?” if/when the slot is vacant).
>>>>
>>>> It's always nice to have a maintainer but community members sometimes
>>>> keep recipes up to date even if they aren't direct users.
>>>>
>>>>>
>>>>> BTW: If this is the wrong list for this query, please let me know.
>>>>
>>>> It a reasonable list for general discussion.
>>>> If you get to a point where patches are being submitted,
>>>> it should probably go to another list such as:
>>>>
>>>>>
>>>>> Why?  We are trying to gauge community interest before making long
>>>>> term plans.
>>>>>
>>>>> We would like to know if this horse is at all likely to have
>>>>> healthcare before betting on it (without sacrificing other patients to
>>>>> obtain the proper veterinary degree and keep up practice to treat it
>>>>> ourselves).
>>>> heh.
>>>>
>>>> Thanks!
>>>> ../Randy
>>>>
>>>>>
>>>>> NOTE:  I see from the RRS emails that Derek Straka is currently
>>>>> maintaining the python-numpy recipe.  THANK YOU!
>>>>>
>>>>>
>>>>> 
>>>>>
>>>>> Notice to recipient: This email is meant for only the intended
>>>>> recipient of the transmission, and may be a communication privileged
>>>>> by law, subject to export control restrictions or that otherwise
>>>>> contains proprietary information. If you receive this email by
>>>>> mistake, please notify us immediately by replying to this message and
>>>>> then destroy it and do not review, disclose, copy or distribute it.
>>>>> Thank you in advance for your cooperation.
>>>>>
>>>>
>>>>
>>

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

Re: [yocto] [rauc] create a rescue image

[Mike Looijmans]

On 26-03-19 11:02, jairo wrote:
> El mar, 26-03-2019 a las 09:14 +0100, Patrick Boettcher escribió:
>> On Tue, 26 Mar 2019 09:05:47 +0100
>> jairo  wrote:
...
> Yes, I know, it is somewhat risky, but I have only 512MB of nand
> memory, and we are getting a lot of software. I think we have to
> evaluate the move to a hardware with more memory, at the moment is what
> we have. I think it is practically impossible to put 2 systems in so
> little memory.

With NAND you'll probably have a filesystem (jffs2 or UBI) in place. With 
that, you could just use a package manager like opkg to update sofware. If the 
box has a network connection, just running "opkg update && opkg upgrade" will 
install the current releases with the minimum effort. We've been using this on 
a million boxes and it works fine (until someone decides to patch libc and you 
get a 300+ package upgrade).

Linux is also capable of upgrading a running system. Basically, copy some 
executables to a tmp filesystem, remount everything read-only, and change root 
to the tmp part. Then you can rewrite partitions and reboot.

In any case, you should have a u-boot configuration that allows it to be 
debricked. Typically a USB stick or DFU will do nicely if your board has USB. 
Or even serial...
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [rauc] create a rescue image

[Mike Looijmans]

On 26-03-19 12:31, jairo wrote:
> 
> Thank you very much Mike.
> 
> 
> 
>> With NAND you'll probably have a filesystem (jffs2 or UBI) in place.
>> With that, you could just use a package manager like opkg to update
>> sofware. If the box has a network connection, just running "opkg
>> update && opkg upgrade" will install the current releases with the
>> minimum effort. We've been using this on a million boxes and it works
>> fine (until someone decides to patch libc and you get a 300+ package
>> upgrade).
> 
> 
> Is there a public repository with ipk packages, or do I have to create
> my own repository?

OpenEmbedded already created it, it's usually in build/tmp-glibc/deploy/ipk

To turn it into a "feed" just share this directory through http. On my 
development setup, I installed apache and created a symlink to that directory. 
You'll also need to add "distro-feed-configs" to your image (and maybe append 
it a bit to match your system).

> Can opkg solve dependencies well? Can it create problems?

Haven't seen any problems with it, and it installs dependencies along with 
packages.

>> Linux is also capable of upgrading a running system. Basically, copy
>> some
>> executables to a tmp filesystem, remount everything read-only, and
>> change root
>> to the tmp part. Then you can rewrite partitions and reboot.
>>
>> In any case, you should have a u-boot configuration that allows it to
>> be
>> debricked. Typically a USB stick or DFU will do nicely if your board
>> has USB.
>> Or even serial...
> 
> I'm using Barebox, I think there would be no problems out there, the
> bad part of using opkg is that the product should be used by clients
> without much knowledge of linux. In that part I think it would be
> easier for customers to use a update system such as Rauc or any similar

The system that's using ipkg is a TV settop box, and the average user has 
about the intellectual capabilities of a potato.

To actually upgrade, the user selects "settings" and "update software" from 
the main menu using the remote control, and doesn't even have to leave the 
couch.

(To recover a bricked box, or install from scratch, the procedure is much more 
complicated: Download a zip file, unpack on a USB stick, put it into the 
settop and switch it on. That'd require intellect slightly above your average 
vegetable but is still doable apparently.)

Being user-friendly is about providing a proper wrapper, it's not about 
technology.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] how to make writable permission for home/root in read-only rootfs (yocto build)

[Mike Looijmans]

On 19-03-19 11:26, Arunkumar V wrote:
> HI
> 
> can any one explain me how to config the /home/root as writable in read-only 
> rootfs?
> 
> is any setting to do with local file or .bbclass?
> if any macros need to be enable, please
> 


You can mount something writeable on top of /home/root to accomplish that.

(Being able to write onto a read-only partition would kind of defeat the 
purpose of a read-only filesystem...)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Managing multiple builds

[Mike Looijmans]

The first thing you should realize is that providing your recipe files will 
produce a lot more insight into your issue than lengthy e-mails ever will.

What I was attempting to convey to you is that you should move your "distro" 
parameters into the "machine" config. Then just build for multiple machines. 
If you want to have multiple image types, just create multiple image recipes, 
and build them.

You can use the whole build tree for multiple machines. Changing DISTRO has 
lots of extra effects on packages, in the past it wasn't possible at all 
without wiping tmp, and it still is not a nice thing to do, as you have 
discovered for yourself now.

You'd invoke your build like this:

for machine in apple-pie orange-pie banana-pie
do
   MACHINE=$machine bitbake red-image blue-image green-image
done

You can build multiple images for the same machine in parallel, and you can 
build multiple machine in the same environment (not in parallel yet, 
unfortunately, but you probably don't have that many machines that this might 
really help).


On 14-02-19 19:04, Timothy Froehlich wrote:
> It'll be multiple software loads (with different required kernel modules and 
> things like) over at least two machines. These products will do very 
> different 
> things but I want to use the same base and take advantage of OE's sstate, etc.
> 
> So I want to be clear, I can figure out how to piece things together with 
> bash 
> scripts to accomplish what I want, but I feel like there's a "correct" way to 
> manage multiple builds (that use different distros, machines, environment 
> variables) that I'm missing. (And perhaps I've already stumbled on the 
> "correct way" but it's not as elegant as I'd like so I'm not happy with it 
> yet.) Problem number one is that the build directory doesn't seem to be 
> something that is intended to be source controlled. I found the TEMPLATECONF 
> flag last night so that answers my question of how to source control my 
> sstate 
> mirror locations and etc. I can write instructions that are basically "git 
> pull poky, git pull the layers, 'TEMPLATECONF=... source oe_init_build_env', 
> bitbake add_layers" But then what if you want to build product a or product b?
> 
> I think what I may have just settled on is to make sure I've got my distros 
> set up correctly (one distro per product) and add in my own DEVBUILD flag to 
> my template local.conf.sample which will do things like turning on 
> debug_tweaks, ENABLE_UART and adding dropbear/etc. And that'll let me just 
> configure things by setting DISTRO, MACHINE and DEVBUILD=1/0. I'm ruling out 
> multiconf. I don't want my builds to take five minutes before I find out that 
> I have a typo in a recipe and I can get the same behavior by just controlling 
> the above. I'll probably set the tmpdir to something like 
> "tmp_DISTRO_MACHINE" 
> to avoid different configs stepping on each other.
> 
> Does this seem like the proper way to do things?
> 
> 
> 
> On Wed, Feb 13, 2019 at 11:18 PM Mike Looijmans  <mailto:mike.looijm...@topic.nl>> wrote:
> 
> Two products sounds like two machines. Just create a machine.conf for each
> product (even if they use similar hardware), then you don't need overrides
> elsewhere.
> 
> OE/Yocto is smart enough to figure out what needs to be (re)built. Some OE
> projects build the same image(s) for over 40 machines (and counting)...
> 
> On 14-02-19 01:34, Timothy Froehlich wrote:
>  >
>  > Hi, I've been struggling a bit with this question. I want to use Yocto 
> to
>  > build two+ products with separate dev/prod images for each (dev 
> including
>  > debug-tweaks, etc.). I've ruled out separate image recipes because my 
> dev
>  > builds need ENABLE_UART on my RaspberryPi and that needs to be set at
> the conf
>  > level (I've got it set conditionally in my base dist conf). Multiconfig
> looked
>  > promising, but I'm not happy about how long the parsing takes to start 
> a
>  > build. "--postread" looked nice, but I've barely seen it mentioned so 
> I'm
>  > worried that it's not well supported.
>  >
>  > Basically, what do most people do for controlling their builds?
>  > Tim Froehlich
>  > Embedded Linux Engineer
>  > tfroehl...@archsys.io <mailto:tfroehl...@archsys.io>
> <mailto:tfroehl...@archsys.io <mailto:tfroehl...@archsys.io>>
>  > 215-218-8955
>  >
> 
> 
> 
> -- 
> Tim Froehlich
> Embedded Linux Engineer
> tfroehl...@archsys.io <mailto:tfroehl...@archsys.io>
> 215-218-8955

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

Re: [yocto] Managing multiple builds

[Mike Looijmans]

Two products sounds like two machines. Just create a machine.conf for each 
product (even if they use similar hardware), then you don't need overrides 
elsewhere.

OE/Yocto is smart enough to figure out what needs to be (re)built. Some OE 
projects build the same image(s) for over 40 machines (and counting)...

On 14-02-19 01:34, Timothy Froehlich wrote:
> 
> Hi, I've been struggling a bit with this question. I want to use Yocto to 
> build two+ products with separate dev/prod images for each (dev including 
> debug-tweaks, etc.). I've ruled out separate image recipes because my dev 
> builds need ENABLE_UART on my RaspberryPi and that needs to be set at the 
> conf 
> level (I've got it set conditionally in my base dist conf). Multiconfig 
> looked 
> promising, but I'm not happy about how long the parsing takes to start a 
> build. "--postread" looked nice, but I've barely seen it mentioned so I'm 
> worried that it's not well supported.
> 
> Basically, what do most people do for controlling their builds?
> Tim Froehlich
> Embedded Linux Engineer
> tfroehl...@archsys.io 
> 215-218-8955
> 

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

Re: [yocto] Make one directory writeable

[Mike Looijmans]

As for the particular case of /mnt, on most images, /mnt is a symlink to 
/media, and /media is (on) a filesystem in RAM, so it's already writeable.

If the write does not need to persist across reboots, use a tmpfs mount.

If your real problem is that you cannot create anything in /mnt (or /media for 
modern users), the issue is that someone broke something in your image, 
because that should work out of the box.


On 13-02-19 09:27, Josef Holzmayr wrote:
> Hi Bhupendra,
> 
> On Wed, Feb 13, 2019 at 12:51:17PM +0530, Bhupendra Singh wrote:
>> Hello
>>
>> I have built core-image-minimal  with read only rootfs  then now  I want to
>> make one directory (like /mnt) writable.
>>
>> Is it possible to make one directory writeable in read only rootfs if yes
>> ,please tell me how can I do same.
> 
> This is not exactly yocto specific, general linux concepts apply. You
> can use a secondary, tertiary, ... partition or starage device and then
> mount that as read-write. But it always has to be a seperate filesystem.
> There is no way to make only one path of a given filesystem RW, it
> always means that the whole filesystem is writeable.
> 
> Greetz
> 

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

Re: [yocto] Update kernel by package-management

[Mike Looijmans]

On 08-02-19 17:02, Mauro Ziliani wrote:
> Hi all.
> 
> I know this is a VERY dangerous operation, but I'm curious.

Depends on your definition of "dangerous".

> Is it possible to upgrade the kernel & dtb from debian package in Yocto?

Sure, doing it all the time (from ipk, but that shouldn't matter much).

If the kernel/dts is just a file on the system, there's just a package that 
installs /boot/uImage or whatever.

If the kernel is in some special location in flash or so, I usually set up the 
kernel image to install into /tmp/ and then let a post-install script write it 
from /tmp/ into the flash location (e.g. using "flashcp").

Same for the devicetree.

As for dangerous, worst thing that could happen is that you'd have to use the 
bootloader to revive the system.

> That is: there is a recipe  (which produce a deb package) to copy zImage
> and imx6dl-sabresd.dtb directly in the boot partition?
> 
> 
> I working on a imx6sabresd board.
> 
> The root partition is /dev/mmcblk2p1

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

Re: [yocto] Yocto Project support for Numeric/Scientific Python

[Mike Looijmans]

+1

Got lapack to compile, but no such luck with any "blas" package (like 
openblas). And that's a requirement for octave, which was what I was aiming at.

I'll share some recipes, tomorrow or so (today is stuffed with other work).


On 23-01-19 22:39, Philip Balister wrote:
> I care :)
> 
> On 01/23/2019 04:28 PM, Randy MacLeod wrote:
>> On 1/23/19 2:54 PM, Smith, Virgil (US) wrote:
>>> Is there a current or relatively recent recipe for SciPy and related
>>> libraries?
>>
>> People have worked on it at least once before but found some problems
>> with blas and atlas:
>>
>> https://lists.yoctoproject.org/pipermail/yocto/2018-March/thread.html#40348
>>
>> I'd say that there is interest.
>> I CCed Peter who started one of the threads
>> and BCCed 5 other people who seemed to be interested
>> since I didn't want to drag them all into the thread.
>>
>>
>>>
>>> Further and more importantly, is having a maintainer for (recipes for)
>>> those libraries a priority for the active members of the Project?
>>> (i.e. does interest rise above the general welcoming of participants
>>> to periodically asking “Hey has anyone put out a call to fill this
>>> slot?” if/when the slot is vacant).
>>
>> It's always nice to have a maintainer but community members sometimes
>> keep recipes up to date even if they aren't direct users.
>>
>>>
>>> BTW: If this is the wrong list for this query, please let me know.
>>
>> It a reasonable list for general discussion.
>> If you get to a point where patches are being submitted,
>> it should probably go to another list such as:
>>
>>>
>>> Why?  We are trying to gauge community interest before making long
>>> term plans.
>>>
>>> We would like to know if this horse is at all likely to have
>>> healthcare before betting on it (without sacrificing other patients to
>>> obtain the proper veterinary degree and keep up practice to treat it
>>> ourselves).
>> heh.
>>
>> Thanks!
>> ../Randy
>>
>>>
>>> NOTE:  I see from the RRS emails that Derek Straka is currently
>>> maintaining the python-numpy recipe.  THANK YOU!
>>>
>>>
>>> 
>>>
>>> Notice to recipient: This email is meant for only the intended
>>> recipient of the transmission, and may be a communication privileged
>>> by law, subject to export control restrictions or that otherwise
>>> contains proprietary information. If you receive this email by
>>> mistake, please notify us immediately by replying to this message and
>>> then destroy it and do not review, disclose, copy or distribute it.
>>> Thank you in advance for your cooperation.
>>>
>>
>>

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

Re: [yocto] Set linux capabilities on binary on a recipe in meta-oe layer

[Mike Looijmans]

Sometimes the problem is that parts of the underscored function name are seen 
as overrides, so you should try using "mysetcapfunction" instead as a name.

Also, there's a semicolon missing:
ROOTFS_POSTPROCESS_COMMAND += "my_setcap_function;"


On 12-11-18 14:09, Markus W wrote:
> Thanks Uwe!
> 
> I tried the global approach by adding the following to my local.conf file:
> 
> ROOTFS_POSTPROCESS_COMMAND += "my_setcap_function"
> 
> my_setcap_function() {
>      setcap cap_net_raw+eip ${IMAGE_ROOTFS}/usr/bin/node
> }
> 
> But got the following warning:
> WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: Function 
> my_setcap_function 
> doesn't exist
> 
> I have tried to add the function into a recipe but this doesn't work either. 
> Where should the function be defined?
> 
> Regards,
> Markus
> 
> 
> On Fri, 9 Nov 2018 at 15:35, Uwe Geuder  > wrote:
> 
> Hi!
> 
> 
> On Fri, Nov 9, 2018 at 12:16 PM Markus W markus4dev-at-gmail.com
>  wrote:
> 
>  > On Thu, 8 Nov 2018 at 22:53, Piotr Tworek  > wrote:
> ...
>  >> pkg_postinst_ontarget_${PN} () {
>  >>    setcap cap_net_raw+eip $D${bindir}/node
>  >> }
> ...
>  > How can this be achieved when the rootfs is created and not on first
>  > boot? I would like not to ship libcap binaries with the target in
>  > production.
> 
> Ideally I would do it "locally" in do_install of the node recipe (you can
> append extra statements to the task in your own .bbappend in your own
> layer, don't edit existing recipes)
> 
> That of course requires that the package manager preserves the
> capabilites. I have no experience which package manager would do
> or not do that.
> 
> "Globally" you can do it by appending a new function to
> ROOTFS_POSTPROCESS_COMMAND
> 
> https://www.yoctoproject.org/docs/2.5.1/mega-manual/mega-manual.html#var-
> ROOTFS_POSTPROCESS_COMMAND
> 
> This is done in your image recipe.
> 
> Regards,
> 
> Uwe Geuder
> Neuro Event Labs Oy
> Tampere, Finland
> uwe.gex...@neuroeventlabs.com  (Bot
> check: fix one obvious typo)
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto
> 
> 

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

Re: [yocto] [PATCH] runtime: add BSP test case for usb storage

[Mike Looijmans]

On 24-09-18 23:01, Paul Eggleton wrote:

On Monday, 24 September 2018 3:02:28 PM NZST Hussin, Mohamad Noor Alim wrote:

...

Otherwise I agree with Mike's reply, we should avoid writing to the storage 
device as part of the test.


It is mean that just do test like mount and unmount only? To read something in 
storage device we need to write at first place?


That's true - but you can still do a read test if you make it a precondition of 
the test
that you write some known file to the storage device before running the test
(as part of setup, just as you need to set up the board/device before
running any tests - you just need to ensure this gets documented somewhere).


You're not testing the USB device, you're testing the USB stack. To do that, 
just reading some data from "/dev/sda" is sufficient. You don't even need to 
mount it. If this works, the stack is okay. If there are transfer errors or 
problems, the USB stack will tell you about it.

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

Re: [yocto] Yocto userbase in numbers?

[Mike Looijmans]

On 20-08-18 09:40, Joe Steeve wrote:

On Thu, 2018-08-09 at 21:43 +0100, Richard Purdie wrote:

Even if you just look at the fields the project is used in based on the
project's members like Comcast, the automotive industry (e.g.
Automotive Grade Linux), several major OS vendors (Windriver, Mentor
Graphics, Montavista, ENEA) and in TVs (LG), the deployment of the
project is significant


I think it's a safe bet that if you see some device running (embedded) Linux 
it's probably using Yocto in some form (unless they used buildroot, that is).


As for installed userbase, the open settopbox project openpli.org has a 
install base that is probably somewhere in the 10 to 100 million devices. Just 
the openpli server generates over 4TB a month in traffic each month, which 
mostly consists of fetching "packages.gz" files for the weekly upgrades. 
Again, out of respect for people's privacy there aren't any solid numbers.



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

Re: [yocto] [PATCH] runtime: add BSP test case for usb storage

[Mike Looijmans]

I would not write to flash media in this test. It's pointless, if you can read 
the the device, it means that you can already send commands and data to it, 
and reading will thus test data going in both directions already. Writing to 
the media will just wear it out, and if there's a problem unmounting it, it 
may lead to a corrupted filesystem and yield unpredictable future results.



On 19-08-18 17:22, mohamad.noor.alim.hus...@intel.com wrote:

From: Mohamad Noor Alim Hussin 

Contain test cases to test mount/unmount the usb stick on target
platform such as minnowboard and beaglebone. The test assume that
the usb storage device such as usb thumb drive was plugged into
the target device otherwise the test for would failed. It also test
to read and write from usb thumb drive. Usb test cases start with
mount the usb thumb drive then write and read from it. Lastly, it
will unmount it. If the usb thumb drive unable to mount due to corrupt
of partition or not exists, then the mount test will failed and the
following test would skip.

This test need to enable flag 'HARDWARE_TEST = "1"' on conf/local.conf
file in order to run on target device. This test should be skip on qemu.

Signed-off-by: Mohamad Noor Alim Hussin 
---
  meta/lib/oeqa/runtime/cases/usb.py | 54 ++
  1 file changed, 54 insertions(+)
  create mode 100644 meta/lib/oeqa/runtime/cases/usb.py

diff --git a/meta/lib/oeqa/runtime/cases/usb.py 
b/meta/lib/oeqa/runtime/cases/usb.py
new file mode 100644
index 000..3e17645
--- /dev/null
+++ b/meta/lib/oeqa/runtime/cases/usb.py
@@ -0,0 +1,54 @@
+from oeqa.runtime.case import OERuntimeTestCase
+from oeqa.core.decorator.depends import OETestDepends
+from oeqa.core.decorator.oeid import OETestID
+from oeqa.core.decorator.data import skipIfNotDataVar
+
+class USBTest(OERuntimeTestCase):
+@classmethod
+def setUpClass(cls):
+cls.hw_test_path = '~/test'
+cls.usb_path = os.path.join(cls.hw_test_path, 'stick')
+cls.usb_file = os.path.join(cls.usb_path, 'hello_stick')
+src = os.path.join(cls.tc.runtime_files_dir, 'bsp-test-helper')
+cls.tc.target.run('mkdir -p %s' % (cls.usb_path))
+cls.tc.target.copyTo(src, '/usr/bin')
+
+@classmethod
+def tearDownClass(cls):
+cls.tc.target.run('rm -rf %s' % (cls.hw_test_path))
+
+@skipIfNotDataVar('HARDWARE_TEST','1',
+'Usb test only run on platform. It will skip on qemu.')
+@OETestID(216)
+def test_usb_mount(self):
+command = ('bsp-test-helper --mount pendrive %s' % (self.usb_path))
+status, output = self.target.run(command)
+msg = ('Unable to mount USB stick. '
+'Status and output:%s and %s.' % (status, output))
+self.assertEqual(status, 0, msg = msg)
+
+@OETestID(217)
+@OETestDepends(['usb.USBTest.test_usb_write_file'])
+def test_usb_read_file(self):
+command = ('cat %s' % (self.usb_file))
+status, output = self.target.run(command)
+msg = ('Unable to read file from USB stick. '
+'Status and output:%s and %s.' % (status, output))
+self.assertEqual(status, 0, msg = msg)
+
+@OETestDepends(['usb.USBTest.test_usb_mount'])
+@OETestID(219)
+def test_usb_write_file(self):
+command = ('echo hello_world > %s' % (self.usb_file))
+status, output = self.target.run(command)
+msg = ('Status and  output:%s and %s.' % (status, output))
+self.assertEqual(status, 0, msg = msg)
+
+@OETestDepends(['usb.USBTest.test_usb_mount'])
+@OETestID(218)
+def test_usb_unmount(self):
+command = ('bsp-test-helper --umount %s' % (self.usb_path))
+status, output = self.target.run(command)
+msg = ('Unable to unmount USB stick. '
+'Status and output:%s and %s.' % (status, output))
+self.assertEqual(status, 0, msg = msg)



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

Re: [yocto] Fwd: Basehash value changed issue

[Mike Looijmans]

The simplest (and probably preferred) way to fix would be to get rid of TIME 
usage from that recipe. Parsing the recipe twice should yield the same result 
and your trouble would be over.



On 02-07-18 07:27, techi eth wrote:

Hi,

Can anybody give me hint over below issue.

Thanks




Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



-- Forwarded message --

From: *techi eth* mailto:techi...@gmail.com>>
Date: Thu, Jun 21, 2018 at 6:30 PM
Subject: Basehash value changed issue
To: yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>


Hi,

I am facing issue with basehash value changed while building image on one of 
my test board (Ref of beagle bone) on morty branch.


Error :
gateway.bb.do_rootfs, the basehash value changed from 
e685a429b8df6dcff60063f087d425ee to 3f98a102f48ea8722835ad0d65bfbc1f. The 
metadata is not deterministic and this needs to be fixed


When i run bitbake-diffsigs -t gateway do_rootfs
I found below O/P.
basehash changed from 8e6b9498c9704590bd016491efcbf9f9 to 
3f98a102f48ea8722835ad0d65bfbc1f

Variable TIME value changed from '112854' to '115745'

After googling I found that TIME need's to be added in vardepsexclude list.
I added below in conf/distro/machine.conf but error persist.
do_rootfs[vardepsexclude] = "TIME DATE DATETIME"

Please suggest me where & what has to be added to come out of issue.





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

Re: [yocto] fstab entry not mounting at boot-up

[Mike Looijmans]

On 05-01-18 20:43, Edward Wingate wrote:

My system has a USB-SSD drive and I added this to my fstab:
/dev/sda1  /mnt/driveauto   defaults,nonempty  0 0

But it doesn't get mounted on start-up.  I can use "mount -a" after
start-up and it mounts successfully.

Everything else in fstab gets mounted on boot.  Does anyone know why
my new entry doesn't?


Wild guess: "/mnt/drive" does not exist yet when the fstab is processed during 
startup. That will cause mount to fail.



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



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

Re: [yocto] recipe to clean up files from rootfs

[Mike Looijmans]

${D} won't work here, grep on ROOTFS_POSTPROCESS_COMMAND for recipes that get 
it right.


And, much much much better would be to just not install psplash into your image!

On 13-12-17 09:10, Sherif Omran wrote:
here is my recipe, the aim was to remove some files from the init.d folder and 
tweek before creating the image


#
# This file was derived from the 'Hello World!' example recipe in the
# Yocto Project Development Manual.
#

SUMMARY = "This recipe removes any missing files from the filesystem before 
finalinzing it"

SECTION = "base"
LICENSE = "MIT"
LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"


#SRC_URI = "file://*"

S = "${WORKDIR}"
BB_STRICT_CHECKSUM ="0"
ALLOW_EMPTY_${PN}="1"


#IMAGE_INSTALL = "packagegroup-core-boot packagegroup-base-extended 
${CORE_IMAGE_EXTRA_INSTALL}"

#IMAGE_INSTALL = "${CORE_IMAGE}"

#inherit core-image

my_postprocess_function() {
  rm -r ${D}${bindir}/init.d/psplash.sh
}

ROOTFS_POSTPROCESS_COMMAND += "my_postprocess_function; "

On Wed, Dec 13, 2017 at 7:22 AM, Mike Looijmans <mike.looijm...@topic.nl 
<mailto:mike.looijm...@topic.nl>> wrote:


Well, start by sharing yours first.

Be careful when naming your shell routine, sometimes OE considers parts
behind the underscore as overrides and then it cannot find it.


On 13-12-17 07:14, Sherif Omran wrote:

hi Mike,
i could not get it to work, if you have a recipe that works, please
    share it. ROOTFS_POSTPROCESS_COMMAND seems to be buggy.

thank you



On Tue, Dec 12, 2017 at 1:58 PM, Mike Looijmans
<mike.looijm...@topic.nl <mailto:mike.looijm...@topic.nl>
<mailto:mike.looijm...@topic.nl <mailto:mike.looijm...@topic.nl>>> 
wrote:

     On 11-12-17 15:18, Sherif Omran wrote:

         i want to create a recipe to clean some files from the rootfile
         system, but i don't know how to let this recipe run the last 
one
         before building the rootfile system.


     You can use ROOTFS_POSTPROCESS_COMMAND in your image recipe to do
some
     last-minute filesystem cleanup.

     However, in most cases it's much better to determine what recipe
puts the
     files there and modify the recipe or remove the package. It would
    help a
     lot if you would reveal what files you want to remove and why.


     Kind regards,

     Mike Looijmans
     System Expert

     TOPIC Products
     Materiaalweg 4, NL-5681 RJ Best
     Postbus 440, NL-5680 AK Best
     Telefoon: +31 (0) 499 33 69 79
<tel:%2B31%20%280%29%20499%2033%2069%2079>
<tel:%2B31%20%280%29%20499%2033%2069%2079>
     E-mail: mike.looijm...@topicproducts.com
<mailto:mike.looijm...@topicproducts.com>
     <mailto:mike.looijm...@topicproducts.com
<mailto:mike.looijm...@topicproducts.com>>
     Website: www.topicproducts.com <http://www.topicproducts.com>
<http://www.topicproducts.com>

     Please consider the environment before printing this e-mail



     --


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79 <tel:%2B31%20%280%29%20499%2033%2069%2079>
E-mail: mike.looijm...@topicproducts.com
<mailto:mike.looijm...@topicproducts.com>
Website: www.topicproducts.com <http://www.topicproducts.com>

Please consider the environment before printing this e-mail






Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



___


     yocto mailing list
yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
<mailto:yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>>
https://lists.yoctoproject.org/listinfo/yocto
<https://lists.yoctoproject.org/listinfo/yocto>
     <https://lists.yoctoproject.org/listinfo/yocto
<https://lists.yoctoproject.org/listinfo/yocto>>






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

Re: [yocto] recipe to clean up files from rootfs

[Mike Looijmans]

Well, start by sharing yours first.

Be careful when naming your shell routine, sometimes OE considers parts behind 
the underscore as overrides and then it cannot find it.



On 13-12-17 07:14, Sherif Omran wrote:

hi Mike,
i could not get it to work, if you have a recipe that works, please share it. 
ROOTFS_POSTPROCESS_COMMAND seems to be buggy.


thank you



On Tue, Dec 12, 2017 at 1:58 PM, Mike Looijmans <mike.looijm...@topic.nl 
<mailto:mike.looijm...@topic.nl>> wrote:


On 11-12-17 15:18, Sherif Omran wrote:

i want to create a recipe to clean some files from the rootfile
system, but i don't know how to let this recipe run the last one
before building the rootfile system.


You can use ROOTFS_POSTPROCESS_COMMAND in your image recipe to do some
last-minute filesystem cleanup.

However, in most cases it's much better to determine what recipe puts the
files there and modify the recipe or remove the package. It would help a
lot if you would reveal what files you want to remove and why.


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79 <tel:%2B31%20%280%29%20499%2033%2069%2079>
E-mail: mike.looijm...@topicproducts.com
<mailto:mike.looijm...@topicproducts.com>
Website: www.topicproducts.com <http://www.topicproducts.com>

Please consider the environment before printing this e-mail



-- 



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



___

yocto mailing list
yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto
<https://lists.yoctoproject.org/listinfo/yocto>




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

Re: [yocto] recipe to clean up files from rootfs

[Mike Looijmans]

On 11-12-17 15:18, Sherif Omran wrote:
i want to create a recipe to clean some files from the rootfile system, but i 
don't know how to let this recipe run the last one before building the 
rootfile system.


You can use ROOTFS_POSTPROCESS_COMMAND in your image recipe to do some 
last-minute filesystem cleanup.


However, in most cases it's much better to determine what recipe puts the 
files there and modify the recipe or remove the package. It would help a lot 
if you would reveal what files you want to remove and why.



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



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

Re: [yocto] VPS for building and serving.

[Mike Looijmans]

On 11-12-17 12:12, Paul Barker wrote:

On Sun, Dec 10, 2017 at 1:15 PM, Daniel. <danielhi...@gmail.com> wrote:

Hi,

Is there anybody using VPS for building and serving packages? What plans you
do recommend?


I don't recommend using a VPS, they tend to get expensive for the spec
you need for a Yocto build. You want plenty of RAM, CPU and disk
space.


Saparate the two.

Use a private desktop machine for building images and feeds. You probably 
already have it...


For serving packages, any HTTP server will do, so you can use any cheap plain 
and simple file based hosting.
Update the feed using rsync, or just use a script that copies the newer files 
over to the hosting.


It's also a much better option security wise.


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



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

Re: [yocto] RFC: Backwards compatibility checking sstate-cache

[Mike Looijmans]

On 23-09-17 00:51, Joshua Lock wrote:

On 22/09/17 15:00, Mike Looijmans wrote:
I think this remark in the referenced link is the best summary of "what 
could be improved":


"""the biggest weakness of the sstate signature bits, in my opinion, is that 
it only tracks inputs, not outputs. If task A depends on B, and the metadata 
input to B changes, then A will be rebuilt, even if the *output* of B didn't 
change as a result of the change to its metadata."""


For example, if someone fixes a bug in gcc that only applies to MIPS, then 
builds that only target an ARM machine shouldn't be affected. Much worse 
than that, I have a dependency like:

gcc -> ... -> python -> bitstream tool -> FPGA image

so this means that a change in gcc causes Python to rebuild, which causes 
the bitstream tool to be rebuilt and produce idential output, and that 
triggers a roughly 31-hour build of lots of FPGA images. These are the ones 
we really want to break. A binary output compare would help a lot, even if 
80% of the libraries fail to create reproducible output, I may still be 
spared those 31 hours...


I think tracking digital output is technically feasible, and won't require 
any change to existing recipes.


Also think about "feed" setups. When I see my settop reporting "331 packages 
need updating"... It'd be great if that could be avoided.




That's what packagefeed-stability.bbclass is for. Work on binary 
reproducibility will improve things here too.


Interesting, thanks for the hint.

That might cut down a bit on the over 4TB/month "update my box" traffic.


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail


Visit us at the Space Tech Expo Europe (Stand E-71)
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] RFC: Backwards compatibility checking sstate-cache

[Mike Looijmans]

people are interested in making use of it and their use cases.

Kind regards,
Michael Ho

--
BMW Car IT GmbH
Michael Ho
Spezialist Entwicklung - Linux Software Integration
Lise-Meitner-Str. 14
89081 Ulm

Tel.: +49 731 3780 4071 <tel:%2B49%20731%203780%204071>
Mobil: +49 152 5498 0471 <tel:%2B49%20152%205498%200471>
Fax: +49-731-37804-001 <tel:%2B49-731-37804-001>
Mail: michael...@bmw-carit.de <mailto:michael...@bmw-carit.de>
Web: http://www.bmw-carit.de

BMW Car IT GmbH
Gechäftsführer: Kai-Uwe Balszuweit und Alexis Trolin
Sitz und Registergericht: München HRB 134810


--



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail


Visit us at the Space Tech Expo Europe (Stand E-71)
___

yocto mailing list
yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto
<https://lists.yoctoproject.org/listinfo/yocto>






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

Re: [yocto] The basehash value changed from...

[Mike Looijmans]

On 07-09-17 11:06, Zoran Stojsavljevic wrote:

 > If you keep your sstate-cache directory then delete tmp/ dir is what you need
 > to do. Rebuilding from sstate-cache is very quick.

It does not help. Since I'll have at the end/I'll end-up with the same 
problem. My best guess. :-(


Since I am building the whole humongous YOCTO build not in one, rather in two 
steps, like this:


|bitbake meta-toolchain-qt5 (5 hours build||on my HP EliteBook 840 G1)
||bitbake angstrom-lxde-image|  (5 hours build on my HP EliteBook 840 G1)

Here, my best guess is that the first build sets its own hash, which the 
second sets also its own (very

different), then makes hash checks in deploy/ tree, and fails... !?


You should be able to do "bitbake meta-toolchain-qt5 angstrom-lxde-image" in 
one go. That should be faster than two separate runs.


If you change the DISTRO, you'll invalidate your "tmp" building dir resulting 
in loads of new stuff being built.


If you need two distros, make two build enviroments from them. You should 
share the sstate-cache directory between them (saves tons on building 
compilers and such) but not the "tmp" directory.




On Thu, Sep 7, 2017 at 9:42 AM, Khem Raj <raj.k...@gmail.com 
<mailto:raj.k...@gmail.com>> wrote:


On Thu, Sep 7, 2017 at 12:37 AM, Zoran Stojsavljevic
<zoran.stojsavlje...@gmail.com <mailto:zoran.stojsavlje...@gmail.com>> 
wrote:
> While re-compiling the whole YOCTO load for freescale i.MX6, where I have
> added Qt5 layers (and it failed many times, so I needed to do some tricks
> there), I encounter the following warning (in ORANGE) and error (in RED)
> while finishing the build:
>
> WARNING: Duplicate inclusion for
> 
/home/user/toradex/Qt5-plus-x11/oe-core/build/../layers/meta-toradex-bsp-common/conf/tdx_version.conf
> in
> 
/home/user/toradex/Qt5-plus-x11/oe-core/build/../layers/meta-toradex-demos/recipes-images/images/tdx-image-fstype.inc
> ERROR: When reparsing
> 
/home/user/toradex/Qt5-plus-x11/oe-core/build/../layers/meta-toradex-demos/recipes-images/images/angstrom-lxde-image.bb.do_image_teziimg,
> the basehash value changed from b7b4f312b8b657bfdd068ebd8e2dd104 to
> 1e71714a9c01964cdc724c52290abee4. The metadata is not deterministic and 
this
> needs to be fixed.
> NOTE: Tasks Summary: Attempted 7415 tasks of which 7394 didn't need to be
> rerun and all succeeded.
> NOTE: Writing buildhistory
>
> It built (after all) complete deploy with all the images. I kind of get 
what
> is going on here.
>
> Question: how to rebuild the complete deploy/images NOT deleting tmp/? It
> compiled overall (in two steps) > 10h. Do I need to touch some file?
>

if you keep your sstate-cache directory then delete tmp/ dir is what you 
need
    to do. Rebuilding from sstate-cache is very quick

 > Thank you,
 > Zoran
 >
>
> --
> 


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



___

> yocto mailing list
> yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
> https://lists.yoctoproject.org/listinfo/yocto
<https://lists.yoctoproject.org/listinfo/yocto>
>






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

Re: [yocto] release management

[Mike Looijmans]

On 14-08-17 21:10, Gunnar Andersson wrote:


Hey Russell

I don't claim to be an authority on best practices but I will share some
thoughts.

On Sun, 2017-08-13 at 06:58 -0400, Russell Peterson wrote:

Hello.

As I learn more about yocto and more importantly gain practical experience
with it I have started to think about my release structure.  Is there a
“best practices” document or something like that that speaks to this?
For example, how does everyone deal with “external” meta layer
dependencies?  My software uses poky and meta-openembedded, of course.


We simply use a parent project [1] that includes git submodules, one per
yocto layer.  I'm of the opinion that if git (only) can be used, why
introduce other tools?   But it requires you to learn and master that
feature.



We arrived at exactly the same setup. One parent repository that contains the 
project-unique recipes, and submodules for the layers it needs.


It's a lot better than attempting to script things. For one thing, git will 
tell you the state of the submodules.


If I rembemer correctly, Android builds use a tool to manage the layer 
repositories. I didn't much like it though. And "yet another tool"...



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



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

Re: [yocto] What can I share between projects?

[Mike Looijmans]

On 19-05-17 13:47, Mike Looijmans wrote:

On 19-05-17 03:43, Paul D. DeRocco wrote:

If I'm doing multiple unrelated Yocto based projects, and they use the
same version of Yocto, and the same metadata (except for my own layers),
am I right in assuming that I can share everything in poky, downloads, 
and

sstate-cache, and I only need separate build directories? (I normally put
downloads and sstate-cache next to my build directory, rather than inside
it.)



You can share BOTH the downloads and sstate-cache. You can safely share 
sstate-cache between various versions of Yocto (OE) and distros, 
machines, etc., it was designed just for that.


Our build server keeps a single sstate-cache for about 30 projects, with 
4 versions of OE, 3 distros, and a dozen MACHINE configs. No problems 
encountered.


In addition to that, you can share the whole thing ("tmp") for projects 
that use the same local.conf and the same OE version. Building various 
images for about 20 different machines with over 4 different 
architectures (MIPS and ARM variants) in the same directory works just 
fine and drastically reduces build times since they can share about 
everything that's not unique to each machine.



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



Join our presentation at Electronics & Applications 2017:
FPGA for real-time data processing, subject “Hardware platform for industrial 
ultrasound steel plate Inspection” Topic Embedded Systems - Herman Kuster, 1st 
June 10 AM

Visit http://eabeurs.nl/author/612884/ for more information

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

Re: [yocto] What can I share between projects?

[Mike Looijmans]

On 19-05-17 03:43, Paul D. DeRocco wrote:

If I'm doing multiple unrelated Yocto based projects, and they use the
same version of Yocto, and the same metadata (except for my own layers),
am I right in assuming that I can share everything in poky, downloads, and
sstate-cache, and I only need separate build directories? (I normally put
downloads and sstate-cache next to my build directory, rather than inside
it.)



You can share BOTH the downloads and sstate-cache. You can safely share 
sstate-cache between various versions of Yocto (OE) and distros, machines, 
etc., it was designed just for that.


Our build server keeps a single sstate-cache for about 30 projects, with 4 
versions of OE, 3 distros, and a dozen MACHINE configs. No problems encountered.



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



Join our presentation at Electronics & Applications 2017:
FPGA for real-time data processing, subject “Hardware platform for industrial 
ultrasound steel plate Inspection” Topic Embedded Systems - Herman Kuster, 1st 
June 10 AM

Visit http://eabeurs.nl/author/612884/ for more information

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

Re: [yocto] [PATCHv2][meta-gplv2] gnutls: add older gnutls compatible with nettle

[Mike Looijmans]

On 24-04-17 16:29, Martin Jansa wrote:

* gnutls depends on nettle-3.1* since 3.4.0:
  The requirement for nettle was bumped from 3.0 to 3.1 in gnutls_3_4_0
  
https://gitlab.com/gnutls/gnutls/commit/c84129af91b21d33ffe086e507632771b0e76498
  and from 2.7 to 3.0 a bit earlier also in gnutls_3_4_0
  
https://gitlab.com/gnutls/gnutls/commit/3fa80cf68919f07b3351b2722278ba463d6e731c
* add recipe for last release in 3.3 branch which is compatible
  with nettle 2.7.1 used in meta-gplv2

Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
---
 .../gnutls/configure.ac-fix-sed-command.patch  | 31 ++
 recipes-support/gnutls/gnutls_3.3.27.bb| 23 
 2 files changed, 54 insertions(+)
 create mode 100644 
recipes-support/gnutls/gnutls/configure.ac-fix-sed-command.patch
 create mode 100644 recipes-support/gnutls/gnutls_3.3.27.bb

diff --git a/recipes-support/gnutls/gnutls/configure.ac-fix-sed-command.patch 
b/recipes-support/gnutls/gnutls/configure.ac-fix-sed-command.patch
new file mode 100644
index 000..44a9934
--- /dev/null
+++ b/recipes-support/gnutls/gnutls/configure.ac-fix-sed-command.patch
@@ -0,0 +1,31 @@
+From eb93aa7b986c84da60a3db40afb29d1a70c50223 Mon Sep 17 00:00:00 2001
+From: Robert Yang <liezhi.y...@windriver.com>
+Date: Sat, 17 Jan 2015 17:02:15 +
+Subject: [PATCH] configure.ac: fix sed command
+
+The "sed 's/.bak//g'" matchs "bitbake", which would cause strange errors
+when the S contains "bitbake", fix to "sed 's/\.bak$//'`"
+
+Upstream-Status: Pending
+
+Signed-off-by: Robert Yang <liezhi.y...@windriver.com>
+---
+ configure.ac | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index c6818a0..1c4582d 100644
+--- a/configure.ac
 b/configure.ac
+@@ -466,7 +466,7 @@ if test "$NEED_LIBOPTS_DIR" = "true";then
+   dnl replace libopts-generated files with distributed backups, if present
+   missing_baks=
+   for i in ${srcdir}/src/*-args.c.bak ${srcdir}/src/*-args.h.bak; do
+-  nam=`echo $i|sed 's/.bak//g'`
++  nam=`echo $i|sed 's/\.bak$//'`


How about:
 nam=`basename $i .bak`



+   if test -f $i;then
+   cp -f $i $nam
+   else
+--
+2.0.1
+
diff --git a/recipes-support/gnutls/gnutls_3.3.27.bb 
b/recipes-support/gnutls/gnutls_3.3.27.bb
new file mode 100644
index 000..c98da34
--- /dev/null
+++ b/recipes-support/gnutls/gnutls_3.3.27.bb
@@ -0,0 +1,23 @@
+require recipes-support/gnutls/gnutls.inc
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
+file://COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"
+
+FILESEXTRAPATHS_prepend = "${COREBASE}/meta/recipes-support/${BPN}/${BPN}:"
+
+SRC_URI += " \
+file://correct_rpl_gettimeofday_signature.patch \
+file://configure.ac-fix-sed-command.patch \
+file://use-pkg-config-to-locate-zlib.patch \
+"
+SRC_URI[md5sum] = "8ee8cebd7f7575b11f232766a21c31d3"
+SRC_URI[sha256sum] = 
"8dfda16c158ef5c134010d51d1a91d02aa5d43b8cb711b1572650a7ffb56b17f"
+
+# This version doesn't support this option added in newer gnutls
+# ERROR: gnutls-3.3.27-r0 do_configure: QA Issue: gnutls: configure was passed 
unrecognised options: --with-idn [unknown-configure-option]
+PACKAGECONFIG[libidn] = ""
+# but it still has the libidn dependency, without this option
+EXTRA_OECONF += "--disable-crywrap"
+
+# This version doesn't support this option added in newer gnutls
+EXTRA_OECONF_remove = "--without-libunistring-prefix"





Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] Install rootfs.tar.bz2 to ${D}/home/root/

[Mike Looijmans]

On 05-04-17 13:21, Maier, Chris wrote:

Hi,



I want to create a deployable SD card image. My board (beaglebone based) boots
from SD card and runs a script which copies the rootfs.tar.bz2 to the flash
memory.

So how can I deploy a copy of the whole rootfs to ${D}/home/root?

A rootfs in the rootfs, does that make sense?


I do it like this:

http://lists.openembedded.org/pipermail/openembedded-core/2017-April/135187.html


The idea is that you make a regular package that contains the tar.bz2 of the 
image you want in flash and put that into the image for the SD card.


You cannot have the same image, since that would recursively include itself, 
but you could make big-image.bb like this:


require small-image.bb
IMAGE_INSTALL += "big-project"




Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] Current situation with gobject introspection? (off-topic)

[Mike Looijmans]

On 28-03-17 10:39, Burton, Ross wrote:


Krogoth (2.1) isn't the latest, that's Morty (2.2) released in October 2016
and next month Pyro (2.3) is being released.


So what happened to the missing two walker bots?

:-)



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] Changing over to systemd (no dhcp)

[Mike Looijmans]

On 20-01-17 14:59, colin.helliw...@ln-systems.com wrote:

Thanks for all the pointers everyone. I’ve now got (in my distro conf):

DISTRO_FEATURES_append = " systemd"

DISTRO_FEATURES_remove = " sysvinit"

VIRTUAL-RUNTIME_init_manager = "systemd"

PREFERRED_PROVIDER_udev = "systemd"

PACKAGECONFIG_append_pn-systemd = " resolved networkd"


Thanks for the tip, I was also wondering why network didn't work with systemd.

Is there a reason why this has been disabled by default? It's strange to have 
a system without network as the default setup.


I would at least have expected network support to be enabled for any machine 
that has some networking features.





Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] Changing over to systemd (no dhcp)

[Mike Looijmans]

On 21-01-17 13:41, Leon Woestenberg wrote:

Hello Mike,

On Fri, Jan 20, 2017 at 3:27 PM, Mike Looijmans <mike.looijm...@topic.nl
<mailto:mike.looijm...@topic.nl>> wrote:

An no one (except one of the systemd folks) has come up with a program
that just waits for the the processes to finish (with a timeout) and only
uses the "-9" double barrel shotgun to finish only the ones that didn't
respond?
(though doing that is rather pointless if the system power is about to be
cut anyway...)

What lesser-brain-dead "one of the systemd folks" solution is that?


Sorry if I wasn't clear. The systemd folk seems to have gotten it right.

The problem with the "sleep" is that 5 seconds is way too long, since most 
processes will finish in mere milliseconds. But 5 seconds is also way too 
short, because if a program needs to spin up a harddisk to write out its final 
state, it'll need about 7 seconds to do so on the average 3.5" disk...




Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] Changing over to systemd (no dhcp)

[Mike Looijmans]

On 23-01-17 08:47, colin.helliw...@ln-systems.com wrote:

Looking at it in more detail, it's perhaps more that not everything is taken up 
by systemd i.e. I have lots of symlinks to /dev/null in etc/systemd/system, 
with the corresponding/original SysV script still in /etc/init.d.  Things like 
banner, sysfs, urandom, dmesg (to name just a few).
Maybe these don't matter but, as I say, it just seems like a bit of 'clutter'

Looking at one which does seem to switch over cleanly - dropbear - I'm puzzled 
how the recipe [dropbear.inc, in poky/meta/recipes-core] appears to install 
both init.d script and .service in its do_install, yet only one or the other 
ultimately shows up in the rootfs..? (Relates to my other question about how to 
determine the init type in do_install)


I suspect that "inherit systemd" is taking care of that.







Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





-Original Message-

From: Leon Woestenberg [mailto:l...@sidebranch.com]
Sent: 21 January 2017 13:09
To: colin.helliw...@ln-systems.com
Cc: Yocto discussion list <yocto@yoctoproject.org>
Subject: Re: [yocto] Changing over to systemd (no dhcp)

Hi Colin,

On Fri, Jan 20, 2017 at 2:59 PM, <colin.helliw...@ln-systems.com> wrote:


DISTRO_FEATURES_remove = " sysvinit"

I suspect there’s also some de-cluttering needed e.g. init.d scripts still 
being installed as well as a .service.


I wouldn't expect these to be installed.  Which ones specifically?

Regards,

Leon.



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

Re: [yocto] Changing over to systemd (no dhcp)

[Mike Looijmans]

On 20-01-17 07:15, Michael Gloff wrote:

Mike,

On Thu, Jan 19, 2017 at 3:18 AM, Mike Looijmans <mike.looijm...@topic.nl
<mailto:mike.looijm...@topic.nl>> wrote:

On 18-01-17 16:10, colin.helliw...@ln-systems.com
<mailto:colin.helliw...@ln-systems.com> wrote:

We have a configuration for our embedded system which is working via
SysV, but
we’re investigating moving over to systemd.

Not sure if this is ‘wise’ – if anyone has technological arguments
for/against
then I’d be interested – but I wanted to investigate it anyway.


Just one. systemd is a bit larger. So it will increase the boot time if
your platform is I/O limited (many embedded systems are).

The good thing I noticed is that it shuts down a lot faster than
initscripts. (I don't understand why I can boot my system in 2 seconds,
but shutdown takes over 5 seconds...)


The 5+ seconds may be from sendsigs on shutdown or reboot:
 echo "Sending all processes the TERM signal..."
 killall5 -15
sleep 5
 echo "Sending all processes the KILL signal..."
 killall5 -9


OMG, indeed, this is utterly braindead!

An no one (except one of the systemd folks) has come up with a program that 
just waits for the the processes to finish (with a timeout) and only uses the 
"-9" double barrel shotgun to finish only the ones that didn't respond?
(though doing that is rather pointless if the system power is about to be cut 
anyway...)




Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] Changing over to systemd (no dhcp)

[Mike Looijmans]

On 18-01-17 16:10, colin.helliw...@ln-systems.com wrote:

We have a configuration for our embedded system which is working via SysV, but
we’re investigating moving over to systemd.

Not sure if this is ‘wise’ – if anyone has technological arguments for/against
then I’d be interested – but I wanted to investigate it anyway.


Just one. systemd is a bit larger. So it will increase the boot time if your 
platform is I/O limited (many embedded systems are).


The good thing I noticed is that it shuts down a lot faster than initscripts. 
(I don't understand why I can boot my system in 2 seconds, but shutdown takes 
over 5 seconds...)



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] Adding to inittab based on image content

[Mike Looijmans]

On 06-01-17 18:17, Rudolf J Streif wrote:

Hi Colin,

The correct way of doing this is a package postinstallation script that is run
by the package manager after the package containing your application is
installed on the target system.

You add to your recipe:

pkg_postinst_${PN}() {
#!/bin/sh
echo "whateveryouneed" >> ${D}/etc/inittab
}


Problems are that if you upgrade the application on target, it'll be 
included twice, and that when you remove the application, the inittab 
entry remains. If inittab itsef gets upgraded, the entry will be gone.





The build system will include this as the post install script into the package
in the correct form for the package manager you are using e.g. RPM, DEB, IPK.

This will work when the build system installs your package into the system
root or when executed on the target.

You can also distinguish the two cases:

pkg_postinst_${PN}() {
#!/bin/sh
if [ x"$D" = "x" ] ; then
# shell commands for target execution
else
# shell commands for build system execution
fi
}

In the case of target execution $D is not set.

Best regards,
Rudi


On Friday, January 6, 2017 1:39:40 PM PST colin.helliw...@ln-systems.com
wrote:

Hi,

I have a custom recipe for an application, and the app also needs an entry
adding to inittab. I'd like to trigger this, obviously, only when the app is
included in the image.

I came across some hints at how to do this -
http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-c
ore/sysvinit/sysvinit-inittab_2.88dsf.bbappend?h=dizzy - but the app isn't
in DISTRO_FEATURES. (Right or wrong.., I include it in the image with a
"CORE_IMAGE_EXTRA_INSTALL +=" in my image recipe).

Any suggestions on how to make this inittab addition conditional?

Thanks








--
Mike Looijmans


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] [meta-raspberrypi][PATCH 1/1] linux-rpi: clean .config in before do_configure step

[Mike Looijmans]

On 16-12-16 17:58, Khem Raj wrote:






Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





On Dec 15, 2016, at 2:05 AM, Piotr Lewicki <piotr.lewi...@elfin.de> wrote:


Signed-off-by: Piotr Lewicki <piotr.lewi...@elfin.de>
---
recipes-kernel/linux/linux-rpi.inc | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/recipes-kernel/linux/linux-rpi.inc 
b/recipes-kernel/linux/linux-rpi.inc
index 95a9530..c665b9f 100644
--- a/recipes-kernel/linux/linux-rpi.inc
+++ b/recipes-kernel/linux/linux-rpi.inc
@@ -34,11 +34,13 @@ kernel_configure_variable() {
 fi
}

-do_configure_prepend() {
+do_rpi_kconfig_clean() {
 # Clean .config
-echo "" > ${B}/.config
+echo -n "" > ${B}/.config
 CONF_SED_SCRIPT=""
+}

+do_configure_prepend() {
 # oabi / eabi support
 kernel_configure_variable AEABI y
 if [ "${ARM_KEEP_OABI}" = "1" ] ; then
@@ -124,8 +126,11 @@ do_configure_prepend() {
 # Keep this the last line
 # Remove all modified configs and add the rest to .config
 sed -e "${CONF_SED_SCRIPT}" < '${WORKDIR}/defconfig' >> '${B}/.config'
+# Clean variable- useful when calling configure step multiple times
+CONF_SED_SCRIPT=""

 yes '' | oe_runmake oldconfig
+
}

# Automatically depend on lzop-native if CONFIG_KERNEL_LZO is enabled
@@ -146,3 +151,5 @@ python () {

 configfile.close()
}
+
+addtask rpi_kconfig_clean before do_configure after do_populate_lic


we should investigate the kernel tooling from OE-Core and use that IMO


See this thread on the OE list for a similar problem:
http://lists.openembedded.org/pipermail/openembedded-core/2016-November/129205.html



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

Re: [yocto] update mechanisms

[Mike Looijmans]

On 09-12-16 16:13, Patrick Ohly wrote:

Hello everyone!

Thanks for contributing directly to the page. It's great to see this
done collaboratively.


Nice informative page.

Only thing lacking is simple, OE-built in upgrade procedures like: "Just run 
'opkg update && opkg upgrade'"




Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] suggestions for version controlling multi-layer reproducible builds?

[Mike Looijmans]

On 12-12-16 16:20, Robert P. J. Day wrote:


  (if there's already a doc section for this somewhere, a pointer to
it would be just ducky.)

  if one is building an image for a releasable, commercial product,
and that image involves pulling in numerous layers, then dumping all
sorts of proprietary apps on top of it, what are the possibilities for
how to version number the released images such that, if a client has
an issue, they can identify precisely the state of components that
went into the system they're working with?


I always make a top-level git repository for the project. It contains all the 
"meta" layers as submodules (sometimes nested).


That way, the version of the top layer is the version of the whole product and 
can be reproduced any time.



  in addition to all of the layers involved in the build, one has to
take into account that, when critical bugs are identified, an updated
RPM might be sent out and applied, whereupon that system's version
number is no longer perfectly accurate. in the end, the state of
someone's running system will be determined by a possibly huge
combination of selected packages, preferred package versions, build
config options, additional user space apps, hot fixes that have been
applied and so on.


The only way to version such a system is to actually dump the whole package 
version table (e.g. "opkg list-installed"). You could compare the table to the 
initially installed one and only send the difference, as an optimization.



  what sort of meaningful "version number" can be applied to something
like that? i'm sure at least a few other people have to be doing
something like that, so i'm open to suggestions.


Version "numbers" are for marketing purposes only and have no useful meaning 
in version management. The git hash is the "technical" version number. Create 
a table somewhere to map the commercial version number to a git hash. The 
simplest implementation is to "tag" the version numbers in the top-level 
repository.




Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] How to handle meta-intel/openembedded repos with multiple developers

[Mike Looijmans]

Git submodules work fine for this.

In general, for each project I create a top-level repo that has the OE repos 
as submodule. The project repo also contains the project-specific recipes.



On 07-11-16 20:31, Chris Z. wrote:

Hi,

How you store your project configuration ? How you prepare workspace (download
each layer separately)?
Basic stuff, SW release should be reproducible (in easy way). Store somewhere
used hash of each piece or use tags. Non company assets should be already
somehow tagged or you use HEAD or master/-next ?

Br,
Chris Z

On Thu, Oct 27, 2016 at 8:22 AM, Edward Wingate <edwinga...@gmail.com
<mailto:edwinga...@gmail.com>> wrote:

On Thu, Mar 3, 2016 at 8:27 AM, Mark Hatle <mark.ha...@windriver.com
<mailto:mark.ha...@windriver.com>> wrote:
>  At some point during product development a lead/architect needs to make 
the
> decision to 'freeze' development and at that point everything is
tagged/branched
> and only backports are used from them on.  (If the number of backports
gets too
> large, you MIGHT decide to selectively rebase.)

I'm currently trying to figure out with how to control external layers
in my Yocto build and found this thread.  I'm a little unclear on how
to track a release to the version used on non-company layers.  Say I'm
using poky, meta-openembedded, meta-xilinx and then my own layer,
meta-me. When I freeze development and do a release, I can tag
meta-me, but because I also treat non-company assets as RO, I
shouldn't tag poky, meta-openembedded nor meta-xilinx (or should I? Is
this where I use git's lightweight tagging as opposed to annotated
tags?) When "everything is tagged/branched", does that somehow include
tagging the non-company assets?  Thanks for any help.

Ed
--



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





___

yocto mailing list
yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto
<https://lists.yoctoproject.org/listinfo/yocto>






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

Re: [yocto] [sstate-cache] using sstate-cache in parallel builds

[Mike Looijmans]

On 02-11-16 15:17, Burton, Ross wrote:


On 2 November 2016 at 13:36, Chris Z. <winotu.em...@gmail.com
<mailto:winotu.em...@gmail.com>> wrote:

Is it secure to use in parallel sstate-cache for building images for
different target machines ?

Short answer: yes.

The hashes will be different so there's no risk of conflicting files for the
target, so it's only native recipes that may conflict.  The worst case
situation here in two parallel builds is that they'll both build the same
recipe and put it into sstate, there isn't any risk of corruption.


Could I take this one step further:

Would it be safe to store the sstate-cache for a bunch of builds into a single 
directory, with builds running in parallel contributing to that?


Each build would be using a different set of layers, different machines, and 
building different images, but there would be a lot of common things (usually 
they all refer to the same OE branches).


We use a build server to share out sstate-cache for various builds, but as 
projects are getting added, it's getting more complicated with projects using 
the sstate-caches of other projects. It would make things quite simple if all 
builds just pointed to the same sstate-cache directory, so they could share 
whatever they want.


Would that work? I'd think so, but never dared to actually make it so...


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] Big endian ARM machine with NEON wanted

[Mike Looijmans]

On 13-10-16 19:20, Andreas Müller wrote:


Does anybody know a big endian and common machine supporting NEON? I
would need one for testing my port of portaudio.



Most ARM systems can run in both big-endian and little-endian modes. Somewhere 
early during boot this choice is being made.


Having said that, since big-endian machines are getting rare, there's very 
little support for big-endian ARM systems. Most (if not all) boards can run 
big-endian, but software support is usually lacking, in particular in the 
bootloader parts where this matters.


If it's just for testing some software, maybe you can use a QEMU machine?


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] Automating imaging building and testing, what aproach to use!?

[Mike Looijmans]

On 30-08-16 22:18, Daniel. wrote:> Hey everybody!>> While writing software we're used to delivery packages, libraries and> stacks. There are out there a lot of continuos integration solutions> to automaticaly build and test these kinds of software. But when> dealing to images the thing is more tricky.>> I can't run the tests at the same machine that build the image because> crosscompilation take place on 99% of the cases. What is aproach that> you guys are using to automate and increase the quality of your> images?>> Automating the build is the easy part my concert is about automating> the runtime tests that need the target board to run. In my case I> depend on hardware to fully test the image features. Is there any> reliable way to automate image installation and boot!?It helps a lot if you take testing into account when designing the hardware.We have a bunch of hardware targets in a corner. The board can be powered on/off forcibly by controlling/monitoring the RTS/DTR/CTS/DSR lines of the serial debug port (FTDI chip).A python script on a PC boots a board, puts it into USB "DFU" mode by "typing" commands into u-boot, and then sends an image over USB into RAM. The board then configures its USB OTG port as network, and the Python script connects to the board via SSH (paramiko) over that USB connection when it sees the "network" come up. Using the SSH connection, it can run whatever tests it needs doing (send data and even executables, run shell commands, and get reliable feedback on process completion).One test PC can control multiple boards (each board needs two USB connectors in this setup).I'd also be interested to know what other projects are doing.
 
Kind regards,
 
Mike Looijmans
System Expert
 





  
  

  TOPIC
  Products

   

   
  

  Materiaalweg
  4

   

   
  

  5681
  RJ Best

  T:

  +31 (0) 499 33
  69 69
  

  Postbus
  440

  E:

  mike.looijm...@topicproducts.com
  

  5680 AK
  Best

  W:

  www.topicproducts.com
  
The Netherlands



 Please consider the environment before printing this
e-mailTopic zoekt gedreven (embedded) software specialisten!



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

Re: [yocto] How to create a directory for an SD-Card mount?

[Mike Looijmans]

On many embedded systems, /media/ is volatile. So you probably need to create an entry for a volatile dir.Better is to create/delete the directory in the mount script. That also avoids races, since creating a directory is an atomic operation. And it allos you to mount multiple devices.I'm actually surprised that this isn't already in place. Maybe you're missing some obscure udev package in your image?On 06-07-16 20:09, Daniel. wrote:> install -d ${D}/media/sd1> ???>> 2016-07-06 11:44 GMT-03:00  <s.jar...@esa-grimma.de>:>> Hej>>>> I managed to create and install a rule that should mount a sd card to>> "/media/sd1".  To finish it, I need to create the directory "sd1" in media.>> My recipe for the rule looks like:>> ###>> SUMMARY = "the udev rules for the board">> SECTION = "rules">> LICENSE = "CLOSED">>>> SRC_URI = "file://50-mmc.rules \>>  ">> S = "${WORKDIR}">>>> do_install () {>>  install -d ${D}${sysconfdir}/udev/rules.d>>  install -m 0644 ${WORKDIR}/50-mmc.rules>> ${D}${sysconfdir}/udev/rules.d/>> }>> ###>> How to create a dir in do_install which goes to the package?>>>> By the way:>> I was also appending fstab after this article>>>> https://communities.intel.com/thread/49251>>>> Is there an better way to uncomment/modify that one line in fstab?>>>> Regards!>>>> Stefan Jaritz>>>> >> ESA Elektroschaltanlagen Grimma GmbH>> Broner Ring 30>> 04668 Grimma>> Telefon: +49 3437 9211 176>> Telefax: +49 3437 9211 26>> E-Mail: s.jar...@esa-grimma.de>> Internet: www.esa-grimma.de>>>>>> Geschäftsführer:>> Dipl.-Ing. Jörg Gaitzsch>> Jörg Reinker>>>> Sitz der Gesellschaft: Grimma>> Ust.-ID: DE 141784437>> Amtsgericht: Leipzig, HRB 5159>> Steuernummer: 238/108/00755>>>>>> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte>> Informationen.>> Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich>> erhalten>> haben, informieren Sie bitte sofort den Absender und löschen Sie diese>> Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser>> Mail>> ist nicht gestattet.>>>> This e-mail may contain confidential and/or privileged information. If you>> are>> not the intended recipient (or have received this e-mail in error) please>> notify the sender immediately and destroy this e-mail. Any unauthorized>> copying, disclosure or distribution of the material in this e-mail is>> strictly>> forbidden.>> -->> 
 
Kind regards,
 
Mike Looijmans
System Expert
 





  
  

  TOPIC 
  Products

   

   
  

  Materiaalweg 
4

   

   
  

  5681 
  RJ Best

  T:

  +31 (0) 499 33 69 
  69
  

  Postbus 440

  E:

  mike.looijm...@topicproducts.com
  

  5680 AK 
Best

  W:

  www.topicproducts.com
  
The Netherlands



 Please consider the 
environment before printing this e-mailTopic zoekt gedreven (embedded) software specialisten!
___>> yocto mailing list>> yocto@yoctoproject.org>> https://lists.yoctoproject.org/listinfo/yocto>>>>>


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

Re: [yocto] Mounting USB drives on a "read-only-rootfs" based system

[Mike Looijmans]

On 14-06-16 15:48, Jeffrey D Boyer wrote:

Sorry, /media is not a symlink and there is no /run/media link or directory 
present on my running system.  When I insert an SD card, for example, I get a 
bit of text on the debug serial port that a card has been detected, but I don't 
see a mount point anywhere after that.

root@mySys:/# mmc1: new high speed SDHC card at address 1234
mmcblk1: mmc1:1234 SA04G 3.63 GiB
 mmcblk1: p1

It should be noted that if I exclude the " read-only-rootfs" option in the bb 
script, a normal read/write kernel image is produced and the action of inserting an SD 
card under those conditions will automatically produce a mount point at /media/mmcblk1p1


Apparently your distro or image or whatever is lacking some directories. The 
/run/media should have been created automagically.


Are you using udev or mdev for hotplug?

For mdev, I implemented the automounting using /run/media and that should also 
work on read-only-rootfs systems. So I can probably figure out what's wrong 
with your config.


For udev, I don't have a clue, sorry...



FYI, I'm running 3.14 kernel.  Is this a job for aufs?  If so, how would I go 
about configuring it?


No, it's not related to autofs or aufs or whatever. It's plain simple udev or 
mdev.




Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] Mounting USB drives on a "read-only-rootfs" based system

[Mike Looijmans]

Yup, even mdev based images do that with current OE.

I'd expect "/media" to symlink to "run/media" on most devices (regardless 
whether the rootfs is read-only or not). Check if that's the case on your system.


On 14-06-16 00:01, Christopher Larson wrote:

Afaik usb storage is already automounted by udev on /run/media/, so there's no
need to use /media for that purpose.

On Mon, Jun 13, 2016 at 2:22 PM, Jeffrey D Boyer <jeffrey.d.bo...@jci.com
<mailto:jeffrey.d.bo...@jci.com>> wrote:

Hello,

__ __

New to the list here, so I’m sorry if this question has been asked before,
but I couldn’t find a direct answer to it. 

__ __

I have a yocto image that was built using the following bb script line:
IMAGE_FEATURES += " read-only-rootfs". 

__ __

As this image eventually resides on a static flash device, it must be
read-only.  However, the system hardware supports removable media (SD card
and USB drives), and I’d like to be able to mount and write to those
removable drives / partitions for data logging purposes.  What needs to be
done in order to make the /media directory auto-mountable when a
“read-only” image is specified by the build script?

__ __

Thanks.

    __ __


    --



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





___

yocto mailing list
yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto




--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics




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

Re: [yocto] What's this

[Mike Looijmans]

On 08-06-16 00:20, Richard Purdie wrote:

On Wed, 2016-06-08 at 09:24 +1200, Paul Eggleton wrote:

On Tue, 07 Jun 2016 17:20:12 Burton, Ross wrote:

On 7 June 2016 at 17:02, Burton, Ross <ross.bur...@intel.com>
wrote:

It means the hash calculated my the bitbake master was different
to the
hash calculated when the worker started up.  This usually means
that
you're
using something like ${TIME} in the recipe but not marking it
appropriatly
so the cache ignores it.  Do you have a base-files bbappend that
writes a
timestamp?


The always wise Joshua reminds me that if your DISTRO_VERSION
contains
${DATETIME} then this happens.  If you're doing this then you'll
want to
set [vardepsexclude] on DISTRO_VERSION to stop the DATETIME from
getting
into the cache (or not put the current date/time into the distro
version).


I think we need to handle this situation better - if it's really
worth
producing an error about then it's worth producing an error message
that
people can actually understand, particularly as it's recently added
validation.


It was silently running into problems due to this all along but not
reporting it. Its now reporting it which is better than silently things
behaving strangely.

Its very hard for bitbake to know why the hashes differ, it only knows
the values afterwards and hence that they've changed, the information
about how that hash was constructed is not present in any of bitbake's
caches. That implies to have better messages we need to write out more
data.

I did add a patch to make bitbake write out data to allow
reconstruction of basehash (which is part of taskhash). Sadly the
parsing performance was diabolical (10 times slower). I think that
could perhaps be improved if the files don't require an atomic move
during creation but I haven't had time to look further at it.

So whilst I do agree, what is the price people are willing to pay to
have those better messages?


I have a build machine that every so often runs into "basehash mismatch" 
problems (but never when you want it to, such as now), so getting some 
information on what might cause it would be "priceless". I'd happily let the 
machine run for 10 days straight if at the end I get a message that I can work 
with.


Which implies that any performance hit is acceptable, if there's a switch to 
enable and disable that extra diagnostic. Oh dear, just what we need, yet 
another switch...


M.



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] Is There a Package Limit to use of Smart / RPM?

[Mike Looijmans]

We've seen similar effects with IPK packages and opkg, but the problem then 
isn't so much the package manager, but it's just that some packages don't 
upgrade properly when bunched together with some others. For example, two 
packages A and B which individually upgrade just fine, but if you try to 
upgrade them both, something in their pre/post-install/remove actions messes 
things up and causes one or both of them to fail.


Also, things like upgrading network components while using ssh to start the 
upgrade, or upgrading parts of the package manager can also cause strange 
upgrade problems.


I doubt there's some magic "maximum number of packages" in any package manager.


On 28-05-16 21:16, Darcy Watkins wrote:

Hi,

In my project, we have exceeded 700 packages and have run into numerous issues
using smart with rpm handling large transactions on the target (e.g. update
from a non-PR service build to a PR-service build resulting in all RPMs being
updated, though most are just version/release 'bumped' by the PR service).

Before I dig too deep, I figured I would see if anyone recognizes this
signature as a known issue.

1.  Are there any hard coded limits to number of packages that can be handled
in a smart/rpm transaction?  (Particularly around 700)?

2.  Are there known issues related to when 'smart' updates itself and/or 'rpm'?

Daisy branch

Layerscape (ARM) architecture

Kernel 3.19 (yocto-linux + BSP patches)

Installing on ext3 rootfs

Building on CentOS7

All appeared to work fine until recently when a bunch of added kernel modules
and other firmware packages were added, which makes me wonder about a magic
limit of 700.

Thanks in advance for your insights.



Regards,

Darcy

Darcy Watkins :: Staff Engineer, Firmware

SIERRA WIRELESS
Direct +1 604 233 7989 :: Fax +1 604 231 1109 :: Main +1 604 231 1100
13811 Wireless Way :: Richmond, BC Canada V6V 3A4
[M1]
dwatk...@sierrawireless.com :: www.sierrawireless.com ::
www.inmotiontechnology.com







Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] How can I set a recipe that its binaries become available at cross-compile time?

[Mike Looijmans]

On 23-05-16 15:37, s.jar...@esa-grimma.de wrote:

Hej

I a cmake based application, some code generation via dbusxx-xml2cpp. It is
provided by the dbuss-c++ lib. A recipe can be found under:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi/tree/meta-ivi-demo/recipes-extended/dbus-c++?id=b90c2a20744e1e82b2169a88e68d7677bec907b6


It working and it's compiling & linking, "dbusxx-xml2cpp" is included at the
native build.

How can I set a recipe that its binaries become available at cross-compile time?


Simply adding the following to a recipe should make the command available in 
the PATH:


DEPENDS += "dbus-c++-native"

(though your moving of the binary into a "dbg" package might disturb that. I'd 
create a "utils" package for it)



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] How to enforce installation of image specific config file/package

[Mike Looijmans]

On 01-04-16 11:34, Isak Lichtenstein wrote:

Hi,

I've got a package "A" that has a runtime dependency to a configuration file. This 
configuration file is image specific. For each image I've got a specific configuration package 
"config-image-X" that installs this needed configuration file and I build multiple image 
in the same build directory.
How can I enforce that each image containing package "A" also installs an image 
specific configuration package?


If the "config" package is image-specific, you could just invert the 
dependency. Make the config package RDEPEND on "A". Images that install the 
config (which they have to do anyway according to your description) will then 
automatically install "A" which at least accomplishes that you don't need to 
specify both.


I've been in the same position, and it just isn't possible to do what you want.




Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] [PATCH][opkg-utils] opkg-build: Exit when fail to list files.

[Mike Looijmans]

On 31-03-16 23:27, Aníbal Limón wrote:

We have an issue when ls segfaults in some cases [1] so it's
better to detect the failure at this level instead of continue
the build process.

[YOCTO #8926]

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=8926#c0

Signed-off-by: Aníbal Limón <anibal.li...@linux.intel.com>
---
  opkg-build | 8 
  1 file changed, 8 insertions(+)

diff --git a/opkg-build b/opkg-build
index 98008b6..a9ccad2 100755
--- a/opkg-build
+++ b/opkg-build
@@ -53,6 +53,10 @@ pkg_appears_sane() {
echo "*** Warning: The following files have names ending in '~'.
  You probably want to remove them: " >&2
ls -ld $tilde_files
+   if [ $? -ne 0 ]; then


Instead of using $? you could just use the result of "ls" directly, i.e.:

if ! ls -ld $tilde_files; then



+   echo "*** Error: Fail to list files have names ending in 
'~'."
+   exit 1
+   fi
echo >&2
else
echo "*** Removing the following files: $tilde_files"
@@ -66,6 +70,10 @@ You probably want to remove them: " >&2
echo "*** Warning: The following files have a UID greater than 
99.
  You probably want to chown these to a system user: " >&2
ls -ld $large_uid_files
+   if [ $? -ne 0 ]; then
+   echo "*** Error: Fail to list files have a UID greater than 
99."
+       exit 1
+   fi
echo >&2
fi






Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] FW: root password in a core-image-base without "debug-tweaks" ?

[Mike Looijmans]

On 12-10-15 23:39, Thanassis Silis wrote:


I bitbaked a core-image-base without "debug-tweaks" , and now i am greeted on
ttymxc1 with a login , but it also asks for password.
empty password is not accepted.
/etc/shadow states "root::..." so the root password is supposedly empty. but I
cannot login.


Yep, turning it on makes the box too vulnerable and leaving it out makes the 
box inaccessible.


Here's a simple solution to allow you to login but without crippling SSH:

https://github.com/OpenPLi/openpli-oe-core/blob/master-next/meta-openpli/recipes-openpli/images/openpli-image.bb#L45



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] tmp on NFS

[Mike Looijmans]

I can think of various things that would go wrong with tmp on NFS. One of the 
most obvious example would be to try and change the network configuration 
while running, and needing some temporary file to manage that.\


I think the expectation is that /tmp should be accessible at all times, and 
that it's local and (at least somewhat) volatile.


I tend to mount /tmp/ in RAM on all systems. Even my desktop. Not having to do 
wait for a device IO queue when performing actions in /tmp/ can greatly 
improve the responsiveness of the system.


If your application's /tmp/ storage requirements are such that they don't fit 
in RAM, I don't think /tmp/ is the place where they should be stored.




On 07-10-15 03:37, Luke (Lucas) Starrett wrote:

Hi,

Can anybody give a brief history of time on why using an NFS drive for tmp is
necessarily a bad thing, and why we have a sanity check for it?  We’re doing
this without any obvious side effects.

I’m aware of the checks added by changes like this:

patchwork.openembedded.org/patch/61107/

However, I don’t see the reasoning/background documented as to exactly what is
actually broken when putting tmp on NFS.  Is it time skew, problems with
concurrent file access, something else?

Thanks,

Luke







Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] [systemd-devel] How to automount

[Mike Looijmans]

On 23-09-15 12:09, Daniel. wrote:

I think that sync just flushes data to disk and umount clears the dirty bit.
There is no sync.vfat that I know.

Em 23/09/2015 05:31, "Paul D. DeRocco" <pdero...@ix.netcom.com
<mailto:pdero...@ix.netcom.com>> escreveu:

 > From: Mike Looijmans
 >
 > This only serves to remove a mounted directory after
 > "yanking" the device. It
 > doesn't really do anything useful though, you'll still get corrupted
 > filesystems, because Linux is way too lazy in writing out dirty data.
 >
 > Proper solution would be to have the system mount a removable
 > device as
 > read-only, and promote it to r/w once someone tries to write
 > to it. And then
 > after a timeout, it should go back to readonly.
 >
 > Supposedly, "autofs" can accomplish this, but I've never met
 > anyone who got
 > that to actually work.

In my system, the removable drive is used only for backing up or restoring
various data files in response to user commands. If I do a sync after each
such command, shouldn't that be enough to guarantee the file system
doesn't get corrupted when the drive is removed? Will it also ensure the
dirty flag is clear, or does that get set anyway?


Nope, "sync" does not clear the flag. Only umount does that (the same for any 
filesystem, this is not fat specific). Actually, sync is no guarantee that 
it's actually safe to yank the stick, data could still reside in buffers 
somewhere. Only umount (sort of) guarantees that.


The only thing that would really work is to unmount the device.

You could try mounting it read-only by default, and remount it before (rw) and 
after (ro) writing to it. Since it's under your control, it's possible to 'get 
it right' here and always have clean media.




Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] [systemd-devel] How to automount

[Mike Looijmans]

On 24-09-15 08:04, Johannes Pointner wrote:

I'm using autofs to do the trick. It's working fine for me.

To get the umount working I use a timeout of 2 seconds, which seems to
be ok so far.



I am very very interested in how you got that to actually work. Please show us 
your configuration files and/or recipes and enlighten us!


So far, all I ever got autofs to accomplish was giving me a major headache.


Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] [systemd-devel] How to automount

[Mike Looijmans]

On 22-09-15 20:33, Fred Ollinger wrote:
...

SUBSYSTEM=="block", ACTION=="remove" RUN+="/etc/udev/scripts/mount.sh"


This only serves to remove a mounted directory after "yanking" the device. It 
doesn't really do anything useful though, you'll still get corrupted 
filesystems, because Linux is way too lazy in writing out dirty data.


Proper solution would be to have the system mount a removable device as 
read-only, and promote it to r/w once someone tries to write to it. And then 
after a timeout, it should go back to readonly.


Supposedly, "autofs" can accomplish this, but I've never met anyone who got 
that to actually work.




Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] Dumping sysvinit

[Mike Looijmans]

On 21-09-15 12:48, Andy Pont wrote:

Hi Mike,


Back to plan A then, trying to figure out how to get Busybox init and

mdev as the defaults in the image.

Create your own distro, here's an example that uses mdev:

https://github.com/topic-embedded-products/meta-
topic/blob/master/conf/distro/tiny.conf


Thanks for pointing me in the direction of this.  I have cloned it and used
it as the basis of my distro, tweaked it a bit and it is starting to behave
how I want.  There are a few anomalies that I haven't managed to figure out
yet...

Despite having VIRTUAL-RUNTIME_initscripts = "" the root file system still
contains /etc/rcX.d directories

On other embedded Linux projects that boot using Busybox init the
/etc/init.d directory contained the individual service start and kill files
e.g. S50-dropbear and K50-dropbear but I can't see how to make Yocto
populate this directory in that form.

Thoughts and guidance from anyone would be much appreciated!


I didn't go as far as attempting to get rid of initscripts as well. I just 
patched the initscripts to remove the things I did not want in a 
do_install_append.


Many recipes will create /etc/rcX.d entries to start/stop things.



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] Dumping sysvinit

[Mike Looijmans]

On 16-09-15 16:13, Andy Pont wrote:

Ross wrote...


Now to figure out why the tar.gz file for the root file system has grown
from just under 3MiB to almost 15MiB!


That would be systemd... it pulls in a lot of libraries that are fairly common
on complex systems but on a minimal image less so.


Back to plan A then, trying to figure out how to get Busybox init and mdev as 
the defaults in the image.


Create your own distro, here's an example that uses mdev:

https://github.com/topic-embedded-products/meta-topic/blob/master/conf/distro/tiny.conf


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

Re: [yocto] I hate busybox!

[Mike Looijmans]

On 16-09-15 18:43, Paul D. DeRocco wrote:

From: Mike Looijmans

"Embedded" in my world is not about RAM or disk size. It's about
building a device that has a set task in life, and nothing is as
important as that one task. Whether that's running on an i7
or an M3 is irrelevant.

For a system to acquire and process sensor data, record your
favorite TV
shows, or guide a missile, there's no need for a full fledged
bash shell
interpreter. It just needs a bit of plumbing to get the
application up
and running, and that's about it.

Busybox is for systems like that. For these systems, anything more is
overkill, and will waste resources and increase the boot time.


If you've got a 1GB eSSD drive, because that's the smallest you can buy,
having a 382MB image rather than a 346MB image isn't a waste of anything.


To me it looks like a waste of 36 MB that could have been used for storing 
useful data.


For many projects, 36MB is more than I have for the whole root filesystem. 
Usually I get between 8 and 32 MB for the whole system (bootloader, kernel, 
rootfs and user data storage).



How much boot time increase do you think you'll get from full-featured
command line tools? I'd be surprised if it was noticeable to anyone.


My current boot time is about 4 seconds. The SD memory on this board reads at 
roughly 20MB/s, so each MB that I need to read at boot will cost me 50ms 
extra. That is most certainly measurable. The NAND flash reads at 10MB/s, so 
that'll be 100ms per megabyte.



As I said before, you and I live in different worlds. From where I'm standing, 
your system is the exception, not the rule.

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

Re: [yocto] I hate busybox!

[Mike Looijmans]

On 16-09-15 03:13, Khem Raj wrote:

On Sep 15, 2015, at 7:47 AM, Trevor Woerner  wrote:
On 09/15/15 04:26, Paul D. DeRocco wrote:

My embedded system has enough room in it for full-featured command line
tools,...
"Embedded" in my world is not about RAM or disk size. It's about 
building a device that has a set task in life, and nothing is as 
important as that one task. Whether that's running on an i7 or an M3 is 
irrelevant.


For a system to acquire and process sensor data, record your favorite TV 
shows, or guide a missile, there's no need for a full fledged bash shell 
interpreter. It just needs a bit of plumbing to get the application up 
and running, and that's about it.


Busybox is for systems like that. For these systems, anything more is 
overkill, and will waste resources and increase the boot time.



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

Re: [yocto] How to disable OVERRIDES temperally

[Mike Looijmans]

On 27-08-15 13:40, Qiang Yu wrote:

Hi all,

I want to load kernel module ci_hdrc_imx at boot time and add a conf file in
/etc/modprobe.d. I find it can be done by add
module_conf_ci_hdrc_imx = my configure

But the suffix imx is in OVERRIDES, so I get
module_conf_ci_hdrc = my configure

How to disable the OVERRIDES temperally here? Or may be there is another
way?


This might work (untested):

MY_HDRC_MODULE_NAME = conf_ci_hdrc
module_${MY_HDRC_MODULE_NAME} = my configure




Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] Deploying 2 machines, u-boot does not include with both.

[Mike Looijmans]

On 16-08-15 09:39, Khem Raj wrote:






Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





On Jun 24, 2015, at 1:53 AM, John Ernberg john.ernb...@actia.se wrote:


Hi

This is a weird one that I have been researching for a while trying to
figure out how this can happen.
We recently had to extend our targets with another machine, they have
the same core CPU architecture, but we provide different configurations
of the kernel for them. Along with some IMAGE_INSTALL changes.

Since very little needs to be rebuilt, and the only thing needed to
change target machine is to edit the MACHINE variable, we chose to build
the images using the same build directory.

This means we set the MACHINE variable to machine_A. run bitbake
[machine_A_image], change the MACHINE variable to machine_B, and then
run bitbake [machine_B_image].

Here is when the weird happens. After machine_A has built, we can find
everything we expect to find in the machine_A image deploy directory.
When we change the MACHINE variable and build machine_B, we find that
the u-boot image from the machine_A directory has disappeared.
Depending on build machine it has moved into the machine_B directory, in
addition to u-boot image for machine_B being present in this directory,
OR it has just been removed.
Changing back to building machine_A, the u-boot(s) are removed from the
machine_B directory, and the machine_A u-boot will show up in the
machine_A directo

What could be at play here to cause such a strange behaviour? How can I
debug such a behaviour? I could not find anything on Google regarding
this, nor anything in the logs generated by bitbake.



u-boot is machine specific package so in theory, it should have rebuilt for 
each of your target machines
and deploy images directory is also per machine so there should be no conflicts 
at all, unless you modify
the u-boot recipes such that they are made to be SOC family specific or some 
other voodoo, share your configurations
and recipes to get clear picture and may be something can come out.



This happens to any recipe that is built for multiple machines, e.g. the 
kernel as well if it is shared between machines. Somewhere in the early tasks, 
the recipe just blatantly removes the last build, and then starts running 
anew, ignoring that the output of that build was not located in the current 
machine's path. I think it will happen to anything that is deployed but is not 
specific to one machine. It will even happen to a rootfs if you share that 
between machines.


The only 'solution' I found for this problem is to copy the resulting binaries 
to yet another location after building them. Then bitbake can't reach them.


The proper thing to do here would be to have ARCH specific deploy paths 
instead of MACHINE specific. Some symlinks in the MACHINE path would take care 
of backward compatibility.


I had a discussion about this problem on the oe-core list about a year ago 
when I bumped into the same problem you describe here.

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

Re: [yocto] Selecting different kernel inside an image recipe

[Mike Looijmans]

There are several solutions:

- Pick one kernel as the master one. Create recipes for alternative kernels 
as required, but blank the (R)PROVIDES so that they do not provide a kernel 
and bitbake will treat them as yet another package to build. In the scripts 
that you use to deploy the images, pick the kernel that you want.


- Create a new MACHINE for each alternative.

- Set up multiple build environments, share the sstate-cache and similar 
directories. Each environment can then pick its own kernel etc.



On 04-08-15 06:15, Klaus Knopper wrote:

Hello Bruce  list,

I need to come back to the topic after quite some failed attempts to
solve the problem of switching kernel configurations specific to an
image recipe.

On Wed, Jul 08, 2015 at 01:30:54PM -0400, Bruce Ashfield wrote:

On 2015-07-08 12:36 PM, Klaus Knopper wrote:

Hello Leonardo,

On Wed, Jul 08, 2015 at 10:40:10AM -0500, Leonardo Sandoval wrote:

On 07/08/2015 09:50 AM, Klaus Knopper wrote:

Hello list,

I'm trying to build variantions/brands of an image that only differ in
kernel configuration and kernel modules included, but everything else stays
the same, for the exact same board, as in the main image.

Setting PREFERRED_PROVIDER_virtual/kernel = different_kernel
right inside in the new image recipe does not have any effect, as that
variable seems to be evaluated exclusively in the local.conf machine
file, which is read by all recipes.


This variable is commonly used inside configuration metadata (machine or
distro conf files). You may try it there.


Please help me to understand your answer: You are saying that I do have
to change the machine or distro config used for ALL recipes, to be able
to use a different kernel configuration in ONE recipe, right?

I was really trying to avoid that. :-(

So it is really not possible to just select a different kernel config
within a normal recipe without changing the global configuration?


You really want a different kernel recipe to provide that different
kernel configuration.  Which looks to be what you are describing, and
you just want to switch the provider (again, what you are saying).


Yes, and I had indeed already added a new kernel recipe, which builds
the desired kernel as uImage when calling bitbake kernel-recipename
directly, but it's ignored by the image recipes. All of them use only
the kernel that's defined in build/conf/local.conf as
PREFERRED_PROVIDER_virtual/kernel . Redefining the variable in the image
recipes has no effect.


Changing the included kernel via that different kernel recipe/package
name, and setting it via the preferred provider is the same as any
bitbake variable.


I thought so, but apparently I'mmissing something. It looks like
PREFERRED_PROVIDER_virtual/kernel only works in local.conf, i.e. I need
to fork the project or change the local.conf file each time I want to
use a different kernel. Is this a known or desired behavior?


So you should be able to set it in any .conf file, and then have what
you want.


So, can you confirm that it is not possible to set
PREFERRED_PROVIDER_virtual/kernel inside an image recipe?


I've used layers with layer.conf files, and similar mechanisms
to do what you are trying in the past .. but the longer serving oe/bitbake
folks may have a better example to point at.


If there are examples for a more convenient way to switch kernels in a
recipe rather than inside a .conf file, please point me to the right
direction.

Regards
-Klaus





Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] Read-only file system with persistent storage

[Mike Looijmans]

On 16-07-15 13:36, Gary Thomas wrote:

I'd like to set up a system with a read-only root file system
along with some persistent read-write storage.  What are the
[best] options in Poky/Yocto for this?  Is there any support
for some type of overlay file system?

Thanks for any ideas/pointers


Depends. NOR or NAND flash?

with NOR, you can store a squashfs rootfs into it, and then use another 
portion with jffs2 or ubifs for r/w capability. If you want to be able to 
change 'everything', you can use an overlay fs, this requires some fiddling 
with pivot_root and friends.


with NAND, you'd have to use a fault-tolerant filesystem to store the rootfs. 
Dunno if it's possible to store a squashfs as a volume into ubi. The rest is 
similar to NOR.




Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] armv7 firmware recipe in armv8 distro

[Mike Looijmans]

On 27-05-15 21:19, Joel (Xi Zhou) Zhou wrote:

Hi all,

We have a Yocto BSP based on arm64/aarch64 machine.

On top of this, I need to create a firmware recipe, which need armv7
cross-compiler.

So question is, how to support multiple toolchain in Yocto?


Yocto/OE doesn't support multiple machines in a single build.

You'll have to create a separate yocto build (can use the same environment 
though) by setting MACHINE to your armv7 firmware system and then placing the 
output somewhere (deploy task). Then make a recipe for the arm64 machine 
that picks up this output and packs it for deployment on target, like other 
firmware blobs.



I think eventually we'll see composite machine support in OE, I guess, but 
for now, I have no clue as to how this would work, otherwise I'd have 
submitted a patch implementing it already.

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

Re: [yocto] creating images which include actively developed applications

[Mike Looijmans]

On 22-04-15 19:58, Paul Eggleton wrote:

Hi Brian,

On Wednesday 22 April 2015 15:32:06 Brian Karcz wrote:

 ..
Is there a way to create a recipe to build actively developed code located
in an external source directory? Basically skip the fetch and unpack steps
and always execute the compile and populate steps each time and image is
built?


Indeed there is:

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#building-software-from-an-external-source


Man, I've been working with OE for years, and this is the first time I ever 
saw this.


You should create a link to this page using ten feet neon tubes. Seriously. 
People have been asking me this question over and over, and all I had to offer 
was some crappy scripts to invalidate and rebuild a package.


Kind regards,
Mike.



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [yocto] Yocto Kernel Module Workflow Question

[Mike Looijmans]

On 15-01-15 22:51, Glenn Schmottlach wrote:

I am developing a codec kernel driver/module for the BeagleBone Black
and have a question about the recommended work-flow for developing
this module in the context of the Yocto/poky environment. Currently
I'm working with the Daisy release using the meta-ti layer and the
linux-ti-staging_3.14 kernel sources.

The codec driver, at this point, is just an very minimal
implementation. It follows closely the instructions described here:

http://processors.wiki.ti.com/index.php/Sitara_Linux_SDK_Audio_DAC_Example

The work involves a dummy (platform independent) ALSA driver for the
DAC and then code modifications to the ALSA machine layer driver
(sound/soc/davinci/davinci-evm) and the BeagleBone Black device tree
to knit all of these pieces together.

There seems to be two approaches for developing the codec driver. The
first approach is to build the codec driver externally from the kernel
sources (e.g. as described in working with out-of-tree modules in
the Yocto Kernel Development Guide). With this model I can represent
the codec driver as a separate Yocto/Bitbake recipe and simply include
the resulting package in my target image.

Unfortunately, the codec driver also requires changes to the kernel
sources in the ALSA machine layer driver and device tree. My approach
here is the create a linux-ti-staging_3.14.bbappend file that contains
a series of patches to the kernel for the machine layer driver and
device tree. In this scenario, the kernel sources do *not* explicitly
know about this new codec since there are no changes to the
sound/soc/codec Makefile and associated Kconfig's that describe the
dependencies of the codec driver. This means of course that menuconfig
won't show the codec as a build-able option. So the ALSA machine
driver (davinci-evm) knows the name of the codec driver but nothing
more other than it's association with a particular device tree
configuration node (e.g. dtc_id). This may not be ideal for someone
configuring the kernel since this codec doesn't appear as an option
and the dependencies (as described in the Kconfig) are not clear.

The work-around, albeit clumsy, is to bundle the changes to the
Makefile/Kconfig's and the codec source itself as a set of patches
referenced from the linux-ti-staging_3.14.bbappend file. Now building
the kernel modules also builds the codec (e.g. no separate codec
Bitbake recipe is required).  This works but now my codec sources
exist as a patch and stored directly in the recipe. Assuming I want
to do iterative development with this module, every change to the
codec sources require me to update the codec patch. Also, the codec
source must then effectively be version-controlled within the
*.bbappend recipe itself (as a *.patch file or possibly as a naked
codec.c that is copied into the destination kernel sources during the
patch step of bitbake).

Ideally, I'd like to maintain my codec driver outside of the kernel
tree (since it is not dependent on the BeagleBone Black) and just
maintain the *.bbappend to make the necessary platform-specific
machine-layer/device-tree patches. I want the codec to be built with
the kernel sources but not treated as a Yocto out-of-tree module. Is
there a way for the *.bbappend to fetch the codec sources from another
repo and place them in the kernel sound/soc/codecs directory before
the kernel is built? Can anyone suggest a better/alternative work-flow
that accommodates keeping the codec sources in a separate repo (much
like the out-of-tree modules) while allowing seamless integration
into the kernel sources. Fundamentally, I don't want the codec sources
to be version controlled directly *inside* the *.bbappend recipe as
either a patch or as a raw source file. Is there an alternative
work-flow that works better with Yocto?



Obvious alternative is to fork the kernel and manage it in your own repo. 
Using git rebase you can keep your changes on top, and git format-patch can 
generate patches for when you want your recipe to go out into the big bad world.


The kernel source dir is a git repository, so you can us that as your 
repository for making changes too. Instead of pushing your work, use git 
format-patch to output the patches (into the bitbake recipe path). When you 
build the kernel, the git repo will contain your patches as commits.





Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/

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

Re: [yocto] [meta-raspberrypi] Why not enable hard floating point?

[Mike Looijmans]

On 15-01-15 01:11, J. Tang wrote:


On Jan 14, 2015, at 15:36 , Andrei Gherzan and...@gherzan.ro wrote:


On Sat, Jan 10, 2015 at 10:38:50AM -0500, J. Tang wrote:

The upstream meta-raspberrypi recipe builds an arm6 toolchain with only soft 
floating point. As an experiment, I enabled hard floating point by setting my 
DEFAULTTUNE to “armv6hf”. My code still ran correctly. Is there a reason why 
the meta-raspberrypi layer does not enable hard floating point?



Well we played a little with this in the past. And we realised that, at that
time at least, switching to hf didn't add any performace improvements. Did you
test anything that proves the contrary?


In my case, I was re-compiling MAME for the Raspberry Pi. The code has a 
dependency on hf. Furthermore, Rasbian is built with hf.


If the CPU has actual hard-float support, then enabling it should increase 
floating point performance by an order of magnitude (e.g. 100x faster or so).


If you don't see any real world performance improvements, My guess would be 
one of these cases:


-1- The compiler is already creating FPU instructions, based on other 
properties of the target platform. The hf tune only changes the ABI, so that 
floating point values are passed to/from libraries in normal registers instead 
of FPU registers. This has very little impact on performance (unless you have 
some very badly designed libs). You can check if this is the case by examining 
disassember output for a bit of FPU code, if you see instructions starting 
with F in there, it's using the ARM VFP.


-2- The CPU doesn't actually have floating point support and the kernel is 
emulating it for you. This allows the platform to run hf binaries, at a 
minor performance cost compared to completely doing the emulation in user 
space (libc).




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/

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

Re: [yocto] addiding external driver to minimal image

[Mike Looijmans]

Create your own image recipe (hint: require another image, or just 
copy it), that reduces the parse time. Creating the image usually takes 
less than a minute.


You can also just build the new package and manually install it on the 
target.



On 12/21/2014 11:07 AM, abhishek srivastava wrote:

Hi
How to add external driver (ex:TFT driver) to core-minimal-image.
After building core -minimal-image, in case I need to add additional
package to existing image, do i need to modify in .conf file and REBUILD
IT..every time ?

please clarify !

Thank you





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

Re: [yocto] parallel build of multiple machine/os?

[Mike Looijmans]

On 12/11/2014 08:42 PM, Mark Hatle wrote:

On 12/11/14, 12:55 AM, Mike Looijmans wrote:

On 12/10/2014 08:00 PM, Khem Raj wrote:



On Dec 10, 2014, at 10:52 AM, Koehler, Yannick (HP Networking)
yannick.koeh...@hp.com wrote:

Can Yocto build for example in a single bitbake call an image for x86,
ppc, arm, others?  Or is the call to bitbake limited to a single
architecture?  And if so, how?

I see that lots of *-native package are built, and I guess is that for
each machine/os those would be reused, as such, it appears it would be a
benefit to be able to build multiple package version for different
architecture/distro/machine in a single invocation of bitbake.


parallel multi-machine builds have been discussed but not thought of worth
doing. you could however share
lot of common packages among machines sequentially.

[...]


A more convincing use-case for multi-machine building is the emerging of
hybrids. The little/big architecture that puts different versions of ARM
CPUs into a single machine is one example, the OMAPs with the DSP and PRUs are
another. Boards with FPGAs can have several CPU architectures running on a
single board. One could imagine that one would want to build the software for
all these subsystems in a single call, and that one bitbake process would be
managing that the build system gets properly used.

Currently, these hybrids have to invoke bitbake for each subsystem, probably
needlessly regenerating binaries, and once more for the one image to find them
all and in darkness bind them...



 From a userspace perspective, this is more or less solved with the multilib
configurations.  Perhaps it would be possible to implement some kind of hybrid
kernel configuration using the same type of multilib setup.  (Note, this would
be new work, it's not something we have today.)


The OMAP PRU and DSP each run their own bootloader/kernels (the PRU is just 
bare metal code), and do not share code with the ARM that runs the rest. From 
the ARM's perspective, the DSP and PRU just need firmware.


If I put a Microblaze into the FPGA of a Zynq, I have a system that can run 
multiple kernels, on the built-in ARM CPUs and on the Microblaze(s). The ARM 
is then responsible for bootstrapping the microblaze, but it ends there, as 
the microblaze can run its own kernel and rootfs and applications, and they 
don't need to understand each other's binaries.


One problem here is that the firmware for the microblaze would be a image, 
and images and in particular the rootfs, for reasons yet unknown to me, always 
get rebuilt even if nothing changed and the output would be the same.


I might succeed in spawning another bitbake from within the one that builds 
the ARM system, but on a 8-core system this sub-bitbake would also try to run 
8 parallel processes, each potentially running 8 compiler threads. Some of 
these compilers eat RAM like crazy, so this is not going to be productive. It 
would be much better if the builds for the ARM and mircroblaze would share the 
load. Probably a very challenging thing to do currently.




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/

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

Re: [yocto] parallel build of multiple machine/os?

[Mike Looijmans]

On 12/10/2014 08:00 PM, Khem Raj wrote:



On Dec 10, 2014, at 10:52 AM, Koehler, Yannick (HP Networking) 
yannick.koeh...@hp.com wrote:

Can Yocto build for example in a single bitbake call an image for x86, ppc, 
arm, others?  Or is the call to bitbake limited to a single architecture?  And 
if so, how?

I see that lots of *-native package are built, and I guess is that for each 
machine/os those would be reused, as such, it appears it would be a benefit to 
be able to build multiple package version for different 
architecture/distro/machine in a single invocation of bitbake.


parallel multi-machine builds have been discussed but not thought of worth 
doing. you could however share
lot of common packages among machines sequentially.

[...]


A more convincing use-case for multi-machine building is the emerging of 
hybrids. The little/big architecture that puts different versions of ARM 
CPUs into a single machine is one example, the OMAPs with the DSP and PRUs are 
another. Boards with FPGAs can have several CPU architectures running on a 
single board. One could imagine that one would want to build the software for 
all these subsystems in a single call, and that one bitbake process would be 
managing that the build system gets properly used.


Currently, these hybrids have to invoke bitbake for each subsystem, probably 
needlessly regenerating binaries, and once more for the one image to find them 
all and in darkness bind them...



Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/

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

Re: [yocto] External Linux Kernel Module

[Mike Looijmans]

On 12/10/2014 06:42 AM, Moore, Thomas (FtWorth) wrote:

Hello,

I’m working on incorporating an external kernel module based on the hello-mod
skeleton recipe. Everything was going well until I added the following line to
my machine configuration:

MACHINE_EXTRA_RDEPENDS += kernel-module-hello”

Attempting to run “bitbake core-image-base” then leads to the following error:

no package provides kernel-module-hello

After digging through the .bbclass files in the meta folder, I’m beginning to
think that the following comment in the hello-mod_0.1.bb file is no longer true:

# The inherit of module.bbclass will automatically name module packages with

# kernel-module- prefix as required by the oe-core build environment.

Adding the following lines to the end of hello-mod_0.1.bb allows the image to
be successfully created:

PROVIDES = kernel-module-hello

RPROVIDES_${PN} = kernel-module-hello

Has something been changed in module.bbclass? Is it even required to have to
have the “kernel-module-“ prefix?


I think that comment is outdated or something that someone wanted to implement 
some day or so.


I've always just named my kernel module recipes kernel-module-XXX.bb.




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/

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

Re: [yocto] Support for writable files with a read-only root file system

[Mike Looijmans]

The one-size-fits-all solution is to use an unionfs, and a writable part in 
RAM or mounted elsewhere, e.g. in flash (typically a tiny jffs2 partition).


It requires quite some scripting to get right, you have to boot the system and 
then mount the overlay, the unionfs to join it with the rootfs, and then 
pivot it to make it the new root.


After that you get a root where you can modify any file, and even persist that 
change (if you use a persistent overlay).




On 11/26/2014 08:51 AM, Matt Schuckmann wrote:

I've been investigating the support for read only root file systems and trying 
to suss out how to support persistent writeable files in my image where the 
root file system is read only, this seems like a very common thing for an 
embedded Linux system to need but I'm not seeing the support for it.

I should note that I'm working off of the Dylan branch, I'm not sure if things 
have changed in a newer branch.

So far I've had to read the code to figure out as much as I have, and I haven't 
found any documentation for this, am I missing something?

It appears that my recipe(s) are supposed to install a volatiles file under 
${D}${sysconfdir}/default/volatiles/ that lists out the volatile directories, 
links and files that need to be created in the image.

For writeable persistent files I would presume that I should specify links that 
point to some place on a write partition.

What I don't see is any sort of mechanism for setting up the default files on 
that writeable partition, am I on my own for this or is there some other 
recommended mechanism.

In my early research I found the MentorEmbedded/meta-ro-rootfs layer that had a 
nifty way of specifying VOLATILE_BINDS to create a list of binds that should 
occur at boot up and in the process creating the mounts if the target of the 
bind didn't exist a copy was made from the read only location, this appears to 
have provided a sort of default to go into the writeable location. Was this 
functionality abandoned when support for ro-rootfs was brought into oe-core? If 
so why?

A good example for the kind of writeable persistent file that I intend to have 
is /etc/network/interfaces
How do I go about letting the init_ifupdown recipe install it normally and then 
have another recipe or even the image configure it to be either a link or a 
bind mount at another location while still preserving the default contents.

I hope I'm making sense here.

Thanks,
Matt S.





Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/

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

Re: [yocto] sharing directories between users on same machine

[Mike Looijmans]

For the download directory, just set the permissions for the group to allow 
writing. I've used this with an NFS share that holds all downloads. The 
machien also runs apache and shares this directory via http.


I share the sstate-cache via http, and there's one machine that runs all 
builds every night, so that the cache is usually up to date. But I think chmod 
g+w on the sstate-cache dir should accomplish the same.


On 11/19/2014 04:20 PM, Urs Fässler wrote:

Hello,
we try to share the sstate-cache and download directory between multiple users
on the same machine.

It seems that this don't work as yocto want to overwrite some files in those
directories, but does not have the rights (since another user created them).

Is this not an use case?
- If it should work, can somebody give pointers what might went wrong
   (some missing configuration or so)
- If it can not work, can we do that differently?


Thanks
Urs




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Visit us at Bits  Chips Smart Systems 20th November, 1931 Congrescentum 
Brabanthallen 's-Hertogenbosch, stand number 34
http://bc-smartsystems.nl

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

Re: [yocto] Sato image touchscreen calibration is borked

[Mike Looijmans]

On 11/13/2014 06:58 PM, Michael Gloff wrote:

On Thu, Nov 13, 2014 at 7:28 AM, Burton, Ross ross.bur...@intel.com
mailto:ross.bur...@intel.com wrote:

Hi,

On 13 November 2014 13:19, Mike Looijmans mike.looijm...@topic.nl
mailto:mike.looijm...@topic.nl wrote:

I've been using ts_calibrate in the past, and that worked just fine
on this board.


Modern X servers don't use tslib, so this won't work since we stopped
using kdrive about two years ago.

BTW, you can use tslib with xorg. This is what I have set up as I find
ts_calibrate easier to work with.


Interesting option, can you elaborate on that (in particular, in combination 
with Yocto builds)?






Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Visit us at Bits  Chips Smart Systems 20th November, 1931 Congrescentum 
Brabanthallen 's-Hertogenbosch, stand number 34
http://bc-smartsystems.nl

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

[yocto] Sato image runs, but doesn't start its GUI

[Mike Looijmans]

I finally got around to trying to use our custom board's BSP with Yocto images.

Since the board has a touchscreen (well, actually it has two) I built the 
core-image-sato.


I had to tweak the startup a bit, because our framebuffer is in the FPGA it 
won't be available until after programming it and loading the modules.


Setting psplash to S05 instead of S00, and modutils to load at S04 fixes the 
initialization order problems I saw.


What I get now is a nice Yocto logo on the screen, and a progress bar that 
almost fills up. But nothing else happens. I'd expect the GUI to start then, 
but apparently there's nothing to trigger that?


Display works, touch works, everything seems in perfect working order.

I can't find anything that attempts to start anything. There's nothing in 
inittab, and there's nothing in rc3.d that resembles an attempt at starting 
something desktop GUI application or so.


Am I missing something, is this a bug, or is this expected behaviour and am I 
supposed to type some magic command first?



Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Visit us at Bits  Chips Smart Systems 20th November, 1931 Congrescentum 
Brabanthallen 's-Hertogenbosch, stand number 34
http://bc-smartsystems.nl

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

Re: [yocto] Sato image runs, but doesn't start its GUI

[Mike Looijmans]

On 11/13/2014 02:07 PM, Burton, Ross wrote:


On 13 November 2014 12:59, Mike Looijmans mike.looijm...@topic.nl
mailto:mike.looijm...@topic.nl wrote:

I can't find anything that attempts to start anything. There's nothing in
inittab, and there's nothing in rc3.d that resembles an attempt at
starting something desktop GUI application or so.


core-image-sato should be shipping the xserver-nodm init script, which starts X.

Ross


Ah, thanks, found it. It's set to run at runlevel 5 and somehow my inittab has 
3 as its level. Setting it to 5 displays the desktop.


Next challenge is to calibrate the touch screen...


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Visit us at Bits  Chips Smart Systems 20th November, 1931 Congrescentum 
Brabanthallen 's-Hertogenbosch, stand number 34
http://bc-smartsystems.nl

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

[yocto] Sato image touchscreen calibration is borked

[Mike Looijmans]

On 11/13/2014 02:10 PM, Mike Looijmans wrote:

Next challenge is to calibrate the touch screen...


Hmm. That's a big disappointment.

I've been using ts_calibrate in the past, and that worked just fine on this 
board.


Sato uses an X application for this, and it's apparently borked or so.

It does not run at startup, as I'd expect it to do (though it seems to be 
setup for that).


running DISPLAY=0:0 xinput_calibrator_once.sh displays it, but it doesn't 
really work. I can only touch the crosses in the upper left and right 
corner, but it does not accept the lower right one.


I ran it with the -v option to get some more info, and this is what it 
displays when I click the crosses. The lower left one causes the Not 
adding... output.



root@topic-miami-florida-med-xc7z015:~# xinput_calibrator -v
DEBUG: XInputExtension version is 2.3
DEBUG: Skipping virtual master devices and devices without axis valuators.
DEBUG: Skipping device 'Virtual core XTEST pointer' id=4, does not report 
Absolute events.

DEBUG: Selected device: AD7879 Touchscreen
DEBUG: Not usbtouchscreen calibrator: Not a usbtouchscreen device
DEBUG: Read axes swap value of 0.
DEBUG: Read InvertX=0, InvertY=0.
Calibrating EVDEV driver for AD7879 Touchscreen id=6
current calibration values (from XInput): min_x=0, max_x=1024 and 
min_y=0, max_y=600

DEBUG: Adding click 0 (X=1023, Y=599)
DEBUG: Adding click 1 (X=607, Y=599)
DEBUG: Not adding click 2 (X=1023, Y=599): within 7 pixels of previous click
DEBUG: Not adding click 2 (X=1023, Y=599): within 7 pixels of previous click
DEBUG: Not adding click 2 (X=1023, Y=599): within 7 pixels of previous click




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Visit us at Bits  Chips Smart Systems 20th November, 1931 Congrescentum 
Brabanthallen 's-Hertogenbosch, stand number 34
http://bc-smartsystems.nl

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

Re: [yocto] Sato image touchscreen calibration is borked

[Mike Looijmans]

On 11/13/2014 02:28 PM, Burton, Ross wrote:

Hi,

On 13 November 2014 13:19, Mike Looijmans mike.looijm...@topic.nl
mailto:mike.looijm...@topic.nl wrote:

I've been using ts_calibrate in the past, and that worked just fine on
this board.


Modern X servers don't use tslib, so this won't work since we stopped using
kdrive about two years ago.


Maybe, but it demonstrates that the hardware and drivers are working just fine.




DEBUG: Adding click 0 (X=1023, Y=599)
DEBUG: Adding click 1 (X=607, Y=599)
DEBUG: Not adding click 2 (X=1023, Y=599): within 7 pixels of previous click
DEBUG: Not adding click 2 (X=1023, Y=599): within 7 pixels of previous click
DEBUG: Not adding click 2 (X=1023, Y=599): within 7 pixels of previous click


Well, it's not within seven pixels is it...  I wonder if there's a bug in the
logic.  It might be worth bumping the xinput-calibrator revision to the latest
commit in the upstream git repo in case this has been fixed already there.


Tried, but that did not help, same problem.


I bought a HDMI display with an integrated touchscreen to test this sort of
thing, but the device was so dodgy that it often caused the kernel to hang on
boot...


I have one of those attached to the system as well. Explaining that I have two 
touch screens might be a bit of a challenge though, so I started with the 
little LVDS screen first.





Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Visit us at Bits  Chips Smart Systems 20th November, 1931 Congrescentum 
Brabanthallen 's-Hertogenbosch, stand number 34
http://bc-smartsystems.nl

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

Re: [yocto] Sato image touchscreen calibration is borked

[Mike Looijmans]

On 11/13/2014 02:54 PM, Mike Looijmans wrote:

On 11/13/2014 02:28 PM, Burton, Ross wrote:

Hi,

On 13 November 2014 13:19, Mike Looijmans mike.looijm...@topic.nl
mailto:mike.looijm...@topic.nl wrote:

I've been using ts_calibrate in the past, and that worked just fine on
this board.


Modern X servers don't use tslib, so this won't work since we stopped using
kdrive about two years ago.


Maybe, but it demonstrates that the hardware and drivers are working just fine.




DEBUG: Adding click 0 (X=1023, Y=599)
DEBUG: Adding click 1 (X=607, Y=599)
DEBUG: Not adding click 2 (X=1023, Y=599): within 7 pixels of previous
click
DEBUG: Not adding click 2 (X=1023, Y=599): within 7 pixels of previous
click
DEBUG: Not adding click 2 (X=1023, Y=599): within 7 pixels of previous
click


Well, it's not within seven pixels is it...  I wonder if there's a bug in the
logic.  It might be worth bumping the xinput-calibrator revision to the latest
commit in the upstream git repo in case this has been fixed already there.


Tried, but that did not help, same problem.


I bought a HDMI display with an integrated touchscreen to test this sort of
thing, but the device was so dodgy that it often caused the kernel to hang on
boot...


I have one of those attached to the system as well. Explaining that I have two
touch screens might be a bit of a challenge though, so I started with the
little LVDS screen first.


That one works,

root@topic-miami-florida-med-xc7z015:~# DISPLAY=0:0 xinput_calibrator -v --devic
e event1
DEBUG: XInputExtension version is 2.3
DEBUG: Skipping virtual master devices and devices without axis valuators.
DEBUG: Selected device: PixArtImaging OpticalTouchScreen
DEBUG: Not usbtouchscreen calibrator: Not a usbtouchscreen device
DEBUG: Evdev Axis Calibration not set, setting to axis valuators to be sure.
Setting calibration data: 0, 32767, 0, 32767
DEBUG: Successfully applied axis calibration.
DEBUG: Read axes swap value of 0.
DEBUG: Read InvertX=0, InvertY=0.
Calibrating EVDEV driver for PixArtImaging OpticalTouchScreen id=6
current calibration values (from XInput): min_x=0, max_x=32767 and 
min_y=0, max_y=32767

DEBUG: Found that 'PixArtImaging OpticalTouchScreen' is a sysfs name.
INFO: width=1920, height=1080
DEBUG: Adding click 0 (X=229, Y=147)
DEBUG: Adding click 1 (X=1699, Y=144)
DEBUG: Adding click 2 (X=231, Y=943)
DEBUG: Adding click 3 (X=1685, Y=942)

Doing dynamic recalibration:
Setting calibration data: -233, 33034, 384, 32625


So it seems related to the little I2C touchscreen controller, or some kind of 
rotation. The coordinate system for the small touchscreen looks rotated 180 
degrees, looking at the numbers. xinput cannot handle that?





Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Visit us at Bits  Chips Smart Systems 20th November, 1931 Congrescentum 
Brabanthallen 's-Hertogenbosch, stand number 34
http://bc-smartsystems.nl

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

Re: [yocto] [OE-core] DNS when using Static IP

[Mike Looijmans]

When using DHCP, busybox's udhcpc script will write the DNS entries that 
the server returned into the resolv.conf file.


In this case, I think you'll have to provide resolv.conf in some other 
way, there's nothing in ifup/ifdown that will modify resolv.conf based 
on keywords in the interfaces file.


Mike.


On 05/02/2014 02:49 PM, Iorga, Cristian wrote:

Not really, I just wanted to get a better overview of the issue that you
are facing.

What image did you started from, if any?

*From:*Tarek El-Sherbiny [mailto:tarek.elsherb...@gmail.com]
*Sent:* Friday, May 2, 2014 3:31 PM
*To:* Iorga, Cristian
*Cc:* openembedded-c...@lists.openembedded.org; yocto@yoctoproject.org
*Subject:* RE: [OE-core] DNS when using Static IP

No connman is not included.  Shall I include it and try?

On 2 May 2014 13:01, Iorga, Cristian cristian.io...@intel.com
mailto:cristian.io...@intel.com wrote:

Hello,

What image did you start from, if any?

i.e., core-image-minimal, core-image-sato, etc…

Is connman included?

Regards,

Cristian Iorga

YP

Intel Corporation

*From:*openembedded-core-boun...@lists.openembedded.org
mailto:openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org
mailto:openembedded-core-boun...@lists.openembedded.org] *On
Behalf Of *Tarek El-Sherbiny
*Sent:* Friday, May 2, 2014 2:05 PM
*To:* yocto@yoctoproject.org mailto:yocto@yoctoproject.org;
openembedded-c...@lists.openembedded.org
mailto:openembedded-c...@lists.openembedded.org
*Subject:* [OE-core] DNS when using Static IP

Hi.

I'm trying to set my IP config to a static address.

iface eth0 inet static

  address 192.168.55.45

  network 192.168.55.0

  netmask 255.255.255.0

  broadcast 192.168.55.255

  gateway 192.168.55.1

  dns-nameservers 192.168.10.2

But I don't get the DNS server address to be included in
/etc/resolv.conf

If I run in dchp mode, then the resolv.conf is updated with my DNS
address.

Is there something I'm missing here in my setup?

--

/Tarek/






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