So, I am currently trying to get a hold on Open Embedded to build for an i.MX53 platform, but i have some difficulties in understanding the main outline of the OE concept, as well as how the folder structure should be, gaining an upper view.
So, I was hoping someone could in a few words summarize why not just using the make command in the kernel root.
more importantly(for me ), i would like to know how the folder structure should be, having a Oe-core and the meta-fsl-arm layer built for an i:MX53QSB.
Which file am I supposed to run with bitbake to get a custom image for my device?
you should start building some bitbake example recipes, if you hace success with this you should move forward to build your own images. look for the configuration scripts for angstrom, they will help you for setting up some things like architecture and deploy platform. After all these stuff you should put your custom image in your openembedded images folder and execute:
bitbake my_image
Start with this link It is a comprehensive study of the Yocto Open Embedded project. Yocto is a ready-to-go subset that is known to work and is a good place to start.
This link shows you the directory hierarchy.
Related
I trying to figure out how to make a Spectrum Distribution (+3dB/oct) graph from my music files.
Currently there are a free online mastering service which outputs this graph when you master a music. It's this free service. But you need to upload and master a song every time to get it.
I know there are free vst plugins which can do this, but you need to manually record the sound, and it does not analyze whole files.
Are there any linux programs which can do this, preferably +3dB/oct or 4.5dB/oct ?
I tried free vst plugins but you can't process whole folders with that.
EDIT: Okay now i think i found the source code of this graph, but i have no idea how to use this code. Could someone help with that? I am very new to programming.
SOLVED! You need to use the audio analyzer file in the github link i linked. It's working. Then you can write a script to batch process folders. You can find the build on the github page. You need to use the -spectrum_distribution_output "PATH.png" to output the image to a folder.
Source code
I am try to learn Yocto.I read the files on the website of Yocto.It is confusion that what is the difference between images and recipes?
A recipe is a module/program configuration (e.g. config for building and installing into OS our desired libraries or programs like SSH services or nano editor). Image - is a resulting OS image ready for deployment onto e.g. USV stick or NAND.
Recipe - All software/library should be described for Yocto Project via bitbake to process it: Download, decompress, patch if necessary, compile, and package (.deb, .ipk, .rpm)
Image - Includes all the recipes you want to install, example (openssh, picocom, python3, ...) in addition to being able to automate the image with Hostname, configured IP, startup scripts. The image would already be the end result of Bootloader + Kernel + Rootfs (your installed applications and programs). In addition to many other customizations for the OS at startup, different File Systems and etc.
Recipes are the most common file type in a Yocto build description. They contain instructions on how to configure, compile and deploy a given piece of software. Recipes also contain the location of the source code. This location can either be a static release archive, or a reference to a Git repository. Custom modifications to the sources themselves or the build process can be provided in form of patches. To minimize repetition for common tasks in recipes, such behavior is encapsulated in recipe class files, from which recipes can inherit.
Image contains all packages which have to be built and installed into the final root file system. The build system will take care that any known dependent package will also be installed. The end goal for anyone using the Yocto Project should be to create a Linux distributions that is customized to match your product(s) requirements. Images are a central concept within the Yocto Project and essential to the definition of a Linux distribution.
I just try to set up Valves Source SDK 2013 for Linux but I need to say that I find the wiki + documentation rather confusing and partly heavily outdated (Windows-only instructions, only for GoldSrc / pre-20XX SDk etc.).
I hope that someone who already has gone through the hassle can supply me with some hints on how to correctly set up the system.
I tried to use some Windows-specific instructions to understand the system but some are highly platform-specific.
So here is the current status (I based what I did on this wiki page: Wiki: Source SDK 2013:
The source of the SDK SDK 2013 from GitHub is cloned to
~/Git/source-sdk-2013/
the SDK Base 2013 installed via Steam and the steam-runtime to
~/working/steam-runtime-sdk_2013-09-05/
I was not sure whether there is a specific path I should put the steam runtime into so I just put it into my self-created working dir.
# Create a Multiplayer sample project
export SDKROOT="~/Git/source-sdk-2013"
bash $SDKROOT/mp/src/creategameprojects
bash $SDKROOT/mp/src/createallprojects
# Setup Steam Runtime
export STEAMRT="~/working/steam-runtime-sdk_2013-09-05/"
cd $STEAMRT
# Choose all build targets (i386 + amd64) and download these
./setup.sh
# Set current to target to the same as host machine (ie. amd64)
./shell.sh
# Compile the actual game
make -f $SDKROOT/mp/src/games.mak
I have not yet touched any source files as there's plenty of sources already supplied. I just wanted to confirm having a working toolchain set up
This all compiles fine but in the end the script wants to chmod the client.so and server.so but claims "not found" – but it sadly does not provide any information where it searched for them. Actually these are existant in
$SDKROOT/mp/game/mod_hl2mp/bin
and even marked as executable (-rwxr-xr-x).
So I just ignored this and hoped for the best. The next line to me sounds a bit strange:
At this point you should have client.so and server.so files to load with the Source SDK Base 2013 of your choice.
So I should be able so load the files with "the Source SDK Base 2013" (of your choice?!? Valve is the only one providing it O.o). How am I supposed to do that? I have not found any hint whatsoever for that, sadly.
But they hint me to the README.txt of the steam-runtime which tells me to do this:
run.sh ./MyGame
But where's the executable? I only have .so's
And this is the point where I currently am. I'm quite confused as I have many questions now:
Why do only the Linux users need to download the steam runtime? What if I want to not ship via Steam?
Is that chmod failure a script failure or a mistake in my directory setup?
How do I load these libraries via the SDK Base
Where is the binary? I'm quite confused here...
Have I overlooked something?
I appreciate any hints or links to resources, maybe explanations when I just were to dumb to understand what they mean :P
EDIT: Actually there is a GitHub repo for the steam-runtime too (GitHub/steam-runtime) – why is the download so outdated, the git repo has some updated stuff going on. Which should one choose?
With the help of a friend I didn't expect to be able to answer this (he didn't know about Linux but we could figure it out) I could solve it faster than expected.
To "load" the game via the Steam SDK Base just append the -game parameter and point it to the directory with the gameinfo.txt (ie. $SDKROOT/mp/game/mod_hl2mp/) in it.
Alternatively just copy the contents of this directory to
~/.local/share/Steam/steamapps/sourcemods/$MYSOURCEMOD
where $MYSOURCEMOD is how you want to call it (do not use spaces). Then add a steam.inf file in that dir with following content:
appID=243750
ProductName=$MYSOURCEMOD
PatchVersion=1.0.0.0
After a restart Steam will be able to find the sourcemod.
I'm not quite sure what the "steam-runtime" thingy is but I suppose it is to set up the build environment (to use a custom gcc etc.) as this is how the scripts look like. I'm not sure why you should run the game via the run.sh in the bin/ subfolder of the runtime instead of via Steam or via the parameter one the Source SDK Base but maybe someone can enlighten me here.
The archive one shall download is only a downloader/configurator for the steam-runtime hosted on GitHub.
The need
Recently I've started flirting with the idea of making my own customized Debian live distro. My aim is to have an USB stick with Debian, specific packages, custom scripts and files installed inside. In this way, I can take my OS with everything I need to work with without taking my laptop with me. Furthermore, It will be specially useful in case I just wanted to replicate the OS without the hassle of installing every single packages and further customizations over again.
The research
So I decided to go for it and educate myself on the subject. I've found the Linux from scratch project (LFS), but to be honest, it will take me lots of time I currently cannot afford to invest (But seriously thinking for the future).
I decided to use the live-build project scripts based on the instructions and examples of their manual. http://live.debian.net/manual/3.x/html/live-manual.en.html
The problem
So far, I've built a hybrid.iso image with a custom selection of packages by specifying them in the /config/packages-list/mylist.list.chroot.
Then I tried to copy my custom scripts, files and software inside specific folders under the chroot directory just created,
i.e.
mkdir chroot/etc/skel/<custom dir here>
or
cp <some file or script> chroot/usr/local/bin/
and then run
lb build binary
The problem is that the iso doesn't get built after the first time I run lb build and the customizations done on the chroot directory are deleted every time I try to build it again.
I've tried...
lb clean --binary
lb clean --stage
lb build binary
or
lb build binary iso
So what am I missing? How can I add custom files, folders, scripts to my custom live Debian without downloading every single package over again?
why isn't the iso image built again after the first time I run lb build?
Thanks in advance...
P.D: I decided to be very detailed on the writing so anyone could understand, specially those that want to try the same...
I am conscious about LFS too. But, this
My aim is to have an USB stick with Debian, specific packages, custom
scripts and files installed inside.
and this
it will take me lots of time I currently cannot afford to invest
made me pointing to my answer
I have two suggestions. The easy one, use tools like remastersys or live-magic.
Follow this link.
The difficult one, follow the official documentation to how to creat a custom debian cd.
Debian official doc
This answer comes a year late for the original poster, but for future searchers: don't add files directly to the chroot. Instead, make a folder structure in config/includes.chroot. Then your customizations will be retained when you rebuild the image.
See the section "Live/chroot local includes" in the debian-live manual: http://live.debian.net/manual/4.x/html/live-manual.en.html#506
I am following the instructions here:
http://www.rocketboards.org/foswiki/Documentation/AlteraSoCDevelopmentBoardYoctoGettingStarted
I run this command
bitbake virtual/kernel
Everything works fine except it does not create a socfpga_cyclone5.dtb
I run this command, which should be the same
bitbake altera-image
And I get the error
ERROR: Multiple .bb files are due to be built which each provide virtual/kernel (/home/bobo/yocto/meta-altera/recipes-kernel/linux/linux-altera_3.11.bb /home/bobo/yocto/meta-altera/recipes-kernel/linux/linux-altera-dist.bb).
This usually means one provides something the other doesn't and should.
Does anyone know how to create that .dtb file or fix the second command? Up to that point I had no errors.
Ideally your .dtb file should be coming from the Altera software flow through Qsys and that is the one you should use, rather than the one that is created from the Yocto build system.
The Yocto build system will not be aware of the FPGA design and hence that .dtb won't be useful.
The error you're getting is mostly due to conflicting meta files. Sometimes a target might have multiple providers. A common example is "virtual/kernel", which is provided by each kernel recipe. Each machine often selects the best kernel provider by using a line similar to the following in the machine configuration file, which should be somewhere in
poky/meta-altera/conf/machine/your-machine.conf:
PREFERRED_PROVIDER_virtual/kernel = "linux-altera-3.11"