[yocto] problem of toolchain install directrory

[Neil.Wu]

Hello ,all
I build the toolchain via  bitbake core-image-minimal –c populate_sdk. Then I 
install the toolchain.

If I install the toolchain in default directory(default: /opt/poky/1.7.1), 
everything is ok.

But,   if I not install in the default directory, it will appears the problem 
that can’t find the system header files.
Example: stdio.h

Why is this ? Whether I need to do some other operation.  If you know please 
help me ! Thank you very much.

Best wishes
Neil

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

Re: [yocto] problem of toolchain install directrory

[Liviu Gheorghisan]

Hello Neil,

Your problem is that the toolchain is installed with the location of the 
sysroot hardcoded as the default installation path for the tool-chain.

You can see this location with:
$ arm-poky-linux-gnueabi-gcc --print-sysroot // or whatever 
cross-compiler you built


However, after you source the environment script for the toolchain:

$ source environment-setup-armv7a-vfp-neon-poky-linux-gnueabi

the environment variables related to the toolchain will be updated 
accordingly, taking care of this problem.


So, use $CC instead of directly calling the gcc cross compiler 
arm-poky-linux-gnueabi-gcc (or whatever the platform you're building for).


Check the difference with this:
$ echo $CC
arm-poky-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork 
-mfloat-abi=softfp -mfpu=neon 
--sysroot=/home/livghe/work/ab/sdk/sysroots/armv7a-vfp-neon-poky-linux-gnueabi


$ $CC --print-sysroot // uses the correct sysroot
/home/livghe/work/ab/sdk/sysroots/armv7a-vfp-neon-poky-linux-gnueabi

$ $ arm-poky-linux-gnueabi-gcc --print-sysroot // uses the sysroot from 
the default instalation path, where it's not present.

/opt/poky/4.0/sysroots/armv7a-vfp-neon-poky-linux-gnueabi

So, you should always use the env variables ($CC, $AR, $LDFLAGS, etc) 
after sourcing the environment script from the toolchain instalation 
path, and not the toolchain executables directly, because the 
environment variables add some useful flags, not only related to the 
sysroot, but also to the type of CPU, etc.


- Liviu


On 12/17/2014 11:30 AM, neil...@emerson.com wrote:


*Hello ,all*

I build the toolchain via  bitbake core-image-minimal –c populate_sdk. 
Then I install the toolchain.


If I install the toolchain in default directory(/default: 
/opt/poky/1.7.1/), everything is ok.


But,   if I not install in the default directory, it will appears the 
problem that can’t find the system header files.


Example: stdio.h

Why is this ? Whether I need to do some other operation.  If you know 
please help me ! Thank you very much.


Best wishes

Neil





--
Liviu Gheorghisan
Software Engineer

http://www.enea.com

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

Re: [yocto] Package Feature compile/runtime dependency

[Koehler, Yannick (HP Networking)]

The size of the resulting image of poky-tiny + systemd is a lot smaller than 
poky itself, even with the systemd kernel/glibc requirement set in.  The poky 
distro also pulls a lot more package into the mix that I do not need for my 
tasks.  I could go and disable those, but that is actually what poky-tiny also 
does for me already.

Poky-tiny allow me to go from small to my needs instead of the reverse which is 
harder to achieve as I would need to have a full understanding on how the 
dependencies works to save space, where the other way I need to learn how to 
get where I want but no more.

At least in my opinion, building with poky-tiny gives me currently around 1500 
build tasks, where poky pulls over 2500, this shows how much more stuff "Poky" 
pulls in, no?

--
Yannick Koehler

De : Burton, Ross [mailto:ross.bur...@intel.com] 
Envoyé : December-16-14 3:42 PM
À : Koehler, Yannick (HP Networking)
Cc : Anders Darander; yocto@yoctoproject.org
Objet : Re: [yocto] Package Feature compile/runtime dependency


On 12 December 2014 at 15:44, Koehler, Yannick (HP Networking) 
 wrote:
My hope, was that somehow, adding systemd to DISTRO_FEATURE would not only add 
the packages I need, but also add feature to some package like the kernel/libc 
that are required by such addition.

No, DISTRO_FEATURES don't change how eg libc and the kernel are built.  That 
said if you're building systemd, why are you using poky-tiny?  I doubt you'll 
see much gain from poky-tiny + all the pieces to make systemd work and plain 
poky (or the default distro configuration).

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

Re: [yocto] how to set static ip in linux

[Philip Balister]

I'd install a custom /etc/network/interfaces file via a bbappend or
similar method. There is numerous examples in google of how to set up  a
static Ip via the interfaces file.

Philip

On 12/16/2014 05:08 AM, Constantin, Costin C wrote:
> Hello Sachin
> 
> The easiest way to do this is by modifying the install script. Here is how:
> Suppose you cloned poky into a local dir. on your HDD drive. I use Ubuntu for 
> this but you can use whatever certified OS (Fedora, Centos, OpenSuse) just:
> 
> $ cd your_local_poky_dir
> $ gedit meta/recipes-core/initrdscripts/files/init-install.sh
> ...
> #before the line containing "umount /tgt_root"   add the following
> # interface=$(ls /sys/class/net | grep eth)
> # echo "ifconfig $interface your_desired_ip netmask 255.255.255.0 up" >> 
> /tgt_root/etc/profile
> #eg.:
> interface=$(ls /sys/class/net | grep eth)
> echo "ifconfig $interface 10.10.10.10 netmask 255.255.255.0 up" >> 
> /tgt_root/etc/profile
> #after this comes
> umount /tgt_root
> ...
> 
> Regards,
> 
> Costin Constantin
> Yocto QA team
> 
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] how to set static ip in linux

[Constantin, Costin C]

... or easier, you can directly use the 
poky_dir/meta/recipes-core/init-ifupdown/init-ifupdown-1.0/interfaces to
set up interfaces. An eg. would be:

auto eth0
iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0
network 192.168.1.0
gateway 192.168.1.1

I personally used the already mentioned method for convenience, because i had a 
lot to work with install script
lately ... 

Costin Constantin
Yocto QA team


From: Philip Balister [phi...@balister.org]
Sent: Wednesday, December 17, 2014 5:06 PM
To: Constantin, Costin C; yocto@yoctoproject.org
Subject: Re: [yocto] how to set static ip in linux

I'd install a custom /etc/network/interfaces file via a bbappend or
similar method. There is numerous examples in google of how to set up  a
static Ip via the interfaces file.

Philip

On 12/16/2014 05:08 AM, Constantin, Costin C wrote:
> Hello Sachin
>
> The easiest way to do this is by modifying the install script. Here is how:
> Suppose you cloned poky into a local dir. on your HDD drive. I use Ubuntu for 
> this but you can use whatever certified OS (Fedora, Centos, OpenSuse) just:
>
> $ cd your_local_poky_dir
> $ gedit meta/recipes-core/initrdscripts/files/init-install.sh
> ...
> #before the line containing "umount /tgt_root"   add the following
> # interface=$(ls /sys/class/net | grep eth)
> # echo "ifconfig $interface your_desired_ip netmask 255.255.255.0 up" >> 
> /tgt_root/etc/profile
> #eg.:
> interface=$(ls /sys/class/net | grep eth)
> echo "ifconfig $interface 10.10.10.10 netmask 255.255.255.0 up" >> 
> /tgt_root/etc/profile
> #after this comes
> umount /tgt_root
> ...
>
> Regards,
>
> Costin Constantin
> Yocto QA team
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] bump linux-yocto-dev to 3.18?

[Cody P Schafer]

It looks like http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-dev/
is still sitting at 3.17.6, are their plans to merge the 3.18 changes?

Or does linux-yocto-dev wait on stable kernel releases?
Or is this blocked on something else I'm unaware of?

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

Re: [yocto] bump linux-yocto-dev to 3.18?

[Bruce Ashfield]

On 14-12-17 01:02 PM, Cody P Schafer wrote:

It looks like http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-dev/
is still sitting at 3.17.6, are their plans to merge the 3.18 changes?

Or does linux-yocto-dev wait on stable kernel releases?
Or is this blocked on something else I'm unaware of?


I'm actually waiting for 3.19 at this point. If you look at the patch
series I sent out last week, we were busy working on developer
experience patches and integrating LTSI content.

There's also another activity to get linux-yocto-dev glued fully into
the autobuilder to shake out bugs before I push the changes to the
the main repositories.

Generally speaking, I don't merge each and every korg kernel into the
development branches, with a one kernel jump after we do a release
with a kernel (which in this case 3.17 comes with Yocto 1.8). And
that is simply to allow the existing set of three kernels to settle
before refreshing features, moving into another round of development
and preparation for the next release kernel.

Cheers,

Bruce



--
Cody



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

Re: [yocto] Debugging opkg installs

[Paul Barker]

On Mon, Dec 08, 2014 at 10:17:37AM -0800, Matt Schuckmann wrote:
> I'm looking for some tips on debugging package install problems. 
> Recently I've had a problem where edits to a pkg_postinst function in one of 
> my recipes was not getting run when rebuilding my image. The only way I could 
> get the pkg_postinst() function to run was to wipe out my complete 
> openembedded build/tmp directory and let it rebuild everything from scratch 
> (and the sstate cache). I'd really like to understand what was going on here. 
> My guess is there was some sort of flag somewhere that was telling the opkg 
> to not run the postinst script for that package because it had already been 
> done once. 
> 
> It would also be nice to know how to run opkg installs locally on my dev 
> system to test out recipes but I haven't quite worked out the right tools in 
> place on my dev system and or what the right commands are.

Hi Matt,

I'm currently the maintainer of opkg so I can probably answer your questions.
I'm pretty busy at the minute though so sorry for the late reply.

If you want to run opkg with more verbosity you can add the '-V4' argument to
the opkg invocation to run at the highest verbosity level. Within OpenEmbedded I
think you need to append this to self.opkg_args in OpkgPM::__init__ in
meta/lib/oe/package_manager.py to ensure the argument is passed when opkg is
invoked to install packages into the rootfs. There is an OPKG_ARGS variable
which can be set in local.conf and is referenced by the code which invokes opkg,
but arguments I've specified in OPKG_ARGS have not been correctly passed to opkg
when I've ran builds. I've not had chance to debug why that variable doesn't
work though.

To install packages on your dev system you should be able to use the opkg binary
created by the build of opkg-native. That should reside in
tmp-glibc/sysroots/x86_64-linux/usr/bin/ within your build directory, though the
exact path may change depending on the libc used and the host architecture. The
opkg binary may be called 'opkg-cl'. You'll need to setup an opkg configuration
file for use on the dev system and I'd suggest you do this by copying the
contents of /etc/opkg/*.conf from your target system into a single conf file on
your dev system. You can pass '-f ' to opkg to instruct it to
read from this new configuration file.

That should get you started, any further questions just ask.

> 
> Thanks,
> Matt S. 
> 

Cheers,

-- 
Paul Barker

Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Using YP for non-embedded purposes.

[John Unland]

Hello everyone,

I am developing a linux distro for small businesses and I am wanting to
have a easy to use tool to develop that OS. However with the main-line
distros there is a lot of hoops to jump over to get to that point
(re-branding, remove certain software, etc). So I was wondering is it
possible to use the tool and it's documentation to develop a
non-embedded linux using YP?

Thank you,
John

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

Re: [yocto] Using YP for non-embedded purposes.

[Philip Balister]

On 12/17/2014 04:00 PM, John Unland wrote:
> Hello everyone,
> 
> I am developing a linux distro for small businesses and I am wanting to
> have a easy to use tool to develop that OS. However with the main-line
> distros there is a lot of hoops to jump over to get to that point
> (re-branding, remove certain software, etc). So I was wondering is it
> possible to use the tool and it's documentation to develop a
> non-embedded linux using YP?

I do not see any problem doing this, after all OpenEmbedded is a build
system and scales form small to large systems. It is just most work is
focused on the smaller end.

Philip


> 
> Thank you,
> John
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] problem of toolchain install directrory

[Neil.Wu]

Hello Liviu,

Thank you very much for your reply. I got a very useful information from your 
reply.

At the  beginning , I want  to add the cross compiler to eclipse project and 
not use the  default installer directory, but it appears the  above problem.

In eclipse project, the setting as  these:
Properties -- Setting--CrossSetting --Prefilx: arm-poky-linux-gnueabi-
Properties--Setting -- CrossSetting--Path: /opt/poky/mycompiler/sysroots/ 
i686-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi

You give me the idea to add the sysroot path:
Properties -- Setting -- Cross GCC compiler -MisCellaneous: 
--sysroot=/opt/poky/mycompiler/sysroots/ armv5te-poky-linux-gnueabi

Now, everything is ok . Thank you again for your help.

Best wishes

Neil
From: Liviu Gheorghisan [mailto:liviu.gheorghi...@enea.com]
Sent: Wednesday, December 17, 2014 5:47 PM
To: Wu, Neil [CLIMATE/RS/CN]; yocto@yoctoproject.org
Subject: Re: [yocto] problem of toolchain install directrory

Hello Neil,

Your problem is that the toolchain is installed with the location of the 
sysroot hardcoded as the default installation path for the tool-chain.
You can see this location with:
$ arm-poky-linux-gnueabi-gcc --print-sysroot // or whatever cross-compiler you 
built

However, after you source the environment script for the toolchain:

$ source environment-setup-armv7a-vfp-neon-poky-linux-gnueabi

the environment variables related to the toolchain will be updated accordingly, 
taking care of this problem.

So, use $CC instead of directly calling the gcc cross compiler 
arm-poky-linux-gnueabi-gcc (or whatever the platform you're building for).

Check the difference with this:
$ echo $CC
arm-poky-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=softfp 
-mfpu=neon 
--sysroot=/home/livghe/work/ab/sdk/sysroots/armv7a-vfp-neon-poky-linux-gnueabi

$ $CC --print-sysroot // uses the correct sysroot
/home/livghe/work/ab/sdk/sysroots/armv7a-vfp-neon-poky-linux-gnueabi

$ $ arm-poky-linux-gnueabi-gcc --print-sysroot // uses the sysroot from the 
default instalation path, where it's not present.
/opt/poky/4.0/sysroots/armv7a-vfp-neon-poky-linux-gnueabi

So, you should always use the env variables ($CC, $AR, $LDFLAGS, etc) after 
sourcing the environment script from the toolchain instalation path, and not 
the toolchain executables directly, because the environment variables add some 
useful flags, not only related to the sysroot, but also to the type of CPU, etc.

- Liviu

On 12/17/2014 11:30 AM, neil...@emerson.com wrote:
Hello ,all
I build the toolchain via  bitbake core-image-minimal -c populate_sdk. Then I 
install the toolchain.

If I install the toolchain in default directory(default: /opt/poky/1.7.1), 
everything is ok.

But,   if I not install in the default directory, it will appears the problem 
that can't find the system header files.
Example: stdio.h

Why is this ? Whether I need to do some other operation.  If you know please 
help me ! Thank you very much.

Best wishes
Neil






--

Liviu Gheorghisan

Software Engineer



http://www.enea.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi] Image will halt soon after boot

[Petter Gustad]

I've run "bitbake rpi-hwup-image" using the daisy branch:

meta-yocto-bsp= "daisy:1e668ccf1a05c5d730de9747bc1c2b0446bda556"
meta-raspberrypi.git = "daisy:946b69299737cc2f1378c864f1b9075280db1b53"

However, whenever I boot the created sdimage it will lock up during
boot. Typically I will see some garbage on the serial console.
Sometimes I'm able to log in, but then then I get no response (as in
the below session). Putting a pre-compiled distribution on the same
sdcard will boot just fine.

Does anybody else observe this behavior?

Is there a specific meta-raspberrypi mailing list? 

Best regards
//Petter

[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.12.21 (yocto@pangea) (gcc version 4.8.2 (GCC) ) 
#1 PREEMPT Wed Dec 17 22:58:01 CET 2014
[0.00] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), 
cr=00c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing 
instruction cache
[0.00] Machine: BCM2708
[0.00] cma: CMA: reserved 8 MiB at 0b80
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] On node 0 totalpages: 49152
[0.00] free_area_init_node: node 0, pgdat c061ada0, node_mem_map 
c06cc000
[0.00]   Normal zone: 384 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 49152 pages, LIFO batch:15
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 48768
[0.00] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 
bcm2708_fb.fbheight=416 bcm2708.boardrev=0x2 bcm2708.serial=0xb3c91a9a 
smsc95xx.macaddr=B8:27:EB:C9:1A:9A sdhci-bcm2708.emmc_clock_freq=25000 
vc_mem.mem_base=0xec0 vc_mem.mem_size=0x1000  dwc_otg.lpm_enable=0 
console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 
rootfstype=ext4 rootwait debug
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Memory: 179648K/196608K available (4492K kernel code, 238K 
rwdata, 1340K rodata, 143K init, 701K bss, 16960K reserved)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xcc80 - 0xff00   ( 808 MB)
[0.00] lowmem  : 0xc000 - 0xcc00   ( 192 MB)
[0.00] modules : 0xbf00 - 0xc000   (  16 MB)
[0.00]   .text : 0xc0008000 - 0xc05ba210   (5833 kB)
[0.00]   .init : 0xc05bb000 - 0xc05defe4   ( 144 kB)
[0.00]   .data : 0xc05e - 0xc061b8c0   ( 239 kB)
[0.00].bss : 0xc061b8cc - 0xc06cb088   ( 702 kB)
[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] Preemptible hierarchical RCU implementation.
[0.00] NR_IRQS:394
[0.00] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 
4294967ms
[0.00] Switching to timer-based delay loop
[0.00] Console: colour dummy device 80x30
[0.000403] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 2.00 BogoMIPS (lpj=1)
[0.000427] pid_max: default: 32768 minimum: 301
[0.000918] Mount-cache hash table entries: 512
[0.001722] Initializing cgroup subsys memory
[0.001801] Initializing cgroup subsys devices
[0.001820] Initializing cgroup subsys freezer
[0.001836] Initializing cgroup subsys blkio
[0.001963] CPU: Testing write buffer coherency: ok
[0.002422] Setting up static identity map for 0xc04461a8 - 0xc0446204
[0.004356] devtmpfs: initialized
[0.020651] VFP support v0.3: implementor 41 architecture 1 part 20 variant 
b rev 5
[0.022182] NET: Registered protocol family 16
[0.027441] DMA: preallocated 4096 KiB pool for atomic coherent allocations
[0.028048] cpuidle: using governor ladder
[0.028070] cpuidle: using governor menu
[0.028501] bcm2708.uart_clock = 0
[0.030443] hw-breakpoint: found 6 breakpoint and 1 watchpoint registers.
[0.030464] hw-breakpoint: maximum watchpoint size is 4 bytes.
[0.030478] mailbox: Broadcom VideoCore Mailbox driver
[0.030553] bcm2708_vcio: mailbox at f200b880
[0.030637] bcm_power: Broadcom power driver
[0.030656] bcm_power_open() -> 0
[0.030667] bcm_power_request(0, 8)
[0.531373] bcm_mailbox_read -> 0080, 0
[0.531391] bcm_power_request -> 0
[0.531629] Serial: AMBA PL011 UART driver
[0.531779] dev:f1: ttyAMA0 at MMIO 0x20201000 (irq = 83, base_baud = 0) is 
a PL011 rev3
[0.912882] console [ttyAMA0] enabled
[