Michal Fita Posted January 22 Share Posted January 22 I found it very confusing that Armbian doesn't seem to follow the Ubuntu/Debian traditional scheme for naming kernel modules: linux-image-*, linux-modules-* and linux-headers-*. I need them to cross compile out-of-tree kernel module in `schroot`. Armbian seem to have only `linux-image-edge-rockchip64` and `linux-headers-edge-rockchip64`. What's the reasoning behind such design decision? Moreover, I've noticed kernel packages incorporate all the logic that make the board bootable, instead having more generic kernel binaries and relying on `flash-kernel` tool that both Ubuntu and Debian widely use. I wonder why not? What are chances in future `linux-image-*` could be split and have matching `linux-modules-*` package as upstream? Is there any maintained roadmap to figure out most recent supported numbered kernel package, so I could have Orange Pi 3B board with fixed (pinned) kernel version out-of-the-box? Thank you. 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted January 22 Share Posted January 22 1 hour ago, Michal Fita said: What's the reasoning behind such design decision? Armbian is hardware oriented Linux where Debian like userspace is attached on it. In embedded Linux none of this has much value ... and also people who sold you hardware provides Armbian Linux (branded as Orangepi OS) with their Rockchip private static kernel which will never be updated. Its there to die off. This is the norm. There is a long path from that toward some traditional norm. Millions of dollars or thousands of hours of community and business that are investing their time here. tl;dr; Complexity. We needed several years to fix all garbage code in all kernels, where headers compilation is a matter of randomness already on native compilation. When you add different compilers (different debian / ubuntu package base) and cross-compilation ... on 50 different kernel forks, which some, have so many custom code that its hard to say its a Linux kernel. Upstream Ubuntu/Debian usually only deal with clean mainstream world. 1 hour ago, Michal Fita said: I found it very confusing that Armbian doesn't seem to follow the Ubuntu/Debian traditional scheme for naming kernel modules: We provide around 50 different kernels. From UEFI generic down to per SoC and further per vendor. Naming convention, current, edge (and several more) provides some simplicity in this world. And helps you to not think much. Supported hardware is tested daily: https://github.com/armbian/os?tab=readme-ov-file#latest-smoke-tests-results Which means you are generally safe - if you stick to supported hardware! Our hardware support is significantly better then Debian / Ubuntu. There users tests (except generic x86), bug response cycle is significantly longer. 1 hour ago, Michal Fita said: Moreover, I've noticed kernel packages incorporate all the logic that make the board bootable, instead having more generic kernel binaries and relying on `flash-kernel` tool that both Ubuntu and Debian widely use. I wonder why not? Our system was designed from bigger picture then Debian way (Ubuntu just copy this tool as they have no other option). It works perfectly fine and all our secondary tools are adopted to it. We looked into and even trial flash-kernel with Raspberry Pi and I am more than happy we recently drop it. Its unreliable amateur maintained tool which IMO is not very useful when you go outside RPi world. On the other hand, most of Armbian engineers comes from embedded Linux. We have significantly wider know-how about embedded Linux (which is needed to maintain such tool) then generic desktop server Debian / Ubuntu world. We checked that tool and there is nothing to learn / take from there. We have several ideas for improvement and changes here, there are 3rd party special industrial grade solutions too ... but all those ideas quickly dies due to complex and expensive integration. We can't finance this and amateurs don't work on long term complex integrations. 1 hour ago, Michal Fita said: Is there any maintained roadmap to figure out most recent supported numbered kernel package, so I could have Orange Pi 3B board with fixed (pinned) kernel version out-of-the-box? No. If HW is not on supported list, we have no information if this hardware boots or what works. This is on you to determine and share withing the community if you like. More can ofc be done, but someone needs to volunteer and assembly this information. Until then, it does not exists, its just a GitHub commit log(s) ... 1 hour ago, Michal Fita said: What are chances in future `linux-image-*` could be split and have matching `linux-modules-*` package as upstream? If you do it right, big, if you give this task to maintainers, small, ... hundreds of people are asking for something useful all the time and there is a few people that does something on the other side and are not supported by community. Study build framework, make a PR and make sure it gets to the documentation is the right and friendly way. I hope this at least partially answers. If I would had hours, I could write a lot more on the topic Yes, we have reasons why this is so, but things can always be improved. 0 Quote Link to comment Share on other sites More sharing options...
Michal Fita Posted February 2 Author Share Posted February 2 Thanks @Igor. Quote If HW is not on supported list, we have no information if this hardware boots or what works. This is on you to determine and share withing the community if you like. More can ofc be done, but someone needs to volunteer and assembly this information. How to provide information that OrangePi 3B for example boots on Edge? We could run GPU stuff on it with success. Quote We looked into and even trial flash-kernel with Raspberry Pi and I am more than happy we recently drop it. Its unreliable amateur maintained tool which IMO is not very useful when you go outside RPi world. I find it useful it allows board customization w/o maintaining whole kernel fork. However, it's maybe we started from official Ubuntu for Xilinx? Quote Study build framework, make a PR and make sure it gets to the documentation is the right and friendly way. Looks like I have to. I need Rockchip's MIPI CSI2 drivers to connect camera to OrangePi 3B and Radxa Zero 3E. 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.