We use cookies to provide our visitors with an optimal site experience. View our privacy notice and cookie notice to learn more about how we use cookies and how to manage your settings. By proceeding on our website you consent to the use of cookies.
In .config, I enabled LL-Debugging for beagle including earlyprintk. This, I did because of some research I did on how to debug booting process.
In case of gcc, i noticed that the build script actually installed the latest, but for u-boot I used the one listed in your post. I guess it does not matter?
The build script itself I did not change at all. It even compiled with -j1 because it did not get my number of cores (4).
But, as I have mentioned, the same “error” occurs with all previous attempts as well and I dont know what i am doing wrong at all. I am using Debian 9 VM on Windows 10.
@eloa, over the years we really had nothing bug trouble with any “virtual machine” running on windows. Usually it came down to simply not correctly writing the files to the external flash device.
This is why all my directions specifically note:
* Running a recent release of Debian, Fedora or Ubuntu; without OS Virtualization Software.
I’ve pushed this build to one of my external servers, retry your microSD with these files.
I’ve just downloaded your files directly to my microSD and replaced mine. And finally, my first custom kernel is booting and it seems to work perfectly. But, as I need to build my own kernel to patch it with Xenomai, i need to figure out what exactly goes wrong.
As it works with my own U-Boot configuration I guess the mistake must happen within the compiling process.
Usually it came down to simply not correctly writing the files to the external flash device.
So, what do you mean? Does the known error occur when copying the compiled files/archives from VM to SDcard or while compiling?
@eloa, no it’s a bug somewhere in the; usb adapter - host os - vm stack - linux os… Where the real fix is just to natively run Debian/Ubuntu or Fedora by itself. Thus not wasting time debugging random “VM” issues…
One more thing to add: I’ve just rebuilt the same kernel without the LL-debbuging and earlyprintk enabled in .config. And now my own kernel works, which is, first of all, awesome! Therefore, is it possible that the kernel does not boot because of those options enabled?
Ok, so my next step is gonna be to compile your xenomai-4.4 kernel. Thank you very much!
So in later kernel’s, you need to specify which “uart” LL-debugging is going to use. This is one reason it’s not enabled by default, as it very “board” specific.
The 4.9.x-xenomai branch really didn’t get any downstream users. Whereas the 4.4.x-xenomai branch is used by multiple groups and shipped by default in a few beagleboard based products today.
So in later kernel’s, you need to specify which “uart” LL-debugging is going to use. This is one reason it’s not enabled by default, as it very “board” specific.
That’s weird because I actually did this. I chose option “OMAP3 UART3” which was recommended somewhere online and which mentions “beagle” in its help window. So I cannot say why it leads to a not-working kernel.
I’ve successfully built your 4.4-xenomai kernel and its modules. To boot it, I replaced zImage- and .dtb-file and installed the modules to the existing rootfs (from previous 4.14 kernel). Apart from some errors, the kernel actually boots and “uname -r” says “4.4.113”. But, I am not able to run the “latency test” at “/usr/xenomai/bin/latency” and I do not notice any hint of the Xenomai patch. So, how can I test whether Xenomai actually works or not?
You don’t need to build it on “every” unit, just build it once and then copy the files under /usr/xenomai/
Yes, you’ll need to install the build dependices, start with build-essential and autoconf
Thanks, that worked for the first line. But when running the second command (./configure …) I get a weird error which I could not fix with installing packages so far:
./configure: line 13838: syntax error near unexpected token 'FUSE, ’
./configure: line 13838: ` PKG_CHECK_MODULES(FUSE, fuse) ’