Beaglebone blue, buildroot and wifi

Hi,

I recently purchased a beaglebone blue and tried it with pre-installed image and the latest debian image from beagleboard.org. Everything is ok and the wifi works perfectly.

Now, I want to build my own custom image with buildroot. I have some experience with buildroot and raspberry pi. I managed to have a bootable image with linux console on uart. The problem is that when I try to activate wlan0 (ip link set wlan0 up), the board hangs. I cannot connect to ssh anymore (USB connection), I cannot access it via the uart linux console (no more log from kernel), the heartbeat LED stops blinking, the only thing i can do is ping the board (through USB).

What I have tried so far,

Use different firmware (/lib/firmware/ti-connectivity) from:

  • Buildroot linux-firmware package
  • Beaglebone Black wireless firmware (on github)
  • Pre installed firmware from the official Debian image

Use different device-tree

  • am35x-boneblue.dts built with the linux kernel by buildroot
  • the devicetree provided in the official Debian image

Use different libc

  • µclibc
  • glibc

At this point I end up every time with the symptoms described before. Could anyone help to investigate further?

Thank you,

Thomas

Hi,

I recently purchased a beaglebone blue and tried it with pre-installed image and the latest debian image from beagleboard.org. Everything is ok and the wifi works perfectly.

Now, I want to build my own custom image with buildroot. I have some experience with buildroot and raspberry pi. I managed to have a bootable image with linux console on uart. The problem is that when I try to activate wlan0 (ip link set wlan0 up), the board hangs. I cannot connect to ssh anymore (USB connection), I cannot access it via the uart linux console (no more log from kernel), the heartbeat LED stops blinking, the only thing i can do is ping the board (through USB).

That sounds like a kernel panic.
Is any logging of this event written to a file that you can look at after boot?
Do you get any output the moment it happens?

Do you have the kernel module for wlan compiled into the kernel? You might get a bit more logging if it is a module.

What I have tried so far,

Use different firmware (/lib/firmware/ti-connectivity) from:

  • Buildroot linux-firmware package
  • Beaglebone Black wireless firmware (on github)
  • Pre installed firmware from the official Debian image

Use different device-tree

  • am35x-boneblue.dts built with the linux kernel by buildroot
  • the devicetree provided in the official Debian image

I trust you know that the device tree can be specific for a kernel.
For my beaglebone black, there are huge differences between the beaglebone kernel and the stable kernel from kernel.org.

I would try it as well with the beaglebone kernel and matching device tree.
https://github.com/beagleboard/linux

If you see that working you could backtrack where the differences are.

Use different libc

  • µclibc
  • glibc

I don’t think that matters that much. Errors in those libraries are not that common and would probably cause more errors.
Glibc is used more, so to be safe stick to that.

Hi,

I recently purchased a beaglebone blue and tried it with pre-installed image and the latest debian image from beagleboard.org. Everything is ok and the wifi works perfectly.

Now, I want to build my own custom image with buildroot. I have some experience with buildroot and raspberry pi. I managed to have a bootable image with linux console on uart. The problem is that when I try to activate wlan0 (ip link set wlan0 up), the board hangs. I cannot connect to ssh anymore (USB connection), I cannot access it via the uart linux console (no more log from kernel), the heartbeat LED stops blinking, the only thing i can do is ping the board (through USB).

That sounds like a kernel panic.
Is any logging of this event written to a file that you can look at after boot?
Do you get any output the moment it happens?

I do not have any log after the moment it happens, but I do not believe it is a kernel panic as I can still ping my board through the USB connection. It means that icmp request are handled by the kernel. I think that what happens is a kind of deadlock.

Actually, yesterday, I tried with a different kernel version. I forgot to mention that I was using the branch 4.19-rt from https://github.com/beagleboard/linux. When changing to the default 4.14 version/branch, I was able to use wifi normally. So I belive it is related to the preempt-rt patch, but I have to investigate further.

Do you have the kernel module for wlan compiled into the kernel? You might get a bit more logging if it is a module.

I tried both.

What I have tried so far,

Use different firmware (/lib/firmware/ti-connectivity) from:

  • Buildroot linux-firmware package
  • Beaglebone Black wireless firmware (on github)
  • Pre installed firmware from the official Debian image

Use different device-tree

  • am35x-boneblue.dts built with the linux kernel by buildroot
  • the devicetree provided in the official Debian image

I trust you know that the device tree can be specific for a kernel.
For my beaglebone black, there are huge differences between the beaglebone kernel and the stable kernel from kernel.org.

I would try it as well with the beaglebone kernel and matching device tree.
https://github.com/beagleboard/linux

If you see that working you could backtrack where the differences are.

As I told, I was using a kernel from https://github.com/beagleboard/linux. I even looked for a diff between my working setup am335xx-boneblue.dts and the 4.19-rt am335xx-boneblue.dts, but they are equivalent.

Use different libc

  • µclibc
  • glibc

I don’t think that matters that much. Errors in those libraries are not that common and would probably cause more errors.
Glibc is used more, so to be safe stick to that.

I found on google that µclibc do not implement some stuff related to ipv6, so I gave it a try ^^.

At this point I end up every time with the symptoms described before. Could anyone help to investigate further?

Thank you,

Thomas

Anyway, it works now. Thank you for your quick response, it made me investigate the device-tree further.

Thomas