[yocto] addiding external driver to minimal image

[abhishek srivastava]

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  -- 
___
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

[yocto] runqemu-extract-sdk does not provide all required libraries in rootfs

[peterengcomau001]

I am using poky 1.6.2.  If I create a rootfs using ADT I can Use
Eclipse to test against qemu all OK but this is not the traget rootfs
so its use is limited If I create a rootfs using $ bitbake image -c
populate_sdk then run the shell script, the rootfs created has all
the required libraries, but it does not create a directory called
pseudo_state, and qemu fails to work because of this. If I create a
rootfs with runqemu-extract-sdk on the image I created using $
bitabke image, the resulting rootfs has the required pseudo_state
directory but is missing crucial libraries. 
 The missing libraries are crt1.o, crti.o, ctrn.o, crtbegin.o,
crtend.o, crtn.o, libc.so, libc_nonshared.a, libgcc.a, libgcc_s.so,
libgcc_s.so.1.  
 I can import these libraries from the rootfs created by running teh
populate_sdk script, but I get an error:  compatibility issue
Message sent via Adam Internet WebMail - http://www.adam.com.au/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Sound over HDMI for ASrock IMB-151 (valleyisland)

[Chris Tapp]

I think I've worked this one out. It looks as if the kernel patch at 
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-October/067530.html 
needs to be included so that the ValleyView HDMI codec is detected.

Adding it manually before compiling the kernel gives me audio over HDMI.

Chris

On 14 Dec 2014, at 13:04, Chris Tapp  wrote:

> I'm having trouble getting audio out of the HDMI connector on an ASrock 
> IMB-151 board.
> 
> aplay -l reports:
> 
>  List of PLAYBACK Hardware Devices 
> card 0: PCH [HDA Intel PCH], device 0: ALC662 rev1 Analog [ALC662 rev1 Analog]
>  Subdevices: 1/1
>  Subdevice #0: subdevice #0
> card 0: PCH [HDA Intel PCH], device 1: ALC662 rev1 Digital [ALC662 rev1 
> Digital]
>  Subdevices: 1/1
>  Subdevice #0: subdevice #0
> card 0: PCH [HDA Intel PCH], device 3: ID 2882 Digital [ID 2882 Digital]
>  Subdevices: 1/1
>  Subdevice #0: subdevice #0
> 
> and aplay -L gives:
> 
> null
>Discard all samples (playback) or generate zero samples (capture)
> sysdefault:CARD=PCH
>HDA Intel PCH, ALC662 rev1 Analog
>Default Audio Device
> front:CARD=PCH,DEV=0
>HDA Intel PCH, ALC662 rev1 Analog
>Front speakers
> surround40:CARD=PCH,DEV=0
>HDA Intel PCH, ALC662 rev1 Analog
>4.0 Surround output to Front and Rear speakers
> surround41:CARD=PCH,DEV=0
>HDA Intel PCH, ALC662 rev1 Analog
>4.1 Surround output to Front, Rear and Subwoofer speakers
> surround50:CARD=PCH,DEV=0
>HDA Intel PCH, ALC662 rev1 Analog
>5.0 Surround output to Front, Center and Rear speakers
> surround51:CARD=PCH,DEV=0
>HDA Intel PCH, ALC662 rev1 Analog
>5.1 Surround output to Front, Center, Rear and Subwoofer speakers
> surround71:CARD=PCH,DEV=0
>HDA Intel PCH, ALC662 rev1 Analog
>7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
> iec958:CARD=PCH,DEV=0
>HDA Intel PCH, ALC662 rev1 Digital
>IEC958 (S/PDIF) Digital Audio Output
> hdmi:CARD=PCH,DEV=0
>HDA Intel PCH, ID 2882 Digital
>HDMI Audio Output
> 
> Running
> 
>  aplay -D plug:hdmi /usr/share/sounds/alsa/Front_Center.wav
> 
> gives nothing out of the hdmi. And
> 
>  speaker-test -D hdmi
> 
> gives:
> 
> speaker-test 1.0.27.2
> 
> Playback device is hdmi
> Stream parameters are 48000Hz, S16_LE, 1 channels
> Using 16 octaves of pink noise
> Channels count (1) not available for playbacks: Invalid argument
> Setting of hwparams failed: Invalid argument
> 
> I've not been able to find anything on the internet that gives me a clue to 
> what's wrong, and alsa is not an area I'm familiar with!
> 
> Anyone got an idea where I need to look?
> 
> --
> 
> Chris Tapp
> opensou...@keylevel.com
> www.keylevel.com
> 
> 
> You can tell you're getting older when your car insurance gets real cheap!
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

--

Chris Tapp
opensou...@keylevel.com
www.keylevel.com


You can tell you're getting older when your car insurance gets real cheap!

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

[yocto] Board files vs. device tree

[Fabian Schwartau]

Hi,

I am building a system with yocto for a board which is similar to 
Beagleboard-xM. So I used beagleboard as a starter. However, the kernel 
is not booting. Uboot just tells me that he is starting the kernel and 
then nothing happens any more.
So I guess there is something wrong with the pin muxing as my board is a 
little different from Beagleboard.
At the moment I am using the device tree file for beagleboard-xm by 
passing it with the uboot command

bootm ${loadaddr} - ${dtbaddr}
I looked around in the kernel and had to notice that there are still 
several board  files build in the kernel.
When there are several board files compiled into the kernel, how does 
the kernel determine the right one at boot time?
What does the kernel do if there are board files activated and I am also 
passing a device tree?
Why are there still board files when the specific board has already a 
device tree file?

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

Re: [yocto] Board files vs. device tree

[Maciek Borzecki]

On 12/21 16:32, Fabian Schwartau wrote:
> Hi,
>
> I am building a system with yocto for a board which is similar to
> Beagleboard-xM. So I used beagleboard as a starter. However, the kernel is
> not booting. Uboot just tells me that he is starting the kernel and then
> nothing happens any more.
> So I guess there is something wrong with the pin muxing as my board is a
> little different from Beagleboard.
> At the moment I am using the device tree file for beagleboard-xm by passing
> it with the uboot command
> bootm ${loadaddr} - ${dtbaddr}
> I looked around in the kernel and had to notice that there are still several
> board  files build in the kernel.
> When there are several board files compiled into the kernel, how does the
> kernel determine the right one at boot time?

U-boot does that, based on what is found at runtime. Typically this
would employ checks for CPU IDs, EEPROM contents, GPIO line states
etc. then at some point the could would set board_name to some
value. IIRC the exact model of Beagle Bone is determined based on system
EEPROM contents. Then the default uboot script would check board_name
and pick proper *.dtb based on some hardcoded names.

The actual checks are here:
http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;h=560e3bf7755d55d37c1e5e9fb5de162568d9cc9f;hb=HEAD#l176

Board checks here:
http://git.denx.de/?p=u-boot.git;a=blob;f=board/ti/am335x/board.h

> What does the kernel do if there are board files activated and I am also
> passing a device tree?

What do you mean by activated?

> Why are there still board files when the specific board has already a device
> tree file?

Because DTB defines what things are in the system and now how to operate
them. There still has to be some code that brings the system up for you
based on the board config. It's just that if you have a DTB, there's no
longer need to hardcode things such as CPU count, amount of RAM, flash
layout and so on. Off the top of my head, low level init or system reset
might be one of the things that end up in board specific code within the
kernel.

Also, IIRC dts is mandatory for all new ARM board being added to the
kernel. It has not always been like this, there's still a bunch of older
or obscure boards that do not have a dts at all.

--
Maciej Borzęcki
Senior Software Developer at Open-RnD Sp. z o.o., Poland
www.open-rnd.pl
mobile: +48 889 117 365, fax: +48 42 657 9079


Niniejsza wiadomość wraz z załącznikami może
zawierać chronione prawem lub poufne informacje i została
wysłana wyłącznie do wiadomości i użytku osób, do których
została zaadresowana. Jeśli wiadomość została otrzymana
przypadkowo zabrania się jej kopiowania lub rozsyłania do osób
trzecich. W takim przypadku uprasza się o natychmiastowe
zniszczenie wiadomości oraz poinformowanie nadawcy o
zaistniałej sytuacji za pomocą wiadomości zwrotnej.
Dziękujemy.

This message, including any attachments hereto,
may contain privileged or confidential information and is sent
solely for the attention and use of the intended addressee(s).
If you are not an intended addressee, you may neither use this
message nor copy or deliver it to anyone. In such case, you
should immediately destroy this message and kindly notify the
sender by reply email. Thank you.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Board files vs. device tree

[Fabian Schwartau]

Am 21.12.2014 um 18:08 schrieb Maciek Borzecki:
> On 12/21 16:32, Fabian Schwartau wrote:
>> Hi,
>>
>> I am building a system with yocto for a board which is similar to
>> Beagleboard-xM. So I used beagleboard as a starter. However, the 
kernel is

>> not booting. Uboot just tells me that he is starting the kernel and then
>> nothing happens any more.
>> So I guess there is something wrong with the pin muxing as my board is a
>> little different from Beagleboard.
>> At the moment I am using the device tree file for beagleboard-xm by 
passing

>> it with the uboot command
>> bootm ${loadaddr} - ${dtbaddr}
>> I looked around in the kernel and had to notice that there are still 
several

>> board  files build in the kernel.
>> When there are several board files compiled into the kernel, how 
does the

>> kernel determine the right one at boot time?
>
> U-boot does that, based on what is found at runtime. Typically this
> would employ checks for CPU IDs, EEPROM contents, GPIO line states
> etc. then at some point the could would set board_name to some
> value. IIRC the exact model of Beagle Bone is determined based on system
> EEPROM contents. Then the default uboot script would check board_name
> and pick proper *.dtb based on some hardcoded names.
OK, but there he is only creating the default configuration I guess. As 
I am using my own uboot configuration file, this does not matter to me 
and I will load the dtb file my own using the mentioned uboot command. 
Is that correct?

>
> The actual checks are here:
> 
http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;h=560e3bf7755d55d37c1e5e9fb5de162568d9cc9f;hb=HEAD#l176

>
> Board checks here:
> http://git.denx.de/?p=u-boot.git;a=blob;f=board/ti/am335x/board.h
>
>> What does the kernel do if there are board files activated and I am also
>> passing a device tree?
>
> What do you mean by activated?
Well, they are activated in the kernel configuration by default. So 
there are several board files compiled into the kernel. I was wondering 
how the kernel will pick the correct one at boot time.
So if I choose the dtb manually, how is the kernel supposed to know 
which board file to use?

>
>> Why are there still board files when the specific board has already 
a device

>> tree file?
>
> Because DTB defines what things are in the system and now how to operate
> them. There still has to be some code that brings the system up for you
> based on the board config. It's just that if you have a DTB, there's no
> longer need to hardcode things such as CPU count, amount of RAM, flash
> layout and so on. Off the top of my head, low level init or system reset
> might be one of the things that end up in board specific code within the
> kernel.
>
> Also, IIRC dts is mandatory for all new ARM board being added to the
> kernel. It has not always been like this, there's still a bunch of older
> or obscure boards that do not have a dts at all.
>
> --
> Maciej Borzęcki
> Senior Software Developer at Open-RnD Sp. z o.o., Poland
> www.open-rnd.pl
> mobile: +48 889 117 365, fax: +48 42 657 9079
>
>
> Niniejsza wiadomość wraz z załącznikami może
> zawierać chronione prawem lub poufne informacje i została
> wysłana wyłącznie do wiadomości i użytku osób, do których
> została zaadresowana. Jeśli wiadomość została otrzymana
> przypadkowo zabrania się jej kopiowania lub rozsyłania do osób
> trzecich. W takim przypadku uprasza się o natychmiastowe
> zniszczenie wiadomości oraz poinformowanie nadawcy o
> zaistniałej sytuacji za pomocą wiadomości zwrotnej.
> Dziękujemy.
>
> This message, including any attachments hereto,
> may contain privileged or confidential information and is sent
> solely for the attention and use of the intended addressee(s).
> If you are not an intended addressee, you may neither use this
> message nor copy or deliver it to anyone. In such case, you
> should immediately destroy this message and kindly notify the
> sender by reply email. Thank you.
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Microcontroller Cross Compiler

[João Henrique Ferreira de Freitas]

Hi,

I have the same requirement.

I will try it. But in my case I need to use this 
https://launchpad.net/gcc-arm-embedded.


There are some way to yocto creates the gcc-arm-embedded SDK? Instead of 
use the gcc-arm-embedded packages. Is it feasibly?


Thanks.


On 19/12/2014 11:21, Andrea Adami wrote:

On Thu, Dec 18, 2014 at 8:09 PM, Darcy Watkins
 wrote:

Hello,

In my target system I have a microcontroller (MCU) that handles some I/O, power 
supplies and system boot up to the point of taking the main CPU out of reset.  
At present, we build the MCU firmware from source and then the binary file is 
packaged to be used as payload with an MCU firmware update utility.

Now my main question...  does anyone have suggestions (or is there a 'yocto' 
way) to build such a cross compiler for the MCU so that it can be invoked to 
build MCU firmware from source as part of the bitbake build for the Linux 
target's image.  The idea would be to build MCU firmware image from source 
using the MCU cross compiler, but obviously to build drivers and utilities that 
run on the main CPU using the normal cross-compiler toolchains built under 
yocto.  Then I could package the payload firmware image along with utilities 
all as part of the same RPM package.

The MCU cross compiler we use was originally generated using crosstool-ng, and 
is essentially a gcc cross compiler for 'bare metal' MCU target.

Does anyone who has gone down this road have suggestions?

Thanks in advance!


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
[P2]
dwatk...@sierrawireless.com :: www.sierrawireless.com :: 
www.inmotiontechnology.com

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

Hi Darcy,

if I understand correctly you use the standard toolchain for the
target image and a custom $CC to build one custom binary.

We use klcc for a couple of klibc-static-recipes thus we created a
.bbclass to be inherited.
See 
http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/classes/klibc.bbclass

Regards

Andrea


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

[yocto] [Package Report System]Upgrade recipes name list

[package-rep...@yoctoproject.org]

This mail was sent out by Package Report System.
This message list those recipes which need to be upgraded. If maintainers 
believe some of them needn't to upgrade this time, they can fill in 
RECIPE_NO_UPDATE_REASON_pn-"xxx" in upstream_tracking files to ignore this 
recipe remainder until newer upstream version was detected.
Example:
RECIPE_NO_UPDATE_REASON_pn-"xxx" = "Not upgrade to 2.0 because the new version 
is unstable"
You can check the detail information at 
http://packages.yoctoproject.org/upgradepkgname


PackageName   Version   UpVersion   
  MaintainerNoUpgradeReason 
  
chkconfig-alternatives-native 1.3.59+AUTOINC+cd437ecbd8 
1.3.59+gitAUTOINC+cd437e  Wenzong Fan
blktrace  1.0.5+gitAUTOINC+d6918c8  
1.1.0+gitAUTOINC+2cf87e6  Tom Zanussi
systemtap-uprobes 2.6+gitAUTOINC+7682e51d2e 
2.6+gitAUTOINC+e6f437adfe Tom Zanussi
sysprof   1.2.0+gitAUTOINC+cd44ee6  
1.2.0+gitAUTOINC+6901897  Tom Zanussi
mkelfimage4.0+gitAUTOINC+686a48a339 
4.0+gitAUTOINC+e4db49730e Saul Wold   
 
mtd-utils 1.5.1+gitAUTOINC+9f10713  
1.5.1+gitAUTOINC+92686f2  Saul Wold   
 
u-boot-mkimagev2014.07+gitAUTOINC+5241  
2014.10+gitAUTOINC+d8bec  Saul Wold   
 
dtc   1.4.0+gitAUTOINC+65cc4d2  
1.4.1+gitAUTOINC+302fca9  Saul Wold   
 
systemtap 2.6+gitAUTOINC+7682e51d2e 
2.6+gitAUTOINC+e6f437adfe Saul Wold   
 
cross-localedef-native2.20  
28+gitAUTOINC+f80af76648  Saul Wold   
 
build-appliance-image 8.0   
12.0.0+gitAUTOINC+02627a  Saul Wold   
 
babeltrace1.2.4+gitAUTOINC+9039582  
1.2.4+gitAUTOINC+a53ed92  Saul Wold   
 
mx-1.01.4.7+gitAUTOINC+9b1db6b  
1.99.4+gitAUTOINC+24efb0  Saul Wold   
 PRS 1.99 is dev version   
update-rc.d   0.7   
0.7+gitAUTOINC+eca680ddf2 Saul Wold   
 
xf86-video-omapfb 0.1.1+gitrAUTOINC+28c006  0.1.1+gitAUTOINC+   
  Ross Burton
xf86-video-omap   0.4.2+gitrAUTOINC+ae0394  
0.4.3+gitAUTOINC+5d3d49b  Ross Burton
matchbox-panel-2  2.0+gitAUTOINC+26a3a67b41 
2.0+gitAUTOINC+1a7304d6e9 Ross Burton
piglit1.0+gitrAUTOINC+bbeff5d2  
1.0+gitAUTOINC+a68d27e725 Ross Burton
matchbox-desktop  2.0+gitAUTOINC+71e3e6e042 
2.0+gitAUTOINC+09170f41ab Ross Burton
xinput-calibrator 0.7.5+gitAUTOINC+c01c5af  
0.4.1+gitAUTOINC+03dadf5  Ross Burton
presentproto  1.0+gitAUTOINC+24f3a56e54 
1.0+gitAUTOINC+ef84007fc4 Ross Burton
lttng-modules 2.5.0 
2.5.2+gitAUTOINC+b80f1df  Richard Purdie 

glibc-initial 2.20  
28+gitAUTOINC+f80af76648  Richard Purdie 

lttng-tools   v2.5.0
2.5.3+gitAUTOINC+75d9667  Richard Purdie 

tcf-agent 0.4.0+gitAUTOINC+4ef94ec  
8.0+gitAUTOINC+3dddb01fef Richard Purdie 

btrfs-tools   3.14.2+gitAUTOINC+44cdb6  
3.17.3+gitAUTOINC+e4c122  Richard Purdie 

lttng-ust 2.5.0 
2.5.2+gitAUTOINC+85d1d27  Richard Purdie 

glibc 2.20  
28+gitAUTOINC+f80af76648  Richard Purdie 
two glibc plugins are based o...
x264  r2265+gitAUTOINC+ffc3ad4  
r2265+gitAUTOINC+40bb568  Paul Eggleton  
opkg-utils0.1.8+gitAUTOINC+127b371  
0.1.8+gitAUTOINC+53274f0  Paul Barker
mmc-utils 0.1   
0.1+gitAUTOINC+f4eb241519 No Maintainer info
eglinfo-fb1.0   
1.0+gitAUTOINC+223817ee37 No Maintainer info
eglinfo-x11   1.0   
1.0+gitAUTOINC+223817ee37 No Maintainer info
bootchart20.14.6+gitAUTOINC+b65ed4  
0.14.6+gitAUTOINC+3ab811  No Maintainer info
prelink   1.0+gitAUTOINC+faa069deec 
1.0+gitAUTOINC+3ceadf992d Mark Hatle  
gummiboot 43+gitAUTOINC+406

[yocto] [Package Report System]Manual check recipes name list

[package-rep...@yoctoproject.org]

This mail was sent out by Package Report System.
It will list all the recipes which can't check upstream version by script, and 
will show how long it is since their last mannual version check.
You can check the detail information at 
http://packages.yoctoproject.org/manuallychkinfo


PackageName  Version LastChkVersion  LastChkTime
  Maintainer  NoUpgradeReason   
ccache   3.1.9   N/A 41993 d
  Wenzong Fan = 1.10.2 needs ruby  
libxdamage   1.1.4   N/A 41993 d
  Ross BurtonNo data   
python-mako  0.9.1   N/A 41993 d
  Khem RajNo data   
python-numpy 1.7.0   N/A 41993 d
  Khem RajNo data   
python3-distribute   0.6.32  N/A 41993 d
  Khem RajNo data   
libxml-sax-perl  0.99N/A 41993 d
  Kai Kang  
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building clang with Yocto

[Yu, Chan KitX]

Hi guys,

Here's an update FYI. I have managed to get clang sort of working. It compiles 
my sample code but I can't get the binary to execute. ./a.out simply returns:


./a.out: No such file or directory.

I'm sure that a.out exists and weirdly I could get the same binary file to run 
on my build machine. So I guess it could be because of some architecture 
difference but both target and build platform are quite the same (Intel x64 in 
build machine and BayleyBay for target platform) I used valleyisland-64 for the 
target platform so both should be able to execute 64 bit binaries. I suppose I 
can specify some other configuration options there but I have no idea what to 
specify the configure parameter --target= . x64 did not do any good. So 
any idea?

Thanks,
Chan Kit


From: Yu, Chan KitX
Sent: Wednesday, December 10, 2014 11:25 AM
To: Liviu Gheorghisan; Jim Rafert; yocto@yoctoproject.org
Subject: RE: [yocto] Building clang with Yocto

Liviu and Jim,

The thing is I'm trying to integrate LLVM+Clang together in the LLVM recipe. 
The modifications that I made are just adding Clang, compiler-rt and Clang 
tools within the LLVM work directory.  Using this way, I can mimic the original 
way (the one in LLVM website) of installing Clang+LLVM. So there are just two 
recipes; llvm3.3 and llvm-common just like the ones in the OpenEmbedded 
website. I do not know if I can build Clang separately.

Jim, judging from your postbuild script, it would need a RPM based linux system 
to build isn't it?

Chan Kit

From: Liviu Gheorghisan [mailto:liviu.gheorghi...@enea.com]
Sent: Wednesday, December 10, 2014 12:27 AM
To: Yu, Chan KitX; Jim Rafert; 
yocto@yoctoproject.org
Subject: Re: [yocto] Building clang with Yocto

Hello Yu, Jim

I think you can get the clang executable into the SDK installer script with 
something like this:

1. Add this dependency in nativesdk-packagegroup-sdk-host.bb:
RDEPENDS_${PN} += "nativesdk-"

2. In the clang recipe add this install() overwrite for the nativesdk class - 
this will install it into the SDK sysroot:
do_install_class-nativesdk() {
install -d ${D}${bindir}
install -m 0755 clang ${D}${bindir}
}

3. The clang recipe (I don't know if it has a recipe of its own, or it's part 
of the LLVM recipe) should also inherit from nativesdk:
BBCLASSEXTEND = "nativesdk"

Basically this should get your clang executable inside the SDK installer. Sure 
you can add more executables related to clang (like the llvm-related ones) in 
the install_class-nativesdk() function.

- Liviu Gheorghisan
On 12/09/2014 04:36 AM, Yu, Chan KitX wrote:

I **think** I'm just inches away from success. I think I just need to invoke a 
correct install command somewhere in the do_install function but so far I have 
not managed to do so. But right now the alternative way of jamming the compiler 
into the SDK sounds tempting to me.



-Original Message-

From: Yu, Chan KitX

Sent: Tuesday, December 09, 2014 9:19 AM

To: 'Jim Rafert'; yocto@yoctoproject.org

Subject: RE: Building clang with Yocto



Hi Jim,



How did you jam the clang compiler into the SDK tarball?



Chan Kit



-Original Message-

From: Jim Rafert [mailto:j...@spectralogic.com]

Sent: Tuesday, December 09, 2014 1:48 AM

To: yocto@yoctoproject.org; Yu, Chan KitX

Subject: Building clang with Yocto



Hello Chan,



I have been working to a similar goal, to include clang in the toolchain to be 
used for compiling applications to run on the target.  Using clang to compile 
the OS and kernel are not required or  desired by me.



You may get some insight from the thread I started in November on the subject.  
I'm not sure that this contains all of the posts on the subject. You may want 
to search the archive for November.



I have not been successful yet in getting clang actually packaged in the 
toolchain, in the Yocto build,  but at least it builds.  I have a postbuild 
script that takes the built clang compiler from the work directory and jams it 
into the SDK tarball that is embedded in the sdk install script.



-Jim-







From: yocto-boun...@yoctoproject.org 
[yocto-boun...@yoctoproject.org] on 
behalf of yocto-requ...@yoctoproject.org 
[yocto-requ...@yoctoproject.org]

Sent: Monday, December 08, 2014 2:56 AM

To: yocto@yoctoproject.org

Subject: yocto Digest, Vol 51, Issue 26



Send yocto mailing list submissions to

yocto@yoctoproject.org



To subscribe or unsubscribe via the World Wide Web, visit

https://lists.yoctoproject.org/listinfo/yocto

or, via email, send a message with subject or body 'help' to

yocto-requ...@yoctoproject.org

Re: [yocto] Microcontroller Cross Compiler

[彥瑾]

Though it's not the same case, but I use yocto to build the android-system
with the prebuilt bionic toolchain shipped with android manifest.

So generally speaking, you can use prebuilt toolchain with customize
makefile to make building MCU's binary in yocto.

But if you want to use yocto to build the embedded toolchain, there maybe
lots to work.

the recipes I build android-system is here:

https://github.com/aosp-hybris/meta-aosp-hybris/blob/master/recipes-android/android-system/android-system.inc

2014-12-22 6:57 GMT+08:00 João Henrique Ferreira de Freitas <
joa...@gmail.com>:

>
> Hi,
>
> I have the same requirement.
>
> I will try it. But in my case I need to use this
> https://launchpad.net/gcc-arm-embedded.
>
> There are some way to yocto creates the gcc-arm-embedded SDK? Instead of
> use the gcc-arm-embedded packages. Is it feasibly?
>
> Thanks.
>
>
>
> On 19/12/2014 11:21, Andrea Adami wrote:
>
>> On Thu, Dec 18, 2014 at 8:09 PM, Darcy Watkins
>>  wrote:
>>
>>> Hello,
>>>
>>> In my target system I have a microcontroller (MCU) that handles some
>>> I/O, power supplies and system boot up to the point of taking the main CPU
>>> out of reset.  At present, we build the MCU firmware from source and then
>>> the binary file is packaged to be used as payload with an MCU firmware
>>> update utility.
>>>
>>> Now my main question...  does anyone have suggestions (or is there a
>>> 'yocto' way) to build such a cross compiler for the MCU so that it can be
>>> invoked to build MCU firmware from source as part of the bitbake build for
>>> the Linux target's image.  The idea would be to build MCU firmware image
>>> from source using the MCU cross compiler, but obviously to build drivers
>>> and utilities that run on the main CPU using the normal cross-compiler
>>> toolchains built under yocto.  Then I could package the payload firmware
>>> image along with utilities all as part of the same RPM package.
>>>
>>> The MCU cross compiler we use was originally generated using
>>> crosstool-ng, and is essentially a gcc cross compiler for 'bare metal' MCU
>>> target.
>>>
>>> Does anyone who has gone down this road have suggestions?
>>>
>>> Thanks in advance!
>>>
>>>
>>> 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
>>> [P2]
>>> dwatk...@sierrawireless.com :: www.sierrawireless.com ::
>>> www.inmotiontechnology.com
>>>
>>> --
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>> Hi Darcy,
>>
>> if I understand correctly you use the standard toolchain for the
>> target image and a custom $CC to build one custom binary.
>>
>> We use klcc for a couple of klibc-static-recipes thus we created a
>> .bbclass to be inherited.
>> See http://cgit.openembedded.org/meta-openembedded/tree/meta-
>> initramfs/classes/klibc.bbclass
>>
>> Regards
>>
>> Andrea
>>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto