[yocto] help
Suneetha Lakshmi G
suneetha.g at tataelxsi.co.in
Fri Mar 10 06:25:04 PST 2017
Hi All,
Im new to yocto and trying to build for my customer device im facing this issue.
| arm-linux-gnueabi-xgcc: error: unrecognized command line option '-mgeneral-regs-only'
| arm-linux-gnueabi-xgcc: error: unrecognized command line option '-mcmodel=large'
| make: *** [opkg-compare-versions] Error 1
| ERROR: oe_runmake failed
Please guide how to progress further.
Regards,
Suneetha
________________________________
From: yocto-bounces at yoctoproject.org <yocto-bounces at yoctoproject.org> on behalf of yocto-request at yoctoproject.org <yocto-request at yoctoproject.org>
Sent: Friday, March 10, 2017 7:20 PM
To: yocto at yoctoproject.org
Subject: yocto Digest, Vol 78, Issue 45
Send yocto mailing list submissions to
yocto at 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-request at yoctoproject.org
You can reach the person managing the list at
yocto-owner at yoctoproject.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of yocto digest..."
Today's Topics:
1. Re: Raspberry Pi2 Fails to boot into LXDE. (Steve Plant)
2. Re: update mechanisms (Kristian Amlie)
3. Proposal: dealing with language-specific build
tools/dependency management tools (Alexander Kanavin)
----------------------------------------------------------------------
Message: 1
Date: Fri, 10 Mar 2017 13:31:40 +0000
From: Steve Plant <steove at hotmail.com>
To: Gary Thomas <gary at mlbassoc.com>
Cc: "yocto at yoctoproject.org" <yocto at yoctoproject.org>
Subject: Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.
Message-ID:
<SG2PR0301MB20164F99A2AF83AFC01ECDCFD1200 at SG2PR0301MB2016.apcprd03.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Thanks Gary,
You where spot on! I have now been able to SSH into the rpi and have posted the Xorg.log file to the mailing list.
I think Xorg is failing to load correctly because it cannot find the evdev module. Looking into how to fix this now......
Regards, Steve.
________________________________
From: yocto-bounces at yoctoproject.org <yocto-bounces at yoctoproject.org> on behalf of Gary Thomas <gary at mlbassoc.com>
Sent: Friday, 10 March 2017 5:42 a.m.
To: yocto at yoctoproject.org
Subject: Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.
On 2017-03-10 01:55, Steve Plant wrote:
> OK, I have spent the last day googling my heart out trying to find the Xorg.log file without any luck.
>
>
> The problem is that due to the rpi hanging on boot, the only way I can access the SD card to look for the file is place
> it in a USB SD card reader and use my VirtualBox based Debian to "ls" directores etc.
>
> Having established that there is no file located at /var/log/Xorg.log (there isn't a log directory) but there is a
> symbolic link in the var directory - goes nowhere.
>
>
> After goggling I discovered that the file could also be in the ~/.local/share/xorg/Xorg.0.log, however if I try to look
> there I get "permission denied" and cannot seem to get to the root directory of the card and I can't find a way around
> this as I'm trying to access this directory through the USB card reader.
>
>
> Looked everywhere with no answers, Is there anyone who could help me here??
/var/log is on a volatile file system (i.e. it does not live on the SD card)
If you can get into your board via SSH, you can copy the file and send it
> ------------------------------------------------------------------------------------------------------------------------
> *From:* Khem Raj <raj.khem at gmail.com>
> *Sent:* Wednesday, 8 March 2017 5:17 p.m.
> *To:* Steve Plant
> *Cc:* yocto at yoctoproject.org
> *Subject:* Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.
>
> On 17-03-08 12:40:51, Steve Plant wrote:
>> Hi All,
>>
>>
>> Very new to all this linux world, and especially Yocto.
>>
>>
>> I'm working on a embedded project at the moment using a raspberry pi2 board.
>>
>>
>> I have used toaster with Morty 2.2 to compile an image using"rpi-basic-image", to this I have added the following bitbake variables:
>>
>> Bitbake variables
>>
>> DISTRO
>> poky
>> DL_DIR
>> /home/steve/poky/downloads
>> IMAGE_FSTYPES
>> ext3 jffs2 tar.bz2 rpi-sdimg
>> IMAGE_INSTALL_append
>> packagegroup-core-x11-base packagegroup-lxde-base connman
>> PACKAGE_CLASSES
>> package_rpm
>> SSTATE_DIR
>> /home/steve/poky/sstate-cache
>>
>> DISABLE_OVERSCAN
>> 1
>> GPU_MEM_1024
>> 512
>>
>> I have dd'ed the image to an SD card increased the sdb2 partition to the max size and powered up the rpi. Everything looks fine to start with, as it displays the four raspberrys in the top left, then the white "Yocto Project" splash screen complete with small blue dot to the side appears, the progress bar moves across to 100 percent, then the screen turns black with a white
> cursor in the middle and it appears to freeze with only a very dim one second flash of the "act" led.
>>
>>
>> I have then connected the 7" touchscreen and apart from the added multicolored square at the very beginning I get the exact same boot up problem, hangs on the black screen with white cursor (good to see its all resized correctly for the TfT through!!)
>>
>>
>> Before adding the packagegroup-core-x11-base and packagegroup-lxde-base I successfully copied over and ran the rpi-basic-image with no problem, ending up with a usable console.
>>
>>
>> Looking for any help here, I'm thinking I've missed adding a package, or some type of local.conf instruction. any suggestions would be appreciated.............
>
> Can you send the content of /var/log/Xorg.log file ?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
_______________________________________________
yocto mailing list
yocto at yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
yocto Info Page<https://lists.yoctoproject.org/listinfo/yocto>
yocto Info Page<https://lists.yoctoproject.org/listinfo/yocto>
lists.yoctoproject.org
Discussion of all things about the Yocto Project. Read our Community Guidelines or learn more about how to participate in other community discussions.
lists.yoctoproject.org
Discussion of all things about the Yocto Project. Read our Community Guidelines or learn more about how to participate in other community discussions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20170310/74aab5d4/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 10 Mar 2017 14:35:02 +0100
From: Kristian Amlie <kristian.amlie at mender.io>
To: Patrick Ohly <patrick.ohly at intel.com>, Eystein M?l?y Stenberg
<eystein at mender.io>
Cc: yocto at yoctoproject.org
Subject: Re: [yocto] update mechanisms
Message-ID: <0135756b-1d20-a743-4f82-8f45becea106 at mender.io>
Content-Type: text/plain; charset=utf-8
On 10/03/17 14:02, Patrick Ohly wrote:
> On Wed, 2017-03-01 at 16:35 -0800, Eystein M?l?y Stenberg wrote:
>> On Tue, 2016-12-06 at 10:45 +0100, Patrick Ohly wrote:
>>> On Tue, 2016-12-06 at 10:01 +0100, Stefano Babic wrote:
>>>> Hi Patrick,
>>>>
>>>> On 30/11/2016 15:59, Patrick Ohly wrote:
>>>>> I've started a Wiki page
>>>>> https://wiki.yoctoproject.org/wiki/System_Update - rudimentary at the
>>>>> moment, but might as well be mentioned already now.
>>>>
>>>> I have seen Mariano added an entry for SWUpdate, too, thanks - I would
>>>> like to edit for better explanation on some parts. Should I try to edit
>>>> directly the page or is it better to discuss it here ?
>>>
>>> Use your own judgment. If its uncontroversial, the feel free to edit the
>>> page directly, otherwise let's discuss it here.
>>>
>>> If feel that putting information directly into the table is too limiting
>>> (it should be brief), then feel free to start a complete section about
>>> SWUpdate.
>>>
>>> I'll do the same for swupd. Editing the sections should be possible
>>> without conflicts, we just have to be more careful about editing the
>>> table concurrently.
>>
>> I updated the Mender part of the wiki now that the stable version Mender
>> 1.0 is released. These changes should not be controversial, but let me
>> know if you disagree. We are planning to keep the Mender section
>> up-to-date as we release new versions, as I think this is what you expect.
>
> Yes, that's useful.
>
>> Are there any plans for next steps or is the wiki the "final state" in
>> terms of integrating OTA updates in Yocto/OE?
>
> My own conclusion is that it is impossible to integrate a specific OTA
> update into Yocto/OE (because there's no single solution that fits all
> requirements) and/or it would be unfair to those solutions that don't
> get such special testing. In that sense the Wiki page is the final
> result of the investigation. Anyone interested in picking a solution can
> go there, consider the pros and cons, and then make a choice.
Makes sense. We can always revisit this at a later point, if one method
starts to emerge as the preferred option for most people.
> However, I see room for some collaborative work that then can happen in
> Yocto/OE:
> * carrying local system configuration changes across system
> updates: I find it promising to investigate the "stateless"
> concept and have started some exploratory work, see
> https://wiki.yoctoproject.org/wiki/Stateless#Status_and_goals_for_.22stateless.22_in_Yocto (more on that soon)
What's the relation (if any) between this and a read-only rootfs?
Also this may be only vaguely related, but I have it in my queue to
finish the built-in partitioning of rootfs images [1], which will help
divide the filesystem into a stateful and a stateless part. The wic part
is done [2], but ext4 images are not covered yet.
[1] It works by choosing which sub directories of the complete rootfs
you want on each partition.
[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=10712
> * supporting UEFI-based machines
Great, this is something we are interested in as well!
--
Kristian
------------------------------
Message: 3
Date: Fri, 10 Mar 2017 15:49:01 +0200
From: Alexander Kanavin <alexander.kanavin at linux.intel.com>
To: openembedded-architecture at lists.openembedded.org, Yocto Project
<yocto at yoctoproject.org>
Subject: [yocto] Proposal: dealing with language-specific build
tools/dependency management tools
Message-ID: <37d4f98c-9102-f4bf-c6cc-f64e1ffbce40 at linux.intel.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hello all,
*Introduction*
The new generation of programming languages (think node.js, Go, Rust) is
a poor fit for the Yocto build model which follows the traditional Unix
model. In particular, those new development environments have no problem
with 'grabbing random stuff from the Internet' as a part of development
and build process. However, Yocto has very strict rules about the build
steps and what they can and can not do, and also a strict enforcement of
license and version checks for every component that gets built. Those
two models clash, and this is a proposal of how they could be reconciled.
I'll also send a separate email that talks specifically about MEAN stack
and how it could be supported as Yocto - take it as a specific example
for all of the below.
*Background*
The traditional development model on Unix clearly separates installation
of dependencies needed to develop a project from the development process
itself. Typically, when one wants to build some project, first the
project README needs to be inspected, and any required dependencies
installed system-wide using the distribution package management's tool.
When those dependencies change, usually this manifests itself in a
previously unseen build failure which is again manually resolved by
figuring out the missing dependency and installing it. This can be
awkward, but it's how things have been done for decades, and Yocto's
build system (with separate steps for fetching, unpacking, building,
packaging etc.) is built around the assumption that most software can be
built this way.
Unfortunately, this situation is changing. The new development
environments, such as Go, Rust or node.js see this approach as
cumbersome and getting-in-the-way for developers. They want projects'
setup to be as quick and automatic as possible - and it should also be
cross-platform. So each such environment comes with a specialized tool
which handles installation of dependencies and bypasses the distribution
package management altogether. Typically these dependencies are fetched
from the Internet and installed into the project tree. The details are
hidden; it's assumed that developers don't want to know or care. In
particular, specific versions of dependencies can be only weakly
specified or ignored altogether (that is, the latest commit is always
fetched), licensing is totally overlooked, a list of what was installed
cannot be trivially obtained, and repeating the procedure the next day
may result in a different set of code being pulled in, because someone
somewhere added a commit to their github repo.
This does not work well in Yocto context. Yocto project prides itself on
being specific and exact about what gets build, how it gets built and
what license is attached to each component. So we need to somehow
enforce that with the new model, and avoid the situation where separate,
incompatible, and difficult to grasp solutions are developed for each
language environment.
*Design considerations*
1. I would like recipes to remain short and sweet and clear. In
particular, node.js projects can pull in hundreds of dependencies; I
want to keep their metadata out of the recipe and somewhere else, for
readability, clarity, and maintainability.
2. I don't want to implement custom fetchers, or otherwise re-implement
(poorly) those language-specific build and dependency management tools.
Let's use npm, cargo and go as much as we possibly can and let them do
their job - yes, that also includes them fetching things from the
internet for us.
3. When things need to be updated to a new version, manual editing of
metadata should be avoided: when there are hundreds of dependencies, a
tool should modify the metadata, and human should only inspect the changes.
*How do we deal with this?*
By introducing a lockdown file that lives next to the recipe. The
concept is already implemented in npm, but needs to be made generic and
come with a common API that is using the file to verify the build.
*What is a lockdown file?*
The file captures all of the recipe dependencies that are pulled in by
the build tool. For each such dependency the following information is
provided (this is really similar to what is in recipes, and that is on
purpose:
- name
- description (optional)
- verification data (this is specific to each language, but can be
version, git commit id, a checksum and so on). The only requirement is
that it maps to a unique set of code.
- license string
- license file path
- license checksum
*How is the lockdown file used?*
1. It needs to be generated in the first place when adding a new recipe.
For example:
bitbake -c generate_lockdown recipe
would fetch and unpack the recipe code, then run npm/cargo/go to pull in
the dependencies, then walk the project tree and generate the lockdown
metadata. Sometimes the tools can help here somewhat, but other times
they can be used only for fetching, and verification data has to be
figured out by inspecting the tree with our custom-written code. This is
the hard part that we have to deal with.
2. It can be used to perform a 'loose' build of the recipe that does not
guarantee reproducibility.
We have to accept this: some projects just don't care about it, and
offer no support to those who want reproducibility. We should at least
provide a way to build such projects in Yocto. The information in
lockdown file is not enforced; it's merely compared against the actual
build and any differences presented to the user as warnings. This is a
recipe setting.
3. It can also be used to perform a 'strict' build of the recipe that
enforces what is in the lockdown file.
The information in the lockdown file is given to the language-specific
tool to help it fetch the right things (whenever the tool makes it
possible), and then is used to compare to what was fetched, but this
time any mismatches stop the build. Exactly how this happens is specific
to each language, and again, it is the hard bit that we need to deal with.
4. When a recipe is updated to a new version, the lockdown file needs to
be updated as well.
One possibility is to generate a new lockdown file (as in point 1), and
then a human can compare that against the old lockdown file.
bitbake -c update_lockdown recipe
5. Packaging
Go by default is compiling everything into a static executable, so there
are no separate packages. All dependencies' licenses should be rolled
into the package: lockdown file tells what they are and where they are
in the build tree.
Other environments do install the dependencies somewhere in the system,
so those should be packaged separately: lockdown file is used to get a
list of them and attach licenses to them. Installation paths (things
that FILES_ is set to) should typically be easy to figure out from
dependency names.
*Conclusion*
This is only a preliminary idea: I understand that the devil is in the
details, and there are plenty of details where things may not work out
as planned, or there's something else I didn't think of that should be
accounted for. So flame away!
------------------------------
--
_______________________________________________
yocto mailing list
yocto at yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
End of yocto Digest, Vol 78, Issue 45
*************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20170310/47a4e620/attachment.html>
More information about the yocto
mailing list