Tucson Tom Posted August 5, 2020 Posted August 5, 2020 Why do I want the source code? Well I am working with an Allwinner H5 board (Orange Pi PC 2), getting a RTOS to run on it, and want to study some of the device drives. I have found the Armbian sources for the H3 quite valuable in this way. So I spent the bulk of the afternoon and got nowhere. My desktop is a Fedora System. I don't want to install VirtualBox again (which is what I did several years ago in order to get the H3 sources). I tried the Docker thing, but Fedora 32 and Docker don't work together. Then I remembered that I have access to a system running Fedora 30, and the Docker setup worked fine there, but the process choked with this: [ o.k. ] Cleaning /root/armbian/output/debs for [ orangepipc2 current ] [ o.k. ] Cleaning [ arm-trusted-firmware-sunxi-mainline/master ] [ o.k. ] Compiling ATF [ o.k. ] Compiler version [ aarch64-none-linux-gnu-gcc 9.2.1 ] [ o.k. ] Started patching process for [ atf sunxi64-orangepipc2-current ] [ o.k. ] Looking for user patches in [ userpatches/atf/atf-sunxi64 ] [ warn ] * [l][c] 0001-Fix-reset-issue-on-H6-by-using-R_WDOG.patch [ failed ] [ error ] ERROR in function compile_atf [ compilation.sh:78 ] [ error ] ATF compilation failed [ o.k. ] Process terminated So, I don't know quite what is wrong here. Presumably some patch didn't go in right. And I am virtually certain this applies to U-Boot, which I don't (at this time anyway) really want the sources for anyway. So I am thinking. All I want is the patched sources. I don't need (or want) to compile anything. I wonder if I can study the Armbian ./compile.sh script and just pull out the part that fetches kernel source, fetches patches, and applies them. I looked at this years back and it is quite a monster of a bash script. Well if anyone has ideas, I am all ears. Tom
Werner Posted August 5, 2020 Posted August 5, 2020 Well you can grab the sources and the needed patch dirs and simply loop through the patch dir to apply the patches to the sources to get the patched sources.
martinayotte Posted August 5, 2020 Posted August 5, 2020 7 hours ago, Tucson Tom said: [ warn ] * [l][c] 0001-Fix-reset-issue-on-H6-by-using-R_WDOG.patch [ failed ] [ error ] ERROR in function compile_atf [ compilation.sh:78 ] Did you look at log files in output/debug/ folder ?
Tucson Tom Posted August 6, 2020 Author Posted August 6, 2020 I would have been back sooner, but being new on the forum, it seemed to not let me post more than once in 24 hours. Or something. But I was busy with this most of yesterday in an interesting way. I gave up (for now anyway) doing this on my Fedora Desktop. What I did was to download Armbian for my Orange Pi PC 2, put it on an SD card and run it on the Orange Pi. Then I used armbian-config to download kernel sources, which worked just fine, placing them in /usr/src. Then I could remove the SD card, mount it on my desktop and copy the sources for my convenience. Then I put the SD card back into the Orange Pi, fired it up, did a cd to /usr/src/linux-source-5.4.43-sunxi64 and typed "make". It plowed away for 10 hours or more (it finished during the night when I was asleep). It hung once in the afternoon requiring a reboot and restarting make. The advantage of this for me, is the build leaves object files (*.o) in the source tree letting me know at a glance just what source files were involved in the build. This has proven invaluable for me in the past when rummaging around in the linux sources. Now I can pull that SD card again and copy these files to my desktop for study. It would be nice to do as Werner says and be able to grab the sources and patch them on my desktop. I have the idea of studying the Armbian build system and reproducing parts of it in Python to liberate it from being debian dependent -- but using the actual target system was the easy way. So thanks for the advice. I still haven't looked at why the R_WDOG patch failed, but I figure that is something that someone else will run into and sort out. Thanks again. Tom 1
Werner Posted August 7, 2020 Posted August 7, 2020 16 hours ago, Tucson Tom said: I would have been back sooner, but being new on the forum, it seemed to not let me post more than once in 24 hours. Or something. The limit should be gone with the next cronjob.
Tucson Tom Posted August 8, 2020 Author Posted August 8, 2020 Thanks for accepting me as one of the crowd here ! I am back to doing a study of the armbian-build script. I really do want to use my Fedora system, and all I really want to do on it (for now) is to be able to recompile the kernel. And I don't want to go through the nightmare of docker or virtualbox or any of that. There is no reason that just building a linux kernel ought to be debian dependent. At some point I'll want to replace the kernel on my SD card with one I build -- but that will be the next project. For now my goal is to be able, given the source tree I now have, to build the kernel for my Opi PC 2 on my Fedora system without any virtualization games. And ultimately that will boil down to just typing "make" in the root of the linux source directory with a proper bunch of options for things like CROSS_COMPILE and ARCH and such. Here is one question, if anyone is reading all of this. I noticed that the armbian build script downloads and builds a "linaro" C compiler, which I suppose is some fork from gcc. My fedora system offers an ARM cross compiler that I have been using for years for all of my ARM projects. It is a standard Fedora package. It identifies itself as arm-linux-gnu-gcc (GCC) 9.2.1 20190827 (Red Hat Cross 9.2.1-3) Is there any reason I should not, or might not want to, use this versus the linaro compiler? Maybe I should repost this question all by itself in some more appropriate part of these forums? (If so, where). Tom
Igor Posted August 9, 2020 Posted August 9, 2020 14 hours ago, Tucson Tom said: And I don't want to go through the nightmare of docker or virtualbox or any of that. I am not very familiar with Fedora user land so there is impossible to support you in porting build script there or make it Fedora friendly. Sorry. On the other hand - there is a lot of maintenance related to this script - easily translated to full time job for a few people to keep things up with the users wishes. This means porting elsewhere and forget is IMO pointless job. We have seen several forks died this way - extreme underestimation for the cost of maintenance. I do understand that your goal is "just" compiling the kernel ... solo that task is simple and you don't need to deal with the script - you can extract needed info, but again - I have no idea how it has to be packed, especially one wants also that "advanced" features such as kernel headers, sources, blobs and overlays works flawlessly ... 14 hours ago, Tucson Tom said: arm-linux-gnu-gcc (GCC) 9.2.1 20190827 (Red Hat Cross 9.2.1-3) If you strictly limit yourself on compiling vanilla kernel, this is good enough, you can also use CC (from v6 - to v9 is probably fine for current vanilla kernel) that comes with the distribution, while for example if you need to compile Odroid N2 image (with mainline kernel or not) for example, you will need different set of compilers. And our build system was build around the need to cover such (very standard in ARM SBC) scenarios. If you want to include some wireless drivers, you will sometimes need to fix the code to meet modern compiler standards ... its much more simpler and faster to declare "use this version of compiler". We have no intention and absolutely no resources (armbian is already insane expensive and its mainly our private cost) to support porting this to Fedora or anywhere else. Even keeping Debian clones is hard/wasteful enough ... we only want to build image and focus there. Not to build on every possible Linux on the planet. I hope you do understand that - nothing against Fedora or your - fully legit - stand point. 14 hours ago, Tucson Tom said: Maybe I should repost this question all by itself in some more appropriate part of these forums? I'll move it down to Development / Armbian build script.
Tucson Tom Posted August 9, 2020 Author Posted August 9, 2020 Thank you Igor for your kind reply. Let me say a couple of things. First thanks for Armbian -- having this for these ARM boards is a fantastic thing. And no, I am not asking for support or a fork or trying to load more work on you. I am very grateful for a question or two answered as I work my way along learning. Hopefully someday I will contribute and be helpful. I occurred to me that since I can build the Armbian kernel on my target board that I can "rm" some object file, then run "make V=1" and see all the options to rebuild that file and relink the kernel, which would be fast and helpful to me. It also occurred to me that I have an extra computer here running Windows 10. I have used it only for photo software (photoshop and lightroom), but I could run the WSL (windows system for linux) and then select Debian and see if I can then use that system for Armbian! I am not a Fedora Fanboy. I just have run it since Red Hat days and I have a bunch of computers I support that run Fedora at the observatory, so my own systems serve as a test bed before deploying critical things to those computers. Otherwise I might switch to Debian. But if all I want to do is build kernels and put them onto SD cards and experiment, I should be able to get that to work on Fedora. Once we get into setting up debian user land, it is quite a different matter. I am studying armbian-build. Almost 7000 lines of bash, so it is a lot to digest!! Thanks for all of your work.
Recommended Posts