I am working on a Ultra96 board, SOC Xilinx Zynq UltraScale+ MPSoC ZU3EG A484, running:
DISTRIB_ID=petalinux
DISTRIB_RELEASE=2020.1
DISTRIB_CODENAME=zeus
DISTRIB_DESCRIPTION="PetaLinux 2020.1"
Here my kernel version: 5.4.0-xilinx-v2020.1
I am not familiar with petalinux so i need help about recompiling xilinx kernel to enable hugepages.
Is there any guide that explain step by step how to recompile the kernel?
Thank you.
Run
petalinux-config -c kernel
which will take you to the kernel menuconfig, which you can then use to set hugepages.
Once you are happy with the changes and want to save them, you can run:
petalinux-build -c kernel -x finish
which will save the mods to project-spec/meta-user/recipes-kernel/devtool-fragment.cfg
which you can commit to git to keep the configuration changes.
See Configuring Project Components in https://www.xilinx.com/support/documentation/sw_manuals/xilinx2020_1/ug1144-petalinux-tools-reference-guide.pdf for more details
Related
I am trying to experiment with a Deep learning framework called STIT(Stitch in Real Time), and it needs CUDA too. As I googled and found on Stackoverflow that you need to put run time on GPU in the case of google Colab and so I did. However, I get the error message
warnings.warn('Failed to build CUDA kernels for upfirdn2d. Falling back to slow reference implementation. Details:\n\n' + traceback.format_exc())
100% 98/98 [00:45<00:00, 2.13it/s]
Which results in really slow training.
Any suggestions, What should I do here?
ok, I don't know why but the installation of the following solved the problem
!wget https://github.com/ninja-build/ninja/releases/download/v1.8.2/ninja-linux.zip
!sudo unzip ninja-linux.zip -d /usr/local/bin/
!sudo update-alternatives --install /usr/bin/ninja ninja /usr/local/bin/ninja 1 --force
An explanation around it is appreciated
I found in QEMU NIOS IP https://wiki.qemu.org/Documentation/Platforms/Nios2
I have downloaded intel tool chain from their website : https://www.intel.com/content/www/us/en/programmable/products/boards_and_kits/dev-kits/altera/kit-niosii-2s60.html
I have few questions:
Is the NIOS2 in QEMU IP matching intel’s NIOS IP ?
What is the toolchain you use to compile and run it in QEMU ? Is it same tool-chain as provided by intel’s website ?
How to general Firmware code and run it on NIOS over QEMU. In the Wiki it says:
qemu-system-nios2 -M 10m50-ghrd -kernel -dtb -nographic
How to generate dtb file for it?
Do we need to take products created by the quartos/EDS for the running of the QEMU, other from the compiled binary? (DTB - board specification?)
Do we need to run it with specific QEMU parameters/arguments ?
Do you have code examples for NIOS using its peripherals?
Basically, I didn’t find any documentations/examples about how to use the NIOS2 in QEMU. Can you help with some additional info ?
Even some basic “hello would” (compile and run in QEMU) would be great…
UPDATE: the most up-to-date answer to this question may be to analyse the linux console nios test at https://gitlab.com/qemu-project/qemu/-/blob/master/tests/acceptance/boot_linux_console.py#L1029 (or of course contact a maintainer). The kernel image from advent calendar 2018 day 14 runs great. It looks like it can all be done with buildroot.
My comments started bearing fruit, so I'll try to put a partial answer together. I haven't gotten this to work yet, but maybe this can be helpful to others who might work farther.
NOTE: If you just want to run a single nios2 binary, you can pass it straight to qemu-nios2. qemu-system-nios2 is for running linux.
I believe the qemu behavior is functionality rather than intellectual property. It would be a bug if it mismatched. I do not know whether it does. Mentioning IP here, please remember that open source projects are generally run by a handful of vulnerable caring devs who usually have no legal team if ownership of intellectual property is challenged. If there's an issue, it would be polite to refer the concerning party to https://eff.org/ who often legally represents such things.
I expect that any nios2 toolchain works. Here's a toolchain from a quick internet search that led me to bootlin.com. Appears to include instructions on how to duplicate it from source.
See 4
Here is what I have so far for firmware generation:
# set up a toolchain (note: this old step is redundant with buildroot, lower down, which also installs a toolchain and even builds a kernel if asked)
wget https://toolchains.bootlin.com/downloads/releases/toolchains/nios2/tarballs/nios2--glibc--stable-2020.08-1.tar.bz2
tar -jxvf nios2--glibc--stable-2020.08-1.tar.bz2
# get kernel sources (pass --depth 1 to speed up)
git clone https://github.com/altera-opensource/linux-socfpga.git
# build kernel and device tree
cd linux-socfpga
make ARCH=nios2 CROSS_COMPILE=$(pwd)/../nios2--glibc--stable-2020.08-1/bin/nios2-linux- 10m50_defconfig 10m50_devboard.dtb vmlinux -j5
cd ..
# kernel is now at linux-socfpga/vmlinux
# device tree is now at linux-socfpga/arch/nios2/boot/dts/10m50_devboard.dtb
# set up buildroot to build a root image
git clone https://github.com/buildroot/buildroot.git
cd buildroot
# configure for qemu nios2
make qemu_nios2_10m50_defconfig
# build root image
PERL_MM_OPT= LDFLAGS= CPPFLAGS= LD_LIBRARY_PATH= make
cd ..
# rootfs images are now in buildroot/output/images/
I'm afraid I'm just a visitor and I don't know who quartos/eds are or what compiled binary you are referring to.
The qemu command line appears to be qemu-system-nios2 -M <machine> -kernel <kernel file> -dtb <dtb file> <rootfs image file>. The example machine is 10m50-ghrd which we built the kernel for above, and this may be the only one.
not yet! i'll try to update this answer if i get farther. feel free to edit it if you get farther.
How can I run valgrind on an embedded Linux box to find memory leaks in my main software?
In the rcS script, I am running like this:
./main_app
How can I associate the ./main_app program with valgrind? The main_app process never terminates.
I want to constantly log the data to file. Also, I want to access the log file without terminating the main_app process. I can do telnet and can access the log file. But the problem is until and unless the handler is closed, how can I open the file i.e. I don't quite understand which valgrind parameters control how memory leaks are logged to file. Please help!
You can try to build it by your own for mips, here the steps:
download valgrind from here http://valgrind.org/downloads/ - I used Valgrind 3.8.1
unpack archive with valgrind and move to the valgrinds folder
execute:
./autogen.sh
./configure --host=mipsel-linux-gnu --prefix=/home/pub/valgrind CFLAGS="-mips32r2" CC=/opt/toolchains/mips-4.3/bin/mips-linux-gnu-gcc CXX=/opt/toolchains/mips-4.3/bin/mips-linux-gnu-c++
./make -j6
./make install
prefix - folder to install compiled binaries of valgrind;
CC and CXX - path to compilers;
CFLAGS - "-mips32r2" and "-mplt" flags should be passed to compilers if it older then gcc (GCC) 4.5.1
on target mips box export path to valgrind lib folder:
export VALGRIND_LIB=/mnt/nfs/lib/valgrind
Now you can use it as usual, for memory checking features you can look here http://valgrind.org/docs/manual/mc-manual.html
It works for me, good luck.
Valgrind only works on x86. You can still track down your leak if you build your application for x86 and run it under valgrind there. Its unlikely the problem is specific to the target architecture.
The answer above describes how to build valgrind but to actually get a full leak check as opposed to just a list of memory problems, your program does have to terminate, I am guessing you never terminate your program.
Assuming your process is some kind of daemon process your best bet is just run it in a loop, monitor memory usage using something like top and then when you see signs of excessive memory usage send it a shutdown command somehow. If you then run valgrind with the following options, you will get a unique log for each process run, including a dump of leaks at exit:
while true ; do
valgrind --leak-check=yes --log-file=/tmp/log.%p.txt main_app
sleep 1
done
The %p in the filename inserts the process id.
You can also specify --show-possibly-lost=no which will reduce the volume of leaks reported to those that valgrind has a much higher degree of confidence are lost.
I am running a cuda project. But somehow I am not able to set the flag -arch=sm_20 in the
sconscript file which has been written by someone else. I need to use printf in kernel for debugging and I have little experience of sconscript python.
The specifics depend on the way you have SCons set up to work with CUDA. I use these scripts: http://github.com/BryanCatanzaro/cuda-scons
With this setup, all you need to do is invoke SCons with your preferred architecture:
scons arch=sm_20
And nvcc will be invoked with the -arch=sm_20 flag.
Details of your setup may be different, but if you look through your SCons script, you should see how to change this flag.
with a very simple code, hello world, the breakpoint is not working.
I can't write the exact comment since it's not written in English,
but it's like 'the symbols of this document are not loaded' or something.
there's not cuda codes, just only one line printf in main function.
The working environment is windows7 64bit, vc++2008 sp1, cuda toolkit 3.1 64bits.
Please give me some explanation on this. :)
So this is just a host application (i.e. nothing to do with CUDA) doing printf that you can't debug? Have you selected "Debug" as the configuration instead of "Release"?
Are you trying to use a Visual Studio breakpoint to stop in your CUDA device code (.cu)? If that is the case, then I'm pretty sure that you can't do that. NVIDIA has released Parallel NSIGHT, which should allow you to do debugging of CUDA device code (.cu), though I don't have much experience with it myself.
Did you compile with -g -G options as noted in the documentation?
NVCC, the NVIDIA CUDA compiler driver, provides a mechanism for generating the debugging information necessary for CUDA-GDB to work properly. The -g -G option pair must be passed to NVCC when an application is compiled for ease of debugging with CUDA-GDB; for example,
nvcc -g -G foo.cu -o foo
here: https://docs.nvidia.com/cuda/cuda-gdb/index.html