I am new to contiki os, I tried to compile and run hello-world.c file located in examples directory in contiki os 3.0. But I got the error,
hello-world.c:40:21: fatal error: contiki.h: No such file or directory".
I tried this in root user.
Any kind of help to run very beginner program in contiki is appreciated.
Use the make command to build Contiki. Doing that invokes architecture-specific version of gcc with compiler flags pointing to the the proper header file paths:
By default, make is going to build for the "native" platform (that is, x86) and create an application image that is executable on the host PC.
To build for a specific hardware platform, set the TARGET variable. For example, to build for Tmote Sky/TelosB nodes:
make TARGET=sky hello-world
To build and run for the native platform:
make
Output:
TARGET not defined, using target 'native'
mkdir obj_native
...
CC hello-world.c
LD hello-world.native
rm hello-world.co
To run it:
./hello-world.native
Output:
Contiki-3.x-1457-g552408b started with IPV6, RPL
Rime started with address 1.2.3.4.5.6.7.8
MAC nullmac RDC nullrdc NETWORK sicslowpan
Tentative link-local IPv6 address fe80:0000:0000:0000:0302:0304:0506:0708
Hello, world
Thanks for all, who helped to answer my question. Finally, I am able to run first hello-world program in Contiki OS. I have use the following code syntax.
$cd contiki
$cd examples/hello-world
$make TARGET=native
To run the compiled code use the following code.
$ ./hello-world.native
Out put:
Contiki 3.0 started with IPV6, RPL
Rime started with address 1.2.3.4.5.6.7.8
MAC nullmac RDC nullrdc NETWORK sicslowpan
Tentative link-local IPv6 address fe80:0000:0000:0000:0302:0304:0506:0708
Hello, world
Related
I'm trying to compile a program with the mbed CLI using the following command:
mbed compile -m UBLOX_C027 -t ARM
It results in the following error:
make.py: error: Could not find executable for ARM.
Currently set search path: No path set
How can I set the executable?
I know I am way too late but still if anyone is facing the same problem.
I solved it in this way in MAC OS.
Download GCC_ARM for MAC OS from here: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
Extract it in some location and set the path using mbed cli:
mbed config -G GCC_ARM_PATH "/Users/amod-mac/Desktop/gcc-arm-none-eabi-7-2017-q4-major/bin"
Two ways, either:
Set ARM_PATH in mbed_settings.py in the root folder of your project.
Or make sure that ARMCC is in your path.
Note that ARM compiler target is for the commercial ARM compiler. If you're using GCC ARM use the GCC_ARM target.
I want to test DTLS libraries on two K64F board with ARM Mbed OS. I have just created a new project:
mbed new .
I have created a folder called source and copied there dtls_client.c obtained from the mbeddtls project page. I have changed the value of the SERVER_ADDR constant.
I have repeated this process with dtls_server.c file.
Both project compiled without errors.
mbed compile -m K64F -t GCC_ARM -c
I copied each bin file to a different board but when I connect to them through the putty terminal I cannot see anything. I have been using this connection with the rest of my programs and it works. I think It may have something related to connection (now it is 115200).
I see that the code uses a mbedtls_printf function to print messages. I have tried inserting some printf traces but I don't see them either. How should I set the terminal to be able to see something?
#jordi,
Baudrate of 115200 should be OK for K64F.
You should verify that you have DEBUG_LEVEL set to a value higher than 0, and that Mbed TLS is compiled in debug mode.
Please compile your application with the following command:
mbed compile -m K64F -t GCC_ARM -c --profile=mbed-os/tools/profiles/debug.json
In addition, you should verify that your configuration file has MBEDTLS_DEBUG_C configured
When I try to add it to sources as per debian install instructions I get this error. I'm guessing this means that there are no arm packages for it.
Failed to fetch https://dist.crystal-lang.org/apt/dists/crystal/InRelease Unable to find expected entry 'main/binary-armhf/Packages' in Release file (Wrong sources.list entry or malformed file)
I'm guessing I probably need to install it from source. How would I go about doing that with an arm cpu? When I check it out and run make I get the error:
You need to have a crystal executable in your path! Makefile:113:
recipe for target '.build/crystal' failed make: *** [.build/crystal]
Error 1
Any suggestions would be greatly appreciated.
EDIT: There's now a semi-official repository for crystal on raspbian, check it out here: http://public.portalier.com/raspbian
Crystal doesn't build Debian packages for ARM, and you're correct in that you'll need to build from source.
However, the Crystal compiler is written in Crystal. This presents the obvious problem of how to get a compiler to build the compiler. The answer is cross-compilation: building an arm binary on a x86 desktop computer and copying it across.
Here's a quick step-by-step based on my memory of last time I cross-compiled:
Install Crystal on a x86 desktop PC, and check it works.
Install all required libraries on the desktop and Raspberry Pi. You'll need the same LLVM version on the Raspberry Pi and desktop. This is probably the hardest and longest step. You can install llvm 3.9 from debian testing for ARM, see this stackoverflow post for how to install only LLVM from debian testing.
Check out the sources from git on both computers, and run make deps.
Cross-compile the compiler by running this command in the root of the git repository:
./bin/crystal build src/compiler/crystal.cr --cross-compile --target arm-unknown-linux-gnueabihf --release -s -D without_openssl -D without_zlib
This command will create a crystal.o file in your current directory, and also output a linker command (cc crystal.o -o crystal ...).
Copy crystal.o to the raspberry pi, and run the linker command. Be sure to edit the absolute path to llvm_ext.o so that it points to the Crystal checkout on your Raspberry Pi, not the checkout on your desktop. Also make sure that all references to llvm-config in the command are for the correct LLVM version. For example, changing /usr/local/bin/llvm-config to llvm-config-3.9 on Raspbian.
Run the crystal executable in your current directory (./crystal -v) and make sure it works.
Ensure to set CRYSTAL_PATH environment variable is set to lib:/path/to/crystal/source/checkout/src so that the compiler can find the standard library when compiling applications.
I would ultimately like to modify and compile the existing Linux USB storage driver and test it. For the first step, I wanted to compile the module as is.
I downloaded the latest Linux kernel (version 3.12) and extracted it to ~/linux-3.12.
I found the driver I wanted to compile: drivers/usb/storage, but when I ran make, I got the following error:
make: *** No targets. Stop.
I found many guides online, but none of them worked for the USB storage driver. All I want is to compile this one module and get the .ko so I can test it out.
NOTE: I'm running Ubuntu 13.04 64-bit, and uname -r outputs 3.8.0-30-generic - I'm not sure if that's the problem, but I managed to compile the whole Kernel before. I don't want to do that now because it takes an eon.
If you wanted to build the drivers/usb/storage module you would do this:
make M=drivers/usb/storage
from the root directory of the kernel tree. Before doing so, you will need to make sure that your configuration is the same as the config of the running kernel.
You can't simply take the source code for one kernel and use it to build modules for another one. The module needs to be built from the same source and with the same configuration as the kernel itself.
Basically, you need to find the source code for the Ubuntu kernel you're running. In Ubuntu, as in Debian, that can be done with 'apt-get source '. The package name is probably something like 'linux-image-3.8-2-amd64'.
Once you have the source code you need to find the configuration of your running kernel. Fortunately Ubuntu keeps that in /boot/config-3.8-....
Copy that config to your kernel source tree as .config and run 'make oldconfig'. Now you should be able to build the module (assuming it's not already built into your kernel!).
I have an OLinuXino board. I downloaded the ArchLinux img file (ArchLinuxARM-2013.02-olinuxino-rootfs.img) and wrote it to the SD card using dd and booted the board using the card. I connected the board to the internet using ethernet and installed gcc and make on it using pacman. I was able to build userspace program for the board o n the board.
The ArchLinux SD card image already had the kernel headers directory in the rootfs (/lib/modules/linux-3.7.2-2-ARCH/build). And so I was able to build loadable kernel modules for the board on the board itself too.
I have an Ubuntu 12.04.1 development PC. I have installed Sourcery CodeBench Lite for ARM GNU/Linux (arm-2012.09-64-arm-none-linux-gnueabi.bin) on it. I am able to cross compile userspace programs for OLinuXino on this development PC and transfer it to the board over SFTP and run it on the board (using console over ttyAMA0 Serial port).
Now I want to cross compile kernel modules for the OLinuXino board. I have done this earlier for another custom build imx233 board - in that case I had configured the kernel build system (LTIB) to leave the kernel sources and rootfs intact after building the image. That way I was able to specify the kernel headers build directory for cross compiling the kernel module and it worked.
This time for OLinuXino I don't have the build sources so I copied the rootfs (using cp -dR) to my Ubuntu PC and tried cross compiling a hello world kernel module by specifying the kernel headers directory as /lib/modules/linux-3.7.2-2-ARCH/build and it threw the following error:
anurag#anurag-VirtualBox:~/HelloKS$ make
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -C /mnt/ArchOL/lib/modules/3.7.2-2- ARCH/build M=/home/anurag/HelloKS modules
make[1]: Entering directory `/mnt/ArchOL/usr/src/linux-3.7.2-2-ARCH'
CC [M] /home/anurag/HelloKS/khello.o
/bin/sh: scripts/basic/fixdep: cannot execute binary file
make[2]: *** [/home/anurag/HelloKS/khello.o] Error 126
make[1]: *** [_module_/home/anurag/HelloKS] Error 2
make[1]: Leaving directory `/mnt/ArchOL/usr/src/linux-3.7.2-2-ARCH'
make: *** [all] Error 2
The fixdep binary in the scripts folder was precompiled for ARM, so I deleted the binary and recompiled it for x86 and placed it there. When I tried cross compiling the kernel module again, a similar error was thrown complaining about another executable in the scripts folder (this time modpost).
My question is how can I replace these arm binaries in the kernel-header / build folder with x86 version? is there a script in the build folder to do this? Can I replace the scripts folder in the copied ArchLinux with the scripts folder from my ubuntu's kernel module build folder? Or do I modify kernel modules's makefile to instruct the build script to rebuild binaries in the scripts folder or use a different scripts folder for this binary (I would specify) the path to ubuntu's scripts folder in its kernel headers folder?
Or am I going about this the wrong way and there a better way to setup cross compilation for the board and setup I have?
PS. FYI: Cross compiler uses libc 2.16 and the ArchLinux img for OLinuXino has libc 2.17 on it
I've successfully compiled a module without kernel sources, only with kernel headers. I used qemu and ARM version library files from gcc-libs and glibc.
Just copy over the host's scripts directory to override the ARM one, except the mod/modpost program. Edit mod/Makefile.modpost to run the modpost program with qemu-arm. If you don't want to actually change those files, you can of cause use aufs / overlayfs / bind mount to achieve the same.
Set QEMU_LD_PREFIX to where your ARM library files are, make sure qemu-arm .../modpost actually work. Then run make as you've tried to do.
If you can read Chinese, you can read my experience here.
If you are compiling for x86 should specify the kernel headers directory as /lib/modules/linux-3.7.2-2-ARCH/build. For cross-compiling either we will be downloading the linux source or use the linux source provided by the SOC manufacturer. Kernel header of the downloaded linux source has to be specified for compilation. Suppose have your downloaded linux source under /opt directory then sample "Makefile" would look like this
obj-m += name-of-driver.o
make -C /opt/linux(specify full version) M=${PWD} modules
Have to install the cross compiler and export i.e. export PATH=$PATH:<absolute-path-of-cross-compiler-binaries>. While compiling using make utility provide make ARCH=arm(Target for which you are compiling) CROSS_COMPILE=arm-none-linux-gnueabi-. Once all these procedure are followed you will be successfully compiling your kernel module for target.