Jump to content

How to build my own image or kernel?


Recommended Posts

I still don't understand why it downloads so many toolchains onto my disk, I've just one A20 board which only needs the recent eabihf toolchain. Or does a different logic apply here?

[ .... ] Downloading [ gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux ]
[ .... ] Downloading [ gcc-linaro-4.9.4-2017.01-x86_64_aarch64-linux-gnu ]
[ .... ] Downloading [ gcc-linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabi ]
[ .... ] Downloading [ gcc-linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabihf ]
[ .... ] Downloading [ gcc-linaro-5.5.0-2017.10-x86_64_aarch64-linux-gnu ]
[ .... ] Downloading [ gcc-linaro-5.5.0-2017.10-x86_64_arm-linux-gnueabi ]
...
 

Link to comment
Share on other sites

8 minutes ago, martinayotte said:

... to make sure they are available/installed for whatever boards/SoC that will be selected later ...

 

Hmm.... I guess over 99% of the users have just one board to work on at a time...

This could have been solved better, IMO. Ie. kind of "on-demand" download etc. ie download only if really needed according to the selection made in the menu...

 

There are 46 toolchains. No, thx, I'm not going to download that much stuff onto my machine. This is IMO insane.

 

 

 

Link to comment
Share on other sites

On 3/11/2019 at 11:30 PM, mutluit said:

This could have been solved better, IMO. Ie. kind of "on-demand" download etc. ie download only if really needed according to the selection made in the menu...


Agree. Many things are not done ideally, but they work!

Welcome to study how things were made. Keep in mind that the overall goal of this tool-chain is to gain control over all boards and also some of the functions are implemented to serve us for making a distribution, to build images in parallel, etc. Crippling those feature or making expensive changes in favour to save some time/data usage for end user (at first build only in this case) is not a good idea.

 

If you have a desire for changes and you think we all will benefit from them, propose with a PR.

 

On 3/11/2019 at 11:30 PM, mutluit said:

There are 46 toolchains. No, thx, I'm not going to download that much stuff onto my machine. This is IMO insane.


Armbian only needs 15 of them to compile everything and they use 10G of space. It is possible to reduce this number by adjusting old dirty sources to meet modern compile requirements but this is even more stupid and insane wasteful.

Link to comment
Share on other sites

On 3/11/2019 at 6:30 PM, mutluit said:

There are 46 toolchains. No, thx, I'm not going to download that much stuff onto my machine. This is IMO insane.

 

With all due respect, if you don't need to compile your own kernel/distribution then don't! But if you actually do need to, what is your alternative? Are you going to fork Armbian, because you can!

Link to comment
Share on other sites

I need to run 3rd party armhf packages on Nanopi Fire 3. I cannot make custom 64bit packages because I cannot get sourcecode for them.

Adding armhf architecture to running 64bit Armbian failed and I found information it is not so straightforward like on x86 vs amd64 architecture. 

 

While manufacturer FriendlyElec provides both aarch64 and armhf images, Armbian does not.

Any ideas howto build 32bit image via Armbian toolchain?

Link to comment
Share on other sites

Please help me how to install the mainline kernel..
I have found instructions but all i have found is not complete for armbian & rockpro64.
I have downloaded 5.2.9 from kernel.org and compiled with rockpro64 armbian 4.4.18X .config
after that make modules_install / make headers_install / update-initramfs -c -k 5.2.9
and copy dtb-5.2.9-rockchip64 vmlinuz-5.2.9-rockchip64 to /boot
and make symlinks
/boot/dtb -> /boot/dtb-5.2.9-rockchip64
/boot/Image -> vmlinuz-5.2.9-rockchip64

System does not boot
I don't know what else to do
The problem 99% is at uboot.

The uboot is the most confusing thing that i have meet in linux i had no prob years with lilo and after grub but this uboot i cannot understand it how it is work...
PLEASE HELP ME

Link to comment
Share on other sites

On 8/20/2019 at 9:53 PM, rocksa said:

I have downloaded 5.2.9 from kernel.org and compiled with rockpro64 armbian 4.4.18X .config

 

This will almost certainly fail. Its not that simple.


Sometimes you also need correct compiler (version), you might need to adjust u-boot environment or boot scripts if you haven't use ramdisk for booting or pack kernel differently ... who knows. You need to debug your creation.

If you are new to this ARM/embedded world, build a kernel with our tools. Forget about previous x86 experiences for some time ... Build a kernel that we made available to build. Usually those are the only working variants! One old and one new, which is also usually still in development and can break. This is the case for RK3399. 

 

4 hours ago, rocksa said:

Can you help me with that ?

 

When you step out from predicted and well tested environment you are on your own. For free generic support there are slim chances. We already officially don't support things you are asking for (development for end user) since this type of support is extremely wasteful / expensive and if we want to clear out and help all before you ... waiting time would be measured in years. We simply have no resources and "you" don't pay to develop that kind of support.

 

Step back, learn a bit and then try looking for borders.

Link to comment
Share on other sites

Grab our build tools, add a parameter EXPERT="yes" and you will be able to build (install-able .deb package) DEV 5.3.y. Probably working, the best modern kernel for RK3399 which exists but still under development and without support.

 

5 hours ago, rocksa said:

I don't want help with .config on how to compile/install kernel only with

 

... more critical and complicated stuff :) 

Link to comment
Share on other sites

I got a .config from manjaro arm which has stock 5.2 kernel for rockpro64 and works so .config is correct.

If i copy also dtbs & System.map from manjaro is ok ?

In armbian how you can change the boot kernel ?

Only changing symlinks at /boot Image uInitrd dtb and rebuilding boot.scr is enough to boot from new kernel ?

Link to comment
Share on other sites

9 hours ago, rocksa said:

Can in this version compile my own kernel 5.3 ?


Our 5.3.y DEV should work, but its bleeding edge. It will work better then Manjaro, but not all features works o.k. yet.
 

Just install .deb files from output/deb ... you need packages with image and dtb in the name at minimum. Installing u-boot is optional and if - after you install the package, you need to flash u-boot from armbian-config. This is a safety feature.

 

BTW: check https://www.youtube.com/watch?v=0K0vtUg_cgo

 

 

 

Link to comment
Share on other sites

I have a Jenkins server that builds kernels/images for several boards that I own, and, for the most part it works very well. The biggest problem that I currently have is the kernel configuration. I need to add a few patches, which generally works well, and change a couple of configuration options, which sometimes fails.

 

The problem is that I go through a process of creating a modified kernel configuration by first building a stock configuration. I then go into the kernel source directory under cache, make my changes, do a "make oldconfig", grab the new config file and add it to my userpaches directory. That works for a while, but eventually the kernel configuration changes enough that I get non-bootable images and have to go through the process again, potentially for each board.

 

Is there a better way of doing this? Is there a way to build the kernel using the default configuration with just a few options changed?

Link to comment
Share on other sites

Well if you have "just a few options changed" userpatches should suffice. Anyway from time to time the default configs get updates to either match a new kernel version or due to user contributions. So in this solution you always have to check up with Github to see if any chances happened.

 

Another solution would be forking the whole repository and from time to time manually merge any changes that do not affect your kernel configs.

 

Both not optimal as both need manual intervention.

Link to comment
Share on other sites

On 10/22/2019 at 6:50 PM, webbbn said:

The problem is that I go through a process of creating a modified kernel configuration by first building a stock configuration. I then go into the kernel source directory under cache, make my changes, do a "make oldconfig", grab the new config file and add it to my userpaches directory. That works for a while, but eventually the kernel configuration changes enough that I get non-bootable images and have to go through the process again, potentially for each board.


I don't fully understand what you want ... but perhaps this

https://github.com/armbian/build/blob/master/lib/compilation.sh#L360

will help you.

Link to comment
Share on other sites

It turns out that buildroot has exactly what I'm looking for. They call it KCONFIG_FRAGMENT_FILES. Essentially it allows one to just say that I want to use the default configuration, but change these specific options.

 

I'm sure it wouldn't work 100% of the time, but it seems like it could be better in some circumstances than just replacing the current default configuration with an old, possibly now non-functional configuration just to change a couple of options.

 

Link to comment
Share on other sites

Probably doing something stupid here. The whole kernel build process is triggered every single time when recompiling the image. I would expect only to rebuild files I have modified, or drivers I have added during menuconfig.

 

I did set this in userpatches/config-example.conf:

CLEAN_LEVEL="debs"

 

But still getting:

[ o.k. ] Checking git sources [ u-boot v2019.10 ]
[ .... ]  Cleaning ....  [ 8 files ]

[ o.k. ] Checking git sources [ linux-mainline orange-pi-5.3 ]
[ .... ]  Cleaning ....  [ 206 files ]

 

And then it compiles the whole thing all over again.

 

Can someone please point me to what I am doing wrong here?

Link to comment
Share on other sites

51 minutes ago, Jan Gregor said:

And then it compiles the whole thing all over again.


Logic is reversed. Remove "debs" from there and it will not recreate them ... 
 

Quote

"debs" = delete packages in "./output/debs" for current branch and family

https://github.com/armbian/build/blob/master/config/templates/config-example.conf#L7

Link to comment
Share on other sites

Just installed ubuntu 18.04 in a virtual machine (QEMU/KVM). Cloned the build directory. Changed to build.

 

When I then run

sudo ./compile.sh 

I get

[ o.k. ] Using config file [ /home/robert/armbian/build/userpatches/config-example.conf ]
/home/robert/armbian/build/lib/main.sh: line 136: dialog: command not found
[ error ] ERROR in function source [ main.sh:138 ]
[ error ] No option selected 
[ o.k. ] Process terminated 

Any idea what I do wrong?

Edited by T-6
Link to comment
Share on other sites

1 minute ago, T-6 said:

feel kind of stupid

 

Did you try my tip? It is a solution: environment installation sometimes break because ... by a suspicion you were not following our instructions in detail. Installing full Ubuntu server package and not minimal image make this happen.

 

Remember that this project R&D + support is 99.9% our cost and its not small. I know where is the source of this border case problem but explaining in details (two times is already too much) or solving exceeds minutes which are possible to deal with this issue.

This way you can get/earn better support: https://www.armbian.com/get-involved

Link to comment
Share on other sites

Hello!

I'm trying to build some patches in order to use a touch screen display with the current kernel for my Banana-Pi 1.  I tried this Tutorial (which worked fine with the last kernel releases and build environment based on Ubuntu 16.04)

 

Now I switched to build environment bases on Ubuntu 18.04 and I'm having issues with compiling. I get an error message but I don't know what I have to do now. Anybody who can give some hints?

 

scripts/Makefile.lib:308: recipe for target 'arch/arm/dts/sun7i-a20-bananapi.dtb' failed
dts/Makefile:38: recipe for target 'arch-dtbs' failed
Makefile:1061: recipe for target 'dts/dt.dtb' failed
[ error ] ERROR in function compile_uboot [ compilation.sh:204 ]
[ error ] U-boot compilation failed 
[ o.k. ] Process terminated

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines