Hints on debugging driver issues with GW7401 board
Hi, Thanks for all of the work on MicroOS for the last few years. It has been great to use! A few years ago, I worked on getting a Gateworks (Arm64) GW7200 board running with MicroOS and initially things were rough because some of the drivers were not in the upstream Linux kernel yet. Over the course of 4-6 months the drivers showed up in the openSUSE kernel used in MicroOS (and Tumbleweed). Today, it is quite straightforward to install MicroOS on that board by imaging the aarch64 installer DVD onto a MicroSD card and booting from the card. As a stop gap waiting for the upstream drivers to make it into the upstream kernel, I figured out how to patch the openSUSE Linux kernel source with code from Gateworks (who had some of the latest drivers in their Linux kernel repository). That worked, but it isn't a great long term solution since you want to (must?) use the kernels provided from openSUSE to make updates easy. I am now using the GW7401 board, an updated version of the GW7200 that has more MiniPCIe slots, an M.2 slot, an updated processor, and a built-in Ethernet switch. Unfortunately, the drivers for the USB and PCIe interfaces and peripherals are not being fully loaded at boot when using the installer or post install despite using the device tree for the board from the "dtb-freescale" package that matches the aarch64 kernel for MicroOS (6.4.12 as of my recent install). It seems like some of the drivers for the devices described in the device tree are being loaded as kernel modules, but not all of them. I contacted Gateworks about the issue and they were helpful, pointing out the drivers that need to be compiled into the kernel or built as a module for the USB and PCIe to work. They provided me with a .config file for their kernel builds as a reference. Looking at the kernel config file provided in "/proc/config.gz" on the running MicroOS system, it looks like all of the relevant drivers are built as modules, so that is promising. My sense is that there might be some problem with the device tree itself, especially since Gateworks is using slightly older kernels for their supported products (they support Ubuntu out of the box). So, my questions are: 1. Do you have any hints or suggestions on debugging issues with device trees and kernel module loading at boot time? Gateworks demonstrated that the board works fine with a Linux 6.4.6 kernel with their .config file, but they compile most, if not all, of their drivers directly into the kernel. Anyway, I believe that using the openSUSE kernels will work if I can work through some device tree issues. 2. In the short term, if I needed to use a custom kernel for this board with MicroOS, is there any straightforward method to use it with the usual transactional-update process? We already have custom application packages that we host in a repository that MicroOS uses for installing and updating our packages. Could we just include our custom kernel package in our repository somehow despite the fact that MicroOS pushes out its own kernel package? It seems like the kernel is part of the group of packages that MicroOS installs as its base OS, so it isn't clear to me that I can just replace the kernel from MicroOS with my own. Sorry for the long email and thanks again for your help! Paul
Hi, Am Freitag, 15. September 2023, 03:47:08 CEST schrieb Paul Graham:
...
So, my questions are: 1. Do you have any hints or suggestions on debugging issues with device trees and kernel module loading at boot time? Gateworks demonstrated that the board works fine with a Linux 6.4.6 kernel with their .config file, but they compile most, if not all, of their drivers directly into the kernel. Anyway, I believe that using the openSUSE kernels will work if I can work through some device tree issues.
What's the issue precisely? Usually any driver that can be built as a module can be used just fine when loaded as a module, so inherently using =m shouldn't be an issue. Is this about specific platform drivers which don't have any autoloading/hardware matching configured?
2. In the short term, if I needed to use a custom kernel for this board with MicroOS, is there any straightforward method to use it with the usual transactional-update process? We already have custom application packages that we host in a repository that MicroOS uses for installing and updating our packages. Could we just include our custom kernel package in our repository somehow despite the fact that MicroOS pushes out its own kernel package? It seems like the kernel is part of the group of packages that MicroOS installs as its base OS, so it isn't clear to me that I can just replace the kernel from MicroOS with my own.
You can. MicroOS will honour any repo and packaging changes you make. Ideally you set up builds on OBS based on the latest distro kernel to get updates, but this only works if the patches are very simple such that they don't need to be rebased manually all the time. Cheers, Fabian
Sorry for the long email and thanks again for your help!
Paul
On Thu, Sep 14, 2023 at 07:47:08PM -0600, Paul Graham wrote:
Hi,
Thanks for all of the work on MicroOS for the last few years. It has been great to use!
A few years ago, I worked on getting a Gateworks (Arm64) GW7200 board running with MicroOS and initially things were rough because some of the drivers were not in the upstream Linux kernel yet. Over the course of 4-6 months the drivers showed up in the openSUSE kernel used in MicroOS (and Tumbleweed). Today, it is quite straightforward to install MicroOS on that board by imaging the aarch64 installer DVD onto a MicroSD card and booting from the card.
As a stop gap waiting for the upstream drivers to make it into the upstream kernel, I figured out how to patch the openSUSE Linux kernel source with code from Gateworks (who had some of the latest drivers in their Linux kernel repository). That worked, but it isn't a great long term solution since you want to (must?) use the kernels provided from openSUSE to make updates easy.
I am now using the GW7401 board, an updated version of the GW7200 that has more MiniPCIe slots, an M.2 slot, an updated processor, and a built-in Ethernet switch. Unfortunately, the drivers for the USB and PCIe interfaces and peripherals are not being fully loaded at boot when using the installer or post install despite using the device tree for the board from the "dtb-freescale" package that matches the aarch64 kernel for MicroOS (6.4.12 as of my recent install). It seems like some of the drivers for the devices described in the device tree are being loaded as kernel modules, but not all of them.
I contacted Gateworks about the issue and they were helpful, pointing out the drivers that need to be compiled into the kernel or built as a module for the USB and PCIe to work. They provided me with a .config file for their kernel builds as a reference. Looking at the kernel config file provided in "/proc/config.gz" on the running MicroOS system, it looks like all of the relevant drivers are built as modules, so that is promising. My sense is that there might be some problem with the device tree itself, especially since Gateworks is using slightly older kernels for their supported products (they support Ubuntu out of the box).
So, my questions are: 1. Do you have any hints or suggestions on debugging issues with device trees and kernel module loading at boot time? Gateworks demonstrated that the board works fine with a Linux 6.4.6 kernel with their .config file, but they compile most, if not all, of their drivers directly into the kernel. Anyway, I believe that using the openSUSE kernels will work if I can work through some device tree issues.
2. In the short term, if I needed to use a custom kernel for this board with MicroOS, is there any straightforward method to use it with the usual transactional-update process? We already have custom application packages that we host in a repository that MicroOS uses for installing and updating our packages. Could we just include our custom kernel package in our repository somehow despite the fact that MicroOS pushes out its own kernel package? It seems like the kernel is part of the group of packages that MicroOS installs as its base OS, so it isn't clear to me that I can just replace the kernel from MicroOS with my own.
Sorry for the long email and thanks again for your help!
Paul
Is there an initramfs and are the modules included in it? -- Abhinav Praveen
participants (3)
-
Abhinav Praveen -
Fabian Vogt -
Paul Graham