You are not logged in.
Pages: 1
Hello all,
I am building a new builder for ARM/Mips( maybe amd64 too..PCEngines boards?, but some adjust still are needed.. ).
At the moment, there are only tested backend configs for rpi1,OrangePi One Plus,Rockpro64,rockpi4,Olinuxino Lime 2..
It is not Complete, so for now only this options work:
[F1] Install BootLoader CrossCompiler ToolChain ..
[F2] Install Kernel CrossCompiler ToolChain ..
[F3] Build Devuan RootFS( Root Access needed )
[F4] Build Bootloader..
[F5] Build Linux Kernel, Modules, DTBS..
At the moment it can build:
Bootloaders( uboot ),
Trusted Firmware Execution Engines( ARM Trusted Firmware ),
Kernels Ofcourse( Based on kernel specific defconfig files that are in 'reference/.config/kernels/' ),
Devuan rootfs( 3 options.. basics, server, desktop, last one, still need some love.. ),
Install Cross-compilers to build for specific board,
It will build always software based in which boards was first chosen, the same for the rest, like installing cross-compilers for current board selected....or bootloaders, or even decide to build extra software that is needed for that board( ARM trusted firmware is a example of that.. )
You can find it in: https://gitea.devuan.org/tuxd3v/edev1
Any Doubts about its usage, please drop me a line here.
I hope you enjoy it..
Best Regards,
tux
Last edited by tuxd3v (2020-07-18 17:51:30)
Best Regards,
tux
Offline
Hi, I appreciate your effort but I doubt that building hardcoded kernels is the proper way to go. The "universal" Debian/Devuan kernel supports at least some of the mentioned boards quite well. Newer boards might run better with newer kernels from unstable.
I mean, if you want to provide such kernels you should build a repository where you package, test and update these kernels as well. Since this is probably too much effort, it might be better to simply use the packaged and SoC-optimized kernels from Armbian as they receive updates regularly.
Offline
Hi, I appreciate your effort but I doubt that building hardcoded kernels is the proper way to go. The "universal" Debian/Devuan kernel supports at least some of the mentioned boards quite well. Newer boards might run better with newer kernels from unstable.
I mean, if you want to provide such kernels you should build a repository where you package, test and update these kernels as well. Since this is probably too much effort, it might be better to simply use the packaged and SoC-optimized kernels from Armbian as they receive updates regularly.
Hello kuleszdl,
Thanks,
What do you mean by "hardcoded" Kernels( they are from Mainline Official Releases.. )?
The builder has the option to create deb packages
bindeb-pkg - Created only binary packages
deb-pkg - Creates binary ones plus source packages..
it also creates rootfs and compile bootloaders..
Its not only a package builder for kernels..
Also Edev1, don't distribute kernels..
If you use it,
It will download a specific Mainline Source code Kernel assigned to a chosen board, and build a kernel for it, according with 'reference/.config/kernels/sbc_defconfig'
Ofcourse, armbian also provides images for a lot of boards,yes they have a lot of manpower comparatively, and it should be that they provide some changes that we don't have in advance..
A have been testing and updating the status of each board( it would be easier if it was done by a lot of guys, each one providing updates for a specific board, for example..the objective of the builder was exactly start something to be shared between our community ), for rpi1,OrangePi One Plus,Rockpro64,rockpi4,Olinuxino Lime 2..and others to be added,,
For other boards, some skeleton exists, but they are not complete as I don't have that hardware, I can't verify they are ok..so I am not adding anything to their skeleton description..but I am awaiting that someone that has those boards can contribute and complete their skeleton descriptions, kernel config's, etc..
With all that being said,
I already found several times that the work on this boards is on par, or even more updated than Armbian ones( I already noticed that several times.. ).
It really depends on the time frame, sometimes they update something new first..sometimes, I do it first..
It happens with all projects some times you are on front, sometimes you are behind..
Right now, my focus is on OrangePi one Plus, as kernel 5.8 Released on, August 2, brings in new stuff
The Idea of Edev1,
Is to support boards that are not well supported, or its support is inexistent in Debian/Devuan..
Other Boards can also be added, but the principal objective is to support boards not yet supported by Devuan/Debian,
There are a lot of possibilities there..
Boards descriptions or "modules" are in 'reference/hw/boards' folder..
Edev1 doesn't distribute, kernels, bootloaders, compilers, and so on, it is only a automated builder for Devuan..
Best Regards,
tux
Offline
I checked it out, but I only have a bunch of rpi3.
Happy to test them if you can add support for them.
Currently test running a rpi3 beowulf image I found after much searching, along with Home Assistant.
Mark.
Offline
I checked it out, but I only have a bunch of rpi3.
Happy to test them if you can add support for them.Currently test running a rpi3 beowulf image I found after much searching, along with Home Assistant.
Mark.
Hello Mark,
yeah,
Unfortunately I don't have RPI versions{2,3,4}, only RPI1.
Also RPI foundation does its development in a "close" branch of their own, and not in mainline, which could bring some difficulties to integrate, but If I got a RPI4, maybe I will try
For RPi3,
I believe the ASCII Image is a solution..
Burning it to the sdcard, then apt-get upgrade, and after apt-get dist-upgrade
For RPI4,
There are already some images made by ShortTie, and others like C0rnelious, and also MetaYan..
ShortTie has a post of its builder HERE.
Last edited by tuxd3v (2020-08-30 20:04:29)
Best Regards,
tux
Offline
Hello all,
Adding support for 1 board more, to edev1.
nanoPI R2S - mini router
next board, will probably be nanoPi Fire3( a octacore cortex-A53 ).
Best Regards,
tux
Offline
Pages: 1