OK here's some actual content for this thread outside of chatting about the build system.
Pulling in features from the Xilinx fork to our X4xx kernel sources isn't something we've had any kind of eye on, but it's interesting and we're curious to see how this goes. It's something we'd like to see you succeed in. Currently our X4xx kernel sources are defined as follows: base branch: git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git (see: linux-x4xx.inc <https://github.com/EttusResearch/meta-ettus/blob/kirkstone/meta-ettus-bsp/recipes-kernel/linux/linux-x4xx.inc>), commit: e97bd1e03e6ef58ec47ee7f085f8c14ed6329cf7 (see linux-x4xx_5.10.bb <https://github.com/EttusResearch/meta-ettus/blob/kirkstone/meta-ettus-bsp/recipes-kernel/linux/linux-x4xx_5.10.bb>), patches: meta-ettus-bsp/recipes-kernel/linux/linux-x4xx <https://github.com/EttusResearch/meta-ettus/tree/kirkstone/meta-ettus-bsp/recipes-kernel/linux/linux-x4xx> One option we could discuss is if it were easier for folks if we based our kernel on linux-xlnx instead of mainline (no promises or plans here, just thinking out loud). Not everyone has Piotr-level expertise, and if this would make things easier for folks, that could be something we do going forward. Whichever way we go -- of course you need to pull in patches from the right kernel version. If that's something people struggle with, maybe we can make that clearer? Just fishing for thoughts and/or suggestions here! Cheers, Martin On Thu, Oct 3, 2024 at 1:51 PM <per...@o2.pl> wrote: > Hello Mike, > > I don’t know what your preference regarding setup is, but for me it was > crucial to be able to make changes to the rootfs and kernel quickly and to > be able to remotely reset the device. > > This was especially important when dealing with kernel and bootloader. As > I didn’t have much experience with editing kernel and u-boot sources, it > was indispensable to be able to check my changes and applied patches > quickly (the additional difficulty was that I didn’t have a X410 to see in > action how things should work). > > My setup consisted of NFS server hosting rootfs and TFTP server for > kernel. The bootloader was loaded through JTAG. This way I for example was > able to make a script that: compiled and installed new kernel with the > board turned off or in not working state, tried to boot it, check if system > started correctly and return the result to git bisect. This way (after some > fine-tuning) I was able to run ‘git bisect’ and wait for it to find a > commit where the board started to work. If you are interested how to > configure what I’ve described - ask. > > With this approach you could for example locate when DPU support that you > need was added. Your case seems to be better in one regard though: as you > know what you are looking for you can also look at commit messages and the > code. In my case I didn’t know what was source of problems - the board just > didn’t boot or (in another case) loading ‘nixge’ driver for 10Gb/s ports > crashed the board. > > Piotr > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
