I have a device tree file (.dts) and I want to compile the file for my powerpc based board.
How can I do it on my machine, which is not powerpc based?? Can I do it with the DTC installed on my Ubuntu system? Or will it be more like using a separate compiler and passing ARCH information (like using a toolchain)?
Device trees do not need to be compiled with "architecture-aware" tools. The dtc compiler on your ubuntu machine is probably current enough to compile your device tree. Or you can download the latest source and compile it yourself. The dtc compiler can be found here:
https://git.kernel.org/pub/scm/utils/dtc/dtc.git
There are some good documents in that package that will help you better understand device trees in general.
It's pretty easy to compile (and disassemble) device trees. For example
$ dtc -O dtb -o p4080ds.dtb p4080ds.dts
To get the device tree in text from from the device tree blob, do this:
$ dtc -I dtb -O dts p4080ds.dtb
Hope this helps!
dtc can be installed by this command on linux:
sudo apt-get install device-tree-compiler
you can compile dts or dtsi files by this command:
dtc -I dts -O dtb -o devicetree_file_name.dtb devicetree_file_name.dts
you can convert dts to dtb by this command:
dtc -I dts -O dtb -f devicetree_file_name.dts -o devicetree_file_name.dtb
you can convert dtb to dts by this command:
dtc -I dtb -O dts -f devicetree_file_name.dtb -o devicetree_file_name.dts
make dtbs
Doing this from the kernel tree is another common way to compile them, since the standard place to put dts is under the kernel tree in directories of the form ./arch/<arch>/boot/dts/.
This ends up calling dtc, but might work better because potential includes will be in the right place.
dtb files are placed in the same directory as the dts.
Related
When I try to train my yolov4 on my vm with command
./darknet detector train build/darknet/x64/data/obj.data cfg/yolov4-my_gray.cfg backup/yolov4-my_gray_1200.weights -gpus 0,1,2,3 -dont_show
I received
-bash: ./darknet: No such file or directory
Of course I do this in darknet directory. When I try to make i received
When i check open cv
pkg-config --cflags opencv
I received
"-I/usr/include/opencv"
Maybe somebody can help.
Seems compiler is not able to find the file in the includes path you mentioned.
First check if cuda_runtime.h file is available on your machine and get that location. If the file is available then just give the path of the file to the compiler using -I option.
If the file is available at the path /usr/include/opencv, then you would need to provide it with -I option to the compiler
g++ -std=c++11 -I/usr/local/cuda/include ...
I am successfully able to create and boot a little OS generated from buildroot on my embedded system.
Buildroot generates a cpio.
I decompress it (a working cpio, that boot with no problem )with
cpio -iv < ../rootfs.cpio
in a directory. After that I compress it again with
find . | cpio --quiet -o -H newc > ../rootfs.cpio
that is the command used in buildroot (in cpio.mk:31)
but at this point that cpio do not work anymore. If I compile my kernel with that file I get a kernel panic.
File persmission seems the same. With bcompare I saw that the "re-compressed" file has some additional zero at the end, just before the init script. I've tried to remove them, but at this point the system freeze, maybe there is some CRC check somewhere.
Any ideas?
the point is that I'd like to start from buildroot but I want to add my stuff to that rootfs and then embed it into my kernel.
I have installed the cds library with command ./build.sh -b 64 -z '-std=c++0x' -l '-L /usr/lib/x86_64-linux-gnu' --with-boost /usr/include/boost --amd64-use-128bit at build folder.
After I tried to compile the example init.cpp of src folder, I typed this in terminal: g++ init.cpp -o init, and terminal showed: fatal error: cds/init.h: No such file or directory.
What should I do for compilation command in this case?
Thanks.
For general troubleshooting in cases like this, i would recommend finding where on the system the file got installed (if your build.sh actually installed the file). You would be able to find the missing header file using
find / -path '*/cds/init.h' 2>/dev/null
Then you need to supply two parameters to g++:
First one gets the compiler to know about the include files from the install directory
-I path_to_folder_one_step_above_cds_folder
Second one gets the linker to know about the librarys location. If the library file is called libcds.so, you can find it by running
find / -name libcds.so 2>/dev/null
So for linking, you supply the flag
-L path_to_folder_one_step_above_libcds.so
In your case you might not need the -L flag, since most of your library supposedly is header only.
UPDATE: the build.sh script is printing out important information at the top, starting with "Building with the following options:". The important bits will be "Compile options:" and "Link options:". Those should be enough to solve your specific option.
UPDATE2: build.sh also exports some flags which might include more options. You can print them out directly after running build.sh by running
echo LDFLAGS=$LDFLAGS
echo CFLAGS=$CFLAGS
echo CXXFLAGS=$CXXFLAGS
you are likely to need to pass all these options to g++ when compiling and linking against that library. LDFLAGS are specific to the linker only. Both the other ones are needed for compiling c++ files.
I would like to decode HEVC encoded files to YUV files.
Is there any simple way to do this yet? An executable would be nice but I would make do with source code that is easily compilable.
It's as simple as (guide assumed linux, tweek it to your needs)
Clone the official reference codec (the official-official is a svn-repo found at https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/trunk/ but a read-only git-repo that is kept in sync with the svn is provided by BBC which is so much easier to work with IMHO)
git clone git://hevc.kw.bbc.co.uk/git/jctvc-hm.git
To create the executables:
cd jctvc-hm/build/linux && make -f makefile
Binaries are now placed in
jctvc-hm/bin
Now, to decode a HEVC-encoded binary file into YCbCr, do
./TAppDecoderStatic -b encoded_file.bin -o reconstructed.yuv
If you are not on a linux system, just goto the build folder and you will hopefully find something you can use for your system:
$ cd jctvc-hm/build && ls
HM_vc10.sln HM_vc8.sln HM_vc9.sln linux/ vc10/ vc8/ vc9/
Follow the instructions on https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/branches/HM-9.2-dev/doc/software-manual.pdf, the source code can be downloaded from https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/trunk/ by using any subversion software.
You can build it on both Windows and Linux based OS. After you built the software, you may run the exe files as it is instructed on the software manual.
Alternatively, you can use libde265 as a much faster decoder.
Get the latest version from its github release page.
Configure with ./configure --disable-sherlock265
Compile: make
Generate the YUV file with
./dec265/dec265 hevc-file.bin -o output.yuv -t4
The option -t4 is for multi-threaded decoding. You can also do more things like input NAL-unit streams, dump the headers, directly display the video, or check the SEI hashes.
You can download the ffmpeg windows build exe file
simply decoding HEVC bitstream.
ffmpeg.exe -i xxx.bin out.yuv
I recently updated to the most recent version of Cygwin (1.7.23), and what used to be a functional 'arm-elf-gcc' compiler seems to now be broken. In particular, no matter what input I supply the command, it complains that there are no input files:
$ arm-elf-gcc foo.c
arm-elf-gcc: no input files
$ arm-elf-gcc --help
arm-elf-gcc: no input files
$ arm-elf-gcc -v
arm-elf-gcc: no input files
Any ideas or suggestions as to why this could be happening? A Google search for 'arm-elf-gcc no input files' reveals little as to the cause. Thanks!
As TurboJ mentioned in the comments to the original question, there were two conflicting versions of the cygwin1.dll. The folder that contained the arm-elf-gcc executable also contained a cygwin1.dll, which clashed with the one from the 'bin' subdirectory of Cygwin. I merely replaced the former with the latter.
As Jon Kother says, If you Installed Gnu arm and checked install cygwin.dll and cygwin 32 version,this problem will happen
so just go to your X:/gunarm/bin/ and rename cygwin.dll to cynwin.dll.bak,And everything will to alright