Installed Vivado 2018.2
Clone u-boot git clone https://github.com/Xilinx/u-boot-xlnx.git
change directory to u-boot-xlnx
source /opt/Xilinx/Vivado/2018.2/settings64.sh
export CROSS_COMPILE=aarch64-linux-gnu-
export ARCH=aarch64
make avnet_ultra96_rev1_defconfig
make
Both u-boot and u-boot.elf appear at the directory, what they are?
I want to build a boot.bin from fsbl.elf, xxxx.bit and u-boot.elf with SDK, which file shall I use?
I search the issue on web but get difference answer, someone recommends that rename the u-boot to u-boot.elf and apply it, other says use the u-boot.elf directly.
Your answer is welcome, thanks a lot.
Related
How to add wiringpi in Buildroot image ?
I followed the same steps as described here: How to add an out-of-tree package to buildroot? The download of the git archive functions correctly but the compilation of the library doesn't work. I tried to change the "sh build" command in the .mk file using an absolute path to where the archive was extracted (in output/build).
I also tried to change the build.sh included in WiringPi archive with absolute paths everytime cd was used beacause the make command used with buildroot wasn't executed in the same directory Can you help me write a correct .mk file that will compile wiringpi for my buildroot image using this git: https://github.com/WiringPi/WiringPi ?
WiringPi is/was already in buildroot packages, however, the whole library was deprecated by the author at some point. Due to this and apparently also because the WiringPi's author deleted all sources (according to this), it was moved to buildroot's legacy packages. However, that deprecation post is now removed by the WiringPi author (which is why the first link points to internet archives), so it could be that the sources are also restored and the WiringPi package from the legacy config works or could be made working with small modifications.
TLDR; Even if you could get it working, you should use something else.
Today, I went and looked at the Jelly github page. I found this.
I noticed that after they cloned the repo(and moving to the jellylanguage directory), they were able to use the "jelly" command. How is this possible? And how can I do it myself?
It is an executable binary. You can compile code to create a natively executable binary that can be run as ./a - then you can put that in /usr/local/bin to be able to use it from anywhere OR add the directory where that binary is to your path environment variable
I have a question regarding including different tools into Yocto image recipe. Currently I am building image recipe for my Avenger96 board. I have created a base image and it runs fine on the device. But when I try to do sgdisk after booting it says -sh: sgdisk: command not found. I understand that these commands are not available by default and need to install it.
But I am not sure how to do it given my board is not connected to internet. Can I include these commands/tools in image recipe? I want to use some other commands like ufw, etc but I have same issue with them too.
Can someone please let me know how to do this?
Your help will be much appreciated.
Thanks in advance.
P.S: I am using Ubuntu 20.04 with Yocto as build system.
sgdisk is present under recipe: meta/recipes-devtools/fdisk/gptdisk_xx.bb
For xx it depends on your poky version.
For dunfell this is the recipe here.
ufw is present in meta-openembedded/meta-networking/recipes-connectivity/ufw
So, make sure meta-openembedded/meta-networking is present in your bblayers.conf and to include both of them add the following line to local.conf or to your custom image file:
IMAGE_INSTALL_append = " gptfdisk ufw"
If you still do not find sgdisk try gptdisk-sgdisk.
If you want to add any recipe in the future, try to look for it in the official yocto git repositories in this link.
It is not recommended to add tools manually into the board, unless you are in the development process and you need to gain time, so here are some ideas for you:
Create an image for development that includes all dev features (gcc, g++, cmake, ..etc)
Include git and other fetching tools
Clone the tool's source code and compile it in the board
Or: bitbake the recipe with Yocto and copy the output binary directly to the image via ssh or other ways.
I am using buildroot to build linux firmware. How can I do a clean rebuild the linux kernel only (without having to build the whole thing which take an hour)?
I tried -
make linux-rebuild
but that does not do a clean.
I have also tried
make linux-reconfigure && make linux-rebuild
but that does not work either.
If you want to remove all of the changes in sources of the linux kernel be in buildroot directory (cd buildroot) and do following:
make linux-dirclean
make linux-rebuild
The first command will remove output/build/linux* directory and the second one will fetch and rebuild from scratch the kernel.
I've found in the buildroot /dl folder a copy of the kernel repo is stored in there as a tar.gz file. If you do not delete that file, buildroot will not pull any kernel updates.
after reading a lot through buildroot manual and trail and error - this is what you need to do for cleaning of linux only -
make clean linux
I'm working on a Windows 7 computer at work and want to use the libpostal package. Unfortunately, it's apparently not available for Windows, so I'm trying to configure it through Cygwin and I'm SO close. The last step is to install snappy from Google. Again, not available on Windows...
My assumption (based on nothing) is that I can just download the tarball and build it from source, right? I tried that, and I think it worked? But a) I don't know how to tell, and b) if it did, I don't know how to tell ./configure in libpostal to find it.
In order to build it from source, I downloaded the tarball and saved it in the folder that Cygwin reads as my home, which is C:\cygwin64\home\brittenb\. From there, I ran bash autogen.sh, which created the ./configure that I needed. So I ran that and while some responses to the checks were no, it seemed to run fine. I then ran make and make install. Nothing seemed out of place, so my assumption is that it did what it was supposed to do. I just have no idea where to go from here.
Here is the output from ls after I run everything:
aclocal.m4 snappy.cc
AUTHORS snappy.h
autogen.sh snappy.lo
autom4te.cache snappy.o
ChangeLog snappy.pc
compile snappy.pc.in
config.guess snappy_unittest.cc
config.h snappy_unittest.exe
config.h.in snappy_unittest-snappy_unittest.o
config.log snappy_unittest-snappy-test.o
config.status snappy-c.cc
config.sub snappy-c.h
configure snappy-c.lo
configure.ac snappy-c.o
COPYING snappy-internal.h
depcomp snappy-sinksource.cc
format_description.txt snappy-sinksource.h
framing_format.txt snappy-sinksource.lo
INSTALL snappy-sinksource.o
install-sh snappy-stubs-internal.cc
libsnappy.la snappy-stubs-internal.h
libtool snappy-stubs-internal.lo
ltmain.sh snappy-stubs-internal.o
m4 snappy-stubs-public.h
Makefile snappy-stubs-public.h.in
Makefile.am snappy-test.cc
Makefile.in snappy-test.h
missing stamp-h1
NEWS testdata
README test-driver
ls /usr/local/bin shows nothing, but ls /usr/local/include shows:
snappy.h snappy-c.h snappy-sinksource.h snappy-stubs-public.h
So... my question: did it work? Why does ./configure in libpostal say it can't find snappy? Thanks in advance.
The snappy dependency has been removed as of release 1.0.0. I made changes to the source and make and config so that it will build on MinGW.
Get it in my repository:
https://github.com/BenK10/libpostal_windows
Note that this is not the complete source since not everything had to be changed. I would suggest merging my changes with the official libpostal distribution to make sure you've got everything. Also, there are some extra DLLEXPORTs in some source files that I haven't removed yet, and the part in the Makefile that builds the executables like address_parser.exe was removed because some porting is necessary to build those programs on Windows. You can write your own using the DLL you'll get in the Windows build and the original source as a reference.
Check the return code from make install ($?). If it is zero, make install succeeded.
snappy looks like a library, so maybe it doesn't install anything in /usr/local/bin. The library is probably installed into /usr/local/lib.