I'm using buildroot to create a linux system for raspberry pi. I want to use the initramfs to enable to system to self-patch. The procedure roughly runs as follows:
Raspi boots, kernel loads initramfs
The initramfs-system (which contains busybox, zsync etc.) connects to a central server and checks if there are boot-file updates available (e.g. a new kernel)
If not, it checks if there is a system update available and downloads that if needed
The downloaded (squashfs) system image is mounted and executed via switch_root
My problem is that I need to compile a secondary busybox (and some more packages) for the initramfs which do not belong in the main system. I currently solved this by manually tinkering with the package files to install into target/initramfs, moving this folder out with pre-build and back in again with post-build, but this seems rather hacky. Additionally, different package types require different types of changes. Is there a better solution to this problem? If one could for example manually overwrite the target directory for each package, this problem would be rather easy to solve.
Create two separate buildroot configurations.
One configuration will have the kernel and the initramfs.
The other configuration only has the squashfs rootfs.
Creating a partial rootfs from a configuration is very tricky, because you have to be sure that you don't miss any shared libraries or other auxiliary files needed by some program.
Note that to speed up the build, you can use ccache and/or use an external toolchain. See the manual.
Related
I am attempting to stand up a VxWorks Workbench version 4.5.2 project into a CM system but am running into issues. I have just started learning VxWorks Workbench. I have searched a bit on how others have done this and I came across two solutions:
Make the project path relative in a sub-directory in the WindRiver home directory.
Do not version Workbench project files and just version my source code. Every client must re-create the Workbench project on their local machine.
The first solution would be ok but I have not been able to make it work. There seems to be some registry (Windows 10) or some path stored elsewhere for Workbench related workspace locations but the end result is the project is not loaded.
The second solution would be a last resort that I would prefer not to do as there are many steps to re-creating a project on a local machine making it tedious and error prone. Does anyone have experience versioning Workbench 4 projects into CM and can share possible solutions?
This can be complicated, and it very much depends on what project type you are talking about.
For DKMs, RTPs, Static and Shared Library projects, you need to version these project files:
.wrproject
.wrmakefile
.cproject
.project
Other project types will have these, but also some additional files that are required to recreate the project, for instance VIP projects also have a <projectname>.wpj file. A conclusive list is too long for this answer however.
You do not need to version the automatically generated Makefile , nor do you need to version the automatically generated build subfolders.
My advice is to store the projects along side your code. I personally prefer to store my projects outside of my workspace, and they should certainly not be stored anywhere in your Windriver installation folder.
I tend to use a structure like this:
c:\gitrepositorys\CuriousCamel\Source\
dkmProject1
.wrproject
.project
.wrmakefile
.cproject
dkm.c
dkmProject2
dkmProject3
vipProject
etc.
The above are all versioned. In terms of the actual Workbench Workspace, I tend to create it in c:\gitrepositorys\CuriousCamel\Workspace and this is explicitly not versioned - I create it fresh for each clone, and often delete and recreate when I switch branch.
Existing projects can be imported into the workspace using the import wizard (using the General->Existing Projects from Filesystem option). When you create a new project, just make sure you choose the "Create Project in external location" option, and select wherever you have chosen to store projects.
I installed Perl6 with rakudobrew and wanded to browse the installed files to see a list of hex-filenames in ~/.rakudobrew/moar-2018.08/install/share/perl6/site/sources as well as ~/.rakudobrew/moar-2018.08/install/share/perl6/sources/.
E.g.
> ls ~/.rakudobrew/moar-2018.08/install/share/perl6/sources/
09A0291155A88760B69483D7F27D1FBD8A131A35 AAC61C0EC6F88780427830443A057030CAA33846
24DD121B5B4774C04A7084827BFAD92199756E03 C57EBB9F7A3922A4DA48EE8FCF34A4DC55942942
2ACCA56EF5582D3ED623105F00BD76D7449263F7 C712FE6969F786C9380D643DF17E85D06868219E
51E302443A2C8FF185ABC10CA1E5520EFEE885A1 FBA542C3C62C08EB82C1F4D25BE7B4696F41B923
522BE83A1D821D8844E8579B32BA04966BAB7B87 FE7156F9200E802D3DB8FA628CF91AD6B020539B
5DD1D8B49C838828E13504545C427D3D157E56EC
The files contain the source of packages but this does not feel very accessible. What is the rational for that?
In Perl 6, the mechanism for loading modules and caching their compilations is pluggable. Rakudo Perl 6 comes with two main mechanisms for this.
One is a file-system based repository, and it's used with things like -Ilib. This resolves modules simply using paths on disk. Whenever a module loaded, it first has to check that the modules sources have not changed in order to re-compile them if so. This is ideal for development, however such checks take time. Furthermore, this doesn't allow for having multiple versions of the same module available and picking the one matching the specification in the use statement. Again, ideal for development, when you just want it to use your latest changes, but less so for installation of modules from the ecosystem.
The other is an installation repository. Here, specific versions of modules are installed and precompiled. It is expected that all interactions with such a repository will be done through the API or tools using the API (for example, zef locate Some::Module). It's assumed that once a specific version of a module has been installed, then it is immutable. Thus, no checks need to be done against source, and it can go straight to loaded the compiled version of the module.
Thus, the installation repository is not intended for direct human consumption. The SHA-1s are primarily an implementation convenience; an alternative scheme could have been used in return for a bit more effort (and may well be used in the future). However, the SHA-1s do also create the appearance of something that wasn't intended for direct manipulation - which is indeed the case: editing a source file in there will have no effect in the immediate, and probably confusing effects next time the compiler is upgraded to a new version.
I use cmake to install a linux driver. To get the kernel version I use CMAKE_SYSTEM_VERSION which should yield the output of uname -r.
However, after I installed a new kernel, I tried to reinstall the driver with cmake, just to note that it was installing to /lib/modules/<previous kernel>/... rather than to the directory for the current kernel. uname- r gives the correct result.
I use the following line in my CMakeLists.txt:
install(PROGRAMS myDevice.ko DESTINATION "/lib/modules/${CMAKE_SYSTEM_VERSION}/kernel/drivers/myDevice" COMPONENT driver)
I could not find CMAKE_SYSTEM_VERSION in the CMakeCache.txt, and just rerunning cmake .. did not do the trick either. I had to regenerate the entire build folder.
I would like to know if there is a better way, since the build folder also contains applications, that should not need rebuilding, just because there is a new kernel.
There are CMake variables, which are fixed since the first configuration. CMAKE_SYSTEM_VERSION is one of them. CMAKE_C_COMPILER is another example of "fixed" variables: changing it invalidates cache completely.
So, you need to make different builds for different kernels.
You may separate configuration and building of user-space application from kernel modules. So rebuilding kernel module doesn't force rebuilding of the applications.
Exactly that approach I have used in my projects: setting one option (introduced with option() command) builds only applications, setting another option builds only kernel modules. By default, none option is set and both kernel-space and user-space components are built.
I am working on a project that is using Leopardboard DM368 interfacing with LI-M024DUAL camera board for stereo vision. The camera uses Aptina's MT09M024 as its image sensor.
After spending a lot of time on the web searching for appropriate drivers I asked the OEM to provide me some support. They provided me with the driver source files. The problem is I am not able to include them to the kernel.
I also looked up for the method to build modules and am fairly comfortable with it. But with the current driver I have a bunch of *.c files that use non-existent header files (I am not able to find these linux header files in the /linux directory).
Now my question is if I have the source code for an image sensor driver and want to build it, what is the general procedure followed for the same.
Any help in this regard would be welcome.
-Kartik
There are two ways to build you module:
1. Statically linking to kernel image (inbuilt)
2. Creating dynamically loadable Modules
Statically linking to kernel image (inbuilt)
For this you must find a appropriate place in kernel folder (somewhere in drivers/) to copy your .c files. copy them there. Edit Kconfig and Makefiles refering to other kernel drivers. and enable the support using menuconfig. Compile.
Creating dynamically loadable Modules
You can built without copying them to Kernel source. Just create a Makefile and place rules in Makefile to compile your module. Here you must link your module to your kernel by providing the kernel source path.
For more google should help.
I would like to use an iron.io worker to stich panoramas and create HDRs using the OpenSource Hugin and libpano13 toolkits. The programs needed are all command-line (no GUI is needed) but I'm not entirely sure how I go about building a worker that includes the correct binaries for using the Hugin panotools.
Can I pre-compile the right binaries for the iron.io worker OS (Ubuntu Linux)? I can create a VM and install Ubuntu on it to get a set of binaries built that I include in my worker. But is there a better way using the "build" directive in the worker file? The problem I see right away is that Hugin is a cmake-based build so I'd need to create something that uses autoconf/automake, right?
I don't really need all of Hugin, either. I just need the control point finder utility and the enfuse/enblend utilities for doing the actual stitching. I don't need any of the GUI stuff, which is wxWidgets based.
Can anyone shed light on how I would go about this? Thanks!
You really need only statically compiled x64 binaries, find them anywhere - and you're done.
Possible solutions:
Install stuff on local Ubuntu x64 (IronWorker using 12.04 TLS x64) and include required files into worker's package (which is just .zip file after uploading) (and probably extend PATH at start of a worker)
Use build command to do any installation procedures remotely (you're still limited to non-root operations though)
Use deb command to install existing .deb packages.
.worker file example (including custom version of imagemagick):
runtime 'binary'
exec 'run.sh'
full_remote_build true
deb 'http://mirror.pnl.gov/ubuntu//pool/main/i/imagemagick/libmagickcore5_6.7.7.10-2ubuntu4_amd64.deb'
deb 'http://mirror.pnl.gov/ubuntu//pool/main/i/imagemagick/libmagickwand5_6.7.7.10-2ubuntu4_amd64.deb'
deb 'http://mirror.pnl.gov/ubuntu//pool/main/i/imagemagick/imagemagick_6.7.7.10-2ubuntu4_amd64.deb'